# Microsoft Azure - 云中的容錯問題和解決方法 通過?[Mario Szpuszta](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Mario+Szpuszta)?| 2015 年 9 月 有幾種內置到 Microsoft Azure 以確保服務和應用程序保持在發生故障時可用的機制。此類故障可包括硬件故障，如硬盤故障或依賴的服務，如存儲或網絡服務的臨時的可用性問題。Azure 和其軟件控制的基礎結構是以預測和管理此類故障的方式編寫的。 出現故障時，Azure 基礎結構 (Fabric Controller) 所作出的反應立即還原服務和基礎結構。例如，如果虛擬機 (VM) 由于在物理主機上的硬件故障而失敗，結構控制器移動到另一個物理節點的虛擬機基于同一個 Azure 存儲中的硬盤上。Azure 是同樣能夠協調升級和更新的方式避免服務中斷。 對于計算資源 （如云服務，傳統的 IaaS Vm VM 擴展集），用于啟用高可用性的最重要且基本概念是容錯域和升級域。這些是 Azure 的一部分從誕生之初。本文將提供圍繞這些概念不那么的已知澄清。 ## Azure 數據中心體系結構 若要完全了解故障域和升級域，它有助于直觀顯示的高級視圖的方式 Azure 數據中心內的結構。Azure 數據中心內使用 Microsoft 擔任量程 10 中引用的體系結構。它支持更高的吞吐量相比以前的數據中心體系結構。其拓撲實現為每個 Azure 數據中心，提供高帶寬聚合底板的完整的、 非阻塞、 網狀網絡中所示?圖 1。 ? 圖 1 高級 Azure 數據中心體系結構 節點排列到機架。機架的一組然后形成群集。每個數據中心都有大量的不同類型的群集。某些群集負責存儲而有些則負責計算、 SQL 等。頂部的架 (TOR) 交換機是故障的單一有關整個機架點。 群集的結構控制器管理的計算機或節點。結構控制器協調跨群集內的節點的部署。每個群集上有多個結構控制器以實現容錯功能。結構控制器必須注意的群集中的每個節點的運行狀況。這有助于確定節點是否可以運行部署它。它還有助于檢測故障以便它可以自動修復通過重新配置受影響的虛擬機位于不同物理節點上的部署結構控制器。 為了更好地幫助確定節點的運行狀況的 Fabric Controller，運行在群集內的每臺計算機具有不同的代理連續監視節點運行狀況和通信結構控制器到相同的背面。若要了解不同組件如何協同工作來做到這一點至關重要。一些重要組件，如中所示?圖 2, ，是： * 主機操作系統: 在物理計算機上運行的操作系統。 * 主機代理： 正在運行的進程在各個節點上提供從該計算機到結構控制器的通信點。 * 來賓操作系統： 在該 VM 中運行的操作系統。 * 來賓代理： 駐留在 VM 中，并且與主機代理以監視和維護虛擬機的運行狀況進行通信。 ? 圖 2 的 Microsoft Azure 群集物理機內部 ## 容錯域和升級域 對于維護任何平臺作為-服務 (PaaS) 應用程序的高可用性，每個 PaaS 應用程序結構控制器主機將是分散在不同的容錯域和更新域。 容錯域是失敗的物理單元。它與在數據中心中的物理基礎結構密切相關。對于 Azure 中，每個服務器機架上的對應到某個故障域。Azure 可保證任何 PaaS 應用程序 （具有多個實例) 平臺托管可跨多個故障域，而是由基于的數據中心內的計算機的可用性的結構控制器確定對其的應用程序實例分布在容錯域的總數。 升級域是一個邏輯單元，可幫助您將更新推送到系統時保持應用程序可用性。對于 PaaS 應用程序，這是用戶可配置的設置。在 Azure 上的應用程序可以有其分布在最多為五個升級域的實例 （請參閱?圖 3)。 ? 圖 3 容錯域和升級域配置 ## 故障域、 升級域和 IaaS 虛擬機 若要升級域分布在容錯域的基礎結構作為-服務 (IaaS) 虛擬機，Azure，引入了的可用性集的概念。在可用性集中的所有實例都分布在兩個或多個故障域和分配單獨的升級域值。 如果不將虛擬機分配到一個可用性集中，您不適合用于這些虛擬機的服務級別協議 (Sla)。請務必理解這一點因為它定義如何實現您的服務和應用程序的高可用性即使可能發生失敗或升級到 Azure 數據中心推出。僅通過將您的虛擬機分配給可用性集，您可以避免會受到此類故障。 為了演示這的重要性，考慮以下方案： Azure 產品團隊將在所有數據中心之間的操作系統更新推送定期進行。若要將更新推送到整個數據中心，主機操作系統 （物理機） 和來賓操作系統 (承載 PaaS 應用程序或您自己的 IaaS Vm 的 Vm) 必須更新為最新操作系統。若要前滾更新而不會影響應用程序的可用性： 1. 主機操作系統更新一次，所有可用的容錯域執行跨數據中心的一個故障域。 2. 來賓操作系統更新在每個用戶應用程序的一個升級域上執行一次，所有可用的升級域。 使用這些方法又稱為 Azure 可以推送升級到其自己的基礎結構同時保持服務可用性 — 只要您運行每個服務或在至少兩臺虛擬機的至少兩個實例的可用性集 （例如負載平衡 Web 服務、 SQL Server AlwaysOn 可用性組節點等) 的一部分。 ## 多少容錯域？ 容錯域和升級域幫助 PaaS 式工作負荷，很大程度上無狀態時保持可用性。無狀態的 Web 應用程序可以與這些方法兼容。即使在節點的子集在升級周期或臨時的停機時間的過程變得不可用，則整個 Web 應用程序或服務仍然可用。 這種情況獲取相對要復雜就更有狀態的性質，例如數據庫服務器的基礎結構 (是 RDBMS 或 NoSQL）。在這些情況下，了解您的服務器將分布在多個容錯域可能不是足夠。數據庫群集可能需要大量的節點會在所有時間的群集運行狀況的最小。請考慮基于仲裁的用來選擇新的主節點在發生故障的方法。 有關 IaaS Vm Azure 可保證同一可用性組中的 Vm 將部署在至少兩個故障域 （因此兩個機架)。雖然某些在可用性集中的虛擬機部署在兩個以上的容錯域的概率，就不能保證。在實際測試中在過去幾年，該項目時始終使用正好兩個故障域將部署到北美或歐洲西部，以及幾個美國區域 (如中所示?圖 4)。 ? 圖 4 為示例 SQL AlwaysOn 可用性組群集的的故障域 圖 4?顯示通過 Azure PowerShell，然后在其 GridView 控件中顯示結果發出的 Get AzureVM 命令的結果。它顯示在群集中的虛擬機 — 這都是相同的可用性集 (不顯示在網格中) 的一部分 — 跨兩個故障域和三個升級域部署。 該示例部署的 sql1 和 sqlwitness 節點駐留在同一物理機架上。同一 TOR 連接到數據中心的其余部分的機架。Sql2 節點位于不同機架。 ## 只有兩個故障域？ 對于無狀態應用程序 （如 Web Api 或 Web 應用程序，在只有兩個故障域部署不應是一個問題，至少從一致性角度來看。對于有狀態的工作負荷如數據庫服務器，它是另外一回事，至少從可用性角度來看。 具體取決于群集的工作原理，這可能是需要記住多少個節點向下發生故障時可以轉以免影響群集的運行狀況。如果群集取決于仲裁投票或基于大多數投票對于某些操作 （如選擇新的主控形狀或確認讀取請求的一致性在最糟糕的情形中的節點數會下降的問題是更重要的。 即使的容錯域自動恢復您的虛擬機，也是如此的多少個節點可能在同一時間失敗的問題是相關的。恢復操作可能需要具體取決于它所花費的時間結構控制器來恢復虛擬機本身及其在 VM 上運行的數據庫系統時間。 如果您了解升級 Azure automatism 的內部行為，整個主題變得更重要。在 IaaS Vm 的情況下為主機上運行每個物理節點上的虛擬機監控程序承載您的虛擬機的操作系統的所有升級都發生基于在容錯域上 — — 因為假定廣泛的開發人員社區中不升級域。升級域僅用于在 PaaS Vm 內部運行的應用程序更新。這意味著您將會受主機操作系統升級每個季度，這是典型的間隔。如果您的群集部署在兩個故障域，但取決于大多數投票并類似，則可能有間歇性的停機時間。 常見的例子將部署在 Azure 中設置 MongoDB 副本。每個 MongoDB 副本集要求恰好一個母版。如果該主節點出現故障，新的主密鑰者選擇通過剩余的節點。這些選擇需要的大部分投票要求選擇母版。如果沒有足夠的節點是最新的主節點投票，整個副本集中聲明的不正常狀態并可被視為"已關閉。" MongoDB 文檔 ([bit.ly/1SxKrYI](http://bit.ly/1SxKrYI)) 能夠清楚地表明每個副本集大小容錯。三個節點的副本集中的情況下只有一個節點可能會失敗。在一組五個節點，兩個是最大可能會失敗而不向下，整個群集的節點數中所示?圖 5。 圖 5 MongoDB 副本設置容錯功能 | 成員數 | 選擇新的主副本所需的大多數 | 容錯 | |---|---|---| | 3 | 2 | 1 | | 4 | 3 | 1 | | 5 | 3 | 2 | | 6 | 4 | 2 | 如果您需要運行在副本集中的數據庫節點數甚至 （例如，為副本集的兩個數據庫節點），MongoDB 引入了仲裁器的概念。仲裁器充當投票的選舉、 為服務器但不運行的整個數據庫堆棧 （節省成本和資源）。如果您最終創建與 MongoDB 副本集其中兩個數據庫節點已經足夠，因此您需要第三個節點 — 仲裁服務器 — — 這只是提供對大多數基于在發生故障的主選舉其他投票。 它是 SQL Server AlwaysOn 可用性組，其中大多數節點需選擇一個新的主節點與類似的情況。僅投票成員的原則是類似的。它只是在 SQL Server 的世界中稱為見證服務器 （而不是仲裁器，即所謂 MongoDB 中)。 SQL Server 和返回中所示的部署考慮?圖 4, 、 它清楚地狀態 sql1 和 sqlwitness 位于一個故障域和 sql2 是在另一臺。如果故障域"0"失敗，母版和見證服務器均向下 — 保留僅 sql2。但是，單獨的 sql2 是不足的大多數選擇群集中新的主密鑰。這意味著如果容錯域"0"失敗，您的整個群集都不正常。 這種情況將 sql1 和 sql2 得到在同一容錯域上的情況下更糟。則這兩個數據庫節點就是向下直到結構控制器從潛在的故障中恢復節點或完成主機操作系統升級過程。 這種情況是使用 MongoDB 副本集類似。表中所示?圖 5?從官方 MongoDB 文檔能夠清楚地表明在副本集中的三個節點時，失敗的只有一個節點可以為整個群集保持活動狀態并且可用。因此，它是關鍵如何將您的節點分布在給定數量的容錯域。它可能會影響在 Azure 主機操作系統升級和潛在的故障。 ## 有狀態的服務中的高可用性 一個有效的問題，然后，是如何實現高可用性時 Azure 主要將 Vm 部署在兩個故障域。有中間的術語和短期的解答這個問題。 中期 Azure 產品組工作來顯著改善這種情況。在部署時 （基于新的 Azure 資源管理器 API） 的版本 2 IaaS Vm，Azure 可以通過最少三個故障域部署您的工作負荷。這就是合理的理由使用第 2 版虛擬機和 Azure 資源管理器。 短期或只要您很快就會仍然依賴于傳統的 Azure 服務管理和版本 1 IaaS Vm，就不這么簡單。具體取決于您 SLA 恢復時間目標 (RTO) 和恢復點目標 (RPO) 目標具有降低停機時間的風險的兩個選項。這兩種方法所示?圖 6, ，并且基于 SQL Server AlwaysOn 可用性組。 ? 圖 6 SQL Server AlwaysOn 可用性組部署 目標是始終以減少定期發生主機操作系統升級和最終失敗的影響。對于在單個數據中心內的三個節點群集，將部署在虛擬機的可用性集之外的一個節點和兩個節點作為同一個虛擬機的可用性集的一部分。 使用該方法幾乎完全緩解主機操作系統升級的效果。虛擬機的可用性集內的升級的計時是不同的單一 VM 主機操作系統升級。正在運行的不可用性集的情況下的單個 Vm 的主機操作系統通常將升級大約一周早于那些使用虛擬機中的可用性集中。 在故障域故障的情況下只能減少受影響的概率。始終是可用性集克提克地區對其中一個可用性集內的虛擬機的故障域之外的節點的概率。很多取決于已使用并且在 Azure 數據中心中可用的資源。 有關 Active Directory 域中作為?圖 6, ，此類解決方案無需。存在無論如何都是僅對高可用性、 主要和備份域控制器。這就是完全分布在兩個故障域，這是 Azure 可保證有關版本 1 IaaS Vm 的兩個節點。 這樣仍然不會提供更好地正準備基礎的 SQL 節點這一難題?圖 6。可以通過不部署同一數據中心內的 sqlwitness 來降低該風險。這并不只是減少概率;它實質上是消除了風險。以解決方案還為單位表示?圖 6: 將您的部署分布到兩個區域。 ## 兩個選項 具體取決于您 SLA RPO 和 RTO 需要和你愿意為之付款的高可用性，再次您有兩個主要選項： 中的第二個區域或輔助區域中具有只需仲裁器/見證服務器的完全正常運行的備份部署。 完全正常運行的輔助部署是指將復制整個部署輔助區域中。也還可包括前端和中間層應用程序和服務。出現重大故障時的主要區域中，然后可以將客戶轉到輔助區域。 這種部署通常會為強 RPO/RTO 目標生成。對于如 MongoDB 或短 Rpo 和 rto 要求使用 SQL AlwaysOn 數據庫系統，這種需求通常會導致跨兩個區域跨越的副本集或 SQL 可用性組群集，與啟用跨這些區域的正在進行復制。盡管可能會因延遲和性能問題而異步跨區域復制，復制將發生這種情況中任意位置毫秒為單位為分鐘，而不是兩位數分鐘或幾小時。 另一方面，虛擬機在作為單個輔助區域中運行僅見證服務器或仲裁器是一個更廉價的替代品。它是很好足夠時您只需在故障域出現故障時保持您的主群集。它不會為您提供立即向整個輔助區域而無需一些嚴重的其他步驟，如啟動新的節點和輔助區域中的虛擬機故障轉移的選項。 在示例中所示?圖 6, ，您還可以運行完整的 SQL 節點作為唯一的節點的次要區域中。由于它作為一個單獨的 VM 中運行，它將具有不同的升級周期。此外，因為它運行在不同數據中心中，那么它正在升級的概率或在同一時間作為主可用性組中的節點的故障很小。 ## 總結 實現高可用性和容錯功能的應用程序和服務并不是一個簡單的過程。它要求您理解并對基本概念的調整。您需要了解的容錯域、 升級域和可用性集。尤其被需要了解在您的基礎結構中使用的遷移到 Azure 時的狀態系統的容錯功能要求。將這些容錯功能要求映射到行為的容錯域和升級在 Azure 中的域。 全新的 IaaS 部署來說，務必利用 IaaS Vm v2 作為 Azure 資源管理器和資源組工作的一部分。這樣一來，您將受益于在至少三個容錯域上所部署的容錯能力。對于使用傳統的服務管理的部署，請確保您了解并接受在本文中概述的現實。這些建議可以幫助減少故障域停機時間和維護事件如主機操作系統升級的影響。通過接受并調整到此處所述的概念，您將能夠實現高可用性而不需要的意外事件。 * * * Mario Szpuszta?*是 DX corp.的首席項目經理全局 ISV 團隊。他是在世界各地若要啟用其解決方案和 Microsoft Azure 上的服務與獨立軟件供應商。您可以通過他的博客與他聯系 ([blog.mszcool.com](http://blog.mszcool.com/))，在 Twitter 上 ([twitter.com/mszcool](http://twitter.com/mszcool)) 或通過?[marioszp@microsoft.com](mailto:marioszp@microsoft.com)。* Srikumar Vaitinadin?*是 DX corp.的軟件開發工程師全局 ISV 團隊。在此之前，他曾參與遷移到 Azure 的 Microsoft 屬性。您可以獲得與通過 Srikumar 聯系?[srivaiti@microsoft.com](mailto:srivaiti@microsoft.com)。*