目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availability Extensionのドキュメント / 管理ガイド / 設定および管理 / フェンシングとSTONITH
適用項目 SUSE Linux Enterprise High Availability Extension 15 SP4

10 フェンシングとSTONITH

 

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

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

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

10.1 フェンシングのクラス

 

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

リソースレベルのフェンシング

リソースレベルのフェンシングにより、特定のリソースへの排他的アクセスが保証されます。この一般的な例として、SANファイバチャネルスイッチからのノードのゾーニングの変更(つまり、ノードのディスクへのアクセスのロックアウト)や、SCSI予約などの方法が挙げられます。例については、 11.10項 「ストレージ保護のための追加メカニズム」を参照してください。

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

ノードレベルのフェンシングにより、障害が発生したノードから共有リソースに完全にアクセスできなくなります。このことは通常、そのノードをリセットする、または電源オフにするというような、極端な手段で行われます。

A tree showing the different types and features of fencing
図 10.1: フェンシングのクラス
 

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)は急速に広まっており、既製コンピュータの標準装備になる可能性さえあります。ただし、電源をホスト(クラスタノード)と共有するため、これらはUPSデバイスに内蔵されています。ノードに電力が供給されないままでは、それを制御するデバイスも役に立ちません。その場合は、CRMがノードのフェンシングの試行を無限に継続し、他のすべてのリソース操作はフェンシング/STONITH操作の完了を待機することになります。

テストデバイス

テストデバイスは、テスト専用に使用されます。通常、ハードウェアにあまり負担をかけないようになっています。クラスタが運用に使用される前に、実際のフェンシングデバイスに交換される必要があります。

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

10.2.2 STONITHの実装

 

SUSE® Linux Enterprise High Availability Extensionでの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プロトコルを実装し、このプロトコルをサポートする任意のデバイスを制御できます。

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

 

フェンシングをセットアップするには、1つまたは複数のSTONITHリソースを設定する必要があります。pacemaker-fencedデーモンでは設定は不要です。すべての設定はCIBに保存されます。STONITHリソースはクラスstonithのリソースです(6.3.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

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操作は信頼できません。ノードがリセットされていない場合、フェンシング操作結果について通知を送信できません。これを実行する方法は、操作が成功すると仮定して事前に通知を送信するほかありません。ただし操作が失敗した場合、問題が発生することがあります。したがって、規則によってpacemaker-fencedはホストの終了を拒否します。

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

例 10.3: kdumpデバイスの設定
 

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

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

  1. 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リソースを設定します。特定のノードでフェンシングデバイスを使用しないようにするには、場所に対する制約を追加します。

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

  2. 各ノード上の/etc/sysconfig/kdumpで、kdumpプロセスが完了したときにすべてのノードに通知が送信されるようにKDUMP_POSTSCRIPTを設定します。例: 

    /usr/lib/fence_kdump_send -i INTERVAL -p PORT -c 1 alice bob charlie [...]

    kdumpが完了すると、kdumpを実行するノードが自動的に再起動します。

  3. ネットワークが有効化されたfence_kdump_sendライブラリに関する指定を含む、新しいinitrdを記述します。-fオプションを使用して既存のファイルを上書きし、次回のブートプロセスでその新規ファイルが使用されるようにします。 

    root # dracut -f -a kdump

  4. fence_kdumpリソース用のポートをファイアウォールで開きます。デフォルトポートは7410です。

  5. 実際のフェンシングメカニズム(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.3.9項 「リソース監視の設定」を参照してください(コマンドラインアプローチについて説明されている)。

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

 

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

警告
警告: テスト専用

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

  • external/ssh

  • ssh

fence_kdump

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

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

external/sbd

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

重要
重要: 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は、「自分のホストを停止させない」というルールに対する唯一の例外です。

10.6 基本的な推奨事項

 

次の推奨事項のリストをチェックして、よく発生する間違いを避けてください。

  • 複数の電源スイッチを並列に接続しないでください。

  • STONITHデバイスとその設定をテストする際には、各ノードからプラグを1回抜いて、ノードのフェンシングが起こらないことを検証してください。

  • リソースのテストは負荷のかかった状態で行って、タイムアウト値が適切であるかどうかを検証してください。タイムアウト値が短すぎると、(不必要な)フェンシング操作がトリガされることがあります。詳細については、6.3.9項 「タイムアウト値」を参照してください。

  • セットアップでは適切なフェンシングデバイスを使用してください。詳細については、10.5項 「特殊なフェンシングデバイス」も参照してください。

  • 1つ以上のSTONITHリソースを設定します。デフォルトでは、グローバルクラスタオプションのstonith-enabledはtrueに設定されています。STONITHリソースが定義されていない場合、クラスタはどのリソースも開始することを拒否します。STONITHリソースが定義されていない場合、クラスタはどのリソースを開始することも拒否します。

  • グローバルクラスタオプションstonith-enabledをfalseに設定しないでください。これは、次の理由によります。

    • STONITHが有効でないクラスタはサポートされていません。

    • DLM/OCFS2は、決して発生しないフェンシング操作を待機して、永久にブロックし続けます。

  • グローバルクラスタオプションstartup-fencingをfalseに設定しないでください。デフォルトでは、これは次の理由でtrueに設定されています。クラスタの起動時に、あるノードが不明な状態になっていると、そのノードは、ステータスが明らかにされるまでフェンシングされます。

10.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/pacemaker/doc/

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

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

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