test

Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド

第 12 章 高可用性配備の設計

高可用性とは、ディレクトリサービスに関して同意された最小の「稼働時間」とパフォーマンスのレベルを示しています。同意されたサービスレベルは、組織ごとに異なります。サービスレベルは、システムがアクセスされる 1 日の中の時間帯、システムを保守のために停止できるかどうか、組織にとっての停止時間のコストなどの要因によって異なる可能性があります。ここでは、ディレクトリサービスがこの最小レベルのサービスを提供できなくなるあらゆる要因を障害と定義します。

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

可用性とシングルポイント障害

高可用性を提供する Directory Server Enterprise Edition 配備は、障害からすばやく回復できます。高可用性配備では、コンポーネント障害が個別のディレクトリクエリーに影響する可能性はありますが、完全なシステム障害には陥りません。シングルポイント障害 (SPOF) のシングルポイントとは、システム内でそのコンポーネントに障害が発生すると、システム全体が使用不可になるか、または信頼できなくなってしまうようなコンポーネントを意味します。高可用性配備を設計する場合は、潜在的な SPOF を識別し、どのようにしたらこれらの SPOF を軽減できるかを調査します。

SPOF は、次の 3 つのカテゴリに分類できます。

SPOF の軽減

「冗長性」を使用することにより、単一コンポーネントの障害によってディレクトリサービス全体が障害に陥ることのないように保証できます。冗長性には、冗長性のあるソフトウェアコンポーネント、ハードウェアコンポーネント、またはその両方の提供が含まれます。この例には、個別のホストへの Directory Server の複数のレプリケートされたインスタンスの配備や、Directory Server データベースのストレージでの RAID (Redundant Arrays of Independent Disks) の使用などがあります。レプリケートされた Directory Server による冗長性は、高可用性を実現するためのもっとも効率的な方法です。

また、クラスタリングを使用して高可用性サービスを提供することもできます。クラスタリングには、パッケージ化済みの高可用性ハードウェアおよびソフトウェアの提供が含まれます。この例として、Sun Cluster ハードウェアおよびソフトウェアの配備があります。

冗長性とクラスタリングのどちらを使用するかの決定

この章の残りでは、高可用性を確保するための冗長性とクラスタリングの使用についてさらに詳細に説明します。この節では、各ソリューションの利点と欠点の概要について説明します。

冗長性の利点と欠点

高可用性ディレクトリサービスを提供するためのより一般的なアプローチは、冗長性のあるサーバーコンポーネントとレプリケーションの使用です。冗長ソリューションは通常、クラスタリングソリューションより安価であり、実装もより簡単です。また、これらのソリューションは一般に、管理も容易です。冗長ソリューションの一部としてのレプリケーションには、可用性以外にも多くの機能があることに注意してください。レプリケーションの主な利点は読み取り負荷を複数のサーバーにわたって分割できることですが、サーバー管理の点から見ると、この利点のためにオーバーヘッドが増えます。レプリケーションではまた、読み取り操作に関するスケーラビリティーと、正しく設計されている場合は、一定の制限内で書き込み操作に関するスケーラビリティーも提供されます。レプリケーションの概念の概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。

障害の間に冗長システムが提供する可用性は、クラスタリングソリューションより劣る可能性があります。たとえば、負荷が 2 つの冗長性のあるサーバーコンポーネント間で共有されている環境を考えてみます。1 つのサーバーコンポーネントの障害によってもう一方のサーバーに過剰な負荷がかかり、それによって、クライアント要求へのこのサーバーの応答が遅くなることがあります。応答の遅さは、すばやい応答時間に依存しているクライアントには障害と見られる場合があります。つまり、サービスの可用性が (そのサービスが運用に入っているにもかかわらず)、クライアントの可用性の要件を満足しない可能性があります。

クラスタリングの利点と欠点

クラスタ化されたソリューションの主な利点は、障害からの自動復旧、つまりユーザーの介入を必要としない復旧です。クラスタリングの欠点は、複雑さと、データベース破壊からは回復できない点です。

クラスタ化された環境では、どのクラスタノードが実際にサービスを実行しているかには関係なく、クラスタは Directory Server と Directory Proxy Server に同じ IP アドレスを使用します。つまり、IP アドレスは、クライアントアプリケーションには影響がありません。レプリケートされた環境では、トポロジ内の各マシンに独自の IP アドレスが割り当てられます。この場合は、Directory Proxy Server を使用して、ディレクトリトポロジへのシングルポイントアクセスを提供できます。したがって、レプリケーショントポロジは、クライアントアプリケーションからは実質的に隠されます。この透過性を向上させるために、Directory Proxy Server を、リフェラルと検索参照を自動的に処理するように設定できます。Directory Proxy Server ではまた、負荷分散や、1 台に障害が発生した場合に別のマシンに切り替える機能も提供されます。

冗長性とクラスタリングでの SPOF の処理方法

この章の最初に説明した SPOF の点から見ると、冗長性とクラスタリングは、障害を次の方法で処理します。

ハードウェアレベルでの冗長性

ここでは、ハードウェア冗長性に関する基本的な情報について説明します。多くの刊行物が、高可用性を実現するためのハードウェア冗長性の使用に関する包括的な情報を提供しています。特に、John Wiley & Sons, Inc. によって発行された『Blueprints for High Availability』を参照してください。

ハードウェア SPOF は、次のように広範囲に分類できます。

ネットワークレベルでの障害は、冗長性のあるネットワークコンポーネントを配置することによって軽減できます。配備を設計する場合は、次の冗長性のあるコンポーネントを配置することを検討してください。

冗長性のあるロードバランサをアーキテクチャーに追加することによって、SPOF としてのロードバランサを軽減できます。

データベース破壊の発生については、可用性を確保するためのデータベースフェイルオーバー手法を確立するようにしてください。冗長性のあるサーバーコントローラを使用することにより、ストレージサブシステム内の SPOF を軽減できます。また、コントローラとストレージサブシステムの間の冗長性のある配線、冗長性のあるストレージサブシステムコントローラ、または RAID を使用することもできます。

電源装置が 1 つしかない場合は、この電源がなくなるとサービス全体が使用不可になる可能性があります。この状況を回避するには、ハードウェアへの冗長電源装置の供給 (可能な場合) や、電源の分散化を考慮してください。電源装置内の SPOF を軽減するためのその他の方法には、サージプロテクタ、複数の電源供給元、およびローカルバッテリバックアップの使用や、ローカルでの電源の生成などがあります。

データセンター全体の障害は、たとえば、自然災害が特定の地域を襲った場合に発生します。この場合は、適切に設計された複数データセンターレプリケーショントポロジにより、分散ディレクトリサービス全体が使用不可になることを回避できます。詳細については、「高可用性を実現するためのレプリケーションと冗長性の使用」を参照してください。

ソフトウェアレベルでの冗長性

Directory Server または Directory Proxy Server の障害には、次のものが含まれる可能性があります。

これらの SPOF は、Directory Server と Directory Proxy Server の冗長性のあるインスタンスを配置することによって軽減できます。ソフトウェアレベルでの冗長性には、レプリケーションの使用が含まれます。レプリケーションによって、冗長性のあるサーバーの同期が維持されること、および要求を停止時間なく再経路指定できることが保証されます。詳細については、「高可用性を実現するためのレプリケーションと冗長性の使用」を参照してください。

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

レプリケーションを使用すると、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 を使用するなど、さまざまな方法があります。

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

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

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

レプリカの昇格と降格

レプリカの昇格または降格によって、レプリケーショントポロジでのそのロールが変更されます。専用のコンシューマとハブを含む非常に大規模なトポロジでは、レプリカのオンライン昇格および降格によって、高可用性戦略の一部が形成される場合があります。たとえば、負荷分散とフェイルオーバーのために 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 つのデータセンターでのマルチマスターレプリケーション

図は、3 つのマスター Directory Server と 1 つの Directory Proxy Server を含む 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 つのコンポーネントに障害が発生した場合の復旧手順を示すフローチャート

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

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

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

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

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

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

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

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

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

  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 つのデータセンターのための復旧レプリケーションアグリーメント

冗長性のある復旧レプリケーションアグリーメントを示す 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 ファイアウォール内での高可用性設定

4 つの Directory Server レプリカと 2 つの Directory Proxy Server を含む高可用性アーキテクチャー

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

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

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

図は、Directory Proxy Server がクライアントアプリケーションに基づいて要求を分散しているようすを示しています。

高可用性を実現するためのクラスタリングの使用

物理的な観点から見ると、クラスタは、1 つのエンティティーとして連携して動作する 1 〜 8 個のサーバーで構成されます。これらのサーバーは、アプリケーション、システムリソース、およびデータへの高可用性アクセスを提供するために連携して動作します。各サーバーを、複数の CPU を備えた対称型マルチプロセッサにすることができます。

クラスタリングソリューションは、次のコンポーネントに対して高可用性を提供できます。

クラスタリングによって、ディレクトリアーキテクチャー内のすべての SPOF が軽減されるわけではありません。外部ネットワーク、電源生成、およびデータセンターでの障害は、クラスタリングソリューション以外の手法で軽減するようにしてください。

ディレクトリサービスの可用性向上のために Sun Cluster 3.2 または 3.1 を使用するには、Sun Cluster HA for Directory Server データサービスをフェイルオーバーデータサービスとしてインストールおよび設定する必要があります。この戦略を使用すると、Sun Cluster 環境で Directory Server を安全にフェイルオーバーさせることができます。

次の図は、Sun Cluster アーキテクチャー内の Sun Cluster HA for Directory Server データサービスの位置付けを示しています。

図 12–6 Sun Cluster アーキテクチャー

図は、Sun Cluster アーキテクチャーを使用した高可用性配備を示しています。

ハードウェア冗長性

Sun Cluster ハードウェアシステムのアーキテクチャーは、SPOF によってクラスタが使用不可にならないように設計されています。冗長性のある高速インターコネクト、ストレージシステム接続、およびパブリックネットワークによって、クラスタ接続に単一障害が発生しないことが保証されます。

クライアントは、パブリックネットワークインタフェースを介してクラスタに接続します。ネットワークアダプタカードに複数のハードウェアインタフェースがある場合、そのカードは 1 つ以上のパブリックネットワークに接続できます。複数のネットワークインタフェースカードを含むようにノードを設定できます。これらのカードは、1 枚のカードがアクティブであり、もう 1 枚のカードがバックアップとして機能するように設定されます。

クラスタファイルシステムは、1 つ以上のノード上のカーネルと、配下のファイルシステムおよびボリュームマネージャーの間のプロキシです。クラスタファイルシステムは、ディスクへの物理的な接続が存在するノード上で実行されます。クラスタファイルシステムの可用性を向上させるには、ディスクを複数のノードに接続してください。ローカルファイルシステムで構成したクラスタファイルシステムの可用性は高くありません。ローカルファイルシステムとは、ノードのローカルディスクに格納されているファイルシステムを指します。

ボリュームマネージャーによって、多重ホストディスクのデータ冗長性を向上させるためのミラー化構成または RAID 5 構成が可能になります。多重ホストディスクをディスクのミラー化およびストライプ化と組み合わせることにより、ノード障害と個別のディスク障害の両方から保護できます。

クラスタインターコネクトは、クラスタノード間のクラスタプライベート通信やデータサービス通信を転送するプライベートネットワークです。冗長性のある NIC、接続中継点、およびケーブルによって、ネットワーク障害から保護されます。

クラスタ化されたソリューションでの監視

クラスタでは、すべてのメンバーが継続的に監視されます。障害の発生したノードがクラスタに参加しないようにブロックされるため、破壊されたデータの交換が回避されます。また、クラスタはアプリケーションも監視し、障害が発生した場合は、そのアプリケーションをフェイルオーバーまたは再起動します。

Sun Cluster ソフトウェアのサブシステムである Public Network Management は、アクティブなインタフェースを監視します。アクティブなアダプタに障害が発生した場合は、そのインタフェースをいずれかのバックアップアダプタにフェイルオーバーするために Network Adapter Failover ソフトウェアが呼び出されます。

Cluster Membership Monitor (CMM) は、クラスタメンバーまたはノードごとに 1 セットが割り当てられた、エージェントの分散されたセットです。これらのエージェントは、クラスタインターコネクトを介してメッセージを交換することにより、すべてのノード間の完全な接続を保証します。CMM がノード障害などによるクラスタメンバーシップの変更を検出した場合は、CMM によってクラスタが再構成されます。CMM がノードに関する重大な問題を検出した場合、CMM はクラスタフレームワークに連絡します。次に、クラスタフレームワークがそのノードを強制的に停止し、クラスタメンバーシップからそのノードを削除します。

システム保守

保守が必要なデータやアプリケーションを現在のコンポーネントからシステム上の別のコンポーネントに移動することによって、システム保守の計画的な停止時間を最小限に抑えることができます。保守が完了したら、そのデータやアプリケーションを元のコンポーネントに戻すことができます。

Directory Server Failover Data Service

Directory Server Failover Data Service は、クラスタ内の 1 つのノード上で実行されます。ただし、ノードには、スケーラビリティー向上のために複数の CPU を実装できます。障害モニターが、このフェイルオーバーサービスを定期的に監視します。

Resource Group Manager (RGM) は、データサービスをリソースとして管理します。CMM がクラスタのメンバーシップを変更した場合は、RGM がそのクラスタのオンラインまたはオフラインリソースへの変更を要求する可能性があります。RGM は、フェイルオーバーデータサービスを開始および停止します。

障害からの回復

以降の節では、Directory Server Data Service に障害が発生した場合や、サーバーに障害が発生した場合にサービスがどのように回復されるかについて説明します。

アプリケーション障害が発生した場合の復旧

障害モニターが Directory Server Data Service に障害が発生したと判定した場合、モニターはそのサービスを再開するためのアクションを開始します。実行されるアクションは、そのサービスの設定によって異なります。

フェイルオーバーデータサービスを、障害の発生したサービスの、同じノード上での再開を試みるように設定できます。あるいは、障害の発生したサービスを別のノード上でただちに開始するようにデータサービスを設定することもできます。データサービスが、同じノード上での再開を試みるように設定されている場合、障害モニターはローカルの RGM に連絡します。ローカルの RGM は次に、障害の発生したサービスの再開を試みます。このアクションに失敗すると、ローカルの RGM は、別のノード上でのサービスの開始を試みます。

障害の発生したデータサービスを同じノード上で再開できない場合、ローカルノードの RGM は、別のノードにあるサービスのバージョンの検索を試みます。このアクションは、そのデータサービスが、障害のあと別のノード上で開始するように設定されている場合にも実行されます。ローカルの RGM がそのサービスのバージョンを見つけると、ローカルの RGM はローカルの CMM に連絡して、クラスタインターコネクトを介してリモートノードに連絡するよう要求します。リモートの CMM は次に、そこのローカルの RGM に連絡して、サービスを開始するよう指示します。

次の図は、アプリケーション障害が発生した場合の復旧を示しています。

図 12–7 Sun Cluster アーキテクチャーでのアプリケーション障害と復旧

図は、Sun Cluster アーキテクチャーでのアプリケーション障害のあとの復旧を示しています。

サーバー障害が発生した場合の復旧

Directory Server Data Service が実行されているサーバーまたはノードに障害が発生した場合、サービスは機能している別のノードに移行されます。ユーザーの介入は必要ありません。このサービスは、フェイルオーバーリソースグループ、Directory Server インスタンスを定義しているコンテナ、およびフェイルオーバーの要件をサポートしているホストを使用します。

次の図は、サーバー障害が発生した場合の復旧を示しています。

図 12–8 Sun Cluster アーキテクチャーでのサーバー障害と復旧

図は、Sun Cluster アーキテクチャーでのサーバー障害のあとの復旧を示しています。