本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
SAP HANA 的多区域架构模式
AWS 全球基础设施横跨全球多个地区，而且其足迹不断增加。有关最新更新，请参阅AWS 全球基础架构
在部署多区域模式时，您可以从使用集群解决方案等自动化方法中获益，在可用区之间进行故障转移，从而最大限度地减少总体停机时间并消除人为干预的需求。多区域模式不仅提供高可用性，还提供灾难恢复，从而降低总体成本。所选区域之间的距离会直接影响延迟，因此，在多区域模式中，SAP HANA 系统复制的总体设计中必须考虑这一点。
跨区域复制或数据传输还会产生额外的成本影响，这些影响也需要考虑在解决方案的总体定价中。不同地区的定价各不相同。
以下是四种多区域架构模式。
模式
模式 5：主区域有两个生产可用区，辅助区域带有备份副本/ AMIs
此模式类似于模式 1，其中您的 SAP HANA 实例具有高可用性。您可以使用同步 SAP HANA 系统复制在主区域的两个可用区部署生产 SAP HANA 实例。您可以使用存储在 Amazon S3、Amazon EBS 和亚马逊系统映像 (AMIs) 中的备份副本在辅助区域中恢复 SAP HANA 实例。
通过跨区域复制存储在 Amazon S3 中的文件，存储在存储桶中的数据会自动（异步）复制到目标区域。可以在区域之间复制 Amazon EBS 快照。有关更多信息，请参阅复制 Amazon EBS 快照。您可以使用 AWS CLI、 AWS Management Console或 Amazon 在区域内或跨区域复制 AMI EC2 APIs。 AWS SDKs 有关更多信息，请参阅复制 AMI。您还可以使用 AWS Backup 跨区域计划和运行快照和复制。
如果区域完全失败，则需要使用 AMI 在辅助区域中构建生产 SAP HANA 实例。您可以使用 AWS CloudFormation 模板自动启动新的 SAP HANA 实例。实例启动后，您可以从 Amazon S3 下载最后一组备份，将您的 SAP HANA 实例恢复到灾难事件发生 point-in-time前的状态。您还可以使用 AWS Backint Agent 恢复和恢复 SAP HANA 实例，并将您的客户端流量重定向到辅助区域中的新实例。
该架构为您提供了跨多个可用区实施 SAP HANA 实例的优势，并且能够在出现故障时立即进行故障转移。对于主区域之外的灾难恢复，恢复点目标受您在 Amazon S3 存储桶中存储 SAP HANA 备份文件的频率以及将 Amazon S3 存储桶复制到目标区域所需的时间的限制。您可以使用 Amazon S3 复制时间控制进行有时限的复制。有关更多信息，请参阅启用 Amazon S3 复制时间控制。
您的恢复时间目标取决于在辅助区域中构建系统以及从备份文件恢复操作所需的时间。时间长短将根据数据库的大小而有所不同。此外，在没有预留实例容量的情况下，获得恢复过程的计算容量所需的时间可能会更长。当您需要在某个区域内实现尽可能低的恢复时间和恢复点目标以及主区域之外的灾难恢复的高恢复点和时间目标时，此模式非常适合。
模式 6：主区域有两个生产可用区，辅助区域将计算和存储容量部署在单个可用区中
除了模式 5 的架构外，此模式还在主区域的 SAP HANA 实例和辅助区域的其中一个可用区中的相同第三个实例之间设置了异步 SAP HANA 系统复制。由于延迟增加，我们建议在 AWS 区域间复制时使用 SAP HANA 系统复制的异步模式。
如果主区域出现故障，生产工作负载将手动故障转移到辅助区域。这种模式可确保您的 SAP 系统具有高可用性和容灾能力。这种模式通过连续的数据复制提供了更快的故障转移和业务运营的连续性。
在辅助区域中为生产 SAP HANA 实例部署所需的计算和存储以及区域之间的数据传输成本会增加。当您需要在主区域之外进行灾难恢复且恢复点和时间目标较低时，此模式非常适合。
这种模式可以部署在多层和多目标复制配置中。
下图显示了多目标复制，其中主 SAP HANA 实例复制到同一区域内的两个可用区和辅助区域。
下图显示了以链式方式配置复制的多层复制。
模式 7：具有两个生产可用区的主区域，以及一个部署计算和存储容量的辅助区域，以及跨两个可用区域进行数据复制
在这种模式下，在两个 AWS 区域部署了两组两层 SAP HANA 系统复制。两层 SAP HANA 系统复制是跨同一区域内的两个可用区配置的，主区域之外的复制是使用 SAP HANA 多目标系统复制配置的。此设置可以通过高可用性群集解决方案进行扩展，以实现主区域的自动故障转移功能。有关更多信息，请参阅 SAP HANA 多目标系统复制
此模式可防止可用区和区域出现故障。但是，跨区域接管 SAP HANA 实例需要手动干预。在次要区域故障转移期间，SAP HANA 实例继续在新区域启动并运行 SAP HANA 系统复制，无需任何手动干预。如果您希望始终保持最高的应用程序可用性，并在主区域之外寻求灾难恢复，同时尽可能减少恢复点和时间目标，则此设置适用。这种模式可以承受分布在多个区域的三个可用区出现故障的极其罕见的可能性。
如果您操作active/active (read-only) SAP HANA instances in the primary Region and plan to continue the same SAP HANA System Replication configuration with read-only capability. If you are looking for read-only capability across two Regions along with an existing read-only instance within the Region, you can configure multiple secondary systems supporting active/active（只读）配置，则此模式非常适合您。但是，只能通过基于提示的语句路由访问其中一个系统，而其他系统则必须通过直接连接进行访问。
在这种模式下，跨两个区域的两个可用区部署的冗余计算和存储容量以及跨区域通信增加了总拥有成本。
模式 8：主区域，其中一个可用区用于生产，一个辅助区域包含备份副本/ AMIs
这种模式与模式 4 类似，在次要区域中进行额外的灾难恢复，该区域包含存储在 Amazon S3 中的 SAP HANA 实例备份的副本、Amazon EBS 快照和。 AMIs在这种模式下，SAP HANA 实例作为独立安装部署在主区域的一个可用区中，没有目标 SAP HANA 系统可以复制数据。
在这种模式下，您的 SAP HANA 实例的可用性不高。如果区域完全失败，则需要使用 AMI 在辅助区域中构建生产 SAP HANA 实例。您可以使用 AWS CloudFormation 模板自动启动新的 SAP HANA 实例。实例启动后，您可以从 Amazon S3 下载最后一组备份，将您的 SAP HANA 实例恢复到灾难事件发生 point-in-time前的状态。您还可以使用 AWS Backint Agent 恢复您的 SAP HANA 实例，并将您的客户端流量重定向到辅助区域中的新实例。
对于主区域之外的灾难恢复，恢复点目标受您在 Amazon S3 存储桶中存储 SAP HANA 备份文件的频率以及将 Amazon S3 存储桶复制到目标区域所需的时间的限制。您的恢复时间目标取决于在辅助区域中构建系统以及从备份文件恢复操作所需的时间。时间长短将根据数据库的大小而有所不同。这种模式适用于可以容忍恢复正常运行所需的停机时间的非生产或非关键生产系统。
摘要
我们强烈建议跨两个可用区运行业务关键型 SAP HANA 实例。您可以使用第三方集群解决方案，例如 Pacemaker 和 SAP HANA 系统复制，以确保设置的高可用性。
使用第三方群集解决方案的高可用性设置会增加许可成本，因此仍建议使用这种设置，因为它可以提供高弹性架构、几乎为零的恢复时间和点目标。
