計算雲中的應用程序可用性
在雲中部署關鍵業務應用程序時，您要確保它們具有高可用性。 好消息是，如果您進行適當的計劃，則可以實現99.99％（4-nines）的可用性或更高。 但是，計算您的真實可用性可能並不像看起來那樣簡單。
在考慮可用性時，您必須考慮使訪問應用程序成為可能的關鍵組件，我將其稱為可用性鏈。 可用性鏈的組成部分是：
- 計算
- 網絡
- 存儲
- 應用
- 依賴服務
您的應用程序只有最弱的鏈接才可用，並且您向鏈中添加的每個其他鏈接的停機時間都會成倍增加。讓我們檢查每個鏈接。
計算可用性
三個主要的雲服務提供商中的每一個都有一些相似之處。 這三個平台的共同點是它們將致力於計算的服務級別協議（SLA）。
當您在不同可用性區域中配置了兩個或多個VM時，所有三個VM的公共雲提供商的SLA為99.99％。請記住，此SLA僅保證在任何給定時間對其中一個VM的遠程訪問，它不保證VM內運行的服務或應用程序的可用性。如果在單個數據中心內部署單個VM，則此SLA的範圍從“每小時90％”（AWS）到99.5％（Azure和GCP）或99.9％（使用Premium SSD時，Azure單個VM）。
真正的高可用性從99.99％開始，因此第一步是確保您的應用程序可用，是確保該應用程序分佈在兩個或多個跨越可用區的VM中。 通過將兩個VM分佈在兩個可用區中，可以為您提供至少其中一個VM的99.99％的可用性，您可以得出以下理論：如果三個VM分佈在三個可用區中，則您的可用性將甚至超過99.99％。 儘管雲提供商的SLA永遠不會保證可用性超過99.99％（無論使用的可用性區域有多少），但是如果您使用純統計信息，您可能會得出結論，您的可用性可能會高達99.999999％或8尼茲。可用性，每月停機時間為26.30毫秒。
1-（。0001 * .0001）= .99999999
具有三個可用區的99.999999％可用性？
不要四處引用那個數字。 但是請記住，如果兩個可用性區域可以為您提供99.99％的可用性，這是有道理的。 可以肯定地說，三個可用區將為您提供超過99.99％的可用性。
計算只是可用性鏈中的一個環節。 我們仍然必須解決網絡，存儲和其他相關服務，這些都代表了可能的故障點。
網絡可用性
為了使您的應用程序可用，客戶端與應用程序之間的每個網絡躍點以及應用程序依賴的所有資源都必須可用，並且必須在可容忍的延遲範圍內工作。 您需要了解數據庫服務器，應用程序服務器，Web服務器和客戶端之間的網絡鏈接，以準確了解網絡可能在哪裡發生故障。 請記住，可用性鏈中的鏈接越多，總體可用性就越低。
儘管標準計算SLA涵蓋了同一vNet中虛擬機之間的網絡可用性，但是您可能仍在使用其他網絡服務。 這只是您可能會使用的網絡服務的一些示例，這些示例會影響整體應用程序的可用性。
快速路線– 99.95％
VPN網關– 99.9％至99.95％
負載均衡器– 99.99％
流量管理器– 99.99％
彈性負載平衡器– 99.99％
直接連接– 99.9％– 99.99％
基於到目前為止所學的知識，讓我們看一下跨兩個可用區部署的應用程序的可用性。
99.99％的計算可用性
99.99％負載均衡器可用性
.9999 * .9999 = .9998
99.98％的可用性=每月約9分鐘的停機時間
既然我們已經解決了計算和網絡可用性問題，那麼讓我們繼續進行存儲。
存儲空間
現在這裡是故事多毛的地方。 看一下以下存儲SLA
https://azure.microsoft.com/zh-CN/support/legal/sla/storage/v1_5/
https://cloud.google.com/storage/sla
https://aws.amazon.com/compute/sla/
顯然，Azure和Google在塊存儲解決方案上提供了99.9％的SLA。 AWS在這裡沒有特別提及EBS。 他們只談論虛擬機，並按小時而不是其他雲提供商那樣按月衡量其單實例虛擬機的可用性。 為了便於討論，讓我們使用Azure和GCP均已發布的99.9％可用性保證。
在前面的示例的基礎上，讓我們為方程式添加一些存儲空間。
99.99％的計算可用性
99.99％負載均衡器可用性
99.9％託管磁盤
.9999 * .9999 * .999 = .9988
99.88％的可用性=每月約53分鐘的停機時間。
53分鐘的停機時間比我們在先前示例中計算的9分鐘的停機時間要長得多。 我們如何才能最大程度地降低99.9％的存儲可用性的影響？ 我們必須在存儲中建立更多的冗餘！
幸運的是，在計劃應用程序可用性時，我們通常會包括存儲冗餘。 例如，當我們站起Web服務器時，每個Web服務器通常會將數據存儲在本地連接的磁盤上。 部署域控制器時，Microsoft Active Directory負責在所有域控制器之間複製AD信息。 對於類似SQL Server的情況，我們利用AlwaysOn可用性組或SIOS DataKeeper來保持數據在本地連接的磁盤之間的同步。
我們跨不同可用性區域分佈的數據副本越多，我們越有可能倖免於難。
例如，將數據存儲在不同可用性區域中的兩個不同磁盤上的應用程序將受益於冗餘，而不是99.9％的可用性，它更有可能實現99.9999％的存儲可用性。
1 –（.001 * .001）= .999999
如果將其放到先前的方程式中，圖片將開始看起來更亮一些。
.9999 * .9999 * .999999 = .9998
99.98％的可用性=約9分鐘的停機時間
通過跨多個可用區（因此跨多個磁盤）複製數據，我們有效地減輕了與雲存儲相關的停機時間。
應用程序和相關服務的可用性
您已盡力確保計算，網絡和存儲的可用性。 但是應用程序本身呢？ 某些應用程序可以通過在同一應用程序的多個實例之間進行負載平衡來橫向擴展並提供冗餘。 想想典型的Web服務器場，您通常可以在其中平衡五台服務器之間的Web請求。 如果您丟失一台服務器，則負載平衡器僅將其從旋轉中刪除，直到再次響應為止。
其他應用程序則需要更多的維護和監視。 以SQL Server為例。 通常，“始終在線可用性組”或“故障轉移群集實例”用於監視數據庫可用性，並在數據庫由於應用程序或系統級故障而變得無響應時使用恢復操作。 儘管沒有針對SQL Server可用性解決方案的已發布SLA，但通常公認的是，如果將SQL Server正確配置為具有高可用性，則SQL Server可以提供99.99％的可用性。
您可能依賴於其他基於雲的服務，例如託管的Active Directory，託管的DNS，微服務，甚至雲門戶本身的可用性都應納入整體可用性方程中。
概要
應用程序可用性是所有活動部分的總和。 僅在一個區域中跳過會成倍地影響應用程序的整體可用性。 花點時間研究可用性鏈中的所有鏈接是否存在漏洞，包括計算，網絡，存儲，應用程序和相關服務。
總的來說，這裡列出的數字是最壞的情況，希望您的實際可用性超過已發布的SLA。 做好家庭作業，並提防任何不能保證99.99％可用性的服務，這是被認為具有高可用性的典型閾值。
本文未解決人為錯誤和安全問題。 您可以使您的應用程序盡可能地高可用性。 但是，如果您尚未採取措施保護應用程序免受外部威脅和愚蠢的人為錯誤，那麼在可用性方面，所有賭注都沒有了。
5， 定義警報條件
