| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11g リリース1(11.1.1) B55922-08 |
|
 前 |
 次 |
この章では、Oracle Virtual Directoryのフォルト・トレランスについて説明します。この章の内容は次のとおりです。
Oracle Virtual Directoryは、非常に柔軟にフォルト・トレラント設計を実装できます。Oracle Virtual Directoryではデータがローカルに格納されないため、データのコピーを複製し、複数のOracle Virtual Directoryインスタンス全体にデプロイして管理できます。また、Oracle Virtual Directoryの構成ファイルは、適切なストレージ・エリア・ネットワーク(SAN)構成で簡単に複製または共有できます。
Oracle Virtual DirectoryのLDAPアダプタは、複数のソース・ディレクトリのレプリカおよびマスターへの接続を管理するための優れたサポートを提供します。Oracle Virtual Directoryは、複数のディレクトリ・レプリカに問合せの負荷を分散すると同時に、指定したディレクトリ・マスター・サーバーに追加、変更、削除、および名前変更の操作を転送する機能を備えています。
あるソース・ディレクトリにフォルト・トレランスがなく、LDAPクライアント・アプリケーションがすべてのディレクトリを対象とする問合せを発行した場合、LDAP RFCでは、ディレクトリのすべての部分が正しく応答するか、すべての結果が無効になることが必要です。プロキシ・ディレクトリが使用不可にならないかぎり、通常は問題なく作動します。冗長ディレクトリ・リンクのないソースで障害が発生すると、ユーザー・ベースの一部しか影響を受けない場合でも、グローバル問合せがすべてのディレクトリでフェイルオーバーするようになります。Oracle Virtual Directoryを使用すると、個々のプロキシで障害が発生したときの応答や、障害のサービス全体への影響を制御することができます。
多くのシナリオでは、パートナ企業のユーザーがホスト企業のアプリケーションにアクセスできるようにプロキシ・ディレクトリが提供されます。パートナ・ディレクトリがオフラインまたはアクセス不可になると、その企業のユーザーもアプリケーションを使用できないことが多く、障害はアプリケーションにとってクリティカルではないとみなされます。この場合、停止中のサーバー接続を無視するようにOracle Virtual Directoryを構成することで、その他のパートナが作業を続行することができます。
次に、Oracle Virtual Directoryのフェイルオーバーの主な分野のリストを示します。これらの分野については、この章の後続の項で説明します。
Oracle Virtual Directoryのフォルト・トレランスの実装計画によって異なりますが、クライアントを使用可能なOracle Virtual Directoryシステムにルーティングするためにいくつかの方法を検討することができます。
最も単純な方法は、DNSラウンド・ロビンを定義することです。その場合、DNS管理条件で1つの特定のDNS名が2つのIN Aレコードを持つようになります。こうすることで、特定のアドレスへのリクエストが発生するたびにDNSサーバーが順番のアドレスを割り当てます(たとえば、ldap.corp.comは交互に192.168.0.1および192.168.0.2になります)。この方法は、2つの使用可能なサーバーの間で負荷を分散する場合には便利ですが、いずれかのサーバーが使用不可になるとそれほど有効ではありません。DNSは障害を認識しないため、障害が発生したサーバーのアドレスの番になるたびにクライアントをそのサーバーに送り続けるためです。
Cisco社のLocalDirectorやF5社のBig-IPなどのハードウェア・ロード・バランサを使用することもできます。これらのタイプの製品では、各サーバーのパフォーマンスが監視されて、本来のロード・バランシングが提供されます。この分野には価格や機能の異なる多くの製品があります。
もう1つの方法として、クラスタ内の障害が発生したノードのIPアドレスを切り替えられるクラスタ構成(Veritasなど)を使用することもできます。
Oracle Virtual Directoryシステムのフェイルオーバーは、ローカル・ストア・アダプタを使用していないかぎり比較的容易です。Oracle Virtual Directoryでは、起動時にのみ読み取られる構成ファイルが使用されます。理論上は、同じ構成データを読み取る2つのサーバーは同じ機能を自動的に実行します。
ローカル・ストア・アダプタを使用するときは、その他の問題、特にレプリケーションについても考慮する必要があります。レプリケーションは、ローカル・データ・ストアの変更を反映するように1つのノードが別のノードを更新するプロセスです。
|
注意: Oracle Virtual Directoryはレプリケーション・プロセスを提供しません。Oracle Virtual Directoryは仮想サーバーであるため、バックエンド・ソースの高可用性はOracle Virtual Directory自体の範囲を超えています。
|
ローカル・ストア・アダプタを使用している場合は、クラスタ・ノード間で(および、場合によっては他の非クラスタ・ノード間でも)レプリケーション承諾を設定する必要があります。レプリケーションが構成されると、1つのノードが1次ノードになり、もう一方のノードは1次ノードの下位ノードになります。たとえば、ノード1がプライマリ、ノード2が下位になります。この構成では、両方のノードは同等に機能しますが、書込みを処理できるのはノード1のみです。処理が終了すると、ノード1が自動的にノード2を更新します。
障害に備えて、適切なアクションを実行するようにクラスタ障害の処理スクリプトを構成する必要があります。ノード2で障害が発生した場合、ノード2の復帰時にレプリケーションが再開されるのであれば何も影響はありません。反対にノード1で障害が発生した場合は、ノード2をプライマリにして、ノード1がなくてもノード2で書込み処理を続行できるようにする必要があります。ノード1が稼働できる状態に戻る前に、レプリケーション承諾を逆方向にする必要があります。
Oracle Virtual DirectoryのLDAPアダプタは、すべてのLDAP準拠データ・リポジトリに対して、高機能のフェイルオーバーおよびロード・バランシング管理を提供します。どのプロキシ・ソースまたはアダプタについても、複数のリモート・ホスト・レプリカを定義して、次の特徴を指定できます。
読取り/書込みまたは読取り専用(マスター・ノードまたはレプリカ・ノード)
負荷分散のパーセンテージまたは障害時のみの切替え
図7-1に、Oracle Virtual DirectoryのLDAPアダプタで、トランザクション・ロード・バランシングがどのように実行されるかの例を示します。
Oracle Virtual Directoryには構成可能な接続処理設定があり、次の項目を指定できます。
ハートビート間隔: Oracle Virtual Directoryがプロキシのオンライン・ステータスを確認する間隔。ハートビート間隔は、サーバーの可用性を継続して確認します。プロキシがオフラインになると、Oracle Virtual Directoryはアクティブ・サーバーのリストからそのプロキシを自動的に削除し、その他の定義済レプリカに負荷を分散させます。サーバーが再び使用可能になったことがハートビート間隔で確認されると、サーバーは使用可能リストに戻されます。
タイムアウト時間: 接続に障害が発生したことを判別するまでOracle Virtual Directoryが待機する時間(ミリ秒単位)。接続で障害が発生すると、Oracle Virtual Directoryはレプリカ・リストの次のサーバーを自動的に試行します。応答するプロキシ・サーバーがない場合、LDAPクライアントがDSA使用不可というエラーを受け取ります。
重大性: プロキシの結果が問合せ全体に対して重大であることをOracle Virtual Directoryが判別する方法。問合せが複数のアダプタからのレスポンスを必要とする場合、いずれかのソースが使用不可になっており(すべてのアダプタを問合せできないため)、それらが「重要性」と指定されていると、Oracle Virtual Directoryがエラーで応答します。場合によっては、一部のサーバーしか問合せできないときでもOracle Virtual Directoryからの結果を必要とすることがあります。Oracle Virtual Directoryで部分的な結果を戻すようにするには、結果を得られなくてもよいアダプタを「重要ではない」に設定します。
