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。

本信息面向计划在 Power Virtual Server 上高可用性部署 SAP HANA 的架构师和专家。

准备工作

查看 IBM Power Virtual Server 参考资料中为 SAP 应用程序实施高可用性 中列出的一般要求、产品文档、支持文章和 SAP 注释。

先决条件

  • Power Virtual Server 中的两个虚拟服务器实例上部署了 Red Hat High Availability 集群。
  • 虚拟服务器实例需要满足 SAP HANA 范围内系统的硬件和资源要求。 请遵循 规划部署 文件中的指导原则。
  • 虚拟服务器实例的主机名必须符合 SAP HANA 的要求。
  • SAP HANA 安装在两个虚拟服务器实例上，并配置了 系统复制。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

为单区实施设置额外的环境变量

查看 保留虚拟 IP 地址 中的信息，并为 SAP HANA 系统复制群集保留一个虚拟 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 系统复制的状态和配置。 它还会启动和监控本地 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 indexserver 进程（由 SAP HANA 停止和重新启动）与实例关闭时停止的进程区分开来。

根据 action_on_lost 参数的配置，钩子会采取不同的操作：

忽略
此操作只是将事件和决策信息记录到日志文件中。
停止
使用 sapcontrol 命令，该操作会触发 SAP HANA 实例的优雅停止。
终止
该操作会触发 HDB kill-<signal> 命令，默认信号为 9。 信号可以配置。

停止和杀死操作都会导致 SAP HANA 实例停止，但杀死操作稍快一些。

在所有 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 附加集群。
  • 两个群集节点都处于活动状态。
  • 在 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 上的新主 IP 地址上获取该地址。
  • 如果应用程序（如 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 附加集群。
  • 两个节点都处于活动状态。
  • 群集在 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 系统复制的功能性双节点 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 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 附加集群。
  • 两个节点都处于活动状态。
  • 群集在 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