在 Azure 中， 區域 資源是指固定在單一區域的資源。 因為區域資源只在單一可用區域內，所以它不具備區域韌性。 如果包含該資源的區域出現問題，該資源很可能會出現停機。
有些 Azure 服務需要或允許你部署區域資源。 你可能會因為延遲考量或特定服務需求而選擇區域部署資源。 你可以將個別資源或相關資源綁定在單一區域。
本文概述了你可能選擇部署區域資源而非區域冗餘資源的情境。 同時也強調了確保解決方案能抵禦分區停電所需的考量與責任。
資源部署類型
在 Azure 中，只有部分部署類型提供區域韌性。 下表比較三種資源部署類型，說明其區域韌性、區域分布、配置選項及建議。
| 資源部署類型 | 區域韌性支援 | 區域分布 | 如何設定 | Recommendation |
|---|---|---|---|---|
| Zone-redundant | 一律具有區域復原力 | 區域冗餘資源分布於多個區域，且對區域失效具有韌性。 若某區域發生故障，服務可在其他區域繼續運行。 | 部分區域冗餘資源提供跨可用區域的自動冗餘，而其他資源則需手動啟用區域冗餘。 請查閱你服務的 可靠性指引 ，了解服務需要什麼才能啟用韌性。 | 盡可能使用區域冗餘資源，尤其是在生產部署時。 |
| 區域性 | 不是自動的。 如果你願意，啟用區域韌性是你的責任。 區域資源被隔離，不受其他區域故障影響，但自身區域的故障可能導致停機。 |
你選擇資源的區域。 | 如果你有多個資源需 區域對齊（放置於同一區域），你必須為 每個 資源設定相同的區域。 | 只有在明確 需求時才使用區域資源。 為了讓你的解決方案具備區域韌性，設計並實施多區域解決方案是你的責任。 |
| 非區域（區域） | None | 如果該區域有支援可用性區域，Azure 可能會使用該區域內的任何區域。 | 非區域資源沒有區域配置。 | 由於非區域資源無法實現區域韌性，在有可用性區域的區域內，避免對所有生產工作負載進行非分區部署。 |
欲了解更多關於可用區域與資源部署的資訊，請參閱 可用性區域。
結合區域冗餘與區域資源的工作負載
許多工作負載結合了區域冗餘與區域資源。 舉例來說，你的工作負載可能包含一組用於資料庫層的區域虛擬機（VM）、一台由 Azure App Service 託管的區域冗餘網頁伺服器，以及一個區域冗餘負載平衡器用來將流量傳送到資料庫虛擬機。
當你在工作負載中結合區域與區域冗餘資源時，請考慮當某個可用區出現問題時，每個資源及整體解決方案的行為。 通常，區域冗餘服務會自動從區域中斷中恢復，且資料損失極少甚至無，且 Microsoft 負責管理整個流程。 對於區域資源，你負責配置自動故障轉移或進行手動恢復作業。 想了解各服務在區域關閉情境下的行為、了解你的責任與 Microsoft 責任的差異，以及監控區域限制事件中服務的健康狀況，請參閱你的服務可靠性指南。
何時使用區域部署
只有在明確需求時才使用區域資源。 單區部署的典型原因包括資源必須是區域性、服務僅在特定區域可用，或工作負載對區域間延遲高度敏感的情況。
這很重要
有些 Azure 服務允許你在區域部署和區域冗餘部署之間選擇。 如果你沒有強烈理由使用區域部署，就使用區域冗餘部署。
需要區域部署的資源
部分 Azure 服務只支援區域部署，且不提供區域冗餘部署。
虛擬機 是區域資源。 你可以使用虛擬機縮放集來建立虛擬機集合。 虛擬機規模集可以跨區域，也就是說，集合中的虛擬機分布在多個區域。 規模設定是一種為許多基於虛擬機的工作負載實現區域韌性的良好方法。
小提示
如果你部署多個執行類似功能的虛擬機，我們建議你使用跨區域擴展的擴展集，而非單實例虛擬機單獨部署。
另一個例子是 Azure NetApp Files，支援將磁碟區部署到單一區域。 這項服務也提供一種可以在多個區域區間複製的方式。
部分服務僅提供特定區域的選項。 例如，使用先進圖形處理器（GPU）的特定虛擬機類型，可能只在區域內的特定區域使用，這意味著它們無法跨多個區域部署。 若要檢查哪些區域和區域支援您需要的 VM 類型，請使用下列資源：
若要檢查每個區域中可用的 VM 類型，請參閱 依區域提供的產品。
若要檢查特定區域每個區域內支援的 VM 類型和大小，請參閱 檢查 VM SKU 可用性。
如果你需要的虛擬機類型只在你使用的區域內單一區域內可用，你可以考慮為該虛擬機做區域部署，然後再用其他方法讓虛擬機對區域中斷有彈性。 但你應該持續確保解決方案的其他部分具備區域韌性。
欲了解更多資訊，請參閱 支援可用性區域的 Azure 服務。
區域間延遲
如果你的工作負載對延遲特別敏感，你可能會使用區域資源而非區域冗餘資源，即使服務支援區域冗餘部署。
低延遲網路連接可用區域，區域間往返延遲通常低於兩毫秒。 對大多數工作負載來說，區域間延遲不是問題。 分散資源在可用區域間的韌性效益，比在區域間傳送流量帶來的最小效能影響更為重要。 但少數工作負載對區域間延遲非常敏感。 這些工作負載可能包括以下情境：
舊有的本地部署應用程式： 部分舊有工作負載可能包含原本為本地環境設計的應用程式。 這些工作負載假設元件，如資料庫及其他應用程式與服務，與主機共置或物理上距離相近。
非常大規模的同步複製： 有狀態應用程式與資料庫偶爾會透過 同步複寫執行大量寫入。 同步複製表示在寫入操作完成前，資料會寫入多個 副本 。 將副本分散在不同可用區域能提升韌性，但使用同步複製時，區域間延遲可能會增加工作負載的寫入延遲。 這種延遲增加通常不顯著，但由於某些應用的設計，在大規模時有時會造成問題。
這很重要
工作負載對區域間延遲敏感是不尋常的。 除非你針對你的工作負載和需求測試延遲，否則不要假設你的工作負載會受到影響。
如果你懷疑區域間延遲影響了你的工作負載，請在實際環境中測試其影響，並依照以下步驟針對你的特定工作負載進行：
定義可接受的性能要求。 區域間流量會增加一點延遲，但對大多數工作負載來說幾乎可以忽略不計。 定義你工作 負載下可 接受的效能是什麼樣子。
在單一可用區域內執行效能測試。 建立一套基線績效指標。
這很重要
測試你的工作負載，包括應用程式、協定、設定和 Azure 區域。 使用真實的載重。 基準和合成測試並不充分，因為它們無法反映你的解決方案的實際行為。
啟用區域間複製。 根據你使用的元件，你可能會啟用區域冗餘或在區域間移動副本。
重做效能測試。 收集你之前收集的相同的指標。
將效能影響與您的需求做比較。 利用您的需求與效能數據，對延遲與區域停電韌性之間的權衡做出明智決策。
如果測試顯示延遲對你的工作負載來說過高，請考慮採取以下措施：
請嘗試改用另一組區域。 不同區域間的延遲可能有些微差異，因為它們彼此之間的物理距離可能不同。
小提示
如果您跨 Azure 訂用帳戶進行測試時，請檢閱實體區域對應合乎邏輯，以確保您測試的是預期中的實體區域集。
如果有其他 Azure 區域符合你對資料駐留和其他因素的整體需求，試著在該區域使用多個區域。
考慮是否能重新設計應用程式，以減少所需的跨區通訊。 例如，你可能能將多個小型資料庫操作整合成單一操作。 這種方式可以降低對工作負載的延遲影響。
如果以上步驟都無效，可以考慮使用區域虛擬機及其他支援的 Azure 服務，在單一可用性區域內執行特定工作負載或元件。 接著你負責讓分區組件能夠抵抗分區停電。 請閱讀本文其餘部分，了解您的責任以及一些可考慮的做法。
你在區域部署時的責任
當區域資源的可用性區域發生停電時，就面臨停機風險。 當你部署區域資源時，你有責任讓你的工作負載能夠承受區域層級的故障。
這很重要
區域資源 本身並非 對區域失效具有韌性。 你必須設計方法，透過制定包含分區降級情境的計畫來降低分區失效的風險。
為使區域資源具備區域韌性，請考慮以下責任：
多資源的部署與配置： 手動將不同的區域資源部署到不同的區域或區域。 決定如何在每個資源間保持設定一致。 使用基礎設施即程式碼（IaC）是一種最佳實務，因為它能快速部署多個相同資源。
流量路由與分配： 你必須選擇負載平衡器元件，確保它具備區域韌性，並設定它能在不同區域的資源間傳送流量。 你通常會設定路由政策（例如主動-主動或主動-被動）、自動健康檢查和故障轉移程序。 如需詳細資訊，請參閱 負載平衡選項。
複製或資料備份： 對於有狀態的資源，你負責保護它們儲存的資料，並確保它們安全地分在多個區域保存。 常見做法是將複本設定到不同可用性區域中的另一個服務執行個體。 在某些情況下，你可能會依賴備份。 但備份在區域故障時需要較長的復原時間，這也需要更高的復原目標（RTO）。 同時也會導致更多資料遺失，這需要更高的復原點目標（RPO）。
區域失效偵測與應變流程實作： 你必須決定如何監控區域資源的健康狀況，定義標記為不健康的條件，並觸發回應行動，例如恢復其他區域或區域的運作。
區域復原流程： 區域恢復後，您需負責所有必要的復原動作，例如容錯回退到主要區域的資源。
區域部署韌性常見方法
為了明智地決定如何實現區域資源的區域韌性，請考慮以下因素：
檢視你所有的工作量。 了解各組成部分在區域降級事件中的行為，包括區域冗餘資源、區域性資源及非區域資源。 使用每個服務的可靠性指南，了解服務在分區降級情境下的運作方式，以及如何監控服務在分區降級事件中的健康狀況。
了解區域故障時允許的資料遺失範圍。 你的 RPO 會規定你能接受多少資料遺失。
許多 Azure 區域冗餘資源對區域故障的 RPO 為零，意即不會發生資料遺失。 他們通常透過同步複製跨區域的所有變更來達成此 RPO。
當你規劃區域部署時，必須確保當區域失效時，能符合工作負載的 RPO 要求。
了解區域失效期間允許的停機時間。 你的RTO會規定你能接受多少停機時間。
Azure 區域冗餘資源通常能在區域故障時提供非常低的復原時間目標（RTO），而且只需短短幾秒鐘的停機時間。
當你規劃區域部署時，必須確保能符合工作負載的 RTO 要求。 如果你的 RTO 很低，可能需要依賴自動偵測和恢復流程。 較高的RTO能讓你的回應流程更有彈性。
了解費用。 區域資源通常會單獨計費，因此部署多個區域資源可能會增加資源成本。
設計區域部署以提升韌性
在設計區域韌性部署時，請考慮你是使用可用性區域來達成 高可用性 還是 災難復原。 這些概念的區別是根據你的 RTO 和 RPO 要求而定。
如果你的 RTO 和 RPO 需求都很低，你需要把可用區當作 高可用性 的結構來處理。 但如果你的 RTO 和 RPO 較高，你可能會選擇將可用區視為 災難復原 的結構。 欲了解更多資訊，請參閱 業務持續性、高可用性與災難復原。 你的 工作量層級 可以幫助你判斷需求和必要的行動。
高可用性設計
考慮在多個區域部署你自己的高可用性架構。 高可用性架構需要在部署於多個區域的元件間自動且頻繁地複製資料，並在區域故障發生時自動切換。
有些部署在區域虛擬機上的應用程式會內建高可用性支援，例如具備副本感知能力。 例如，如果你在 Azure VM 上使用 SQL Server， 可用性群組 提供流量路由與故障轉移功能。 你可以選擇使用同步或非同步複製。 欲了解更多資訊，請參閱 Azure VM 上的業務持續性、高可用性與災難復原 SQL Server。
為災害復原而設計
災難復原與高可用性不同，因為在災難情境下，較大的停機時間和資料遺失是可以接受的。 RTO和RPO通常以小時或更長的時間計量。
災難復原計畫能幫助你為不同情境做好準備，並結合自動化與人工流程來定義如何應對。
以下災難復原方法能協助您規劃區域部署：
Azure Site Recovery 區域到區域的災難復原： 當需要在不同區域的虛擬機之間進行磁碟層級非同步複寫時，這種方法非常有用。 更多資訊請參閱 啟用 Azure VM 災難復原於可用性區域間。
區域間的場址復原災難復原： Site Recovery 支援區域間災難復原，並依賴非同步複製。 這種方式讓您可以容錯移轉到另一個 Azure 區域中的區域，而不是主要區域中的另一個區域。 欲了解更多資訊，請參閱 「將 Azure VMS 複製到另一個 Azure 區域」。
基於備份的災難復原： 如果你的解決方案能容忍高 RTO 和高 RPO，考慮將備份作為災難復原策略。 如果該區域發生故障，你可以將備份還原到另一個區域或區域。 你還需要考慮是預先建立解決方案中的其他 Azure 資源，還是在故障轉移過程中建立。
在區域架構中，你通常負責儲存和複製這些備份。
Azure Backup 是一個廣泛使用的管理備份服務。 它支援區域冗餘備份及跨成對 Azure 區域的地理複製備份。 有些應用程式，如 Azure VM 上的 SQL Server，也內建應用程式專用的備份功能。