| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
前 |
次 |
グローバル・デプロイメントでは、複数の地理的な場所またはデータ・センターにあるディレクトリ・サービスへのアクセスが必要になります。この章では、複数のデータ・センターにDirectory Server Enterprise Editionを効果的にデプロイするための方針について説明します。これらの方針によって、第5章「サービス・レベル合意の定義」で特定したサービス品質要件に反しないことが確実になります。
この章の内容は、次のとおりです。
レプリケーションの目標の1つは、LDAPサービスを地理的に分散できるようにすることです。レプリケーションを使用すると、複数のサーバーや複数のデータ・センターに、まったく同じ情報のコピーを保持できます。レプリケーションの概要は、このガイドの第10章「スケーラビリティを持つデプロイメントの設計」およびOracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。
Directory Serverは、異なるプラットフォームで稼働するインスタンス間のレプリケーションをサポートしています。
この項の内容は次のとおりです。
マルチマスター・レプリケーションでは、同じデータのレプリカが複数のサーバーに存在します。マルチマスター・レプリケーションの詳細は、次の項を参照してください。
マルチマスター構成では、複数のマスターでデータが更新されます。各マスターでは変更ログを保守し、各マスターに加えられた変更は、他のサーバーにレプリケートされます。各マスターは、サプライヤおよびコンシューマの役割を果たします。
マルチマスター構成には、次の利点があります。
1つのマスターにアクセスできない場合は、自動書込みフェイルオーバーが行われます。
地理的に分散した環境内のローカル・マスターで更新が行われます。
マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルを使用します。これは同一エントリを別々のサーバーで同時に変更できることを意味します。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。レプリケーションの競合が発生する可能性は、待機時間など、WANの様々な属性によって高くなります。通常、競合解消は自動的に行われます。優先される変更は、数多くの競合ルールによって判断されます。場合によっては、競合を手動で解決する必要があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の一般的なレプリケーションの競合の解決に関する説明を参照してください。
マルチマスター・トポロジでサポートされるマスターの数は、理論的には無制限です。コンシューマおよびハブの数も、理論的には無制限です。ただし、1つのサプライヤがレプリケートできるコンシューマの数は、サプライヤ・サーバーの容量によって異なります。SLAMD分散負荷生成エンジン(SLAMD)を使用すると、サプライヤ・サーバーの容量を評価できます。SLAMDの詳細およびSLAMDソフトウェアのダウンロード方法は、http://www.slamd.com (http://www.slamd.com/)を参照してください。
マルチマスター環境内の各サプライヤには、レプリケーション承諾が必要です。次の図は、2つのマスター・サーバーと、そのサーバーのレプリケーション承諾を示しています。
前の図では、マスターAおよびマスターBが同じデータのマスター・レプリカを保持しています。各マスターは、レプリケーションのフローを指定するレプリケーション承諾を保持しています。マスターAは、レプリケーション承諾1の範囲ではマスターとして機能し、レプリケーション承諾2の範囲ではコンシューマとして機能します。
マルチマスター・レプリケーションは、次のタスクに使用できます。
レプリカIDの使用による更新のレプリケート
異なるレプリカIDから更新が発生した場合は、レプリカIDを使用して更新を行うことで、複数のサプライヤからコンシューマを同時に更新できます。
レプリケーション承諾の有効化または無効化
レプリケーション承諾は、構成後、無効のままにしておき、必要になったときに短時間で有効化できます。この機能により、レプリケーションを柔軟に構成できます。これは、複数のマスターを使用しているかどうかに関係なく実行できます。
Directory Serverは、WAN経由のマルチマスター・レプリケーションをサポートしています。この機能により、国際的な、複数のデータ・センター・デプロイメントにおける、地理的な境界をまたぐマルチマスター・レプリケーション構成を実現できます。
通常、「初期レプリケーション要件の評価」で計算されるNumber of hostsが16未満、または大幅に超過しない場合は、トポロジに、完全に接続されたトポロジ内のマスター・サーバーのみが含まれている、つまり、すべてのマスターがトポロジ内の他のすべてのマスターにレプリケートする状態である必要があります。WAN経由のマルチマスター・レプリケーション構成では、WANで分離されたすべてのDirectory Serverインスタンスが、Directory Server 5.2よりも前のバージョンを実行していないようにしてください。マスターが4つを超えるマルチマスター・トポロジには、Directory Server 6.xが必要となります。
レプリケーション・プロトコルでは、完全な非同期サポート以外に、ウィンドウ、グループ化および圧縮のメカニズムが提供されます。これらの機能によって、WAN経由のマルチマスター・レプリケーションが実行可能になります。レプリケーション・データの転送レートは、使用可能な物理媒体が帯域幅に関して許可している転送レートを常に下回ります。レプリカ間の更新が有効帯域幅と物理的に見合わないほどの量である場合、更新負荷が大きくなったときにレプリカ間に差異が発生することを、チューニングによって回避できなくなります。レプリケーションの遅延と更新のパフォーマンスは、変更率、エントリ・サイズ、サーバー・ハードウェア、平均待機時間および平均帯域幅を含む、様々な要素によって異なります。
レプリケーション・メカニズムの内部パラメータは、デフォルトでWAN用に最適化されています。ただし、前述の要素などが原因でレプリケーションが遅くなる場合は、ウィンドウ・サイズとグループ・サイズのパラメータを実験的に調節してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な使用率を高めることもできます。さらに、Directory Serverでは、帯域幅の使用率を最適化するためにレプリケーション・データ圧縮をサポートしています。
WANリンク経由でデータをレプリケートする場合は、データの整合性と機密性を保証するなんらかの形式のセキュリティを導入することをお薦めします。Directory Serverで使用できるセキュリティ手段の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第5章「Directory Serverのセキュリティ」を参照してください。
Directory Serverは、レプリケーションのフローを最適化するためのグループとウィンドウのメカニズムを提供しています。グループのメカニズムを使用すると、変更を個別にではなく、まとめて送信するように指定できます。グループ・サイズは、1つの更新メッセージにバンドルできるデータ変更の最大数を表します。ネットワーク接続がレプリケーションのボトルネックになっているように見える場合は、グループ・サイズを大きくし、レプリケーションのパフォーマンスを再度チェックしてください。グループ・サイズを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のグループ・サイズの構成に関する説明を参照してください。
サプライヤが処理を継続する前にコンシューマからの確認応答を待つことなく、特定の数の更新リクエストがコンシューマに送信されることが、ウィンドウのメカニズムによって指定されます。ウィンドウ・サイズは、コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、すばやく連続して数多くのメッセージを送信すると、より効率的です。適切なウィンドウ・サイズを使用することにより、レプリカがレプリケーション更新または確認応答の着信を待つ間に費やす時間を削減できます。コンシューマ・レプリカがサプライヤに遅れをとっている場合、さらに調整を行う前にウィンドウ・サイズをデフォルトよりも高い値(100など)に設定して、レプリケーション・パフォーマンスを再度チェックします。レプリケーションの更新頻度が高く、そのために更新間隔が短い場合は、LAN接続のレプリカでも、ウィンドウ・サイズを大きくするとパフォーマンスが向上する可能性があります。ウィンドウ・サイズを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のウィンドウ・サイズの構成に関する説明を参照してください。
グループとウィンドウのメカニズムは、いずれも変更のサイズに基づいています。このため、変更のサイズが大幅に変動する場合は、これらのメカニズムを使用してレプリケーションのパフォーマンスを最適化することが現実的でない場合があります。変更のサイズが比較的安定している場合は、グループとウィンドウのメカニズムを使用して、増分更新と合計更新を最適化できます。
SolarisおよびLinuxのプラットフォームでは、グループ化とウィンドウのメカニズム以外に、レプリケーション圧縮も構成できます。レプリケーション圧縮によって、レプリケーションのフローが効率化され、これにより、WANを経由するレプリケーションでのボトルネックの発生率が大幅に低下します。レプリケートされるデータを圧縮すると、CPU性能は十分でも帯域幅が狭いネットワークの場合や、バルク変更をレプリケートする場合など、特定の状況におけるレプリケーションのパフォーマンスを改善できます。また、大きいエントリが含まれるリモート・レプリカを初期化する場合も、レプリケーション圧縮が有益であることがあります。ネットワーク帯域幅が広いLocal Area Network (LAN)ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算により、レプリケーションが遅くなります。
レプリケーション・メカニズムでは、Zlib圧縮ライブラリが使用されます。予想されるレプリケーション使用率に対して、WAN環境で最高の結果が得られる圧縮レベルを実験的にテストし、選択する必要があります。
レプリケーション圧縮を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリケーション圧縮の構成に関する説明を参照してください。
フル・メッシュのマルチマスター・トポロジでは、各マスターが、他のマスターのそれぞれと接続しています。フル・メッシュのトポロジでは高可用性が実現され、データの整合性が保証されます。次の図は、いくつかのコンシューマを含む、フル・メッシュの4方向マルチマスター・レプリケーション・トポロジを示しています。
図11-2では、変更リクエストに常に対応できるようにするために、4つのマスターに対する接尾辞が保持されています。各マスターでは独自の変更ログを保守します。いずれかのマスターによってクライアントからの変更リクエストが処理されると、その操作がその変更ログに記録されます。次に、そのマスターによって他のマスターにレプリケーションの更新が送信され、その結果、他のコンシューマに送信されます。また、各マスターには、レプリケーション・マネージャ・エントリも格納され、レプリケーションの更新の送信に備えてバインドするとき、このエントリを使用して他のマスターを認証します。
各コンシューマには、レプリケーション・マネージャ・エントリに対応する、1つ以上のエントリが格納されます。コンシューマは、このエントリを使用して、レプリケーションの更新を送信するためにバインドするときにマスターを認証します。各コンシューマでは、レプリケーション・マネージャ・エントリを1つのみ保持でき、このエントリを使用すると、すべてのマスターが、同じレプリケーション・マネージャ・エントリを使用して認証できるようになります。デフォルトでは、コンシューマには、トポロジ内のすべてのマスターに関するリフェラルが設定されています。コンシューマは、クライアントから変更リクエストを受信すると、クライアントにリフェラルを返信します。リフェラルの詳細は、Oracle Directory Server Enterprise Editionリファレンスのリフェラルとレプリケーションに関する説明を参照してください。
図11-3は、マスターAに設定が必要なレプリケーション承諾、変更ログおよびレプリケーション・マネージャ・エントリを詳細に示しています。図11-4は、コンシューマEに関して同じ内容を詳細に示しています。
マスターAには次のものが必要です。
マスター・レプリカ
変更ログ
マスターB、CおよびDのレプリケーション・マネージャ・エントリ(各レプリカで同じレプリケーション・マネージャ・エントリを使用しない場合)
マスターB、C、DおよびコンシューマEとFのレプリケーション承諾
コンシューマEには次のものが必要です。
コンシューマ・レプリカ
レプリケーションの更新を送信するためにバインドするとき、マスターAとBを認証するためのレプリケーション・マネージャ・エントリ
カスケード型レプリケーション構成では、ハブとして機能するサーバーが、サプライヤとして機能するサーバーから更新を受信します。ハブは、それらの更新をコンシューマにリプレイします。次の図は、カスケード型レプリケーション構成を示しています。
カスケード型レプリケーションは、次の場合に役立ちます。
コンシューマの数が多い場合
レプリケーション・トポロジ内のマスターは更新トラフィックをすべて処理するため、コンシューマへのレプリケーション・トラフィックをサポートすると、マスターに大きな負荷がかかる場合があります。レプリケーション・トラフィックの負荷を複数のハブに分散すると、それぞれのハブから、コンシューマのサブセットに対して、レプリケーションの更新を送信できます。
地理的に分散した環境で、ローカル・ハブを使用して接続コストを削減する場合
次の図は、数多くのコンシューマに対するカスケード型レプリケーションを示しています。
図11-6では、ハブ1およびハブ2がレプリケーションの更新をコンシューマの1から10に中継し、ディレクトリの更新を処理するリソースをマスター・レプリカに多く確保しています。
マスターとハブは、変更ログを保持しています。ただし、クライアントからのディレクトリ変更リクエストは、マスターによってのみ処理できます。ハブには、更新をハブに送信するマスターごとに、レプリケーション・マネージャ・エントリが格納されています。コンシューマの1から10には、ハブ1およびハブ2のレプリケーション・マネージャ・エントリが格納されています。
コンシューマおよびハブは、クライアントから受信した検索リクエストを処理できますが、変更リクエストは処理できません。コンシューマとハブは変更リクエストをマスターに委任します。
優先順位付きレプリケーションは、特定の属性に関してレプリケートされるデータについて、より厳密な一貫性を強く求めるビジネス要件がある場合に使用できます。前のバージョンのDirectory Serverの場合は、受信した順序で更新がレプリケートされました。優先順位付きレプリケーションを使用すると、トポロジ内の他のサーバーにレプリケートするとき、特定の属性に対する更新が優先されるように指定できます。
優先順位はブール型の機能であるため、オンまたはオフを選択します。優先順位にレベルはありません。レプリケートを待機している更新が格納されたキューでは、優先順位がオンの更新がレプリケートされた後、優先順位がオフの更新がレプリケートされます。
優先順位のルールは、次のレプリケーション優先順位ルールのプロパティを使用して構成します。
クライアントのアイデンティティ、bind-dn
更新のタイプ、op-tyupe
更新されたエントリまたはサブツリー、base-dn
更新によって変更された属性、att
これらのプロパティの詳細は、repl-priorityを参照してください。
マスターが1つ以上のハブまたはコンシューマ・レプリカに更新をレプリケートするとき、その更新の優先順位は、すべてのハブおよびコンシューマ・レプリカで等しくなります。優先順位付きレプリケーションの優先順位ルールで、パラメータが1つ構成されている場合は、そのパラメータに一致するすべての更新に対して、レプリケーションの優先順位が付けられます。優先順位付きレプリケーションの優先順位ルールで、パラメータが2つ以上構成されている場合は、すべてのパラメータに一致するすべての更新に対して、レプリケーションの優先順位が付けられます。
次の例では、マスター・レプリカがエントリに対する更新のレプリケートを試みた後、エントリの追加がレプリケートされる可能性があります。
マスター・レプリカにエントリを追加した後、マスター・レプリカ上で更新します。
更新操作にはレプリケーションの優先順位を設定しているものの、追加操作には設定していません。
この例では、追加操作がレプリケートされるまで、更新操作をレプリケートできません。追加操作の後、更新は、時系列の順番に従って、レプリケートされることを待機します。
優先順位付きレプリケーションには、次の利点があります。
セキュリティの向上。優先順位付きレプリケーションは、アカウントのロックアウトのためにデフォルトで使用されます。たとえば、ある従業員が組織を離れたため、その従業員のアカウントをロックする場合を考えます。その従業員が、アカウントのロックアウトがまだレプリケートされていないリモート・サーバーにログインできないように、アカウントのロックアウトの変更は、他の変更がレプリケートされる前にレプリケートされます。
一貫性の向上。Directory Serverのレプリケーションは、一貫性に関して厳密ではありません。優先順位付きレプリケーションを使用すると、組織内で重要とみなされる特定の属性に対して、より強力な一貫性を保証できます。
グローバルなトポロジ(複数の国にデータ・センターがある)では、セキュリティまたは法令順守の理由から、レプリケーションの制限が必要になる場合があります。たとえば、法的な規制により、特定の従業員情報を米国国外にコピーできないと規定されている場合があります。あるいは、オーストラリアのサイトでは、オーストラリアの従業員の詳細情報のみが必要になる可能性があります。
部分レプリケーション機能を使用すると、エントリ内にある属性のサブセットのみをレプリケートできます。レプリケートできる属性がどれで、できない属性がどれかを指定するには、属性リストを使用します。部分レプリケーションは、読取り専用のコンシューマに対してのみ適用できます。
部分レプリケーションは、ある接尾辞またはサブ接尾辞の、すべてのエントリの属性のサブセットをレプリケートする場合に使用できます。部分レプリケーションを承諾単位で構成すると、属性をレプリケーションの対象にしたり、レプリケーションから属性を除外できます。通常、部分レプリケーションは、属性を除外するように構成されています。機能と属性間には相互依存性があるため、対象とする属性のリストを管理することは困難です。
部分レプリケーションは、次の目的に使用できます。
イントラネットとエクストラネットのサーバー間で同期する内容のフィルタ
デプロイメントで場所を問わずに利用できる属性を特定の属性に限定する必要がある場合の、レプリケーション・コストの削減
部分レプリケーションは、レプリケーション承諾プロパティのrepl-fractional-include-attr属性およびrepl-fractional-exclude-attr属性を使用して構成します。これらのプロパティの詳細は、repl-agmtを参照してください。部分レプリケーションを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の部分レプリケーションに関する説明を参照してください。
この例では、ある企業の2つの主要なデータ・センターがロンドンとニューヨークに1つずつあり、WANで隔てられています。ここでは、通常の業務時間内は、ネットワークが非常にビジーであることを前提にします。
この例では、Number of hostsを8と計算しています。2つのデータ・センターのそれぞれには、完全に接続された、4方向のマルチマスター・トポロジが配置されています。また、これらの2つのトポロジも、互いに完全接続されています。わかりやすくするため、次の図には、2つのデータ・センター間のレプリケーション承諾が一部のみ示されています。
この例のレプリケーション方針には、次の内容が含まれています。
ディレクトリ・データのマスター・コピーは、両データ・センターのサーバーで保持します。
デプロイメントをまたぐ高可用性および書込みフェイルオーバーを実現するために、データ・センター間にマルチマスター・レプリケーション・トポロジを配置します。
帯域幅を最適化するために、WANリンク全体をまたぐレプリケーションは、ピークを外れた時間帯にのみ実行されるようにスケジュールします。
パフォーマンス向上のために、クライアント・アプリケーションをローカル・サーバーに振り分けます。米国のクライアントは、ニューヨークのデータ・センター内のマスターからの読取りと、これらのマスターへの書込みを実行します。イギリスのクライアントは、ロンドンのデータ・センター内のマスターからの読取りと、これらのマスターへの書込みを実行します。
図11-7 2つのデータ・センターでのロード・バランシングのためのマルチマスター・レプリケーションの使用
グローバル企業では、集中管理データ・モデルにより、スケーラビリティとパフォーマンスの問題が発生する可能性があります。このような状況でDirectory Proxy Serverを使用すると、データを効率的に分散し、検索や更新のリクエストを適切にルーティングできます。
ここで示すアーキテクチャでは、大手金融機関の本社がロンドンにあります。この組織は、ロンドン、ニューヨークおよび香港にデータ・センターを保有しています。現在、従業員が利用できるデータの大部分は、ロンドンにある古いRDBMSリポジトリにまとめて格納されています。この金融機関のクライアント・コミュニティからは、完全にWAN経由でこのデータにアクセスしています。
この集中管理モデルでスケーラビリティとパフォーマンスの問題が発生しているため、この組織では、分散データ・モデルに移行することを決定しています。また、同時に、LDAPディレクトリ・インフラストラクチャを配置することも決定しました。問題のデータはミッション・クリティカルであるとみなされているため、可用性の高い、フォルト・トレラントなインフラストラクチャにデプロイする必要があります。
クライアント・アプリケーションのプロファイル分析から、データが顧客ベースのものであることがわかっています。そのため、地域のクライアント・コミュニティからアクセスされるデータの95パーセントは、そのコミュニティに固有のデータです。まれに、アジアのクライアントが北米の顧客のデータにアクセスすることもありますが、このことはほとんど発生しません。また、クライアント・コミュニティでは、ときどき顧客情報を更新することも必要となります。
次の図は、分散ソリューションの論理アーキテクチャを示しています。
95パーセントがローカル・データへのアクセスというプロファイル結果を受けて、この組織は、ディレクトリ・インフラストラクチャを地理的に分散することにしました。香港、ニューヨークおよびロンドンというそれぞれの地理的な場所に、複数のディレクトリ・コンシューマが配置されます。わかりやすくするため、この図でロンドンのコンシューマは省略されています。これらの各コンシューマは、拠点固有の顧客データを保持するように構成されます。ヨーロッパと中東の顧客のデータは、ロンドンのコンシューマが保持します。北米と南米の顧客のデータは、ニューヨークのコンシューマが保持します。アジアと環太平洋地域の顧客のデータは、香港のコンシューマが保持します。
このデプロイメントでは、クライアント・コミュニティのデータ・リクエストのほとんどが、ローカルのコミュニティに対して行われます。この方針によって、集中管理モデルを大幅に上回るパフォーマンスが実現されます。クライアント・リクエストはローカルに処理されるため、ネットワークのオーバーヘッドが減少します。ローカルのディレクトリ・サーバーによって、ディレクトリ・インフラストラクチャが効果的にパーティション化されるため、ディレクトリ・サーバーのパフォーマンスとスケーラビリティが向上します。コンシューマ・ディレクトリ・サーバーの各セットは、クライアントが更新リクエストを送信した場合はリフェラルを返すように構成されます。また、どこか別の場所に格納されているデータの検索リクエストをクライアントが送信した場合にも、リフェラルが返されます。
クライアントのLDAPリクエストは、ハードウェア・ロード・バランサを介してDirectory Proxy Serverに送信されます。このハードウェア・ロード・バランサによって、クライアントが、常に1つ以上のDirectory Proxy Serverにアクセスできることが保証されます。ローカルに配置されたDirectory Proxy Serverでは、最初に、ローカルの顧客データを保持する複数のローカル・ディレクトリ・サーバーのアレイにすべてのリクエストをルーティングします。Directory Proxy Serverのインスタンスは、複数のディレクトリ・サーバーのアレイ全体にロード・バランスするように構成されます。このロード・バランシングにより、自動フェイルオーバーおよびフェイルバックが実現されます。
ローカルの顧客情報に対するクライアントの検索リクエストは、ローカル・ディレクトリによって満たされます。クライアントには、Directory Proxy Serverを介して適切なレスポンスが返されます。地理的に外部にある顧客情報に対するクライアントの検索リクエストは、最初に、Directory Proxy Serverにリフェラルを返すことで、ローカルのディレクトリ・サーバーによって満たされます。
このリフェラルには、地理的な分散に対応するDirectory Proxy Serverインスタンスを指すLDAP URLが含まれています。ローカルのDirectory Proxy Serverは、ローカル・クライアントのかわりに、このリフェラルを処理します。ローカルのDirectory Proxy Serverは、次に、この検索リクエストをDirectory Proxy Serverの適切な分散インスタンスに送信します。分散Directory Proxy Serverは、この検索リクエストを分散Directory Serverに転送し、適切なレスポンスを受信します。次に、このレスポンスは、Directory Proxy Serverの分散インスタンスおよびローカル・インスタンスを介して、ローカル・クライアントに返されます。
ローカルのDirectory Proxy Serverが受信した更新リクエストは、最初に、ローカルのDirectory Serverが返すリフェラルによって満たされます。Directory Proxy Serverは、ローカル・クライアントのかわりに、このリフェラルに従います。ただし、この場合、この更新リクエストは、プロキシによって、ロンドンに配置されているサプライヤ・ディレクトリ・サーバーに転送されます。サプライヤのDirectory Serverは、この更新をサプライヤ・データベースに適用し、そのレスポンスをローカルのDirectory Proxy Serverを介してローカル・クライアントに返します。その後、サプライヤのDirectory Serverは、この更新を適切なコンシューマのDirectory Serverに伝播します。
