本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# SAP HANA 系统复制
SAP HANA 系统复制是 SAP 为 SAP HANA 提供的高可用性解决方案。SAP HANA 系统复制用于在进行计划内维护、出现故障和灾难时，减少所导致的 SAP HANA 停机时间。在系统复制中，辅助 SAP HANA 系统是活动主系统的完全相同副本，每个系统中的活动主机数量相等。主系统中的每项服务都与其辅助系统中的对等服务进行通信，并在实时复制模式下运行，从而复制数据和日志并加以保存，通常还会将数据加载到内存中。Amazon 完全支持 SAP HANA 系统复制。
**Topics**
+ [架构模式](#hsr-patterns)
+ [复制和操作模式](#hsr-modes)
+ [配置方案](#hsr-configuration-scenarios)
+ [接管注意事项](#hsr-takeover)
## 架构模式
Amazon 通过区域和可用区在地理位置上隔离设施。多可用区架构可以保持性能，同时降低位置故障的风险。
使用单区域多可用区模式，辅助系统可以安装在与主系统属于同一 Amazon 区域的不同可用区中。这为计划内停机时间、管理存储损坏或其他任何本地故障提供了快速失效转移解决方案。
对于灾难恢复，您可以使用多区域架构模式，将辅助系统安装在不同的 Amazon 区域。您可以根据业务要求选择区域，例如合规性所要求的数据驻留限制。
有关更多信息，请参阅 [Amazon 云端 SAP HANA 架构模式](https://docs.amazonaws.cn/sap/latest/sap-hana/hana-ops-patterns.html)。
## 复制和操作模式
SAP HANA 系统复制功能提供 Amazon 云端完全支持的以下复制和操作模式。
**复制模式**
根据恢复时间目标和恢复点目标，您可以使用不同的复制模式选项来复制重做日志，包括磁盘上同步复制、内存中同步复制和异步复制。对于多可用区部署，建议使用同步 SAP HANA 系统复制，以确保接近零的恢复点目标。Amazon 在一个区域内的不同可用区之间提供低延迟和高带宽连接。
对于跨 Amazon 区域的系统复制，建议使用异步复制。如果您的业务需求不会受到潜在网络延迟的影响，则可以选择多区域架构模式。您还必须考虑不同区域中 Amazon 服务成本和跨区域数据传输。
**操作模式**
注册辅助 SAP HANA 系统时可以使用不同的操作模式，例如 `delta_datashipping`、`logreplay` 或 `logreplay_readaccess`。数据库相应地将不同类型的数据包发送到辅助系统。
## 配置方案
SAP HANA 系统复制功能支持 Amazon 云端完全支持的以下配置方案。
**Topics**
+ [主动/被动辅助系统](#hsr-active-passive-secondary)
+ [主动/主动（启用读取）辅助系统](#hsr-active-active-read-secondary)
+ [SAP HANA 辅助时间旅行](#hsr-secondary-time-travel)
+ [Amazon 云端的 SAP HANA 复制场景](#hsr-hana-replication-aws)
+ [SAP HANA 多层复制](#hsr-multi-tier)
+ [SAP HANA 多目标复制](#hsr-multi-target)
### 主动/被动辅助系统
在此场景中，通过接管过程将活动系统从当前的主系统切换到辅助系统之前，系统复制功能不允许对辅助系统进行读取访问或 SQL 查询。辅助系统在 `logreplay` 操作模式下充当热备用系统。
### 主动/主动（启用读取）辅助系统
在此场景中，系统复制功能支持对辅助系统的读取访问。它需要 `logreplay_readaccess` 操作模式。
### SAP HANA 辅助时间旅行
在此场景中，您可以访问在主系统中已删除的数据，或者在辅助系统中有意延迟 `logreplay` 操作（这样就可以读取较早的数据），同时继续在辅助系统上进行复制。您能够以更快的恢复速度从逻辑错误中恢复。您只能在 `logreplay` 操作模式下使用辅助时间旅行配置。
您必须正确调整辅助时间旅行内存实例的大小，以便进行复制。对于 `logreplay` 操作模式，最低内存要求是使用行存储大小、列存储内存大小和预加载的 50 GB 内存。有关更多信息，请参阅 [SAP Note 1999880 - FAQ: SAP HANA System Replication](https://me.sap.com/notes/1999880)。以下参数必须进行设置。
+ 辅助系统上必须配置“global.ini/[system\_replication]/timetravel\_max\_retention\_time”参数。此参数定义辅助系统可以恢复到过去的时间段。
+ “global.ini/[system\_replication]/timetravel\_snapshot\_creation\_interval”是可选参数。您可以调整辅助系统的快照创建过程。辅助系统可以开始保留日志和快照。
下图显示了 SAP HANA 辅助时间旅行配置场景。
### Amazon 云端的 SAP HANA 复制场景
在两层 SAP HANA 系统复制中，Amazon 云端的部署会针对性能或成本进行优化。要获得最快的接管速度，请使用与主实例大小相同的辅助实例。这是性能优化型部署。成本优化型部署可以降低总体成本，但会牺牲恢复时间目标。成本优化型场景也称为 Pilot Light 灾难恢复。有关更多信息，请参阅 [Rapidly recover mission-critical systems in a disaster](https://www.amazonaws.cn/blogs/publicsector/rapidly-recover-mission-critical-systems-in-a-disaster/)。
**Topics**
+ [性能优化](#hsr-performance-optimized)
+ [成本优化](#hsr-cost-optimized)
#### 性能优化
不论是遇到计划内停机还是计划外停机，对业务连续性至关重要的 SAP HANA 数据库系统都需要接近零的恢复时间目标。您可以使用与主实例大小相同的辅助实例来优化性能。此配置可以容纳内存中预加载的列式表和同步系统复制。对于此设置，建议不要跨 Amazon 区域托管 SAP HANA 实例。这是为了避免在同步模式下复制时出现延迟。这种部署可以保护您的关键 SAP HANA 系统免受可用区故障的影响，虽然这种情况很少发生。
您可以设置第三方集群解决方案以及 SAP HANA 系统复制，来检测故障并自动进行失效转移。有关更多信息，请参阅 [Pacemaker 集群](https://docs.amazonaws.cn/sap/latest/sap-hana/hana-ops-ha-dr.html#pacemaker-hana-hadr)。下图显示性能优化型部署。
#### 成本优化
您可以使用较小的或共享的辅助 SAP HANA 系统来降低成本。在较小的辅助选项中，基础设施最初的大小要小于主基础设施，并在执行接管之前调整大小。在共享辅助选项中，辅助系统上未使用的内存由非生产或可牺牲实例使用。
对于较小的辅助选项和共享的辅助选项，`preload_column_tables` 参数均设置为 *false*。您可以在位于 `global.ini` 的 `(/hana/shared//global/hdb/custom/config` 文件中找到此参数。将参数设置为 *false* 可使辅助系统在内存减少的情况下运行。但是，`preload_column_tables` 的默认值为 *true*。
**注意**
在成本优化型部署执行接管之前，`preload_column_tables` 参数必须设置为默认值 *true* 并重新启动 SAP HANA 系统。
SAP HANA 数据库的大小会影响将列式表加载到主内存所花费的时间。这会影响您的总恢复时间目标。您可以使用 SQL 脚本来粗略估计这些表所需的最小内存。有关更多信息，请参阅 [SAP Note 1969700 – SQL Statement Collection for SAP HANA](https://me.sap.com/notes/1969700) 中的 *HANA\_Tables\_ColumnStore\_Columns\_LastTouchTime* 部分。
**较小的辅助系统**
下图显示了在同一 Amazon 区域内，不同可用区中较小的辅助 SAP HANA 系统的部署情况。
此部署也可以跨多个 Amazon 区域。在跨区域复制时，建议使用异步模式。请注意，在接管前调整辅助系统大小时，没有预留容量。生产规模的实例的要求取决于可用区的当前可用性。
**共享辅助部署**
多个组件一个系统（MCOS，Multiple Components One System）模型是共享辅助部署选项的常见使用案例。您可以在同一台主机上操作活动的高质量实例和辅助实例。此设置需要额外的存储空间来操作其他实例。在接管期间，优先级较低的实例可以关闭，使得底层主机资源可用于生产工作负载。
您必须为站点上运行的所有实例设置 `global_allocation_limit`。这样可以确保 `global_allocation_limit` 设置为 `0` 的任何实例都不会占用主机上的全部可用内存。有关更多信息，请参阅 [SAP Note 1681092 – Multiple SAP HANA systems (SIDs) on the same underlying server(s)](https://me.sap.com/notes/1681092)。
下图显示了 Amazon 上的共享辅助部署。
**成本优化型部署的大小调整注意事项**
尽管禁止预加载列式表，但辅助主机上的实际内存使用量同样取决于系统复制的操作模式。有关更多信息，请参阅 [SAP Note 1999880 - FAQ: SAP HANA System Replication](https://me.sap.com/notes/1999880)。
尽管 `preload_column_tables` 参数设置为 *false*，但 `logreplay` 操作模式也是影响内存大小的因素。您应该考虑列存储表中，自当前评估之日起过去 30 天内修改过的数据量大小。
`logreplay` 操作模式可能无法提供真正的成本优化。`delta_datashipping` 操作模式可以作为备用选项。但是，`delta_datashipping` 有局限性。这包括更长的恢复时间以及对复制站点之间网络带宽的需求增加。如果您的业务需求能够承受更高的网络带宽和宽松的恢复时间，则 `delta_datashipping` 模式可能是可行的选择。
数据库实例越大，可能节省的成本越高。即使对于较小的数据库实例，辅助系统上的内存占用也具有最低行存储内存要求和缓冲区要求。计算内存需求并相应地设置 `global_allocation_limit` 是一个迭代过程。随着生产数据库规模的扩大，列存储对增量合并的需求也随之增长。因此，应定期监控站点上所有主机的内存分配，并在海量数据加载、上线和 SAP 系统特定的生命周期事件之后监控内存分配。
### SAP HANA 多层复制
如果您同时寻求实现高可用性和灾难恢复，则此配置场景非常适合。此设置提供了一种链式复制模型，在这种模型中，主系统在任何给定时间点只能复制到一个辅助系统。有关更多信息，请参阅 [Setting Up SAP HANA Multi-tier System Replication](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/f730f308fede4040bcb5ccea6751e74d.html)。
在此场景中，可以混合使用性能优化和成本优化部署选项。主系统和辅助系统可以使用 Pacemaker 集群部署在高可用性设置中。第三级系统（即灾难恢复系统）可以是成本优化型部署。活动的非生产实例可以在同一个节点上运行，就像多个组件、一个安装模型一样。下图显示了此设置。
### SAP HANA 多目标复制
在 SAP HANA 多层场景中，复制按顺序进行，从主系统到辅助系统，然后从辅助系统复制到第三级系统。从 SPA HANA 2.0 SPS 03 开始，SAP HANA 为单个主系统提供了多目标系统复制配置，用于复制到多个辅助系统。有关更多信息，请参阅 [SAP HANA Multitarget System Replication](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/ba457510958241889a459e606bbcf3d3.html)。
下图显示了 Amazon 云端的多层目标复制配置。
**复制模式**
主系统、辅助系统和第三级系统可以放置在相同 Amazon 区域内或跨区域的不同可用区上。在 SAP 支持的复制模式之外，由于延迟要求，跨不同 Amazon 区域部署的 SAP HANA 系统必须选择异步复制模式。要查看 SAP 支持的复制模式，请参阅 [Supported Replication Modes between Sites](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/c3fe0a3c263c49dc9404143306455e16.html)。
**操作模式**
在多层或多目标系统复制中，无法合并 `logreplay` 和 `delta_datashipping` 操作模式。例如，如果主系统和辅助系统使用 `logreplay` 进行系统复制，则不能在辅助和第三级系统之间使用 `delta_datashipping`，反之亦然。
只有在多目标系统复制场景中才支持 `logreplay` 操作模式。要实施高可用性 Pacemaker 集群解决方案以及多目标复制，请查看 SUSE 和 RHEL 的相关资源。
使用多目标系统复制的主动/主动（启用读取）配置上支持 `logreplay_readaccess` 操作模式。但是，在多层复制中，只有辅助系统才能用于只读功能，并且不能扩展到第三级系统。
**灾难恢复**。
通过多目标系统复制功能，在主系统出现故障时，可自动将辅助系统重新注册为新的主源系统。您可以使用 `register_secondaries_on_takeover` 参数设置此自动化。有关更多信息，请参阅 [Disaster Recovery Scenarios for Multitarget System Replication](https://help.sap.com/docs/SAP_HANA_PLATFORM/4e9b18c116aa42fc84c7dbfd02111aba/8428f79ca32d4869848a1aefe437151c.html)。
## 接管注意事项
在需要 SAP HANA 系统复制接管时，您必须按照标准的 SAP HANA 接管流程，在辅助系统中触发接管。如果您启用了自动恢复，则在接管之前，必须确定是否要在主可用区等待系统恢复。有关更多信息，请参阅 [SAP Note 2063657 - SAP HANA System Replication Takeover Decision Guideline](https://me.sap.com/notes/2063657)。
**Topics**
+ [客户端重定向选项](#hsr-client-redirect)
+ [主动/主动高可用性场景的客户端重定向](#hsr-ha-client-redirect)
### 客户端重定向选项
在几乎所有场景中，仅靠 SAP HANA 系统的失效转移并不能保证业务连续性。您必须确保您的客户端应用程序（例如 NetWeaver 应用程序服务器、JDBC、ODBC 等）能够在失效转移后连接到 SAP HANA 系统。通过重定向基于网络的 IP 或 DNS 可以重新建立连接。与通过全球网络同步 DNS 条目更改相比，在脚本中处理 IP 重定向的速度更快。有关更多信息，请参阅 [SAP HANA Administration Guide](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/330e5550b09d4f0f8b6cceb14a64cd22.html) 中的“Client Connection Recovery”**部分。
#### DNS 重定向
对于基于网络的 DNS 重定向，您必须在主机名中设置辅助系统的 IP 地址。DNS 记录必须指向位于同一可用区中的活动 SAP HANA 实例。在接管过程中，您可以使用脚本来修改 DNS 记录。您也可以手动更改 DNS 记录。
修改 DNS 记录需要供应商的专有解决方案。借助 Amazon，您可以使用 Amazon Route 53，通过 Amazon CLI 或 Amazon API 自动修改 DNS 记录。有关更多信息，请参阅[将 Amazon Route 53 配置为 DNS 服务](https://docs.amazonaws.cn/Route53/latest/DeveloperGuide/dns-configuring.html)。
#### IP 重定向
使用基于网络的 IP 重定向，会向虚拟主机名分配虚拟 IP 地址。在进行接管时，虚拟 IP 将解除与主系统网络适配器的绑定，并绑定到辅助系统上的网络适配器。
Amazon VPC 设置包括为 SAP HANA 数据库的主节点和辅助节点分配子网。这些已配置的子网都具有来自完全驻留在一个可用区内的 Amazon VPC 的无类别域间路由（CIDR）IP 分配。在失效转移情况下，此 CIDR IP 分配不能跨多个可用区，也不能重新分配给不同可用区中的辅助实例。有关更多信息，请参阅 [Amazon VPC 的工作原理](https://docs.amazonaws.cn/vpc/latest/userguide/how-it-works.html)。
**Topics**
+ [Amazon Transit Gateway](#hsr-redirect-ip-gateway)
+ [网络负载均衡器](#hsr-redirect-ip-nlb)
##### Amazon Transit Gateway
借助 Transit Gateway，您可以使用路由表规则，这些规则使重叠 IP 地址可以与 SAP 实例通信，而无需配置任何其他组件，如网络负载均衡器或 Route 53。您可以通过以下方式连接到重叠 IP：从另一个 VPC、另一个子网（不共享维护着重叠 IP 地址的相同路由表）、通过 VPN 连接或通过来自企业网络的 Amazon Direct Connect 连接。有关更多信息，请参阅[什么是 Transit Gateway？](https://docs.amazonaws.cn/vpc/latest/tgw/what-is-transit-gateway.html)
##### 网络负载均衡器
如果您不使用 Amazon Route 53 或 Amazon Transit Gateway，则可以使用网络负载均衡器从外部访问重叠 IP 地址。Network Load Balancer 在开放系统互连 (OSI) 模型的第四层运行。它每秒可以处理数百万个请求。负载均衡器收到连接请求后，它会从 Network Load Balancer 目标组中选择一个目标，将网络连接请求路由到目标地址，可以是 Overlay 网络 IP 地址。有关更多信息，请参阅[什么是网络负载均衡器？](https://docs.amazonaws.cn/elasticloadbalancing/latest/network/introduction.html)
### 主动/主动高可用性场景的客户端重定向
在此配置中，您使用辅助只读系统的额外重叠 IP 地址。作为集群失效转移的一部分，IP 地址绑定到活动的辅助系统。辅助系统的 DNS 记录可以手动更新，也可以在接管期间使用脚本进行更新。
需要额外创建的网络负载均衡器来平衡辅助系统的负载。
使用 Transit Gateway，您可以在辅助系统上使用重叠 IP 地址来连接运行辅助系统的 Amazon VPC 和子网。
**Topics**
+ [使用 DNS 的主动/主动场景](#hsr-redirect-ha-dns)
+ [使用 Amazon Transit Gateway 的主动/主动场景](#hsr-redirect-ha-ip)
+ [使用网络负载均衡器的主动/主动场景](#hsr-redirect-ha-gateway)
#### 使用 DNS 的主动/主动场景
在此场景中，您将两个 DNS 记录用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，可以自动或手动修改 DNS 记录。
#### 使用 Amazon Transit Gateway 的主动/主动场景
在此场景中，两个重叠 IP 地址用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，将在其可用区中调整路由表，然后 Transit Gateway 会将连接重新路由到这些 IP 地址。这适用于两个重叠 IP 地址。
#### 使用网络负载均衡器的主动/主动场景
在此场景中，两个重叠 IP 地址用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，路由表将在其可用区中进行调整，读/写端点或只读端点的网络负载均衡器指向其可用区中的重叠 IP 地址。这适用于两个重叠 IP 地址。
