本文提供將多層式基礎結構即服務 (IaaS) 應用程式部署至 Azure 時的高可用性 (HA) 和災害復原 (DR) 選項的判定樹和範例。
架構
工作流程
可用性設定組 (AS) 藉由將 VM 分散到多個隔離的硬體節點,在數據中心內提供 VM 備援和可用性。 VM 的子集會在計劃性或非計劃性停機期間持續執行,因此整個應用程式仍可供使用且可運作。
可用性區域 (AZ) 是跨越 Azure 區域內數據中心的唯一實體位置。 每個 AZ 都會存取一或多個具有獨立電源、冷卻和網路功能的數據中心,且每個已啟用 AZ 的 Azure 區域至少有三個不同的 AZ。 區域內 AZ 的實體區隔可保護已部署的 VM 免於資料中心失敗。
決策流程圖反映了HA應用程式應盡可能使用 AZ 的原則。 跨區域,因此跨數據中心,HA 提供 > 99.99% SLA,因為數據中心失敗的復原能力。
不同應用層的 AS 和 AZ 不保證位於相同的數據中心內。 如果應用程式延遲是主要考慮,您應該使用 具有 AZ 和 AS 的鄰近放置群組 (PPG) 在單一資料中心共置服務。
元件
替代項目
替代使用 Azure Site Recovery 的區域DR,如果應用程式可以原生複寫數據,您可以使用經常性/冷待命伺服器來實 作多區域DR ,例如僅限DR的延展式叢集。 此替代方法不會在範例中特別詳細說明,但可以新增至任何解決方案。 請注意,區域之間的復寫是異步的,而且預期會有某些數據遺失。
或者,如果您有自己的數據復寫技術,您可以使用它來建立DR的次要區域區域。 視工作負載的區域而定,也可以使用 Azure Site Recovery 將項目復寫至替代區域,您可以檢查區域可用性,並深入瞭解此功能,請參閱 為 Azure 虛擬機啟用區域至區域災害復原。
多區域HA是可能的,但需要全域負載平衡器,例如 Front Door 或 流量管理員。 如需詳細資訊,請參閱 在多個 Azure 區域中執行多層式應用程式,以取得高可用性。
案例詳細資料
多層式或 多層式 架構在傳統內部部署應用程式中很常見,因此它們是將內部部署應用程式移轉至雲端的自然選擇,或在開發內部部署和雲端的應用程式時。 多層式架構通常會實作為 IaaS 應用程式,分成邏輯層和實體層,具有頂端 Web 或表示層、中介商務層和數據層。
在 IaaS 多層式應用程式中,每一層會在一組個別的 VM 上執行。 Web 和商務層是無狀態的,這表示該層中的任何 VM 都可以處理該層的任何要求。 數據層是復寫的資料庫、物件記憶體或檔案記憶體。 如果一個 VM 失敗,每一層中的多個 VM 都會提供復原能力,而負載平衡器會將要求分散到 VM。
您可以將更多 VM 新增至集區,並使用 虛擬機擴展集 自動相應放大相同的 VM,來相應放大階層。 因為您使用負載平衡器,因此您可以相應放大層,而不會影響應用程式運行時間。
如果 IaaS 應用程式的服務等級協定 (SLA) 需要 > 99% 的可用性,您可以將 VM 放在可用性設定組、可用性區域和鄰近放置群組中,以設定應用程式的高可用性。 您選擇的 HA 和 DR 解決方案取決於所需的 SLA、延遲考慮,以及區域 DR 需求。
潛在使用案例
- 將多層式應用程式從內部部署移轉至雲端。
- 在內部部署和雲端部署多層式應用程式。
- 設定 IaaS 應用程式的高可用性和災害復原。
此解決方案可用於任何產業,包括下列案例:
- 公共部門應用程式
- 銀行業(金融業)
- 醫療保健
考量
所有 Azure 區域都無法使用 AZ。
決定您要在建置解決方案之前使用的部署選項。 雖然可行,但不容易從一個選項移至另一個部署后。 您必須刪除 VM,並從基礎受控磁碟重新建立它們,這是相關的程式。
請確定您可以對應應用程式與選取的解決方案。 許多應用層復原模式和設計都超出此判定樹的範圍。
三種案例可能會導致 Azure VM 重新啟動:非計劃性硬體維護、非預期的停機時間和計劃性維護。 如需這些事件和 HA 最佳做法以降低其影響的詳細資訊,請參閱 瞭解 VM 重新啟動、維護與停機時間。
單一 VM
如果應用程式不需要 > 99.9% 的可用性,您就不需要針對 HA 進行設定,而且可以部署單一 VM。 您可以使用虛擬機擴展集自動相應放大相同的 VM。 部署單一 VM 而不指定區域,因此會分散到整個區域。 如果您使用 Azure 進階版 SSD 磁碟,這些應用程式 SLA 的 SLA 為 99.9%。
單一 VM 會使用所有 Azure 資料中心內建的預設服務修復功能。 針對可預測的失敗,這項功能通常會使用即時移轉,但在無法預測的事件期間,VM 可能會重新啟動或無法使用。
高可用性
如果應用程式需要 99.9% 的 SLA > ,請設計 HA 的應用程式。 可能的話,請使用 AZ,因為它們提供資料中心容錯。 您可以使用 AS 而非 AZ,但使用 AS 可將可用性從 99.99% 減少到 99.95%,因為 AS 無法容忍數據中心失敗。
AZ 適用於許多叢集應用程式案例,包括 AlwaysOn SQL 叢集、使用主動-主動、主動-被動,或在每一層使用快速故障轉移的 HA 層級組合。 由於跨區域網路的低延遲,任何資料庫管理系統 (DBMS) 節點之間都可能會進行同步複寫。 您也可以跨區域執行 延展式叢集 組態,其延遲較高,並支援異步複寫。
如果您想要使用以 VM 為基礎的叢集仲裁器,例如檔案共享見證,請將它放在第三個 AZ 中,以確保如果有任何區域失敗,仲裁不會遺失。 或者,您也可以在另一個區域中使用雲端式見證。
AZ 中的所有 VM 都位於單 一容錯網域 (FD) 和 更新網域 (UD),這表示它們共用通用的電源和網路交換器,而且可以同時重新啟動。 如果您跨不同的 AZ 建立 VM,您的 VM 會有效地分散到不同的 FD 和 UD,因此它們不會全部失敗或同時重新啟動。 如果您想要有備援區域 VM 以及跨區域 VM,您應該將區域 VM 放在 PPG 中的 AS 中,以確保不會一次重新啟動它們。 即使是目前沒有備援的單一實例 VM 工作負載,您仍然可以選擇性地使用 PPG 中的 AS 來允許未來的成長和彈性。
若要跨 AZ 部署虛擬機擴展集,請考慮使用 目前處於公開預覽狀態的協調流程模式,以允許合併 FD 和 AZ。
具有區域 PPG 的 AZ 允許 Azure 中最低的網路等待時間之一,而且因為多重數據中心復原能力,SLA 至少為 99.99%。 盡可能在 VM 上使用加速網路。
此解決方案可能會顯示某個區域中 VM 上執行的服務需要與另一個區域中的服務互動的案例。 例如,區域之間可能有主動-主動-主動 Web 層和主動-被動資料庫層。 某些要求會跨區域,這會導致延遲。 雖然跨區域延遲仍然非常低,但如果您需要確保盡可能低的延遲,請保留區域內應用層之間的所有網路通訊。
延遲考慮
網路等待時間取決於所部署 VM 之間的實體距離。 如果應用程式在各層之間需要非常低的延遲,您可以在單一數據中心內部署應用程式,並針對每一層使用具有 AS 的 PPG。 可能的話,請在 VM 上使用加速網路。 此案例允許 Azure 中最低的網路等待時間之一,SLA 為 99.95%。
您可以使用下列工具來深入瞭解各種案例的延遲條件:
- 若要測試 VM 之間的延遲,請參閱 測試 VM 網路等待時間。
- 若要測試區域之間的延遲,請使用 AvZone-Latency-Test。 此測試可協助您判斷哪些邏輯區域具有訂用帳戶的最低延遲。
- 若要測試 Azure 區域之間的延遲,請使用 http://www.azurespeed.com/。 此定期更新的工具在考慮區域之間的異步複寫時很有用。
災害復原
DR 考慮包括 可用性、應用程式以狀況良好狀態持續執行的能力,以及 數據持久性,以及在發生災害時保留數據的能力。
HA 故障轉移應該很快,且不會遺失數據,而且對服務的影響非常有限。 相反地,傳統DR故障轉移可能會有較長的相關聯 復原時間目標 (RTO) 和 恢復點目標 (RPO),而且是異步的,且可能會遺失數據。
您可以針對災害復原解決方案使用不同的可用性區域,利用高可用性和災害復原的可用性區域。 可用性區域已足夠接近,無法與其他可用性區域建立低延遲連線(往返延遲小於 2 毫秒)。 不過,它們相距甚遠,可降低本機中斷或天氣可能會影響多個可用性區域的可能性。 對於任務關鍵性工作負載,除了多個可用性區域之外,您也應該考慮使用多個區域的解決方案。
Azure Site Recovery 可讓您將 VM 複寫至另一個 Azure 區域,以進行區域災害復原和商務持續性。 您可以使用 Azure Site Recovery 在來源區域中斷時復原您的應用程式,或進行定期災害復原演練,以確保您符合合規性需求。
如果您的應用程式支援 Azure Site Recovery,您可以提供區域 DR 解決方案,以增加保護,如果應用程式的關鍵性需要它。 不過,單靠跨區域、跨數據中心 HA 可能是足夠的保護,因為如果應用程式完全具有數據中心失敗的復原能力,就不應該停機或數據遺失。
成本最佳化
在 AZ 中部署的 VM 不需額外費用。 可能會有額外的 AZ VM 對 VM 資料傳輸費用。 如需詳細資訊,請參閱 頻寬定價頁面。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者:
- 肖恩·克勞徹 |資深顧問