通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Red Hat Enterprise Linux 上 Azure VM 中 SAP HANA 的高可用性

  • 项目

对于本地开发，可以使用 HANA 系统复制或共享存储来建立 SAP HANA 的高可用性 (HA)。 在 Azure 虚拟机上，Azure 上的 HANA 系统复制是目前唯一受支持的 HA 功能。

SAP HANA 复制由一个主节点和至少一个辅助节点组成。 对主节点上数据所做的更改以同步或异步方式复制到辅助节点。

本文介绍如何部署和配置虚拟机 (VM)、安装群集框架，以及安装和配置 SAP HANA 系统复制。

在示例配置和安装命令中，使用了实例编号 03 和 HANA 系统 ID HN1。

先决条件

请先阅读以下 SAP 说明和文档：

概述

为了实现 HA，SAP HANA 要安装在两台 VM 上。 数据将使用 HANA 系统复制进行复制。

显示 SAP HANA 高可用性概述的示意图。

SAP HANA 系统复制设置使用专用的虚拟主机名和虚拟 IP 地址。 在 Azure 上，需要负载均衡器才能使用虚拟 IP 地址。 显示的配置展示了一个负载均衡器，其中：

  • 前端 IP 地址：10.0.0.13 (hn1-db)
  • 探测端口：62503

准备基础结构

Azure 市场包含具有高可用性加载项的 SAP HANA 限定的映像，这些映像可用于使用各种版本的 Red Hat 部署新 VM。

通过 Azure 门户手动部署 Linux VM

本文档假定你已部署资源组、Azure 虚拟网络和子网。

部署用于 SAP HANA 的 VM。 选择 HANA 系统支持的合适的 RHEL 映像。 可以通过任何一个可用性选项（虚拟机规模集、可用性区域或可用性集）来部署 VM。

重要

请确保你选择的 OS 已通过 SAP 针对你计划在部署中使用的特定 VM 类型上的 SAP HANA 的认证。 可以在 SAP HANA 认证的 IaaS 平台中查找 SAP HANA 认证的 VM 类型及其 OS 版本。 请确保查看 VM 类型的详细信息，以获取适用于特定 VM 类型的 SAP HANA 支持的 OS 版本的完整列表。

配置 Azure 负载均衡器

在配置 VM 期间，你可以在网络部分中创建或选择现有的负载均衡器。 按照以下步骤设置标准负载均衡器以完成 HANA 数据库的高可用性设置。

按照创建负载均衡器中的步骤，使用 Azure 门户为高可用性 SAP 系统设置标准负载均衡器。 在设置负载均衡器期间，请注意以下几点：

  1. 前端 IP 配置：创建前端 IP。 选择与数据库虚拟机相同的虚拟网络和子网名称。
  2. 后端池：创建后端池并添加数据库 VM。
  3. 入站规则：创建负载均衡规则。 对两个负载均衡规则执行相同步骤。
    • 前端 IP 地址：选择前端 IP。
    • 后端池：选择后端池。
    • 高可用性端口：选择此选项。
    • 协议：选择“TCP”。
    • 运行状况探测：创建具有以下详细信息的运行状况探测：
      • 协议：选择“TCP”。
      • 端口：例如 625<instance-no.>。
      • 间隔时间：输入 5。
      • 探测阈值：输入 2。
    • 空闲超时(分钟)：输入 30。
    • 启用浮动 IP：选择此选项。

注意

不会遵循运行状况探测配置属性 numberOfProbes（在门户中也称为“运行不正常阈值”）。 若要控制成功或失败的连续探测的数量，请将属性 probeThreshold 设置为 2。 当前无法使用 Azure 门户设置此属性，因此请使用 Azure CLI 或 PowerShell 命令。

有关 SAP HANA 所需端口的详细信息，请参阅 SAP HANA 租户数据库指南中的连接到租户数据库一章或 SAP 说明 2388694。

注意

如果没有公共 IP 地址的 VM 放在标准 Azure 负载均衡器的内部（无公共 IP 地址）实例的后端池中，除非执行更多的配置以允许路由到公共终结点，否则就没有出站 Internet 连接。 有关如何实现出站连接的详细信息，请参阅 SAP 高可用性方案中使用 Azure 标准负载均衡器的 VM 的公共终结点连接。

重要

请勿在放置于 Azure 负载均衡器之后的 Azure VM 上启用 TCP 时间戳。 启用 TCP 时间戳会导致运行状况探测失败。 将参数 net.ipv4.tcp_timestamps 设置为 0。 有关详细信息，请参阅负载均衡器运行状况探测和 SAP 说明 2382421。

安装 SAP HANA

本部分中的步骤使用以下前缀：

  • [A] ：该步骤适用于所有节点。
  • [1] ：该步骤仅适用于节点 1。
  • [2] ：该步骤仅适用于 Pacemaker 群集的节点 2。

  1. [A] 设置磁盘布局：逻辑卷管理器 (LVM) 。

    我们建议对存储数据和日志文件的卷使用 LVM。 以下示例假设 VM 上附加了四个用于创建两个卷的数据磁盘。

    列出所有可用的磁盘：

    ls /dev/disk/azure/scsi1/lun*

    示例输出：

    /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3

    为想要使用的所有磁盘创建物理卷：

    sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2
sudo pvcreate /dev/disk/azure/scsi1/lun3

    为数据文件创建卷组。 将一个卷组用于日志文件，将另一个卷组用于 SAP HANA 的共享目录：

    sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3

    创建逻辑卷。 线性卷是使用不带 -i 开关的 lvcreate 创建的。 我们建议你创建一个带区卷，以获得更好的 I/O 性能。 将带区大小与 SAP HANA VM 存储配置中记录的值保持一致。 -i 参数应表示基础物理卷的数量，-I 参数则表示带区大小。

    在本文档中，两个物理卷用于数据卷，因此 -i 开关参数设置为 2。 数据卷的带区大小为 256 KiB。 一个物理卷用于日志卷，因此，-i 或 -I 开关不会显式用于日志卷命令。

    重要

    对每个数据、日志或共享卷使用多个物理卷时，请使用 -i 开关，并将其设置为基础物理卷的数量。 创建带区卷时，请使用 -I 开关来指定带区大小。 有关建议的存储配置，包括带区大小和磁盘数量，请参阅 SAP HANA VM 存储配置。 以下布局示例不一定满足特定系统大小的性能准则。 它们仅用于演示。

    sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared

    不要通过发出装载命令来装载目录。 而是在 fstab 中输入配置，并最后发出 mount -a 来验证语法。 首先为每个卷创建装载目录：

    sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared

    接下来，在 /etc/fstab 文件中插入以下行，为这三个逻辑卷创建 fstab 条目：

    /dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 2

    最后，一次性装载所有新卷：

    sudo mount -a

  2. [A] 为所有主机设置主机名解析。

    通过在 /etc/hosts 中像这样为所有节点创建条目，可以使用 DNS 服务器，也可以修改所有节点上的 /etc/hosts 文件：

    10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1

  3. [A] 执行 RHEL for HANA 配置。

    按照以下说明配置 RHEL：

  4. [A] 按照 SAP 文档安装 SAP HANA。

  5. [A] 配置防火墙。

    为 Azure 负载均衡器探测端口创建防火墙规则。

    sudo firewall-cmd --zone=public --add-port=62503/tcp
sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent

配置 SAP HANA 2.0 系统复制

本部分中的步骤使用以下前缀：

  • [A] ：该步骤适用于所有节点。
  • [1] ：该步骤仅适用于节点 1。
  • [2] ：该步骤仅适用于 Pacemaker 群集的节点 2。

  1. [A] 配置防火墙。

    创建防火墙规则以允许 HANA 系统复制和客户端流量。 所有 SAP 产品的 TCP/IP 端口上均列出了所需端口。 以下命令是允许 HANA 2.0 系统复制和到数据库 SYSTEMDB、HN1 和 NW1 的流量的示例。

     sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp

  2. [1] 创建租户数据库。

    以 <hanasid>adm 身份运行以下命令：

    hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'

  3. [1] 在第一个节点上配置系统复制。

    以 <hanasid>adm 身份备份数据库：

    hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

    将系统 PKI 文件复制到辅助站点：

    scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

    创建主站点：

    hdbnsutil -sr_enable --name=SITE1

  4. [2] 在第二个节点上配置系统复制。

    注册第二个节点以启动系统复制。 以 <hanasid>adm 身份运行以下命令：

    sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

  5. [2] 启动 HANA。

    以 <hanasid>adm 身份运行以下命令以启动 HANA：

    sapcontrol -nr 03 -function StartSystem

  6. [1] 检查复制状态。

    检查复制状态并等待，直到所有数据库都保持同步。如果状态一直“未知”，请检查防火墙设置。

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
# | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# mode: PRIMARY
# site id: 1
# site name: SITE1

创建 Pacemaker 群集

按照在 Azure 中的 Red Hat Enterprise Linux 上设置 Pacemaker 的步骤，创建适用于此 HANA 服务器的基本 Pacemaker。

重要

借助基于 systemd 的 SAP 启动框架，SAP HANA 实例现在可以由 systemd 管理。 SAP 所需的最低 Red Hat Enterprise Linux (RHEL) 版本是 RHEL 8。 如 SAP 说明 3189534 中所述，任何新安装的 SAP HANA SPS07 修订版 70 或更高版本，或者将 HANA 系统更新到 HANA 2.0 SPS07 修订版 70 或更高版本，SAP 启动框架都会自动注册到 systemd。

当使用 HA 解决方案与启用 systemd 的 SAP HANA 实例结合管理 SAP HANA 系统复制时（请参阅 SAP 说明 3189534），需要执行其他步骤以确保 HA 群集无需 systemd 即可管理 SAP 实例。 因此，对于与 systemd 集成的 SAP HANA 系统，必须在所有群集节点上遵循 Red Hat KBA 7029705 中概述的其他步骤。

实现 SAP HANA 系统复制挂钩

这是优化与群集的集成并在需要进行群集故障转移时改进检测的重要步骤。 必须执行正确的群集操作才能启用 SAPHanaSR 挂钩。 强烈建议同时配置 SAPHanaSR 和 ChkSrv Python 挂钩。

  1. [A] 在所有节点上安装 SAP HANA 资源代理。 确保启用包含程序包的存储库。 如果使用启用了 RHEL 8.x 或更高版本的 HA 映像，则无需启用其他存储库。

    # Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo dnf install -y resource-agents-sap-hana

    注意

    对于 RHEL 8.x 和 RHEL 9.x，请验证已安装的 resource-agents-sap-hana 包是否为版本 0.162.3-5 或更高版本。

  2. [A] 安装 HANA system replication hooks。 需要在两个 HANA DB 节点上安装复制挂钩的配置。

    1. 在两个节点上停止 HANA。 以 <sid>adm 身份运行。

      sapcontrol -nr 03 -function StopSystem

    2. 在每个群集节点上调整 global.ini。

      [ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/SAPHanaSR/srHook
execution_order = 2
action_on_lost = kill

[trace]
ha_dr_saphanasr = info
ha_dr_chksrv = info

    如果将参数 path 指向默认的 /usr/share/SAPHanaSR/srHook 位置，Python 挂钩代码将通过 OS 更新或包更新自动更新。 HANA 在下一次重启时使用挂钩代码更新。 通过使用可选自有路径（如 /hana/shared/myHooks），可将 OS 更新与 HANA 将使用的挂钩版本分离。

    可以使用 action_on_lost 参数调整 ChkSrv 挂钩的行为。 有效值为 [ ignore | stop | kill ]。

  3. [A] 群集需要在每个群集节点上为 <sid>adm 配置 sudoers。 在此示例中，通过创建新文件来实现此目的。 以 root 身份使用 visudo 命令编辑 20-saphana 轻松替换文件。

    sudo visudo -f /etc/sudoers.d/20-saphana

    插入以下行，然后保存：

    Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty

  4. [A] 在两个节点上启动 SAP HANA。 以 <sid>adm 身份运行。

    sapcontrol -nr 03 -function StartSystem

  5. [1] 验证 SRHanaSR 挂钩安装。 在活动 HANA 系统复制站点上以 <sid>adm 身份运行。

     cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

     # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK

  6. [1] 验证 ChkSrv 挂钩安装。 在活动 HANA 系统复制站点上以 <sid>adm 身份运行。

     cdtrace
 tail -20 nameserver_chksrv.trc

有关 SAP HANA 挂钩实现的详细信息，请参阅启用 SAP HANA srConnectionChanged() 挂钩和为 hdbindexserver 进程失败操作（可选）启用 SAP HANA srServiceStateChanged() 挂钩。

创建 SAP HANA 群集资源

创建 HANA 拓扑。 在其中一个 Pacemaker 群集节点上运行以下命令。 在这些说明中，请务必根据需要替换实例编号、HANA 系统 ID、IP 地址和系统名称。

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

接着，创建 HANA 资源。

注意

本文包含对 Microsoft 不再使用的术语的引用。 在从软件中删除该术语后，我们会将其从本文中删除。

如果在 RHEL 7.x 上构建群集，请使用以下命令：

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000

sudo pcs property set maintenance-mode=false

如果在 RHEL 8.x/9.x 上构建群集，请使用以下命令：

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  promotable notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

sudo pcs property set maintenance-mode=false

若要为 SAP HANA 配置 priority-fencing-delay（仅适用于 pacemaker-2.0.4-6.el8 或更高版本），需要执行以下命令。

注意

如果有双节点群集，则可以配置 priority-fencing-delay 群集属性。 当发生脑裂情况时，此属性会在隔离具有较高总资源优先级的节点时引入延迟。 有关详细信息，请参阅 Pacemaker 是否可以隔离运行最少资源的群集节点？。

属性 priority-fencing-delay 适用于 pacemaker-2.0.4-6.el8 或更高版本。 如果要在现有群集上设置 priority-fencing-delay，请确保取消设置隔离设备中的 pcmk_delay_max 选项。

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

重要

在执行故障转移测试时，最好将 AUTOMATED_REGISTER 设置为 false，以防止故障的主实例自动注册为辅助实例。 测试后，最佳做法是将 AUTOMATED_REGISTER 设置为 true，以便在接管后系统复制可以自动继续。

确保群集状态正常，并且所有资源都已启动。 资源在哪个节点上运行并不重要。

注意

上述配置中的超时只是示例，可能需要根据特定的 HANA 设置进行调整。 例如，如果启动 SAP HANA 数据库需要较长时间，则可能需要增加启动超时。

使用命令 sudo pcs status 检查创建的群集资源的状态：

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

在 Pacemaker 群集中配置启用 HANA 活动/读取的系统复制

从 SAP HANA 2.0 SPS 01 开始，SAP 允许对 SAP HANA 系统复制使用启用活动/读取的设置，在这种情况下，SAP HANA 系统复制的辅助系统可积极用于读取密集型工作负载。

若要在群集中支持此类设置，需要提供第二个虚拟 IP 地址，以便客户端能够访问启用了读取的辅助 SAP HANA 数据库。 若要确保辅助复制站点在接管后仍可以访问，群集需要将虚拟 IP 地址与辅助 SAPHana 资源一起移动。

本部分介绍使用第二个虚拟 IP 在 Red Hat 高可用性群集中管理启用了 HANA 活动/读取系统复制所需的其他步骤。

在继续操作之前，请确保已完全配置管理 SAP HANA 数据库的 Red Hat HA 群集，如文档前面的部分所述。

示意图显示具有启用了读取的辅助数据库的 SAP HANA HA。

在 Azure 负载均衡器中进行其他设置，以实现启用活动/读取设置

若要继续执行有关预配第二个虚拟 IP 的更多步骤，请确保已按照通过 Azure 门户手动部署 Linux VM 部分所述，配置了 Azure 负载均衡器。

  1. 对于“标准”负载均衡器，请在前面部分中创建的同一负载平衡器上按照以下步骤进行操作。

    a. 创建第二个前端 IP 池：

    • 打开负载均衡器，选择前端 IP 池，然后选择“添加”。
    • 输入第二个新前端 IP 池的名称（例如“hana-secondaryIP”）。
    • 将“分配”设置为“静态”并输入 IP 地址（例如 10.0.0.14）。
    • 选择“确定”。
    • 创建新前端 IP 池后，请记下池 IP 地址。

    b. 创建运行状况探测：

    • 打开负载均衡器，选择运行状况探测，然后选择“添加”。
    • 输入新运行状况探测的名称（例如“hana-secondaryhp”）。
    • 选择“TCP”作为协议，并选择端口“62603” 。 将“间隔”值保留设置为 5，将“不正常阈”值设置为 2。
    • 选择“确定”。

    c. 创建负载均衡规则：

    • 打开负载均衡器，选择负载均衡规则，然后选择“添加”。
    • 输入新负载均衡器规则的名称（例如“hana-secondarylb”）。
    • 选择前面创建的前端 IP 地址、后端池和运行状况探测（例如“hana-secondaryIP”、“hana-backend”和“hana-secondaryhp”）。
    • 选择“HA 端口”。
    • 确保启用浮动 IP。
    • 选择“确定”。

配置启用 HANA 活动/读取的系统复制

配置 SAP HANA 2.0 系统复制部分介绍了配置 HANA 系统复制的步骤。 如果部署已启用读取的辅助方案，则在第二个节点上配置系统复制的同时，请以 hanasidadm 身份运行以下命令：

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess

为已启用活动/读取设置添加辅助虚拟 IP 地址资源

可以通过以下命令配置第二个虚拟 IP 和适当的归置约束：

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603
pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master
pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5

pcs property set maintenance-mode=false

确保群集状态正常，并且所有资源都已启动。 第二个虚拟 IP 将与 SAPHana 辅助资源一起在辅助站点上运行。

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

在下一部分中，可以找到要运行的典型故障转移测试组。

请注意第二个虚拟 IP 的行为，同时测试使用启用了读取的辅助数据库配置的 HANA 群集：

  1. 将“SAPHana_HN1_03”群集资源迁移到辅助站点“hn1-db-1”时，第二个虚拟 IP 将继续在同一站点“hn1-db-1”上运行。 如果为资源设置了 AUTOMATED_REGISTER="true" 并且已在 hn1-db-0 上自动注册了 HANA 系统复制，则第二个虚拟 IP 也会移动到 hn1-db-0。

  2. 测试服务器故障时，第二个虚拟 IP 资源 (secvip_HN1_03) 和 Azure 负载均衡器端口资源 (secnc_HN1_03) 将在主服务器上与主虚拟 IP 资源一起运行。 在辅助服务器关闭前，连接到启用了读取的 HANA 数据库的应用程序会连接到主 HANA 数据库。 此行为是预期行为，因为在辅助服务器不可用之前，你不希望连接到已启用读取的 HANA 数据库的应用程序无法访问。

  3. 在故障转移和回退第二个虚拟 IP 地址过程中，使用第二个虚拟 IP 连接到 HANA 数据库的应用程序的现有连接可能会中断。

该设置会使第二个虚拟 IP 资源被分配给正在运行状况良好的 SAP HANA 实例的节点所需的时间达到上限。

测试群集设

本部分介绍如何测试设置。 在开始测试之前，请确保 Pacemaker 没有任何失败的操作（通过 pcs 状态检查）、没有任何意外的位置约束（例如迁移测试的遗留内容），并且 HANA 处于同步状态，例如，使用 systemReplicationStatus 检查。

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

测试迁移

开始测试之前的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

通过以 root 身份运行以下命令，可以迁移 SAP HANA 主节点：

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

该群集会将 SAP HANA 主节点和包含虚拟 IP 地址的组迁移到 hn1-db-1。

完成迁移后，sudo pcs status 输出如下所示：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

AUTOMATED_REGISTER="false" 时，该群集不会重启失败的 HANA 数据库，也不会针对 hn1-db-0 上的新主数据库注册该数据库。 在这种情况下，以 hn1adm 身份通过运行以下命令将 HANA 实例配置为辅助实例：

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

迁移过程将创建位置约束，需要再次删除这些约束。 以 root 身份或通过 sudo 运行以下命令：

pcs resource clear SAPHana_HN1_03-master

使用 pcs status 监视 HANA 资源的状态。 在 hn1-db-0 上启用 HANA 后，输出应如下所示：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

阻止网络通信

开始测试之前的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

运行防火墙规则以阻止其中一个节点上的通信。

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

当群集节点无法相互通信时，存在脑裂情况的风险。 在这种情况下，群集节点尝试同时相互隔离，从而导致围栏争用。 为了避免这种情况，我们建议在群集配置中设置 priority-fencing-delay 属性（仅适用于 pacemaker-2.0.4-6.el8 或更高版本）。

通过启用 priority-fencing-delay 属性，群集会专门在托管 HANA 主资源的节点上引入隔离操作延迟，从而让节点赢得围栏争用。

运行以下命令以删除防火墙规则：

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

测试 Azure 隔离代理

注意

本文包含对 Microsoft 不再使用的术语的引用。 在从软件中删除该术语后，我们会将其从本文中删除。

开始测试之前的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

可以通过禁用节点上的网络接口（SAP HANA 作为主控节点运行）来测试 Azure 隔离代理的设置。 如需了解如何模拟网络故障，请参阅 Red Hat 知识库文章 79523。

在此示例中，我们以 root 身份使用 net_breaker 脚本阻止对网络的所有访问：

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

现在，VM 应会根据群集配置重启或停止。 如果将 stonith-action 设置为 off，则会停止 VM，并将资源迁移到正在运行的 VM。

如果设置 AUTOMATED_REGISTER="false"，则再次启动 VM 后，SAP HANA 资源将无法作为辅助资源启动。 在这种情况下，通过以 hn1adm 用户身份运行以下命令，将 HANA 实例配置为辅助实例：

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

切换回 root 身份录并清理失败状态：

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

测试之后的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

测试手动故障转移

开始测试之前的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

通过以 root 身份停止 hn1-db-0 节点上的群集可以测试手动故障转移：

pcs cluster stop

故障转移后，可以再次启动该群集。 如果设置了 AUTOMATED_REGISTER="false"，则 hn1-db-0 节点上的 SAP HANA 资源将无法作为辅助资源启动。 在这种情况下，请以 root 身份运行以下命令，将 HANA 实例配置为辅助实例：

pcs cluster start

以 hn1adm 身份运行以下命令：

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

然后以 root 身份运行以下命令：

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

测试之后的资源状态：

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

后续步骤