SAP HANA 系统复制 - SAP HANA 开启Amazon
架构模式复制和操作模式配置方案接管注意事项
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

SAP HANA 系统复制

SAP HANA 系统复制是 SAP 为 SAP HANA 提供的高可用性解决方案。SAP HANA 系统复制用于在进行计划内维护、出现故障和灾难时，减少所导致的 SAP HANA 停机时间。在系统复制中，辅助 SAP HANA 系统是活动主系统的完全相同副本，每个系统中的活动主机数量相等。主系统中的每项服务都与其辅助系统中的对等服务进行通信，并在实时复制模式下运行，从而复制数据和日志并加以保存，通常还会将数据加载到内存中。Amazon 完全支持 SAP HANA 系统复制。

架构模式

Amazon 通过区域和可用区在地理位置上隔离设施。多可用区架构可以保持性能，同时降低位置故障的风险。

使用单区域多可用区模式，辅助系统可以安装在与主系统属于同一 Amazon 区域的不同可用区中。这为计划内停机时间、管理存储损坏或其他任何本地故障提供了快速失效转移解决方案。

对于灾难恢复，您可以使用多区域架构模式，将辅助系统安装在不同的 Amazon 区域。您可以根据业务要求选择区域，例如合规性所要求的数据驻留限制。

有关更多信息，请参阅 Amazon 云端 SAP HANA 架构模式。

复制和操作模式

SAP HANA 系统复制功能提供 Amazon 云端完全支持的以下复制和操作模式。

复制模式

根据恢复时间目标和恢复点目标，您可以使用不同的复制模式选项来复制重做日志，包括磁盘上同步复制、内存中同步复制和异步复制。对于多可用区部署，建议使用同步 SAP HANA 系统复制，以确保接近零的恢复点目标。Amazon 在一个区域内的不同可用区之间提供低延迟和高带宽连接。

对于跨 Amazon 区域的系统复制，建议使用异步复制。如果您的业务需求不会受到潜在网络延迟的影响，则可以选择多区域架构模式。您还必须考虑不同区域中 Amazon 服务成本和跨区域数据传输。

操作模式

注册辅助 SAP HANA 系统时可以使用不同的操作模式，例如 delta_datashipping、logreplay 或 logreplay_readaccess。数据库相应地将不同类型的数据包发送到辅助系统。

配置方案

SAP HANA 系统复制功能支持 Amazon 云端完全支持的以下配置方案。

主动/被动辅助系统

在此场景中，通过接管过程将活动系统从当前的主系统切换到辅助系统之前，系统复制功能不允许对辅助系统进行读取访问或 SQL 查询。辅助系统在 logreplay 操作模式下充当热备用系统。

主动/主动（启用读取）辅助系统

在此场景中，系统复制功能支持对辅助系统的读取访问。它需要 logreplay_readaccess 操作模式。

SAP HANA 辅助时间旅行

在此场景中，您可以访问在主系统中已删除的数据，或者在辅助系统中有意延迟 logreplay 操作（这样就可以读取较早的数据），同时继续在辅助系统上进行复制。您能够以更快的恢复速度从逻辑错误中恢复。您只能在 logreplay 操作模式下使用辅助时间旅行配置。

您必须正确调整辅助时间旅行内存实例的大小，以便进行复制。对于 logreplay 操作模式，最低内存要求是使用行存储大小、列存储内存大小和预加载的 50 GB 内存。有关更多信息，请参阅 SAP Note 1999880 - FAQ: SAP HANA System Replication。以下参数必须进行设置。

  • 辅助系统上必须配置“global.ini/[system_replication]/timetravel_max_retention_time”参数。此参数定义辅助系统可以恢复到过去的时间段。

  • “global.ini/[system_replication]/timetravel_snapshot_creation_interval”是可选参数。您可以调整辅助系统的快照创建过程。辅助系统可以开始保留日志和快照。

下图显示了 SAP HANA 辅助时间旅行配置场景。

SAP HANA 辅助时间旅行配置场景示意图。

Amazon 云端的 SAP HANA 复制场景

在两层 SAP HANA 系统复制中，Amazon 云端的部署会针对性能或成本进行优化。要获得最快的接管速度，请使用与主实例大小相同的辅助实例。这是性能优化型部署。成本优化型部署可以降低总体成本，但会牺牲恢复时间目标。成本优化型场景也称为 Pilot Light 灾难恢复。有关更多信息，请参阅 Rapidly recover mission-critical systems in a disaster。

性能优化

不论是遇到计划内停机还是计划外停机，对业务连续性至关重要的 SAP HANA 数据库系统都需要接近零的恢复时间目标。您可以使用与主实例大小相同的辅助实例来优化性能。此配置可以容纳内存中预加载的列式表和同步系统复制。对于此设置，建议不要跨 Amazon 区域托管 SAP HANA 实例。这是为了避免在同步模式下复制时出现延迟。这种部署可以保护您的关键 SAP HANA 系统免受可用区故障的影响，虽然这种情况很少发生。

您可以设置第三方集群解决方案以及 SAP HANA 系统复制，来检测故障并自动进行失效转移。有关更多信息，请参阅 Pacemaker 集群。下图显示性能优化型部署。

性能优化型部署示意图。

成本优化

您可以使用较小的或共享的辅助 SAP HANA 系统来降低成本。在较小的辅助选项中，基础设施最初的大小要小于主基础设施，并在执行接管之前调整大小。在共享辅助选项中，辅助系统上未使用的内存由非生产或可牺牲实例使用。

对于较小的辅助选项和共享的辅助选项，preload_column_tables 参数均设置为 false。您可以在位于 global.ini 的 (/hana/shared/<SID>/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 中的 HANA_Tables_ColumnStore_Columns_LastTouchTime 部分。

较小的辅助系统

下图显示了在同一 Amazon 区域内，不同可用区中较小的辅助 SAP HANA 系统的部署情况。

同一区域内，不同可用区中较小的辅助 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)。

下图显示了 Amazon 上的共享辅助部署。

共享辅助部署示意图。

成本优化型部署的大小调整注意事项

尽管禁止预加载列式表，但辅助主机上的实际内存使用量同样取决于系统复制的操作模式。有关更多信息，请参阅 SAP Note 1999880 - FAQ: SAP HANA System Replication。

尽管 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。

在此场景中，可以混合使用性能优化和成本优化部署选项。主系统和辅助系统可以使用 Pacemaker 集群部署在高可用性设置中。第三级系统（即灾难恢复系统）可以是成本优化型部署。活动的非生产实例可以在同一个节点上运行，就像多个组件、一个安装模型一样。下图显示了此设置。

在同一节点上运行的活动非生产实例示意图

SAP HANA 多目标复制

在 SAP HANA 多层场景中，复制按顺序进行，从主系统到辅助系统，然后从辅助系统复制到第三级系统。从 SPA HANA 2.0 SPS 03 开始，SAP HANA 为单个主系统提供了多目标系统复制配置，用于复制到多个辅助系统。有关更多信息，请参阅 SAP HANA Multitarget System Replication。

下图显示了 Amazon 云端的多层目标复制配置。

多层目标复制配置示意图。

复制模式

主系统、辅助系统和第三级系统可以放置在相同 Amazon 区域内或跨区域的不同可用区上。在 SAP 支持的复制模式之外，由于延迟要求，跨不同 Amazon 区域部署的 SAP HANA 系统必须选择异步复制模式。要查看 SAP 支持的复制模式，请参阅 Supported Replication Modes between Sites。

操作模式

在多层或多目标系统复制中，无法合并 logreplay 和 delta_datashipping 操作模式。例如，如果主系统和辅助系统使用 logreplay 进行系统复制，则不能在辅助和第三级系统之间使用 delta_datashipping，反之亦然。

只有在多目标系统复制场景中才支持 logreplay 操作模式。要实施高可用性 Pacemaker 集群解决方案以及多目标复制，请查看 SUSE 和 RHEL 的相关资源。

使用多目标系统复制的主动/主动（启用读取）配置上支持 logreplay_readaccess 操作模式。但是，在多层复制中，只有辅助系统才能用于只读功能，并且不能扩展到第三级系统。

灾难恢复。

通过多目标系统复制功能，在主系统出现故障时，可自动将辅助系统重新注册为新的主源系统。您可以使用 register_secondaries_on_takeover 参数设置此自动化。有关更多信息，请参阅 Disaster Recovery Scenarios for Multitarget System Replication。

接管注意事项

在需要 SAP HANA 系统复制接管时，您必须按照标准的 SAP HANA 接管流程，在辅助系统中触发接管。如果您启用了自动恢复，则在接管之前，必须确定是否要在主可用区等待系统恢复。有关更多信息，请参阅 SAP Note 2063657 - SAP HANA System Replication Takeover Decision Guideline。

客户端重定向选项

在几乎所有场景中，仅靠 SAP HANA 系统的失效转移并不能保证业务连续性。您必须确保您的客户端应用程序（例如 NetWeaver 应用程序服务器、JDBC、ODBC 等）能够在失效转移后连接到 SAP HANA 系统。通过重定向基于网络的 IP 或 DNS 可以重新建立连接。与通过全球网络同步 DNS 条目更改相比，在脚本中处理 IP 重定向的速度更快。有关更多信息，请参阅 SAP HANA Administration Guide 中的“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 服务。

途中显示 Amazon Route 53 自动修改 DNS 记录。

IP 重定向

使用基于网络的 IP 重定向，会向虚拟主机名分配虚拟 IP 地址。在进行接管时，虚拟 IP 将解除与主系统网络适配器的绑定，并绑定到辅助系统上的网络适配器。

Amazon VPC 设置包括为 SAP HANA 数据库的主节点和辅助节点分配子网。这些已配置的子网都具有来自完全驻留在一个可用区内的 Amazon VPC 的无类别域间路由（CIDR）IP 分配。在失效转移情况下，此 CIDR IP 分配不能跨多个可用区，也不能重新分配给不同可用区中的辅助实例。有关更多信息，请参阅 Amazon VPC 的工作原理。

Amazon Transit Gateway

借助 Transit Gateway，您可以使用路由表规则，这些规则使重叠 IP 地址可以与 SAP 实例通信，而无需配置任何其他组件，如网络负载均衡器或 Route 53。您可以通过以下方式连接到重叠 IP：从另一个 VPC、另一个子网（不共享维护着重叠 IP 地址的相同路由表）、通过 VPN 连接或通过来自企业网络的 Amazon Direct Connect 连接。有关更多信息，请参阅什么是 Transit Gateway？

图中显示使用 Transit Gateway 和路由表规则，来允许重叠 IP 地址与 SAP 实例进行通信。
网络负载均衡器

如果您不使用 Amazon Route 53 或 Amazon Transit Gateway，则可以使用网络负载均衡器从外部访问重叠 IP 地址。Network Load Balancer 在开放系统互连 (OSI) 模型的第四层运行。它每秒可以处理数百万个请求。负载均衡器收到连接请求后，它会从 Network Load Balancer 目标组中选择一个目标，将网络连接请求路由到目标地址，可以是 Overlay 网络 IP 地址。有关更多信息，请参阅什么是网络负载均衡器？

图中显示使用网络负载均衡器从外部访问重叠 IP 地址。

主动/主动高可用性场景的客户端重定向

在此配置中，您使用辅助只读系统的额外重叠 IP 地址。作为集群失效转移的一部分，IP 地址绑定到活动的辅助系统。辅助系统的 DNS 记录可以手动更新，也可以在接管期间使用脚本进行更新。

需要额外创建的网络负载均衡器来平衡辅助系统的负载。

使用 Transit Gateway，您可以在辅助系统上使用重叠 IP 地址来连接运行辅助系统的 Amazon VPC 和子网。

使用 DNS 的主动/主动场景

在此场景中，您将两个 DNS 记录用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，可以自动或手动修改 DNS 记录。

图中显示 DNS 的主动/主动场景。

使用 Amazon Transit Gateway 的主动/主动场景

在此场景中，两个重叠 IP 地址用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，将在其可用区中调整路由表，然后 Transit Gateway 会将连接重新路由到这些 IP 地址。这适用于两个重叠 IP 地址。

图中显示 Transit Gateway 的主动/主动场景。

使用网络负载均衡器的主动/主动场景

在此场景中，两个重叠 IP 地址用于 SAP HANA 读/写主实例和 SAP HANA 只读辅助实例。在失效转移时，路由表将在其可用区中进行调整，读/写端点或只读端点的网络负载均衡器指向其可用区中的重叠 IP 地址。这适用于两个重叠 IP 地址。

图中显示使用网络负载均衡器的主动/主动场景。