高可用性を実現するためのレプリケーションと冗長性の使用

レプリケーションを使用すると、1 つのサーバーの停止により、ディレクトリサービスが使用不可になることを回避できます。信頼できるレプリケーショントポロジを構築することで、サーバー障害が発生した場合でも、データセンターにアクセスするすべてのクライアントは最新のデータに確実にアクセスできます。最低でも、ローカルのディレクトリツリーは、少なくとも 1 つのバックアップサーバーにレプリケートする必要があります。ディレクトリの設計者の中には、データの信頼性を最大限保証するために物理的な場所ごとに 3 回はレプリケートしておく必要があると言う人もいます。フォールトトレランスのためにレプリケーションをどれだけ使用するかを決定する場合は、ディレクトリで使用されているハードウェアとネットワークの品質を考慮してください。信頼性の低いハードウェアでは、より多くのバックアップサーバーが必要になります。

通常のデータバックアップポリシー代わりにレプリケーションを使用しないでください。ディレクトリデータのバックアップについては、「バックアップと復元のポリシーの設計」および『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 9 章「Directory Server のバックアップと復元」を参照してください。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーだけを検索するように設定します。異なる DNS ホスト名に配置されている LDAP サーバーを循環するように、カスタムクライアントアプリケーションを作成することができます。それ以外の場合、LDAP クライアントアプリケーションは、Directory Server の単一の DNS ホスト名を検索するようにしか設定できません。バックアップ用の Directory Server へのフェイルオーバーを実現するには、Directory Proxy Server、DNS ラウンドロビン、またはネットワークソートを使用できます。DNS ラウンドロビンまたはネットワークソートの設定と使用については、DNS のマニュアルを参照してください。このコンテキストで Directory Proxy Server がどのように使用されるかについては、「冗長ソリューションの一部としての Directory Proxy Server の使用」を参照してください。

ディレクトリ内のデータを読み取る機能を維持するには、適切な負荷分散戦略を配備する必要があります。読み取りの負荷を複数のレプリカに分散するには、ソフトウェアとハードウェアの両方の負荷分散ソリューションを利用できます。また、これらの各ソリューションは、各レプリカの状態を判定し、それらの負荷分散トポロジへの参加を管理することもできます。これらのソリューションは、総合性や精度の点ではそれぞれ異なっている可能性があります。

地理的に離れた場所にまたがって書き込みフェイルオーバーを維持するには、WAN を介した複数データセンターレプリケーションを使用します。それには、各データセンターに少なくとも 2 つのマスターサーバーを設定し、WAN を介して完全にメッシュ化されるようにそれらのサーバーを設定することが必要です。この戦略によって、トポロジ内のどのマスターに障害が発生してもサービスが失われることはありません。書き込み可能なサーバーが使用不可になった場合は、書き込み操作を代替のサーバーに経路指定する必要があります。書き込み操作の経路を再指定するには、Directory Proxy Server を使用するなど、さまざまな方法があります。

以降の節では、高可用性を確保するためにレプリケーションと冗長性がどのように使用されるかについて説明します。

• 「冗長性のあるレプリケーションアグリーメントの使用」

• 「レプリカの昇格と降格」

• 「冗長ソリューションの一部としての Directory Proxy Server の使用」

• 「アプリケーション分離による高可用性の実現」

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

冗長性のあるレプリケーションアグリーメントの使用

冗長レプリケーションアグリーメントを使用すると、障害発生時の迅速な復旧が可能になります。レプリケーションアグリーメントを有効にしたり無効にしたりできるということは、元のレプリケーショントポロジに障害が発生した場合にのみ使用されるレプリケーションアグリーメントを設定できることを意味します。有効/無効の切り替えは手動で行う必要がありますが、この方法は、レプリケーションアグリーメントが必要になった時点ではじめて設定する場合に比べて、費やす時間がはるかに短くて済みます。冗長レプリケーションアグリーメントの使用は、「高可用性を実現するために冗長性を使用したサンプルのトポロジ」で図を使用して説明されています。

レプリカの昇格と降格

レプリカの昇格または降格によって、レプリケーショントポロジでのそのロールが変更されます。専用のコンシューマとハブを含む非常に大規模なトポロジでは、レプリカのオンライン昇格および降格によって、高可用性戦略の一部が形成される場合があります。たとえば、負荷分散とフェイルオーバーのために 2 つのハブが設定されたマルチマスターのレプリケーション環境を例に考えてみます。1 つのマスターがオフラインになった場合は、読み取り/書き込みの最適な可用性を維持するために、いずれかのハブをマスターに昇格できます。マスターレプリカがオンラインに復帰したときは、ハブレプリカに降格させるだけで元のトポロジを回復できます。

詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「レプリカの昇格と降格」を参照してください。

冗長ソリューションの一部としての Directory Proxy Server の使用

Directory Proxy Server は、高可用性ディレクトリ配備をサポートするように設計されています。このプロキシによって、レプリケートされた一連の Directory Server 間での自動負荷分散や、自動フェイルオーバーおよびフェイルバックが実現されます。トポロジ内の 1 つ以上の Directory Server が使用不可になった場合は、その負荷が残りのサーバー間で比例的に再分散されます。

Directory Proxy Server は、Directory Server をアクティブに監視して、これらのサーバーが常にオンラインになっていることを保証します。このプロキシはまた、実行されている各操作の状態も検査します。すべてのサーバーが、スループットやパフォーマンスの点で同等であるとはかぎりません。主サーバーが使用不可になった場合、副サーバーに一時的にリダイレクトされたトラフィックは、主サーバーが使用可能になるとすぐにふたたび主サーバーに送信されるようになります。

データを分散する場合は、切り離された複数のレプリケーショントポロジを管理する必要があり、それによって管理が複雑になることに注意してください。さらに、Directory Proxy Server は、ユーザー承認の管理をプロキシ認証制御に大きく依存しています。この分散に関与している各 Directory Server で、特定の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシアクセス制御の権限を許可する必要があります。

アプリケーション分離による高可用性の実現

Directory Proxy Server を使用すると、レプリケートされたディレクトリサービスを問題のあるクライアントアプリケーションによる障害から保護することもできます。可用性を向上させるために、各アプリケーションには、マスターまたはレプリカのセットをいくつか限定して割り当てられます。

問題のあるアプリケーションが特定のアクションを実行して、サーバーの停止を引き起したとします。そのアプリケーションが各レプリカに次々とフェイルオーバーした場合に、1 つのアプリケーションでの単一の問題によって、レプリケートされるトポロジ全体が障害に陥る可能性があります。このような状況を回避するために、各アプリケーションのフェイルオーバーや負荷分散を、制限された数のレプリカに限定することができます。起こりうる障害の影響範囲が割り当てられたレプリカのセットにのみ限定されるため、ほかのアプリケーションへの障害の影響は軽減されます。

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

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

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

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

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

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

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

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

障害が発生したコンポーネント	アクション
マスター 1	読み取りおよび書き込み操作は、マスター 1 が修復されている間、Directory Proxy Server を介してマスター 2 とマスター 3 に再経路指定されます。マスター 3 への更新がマスター 2 にレプリケートされるように、マスター 2 とマスター 3 の間の復旧レプリケーションアグリーメントが有効になります。
マスター 2	読み取りおよび書き込み操作は、マスター 2 が修復されている間、マスター 1 とマスター 3 に再経路指定されます。マスター 3 への更新がマスター 1 にレプリケートされるように、マスター 1 とマスター 3 の間の復旧レプリケーションアグリーメントが有効になります。
マスター 3	マスター 3 はバックアップサーバーでしかないため、このマスターに障害が発生しても、ディレクトリサービスは影響を受けません。サービスを中断することなく、マスター 3 をオフラインにしたり、修復したりできます。
Directory Proxy Server	Directory Proxy Server の障害は、重大なサービス中断を引き起します。このトポロジでは、Directory Proxy Server の冗長性のあるインスタンスを作成することをお勧めします。このようなトポロジの例については、「複数の Directory Proxy Server の使用」を参照してください。

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.3 管理ガイド』の「レプリカの初期化」を参照してください。

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

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

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

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

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

   詳細については、 『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「レプリケーションの状態の取得」、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 拡張配備でのアプリケーション分離の使用