本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 概念


## SAP – SAP HANA 和 Hana 系统复制


SAP HANA 是内存中面向列的关系数据库管理系统，由 SAP 开发。它使用 HANA 系统复制（HSR），将数据和更改从主系统复制到一个或多个辅助系统。在横向扩展部署中，这种复制发生在主系统和辅助系统的对应节点之间，每项服务在辅助系统中都有对应的服务。HSR 确保持续复制更改，从而最大限度地减少恢复点目标（RPO）。虽然您可以使用 HANA 工具手动触发接管，但添加 Pacemaker 集群后，可通过监控、编排以及与用于硬件连接和管理的资源代理集成，来实现失效转移过程的自动化。

## Amazon— 可用区


可用区是一个或多个独立的数据中心，在一个Amazon区域内具有冗余电源、网络和连接。有关更多信息，请参阅区域和可用区。

对于以最小化恢复时间目标 (RTO) 为目标的 SAP 关键任务部署，我们建议将单点故障分散到可用区。Amazon与单实例或单可用区部署相比，这可以增强韧性，实现更好的隔离，可以防范包括自然灾害在内的各种故障场景和问题。

各个可用区之间相隔合理的距离（数千米）。一个Amazon区域中的所有可用区域通过完全冗余的专用城域光纤与高带宽、低延迟的网络重新互连。这样可以实现同步复制。可用区之间的所有流量都是加密的。

## Amazon— 覆盖 IP


重叠 IP 用于实现与应用程序的连接，无论活动主节点包含在哪个可用区（和子网）中。

在中部署 Amazon EC2 实例时Amazon，IP 地址是从所分配子网的 CIDR 范围中分配的。子网不能跨越多个可用区，因此在出现故障后（包括网络连接或硬件问题），子网 IP 地址可能不可用，需要失效转移到不同可用区中的复制目标。

为了解决这个问题，我们建议您配置重叠 IP，并在应用程序的连接参数中使用它。此 IP 地址是来自 VPC CIDR 块之外的非重叠 RFC1918 私有 IP 地址，被配置为一个或多个路由表中的一个条目。该路由将连接定向到活动的节点，并在失效转移期间由集群软件更新。

您可以为叠加 IP 地址选择以下任意一个 RFC1918 私有 IP 地址：
+ 10.0.0.0 - 10.255.255.255（10/8 前缀）
+ 172.16.0.0 - 172.31.255.255（172.16/12 前缀）
+ 192.168.0.0 - 192.168.255.255（192.168/16 前缀）

例如，如果您在 SAP VPC 中使用 10/8 前缀，则可以选择 172 或 192 IP 地址来区分重叠 IP。考虑使用诸如 Amazon VPC IP 地址管理器之类的 IP 地址管理 (IPAM) 工具来规划、跟踪和监控工作负载的 IP 地址。Amazon有关更多信息，请参阅[什么是 IPAM？](https://docs.amazonaws.cn/vpc/latest/ipam/what-it-is-ipam.html) 

在子网关联或连接有需要时，您也可以对集群中的重叠 IP 代理进行配置，来更新包含重叠 IP 条目的多个路由表。

### 访问重叠 IP


叠加 IP 不在 VPC 的范围内，因此无法从与路由表无关的地点（包括本地和其他位置）到达 VPCs。

使用 T Amazon ransit Gateway 作为中心枢纽，使用 Di Amazon rect Connect 或 C Amazon lient VPN，便于从多个位置（包括亚马逊 VPCs、其他Amazon地区和本地）连接到叠加 IP 地址。

如果您未将 T Amazon ransit Gateway 设置为网络交通枢纽，或者在您的首选Amazon区域不可用，则可以使用网络负载均衡器来启用对叠加 IP 的网络访问。

有关更多信息，请参阅 [SAP 关于 Amazon 高可用性设置](sap-oip-sap-on-aws-high-availability-setup.md)。

## Amazon— 共享 VPC


企业登录区设置或安全要求可能需要使用单独的集群账户，将对重叠 IP 所需的路由表访问权限限制为隔离账户。有关更多信息，请参阅[与其他账户共享 VPC](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-sharing.html)。

在设置共享 VPC 之前，请评估该操作对安全态势的影响。

## Pacemaker – STONITH 隔离代理


在 SAP HANA 部署中，无论是在纵向扩展配置（双节点）还是横向扩展配置（每个站点两个或更多节点）中，通过确保在任何给定时间只有指定的一个或多个主节点才能处理写入操作来保持数据一致性，这一点至关重要。当节点变成无响应或无法通信时，为了保持数据一致性，可能需要在集群开始其他操作（例如提升新的主节点）之前关闭故障节点的电源，将其隔离。此仲裁是隔离代理的职责。

在双节点纵向扩展场景中，需要考虑隔离竞赛问题。当通信故障导致两个节点均认为另一个节点已经出现故障并同时尝试隔离（断电）对方时，就会发生这种情况。隔离代理通过提供外部见证方来应对这种风险。在横向扩展部署中，虽然由于有多个节点可以参与仲裁决策，因此出现隔离竞赛的可能性较小，但在大型节点集中，妥善的隔离机制对于保持数据一致性仍然至关重要。

红帽支持多种屏蔽代理，包括推荐用于亚马逊 EC2 实例的屏蔽代理 (fence\$1aws)。