SBD (STONITH Block Device)は、共有ブロックストレージ(SAN、iSCSI、FCoEなど)を介したメッセージの交換を通じて、Pacemakerベースのクラスタのノードフェンシングメカニズムを提供します。これにより、フェンシングメカニズムが、ファームウェアバージョンの変更や特定のファームウェアコントローラへの依存から切り離されます。動作異常のノードが本当に停止したかどうかを確認するために、各ノードではウォッチドッグが必要です。特定の条件下では、ディスクレスモードで実行することにより、共有ストレージなしでSBDを使用することもできます。
ha-cluster-bootstrap スクリプトは、フェンシングメカニズムとしてSBDを使用するオプションを用いて、クラスタを設定する自動化された方法を提供します。詳細については、『インストールおよびセットアップクイックスタート』を参照してください。ただし、SBDを手動で設定する場合、個々の設定に関するオプションが増えます。
この章では、SBDの背後にある概念について説明します。スプリットブレインシナリオの場合に潜在的なデータ破損からクラスタを保護するために、SBDが必要とするコンポーネントを設定する手順を説明します。
ノードレベルのフェンシングに加えて、LVM2排他アクティブ化やOCFS2ファイルロックのサポート(リソースレベルのフェンシング)など、ストレージ保護のための追加のメカニズムを使用することができます。これにより、管理上またはアプリケーション上の障害からシステムが保護されます。
SBDは、「Storage-Based Death」または「STONITHブロックデバイス」の略語です。
High Availabilityクラスタスタックの最優先事項は、データの整合性を保護することです。これは、データストレージへの非協調的な同時アクセスを防止することによって実現されます。クラスタスタックは、複数の制御メカニズムを使用してこの処理を行います。
ただし、ネットワークのパーティション分割やソフトウェアの誤動作により、クラスタでいくつものDCが選択される状況となる可能性があります。このいわゆるスプリットブレインシナリオが発生した場合は、データが破損することがあります。
STONITHによるノードフェンシングは、これを防ぐためのプライマリメカニズムです。ノードフェンシングメカニズムとしてSBDを使用することは、スプリットブレインシナリオの場合に、外部電源オフデバイスを使用せずにノードをシャットダウンする1つの方法です。
すべてのノードが共有ストレージへのアクセスを持つ環境で、デバイスの小さなパーティションをSBDで使用できるようにフォーマットします。パーティションのサイズは、使用されるディスクのブロックサイズによって異なります(たとえば、512バイトのブロックサイズの標準SCSIディスクには1MB、4KBブロックサイズのDASDディスクには4MB必要です)。初期化プロセスでは、最大255のノードに対するスロットを備えたデバイス上にメッセージレイアウトが作成されます。
SBDは、そのデーモンの設定後、クラスタスタックの他のコンポーネントが起動される前に各ノードでオンラインになります。SBDデーモンは、他のすべてのクラスタコンポーネントがシャットダウンされた後で終了されます。したがって、クラスタリソースがSBDの監督なしでアクティブになることはありません。
このデーモンは、自動的に、パーティション上のメッセージスロットの1つを自分自身に割り当て、自分へのメッセージがないかどうか、そのスロットを絶えず監視します。デーモンは、メッセージを受信すると、ただちに要求に従います(フェンシングのための電源切断や再起動サイクルの開始など)。
また、デーモンは、ストレージデバイスへの接続性を絶えず監視し、パーティションが到達不能になった場合は、デーモン自体が終了します。このため、デーモンがフェンシングメッセージから切断されることはありません。これは、クラスタデータが別のパーティション上の同じ論理ユニットにある場合、追加障害ポイントになることはありません。ストレージ接続を失えば、ワークロードは終了します。
SBDを使用する場合は常に、正常動作するウォッチドッグが不可欠です。近代的なシステムは、ソフトウェアコンポーネントによって「チックル」または「フィード」される必要のあるhardware watchdogをサポートします。ソフトウェアコンポーネント(この場合、SBDデーモン)は、ウォッチドッグにサービスパルスを定期的に書き込むことによって、ウォッチドッグに「フィード」します。デーモンがウォッチドッグへのフィードを停止すると、ハードウェアでシステムが強制的に再起動されます。この機能は、SBDプロセス自体の障害(I/Oエラーで終了またはスタックするなど)に対する保護を提供します。
Pacemaker統合が有効になっている場合、デバイスの過半数が失われてもSBDはセルフフェンスを行いません。たとえば、クラスタにA、B、Cの3つのノードが含まれており、ネットワーク分割によってAには自分自身しか表示できず、BとCはまだ通信可能な状態であるとします。この場合、2つのクラスタパーティションが存在し、1つは過半数(B、C)であるためにクォーラムがあり、もう1つにはクォーラムがない(A)ことになります。過半数のフェンシングデバイスに到達できないときにこれが発生した場合、ノードAはすぐに自らダウンしますが、BとCは引き続き実行されます。
手動でストレージベースのフェンシングを設定するには、次の手順に従う必要があります。 これらはroot
として実行する必要があります。開始する前に、11.3項 「要件」を確認してください。
シナリオに応じて、1~3台のデバイスとともにまたはディスクレスモードでSBDを使用してください。概要については、11.4項 「SBDデバイスの数」を参照してください。詳細な設定については、以下に記載されています。
ストレージベースのフェンシングには、最大3つのSBDデバイスを使用できます。1~3台のデバイスを使用する場合、共有ストレージにすべてのノードからアクセス可能である必要があります。
共有ストレージデバイスのパスが永続的で、クラスタ内のすべてのノードで一致している必要があります。/dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345
などの固定デバイス名を使用してください。
共有ストレージはFC (ファイバチャネル)、FCoE (Fibre Channel over Ethernet)、またはiSCSI経由で接続できます。仮想化環境では、ハイパーバイザーは共有ブロックデバイスを提供する場合があります。どの場合にも、共有ブロックデバイス上のコンテンツがすべてのクラスタノードに対して一貫性がある必要があります。キャッシュによってその一貫性が損なわれないようにしてください。
共有ストレージセグメントが、ホストベースのRAID、LVM2、またはDRBD*を「使用してはなりません」。DRBDは分割できますが、SBDでは2つの状態が存在することはできないため、これはSBDにとって問題になります。クラスタマルチデバイス(クラスタMD)は、SBDには使用できません。
ただし、信頼性向上のため、ストレージベースのRAIDとマルチパスの使用は推奨されます。
255を超えるノードでデバイスを共有しない限り、異なるクラスタ間でSBDデバイスを共有できます。
3つ以上のノードがあるクラスタの場合は、SBDをディスクレスモードで使用することもできます。
SBDは、最大3つのデバイスの使用をサポートしています。
最も単純な実装です。すべてのデータが同じ共有ストレージ上にあるクラスタに適しています。
この設定は、主に、ホストベースのミラーリングを使用しているものの3つ目のストレージデバイスが使用できない環境で役立ちます。1つのミラーログにアクセスできなくなっても、SBDは終了せず、クラスタは引き続き実行できます。ただし、SBDにはストレージの非同期分割を検出できるだけの情報が与えられていないので、ミラーログが1つだけ使用可能なときにもう一方をフェンスすることはありません。つまり、ストレージアレイのいずれかがダウンしたときに、2つ目の障害に自動的に耐えることはできません。
最も信頼性の高い設定です。障害または保守による1台のデバイスの機能停止から回復できます。複数のデバイスが失われた場合、およびクラスタパーティションまたはノードの状態に応じて必要な場合にのみ、SBD自体が終了します。少なくとも2つのデバイスにまだアクセス可能な場合は、フェンシングメッセージを正常に送信できます。
この設定は、ストレージが1つのアレイに制約されていない、比較的複雑なシナリオに適しています。ホストベースのミラーリングソリューションでは、1つのミラーログに1つのSBDを設定し(自分自身はミラーしない)、iSCSI上に追加のタイブレーカを設定できます。
この設定は、共有ストレージなしのフェンシングメカニズムが必要なときに便利です。このディスクレスモードでは、SBDは共有デバイスに頼らず、ハードウェアウォッチドッグを使用してノードをフェンスします。ただし、ディスクレスSBDは2ノードクラスタ用のスプリットブレインシナリオには対応できません。そのため、ディスクレスSBDを使用するには、3以上のノードが必要です。
フェンシングメカニズムとしてSBDを使用する場合、すべてのコンポーネントのタイムアウトを考慮することが重要です。それらのコンポーネントが相互に依存するためです。
このタイムアウトは、SBDデバイスの初期化中に設定されます。これは主にストレージのレイテンシに依存します。この時間内に大半のデバイスを正常に読み込む必要があります。それができない場合、そのノードでセルフフェンスを行うことがあります。
マルチパスセットアップまたはiSCSI上にSBDデバイスがある場合、パスの障害を検出して次のパスに切り替えるのに必要な時間に、タイムアウトを設定する必要があります。
またこれは、/etc/multipath.conf
でmax_polling_interval
の値がウォッチドッグ
のタイムアウト未満でなければならないことを意味します。
msgwait
タイムアウトこのタイムアウトは、SBDデバイスの初期化中に設定されます。この時間が経過するとSBDデバイス上のノードのスロットに書き込まれたメッセージが配信されたとみなされる時間を定義します。タイムアウトは、ノードでセルフフェンスを行う必要があることを検出するのに十分な長さでなければなりません。
ただし、msgwait
タイムアウトが比較的長い場合、フェンシングアクションが戻る前にフェンスされたクラスタノードが再加入することがあります。これは、SBD設定の SBD_DELAY_START
パラメータを設定することで軽減できます(手順 11.4のステップ 4で説明)。
stonith-timeout
このタイムアウトは、グローバルクラスタプロパティとしてCIBで設定されます。これは、STONITHアクション(再起動、オン、オフ)が完了するのを待つ時間の長さを定義します。
stonith-watchdog-timeout
このタイムアウトは、グローバルクラスタプロパティとしてCIBで設定されます。明示的に設定されていない場合は、デフォルトで0
に設定されます。これは1~3台のデバイスとともにSBDを使用するのに適しています。ディスクレスモードでSBDを使用する方法の詳細については、手順11.8「ディスクレスSBDの設定」を参照してください。
ウォッチドッグのタイムアウトを変更する場合は、他の2つのタイムアウトも調整する必要があります。次の「式」は、これら3つの値の関係を示しています。
Timeout (msgwait) >= (Timeout (watchdog) * 2) stonith-timeout = Timeout (msgwait) + 20%
たとえば、ウォッチドッグのタイムアウトを120
に設定した場合、msgwait
タイムアウトを240
に設定し、stonith-timeout
を288
に設定します。
ha-cluster-bootstrap スクリプトを使用してクラスタを設定し、SBDデバイスを初期化する場合、これらのタイムアウト間の関係が自動的に考慮されます。
SUSE Linux Enterprise High Availability Extensionには、ハードウェア固有のウォッチドッグドライバを提供する、いくつかのカーネルモジュールが付属しています。最もよく使用されるカーネルモジュールのリストについては、よく使用されるウォッチドッグドライバを参照してください。
運用環境のクラスタでは、ハードウェア固有のウォッチドッグドライバを使用することをお勧めします。ただし、ハードウェアに適合するウォッチドッグがない場合、カーネルウォッチドッグモジュールとしてsoftdog
を使用することができます。
High Availability Extensionはウォッチドッグに「フィード」するソフトウェアコンポーネントとしてSBDデーモンを使用します。
特定のシステムの正しいウォッチドッグカーネルモジュールを判断することは、容易ではありません。自動プロービングは頻繁に失敗します。その結果、正しいモジュールがロードされる前に、多くのモジュールがすでにロードされている状態になってしまいます。
表 11.1は、最もよく使用されるウォッチドッグドライバのリストです。お使いのハードウェアがそこに記載されていない場合、ディレクトリ/lib/modules/KERNEL_VERSION/kernel/drivers/watchdog
も選択肢のリストとして用意されています。または、ハードウェアベンダーに名前を問い合わせてください。
Hardware (ハードウェア) | ドライバ |
---|---|
HP | hpwdt |
Dell、Supermicro、Lenovo | iTCO_wdt |
Fujitsu | ipmi_watchdog |
IBMメインフレーム上のz/VMのVM | vmwatchdog |
Xen VM (DomU) | xen_wdt |
Generic | softdog |
一部のハードウェアベンダーは、システムのリセット用にウォッチドッグを使用するシステム管理ソフトウェアを提供しています(たとえば、HP ASRデーモンなど)。ウォッチドッグがSBDで使用されている場合は、このようなソフトウェアを無効にします。他のソフトウェアは、ウォッチドッグタイマにアクセスしないでください。
正しいウォッチドッグモジュールがロードされていることを確認するには、次の手順を実行します。
お使いのカーネルバージョンでインストールされているドライバをリストします。
root #
rpm
-ql kernel-VERSION |grep
watchdog
カーネルに現在ロードされているウォッチドッグモジュールをリストします。
root #
lsmod
|egrep
"(wd|dog)"
結果が表示されたら、間違ったモジュールをアンロードします。
root #
rmmod
WRONG_MODULE
お使いのハードウェアに適合するウォッチドッグモジュールを有効にします。
root #
echo
WATCHDOG_MODULE > /etc/modules-load.d/watchdog.confroot #
systemctl
restart systemd-modules-load
ウォッチドッグモジュールが正しくロードされているかどうかをテストします。
root #
lsmod
|egrep
"(wd|dog)"
運用環境のクラスタでは、ハードウェア固有のウォッチドッグドライバを使用することをお勧めします。ただし、ハードウェアに適合するウォッチドッグがない場合、カーネルウォッチドッグモジュールとしてsoftdog
を使用することができます。
softdogドライバはCPUが最低1つは動作中であることを前提とします。すべてのCPUが固まっている場合、システムを再起動させるsoftdogドライバのコードは実行されません。これに対して、ハードウェアウォッチドッグはすべてのCPUが固まっていても動作し続けます。
softdogドライバを有効にします。
root #
echo
softdog > /etc/modules-load.d/watchdog.conf
/etc/modules-load.d/watchdog.conf
にsoftdog
モジュールを追加し、サービスを再起動します。
root #
echo
softdog > /etc/modules-load.d/watchdog.confroot #
systemctl
restart systemd-modules-load
softdogウォッチドッグモジュールが正しくロードされているかどうかをテストします。
root #
lsmod
|grep
softdog
セットアップには次の手順が必要です。
開始する前に、SBDに使用するブロックデバイスが、11.3項で指定された要件を満たしていることを確認してください。
SBDデバイスを設定するときは、いくつかのタイムアウト値を考慮する必要があります。 詳細については、11.5項 「タイムアウトの計算」を参照してください。
ノード上で実行しているSBDデーモンがウォッチドッグタイマを十分な速さで更新していない場合、ノード自体が終了します。タイムアウトを設定したら、個別の環境でテストしてください。
共有ストレージでSBDを使用するには、まず1~3台のブロックデバイス上でメッセージングレイアウトを作成する必要があります。sbd create
コマンドは、指定された1つまたは複数のデバイスにメタデータヘッダを書き込みます。また、最大255ノードのメッセージングスロットを初期化します。追加のオプションを指定せずに実行する場合、このコマンドはデフォルトのタイムアウト設定を使用します。
SBD用に使用するデバイスには、重要なデータが一切ないようにしてください。sbd create
コマンドを実行すると、指定されたブロックデバイスの最初のメガバイトが、さらなる要求やバックアップなしに上書きされます。
SBDに使用するブロックデバイスを決定します。
次のコマンドで、SBDデバイスを初期化します。
root #
sbd
-d /dev/SBD create
(/dev/SBD
を実際のパス名で置き換えます。たとえば/dev/disk/by-id/scsi-ST2000DM001-0123456_Wabcdefg
です)。
SBDに複数のデバイスを使用するには、-d
オプションを複数回指定します。たとえば、次のようになります。
root #
sbd
-d /dev/SBD1 -d /dev/SBD2 -d /dev/SBD3 create
SBDデバイスがマルチパスグループにある場合は、-1
と-4
オプションを使用して、SBDに使用するタイムアウトを調整します。詳細については、11.5項 「タイムアウトの計算」を参照してください。タイムアウトはすべて秒単位で指定します。
root #
sbd
-d /dev/SBD -4 1801 -1 602 create
デバイスに書き込まれた内容を確認します。
root #
sbd
-d /dev/SBD dump Header version : 2.1 UUID : 619127f4-0e06-434c-84a0-ea82036e144c Number of slots : 255 Sector size : 512 Timeout (watchdog) : 60 Timeout (allocate) : 2 Timeout (loop) : 1 Timeout (msgwait) : 180 ==Header on disk /dev/SBD is dumped
ご覧のように、タイムアウトがヘッダにも保存され、それらに関するすべての参加ノードの合意が確保されます。
SBDデバイスを初期化したら、SBD設定ファイルを編集し、次にそれぞれのサービスを有効にして起動し、変更を有効にします。
ファイル/etc/sysconfig/sbd
を開きます。
次のパラメータを検索します。 SBD_DEVICE
SBDメッセージを交換するために監視および使用するデバイスを指定します。
SBDをお使いのSBDデバイスに置き換えて、この行を編集します。
SBD_DEVICE="/dev/SBD"
1行目で複数のデバイスを指定する必要がある場合は、セミコロンで区切って指定します(デバイスの順序は任意で構いません)。
SBD_DEVICE="/dev/SBD1; /dev/SBD2; /dev/SBD3"
SBDデバイスがアクセス不能な場合は、SBDデーモンが開始できなくなり、クラスタの起動を抑止します。
次のパラメータを検索します。 SBD_DELAY_START.
遅延を有効または無効にします。 SBD_DELAY_START
をyes
に設定します(msgwait
が比較的長い場合)。ただし、クラスタノードは非常に高速に起動します。 このパラメータをyes
に設定すると、ブート時にSBDの起動が遅れます。これは、仮想マシンで必要となることがあります。
SBDデバイスをSBD設定ファイルに追加したら、SBDデーモンを有効にします。SBDデーモンは、クラスタスタックの不可欠なコンポーネントです。これは、クラスタスタックが実行されているときに、実行されている必要があります。したがって、sbd
サービスは、pacemaker
サービスが開始されるたびに依存関係として開始されます。
各ノードで、SBDサービスを有効にします。
root #
systemctl
enable sbd
これは、Pacemakerサービスが開始されるたびに、Corosyncサービスと一緒に開始されます。
各ノードでクラスタスタックを再起動します。
root #
systemctl
stop pacemakerroot #
systemctl
start pacemaker
これによって、自動的にSBDデーモンの開始がトリガされます。
次の手順として、手順 11.6の説明に従ってSBDデバイスをテストします。
次のコマンドを使用すると、ノードスロットとそれらの現在のメッセージがSBDデバイスからダンプされます。
root #
sbd
-d /dev/SBD list
ここでSBDを使用して起動したすべてのクラスタノードが表示されます。たとえば、2ノードクラスタを使用している場合、両方のノードのメッセージスロットにはclear
と表示されます。
0 alice clear 1 bob clear
ノードの1つにテストメッセージを送信してみます。
root #
sbd
-d /dev/SBD message alice test
ノードがシステムログファイルにメッセージの受信を記録します。
May 03 16:08:31 alice sbd[66139]: /dev/SBD: notice: servant: Received command test from bob on disk /dev/SBD
これによって、SBDがノード上で実際に機能し、メッセージを受信できることが確認されます。
最後のステップとして、手順 11.7の説明に従ってクラスタ設定を調整する必要があります。
クラスタでSBDの使用を設定するには、クラスタ設定で次の操作を行う必要があります。
設定に適合する値に stonith-timeout パラメータを設定します。
SBD STONITHリソースを設定します。
stonith-timeout の計算については、11.5項 「タイムアウトの計算」を参照してください。
シェルを起動し、root
または同等のものとしてログインします。
crm
configure
を実行します。
次のように入力します。
crm(live)configure#
property
stonith-enabled="true" 1crm(live)configure#
property
stonith-watchdog-timeout=0 2crm(live)configure#
property
stonith-timeout="220s" 3
2ノードクラスタの場合、予測可能な遅延を希望するか、ランダムな遅延を希望するかを決めます。他のクラスタ設定については、このパラメータを設定する必要はありません。
このパラメータはSTONITHアクションを実行する前に静的遅延を有効にします。別々のフェンシングリソースおよび異なる遅延値が使用されている場合に、ノードが互いにフェンシングしないようにします。対象ノードは「フェンシングの競合」で失われます。2ノードクラスタのスプリットブレインシナリオの場合に、このパラメータを使用して、特定のノードが存続するよう「マーク付けする」ことができます。これを正常に実行するには、各ノードに2つのプリミティブSTONITHデバイスを作成することが必須です。次の設定では、スプリットブレインシナリオの場合に、aliceが勝利して存続します。
crm(live)configure#
primitive
st-sbd-alice stonith:external/sbd params \ pcmk_host_list=alice pcmk_delay_base=20crm(live)configure#
primitive
st-sbd-bob stonith:external/sbd params \ pcmk_host_list=bob pcmk_delay_base=0
このパラメータは、SBDなどの低速デバイスを使用する場合の二重フェンシングを防止します。これは、フェンシングデバイスに対するSTONITHアクションのランダム遅延を追加します。スプリットブレインシナリオの場合、両方のノードが互いにフェンスを試みる可能性がある2ノードクラスタでは特に重要です。
crm(live)configure#
primitive
stonith_sbd stonith:external/sbd params pcmk_delay_max=30
show
で変更内容をレビューします。
commit
で変更を送信し、exit
でcrmライブ設定を終了します。
リソースの起動後、SBDを使用するためにクラスタが正常に設定されます。ノードをフェンスする必要がある場合にこの方法を使用します。
ディスクレスモードでSBDを動作させることができます。このモードでは、次の場合にウォッチドッグデバイスを使用してノードをリセットします。クォーラムが失われた場合、監視されているデーモンが失われて回復しなかった場合、またはノードでフェンシングが必要であるとPacemakerが判断した場合。ディスクレスSBDは、クラスタの状態、クォーラム、およびいくつかの合理的な前提に応じた、ノードの「セルフフェンシング」に基づいています。STONITH SBDリソースプリミティブはCIBでは必要ありません。
2ノードクラスタのフェンシングメカニズムとしてディスクレスSBDを使用しないでください。3つ以上のノードを含むクラスタでのみ使用してください。ディスクレスモードのSBDでは、2ノードクラスタのスプリットブレインシナリオを処理できません。
ファイル/etc/sysconfig/sbd
を開き、次のエントリを使用します。
SBD_PACEMAKER=yes SBD_STARTMODE=always SBD_DELAY_START=no SBD_WATCHDOG_DEV=/dev/watchdog SBD_WATCHDOG_TIMEOUT=5
共有ディスクが使用されていないので、 SBD_DEVICE
エントリは不要です。このパラメータがない場合、sbd
サービスはSBDデバイスのウォッチャプロセスを開始しません。
各ノードで、SBDサービスを有効にします。
root #
systemctl
enable sbd
これは、Pacemakerサービスが開始されるたびに、Corosyncサービスと一緒に開始されます。
各ノードでクラスタスタックを再起動します。
root #
systemctl
stop pacemakerroot #
systemctl
start pacemaker
これによって、自動的にSBDデーモンの開始がトリガされます。
パラメータ have-watchdog=true が自動的に設定されているかどうかを確認します。
root #
crm
configure show | grep have-watchdog have-watchdog=true
crm configure
を実行し、crmシェルで次のクラスタプロパティを設定します。
crm(live)configure#
property
stonith-enabled="true" 1crm(live)configure#
property
stonith-watchdog-timeout=10 2
STONITHを使用しないクラスタはサポートされていないため、これがデフォルト設定になります。ただし、テスト目的でSTONITHが無効化されている場合は、再度このパラメータが | |
ディスクレスSBDの場合、このパラメータはゼロであってはなりません。これは、どれくらいの時間が経ったらフェンシングターゲットがすでにセルフフェンスを行ったとみなされるのかを定義します。したがって、その値は、
|
show
で変更内容をレビューします。
commit
で変更を送信し、exit
でcrmライブ設定を終了します。
SBDがノードフェンシング目的で期待どおりに機能するかどうかをテストするには、次のいずれかまたはすべての方法を使用します。
ノードNODENAMEのフェンシングアクションをトリガするには:
root #
crm
node fence NODENAME
当該ノードがフェンシングされているかどうか、および stonith-watchdog-timeoutの時間が経過した後に他のノードが当該ノードをフェンシングされたとしてみなしているかどうかを確認します。
SBD inquisitorのプロセスIDを特定します。
root #
systemctl
status sbd ● sbd.service - Shared-storage based fencing daemon Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2018-04-17 15:24:51 CEST; 6 days ago Docs: man:sbd(8) Process: 1844 ExecStart=/usr/sbin/sbd $SBD_OPTS -p /var/run/sbd.pid watch (code=exited, status=0/SUCCESS) Main PID: 1859 (sbd) Tasks: 4 (limit: 4915) CGroup: /system.slice/sbd.service ├─1859 sbd: inquisitor [...]
SBD inquisitorプロセスを終了することにより、SBD障害をシミュレーションします。この例では、SBD inquisitorのプロセスIDは1859
です)。
root #
kill
-9 1859
当該ノードは積極的にセルフフェンスを行います。他のノードは、当該ノードの喪失を認識し、 stonith-watchdog-timeoutの時間経過後に当該ノードがセルフフェンスを行ったとみなします。
通常の設定では、リソース停止動作の障害によって、フェンシングがトリガされます。フェンシングを手動でトリガするために、リソース停止動作の障害を発生させることができます。あるいは、以下に説明するように、リソース監視動作の設定を一時的に変更して、監視障害を発生させることができます。
リソース監視動作のon-fail=fence
プロパティを設定します。
op monitor interval=10 on-fail=fence
監視動作の障害を発生させます(たとえば、リソースがサービスに関連する場合は、それぞれのデーモンを終了させます)。
この障害により、フェンシングアクションがトリガされます。
STONITHによるノードフェンシング以外に、リソースレベルでストレージ保護を実現する他の方法があります。たとえば、SCSI-3とSCSI-4は永続予約を使用しますが、sfex
はロック機構を提供します。両方の方法について以下のサブセクションで説明します。
SCSI仕様3および4では、「永続予約」が定義されています。これらはSCSIプロトコル機能であり、I/Oフェンシングとフェールオーバーに使用できます。この機能は、sg_persist
Linuxコマンドで実装されます。
sg_persist
のバッキングディスクは、SCSIディスクとの互換性が必要です。sg_persist
は、SCSIディスクやiSCSI LUNなどのデバイスでのみ機能します。 IDE、SATA、またはSCSIプロトコルをサポートしないブロックデバイスでは、使用しないでください。
続行する前に、お使いのディスクが永続予約をサポートしているかどうかを確認してください。次のコマンドを使用します(DISKをデバイス名で置き換えてください)。
root #
sg_persist
-n --in --read-reservation -d /dev/DISK
結果に、ディスクが永続予約をサポートしているかどうかが示されます。
サポートされているディスク:
PR generation=0x0, there is NO reservation held
サポートされていないディスク:
PR in (Read reservation): command not supported Illegal request, Invalid opcode
上記のようなエラーメッセージが表示された場合は、古いディスクをSCSIと互換性のあるディスクに交換してください。それ以外の場合は、以下の手順に従います。
プリミティブリソースsg_persist
を作成するには、root
として次のコマンドを実行します。
root #
crm
configurecrm(live)configure#
primitive
sg sg_persist \ params devs="/dev/sdc" reservation_type=3 \ op monitor interval=60 timeout=60
sg_persist
プリミティブをマスタ-スレーブグループに追加します。
crm(live)configure#
ms
ms-sg sg \ meta master-max=1 notify=true
いくつかのテストをします。リソースがマスタ/スレーブ構成のステータスにある場合、マスタインスタンスが実行されているクラスタノードでは/dev/sdc1
をマウントして書き込みを行えますが、スレーブインスタンスが実行されているクラスタノードでは書き込みが禁止されます。
Ext4のファイルシステムプリミティブを追加します。
crm(live)configure#
primitive
ext4 ocf:heartbeat:Filesystem \ params device="/dev/sdc1" directory="/mnt/ext4" fstype=ext4
sg_persist
マスタとファイルシステムリソースの間に、次の順序関係とコロケーションを追加します。
crm(live)configure#
order
o-ms-sg-before-ext4 inf: ms-sg:promote ext4:startcrm(live)configure#
colocation
col-ext4-with-sg-persist inf: ext4 ms-sg:Master
show
コマンドで、すべての変更内容を確認します。
変更をコミットします.
詳細については、sg_persist
のマニュアルページを参照してください。
sfex
を使用した排他的なストレージアクティブ化の保証 #
このセクションでは、共有ストレージへのアクセスを1つのノードに排他的にロックする低レベルの追加メカニズムであるsfex
を紹介します。ただし、sfexは、STONITHと置き換えることはできないので注意してください。sfexには共有ストレージが必要なので、上記で説明したSBDノードフェンシングメカニズムは、ストレージの別のパーティションで使用することをお勧めします。
設計上、sfexは、同時実行が必要なワークロード(OCFS2など)では使用できません。これは、従来のフェールオーバースタイルのワークロードに対する保護の層として機能します。これは、実際にはSCSI-2予約と似ていますが、もっと一般的です。
共有ストレージ環境では、ストレージの小さなパーティションが1つ以上のロックの保存用に確保されます。
ノードは、保護されたリソースを取得する前に、まず、保護ロックを取得する必要があります。順序は、Pacemakerによって強制されます。sfexコンポーネントは、Pacemakerがスプリットブレイン条件に制約されても、ロックが2回以上付与されないことを保証します。
ノードのダウンが永続的にロックをブロックせず、他のノードが続行できるように、これらのロックも定期的に更新される必要があります。
次に、sfexで使用する共有パーティションの作成方法と、CIBでsfexロック用にリソースを設定する方法を説明します。1つのsfexパーティションは任意の数のロックを保持でき、ロックごとに1KBのストレージスペースを割り当てる必要があります。デフォルトでは、sfex_init
はパーティション上にロックを1つ作成します。
sfex用の共有パーティションは、保護するデータと同じ論理ユニットにある必要があります。
共有されたsfexパーティションは、ホストベースのRAIDやDRBDを使用してはなりません。
LVM2論理ボリュームを使用することは可能です。
sfexで使用する共有パーティションを作成します。このパーティションの名前を書き留め、以降の手順の/dev/sfex
をこの名前で置き換えます。
次のコマンドでsfexメタデータを作成します。
root #
sfex_init
-n 1 /dev/sfex
メタデータが正しく作成されたかどうか検証します。
root #
sfex_stat
-i 1 /dev/sfex ; echo $?
現在、ロックがかかっていないので、このコマンドは、2
を返すはずです。
sfexロックは、CIB内のリソースを介して表現され、次のように設定されます。
crm(live)configure#
primitive
sfex_1 ocf:heartbeat:sfex \ # params device="/dev/sfex" index="1" collision_timeout="1" \ lock_timeout="70" monitor_interval="10" \ # op monitor interval="10s" timeout="30s" on-fail="fence"
sfexロックによってリソースを保護するには、保護対象のリソースとsfexリソース間の必須の順序付けと配置の制約を作成します。保護対象のリソースがfilesystem1
というIDを持つ場合は、次のようになります。
crm(live)configure#
order
order-sfex-1 inf: sfex_1 filesystem1crm(live)configure#
colocation
col-sfex-1 inf: filesystem1 sfex_1
グループ構文を使用する場合は、sfexリソースを最初のリソースとしてグループに追加します。
crm(live)configure#
group
LAMP sfex_1 filesystem1 apache ipaddr