フェンシングとSTONITH | 管理ガイド | SUSE Linux Enterprise High Availability Extension 12 SP5

documentation.suse.com › SUSE Linux Enterprise High Availability Extensionのドキュメント › 管理ガイド › 設定および管理 › フェンシングとSTONITH

管理ガイド

ナビゲーション←→

適用先 SUSE Linux Enterprise High Availability Extension 12 SP5

10 フェンシングとSTONITH #

概要#

フェンシングはHA(High Availability)向けコンピュータクラスタにおいて、非常に重要なコンセプトです。クラスタがノードの1つの誤動作を検出し、そのノードの削除が必要となることがあります。これをフェンシングと呼び、一般にSTONITHリソースで実行されます。フェンシングは、HAクラスタを既知の状態にするための方法として定義できます。

クラスタのすべてのリソースには、それぞれ状態が関連付けられています。たとえば、「リソースr1はaliceで起動されている」などです。HAクラスタでは、このような状態は「リソースr1はalice以外のすべてのノードで停止している」ことを示します。クラスタは各リソースが1つのノードでのみ起動されるようにするためです。各ノードはリソースに生じた変更を報告する必要があります。つまり、クラスタの状態は、リソースの状態とノードの状態の集まりです。

ノードまたはリソースの状態を十分に確定することができない場合には、フェンシングが発生します。クラスタが所定のノードで起こっていることを認識しない場合でも、フェンシングによって、そのノードが重要なリソースを実行しないようにできます。

10.1 フェンシングのクラス
10.2 ノードレベルのフェンシング
10.3 STONITHのリソースと環境設定
10.4 フェンシングデバイスの監視
10.5 特殊なフェンシングデバイス
10.6 基本的な推奨事項
10.7 詳細

10.1 フェンシングのクラス #

フェンシングには、リソースレベルとノードレベルのフェンシングという、2つのクラスがあります。後者について、この章で主に説明します。

リソースレベルのフェンシング: リソースレベルのフェンシングにより、特定のリソースへの排他的アクセスが保証されます。この一般的な例として、SANファイバチャネルスイッチからのノードのゾーニングの変更(つまり、ノードのディスクへのアクセスのロックアウト)や、SCSI予約などの方法が挙げられます。例については、 11.10項「ストレージ保護のための追加メカニズム」を参照してください。
ノードレベルのフェンシング: ノードレベルのフェンシングにより、障害が発生したノードから共有リソースに完全にアクセスできなくなります。このことは通常、そのノードをリセットする、または電源オフにするというような、極端な手段で行われます。

10.2 ノードレベルのフェンシング #

Pacemakerクラスタにおけるノードレベルフェンシングの実装は、STONITH (Shoot The Other Node in the Head: 他のノードの即時強制終了)です。High Availability Extensionにはstonithコマンドラインツールが付属し、これはクラスタ上のノードの電源をリモートでオフにする拡張インタフェースです。使用できるオプションの概要については、stonith --helpを実行するか、またはstonithのマニュアルページで詳細を参照してください。

10.2.1 STONITHデバイス #

ノードレベルのフェンシングを使用するには、まず、フェンシングデバイスを用意する必要があります。High Availability ExtensionでサポートされているSTONITHデバイスのリストを取得するには、任意のノード上で次のコマンドのいずれかを実行します。

root # stonith -L

または

root # crm ra list stonith

STONITHデバイスは次のカテゴリに分類できます。

電源分配装置(PDU): 電源分配装置は、重要なネットワーク、サーバ、データセンター装置の電力と機能を管理する、重要な要素です。接続した装置のリモートロード監視と、個々のコンセントでリモート電源オン/オフのための電力制御を実行できます。
無停電電源装置(UPS): 電力会社からの電力の停電発生時に別個のソースから電力を供給することで、安定した電源から接続先の装置に緊急電力が提供されます。
ブレード電源制御デバイス: クラスタを一連のブレード上で実行している場合、ブレードエンクロージャの電源制御デバイスがフェンシングの唯一の候補となります。当然、このデバイスは1台のブレードコンピュータを管理できる必要があります。
ライトアウトデバイス: ライトアウトデバイス(IBM RSA、HP iLO、Dell DRAC)は急速に広まっており、既製コンピュータの標準装備になる可能性さえあります。ただし、ホスト(クラスタノード)と電源を共有する場合は、必要時にそれらが機能しない場合があります。ノードに電力が供給されないままでは、それを制御するデバイスも役に立ちません。したがって、バッテリ駆動のライトアウトデバイスを使用することを強くお勧めします。これらのデバイスはネットワークでアクセスできるという別の側面があります。これはシングルポイント障害またはセキュリティの懸念事項を示唆している可能性があります。
テストデバイス: テストデバイスは、テスト専用に使用されます。通常、ハードウェアにあまり負担をかけないようになっています。クラスタが運用に使用される前に、実際のフェンシングデバイスに交換される必要があります。

STONITHデバイスは、予算と使用するハードウェアの種類に応じて選択します。

10.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プラグインはフェンシングデバイスへのインタフェースです。cluster-glueパッケージに付属するSTONITHプラグインは、各ノード上の/usr/lib64/stonith/pluginsにあります(fence-agentsパッケージもインストールしている場合、そのパッケージに付属する各種プラグインは、/usr/sbin/fence_*にインストールされています)。すべてのSTONITHプラグインはstonithdからは同一のものと認識されますが、フェンシングデバイスの性質を反映しているため、大きな違いがあります。

一部のプラグインは、複数のデバイスをサポートします。代表的な例はipmilan (またはexternal/ipmi)で、IPMIプロトコルを実装し、このプロトコルをサポートする任意のデバイスを制御できます。

10.3 STONITHのリソースと環境設定 #

フェンシングをセットアップするには、1つまたは複数のSTONITHリソースを設定する必要があります。stonithdデーモンでは設定は不要です。すべての設定はCIBに保存されます。STONITHリソースはクラスstonithのリソースです(6.3.2項「サポートされるリソースエージェントクラス」を参照)。STONITHリソースはSTONITHプラグインのCIBでの表現です。フェンシング操作の他、STONITHリソースはその他のリソースと同様、起動、停止、監視できます。STONITHリソースの開始または停止は、ノード上でSTONITHデバイスドライバのロードおよびアンロードが行われることを意味しています。開始と停止は管理上の操作であるため、フェンシングデバイス自体での操作にはなりません。ただし、監視は、デバイスのログイン操作になります(必要な場合にデバイスが動作していることを検証するため)。STONITHリソースが別のノードにフェールオーバーすると、対応するドライバがロードされて、現在のノードがSTONITHデバイスと通信できるようにされます。

STONITHリソースはその他のリソースと同様にして設定できます。これらの操作の詳細については、使用しているクラスタ管理ツールに応じて次のいずれかを参照してください。

Hawk2: 7.5.6項「STONITHリソースの追加」
crmsh: 8.4.4項「STONITHリソースの作成」

パラメータ(属性)のリストは、それぞれのSTONITHの種類に依存します。特定のデバイスのパラメータ一覧を表示するには、stonithコマンドを実行します。

stonith -t stonith-device-type -n

たとえば、ibmhmcデバイスタイプのパラメータを表示するには、次のように入力します。

stonith -t ibmhmc -n

デバイスの簡易ヘルプテキストを表示するには、-hオプションを使用します。

stonith -t stonith-device-type -h

10.3.1 STONITHリソースの設定例 #

以降では、crmコマンドラインツールの構文で作成された設定例を紹介します。これを適用するには、サンプルをテキストファイル(sample.txtなど)に格納して、実行します。

root # crm < sample.txt

crmコマンドラインツールでのリソースの設定については、第8章「クラスタリソースの設定と管理(コマンドライン)」を参照してください。

例 10.1: IBM RSAライトアウトデバイスの設定 #

IBM RSAライトアウトデバイスは、次のようにして設定できます。

configure
primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
params nodename=alice ip_address=192.168.0.101 \
username=USERNAME password=PASSW0RD
primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
params nodename=bob ip_address=192.168.0.102 \
username=USERNAME password=PASSW0RD
location l-st-alice st-ibmrsa-1 -inf: alice
location l-st-bob st-ibmrsa-2 -inf: bob
commit

この例では、location制約が使用されていますが、それは、STONITH操作が常に一定の確率で失敗するためです。したがって、(実行側でもあるノード上の) STONITH操作は信頼できません。ノードがリセットされていない場合、フェンシング操作結果について通知を送信できません。これを実行する方法は、操作が成功すると仮定して事前に通知を送信するほかありません。ただし操作が失敗した場合、問題が発生することがあります。したがって、規則によってstonithdはホストの終了を拒否します。

例 10.2: 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 have 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製品ラインでサポートされているものです。

例 10.3: kdumpデバイスの設定 #

Kdumpは特殊なフェンシングデバイスに属し、実際にはフェンシングデバイスとは正反対のものです。このプラグインは、ノードでカーネルダンプが進行中かどうかをチェックします。進行中であればtrueを返し、ノードがフェンシングされたかのように動作します。

Kdumpプラグインは、別の実際のSTONITHデバイスと共に使用する必要があります(たとえば、external/ipmiなど)。フェンシングメカニズムが正常に機能するには、実際のSTONITHデバイスがトリガされる前にKdumpをチェックするよう指定する必要があります。次の手順で示すように、crm configure fencing_topologyを使用して、フェンシングデバイスの順序を指定してください。

kdump機能を有効にしたノードをすべて監視するには、stonith:fence_kdumpリソースエージェント(パッケージfence-agentsで提供)を使用します。構成の例については、以下のリソースを参照してください。

configure
  primitive st-kdump stonith:fence_kdump \
    params nodename="alice "\ 1
    pcmk_host_check="static-list" \
    pcmk_reboot_action="off" \
    pcmk_monitor_action="metadata" \
    pcmk_reboot_retries="1" \
    timeout="60"
commit

1	監視されるノードの名前。複数のノードを監視する必要がある場合は、追加のSTONITHリソースを設定します。特定のノードでフェンシングデバイスを使用しないようにするには、場所に対する制約を追加します。

フェンシングのアクションは、リソースのタイムアウトが経過すると始まります。

各ノード上の/etc/sysconfig/kdumpで、kdumpプロセスが完了したときにすべてのノードに通知が送信されるようにKDUMP_POSTSCRIPTを設定します。次に例を示します。
```
/usr/lib/fence_kdump_send -i INTERVAL -p PORT -c 1 alice bob charlie [...]
```
kdumpが完了すると、kdumpを実行するノードが自動的に再起動します。
ネットワークが有効化されたfence_kdump_sendライブラリに関する指定を含む、新しいinitrdを記述します。-fオプションを使用して既存のファイルを上書きし、次回のブートプロセスでその新規ファイルが使用されるようにします。
```
root # dracut -f -a kdump
```
fence_kdumpリソース用のポートをファイアウォールで開きます。デフォルトポートは7410です。
実際のフェンシングメカニズム(external/ipmiなど)をトリガする前にKdumpがチェックされるようにするため、次のような設定を使用します。
```
fencing_topology \
  alice: kdump-node1 ipmi-node1 \
  bob: kdump-node2 ipmi-node2
```
fencing_topologyの詳細:
```
crm configure help fencing_topology
```

10.4 フェンシングデバイスの監視 #

他のリソースと同様に、STONITHクラスのエージェントは、ステータスのチェックのための監視操作もサポートします。

注記: STONITHリソースの監視

STONITHリソースの監視は定期的に行われますが、頻繁ではありません。ほとんどのデバイスでは、少なくとも1800秒(30分)の監視間隔があれば十分です。

フェンシングデバイスはHAクラスタの不可欠な要素ですが、使用する必要が少ないほど好都合です。ブロードキャストトラフィックが多すぎると、しばしば、電源管理装置が影響を受けます。1分間に10本程度の接続しか処理できないデバイスもあります。2つのクライアントが同時に接続しようとすると、混乱するデバイスもあります。大部分は、同時に複数のセッションを処理できません。

したがって、通常、フェンシングデバイスのステータスは数時間ごとにチェックすれば十分です。フェンシング操作の実行が必要となり、電源スイッチが故障する可能性は小さいものです。

監視操作の設定方法の詳細については、8.4.9項「リソース監視の設定」を参照してください(コマンドラインアプローチについて説明されている)。

10.5 特殊なフェンシングデバイス #

実際のSTONITHデバイスを操作するプラグインに加えて、特殊目的のSTONITHプラグインも存在します。

警告: テスト目的のみ

次に示すSTONITHプラグインの一部は、デモとテストだけを目的としています。次のデバイスは、現実のシナリオでは使用しないでください。使用すると、データが損なわれたり、予測できない結果が生じることがあります。

external/ssh
ssh

fence_kdump

このプラグインは、ノードでカーネルダンプが進行中かどうかをチェックします。進行中であればtrueを返し、ノードがフェンシングされたかのように動作します。いずれにせよ、ダンプ中には、ノードはどのリソースも実行できません。これによって、すでにダウンしているがダンプ中(これは時間がかかります)であるノードのフェンシングを避けることができます。このプラグインは、別の実際のSTONITHデバイスとともに使用する必要があります。

設定の詳細については、例10.3「kdumpデバイスの設定」を参照してください。

external/sbd

これは自己フェンシングデバイスです。共有ディスクに挿入されることがある、いわゆる「ポイズンピル」に反応します。共有ストレージ接続が失われた場合、このデバイスはノードの動作を停止します。このSTONITHエージェントを使用してストレージベースのフェンシングを実装する方法については、第11章、手順11.7「SBDを使用するようにクラスタを設定する」を参照してください。詳細については、https://github.com/ClusterLabs/sbdも参照してください。

重要: `external/sbd`およびDRBD

external/sbdフェンシングメカニズムは、SBDパーティションが各ノードから直接読み取れることを要求します。そのため、SBDパーティションではDRBD*デバイスを使用してはなりません。

ただし、SBDパーティションが階層配置または複製されていない共有ディスク上にある場合には、DRBDクラスタでフェンシングメカニズムを使用することはできます。

external/ssh

別のソフトウェアベースの「フェンシング」メカニズムです。ノードは、rootとして、パスワードなしでお互いにログインできる必要があります。このメカニズムは、1つのパラメータhostlistをとり、ターゲットにするノードを指定します。これは、本当に障害のあるノードをリセットすることはできないので、実際のクラスタには使用しないでください。これは、テストとデモの目的にのみ使用します。これを共有ストレージに使用すると、データが破損します。

meatware

meatwareではユーザが操作を支援する必要があります。起動すると、meatwareはノードのコンソールに表示されるCRIT重大度メッセージを記録します。その場合、オペレータはノードがダウンしていることを確認して、meatclient(8)コマンドを発行します。これによりmeatwareは、クラスタに対して、そのノードが機能しなくなっていることを伝えます。詳細については、/usr/share/doc/packages/cluster-glue/README.meatwareを参照してください。

suicide

これはソフトウェアのみのデバイスで、rebootコマンドを使用して実行しているノードを再起動できます。これにはノードのオペレーティングシステムによる操作が必要で、特定の状況では失敗することがあります。したがって、このデバイスの使用は、極力避けてください。ただし、1ノードクラスタで使用する場合は安全です。

ディスクレスSBD

この設定は、共有ストレージなしのフェンシングメカニズムが必要なときに便利です。このディスクレスモードでは、SBDは共有デバイスに頼らず、ハードウェアウォッチドッグを使用してノードをフェンスします。ただし、ディスクレスSBDは2ノードクラスタ用のスプリットブレインシナリオには対応できません。そのため、ディスクレスSBDを使用するには、3以上のノードが必要です。

suicideは、「自分のホストを停止させない」というルールに対する唯一の例外です。

10.7 詳細 #

/usr/share/doc/packages/cluster-glue

インストールしたシステムのこのディレクトリには、多数のSTONITHプラグインおよびデバイスのREADMEファイルが格納されています。

http://clusterlabs.org/pacemaker/doc/crm_fencing.html

STONITHに関する情報です。

http://www.clusterlabs.org/doc/

『Pacemakerの説明』: Pacemakerの設定に必要なコンセプトを説明します。包括的で詳しい参照用情報です。

http://techthoughts.typepad.com/managing_computers/2007/10/split-brain-quo.html

HAクラスタでのスプリットブレイン、クォーラム、フェンシングのコンセプトを説明する記事。

このページを印刷

管理ガイド

10 フェンシングとSTONITH #

概要#

10.1 フェンシングのクラス #

10.2 ノードレベルのフェンシング #

10.2.1 STONITHデバイス #

10.2.2 STONITHの実装 #

10.3 STONITHのリソースと環境設定 #

10.3.1 STONITHリソースの設定例 #

例 10.1: IBM RSAライトアウトデバイスの設定 #

例 10.2: UPSフェンシングデバイスの設定 #

例 10.3: kdumpデバイスの設定 #

10.4 フェンシングデバイスの監視 #

注記: STONITHリソースの監視

10.5 特殊なフェンシングデバイス #

警告: テスト目的のみ

重要: external/sbdおよびDRBD

10.6 基本的な推奨事項 #

10.7 詳細 #

重要: `external/sbd`およびDRBD