Red Hat Enterprise Linux High Availability Add-On クラスタにおける SAP HANA スケールアップシステムレプリケーションの設定

SAP HANA Scale-Up System Replicationを管理するための Red Hat Enterprise Linux (RHEL) High Availability Add-Onクラスタの構成について説明します。クラスタは IBM® Power® Virtual Server をクラスタノードとして使用します。

この手順では、RHEL HAアドオン・クラスタ上のパフォーマンスを最適化したシナリオで、 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 のインストールとHANAシステムレプリケーションのセットアップは、 Power Virtual Server 環境に特化したものではなく、標準的な手順に従う必要があります。
SAP HANA と HA 構成用のリソースエージェントをインストールするために必要なリポジトリを有効にするには、有効な RHEL for SAP Applications または RHEL for SAP Solutions のサブスクリプションが必要です。

IBM 上の RHEL HA Add-On クラスタにおける SAP HANA システムレプリケーションの設定 Power Virtual Server

手順は、 IBM Power Virtual Server リファレンス上の SAP アプリケーションの高可用性の実装に記載されている Red Hat 製品のドキュメントと記事に基づいています。

環境変数の準備

セットアップを簡単にするため、両ノードのrootに以下の環境変数を用意する。これらの環境変数は、本情報の後のオペレーティング・システム・コマンドで使用される。

両方のノードで、以下の環境変数を設定する。

# General settings
export SID=<SID>            # SAP HANA System ID (uppercase)
export sid=<sid>            # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>      # SAP HANA instance number

# Cluster node 1
export NODE1=<HOSTNAME_1>   # Virtual server instance hostname
export DC1="Site1"          # HANA System Replication site name

# Cluster node 2
export NODE2=<HOSTNAME_2>   # Virtual server instance hostname
export DC2="Site2"          # HANA System Replication site name

# Single zone
export VIP=<IP address>     # SAP HANA System Replication cluster virtual IP address

# Multizone region
export CLOUD_REGION=<CLOUD_REGION>       # Multizone region name
export APIKEY="APIKEY or path to file"   # API Key of the IBM Cloud IAM ServiceID for the resource agent
export API_TYPE="private or public"      # Use private or public API endpoints
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1>   # Workspace 1 CRN
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2>   # Workspace 2 CRN
export POWERVSI_1=<POWERVSI_1>           # Virtual server instance 1 id
export POWERVSI_2=<POWERVSI_2>           # Virtual server instance 2 id
export SUBNET_NAME="vip-${sid}-net"      # Name which is used to define the subnet in IBM Cloud
export CIDR="CIDR of subnet"             # CIDR of the subnet containing the service IP address
export VIP="Service IP address"          # IP address in the subnet
export JUMBO="true or false"             # Enable Jumbo frames

単一ゾーン実装のための余分な環境変数の設定

仮想 IP アドレスの予約」の情報を確認し、 SAP HANA System Replication クラスター用の仮想 IP アドレスを予約します。環境変数 VIP に予約済みIPアドレスを設定する。

マルチゾーン地域実装のための追加環境変数の設定

CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? 変数を、高可用性クラスタを構成するためのパラメータを収集するセクションで説明したように設定します。 IBM Cloud IAM および IBM Power Cloud API とプライベートエンドポイントを介して通信するために、 API_TYPE 変数を private に設定します。変数 SUBNET_NAME にはサブネットの名前が入る。変数 CIDR は、サブネットの CIDR（Classless Inter-Domain Routing） 表記を <IPv4_address>/number の形式で表している。変数 VIP は、バーチャルIPアドレスリソースのIPアドレスで、サブネットの CIDR に属していなければならない。大きなMTUサイズのサブネットを有効にしたい場合は、変数 JUMBO を true に設定する。

以下は、マルチゾーン地域の実装に必要な追加環境変数の設定方法の例である。

export CLOUD_REGION="eu-de"
export IBMCLOUD_CRN_1="crn:v1:bluemix:public:power-iaas:eu-de-2:a/a1b2c3d4e5f60123456789a1b2c3d4e5:a1b2c3d4-0123-4567-89ab-a1b2c3d4e5f6::"
export IBMCLOUD_CRN_2="crn:v1:bluemix:public:power-iaas:eu-de-1:a/a1b2c3d4e5f60123456789a1b2c3d4e5:e5f6a1b2-cdef-0123-4567-a1b2c3d4e5f6::"
export POWERVSI_1="a1b2c3d4-0123-890a-f012-0123456789ab"
export POWERVSI_2="e5f6a1b2-4567-bcde-3456-cdef01234567"
export APIKEY="@/root/.apikey.json"
export API_TYPE="private"
export SUBNET_NAME="vip-mha-net"
export CIDR="10.40.11.100/30"
export VIP="10.40.11.102"
export JUMBO="true"

SAP HANA リソースエージェントのインストール

次のコマンドを実行して、 SAP HANA System Replication用のRHEL HAアドオンリソースエージェントをインストールします。

dnf install -y resource-agents-sap-hana

SAP HANA システムの起動

SAP HANA を起動し、HANAシステムレプリケーションがアクティブになっていることを確認します。詳細は 2.4 を参照。 SAP HANA システム・レプリケーション状態のチェック.

両方のノードで以下のコマンドを実行する。

sudo -i -u ${sid}adm -- HDB start

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

SAP HANA srConnectionChanged( ) フックを有効にする

SAP HANA の最近のバージョンでは、 SAP HANA が特定のイベントに対して通知を送信できるように、 フックが提供されている。詳細については、 HA/DRプロバイダーの実装を参照してください。

srConnectionChanged( ) フックは、クラスタからのアクションを必要とするHANAシステムレプリケーションの状態変化を検出するクラスタの能力を向上させます。偶発的な乗っ取りを防ぐことで、データの損失や破損を防ぐのが目的だ。

すべての SAP HANA インスタンスで srConnectionChanged( ) フックをアクティブにする

クラスターを停止する。

NODE1 で、以下のコマンドを実行する。
```
pcs cluster stop --all
```
resource-agents-sap-hana パッケージで提供されるフックスクリプトを、各HANAインスタンスの /hana/shared/myHooks ディレクトリにインストールし、必要な所有権を設定します。

両方のノードで以下のコマンドを実行する。
```
mkdir -p /hana/shared/myHooks
```
```
cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
```
```
chown -R ${sid}adm:sapsys /hana/shared/myHooks
```

各HANAノードで global.ini ファイルを更新し、フックスクリプトを有効にします。

両方のノードで以下のコマンドを実行する。

sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/provider=SAPHanaSR \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/execution_order=1 \
      -set SYSTEM/global.ini/trace/ha_dr_saphanasr=info
EOT

変更されたファイルを確認する。

両方のノードで以下のコマンドを実行する。
```
cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
```

SAP HANA OSユーザーのsudo設定を作成する。

srConnectionChanged( ) フックの実行時に ${sid}adm ユーザースクリプトがノード属性を更新できるようにするには、以下の sudo 設定が必要です。

両方のノードで以下のコマンドを実行する。

必要なsudoエイリアスとユーザー指定のファイルを作成する。

cat >> /etc/sudoers.d/20-saphana << EOT
Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SFAIL -t crm_config -s SAPHanaSR
${sid}adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL
Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty
EOT

パーミッションを調整し、構文エラーをチェックする。

chown root:root /etc/sudoers.d/20-saphana

chmod 0440 /etc/sudoers.d/20-saphana

cat /etc/sudoers.d/20-saphana

visudo -c

visudo -c コマンドで報告された問題はすべて修正しなければならない。

フックが機能することを確認する。
- 両方のHANAインスタンスを再起動し、フックスクリプトが期待通りに動作することを確認します。
- HANAインスタンスの停止など、フックをトリガーするアクションを実行します。
- フックがトレース・ファイルに何かを記録したかどうかをチェックする。
両方のノードで以下のコマンドを実行する。

HANAインスタンスを停止します。
```
sudo -i -u ${sid}adm -- HDB stop
```
HANAインスタンスを起動します。
```
sudo -i -u ${sid}adm -- HDB start
```
フックがトレース・ファイルにメッセージを記録していることを確認する。
```
sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_SAPHanaSR.*crm_attribute" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,5,17'
```
フックが機能することを確認したら、HAクラスタを再起動します。
クラスターを開始します。

NODE1 で、以下のコマンドを実行する。

クラスターを開始します。
```
pcs cluster start --all
```
クラスタの状態を確認する。
```
pcs status --full
```

一般的なクラスタ・プロパティの設定

初期テスト中および本番稼動後のリソースのフェイルオーバーを回避するには、resource-stickinessおよびmigration-thresholdパラメータに以下のデフォルト値を設定します。

デフォルトは、独自の定義値でオーバーライドするリソースには適用されないことを覚えておいてください。

NODE1 で、以下のコマンドを実行する。

pcs resource defaults update resource-stickiness=1000

pcs resource defaults update migration-threshold=5000

クローン SAPHanaTopology リソースの作成

リソースは SAPHanaTopology リソースは、各ノードの SAP HANA システムレプリケーションのステータスと構成を収集します。また、 SAP HANA インスタンスの起動、停止、監視に必要なローカル SAP HostAgent も起動および監視します。

NODE1 で、以下のコマンドを実行する。

リソースを作成する。 SAPHanaTopology リソースを作成します。

pcs resource create SAPHanaTopology_${SID}_${INSTNO} SAPHanaTopology \
    SID=${SID} InstanceNumber=${INSTNO} \
    op start timeout=600 \
    op stop timeout=300 \
    op monitor interval=10 timeout=600 \
    clone clone-max=2 clone-node-max=1 interleave=true

以下のコマンドを実行して、コンフィギュレーションとクラスタの状態を確認する。

pcs resource config SAPHanaTopology_${SID}_${INSTNO}

pcs resource config SAPHanaTopology_${SID}_${INSTNO}-clone

pcs status --full

推進可能な SAPHana リソースの作成

SAPHana リソースは、HANAシステムレプリケーションノードとして構成された2つの SAP HANA インスタンスを管理します。

NODE1 で、以下のコマンドを実行して SAPHana リソースを作成する。

pcs resource create SAPHana_${SID}_${INSTNO} SAPHana \
    SID=${SID} InstanceNumber=${INSTNO} \
    PREFER_SITE_TAKEOVER=true \
    DUPLICATE_PRIMARY_TIMEOUT=7200 \
    AUTOMATED_REGISTER=false \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Unpromoted" timeout=700 \
    op monitor interval=59 role="Promoted" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable notify=true clone-max=2 clone-node-max=1 interleave=true

コンフィギュレーションとクラスタのステータスを確認する。

pcs resource config SAPHana_${SID}_${INSTNO}

pcs status --full

仮想IPアドレス・クラスタ・リソースの作成

シナリオに応じて、以下のセクションのいずれかに進む：

クラスタノードが単一の Power Virtual Server ワークスペースで動作している場合、シングルゾーン環境で仮想IPアドレスクラスタリソースを作成する
クラスタノードが別々の Power Virtual Server ワークスペースで動作している場合、マルチゾーンリージョン環境での仮想IPアドレスクラスタリソースの作成

シングルゾーン環境での仮想IPアドレスクラスターリソースの作成

予約IPアドレスを使用して、仮想IPアドレス・クラスター・リソースを作成します。この仮想IPアドレスは、 SAP HANA システム・レプリケーションのプライマリ・インスタンスに到達するために使用されます。

以下のコマンドで仮想IPアドレス・クラスター・リソースを作成します。

pcs resource create vip_${SID}_${INSTNO} IPaddr2 ip=$VIP

設定されている仮想IPアドレスクラスターリソースとクラスターステータスを確認します。

pcs resource config vip_${SID}_${INSTNO}

pcs status --full

クラスタリソース制約の作成セクションに進みます。

マルチゾーン環境での仮想IPアドレスクラスターリソースの作成

仮想IPアドレスリソースのためのマルチゾーンRHEL HAアドオンクラスターの準備」セクションのすべての手順が完了していることを確認します。

pcs resource describe powervs-subnet コマンドを実行し、リソースエージェントのパラメータに関する情報を取得する。

NODE1 で、次のコマンドを実行して powervs-subnet クラスタ・リソースを作成します。

pcs resource create vip_${SID}_${INSTNO} powervs-subnet \
    api_key=${APIKEY} \
    api_type=${API_TYPE} \
    cidr=${CIDR} \
    ip=${VIP} \
    crn_host_map="${NODE1}:${IBMCLOUD_CRN_1};${NODE2}:${IBMCLOUD_CRN_2}" \
    vsi_host_map="${NODE1}:${POWERVSI_1};${NODE2}:${POWERVSI_2}" \
    jumbo=${JUMBO} \
    region=${CLOUD_REGION} \
    subnet_name=${SUBNET_NAME} \
    op start timeout=720 \
    op stop timeout=300 \
    op monitor interval=60 timeout=30

API_TYPE を public に設定する場合は、 proxy パラメータも指定する必要がある。

pcs resource config コマンドを実行する前に、クラスタ内の両方の仮想サーバーインスタンスのステータスが Active で、ヘルスステータスが OK であることを確認してください。

設定されている仮想IPアドレスリソースとクラスタステータスを確認します。

pcs resource config vip_${SID}_${INSTNO}

出力例:

# pcs resource config vip_MHA_00
Resource: vip_MHA_00 (class=ocf provider=heartbeat type=powervs-subnet)
  Attributes: vip_MHA_00-instance_attributes
    api_key=@/root/.apikey.json
    api_type=private
    cidr=10.40.11.100/30
    crn_host_map=cl-mha-1:crn:v1:bluemix:public:power-iaas:eu-de-2:**********************************:************************************::;cl-mha-2:crn:v1:bluemix:public:power-iaas:eu-
        de-1:**********************************:************************************::
    ip=10.40.11.102
    jumbo=true
    proxy=http://10.30.40.4:3128
    region=eu-de
    subnet_name=vip-mha-net
    vsi_host_map=cl-mha-1:************************************;cl-mha-2:************************************
  Operations:
    monitor: res_vip_MHA_00-monitor-interval-60
      interval=60
      timeout=60
    start: res_vip_MHA_00-start-interval-0s
      interval=0s
      timeout=720
    stop: res_vip_MHA_00-stop-interval-0s
      interval=0s
      timeout=300

pcs status --full

次の例は、マルチゾーン・リージョン・セットアップの SAP HANA システム・レプリケーション・クラスターの出力例です。

# pcs status --full
Cluster name: SAP_MHA
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-07-31 11:37:49 +02:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-mha-2 (2) (version 2.1.5-9.el9_2.4-a3f44794f94) - partition with quorum
  * Last updated: Wed Jul 31 11:37:50 2024
  * Last change:  Wed Jul 31 11:37:31 2024 by root via crm_attribute on cl-mha-1
  * 2 nodes configured
  * 7 resource instances configured

Node List:
  * Node cl-mha-1 (1): online, feature set 3.16.2
  * Node cl-mha-2 (2): online, feature set 3.16.2

Full List of Resources:
  * fence_node1	(stonith:fence_ibm_powervs):	 Started cl-mha-1
  * fence_node2	(stonith:fence_ibm_powervs):	 Started cl-mha-2
  * Clone Set: SAPHanaTopology_MHA_00-clone [SAPHanaTopology_MHA_00]:
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-2
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-1
  * Clone Set: SAPHana_MHA_00-clone [SAPHana_MHA_00] (promotable):
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Unpromoted cl-mha-2
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Promoted cl-mha-1
  * vip_MHA_00	(ocf:heartbeat:powervs-subnet):	 Started cl-mha-1

Node Attributes:
  * Node: cl-mha-1 (1):
    * hana_mha_clone_state            	: PROMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-2
    * hana_mha_roles                  	: 4:P:master1:master:worker:master
    * hana_mha_site                   	: SiteA
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: PRIM
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-1
    * lpa_mha_lpt                     	: 1722418651
    * master-SAPHana_MHA_00           	: 150
  * Node: cl-mha-2 (2):
    * hana_mha_clone_state            	: DEMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-1
    * hana_mha_roles                  	: 4:S:master1:master:worker:master
    * hana_mha_site                   	: SiteB
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: SOK
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-2
    * lpa_mha_lpt                     	: 30
    * master-SAPHana_MHA_00           	: 100

Migration Summary:

Tickets:

PCSD Status:
  cl-mha-1: Online
  cl-mha-2: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

クラスタリソース制約の作成セクションに進みます。

クラスタリソース制約の作成

SAPHana リソースを起動する前に、 SAPHanaTopology リソースが起動されていることを確認してください。

仮想IPアドレスは、「SAPHana」のプライマリリソースが稼働しているノード上に存在する必要があります。

SAPHana" の前に "SAPHanaTopology" を開始するリソース制約を作成する。この制約は、これらのリソースの開始順序を強制する。

NODE1 で、次のコマンドを使用して、順序制約を作成する。 SAPHanaTopology 順序制約を作成します：
```
pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \
    then SAPHana_${SID}_${INSTNO}-clone symmetrical=false
```
コンフィギュレーションをチェックする。
```
pcs constraint
```
仮想IPアドレスをプライマリにコロケートするためのリソース制約を作成する。この制約は、仮想IPアドレスリソースを、プライマリとして昇格したSAPHanaリソースにコロケーションする。

NODE1 で、以下のコマンドを実行して、仮想IPアドレスのコロケーション制約を作成します。
```
pcs constraint colocation add vip_${SID}_${INSTNO} \
    with Promoted SAPHana_${SID}_${INSTNO}-clone 2000
```
コンフィギュレーションとクラスタのステータスを確認する。
```
pcs constraint
```
出力例:
```
# pcs constraint
Location Constraints:
Ordering Constraints:
  start SAPHanaTopology_HDB_00-clone then start SAPHana_HDB_00-clone (kind:Mandatory) (non-symmetrical)
Colocation Constraints:
  vip_HDB_00 with SAPHana_HDB_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Promoted)
Ticket Constraints:
```
クラスタの状態を確認します。
```
pcs status --full
```
昇格したクラスタノードで、クラスタサービスIPアドレスがアクティブであることを確認します。
```
ip addr show
```

SAP HANA srServiceStateChanged( ) フックを有効にする（オプション）

SAP HANA には、を監視する機能が組み込まれている。 indexserver 問題が発生した場合、 SAP HANA、プロセスの停止と再起動によって自動的に回復しようとする。プロセスの停止やクラッシュ後のクリーンアップを行うには、 Linux カーネルはプロセスによって割り当てられたメモリをすべて解放しなければならない。大規模なデータベースでは、このクリーンアップに長い時間がかかることがある。この間、 SAP HANA は営業を継続し、新規顧客の依頼を受け付ける。その結果、 SAP HANA システムのレプリケーションが同期しなくなることがある。 indexserver の再起動とリカバリーが完了する前に、 SAP HANA インスタンスで別のエラーが発生した場合、データの一貫性が危険にさらされる。

srServiceStateChanged() フック用の ChkSrv.py スクリプトは、このような状況に反応し、 SAP HANA インスタンス全体を停止させることで、復旧を早めることができる。クラスタで automated failover 、セカンダリノードが健全な状態にある場合、テイクオーバー操作が開始される。そうでない場合は、ローカルでリカバリーを続けなければならないが、 SAP HANA インスタンスの強制再起動によって加速される。

SAP HANA srServiceStateChanged() フックは、 resource-agents-sap-hana バージョン 0.162.3 以降で利用可能です。

フックスクリプトは、インスタンス内のイベントを分析し、イベントの詳細にフィルタを適用し、その結果に基づいてアクションをトリガします。これは、 SAP HANA によって停止および再起動される SAP HANA indexserver プロセスと、インスタンスのシャットダウン中に停止されるプロセスとを区別する。

action_on_lost パラメーターの設定によって、フックは異なるアクションを取る：

無視: このアクションは、イベントと決定情報をログファイルに記録するだけである。
停止: このアクションは、sapcontrolコマンドを使用して SAP HANA インスタンスのグレースフルストップをトリガーする。
強制終了: このアクションは、デフォルトシグナル9でHDB kill-<signal> コマンドをトリガーする。信号を設定することができる。

stop アクションと kill アクションの両方が、 SAP HANA インスタンスの停止をもたらすが、 kill アクションの方が若干速い。

すべての SAP HANA インスタンスで srServiceStateChanged( ) フックをアクティブにする

srServiceStateChanged() フックは、 SAP HANA が両方のノードで実行されている間に追加できる。

各HANAインスタンスについて、 /hana/shared/myHooks ディレクトリに resource-agents-sap-hana パッケージで提供されるフックスクリプトをインストールし、必要な所有権を設定します。

両方のノードで以下のコマンドを実行する。
```
cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks
```
```
chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py
```

各 SAP HANA ノードの global.ini ファイルを更新し、フックスクリプトを有効にする。

両方のノードで以下のコマンドを実行する。

sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/provider=ChkSrv \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/execution_order=2 \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/action_on_lost=stop \
      -set SYSTEM/global.ini/trace/ha_dr_chksrv=info
EOT

この例では、 action_on_lost パラメーターは stop に設定されています。デフォルト設定は ignore です。オプションで、パラメータ stop_timeout （デフォルト： 20 秒）と kill_signal （デフォルト： 9 ）を設定できる。

ChkSrv.py フックを作動させる

両方のノードで以下のコマンドを実行し、HA-DRプロバイダーをリロードする。
```
sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders
```
フックがトレース・ファイルにメッセージを記録していることを確認する。

両方のノードで以下のコマンドを実行する。
```
sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_ChkSrv" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,6-'
```

セカンダリーインスタンスの自動登録が可能に

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 システム・レプリケーション・クラスターのテスト

クラスタが正しく動作していることを確認するためには、クラスタ構成を徹底的にテストすることが不可欠である。以下の情報は、フェイルオーバー・テスト・シナリオのサンプルをいくつか示していますが、テスト・シナリオの完全なリストではありません。

例えば、各テストケースの説明には以下の情報が含まれる。

テストされるコンポーネント
試験内容
フェイルオーバー・テストを開始する前の前提条件とクラスタの状態
試験手順
期待される行動と結果
リカバリー手順

テスト1 - プライマリー・データベース・インスタンスの障害テスト

以下の情報を使用して、プライマリ・データベース・インスタンスの障害をテストする。

テスト1 - 内容

NODE1 で稼働しているプライマリHANAデータベースインスタンスのクラッシュをシミュレートする。

テスト1 - 前提条件

HANAシステムレプリケーション用の機能的な2ノードRHEL HAアドオンクラスター。
両方のクラスタノードがアクティブである。
NODE1 と NODE2 で開始されるクラスタ。
AUTOMATED_REGISTER=false で設定されているクラスタリソース SAPHana_${SID}_${INSTNO}。
SAP HANA システムレプリケーションのステータスを確認する：
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- HANAシステムレプリケーションが有効化され、同期している

テスト1 - テスト手順

${sid}adm ユーザーがSIGKILLシグナルを送ることによって、 SAP HANA プライマリーをクラッシュさせる。

NODE1 で、以下のコマンドを実行する。

sudo -i -u ${sid}adm -- HDB kill-9

テスト1 - 期待される動作

SAP HANA NODE1、プライマリ・インスタンスがクラッシュした。
クラスタは停止したプライマリHANAデータベースを検出し、リソースを failed。
クラスターは、 NODE2 上のセカンダリ HANA データベースを新しいプライマリとして引き継ぐようにプロモートします。
クラスタは NODE1 上の仮想IPアドレスを解放し、 NODE2 上の新しいプライマリでそれを取得します。
SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。

テスト1 - 回復手順

クラスタリソース SAPHana_${SID}_${INSTNO} が AUTOMATED_REGISTER=false で構成されているため、クラスタは障害の発生したHANAデータベースを再起動せず、新しいプライマリに対して登録しません。つまり、新しいプライマリ（ NODE2 ）のステータスも、セカンダリのステータスを「CONNECTION TIMEOUT」と表示している。

以前のプライマリを新しいセカンダリとして再登録するには、以下のコマンドを使用する。

NODE1 で、以下のコマンドを実行する。

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay \
      --online
EOT

システムのレプリケーションステータスを確認する：

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

手動での登録とリソースのリフレッシュが終わると、新しいセカンダリ・インスタンスが再起動し、ステータスが同期済み（SOK ）に表示される。

NODE1 で、以下のコマンドを実行する。

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full

テスト2 - プライマリー・データベースが稼動しているノードの障害テスト

以下の情報を使用して、プライマリ・データベースを実行しているノードの障害をテストする。

テスト2 - 内容

プライマリHANAデータベースを実行しているノードのクラッシュをシミュレートします。

テスト2 - 準備

クラスタリソース SAPHana_${SID}_${INSTNO} が AUTOMATED_REGISTER=true で構成されていることを確認してください。

NODE1 で、以下のコマンドを実行する。

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

pcs resource config SAPHana_${SID}_${INSTNO}

テスト2 - 前提条件

HANAシステムレプリケーション用の機能的な2ノードRHEL HAアドオンクラスター。
両ノードともアクティブだ。
クラスターは NODE1 と NODE2 で起動する。
SAP HANA システムレプリケーションのステータスを確認する。
- プライマリ SAP HANA データベースは NODE2
- セカンダリ SAP HANA データベースは NODE1
- HANAシステムレプリケーションが有効化され、同期している

テスト2 - テスト手順

NODE2、 クラッシュシステムリクエストを送信してプライマリをクラッシュさせる。

NODE2 で、以下のコマンドを実行する。

sync; echo c > /proc/sysrq-trigger

テスト2 - 期待される動作

NODE2 をシャットダウンする。
クラスタは故障したノードを検出し、その状態を OFFLINE に設定します。
クラスターは、 NODE1 上のセカンダリ HANA データベースを新しいプライマリとして引き継ぐようにプロモートします。
クラスタは新しいプライマリ上の NODE1、仮想IPアドレスを取得します。
SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。

テスト2 - 回復手順

IBM Cloud® コンソールにログインし、 NODE2 インスタンスを起動する。 NODE2 が再び利用可能になるまで待ってから、クラスター・フレームワークを再起動する。

NODE2 で、以下のコマンドを実行する。

pcs cluster start

pcs status --full

クラスタリソース SAPHana_${SID}_${INSTNO} は AUTOMATED_REGISTER=true で構成されているため、 NODE2 がクラスタに再参加し、以前のプライマリがセカンダリとして再登録されると、 SAP HANA が再起動します。

テスト3 - セカンダリー・データベース・インスタンスの障害テスト

以下の情報を使用して、セカンダリ・データベース・インスタンスの障害をテストする。

テスト3 - 内容

セカンダリHANAデータベースのクラッシュをシミュレートします。

テスト3 - 前提条件

HANAシステムレプリケーション用の機能的な2ノードRHEL HAアドオンクラスター。
両ノードともアクティブだ。
クラスターは NODE1 と NODE2 で起動する。
クラスタリソース SAPHana_${SID}_${INSTNO} は AUTOMATED_REGISTER=true で設定されている。
SAP HANA システムレプリケーションのステータスを確認する：
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- HANAシステムレプリケーションが有効化され、同期している

テスト3 - テスト手順

${sid}adm ユーザーがSIGKILLシグナルを送ることによって、 SAP HANA セカンダリーをクラッシュさせる。

NODE2 で、以下のコマンドを実行する。

sudo -i -u ${sid}adm -- HDB kill-9

テスト3 - 期待される動作

SAP HANA NODE2 クラッシュに関する二次的なもの。
クラスタは停止したセカンダリHANAデータベースを検出し、リソースを failed。
クラスタはセカンダリHANAデータベースを再起動します。
クラスターはシステムのレプリケーションが再び同期したことを検出する。

テスト3 - 回復手順

セカンダリHANAインスタンスが起動し、再び同期するまで待ち（SOK ）、 pcs status に示すように、失敗したリソースアクションをクリーンアップします。

NODE2 で、以下のコマンドを実行する。

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full

テスト4 - SAPHanaリソースの別のノードへの手動移動のテスト

以下の情報を使用して、SAPHanaリソースの別のノードへの手動移動をテストします。

テスト4 - 内容

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

テスト4 - 前提条件

HANAシステムレプリケーション用の機能的な2ノードRHEL HAアドオンクラスター。
両ノードともアクティブだ。
クラスターは NODE1 と NODE2 で起動する。
クラスタリソース SAPHana_${SID}_${INSTNO} は AUTOMATED_REGISTER=true で設定されている。
SAP HANA システムレプリケーションのステータスを確認する：
- プライマリ SAP HANA データベースは NODE1
- セカンダリ SAP HANA データベースは NODE2
- HANAシステムレプリケーションが有効化され、同期している

テスト4 - テスト手順

pcs resource move コマンドを使用して、 SAP HANA プライマリを他のノードに移動する。

NODE1 で、以下のコマンドを実行する。

pcs resource move SAPHana_${SID}_${INSTNO}-clone

テスト4 - 期待される動作

クラスターはリソースを移動させるための位置制約を作成する。
クラスタはセカンダリHANAデータベースへのテイクオーバーをトリガーする。
SAP NetWeaver などのアプリケーションが SAP HANA のテナント・データベースに接続されている場合、アプリケーションは自動的に新しいプライマリに再接続する。

テスト4 - 回復手順

将来的に自動フェイルオーバーを可能にするためには、自動的に作成されたロケーション制約を削除する必要がある。

プライマリHANAインスタンスがアクティブになるまで待ち、制約を削除します。

クラスタはHANAデータベースを新しいセカンダリインスタンスとして登録し、起動します。

NODE1 で、以下のコマンドを実行する。

pcs constraint

pcs resource clear SAPHana_${SID}_${INSTNO}-clone

pcs constraint

pcs status --full

Red Hat Enterprise Linux High Availability Add-On クラスタにおける SAP HANA スケールアップ システム レプリケーションの設定

開始前に

前提条件

IBM 上の RHEL HA Add-On クラスタにおける SAP HANA システムレプリケーションの設定 Power Virtual Server

環境変数の準備

単一ゾーン実装のための余分な環境変数の設定

マルチゾーン地域実装のための追加環境変数の設定

SAP HANA リソースエージェントのインストール

SAP HANA システムの起動

SAP HANA srConnectionChanged( ) フックを有効にする

すべての SAP HANA インスタンスで srConnectionChanged( ) フックをアクティブにする

一般的なクラスタ・プロパティの設定

クローン SAPHanaTopology リソースの作成

推進可能な SAPHana リソースの作成

仮想IPアドレス・クラスタ・リソースの作成

シングルゾーン環境での仮想IPアドレスクラスターリソースの作成

マルチゾーン環境での仮想IPアドレスクラスターリソースの作成

クラスタリソース制約の作成

SAP HANA srServiceStateChanged( ) フックを有効にする（オプション）

すべての SAP HANA インスタンスで srServiceStateChanged( ) フックをアクティブにする

セカンダリーインスタンスの自動登録が可能に

SAP HANA システム・レプリケーション・クラスターのテスト

テスト1 - プライマリー・データベース・インスタンスの障害テスト

テスト1 - 内容

テスト1 - 前提条件

テスト1 - テスト手順

テスト1 - 期待される動作

テスト1 - 回復手順

テスト2 - プライマリー・データベースが稼動しているノードの障害テスト

テスト2 - 内容

テスト2 - 準備

テスト2 - 前提条件

テスト2 - テスト手順

テスト2 - 期待される動作

テスト2 - 回復手順

テスト3 - セカンダリー・データベース・インスタンスの障害テスト

テスト3 - 内容

テスト3 - 前提条件

テスト3 - テスト手順

テスト3 - 期待される動作

テスト3 - 回復手順

テスト4 - SAPHanaリソースの別のノードへの手動移動のテスト

テスト4 - 内容

テスト4 - 前提条件

テスト4 - テスト手順

テスト4 - 期待される動作

テスト4 - 回復手順

Red Hat Enterprise Linux High Availability Add-On クラスタにおける SAP HANA スケールアップシステムレプリケーションの設定