クラスタ化されたシステムでは,ディスクやファイルのような,さまざまなデータおよびシステム・リソースを共用します。リソースの一貫性の維持にはメンバの連携が必要であり,そのためにはメンバシップに関する明確な基準が必要です。この基準を満たさないシステムに対しては,クラスタへの参加を許可しないようにします。
この章では,次の項目について説明します。
接続マネージャの機能の概要 (4.1 節)
クォーラム,ボート,およびクラスタのメンバシップ (4.2 節)
接続マネージャによるクォーラムの計算方法 (4.3 節)
3 メンバ構成のクラスタの使用例 (4.4 節)
クォーラム・ディスクを使用するタイミングと方法 (4.5 節)
clu_quorum
コマンドによるクラスタのクォーラム情報の表示方法 (4.6 節)
さまざまなボート設定による接続マネージャの動作例 (4.7 節)
接続マネージャのモニタ方法 (4.8 節)
接続マネージャのパニック (4.9 節)
不適切な期待ボートおよびノード・ボート設定に関する問題解決 (4.10 節)
接続マネージャは,クラスタのメンバが相互に通信できるかどうかを監視し,クラスタのメンバシップに関する規則を強制する分散型のカーネル構成要素です。接続マネージャは次のような機能を実行します。
クラスタの形成,クラスタへのメンバの追加,およびクラスタからのメンバの削除を行う。
クラスタのどのメンバが稼働中であるか追跡する。
クラスタのすべてのメンバ上でクラスタのメンバシップ・リストの一貫性を維持する。
EVM (イベント・マネージャ) のイベントを使ってメンバシップの変更を随時通知する。
クラスタ分断を検出して対処する。
接続マネージャのインスタンスは,クラスタの各メンバ上で動作します。これらのインスタンスは,クラスタのメンバシップ・リストのような情報を共有することによって,メンバ間の相互接続を維持します。接続マネージャは,三相コミット・プロトコルを使って,すべてのメンバから見えるクラスタのビューの一貫性を維持します。
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 クラスタのクォーラム・ボートの計算の概要
接続マネージャは,クォーラム・アルゴリズムを使って,あるノードがクラスタに参加し,クラスタ全体のリソースに安全にアクセスして,有用な作業を実行できるかどうかを調べます。このアルゴリズムは動的です。つまり,クラスタのクォーラム・ボートの計算はクラスタのイベントによって開始され,その計算結果はクラスタの存在期間に渡って変化します。
クォーラム・アルゴリズムは次のような仕組みになっています。
接続マネージャは,クラスタのクォーラム・ボートの計算に使用するクラスタ・メンバの集合を選択します。この集合には相互通信可能なメンバのみが含まれます。構成されているがブートされていないノード,ダウンしているメンバ,ハードウェアの障害 (クラスタのインターコネクト・ケーブルの切断や Memory Channel アダプタの故障) によって到達不能になったメンバなどは含まれません。
クラスタの形成時,ノードがブートしてクラスタに参加するたびに,接続マネージャは次の値から最大値を選択し,その値を使ってクラスタの期待ボートを計算します。
手順 1 で選択したメンバの集合から取得したメンバの期待ボートのうちの最大値
手順 1 で選択したメンバの集合から取得したノード・ボートとクォーラム・ディスク・ボート (クォーラム・ディスクが構成されている場合) との合計
前回のクラスタの期待ボート値
たとえば,クォーラム・ディスクがない 3 メンバ構成のクラスタがあるとします。すべてのメンバは稼働中であり,相互に接続されています。各メンバのノード・ボートは 1 に設定され,期待ボートは 3 に設定されています。クラスタの期待ボートは現在 3 です。
その後,4 番目の投票メンバがクラスタに参加するとします。この新しいメンバがブートしてクラスタに参加した場合,接続マネージャはクラスタの期待ボートを計算して,4 に設定します。この値はクラスタ内のノード・ボートの合計です。
クラスタの期待ボートの現在の値を表示するには,コマンド
clu_quorum
または
clu_get_info -full
を使用します。
接続マネージャは,クラスタの期待ボートを再計算するたびに (または
clu_quorum -e
コマンドでクラスタの期待ボートをリセットするたびに),クォーラム・ボートを計算します。
クォーラム・ボートは,クラスタの期待ボートの値に基づいて動的に計算されるクラスタ単位の値です。この値によって,ノードに対し,クラスタの形成,クラスタへの参加,またはクラスタへの残留を許可するかどうかが決まります。接続マネージャは,次の数式を使ってクラスタのクォーラム・ボートを計算します。
クォーラム・ボート = (クラスタの期待ボート + 2) / 2 (小数点以下切り捨て)
たとえば,前述した手順の 3 メンバ構成のクラスタの場合,クラスタの期待ボートが 3 なので,クォーラム・ボートは,((3+2) / 2) で計算して小数点以下を切り捨てた結果,2 になります。4 番目のメンバが正常に追加された場合,クォーラム・ボートは,((4+2) / 2) で計算して小数点以下を切り捨てた結果,3 になります。
注意
期待ボートは (結果的にクォーラム・ボートも) クラスタ構成に基づきます。どのノードが稼働しているかダウンしているかには関係ありません。メンバがシャットダウンされたか,他の何らかの理由でダウンしたとき,接続マネージャはクォーラム・ボートの値を減らしません。メンバが削除されたか,
clu_quorum -e
コマンドが実行されたときだけ,接続マネージャは稼働中のクラスタのクォーラム・ボート値を減らします。
クラスタのメンバが参照可能なボート数の変化を検出すると (ノードがクラスタに参加したか,既存メンバがクラスタから削除されたか,通信エラーが報告されたことが原因),そのメンバは常に現在のボートとクォーラム・ボートとを比較します。
この後,メンバは次の条件に基づいたアクションをとります。
現在のボートの値がクォーラム・ボートの値以上の場合,そのメンバは動作を続行するか,動作を再開します (中断されていた場合)。
現在のボートの値がクォーラム・ボートの値未満の場合,そのメンバはすべてのプロセス動作,クラスタ全体のストレージへの入出力操作,およびクラスタの外部ネットワークに対する操作を中断します。十分な数のボートが追加され (つまり十分な数のメンバがクラスタに参加するか,通信上の問題が解決され),現在のボートの値がクォーラム・ボートの値以上になると,中断されていた動作や操作は再開されます。
イベント・メッセージにはクォーラムが失われたことがクラスタ単位のイベントとして書き込まれることがありますが,現在のボートとクォーラム・ボートとの比較はメンバ単位で行われます。クラスタのいずれかのメンバがクォーラムを失うと,そのメンバの入出力操作はすべて中断され,クラスタ・インターコネクト以外のすべてのネットワーク・インタフェースが停止状態になります。クラスタ全体のリソースへのアクセスを必要とするコマンドはすべて,そのメンバ上では機能しなくなります。その結果,そのメンバはハングアップしているように見えることがあります。
そのメンバがどのようにクォーラムを失ったかにもよりますが,クォーラムを失ったメンバがクォーラムを満たせるだけのボートを別のメンバに割り当て,そのメンバをブートし,クォーラムを回復させることによって,この状況を解決できる場合があります。ただし,クラスタのすべてのメンバがクォーラムを失った場合は,それらのメンバがクォーラムを満たせるだけのボートを新規メンバに割り当て,その新規メンバをブートするか,クラスタ全体をリブートするか,あるいは
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. . .
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 . . .
次に,クォーラム・ディスクの使用上の制限を示します。
クラスタ内には 1 つのクォーラム・ディスクしか構成できません。
クォーラム・ディスクは,クラスタのすべてのメンバが直接接続される共用バス上に置くことを推奨します。共用バス上にない場合,クォーラム・ディスクに直接接続されないメンバは,クォーラム・ディスクに直接接続されるメンバよりも先に,クォーラムを失う可能性があります。
クォーラム・ディスクにはデータが格納されていてはなりません。クォーラム・ディスクの初期化時,ディスク内の既存データは
clu_quorum
コマンドによって上書きされます。また,メンバに障害が発生すると,稼働中のクラスタからクォーラム・ディスクに格納されたデータ (またはファイル・システムのメタデータ) の一貫性は失われます。
メンバのブート・ディスク,およびクラスタ全体のルート (/) があるディスクは,クォーラム・ディスクとして使用できません。
クォーラム・ディスクの容量は非常に小さくても問題ありません。クラスタ・サブシステム用に必要なのは 1 MB だけです。
クォーラム・ディスクには 1 ボートを割り当てても,ボートを割り当てなくてもかまいません。通常は,クォーラム・ディスクにはボートを割り当てておきます。ただし,テスト構成または一時的な構成では,ボートを割り当てない場合もあります。たとえば,1 メンバ構成のクラスタで 1 ボートを持つクォーラム・ディスクが別の障害ポイントとなる場合です。
概念としては,クラスタの障害のあるメンバ (ボート) とないメンバが同数である場合,クォーラム・ディスクで提供されるボートはタイブレーカとして働きます。タイブレーカのボートによって,クォーラムを維持してクラスタ操作が継続されます。この点についてクォーラム・ディスクのボートは,ボートと違いはありません。たとえば,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 障害が発生したクォーラム・ディスクの交換
クラスタの稼働中にクォーラム・ディスクに障害が発生したが,クラスタがクォーラムを失わない場合は,次の手順でディスクを交換できます。
ディスクがクラスタから切断されていることを確認します。
clu_quorum
コマンドを実行し,クォーラム・ディスク・ボートの実行時の値をメモしておきます。
clu_quorum -f -d remove
コマンドを使って,クラスタからクォーラム・ディスクを削除します。
ディスクを交換します。各クラスタ・メンバ上で
hwmgr -scan scsi
コマンドを入力します。
注意
hwmgr -scan scsi
コマンドは,すべてのクラスタ・メンバ上で実行する必要があります。
新規ディスクがすべてのメンバによって認識されるまで,しばらく待ちます。
hwmgr -view devices -cluster
コマンドを使って,新規ディスクのデバイス・スペシャル・ファイルの名前 (dsk
名) を調べます。この名前は,障害が発生したクォーラム・ディスクの名前とは異なります。任意に,dsfmgr -n
コマンドを使って,新規ディスクのデバイス・スペシャル・ファイルの名前を障害が発生したディスクの名前に変更することもできます。
clu_quorum -f -d add
コマンドを使って,新規ディスクをクォーラム・ディスクとして構成します。新規ディスクには,手順 2 でメモしておいたボートと同数のボートが割り当てられていることを確認します。
クラスタの稼働中にクォーラム・ディスクに障害が発生して,クラスタがクォーラムを失い,クラスタの動作が中断された場合は,4.10.1 項の手順に従って,1 つのクラスタ・メンバを停止し,対話形式でリブートして,クラスタのクォーラムを回復しなければなりません。その後,前述の手順を実行できます。
4.6 clu_quorum コマンドによるクラスタのクォーラム情報の表示
clu_quorum
コマンドをオプションなしで実行するか,-f
または
-v
(あるいはその両方) を付けて実行すると,クラスタの現在のクォーラム・ディスク,メンバのノード・ボート,およびクラスタの期待ボートに関する情報が表示されます。この情報は次の項目から構成されます。
クラスタの共通クォーラム・データ。たとえば,構成済みのクォーラム・ディスクのデバイス名,およびクラスタ単位の
/etc/sysconfigtab.cluster
からのクォーラム・データが表示されます。
各メンバの動作中のカーネルおよび
/etc/sysconfigtab
ファイルからのメンバ固有のクォーラム・データと,メンバの状態 (UP
または
DOWN
)。省略時の設定では,DOWN
状態のメンバに関するクォーラム・データは表示されません。ただし,DOWN
状態のメンバのブート・パーティションが
clu_quorum
コマンドの実行元のメンバにアクセス可能な限り,-f
オプションを使って,DOWN
状態のメンバのクォーラム・データの値を表示できます。
clu_quorum
による表示項目については,
clu_quorum
(8)4.7 クラスタ・ボートの割り当て例
表 4-1
に,クラスタ・メンバ上の属性
cluster_expected_votes
および
cluster_node_votes
のさまざまな設定によって,クラスタの形成にどのような影響が出るかを示します。さらに,これらの属性のどの設定の組み合わせによって,クラスタ全体が稼働不能になるか,またはクラスタの可用性が最大限に高まるかも示します。この表では,2 メンバ,3 メンバ,および 4 メンバ構成のクラスタを対象にします。
次に,この表内の見出し下の列の内容と表記について説明します。
「メンバの期待ボート」の列には,メンバの
/etc/sysconfigtab
ファイル内にある
clubase
スタンザの
cluster_expected_votes
属性に設定したメンバの期待ボートを示します。
「M1」,「M2」,「M3」,および「M4」の列には,メンバに割り当てたボートを示します。
「クォーラム・ディスク」の列には,クォーラム・ディスク (構成されている場合) に割り当てたボートを示します。
「---」という表記は,そのノードがクラスタ内で構成されていないことを示します。
表 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 種類のイベントを EVM (イベント・マネージャ) のイベント・メッセージによって管理者に通知します。
クラスタにノードが参加した。
クラスタからノードが削除された。
クォーラム・ディスクが使用不能になった (エラー,削除などが原因)。
クォーラム・ディスクが再度使用可能になった。
これらの各イベントは,コンソール・メッセージによっても通知されます。
接続マネージャは,メンバのブート中やクラスタ・トランザクションの実行中に,さまざまな通知メッセージをコンソールに表示します。
クラスタ・トランザクションは,クラスタのすべてのメンバ上でクラスタ全体の状態をアトミックに変更するためのメカニズムです。つまり,すべてのメンバが新規の値を採用するか,どのメンバも新規の値を採用しないかのいずれかの状態になります。最も多く発生するクラスタ・トランザクションは,メンバシップ関連のトランザクションです。たとえば,クラスタの形成時やクラスタに対するメンバの追加または削除時に発生します。ある種の保守作業,たとえばクォーラム・ディスクの追加または削除,クラスタの期待ボートの変更,メンバのノード・ボートの変更を行うときにも,クラスタ・トランザクションは発生します。
クラスタ・トランザクションはグローバルに (クラスタ単位で) 発生するイベントですが,接続マネージャは,ローカルで発生したイベントに対応するメッセージもメンバのコンソールに表示します。たとえば,そのノードと別のノード (またはクォーラム・ディスク) との間の接続性の変化,クォーラムの獲得,クォーラムの喪失などを通知します。
4.9 接続マネージャのパニック
接続マネージャはクラスタのメンバを連続的に監視しています。クラスタの分断によって既存のクラスタが 2 つ以上のクラスタに分割されている場合は,ノードが自分たちをいずれかのクラスタのメンバであると認識することがまれにあります。4.3 節で説明したように,接続マネージャが動作を許可するクラスタは,多くても 1 つです。
クラスタ分断の発生時にデータの一貫性を維持するために,接続マネージャは 1 つのメンバをパニック状態にします。パニック文字列はクラスタ分断の検出時の状況を示します。このようなパニックは,接続マネージャの問題が原因で発生するのではなく,悪状況に対応して発生します。たとえば,徹底した対処策をとらないとデータの一貫性を維持できないような状況です。クラスタ分断を解消するには,1 つ (または複数) のメンバをリブートして,クラスタに再参加させるしか対処策はありません。
接続マネージャがクラスタの 1 つのメンバをパニック状態にするのは,次のような状況が発生したときです。
クォーラム・ディスクが 2 つのクラスタに接続された。
CNX QDISK: configuration error. Qdisk in use by cluster of different name. CNX QDISK: configuration error. Qdisk written by cluster of different name.
クラスタ分断後に複数のクラスタ間でクォーラム・ディスクの所有権の競合が発生した。
この状況が発生したメンバは,引き続きクォーラム・ディスクの所有権を要求するか,パニック状態に移行してこの所有権を別のクラスタに譲ります。
CNX QDISK: Yielding to foreign owner with quorum. CNX QDISK: Yielding to foreign owner with provisional quorum. CNX QDISK: Yielding to foreign owner without quorum.
あるクラスタのメンバであるノード上の接続マネージャが,別のクラスタのメンバであるノード (または同じクラスタからクラスタ分断によって発生した別のクラスタのメンバであるノード) を検出した。
この状況が発生したノードは,クォーラムの状態に応じて,パニック状態に移行するように別のノードに指示するか,自身がパニック状態に移行します。
CNX MGR: restart requested to resynchronize with cluster with quorum. CNX MGR: restart requested to resynchronize with cluster
パニック状態に移行したノードがクラスタを検出し,リブートしてそのクラスタに参加しようとした。
CNX MGR: rcnx_status: restart requested to resynchronize with cluster with quorum. CNX MGR: rcnx_status: restart requested to resynchronize with cluster
通信上の問題のため再構成中にノードがクラスタから削除された。
CNX MGR: this node removed from cluster
4.10 不適切な期待ボートおよびノード・ボート設定に関するトラブルシューティング
クラスタがクォーラムを維持している限り,clu_quorum
コマンドを使って,クラスタ内のノード・ボート,期待ボート,およびクォーラム・ディスク・ボートを調節できます。このコマンドに
-f
オプションを使用すれば,現在ダウンしているメンバにも変更を反映できます。
ただし,クラスタのいずれかのメンバがクォーラムを失った場合は,そのメンバの入出力操作はすべて中断され,クラスタ・インターコネクト以外のすべてのネットワーク・インタフェースが停止状態になります。クラスタ全体のリソースへのアクセスが必要なコマンド (clu_quorum
など) もすべて,そのメンバ上では機能しなくなります。この場合は,クォーラムを失ったメンバがクォーラムを満たせるだけのボートを別のメンバに割り当て,そのメンバをクラスタに再参加させて,クォーラムを回復させるか,あるいはクラスタ・メンバを停止して,リブートしなければなりません。
クォーラムの喪失でハングアップしているクラスタや,ボート不足のために形成不能のクラスタでは,ボート構成の調節が必要な場合があります。以降の各項では,クラスタに関するいくつかの問題とそれらの解決に使用できるメカニズムについて説明します。
4.10.1 クラスタのメンバまたはクォーラム・ディスクに障害が発生しクラスタがクォーラムを失った後にクラスタに参加させる
1 つまたは複数のメンバ (またはクォーラム・ディスク) にハードウェアの問題が発生し,クラスタはそれらのメンバを失いました。問題が発生したメンバはリブート不能です。それらのメンバを失ったことで,クラスタはクォーラムを失いました。残りの稼働中のメンバの期待ボートまたはノード・ボートの設定では,メンバが減った現在のクラスタの可用性を維持できません。クラスタはクォーラムを失い,ハングアップしています。
この種のクォーラム喪失状況は,クラスタ全体をシャットダウンしなくても解決できます。手順としては,1 つのクラスタ・メンバを停止し,クラスタに参加できるようにそのメンバをリブートして,クォーラムを回復します。このメンバをブートした後に,clu_quorum
コマンドを使用して,本来の問題を修正する必要があります。
注意
1 つのクラスタ・メンバだけが稼働中であるか,またはクォーラム・ディスクに障害が発生した場合は,4.10.2 項で説明する手順を使用し,十分なボートを持つクラスタ・メンバをブートして,クラスタを形成します。
1 つまたは複数のメンバあるいはクォーラム・ディスクに障害が発生したためにクォーラムを失ったクラスタのクォーラムを回復するには,次の手順に従います。
Halt ボタンを使用して,クラスタの 1 つのメンバを停止します。
停止したメンバを対話形式でリブートします。リブート中,ブート元のカーネルの名前を要求されたら,カーネル名と
clubase
の
cluster_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
ファイル内に格納されている値は変更されません。この時点で,クラスタ内のノード・ボート,期待ボート,およびクォーラム・ディスクを明示的に再構成しない場合,クラスタの次回リブート時には,ブート・メンバはクォーラムを満たさず,クラスタを形成できません。この理由から,必要に応じ,次の手順に従って,クラスタ内のこのメンバとその他のメンバのノード・ボートと期待ボートの値を修正してください。
故障しているハードウェアが修理されるかまたは取り換えられるまで,表 4-2
を参照し,適切な
clu_quorum
コマンドを使用して,クラスタのボート構成を一時的に修正します。通常は,クラスタが起動して安定すると,clu_quorum
コマンドを使用して,本来の問題を修正します。たとえば,次のようにします。
ハードウェアに問題があるメンバのノード・ボートを減らす。
# clu_quorum -f -m member-ID lower_node_votes_value
このメンバのブート・ディスクにアクセスできない場合 (たとえばブート・ディスクがメンバのプライベート・バス上にある場合),このコマンドはエラーを返すことがあります。この理由からこのコマンドの実行が失敗する場合は,clu_quorum -f -e
コマンドを使って,期待ボートを適切な値に調節します。
すべてのメンバの期待ボートから,ハードウェアの問題によって投票不能になったが,そのボートを削除できないメンバ分のボートを差し引く。
# clu_quorum -f -e lower_expected_votes_value
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.
2.
3.
4.
故障したハードウェアを修理または交換する。2 メンバ・クラスタで,障害に耐えなければならない場合に最も緊急に必要となるのは,投票クォーラム・ディスクである。 クォーラム・ディスクを追加できない場合は, |
稼働,1 ボート | 稼働,1 ボート | 障害,1 ボート | 障害,1 ボート | 障害,1 ボート | NC | 1.
2.
3.
故障したハードウェアを修理または交換する。2 メンバ・クラスタで障害に耐えなければならない場合に最も緊急に必要となるのは,投票クォーラム・ディスクである。 障害の発生したメンバが長時間利用できない場合は, |
4.10.2 メンバがブートとクラスタ形成に必要な数のボートを持っていない場合のクラスタ形成
クラスタを形成できません。すべてのメンバをブートしようとすると,クラスタを形成できず,各メンバはハングアップします。これらのメンバには,クォーラムに達するのに必要なボートが不足しています。ハードウェアの故障がよく起こる小規模のクラスタも,最後に稼働していた投票メンバがクォーラムを失うような構成になる場合があります。
次の手順を実行すると,クラスタを形成するのに十分なボートを持つ 1 つのクラスタ・メンバをブートすることができます。その後,ノード・ボートを調節して,残りのメンバをクラスタにブートします。
各クラスタ・メンバを停止します。
表 4-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-3
を参照し,適切な
clu_quorum
コマンドを使用して,クラスタのボートの構成を一時的に修正します。利用できないクォーラム・ディスクが問題の原因となっている場合は,そのディスクが利用可能かどうかと,ボートを持っているかどうかを確認します。必要であれば,クォーラム・ディスクを交換します (4.5.1 項を参照)。そうでない場合,他のメンバをブートできないことがあります。
残りのメンバをリブートします。
表 4-3
に,クラスタを形成するのに十分なボートを持つクラスタ・メンバをブートして,クォーラム不足を解決する方法の例を示します。この表で,NC は,メンバまたはクォーラム・ディスクがクラスタで構成されていないことを示します。
表 4-3: クラスタを形成するのに十分なボートを持つメンバのブートによるクォーラム不足の解決例
M1 | M2 | M3 | クォーラム・ディスク | 手順 |
稼働,1 ボート | 稼働,0 ボート | NC | 障害,1 ボート | 1.
2.
3.
|
稼働,1 ボート | 障害,1 ボート | NC | 障害,1 ボート | 1.
2.
3.
4. 故障したハードウェアを修理または交換する。投票クォーラム・ディスクのある 2 番目の投票メンバを直ちに入手できない場合は,暫定的な解決方法として,ボートのない 2 番目のメンバを追加する。この結果,非投票メンバの障害に耐える構成となる。 |
稼働,1 ボート | 障害,1 ボート | 障害,1 ボート | NC | 1.
2.
適切な
3. 故障したハードウェアを修理または交換する。投票クォーラム・ディスクのある 2 番目の投票メンバを直ちに入手できない場合は,暫定的な解決方法として,ボートのない 2 番目のメンバを追加する。この結果,非投票メンバの障害に耐える構成となる。 |