你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性
若要在本地 SAP HANA 部署中建立高可用性，可以使用 SAP HANA 系统复制或共享存储。
当前在 Azure 虚拟机 (VM) 上，Azure 上的 SAP HANA 系统复制是唯一受支持的高可用性功能。
SAP HANA 系统复制由一个主节点和至少一个辅助节点组成。 对主节点上数据所做的更改以同步或异步方式复制到辅助节点。
本文介绍如何部署和配置 VM、安装群集框架，以及安装和配置 SAP HANA 系统复制。
在开始之前，请先阅读以下 SAP 说明和文章：
- SAP 说明 1928533。 说明包括：
- SAP 软件部署支持的 Azure VM 大小的列表。
- Azure VM 大小的重要容量信息。
- 支持的 SAP 软件、操作系统 (OS) 和数据库组合。
- Microsoft Azure 上 Windows 和 Linux 所需的 SAP 内核版本。
- SAP 说明 2015553 列出了在 Azure 中 SAP 支持的 SAP 软件部署的先决条件。
- SAP 说明 2205917 包含适用于 SUSE Linux Enterprise Server 12 (SLES 12) for SAP Applications 的推荐 OS 设置。
- SAP 说明 2684254 包含适用于SUSE Linux Enterprise Server 15 (SLES 15) for SAP Applications 的推荐 OS 设置。
- SAP 说明 2235581 介绍了 SAP HANA 支持的操作系统
- SAP 说明 2178632 包含为 Azure 中的 SAP 报告的所有监控指标的详细信息。
- SAP 说明 2191498 包含 Azure 中的 Linux 所需的 SAP 主机代理版本。
- SAP 说明 2243692 包含 Azure 中的适用于 Linux 的 SAP 许可的相关信息。
- SAP 说明 1984787 包含有关 SUSE Linux Enterprise Server 12 的一般信息。
- SAP 说明 1999351 包含适用于 SAP 的 Azure 增强型监视扩展的更多故障排除信息。
- SAP 说明 401162 包含有关如何在设置 HANA 系统复制时避免“地址已使用”错误的信息。
- SAP 社区支持 Wiki 包含适用于 Linux 的所有必需 SAP 说明。
- 经 SAP HANA 认证的 IaaS 平台。
- 针对 Linux 上的 SAP 的 Azure 虚拟机规划和实施指南。
- 适用于 Linux 上的 SAP 的 Azure 虚拟机部署指南。
- 适用于 Linux 上的 SAP 的 Azure 虚拟机 DBMS 部署指南。
- SUSE Linux Enterprise Server for SAP Applications 15 最佳做法指南和 SUSE Linux Enterprise Server for SAP Applications 12 最佳做法指南：
- 设置 SAP HANA SR 性能优化的基础结构 (SLES for SAP Applications)。 本指南包含为本地开发设置 SAP HANA 系统复制的所需的全部信息。 请使用本指南作为基准。
- 设置 SAP HANA SR 成本优化的基础结构 (SLES for SAP Applications)。
规划 SAP HANA 高可用性
若要实现高可用性，请在两个 VM 上安装 SAP HANA。 数据将使用 HANA 系统复制进行复制。
SAP HANA 系统复制设置使用专用的虚拟主机名和虚拟 IP 地址。 在 Azure 中，需要使用负载均衡器来部署虚拟 IP 地址。
上图显示了具有以下配置的负载均衡器示例：
- 前端 IP 地址：10.0.0.13 (HN1-db)
- 探测端口：62503
准备基础结构
SUSE Linux Enterprise Server for SAP Applications 中已随附 SAP HANA 的资源代理。 Azure 市场中提供了 SUSE Linux Enterprise Server for SAP Applications 12 或 15 的映像。 可使用该映像来部署新的 VM。
通过 Azure 门户手动部署 Linux VM
本文档假定你已部署 Azure 虚拟网络资源组和子网。
为 SAP HANA 部署虚拟机。 选择 HANA 系统支持的、合适的 SLES 映像。 可以通过任何一个可用性选项（虚拟机规模集、可用性区域或可用性集）来部署 VM。
重要
请确保你选择的 OS 已通过 SAP 针对你计划在部署中使用的特定 VM 类型上的 SAP HANA 的认证。 可以在 SAP HANA 认证的 IaaS 平台中查找 SAP HANA 认证的 VM 类型及其 OS 版本。 请确保查看 VM 类型的详细信息，以获取适用于特定 VM 类型的 SAP HANA 支持的 OS 版本的完整列表。
配置 Azure 负载均衡器
在配置 VM 期间，你可以在网络部分中创建或选择现有的负载均衡器。 按照以下步骤设置标准负载均衡器以完成 HANA 数据库的高可用性设置。
按照创建负载均衡器中的步骤，使用 Azure 门户为高可用性 SAP 系统设置标准负载均衡器。 在设置负载均衡器期间，请注意以下几点：
- 前端 IP 配置：创建前端 IP。 选择与数据库虚拟机相同的虚拟网络和子网名称。
- 后端池：创建后端池并添加数据库 VM。
- 入站规则：创建负载均衡规则。 对两个负载均衡规则执行相同步骤。
- 前端 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。 - 为防止 saptune 将手动设置的
net.ipv4.tcp_timestamps值从0更改回1，请将 saptune 版本更新为 3.1.1 或更高版本。 有关更多详细信息，请参阅 saptune 3.1.1 – 我是否需要更新？。
创建 Pacemaker 群集
按照在 Azure 中的 SUSE Linux Enterprise Server 上设置 Pacemaker 中的步骤为此 HANA 服务器创建一个基本 Pacemaker 群集。 还可对 SAP HANA 和 SAP NetWeaver (A)SCS 使用同一 Pacemaker 群集。
安装 SAP HANA
本部分中的步骤使用以下前缀：
- [A] ：该步骤适用于所有节点。
- [1]：此步骤仅适用于节点 1。
- [2]：此步骤仅适用于 Pacemaker 群集的节点 2。
将 <placeholders> 替换为 SAP HANA 安装的值。
[A] 使用逻辑卷管理器 (LVM) 设置磁盘布局。
我们建议对存储数据和日志文件的卷使用 LVM。 以下示例假设 VM 上附加了四个用于创建两个卷的数据磁盘。
运行以下命令列出所有可用磁盘：
/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_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2 sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3创建逻辑卷。
线性卷是使用不带
-i开关的lvcreate创建的。 我们建议你创建一个带区卷，以获得更好的 I/O 性能。 将带区大小与 SAP HANA VM 存储配置中所述的值保持一致。-i参数应表示基础物理卷的数量，-I参数则表示带区大小。例如，如果两个物理卷用于数据卷，
-i开关参数设置为 2，数据卷的带区大小为 256KiB。 一个物理卷用于日志卷，因此，-i或-I开关不会显式用于日志卷命令。重要
对每个数据卷、日志卷或共享卷使用多个物理卷时，请使用
-i开关，并将其设置为基础物理卷的数量。 创建条带卷时，请使用-I开关指定带区大小。有关建议的存储配置，包括带区大小和磁盘数，请参阅 SAP HANA VM 存储配置。
sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID> sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID> sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID> sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared创建装载目录并复制所有逻辑卷的通用唯一标识符 (UUID)：
sudo mkdir -p /hana/data/<HANA SID> sudo mkdir -p /hana/log/<HANA SID> sudo mkdir -p /hana/shared/<HANA SID> # Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared sudo blkid编辑 /etc/fstab 文件，为三个逻辑卷创建
fstab条目：sudo vi /etc/fstab在 /etc/fstab 文件中插入以下行：
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs defaults,nofail 0 2装载新卷：
sudo mount -a
[A] 使用普通磁盘设置磁盘布局。
对于演示系统，可将 HANA 数据和日志文件放在一个磁盘上。
在 /dev/disk/azure/scsi1/lun0 上创建分区，并使用 XFS 设置其格式：
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0' sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1 # Write down the ID of /dev/disk/azure/scsi1/lun0-part1 sudo /sbin/blkid sudo vi /etc/fstab在 /etc/fstab 文件中插入此行：
/dev/disk/by-uuid/<UUID> /hana xfs defaults,nofail 0 2创建目标目录并装载磁盘：
sudo mkdir /hana sudo mount -a
[A] 为所有主机设置主机名解析。
可以使用 DNS 服务器，或修改所有节点上的 /etc/hosts 文件。 此示例演示如何使用 /etc/hosts 文件。 请替换以下命令中的 IP 地址和主机名。
编辑 /etc/hosts 文件：
sudo vi /etc/hosts将以下行插入 /etc/hosts 文件。 根据你的环境更改 IP 地址和主机名。
10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] 按照 SAP 文档安装 SAP HANA。
配置 SAP HANA 2.0 系统复制
本部分中的步骤使用以下前缀：
- [A] ：该步骤适用于所有节点。
- [1]：此步骤仅适用于节点 1。
- [2]：此步骤仅适用于 Pacemaker 群集的节点 2。
将 <placeholders> 替换为 SAP HANA 安装的值。
[1] 创建租户数据库。
如果使用的是 SAP HANA 2.0 或 SAP HANA MDC，请为 SAP NetWeaver 系统创建一个租户数据库。
以 <HANA SID>adm 身份运行以下命令：
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'[1] 在第一个节点上配置系统复制：
首先，将数据库备份为 <HANA SID>adm：
hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')" hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')" hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"然后，将系统公钥基础结构 (PKI) 文件复制到辅助站点：
scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/ scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/创建主站点：
hdbnsutil -sr_enable --name=<site 1>[2] 在第二个节点上配置系统复制：
注册第二个节点以启动系统复制。
以 <HANA SID>adm 身份运行以下命令：
sapcontrol -nr <instance number> -function StopWait 600 10 hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
实现 HANA 资源代理
SUSE 为 Pacemaker 资源代理提供了两个不同的软件包来管理 SAP HANA。 软件包 SAPHanaSR 和 SAPHanaSR-angi 使用的语法和参数略有不同，两者互不兼容。 有关 SAPHanaSR 与 SAPHanaSR-angi 的详细信息和差异，请参阅 SUSE 发行说明和文档。 本文档在相应部分的单独选项卡中介绍了这两个包。
警告
请不要在已配置的群集中将包 SAPHanaSR 替换为 SAPHanaSR-angi。 从 SAPHanaSR 升级到 SAPHanaSR-angi 需要遵循特定的过程。
- [A] 安装 SAP HANA 高可用性包：
运行以下命令以安装高可用性包：
sudo zypper install SAPHanaSR
设置 SAP HANA HA/DR 提供程序
SAP HANA HA/DR 提供程序优化与群集的集成并在需要进行群集故障转移时改进检测。 主要挂钩脚本为 SAPHanaSR（用于 SAPHanaSR 包）/susHanaSR（用于 SAPHanaSR-angi）。 强烈建议配置 SAPHanaSR/susHanaSR Python 挂钩。 对于 HANA 2.0 SPS 05 及更高版本，建议同时实现 SAPHanaSR/susHanaSR 和 susChkSrv 挂钩。
susChkSrv 挂钩扩展了主 SAPHanaSR/susHanaSR HA 提供程序的功能。 它在 HANA 进程 hdbindexserver 崩溃时发挥作用。 如果单个进程崩溃，HANA 通常会尝试重启该进程。 重启 indexserver 进程可能需要很长时间，在此期间 HANA 数据库无法响应。
实现 susChkSrv 后，将立即执行可配置操作。 该操作在配置的超时期内触发故障转移，而不是等待 hdbindexserver 进程在同一节点上重启。
- [A] 停止两个节点上的 HANA。
以 <sap-sid>adm 身份运行以下代码：
sapcontrol -nr <instance number> -function StopSystem
[A] 安装 HANA 系统复制挂钩。 挂钩必须安装在两个 HANA 数据库节点上。
提示
只能为 HANA 2.0 实现 SAPHanaSR Python 挂钩。 SAPHanaSR 包必须至少为版本 0.153。
只能为 HANA 2.0 SPS 05 及更高版本实现 SAPHanaSR-angi Python 挂钩。
susChkSrv Python 挂钩要求安装 SAP HANA 2.0 SPS 05 和 SAPHanaSR 版本 0.161.1_BF 或更高版本。[A] 调整每个群集节点上的 global.ini。
如果未满足 susChkSrv 挂钩的要求，请从以下参数中删除整个
[ha_dr_provider_suschksrv]块。 可以使用action_on_lost参数调整susChkSrv的行为。 有效值为 [ignore|stop|kill|fence]。[ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR execution_order = 1 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR execution_order = 3 action_on_lost = fence [trace] ha_dr_saphanasr = info如果将参数路径指向默认的
/usr/share/SAPHanaSR位置，Python 挂钩代码将通过 OS 更新或包更新自动更新。 HANA 在下一次重启时使用挂钩代码更新。 通过使用可选自有路径（如/hana/shared/myHooks），可将 OS 更新与使用的挂钩版本分离。[A] 群集要求对于 <sap-sid>adm，在每个群集节点上使用 sudoers 配置。 在此示例中，通过创建新文件来实现此目的。
以 root 身份运行以下命令。 请将 <sid> 替换为小写的 SAP 系统 ID，将 <SID> 替换为大写的 SAP 系统 ID，并将 <siteA/B> 替换为所选的 HANA 站点名称。
cat << EOF > /etc/sudoers.d/20-saphana # Needed for SAPHanaSR and susChkSrv Python hooks Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias HELPER_TAKEOVER = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover Cmnd_Alias HELPER_FENCE = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE EOF
有关实现 SAP HANA 系统复制挂钩的详细信息，请参阅设置 HANA HA/DR 提供程序。
[A] 在两个节点上启动 SAP HANA。 以 <sap-sid>adm 身份运行以下命令：
sapcontrol -nr <instance number> -function StartSystem[1] 验证是否安装了挂钩。 在活动 HANA 系统复制站点上，以 <sap-sid>adm 身份运行以下命令：
cdtrace awk '/ha_dr_SAPHanaSR.*crm_attribute/ \ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_* # Example output # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK
- [1] 验证 susChkSrv 挂钩安装。
在 HANA VM 上以 <sap-sid>adm 身份运行以下命令：
cdtrace egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc # Example output # 2022-11-03 18:06:21.116728 susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9 # 2022-11-03 18:06:27.613588 START: indexserver event looks like graceful tenant start # 2022-11-03 18:07:56.143766 START: indexserver event looks like graceful tenant start (indexserver started)
创建 SAP HANA 群集资源
- [1] 首先创建 HANA 拓扑资源。
在其中一个 Pacemaker 群集节点上运行以下命令：
sudo crm configure property maintenance-mode=true
# Replace <placeholders> with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
op monitor interval="10" timeout="600" \
op start interval="0" timeout="600" \
op stop interval="0" timeout="300" \
params SID="<HANA SID>" InstanceNumber="<instance number>"
sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
meta clone-node-max="1" target-role="Started" interleave="true"
- [1] 接着创建 HANA 资源：
注意
本文包含对 Microsoft 不再使用的术语的引用。 当这些术语在软件中被删除后，我们会将它们从本文中删除。
# Replace <placeholders> with your instance number and HANA system ID.
sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
op start interval="0" timeout="3600" \
op stop interval="0" timeout="3600" \
op promote interval="0" timeout="3600" \
op monitor interval="60" role="Master" timeout="700" \
op monitor interval="61" role="Slave" timeout="700" \
params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"
# Run the following command if the cluster nodes are running on SLES 12 SP05.
sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
meta notify="true" clone-max="2" clone-node-max="1" \
target-role="Started" interleave="true"
# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
meta notify="true" clone-max="2" clone-node-max="1" \
target-role="Started" interleave="true" promotable="true"
sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100
- [1] 继续处理虚拟 IP、默认值和约束相关的群集资源。
# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer.
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
op monitor interval="10s" timeout="20s" \
params ip="<front-end IP address>"
sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>
sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
msl_SAPHana_<HANA SID>_HDB<instance number>:Master
sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
msl_SAPHana_<HANA SID>_HDB<instance number>
# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>
sudo crm configure property priority-fencing-delay=30
sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000
重要
建议仅在完成彻底故障转移测试时将 AUTOMATED_REGISTER 设置为 false，以防止失败的主实例自动注册为辅助实例。 成功完成故障转移测试后，将 AUTOMATED_REGISTER 设置为 true，这样在接管后系统复制会自动恢复。
确保群集状态为 OK，并且所有资源都已启动。 资源在哪个节点上运行并不重要。
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
在 Pacemaker 群集中配置启用 HANA 活动/读取的系统复制
在 SAP HANA 2.0 SPS 01 和更高版本中，SAP 允许对 SAP HANA 系统复制使用启用活动/读取的设置。 在此场景中，SAP HANA 系统复制的辅助系统可以主动用于读取密集型工作负荷。
若要在群集中支持此设置，需要提供第二个虚拟 IP 地址，使客户端能够访问启用了辅助读取的 SAP HANA 数据库。 若要确保辅助复制站点在接管后仍可以访问，群集需要将虚拟 IP 地址与 SAPHana 资源的辅助地址一起移动。
本部分介绍在使用第二个虚拟 IP 地址的 SUSE 高可用性群集中管理启用 HANA 活动/读取的系统复制所需的额外步骤。
在继续之前，请确保已按照前面章节的描述，完全配置了管理 SAP HANA 数据库的 SUSE 高可用性群集。
为启用活动/读取的系统复制设置负载均衡器
若要继续执行有关预配第二个虚拟 IP 的额外步骤，请确保已按照通过 Azure 门户手动部署 Linux VM 所述，配置了 Azure 负载均衡器。
对于“标准”负载均衡器，请在之前创建的同一负载均衡器上完成这些额外步骤。
- 创建第二个前端 IP 池：
- 打开负载均衡器，选择前端 IP 池，然后选择“添加”。
- 输入第二个新前端 IP 池的名称（例如“hana-secondaryIP”）。
- 将“分配”设置为“静态”并输入 IP 地址（例如，“10.0.0.14”） 。
- 选择“确定”。
- 创建新前端 IP 池后，请记下前端 IP 地址。
- 创建运行状况探测：
- 在负载均衡器中，选择“运行状况探测”，然后选择“添加”。
- 输入新运行状况探测的名称（例如“hana-secondaryhp”）。
- 选择 TCP 作为协议，并选择端口 626<实例编号>。 将“间隔”值保留设置为 5，将“不正常阈”值设置为 2。
- 选择“确定”。
- 创建负载均衡规则：
- 在负载均衡器中，选择“负载均衡规则”，然后选择“添加”。
- 输入新负载均衡器规则的名称（例如“hana-secondarylb”）。
- 选择前面创建的前端 IP 地址、后端池和运行状况探测（例如“hana-secondaryIP”、“hana-backend”和“hana-secondaryhp”）。
- 选择“HA 端口”。
- 将空闲超时增大到 30 分钟。
- 确保启用浮动 IP。
- 选择“确定”。
设置启用 HANA 活动/读取的系统复制
配置 SAP HANA 2.0 系统复制介绍了配置 HANA 系统复制的步骤。 如果部署已启用读取的辅助方案，则在第二个节点上设置系统复制时，请以 <HANA SID>adm 身份运行以下命令：
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess
添加辅助虚拟 IP 地址资源
可以使用以下命令设置第二个虚拟 IP 和适当的共置约束：
crm configure property maintenance-mode=true
crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
op monitor interval="10s" timeout="20s" \
params ip="<secondary IP address>"
crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>
crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
msl_SAPHana_<HANA SID>_HDB<instance number>:Slave
crm configure property maintenance-mode=false
确保群集状态为 OK，并且所有资源都已启动。 第二个虚拟 IP 将与 SAPHana 辅助资源一起在辅助站点上运行。
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
# rsc_secip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
# rsc_secnc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
下一部分介绍要执行的一组典型的故障转移测试。
测试配置了已启用读取的辅助实例的 HANA 群集时的注意事项：
将
SAPHana_<HANA SID>_HDB<instance number>群集资源迁移到hn1-db-1时，第二个虚拟 IP 会移到hn1-db-0。 如果已配置AUTOMATED_REGISTER="false"且 HANA 系统复制未自动注册，则第二个虚拟 IP 会在hn1-db-0上运行，因为服务器可用，群集服务处于联机状态。测试服务器故障时，第二个虚拟 IP 资源 (
rsc_secip_<HANA SID>_HDB<instance number>) 和 Azure 负载均衡器端口资源 (rsc_secnc_<HANA SID>_HDB<instance number>) 与主要虚拟 IP 资源一起在主服务器上运行。 当辅助服务器关闭时，连接到启用读取的 HANA 数据库的应用程序将连接到主 HANA 数据库。 此行为是预期行为，因为在辅助服务器不可用时，你不希望连接到已启用读取的 HANA 数据库的应用程序无法访问。当辅助服务器可用且群集服务处于联机状态时，第二个虚拟 IP 和端口资源会自动转移到辅助服务器，即使 HANA 系统复制可能无法注册为辅助服务器。 确保在启动该服务器上的群集服务之前，将辅助 HANA 数据库注册为已启用读取。 可以通过设置参数
AUTOMATED_REGISTER="true"来将 HANA 实例群集资源配置为自动注册辅助副本。在故障转移和回退过程中，使用第二个虚拟 IP 连接到 HANA 数据库的应用程序的现有连接可能会中断。
测试群集设
本部分介绍如何测试设置。 每个测试都假定你已以根身份登录，且 SAP HANA 主实例在 hn1-db-0 VM 上运行。
测试迁移
在开始测试之前，请确保 Pacemaker 没有任何失败的操作（运行 crm_mon -r）、没有任何意外的位置约束（例如迁移测试的遗留内容），并且 HANA 处于同步状态，例如，通过运行 SAPHanaSR-showAttr。
hn1-db-0:~ # SAPHanaSR-showAttr
Sites srHook
----------------
SITE2 SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts clone_state lpa_hn1_lpt node_state op_mode remoteHost roles score site srmode sync_state version vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED 1534159564 online logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150 SITE1 sync PRIM 2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED 30 online logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100 SITE2 sync SOK 2.00.030.00.1522209842 nws-hana-vm-1
通过运行以下命令，可以迁移 SAP HANA 主节点：
crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force
该群集会将 SAP HANA 主节点和包含虚拟 IP 地址的组迁移到 hn1-db-1。
迁移完成后，crm_mon -r 输出如以下示例所示：
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms
当 AUTOMATED_REGISTER="false" 时，群集不会重启失败的 HANA 数据库，也不会针对 hn1-db-0 上的新主数据库注册该数据库。 在这种情况下，请运行以下命令，将 HANA 实例配置为辅助实例：
su - <hana sid>adm
# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
迁移过程将创建位置约束，需要再次删除这些约束：
# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>
此外，还需要清理辅助节点资源的状态：
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
使用 crm_mon -r 监视 HANA 资源的状态。 HANA 在 hn1-db-0 上启动时，输出如以下示例所示：
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
阻止网络通信
开始测试之前的资源状态：
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): 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
当群集节点无法相互通信时，存在脑裂情况的风险。 在这种情况下，群集节点尝试同时相互隔离，从而导致隔离竞赛。
配置隔离设备时，建议配置 pcmk_delay_max 属性。 因此，在脑裂场景中，群集会向每个节点上的隔离操作引入随机延迟，最高为 pcmk_delay_max 值。 将选择延迟最短的节点进行隔离。
此外，为了确保运行 HANA 主资源的节点优先且在脑裂场景中赢得隔离竞赛，建议在群集配置中设置 priority-fencing-delay 属性。 通过启用 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
测试 SBD 隔离
可以通过终止 inquisitor 进程来测试 SBD 的设置：
hn1-db-0:~ # ps aux | grep sbd
root 1912 0.0 0.0 85420 11740 ? SL 12:25 0:00 sbd: inquisitor
root 1929 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root 1930 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root 1931 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root 1932 0.0 0.0 90524 16656 ? SL 12:25 0:00 sbd: watcher: Pacemaker
root 1933 0.0 0.0 102708 28260 ? SL 12:25 0:00 sbd: watcher: Cluster
root 13877 0.0 0.0 9292 1572 pts/0 S+ 12:27 0:00 grep sbd
hn1-db-0:~ # kill -9 1912
<HANA SID>-db-<database 1> 群集节点将重新启动。 Pacemaker 服务可能不会重启。 请确保再次启动它。
测试手动故障转移
可以通过停止 hn1-db-0 节点上的 Pacemaker 服务来测试手动故障转移：
service pacemaker stop
故障转移后，可以再次启动该服务。 如果设置了 AUTOMATED_REGISTER="false"，则 hn1-db-0 节点上的 SAP HANA 资源将无法作为辅助资源启动。
在这种情况下，请运行以下命令，将 HANA 实例配置为辅助实例：
service pacemaker start
su - <hana sid>adm
# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
SUSE 测试
重要
请确保你选择的 OS 已通过 SAP 针对你计划使用的特定 VM 类型上的 SAP HANA 进行的认证。 可以在 SAP HANA 认证的 IaaS 平台中查找 SAP HANA 认证的 VM 类型及其 OS 版本。 请确保查看你计划使用的 VM 类型的详细信息，以获取适用于该 VM 类型的 SAP HANA 支持的 OS 版本的完整列表。
运行“SAP HANA SR 性能优化方案”指南或“SAP HANA SR 成本优化方案”指南中列出的所有测试用例，具体取决于你的方案。 可以在 SLES for SAP 最佳做法中找到列出的指南。
以下测试是“SUSE Linux Enterprise Server for SAP Applications 12 SP1 的 SAP HANA SR 性能优化方案”指南测试说明的副本。 如需最新版本，也请阅读指南本身。 在开始测试之前，请务必确保 HANA 已同步，并确保 Pacemaker 的配置正确。
在以下测试说明中，我们假设 PREFER_SITE_TAKEOVER="true" 和 AUTOMATED_REGISTER="false"。
注意
以下测试按顺序运行。 每个测试取决于前一个测试的退出状态。
测试 1：停止节点 1 上的主数据库。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-0节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stopPacemaker 检测到已停止的 HANA 实例，并故障转移到另一个节点。 完成故障转移后，
hn1-db-0节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。运行以下命令将
hn1-db-0节点注册为辅助节点，并清理已失败的资源：hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1测试 2：停止节点 2 上的主数据库。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1在
hn1-db-1节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stopPacemaker 检测到已停止的 HANA 实例，并故障转移到另一个节点。 完成故障转移后，
hn1-db-1节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。运行以下命令将
hn1-db-1节点注册为辅助节点，并清理已失败的资源：hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0测试 3：在节点 1 上使主数据库崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-0节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker 检测到已终止的 HANA 实例，并故障转移到另一个节点。 完成故障转移后，
hn1-db-0节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。运行以下命令将
hn1-db-0节点注册为辅助节点，并清理已失败的资源：hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1测试 4：在节点 2 上使主数据库崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1在
hn1-db-1节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker 检测到已终止的 HANA 实例，并故障转移到另一个节点。 完成故障转移后，
hn1-db-1节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。运行以下命令将
hn1-db-1节点注册为辅助节点，并清理已失败的资源。hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0测试 5：使主站点节点（节点 1）崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-0节点上以根身份运行以下命令：hn1-db-0:~ # echo 'b' > /proc/sysrq-triggerPacemaker 检测到已终止的群集节点，并隔离该节点。 隔离节点后，Pacemaker 触发 HANA 实例的接管。 重新启动隔离的节点时，Pacemaker 不会自动启动。
运行以下命令以启动 Pacemaker，清理
hn1-db-0节点的 SBD 消息，将hn1-db-0节点注册为辅助节点，并清理失败的资源：# run as root # list the SBD device(s) hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear hn1-db-0:~ # systemctl start pacemaker # run as <hana sid>adm hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1测试 6：使辅助站点节点（节点 2）崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1在
hn1-db-1节点上以根身份运行以下命令：hn1-db-1:~ # echo 'b' > /proc/sysrq-triggerPacemaker 检测到已终止的群集节点，并隔离该节点。 隔离节点后，Pacemaker 触发 HANA 实例的接管。 重新启动隔离的节点时，Pacemaker 不会自动启动。
运行以下命令以启动 Pacemaker，清理
hn1-db-1节点的 SBD 消息，将hn1-db-1节点注册为辅助节点，并清理失败的资源：# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker # run as <hana sid>adm hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0 </code></pre>测试 7：停止节点 2 上的辅助数据库。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-1节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stopPacemaker 检测到已停止的 HANA 实例，并将
hn1-db-1节点上的资源标记为失败。 Pacemaker 自动重启 HANA 实例。运行以下命令来清理失败状态：
# run as root hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0测试 8：使节点 2 上的辅助数据库崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-1节点上以 <hana sid >adm 身份运行以下命令：hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker 检测到已终止的 HANA 实例，并将
hn1-db-1节点上的资源标记为失败。 运行以下命令来清理失败状态。 然后，Pacemaker 自动重启 HANA 实例。# run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0测试 9：使运行辅助 HANA 数据库的辅助站点节点（节点 2）崩溃。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-1节点上以根身份运行以下命令：hn1-db-1:~ # echo b > /proc/sysrq-triggerPacemaker 检测到已终止的群集节点，并已隔离该节点。 重新启动隔离的节点时，Pacemaker 不会自动启动。
运行以下命令启动 Pacemaker，清理
hn1-db-1节点的 SBD 消息，并清理已失败的资源：# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0测试 10：使主数据库索引服务器崩溃
仅当已设置 susChkSrv 挂钩（如实现 HANA 资源代理中所述）时，此测试才相关。
开始测试之前的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0在
hn1-db-0节点上以根身份运行以下命令：hn1-db-0:~ # killall -9 hdbindexserver当索引服务器终止时，susChkSrv 挂钩检测到事件，并触发一个操作来隔离“hn1-db-0”节点并启动接管进程。
运行以下命令将
hn1-db-0节点注册为辅助节点，并清理已失败的资源：# run as <hana sid>adm hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0测试之后的资源状态：
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1可以通过导致辅助节点上的索引服务器崩溃来执行类似的测试用例。 如果索引服务器崩溃，susChkSrv 挂钩将识别这种情况，并启动一个操作来隔离辅助节点。