定足数デバイス (SSVM と CVM)

いくつかの状況では (たとえば、2 ノードのクラスタで、両方のクラスタインターコネクトで問題が発生し、両方のノードがまだクラスタのメンバーとして残っている場合)、クラスタ定足数の問題を解決するにあたって、Sun Cluster はハードウェアデバイスの助けを必要とします。定足数デバイスとは、そうしたデバイスのことです。

ボリュームマネージャとして Sun StorEdge Volume Manager (SSVM) または Cluster Volume Manager (CVM) のいずれかを使用しているクラスタでは、定足数デバイスを使用する必要があります。Solstice DiskSuite は、専用のメタデバイス状態データベースの複製を使用することによってクラスタ定足数を確保するので、定足数デバイスを必要としません。つまり、Solstice DiskSuite 構成では、定足数デバイスは必須ではなく、サポートもされません。Solstice DiskSuite を使用するクラスタのインストールでは、scinstall(1M) プログラムによって定足数デバイスが求められたり、受け付けられたりすることはありません。

定足数デバイスは、scinstall(1M) コマンドを使用したクラスタのインストール作業で指定する単なるディスクまたはコントローラです。定足数デバイスは論理的な概念であり、定足数デバイスとして選択された 1 つの具体的なハードウェアに関して、特別な意味はありません。ただし、定足数デバイスは、個別にインポートしたり、エクスポートされる、専用のディスクグループのメンバーである必要があります。SSVM で、ディスクの一部を独立したディスクグループのメンバーにすることはできないので、定足数デバイスにはディスク全体とそのプレックス (ミラー) が必要になります。任意の時点で定足数デバイスがインポートされるノードがどのノードなのかを確定することはできないので、定足数に必要なデータ以外のデータを有用な形で保管することはできません。

定足数デバイスは、ノード間で共有される多重ホストディスクの更新が、いつでも 1 つのノードによってだけ行われるようにします。定足数デバイスは、ノード間のクラスタインターコネクトが失われた場合に使用されます。ノード (ノード 3 つ以上のクラスタの場合は複数のノード) が、過半数の定足数の一部であることを証明できない場合は、そのノードは共有データの更新を試みてはなりません。すべてのノードが採決を行なって、どのノードがクラスタに留まるかを決定します。各ノードは、自身が通信できるノード数を判断します。クラスタの半数以上のノードと通信できる場合、そのノードは過半数の定足数の構成員となり、クラスタのメンバーに留まることが許可されます。ノードが過半数の定足数の一部でない場合、そのノードは終了し、クラスタから切り離されます。

定足数デバイスは「第 3 の投票」として働き、同じ得票数になるのを防ぎます。たとえば、ノード 2 つのクラスでクラスタインターコネクトが失われた場合、それぞれのノードは、定足数デバイスを確保しようとして競合します。図 1-9 は、多重ホストディスク格納装置の 1 つに定足数デバイスが存在する 2 ノードのクラスタ構成を表しています。

図 1-9 定足数デバイスを持つ、2 ノードのクラスタ

定足数デバイスを確保したノードは 2 票の定足数を獲得し、残りのノードは 1 票だけになります。定足数を得たノードは専用のクラスタを起動して、多重ホストディスクをマスターし、もう一方のノードは終了します。

クラスタの再構成では、新しいシステム構成を承認するにあたって、一群のノードと定足数デバイスが投票を行います。再構成は、過半数の定足数に達した場合にだけ行われます。再構成後、ノードがクラスタに留まるのは、そのノードが過半数の定足数を構成する場合だけです。

3 ノード以上のクラスタでは、多重ホストディスクに対するアクセス権を共有する各ノードセットに対して、定足数デバイスを使用するように構成する必要があります。

3 ノード以上のクラスタでは、定足数デバイスの概念が少し異なります。定足数デバイスを共有しないノードで同数の票割れが発生した場合 (この状態を「票割れ (split-brain)」パーティションという) は、どのノードセットが新しいクラスタになり、どのセットが終了するかを決定する必要があります。定足数デバイスがこの状況に対処することはありません。インストール作業の一貫として定足数デバイスを設定するときに、そうしたパーティションが発生したときにどのようなことを行わせるかを決定する問い合わせがあります。票割れパーティションが発生した場合は、クラスタソフトウェアに自動的に新しいクラスタメンバーシップを選択させるようにしたか、あるいは手動介入を指定したかによって、2 つあるイベントのいずれかが発生します。

• 自動選択 - インストール中に select を選択した場合は、選択した設定 (Lowest Nodeid または Highest Nodeid) によって、終了するサブセットが自動的に選択されます。Lowest Nodeid が選択されている場合は、最小のノード ID 値を持つノードを含むサブセットが自動的に新しいクラスタになります。Highest Nodeid が選択されている場合は、最大のノード ID 値を持つノードを含むサブセットが自動的に新しいクラスタになります。別のすべてのサブセットは手動で終了させる必要があります。

• 手動介入 - 票割れパーティションが発生すると、新しいクラスタの選択が求められます。

たとえば、4 ノードのクラスタがあり (全ノードが同じ記憶装置を共有していても、共有していなくてもよい)、ネットワーク障害が発生して、ノード 0 と 1、ノード 2 と 3 がそれぞれ互いに通信していると仮定します。この状況では、定足数の自動または手動決定のどちらでも使用されます。クラスタ監視ソフトウェアは、どのノードをクラスタのメンバーとすべきで、どのノードをメンバーとすべきでないかを独力で判断しようとします。最後の手段として、定足数デバイスに頼って同じ得票数にならないようにするか、あるいはクラスタドメインの手動および自動選択に頼ります (極端な状況の場合のみ)。

定足数デバイスで障害が発生するということは、2 ノードのクラスタでノードの 1 つに障害が発生することと似ています。

定足数デバイス単独で、クラスタメンバーシップに関する決定が必要になるあらゆる状況に対応できるわけではありません。たとえば、完全に動作可能な 3 ノードのクラスタがあり、それらノードのすべてが、Sun StorEdge A5000 のような多重ホストディスクのアクセス権を共有していると仮定します。ノードの 1 つが終了するか、両方のクラスタインターコネクトを失い、残る 2 つのノードが引き続き互いに通信できる場合、残り 2 つのノードが、同じ得票数になるのを回避するために定足数デバイスを確保する必要はありません。代わりに、過半数の得票 (3 票のうちの 2 票) は、互いに通信できる 2 つのノードがクラスタを形成できるかどうかを決定します。クラスタを構成する 2 つのノードは、クラッシュまたは停止したノードがオンラインになって共有データが破壊されないようにする必要があります。このために、2 つのノードは、「障害防護」で説明する手法を使用します。