Google Cloud 上的 SAP 部署的弹性

本文档介绍了有助于在 Google Cloud 上运行弹性佳且可靠的 SAP 系统的设计注意事项。

基础架构和软件可能会发生故障。此类故障的原因和范围要求 SAP 系统部署遵循某些原则，以便充分利用 Google Cloud 基础架构。将基础架构选项与弹性佳的 SAP 软件部署架构相结合，可以确保数据完整性并防止数据丢失或系统不可用。

弹性和可靠性选项

通过利用基础架构和应用层中的功能来吸收故障或是可以从故障中恢复，您可以部署弹性佳且可靠的系统。为确保 Google Cloud 上的 SAP 系统部署的弹性和可靠性，我们建议您考虑以下选项：

• 平台弹性：Google Cloud 服务和产品在设计时考虑到了弹性，并具有内置冗余，可实现我们发布的服务等级协议。当您根据 Google Cloud 准则和最佳实践部署 SAP 系统时，底层平台机制可提高 SAP 系统的弹性。这样您就可以在发生故障或灾难时继续进行业务运营。
• 高可用性 (HA)：通过使用支持高可用性的基础架构和软件配置，您可以实现自动化系统恢复，同时尽量减少中断。这种用法还可确保在底层基础架构或应用程序的某些部分发生故障时，您只需进行极少的干预。高可用性旨在通过为系统组件提供冗余来保护系统免受单组件故障或降级的影响。
• 灾难恢复 (DR)：灾难恢复可在灾难导致故障时恢复业务运营。灾难恢复涉及将服务和应用移动到物理上隔离的次要位置，可从该位置继续运营。灾难恢复系统不仅可缓解单组件或服务故障，而且可缓解不常见但影响较大的事件。这可能包括自然灾害、电网中断等区域级事件，以及火灾或人为错误等本地事件。灾难恢复预配包括：
  • 数据复制：您可以使用软件或存储级别复制功能来确保将数据转移到次要位置，同时尽可能减少潜在的数据丢失。
  • 备份：您可以使用与主要数据存储分开存储的备份来恢复系统或数据库。这可能包括使用上传到 Cloud Storage 中的快照或备份，前提是这些快照或备份存储在与系统部署位置不同的其他区域。

由于这些选项是互补的，因此您可以组合每个选项的各个方面以提高 SAP 部署中的弹性。您选择的选项会影响部署的恢复时间目标 (RTO) 和恢复点目标 (RPO)。因此，您还需要根据这些选项对系统弹性和业务连续性的影响来评估其费用。我们建议您仔细考虑所有可用选项，并实现这些选项以达到您的灾难恢复目标。

下面的部分介绍了一个示例 SAP 部署，以及不同高可用性和灾难恢复配置对其弹性和可靠性的预期影响。

场景示例

请考虑 Google Cloud 上的一个纵向扩容 SAP S/4HANA 部署。下表展示了可应用于此部署的示例高可用性和灾难恢复配置，以及它们对系统弹性和可靠性维度（例如可用性、RTO 和 RPO）的预期影响。

高可用性或灾难恢复配置	弹性或可靠性维度	预计日期
高可用性配置。请考虑以下事项： us-central1 是主要区域。 X4 实例部署在两个不同的可用区，例如 us-central1-a 和 us-central1-b。	可用性	对于整个系统为 99.99% 或更高。 对于每个实例为 99.9% 或更高。
使用针对全内存驻留灾难恢复系统的异步 SAP HANA 系统复制的灾难恢复配置。请考虑以下事项： us-central1 是主要位置。 us-east4 是灾难恢复位置，它运行与主要位置大小相同的 X4 实例。 数据会预加载到在灾难恢复位置上运行 SAP HANA 的 X4 实例中。 在灾难恢复位置，应用服务器已进行预配，或者您为它们购买了预留。^备注 1	恢复时间	数小时，其中可能包括 DNS 传播到客户端系统所需的时间。
	恢复点	相对于上次异步复制的分钟数。
使用具有预配基础架构的备份的灾难恢复配置^备注 1。请考虑一个使用基于 Backint 的备份和恢复的系统。	恢复时间	从备份恢复数据库的时间^备注 2。
	恢复点	到 SAP HANA 日志备份或快照中的最后一个时间点。
使用没有预配基础架构的备份的灾难恢复配置^备注 3。请考虑一个使用基于 Backint 的备份和恢复的系统。	恢复时间	数天，用于预配基础架构^备注 4 并从备份恢复数据^备注 3。
	恢复点	到 SAP HANA 日志备份或快照中的最后一个时间点。

表说明：

1. 您可以通过提前预留所需资源来部署灾难恢复解决方案，而无需预配所需的基础架构。当您因主要位置发生灾难而需要激活灾难恢复解决方案时，这是一种确保所需资源可用性的方法。如需了解详情，请参阅 Compute Engine 可用区级资源的预留。
2. 恢复操作的执行时间在很大程度上取决于所用的备份解决方案和备份文件的大小。如需针对数据库大小和更改率确定确切的预期时间，您需要评估所用备份解决方案（例如 Backint 或磁盘快照）的恢复速度。
3. 如果在部署灾难恢复解决方案时未预配或预留所需资源，则可能导致所需资源不可用的情况。这可能会增加部署的恢复时间，进而影响您的业务运营。
4. 对于不按需提供且需要订购的机器类型（例如 X4），在没有事先预留容量的情况下，可能需要几周的准备时间。

可将上表中提供的信息视为您从行业准则中得出的任何现有设计和灾难恢复计划的补充。如需了解详情，请参阅以下资源：

• 灾难恢复规划指南
• 设计弹性系统

关于弹性佳的部署的建议

以下部分简要介绍了我们针对在 Google Cloud 上部署弹性佳且可靠的 SAP 工作负载所建议的高可用性和灾难恢复配置。

虽然我们强烈建议您为托管业务关键型生产运营的 SAP 工作负载实施这些建议，不过对于长时间服务中断可能会对业务运营造成不利影响的非生产 SAP 系统，您也可以实施这些建议。

如需了解这些建议，请参阅以下部分：

• 高可用性建议
• 灾难恢复建议
• 其他建议

高可用性建议

• 至少使用同一区域内的两个不同可用区来部署实例。
• 移除单点故障。为此，您可以添加额外资源，以便在发生故障时为故障服务或应用组件提供弹性和冗余。
• 使用具有内置冗余的区域级服务。例如，使用 Filestore Enterprise 托管共享文件以及 Cloud Load Balancing 所提供的负载均衡器。
• 使用自动化功能进行故障切换。自动化功能可限制发生故障时对手动干预的需求，并降低对业务运营的影响。例如，您可以使用 Pacemaker 等 Linux 集群管理器。

• 使用冗余网络路径。确保与主要区域建立冗余连接。根据您的连接要求，您可以使用多种方案。如需了解详情，请参阅 Google Cloud 连接。

  如需为 Google Cloud 区域连接实现 99.99% 的可用性，我们建议您配置多个连接。如需了解详情，请参阅为专用互连建立 99.99% 可用性配置。

• 对 Compute Engine 资源启用实时迁移和自动重启政策：

  • 如需在 Google 发起的维护事件期间使计算实例保持在线状态，您可以通过使用 MIGRATE（默认）选项设置 onHostMaintenance 属性来使用实时迁移。对于不支持实时迁移的计算实例，请将 automaticRestart 属性设置为 true（默认）。这样可以让 Google 重启所有无响应的实例。如需了解详情，请参阅关于主机事件。
  • 对于不支持实时迁移或计划内维护的计算实例，可以使用高级维护控制。如需了解详情，请参阅为单租户节点启用高级维护控制。

• 上线之前，在环境中测试故障切换。

  • 如需确保高可用性配置设置正确并按预期运行，请务必测试会触发一个或多个组件终止的故障场景。如需了解详情，请参阅在 Google Cloud 上测试高可用性集群。
  • 如需评估高可用性配置，您可以使用 Workload Manager。如需了解详情，请参阅 Workload Manager 评估简介。如需了解对于 SAP 工作负载，Workload Manager 所支持的评估，请参阅适用于 SAP 的 Workload Manager 最佳实践。

灾难恢复建议

• 在与主要位置不同的其他位置托管灾难恢复解决方案。为避免灾难恢复解决方案与主要系统受到相同事件影响，请确保在不同的位置托管两者。

  理想情况下，您的灾难恢复位置必须是其他区域。但是，如果由于数据驻留或主权问题而不适合使用第二个区域，请与 Google Cloud 销售团队联系，以讨论其他可用选项。

  下图展示了 Google Cloud 上具备以下高可用性和灾难恢复预配的 SAP HANA 部署的概要架构：

  • 为了实现高可用性，主要系统有两个节点，部署在同一区域内的不同可用区中。
  • 为了实现弹性，主要系统和灾难恢复系统在不同的区域中托管，会进行异步复制。

  

• 确保灾难恢复位置有足够的容量。

  • 确定灾难恢复系统是需要采用与主要系统相同的容量运行，还是采用减少的容量运行。对于 SAP HANA 等数据库，灾难恢复位置必须具有足够的资源，以便高效地运行 SAP 工作负载。
  • 此外，请提前检查灾难恢复位置是否提供了所需资源。如需确保资源可用性，您可以在灾难恢复位置预配资源，也可以提前购买预留。购买预留可帮助您避免以下情况：发生故障后，资源由于分配给其他 Google Cloud 客户而不可用。这对于较大的计算实例类型（例如 M2 或 X4）尤为重要。如需了解预留，请参阅 Compute Engine 可用区级资源的预留。

  如需实现更高的成本效益，灾难恢复位置中的基础架构可用于非生产工作负载，并且可在灾难恢复事件期间切换为处理生产工作负载。但是，这会以增加恢复时间为代价。

• 验证与灾难恢复位置的连接。与主要位置的冗余网络路径一样，请考虑添加其他后备选项，例如 Cloud VPN。

• 确定可用于识别灾难的信号。这些信号有助于决定何时触发灾难恢复解决方案。以下是一些此类信号的示例：

  • 来自 Google Cloud Service Health 的有关 Google Cloud 服务健康状况的信息。
  • 根据针对 Google Cloud 项目的配置，Cloud Monitoring 报告实例完全不可用。
  • 来自 Google Cloud Customer Care 或您的 Google Cloud 客户代表的通信，就服务中断和潜在解决时间提供建议。
  • 由 SAP 系统的用户或管理员确定的数据库逻辑损坏，无法通过高可用性机制来解决。

• 定期测试灾难恢复解决方案。确保您的解决方案可在发生灾难时发挥作用。这可能会影响您的日常运营。如果运营允许，请考虑在主要和次要位置上以对称方式进行运营，并且每 3 到 6 个月在它们之间轮替运营。

• 使用复制功能实现最佳恢复点。复制功能可在灾难恢复站点上提供主要站点的近乎实时版本。根据 SAP 工作负载的设计方式，可以使用以下复制选项：

  • 利用 SAP HANA 系统复制（在主要站点和灾难恢复站点之间进行逻辑级别复制）等机制进行数据库级别复制。
  • 利用永久性磁盘异步复制（在块存储级别上进行复制）等机制进行存储级别复制。可用的存储级别复制选项因 SAP 工作负载使用的存储选项而异。

  请务必使用适当的工具（例如 SAP HANA Cockpit）监控复制。这有助于在灾难恢复事件中触发灾难恢复解决方案之前，验证您的 SAP 工作负载是否已完全复制。

• 使用数据备份提供时间点可恢复性。

  • 如需创建冗余，请使用多个存储位置来存储备份。例如：
    • 使用 Google Cloud 的 Agent for SAP 创建基于 Backint 的备份时，请使用双区域或多区域存储桶位置。如需了解详情，请参阅创建 Cloud Storage 存储桶。
    • 创建基于磁盘快照的备份时，请使用多区域或双区域 Cloud Storage。如需了解 Cloud Storage 存储桶位置，请参阅存储桶位置。
  • 使用增量备份或差分备份，其中可能包括在 Google Cloud 上存储快照。
  • 监控备份，以确保根据您的备份策略正确创建它们。如需完整的数据保护解决方案，请考虑使用 Google Cloud 的 Backup and DR Service。
  • 请定期测试备份，以确保它们在发生灾难时可以恢复，并查看恢复系统或数据库所需的时间。建议在每个备份周期（通常为 28 天）进行一次恢复测试。
  • 如同保护主要系统一样保护备份，例如使用存储保留设置和加密密钥。

其他建议

• 根据对业务以下方面的影响来评估高可用性和灾难恢复配置的费用：
  • 运营和业务事务中的潜在停机时间。
  • 潜在的数据丢失，从而导致销售、客户或供应商失去信心，或是未遵守法规。
• 每个企业都有独特的考虑因素。如果您的具体情况需要自定义程度更高的解决方案，欢迎随时与 Google Cloud 销售团队联系。

后续步骤

• SAP HANA 高可用性规划指南
• SAP HANA 灾难恢复计划指南
• 适用于 Google Cloud 上的 SAP NetWeaver 的高可用性规划指南
• 适用于 Google Cloud 上的 SAP NetWeaver 的灾难恢复规划指南