2015 年 9 月

第 30 卷，第 9 期

本文章是由機器翻譯。

Microsoft Azure - 雲端中容錯暗藏的陷阱及其解決方法

由 Mario Szpuszta | 2015 年 9 月

有數個內建於 Microsoft Azure 以確保服務和應用程式仍可在失敗時的機制。這些失敗事件可以包含硬體故障，例如硬碟故障或相依的服務，例如儲存體或網路服務的暫時可用性問題。Azure 和其軟體控制基礎結構是以能夠預測並管理這類失敗的方式撰寫。

如果發生故障，Azure 基礎結構 (網狀架構控制器) 反應立即還原服務和基礎結構。例如，如果虛擬機器 (VM) 會因為實體主機上的硬體失敗而失敗，網狀架構控制器會移到另一個實體節點的 VM 依據相同的硬碟儲存在 Azure 儲存體中。Azure 是同樣能夠協調升級和更新的方式來避免服務中斷。

運算資源 (例如雲端服務、 傳統的 IaaS Vm VM 小數位數組)，最重要且基本概念啟用高可用性是容錯網域和升級網域。這些自創立以來 Azure 的一部分。這篇文章將提供這些概念周圍不那麼知名釐清。

Azure 資料中心架構

若要完全了解故障網域和升級網域，很有幫助視覺化的高層級檢視結構如何 Azure 資料中心。Azure 資料中心使用配量 10 Microsoft 內部所參考的架構。它支援更高的輸送量相較於先前的資料中心架構。其拓撲會實作具有高頻寬的彙總的後擋板提供每個 Azure 資料中心內的完整、 非封鎖、 網狀網路中所示 [圖 1。

[圖 1 高階 Azure 資料中心架構

節點會排列成機架。一群機架然後形成一個叢集。每個資料中心都有許多不同類型的叢集。有些則是負責計算、 SQL 等，某些叢集會負責儲存體。機櫃頂端 (TOR) 交換器是失敗的單一的整個機架點。

叢集的網狀架構控制器會管理所有機器或節點。網狀架構控制器會在叢集內的節點之間協調部署。每個群集都有一個以上的網狀架構控制器的容錯功能。網狀架構控制器必須知道在叢集中的每個節點的健全狀況。這有助於決定節點是否能執行部署它。它也有助於讓它可以藉由重新佈建受影響的 Vm 不同實體節點上自動復原部署偵測失敗的網狀架構控制器。

若要進一步協助網狀架構控制器判斷節點的健全狀況，執行叢集內每一部機器必須持續監視節點健全狀況及通訊網狀架構控制器相同回到不同代理程式。請務必了解如何不同元件一起運作來完成這項工作。中所示的重要元件 [圖 2, ，是:

• 主機作業系統: 在實體機器上執行的 OS。
• 主機代理程式: 執行的處理序在個別節點上提供該機器網狀架構控制器的通訊點。
• 客體作業系統： 在 VM 內執行的 OS。
• 客體代理程式: 位於 [VM 和主機代理程式來監控和維護 VM 的健康情況與通訊。

[圖 2 在 Microsoft Azure 叢集中的實體機器

容錯網域和升級網域

維護高可用性的任何平台做為-服務 (PaaS) 應用程式，每個 PaaS 應用程式的網狀架構控制器主機會分散到不同容錯網域和更新網域。

「 故障 」 網域是失敗的實體單位。在資料中心的實體基礎結構密切相關。Azure 中，每個伺服器機架的對應於 「 故障 」 網域。雖然 Azure 保證任何 PaaS 裝載應用程式 (具有一個以上的執行個體) 平台可以跨多個錯誤網域，哪些應用程式的執行個體分散於故障網域的總數取決網狀架構控制器根據在資料中心內的機器的可用性。

升級網域是可協助維護應用程式可用性當您將更新推送到系統的邏輯單元。對於 PaaS 應用程式，這是使用者可設定的設定。在 Azure 上的應用程式可以有其分散到最大值為 5 個升級網域的執行個體 (請參閱 [圖 3)。

[圖 3 容錯網域和升級網域組態

故障網域、 「 升級 」 網域，IaaS Vm

若要將基礎結構做為-服務 (IaaS) Vm 分散容錯網域和升級網域，Azure 會推出可用性設定組的概念。可用性設定組內的所有執行個體是分散到兩個或多個容錯網域和指派不同的升級網域值。

如果您不要將 Vm 指派給可用性設定組，就不適合使用這些 Vm 的服務等級協定 (Sla)。請務必了解這因為它會定義如何達成高可用性的服務和應用程式，即使失敗或升級推送到 Azure 資料中心。只要將您的 Vm 指派給可用性設定組，您可以避免受到這類失敗。

為了示範的重要性，假設有下列情況： Azure 產品小組會將作業系統更新所有資料中心之間推送上定期執行。若要將更新推送到整個資料中心、 主機作業系統 (實體機器) 和客體作業系統 (裝載的 PaaS 應用程式或 IaaS Vm 的 Vm) 必須更新以最新的作業系統。導入的更新而不會影響應用程式的可用性:

1. 主機作業系統更新會跨資料中心一容錯網域執行一次針對所有可用的錯誤網域。
2. 客體作業系統更新會在每個使用者應用程式一個升級網域上執行一次的所有可用的升級網域。

這些方法的主要 Azure 可以發送升級到它自己的基礎結構同時保有服務可用性 — 只要您執行每個服務或至少兩部 Vm 的至少兩個執行個體之可用性設定組 (例如負載平衡 Web 服務、 SQL Server AlwaysOn 可用性群組節點等等) 的一部分。

多少容錯網域?

容錯網域和升級網域會協助維護可用性談到 PaaS 類似工作負載，大部分都是無狀態。無狀態的 Web 應用程式相容這些方法。即使節點子集變得無法使用時升級循環或暫存的停機時間、 整體的 Web 應用程式或服務仍可使用。

說到基礎結構更可設定狀態的本質，例如資料庫伺服器的情況下取得棘手 (是它 RDBMS 或 NoSQL)。在這些情況下，了解您的伺服器分散到多個容錯網域可能不足夠。資料庫叢集可能需要最少的最長會在所有時間針對叢集健全狀況的節點。請考慮以仲裁為基礎的方法款新的主要節點發生失敗。

IaaS Vm 的 Azure 保證相同可用性設定組中的 Vm 將部署至少兩個故障網域 (因此兩個機架) 上。雖然某些兩個以上的故障網域間部署 Vm 的可用性設定組內的機率，並不保證。在過去幾年來實際測試、 專案一律使用兩個故障網域部署至北美或西歐，以及數個美國區域時 (如所示 [圖 4)。

[圖 4 範例 SQL AlwaysOn AG 叢集的容錯網域

[圖 4 顯示透過 Azure PowerShell，然後將結果顯示其 GridView 控制項發出的 Get-azurevm 命令的結果。它會顯示在叢集內的 Vm — 這都是屬於相同可用性設定組 (未顯示在方格中) — 部署跨兩個故障網域和三個 「 升級 」 網域。

該範例部署 sql1 及 sqlwitness 節點位於相同實體機架上。相同 TOR 連接到資料中心的其餘部分的機架。Sql2 節點位於不同機架上。

只有兩個故障網域嗎?

例如 Web 應用程式開發介面的無狀態應用程式或 Web 應用程式，只有兩個錯誤網域部署不應該會有問題，至少從一致性的觀點來看。可設定狀態的工作負載例如資料庫伺服器，則是另一回事至少從可用性的觀點。

根據叢集的運作方式，可能需要知道多少節點可以關機失敗的情況下才影響叢集健全狀況。如果叢集取決於仲裁投票或大部分為基礎的投票某些作業，例如款新的母片或確認讀取要求的一致性問題的多少節點可以關機壞的情況是更重要。

即使容錯網域會自動復原您的 Vm，多少節點可能會同時失敗的問題會相關。復原作業可能需要根據花費的時間來復原 VM 網狀架構控制器本身和 VM 上執行的資料庫系統時間。

當您了解 Azure automatism 中升級的內部行為整個主題就成為非常重要。在 IaaS Vm 的情況下所有升級至主機的 hypervisor 上執行每個實體節點上裝載您的 Vm 的作業系統架構上都發生故障網域 — 因為假設滿足廣大開發人員社群中未升級網域。升級網域僅適用於更新 PaaS Vm 內執行的應用程式。這表示您將會受到主機作業系統升級每季，這是典型的間隔。如果您的叢集部署跨兩個故障網域，但多數投票等等而定，您可能會有間歇性的停機時間。

一個常見的範例部署在 Azure 中設定 MongoDB 複本。每個 MongoDB 複本集需要一個 master。如果該主節點失敗，新的主要被選擇透過剩餘的節點。該選擇需要得票數款主要的多數。如果沒有足夠的節點到新的主要的一票，整個複本組宣告為狀況不良狀態與可視為 「 停擺 」。

MongoDB 文件 (bit.ly/1SxKrYI) 清楚地說明每個複本集大小容錯功能。只有一個節點可以在三個節點的複本集失敗。在一組五個節點、 兩個是往，整個叢集失敗的節點數目上限中所示 [圖 5。

[圖 5 MongoDB 複本集容錯功能

如果您需要一個複本集中執行的資料庫節點數目，即使 (例如複本組的兩個資料庫節點) MongoDB 導入仲裁的概念。仲裁者做為伺服器投票選舉、 但不會執行整個資料庫堆疊 (適用於儲存成本和資源)。因此如果您得到其中兩個資料庫節點 MongoDB 複本集足夠，您需要第三個節點 — 仲裁者 — 這是僅有提供其他的投票給多數架構在發生失敗時的主要選舉。

它是與 SQL Server AlwaysOn 可用性群組，大多數的節點才能選擇新的主要節點類似的狀況。僅投票成員的原則很類似。它只在 SQL Server 的世界中稱為見證 (而不是仲裁者，所謂於 mongodb 之中)。

考慮到 SQL Server 和部署回示 [圖 4, 、 它清楚狀態 sql1 和 sqlwitness 位於一個故障網域和 sql2 是在另一個。如果失敗的容錯網域"0"，master 和見證都向下 — 只 sql2 會保留。不過，單獨 sql2 是不足的大部分款新的主要叢集中。這表示如果故障網域"0"失敗，整個叢集狀況不良。

這種情況就是如果 sql1 及 sql2 全數相同容錯網域上。然後這兩個資料庫節點會向下直到網狀架構控制器從潛在失敗中復原節點或完成主機作業系統升級程序。

是 MongoDB 複本設定類似的情況。資料表中所示 [圖 5 從官方 MongoDB 文件清楚地說明在三個節點的複本集中，失敗只有一個節點可以維持作用中和可用的整個叢集。因此，它是關鍵節點如何分散給定的容錯網域數目。它會影響您在 Azure 主機作業系統升級和潛在的失敗。

可設定狀態的服務中的高可用性

有效問題是 Azure 大部分跨兩個故障網域部署 Vm 時，如何達成高可用性。有中間的詞彙和短期解答這個問題。

中間的詞彙 Azure 產品群組正致力於大幅改善這種情況。當您部署 (根據新的 Azure 資源管理員 API) 的第 2 版 IaaS Vm 時，Azure 可以跨三個故障網域至少部署您的工作負載。這是使用第 2 版的好理由 VM 和 Azure 資源管理員。

短期或只要你還是相依於傳統的 Azure 服務管理與第 1 版 IaaS Vm，並不簡單。根據您的 SLA、 復原時間目標 (RTO) 和復原點目標 (RPO) 目標您有兩個選項可以減少停機時間的風險。這兩種方法所示 [圖 6, ，而且根據 SQL Server AlwaysOn 可用性群組。

[圖 6 SQL Server AlwaysOn 可用性群組部署

目標永遠是以減少定期發生主機作業系統升級和最終失敗的影響。對於單一資料中心的三個節點叢集，部署 VM 可用性集之外的一個節點和兩個節點做為相同的 VM 可用性設定組的一部分。

這個方法會幾乎完全緩和主機作業系統升級的影響。可用性設定組內的 Vm 升級的時機是不同的單一 VM 主機作業系統升級。執行可用性設定組沒有單一 Vm 的主機作業系統通常會升級大約一週稍早比 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 AG 叢集跨越與進行中啟用跨這些區域的複寫。雖然跨區域複寫可能會因為延遲與效能問題而非同步複寫會發生在任何位置從毫秒為單位為分鐘，而不是兩分鐘或數小時。

相反地，VM 使用單一次要區域中執行只是見證或仲裁者是較多成本較低的替代方案。最好夠當您只需要保持您主要的叢集容錯網域失敗的情況下運作。它不會讓您選擇立即容錯移轉而不需要一些嚴重的額外步驟，例如才能組織好新的節點和次要區域中的 Vm 整個次要區域。

在範例中所示 [圖 6, ，您也可以執行完整的 SQL 節點做為唯一的節點次要區域中。單一 VM 的形式執行，因為它會有不同的升級循環。此外，它是在不同的資料中心執行，因為它正在升級的機率或在完全相同的時間做為主要的可用性設定組中的節點失敗很低。

總結

達成高可用性和容錯功能的應用程式和服務不是簡單的程序。它需要了解並調整基本概念。您必須了解故障網域、 升級網域和可用性設定組。您尤其必須了解基礎結構中移動至 Azure 時所使用的可設定狀態之系統的容錯功能需求。將這些容錯需求對應至行為的容錯網域和升級 Azure 中的網域。

全新的 IaaS 部署中，務必要運用 IaaS Vm v2 做為 Azure 資源管理員和資源群組工作的一部分。如此一來，您將可受益的部署至少三個故障網域上的容錯。如需使用傳統的服務管理的部署，請確定您了解並擁抱安這篇文章中所述。這些建議可以協助降低容錯網域的停機時間和維護事件，例如主機作業系統升級的影響。採行並調整此處所述的概念，您將能夠達到高可用性而不想要出現意外的狀況。

Mario Szpuszta 是 DX corp.的首席程式經理全域 ISV 小組。他負責與獨立軟體廠商若要啟用自己的解決方案和 Microsoft Azure 上的服務世界各地。您可以透過他透過他的部落格 (blog.mszcool.com)，在 Twitter 上 (twitter.com/mszcool) 或透過 marioszp@microsoft.com。

Srikumar Vaitinadin 是 DX Corp.軟體開發工程師全域 ISV 小組。之前他曾參與移轉至 Azure 的 Microsoft 屬性。您可以取得連絡透過 Srikumar srivaiti@microsoft.com。

衷心感謝以下技術專家對本文的審閱: Guadalupe Casuso 和 Jeremiah Talkar
Guada Casuso 是使用 Microsoft azure 的技術推廣者和雲端和跨平台行動開發的經驗。當她沒有運作時，她是 paddleboard 或飛行 drones 中。Guada 分享她在她的部落格的想法 atomosybitsenlanube.net 和在 Twitter 上 twitter.com/guadacasuso。