4.2 NIS の Master サーバと Slave サーバ

　NIS の構成についてもう少し詳しく説明しておく。図 4.2.1. NIS の基本的な構成を示している。

　NIS には必ず Master サーバ が存在する。ユーザ情報などの管理人が、この Master サーバに情報を登録し更新すると、NIS クライアントではその情報が利用可能となる。

図 4.2.1. NIS の Master サーバと Slave サーバ

クライアントは NIS サーバから情報(map ファイル)を獲得するが、この際重要な点は、NIS の情報要求はブロードキャストであるという点である。ほとんどのケースでは、クライアントはブート時(NIS クライアントアプリケーションが立ち上がったとき)情報を獲得するためにブロードキャストにて情報を要求する。情報を獲得する仕組み自体は RPC (リモートプロシージャコール)にて実現されており、標準的な設定ではリトライを繰り返すため、NIS サーバがダウンしたときやネットワーク的に見えなくなったとき、大きな遅延を発生する可能性が高い。つまり、クライアントホスト自体が全く立ち上がらない(動作しない)という状態に陥る可能性がある。

　このような事態を回避するために、NIS では Slave と呼ばれるセカンダリ(予備)の NIS サーバを用意しておくのが一般的である。NIS Master がダウン・または何らかの理由で大幅な遅延が発生した場合、Slave サーバが代りに応答する。これはリクエストがブロードキャストである点がポイントとなる。簡単に言ってしまえば、NIS のクライアントから見れば Master か Slave の違いは全くなく、「応答が早い NIS サーバ」「応答が遅い NIS サーバ」という違いしかない。

　NIS は特にネットワーク間にまたがるユーザ情報の共有に役立つ。動作のベースが TCP/IP であり、かつ NIS そのものがシンプルであるため、障害の場合の対処が行いやすくサーバのコストを定量的に考えやすい。

この NIS や NFS (Network File System) などの機能を実現するものとして、ディレクトリシステムという仕組みがある。また、Windows NET によるユーザ情報の共有ができる仕組みもある。しかし、Winodws NET における名前解決システムは複雑であり、これを上手に利用するには、かなりの経験と忍耐を要する。これらのシステムをうまく使うにはどうすれば良いか。それは、名前解決(ホスト名からそのホスト名と関連つけられたマシンを探しだし接続・通信する)の手順を正確に理解しているかどうかがポイントになる。NIS, DNS, ディレクトリシステム(特定のベンダのもので構わない)、Windows NET 、どれでもかまわないから、正確に解決手順を理解できているものを使うべきである。理解できていないのであれば、それを使ってはならない。