明示的な読み取り専用接続によるアクセスチェック

明示的な読み取り専用接続を使用して、セカンダリ・インスタンスへの接続を検証する。

クラスタ・ノードで以下のコマンドを実行する。

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)

ヒント・ベースのステートメント・ルーティングを使用したアクセス・チェック

ヒント・ベースのステートメント・ルーティングを使用して、セカンダリ・インスタンスへの接続を確認する。

1. 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)
   

2. 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)
   

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- 説明

プライマリ 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- 説明

セカンダリ 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- 説明

クラスタコマンドを使用して、メンテナンス目的でプライマリインスタンスを別のノードに移動します。

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