第 11 章 グローバル配備の設計

グローバル配備では、1 つ以上の地域にあるデータセンターのディレクトリサービスへのアクセスが必要になります。この章では、複数のデータセンターにわたって Directory Server Enterprise Edition を効率的に配備するための戦略について説明します。これらの戦略によって、第 5 章「サービスレベル契約の定義」で説明されているサービスの品質に対する要件は満足されることが保証されます。

この章の内容は次のとおりです。

• 「複数のデータセンターにわたるレプリケーションの使用」

• 「グローバル配備での Directory Proxy Server の使用」

複数のデータセンターにわたるレプリケーションの使用

レプリケーションの 1 つの目標は、LDAP サービスの地理的な分散を可能にすることです。レプリケーションを使用すると、複数のサーバー上や、複数のデータセンターにわたって情報の同一のコピーを保持することができます。レプリケーションの概念については、このガイドの第 10 章「拡張配備の設計」でその概要が、さらに『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」でその詳細が説明されています。この章では、グローバル配備で使用されるレプリケーション機能に焦点を絞ります。

WAN を介したマルチマスターレプリケーションの使用

Directory Server では、WAN を介したマルチマスターレプリケーションをサポートしています。この機能により、マルチマスターレプリケーション設定を地理的に離れた場所にある複数のデータセンターに国際的に配備できます。

一般に、「初期レプリケーション要件の評価」で計算されるホストの数が 16 より小さいか、またはそれより大幅に大きくはない場合、トポロジを、完全に接続されたトポロジ内にマスターサーバーのみが含まれる、つまり、すべてのマスターがトポロジ内のほかのすべてのマスターにレプリケートする状態にしてください。WAN 構成を介したマルチマスターレプリケーションでは、WAN で分離されたすべての Directory Server インスタンスが、Directory Server 5.2 より前のバージョンを実行していないようにしてください。4 つを超えるマスターを含むマルチマスタートポロジの場合は、Directory Server 6.x が必要です。

レプリケーションプロトコルでは、完全な非同期サポートのほか、ウィンドウ、グループ化、および圧縮のメカニズムが提供されます。これらの機能によって、WAN を介したマルチマスターレプリケーションが実行可能になります。レプリケーションのデータ転送速度は、帯域幅の点から見て、使用可能な物理媒体で可能になる速度を常に下回ります。レプリカ間の更新の量が、物理的に、使用可能な帯域幅に収まりきらない場合は、チューニングを行なっても、更新の重い負荷の下でのレプリカの発散を避けることはできません。レプリケーションの遅延や更新のパフォーマンスは、変更の頻度、エントリサイズ、サーバーハードウェア、平均待ち時間、平均帯域幅など (ただし、これらには限定されない) を含む多くの要因に依存します。

デフォルトでは、レプリケーションメカニズムの内部パラメータは WAN に合わせて最適化されています。ただし、上で述べた要因のためにレプリケーションの速度低下が発生している場合は、ウィンドウサイズやグループサイズのパラメータを実験的に調整することをお勧めします。また、ネットワークのピーク時間帯を避けるようにレプリケーションをスケジュールして、全体的なネットワーク使用率を向上させることができる可能性もあります。最後に、Directory Server は、帯域幅の使用を最適化するためにレプリケーションデータの圧縮に対応しています。

WAN リンクを介してデータをレプリケートする場合は、データの完全性と機密性を保証する何らかの形式のセキュリティーを確保することをお勧めします。Directory Server で使用可能なセキュリティー手段の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 2 章「Directory Server Security」を参照してください。

グループとウィンドウのメカニズム

Directory Server は、レプリケーションの流れを最適化するためのグループとウィンドウのメカニズムを提供しています。グループのメカニズムを使用すると、変更を個別にではなく、グループで送信するように指定できます。グループサイズは、1 つの更新メッセージにまとめることのできるデータ変更の最大数を表します。ネットワーク接続がレプリケーションのボトルネックになっているように見える場合は、グループサイズを増やし、レプリケーションのパフォーマンスをもう一度チェックしてください。グループサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「グループサイズの設定」を参照してください。

ウィンドウのメカニズムは、サプライヤが処理継続のためのコンシューマからの受信通知を待つことなく、コンシューマに特定の数の更新要求を送信するように指定します。ウィンドウサイズは、コンシューマからの即座の受信通知がなくても送信できる更新メッセージの最大数を表します。メッセージごとに受信通知を待つのではなく、多数のメッセージをすばやく連続して送信する方がより効率的です。適切なウィンドウサイズを使用することにより、レプリカがレプリケーションの更新または受信通知の到着を待つために費やす時間を削除できます。コンシューマレプリカがサプライヤよりも遅れている場合、詳細な調整を行う前に、ウィンドウサイズをデフォルトよりも大きい数字 (100 など) に設定して、レプリケーションのパフォーマンスをもう一度確認してみます。レプリケーションの更新頻度が高く、そのため更新の間隔が短い場合は、LAN で接続されているレプリカでもウィンドウサイズを大きくすると利点が得られます。ウィンドウサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「ウィンドウサイズの設定」を参照してください。

グループとウィンドウのメカニズムはどちらも、変更のサイズに基づいています。そのため、変更のサイズが大幅に変動する場合、これらのメカニズムを使用してレプリケーションのパフォーマンスを最適化することは実用的でない場合があります。変更のサイズが比較的均一である場合は、グループとウィンドウのメカニズムを使用して、差分更新と完全更新を最適化することができます。

レプリケーションの圧縮

グループ化とウィンドウのメカニズムに加えて、Solaris および Linux プラットフォームではレプリケーションの圧縮も設定できます。レプリケーションの圧縮は、レプリケーションの流れを効率化します。それによって、WAN を介したレプリケーションでのボトルネックの発生率が大幅に削減されます。レプリケートされるデータを圧縮すると、CPU 性能は十分だが帯域幅が狭いネットワークや、一括変更をレプリケートする場合など、特定の場合でのレプリケーションのパフォーマンスを向上させることができます。また、大きなエントリを含むリモートレプリカを初期化する場合も、レプリケーションの圧縮によって利点が得られます。広いネットワーク帯域幅が存在する LAN (ローカルエリアネットワーク) ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算によってレプリケーションの速度が低下するためです。

レプリケーションメカニズムは、Zlib 圧縮ライブラリを使用します。予測されるレプリケーション使用率に対して WAN 環境で最高の結果が得られる圧縮レベルを実験的にテストし、選択してください。

レプリケーションの圧縮を設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「レプリケーションの圧縮の設定」を参照してください。

部分レプリケーションの使用

グローバルなトポロジ (データセンターが各国に存在する) には、セキュリティーまたは遵守の理由から、レプリケーションの制限が必要になる場合があります。たとえば、法律上の規制で、特定の従業員情報を米国外にはコピーできないと規定されている可能性があります。または、オーストラリア内のサイトにはオーストラリアの従業員の詳細情報のみが必要になる可能性があります。

部分レプリケーション機能を使用すると、エントリ内に存在する属性のサブセットのみをレプリケートできます。属性リストは、レプリケートできる属性とレプリケートできない属性を判定するために使用されます。部分レプリケーションは、読み取り専用のコンシューマに対してのみ適用できます。

部分レプリケーションの動作の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Fractional Replication」を参照してください。部分レプリケーションを設定する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「部分レプリケーション」を参照してください。

優先順位付きレプリケーションの使用

優先順位付きレプリケーションは、特定の属性に関してレプリケートされるデータのより厳密な一貫性を確保する、強いビジネス要件が存在する場合に使用できます。5.x バージョンの Directory Server の場合、更新は、受信された順序でレプリケートされていました。優先順位付きレプリケーションでは、トポロジ内のほかのサーバーにレプリケートするときに、特定の属性に対する更新を優先させるように指定できます。

優先順位付きレプリケーションには、次の利点があります。

• セキュリティーの強化。優先順位付きレプリケーションは、アカウントのロックアウトのためにデフォルトで使用されます。たとえば、ある従業員が組織を離れたために、その従業員のアカウントをロックする場合を考えてみます。その従業員が、アカウントのロックアウトがまだレプリケートされていないリモートサーバーにログインできてしまうことがないように、アカウントのロックアウトの変更は、ほかの変更がレプリケートされる前にレプリケートされます。

• 一貫性の向上。Directory Server のレプリケーションは、一貫性に関して厳密ではありません。優先順位付きレプリケーションを使用すると、組織内で重要であると見なされる特定の属性のより強力な一貫性を保証できます。

国際的な企業のレプリケーション戦略のサンプル

このシナリオでは、ある企業の 2 つの主要なデータセンターがロンドンとニューヨークに 1 つずつあり、WAN で分離されています。ここでは、通常業務時間内はネットワークが非常に混み合っていることを前提にしています。

このシナリオでは、ホストの数が 8 と計算されています。2 つのデータセンターのそれぞれに、完全に接続された 4 方向のマルチマスタートポロジが配備されています。これらの 2 つのトポロジもまた、相互に完全に接続されています。簡単のために、次の図には 2 つのデータセンター間のすべてのレプリケーションアグリーメントは示されていません。

このシナリオでのレプリケーション戦略には、次の内容が含まれます。

• ディレクトリデータのマスターコピーを、両方のデータセンターのそれぞれのサーバーで保持する。

• 配備全体にわたって高可用性と書き込みフェイルオーバーを実現するために、データセンター間にマルチマスターレプリケーショントポロジを配備する。

• 帯域幅を最適化するために、WAN リンク全体にわたるレプリケーションをスケジュールして、ピークを外れた時間帯にのみ実行されるようにする。

• パフォーマンスを向上させるために、クライアントアプリケーションをローカルサーバーに振り分ける。米国内のクライアントは、ニューヨークのデータセンター内のマスターとの間で読み取り/書き込みを行う。英国内のクライアントは、ロンドンのデータセンター内のマスターとの間で読み取り/書き込みを行う。

図 11–1 2 つのデータセンターでの負荷分散のためのマルチマスターレプリケーションの使用

グローバル配備での Directory Proxy Server の使用

グローバル企業では、集中管理データモデルのために、スケーラビリティーとパフォーマンスの問題が発生する場合があります。このような状況で Directory Proxy Server を使用すると、データを効率的に分散させ、検索要求や更新要求を適切に経路指定することができます。

グローバル企業のための分散戦略のサンプル

ここに示されているアーキテクチャーでは、大きな金融機関の本社がロンドンに存在します。この組織は、ロンドン、ニューヨーク、および香港にデータセンターを保有しています。現在、従業員が使用可能なデータの大部分は、ロンドンにある旧バージョンの RDBMS リポジトリに集中して格納されています。この金融機関のクライアントコミュニティーからのこのデータへのすべてのアクセスが WAN を介して行われます。

この組織は、この集中管理モデルでスケーラビリティーとパフォーマンスの問題を経験しており、分散データモデルに移行することに決定しました。この組織はまた、同時に LDAP ディレクトリインフラストラクチャーも配備することに決定しました。問題のデータは「ミッションクリティカル」であると見なされるため、可用性の高い、フォールトトレラントなインフラストラクチャーに配備する必要があります。

クライアントアプリケーションのプロファイル分析によって、データが顧客ベースのものであることがわかりました。そのため、地域のクライアントコミュニティーによってアクセスされるデータの 95 パーセントは、そのコミュニティーに固有のデータです。アジアのクライアントが北米の顧客のデータにアクセスすることもありますが、この状況はまれにしか発生しません。また、クライアントコミュニティーはときどき、顧客情報の更新も行う必要があります。

次の図は、分散ソリューションの論理的なアーキテクチャーを示しています。

図 11–2 分散したディレクトリインフラストラクチャー

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 に伝えます。