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

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

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

• サーバーとソフトウェア

• ストレージサブシステム

• ネットワークアダプタ

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

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

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

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

ハードウェア冗長性

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 3.1 アーキテクチャーでのアプリケーション障害と復旧

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

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

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

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