本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
服务水平协议和 SAP 许可证
对于灾难恢复实施，服务水平协议（SLA）用于定义在因灾难事件导致工作负载不可用时，系统在避免数据丢失和减少停机时间方面的韧性。
SAP 系统灾难恢复方法需要复制应用程序层、数据库层以及所有文件共享，例如 NFS 挂载。以下是实施灾难恢复时需要考虑的一些因素。
恢复时间目标（RTO）
恢复时间目标（RTO）是指应用程序在中断后能以多快的速度恢复。在发生灾难时，弹性灾难恢复使您能够在几分钟内，在目标区域上启动复制的服务器，使其进入完全预置的状态，从而继续运行业务。这种自动化方法可以实现低 RTO，并且比手动方法更快、更高效。
考虑因素
由于通常根据对业务流程的影响来评估 RTO，因此其他因素 [例如域名系统（DNS）的传播] 以及环境因素（包括灾难恢复团队的反应时间、目标环境的存储架构、操作系统的引导和应用程序启动时间），都会影响该目标值。
恢复点目标 (RPO)
弹性灾难恢复使用异步的块级复制，持续将更改复制到目标站点的磁盘。弹性灾难恢复的 RPO 通常在亚秒范围内。RPO 可能受到外部因素的影响，例如源系统将更改发送到暂存区所花费的时间。源系统上的事务量会对此造成进一步的影响。其他因素包括网络吞吐量和延迟、源服务器和复制服务器性能等。在计算灾难恢复事件期间可能丢失的数据量时，这些因素都应考虑在内。
考虑因素
由于弹性灾难恢复管理某些场景的方式，可能会不时观察到 SAP 工作负载的数据丢失量超出了亚秒级 RPO 下的预期水平。
发生硬重新引导、磁盘更改和崩溃时，弹性灾难恢复会触发磁盘的重新扫描。在重新扫描期间，复制代理不会将源服务器的更改复制到目标服务器。这会造成两台服务器之间的延迟。如果主系统在这段时间内出现故障，客户遭受的数据丢失量（以 RPO 衡量）可能会比预期的要多。
重新扫描时间取决于多个因素，不进行测试就无法预测。重新引导源服务器后，可能会进行重新扫描。重新扫描时间将根据源磁盘的大小而变。具体时间取决于磁盘的性能（线性读取）、暂存区磁盘性能以及源服务器上的写入操作速率（与重新扫描并行发送）。只要重新扫描还在继续执行并且没有“卡住”，操作就在正常运行。
SAP 数据库的磁盘可能会很大，更改率也可能会很高。我们建议您进行测试，以确保出现此类事件时能够满足您的 SLA 要求。此外，您必须确保主数据库与目标数据库在高峰活动周期内保持同步。
恢复一致性目标（RCO）
许多灾难恢复解决方案仅将 RTO 和 RPO 视为韧性的 SLA。您还必须考虑 SAP 工作负载的恢复一致性目标（RCO）。RCO 是衡量相互关联系统中分布式业务数据一致性的指标。在典型的客户环境中，SAP 系统紧密集成并且数据在这些系统之间频繁交换，例如 SAP ECC 或 SAP S/4HANA、SAP BW 或 SAP BW/4HANA、SAP CRM、SAP SRM、SAP GTS 等。这组紧密集成的系统称为系统组。对于灾难恢复失效转移，系统组内可能会要求 RCO 为零。这意味着出现灾难恢复失效转移时，必须将 SAP 系统组中的所有数据库恢复到相同的时间点。
考虑因素
弹性灾难恢复不能保证多个源实例之间的一致性。如果您的 RCO 要求为零，可以使用数据库原生复制技术进行时间点恢复，或者使用辅助时间历程进行回溯。
有关更多信息，请参阅 SAP Note 434647 - Point-in-time recovery in an SAP system group
SAP 许可证
SAP 系统通过使用硬件密钥的许可证进行保护。在 AWS，硬件密钥基于您的 Amazon EC2 实例 ID。您必须启动 Amazon EC2 实例，然后才能生成 SAP 许可证。当您在灾难恢复站点中恢复 SAP 系统时，SAP 许可证将失效，因为灾难恢复站点是新 Amazon EC2 实例。硬件密钥将不再匹配。启动恢复实例时会创建临时的 SAP 许可证，有效期为 28 天。您无需创建新 SAP 许可证。如果您需要灾难恢复实例在 28 天后继续运行，则可以使用恢复 Amazon EC2 实例 ID 申请新 SAP 许可证。
