5.6. ノードのクラッシュによる ERS インスタンスの障害
ERS
インスタンスが同じノードで再起動されることを確認します。
テストの前提条件
両方のクラスターノードが稼働しており、
ASCS
とERS
のリソースグループが実行されています。[root@node1]# pcs status | egrep -e "S4H_ascs20|S4H_ers29" * S4H_ascs20 (ocf:heartbeat:SAPInstance): Started node1 * S4H_ers29 (ocf:heartbeat:SAPInstance): Started node2
- リソースおよびリソースグループのすべての障害がクリアされ、failcount がリセットされている。
テストの手順
-
ERS
が実行されているノードをクラッシュします。
-
モニタリング
テスト中に、他のノードの別のターミナルで次のコマンドを実行します。
[root@nod1]# watch -n 1 pcs status
予想される動作
-
ERS
が実行されているノードがクラッシュし、設定に従ってシャットダウンまたは再起動します。 -
その間、
ASCS
は、他のノードに対して実行を続けます。ERS
は、クラッシュしたノードがオンラインに戻った後、そのノード上で再起動します。
-
テスト
ERS
が実行されているノードで、root ユーザーとして次のコマンドを実行します。[root@node2]# echo c > /proc/sysrq-trigger
ERS
は、テスト中にASCS
インスタンスを妨げることなく、クラッシュしたノードがオンラインに戻った後、そのノード上で再起動します。[root@node1]# pcs status | egrep -e "S4H_ascs20|S4H_ers29" * S4H_ascs20 (ocf:heartbeat:SAPInstance): Started node1 * S4H_ers29 (ocf:heartbeat:SAPInstance): Started node2
復元の手順
失敗したアクションがあればクリーンアップします。
[root@node2]# pcs resource cleanup