4    クラスタのメンバシップ管理

クラスタ化されたシステムでは,ディスクやファイルのような,さまざまなデータおよびシステム・リソースを共用します。リソースの一貫性の維持にはメンバの連携が必要であり,そのためにはメンバシップに関する明確な基準が必要です。この基準を満たさないシステムに対しては,クラスタへの参加を許可しないようにします。

この章では,次の項目について説明します。

4.1    接続マネージャの概要

接続マネージャは,クラスタのメンバが相互に通信できるかどうかを監視し,クラスタのメンバシップに関する規則を強制する分散型のカーネル構成要素です。接続マネージャは次のような機能を実行します。

接続マネージャのインスタンスは,クラスタの各メンバ上で動作します。これらのインスタンスは,クラスタのメンバシップ・リストのような情報を共有することによって,メンバ間の相互接続を維持します。接続マネージャは,三相コミット・プロトコルを使って,すべてのメンバから見えるクラスタのビューの一貫性を維持します。

4.2    クォーラムとボートの概要

接続マネージャは,投票メカニズムを使用することによって,通信障害の発生時でもデータの一貫性を保証します。このメカニズムでは,ボート (投票数) が過半数に達したときに限り,クラスタ内でのプロセス動作と入出力操作を許可します。このようにクラスタ内に過半数のボートが存在する状態を,クラスタがクォーラム (定足数) を維持しているといいます。

接続マネージャはクォーラムを計算し,その結果に基づいて,クラスタ・メンバとしてのシステムの追加および残留を許可します。このような投票メカニズムは,期待ボート,現在のボート,ノード・ボート,クォーラム・ディスク・ボートなど多くの要素に依存します。 ここでは,これらの要素の概念について説明します。

4.2.1    システムをクラスタのメンバにする方法

クラスタのメンバシップを管理できるのは接続マネージャだけです。コマンド clu_create または clu_add_member を使ってクラスタのメンバになるようにノードを構成しても,そのノードはすぐにはクラスタのメンバになりません。メンバになるのは,クラスタ化カーネルによってリブートされ,接続マネージャによってクラスタの形成またはクラスタへの参加を許可されてからです。クラスタのメンバと,クラスタのメンバになるように構成されたノードとの違いは,クォーラムとボートについて考えるとき常に重要です。

ノードがクラスタを形成したか,クラスタに参加した後,そのノードは接続マネージャによって無期限に (ただし clu_delete_member を使ってクラスタから削除されるまで) クラスタのメンバとみなされます。希に,クラスタ内でのハードウェアの故障または切断などによる通信の切断によって,既存クラスタが複数のクラスタに分断されることがあります。この状況をクラスタ分断といいます。クラスタ分断が発生すると,ノードは所属先のクラスタを特定できなくなる可能性があります。ただし 4.3 節で説明するように,接続マネージャは,これらのクラスタの 1 つしか稼働させません。

4.2.2    期待ボート

期待ボートは,構成済みのボートがすべて使用可能なときのボート数で,接続マネージャが使用します。つまり,期待ボートはクラスタ内で構成済みのノード・ボート (4.2.4 項) とクォーラム・ディスク・ボート (4.2.5 項) との合計ということになります (クォーラム・ディスク・ボートはクォーラム・ディスクが構成されている場合のみ加算します)。 各メンバは,それぞれ自身の情報をクラスタに通知します。すべてのメンバの期待ボートの数は,一致する必要があります。

接続マネージャは,クラスタのブート・メンバのノードの期待ボートを参照して,クラスタ全体の期待ボートを決定します。このクラスタ全体の期待ボートのことをクラスタの期待ボートといいます。接続マネージャは,クラスタの期待ボートの値を使って,クラスタがクォーラムを維持するために必要なボート数 (4.3 節を参照) を決定します。

クラスタの期待ボートの現在の値を表示するには,コマンド clu_quorum または clu_get_info -full を使用します。

新規の投票メンバまたはクォーラム・ディスクがクラスタ内で構成されると,スクリプト clu_create および clu_add_member が各メンバの期待ボートを自動的に調節します。クラスタからメンバが削除されると,clu_delete_member コマンドが期待ボートを自動的に減らします。同様に,クォーラム・ディスクの追加または削除が行われたり,メンバに対してノード・ボートの割り当てや削除が行われたりすると,clu_quorum コマンドが各メンバの期待ボートを調節します。これらのコマンドによって確実に,クラスタ内のすべてのメンバの期待ボートの値が一致し,さらにそのボートの値は,すべてのノード・ボートとクォーラム・ディスク・ボート (クォーラム・ディスクが構成されている場合) との合計に一致します。

メンバの期待ボートは,そのメンバ固有の etc/sysconfigtab ファイル内にある clubase サブシステムのカーネル属性 cluster_expected_votes によって初期化されます。メンバの期待ボートを表示するには,clu_quorum コマンドを使用します。

メンバの期待ボートを変更するには,clu_quorum -e コマンドを使用しなければなりません。これによって確実に,すべてのメンバの期待ボートが適切かつ同一になります。カーネル属性 cluster_expected_votes を直接変更することはできません。

4.2.3    現在のボート

期待ボートの数がクラスタ内で構成されたボートの数と一致する場合,現在のボートは,現在オンラインのメンバと構成済みクォーラム・ディスクが投じたボートの合計です。つまり,現在のボートはクラスタ内で実際に見えるボートの数です。

4.2.4    ノード・ボート

ノード・ボートは,クラスタの 1 つのメンバがクォーラムに投じるボートの定数です。メンバには 1 または 0 (ゼロ) ノード・ボートを割り当てることができます。1 ボートを持つメンバは,クラスタの投票メンバとみなされます。0 (ゼロ) ボートを持つメンバは非投票メンバとみなされます。

注意

シングルユーザ・モードへの移行はメンバの投票状態に影響しません。投票メンバは,シャットダウンされてシングルユーザ・モードでリブートされても,引き続き投票メンバです。つまり接続マネージャは,シャットダウンされてシングルユーザ・モードでリブートされたメンバを,引き続きクラスタのメンバとみなします。

投票メンバはクラスタを形成できます。非投票メンバは既存クラスタへの参加しかできません。

通常は,クラスタの構成中にメンバにボートを割り当てます。たとえば,clu_create による初期メンバの作成時か,clu_add_member による新規メンバの追加時に,ボートの割り当てを行います。省略時の設定により,clu_create の実行時に,最初のメンバに 1 ボートが割り当てられます。clu_add_member の実行時には,省略時の設定により,期待ボートが 1 の場合は新規メンバに 0 ボートが割り当てられ,期待ボートが 2 以上の場合は新規メンバに 1 ボートが割り当てられます (clu_create および clu_add_member は,クラスタ内で新規ボートが構成されると,期待ボートを自動的に増やします)。clu_quorum -m コマンドを使用すれば,クラスタのメンバに割り当てられたノード・ボートの数を後で調節できます。

メンバのノード・ボートは,そのメンバ固有の etc/sysconfigtab ファイル内にある clubase サブシステムのカーネル属性 cluster_node_votes によって初期化されます。メンバのノード・ボートを表示するには,コマンド clu_quorum または clu_get_info -full を使用します。詳細については,4.6 節を参照してください。

メンバのノード・ボートを変更するには,clu_quorum コマンドを使用しなければなりません。カーネル属性 cluster_node_votes を直接変更することはできません。

4.2.5    クォーラム・ディスク・ボート

クラスタ構成では,4.5 節の説明に従ってクォーラム・ディスクを構成することにより,クラスタの可用性を高めることができます。クォーラム・ディスク・ボートは,クォーラム・ディスクがクォーラムに投じるボートの定数です。クォーラム・ディスクには 1 または 0 ボートを割り当てることができます。

通常,clu_create によるクラスタの作成時に,クォーラム・ディスクを構成して,ボートを割り当てます。クラスタの作成時にクォーラム・ディスクを定義する場合,省略時の設定により,クォーラム・ディスクには 1 ボートが割り当てられます。

クォーラム・ディスク・ボートは,各メンバの etc/sysconfigtab ファイル内にある clubase サブシステムのカーネル属性 cluster_qdisk_votes によって初期化されます。クォーラム・ディスク・ボートを表示するには,clu_quorum コマンドまたは clu_get_info コマンドを使用します。

クォーラム・ディスク・ボートを変更するには,clu_quorum コマンドを使用しなければなりません。カーネル属性 cluster_qdisk_votes を直接変更することはできません。

クォーラム・ディスクを構成すると,そのボートはクラスタの形成で特殊な役割を果たします。これは,接続マネージャが強制する次のような規則があるためです。

つまり,ブート・ノードがクォーラムを満たそうとしてクォーラム・ディスク・ボートを要求すると,これらの規則によってジレンマに陥ります。ブート・ノードはクラスタを形成できません。

このジレンマから抜け出すために,接続マネージャは,ブート・ノードがクォーラムにクォーラム・ディスク・ボートを一時的に投じることができるようにします。これによって,ブート・ノードはクォーラムを満たして,クラスタを形成できます。ブート・ノードは,クラスタが形成されると,クォーラム・ディスクの所有権を要求します。この時点で,そのクォーラム・ディスクのボートは仮のボートから正式なボートになります。

4.3    クラスタのクォーラム・ボートの計算の概要

接続マネージャは,クォーラム・アルゴリズムを使って,あるノードがクラスタに参加し,クラスタ全体のリソースに安全にアクセスして,有用な作業を実行できるかどうかを調べます。このアルゴリズムは動的です。つまり,クラスタのクォーラム・ボートの計算はクラスタのイベントによって開始され,その計算結果はクラスタの存在期間に渡って変化します。

クォーラム・アルゴリズムは次のような仕組みになっています。

  1. 接続マネージャは,クラスタのクォーラム・ボートの計算に使用するクラスタ・メンバの集合を選択します。この集合には相互通信可能なメンバのみが含まれます。構成されているがブートされていないノード,ダウンしているメンバ,ハードウェアの障害 (クラスタのインターコネクト・ケーブルの切断や Memory Channel アダプタの故障) によって到達不能になったメンバなどは含まれません。

  2. クラスタの形成時,ノードがブートしてクラスタに参加するたびに,接続マネージャは次の値から最大値を選択し,その値を使ってクラスタの期待ボートを計算します。

    たとえば,クォーラム・ディスクがない 3 メンバ構成のクラスタがあるとします。すべてのメンバは稼働中であり,相互に接続されています。各メンバのノード・ボートは 1 に設定され,期待ボートは 3 に設定されています。クラスタの期待ボートは現在 3 です。

    その後,4 番目の投票メンバがクラスタに参加するとします。この新しいメンバがブートしてクラスタに参加した場合,接続マネージャはクラスタの期待ボートを計算して,4 に設定します。この値はクラスタ内のノード・ボートの合計です。

    クラスタの期待ボートの現在の値を表示するには,コマンド clu_quorum または clu_get_info -full を使用します。

  3. 接続マネージャは,クラスタの期待ボートを再計算するたびに (または clu_quorum -e コマンドでクラスタの期待ボートをリセットするたびに),クォーラム・ボートを計算します。

    クォーラム・ボートは,クラスタの期待ボートの値に基づいて動的に計算されるクラスタ単位の値です。この値によって,ノードに対し,クラスタの形成,クラスタへの参加,またはクラスタへの残留を許可するかどうかが決まります。接続マネージャは,次の数式を使ってクラスタのクォーラム・ボートを計算します。

    クォーラム・ボート = (クラスタの期待ボート + 2) / 2 (小数点以下切り捨て)
     
    

    たとえば,前述した手順の 3 メンバ構成のクラスタの場合,クラスタの期待ボートが 3 なので,クォーラム・ボートは,((3+2) / 2) で計算して小数点以下を切り捨てた結果,2 になります。4 番目のメンバが正常に追加された場合,クォーラム・ボートは,((4+2) / 2) で計算して小数点以下を切り捨てた結果,3 になります。

    注意

    期待ボートは (結果的にクォーラム・ボートも) クラスタ構成に基づきます。どのノードが稼働しているかダウンしているかには関係ありません。メンバがシャットダウンされたか,他の何らかの理由でダウンしたとき,接続マネージャはクォーラム・ボートの値を減らしません。メンバが削除されたか,clu_quorum -e コマンドが実行されたときだけ,接続マネージャは稼働中のクラスタのクォーラム・ボート値を減らします。

  4. クラスタのメンバが参照可能なボート数の変化を検出すると (ノードがクラスタに参加したか,既存メンバがクラスタから削除されたか,通信エラーが報告されたことが原因),そのメンバは常に現在のボートとクォーラム・ボートとを比較します。

    この後,メンバは次の条件に基づいたアクションをとります。

イベント・メッセージにはクォーラムが失われたことがクラスタ単位のイベントとして書き込まれることがありますが,現在のボートとクォーラム・ボートとの比較はメンバ単位で行われます。クラスタのいずれかのメンバがクォーラムを失うと,そのメンバの入出力操作はすべて中断され,クラスタ・インターコネクト以外のすべてのネットワーク・インタフェースが停止状態になります。クラスタ全体のリソースへのアクセスを必要とするコマンドはすべて,そのメンバ上では機能しなくなります。その結果,そのメンバはハングアップしているように見えることがあります。

そのメンバがどのようにクォーラムを失ったかにもよりますが,クォーラムを失ったメンバがクォーラムを満たせるだけのボートを別のメンバに割り当て,そのメンバをブートし,クォーラムを回復させることによって,この状況を解決できる場合があります。ただし,クラスタのすべてのメンバがクォーラムを失った場合は,それらのメンバがクォーラムを満たせるだけのボートを新規メンバに割り当て,その新規メンバをブートするか,クラスタ全体をリブートするか,あるいは 4.10 節の手順を実行するしかありません。

4.4    接続マネージャの動作例

接続マネージャがクラスタの形成を許可するのは,ブートされたノードによってボートが投じられ (クォーラム・ディスクが構成されている場合はクォーラム・ディスク・ボートも投じられ),それらのボートの合計がクラスタのクォーラムに達したときです。

図 4-1 に示すような 3 メンバ構成のクラスタ deli があるとします。すべてのメンバが稼働中であり使用可能なとき,各メンバは 1 ノード・ボートを投じます。その結果,クラスタの期待ボートは 3 になり,クォーラム・ボートの計算結果は 2 になります。つまり,クラスタ deli は,1 つのメンバに障害が発生しても稼働し続けることができます。

図 4-1:  3 メンバ構成のクラスタ deli

ノード salami が最初にブートされると,コンソールには次のメッセージが表示されます。

CNX MGR: Node salami id 3 incarn 0xbde0f attempting to form or join cluster
deli
CNX MGR: insufficient votes to form cluster: have 1 need 2
CNX MGR: insufficient votes to form cluster: have  1 need 2
.
.
.
 

ノード polishham がブートされると,このノードのボートと salami のボートとの合計がクォーラム (2) に達し,クラスタの形成が許可されます。その結果,次の CNX MGR メッセージが表示されます。

.
.
.
CNX MGR: Cluster deli incarnation 0x1921b has been formed
Founding node id is 2 csid is 0x10001
CNX MGR: membership configuration index: 1 (1 additions, 0 removals)
CNX MGR: quorum (re)gained, (re)starting cluster operations.
CNX MGR: Node salami 3 incarn 0xbde0f csid 0x10002 has been added to the
cluster
CNX MGR: Node polishham 2 incarn 0x15141 csid 0x10001 has been added to the
cluster
 

形成されたクラスタにノード pepicelli が参加すると,ノード pepicelli のブート・ログには,前記のメッセージと似たメッセージが表示されますが,クラスタ形成のメッセージの代わりに,次のメッセージが表示されます。

CNX MGR: Join operation complete
CNX MGR: membership configuration index: 2 (2 additions, 0 removals)
CNX MGR: Node pepicelli 1 incarn 0x26510f csid 0x10003 has been added to the
cluster
 

もちろん,ノード pepicelli は,他の 2 つのノードと同時にブートされるときは,それら 2 つのノードと同様,クラスタの形成に参加し,その場合は,クラスタ形成のメッセージが表示されます。

その後,pepicelli がシャットダウンされた場合は,図 4-2 に示すように,メンバ salami および polishham はそれぞれ自身の現在の期待ボート (2) と,クォーラム・ボート (2) とを比較します。その結果,現在のボートがクォーラム・ボートと等しいので,これら 2 つのメンバはクラスタに残留することができ,ノード pepicelli のシャットダウン後も稼働し続けることができます。次に,1 つのメンバを失った場合の一連の動作を記録したログ・メッセージを示します。

memory channel - removing node 2
rm_remove_node: removal took 0x0 ticks
ccomsub: Successfully reconfigured for member 2 down
ics_RM_membership_change: Node 3 in RM slot 2 has  gone down
CNX MGR: communication error detected for node 3
CNX MGR: delay 1 secs 0 usecs
        .
        .
        .
CNX MGR: Reconfig operation complete
CNX MGR: membership configuration index: 13 (2 additions, 1 removals)
CNX MGR: Node pepicelli 3 incarn 0x21d60 csid 0x10001 has been removed
         from the cluster
 

図 4-2:  3 メンバ構成のクラスタ deli が 1 つのメンバを失った場合

ただし,このクラスタは,さらに別のメンバが失われると稼働できなくなります。メンバ polishham がシャットダウンされると,図 4-3 の図と 4.5 節 の説明のような状況になります。クラスタ deli はクォーラムを失い,動作を中断し,次のメッセージが表示されます。

memory channel - removing node 4
rm_remove_node: removal took 0x0 ticks
ccomsub: Successfully reconfigured for member 4 down
ics_RM_membership_change: Node 2 in RM slot 4 has gone down
CNX MGR: communication error detected for node 2
CNX MGR: delay 1 secs 0 usecs
CNX MGR: quorum lost, suspending cluster operations.
        .
        .
 

4.5    クォーラム・ディスクの使用

2 メンバ構成のクラスタで,各メンバのノード・ボートが 1 であり,期待ボートが 2 である場合,1 つのメンバが失われると,クラスタはクォーラムを失い,すべてのアプリケーションが中断されます。この種のクラスタ構成の可用性は高くありません。

2 メンバ構成のクラスタで,1 番目のメンバのノード・ボートが 1 であり,2 番目のメンバのノード・ボートが 0 であり,期待ボートが 1 の場合,前の構成よりも可用性は高まりますが,あまり良い構成とは言えません。このクラスタは,2 番目のメンバ (非投票メンバ) を失っても稼働し続けますが,1 番目のメンバ (投票メンバ) を失うと稼働できなくなります。

このようなクラスタ構成の可用性を高めるには,共用バス上のディスクをクォーラム・ディスクとして指定します。クォーラム・ディスクは,仮想クラスタ・メンバとして動作し,その目的は期待ボートに 1 ボートを加算することです。2 メンバ構成のクラスタでクォーラム・ディスクを構成すると,クォーラム・ディスクまたは 1 つのメンバに障害が発生しても,クラスタは稼働し続けることができます。

たとえば,図 4-3 に示すように,クォーラム・ディスクがない 2 メンバ構成のクラスタ deli があるとします。

図 4-3:  2 メンバ構成のクラスタ deli にクォーラム・ディスクがない場合

メンバ salamiは 1 ノード・ボートを投じ,メンバ polishham は 0 ボートを投じます。したがって,クラスタの期待ボートは 1 です。接続マネージャは次のようにクォーラム・ボートを計算します。

クォーラム・ボート = (クラスタの期待ボート + 2) / 2       (小数点以下切り捨て)
                 = (1 + 2) /2 
                 = 1
 

メンバ salami の障害またはシャットダウンにより,メンバ polishham はクォーラムを失い,クラスタの動作は中断されます。

しかし,クラスタ内にクォーラム・ディスク (クラスタの期待ボートに 1 ボートを加算) を構成し,メンバ polishham にも 1 ボートを割り当てた場合,期待ボートは 3 になり,クォーラム・ボートは 2 になります。この場合のクォーラム・ボートの計算は次のようになります。

クォーラム・ボート = (クラスタの期待ボート + 2) / 2       (小数点以下切り捨て)
                 = (3 + 2) /2  
                 = 2
 

このクラスタ構成では,いずれか一方のメンバまたはクォーラム・ディスクをクラスタから削除する場合でも,クラスタがクォーラムを失わないだけの数の現在のボートが残ります。このように,図 4-4 に示すクラスタは稼働し続けることができます。

図 4-4:  2 メンバ 構成のクラスタ deli が 1 つのメンバを失ってもクォーラム・ディスクがあるために稼働し続ける場合

clu_create ユーティリティを使用すれば,クラスタの作成時に,クォーラム・ディスクを指定し,そのディスクにボートを割り当てることができます。また,clu_quorum ユーティリティを使用すれば,クラスタの存在期間内のその他の任意のタイミングでも,クォーラム・ディスクを追加できます。たとえば,2 メンバ構成のクラスタで clu_delete_member を実行した結果,クラスタの可用性が下がったときなどが挙げられます。

クォーラム・ディスクを構成するには,clu_quorum -d add コマンドを使用します。たとえば次のコマンドは,/dev/disk/dsk11 をクォーラム・ディスクとして定義し,そのディスクに 1 ボートを割り当てます。

# clu_quorum -d add dsk11 1
Collecting quorum data for Member(s): 1 2
 
Info: Disk available but has no label: dsk11
  Initializing cnx partition on quorum disk : dsk11h
 
Successful quorum disk creation.
# clu_quorum
 
Cluster Common Quorum Data
Quorum disk:   dsk11h
        .
        .
        .
 

次に,クォーラム・ディスクの使用上の制限を示します。

概念としては,クラスタの障害のあるメンバ (ボート) とないメンバが同数である場合,クォーラム・ディスクで提供されるボートはタイブレーカとして働きます。タイブレーカのボートによって,クォーラムを維持してクラスタ操作が継続されます。この点についてクォーラム・ディスクのボートは,ボートと違いはありません。たとえば,2 メンバ・クラスタの 3 番目のボート・メンバとするか,4 メンバ・クラスタの 5 番目のボート・メンバとすることができます。これは,全共用ストレージへ直接接続されていない非ボート・メンバが数多くある,大規模なクラスタを計画するときに重要な考えです。

ファイル・サーバとして動作する 2 つの大規模なメンバを持つクラスタを考えてみてください。これらのメンバは,重要なクラスタのファイル・システムとアプリケーション・データベースへ直接接続されるため,クラスタの操作に対して重要であり,それぞれ 1 ボートが割り当てられます。このクラスタのその他のメンバはクライアント要求を処理し,サーバへ送信します。これらのメンバは,共用ストレージへ直接接続されていないため,クラスタ操作への重要性は低く,ボートは割り当てられません。ただし,このクラスタには 2 つしかボートがないため,タイブレーカのボートを設定するまでどちらのファイル・サーバ (メンバ) も動作を停止することができません。

この場合,タイブレーカのボートをどのように構成しようとするでしょうか。ボートを持つクォーラム・ディスクを設定するのは,あまりよい選択ではありません。この設定でのクォーラム・ディスクは 2 つのファイル・サーバのメンバのみに直接接続されています。クライアントの処理メンバは,結果的にクォーラム用のボートに数えることができません。クォーラム・ディスクまたは 1 つのファイル・サーバのメンバに障害が発生すると,クライアントの処理メンバはクォーラムを失い,サーバへのクライアント要求の送信を停止します。これは,たとえクォーラムを維持し続けても,サーバ・メンバの操作に影響を与えます。タイブレーカのボートをこの種の設定に使用するための最良の解決策は,クライアントの処理メンバの 1 つにボートを割り当てることです。クラスタ全体では,1 つのボートが失われても,操作を継続できます。

クォーラム・ディスクを追加し,クォーラムを維持するためにそのボートが必要になると,clu_quorum から次のようなメッセージが表示されます。

Adding the quorum disk could cause a temporary loss
of quorum until the disk becomes trusted.
Do you want to continue with this operation? [yes]:
 

通常は,この質問に "yes" で答えます。clu_quorum コマンドは 20 秒ほどでクォーラム・ディスクの信頼性を判断します。クォーラム・ディスクを信頼できるものにするためには,メンバがそのディスクに直接接続していること,メンバがディスクとの間で読み書きできること,そして,メンバが所有権を要求しているかまたは所有権を要求しているメンバと同じクラスタのメンバになっていることが必要です。

既存のクォーラム・ディスクのボートを調整しようとしたときにメンバがディスクを信頼できると判断していなければ (cnx サブシステムの qdisk_trusted 属性の値がゼロになっている),clu_quorum コマンドから次のメッセージが表示されます。

The quorum disk does not currently appear to be trusted.
Adjusting the votes on the quorum disk could cause quorum loss.
Do you want to continue with this operation? [no]:
 

クォーラム・ディスクが現在信頼されていない場合,前述の条件を満たすために何らかの処置を施さない限り,信頼性は得られません。この場合は,質問に "no" で応答し,別の方法でクラスタへボートを追加してください。

4.5.1    障害が発生したクォーラム・ディスクの交換

クラスタの稼働中にクォーラム・ディスクに障害が発生したが,クラスタがクォーラムを失わない場合は,次の手順でディスクを交換できます。

  1. ディスクがクラスタから切断されていることを確認します。

  2. clu_quorum コマンドを実行し,クォーラム・ディスク・ボートの実行時の値をメモしておきます。

  3. clu_quorum -f -d remove コマンドを使って,クラスタからクォーラム・ディスクを削除します。

  4. ディスクを交換します。各クラスタ・メンバ上で hwmgr -scan scsi コマンドを入力します。

    注意

    hwmgr -scan scsi コマンドは,すべてのクラスタ・メンバ上で実行する必要があります。

    新規ディスクがすべてのメンバによって認識されるまで,しばらく待ちます。

  5. hwmgr -view devices -cluster コマンドを使って,新規ディスクのデバイス・スペシャル・ファイルの名前 (dsk 名) を調べます。この名前は,障害が発生したクォーラム・ディスクの名前とは異なります。任意に,dsfmgr -n コマンドを使って,新規ディスクのデバイス・スペシャル・ファイルの名前を障害が発生したディスクの名前に変更することもできます。

  6. clu_quorum -f -d add コマンドを使って,新規ディスクをクォーラム・ディスクとして構成します。新規ディスクには,手順 2 でメモしておいたボートと同数のボートが割り当てられていることを確認します。

クラスタの稼働中にクォーラム・ディスクに障害が発生して,クラスタがクォーラムを失い,クラスタの動作が中断された場合は,4.10.1 項の手順に従って,1 つのクラスタ・メンバを停止し,対話形式でリブートして,クラスタのクォーラムを回復しなければなりません。その後,前述の手順を実行できます。

4.6    clu_quorum コマンドによるクラスタのクォーラム情報の表示

clu_quorum コマンドをオプションなしで実行するか,-f または -v (あるいはその両方) を付けて実行すると,クラスタの現在のクォーラム・ディスク,メンバのノード・ボート,およびクラスタの期待ボートに関する情報が表示されます。この情報は次の項目から構成されます。

clu_quorum による表示項目については, clu_quorum(8) を参照してください。

4.7    クラスタ・ボートの割り当て例

表 4-1 に,クラスタ・メンバ上の属性 cluster_expected_votes および cluster_node_votes のさまざまな設定によって,クラスタの形成にどのような影響が出るかを示します。さらに,これらの属性のどの設定の組み合わせによって,クラスタ全体が稼働不能になるか,またはクラスタの可用性が最大限に高まるかも示します。この表では,2 メンバ,3 メンバ,および 4 メンバ構成のクラスタを対象にします。

次に,この表内の見出し下の列の内容と表記について説明します。

表 4-1:  2〜4 メンバ構成のクラスタ内でのメンバの cluster_expected_votes 設定とボートの割り当てによる影響

メンバの期待ボート M1 M2 M3 M4 クォーラム・ディスク 影響
1 1 0 --- --- 0 クラスタを形成できるのは M1 が存在するときだけである。クラスタは M2 の障害発生時は稼働し続けるが,M1 の障害発生時には動作が中断される。クォーラム・ディスクを使用しないとき,この構成は 2 メンバ構成のクラスタには一般的である。M2 にボートを追加し,この構成にクォーラム・ディスクを追加してみるとよい。
2 1 1 --- --- 0 クラスタを形成できるのは,両方のメンバが存在するときだけである。クラスタは一方のメンバの障害発生時に動作が中断される (4.4 節で説明したように,この構成は上記の構成よりも可用性が低い)。この構成にクォーラム・ディスクを追加してみるとよい。4.5 節を参照。
3 1 1 --- --- 1 クォーラム・ディスクが構成され,このディスクに 1 ボートが割り当てられたので,クラスタはいずれか一方のメンバまたはクォーラム・ディスクの障害発生時でも稼働し続けることができる。2 メンバ構成のクラスタとしてはこの構成を推奨。
1 1 0 0 --- 0 クラスタはメンバ M2 および M3 の障害発生時でも稼働し続けるが,M1 の障害発生時は動作が中断される。
2 1 1 0 --- 0 クラスタが稼働し続けるには M1 および M2 の両方が稼働中であることが必要である。 M3 の障害発生時には,クラスタの動作は中断される。
3 1 1 1 --- 0 クラスタはいずれか 1 つのメンバの障害発生時でも稼働し続けることができる。3 メンバ構成のクラスタとしてはこの構成を推奨。
4 1 1 1 --- 1 クォーラム・ボートは 3 になるので,1 ボートを持つクォーラム・ディスクがあっても,この構成は上記の構成よりも可用性は低くなる。実際,クォーラム・ディスクに障害が発生した場合 (発生率は 0 に近いが),いずれか 1 つのメンバの障害発生時には,クラスタの動作は中断される。 [脚注 2]
4 1 1 1 1 0 クラスタは,いずれか 1 つのメンバの障害発生時でも稼働し続けることができる。この構成にクォーラム・ディスクを追加してみるとよい。4.5 節を参照。
5 1 1 1 1 1 クラスタは,いずれか 1 つまたは 2 つのメンバの障害発生時,またはクォーラム・ディスクの障害発生時でも稼働し続けることができる。4 メンバ構成のクラスタとしてはこの構成を推奨。

4.8    接続マネージャのモニタ

接続マネージャは,次の 4 種類のイベントを EVM (イベント・マネージャ) のイベント・メッセージによって管理者に通知します。

これらの各イベントは,コンソール・メッセージによっても通知されます。

接続マネージャは,メンバのブート中やクラスタ・トランザクションの実行中に,さまざまな通知メッセージをコンソールに表示します。

クラスタ・トランザクションは,クラスタのすべてのメンバ上でクラスタ全体の状態をアトミックに変更するためのメカニズムです。つまり,すべてのメンバが新規の値を採用するか,どのメンバも新規の値を採用しないかのいずれかの状態になります。最も多く発生するクラスタ・トランザクションは,メンバシップ関連のトランザクションです。たとえば,クラスタの形成時やクラスタに対するメンバの追加または削除時に発生します。ある種の保守作業,たとえばクォーラム・ディスクの追加または削除,クラスタの期待ボートの変更,メンバのノード・ボートの変更を行うときにも,クラスタ・トランザクションは発生します。

クラスタ・トランザクションはグローバルに (クラスタ単位で) 発生するイベントですが,接続マネージャは,ローカルで発生したイベントに対応するメッセージもメンバのコンソールに表示します。たとえば,そのノードと別のノード (またはクォーラム・ディスク) との間の接続性の変化,クォーラムの獲得,クォーラムの喪失などを通知します。

4.9    接続マネージャのパニック

接続マネージャはクラスタのメンバを連続的に監視しています。クラスタの分断によって既存のクラスタが 2 つ以上のクラスタに分割されている場合は,ノードが自分たちをいずれかのクラスタのメンバであると認識することがまれにあります。4.3 節で説明したように,接続マネージャが動作を許可するクラスタは,多くても 1 つです。

クラスタ分断の発生時にデータの一貫性を維持するために,接続マネージャは 1 つのメンバをパニック状態にします。パニック文字列はクラスタ分断の検出時の状況を示します。このようなパニックは,接続マネージャの問題が原因で発生するのではなく,悪状況に対応して発生します。たとえば,徹底した対処策をとらないとデータの一貫性を維持できないような状況です。クラスタ分断を解消するには,1 つ (または複数) のメンバをリブートして,クラスタに再参加させるしか対処策はありません。

接続マネージャがクラスタの 1 つのメンバをパニック状態にするのは,次のような状況が発生したときです。

4.10    不適切な期待ボートおよびノード・ボート設定に関するトラブルシューティング

クラスタがクォーラムを維持している限り,clu_quorum コマンドを使って,クラスタ内のノード・ボート,期待ボート,およびクォーラム・ディスク・ボートを調節できます。このコマンドに -f オプションを使用すれば,現在ダウンしているメンバにも変更を反映できます。

ただし,クラスタのいずれかのメンバがクォーラムを失った場合は,そのメンバの入出力操作はすべて中断され,クラスタ・インターコネクト以外のすべてのネットワーク・インタフェースが停止状態になります。クラスタ全体のリソースへのアクセスが必要なコマンド (clu_quorum など) もすべて,そのメンバ上では機能しなくなります。この場合は,クォーラムを失ったメンバがクォーラムを満たせるだけのボートを別のメンバに割り当て,そのメンバをクラスタに再参加させて,クォーラムを回復させるか,あるいはクラスタ・メンバを停止して,リブートしなければなりません。

クォーラムの喪失でハングアップしているクラスタや,ボート不足のために形成不能のクラスタでは,ボート構成の調節が必要な場合があります。以降の各項では,クラスタに関するいくつかの問題とそれらの解決に使用できるメカニズムについて説明します。

4.10.1    クラスタのメンバまたはクォーラム・ディスクに障害が発生しクラスタがクォーラムを失った後にクラスタに参加させる

1 つまたは複数のメンバ (またはクォーラム・ディスク) にハードウェアの問題が発生し,クラスタはそれらのメンバを失いました。問題が発生したメンバはリブート不能です。それらのメンバを失ったことで,クラスタはクォーラムを失いました。残りの稼働中のメンバの期待ボートまたはノード・ボートの設定では,メンバが減った現在のクラスタの可用性を維持できません。クラスタはクォーラムを失い,ハングアップしています。

この種のクォーラム喪失状況は,クラスタ全体をシャットダウンしなくても解決できます。手順としては,1 つのクラスタ・メンバを停止し,クラスタに参加できるようにそのメンバをリブートして,クォーラムを回復します。このメンバをブートした後に,clu_quorum コマンドを使用して,本来の問題を修正する必要があります。

注意

1 つのクラスタ・メンバだけが稼働中であるか,またはクォーラム・ディスクに障害が発生した場合は,4.10.2 項で説明する手順を使用し,十分なボートを持つクラスタ・メンバをブートして,クラスタを形成します。

1 つまたは複数のメンバあるいはクォーラム・ディスクに障害が発生したためにクォーラムを失ったクラスタのクォーラムを回復するには,次の手順に従います。

  1. Halt ボタンを使用して,クラスタの 1 つのメンバを停止します。

  2. 停止したメンバを対話形式でリブートします。リブート中,ブート元のカーネルの名前を要求されたら,カーネル名と clubasecluster_adjust_expected_votes 属性値 0 (ゼロ) の両方を指定します。この属性に 0 を設定すると,接続マネージャは,クラスタ内で現在使用可能なメンバとクォーラム・ディスクの総数と同数の期待ボートを設定します。

    注意

    cluster_adjust_expected_votes トランザクションは,ブートするノードがクラスタに参加した後でのみ実行されます。したがって,この方法は既存のクラスタがクォーラムの喪失でハングした場合にのみ有効です。期待ボートが高すぎてクラスタを形成できなければ,cluster_adjust_expected_votes が実行できず,ブートしたメンバがハングします。この場合,4.10.2 項で説明しているいずれかの方法を使用して,クラスタからメンバをブートしなければなりません。

    次に,対話形式のリブートの例を示します。

    >>> boot -fl "ia"
     (boot dkb200.2.0.7.0 -flags ia)
     block 0 of dkb200.2.0.7.0 is a valid boot block
     reading 18 blocks from dkb200.2.0.7.0
     bootstrap code read in
     base = 200000, image_start = 0, image_bytes = 2400
     initializing HWRPB at 2000
     initializing page table at fff0000
     initializing machine state
     setting affinity to the primary CPU
     jumping to bootstrap code
     
       
    .
    .
    .
    Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix clubase:cluster_adjust_expected_votes=0[Return]

    ブートを再開すると,そのメンバはクラスタに参加でき,新規の期待ボート値が接続マネージャによってその他のメンバに通知されます。その結果,クォーラムが回復されます。

    警告

    cluster_adjust_expected_votes の設定は,現在稼働中のクラスタの期待ボート設定のみを変更し,クラスタ全体が稼働している場合にかぎり使用されます。/etc/sysconfigtab ファイル内に格納されている値は変更されません。この時点で,クラスタ内のノード・ボート,期待ボート,およびクォーラム・ディスクを明示的に再構成しない場合,クラスタの次回リブート時には,ブート・メンバはクォーラムを満たさず,クラスタを形成できません。この理由から,必要に応じ,次の手順に従って,クラスタ内のこのメンバとその他のメンバのノード・ボートと期待ボートの値を修正してください。

  3. 故障しているハードウェアが修理されるかまたは取り換えられるまで,表 4-2 を参照し,適切な clu_quorum コマンドを使用して,クラスタのボート構成を一時的に修正します。通常は,クラスタが起動して安定すると,clu_quorum コマンドを使用して,本来の問題を修正します。たとえば,次のようにします。

    clu_quorum -f コマンドがダウンしているメンバの /etc/sysconfigtab ファイルにアクセスできない場合は,適切なメッセージが表示されて失敗します。これは,通常,ダウンしているメンバのブート・ディスクが,そのメンバのプライベート・バス上にある場合に起こります。そのようなメンバが原因となっているクォーラムの問題を解決するには,そのメンバを対話形式でブートして,cluster_expected_votes をそのメンバがクラスタに参加できる値に設定します。そのメンバがクラスタに参加すると,clu_quorum コマンドを使用して,この項で説明したように,ボートの設定を修正します。

    表 4-2 に,クォーラム・ディスクのある 4 メンバ構成のクラスタと,クォーラム・ディスクのない 5 メンバ構成のクラスタで,クォーラムを回復する例を示します。この表で,NC は,クラスタでメンバまたはクォーラム・ディスクが構成されていないことを示します。

    表 4-2:  メンバやクォーラム・ディスクに障害が発生したクラスタのクォーラム喪失の解決例

    M1 M2 M3 M4 M5 クォーラム・ディスク 手順
    稼働,1 ボート 稼働,1 ボート 障害,1 ボート 障害,1 ボート NC 障害

    1. clubase:adjust_expected_votes=0 で M1 または M2 を対話型でブートする。

    2. clu_quorum -f -m コマンドを使用して,M3 と M4 からノード・ボートを削除する。

    3. clu_quorum -f -d remove コマンドを使用して,クォーラム・ディスクを削除する。

    4. 故障したハードウェアを修理または交換する。2 メンバ・クラスタで,障害に耐えなければならない場合に最も緊急に必要となるのは,投票クォーラム・ディスクである。clu_quorum -f -d add コマンドを使用して,新しいクォーラム・ディスクを追加する。クォーラム・ディスクがクラスタ全体で認識されるようにするには,すべてのクラスタ・メンバ上で hwmgr -scan scsi コマンドを実行する必要がある。

    クォーラム・ディスクを追加できない場合は,clu_quorum -f -m コマンドを使用して M1 または M2 からボートを削除する。障害の発生したメンバが長時間利用できない場合は,clu_delete_member コマンドを使用してそのメンバをクラスタから削除する。

                 
    稼働,1 ボート 稼働,1 ボート 障害,1 ボート 障害,1 ボート 障害,1 ボート NC

    1. clubase:adjust_expected_votes=0 で M1 または M2 を対話型でブートする。

    2. clu_quorum -f -m コマンドを使用して,M3,M4,および M5 からノード・ボートを削除する。

    3. 故障したハードウェアを修理または交換する。2 メンバ・クラスタで障害に耐えなければならない場合に最も緊急に必要となるのは,投票クォーラム・ディスクである。clu_quorum -f -d add コマンドを使用して,新しいクォーラム・ディスクを追加する。クォーラム・ディスクがクラスタ全体で認識されるようにするには,すべてのクラスタ・メンバ上で hwmgr -scan scsi コマンドを実行する必要がある。

    障害の発生したメンバが長時間利用できない場合は,clu_delete_member コマンドを使用してそのメンバをクラスタから削除する。

4.10.2    メンバがブートとクラスタ形成に必要な数のボートを持っていない場合のクラスタ形成

クラスタを形成できません。すべてのメンバをブートしようとすると,クラスタを形成できず,各メンバはハングアップします。これらのメンバには,クォーラムに達するのに必要なボートが不足しています。ハードウェアの故障がよく起こる小規模のクラスタも,最後に稼働していた投票メンバがクォーラムを失うような構成になる場合があります。

次の手順を実行すると,クラスタを形成するのに十分なボートを持つ 1 つのクラスタ・メンバをブートすることができます。その後,ノード・ボートを調節して,残りのメンバをクラスタにブートします。

  1. 各クラスタ・メンバを停止します。

  2. 表 4-3 を参照して,そのクラスタに特有なクォーラムを失った状況を解決するため,ブート時に調整する必要のあるカーネル属性を決定します。

  3. クラスタの 1 つの投票メンバを対話形式でブートします。ブート中,ブート元のカーネルの名前を要求されたら,カーネル名と推奨するカーネル属性設定の両方を指定します。たとえば,メンバとクォーラム・ディスクの両方に障害が発生した 2 メンバ構成のクラスタ (2 つのノード・ボートと 1 つのクォーラム・ディスク) では,clubase:cluster_expected_votes=1 clubase:cluster_qdisk_votes=0 を入力します。

    次に,対話形式のリブートの例を示します。

    >>> boot -fl "ia"
     (boot dkb200.2.0.7.0 -flags ia)
     block 0 of dkb200.2.0.7.0 is a valid boot block
     reading 18 blocks from dkb200.2.0.7.0
     bootstrap code read in
     base = 200000, image_start = 0, image_bytes = 2400
     initializing HWRPB at 2000
     initializing page table at fff0000
     initializing machine state
     setting affinity to the primary CPU
     jumping to bootstrap code
     
     
    .
    .
    .
    Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix clubase:cluster_expected_votes=1 clubase:cluster_qdisk_votes=0[Return]

    ブートを再開すると,このメンバはクラスタを形成できます。

  4. 故障したハードウェアを修理するか交換するまで,表 4-3 を参照し,適切な clu_quorum コマンドを使用して,クラスタのボートの構成を一時的に修正します。利用できないクォーラム・ディスクが問題の原因となっている場合は,そのディスクが利用可能かどうかと,ボートを持っているかどうかを確認します。必要であれば,クォーラム・ディスクを交換します (4.5.1 項を参照)。そうでない場合,他のメンバをブートできないことがあります。

  5. 残りのメンバをリブートします。

表 4-3 に,クラスタを形成するのに十分なボートを持つクラスタ・メンバをブートして,クォーラム不足を解決する方法の例を示します。この表で,NC は,メンバまたはクォーラム・ディスクがクラスタで構成されていないことを示します。

表 4-3:  クラスタを形成するのに十分なボートを持つメンバのブートによるクォーラム不足の解決例

M1 M2 M3 クォーラム・ディスク 手順
稼働,1 ボート 稼働,0 ボート NC 障害,1 ボート

1. clubase:cluster_node_votes=1 で M2 を対話型でブートする。

2. clu_quorum -f -d remove コマンドを使用して,クォーラム・ディスクを削除する。

3. clu_quorum -f -d add コマンドを使用して,故障したクォーラム・ディスクを交換する。この結果,2 つのノード・ボートと 1 つのクォーラム・ディスク・ボートを持つ 2 メンバ構成のクラスタとなる (ディスクまたは 1 メンバの障害に耐える構成)。クォーラム・ディスクを交換できない場合は,clu_quorum -f -m コマンドを使用して,1 つのメンバのボートを削除する。 この結果,非投票メンバの障害に耐える構成になる。

稼働,1 ボート 障害,1 ボート NC 障害,1 ボート

1. clubase:cluster_expected_votes=1 および clubase:cluster_qdisk_votes=0 で M1 を対話型でブートする。

2. clu_quorum -f -d remove コマンドを使用して,クォーラム・ディスクを削除する。

3. clu_quorum -f -m 2 0 コマンドを使用して,M2 のボートを削除する。

4. 故障したハードウェアを修理または交換する。投票クォーラム・ディスクのある 2 番目の投票メンバを直ちに入手できない場合は,暫定的な解決方法として,ボートのない 2 番目のメンバを追加する。この結果,非投票メンバの障害に耐える構成となる。

稼働,1 ボート 障害,1 ボート 障害,1 ボート NC

1. clubase:cluster_expected_votes=1 で M1 を対話型でブートする。

2. 適切な clu_quorum -f -m コマンドを使用して,M2 および M3 からノードを削除する。

3. 故障したハードウェアを修理または交換する。投票クォーラム・ディスクのある 2 番目の投票メンバを直ちに入手できない場合は,暫定的な解決方法として,ボートのない 2 番目のメンバを追加する。この結果,非投票メンバの障害に耐える構成となる。