|
NIS に限らず DNS でも同様であるが、これらのシステムはネットワークにおける非常に基本的な情報サービスを提供する。したがって、これらのシステムの停止はネットワークが停止した(内部からは外部に接続できなくなり、外部からは消滅したように見える)ように見えてしまうため、必ず動作していなければならない。
このうち、NIS において注意すべき点を簡単にまとめておく。
- マップの配送遅延について考慮した設計を行う
NIS クライアントからのリクエストはブロードキャストであり、コネクションには RPC を利用している。したがって、うまく情報が獲得できないとき(渋滞、停止など) Time Out を大量に発行し、全くクライアントホストが立ち上がらない事態が発生する。Slave の数を増やし、メニーキャストにより NIS サーバを指定することである程度は解消する。基本的に NIS サーバにマシンパワーは要求されない(渋滞を避けるためネットワークは早い方がいいということはいえる)。
- root など、システムが標準で要求するユーザの情報は登録しない
特に root ユーザを NIS に登録し、クライアントがそれに依存してしまうと、クライアント側では NIS サーバが停止した場合、root での login が全くできなくなってしまう。
実際には、NIS サーバが停止するトラブルが発生するよりも、ネットワーク全体におけるトラブル(Hub やルータの異常)の方が発生する割合が高いが、その際 NIS サーバが見えなくなってしまうと、それを利用している他の全てで管理者権限での作業が困難になる。したがって、システムが要求するようなユーザ(はじめから記述されていたり、サーバアプリケーションの都合で導入するようなユーザ)は NIS で提供するような形にしないほうが良い。
- NIS サーバにて提供する情報は OS の情報と別にしておく
良くやってしまうのは、NIS サーバが NIS クライアントにもなっているというケースである。これは絶対に避けるべきである。理由は、NIS は上記 1. でも示したが、NIS サーバ停止状態で遅延が発生する可能性が高い。つまり、NIS サーバ(または NIS サーバホスト)のクリティカルなメンテナンスを行うのに NIS サーバが動作している必要があるという厄介な事態は明示的に避けておくほうが安全である。もちろん、きちんと設定されていれば、例えばネットワークから切り離されたスタンドアローンホストの状態になっても遅延が発生することはないが、往々にして危惧するような状態になる可能性が高い。
具体的には、NIS で提供する /etc 以下の必要なファイルを別の領域にコピーし、その情報を基に map ファイルを作成するようにするとよい。そして、NIS サーバ自体は NIS のクライアントにならないように設定する。
- ルータ越えた位置にある NIS サーバへはメニーキャストで接続
ここで重要な点は、「IP セグメントが変るとブロードキャストが到達しない」という仕組みを理解しているかどうかである。この仕組みを理解していないのに、ネットワークの管理人はやってはならない。ブロードキャストは多くのサーバやサービスシステムで利用されており、また、TCP/IP におけるインターネット層やネットワークアクセス層(OSI 7 層モデルではネットワーク層やデータリンク層)において、通信相手を特定するという基本的な処理においても頻繁に行われている。したがって、ブロードキャストの仕組みを理解していないということは、ネットワーク上の通信について理解していないと言うことである。
|
