

# REL11-BP05 使用静态稳定性来防止双模态行为
<a name="rel_withstand_component_failures_static_stability"></a>

 工作负载应具有静态稳定性，并且仅在单一正常模式下运行。双模态行为是指工作负载在正常模式和故障模式下表现出不同的行为。

 例如，您可能会尝试在不同的可用区中启动新实例，以便从可用区故障中恢复。在故障模式下，这可能会导致双模态响应。您应该构建静态稳定的工作负载，并且仅在一个模式下运行。在此示例中，这些实例应在出现故障之前，已经在第二个可用区中预置。这种静态稳定性设计可确保工作负载仅在单一模式下运行。

 **期望结果：**在正常模式和故障模式下，工作负载不会表现出双模态行为。

 **常见反模式：**
+  假设无论故障范围如何，始终可以预置资源。
+  尝试在故障期间动态获取资源。
+  在出现故障之前，没有跨可用区或跨区域预置足够的资源。
+  仅为计算资源考虑了静态稳定设计。

 **建立此最佳实践的好处：**采用静态稳定设计运行的工作负载，在正常情况和故障事件期间能够得到可预测的结果。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 当工作负载在正常模式和故障模式下展现出不同的行为时，这就是双模态行为（例如，在可用区发生故障时依赖于启动新的实例）。双模态行为的一个例子是，稳定的 Amazon EC2 设计在每个可用区中预置了足够的实例，用于处理在移除了一个可用区时的工作负载。弹性负载均衡或 Amazon Route 53 运行状况将进行检查，将负载从受损实例上移开。在流量转移以后，使用 AWS Auto Scaling 异步替换故障可用区的实例，并在运行状况良好的可用区中启动。适用于计算部署（如 EC2 实例或容器）的静态稳定性将提供最高水平的可靠性。

![\[图中显示了跨可用区的 EC2 实例的静态稳定性\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/static-stability.png)


 您必须就这一模型的成本以及在所有情况下保持工作负载韧性的业务价值进行权衡。预置较少的计算容量并依赖于在出现故障时启动新实例，这种方法的成本较低，但是对于大规模故障（例如可用区或区域受损），这种方法效果较差，因为它既依赖于运营层面，也依赖未受影响的可用区或区域中有足够的可用资源。

 您的解决方案还需要在工作负载的可靠性和成本需求之间做出取舍。静态稳定性架构适用于各种架构，包括跨多个可用区的计算实例、数据库只读副本设计、Kubernetes（Amazon EKS）集群设计和多区域失效转移架构。

 您还可以在每个可用区中使用更多资源，从而实施具有更好的静态稳定性的设计。通过添加更多可用区，您可以减少实现静态稳定性所需的额外计算容量。

 双模态行为的一个例子是，网络超时可能会导致系统尝试刷新整个系统的配置状态。这会向另一个组件添加意外负载，进而可能导致该组件出现故障，引发其他意外后果。此负面的反馈环路会影响工作负载的可用性。相反，您可以构建静态稳定的系统，并且仅在一个模式下运行。静态稳定的设计会持续工作，并且始终定期刷新配置状态。当调用失败时，工作负载将使用先前缓存的值并启动警报。

 双模态行为的另一个示例是允许客户端在故障发生时绕过工作负载缓存。这看起来似乎是可以满足客户端需求的解决方案，但它会明显改变工作负载的需求，而且很有可能导致故障。

 评测关键工作负载，确定哪些工作负载需要这种韧性设计。对于被视为关键的工作负载，必须审核每个应用程序组件。需要静态稳定性评估的服务类型示例包括：
+  **计算**：Amazon EC2、EKS-EC2、ECS-EC2、EMR-EC2 
+  **数据库**：Amazon Redshift、Amazon RDS、Amazon Aurora 
+  **存储**：Amazon S3（单区）、Amazon EFS（挂载）、Amazon FSx（挂载） 
+  **负载均衡器：**在某些设计下 

### 实施步骤
<a name="implementation-steps"></a>
+  构建静态稳定的系统，并且仅在一个模式下运行。在这种情况下，应在每个可用区或区域中预置足够的实例，以便在移除了一个可用区或区域时处理工作负载容量。您可以使用多种服务来路由到运行状况良好的资源，例如：
  +  [跨区域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
  +  [MRAP Amazon S3 多区域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
  +  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
  +  [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  配置[数据库只读副本](https://aws.amazon.com/rds/features/multi-az/)，应对单个主实例或只读副本丢失的情况。如果流量由只读副本提供服务，则每个可用区和每个区域中的资源数量，应等于可用区或区域出现故障时的总体需求量。
+  在 Amazon S3 存储中配置关键数据，设计为在可用区出现故障时可确保所存储数据的静态稳定性。如果使用 [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 存储类，则不应将其视为静态稳定，因为丢失该可用区会将对所存储数据的可访问性降到最低。
+  [负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)有时服务于特定可用区，这可能是因为配置不正确，也可能是有意设计成这样。在这种情况下，静态稳定的设计可能需要采用更复杂的设计，将工作负载分布到多个可用区。出于安全、延迟或成本方面的考虑，可能会使用最初的设计来减少区域间流量。

## 资源
<a name="resources"></a>

 **相关的 Well-Architected 最佳实践：**
+  [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 
+  [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) 

 **相关文档：**
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [Amazon Builders' Library：使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) 
+  [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [多可用区 RDS](https://aws.amazon.com/rds/features/multi-az/) 
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [跨区域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
+  [MRAP Amazon S3 多区域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
+  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
+  [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [单区 Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 
+  [Cross Zone Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 

 **相关视频：**
+  [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704) 