单一区域架构模式

您要求数据始终仅位于特定的地理Amazon区域（区域）

您希望避免与多区域方法相关的潜在网络延迟注意事项

您希望避免与多区域方法相关的成本影响或差异，包括：

您需要一个明确的时间窗口来完成生产恢复，并需要保证另一个可用区中生产 SAP 数据库和中央服务层的计算容量可用性。

您可以接受跨两个可用区为生产 SAP 数据库和中央服务层部署所需的计算和存储的额外成本。

您的非生产环境与生产环境的规模不同，因此在可用区出现故障或 Amazon EC2 服务严重降级时，不能将其用作生产的牺牲容量。

您可以接受跨可用区域的数据复制（需要数据库复制功能或块级复制解决方案）和相关成本。

您可以接受，可用区之间的自动故障转移需要第三方集群解决方案。

您可以接受所需的可变持续时间（包括剩余可用区域中所需计算容量的可用性延迟），以便在区域出现故障时将应用程序层的容量恢复到 100%。

100% 的计算容量部署在可用区 1 和可用区 2，用于生产 SAP 数据库和中央服务层。

生产应用程序层（主动/主动）的计算容量部署在可用区 1 和可用区 2 中。如果可用区出现故障，则需要扩展应用程序层，使其在剩余区域内恢复到 100% 的容量。

使用数据库复制功能或块级复制解决方案，将 SAP 数据库保存在 Amazon EBS 上的两个可用区中。

Amazon EC2 auto recovery 已为所有实例配置以防范底层硬件故障，但受第三方集群解决方案保护的实例除外。

Amazon EFS 用于 SAP 全球文件系统。

SAP 数据库会定期备份到亚马逊 S3。

Amazon S3 单区域复制配置为保护逻辑数据丢失。

定期为所有服务器拍摄 Amazon Machine Image/Amazon EBS 快照。 

低平均恢复时间 (MTTR)

可预测的恢复服务 (RTS)

能够通过将数据库和中央服务层故障转移到可用区 2，防止可用区严重降级或整体故障

如果出现可用区或 Amazon EBS 故障，则无需从 Amazon S3 恢复数据

在可用区之间进行自动故障切换需要有据可查和测试的流程。

维护自动故障转移解决方案需要经过充分记录和测试的流程。

在可用区出现故障或 Amazon EC2 服务严重降级时，扩展Amazon资源以使应用程序层恢复到所需容量需要有据可查和测试的流程。

如果该区域内的可用区出现故障，您需要能够继续为生产配置多可用区。

您需要一个明确的时间窗口来完成生产恢复，并确保另一个可用区中生产 SAP 数据库和中央服务层的计算容量可用性。

您可以接受跨两个可用区为生产 SAP 数据库和中央服务层部署所需的计算和存储的额外成本。

您可以接受跨可用区域的数据复制（需要数据库复制功能或块级复制解决方案）和相关成本。

您可以接受，可用区之间的自动故障转移需要第三方集群解决方案。

在可用区出现故障时，您可以接受所需的可变持续时间（包括剩余可用区域中所需计算容量的可用性延迟），以使应用程序层的容量恢复到 100%。

100% 的计算容量部署在可用区 1 和可用区 2 中，用于生产 SAP 数据库和中央服务层。

100% 的生产计算能力（数据库和中央服务）部署在第三个可用区，供非生产人员在正常操作中使用。

生产应用程序层（主动/主动）的计算容量部署在可用区 1 和可用区 2 中。如果可用区出现故障，则需要扩展应用程序层，使其在剩余区域内恢复到 100% 的容量。

Amazon EC2 auto reco very 已为所有实例配置以防范底层硬件故障，但受第三方集群解决方案保护的实例除外。

使用数据库复制功能或块级复制解决方案，将 SAP 数据库保存在 Amazon EBS 上的两个可用区中。

Amazon EFS 用于 SAP 全球文件系统。

SAP 数据库会定期备份到亚马逊 S3。 

Amazon S3 单区域复制配置为防止逻辑数据丢失。

所有服务器的 Amazon Machine Image/Amazon EBS 快照都是定期拍摄的。

低平均恢复时间 (MTTR)

可预测的恢复服务 (RTS)

能够通过将数据库和中央服务层故障转移到可用区 2，防止可用区严重降级或整体故障

在可用区出现故障或 Amazon EBS 故障时，无需从 Amazon S3 恢复数据

可选择将数据保存在 Amazon EBS 上的三个不同可用区中，具体取决于数据库或块级复制解决方案的功能

如果可用区出现严重降级或完全出现故障，则使用非生产计算容量在两个可用区中恢复生产

在可用区之间进行自动故障切换需要有据可查和测试的流程。

维护自动故障转移解决方案需要经过充分记录和测试的流程。

在可用区出现故障或 Amazon EC2 服务严重降级时，扩展Amazon资源以使应用程序层恢复到所需容量需要有据可查和测试的流程。

如果可用区故障影响生产，则需要经过充分记录和测试的流程，才能将非生产计算容量重新分配为在两个可用区中运行的生产容量。

您需要一个明确的时间窗口来完成生产恢复，并确保 SAP 数据库和中央服务层的另一个可用区域的计算容量可用性。

您可以接受将计算容量从非生产重新分配到生产所需的额外时间，作为恢复生产的总体时间窗口的一部分。

您可以接受将数据从另一个可用区的 Amazon S3 恢复到 Amazon EBS 所需的时间作为恢复生产的整个时间窗口的一部分。

您可以接受在可用区出现故障（包括剩余可用区所需计算容量的可用性出现任何延迟）后将应用程序层恢复到 100% 容量所需的可变持续时间。

您可以接受一段时间，即在可用区出现故障或 Amazon EC2 服务严重降级时，只为生产 SAP 数据库和中央服务层部署一组计算。

100% 的计算容量部署在可用区 1 中，用于生产 SAP 数据库和中央服务层。

100% 的计算容量部署在可用区 1 中，用于生产 SAP 应用程序层。

100% 的生产计算容量（SAP 数据库和中央服务）部署在可用区 2 中，供非生产部门在正常操作中使用。

为所有实例配置了 Amazon EC2 自动恢复，以防出现底层硬件故障。

SAP 数据库仅保存在单个可用区的 Amazon EBS 上，不会复制到其他可用区。

Amazon EFS 用于 SAP 全球文件系统。

SAP 数据库数据会定期备份到 Amazon S3。

Amazon S3 单区域复制配置为防止逻辑数据丢失。

定期为所有服务器拍摄 Amazon Machine Image/Amazon EBS 快照。

通过在生产可用区出现故障时使用非生产容量来优化成本

在两个可用区部署所需的计算容量，以实现更可预测的恢复时间

为了确保可恢复性，需要经过充分记录和测试的流程，用于将所需的计算容量从非生产重新分配到生产以及将数据恢复到不同的可用区。

如果可用区故障影响生产，则可能会丢失非生产环境。

由于两个可用区之间缺乏高可用性，因此在出现计算故障或可用区故障时恢复生产所需的时间会增加。

如果可用区出现故障或 Amazon EC2 服务严重降级，您可以接受与在其他可用区重新创建Amazon资源并将永久数据恢复到 Amazon EBS 所需的可变时间长度（包括剩余可用区中所需计算容量可用性的任何延迟）相关的风险。

您希望通过多可用区方法避免成本影响，并接受生产 SAP 系统停机的相关风险。

100% 的计算容量部署在可用区 1 中，用于生产 SAP 数据库和中央服务层。

100% 的计算容量部署在可用区 1 中，用于生产 SAP 应用程序层。

Amazon EC2 针对所有实例进行了配置，以防出现底层硬件故障。

部署的非生产计算容量低于为生产 SAP 数据库和中央服务层部署的计算容量的 100%。

SAP 数据库仅保存在单个可用区的 Amazon EBS 上，不会复制到其他可用区。

Amazon EFS 用于 SAP 全球文件系统。

SAP 数据库会定期备份到亚马逊 S3。

Amazon S3 单区域复制配置为防止逻辑数据丢失。

所有服务器的 Amazon Machine Image/Amazon EBS 快照都是定期拍摄的。

最低成本

最简单的设计

最简单的操作

为确保可恢复性，需要在不同可用区扩展Amazon资源和恢复数据的流程有据可查、经过测试。