本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 可用性和冗余
<a name="availability-with-redundancy"></a>

 当工作负载使用多个独立的冗余子系统时，它可以实现比使用单个子系统更高的理论可用性水平。例如，假设某个工作负载由两个完全相同的子系统组成。只要有一个子系统正常运行，工作负载就能正常运行。要让整个系统停机，两个子系统必须同时关闭。

 如果一个子系统的故障概率为 1 − *α*，则两个冗余子系统同时停机的概率就是每个子系统的故障概率的乘积：*F* = (1−*α*1) × (1−*α*2)。对于具有两个冗余子系统的工作负载，根据公式 *(3)*，其可用性为：

![\[三个公式的图片\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)


 因此，对于两个可用性为 99% 的子系统，如果一个子系统出现故障的概率为 1%，那么两个子系统都出现故障的概率则为 (1−99%) × (1−99%) = 0.01%。这使得使用两个冗余子系统的可用性达到 99.99%。

 这一规律也适用于增加冗余备件 *s***。在公式 *(5)* 中，我们只假设有一个备件，但是一个工作负载可能有两个、三个或更多备件，从而可以在多个子系统同时失效的情况下正常运行，不会影响可用性。如果某个工作负载有三个子系统并且其中两个是备件，则所有三个子系统同时出现故障的概率为 (1−*α*) × (1−*α*) × (1−*α*)，即 (1−*α*)3。一般来说，具有 *s* 个备件的工作负载只有在 *s* \$1 1 个子系统发生故障时才会失效。

 对于具有 *n* 个子系统和 *s* 个备件的工作负载来说，*f* 代表故障次数，也是 *n* 个子系统中有 *s* \$1 1 个子系统发生故障的概率。

 这实际上是二项式定理，即从 *n* 个元素中选择 *k* 个元素的组合数学（*“**n* *选* *k**”*）。在本例中，*k* 为 *s* \$1 1。

![\[四个公式的图片\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)


 然后，我们可以得出一个包含故障次数和备件数量的广义可用性近似值。（要理解为什么是近似值，请参阅 Highleyman 等人的著作 [Breaking the Availability Barrier](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331) 的附录 2。） 

![\[四个公式的图片\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)


 提供独立失败的资源的任何依赖项都可以设置备件。位于不同 AWS 区域中的不同可用区或不同 Amazon S3 桶中的 Amazon EC2 实例就是一个这方面的例子。使用备件可以帮助依赖项实现更高的总体可用性，从而支持工作负载的可用性目标。

**规则 5**  
 使用备件以便提高工作负载中的依赖项的可用性。

 但是，备件需要投入成本。增加的每个备件的成本与原始模块相同，所以成本至少会线性提高。构建可以使用备件的工作负载也会增加其复杂性。工作负载必须识别依赖项故障、将工作转移到正常运行的资源上，并管理总体容量。

 冗余是一种优化问题。备件太少，工作负载可能比预期更频繁地出现故障；备件太多，工作负载的运行成本就会过高。超出某个阈值之后，增加更多备件的成本将会超过额外获得的可用性带来的收益。

 根据成本与备件的一般公式，即公式 *(7)*，如果子系统的可用性为 99.5%，设置两个备件，那么工作负载的可用性 *A* ≈ 1 − (1)(1−.995)3 = 99.9999875%（每年停机时间约为 3.94 秒）；而如果设置 10 个备件，那么可用性 *A* ≈ 1 − (1)(1−.995)11 = 25.5 个 9**（每年停机时间约为 1.26252 × 10−15 *毫**秒*，实际上等于 0）。比较这两种工作负载可以发现，每年减少四秒钟的停机时间所产生的备件成本提高了 5 倍。对于大多数工作负载来说，成本的增加与可用性的提升显然不成比例。下图显示了这种关系。

![\[增加备件导致收益递减的示意图\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)


 当备件不少于三个时，每年的预期停机时间不到一秒，这意味着在此之后进入了收益递减区间。有人可能想要不断增加备件以便实现更高的可用性，但实际上，成本效益很快就会消失。当子系统本身的可用性至少达到 99% 时，使用三个以上的备件并不能为几乎任何工作负载打来实质性的明显效益。

**规则 6**  
 备件的成本效益存在上限。利用最少的备件来实现所需的可用性。

 在选择正确的备件数量时，您应该考虑故障单元。例如，我们假设某个工作负载需要 10 个 EC2 实例来处理峰值容量，并且这些实例部署在单个可用区内。

 可用区是一种故障隔离边界，因此故障单元不仅仅是单个 EC2 实例，因为整个可用区内的 EC2 实例可能会一起出现故障。在这种情况下，您需要[通过另一个可用区来添加冗余](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)，也就是再部署 10 个 EC2 实例以便在可用区出现故障时处理负载，这样 EC2 实例的总数就是 20 个（遵循静态稳定模式）。

 虽然看起来有 10 个备用 EC2 实例，但实际上我们只部署了一个备用可用区，还没有超过收益递减的边界。但是，您还可以使用 3 个可用区，并在每个可用区部署 5 个 EC2 实例，这样可以进一步提高成本效益和可用性。

 这时有 1 个可用区处于备用状态，总共有 15 个 EC2 实例（而不是 2 个可用区和 20 个实例）。如果出现影响单个可用区的事件，这种配置仍然可以提供所需的 10 个实例来处理峰值容量。因此，您应该设置备件，以便在工作负载使用的所有故障隔离边界（实例、单元、可用区和区域）内建立容错能力。