各 NIS+ ドメインは、一組の NIS+ サーバーによってサポートされています。各組は、1 つのマスタサーバーと 1 つ以上の複製サーバーを持っています。これらのサーバーは、ドメインのディレクトリ、グループ、テーブルを格納して、ユーザー、管理者、アプリケーションからのアクセス要求に応答します。各ドメインをサポートしているのは、一組のサーバーだけです。一組のサーバーで、複数のドメインをサポートすることができますがお勧めできません。
NIS+ サービスでは、マスターサーバーを少なくとも 1 つ各 NIS+ ドメインに割り当てる必要があります。各ドメインが必要とする複製サーバーの数は、通信量の負荷、ネットワークの構成、NIS クライアントの有無などによって決まります。サーバーメモリーの量、ディスク記憶容量、プロセッサの速度は、クライアントの数とサーバー上に置かれる通信量の負荷によって決まります。
Solaris オペレーティング環境が動作しているワークステーションで、十分な容量のハードディスクさえ備わっていれば、NIS+ サーバーにすることができます。NIS+ のサーバー用、クライアント用のソフトウェアは、どちらも Solaris 製品に含まれています。したがって、Solaris オペレーティング環境がインストールされているワークステーションであれば、サーバーかクライアント、またはこの両方にすることができます。
NIS+ 名前空間をサポートするために必要なサーバーを決定するとき、次の節で説明する要因を考慮する必要があります。
初めに、階層内の各ドメインに 1 つのマスターサーバーを割り当てます。図 2-4 に割り当ての例を示します。
1 つ以上の複製を各ドメインに割り当てます。複製を使うと、マスターサーバーが一時的に使用不可能な場合でも、要求に応答することができます。使用する複製の数については、「名前空間の構造を設計する」を参照してください。
ドメインに最適なサーバーの数 (マスターと複製) は、数多くの要因によって決まります。
すべてのドメインには少なくとも 1 つの複製サーバーがなければなりません。その理由は、マスターサーバーが一時的に使用不可能になったときに NIS+ サービスが破壊されないようにするためです。
クライアントの種類。クライアントワークステーションが古くて遅いと、新しくて高速のマシンより必要な複製の数が少なくなります。
設計するドメイン階層が広域ネットワーク (WAN) リンクをまたがる場合、WAN リンクの両側に複製を置くと安全に実行できるようになります。この場合、リンクの 1 つの側にマスターサーバーと 1 つ以上の複製を設置して、他の側にも 1 つ以上の複製を設置するようにします。こうすると、WAN リンクが一時的に使用不可能になった場合でも、リンクの片側にいるクライアントは NIS+ サービスを継続して使用することができます (しかし、サーバーを WAN の両側に置くと、物理的配置によってではなくグループ機能別に構成されている名前空間の構造が変化します。その原因は、複製は地理的に異なったドメインで、物理的に常駐するためです)。
多くのサイトが分散されている組織では、各サイトは独自のサブドメインを必要とする場合もあります。サブドメインマスターは、さらにレベルの高いドメインに配置されます。その結果、ポイントツーポイントのリンク間では非常に多くの通信量が発生します。地域的な複製を作成すると、要求への応答を早くすることができ、さらにリンク両端でのポイントツーポイントの通信量を少なくすることもできます。
ドメイン内のサブネット数。できれば、1 つの複製を各サブネット上に置きます (ただし、ドメイン全体で 10 以上の複製を使わないでください)。Solaris 1.x NIS クライアントがない場合または、NIS クライアントをサポートするために NIS+ サーバーを NIS 互換モードで使う場合、これらの場合以外には、すべてのサブネットに複製を配置する必要はありません。NIS クライアントは、同じサブネット上にないサーバーにアクセスしません。唯一の例外は Solaris オペレーティング環境の NIS クライアントであり、ypinit(1M) を使って NIS サーバーのリストを指定することができます。この場合、ネットマスク数は正しく設定しなければなりません。
ユーザーと管理者がルックアップを実行する方法。niscat table | grep name コマンドは、nismatch name table コマンドが使用するものよりもはるかに多くのサーバー資源を使用します。
サーバーの種類。新しくて高速なサーバーは、古くて遅いマシンが実行するサービスよりも高速で、より効率的なサービスを行うことができます。したがって、サーバーが強力になるほど、必要とするサーバーが少なくなります。
クライアントの数。ドメイン内のクライアントの数が多くなるほど、必要とする複製サーバーの数も多くなります。ドメイン内のクライアントの数は 1000 以下になるようにしてみてください。 NIS+ クライアントは 、 NIS クライアントよりもサーバー上での負荷が大きくなります。非常に多くのクライアントがほんのわずかのサーバーからサービスを提供されると、ネットワークの性能に影響を与えることになります。
次の 表 2-1 は、応答時間を長くしないで一連のサーバーが処理できるビジークライアントのピーク数を示しています。この結果を作成したベンチマークテストでは、クライアントは、 NIS+ サービスを集中的に利用するように設計されています。各クライアントは、通常のドメインが経験する平均的な負荷ではなく、ピーク負荷をシミュレートするため、多くの NIS+ コールを行いました。したがって、表 2-1 に示した数字は応答時間を長くしないでピーク負荷 (平均負荷ではなく) に適合するように設定された構成を示しています。
表 2-1 サーバーの構成と NIS+ クライアントの数サーバーと複製の構成 | ビジークライアントのピーク数 |
---|---|
Master: SS5-110 | 120 |
Master: SS5-110 Replica: SS10-40 | 220 |
Master: SS5-110 Replica: SS10-40 Replica: SS20-50 | 580 |
Master: Ultra-167 | 420 |
Master: Ultra-167 Replica: SS10-40 | 840 |
表の数字は、クライアントが NIS+ サービスを広範囲に使用した場合、約 100 から 400 のクライアントごとに余分な複製を追加する必要があることを示しています。複製が SS5 の場合、 100 のクライアントごとに新しい複製を 1 つ追加する必要があり、複製が Ultra の場合 400 のクライアントごとに新しい複製を追加する必要があります。この数字は、必要性に応じて調整します。
各種のマシンを使わないでドメインあたりの複製の数を十分なものにする 1 つの方法は、マルチホームのサーバーを作成することです。マルチホームサーバーとは、複数のイーサネットまたはネットワークインタフェースを持っているマシンをいいます。マルチホームサーバーは、1 つのドメイン内にある複数のサブネットにサービスを提供することができます (マスターあるいは複製サーバーに複数のドメインを設定することもできますが、これはお勧めできません)。
サーバーの速度が早いほど、 NIS+ の性能は向上します (しかし、その場合 NIS+ サーバーは SMP マルチスレッドハードウェアを有効に利用することはできません)。NIS+ サーバーは、平均的なクライアントと同等かそれ以上に強力にする必要があります。新しいクライアントのサーバーとして古いマシンを使うことはお勧めできません。
サーバーの速度以外に、その他の多くの要因が NIS+ の性能に影響を与えます。ユーザーおよびホストの数と種類、実行しているアプリケーションの種類、ネットワークトポロジ、負荷の密度、その他の要因すべてが NIS+ の性能に影響します。したがって、 2 つの異なるネットワークにおいて、同じサーバーハードウェアからまったく同じ性能を期待することはできません。
表 2-2 に示したベンチマーク数字は、比較のためにだけ示してあります。ネットワーク上の性能は、この数字とは違うこともあります。下に示したベンチマークの数字は、10000 エントリという標準的なテーブルサイズのテストネットワークに基づいています。表 2-2 を参照してください。
表 2-2 ハードウェア速度と NIS+ 動作の比較マシン | 秒当たりの整合動作数 | 秒当たりの追加動作数 |
---|---|---|
SS5-110 | 400 | 6 |
SS20-50 | 440 | 6 |
PPro-200 | 760 | 13 |
Ultra-167 | 800 | 11 |
Ultra-200 | 1270 | 8 |
サーバーの絶対最低メモリー必要量は 32M バイトですが、中から大規模ドメインのサーバーは少なくとも 64M バイトを装備した方が良いでしょう。
理想的には、 NIS+ サーバーは、 有効な NIS+ テーブルすべての検索可能カラムのエントリすべてを RAM 内に一度に保存できるほど十分なメモリーが必要です。要するに、最適なサーバーメモリーは、すべてのNIS+ テーブルが必要とするの合計メモリー必要量になります。
分かりやすくするため、表 2-3 は検索可能カラムが 5 つある netgroup テーブルのメモリー必要量を示し、表 2-4 は passwd 、 host および cred テーブルのおおよそのメモリー必要量を示しています。
表 2-3 netgroups テーブルに必要なサーバーメモリーエントリの数 | サーバーメモリー使用量 ( M バイト) |
---|---|
6000 | 4.2 |
60000 | 39.1 |
120000 | 78.1 |
180000 | 117.9 |
240000 | 156.7 |
300000 | 199.2 |
表 2-4 passwd テーブルに必要なおおよそのメモリー
エントリの数 | サーバーメモリー使用量 ( M バイト) |
6000 | 3.7 |
60000 | 31.7 |
120000 | 63.2 |
180000 | 94.9 |
240000 | 125.8 |
300000 | 159.0 |
1000000 | 526.2 |
他のテーブルには、検索可能な各カラムに対してエントリ当たりの平均バイト数に予測エントリ数を掛けると、メモリーサイズを予測することができます。たとえば、エントリが 10000 で検索可能カラムが 2 のテーブルがあるとします。最初のカラムでのエントリ当たりの平均バイト数は 9 で、 2 番目のカラムでのエントリ当たり平均バイト数は 37 です。したがって、計算結果は、 (10000 * 9) + (10000 * 37) = 46000 になります。
cred テーブルのエントリ数を予測するときは、ユーザーのローカル資格証明書に 1 つ、DES 資格証明書に 1 つずつ、すべてのユーザーが 2 つのエントリを持つことを忘れないでください。各マシンが使用するエントリは 1 つだけです。
標準的な NIS+ テーブルのそれぞれにある検索可能カラムの数については、「NIS+ 標準テーブル」を参照してください。
必要なディスク容量は、次の 4 つの要因によって決まります。
Solaris オペレーティング環境のソフトウェアが使用するディスク容量
/var/nis (および /var/yp 互換モードで使用する場合) のディスク容量
メモリーの容量
NIS+ サーバー処理に必要なスワップ空間
Solaris オペレーティング環境のソフトウェアは、インストールした量によって、220M バイトを超えるディスク容量を必要とすることがあります。正確な数字については、Solaris のインストールガイドを参照してください。また、サーバーが使用する他のソフトウェアの使用するディスク容量も計算に入れる必要があります。NIS+ ソフトウェア自体は、Solaris 2.4 配布の一部であるため、余分なディスク容量を使用しません。
NIS+ のディレクトリ、グループ、テーブル、クライアント情報は、/var/nis に格納されています。この /var/nis ディレクトリは、1 つのクライアントごとにおよそ 5K バイトのディスク容量を使用します。たとえば、名前空間に 1000 のクライアントがあると、/var/nis には、およそ 5M バイトのディスク容量が必要になります。ただし、同じく /var/nis に格納されるトランザクションのログが大量になる場合があるため、クライアントごとにディスク容量を追加する必要があるかもしれません。この場合は 10〜15M バイトの容量を追加するようお勧めします。つまり、1000 のクライアントがあるときは、15〜20M バイトを /var/nis に割り当ててください。トランザクションのログに対して定期的にチェックポイントを実行する場合、この数字を減らすことができます。 /var/nis には独立したパーティションを設けることをお勧めします。パーティションが独立していることにより、オペレーティングシステムのアップグレードを行う際、その作業が容易になります。
NIS+ を NIS と並行して使用するときは、/var/yp に対して、/var/nis に割り当てている量と同じ容量を割り当てて、NIS から転送する NIS マップを格納してください。
さらに、サーバーの通常のスワップ空間の所要量に加えて、rpc.nisd のサイズの 2 倍のスワップ空間も必要になります。システム上で rpc.nisd が使用しているメモリーの量を確認するには、 nisstat コマンドを実行します。詳細は、 rpc.nisd マニュアルページを参照してください。この空間のほとんどは、コールバック操作中や、 nisping-C によってディレクトリに対しチェックポイントを実行するか、複製サーバーが作成されるときに使用されます。これは、このような手続き中には、NIS+ サーバープロセス全体がフォークされるためです。使用するスワップ空間が、64M バイト未満になることはありません。