使用 RHEL HA 附加组件自动化 SAP HANA 放大系统复制
备注：有关如何设置基于 RHEL HA 附加组件的集群，来在 RHEL 8 上管理 SAP HANA 扩展系统复制的指南，请使用 RHEL 8 for SAP Solutions 产品文档中的文档版本：使用 RHEL HA 附加组件自动化 SAP HANA 扩展系统复制。
备注：有关如何设置基于 RHEL HA 附加组件的集群，来在 RHEL 9 上管理 SAP HANA 扩展系统复制的指南，请使用 RHEL 9 for SAP Solutions 产品文档中的文档版本：使用 RHEL HA 附加组件自动化 SAP HANA 扩展系统复制。
内容
- 1.概述
- 2.SAP HANA 系统复制
- 3.在 SAP HANA 中为集群资源代理配置监控帐户(SAP HANA 1.0 SPS12 及更早版本)
- 4.在 pacemaker 集群中配置 SAP HANA
1.概述
本文论述了如何在支持的 RHEL 版本上的 Pacemaker 集群的扩展中配置自动的 HANA 系统复制。
本文不包括为 SAP HANA 安装准备 RHEL 系统，也不包括 SAP HANA 安装流程。有关这些主题的详情，请参阅 SAP Note 2009879 - SAP HANA Guide for Red Hat Enterprise Linux (RHEL)。
1.1.支持的场景
请参阅：RHEL 高可用性集群的支持策略 - 在集群中管理 SAP HANA
1.2.订阅和存储库
需要以下存储库：
RHEL 7.x
- RHEL 服务器：提供 RHEL 内核软件包
- RHEL HA 附加组件：提供 Pacemaker 框架
- RHEL for SAP HANA：为扩展中的 HANA 系统复制自动化提供资源代理
1.2.1.内部或通过云访问自带订阅
对于内部或通过红帽 云访问 自带订阅，要使用的订阅是 RHEL for SAP Solutions。
RHEL 7.x：以下是 RHEL for SAP Solutions 7.6 启用的存储库的示例，内部或通过云访问：
# yum repolist
repo id repo name status
rhel-7-server-e4s-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - Update Services for SAP Solutions (RPMs) 18,929
rhel-ha-for-rhel-7-server-e4s-rpms/7Server/x86_64 Red Hat Enterprise Linux High Availability (for RHEL 7 Server) Update Services for SAP Solutions (RPMs) 437
rhel-sap-hana-for-rhel-7-server-e4s-rpms/7Server/x86_64 RHEL for SAP HANA (for RHEL 7 Server) Update Services for SAP Solutions (RPMs) 38
1.2.2.通过 RHUI 在公有云上按需提供
对于公有云上按需镜像的部署，软件包在 Red Hat Enterprise Linux for SAP with High Availability 和 Update Services 中提供，一个 RHEL for SAP Solutions 的变体，为公有云自定义的，可通过 RHUI 提供。
以下是在具有RHEL for SAP with High Availability 和 Update Services 7.5 的系统上启用的存储库的示例。要在扩展中配置自动的 HANA 系统复制，以下存储库必须存在：
# yum repolist
repo id repo name status
rhui-rhel-7-server-rhui-eus-rpms/7.5/x86_64 Red Hat Enterprise Linux 7 Server - Extended Update Support (RPMs) from RH 21,199
rhui-rhel-ha-for-rhel-7-server-eus-rhui-rpms/7.5/x86_64 Red Hat Enterprise Linux High Availability from RHUI (for RHEL 7 Server) - 501
rhui-rhel-sap-hana-for-rhel-7-server-eus-rhui-rpms/7.5/x86_64 RHEL for SAP HANA (for RHEL 7 Server) Extended Update Support (RPMs) from 43
2.SAP HANA 系统复制
以下示例演示了如何在 2 个运行 SAP HANA 的节点之间设置系统复制。
示例中使用的配置：
SID: RH2
Instance Number: 02
node1 FQDN: node1.example.com
node2 FQDN: node2.example.com
node1 HANA site name: DC1
node2 HANA site name: DC2
SAP HANA 'SYSTEM' user password: <HANA_SYSTEM_PASSWORD>
SAP HANA administrative user: rh2adm
确保两个系统都可以解析这两个系统的 FQDN，而无问题。要确保在没有 DNS 的情况下可以解析 FQDN，您可以将其放在 /etc/hosts 中，如下例所示。
# /etc/hosts
192.168.0.11 node1.example.com node1
192.168.0.12 node2.example.com node2
要使系统复制可以工作，SAP HANA log_mode 变量必须设置为 normal。这可以在两个节点上使用以下命令，以 HANA 系统用户身份进行验证。
[rh2adm]# hdbsql -u system -p <HANA_SYSTEM_PASSWORD> -i 02 "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"
VALUE "normal"
1 row selected
请注意，主和辅助节点的后续配置仅在设置过程中使用。角色（主/辅助）可能会根据集群配置，在集群操作过程中改变。
许多配置步骤是从系统上 SAP HANA 管理用户执行的，用户的名称是在安装过程中选择的。在示例中，我们将使用 rh2adm ，因为我们使用 SID RH2。要成为 SAP HANA 管理用户，您可以使用以下命令：
[root]# sudo -i -u rh2adm
[rh2adm]#
2.1.配置 HANA 主节点
只有在执行了初始备份后，SAP HANA 系统复制才能工作。以下命令将在 /tmp/foo 目录中创建一个初始备份。请注意，备份的大小取决于数据库大小，可能需要一些时间才能完成。将要存放备份的目录必须可被 SAP HANA 管理用户写。
a）在单一容器系统上，可以使用以下命令进行备份：
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "BACKUP DATA USING FILE ('/tmp/foo')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)
b）在多个容器系统(MDC)上，SYSTEMDB 和所有租户数据库需要备份：
以下示例是关于 SYSTEMDB 的备份。请参阅 SAP 文档来了解如何备份租户数据库。
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> -d SYSTEMDB "BACKUP DATA USING FILE ('/tmp/foo')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> -d SYSTEMDB "BACKUP DATA FOR RH2 USING FILE ('/tmp/foo-RH2')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)
在初始备份后，使用以下命令初始化复制。
[rh2adm]# hdbnsutil -sr_enable --name=DC1
checking for active nameserver ...
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.
验证初始化是否显示当前节点为 'primary'，并且 SAP HANA 正在其上运行。
[rh2adm]# hdbnsutil -sr_state
checking for active or inactive nameserver ...
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~
mode: primary
site id: 1
site name: DC1
Host Mappings:
2.2.配置 HANA 辅助节点
辅助节点需要注册到现在运行的主节点。在使用以下命令之前，辅助节点上的 SAP HANA 必须关闭。
[rh2adm]# HDB stop
（仅限 SAP HANA2.0）将 SAP HANA 系统 PKI SSFS_RH2.KEY 和 SSFS_RH2.DAT 文件从主节点复制到辅助节点。
[rh2adm]# scp root@node1:/usr/sap/RH2/SYS/global/security/rsecssfs/key/SSFS_RH2.KEY /usr/sap/RH2/SYS/global/security/rsecssfs/key/SSFS_RH2.KEY
[rh2adm]# scp root@node1:/usr/sap/RH2/SYS/global/security/rsecssfs/data/SSFS_RH2.DAT /usr/sap/RH2/SYS/global/security/rsecssfs/data/SSFS_RH2.DAT
要注册辅助节点，请使用以下命令。
[rh2adm]# hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=02 --replicationMode=syncmem --name=DC2
adding site ...
checking for inactive nameserver ...
nameserver node2:30201 not responding.
collecting information ...
updating local ini files ...
done.
在辅助节点上启动 SAP HANA。
[rh2adm]# HDB start
验证辅助节点是否正在运行，且 'mode' 是否为 syncmem。输出应类似以下输出。
[rh2adm]# hdbnsutil -sr_state
checking for active or inactive nameserver ...
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~
mode: syncmem
site id: 2
site name: DC2
active primary site: 1
Host Mappings:
~~~~~~~~~~~~~~
node2 -> [DC1] node1
node2 -> [DC2] node2
2.3.测试 SAP HANA 系统复制
要手动测试 SAP HANA 系统复制设置，您可以按照以下 SAP 文档中描述的流程操作：
- SAP HANA 1.0：章节“8测试" - 如何为 SAP HANA 1.0 执行系统复制指南
- SAP HANA 2.0：章节 "9.测试" - 如何为 SAP HANA 2.0 执行系统复制指南
2.4.检查 SAP HANA 系统复制状态
要检查 SAP HANA System Replication 的当前状态，您可以以 SAP HANA 管理用户身份在当前主 SAP HANA 节点上执行以下命令。
在 single_container 系统上：
[rh2adm]# python /usr/sap/RH2/HDB02/exe/python_support/systemReplicationStatus.py
| 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 |
| ----- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
| node1 | 30201 | nameserver | 1 | 1 | DC1 | node2 | 30201 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| node1 | 30207 | xsengine | 2 | 1 | DC1 | node2 | 30207 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| node1 | 30203 | indexserver | 3 | 1 | DC1 | node2 | 30203 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
status system replication site "2": ACTIVE
overall system replication status: ACTIVE
Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mode: PRIMARY
site id: 1
site name: DC1
在 multiple_containers 系统(MDC)上：
[rh2adm]# python /usr/sap/RH2/HDB02/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 | node1 | 30201 | nameserver | 1 | 1 | DC1 | node2 | 30201 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| RH2 | node1 | 30207 | xsengine | 2 | 1 | DC1 | node2 | 30207 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| RH2 | node1 | 30203 | indexserver | 3 | 1 | DC1 | node2 | 30203 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
status system replication site "2": ACTIVE
overall system replication status: ACTIVE
Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mode: PRIMARY
site id: 1
site name: DC1
3.在 SAP HANA 中为集群资源代理配置监控帐户(SAP HANA 1.0 SPS12 及更早版本)
不再需要从 SAP HANA 2.0 SPS0 监控帐户开始
具有 CATALOG READ 和 MONITOR ADMIN 特权的技术用户必须在 SAP HANA 中存在，以便资源代理能够对系统复制状态运行查询。以下示例演示了如何创建这样的用户，为其分配正确的权限，并为此用户禁用密码过期。
monitoring user username: rhelhasync
monitoring user password: <MONITORING_USER_PASSWORD>
3.1.创建监控用户
当 SAP HANA 系统复制处于活跃状态时，只有主系统可以访问数据库。访问辅助系统将失败。
在主系统上，运行以下命令来创建监控用户。
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "create user rhelhasync password \"<MONITORING_USER_PASSWORD>\""
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "grant CATALOG READ to rhelhasync"
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "grant MONITOR ADMIN to rhelhasync"
[rh2adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "ALTER USER rhelhasync DISABLE PASSWORD LIFETIME"
3.2.在所有节点上存储监控用户凭证
SAP HANA userkey 允许 OS 级别上的"root"用户通过监控用户访问 SAP HANA，而无需密码。资源代理需要这一点，以便它们可以对 HANA 系统复制状态运行查询。
[root]# /usr/sap/RH2/HDB02/exe/hdbuserstore SET SAPHANARH2SR localhost:30215 rhelhasync "<MONITORING_USER_PASSWORD>"
要验证 userkey 是否已在 root 的 userstore 中正确创建了，您可以在每个节点上运行 hdbuserstore list 命令，并检查监控帐户是否在输出中存在，如下所示：
[root]# /usr/sap/RH2/HDB02/exe/hdbuserstore list
DATA FILE : /root/.hdb/node1/SSFS_HDB.DAT
KEY FILE : /root/.hdb/node1/SSFS_HDB.KEY
KEY SAPHANARH2SR
ENV : localhost:30215
USER: rhelhasync
另外，请通过在 SAP HANA SR 设置的主节点上运行以下命令，来验证是否可以使用 SAPHANA
[root]# /usr/sap/RH2/HDB02/exe/hdbsql -U SAPHANARH2SR -i 02 "select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION"
REPLICATION_STATUS
"ACTIVE"
1 row selected
如果您收到有关密码问题的错误消息，或者提示您输入密码，请使用 hdbsql 命令或 HANA Studio 验证上面使用 hdbsql 命令创建的用户的密码没有被配置为 'to be changed on first login'，或者密码尚未过期。您可以使用以下命令。
（注：确保使用大写的监控用户的名称）
[root]# /usr/sap/RH2/HDB02/exe/hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "select * from sys.users where USER_NAME='RHELHASYNC'"
USER_NAME,USER_ID,USER_MODE,EXTERNAL_IDENTITY,CREATOR,CREATE_TIME,VALID_FROM,VALID_UNTIL,LAST_SUCCESSFUL_CONNECT,LAST_INVALID_CONNECT_ATTEMPT,INVALID_CONNECT_A
TTEMPTS,ADMIN_GIVEN_PASSWORD,LAST_PASSWORD_CHANGE_TIME,PASSWORD_CHANGE_NEEDED,IS_PASSWORD_LIFETIME_CHECK_ENABLED,USER_DEACTIVATED,DEACTIVATION_TIME,IS_PASSWORD
_ENABLED,IS_KERBEROS_ENABLED,IS_SAML_ENABLED,IS_X509_ENABLED,IS_SAP_LOGON_TICKET_ENABLED,IS_SAP_ASSERTION_TICKET_ENABLED,IS_RESTRICTED,IS_CLIENT_CONNECT_ENABLE
D,HAS_REMOTE_USERS,PASSWORD_CHANGE_TIME
"RHELHASYNC",156529,"LOCAL",?,"SYSTEM","2017-05-12 15:10:49.971000000","2017-05-12 15:10:49.971000000",?,"2017-05-12 15:21:12.117000000",?,0,"TRUE","2017-05-12
15:10:49.971000000","FALSE","FALSE","FALSE",?,"TRUE","FALSE","FALSE","FALSE","FALSE","FALSE","FALSE","TRUE","FALSE",?
1 row selected
4.在 pacemaker 集群中配置 SAP HANA
请参阅以下文档来首先建立一个 pacemaker 集群。请注意，集群必须符合文章 RHEL 高可用性集群的支持策略 - 隔离/STONITH 的通用要求。
本指南假定以下事项工作正常：
- Pacemaker 集群按照文档进行了配置，并有适当和正常的隔离
- 在所有集群节点上禁用在引导时启动 SAP HANA ，因为启动和停止将由集群管理
- SAP HANA 系统复制和使用 SAP 工具的接管在集群节点之间工作正常
- 两个节点都已订阅了所需的通道：
- RHEL 7:'high-availability' 和 'RHEL for SAP HANA'(https://access.redhat.com/solutions/2334521)通道
4.1.使用 RHEL HA 附加组件安装管理 SAP HANA 扩展系统复制所需的资源代理和其他组件
[root]# yum install resource-agents-sap-hana
注 ：这将只安装建立此 HA 解决方案所需的资源代理和其他组件。对于红帽支持的完全可操作的设置，仍必须执行以下部分中记录的配置步骤。
4.2.启用 SAP HANA srConnectionChanged（）钩子
如 SAP 的 实施 HA/DR 提供者 中所述，SAP HANA 的最新版本提供所谓的"钩子"，允许 SAP HANA 为特定事件发送通知。srConnectionChanged（） 钩子可用于改进集群检测 HANA 系统复制状态中发生变化时，需要集群采取行动的能力，并通过防止在应该避免的情况下触发意外接管来避免数据丢失/数据损坏。当使用 SAP HANA 2.0 SPS0 或更高版本，以及为支持 srConnectionChanged（） 钩子提供组件的 resource-agents-sap-hana 版本时，需要在继续进行集群设置之前启用钩子。
4.2.1.验证是否安装了 resource-agents-sap-hana 软件包的版本，它提供启用 srConnectionChanged（）钩子的组件
请验证是否安装了为 RHEL 版本提供启用 srConnectionChanged（） 钩子所需组件的 resource-agents-sap-hana 软件包的正确版本，如以下文章中所述：srConnectionChanged （）钩子支持用于 SAP HANA 扩展系统复制的红帽高可用性解决方案吗？
4.2.2.在所有 SAP HANA 实例上激活 srConnectionChanged（）钩子
注意 ：需要为每个 SAP HANA 实例激活 srConnectionChanged（） 钩子的步骤。
-
在两个节点上停止集群，并验证 HANA 实例是否已完全停止。
[root]# pcs cluster stop --all -
将钩子脚本安装到每个 HANA 实例的
/hana/shared/myHooks目录中，并确保它在所有节点上有正确的所有权（将rh2adm替换为 HANA 实例的 admin 用户的用户名）。[root]# mkdir -p /hana/shared/myHooks [root]# cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks [root]# chown -R rh2adm:sapsys /hana/shared/myHooks -
更新每个节点上的
global.ini文件，以使两个 HANA 实例都可以使用钩子脚本（例如，在文件/hana/shared/RH2/global/hdb/custom/config/global.ini中）：[ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /hana/shared/myHooks execution_order = 1 [trace] ha_dr_saphanasr = info -
在每个集群节点上，通过运行
sudo visudo -f /etc/sudoers.d/20-saphana创建文件/etc/sudoers.d/20-saphana，并添加以下内容，以允许钩子脚本在srConnectionChanged（）钩子被调用时更新节点属性。
将rh2替换为您的 HANA 安装的小写 SID，并将DC1和DC2替换为您的 HANA 站点名称。Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_rh2_site_srHook_DC1 -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_rh2_site_srHook_DC1 -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_rh2_site_srHook_DC2 -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_rh2_site_srHook_DC2 -v SFAIL -t crm_config -s SAPHanaSR rh2adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty有关为什么需要
Defaults设置的更多信息，请参阅 管理 SAP HANA 系统复制的 Pacemaker 集群中的 srHook 属性被设置为 SFAIL，即使复制处于健康状态。 -
手动启动这两个 HANA 实例，而不启动集群。
-
验证钩子脚本是否按预期工作。执行一些操作来触发钩子，如停止 HANA 实例。然后，使用如下方法检查钩子是否记录了任何内容。
[rh2adm]# cdtrace [rh2adm]# awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_* 2018-05-04 12:34:04.476445 ha_dr_SAPHanaSR SFAIL 2018-05-04 12:53:06.316973 ha_dr_SAPHanaSR SOK [rh2adm]# grep ha_dr_ *备注：如需更多信息，请参阅 SAP 文档 安装和配置 HA/DR 提供者脚本。
-
验证了钩子的功能后，可以再次启动集群。
[root]# pcs cluster start --all
4.3.配置常规集群属性
为了避免在初始测试和后期生产过程中资源的不必要故障转移，请为 resource-stickiness 和 migration-threshold 参数设置以下默认值：请注意，默认值不适用于使用自己的定义值覆盖它们的资源。
[root]# pcs resource defaults resource-stickiness=1000
[root]# pcs resource defaults migration-threshold=5000
备注 ：
1.在集群的一个节点上运行上述命令就足够了。
2.本文档的早期版本推荐为集群设置的初始测试设置这些默认值，但在生产后删除它们。由于客户反馈和其他测试，已确定对生产环境集群设置使用这些默认设置也是有益的。
3.命令 resource-stickiness=1000 将鼓励资源在其所在的位置运行，而 migration-threshold=5000 将导致资源在 5000 次失败后移至新节点。5000 通常足以防止资源过早故障转移到另一个节点。这也可确保资源故障切换时间保持在可控制的限制内。
本指南的之前版本建议将 no-quorum-policy 设置为 ignore，但当前还不支持。在默认配置中，集群的 no-quorum policy 属性不需要修改。要实现此选项提供的行为，请参阅 在 RHEL 6 或 7 中丢失仲裁后，是否可以配置 pacemaker ，来继续管理资源？
4.4.创建克隆的 SAPHanaTopology 资源
SAPHanaTopology 资源收集每个节点上 SAP HANA 系统复制的状态和配置。另外，它启动并监控本地 SAP HostAgent，这是启动、停止和监控 SAP HANA 实例所需要的。它有以下属性：
| 属性名称 | 必需？ | 默认值 | 描述 |
|---|---|---|---|
| SID | 是 | null | SAP HANA 安装的 SAP System Identifier (SID)（对于所有节点都必须一样）。例如：RH2 |
| InstanceNumber | 是 | null | SAP HANA 安装的实例号（对于所有节点必须一样）。例如：02 |
以下是创建 SAPHanaTopology 克隆资源的一个命令示例。
注意 ：下面显示的资源操作的超时只是示例，可能需要根据实际的 SAP HANA 设置（例如，大型 HANA 数据库可能需要更长的时间才能启动，因此可能需要增加启动超时）。
[root]# pcs resource create SAPHanaTopology_RH2_02 SAPHanaTopology SID=RH2 InstanceNumber=02 \
op start timeout=600 \
op stop timeout=300 \
op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true
生成的资源应类似如下：
[root]# pcs resource show SAPHanaTopology_RH2_02-clone
Clone: SAPHanaTopology_RH2_02-clone
Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
Resource: SAPHanaTopology_RH2_02 (class=ocf provider=heartbeat type=SAPHanaTopology)
Attributes: SID=RH2 InstanceNumber=02
Operations: start interval=0s timeout=600 (SAPHanaTopology_RH2_02-start-interval-0s)
stop interval=0s timeout=300 (SAPHanaTopology_RH2_02-stop-interval-0s)
monitor interval=10 timeout=600 (SAPHanaTopology_RH2_02-monitor-interval-10s)
启动资源后，您将看到以节点属性形式存储的信息，可通过命令 crm_mon -A1 进行查看。以下是在仅启动 SAPHanaTopology 时，属性看起来是什么样子的示例。
[root]# crm_mon -A1
...
Node Attributes:
* Node node1:
+ hana_rh2_remoteHost : node2
+ hana_rh2_roles : 1:P:master1::worker:
+ hana_rh2_site : DC1
+ hana_rh2_srmode : syncmem
+ hana_rh2_vhost : node1
* Node node2:
+ hana_rh2_remoteHost : node1
+ hana_rh2_roles : 1:S:master1::worker:
+ hana_rh2_site : DC2
+ hana_rh2_srmode : syncmem
+ hana_rh2_vhost : node2
...
4.5.创建主/从 SAPHana 资源
SAPHana 资源代理管理 HANA 系统复制中配置的两个 SAP HANA 实例（数据库）。
| 属性名称 | 必需？ | 默认值 | 描述 |
|---|---|---|---|
| SID | 是 | null | SAP HANA 安装的 SAP System Identifier (SID)（对于所有节点都必须一样）。例如：RH2 |
| InstanceNumber | 是 | null | SAP HANA 安装的实例号（对于所有节点必须一样）。例如：02 |
| PREFER_SITE_TAKEOVER | 否 | null | 资源代理应希望切换到辅助实例，而不是在本地重启主实例？true ：更倾向于接管到辅助站点；false: : : 更倾向于在本地重启；never：在任何情况下都不要接管到另一个节点。 |
| AUTOMATED_REGISTER | 否 | false | 如果发生了接管事件，并且 DUPLICATE_PRIMARY_TIMEOUT 已过期，则之前的主实例应被注册为辅助实例？("false": 不, 需要手动干预; "true": 是的,之前的主实例将被资源代理注册为辅助实例)[1] |
| DUPLICATE_PRIMARY_TIMEOUT | 否 | 7200 | 如果发生了 dual-primary 情况，则在两个主时间戳之间需要时间差（以秒为单位）。如果时间差小于时间间隔，集群将把一个或多个实例保持在"WAITING"状态。这是为了让系统管理员有机会对接管做出反应。在传递了时间差后，如果 AUTOMATED_REGISTER 被设为 true，则失败的前主实例将注册为辅助实例。在注册新主实例后，前主实例上的所有数据都将被系统复制覆盖。 |
[1] - 作为测试和 PoC 的良好实践，我们建议让 AUTOMATED_REGISTER 保持其默认值 （AUTOMATED_REGISTER_REGISTER="false"），以防止失败的主实例自动注册为辅助实例。测试后，如果故障转移场景按预期工作，特别是对于生产环境中，那么我们建议设置 AUTOMATED_REGISTER="true"，以便在接管后，系统复制将及时恢复，以避免中断。当 AUTOMATED_REGISTER="false" 时，如果在主节点上失败，调查后，您需要手动将其注册为辅助 HANA 系统复制节点。
注意 ：
- 以下显示的资源操作的超时只是示例，可能需要根据实际的 SAP HANA 设置（例如，大型 HANA 数据库可能需要更长时间才能启动，因此可能需要增加启动超时）进行调整。
4.5.1.RHEL 7.x
以下是一个创建 SAPHana 主/从资源的命令的示例。
[root]# pcs resource create SAPHana_RH2_02 SAPHana SID=RH2 InstanceNumber=02 \
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 meta notify=true clone-max=2 clone-node-max=1 interleave=true
RHEL 7.x 在运行 pcs-0.9.158-6.el7 或更高版本时使用以下命令避免弃用警告。有关更改的更多信息，在 pcs resource create 命令中 master 和 --master 选项之间的区别是什么？ 中进行了解释。
[root]# pcs resource create SAPHana_RH2_02 SAPHana SID=RH2 InstanceNumber=02 \
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
生成的资源应类似如下：
[root]# pcs resource show SAPHana_RH2_02-master
Master: SAPHana_RH2_02-master
Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
Resource: SAPHana_RH2_02 (class=ocf provider=heartbeat type=SAPHana)
Attributes: AUTOMATED_REGISTER=false DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=02 PREFER_SITE_TAKEOVER=true SID=RH2
Operations: demote interval=0s timeout=3600 (SAPHana_RH2_02-demote-interval-0s)
methods interval=0s timeout=5 (SAPHana_RH2_02-methods-interval-0s)
monitor interval=61 role=Slave timeout=700 (SAPHana_RH2_02-monitor-interval-61)
monitor interval=59 role=Master timeout=700 (SAPHana_RH2_02-monitor-interval-59)
promote interval=0s timeout=3600 (SAPHana_RH2_02-promote-interval-0s)
start interval=0s timeout=3600 (SAPHana_RH2_02-start-interval-0s)
stop interval=0s timeout=3600 (SAPHana_RH2_02-stop-interval-0s)
资源启动后，它将添加描述节点上 SAP HANA 数据库当前状态的其它节点属性，如下所示。
[root]# crm_mon -A1
...
Node Attributes:
* Node node1:
+ hana_rh2_clone_state : PROMOTED
+ hana_rh2_op_mode : delta_datashipping
+ hana_rh2_remoteHost : node2
+ hana_rh2_roles : 4:S:master1:master:worker:master
+ hana_rh2_site : DC1
+ hana_rh2_sync_state : PRIM
+ hana_rh2_srmode : syncmem
+ hana_rh2_vhost : node1
+ lpa_rh2_lpt : 1495204085
+ master-hana : 150
* Node node2:
+ hana_rh2_clone_state : DEMOTED
+ hana_rh2_remoteHost : node1
+ hana_rh2_roles : 4:P:master1:master:worker:master
+ hana_rh2_site : DC2
+ hana_rh2_srmode : syncmem
+ hana_rh2_sync_state : SOK
+ hana_rh2_vhost : node2
+ lpa_rh2_lpt : 30
+ master-hana : 100
...
4.6.创建虚拟 IP 地址资源
集群将包含虚拟 IP 地址，以访问 SAP HANA 的主实例。以下是创建 IP 为 192.168.0.15 的 IPaddr2 资源的命令的示例。
[root]# pcs resource create vip_RH2_02 IPaddr2 ip="192.168.0.15"
生成的资源应类似如下：
[root]# pcs resource show vip_RH2_02
Resource: vip_RH2_02 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=192.168.0.15
Operations: start interval=0s timeout=20s (vip_RH2_02-start-interval-0s)
stop interval=0s timeout=20s (vip_RH2_02-stop-interval-0s)
monitor interval=10s timeout=20s (vip_RH2_02-monitor-interval-10s)
4.7.创建约束
为了进行正确的操作，我们需要确保在启动 SAPHana 资源之前启动 SAPHanaTopology 资源，并且虚拟 IP 地址也在运行 SAPHana 的主资源的节点上存在。要达到此目的，需要创建以下 2 个约束。
4.7.1 RHEL 7.x
4.7.1.1 约束 - 在 SAPHana 之前启动 SAPHanaTopology
以下示例命令将创建强制这些资源启动顺序的约束。这里有 2 个值得提及的事情：
symmetrical=false属性定义我们只关注资源的启动，不需要以相反的顺序停止它们。- 两个资源(
SAPHana和SAPHanaTopology)都有属性interleave=true，它允许在节点上并行启动这些资源。这允许，不管什么顺序，我们都不会等待所有节点启动SAPHanaTopology，但只要SAPHanaTopology在任何节点上运行，我们就可以启动SAPHana资源。
创建约束的命令：
[root]# pcs constraint order SAPHanaTopology_RH2_02-clone then SAPHana_RH2_02-master symmetrical=false
生成的约束应类似以下示例。
[root]# pcs constraint
...
Ordering Constraints:
start SAPHanaTopology_RH2_02-clone then start SAPHana_RH2_02-master (kind:Mandatory) (non-symmetrical)
...
4.7.1.2 约束 - 将 IPaddr2 资源与 SAPHana 资源共存
以下是一个示例命令，它将 IPaddr2 资源与被提升为主资源的 SAPHana 资源共存。
[root]# pcs constraint colocation add vip_RH2_02 with master SAPHana_RH2_02-master 2000
请注意，约束使用的是 2000 分，而不是默认的 INFINITY。这允许在 SAPHana 资源中没有提升的主资源时，IPaddr2 资源被集群关闭，因此仍然可以将此地址与 SAP 管理控制台或 SAP LVM 等工具一起使用，这些工具可以使用这个地址来查询有关 SAP 实例的状态信息。
生成的约束应类似如下示例。
[root]# pcs constraint
...
Colocation Constraints:
vip_RH2_02 with SAPHana_RH2_02-master (score:2000) (rsc-role:Started) (with-rsc-role:Master)
...
4.8.为 Active/Active (Read-Enabled) HANA 系统复制设置添加辅助虚拟 IP 地址
从 SAP HANA 2.0 SPS1 开始，SAP 为 SAP HANA 系统复制启用 'Active/Active (Read Enabled)' 设置，其中 SAP HANA 系统复制的辅助系统可以主动用于读密集型工作负载。为了能够支持此类设置，需要辅助虚拟 IP 地址，其使客户端能够访问辅助 SAP HANA 数据库。为确保在发生接管后辅助复制站点仍然可以被访问，集群需要将虚拟 IP 地址与主/从 SAPHana 资源一起移动。
请注意，当为启用了读的辅助配置建立 HSR 时，operationMode 应设置为 logreplay_readaccess。
4.8.1.创建管理辅助虚拟 IP 地址的资源
[root]# pcs resource create vip2_RH2_02 IPaddr2 ip="192.168.1.11"
请根据集群运行的平台，使用适当的资源代理来管理 IP 地址。
4.8.2.创建位置约束，以确保辅助虚拟 IP 地址被放在正确的集群节点上
[root]# pcs constraint location vip2_RH2_02 rule score=INFINITY hana_rh2_sync_state eq SOK and hana_rh2_roles eq 4:S:master1:master:worker:master
[root]# pcs constraint location vip2_RH2_02 rule score=2000 hana_rh2_sync_state eq PRIM and hana_rh2_roles eq 4:P:master1:master:worker:master
这些位置约束确保辅助虚拟 IP 资源具有以下行为：
-
如果有一个 Master/PRIMARY 节点和一个 Slave/SECONDARY 节点，两者都可用，且 HANA 系统复制为 "SOK"，则辅助虚拟 IP 将在 Slave/SECONDARY 节点上运行。
-
如果 Slave/SECONDARY 节点不可用，或者 HANA System Replication 不是 "SOK"，则辅助虚拟 IP 将在 Master/PRIMARY 节点上运行。当 Slave/SECONDARY 将为可用，且 HANA System Replication 将再次为 "SOK" 时，辅助虚拟 IP 将移回到 Slave/SECONDARY 节点上。
-
如果 Master/PRIMARY 节点不可用，或者上面运行的 HANA 实例有问题时，当 Slave/SECONDARY 将接管 Master/PRIMARY 角色时，辅助虚拟 IP 将继续在同一节点上运行，直到其他节点将接管 Slave/SECONDARY 角色，且 HANA 系统复制将是"SOK"。
这最大化了辅助虚拟 IP 资源将被分配给运行健康 SAP HANA 实例的节点的时间。
4.9.测试将 SAPHana 资源的手动移动到另一节点（SAP Hana 被集群接管）
测试将 SAPHana 资源从一个节点移动到另一个节点
4.9.1.在 RHEL 7 上移动 SAPHana 资源
在 RHEL 7 上使用以下命令。请注意，由于 SAPHana 资源内部工作的方式，运行以下命令时 不 应使用选项 --master 。
[root]# pcs resource move SAPHana_RH2_02-master
使用每个 pcs resource move 命令调用，集群创建导致资源移动的位置约束。在验证了 HANA 系统复制接管已完成后，必须删除这些约束，以便允许集群可以再次管理前主 HANA 实例。要删除 move 创建的约束，请运行以下命令。
[root]# pcs resource clear SAPHana_RH2_02-master
Comments