CMM 定足数

Sun Cluster および Solstice HA クラスタ製品は、異なる方法で CMM 定足数を決定していました。2.0 および 2.1 を含む以前のリリースの Sun Cluster では、クラスタフレームワークによって CMM 定足数が決定され、Solstice HA では、Solstice DiskSuite ボリュームマネージャによって定足数が決定されていました。Sun Cluster 2.2 は、Sun Cluster 2.x と Solstice HA 1.x の両方に基づいています。Sun Cluster 2.2 では、CMM 定足数の決定は、ボリュームマネージャの Solstice DiskSuite、SSVM、CVM のいずれかに依存します。ボリュームマネージャが Solstice DiskSuite の場合、CMM 定足数は、Solstice DiskSuite が管理する、定足数のメタデバイス状態データベースの複製によって決定されます。使用されているボリュームマネージャーが SSVM または CVM の場合は、クラスタネットワークによって決定されます。

Sun Cluster 2.2 では、CMM 定足数は次のようにして決定されます。

• ボリュームマネージャーとして SSVM または CVM を使用するクラスタでは、クラスタ定足数は、参加ノード数と独立した別のデバイスに基づいて合意されます。ノード 2 つのクラスタで、クラスタの投票が割れた場合は、定足数デバイスが定足数に対する第 3 の投票を行います。ノードが 3 つ以上のクラスタで、クラスタの投票が割れた場合は、排他ロック機能 (ノードロック) が、定足数の決定に使用されます。

• ボリュームマネージャとして Solstice DiskSuite を使用するクラスタでは、クラスタ定足数は、メタデバイス状態データベースの複製またはメディエータに基づいて合意されます。ディスクストリングが少なくとも 3 つ存在する構成の場合、メタデバイス状態データベースの複製は、常に、ノードをクラスタ定足数に含めるかどうかを決定することができます。ディスクストリングが 2 つだけで、ノード 2 つの構成では、メディエータという考え方が導入されました。メディエータは、SSVM や CVM の定足数デバイスに似た働きをします。詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。

ノードがクラスタに結合したり、クラスタから切り離されたとき、あるいはクラスタインターコネクト (ノード間の冗長プライベートリンク) で問題が発生した場合は、クラスタ定足数を決定する必要があります。Solstice HA 1.x では、クラスタインターコネクトの障害は二重障害とみなされていました。二重障害の場合、ソフトウェアによってデータの完全性は保証されますが、ユーザーの介入なしにクラスタが動作を継続できる保証はありません。システム設計では、二重障害に対して手動介入が行われるようになっていました。これは、可用性が維持されたとしても、データの完全性が損なわれる可能性のある自動応答に比べて、手動介入がデータの完全性を保証する最も安全な手段と判断されたためです。

Sun Cluster 2.x ソフトウェアは、データの完全性の維持とともに、ユーザーの介入なしにクラスタの可用性を維持するように設計されています。クラスタの可用性を維持するため、Sun Cluster 2.x は、いくつかの新しいプロセスを実装しています。たとえば、定足数デバイスや端末集配信装置、あるいはシステムサービスプロセッサがそうです。Solstice HA 1.x は Solstice DiskSuite を使用して、クラスタ定足数を決定するため、Sun Cluster 2.2 では、ボリュームマネージャーがクラスタ定足数を決定し、またはクラスタインターコネクトで問題が発生したときに発生することを決定する最大の要因であることに注意してください。クラスタインターコネクトの障害が及ぼす影響については、「定足数デバイス (SSVM と CVM)」で説明します。