高可用性を実現するために冗長性を使用したサンプルのトポロジ

次のサンプルトポロジは、障害が発生した場合も継続的なサービスを提供するために冗長性をどのように使用するかを示しています。

1 つのデータセンターでの可用性向上のためのレプリケーションの使用

次の図に示されているデータセンターには、3 つのマスターを含むマルチマスタートポロジが存在します。このシナリオの場合、3 番目のマスターは、障害が発生した場合の可用性のためにのみ使用されます。読み取りおよび書き込み操作は、問題が発生しないかぎり、Directory Proxy Server によってマスター 1 とマスター 2 に経路指定されます。復旧を高速化し、レプリケーションアグリーメントの数を最小限に抑えるために、復旧レプリケーションアグリーメントが作成されています。これらのアグリーメントは、デフォルトでは無効になっていますが、障害が発生した場合にはすぐに有効にできます。

図 12–1 1 つのデータセンターでのマルチマスターレプリケーション

1 つのデータセンターの障害マトリックス

図 12–1 に示されているシナリオでは、さまざまなコンポーネントが使用不可になる可能性があります。これらの可能性のある障害の場所と、それに対応する復旧のアクションを次の表に示します。

1 つのデータセンターでの復旧手順

1 つのデータセンターに 3 つのマスターが含まれている場合は、1 つのマスターに障害が発生しても、読み取りおよび書き込み機能が維持されます。ここでは、障害が発生したコンポーネントの復旧に適用できる復旧戦略の例について説明します。

次のフローチャートと手順では、マスター 1 という 1 つのコンポーネントに障害が発生したと仮定しています。2 つのマスターに同時に障害が発生した場合は、その問題を修正している間、読み取りおよび書き込み操作を残りのマスターに経路指定する必要があります。

図 12–2 1 つのデータセンターでのサンプルの復旧手順

1 つのコンポーネントの障害から回復するには

1. マスター 1 がまだ停止されていない場合は、停止します。

2. 障害の原因を特定します。

   • 障害が容易に (たとえば、ネットワークケーブルの置き換えなどにより) 修復される場合は、修復を行い、手順 3 に進みます。

   • より重大な問題の場合は、障害の修正にさらに多くの時間がかかる可能性があります。

   1. マスター 1 にアクセスするすべてのアプリケーションが、Directory Proxy Server を介して、マスター 2 またはマスター 3 をポイントするようにリダイレクトされる必要があります。

   2. 最新のバックアップが使用できることを確認します。

      • 最新のバックアップが使用できる場合は、そのバックアップからマスター 1 を再初期化し、手順 3 に進みます。

      • 最新のバックアップが使用「できない」場合は、次のいずれかの操作を行います

        • マスター 1 を再起動し、マスター 2 またはマスター 3 からマスター 1 への全体的な初期化を実行します。

          この手順の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「レプリカの初期化」を参照してください。

        • 全体的な初期化の実行に時間がかかりすぎる場合は、マスター 2 またはマスター 3 からのオンラインエクスポートを実行し、マスター 1 にインポートします。

3. マスター 1 がまだ起動されていない場合は、起動します。

4. マスター 1 が読み取り専用モードになっている場合は、読み取り/書き込みモードに設定します。

5. レプリケーションが正しく機能していることを確認します。

   レプリケーションの確認には、DSCC の dsccmon view-suffixes または insync コマンドを使用できます。

   詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「レプリケーションの状態の取得」、dsccmon(1M)、および insync(1) を参照してください。

2 つのデータセンターにわたる可用性向上のためのレプリケーションの使用

一般に、2 つのデータセンターを含む配備では、1 つのデータセンターについて説明したのと同じ復旧戦略を適用できます。1 つ以上のマスターが使用不可になった場合は、Directory Proxy Server が、ローカルの読み取りおよび書き込みを残りのマスターに自動的に再経路指定します。

先に説明した 1 つのデータセンターのシナリオの場合と同様に、復旧レプリケーションアグリーメントを有効にすることができます。これらのアグリーメントによって、障害が発生した場合も、レプリケートされた更新を両方のデータセンターが引き続き受信できることが保証されます。この復旧戦略は、図 12–3 に示されています。

復旧レプリケーションアグリーメントを使用する代わりに、すべてのマスターが変更をほかのすべてのマスターにレプリケートする、完全にメッシュ化されたトポロジを使用する方法があります。レプリケーションアグリーメントは少ない方が管理しやすくなる可能性はありますが、完全にメッシュ化されたトポロジは使用しない方がよいという技術的な理由は何もありません。

このシナリオでの唯一の SPOF は、各データセンター内の Directory Proxy Server になります。図 12–4 に示すように、この問題を解消するために、冗長性のある Directory Proxy Server を配備することができます。

図 12–3 2 つのデータセンターのための復旧レプリケーションアグリーメント

復旧戦略は、どのような組み合わせでコンポーネントに障害が発生するかによって異なります。しかし、複数の障害に対する基本的な戦略を準備しておけば、その他のコンポーネントに障害が発生した場合にもそれを適用できます。

図 12–3 に示されているサンプルトポロジでは、ニューヨークのデータセンター内のマスター 1 とマスター 3 に障害が発生したと仮定しています。

このシナリオでは、Directory Proxy Server が、ニューヨークのデータセンター内の読み取りおよび書き込みをマスター 2 とマスター 4 に自動的に再経路指定します。これにより、ニューヨークのサイトのローカルの読み取りおよび書き込み機能が維持されることが保証されます。

複数の Directory Proxy Server の使用

次の図に示されている配備には、内部の LDAP サービスへの外部からのアクセスを拒否する企業ファイアウォールが含まれています。内部で開始されたクライアントの LDAP 要求は、ネットワークロードバランサを経由して Directory Proxy Server に転送されるため、IP レベルでの高可用性が確保されます。Directory Proxy Server を実行しているホストを除き、Directory Server への直接アクセスは阻止されます。プロキシが SPOF になるのを回避するために、2 つの Directory Proxy Server が配備されています。

完全にメッシュ化されたマルチマスタートポロジによって、ほかのどのマスターに障害が発生した場合でも、常にすべてのマスターを使用できることが保証されます。簡単のために、この図にはすべてのレプリケーションアグリーメントは示されていません。

図 12–4 ファイアウォール内での高可用性設定

アプリケーション分離の使用

次の図に示されているシナリオでは、アプリケーション 1 のバグによって Directory Server に障害が発生しています。このプロキシ設定によって、アプリケーション 1 からの LDAP 要求がマスター 1 とマスター 3 にしか送信されないことが保証されます。このバグが発生すると、マスター 1 とマスター 3 に障害が発生します。ただし、アプリケーション 2、3、および 4 は、機能している Directory Server に引き続きアクセスできるため無効になりません。

図 12–5 拡張配備でのアプリケーション分離の使用