適用項目 SUSE Linux Enterprise High Availability 15 SP6

12 フェンシングとSTONITH #

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

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

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

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

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

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

表 12.1: フェンシングのクラス #

Classes (クラス)	Methods	オプション	例
ノードフェンシング^[a] (再起動またはシャットダウン)	リモート管理	ノード内	ILO、DRAC、IPMI
	リモート管理	外部	HMC、vCenter、EC2
	SBDおよびウォッチドッグ	ディスクベース	hpwdt、iTCO_wdt、 ipmi_wdt、softdog
	SBDおよびウォッチドッグ	ディスクレス	hpwdt、iTCO_wdt、 ipmi_wdt、softdog
I/Oフェンシング(ロックまたは予約)	ピュアロック	クラスタ内	SFEX
	ピュアロック	外部	SCSI2予約、SCSI3予約
	内蔵ロック	クラスタベース	Cluster MD、LVM (lvmlockdおよびDLM)
	内蔵ロック	クラスタ処理	MD-RAID
^[a]高可用性クラスタでは必須

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

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

12.2.1 STONITHデバイス #

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

# stonith -L

あるいは、

# crm ra list stonith

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

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

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

12.2.2 STONITHの実装 #

SUSE® Linux Enterprise High AvailabilityでのSTONITHの実装は、2つのコンポーネントで構成されています。

pacemaker-fenced

pacemaker-fencedは、ローカルプロセスまたはネットワーク経由でアクセスできるデーモンです。stonithdは、フェンシング操作に対応するコマンド(rest、power-off、power-on)を受け入れます。フェンシングデバイスのステータスチェックも行います。

pacemaker-fencedデーモンは、高可用性クラスタの各ノードで実行されます。DCノードで実行されるpacemaker-fencedインスタンスは、pacemaker-controldからフェンシング要求を受け取ります。目的のフェンシング操作を実行するのは、このインスタンスとその他のpacemaker-fencedプログラムです。

STONITHプラグイン

サポートされているフェンシングデバイスごとに、そのデバイスを制御できるSTONITHプラグインがあります。STONITHプラグインはフェンシングデバイスへのインタフェースです。cluster-glueパッケージに含まれているSTONITHプラグインは各ノードの/usr/lib64/stonith/pluginsにあります。(fence-agentsパッケージもインストールしている場合、そのパッケージに付属する各種プラグインは、/usr/sbin/fence_*にインストールされています)。すべてのSTONITHプラグインはpacemaker-fencedからは同一のものと認識されますが、フェンシングデバイスの性質を反映しているため違いがあります。

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

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

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

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

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

# stonith -t stonith-device-type -n

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

# stonith -t ibmhmc -n

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

# stonith -t stonith-device-type -h

12.3.1 STONITHリソースの設定例 #

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

# crm < sample.txt

crmコマンドラインツールでのリソースの設定については、5.5項「crmshの概要」を参照してください。

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

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

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

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

例 12.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
For Config info [-p] syntax, give each of the above parameters in order as
the -p value.
Arguments are separated by white space.
Config file [-F] syntax is the same as -p, except # at the start of a line
denotes a comment

今度は次のコマンドを使用します。

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

例 12.3: Kdumpデバイスの設定 #

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

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

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

# crm configure
crm(live)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"
crm(live)configure# commit

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

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

各ノード上の/etc/sysconfig/kdumpで、kdumpプロセスが完了したときにすべてのノードに通知が送信されるようにKDUMP_POSTSCRIPTを設定します。例:
```
KDUMP_POSTSCRIPT="/usr/lib/fence_kdump_send -i INTERVAL -p PORT -c 1 alice bob charlie"
```
kdumpが完了すると、kdumpを実行するノードが自動的に再起動します。
systemctl restart kdump.serviceまたはmkdumprdのいずれかを実行します。これらのコマンドはいずれも/etc/sysconfig/kdumpが変更されたことを検出し、ネットワーク機能を有効にした状態でライブラリfence_kdump_sendを含むinitrdを再生成します。
fence_kdumpリソース用のポートをファイアウォールで開きます。デフォルトポートは7410です。
実際のフェンシングメカニズム(external/ipmiなど)をトリガする前にKdumpがチェックされるようにするため、次のような設定を使用します。
```
crm(live)configure# fencing_topology \
  alice: kdump-node1 ipmi-node1 \
  bob: kdump-node2 ipmi-node2
```
fencing_topologyに関する詳細:
```
# crm configure help fencing_topology
```

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

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

注記: STONITHリソースの監視

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

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

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

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

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

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

警告: テスト専用

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

external/ssh
ssh

fence_kdump

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

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

external/sbd

これは自己フェンシングデバイスです。共有ディスクに挿入されることがある、いわゆる「ポイズンピル」に反応します。共有ストレージ接続が失われた場合、このデバイスはノードの動作を停止します。このSTONITHエージェントを使用してストレージベースのフェンシングを実装する方法については、第13章、手順13.7「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ノードクラスタ用のスプリットブレインシナリオには対応できません。このオプションは、3つ以上のノードを持つクラスタにのみ使用してください。

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

12.7 詳細の参照先 #

/usr/share/doc/packages/cluster-glue: インストールしたシステムのこのディレクトリには、多数のSTONITHプラグインおよびデバイスのREADMEファイルが格納されています。
https://www.clusterlabs.org/pacemaker/doc/: 『Pacemaker Explained』: Pacemakerの設定に使用されるコンセプトの説明。参照用に包括的で詳細な情報が含まれています。
https://techthoughts.typepad.com/managing_computers/2007/10/split-brain-quo.html: HAクラスタでのスプリットブレイン、クォーラム、フェンシングのコンセプトを説明する記事。

12 フェンシングとSTONITH #

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

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

12.2.1 STONITHデバイス #

12.2.2 STONITHの実装 #

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

12.3.1 STONITHリソースの設定例 #

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

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

12.6 基本的な推奨事項 #

12.7 詳細の参照先 #