说明 SAP BTP 的高可用性与灾难恢复概念
学习目标
说明 SAP BTP 的高可用性与灾难恢复概念
在当今动态变化的业务环境中，确保持续运营对任何组织来说都至关重要。业务连续性对于将中断的影响降到最低必不可少，而 SAP Business Technology Platform (SAP BTP) 作为集成与创新的平台，在 SAP 的产品组合中扮演核心角色。因此，拥有具备高可用性 (HA) 和灾难恢复 (DR) 能力的韧性平台至关重要。在以下各节中，我们将探讨高可用性和灾难恢复——它们是业务连续性的关键组成部分，进一步确保您组织的韧性和不间断运营。
Note
请注意，本学习旅程提供的是 SAP Business Technology Platform 内与高可用性和灾难恢复相关概念的概述。如需具有法律约束力的信息，请参阅 SAP Trust Center 或查阅您的法律文件（如合同）。
区分高可用性与灾难恢复
高可用性和灾难恢复对于维持 SAP BTP 上系统的韧性和持续运行至关重要。它们在业务连续性中扮演着不同的角色。
高可用性确保服务以最短的停机时间保持可运行和可访问。它旨在通过处理系统运行期间的问题来防止服务中断。HA 涉及将系统设计为具备冗余和故障转移解决方案，在所有基础设施层、服务和应用程序上维持可用性。
灾难恢复 (DR) 侧重于在发生重大故障后恢复运营。它处理系统故障之后的问题，防止不必要的数据丢失。DR 策略包括定期备份、数据复制和明确的恢复流程，确保系统在灾难后能够迅速恢复上线。
在考虑 HA 和 DR 时，重要的是要考虑相关的服务等级协议 (SLA)，例如与高可用性上下文相关的可用性，以及与灾难恢复相关的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
SAP BTP 相关的业务连续性 SLA
可用性
可用性是指云服务可供用户使用和访问的时间百分比。它表明该服务能够在不中断的情况下被可靠使用的一致性程度，确保用户在任何需要时都能访问和使用系统。高可用性对于维持用户信任和确保运营连续性至关重要。例如，99.9% 的可用性意味着该服务在给定期间（例如一个月或一年）内有 99.9% 的时间保证可运行且可访问。
恢复时间目标
恢复时间目标 (RTO) 定义了灾难后恢复正常运营可接受的时间量。例如，如果系统宕机，RTO 可能规定必须在 2 小时内恢复正常运营。这确保中断是短暂且可控的，帮助企业在尽可能小的延迟下恢复其活动。
恢复点目标
恢复点目标 (RPO) 规定了发生灾难时可接受的最大数据丢失量。例如，如果 RPO 设置为 5 分钟，意味着在发生故障时，系统保证灾难发生前记录的数据丢失不超过 5 分钟。这减轻了重大数据丢失，并确保以最新信息保持运营连续性。
使用多可用性区域的 SAP BTP 区域设置
在我们深入探讨 SAP 为 BTP 高可用性所采取的技术概念之前，我们需要重温一下 BTP 区域：每个区域代表一个地理位置（例如欧洲、美国东部），应用、数据或服务托管在那里。区域由 SAP 或我们的基础设施即服务合作伙伴 Amazon Web Services (AWS)、Microsoft Azure、Google Cloud 和 Alibaba 提供。
云计算中的区域由若干称为可用性区域 (AZ) 的隔离位置组成。这些可用性区域是逻辑分组，每个分组容纳一个或多个数据中心，配备独立的电力、冷却和网络连接。AZ 的主要目的是通过确保局部问题不会影响整个区域，来增强云服务的可靠性和韧性。区域内的每个可用性区域 (AZ) 都通过低延迟、高带宽的通信链路互连，从而实现它们之间资源的无缝复制。
利用区域的可用性区域来实现高可用性被称为多 AZ。多 AZ 部署通过将服务分布在多个 AZ 之间并在它们之间复制服务数据，增强了对故障的韧性。在这种设置中，应用实例分布在所有不同的 AZ 中，确保某个区域发生故障不会影响应用程序的整体可用性和性能。该配置包括同步数据复制、自动故障转移机制以及稳健的流量管理，其中包括负载均衡和故障检测。
高可用性设置
SAP BTP 的多云环境在 HA 设置中运行，在一个区域内采用多 AZ 结构。通过 "Chaos Days" 进行定期测试，确保多 AZ 配置的运营可靠性和韧性。SAP BTP 为关键服务提供开箱即用的多 AZ 高可用性。大多数服务实例，例如 SAP Cloud Identity Services、SAP Build Work Zone、SAP HANA Cloud 和 SAP Integration Suite，都在一个区域内的所有 AZ 上以主动-主动（active-active）模式运行，并利用主动负载均衡。数据持久化在 AZ 1 和 AZ 2 之间配置为主动-被动（active-passive）模式，并通过同步复制来保持数据完整性，以备被动实例需要转为主动时使用。如果其中一个 AZ 发生问题，其余区域会自动接管，在恢复正常运营之前维持服务连续性。这确保了 SAP BTP 服务的高可用性和稳健性能。
灾难恢复
但灾难呢？数据中心中断、自然灾害或网络攻击等灾难会对企业的云软件产生重大影响。遗憾的是，完全防范和避免灾难是不可能的。在发生灾难时，重要的是通过灾难恢复 (DR) 将影响降到尽可能低。对于 SAP BTP，我们设有两个概念。
标准 DR
SAP BTP 包含一个开箱即用、无需额外费用的标准 DR 解决方案。它旨在当 SAP 宣布灾难时，保护生产数据免遭不必要的丢失。标准 DR 的工作原理是从存储在该区域内另一个可用性区域的备份中恢复数据。SAP 持续备份 SAP BTP 的数据，保留期为 14 天。这些备份包含 SAP BTP 上数据库或持久化服务的数据和日志。虽然该服务不保证正式的 SLA，但灾难恢复流程基于"商业上合理的最佳努力"，以在灾难期间尽快恢复受影响的服务。您可以在产品文档中找到有关备份的更多信息：
https://help.sap.com/docs/btp/btp-admin-guide/data-backups-managed-by-sap。
由于这种方法仅是最低限度，而您作为客户希望有 SLA 保障，因此 SAP BTP 提供了区域内 DR（In-Metro DR）。
区域内 DR
区域内 DR 解决方案面向所有 SAP BTP 客户提供，适用于一系列经过审核的服务，提供合同承诺的 SLA：5 分钟 RPO 和 2 小时 RTO。该解决方案利用多 AZ 概念。至少每 12 个月执行一次 DR 测试。该 DR 产品范围包括 SAP Trust Center 中提供的 SAP BTP 灾难恢复概览中所列出的 SAP BTP 服务和 SAP BTP 区域。区域内 DR 仅防范单个 AZ 的灾难，而不防范整个区域的灾难。
Caution
请注意，对于标准 DR 和区域内 DR，均由 SAP 宣布灾难并启动恢复流程。您不能自行触发或请求该流程。
客户管理的场景
对于 SAP 管理的服务，区域内 DR 和高可用性是开箱即用的，使在 SAP 管理下使用 SAP BTP 的客户无需额外配置或合同即可受益于该设置。然而，在某些客户管理的场景中，例如并行扩展或持久化服务，客户必须进行适当配置，以确保满足多 AZ 要求。在 Cloud Foundry 和 Kyma 环境中，建议至少运行三个应用程序实例，SAP 会自动将它们分布在您所在区域的不同可用性区域中。对于持久化服务，您需要确保已配置相应的副本，确保主数据库和辅助数据库分布在不同的可用性区域中。
要了解有关 SAP BTP 高可用性和灾难恢复的更多信息，请参阅官方产品文档：
本课其余配图
