19.1 詳細参照コスト
サーバアプリケーションの多くは、組み込みクライアント(Dclient)経由で他のサーバと通信します。これは、1つのサーバに、アプリケーションが動作するのに必要なすべてのeDirectoryデータが保存されているわけではないためです。1つの例が、要求をチェーンするように設定されたNLDAPです。
サーバアプリケーションがローカルサーバに保存されていないデータを要求した場合、サーバは要求されたデータが保存されている別のサーバを特定してから、クライアントに関するデータを取得します。このプロセスは「ツリーウォーキング」と呼ばれます。通常、サーバがツリーウォーキング経由で要求を満たすまでに時間がかかります。eDirectoryツリー設計に関するベストプラクティスのガイドラインを使用すればツリーウォーキングの必要性が最小限に抑えられますが、それでも必要な場合があります。
図 19-1 詳細参照コスト
図 19-1は、O=MyCorpから始まる、サーバAに対するcn=GHoweのLDAPサブツリー検索を示しています。ただし、cn=GHoweオブジェクトは、サーバA上に存在しないou=MidWestパーティションに配置されています。
クライアントの要求を満たすために必要なデータが保存されたサーバを特定するには、サーバAがサーバBまたはサーバCからデータを取得する必要があります。これを行うには、サーバAがサーバBとサーバCのどちらかに要求を送信する必要があります。サーバAはサーバBを選択しました。サーバ選択プロセスは予測不能であることに注意してください。サーバBはネットワーク上で使用可能で、要求を受け入れますが、要求を迅速に処理できないため、サーバCも必要なデータを提供できたとしても、サーバAはサーバBを待機することになります。サーバBが要求を満たすか、ネットワーク上で使用できなくなるまで、サーバAからの要求が待たされることになります。
以下のセクションで、eDirectoryサーバのパフォーマンスを改善する方法について説明します。
19.1.1 サーバ間接続の向上
詳細参照コスト(ARC)は高度なコストアルゴリズムです。ARCの主な目的は、サーバの機能停止を回避することです。ARCのメリットを以下に示します。
-
サーバのパフォーマンスと耐障害性の向上
-
サーバ間通信の改善
-
負荷分散
-
リモートサーバヘルスモニタリング
-
通信問題の分離と特定の簡素化
ARCを使用すべきなのは誰か?
オブジェクトまたはサービスのローカルコピーが保存されていないサーバは、他のサーバと頻繁に通信するため、ツリーでARCからもたらされた情報を探索する必要があります。ARCは、LDAP環境、特に、優先チェーン処理中に非常に効率的に動作します。
たとえば、図 19-2に示すように、サーバは要求を送り続ける別のサーバから悩まされる場合があります。
図 19-2 ワンストップサーバの影響
必要なオブジェクトのレプリカが保存された使用可能なサーバが他にあったとしても、このサーバが優先されると思われます。これは、サービスまたはレプリカを要求しているサーバがすでにこのサーバに接続されており、処理可能なすべての要求がこのサーバに集中する傾向があるためです。図 19-2は、S4からのすべての要求がS1に送信される様子を示しています。S4はすでにS1に接続されており、S1に対して認証されているため、S2とS3がその要求に応えることができたとしても、S4は青色のパーティションに対するすべての要求をS1に送信し続けます。ARCを使用すれば、より迅速に対応可能なサーバに負荷を分散することによって、このような状況を回避できます。このサーバを必要とするリモートサーバ(S4)上でARCを有効にする必要があります。または、すべてのサーバ上でARCを有効にすることができます。
図 19-3は、「カスケーディングサーバ」の影響を示すもう1つのシナリオを示しています。ここで、サーバS1は頻繁に応答を返しませんが、ダウンしているわけではありません。S1がダウンすると、要求がタイムアウトして、通信が停止します。サーバがまだトランスポートレベルでアップしているが、データベースが低速またはビジーの場合は、他のサーバからの新しい要求を受け付けてキューに入れ続けます。そのため、最終的に、追加のサーバ(S2)がスレッドを使い果たすことになります。未処理の要求がそれぞれリモートサーバでスレッドを取得し、スレッドが使い果たされた段階で、サーバが応答を返さなくなります。ARCは最も高速なサーバに要求を分散することによってこの問題を解決します。これは、低速なまたは不具合のあるサーバは要求の処理に高いコストがかかるためです。
図 19-3 カスケーディングサーバの影響
加えて、ARCは、耐障害性の向上にも役立ちます。サーバの通信問題を簡単に特定する機能を備えています。
19.1.3 ARCの展開
ARCは、通常、サーバ単位で展開されます。ARC対応のこれらのサーバは新しいコスト情報を入手することができます。環境内のすべてのサーバでARCを有効にする必要があります。
展開に関する考慮事項
すべてのサーバ上でARCを有効にすることが役に立つとは限りません。図 19-4は、LDAPサーバの有効性に影響を与える状況を示しています。図では、S4に青色のパーティションではなく緑色のパーティションのコピーが保存されています。青色のパーティションに関する情報が必要なチェーンLDAP要求は、S1、S2、またはS3サーバに送信され、処理される必要があります。これはほとんどのケースで動作します。ARCは、まさにこのような状況に合わせて設計されています。
図 19-4 ARC展開に関する考慮事項
ただし、特定のLDAP操作の実行には困難が伴います。Bob.Blue.Novellなどのユーザを追加することはできますが、Bobを変更するために急いで戻ろうとすると操作が失敗します。図はS2上にBobが追加されたことを示していますが、S3上でBobを変更しようとしても、S3がまだS2と同期していないために操作が失敗して、S3はBobを受け取ることができません。ARCはユーザを別のサーバに誘導する機能を備えています。これは、ARCの方がオリジナルのコスト計算手法より動的なためです。
この設定は、サーバコストがあまり変化せず、正常に同期しているシナリオでうまく動作します。S4上でARCを無効にするとこの問題が解決されます。
19.1.4 詳細参照コストの有効化
ARCは、デフォルトで、eDirectoryに対して有効になっています。NDS iMonitorを使用してARCを設定するには、［］>［］の順にクリックします。加えて、［］、［］、および［］オプションを使用できます。
図 19-5 NDS iMonitorエージェントの環境設定画面
NDSTrace
すべてのUNIXプラットフォームで、NDSTraceツールを使用してARCを有効にします。
表 19-1 UNIXプラットフォーム上でのARCの有効化
|
set NDSTRACE =!ARC |
デバッグ用のgv_ResolveTimesTableを表示します。 |
|
set NDSTRACE =!ARC0 |
詳細参照コストを無効にします。 |
|
set NDSTRACE =!ARC1 |
詳細参照コストを有効にします。 |
|
set NDSTRACE =!ARC2 |
詳細参照コストをデバッグモードで有効にして、コストが決定されるたびに、名前解決DSTraceフラグに対する参照のコストを表示します。 |