このセクションでは、 SAP-SPS_ASCS10 と SAP-SPS_ERS20 のリソース階層で、スイッチオーバーとフェイルオーバー時に期待される動作を検証するための基本的なテストを実行します。ASCS10 インスタンスのエンキューサーバプロセスが、スイッチオーバーまたはフェイルオーバー後に ERS20 インスタンスからエンキューロックテーブルを正常に回復できることをテストすることが重要です。
- SAP-SPS_ASCS10 のリソースの状態が、node-a でアクティブ、node-b で スタンバイとなっていること、および SAP-SPS_ERS20 のリソースの状態が、node-b でアクティブ、node-a でスタンバイとなっていることを確認します。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
- 以下のコマンドを実行し、node-aでASCS10、node-bでERS20のインスタンスが正常に動作していることを確認します。
[root@node-a ~]# su - spsadm -c "sapcontrol -nr 10 -function GetProcessList"
04.03.2021 20:24:12
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
msg_server, MessageServer, GREEN, Running, 2020 12 21 16:53:00, 1755:31:12, 11497
enq_server, Enqueue Server 2, GREEN, Running, 2020 12 21 16:53:00, 1755:31:12, 11498
[root@node-b ~]# su - spsadm -c "sapcontrol -nr 20 -function GetProcessList"
04.03.2021 20:24:22
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
enq_replicator, Enqueue Replicator 2, GREEN, Running, 2021 02 22 16:55:17, 243:29:05, 30028- node-a で次のコマンドを実行して、0-99のラベルが付いた100個の排他ロック (累積なし) を、エンキューサーバーが保持するロック テーブルに書き込みます。
[root@node-a ~]# su - spsadm -c "enq_admin --set_locks=100:X:DIAG::TAB:%u pf=/usr/sap/SPS/SYS/profile/SPS_ASCS10_sps-ascs"
Enqueue Server 2
2021-03-04 20:32:16; OK; 'Set Locks'; Response=41496 usec
==============================================================次のコマンドを実行して、node-a のロック テーブルにロックが正常に格納され、node-b のエンキューレプリケーションサーバーに複製されたことを確認します。
[root@node-a ~]# su - spsadm -c "sapcontrol -nr 10 -function EnqGetStatistic" | grep locks_now
locks_now: 100
[root@node-b ~]# su - spsadm -c "sapcontrol -nr 20 -function EnqGetStatistic" | grep locks_now
locks_now: 100- node-b で SAP-SPS_ASCS10 リソースを右クリックし、*In-Service…* 操作を選択して、ASCS リソース階層のスイッチオーバーを実行します。 In Service をクリックして、スイッチオーバーを開始します。スイッチオーバーが完了すると、 SAP-SPS_ASCS10 と
SAP-SPS_ERS20 の両方のリソースがnode-b でIn-Serviceになります。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
ASCS リソース階層が node-b 上で正常に In-Service になり、エンキューサーバープロセスがエンキューレプリケーションサーバープロセスからバックアップエンキューロックテーブルのコピーを取得すると、LifeKeeperは自動的に SAP-SPS_ERS20 リソースを node-a に再配置し、クラスターノード間でロックテーブルの冗長性を提供します。このプロセスの完了には数分かかる場合があります。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
- LifeKeeper が SAP-SPS_ERS20 リソースを node- a に再配置したら、次のコマンドを実行して、ASCS10 および ERS20 インスタンスがそれぞれ node-b および node- a で正常に実行されていること、両方ともステップ3で書き込んだ100個のロックをまだ保持していることを検証します。
[root@node-a ~]# su - spsadm -c "sapcontrol -nr 20 -function GetProcessList"
04.03.2021 20:58:57
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
enq_replicator, Enqueue Replicator 2, GREEN, Running, 2021 03 04 20:57:34, 0:01:23, 21967
[root@node-a ~]# su - spsadm -c "sapcontrol -nr 20 -function EnqGetStatistic" | grep locks_now
locks_now: 100
[root@node-b ~]# su - spsadm -c "sapcontrol -nr 10 -function GetProcessList"
04.03.2021 20:56:56
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
msg_server, MessageServer, GREEN, Running, 2021 03 04 20:54:47, 0:02:09, 17074
enq_server, Enqueue Server 2, GREEN, Running, 2021 03 04 20:54:47, 0:02:09, 17075
[root@node-b ~]# su - spsadm -c "sapcontrol -nr 10 -function EnqGetStatistic" | grep locks_now
locks_now: 100- 次のコマンドを実行して、node-b を強制的に再起動します。
[root@node-b ~]# echo b > /proc/sysrq-trigger
LifeKeeper が node-b の電源がオフになっていることを検出すると、LifeKeeper GUI で node-b のステータスが「Unknown」に更新されます。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
この時点で、LifeKeeper は SAP-SPS_ASCS10 リソース階層の node-a への自動フェイルオーバーを開始します。 SAP-SPS_ASCS10 と SAP-SPS_ERS20 のリソース階層は、node-b がオンラインに戻るまで、両方とも node-a で Active になります。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
node-b がオンラインに戻ると、LifeKeeper は自動的に SAP-SPS_ERS20 リソース階層をnode-b に再配置します。このプロセスが完了するまでに数分かかる場合があります。このプロセスが完了すると、 SAP-SPS_ASCS10 と SAP-SPS_ERS20 のリソース階層が、node-a と node-b でそれぞれ In-Service に戻ります。
AWS または Azure では、LifeKeeper の GUI は以下の画像のようになります。
Google Cloudでは、LifeKeeper の GUI は以下の画像のようになります。
- 手順2、3で指定した sapcontrol コマンドを再度実行し、各ノードで期待される状態を確認します。
- node-aで以下のコマンドを実行し、手順3で書き込んだロック100個を解除します。
[root@node-a ~]# su - spsadm -c "enq_admin --release_locks=100:X:DIAG::TAB:%u pf=/usr/sap/SPS/SYS/profile/SPS_ASCS10_sps-ascs"
Enqueue Server 2
2021-03-04 21:10:22; OK; 'Release Locks'; Response=36883 usec
===============================================================これで、ASCS および ERS リソース階層の基本的なスイッチオーバーとフェイルオーバー機能の検証は終了です。
このトピックへフィードバック