| 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 |
|
前 |
次 |
第9章「基本的なデプロイメントの設計」で説明した基本的なデプロイメントでは、単一のDirectory Serverで組織の読取りおよび書込み要件を十分に満たすことができることを想定しています。大規模な読取りおよび書込み要件がある組織、つまり、複数のクライアントがディレクトリ・データに同時にアクセスを試みる場合は、スケーラビリティを持つデプロイメントを使用する必要があります。
通常、すべてのデータをキャッシュできる十分なメモリーがある場合、1つのDirectory Serverインスタンスで1秒間に実行できる検索の数は、サーバーのCPUの数と速度に直接関連します。負荷を複数のサーバーに分散することによって、水平方向の読取りスケーラビリティを実現できます。このことは、通常、クライアントが複数のソースからデータを読み取ることができるように、データの追加コピーを提供することを意味します。
マスター・サーバーに対して書込み操作を実行すると、書込み操作がすべてのレプリカに対して実行されるため、書込み操作には水平方向のスケーラビリティがありません。書込み操作を水平方向に拡張する方法は、ディレクトリ・データを複数のデータベースに分割し、それらのデータベースを別々のサーバーに配置することのみとなります。
この章では、Directory Server Enterprise Editionデプロイメントを拡張してより多くの読取りおよび書込みを処理するための様々な方法について説明します。この章の内容は次のとおりです。
ロード・バランシングでは、読取り負荷を複数のサーバーに分散することによって、パフォーマンスを改善します。ロード・バランシングを実現するには、レプリケーション、Directory Proxy Serverまたはこれらの2つの組合せを使用します。
レプリケーションは、ディレクトリ・データを自動的にコピーし、あるディレクトリ・サーバーから別のディレクトリ・サーバーに移動するためのメカニズムです。レプリケーションを使用すると、独自の接尾辞に格納されたディレクトリ・ツリーまたはサブツリーをサーバー間でコピーできます。
|
注意: 構成情報または監視情報のサブツリーはコピーできません。 |
ディレクトリ・データを複数のサーバーにレプリケートすることで、単一のマシンのアクセス負荷を軽減できるため、サーバーのレスポンス時間が短縮され、読取りスケーラビリティが確保されます。また、ディレクトリ・エントリをユーザーに近い場所にレプリケートすると、ディレクトリのレスポンス時間が短縮されます。レプリケーションは、通常、書込みスケーラビリティを実現するためのソリューションではありません。
レプリケーション・メカニズムの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」に記載されています。次の項では、この章で後述されているサンプル・トポロジを確認する前に理解する必要がある基本情報を示します。
レプリケーションに関連するデータベースは、レプリカとして定義されています。
Directory Serverでは、3種類のレプリカが区別されます。
マスターまたは読取り/書込みレプリカ。ディレクトリ・データのマスター・コピーが格納されている読取り/書込みデータベースです。マスター・レプリカでは、ディレクトリ・クライアントからの更新リクエストを処理できます。複数のマスターが含まれているトポロジは、マルチマスター・トポロジと呼ばれます。
コンシューマ・レプリカ。マスター・レプリカ内の情報のコピーが格納されている読取り専用データベースです。コンシューマ・レプリカでは、ディレクトリ・クライアントからの検索リクエストを処理できますが、更新リクエストはマスター・レプリカに委任します。
ハブ・レプリカ。1つ以上のコンシューマ・レプリカを提供するDirectory Serverに格納されている、(コンシューマ・レプリカと同様に)読取り専用データベースです。
次の図は、レプリケーション・トポロジにおけるこれらのレプリカのそれぞれの役割を示しています。
|
注意: 前の図は、説明のみを目的とし、必ずしも推奨トポロジを示すものではありません。Directory Serverでは、マルチマスター・トポロジにおける無制限のマスター数がサポートされています。多くの場合、マスターのみのトポロジが推奨されます。 |
ディレクトリ・サービスを適切にレプリケートするには、本番環境における包括的なテストおよび分析が必要です。ただし、次の基本計算により、レプリケートされたトポロジの設計を開始できます。次の各項では、この計算の結果をレプリケートされたトポロジ設計の基礎として使用します。
ピーク使用時に必要な1秒当たりの最大検索数を見積もります。
この見積りを検索数合計と呼びます。
単一のホストで実行できる1秒当たりの検索数をテストします。
この見積りをホスト当たりの検索数と呼びます。これは、レプリケーションを有効にして評価する必要があります。
ホストで実行できる検索の数は、複数の変数の影響を受けます。これらの中には、エントリのサイズ、ホストの容量およびネットワークの速度があります。これらのテストの実行に役立つ多くのサード・パーティのパフォーマンス・テスト・ツールを使用できます。SLAMD分散負荷生成エンジンは、ネットワークベースのアプリケーションの負荷テストおよびパフォーマンス分析のために設計されたオープン・ソースのJavaアプリケーションです。SLAMDを効果的に使用して、レプリケーション評価のこの部分を実行できます。SLAMDの詳細およびSLAMDソフトウェアのダウンロード方法は、http://www.slamd.com (http://www.slamd.com/)を参照してください。
必要なホストの数を計算します。
ホストの数 = 検索数合計 / ホスト当たりの検索数
レプリケーションでは、次の方法でDirectory Serverの負荷のバランスを取ることができます。
検索アクティビティを複数のサーバーに分散します。
特定のサーバーを特定のタスクまたはアプリケーション専用にします。
通常、「初期レプリケーション要件の評価」で計算したホストの数が約16の場合、またはそれほど大きくない場合は、完全接続トポロジにマスター・サーバーのみを含める必要があります。完全接続とは、すべてのマスターがトポロジ内の他のすべてのマスターにレプリケートされていることを意味します。
|
注意:
|
次の図では、ホストの数が2であることを想定しています。LDAP操作は、クライアント・アプリケーションのタイプに基づいて2つのマスター・サーバー間で分割されます。この方針によって、各サーバーの負荷が減少し、デプロイメントで処理できる操作の合計数が増加します。
グローバル・デプロイメントにおける同様のシナリオは、第11.1.1.2項「WAN経由のマルチマスター・レプリケーション」を参照してください。
デプロイメントに必要なホストの数が16を大幅に超過する場合は、トポロジへの専用コンシューマの追加が必要になることがあります。
次の図では、ホストの数が24であることを想定し、わかりやすくするためにトポロジの一部のみを示しています。残りの10個のサーバーは同じ構成で、合計で8つのマスター、16個のコンシューマがあります。
図10-3 大規模デプロイメントにおけるロード・バランシングのためのマルチサーバー・レプリケーションの使用
次のことを実行する必要がある場合は、これらのコンシューマのいずれかで変更ログを有効にできます。
停止が発生した場合に、コンシューマをマスターに昇格します。
マスターからいずれかのコンシューマに対してバイナリ初期化を実行します。
ホストの数が数百になる場合は、トポロジへのハブの追加が必要になることがあります。このような場合は、マスターよりもハブを多くし、マスターごとに最大10個のハブを用意します。各ハブでは、最大20コンシューマに対するレプリケーションを処理する必要があります。
トポロジのハブの数をマスターまたはコンシューマと同じにすることはできません。
|
注意: マルチマスター・トポロジで一方向のマスター(レプリケーションの変更を受信するが、送信しないマスター)を構成することは、そのマスターへのレプリケーションが中断される可能性があるため、お薦めしません。 |
ホストの数が大きい場合は、サーバー・グループを使用すると、トポロジを簡略化したり、リソース使用率を改善できます。16個のマスターを含むトポロジでは、16個のフルメッシュ・マスターよりも4つのサーバー・グループ(それぞれ4つのマスターを含む)を使用した方が管理しやすくなります。
このようなトポロジは、次の手順で設定します。
レプリケーション承諾のない16個のマスターを構成します。
4つのサーバー・グループを作成し、各グループに4つのマスターを含めます。
単一グループ内にあるすべてのマスター間のレプリケーション承諾を設定します。
各グループの最初のマスター、各グループの2番目のマスターなどの間のレプリケーション承諾を設定します。
次の図は、その結果のトポロジを示しています。
Directory Proxy Serverでは、複数のサーバーを使用して単一のデータ・ソースの負荷を分散できます。また、いずれかのサーバーが使用できなくても、データが使用できる状態を維持することもできます。Directory Proxy Serverによって、データの分散以外に、操作ベースのロード・バランシングが提供されます。つまり、サーバーは、クライアント操作を操作のタイプに基づいて特定のDirectory Serverにルーティングできます。
Directory Proxy Serverでは、操作ベースのロード・バランシング、およびDirectory Server間におけるワークロードの共有方法を決定する様々なロード・バランシング・アルゴリズムがサポートされています。これらの各アルゴリズムの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第16章「Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ」を参照してください。
次の図は、比例アルゴリズムを使用して、2つのサーバーの間で読取り負荷のバランスを取る方法を示しています。サーバーで障害が発生しないかぎり、操作ベースのロード・バランシングによって、すべての書込みはマスター1にルーティングされます。障害が発生すると、すべての読取りおよび書込みはマスター2にルーティングされます。
図10-5 スケーラビリティを持つデプロイメントにおける比例および操作ベース・ロード・バランシングの使用
1つのサーバー・インスタンスで障害が発生した場合、ロード・バランシングの構成は再計算されません。比例ロード・バランシングを使用して、サーバーのロード・バランシングの重みを0に設定することでホット・スタンバイ・サーバーを作成することはできません。
たとえば、3つのサーバーA、BおよびCがある場合を考えます。サーバーAおよびBがそれぞれ負荷の50%を受信するように比例ロード・バランシングが構成されています。サーバーCは、スタンバイ・サーバー専用として設計されているため、負荷は0%になるように構成されています。サーバーAで障害が発生すると、負荷の100%は自動的にサーバーBに移動されます。サーバーBでも障害が発生した場合にのみ、負荷はサーバーCに分散されます。したがって、インスタンスは常にロード・バランシングに参加して常に負荷の一部を担当できる状態であるか、または、すべてのプライマリ・インスタンスで障害が発生した場合はそのサーバーが負荷を引き継ぎます。
飽和ロード・バランシング・アルゴリズムを使用し、スタンバイ・サーバーに適用する重みを低くすることで、ホット・スタンバイに似た処理を実行できます。サーバーは本来のスタンバイ・サーバーではありませんが、プライマリ・サーバーの負荷が大きい場合にのみ、リクエストがこのサーバーに分散されるようにアルゴリズムを構成できます。事実上、1つのプライマリ・サーバーが無効になっている場合は、他のプライマリ・サーバーの負荷が増大するため、リクエストをスタンバイ・サーバーに分散することが必要となります。
書込み操作では、リソースが大量に使用されます。クライアントが書込み操作をリクエストすると、データベースで次の一連のイベントが発生します。
バックエンド・データベースがロックされます。
エントリがデータベース・キャッシュでロックされます。
アクセス制御チェック・プラグインが呼び出されます。
バックエンドの操作前プラグインが呼び出されます。
データベース・トランザクションが開始されます。
データベース・ファイルが更新されます。
古いエントリ・キャッシュが新しいデータに置き換えられます。
データベース・トランザクションがコミットされます。
バックエンドの操作後プラグインが呼び出されます。
バックエンド・データベースのロックが解除されます。
この複雑な手順によって書込みの回数が増加するため、パフォーマンスへの重大な影響が発生する場合があります。
企業の成長に伴い、より多くのクライアント・アプリケーションからの、ディレクトリへの迅速な書込みアクセスが必要になります。また、単一のDirectory Serverに格納される情報が増加することにより、ディレクトリ・データベース内のエントリの追加または変更のコストが増大します。これは、索引が大きくなり、索引に含まれる情報の操作に、より長い時間がかかるようになるためです。
場合によっては、メモリーにすべてのデータをキャッシュすることによってのみサービス・レベル合意を達成できます。ただし、データが大きすぎて、単一のメモリー・マシンに収まらないことがあります。
ディレクトリ・データの量がこの程度まで増加した場合は、複数のサーバーに格納できるようにデータを分割する必要があります。1つの方法として、階層を使用して情報を分割することをあげることができます。情報をある基準に基づいて複数のブランチに分割することによって、各ブランチを別のサーバーに格納できます。その後、各サーバーにチェーンまたはリフェラルを構成して、クライアントがシングル・ポイントからすべての情報にアクセスできるようにすることができます。
このように分割する場合、各サーバーはディレクトリ・ツリーの一部のみを担当します。分散されたディレクトリは、ドメイン・ネーム・サービス(DNS)と同じように動作します。DNSでは、DNSネームスペースの各部分が特定のDNSサーバーに割り当てられます。同じ方法で、クライアントの観点から1つのディレクトリ・ツリーを保持したまま、ディレクトリ・ネームスペースを複数のサーバーに分散できます。
階層ベースの分散メカニズムには短所があります。主な問題は、このメカニズムではクライアントが情報の場所を正確に把握している必要があるということです。または、クライアントは、データを見つけるために広範な検索を実行する必要があります。別の問題として、一部のディレクトリ対応アプリケーションには、複数のブランチに分割された情報を処理する機能がありません。
Directory Serverでは、チェーンおよびリフェラル・メカニズムとともに階層ベースの分散がサポートされています。ただし、分散機能は、スマート・ルーティングがサポートされているDirectory Proxy Serverでも提供されています。この機能を使用すると、企業に最適な分散メカニズムを決定できます。
Directory Serverでは、データが高パフォーマンスのディスクベースLDBMデータベースに格納されます。各データベースはファイルのセットで構成され、ファイルには、そのセットに割り当てられているすべてのデータが含まれます。ディレクトリ・ツリーの異なる部分を異なるデータベースに格納できます。たとえば、次の図に示すように、ディレクトリ・ツリーに3つのサブ接尾辞が含まれている場合を考えます。
3つのサブ接尾辞のデータは、次の図に示すように3つの異なるデータベースに格納できます。
ディレクトリ・ツリーをデータベースに分割すると、データベースを複数のサーバーに分散できます。通常、この方針は複数の物理マシンと同じであり、これにより、パフォーマンスが向上します。前の図の3つのデータベースは、次の図に示すように2つのサーバーに格納できます。
データベースを複数のサーバーに分散すると、各サーバーで実行する必要のある作業の量が削減されます。したがって、単一サーバーよりもかなり多くのエントリを保持できるように、ディレクトリを拡張できます。Directory Serverではデータベースの動的な追加がサポートされているため、ディレクトリ全体を使用できない状態にすることなく、新しいデータベースを必要に応じて追加できます。
Directory Proxy Serverでは、ディレクトリ情報を複数のサーバーに分割しますが、データの階層を変更する必要はありません。データ分散の重要な側面は、データ・セットを論理的に分割できることです。ただし、あるクライアント・アプリケーションで機能する分散ロジックは、別のクライアント・アプリケーションで機能しないことがあります。
このため、Directory Proxy Serverを使用して、データの分散方法およびディレクトリ・リクエストのルーティング方法を指定できます。たとえば、LDAP操作は、ディレクトリ情報ツリー(DIT)階層に基づいて様々なディレクトリ・サーバーにルーティングできます。操作は、操作タイプまたはカスタム分散アルゴリズムに基づいてルーティングすることもできます。
Directory Proxy Serverによって、事実上、分散の詳細がクライアント・アプリケーションから隠されます。クライアントの観点から、単一ディレクトリでディレクトリ問合せに対応します。クライアント・リクエストは、特定の分散方法に従って分散されます。次の各項で説明するように、異なるルーティング方針をDITの異なる部分に関連付けることができます。
この方針は、ディレクトリ・エントリをDIT構造に基づいて分散するために使用できます。たとえば、サブツリーo=sales,dc=example,dc=comのエントリをDirectory Server Aにルーティングし、サブツリーo=hr,dc=example,dc=comのエントリをDirectory Server Bにルーティングできます。
場合によっては、DIT構造を使用することなく、エントリを複数のディレクトリ・サーバーに分散する必要があります。たとえば、サブスクライバを表すエントリをou=subscribers,dc=example,dc=comに格納するサービス・プロバイダを考えます。サブスクライバの数が増加すると、サブスクライバをサブスクライバIDの範囲に基づいて複数のサーバーに分散することが必要になる場合があります。カスタム・ルーティング・アルゴリズムでは、範囲が1-10000のIDを持つサブスクライバ・エントリをDirectory Server Aに配置し、範囲が10001-無限のIDを持つサブスクライバ・エントリをDirectory Server Bに配置できます。サーバーBのデータが大きすぎる場合は、2000から始まるIDを持つエントリを新しいサーバーServer Cに配置できるように分散アルゴリズムを変更できます。
Directory Proxy ServerのDistributionAlgorithmインタフェースを使用して、独自のルーティング・アルゴリズムを実装できます。
このシナリオでは、企業は顧客データを地理的な場所に基づいて3つのマスター・サーバーに分散します。イギリスを本拠地としている顧客は、データをロンドンのマスター・サーバーに格納しています。フランスの顧客は、データをパリのマスター・サーバーに格納しています。日本の顧客のデータは、東京のマスター・サーバーに格納されています。顧客は、独自のデータを単一のWebベースのインタフェースで更新できます。
ユーザーは、Webベースのアプリケーションを使用して、データベースの独自の情報を更新できます。認証フェーズでは、ユーザーは電子メールアドレスを入力します。イギリスの顧客の電子メール・アドレスは、*@uk.example.comという形式です。フランスの顧客の場合、電子メール・アドレスの形式は*@fr.example.com、日本の顧客の場合は*@ja.example.comです。Directory Proxy Serverは、LDAP対応のクライアント・アプリケーションを介してこれらのリクエストを受信します。その後、Directory Proxy Serverは、認証時に入力された電子メール・アドレスに基づいて、リクエストを適切なマスター・サーバーにルーティングします。
このシナリオを次の図に示します。
図10-9 Directory Proxy Serverを使用したバインドDNに基づくリクエストのルーティング
多くの場合、DITの最上位では、データ分散は必要ありません。ただし、ツリーの分散された部分のエントリでは、ツリーの上位のエントリが必要になることがあります。この項では、この場合の分散方針をどのように設計するかを示すサンプル・シナリオについて説明します。
Example.comには、グループ用の1つのサブツリーおよびユーザー用の別のサブツリーがあります。グループ定義の数は小さく、非常に静的ですが、ユーザー・エントリの数は大きく、拡大し続けます。したがって、Example.comでは、ユーザー・エントリのみを3つのサーバーに分散する必要があります。ただし、グループ定義、そのACI、およびネーミング・コンテキストの最上位にあるACIは、ユーザー・サブツリーの下のエントリすべてにアクセスする必要があります。
次の図は、データ分散要件の論理ビューを示しています。
ou=peopleサブツリーは、各エントリのsn属性の先頭文字に従って3つのサーバーに分割されています。ネーミング・コンテキスト(dc=example,dc=com)およびou=groupsコンテナは、各サーバーの1つのデータベースに格納されています。このデータベースは、ou=peopleの下のエントリにアクセスできます。ou=peopleコンテナは、その独自のデータベースに格納されています。
次の図は、個々のDirectory Serverにおけるデータの格納方法を示しています。
ou=peopleコンテナは、最上位コンテナの接尾辞ではありません。
前述した各サーバーは、分散チャンクと考えられます。ネーミング・コンテキストおよびou=groupsの下のエントリを含む接尾辞は、各チャンクで同じです。したがって、マルチマスター・レプリケーション承諾は、この接尾辞に対して、3つの各チャンクをまたいで設定されます。
可用性を確保するために、各チャンクもレプリケートされます。したがって、チャンクごとに少なくとも2つのマスター・レプリカが定義されています。
次の図は、チャンクごとに3つのレプリカが定義されたDirectory Server構成を示しています。わかりやすくするために、レプリケーション承諾は1つのチャンクについてのみ示されていますが、他の2つのチャンクでも同じです。
Directory Proxy Serverを使用したディレクトリ・データへのクライアント・アクセスは、データ・ビューで提供されます。データ・ビューの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第17章「Directory Proxy Serverの配布」を参照してください。
このシナリオでは、分散された接尾辞ごとに1つのデータ・ビューが必要であり、ネーミング・コンテキスト(dc=example,dc=com)およびou=groupsサブツリーに1つのデータ・ビューが必要です。
次の図は、分散データへのアクセスを提供するDirectory Proxy Serverデータ・ビューの構成を示しています。
分散データは、分散アルゴリズムに従って分割されます。使用する分散アルゴリズムを決定する場合は、データの量が変化する可能性があること、および分散方針は拡張可能である必要があることに留意してください。データの完全な再分散を必要とするアルゴリズムは使用しないでください。
たとえば、uidに基づく数値配布アルゴリズムは、容易に拡張できます。最初にuid=0-999およびuid=1000-1999という2つのデータ・セグメントを設定すると、後の段階で、uid=2000-2999という3つ目のセグメントを容易に追加できます。
リフェラルはサーバーによって返される情報であり、操作リクエストを続行するために接続するサーバーをクライアント・アプリケーションに通知します。Directory Proxy Serverを使用して分散ロジックを管理しない場合は、分散データ間の関係を別の方法で定義する必要があります。関係を定義する1つの方法として、リフェラルを使用する方法があります。
Directory Serverでは、リフェラルをいつどのように返すかを構成する方法が3つサポートされています。
デフォルトのリフェラル。サーバーに一致する接尾辞がないDNをクライアント・アプリケーションが示した場合、ディレクトリはデフォルトのリフェラルを返します。
接尾辞リフェラル。メンテナンス時またはセキュリティ上の理由で接尾辞全体がオフラインになっている場合、サーバーはその接尾辞で定義されているリフェラルを返します。クライアントが書込み操作をリクエストした場合、接尾辞の読取り専用レプリカもマスター・サーバーへのリフェラルを返します。
スマート・リフェラル。これらのリフェラルは、ディレクトリ内のエントリに格納されます。スマート・リフェラルは、DNがスマート・リフェラルを含むエントリのDNに一致するサブツリーを把握しているDirectory Serverを指します。
次の図は、リフェラルを使用して、イギリスのクライアントをグローバル・トポロジ内の適切なサーバーに誘導する方法を示しています。このシナリオでは、クライアント・アプリケーションがリフェラルに従うには、トポロジ内のすべてのサーバーに(TCP/IPレベルで)接続できる必要があります。
Directory Proxy Serverをリフェラル・メカニズムと組み合せて使用することで、同じ結果を得ることができます。このようにDirectory Proxy Serverを使用する利点は、クライアント・アプリケーションの負荷および複雑さが減少することです。クライアント・アプリケーションは、Directory Proxy ServerのURLのみを認識します。分散ロジックがなんらかの理由で変更される場合、この変更はクライアント・アプリケーションに対して透過的に行われます。
次の図は、前に説明したシナリオをDirectory Proxy Serverの使用により簡略化する方法を示しています。クライアント・アプリケーションは、リフェラルを処理するProxy Serverに常に接続します。
