你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
跨 Azure 区域的 SAP HANA 可用性
本文介绍跨不同 Azure 区域的 SAP HANA 可用性的相关场景。 由于 Azure 区域之间的距离较远，在多个 Azure 区域中设置 SAP HANA 可用性时涉及到一些特殊的注意事项。
跨多个 Azure 区域部署的原因
不同 Azure 区域的相隔距离较远。 根据地缘政治区域，Azure 区域之间的距离可能有几百甚至几千英里，例如在美国。 由于这种距离，部署在两个不同 Azure 区域的资产之间的网络流量会发生明显的网络往返延迟的情况。 延迟的程度足以影响到典型 SAP 工作负载下，两个 SAP HANA 实例之间的同步数据交换。
另一方面，组织通常对主要数据中心和辅助数据中心位置之间的距离有要求。 在较广泛的地理位置发生自然灾害时，距离要求有助于提供可用性。 例如，2017 年九月和十月在加勒比海和佛罗里达州发生的飓风。 组织可能至少有一个最短距离要求。 对于大多数 Azure 客户而言，此最短距离定义要求在设计时考虑跨 Azure 区域的可用性。 因为，如果两个 Azure 区域之间的距离过大，则不能使用 HANA 同步复制模式，RTO 和 RPO 的要求可能强迫你在一个区域内部署可用性配置，然后在第二个区域补充额外部署。
在这种情况下，要考虑的另一方面是故障转移和客户端重定向。 假设两个不同 Azure 区域中 SAP HANA 实例之间的故障转移始终是手动故障转移。 由于 SAP HANA 系统复制的复制模式设置为异步，因此可能出现主要 HANA 实例中提交的数据未到达次要 HANA 实例的情况。 因此，对于进行异步复制的配置，自动故障转移不能用作一个选项。 即使对于手动控制的故障转移（例如在故障转移练习中），仍需要采取措施确保所有在主要端提交的数据在手动转移到其他 Azure 区域之前，已到达辅助实例。
Azure 虚拟网络使用不同的 IP 地址范围。 IP 地址部署在第二个 Azure 区域。 因此，需要更改 SAP HANA 客户端配置，或者需要创建步骤来更改名称解析（首选）。 这样，客户端就会重定向到新辅助站点的服务器 IP 地址。 有关详细信息，请参阅 SAP 文章接管后的客户端连接恢复。
两个 Azure 区域之间的简单可用性
可以选择不将任何可用性配置放在单个区域中，但如果发生灾难，仍需要为工作负荷提供服务。 这种情况的典型案例是非生产系统。 虽然可以保持系统关闭半日或整日，但不能允许系统在 48 小时或更长时间不可用。 为降低安装成本，可在重要性较低的 VM 中运行另一个系统。 另一个系统充当目标。 也可以将次要区域中的 VM 大小调小，并选择不预加载数据。 由于需要手动进行故障转移，并且还需要更多的步骤来完成整个应用程序堆栈的故障转移，因此可接受花费额外时间关闭 VM、重设其大小和重启 VM。
如果你在一个 VM 中使用与 QA 系统共享 DR 目标的方案，需要注意以下事项：
- 有两种操作模式（delta_datashipping 和 logreplay）可用于这类方案
- 这两种操作模式在不预加载数据的情况下具有不同的内存要求
- 在没有预加载选项的情况下，Delta_datashipping 可能需要的内存显著少于 logreplay。 请参阅 SAP 文档如何为 SAP HANA 执行系统复制的的第 4.3 章
- 不带预加载的 logreplay 操作模式的内存要求不是确定性的，取决于加载的列存储结构。 在极端情况下，可能需要主实例内存的 50%。 用于 logreplay 操作模式的内存与是否选择设置预加载数据无关。
注意
在此配置中，因为 HANA 系统复制模式为异步，所以不能提供 RPO=0。 如果需要提供 RPO=0，则不能选择该配置。
可以在配置中所做的轻微更改可能是将数据配置为预加载。 但是由于故障转移的手动性而且应用层需要移动到次要区域，预加载数据可能没有意义。
在一个区域内或跨区域合并可用性
在一个区域内或跨区域进行可用性合并可由以下因素驱动：
- Azure 区域内对 RPO=0 的要求。
- 组织不希望或不能让全球运营受到波及较大范围的大型自然灾害影响。 例如，过去几年影响加勒比海的几场飓风。
- 规定要求的主要和辅助站点之间的距离明显超过 Azure 可用性区域可提供的距离。
在这些情况下，可以使用 HANA 系统副本 (replica)设置 SAP 调用 SAP HANA 多层系统副本 (replica)配置的内容。 体系结构如下所示：
SAP 使用 HANA 2.0 SPS3 引入了多目标系统复制。 多目标系统复制在更新方案中带来一些优势。 例如，辅助 HA 站点关闭进行维护或更新时，DR 站点（区域 2）不会受到影响。 可以在 SAP 帮助门户找到有关 HANA 多目标系统复制的更多信息。 使用多目标复制的可能体系结构如下所示：
如果组织对第二个 (DR) Azure 区域的高可用性就绪性有要求，那么体系结构将如下所示：
使用 logreplay 作为操作模式时，此配置在主要区域内提供低 RTO 的 RPO=0。 如果需要转移到第二个区域，此配置还能提供更低的 RPO。 第二个区域的 RTO 时间取决于是否预加载数据。 许多客户使用次要区域中的 VM 来运行测试系统。 在这种用例中，无法预加载数据。
重要
不同层之间的操作模式需要是同类的。 不能使用 logreplay 作为第 1 层和第 2 层和第 2 层之间的操作模式，delta_datashipping才能提供第 3 层。 只能选择一种或另一种操作模式，需要对所有层保持一致。 由于 delta_datashipping 不适合提供 RPO=0，因此对于这类多层配置，唯一合理的操作模式仍是 logreplay。 有关操作模式和某些限制的详细信息，请参阅 SAP 文章 SAP HANA 系统复制的操作模式。
后续步骤
有关在 Azure 中设置这些配置的分步指导，请参阅：