本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 单区域架构模式
在以下情况下，选择单区域模式：
+ 您要求数据始终仅位于特定的地理AWS区域（区域）
+ 您希望避免多区域方法中可能出现的[潜在网络延迟](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-multi-region-considerations)因素
+ 您希望避免多区域方法带来的成本影响或差异，包括：
+ [AWS不同AWS地区的服务定价](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-selecting-the-aws-regions)
+ [跨区域数据传输费用](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-cross-regional-data-transfer)
## 模式 1：单个区域，有两个 AZs 用于生产
**图 7：单个区域，具有两个可用区用于生产环境**
![\[单个区域，具有两个可用区用于生产环境\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-pattern-1.png)
在这种模式下，您可以跨两个可用区部署所有生产系统。在两个可用区中，为生产 SAP 数据库和中央服务层部署的计算容量大小相同，在一个可用区出现故障时，可自动进行失效转移。SAP 应用程序层所需的计算容量在两个可用区之间以 50/50 的比例分配。您的非生产系统的大小与生产系统**不相等**，并且部署在该区域内的相同可用区或不同可用区中。
**如需满足以下要求，请选择此模式：**
+ 您需要规定完成生产环境恢复的时间长度，并需要确保在另一个可用区中，提供用于生产 SAP 数据库和中央服务层的计算容量。
+ 对于跨两个可用区为生产 SAP 数据库和中央服务层部署所需的计算和存储容量，您可以接受由此产生的额外成本。
+ 您的非生产环境与生产环境的规模不同，因此在可用区出现故障或亚马逊 EC2 服务严重降级时，不能将其用作生产的牺牲容量。
+ 您可以接受跨可用区的数据复制（需要数据库复制功能或块级复制解决方案）和相关成本。
+ 您可以接受在可用区之间实现自动失效转移需要第三方集群解决方案。
+ 您可以接受在某个可用区出现故障时，将应用程序层恢复到 100% 容量所需的时间长度不确定（包括在剩余可用区中提供所需计算容量会出现的任何延迟）。
**关键设计原则**
+ 100% 的计算容量部署在可用区 1 和可用区 2 中，用于生产 SAP 数据库和中央服务层。
+ 计算容量部署在可用区 1 和可用区 2 中，用于生产应用程序层（主动/主动）。在某个可用区出现故障时，需要扩展应用程序层，在剩余的可用区中恢复 100% 的容量。
+ 使用数据库复制功能或块级复制解决方案，将 SAP 数据库保存在两个可用区中的 Amazon EBS 上。
+ Amazon a EC2 uto recovery 针对所有实例进行了配置，以防范底层硬件故障，但受第三方集群解决方案保护的实例除外。
+ Amazon EFS 用于 SAP 全球文件系统。
+ SAP 数据库定期备份到 Amazon S3。
+ 配置 Amazon S3 [单区域复制](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-s3-replication)来防范[逻辑数据丢失](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss)。
+ 定期为所有服务器拍摄 Amazon Machine Image/Amazon EBS 快照。
**优点**
+ 低平均恢复时间（MTTR）
+ 可预测的恢复服务（RTS）
+ 能够将数据库和中央服务层失效转移到可用区 2，防止性能严重降级或可用区的整体故障
+ 可用区或 Amazon EBS 出现故障时，不要求从 Amazon S3 恢复数据
**注意事项**
+ 对于可用区之间的自动失效转移，需要有明确记录在案且经过测试的流程。
+ 对于维护自动化失效转移解决方案，需要有明确记录在案且经过测试的流程。
+ 如果可用区出现故障或 Amazon EC2 服务严重降级，则需要经过充分记录和测试的流程来扩展AWS资源，使应用程序层恢复到所需的容量。
## 模式 2：在第三个 AZ 中有一个区域，其中两个 AZs 用于生产，生产规模的非生产
**图 8：单个区域，具有两个可用区用于生产环境，与生产环境相同大小的非生产环境位于第三个可用区中**
![\[单个区域，具有两个可用区用于生产环境，与生产环境相同大小的非生产环境位于第三个可用区中\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-pattern-2.png)
在这种模式下，您可以跨两个可用区部署所有生产系统。在两个可用区中，为生产 SAP 数据库和中央服务层部署的计算容量大小相同，在一个可用区出现故障时，可自动进行失效转移。SAP 应用程序层所需的计算容量在两个可用区之间以 50/50 的比例分配。您的非生产系统的大小与生产系统相等，部署在第三个可用区中。如果部署生产系统的某一个可用区出现故障，则会重新分配非生产容量，以便将生产环境恢复到多可用区模式。
**如需满足以下要求，请选择此模式：**
+ 在该区域内的某个可用区出现故障时，您需要能够继续保持用于生产环境的多可用区配置。
+ 您需要规定完成生产环境恢复的时间长度，并需要确保在另一个可用区中，提供用于生产 SAP 数据库和中央服务层的计算容量。
+ 对于跨两个可用区为生产 SAP 数据库和中央服务层部署所需的计算和存储容量，您可以接受由此产生的额外成本。
+ 您可以接受跨可用区的数据复制（需要数据库复制功能或块级复制解决方案）和相关成本。
+ 您可以接受在可用区之间实现自动失效转移需要第三方集群解决方案。
+ 您可以接受在某个可用区出现故障时，将应用程序层恢复到 100% 容量所需的时间长度不确定（包括在剩余可用区中提供所需计算容量会出现的任何延迟）。
**关键设计原则**
+ 100% 的计算容量部署在可用区 1 和可用区 2 中，用于生产 SAP 数据库和中央服务层。
+ 100% 的生产计算容量（数据库和中央服务）部署在第三个可用区，供非生产环境用于正常操作。
+ 计算容量部署在可用区 1 和可用区 2 中，用于生产应用程序层（主动/主动）。在某个可用区出现故障时，需要扩展应用程序层，在剩余的可用区中恢复 100% 的容量。
+ [Amazon a EC2 uto reco](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-ec2-auto-recovery) very 针对所有实例进行了配置，以防范底层硬件故障，但受第三方集群解决方案保护的实例除外。
+ 使用数据库复制功能或块级复制解决方案，将 SAP 数据库保存在两个可用区中的 Amazon EBS 上。
+ Amazon EFS 用于 SAP 全球文件系统。
+ SAP 数据库定期备份到 Amazon S3。
+ 配置 Amazon S3 [单区域复制](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-s3-replication)来防范[逻辑数据丢失](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss)。
+ 所有服务器的 Amazon Machine Image/Amazon EBS 快照都是定期拍摄的。
**优点**
+ 低平均恢复时间（MTTR）
+ 可预测的恢复服务（RTS）
+ 能够将数据库和中央服务层失效转移到可用区 2，防止性能严重降级或可用区的整体故障
+ 可用区出现故障或 Amazon EBS 出现故障时，不要求从 Amazon S3 恢复数据
+ 将数据保存在三个不同可用区中的 Amazon EBS 上的选项，具体取决于数据库或块级复制解决方案的功能
+ 如果可用区出现严重降级或整个可用区出现故障，则使用非生产计算容量，在两个可用区上恢复生产
**注意事项**
+ 对于可用区之间的自动失效转移，需要有明确记录在案且经过测试的流程。
+ 对于维护自动化失效转移解决方案，需要有明确记录在案且经过测试的流程。
+ 如果可用区出现故障或 Amazon EC2 服务严重降级，则需要经过充分记录和测试的流程来扩展AWS资源，使应用程序层恢复到所需的容量。
+ 在某个可用区出现故障影响生产时，对于从非生产环境重新分配计算容量来在两个可用区中回复生产环境的运行，需要有明确记录在案且经过测试的流程。
## 模式 3：单个区域，一个可用区用于生产环境，另一个可用区用于非生产环境
**图 9：单个区域，一个可用区用于生产环境，另一个可用区用于非生产环境**
![\[单个区域，一个可用区用于生产环境，另一个可用区用于非生产环境\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-pattern-3.png)
在这种模式下，您将所有生产系统部署在一个可用区中，并将所有非生产系统部署在另一个可用区中。您的非生产系统的大小与生产系统相等。
**如需满足以下要求，请选择此模式：**
+ 您需要规定完成生产环境恢复的时间长度，并需要确保另一个可用区中，用于 SAP 数据库和中央服务层的计算容量的可用性。
+ 您可以接受在恢复生产的总时间长度中，包括将计算容量从非生产环境重新分配到生产环境所需的额外时间。
+ 您可以接受在恢复生产的总时间长度中，包括将数据从另一个可用区中的 Amazon S3 恢复到 Amazon EBS 所需的时间。
+ 您可以接受在某个可用区出现故障后，将应用程序层恢复到 100% 容量所需的时间长度不确定（包括在剩余可用区中提供所需计算容量会出现的任何延迟）。
+ 您可以接受一段时间，即在可用区出现故障或 Amazon 服务严重降级时，只为生产 SAP 数据库和中央 EC2 服务层部署一组计算。
**关键设计原则**
+ 100% 的计算容量部署在可用区 1 中，用于生产 SAP 数据库和中央服务层。
+ 100% 的计算容量部署在可用区 1 中，用于生产 SAP 应用程序层。
+ 100% 的生产计算容量（SAP 数据库和中央服务）部署在可用区 2，供非生产环境用于正常操作。
+ 为所有实例配置了 Amazon a EC2 uto Recovery，以防出现底层硬件故障。
+ SAP 数据库仅保存在单个可用区的 Amazon EBS 上，不复制到其他可用区。
+ Amazon EFS 用于 SAP 全球文件系统。
+ SAP 数据库的数据定期备份到 Amazon S3。
+ 配置 Amazon S3 单区域复制来防范逻辑数据丢失。
+ 定期为所有服务器拍摄 Amazon Machine Image/Amazon EBS 快照。
**优点**
+ 在生产环境可用区出现故障时，使用非生产容量来优化成本
+ 所需的计算容量部署在两个可用区中，从而实现更可预测的恢复时间
**注意事项**
+ 对于将所需的计算容量从非生产环境部署到生产环境并在不同的可用区中恢复数据，需要有明确记录在案且经过测试的流程来确保可恢复性。
+ 如果某个可用区故障影响到生产环境，则非生产环境可能会丢失。
+ 由于采用两个可用区缺乏高可用性，因此在计算容量或可用区出现故障时，恢复生产所需的时间会增加。
## 模式 4：单个区域，具有单个可用区用于生产环境
**图 10：单个区域，具有单个可用区用于生产环境**
![\[单个区域，具有单个可用区用于生产环境\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-pattern-4.png)
在这种模式下，您将所有生产系统部署在一个可用区中，并将所有非生产系统部署在同一个或另一个可用区中。您的非生产系统的大小与生产系统**不相等**。**\$1**\$1
**如需满足以下要求，请选择此模式：**
+ 如果可用区出现故障或 Amazon EC2 服务严重降级，您可以接受与在其他可用区重新创建AWS资源并将永久数据恢复到 Amazon EBS 所需的可变时间长度（包括剩余可用区中所需计算容量可用性的任何延迟）相关的风险。
+ 您希望避免多可用区方法带来的成本影响，并可以接受生产 SAP 系统停机时间的相关风险。
**关键设计原则**
+ 100% 的计算容量部署在可用区 1 中，用于生产 SAP 数据库和中央服务层。
+ 100% 的计算容量部署在可用区 1 中，用于生产 SAP 应用程序层。
+ Amazon EC2 已针对所有实例进行了配置，以防出现底层硬件故障。
+ 部署的非生产计算容量，不到为生产 SAP 数据库和中央服务层部署的计算容量的 100%。
+ SAP 数据库仅保存在单个可用区的 Amazon EBS 上，不复制到其他可用区。
+ Amazon EFS 用于 SAP 全球文件系统。
+ SAP 数据库定期备份到 Amazon S3。
+ 配置 Amazon S3 单区域复制来防范逻辑数据丢失。
+ 所有服务器的 Amazon Machine Image/Amazon EBS 快照都是定期拍摄的。
**优点**
+ 最低的成本
+ 最简单的设计
+ 最简单的操作
**注意事项**
+ 为确保可恢复性，需要在不同可用区扩展AWS资源和恢复数据的流程有据可查、经过测试。