IBM Cloud Docs
在 Red Hat Enterprise Linux High Availability Add-On 叢集中設定 SAP HANA 擴充系統複製

在 Red Hat Enterprise Linux High Availability Add-On 叢集中設定 SAP HANA 擴充系統複製

以下資訊說明 Red Hat Enterprise Linux (RHEL) High Availability Add-On 群集用於管理 SAP HANA Scale-Up System Replication 的組態。 群集使用 IBM® Power® Virtual Server 作為群集節點。

本說明介紹如何在 RHEL HA 附加元件群集上的效能最佳化方案中，自動執行 SAP HANA Scale-Up System Replication，以進行單一資料庫部署。

本資訊適用於規劃 SAP HANA on Power Virtual Server 高可用性部署的架構人員和專家。

開始之前

檢閱一般需求、產品文件、支援文章，以及 IBM Power Virtual Server 參考資料中為 SAP 應用程式實施高可用性 所列出的 SAP 備註。

必要條件

  • Red Hat High Availability 叢集部署在 Power Virtual Server 的兩個虛擬伺服器實體上。
  • 虛擬伺服器實體需要滿足 SAP HANA 系統範圍內的硬體和資源需求。 請遵循 規劃部署 文件中的指引。
  • 虛擬伺服器實例的主機名稱必須符合 SAP HANA 的要求。
  • SAP HANA 已安裝在兩個虛擬伺服器實體上，並已設定 System Replication。SAP HANA SAP HANA 的安裝和 HANA 系統複製的設定並非特定於 Power Virtual Server 環境，您需要遵循標準程序。
  • 需要有效的 RHEL for SAP Applications 或 RHEL for SAP Solutions 訂閱，才能啟用安裝 SAP HANA 所需的儲存庫，以及 HA 配置的資源代理。

在 IBM 上的 RHEL HA Add-On 群集中設定 SAP HANA 系統複製 Power Virtual Server

本說明依據 Red Hat 產品說明文件以及 IBM Power Virtual Server 參考資料中為 SAP 應用程式實施高可用性所 列出的文章。

準備環境變數

為了簡化設定，請為兩個節點上的 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

為單一區域實作設定額外的環境變數

檢閱 Reserving virtual IP addresses（保留虛擬 IP 位址）中的資訊，並為 SAP HANA System Replication 群集保留虛擬 IP 位址。 將 VIP 環境變數設定為保留的 IP 位址。

為多區域實作設定額外的環境變數

依照「收集設定高可用性群集的參數」一節所述，設定 CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? 變數。 將 API_TYPE 變數設定為 private，以便透過私有端點與 IBM Cloud IAM 和 IBM Power Cloud API 進行通訊。 SUBNET_NAME 變數包含子網路的名稱。 CIDR 變數表示子網路的無類別網域間路由 (CIDR) 符號，格式為 <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 系統複製安裝 RHEL HA Add-On 資源代理。

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( ) 鉤子

  1. 停止群集。

    在 NODE1 上，執行下列指令。

    pcs cluster stop --all

  2. 在每個 HANA 範例的 /hana/shared/myHooks 目錄中安裝 resource-agents-sap-hana 套件提供的勾選指令碼，並設定所需的擁有權。

    在兩個節點上，執行下列指令。

    mkdir -p /hana/shared/myHooks

    cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks

    chown -R ${sid}adm:sapsys /hana/shared/myHooks

  3. 更新每個 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

  4. 驗證已變更的檔案。

    在兩個節點上，執行下列指令。

    cat /hana/shared/${SID}/global/hdb/custom/config/global.ini

  5. 為 SAP HANA OS 使用者建立 sudo 設定。

    您需要下列 sudo 設定，才能允許 ${sid}adm 使用者指令碼在 srConnectionChanged( ) 鉤執行時更新節點屬性。

    在兩個節點上，執行下列指令。

    建立包含所需的 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 指令所報告的任何問題都必須修正。

  1. 驗證掛鉤是否正常運作。

    • 重新啟動兩個 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 群集。

  2. 啟動群集。

    在 NODE1 上，執行下列指令。

    啟動群集。

    pcs cluster start --all

    檢查群集的狀態。

    pcs status --full

設定一般群集屬性

為避免在初始測試和後期製作期間出現資源故障，請設定下列資源堅固性和遷移臨界值參數的預設值。

請記住，預設值不適用於以自己定義的值覆寫預設值的資源。

在 NODE1 上，執行下列指令。

pcs resource defaults update resource-stickiness=1000

pcs resource defaults update migration-threshold=5000

建立複製的 SAPHanaTopology 資源

該 SAPHanaTopology 資源收集每個節點上 SAP HANA System Replication 的狀態和組態。 它還會啟動和監控本機 SAP HostAgent，這是啟動、停止和監控 SAP HANA 實例所必需的。

在 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 系統複製節點的 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 位址群組資源

視情況而定，前往下列其中一節：

在單一區域環境中建立虛擬 IP 位址群組資源

使用保留的 IP 位址建立虛擬 IP 位址群組資源。 此虛擬 IP 位址用於接達 SAP HANA System Replication 主要實例。

使用下列指令建立虛擬 IP 位址群組資源。

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

檢查已設定的虛擬 IP 位址群集資源和群集狀態。

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

pcs status --full

繼續前往「建立群集資源限制」一節。

在多區域環境中建立虛擬 IP 位址群組資源

確認您已完成「為虛擬 IP 位址資源準備多區 RHEL HA Add-On 群集」一節中的所有步驟。

執行 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

繼續前往「建立群集資源限制」一節。

建立群集資源限制

確保 SAPHanaTopology 資源已啟動，才能啟動 SAPHana 資源。

虛擬 IP 位址必須出現在執行「SAPHana」主要資源的節點上。

  1. 建立資源限制，在「SAPHana」之前啟動 "SAPHanaTopology"。 此限制規定了這些資源的開始順序。

    在 NODE1 上，使用以下命令創建 SAPHanaTopology 順序約束：

    pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \
    then SAPHana_${SID}_${INSTNO}-clone symmetrical=false

    檢查設定。

    pcs constraint

  2. 建立資源限制，以將虛擬 IP 位址與主 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 實例的優先停止。
結束
此動作會觸發 HDB kill-<signal> 指令，預設訊號為 9。 訊號可以設定。

Stop 和 kill 動作的結果都是停止 SAP HANA，但 kill 動作的速度稍快。

在所有 SAP HANA 實體上啟動 srServiceStateChanged( ) 鉤子

srServiceStateChanged() 鉤子可以在 SAP HANA 在兩個節點上執行時加入。

  1. 對於每個 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

  2. 更新每個 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)。

  3. 啟動 ChkSrv.py 掛勾

    在兩個節點上，執行下列指令以重新載入 HA-DR 提供者。

    sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders

  4. 檢查鉤子是否記錄了一些訊息到追蹤檔案。

    在兩個節點上，執行下列指令。

    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 系統複製的功能性雙結點 RHEL HA Add-On 集群。
  • 兩個群集節點都處於活動狀態。
  • 在 NODE1 和 NODE2 上啟動的群集。
  • 使用 AUTOMATED_REGISTER=false 配置的群集資源 SAPHana_${SID}_${INSTNO}。
  • 檢查 SAP HANA 系統複製狀態：
    • 主要 SAP HANA 資料庫在 NODE1
    • 次要 SAP HANA 資料庫在 NODE2
    • HANA 系統複製已啟動並保持同步

測試 1 - 測試程序

當使用者 ${sid}adm 時，透過傳送 SIGKILL 訊號使 SAP HANA primary 崩潰。

在 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 系統複製的功能性雙結點 RHEL HA Add-On 集群。
  • 兩個節點都處於活動狀態。
  • 群集在 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 設定的，因此 SAP HANA 會在 NODE2 重新加入群集時重新啟動，而前主要會重新註冊為次要。

測試 3 - 測試次要資料庫實例故障

使用下列資訊測試次要資料庫實例的故障。

測試 3 - 說明

模擬次要 HANA 資料庫當機。

測試 3 - 先決條件

  • 用於 HANA 系統複製的功能性雙結點 RHEL HA Add-On 集群。
  • 兩個節點都處於活動狀態。
  • 群集在 NODE1 和 NODE2 上啟動。
  • 群集資源 SAPHana_${SID}_${INSTNO} 配置為 AUTOMATED_REGISTER=true。
  • 檢查 SAP HANA 系統複製狀態：
    • 主要 SAP HANA 資料庫在 NODE1
    • 次要 SAP HANA 資料庫在 NODE2
    • HANA 系統複製已啟動並保持同步

測試 3 - 測試程序

當使用者 ${sid}adm 時，透過傳送 SIGKILL 訊號讓 SAP HANA secondary 崩潰。

在 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 系統複製的功能性雙結點 RHEL HA Add-On 集群。
  • 兩個節點都處於活動狀態。
  • 群集在 NODE1 和 NODE2 上啟動。
  • 群集資源 SAPHana_${SID}_${INSTNO} 配置為 AUTOMATED_REGISTER=true。
  • 檢查 SAP HANA 系統複製狀態：
    • 主要 SAP HANA 資料庫在 NODE1
    • 次要 SAP HANA 資料庫在 NODE2
    • HANA 系統複製已啟動並保持同步

測試 4 - 測試程序

使用 pcs resource move 指令將 SAP HANA primary 移至其他節點。

在 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