Red Hat Enterprise Linux High Availability Add-On クラスタにおける SAP HANA active/active (read enabled) システムレプリケーションの構成
次の情報では、 SAP HANA Active-Active (Read Enabled) System Replicationを管理するための Red Hat Enterprise Linux (RHEL) High Availability Add-Onクラスタの構成について説明します。 クラスタは IBM® Power® Virtual Server をクラスタノードとして使用します。
Active/Active(読み取り有効) 構成では、 SAP HANA システム・レプリケーションにより、セカンダリ・システム上のデータベース・コンテンツへの読み取りアクセスが許可されます。
この情報は、 SAP HANA on Power Virtual Server の高可用性配備を計画しているアーキテクトやスペシャリストを対象としています。
開始前に
IBM Power Virtual Server リファレンスでの SAP アプリケーションの高可用性の実装」 に記載されている一般要件、製品ドキュメント、サポート記事、および SAP ノートを確認してください。
前提条件
- Power Virtual Server の2つの仮想サーバー・インスタンスに、 Red Hat High Availability クラスターがデプロイされています。
- Red Hat Enterprise Linux High Availability Add-On クラスタの実装 」に従って、RHEL HA Add-On クラスタをインストールしてセットアップします。
- 前述の文書に記載されているように、フェンシングを設定し、検証する。
- 仮想サーバーインスタンスは、 SAP HANA システムのハードウェア要件とリソース要件を満たす必要がある。 配置を計画する 」のガイドラインに従ってください。
- 仮想サーバーインスタンスのホスト名は、 SAP HANA の要件を満たす必要があります。
- SAP HANA が両方の仮想サーバーインスタンスにインストールされ、 System Replication が設定されている。 SAP HANA SAP HANA のインストールと SAP HANA System Replication のセットアップは、 Power Virtual Server 環境に特有なものではないので、標準的な手順に従う必要がある。
アクティブ/アクティブ(リード有効)シナリオの設定
Active/Active(読み取り有効)システム・レプリケーション・シナリオは、 Red Hat Enterprise Linux High Availability Add-Onクラスタでの SAP HANA スケールアップ・システム・レプリケーションの構成で 説明されているセットアップの拡張です。
次の手順に進む前に、本番システム・システム・レプリケーション・クラスターのセットアップを完了してください。
システムのレプリケーション動作モードをActive/Active(読み取り可能)に変更する
セカンダリ・インスタンスを実行しているノードで、以下のコマンドを実行してオペレーション・モードを変更する。
- クラスタをメンテナンスモードにする。
pcs property set maintenance-mode=true
- セカンダリ SAP HANA インスタンスを停止する。
sudo -i -u ${sid}adm -- \ HDB stop
- システムのレプリケーション操作モードを変更する。
sudo -i -u ${sid}adm -- \ hdbnsutil -sr_changeOperationMode --mode=logreplay_readaccess
- セカンダリ SAP HANA インスタンスを起動する。
sudo -i -u ${sid}adm -- \ HDB start
- クラスタをメンテナンスモードから削除します。
pcs property set maintenance-mode=false
Active/Active(読み取り有効)シナリオ用のクラスタリソースの設定
以下の情報を使用して、Active/Active(読み取り有効)シナリオに必要な追加のクラスタ・リソースを構成します。
セカンダリ仮想IPアドレスリソースの作成
仮想IPアドレスの予約 」の情報を確認し、セカンダリ用の仮想IPアドレスを予約します。
予約IPアドレスを使用して仮想IPアドレスリソースを作成する。 この仮想IPアドレスにより、クライアントはセカンダリHANAインスタンスに接続し、読み取り専用のクエリーを実行できる。
クラスタ・ノードで、予約済みIPアドレスを VIP_SECONDARY 環境変数に割り当て、以下のコマンドを実行して仮想IPアドレス・クラスタ・リソースを作成します。
export VIP_SECONDARY=<reserved IP address for SAP HANA secondary>
echo $VIP_SECONDARY
pcs resource create vip_s_${SID}_${INSTNO} IPaddr2 ip=$VIP_SECONDARY
設定されている仮想IPアドレスとクラスタの状態を確認します。
pcs resource config vip_s_${SID}_${INSTNO}
pcs status --full
セカンダリ仮想IPアドレスのロケーション制約の作成
クラスタ制約を作成して、セカンダリ仮想IPアドレスがセカンダリ・インスタンスを実行しているクラスタ・ノードに配置されるようにします。
クラスタ・ノードで以下のコマンドを実行する。
pcs constraint location vip_s_${SID}_${INSTNO} rule \
score=INFINITY hana_${sid}_sync_state eq SOK \
and hana_${sid}_roles eq 4:S:master1:master:worker:master
pcs constraint location vip_s_${SID}_${INSTNO} rule \
score=2000 hana_${sid}_sync_state eq PRIM \
and hana_${sid}_roles eq 4:P:master1:master:worker:master
これらのロケーション制約は、2つ目の仮想IPリソースに対して以下の動作を確立する:
- SAP HANA プライマリと SAP HANA セカンダリの両方が利用可能で、 SAP HANA システムのレプリケーション状態が
SOK
の場合、セカンダリ仮想IPアドレスは SAP HANA セカンダリがアクティブなノードに割り当てられる。 - SAP HANA セカンダリノードが利用できない場合、または SAP HANA システムのレプリケーション状態が
SOK
でない場合、セカンダリ仮想 IP は SAP HANA プライマリがアクティブなノードに割り当てられる。 SAP HANA セカンダリが利用可能になり、 SAP HANA システムのレプリケーション状態が再びSOK
、2番目の仮想IPアドレスは SAP HANA セカンダリがアクティブなノードに戻る。 - SAP HANA プライマリ、またはそれが稼働しているノードが利用できなくなった場合、 SAP HANA セカンダリがプライマリの役割を引き継ぐ。 もう一方のノードが SAP HANA セカンダリ・ロールに変わり、 SAP HANA システム・レプリケーションの状態が
SOK
に戻るまで、2つ目のバーチャルIPはノード上に残る。
この動作は、セカンダリ仮想IPリソースが、 SAP HANA インスタンスが正常に動作しているノードに割り当てられる時間を最大化する。
Active/Active(読み取り有効)シナリオのクラスタ構成が完了しました。
クラスター構成の確認
クラスタ・ノード上で、以下のコマンドを実行してクラスタ・リソースのステータスを確認します。
pcs status --full
出力例:
# pcs status --full
Cluster name: H4S_cluster
Cluster Summary:
* Stack: corosync
* Current DC: cl-h4s-1 (1) (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
* Last updated: Mon Jul 31 11:46:11 2023
* Last change: Mon Jul 31 11:44:34 2023 by root via crm_attribute on cl-h4s-1
* 2 nodes configured
* 7 resource instances configured
Node List:
* Online: [ cl-h4s-1 (1) cl-h4s-2 (2) ]
Full List of Resources:
* res_fence_ibm_powervs (stonith:fence_ibm_powervs): Started cl-h4s-1
* vip_H4S_00_primary (ocf::heartbeat:IPaddr2): Started cl-h4s-1
* Clone Set: SAPHanaTopology_H4S_00-clone [SAPHanaTopology_H4S_00]:
* SAPHanaTopology_H4S_00 (ocf::heartbeat:SAPHanaTopology): Started cl-h4s-2
* SAPHanaTopology_H4S_00 (ocf::heartbeat:SAPHanaTopology): Started cl-h4s-1
* Clone Set: SAPHana_H4S_00-clone [SAPHana_H4S_00] (promotable):
* SAPHana_H4S_00 (ocf::heartbeat:SAPHana): Slave cl-h4s-2
* SAPHana_H4S_00 (ocf::heartbeat:SAPHana): Master cl-h4s-1
* vip_s_H4S_00 (ocf::heartbeat:IPaddr2): Started cl-h4s-2
Node Attributes:
* Node: cl-h4s-1 (1):
* hana_h4s_clone_state : PROMOTED
* hana_h4s_op_mode : logreplay_readaccess
* hana_h4s_remoteHost : cl-h4s-2
* hana_h4s_roles : 4:P:master1:master:worker:master
* hana_h4s_site : SiteA
* hana_h4s_srmode : syncmem
* hana_h4s_sync_state : PRIM
* hana_h4s_version : 2.00.070.00.1679989823
* hana_h4s_vhost : cl-h4s-1
* lpa_h4s_lpt : 1690796675
* master-SAPHana_H4S_00 : 150
* Node: cl-h4s-2 (2):
* hana_h4s_clone_state : DEMOTED
* hana_h4s_op_mode : logreplay_readaccess
* hana_h4s_remoteHost : cl-h4s-1
* hana_h4s_roles : 4:S:master1:master:worker:master
* hana_h4s_site : SiteB
* hana_h4s_srmode : syncmem
* hana_h4s_sync_state : SOK
* hana_h4s_version : 2.00.070.00.1679989823
* hana_h4s_vhost : cl-h4s-2
* lpa_h4s_lpt : 30
* master-SAPHana_H4S_00 : 100
Migration Summary:
Tickets:
PCSD Status:
cl-h4s-1: Online
cl-h4s-2: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
クラスタ・ノードで以下のコマンドを実行して、定義された制約をチェックします。
pcs constraint --full
出力例:
# pcs constraint --full
Location Constraints:
Resource: vip_s_H4S_00
Constraint: location-vip_s_H4S_00
Rule: boolean-op=and score=INFINITY (id:location-vip_s_H4S_00-rule)
Expression: hana_h4s_sync_state eq SOK (id:location-vip_s_H4S_00-rule-expr)
Expression: hana_h4s_roles eq 4:S:master1:master:worker:master (id:location-vip_s_H4S_00-rule-expr-1)
Constraint: location-vip_s_H4S_00-1
Rule: boolean-op=and score=2000 (id:location-vip_s_H4S_00-1-rule)
Expression: hana_h4s_sync_state eq PRIM (id:location-vip_s_H4S_00-1-rule-expr)
Expression: hana_h4s_roles eq 4:P:master1:master:worker:master (id:location-vip_s_H4S_00-1-rule-expr-1)
Ordering Constraints:
promote SAPHana_H4S_00-clone then start vip_H4S_00_primary (kind:Mandatory) (id:order-SAPHana_H4S_00-clone-vip_H4S_00_primary-mandatory)
start SAPHanaTopology_H4S_00-clone then start SAPHana_H4S_00-clone (kind:Mandatory) (non-symmetrical) (id:order-SAPHanaTopology_H4S_00-clone-SAPHana_H4S_00-clone-mandatory)
Colocation Constraints:
vip_H4S_00_primary with SAPHana_H4S_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Master) (id:colocation-vip_H4S_00_primary-SAPHana_H4S_00-clone-2000)
Ticket Constraints:
読み取り可能なセカンダリ SAP HANA インスタンスへのアクセスをチェックする
セカンダリ・システムへの接続には、 SAP HANA システム・レプリケーション Active/Active(読み取り有効)を使用すると、全体的なパフォーマンスが向上します。 読み取り可能なセカンダリHANAインスタンスにアクセスするには、2つの接続方法が利用可能です:
-
明示的な読み取り専用接続 アプリケーションは、セカンダリHANAインスタンスへの明示的な接続を開きます。
-
ヒントベースのステートメントルーティング アプリケーション、例えば SAP S/4HANA は、プライマリHANAインスタンスへの接続を開きます。 この接続では、システム・レプリケーション固有のヒントを持つSQL文がまず準備され、次に実行される。 実行中、SQL文は自動的にセカンダリ・システムにルーティングされ、そこで処理される。 ヒントの詳細については、 『 SAP HANA SQL and System Views Reference Guide 』を参照してください。
以下の2つの環境変数を、 SAP HANA プライマリとセカンダリの仮想IPアドレスに設定する。
export VIP_PRIMARY=<virtual IP address of SAP HANA primary>
export VIP_SECONDARY=<virtual IP address of SAP HANA secondary>
以下の2つのセクションのコマンドは、 SAP HANA SYSTEM
ユーザーのパスワードの入力を求める。 コマンド出力には、SQL文を実行した SAP HANA システムのホスト名とIPアドレスが表示されます。
明示的な読み取り専用接続によるアクセスチェック
明示的な読み取り専用接続を使用して、セカンダリ・インスタンスへの接続を検証する。
クラスタ・ノードで以下のコマンドを実行する。
sudo -i -u ${sid}adm -- \
hdbsql -n $VIP_SECONDARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
"select * from m_host_information \
where key = 'net_hostnames' or key = 'net_ip_addresses'"
サンプル出力は、ステートメントが SAP HANA セカンダリで実行されたことを示している。
HOST,KEY,VALUE
"cl-h4s-2","net_hostnames","cl-h4s-2"
"cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211"
2 rows selected (overall time 7518 usec; server time 291 usec)
ヒント・ベースのステートメント・ルーティングを使用したアクセス・チェック
ヒント・ベースのステートメント・ルーティングを使用して、セカンダリ・インスタンスへの接続を確認する。
-
SQL ヒントなしで SAP HANA プライマリに明示的に接続し、接続テストを実行する。
クラスタ・ノードで以下のコマンドを実行する。
sudo -i -u ${sid}adm -- \ hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \ "select * from m_host_information \ where key = 'net_hostnames' or key = 'net_ip_addresses'"
サンプル出力は、ステートメントが SAP HANA プライマリで実行されたことを示している。
HOST,KEY,VALUE "cl-h4s-1","net_hostnames","cl-h4s-1" "cl-h4s-1","net_ip_addresses","10.40.10.162,10.40.10.201" 2 rows selected (overall time 5239 usec; server time 361 usec)
-
SAP HANA プライマリへの明示的な接続と
result_lag
SQL ヒントを使用して、接続テストを実行する。sudo -i -u ${sid}adm -- \ hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \ "select * from m_host_information \ where key = 'net_hostnames' or key = 'net_ip_addresses' \ with hint(result_lag('hana_sr'))"
サンプル出力は、ステートメントが SAP HANA セカンダリで実行されたことを示している。
HOST,KEY,VALUE "cl-h4s-2","net_hostnames","cl-h4s-2" "cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211" 2 rows selected (overall time 40.722 msec; server time 16.428 msec)
セカンダリーインスタンスの自動登録を可能にする
AUTOMATED_REGISTER
、運用要件に応じてパラメータを設定する必要があります。 以前のプライマリ・インスタンス( SAP HANA )の状態に戻す機能を維持したい場合は、 AUTOMATED_REGISTER=false
、以前のプライマリを新しいセカンダリとして自動登録することを避ける。
クラスタによって引き起こされたテイクオーバー後にデータに問題が発生した場合、 AUTOMATED_REGISTER
が false
に設定されていれば、手動で元に戻すことができます。
AUTOMATED_REGISTER
が true
に設定されている場合、以前のプライマリ SAP HANA インスタンスは自動的にセカンダリとして登録され、以前の履歴でアクティブにすることはできない。 設定 AUTOMATED_REGISTER=true
の利点は、障害が発生したノードがクラスタに再登場した後、高可用性が自動的に再確立されることです。
当面は、クラスタが完全にテストされ、フェイルオーバー・シナリオが期待どおりに動作することが確認されるまで、 AUTOMATED_REGISTER
をデフォルト値 false
のままにしておくことをお勧めします。
pcs resource update
コマンドはリソース属性を変更するために使用され、 pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true
は属性を true
に設定する。
SAP HANA システム・レプリケーション・クラスターのテスト
クラスタが正しく動作していることを確認するために、クラスタ構成を徹底的にテストすることが重要です。 以下の情報は、フェイルオーバー・テスト・シナリオのサンプルをいくつか示していますが、テスト・シナリオの完全なリストではありません。
例えば、各テストケースの説明には以下の情報が含まれる。
- テストされるコンポーネント
- 試験内容
- フェイルオーバー・テストを開始する前の前提条件とクラスタの状態
- 試験手順
- 期待される行動と結果
- リカバリー手順
Test1- プライマリデータベースインスタンスのテスト失敗
以下の情報を使用して、プライマリ・データベース・インスタンスの障害をテストする。
Test1- 説明
NODE1 で稼動しているプライマリ SAP HANA データベースインスタンスのクラッシュをシミュレートする。
Test1- 前提条件
- SAP HANA システム・レプリケーション用の機能的な2ノードRHEL HAアドオン・クラスター。
- 両方のクラスタノードがアクティブである。
- NODE1 と NODE2 で開始されるクラスタ。
AUTOMATED_REGISTER=false
で設定されているクラスタリソースSAPHana_${SID}_${INSTNO}
。- SAP HANA システムレプリケーションのステータスを確認する:
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- SAP HANA システム・レプリケーションが起動し、同期している
Test1- 試験手順
${sid}adm
ユーザーがSIGKILLシグナルを送ることによって、 SAP HANA プライマリーをクラッシュさせる。
NODE1 で、以下のコマンドを実行する。
sudo -i -u ${sid}adm -- HDB kill-9
Test1- 期待される行動
- SAP HANA NODE1、プライマリ・インスタンスがクラッシュした。
- クラスタは停止したプライマリ SAP HANA データベースを検出し、リソースを
failed
としてマークします。 - クラスタは、 NODE2 上のセカンダリ SAP HANA データベースを新しいプライマリとして引き継ぐように昇格させます。
- クラスタは NODE1 上の仮想IPアドレスを解放し、 NODE2 上の新しいプライマリでそれを取得します。
- 引き継ぎ後、セカンダリ SAP HANA インスタンスは利用できなくなり、セカンダリ仮想IPアドレスは NODE2 に残ります。
- SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。
Test1- 回復手順
クラスタ・リソース SAPHana_${SID}_${INSTNO}
は AUTOMATED_REGISTER=false
で構成されているため、クラスタは障害の発生した SAP HANA データベースを再起動せず、新しいプライマリに対して登録しません。 つまり、新しいプライマリ( NODE2 )のステータスも、セカンダリのステータスを「CONNECTION TIMEOUT」と表示している。
以前のプライマリを新しいセカンダリとして再登録するには、以下のコマンドを使用する。
NODE1 で、以下のコマンドを実行する。
sudo -i -u ${sid}adm -- \
hdbnsutil -sr_register \
--name=${DC1} \
--remoteHost=${NODE2} \
--remoteInstance=00 \
--replicationMode=sync \
--operationMode=logreplay_readaccess \
--online
システムのレプリケーションステータスを確認する:
sudo -i -u ${sid}adm -- \
hdbnsutil -sr_state
クラスタ・ノード上で、以下のコマンドを実行してクラスタ・リソースをリフレッシュします。 このコマンドはセカンダリ・インスタンスを起動します。
pcs resource refresh SAPHana_${SID}_${INSTNO}
セカンダリが同期状態(SOK
)になると、セカンダリの仮想IPアドレスは NODE1 に移動する。
クラスタ・ノード上で、以下のコマンドを実行してクラスタの状態を確認します。
pcs status --full
Test2- プライマリデータベースを実行しているノードのテスト障害
以下の情報を使用して、プライマリ・データベースを実行しているノードの障害をテストする。
Test2- 説明
プライマリ SAP HANA データベースを実行しているノードのクラッシュをシミュレートする。
Test2- 準備
クラスタリソース SAPHana_${SID}_${INSTNO}
が AUTOMATED_REGISTER=true
で構成されていることを確認してください。
NODE1 で、以下のコマンドを実行する。
pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true
リソース・コンフィギュレーションの AUTOMATED_REGISTER
。
pcs resource config SAPHana_${SID}_${INSTNO} | grep Attributes
Test2- 前提条件
- SAP HANA システム・レプリケーション用の機能的な2ノードRHEL HAアドオン・クラスター。
- 両ノードともアクティブだ。
- クラスターは NODE1 と NODE2 で起動する。
- SAP HANA システムレプリケーションのステータスを確認する。
- プライマリ SAP HANA データベースは NODE2
- セカンダリ SAP HANA データベースは NODE1
- SAP HANA システム・レプリケーションが起動し、同期している
- セカンダリ仮想IPアドレスは NODE1
Test2- 試験手順
NODE2、 クラッシュシステムリクエストを送信してプライマリをクラッシュさせる。
NODE2 で、以下のコマンドを実行する。
sync; echo c > /proc/sysrq-trigger
Test2- 期待される行動
- NODE2 をシャットダウンする。
- クラスタは故障したノードを検出し、その状態を
OFFLINE
に設定します。 - クラスタは、 NODE1 上のセカンダリ SAP HANA データベースを新しいプライマリとして引き継ぐように昇格させます。
- クラスタは新しいプライマリ上の NODE1、仮想IPアドレスを取得します。
- 引き継ぎ後、セカンダリ SAP HANA インスタンスは利用できなくなり、セカンダリ仮想IPアドレスは NODE1 に残ります。
- SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。
Test2- 回復手順
IBM Cloud® コンソールにログインし、 NODE2 インスタンスを起動する。 NODE2 が再び利用可能になるまで待ってから、クラスター・フレームワークを再起動する。
NODE2 で、以下のコマンドを実行する。
pcs cluster start
pcs status --full
クラスタリソース SAPHana_${SID}_${INSTNO}
は AUTOMATED_REGISTER=true
と共に構成されているため、 NODE2 がクラスタに再参加し、以前のプライマリがセカンダリとして再登録されると、 SAP HANA が再起動する。 セカンダリが同期状態(
SOK
)になると、セカンダリの仮想IPアドレスは NODE2 に移動する。
Test3- セカンダリー・データベース・インスタンスの障害テスト
以下の情報を使用して、セカンダリ・データベース・インスタンスの障害をテストする。
Test3- 説明
セカンダリ SAP HANA データベースのクラッシュをシミュレートする。
Test3- 前提条件
- SAP HANA システム・レプリケーション用の機能的な2ノードRHEL HAアドオン・クラスター。
- 両ノードともアクティブだ。
- クラスターは NODE1 と NODE2 で起動する。
- クラスタリソース
SAPHana_${SID}_${INSTNO}
はAUTOMATED_REGISTER=true
で設定されている。 - SAP HANA システムレプリケーションのステータスを確認する:
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- SAP HANA システム・レプリケーションが起動し、同期している
- セカンダリ仮想IPアドレスは NODE2
Test3- 試験手順
${sid}adm
ユーザーがSIGKILLシグナルを送ることによって、 SAP HANA セカンダリーをクラッシュさせる。
NODE2 で、以下のコマンドを実行する。
sudo -i -u ${sid}adm -- HDB kill-9
Test3- 期待される行動
- SAP HANA NODE2 クラッシュに関する二次的なもの。
- クラスタは停止したセカンダリ SAP HANA データベースを検出し、リソースを
failed
としてマークします。 - クラスタはセカンダリ仮想IPアドレスを NODE1 に移動します。
- クラスタはセカンダリ SAP HANA データベースを再起動します。
- クラスターはシステムのレプリケーションが再び同期したことを検出する。
- クラスタはセカンダリ仮想IPアドレスを NODE2 に戻します。
Test3- 回復手順
セカンダリ SAP HANA インスタンスが起動し、再び同期するまで待ち(SOK
)、 pcs status
に示すように、失敗したリソースアクションをクリーンアップする。
クラスタ・ノードで以下のコマンドを実行する。
pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full
Test4- SAPHanaリソースの別のノードへの手動移動のテスト
以下の情報を使用して、SAPHanaリソースの別のノードへの手動移動をテストします。
Test4- 説明
クラスタコマンドを使用して、メンテナンス目的でプライマリインスタンスを別のノードに移動します。
Test4- 前提条件
- SAP HANA システム・レプリケーション用の機能的な2ノードRHEL HAアドオン・クラスター。
- 両ノードともアクティブだ。
- クラスターは NODE1 と NODE2 で起動する。
- クラスタリソース
SAPHana_${SID}_${INSTNO}
はAUTOMATED_REGISTER=true
で設定されている。 - SAP HANA システムレプリケーションのステータスを確認する:
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- SAP HANA システム・レプリケーションが起動し、同期している
- セカンダリ仮想IPアドレスは NODE2
Test4- 試験手順
pcs resource move
コマンドを使用して、 SAP HANA プライマリを他のノードに移動する。
クラスタ・ノードで以下のコマンドを実行する。
pcs resource move SAPHana_${SID}_${INSTNO}-clone
出力例:
# pcs resource move SAPHana_H4S_00-clone
Warning: Creating location constraint 'cli-ban-SAPHana_H4S_00-clone-on-cl-hdb-1' with a score of -INFINITY for resource SAPHana_H4S_00-clone on cl-hdb-1.
This will prevent SAPHana_H4S_00-clone from running on cl-hdb-1 until the constraint is removed
This will be the case even if cl-hdb-1 is the last node in the cluster
Test4- 期待される行動
- クラスターはリソースを移動させるための位置制約を作成する。
- クラスタはセカンダリ SAP HANA データベースへのテイクオーバーをトリガする。
- セカンダリ仮想IPアドレスは NODE2。
- SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。
Test4- 回復手順
将来的に自動フェイルオーバーを可能にするには、自動的に作成されたロケーション制約を削除する必要がある。
プライマリ SAP HANA インスタンスがアクティブになるまで待ち、制約を削除する。
クラスタ・ノードで以下のコマンドを実行する。
pcs constraint
pcs resource clear SAPHana_${SID}_${INSTNO}-clone
pcs constraint
クラスタは、 SAP HANA データベースを新しいセカンダリ・インスタンスとして登録し、起動します。 システムのレプリケーションステータスが再び同期された後(
SOK
)、クラスタはセカンダリ仮想IPアドレスを NODE1 に移動します。
pcs status --full