Red Hat Summit5.7. ノードのクラッシュによる ASCS インスタンスの障害 (ENSA2)
3 ノードの ENSA 2 クラスター環境の場合、任意のインスタンスのフェイルオーバーイベント中に 3 番目のノードが考慮されます。
テストの前提条件
-
ASCSおよびERSのリソースグループが実行されている 3 ノードの SAP S/4HANA クラスター。 - 3 番目のノードはすべてのファイルシステムにアクセスでき、最初の 2 つのノードと同じ方法で、必要なインスタンス固有の IP アドレスをプロビジョニングできます。
このセットアップ例では、基礎となる共有
NFSファイルシステムは次のとおりです。Node List: * Online: [ node1 node2 node3 ] Active Resources: * s4r9g2_fence (stonith:fence_rhevm): Started node1 * Clone Set: s4h_fs_sapmnt-clone [fs_sapmnt]: * Started: [ node1 node2 node3 ] * Clone Set: s4h_fs_sap_trans-clone [fs_sap_trans]: * Started: [ node1 node2 node3 ] * Clone Set: s4h_fs_sap_SYS-clone [fs_sap_SYS]: * Started: [ node1 node2 node3 ] * Resource Group: S4H_ASCS20_group: * S4H_lvm_ascs20 (ocf:heartbeat:LVM-activate): Started node1 * S4H_fs_ascs20 (ocf:heartbeat:Filesystem): Started node1 * S4H_vip_ascs20 (ocf:heartbeat:IPaddr2): Started node1 * S4H_ascs20 (ocf:heartbeat:SAPInstance): Started node1 * Resource Group: S4H_ERS29_group: * S4H_lvm_ers29 (ocf:heartbeat:LVM-activate): Started node2 * S4H_fs_ers29 (ocf:heartbeat:Filesystem): Started node2 * S4H_vip_ers29 (ocf:heartbeat:IPaddr2): Started node2 * S4H_ers29 (ocf:heartbeat:SAPInstance): Started node2- リソースおよびリソースグループのすべての障害がクリアされ、failcount がリセットされている。
-
テストの手順
-
ASCSが実行されているノードをクラッシュします。
-
モニタリング
テスト中に、
ASCSグループが現在実行されていないノードの 1 つで、別のターミナルから次のコマンドを実行します。[root@node2]# watch -n 1 pcs status
予想される動作
-
ASCSは、3 番目のノードに移動します。 -
ERSは、すでに実行されているのと同じノード上で引き続き実行されます。
-
テスト
ASCSグループが現在実行されているノードをクラッシュさせます。[root@node1]# echo c > /proc/sysrq-trigger
ASCSは、2 番目のノードですでに実行されているERSインスタンスを妨げることなく、3 番目のノードに移動します。[root@node2]# pcs status | egrep -e "S4H_ascs20|S4H_ers29" * S4H_ascs20 (ocf:heartbeat:SAPInstance): Started node3 * S4H_ers29 (ocf:heartbeat:SAPInstance): Started node2
復元の手順
失敗したアクションがあればクリーンアップします。
[root@node2]# pcs resource cleanup
