本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
服务水平协议和 SAP 许可证
对于灾难恢复实施，服务级别协议 (SLA) 用于定义系统在避免数据丢失和减少因灾难事件导致工作负载不可用时的停机时间方面的弹性。
SAP 系统灾难恢复方法需要复制应用程序层、数据库层和任何文件共享，例如 NFS 装载。以下是实施灾难恢复时需要考虑的一些因素。
恢复时间目标（RTO）
恢复时间目标 (RTO) 是指应用程序在中断后能够以多快的速度恢复。在发生灾难时，Elastic Daser Recovery 使您能够在几分钟内将复制的服务器启动到目标区域的完全配置状态并继续运行。这种自动化方法支持低 RTO。它可能比手动方法更快、更有效。
考虑
由于通常根据对业务流程的影响来评估 RTO，因此其他因素，例如域名系统 (DNS) 传播、环境因素，包括灾难恢复团队的反应时间、目标环境的存储架构、操作系统启动和应用程序启动时间，都会影响该目标值。
恢复点目标 (RPO)
Elastic Disaster Recovery 会持续将区块级别的磁盘更改异步复制到目标站点。Elastic 灾难恢复的 RPO 通常在亚秒范围内。RPO 可能受到外部因素的影响，例如源系统将更改发送到暂存区域所花费的时间。源系统上的交易量进一步影响了这一点。其他因素包括网络吞吐量和延迟、源服务器和复制服务器性能等。 应衡量这些因素，以计算灾难恢复事件期间可能丢失的数据量。
考虑
由于 Elastic 灾难恢复管理某些场景的方式，SAP 工作负载可能不时观察到的数据丢失量可能比亚秒的 RPO 更长。
如果发生硬重启、磁盘更改和崩溃，Elastic 灾难恢复会触发磁盘的重新扫描。在重新扫描期间，复制代理不会将源服务器的更改复制到目标服务器。这会在两台服务器之间造成延迟。如果主系统在这段时间内出现故障，客户遭受的数据丢失量（以 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 系统组中的所有数据库恢复到相同的状态 point-in-time。
考虑
Elastic 灾难恢复并不能保证多个源实例之间的一致性。如果您的 RCO 要求为零，则可以使用数据库本机复制技术进行 point-in-time恢复，也可以使用回溯技术进行二次时空旅行。
有关更多信息，请参阅 SAP Note 434647：SAP 系统组中的 P oint-in-time Recovery
SAP 许可证
SAP 系统由使用硬件密钥的许可证保护。在上 Amazon，硬件密钥基于您的 Amazon EC2 实例 ID。在生成 SAP 许可证之前，必须启动您的 Amazon EC2 实例。当您在灾难恢复站点中恢复 SAP 系统时，SAP 许可证将失效，因为灾难恢复站点是一个新的 Amazon EC2 实例。硬件密钥将不再匹配。启动恢复实例时会创建临时的 SAP 许可证，有效期为 28 天。您无需创建新的 SAP 许可证。如果您需要灾难恢复实例在 28 天后继续运行，则可以申请带有恢复 Amazon EC2 实例 ID 的新 SAP 许可证。