本文提供將多層式基礎結構即服務 （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）， 而且是非同步，且可能會遺失資料。
您可以針對 DR 解決方案使用不同的 AZ 來利用 HA 和 DR 的 AZ。 不過，使用不同的 AZ 並不保證每個 AZ 中的資料中心會實際相距甚遠。
Azure Site Recovery 可讓您將 VM 複寫至另一個 Azure 區域，以進列區域災害復原和商務持續性。 您可以使用 Azure Site Recovery 在來源區域中斷時復原您的應用程式，或進行定期災害復原演練，以確保您符合合規性需求。
如果您的應用程式支援 Azure Site Recovery，您可以提供區域 DR 解決方案，以增加保護，如果應用程式的關鍵性需要它。 不過，單靠跨區域、跨資料中心 HA 可能是足夠的保護，因為如果應用程式完全具有資料中心失敗的復原能力，就不應該停機或資料遺失。
成本最佳化
在 AZ 中部署的 VM 不需額外費用。 可能會有額外的 AZ VM 對 VM 資料傳輸費用。 如需詳細資訊，請參閱 頻寬定價頁面 。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 肖恩·克勞徹 |資深顧問