本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 備援的可用性
<a name="availability-with-redundancy"></a>

 當工作負載使用多個、獨立且備援的子系統時，與使用單一子系統相比，它可以達到更高層級的理論可用性。例如，考慮由兩個相同子系統組成的工作負載。它可以是完全可操作的，如果無論是子系統一個或子系統二是操作的。要使整個系統關閉，兩個子系統必須同時關閉。

 *如果一個子系統的故障概率為 1-*α*，那麼兩個冗餘子系統同時關閉的概率是每個子系統的故障概率的乘積，*F* =（1− *α*1）×（1− α）。* 2對於具有兩個備援子系統的工作負載，使用方程式 *(3)*，這會提供可用性定義為：

![\[三個方程式的圖片\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)


 因此，對於兩個可用性為 99％ 的子系統，其中一個失敗的可能性為 1％，並且它們都失敗的概率為（1− 99％）×（1− 99％）= .01％。這使得使用兩個備援子系統的可用性達 99.99%。

 **這可以概括來納入額外的冗餘備件，也是如此。**在方程式 *(5)* 中，我們只假設一個備用，但一個工作負載可能有兩個、三個或更多個備件，以便在多個子系統的同時損失中存活，而不會影響可用性。*如果工作負載有三個子系統，而兩個是備用系統，則三個子系統同時失敗的可能性為 (1− *α*) × (1− *α) × (1− α*) 或 (1− *α*) 3。*一般而言，只有當 **s** \$1 1 個子系統故障時，具有備用的工作負載才會失敗。

 *對於具有 *n* 個子系統和 *s* 備件的工作負載，*f* 是失敗模式的數量或 *s* \$1 1 個子系統可能會故障 n 的方式。*

 ***這實際上是二項式定理，即從一組 n 中選擇 *k* 個元素的組合數學，或者 *「***n** 選擇 k」。***在這種情況下，*k* 是 *s* \$1 1。

![\[四個方程式的圖片\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)


 然後，我們可以產生一個廣義的可用性近似值，其中包含了失敗模式和備用的數量。（要了解為什麼在近似值中這樣做，請參閱海萊曼等的附錄 2。 [打破可用性障礙](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331)。） 

![\[四個方程式的圖片\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)


 備用可套用至提供獨立失敗資源的任何相依性。不同 AZ 或 Amazon S3 儲存貯體中不同的 Amazon EC2 執行個體就AWS 區域是這個範例。使用備援可協助該相依性達到更高的整體可用性，以支援工作負載的可用性目標。

**規則五**  
 使用備用來增加工作負載中相依性的可用性。

 但是，備用是需要付出代價的。每個額外的備用成本與原始模塊相同，至少線性驅動成本。建置可以使用備援的工作負載也會增加其複雜性。它必須知道如何識別相依性失敗、將工作量從它轉移到健康狀態良好的資源，以及管理工作負載的整體容量。

 冗餘是一個優化問題。備用裝置太少，而且工作負載的故障頻率可能比預期的要高，備用裝置太多，而且工作負載執行的成本太高。有一個臨界值，即增加更多備件的成本將超過其實現認股權證的額外可用性。

 ***對於具有 99.5% 可用性的子系統，將我們的一般可用性與備用公式 *(7)* 搭配使用，工作負載的可用性為 *A* 1 − (1) (1−.995) 3 = 99.9999875% (每年停機時間約為 3.94 秒)，而在 10 個備用裝置中，我們會得到一*個* 1 − (1) (1−995) (1−9 ′) = 25.5 將是每年 1.26252 × 10 至 15 米，實際上是 0）。***在比較這兩個工作負載時，我們的備用成本增加了 5 倍，以實現每年減少 4 秒的停機時間。對於大部分的工作負載而言，成本的增加是不必要的，因為可用性的增加。下圖顯示了這種關係。

![\[顯示從增加的備用收益減少的圖表\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)


 在三個備件及以後，結果是每年預期停機時間的一秒鐘的幾分之一，這意味著在這一點之後，您將到達收益遞減的區域。可能有衝動「只是添加更多」以實現更高水平的可用性，但實際上，成本效益消失非常快。當子系統本身至少具有 99% 的可用性時，使用三個以上的備用裝置並不能為幾乎所有工作負載帶來明顯的增益。

**規則第六條**  
 備用的成本效率有一個上限。利用所需的最少備用裝置來達到所需的可用性。

 選取正確的備援數目時，您應該考慮失敗單位。例如，讓我們檢查一個需要 10 個 EC2 執行個體來處理尖峰容量的工作負載，並將它們部署在單一 AZ 中。

 由於 AZ 設計為故障隔離界限，故障單位不僅是單一 EC2 執行個體，因為整個 AZ 值的 EC2 執行個體可能會一起失敗。在這種情況下，您需要[與另一個 AZ 新增冗餘](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)，部署 10 個額外的 EC2 執行個體來處理 AZ 故障時的負載，總共 20 個 EC2 執行個體 (遵循靜態穩定性模式)。

 雖然這似乎是 10 個備用 EC2 實例，但它實際上只是一個備用 AZ，因此我們沒有超過收益遞減的點。不過，您可以更具成本效益，同時利用三個 AZ 並在每個 AZ 部署五個 EC2 執行個體來提高可用性。

 這為一個備用 AZ 提供總共 15 個 EC2 執行個體 (而兩個 AZ 具有 20 個執行個體)，仍然提供所需的 10 個執行個體總計，以在影響單一 AZ 的事件期間提供尖峰容量。因此，您應該在工作負載 (執行個體、儲存格、AZ 和區域) 使用的所有容錯隔離界限內建備容錯能力。