8 フェンシングとSTONITH
フェンシングはHA(High Availability)向けコンピュータクラスタにおいて、非常に重要なコンセプトです。クラスタがノードの1つの誤動作を検出し、そのノードの削除が必要となることがあります。これをフェンシングと呼び、一般にSTONITHリソースで実行されます。フェンシングは、HAクラスタを既知の状態にするための方法として定義できます。
クラスタのすべてのリソースには、それぞれ状態が関連付けられています。たとえば、「リソースr1はaliceで起動されている」などです。HAクラスタでは、このような状態は「リソースr1はalice以外のすべてのノードで停止している」ことを示します。クラスタは各リソースが1つのノードでのみ起動されるようにするためです。各ノードはリソースに生じた変更を報告する必要があります。つまり、クラスタの状態は、リソースの状態とノードの状態の集まりです。
ノードまたはリソースの状態を十分に確定することができない場合には、フェンシングが発生します。クラスタが所定のノードで起こっていることを認識しない場合でも、フェンシングによって、そのノードが重要なリソースを実行しないようにできます。
8.1 フェンシングのクラス #
フェンシングには、リソースレベルとノードレベルのフェンシングという、2つのクラスがあります。後者について、この章で主に説明します。
- リソースレベルのフェンシング
リソースレベルのフェンシングでは、クラスタが、ノードによる1つ以上のリソースのアクセスを不可能にできます。代表的な一例はSANで、フェンシング操作によってSANスイッチのルールを変更し、ノードからのアクセスを拒否します。
リソースレベルのフェンシングは、保護対象のリソースが依存している通常のリソースを使用して実行できます。このようなリソースは、このノード上での起動を拒否するため、それに依存するリソースは同じノード上で実行されません。
- ノードレベルのフェンシング
ノードレベルのフェンシングでは、ノードがどのリソースも実行しなくなります。このことは通常、そのノードをリセットする、または電源オフにするというような、極端な手段で行われます。
8.2 ノードレベルのフェンシング #
SUSE® Linux Enterprise High Availability Extensionにおけるフェンシングの実装が、STONITH (Shoot The Other Node in the Head)です。 これにより、ノードレベルのフェンシングが実行されます。High Availability Extensionにはstonithコマンドラインツールが付属し、これはクラスタ上のノードの電源をリモートでオフにする拡張インタフェースです。使用できるオプションの概要については、stonith --helpを実行するか、またはstonithのマニュアルページで詳細を参照してください。
8.2.1 STONITHデバイス #
ノードレベルのフェンシングを使用するには、まず、フェンシングデバイスを用意する必要があります。High Availability ExtensionでサポートされているSTONITHデバイスのリストを取得するには、次のコマンドをrootとして任意のノード上で実行します。
stonith -L
STONITHデバイスは次のカテゴリに分類できます。
- 電源分配装置(PDU)
電源分配装置は、重要なネットワーク、サーバ、データセンター装置の電力と機能を管理する、重要な要素です。接続した装置のリモートロード監視と、個々のコンセントでリモート電源オン/オフのための電力制御を実行できます。
- 無停電電源装置(UPS)
電力会社からの停電時に別個のソースから電力を供給することで、安定した電源から接続先の装置に緊急電力が提供されます。
- ブレード電源制御デバイス
クラスタを一連のブレード上で実行している場合、ブレードエンクロージャの電源制御デバイスがフェンシングの唯一の候補となります。当然、このデバイスは1台のブレードコンピュータを管理できる必要があります。
- ライトアウトデバイス
ライトアウトデバイス(IBM RSA、HP iLO、Dell DRAC)は急速に広まっており、既製コンピュータの標準装備になる可能性さえあります。ただし、電源をホスト(クラスタノード)と共有するため、これらはUPSデバイスに内蔵されています。ノードに電力が供給されないままでは、それを制御するデバイスも役に立ちません。その場合は、CRMがノードのフェンシングの試行を無限に継続し、他のすべてのリソース操作はフェンシング/STONITH操作の完了を待機することになります。
- テストデバイス
テストデバイスは、テスト専用に使用されます。通常、ハードウェアにあまり負担をかけないようになっています。クラスタが運用に使用される前に、実際のフェンシングデバイスに交換される必要があります。
STONITHデバイスは、予算と使用するハードウェアの種類に応じて選択します。
8.2.2 STONITHの実装 #
SUSE® Linux Enterprise High Availability ExtensionでのSTONITHの実装は、2つのコンポーネントで構成されています。
- stonithd
stonithdは、ローカルプロセスまたはネットワーク経由でアクセスできるデーモンです。stonithdは、フェンシング操作に対応するコマンド(rest、power-off、power-on)を受け入れます。フェンシングデバイスのステータスチェックも行います。
stonithdデーモンはCRM HAクラスタの各ノードで実行されます。DCノードで実行されるstonithdインスタンスは、CRMからフェンシング要求を受け取ります。目的のフェンシング操作を実行するのは、このインスタンスとその他のstonithdプログラムです。
- STONITHプラグイン
サポートされているフェンシングデバイスごとに、そのデバイスを制御できるSTONITHプラグインがあります。STONITHプラグインはフェンシングデバイスへのインタフェースです。各ノード上で、すべてのSTONITHプラグインが
/usr/lib/stonith/plugins(または64ビットアーキテクチャでは/usr/lib 64/stonith/plugins)内に存在します。 すべてのSTONITHプラグインはstonithdからは同一のものと認識されますが、フェンシングデバイスの性質を反映しているため、大きな違いがあります。一部のプラグインは、複数のデバイスをサポートします。代表的な例は
ipmilan(またはexternal/ipmi)で、IPMIプロトコルを実装し、このプロトコルをサポートする任意のデバイスを制御できます。
8.3 STONITHの構成 #
フェンシングをセットアップするには、1つまたは複数のSTONITHリソースを設定する必要があります。stonithdデーモンでは設定は不要です。すべての設定はCIBに保存されます。STONITHリソースはクラスstonithのリソースです(4.2.2項 「サポートされるリソースエージェントクラス」を参照)。STONITHリソースはSTONITHプラグインのCIBでの表現です。フェンシング操作の他、STONITHリソースはその他のリソースと同様、起動、停止、監視できます。STONITHリソースの開始または停止は、ノード上でSTONITHデバイスドライバのロードおよびアンロードが行われることを意味しています。開始と停止は管理上の操作であるため、フェンシングデバイス自体での操作にはなりません。ただし、監視は、デバイスのログイン操作になります(必要な場合にデバイスが動作していることを検証するため)。STONITHリソースが別のノードにフェールオーバーすると、対応するドライバがロードされて、現在のノードがSTONITHデバイスと通信できるようにされます。
STONITHリソースはその他のリソースと同様にして設定できます。リソースの設定については、5.3.3項 「STONITHリソースの作成」、または6.4.3項 「STONITHリソースの作成」を参照してください。
パラメータ(属性)のリストは、それぞれのSTONITHの種類に依存します。特定のデバイスのパラメータ一覧を表示するには、stonithコマンドを実行します。
stonith -t stonith-device-type -n
たとえば、ibmhmcデバイスタイプのパラメータを表示するには、次のように入力します。
stonith -t ibmhmc -n
デバイスの簡易ヘルプテキストを表示するには、-hオプションを使用します。
stonith -t stonith-device-type -h
8.3.1 STONITHリソースの設定例 #
以降では、crmコマンドラインツールの構文で作成された設定例を紹介します。これを適用するには、サンプルをテキストファイル(sample.txtなど)に格納して、実行します。
root #crm< sample.txt
crmコマンドラインツールでのリソースの設定については、第6章 クラスタリソースの設定と管理(コマンドライン)を参照してください。
警告: テストの設定
次の例の一部は、説明およびテストのみを目的としています。テストの設定例を実際のクラスタシナリオで使用しないでください。
例 8.1 テストの設定 #
configure primitive st-null stonith:null \ params hostlist="alice bob" clone fencing st-null commit
例 8.2 テストの設定 #
別の設定:
configure primitive st-alice stonith:null \ params hostlist="alice" primitive st-bob stonith:null \ params hostlist="bob" location l-st-alice st-alice -inf: alice location l-st-bob st-bob -inf: bob commit
この設定例は、クラスタソフトウェアに関してはまったく問題ありません。実世界との違いは、フェンシング操作が行われないことだけです。
例 8.3 テストの設定 #
より現実的な例(ただし、テスト目的のみ)として、次のexternal/ssh設定があります。
configure primitive st-ssh stonith:external/ssh \ params hostlist="alice bob" clone fencing st-ssh commit
これも、ノードをリセットできます。この設定は、null STONITHデバイスを利用する最初の例と似ています。この例では、クローンが使用されています。これはCRM/Pacemakerの機能です。クローンはショートカットで、n個の同一リソースに別の名前を付けて定義しなくても、1つのクローンされたリソースで足ります。すべてのノードからSTONITHデバイスがアクセス可能である限り、クローンの最も一般的な使用方法は、STONITHリソースで使用することです。
例 8.4 IBM RSAライトアウトデバイスの設定 #
実際のデバイス設定とはそれほど違いはありませんが、一部のデバイスにはより多くの属性が必要となります。IBM RSAライトアウトデバイスは、次のようにして設定できます。
configure primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \ params nodename=alice ipaddr=192.168.0.101 \ userid=USERID passwd=PASSW0RD primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \ params nodename=bob ipaddr=192.168.0.102 \ userid=USERID passwd=PASSW0RD location l-st-alice st-ibmrsa-1 -inf: alice location l-st-bob st-ibmrsa-2 -inf: bob commit
この例では、location制約が使用されていますが、それは、STONITH操作が常に一定の確率で失敗するためです。したがって、(実行側でもあるノード上の) STONITH操作は信頼できません。ノードがリセットされていない場合、フェンシング操作結果について通知を送信できません。これを実行する方法は、操作が成功すると仮定して事前に通知を送信するほかありません。ただし操作が失敗した場合、問題が発生することがあります。したがって、規則によってstonithdはホストの終了を拒否します。
例 8.5 UPSフェンシングデバイスの設定 #
UPSタイプのフェンシングデバイスの設定は、上記の例と似ています。詳細についてはここでは割愛します。すべてのUPSデバイスは、フェンシングのために、同じ機構を使用します。デバイスへのアクセス方法が異なる方法。古いUPSデバイスにはシリアルポートしかなく、通常、特別のシリアルケーブルを使用して1200ボーで接続していました。新型の多くは、まだシリアルポートがありますが、USBインタフェースまたはEthernetインタフェースも使用します。使用できる接続の種類は、プラグインが何をサポートしているかによります。
たとえば、apcmasterをapcsmartデバイスと、stonith -t stonith-device-type -nコマンドを使用して比較します。
stonith -t apcmaster -h
次の情報が返されます。
STONITH Device: apcmaster - APC MasterSwitch (via telnet) NOTE: The APC MasterSwitch accepts only one (telnet) connection/session a time. When one session is active, subsequent attempts to connect to the MasterSwitch will fail. For more information see http://www.apc.com/ List of valid parameter names for apcmaster STONITH device: ipaddr login password
今度は次のコマンドを使用します。
stonith -t apcsmart -h
次の結果が得られます。
STONITH Device: apcsmart - APC Smart UPS (via serial port - NOT USB!). Works with higher-end APC UPSes, like Back-UPS Pro, Smart-UPS, Matrix-UPS, etc. (Smart-UPS may need to be >= Smart-UPS 700?). See http://www.networkupstools.org/protocols/apcsmart.html for protocol compatibility details. For more information see http://www.apc.com/ List of valid parameter names for apcsmart STONITH device: ttydev hostlist
最初のプラグインは、ネットワークポートとtelnetプロトコルを持つAPC UPSをサポートします。2番目のプラグインはAPC SMARTプロトコルをシリアル回線で使用します。これはその他多数のAPC UPS製品ラインでサポートされているものです。
8.3.2 制約とクローン #
8.3.1項 「STONITHリソースの設定例」で説明したように、STONITHリソースを制約、クローン、またはその両方を使用して設定するにはいくつかの方法があります。設定にどちらの構成を使用するかは、いくつかの要因(フェンシングデバイスの性質、デバイスで管理されるホスト数、クラスタノード数、または個人の志向)によって決まります。
まとめると、クローンを問題なく使用でき、設定が縮小できる場合には、クローンを作成したSTONITHリソースを使用します。
8.4 フェンシングデバイスの監視 #
他のリソースと同様に、STONITHクラスのエージェントは、ステータスのチェックのための監視操作もサポートします。
注記: STONITHリソースの監視
STONITHリソースの監視は定期的に行われますが、頻繁ではありません。ほとんどのデバイスでは、少なくとも1800秒(30分)の監視間隔があれば十分です。
フェンシングデバイスはHAクラスタの不可欠な要素ですが、使用する必要が少ないほど好都合です。ブロードキャストトラフィックが多すぎると、しばしば、電源管理装置が影響を受けます。1分間に10本程度の接続しか処理できないデバイスもあります。2つのクライアントが同時に接続しようとすると、混乱するデバイスもあります。大部分は、同時に複数のセッションを処理できません。
したがって、通常、フェンシングデバイスのステータスは数時間ごとにチェックすれば十分です。フェンシング操作の実行が必要となり、電源スイッチが故障する可能性は小さいものです。
監視操作の設定方法の詳細については、6.4.8項 「リソース監視の設定」を参照してください(コマンドラインアプローチについて説明されている)。
8.5 特殊なフェンシングデバイス #
実際のSTONITHデバイスを操作するプラグインに加えて、特殊目的のSTONITHプラグインも存在します。
警告: テスト目的のみ
次に示すSTONITHプラグインの一部は、デモとテストだけを目的としています。次のデバイスは、現実のシナリオでは使用しないでください。使用すると、データが損なわれたり、予測できない結果が生じることがあります。
external/sshsshnull
external/kdumpcheckこのプラグインは、ノードでカーネルダンプが進行中かどうかをチェックします。進行中であれば
trueを返し、ノードがフェンシングされたかのように動作します。いずれにせよ、ダンプ中には、ノードはどのリソースも実行できません。これによって、すでにダウンしているがダンプ中(これは時間がかかります)であるノードのフェンシングを避けることができます。このプラグインは、別の実際のSTONITHデバイスとともに使用する必要があります。詳細については、/usr/share/doc/packages/cluster-glue/README_kdumpcheck.txtを参照してください。external/sbdこれは自己フェンシングデバイスです。共有ディスクに挿入されることがある、いわゆる「ポイズンピル」に反応します。共有ストレージ接続が失われた場合、このデバイスはノードの動作を停止します。このSTONITHエージェントを使用してストレージベースのフェンシングを実装する方法については、第17章 ストレージ保護を参照してください。詳細については、http://www.linux-ha.org/wiki/SBD_Fencingも参照してください。
重要:
external/sbdおよびDRBDexternal/sbdフェンシングメカニズムは、SBDパーティションが各ノードから直接読み取れることを要求します。そのため、SBDパーティションではDRBD*デバイスを使用してはなりません。ただし、SBDパーティションが階層配置または複製されていない共有ディスク上にある場合には、DRBDクラスタでフェンシングメカニズムを使用することはできます。
external/ssh別のソフトウェアベースの「フェンシング」メカニズムです。ノードは、
rootとして、パスワードなしでお互いにログインできる必要があります。このメカニズムは、1つのパラメータhostlistをとり、ターゲットにするノードを指定します。これは、本当に障害のあるノードをリセットすることはできないので、実際のクラスタには使用しないでください。これは、テストとデモの目的にのみ使用します。これを共有ストレージに使用すると、データが破損します。meatwaremeatwareではユーザが操作を支援する必要があります。起動すると、meatwareはノードのコンソールに表示されるCRIT重大度メッセージを記録します。その場合、オペレータはノードがダウンしていることを確認して、meatclient(8)コマンドを発行します。これによりmeatwareは、クラスタに対して、そのノードが 機能しなくなっていることを伝えます。詳細については、/usr/share/doc/packages/cluster-glue/README.meatwareを参照してください。nullこれはさまざまなテストシナリオで使用される仮想デバイスです。常にノードが停止したように示しますが、実際は何も行いません。処理内容を理解している場合を除き、使用しないでください。
suicideこれはソフトウェアのみのデバイスで、
rebootコマンドを使用して実行しているノードを再起動できます。これにはノードのオペレーティングシステムによる操作が必要で、特定の状況では失敗することがあります。したがって、このデバイスの使用は、極力避けてください。ただし、1ノードクラスタで使用する場合は安全です。
suicideとnullは、「自分のホストを停止させない」というルールへの唯一の例外です。
8.6 基本的な推奨事項 #
次の推奨事項のリストをチェックして、よく発生する間違いを避けてください。
複数の電源スイッチを並列に接続しないでください。
STONITHデバイスとその設定をテストする際には、各ノードからプラグを1回抜いて、ノードのフェンシングが起こらないことを検証してください。
リソースのテストは負荷のかかった状態で行って、タイムアウト値が適切であるかどうかを検証してください。タイムアウト値が短すぎると、(不必要な)フェンシング操作がトリガされることがあります。詳細については、4.2.9項 「タイムアウト値」を参照してください。
セットアップでは適切なフェンシングデバイスを使用してください。詳細については、8.5項 「特殊なフェンシングデバイス」も参照してください。
1つ以上のSTONITHリソースを設定します。デフォルトでは、グローバルクラスタオプション
stonith-enabledはtrueに設定されています。STONITHリソースが定義されていない場合、クラスタはどのリソースの開始も拒否します。グローバルクラスタオプション
stonith-enabledをfalseに設定しないでください。これは、次の理由によります。STONITHが有効でないクラスタはサポートされていません。
DLM/OCFS2は、決して発生しないフェンシング操作を待機して、永久にブロックし続けます。
グローバルクラスタオプション
startup-fencingをfalseに設定しないでください。 デフォルトでは、これは次の理由でtrueに設定されています。クラスタの起動時に、あるノードが不明な状態になっていると、そのノードは、ステータスが明らかにされるまでフェンシングされます。
8.7 詳細 #
/usr/share/doc/packages/cluster-glueインストールしたシステムのこのディレクトリには、多数のSTONITHプラグインおよびデバイスのREADMEファイルが格納されています。
- http://www.linux-ha.org/wiki/STONITH
STONITHに関する情報。High Availability Linux Projectのホームページにあります。
- http://www.clusterlabs.org/doc/
フェンシングとStonith: フェンシングに関する情報はPacemaker Projectのホームページにあります。
『Pacemaker Explained (Pacemaker 1.1 for Corosync 2.x and crmsh)』: Pacemakerの設定に必要なコンセプトを説明します。包括的で非常に詳細な参照用情報です。
- http://techthoughts.typepad.com/managing_computers/2007/10/split-brain-quo.html
HAクラスタでのスプリットブレイン、クォーラム、フェンシングのコンセプトを説明する記事。