使用可用性區域和區域的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| RE：05 | 在不同的層級新增備援，特別是針對重要流程。 根據識別的可靠性目標，將備援套用至計算、數據、網路和其他基礎結構層。 |
|---|
相關指南：高可用性多區域設計 | 備援
本指南說明決定何時在可用性區域或區域之間部署工作負載的建議。
當您為 Azure 設計解決方案時，您必須決定是否要跨區域中的多個可用性區域部署，或部署到多個區域。 此決策會影響解決方案的可靠性、成本和效能，以及小組操作解決方案的能力。 本指南提供影響您決策的主要商務需求、您可以考慮的方法、每個方法所涉及的取捨，以及每個方法對 Azure 良好架構架構核心要素的影響的相關信息。
決定最適合您解決方案使用的 Azure 區域是一個重要選擇。 選取 Azure 區域指南 說明如何在多個地理區域中選取及操作。 您選擇如何在解決方案中使用區域和可用性區域，也會影響妥善架構架構的數個要素：
- 可靠性：您選擇的部署方法可協助您降低各種類型的風險。 一般而言，藉由將工作負載分散到更地理位置的區域，您可以達到更高的復原能力。
- 成本優化：某些架構方法需要部署比其他資源更多的資源，這會增加您的資源成本。 其他方法牽涉到將數據傳送到異地分隔的可用性區域或區域，這可能會產生網路流量費用。 也請務必考慮管理資源的持續成本，當您有完整的商務需求時，通常會較高。
- 效能效率：可用性區域會透過高頻寬、低延遲的網路連結連線在一起，這足以讓大多數工作負載跨區域啟用同步復寫和通訊。 不過，如果您的工作負載已經過測試，而且對跨區域的網路等待時間很敏感，您可能需要考慮實際尋找工作負載的元件，以在通訊時將延遲降到最低。
- 卓越營運：複雜的架構會花費更多精力來部署、設定和管理。 此外，針對高可用性解決方案，您可能需要規劃如何故障轉移至次要資源集。 故障轉移、容錯回復和透明地重新導向流量可能很複雜，尤其是在需要手動步驟時。 將部署和管理程序自動化是很好的作法。 如需詳細資訊，請參閱營運卓越支柱指南，包括 OE：05 基礎結構即程式代碼、OE：09 工作自動化、OE：10 自動化設計和 OE：11 部署做法。
不過，您設計解決方案時，就會套用安全性要素。 通常，關於您是否使用可用性區域和區域的決定不會變更您的安全性狀態。 Azure 會將相同的安全性嚴謹性套用至每個區域和可用性區域。
提示
對於許多生產工作負載， 區域備援部署 提供取捨的最佳平衡。 您可以使用異步數據備份將此方法 延伸至另一個區域。 如果您不確定要選取哪種方法，請從這種類型的部署開始。
當您需要這些方法提供的特定優點，但請注意所涉及的取捨時，請考慮其他工作負載方法。
定義
| 詞彙 | 定義 |
|---|---|
| 主動-主動 | 一種架構，其中解決方案的多個執行個體會同時主動處理要求。 |
| 主動-被動 | 一種架構，其中會將解決方案的一個執行個體指定為主要執行個體並負責處理流量，而在主要執行個體無法使用時，則會部署一或多個次要執行個體來提供流量。 |
| 非同步複寫 | 一種資料複寫方法，其中資料會寫入並認可至一個位置。 稍後，變更會複寫至另一個位置。 |
| 可用性區域 | 區域內數據中心的分隔群組。 每個可用性區域都與其他區域無關，具有自己的電源、冷卻和網路基礎結構。 許多區域都支援可用性區域。 |
| 資料中心 | 包含伺服器、網路設備和其他硬體以支援 Azure 資源和工作負載的設施。 |
| 本機備援部署 | 一種部署模型，其中資源會部署至單一區域，而不參考可用性區域。 在支援可用性區域的區域中，資源可能會部署在該區域的任何可用性區域中。 |
| 多區域部署 | 一種部署模型，其中資源會部署至多個 Azure 區域。 |
| 配對的區域 | 兩個 Azure 區域之間的關聯性。 某些 Azure 區域 會連線至另一個已定義的區域，以啟用特定類型的多區域解決方案。 較新的 Azure 區域不會配對。 |
| 區域 | 包含一組資料中心的地理周邊。 |
| 區域架構 | Azure 區域的特定設定，包括可用性區域的數目，以及區域是否與另一個區域配對。 |
| 同步複寫 | 一種資料複寫方法，其中資料會寫入並認可至多個位置。 每個位置都必須確認寫入作業完成，才能將整體寫入作業視為完成。 |
| 區域性 (釘選) 部署 | 一種部署模型，其中資源會部署至特定可用性區域。 |
| 區域備援部署 | 一種部署模型，其中資源會跨多個可用性區域部署。 如果區域發生中斷，Microsoft 會管理資料同步處理、流量分佈和容錯移轉。 |
關鍵設計策略
Azure 具有龐大的全球使用量。 Azure 區域 是包含一組數據中心的地理周邊。 您必須完全瞭解 Azure 區域和可用性區域。
Azure 區域有各種不同的設定，也稱為 區域架構。
許多 Azure 區域都提供 可用性區域，這些區域是個別的數據中心群組。 在區域內，可用性區域之間足夠接近，能夠與其他可用性區域建立低延遲連線，卻也足夠遙遠，能夠減少多個可用性區域受到本機中斷或天氣影響的可能性。 可用性區域擁有獨立的電源、冷卻和網路基礎結構。 可用性區域的設計目的在於，當一個區域發生中斷時，可由其餘區域提供支援，包括區域服務、容量和高可用性需求。
下圖會顯示數個範例 Azure 區域。 區域 1 和 2 支援可用性區域。
如果您部署到 包含可用性區域的 Azure 區域，則可以同時使用多個可用性區域。 藉由使用多個可用性區域，您可以將應用程式和資料的個別副本保存在大型大都市區域中個別的實體資料中心內。
有兩種方式可以在解決方案中使用可用性區域：
- 區域性資源會固定在特定的可用性區域內。 您可以合併使用不同區域的多個區域性部署，以滿足高可靠性需求。 您必須負責管理資料複寫，並將要求分散至不同的區域。 若單一可用性區域發生中斷，您必須負責容錯移轉至另一個可用性區域。
- 區域備援資源分散在多個可用性區域中。 Microsoft 會負責管理跨區域的要求分散以及資料複寫。 單一可用性區域發生中斷時，Microsoft 會自動管理容錯移轉。
Azure 服務支援上述其中一種或兩種方法。 平台即服務 (PaaS) 服務通常支援區域備援部署。 基礎結構即服務 (IaaS) 服務通常支援區域性部署。 如需 Azure 服務如何與可用性區域搭配運作的詳細資訊，請參閱 具有可用性區域支援的 Azure 服務。
當Microsoft將更新部署至服務時，我們會嘗試使用最不具干擾性的方法。 例如，我們的目標是一次將更新部署到單一可用性區域。 這種方法可以降低更新對作用中工作負載的影響，因為工作負載可以在進行更新時繼續在其他區域中執行。 不過，工作負載小組最終有責任確保工作負載在平臺升級期間繼續運作。 例如，當您搭配彈性協調流程模式或大部分的 Azure PaaS 服務使用虛擬機擴展集時，Azure 會以智慧方式放置您的資源，以減少平臺更新的影響。 此外，您可能會考慮 過度布 建 - 部署更多資源實例 - 讓某些實例在升級其他實例時維持可用狀態。 如需 Azure 部署更新方式的詳細資訊，請參閱 進階安全部署做法。
許多區域也有 配對的區域。 配對的區域支援特定類型的多區域部署方法。 某些較新的區域有多個可用性區域，而且沒有配對的區域。 您仍然可以將多區域解決方案部署到這些區域，但您所使用的方法可能不同。
如需 Azure 如何使用區域和可用性區域的詳細資訊，請參閱 什麼是 Azure 區域和可用性區域？
瞭解共同責任
共同責任原則描述雲端提供者（Microsoft）與您之間的責任劃分方式。 視您使用的服務類型而定，您可能會或多或少地承擔營運該服務的責任。
Microsoft 會提供可用性區域和區域 ，讓您有彈性地設計解決方案以符合您的需求。 當您使用受控服務時，Microsoft 會承擔更多資源的管理責任，這甚至可能包括與操作散發式系統相關的資料復寫、容錯移轉、容錯回復和其他工作。
您自己的程式代碼需要 適當地處理失敗的建議做法和設計模式。 這些做法在故障轉移作業期間更為重要，例如可用性區域或區域故障轉移發生時發生的做法，因為區域或區域之間的故障轉移通常需要您的應用程式重試服務連線。
識別主要商務和工作負載需求
若要決定如何在解決方案中使用可用性區域和區域，您必須瞭解需求。 這些需求應由解決方案設計工具與商務項目關係人之間的討論所驅動。
風險承受能力
不同的組織有不同的風險承受能力。 即使在組織內，每個工作負載的風險承受能力通常都不同。 大部分的工作負載都不需要極高的可用性。 不過，某些工作負載非常重要，甚至值得減輕不太可能發生的風險，例如影響整個地理區域的重大自然災害。
下表列出您應該在雲端環境中考慮的一些常見風險：
| 風險 | 範例 | 可能性 |
|---|---|---|
| 硬體中斷 | 硬碟或網路設備的問題。 主機重新啟動。 |
高。 任何復原策略都應該考慮這些風險。 |
| 數據中心中斷 | 整個數據中心的電源、冷卻或網路失敗。 大都市區一部分的自然災害。 |
中 |
| 區域中斷 | 影響廣大地理區域的重大自然災害。 讓一或多個 Azure 服務無法在整個區域中使用的網路或服務問題。 |
低 |
最好是減輕每個工作負載可能的風險，但這樣做並不實用或符合成本效益。 請務必與商務項目關係人進行開放式討論，以便您做出明智的決策，以瞭解您應該減輕的風險。
提示
無論可靠性目標為何，所有工作負載都必須有一些災害復原風險降低。 如果您的工作負載需要高度可靠性的目標，則風險降低策略應該全面，而且您應該降低甚至低可能性事件的風險。 對於其他工作負載，請針對您準備接受哪些風險，以及需要減輕的風險做出明智的決定。
復原需求
請務必瞭解工作負載的復原需求，包括復原時間目標 （RTO） 和恢復點目標 （RPO）。 這些目標可協助您決定要排除的方法。如果您沒有明確的需求，則無法做出有關要遵循之方法的明智決策。 如需詳細資訊，請參閱 目標功能和非功能需求。
服務等級目標
您應該瞭解解決方案的預期運行時間服務等級目標 （SLO）。 例如，您的解決方案可能需要符合 99.9% 執行時間的商務需求。
Azure 會為每個服務提供服務等級協定（SLA）。 SLA 表示您應該預期來自服務的運行時間層級，以及達到預期 SLA 所需的條件。 不過，請記住，Azure SLA 指出服務可用性的方式不一定符合您考慮工作負載健康情況的方式。
您的架構決策會影響解決方案的 複合 SLO。 一般而言，您在解決方案中建置的備援越多，SLO 可能就越高。 當您在區域備援或多重區域組態中部署服務時，許多 Azure 服務會提供較高的 SLA。 檢閱您使用的每個 Azure 服務的 SLA，以確保您瞭解如何將服務的復原能力和 SLA 最大化。
資料落地
某些組織會限制可以儲存及處理其數據的實體位置。 有時候，這些需求是以法律或法規標準為基礎。 在其他情況下，組織可能會決定採用數據落地原則，以避免客戶擔心。 如果您有嚴格的數據落地需求，您可能需要使用單一區域部署或使用 Azure 區域和服務子集。
注意
請避免對您的數據落地需求進行毫無根據的假設。 如果您需要遵守特定的法規標準，請確認這些標準實際指定的內容。
使用者位置
藉由了解使用者所在的位置，您可以做出明智的決策，瞭解如何針對您的需求優化延遲和可靠性。 Azure 提供許多選項來支援地理位置分散的使用者群。
如果您的使用者集中在一個區域中，單一區域部署可以簡化您的作業需求，並降低成本。 不過，您必須考慮單一區域部署是否符合可靠性需求。 針對任務關鍵性應用程式，即使您的使用者共置，您仍應該使用多區域部署。
如果您的使用者分散在地理位置上，則跨多個區域部署工作負載可能很合理。 Azure 服務提供不同的功能來支援多區域部署，而且您可以使用 Azure 的全球使用量來改善用戶體驗，並讓您的應用程式更接近您的使用者群。 您可以使用部署戳記模式或地理位置模式，或跨多個區域復寫您的資源。
即使您的用戶位於不同的地理區域，也請考慮您是否需要多區域部署。 請考慮您是否可以使用全域流量加速，如 Azure Front Door 所提供的加速，在單一區域內達成您的需求。
預算
如果您以限制的預算運作，請務必考慮部署備援工作負載元件所涉及的成本。 這些成本可能包括額外的資源費用、網路成本，以及管理更多資源和更複雜的環境的營運成本。
簡化
最好避免解決方案架構中不必要的複雜度。 您介紹的複雜度越複雜，您就越難做出關於架構的決策。 複雜的架構較難運作、較難保護，且效能較低。 遵循簡單的原則。
Azure 便利化
藉由提供區域和可用性區域，Azure 可讓您選取符合需求的部署方法。 有許多方法可供您選擇，每個方法都提供優點併產生成本。
若要說明您可以使用的部署方法，請考慮範例案例。 假設您正在考慮部署新的解決方案，其中包含將數據寫入某種記憶體的應用程式：
此範例並非任何特定的 Azure 服務專屬。 其旨在提供說明基本概念的簡單範例。
有多種方式可以部署此解決方案。 每個方法都會提供一組不同的優點，併產生不同的成本。 概括而言，您可以考慮本機 備援、 區域（已釘選）、 區域備援或 多區域 部署。 下表摘要說明一些要素考慮：
| 要素 | 本地備援 | 分區 （釘選） | 區域備援 | 多區域 |
|---|---|---|---|---|
| 可靠性 | 可靠性低 | 取決於方法 | 高或非常高的可靠性 | 高或非常高的可靠性 |
| 成本最佳化 | 低成本 | 取決於方法 | 中等成本 | 高成本 |
| 效能效率 | 可接受的效能（適用於大部分的工作負載） | 高效能 | 可接受的效能（適用於大部分的工作負載） | 取決於方法 |
| 卓越營運 | 操作需求低 | 高作業需求 | 操作需求低 | 高作業需求 |
下表摘要說明您可以使用的一些方法，以及它們如何影響您的架構：
| 架構考慮 | 本地備援 | 分區 （釘選） | 區域備援 | 多區域 |
|---|---|---|---|---|
| 符合數據落地 | 高 | 高 | 高 | 相依於區域 |
| 區域可用性 | 所有地區 | 具有可用性區域的區域 | 具有可用性區域的區域 | 相依於區域 |
本文的其餘部分說明上表所列的每個方法。 方法清單並不詳盡。 您可能會決定合併多個方法，或在解決方案的不同部分使用不同的方法。
部署方法 1：本地備援部署
如果您在部署資源時未指定多個可用性區域或區域，Azure 不會保證資源是否部署至單一數據中心，或分割於區域中的多個數據中心。 在某些情況下，Azure 也可能在可用性區域之間移動您的資源。
根據預設，大部分的 Azure 資源都是高可用性，而且平臺所管理的數據中心內具有高 SLA 和內建備援。 不過，從可靠性的觀點來看，如果區域的任何部分發生中斷，您的工作負載可能會受到影響。 如果是，您的解決方案可能無法使用，或您的數據可能遺失。
對於高度延遲敏感的工作負載，這種方法也可能會導致效能降低。 您的工作負載元件可能不會共置在相同的數據中心，因此您可能會觀察到區域內流量的一些延遲。 Azure 也可能以透明方式在可用性區域之間移動您的服務實例，這可能會稍微影響效能。 不過，這與大部分工作負載無關。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 可靠性低。 如果數據中心失敗，服務可能會中斷。 不過，您可以建置應用程式以復原其他類型的失敗。 |
| 成本最佳化 | 成本最低。 您只需要擁有每個資源的單一實例，而且不會產生任何區域間頻寬成本。 |
| 效能效率 | 對於大部分的工作負載：可接受的效能。這種方法可能會提供令人滿意的效能。 對於高度延遲敏感的工作負載：低效能。元件不保證位於相同的可用性區域，因此您可能會看到高延遲敏感元件的效能較低。 |
| 卓越營運 | 高效作業效率。 您只需要部署和管理每個資源的單一實例。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 高。 當您部署使用此方法的解決方案時，數據會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 高。 此方法可用於任何 Azure 區域。 |
跨區域備份的本地備援部署
您可以將基礎結構和數據定期備份至次要區域，以擴充本地備援部署。 這種方法增加了額外的保護層，以減輕主要區域中的中斷。 其看起來會像下面這樣：
當您實作此方法時，您必須仔細考慮 RTO 和 RPO：
- 復原時間：如果發生區域性中斷，您可能需要在另一個 Azure 區域中重建解決方案，這會影響復原時間。 請考慮使用基礎結構即程序代碼 （IaC） 方法來建置解決方案，以便在發生重大災害時快速重新部署到另一個區域。 請確定您的部署工具和程式與應用程式一樣具有復原性，因此即使發生中斷，您仍可使用它們來重新部署解決方案。 規劃並排練將解決方案還原回工作狀態所需的步驟。
- 恢復點：您的備份頻率會決定您可能會遇到的數據遺失量（恢復點）。 您通常可以控制備份的頻率，以便符合 RPO。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 適度的可靠性。 如果數據中心失敗，服務可能會中斷。 數據會以異步方式備份至異地分隔的區域，藉由將數據遺失降至最低，以減少完整區域中斷的影響。 在完整的區域中斷中，您可以手動將作業還原到另一個區域。 不過，復原程式可能很複雜，而且可能需要一段時間才能手動還原至其他區域。 |
| 成本最佳化 | 低成本。 一般而言，將備份新增至另一個區域的成本只會略高於部署本地備援資源。 |
| 效能效率 | 對於大部分的工作負載：可接受的效能。這種方法可能會提供令人滿意的效能。 對於高度延遲敏感的工作負載：低效能。元件不保證位於相同的可用性區域，因此您可能會看到高延遲敏感元件的效能較低。 |
| 卓越營運 | 在區域內的任何中斷期間：低營運效率。故障轉移是您的責任，可能需要手動作業和重新部署。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 取決於區域選取專案。 數據主要儲存在您指定的 Azure 區域中。 不過，您必須選取另一個區域來儲存備份，因此請務必選取與數據落地需求相容的區域。 |
| 區域可用性 | 高。 您可以在任何 Azure 區域中使用此方法。 |
部署方法 2：區域性 （已釘選） 部署
在 區域性 部署中，您可以指定資源應該部署到特定可用性區域。 這種方法有時稱為 區域固定部署 。
區域性方法可減少元件之間的延遲。 不過，它本身並不會增加解決方案的復原能力。 若要增加復原能力，您必須將元件的多個實例部署到多個可用性區域，並決定如何路由傳送每個實例之間的流量。 此範例顯示 主動-被動 流量路由方法：
在上述範例中，負載平衡器會部署到多個可用性區域。 請務必考慮如何在不同可用性區域中的實例之間路由傳送流量，因為區域中斷也可能會影響部署到該區域的網路資源。 您也可以考慮使用全域負載平衡器，例如 Azure Front Door 或 Azure 流量管理員，這完全不會部署到區域。
當您使用區域性部署模型時，您會承擔許多責任：
- 您必須將資源部署到每個可用性區域，並個別設定和管理這些資源。
- 您必須決定在可用性區域之間復寫數據的方式和時機，然後設定和管理複寫。
- 您負責使用負載平衡器，將要求分散到正確的資源。 您必須確保負載平衡器符合復原需求。 您也需要決定是否要使用主動-被動或主動-主動要求散發模型。
- 如果可用性區域發生中斷，您必須處理故障轉移，以將流量傳送至另一個可用性區域中的資源。
跨多個可用性區域的主動-被動部署有時稱為 區域內DR 或 MetroDR。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 部署在單一可用性區域中時：可靠性低。區域性部署不會針對數據中心或可用性區域中的中斷提供任何復原功能。 您必須跨多個可用性區域部署備援資源，才能達到高復原能力。 部署在多個可用性區域中時：可靠性高。服務可以復原數據中心或可用性區域中斷。 |
| 成本最佳化 | 部署在單一可用性區域中時：低成本。單一區域部署只需要每個資源的單一實例。 部署在多個可用性區域中時：高成本。您可以部署多個資源的實例，每個實例都會個別計費。 |
| 效能效率 | 高效能。 當服務要求的元件位於相同的可用性區域中時，延遲可能會非常低。 |
| 卓越營運 | 操作效率低。 您必須設定和管理服務的多個實例。 您必須在可用性區域之間複寫數據。 在可用性區域中斷期間，故障轉移是您的責任。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 高。 當您部署使用此方法的解決方案時，數據會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 具有可用性區域的區域。 此方法可在支援 可用性區域的任何區域中使用。 |
此方法通常用於以虛擬機為基礎的工作負載。 如需支援區域部署之服務的完整清單，請參閱 可用性區域服務和區域支援。
當您規劃區域性部署時，請確認您打算使用的可用性區域中是否支援您使用的 Azure 服務。 例如，若要列出每個可用性區域中可用的虛擬機 SKU，請參閱 檢查 VM SKU 可用性。
提示
當您將資源部署到特定可用性區域時，您可以選取區域號碼。 每個 Azure 訂用帳戶的區域號碼順序都不同。 如果您跨多個 Azure 訂用帳戶部署資源，請確認您應該在每個訂用帳戶中使用的區域號碼。 如需詳細資訊，請參閱實體和邏輯可用性區域。
部署方法 3：區域備援部署
當您使用此方法時，應用層會分散到多個可用性區域。 當要求送達時，內建於服務中的負載平衡器（其本身跨越可用性區域）會將要求分散到每個可用性區域中的實例。 如果可用性區域發生中斷，負載平衡器會將流量導向狀況良好的可用性區域中的實例。
您的儲存層也會分散到多個可用性區域。 應用程式數據的複本會透過 同步復寫分散到多個可用性區域。 當應用程式對數據進行變更時，記憶體服務會將變更寫入多個可用性區域，而且只有在所有這些變更都完成時，才會將交易視為完成。 此程式可確保每個可用性區域一律會有最新的數據複本。 如果可用性區域發生中斷，可以使用另一個可用性區域來存取相同的數據。
區域備援方法會增加解決方案對數據中心中斷等問題的復原能力。 不過，由於數據會以同步方式複寫，因此您的應用程式必須等候數據寫入多個可能位於大都市區不同部分的不同位置。 對大多數應用程式而言，區域間通訊所涉及的延遲是微不足道的。 不過，對於某些高度延遲敏感的工作負載，跨可用性區域的同步復寫可能會影響應用程式的效能。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 可靠性高。 服務可復原數據中心或可用性區域的中斷。 數據會同步復寫到可用性區域，且不會延遲。 |
| 成本最佳化 | 中等成本。 視您使用的服務而定，可能會產生較高服務層級的一些成本，以啟用區域備援。 |
| 效能效率 | 對於大部分的工作負載：可接受的效能。這種方法可能會提供令人滿意的效能。 對於高度延遲敏感的工作負載：低效能。某些元件可能會因為區域間流量或數據復寫時間而對延遲造成敏感性。 |
| 卓越營運 | 高效作業效率。 您通常只需要管理每個資源的單一邏輯實例。 對於大多數服務，在可用性區域中斷期間，故障轉移是Microsoft的責任，而且會自動發生。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 高。 當您部署使用此方法的解決方案時，數據會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 具有可用性區域的區域。 此方法可在支援 可用性區域的任何區域中使用。 |
許多 Azure 服務都可能採用此方法，包括 Azure 虛擬機器擴展集、Azure App 服務、Azure Functions、Azure Kubernetes Service、Azure 儲存體、Azure SQL、Azure 服務匯流排，以及其他許多服務。 如需支援區域備援的完整服務清單，請參閱 可用性區域服務和區域支援。
跨區域備份的區域備援部署
您可以將基礎結構和數據定期備份至次要區域，以擴充區域備援部署。 此方法提供區域備援方法的優點，並新增一層保護，以減輕完全區域中斷的極不可能事件。
當您實作此方法時，您必須仔細考慮 RTO 和 RPO：
復原時間：如果發生區域性中斷，您可能需要在另一個 Azure 區域中重建解決方案，這會影響復原時間。 請考慮使用 IaC 方法來建置解決方案，以便在重大災害期間快速重新部署到另一個區域。 請確定您的部署工具和程式與應用程式一樣具有復原性，因此即使發生中斷，您仍可使用它們來重新部署解決方案。 規劃並排練將解決方案還原回工作狀態所需的步驟。
恢復點：您的備份頻率會決定您可能會遇到的數據遺失量（恢復點）。 您通常可以控制備份的頻率，以符合您的 RPO。
提示
這種方法通常為所有架構考慮提供良好的平衡。 如果您不確定要使用哪種方法，請從這種類型的部署開始。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 可靠性很高。 服務可復原數據中心或可用性區域的中斷。 對大部分服務而言，數據會自動跨區域複寫，且不會延遲。 數據會以異步方式備份至異地分隔的區域。 此備份可藉由將數據遺失降至最低，以減少完整區域中斷的影響。 完整區域中斷之後，您可以手動將作業還原到另一個區域。 不過，復原程式可能很複雜，而且可能需要一段時間才能手動還原至其他區域。 |
| 成本最佳化 | 中等成本。 一般而言，將備份新增至另一個區域的成本只會略高於實作區域備援。 |
| 效能效率 | 對於大部分的工作負載：可接受的效能。這種方法可能會提供令人滿意的效能。 對於高度延遲敏感的工作負載：低效能。某些元件可能會因為區域間流量或數據復寫時間而對延遲造成敏感性。 |
| 卓越營運 | 在可用性區域中斷期間：高效運作效率。故障轉移是Microsoft並自動發生的責任。 在區域性中斷期間：低營運效率。故障轉移是您的責任，可能需要手動作業和重新部署。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 取決於區域選取專案。 數據主要儲存在您指定的 Azure 區域中，但您需要選取另一個區域來儲存備份。 選取與您的數據落地需求相容的區域。 |
| 區域可用性 | 具有可用性區域的區域。 此方法可在支援 可用性區域的任何區域中使用。 |
部署方法 4：多區域部署
您可以將多個 Azure 區域一起使用，將解決方案分散到廣泛的地理區域。 您可以使用這個多區域方法來改善解決方案的可靠性，或支援地理位置分散的使用者。 藉由部署到多個區域，您也會降低在單一區域中遇到暫時資源容量限制的風險。 如果數據落地是解決方案的重要考慮，請仔細考慮您使用哪些區域以確保您的數據只儲存在符合您需求的位置。
主動和被動區域
多區域架構很複雜，而且有許多方式可以設計多區域解決方案。 對於某些工作負載，讓多個區域同時主動處理要求是合理的（主動-主動部署）。 對於其他工作負載，最好指定一個主要區域，並使用一或多個次要區域進行故障轉移（主動-被動部署）。 本節著重於第二個案例，其中一個區域是主動的，另一個是被動的。 如需主動-主動多區域解決方案的相關信息，請參閱 部署戳記模式 和 Geode 模式。
資料複寫
跨區域通訊的速度比區域內的通訊慢得多。 一般而言，兩個區域之間的較大地理距離會產生更多的網路等待時間，因為數據需要移動的較長實體距離。 當您在兩個區域之間連線時，請參閱 Azure 網路來回延遲統計數據 ，以瞭解預期的網路等待時間。
跨區域網路等待時間可能會大幅影響您的解決方案設計，因為您需要仔細考慮額外的延遲如何影響數據復寫和其他交易。 對於許多解決方案，跨區域架構需要 異步 複寫，以將跨區域流量對效能的影響降到最低。
異步數據復寫
當您跨區域實作異步複寫時，應用程式不會等候所有區域認可變更。 在主要區域中認可變更之後，交易就會被視為完成。 變更會在稍後復寫至次要區域。 此方法可確保區域間連線延遲不會直接影響應用程式效能。 不過，由於復寫延遲，全區域中斷可能會導致某些數據遺失。 發生此數據遺失的原因可能是區域在主要區域中完成寫入后可能會發生中斷，但在變更可以復寫至另一個區域之前。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 可靠性高。 解決方案可復原數據中心、可用性區域或整個區域的中斷。 數據會復寫，但可能不是同步的，因此在故障轉移案例中可能會遺失某些數據。 |
| 成本最佳化 | 高成本。 您必須在每個區域中部署個別的資源，而且每個資源會產生部署和維護成本。 跨區域的數據復寫也可能會產生顯著的成本。 |
| 效能效率 | 高效能。 應用程式要求不需要跨區域流量，因此流量通常是低延遲。 |
| 卓越營運 | 操作效率低。 您必須跨多個區域部署和管理資源。 您也會在區域中斷期間負責區域之間的故障轉移。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 取決於區域選取專案。 此方法會要求您選取多個區域，讓工作負載執行。 選擇與您的數據落地需求相容的區域。 |
| 區域可用性 | 許多 Azure 區域 會配對。 某些 Azure 服務會使用配對的區域自動復寫數據。 如果您在沒有配對的區域執行工作負載，您可能需要使用不同的方法來復寫數據。 |
同步數據複寫
如果您實作同步多區域解決方案，您的應用程式必須在交易視為完成之前，等候寫入作業在每個 Azure 區域中完成。 等候寫入作業所產生的延遲取決於區域之間的距離。 對於許多工作負載，區域間延遲可能會使同步復寫速度太慢，無法很有用。
下表摘要說明一些要素考慮：
| 要素 | 影響 |
|---|---|
| 可靠性 | 可靠性很高。 解決方案可復原數據中心、可用性區域或整個區域的中斷。 數據一律會跨區域同步，因此，即使發生完整區域遺失，您的數據仍可在另一個區域中取得並完成。 |
| 成本最佳化 | 高成本。 您必須在每個區域中部署個別的資源，而且每個資源會產生部署和維護成本。 跨區域的數據復寫也可能會產生顯著的成本。 |
| 效能效率 | 效能低。 應用程式要求需要跨區域流量。 視區域之間的距離而定，同步復寫可能會對要求造成顯著的延遲。 |
| 卓越營運 | 操作效率低。 您必須跨多個區域部署和管理資源。 您也會在區域中斷期間負責區域之間的故障轉移。 |
下表摘要說明架構觀點中的一些考慮：
| 架構考慮 | 影響 |
|---|---|
| 符合數據落地 | 取決於區域選取專案。 此方法會要求您選取多個區域，讓工作負載執行。 選取與您數據落地需求相容的區域。 |
| 區域可用性 | 許多 Azure 區域 會配對。 某些 Azure 服務會使用配對的區域自動復寫數據。 如果您在沒有配對的區域執行工作負載，您可能需要使用不同的方法來復寫數據。 |
區域架構
當您設計多區域解決方案時，請考慮您打算使用的 Azure 區域是否配對。
即使區域未配對，您也可以建立多區域解決方案。 不過，您用來實作多重區域架構的方法可能不同。 例如，在 Azure 儲存體 中，您可以使用異地備援記憶體 （GRS） 搭配配對的區域。 如果無法使用 GRS，請考慮使用 Azure 儲存體 物件複寫等功能，或設計應用程式以寫入多個區域。
結合多區域和多重區域方法
如果您的商務需求需要這類解決方案，您應該結合多區域和多區域語句。 例如，您可以將區域備援元件部署到每個區域，同時設定區域之間的複寫。 對於某些解決方案，此方法提供非常高的可靠性。 不過，設定這種類型的方法可能會很複雜，而且這種方法可能很昂貴。
重要
任務關鍵性工作負載應該同時使用多個可用性區域 和 多個區域。 如需設計任務關鍵性工作負載時應提供之考慮的詳細資訊，請參閱 任務關鍵性工作負載檔。
Azure 服務如何支援部署方法
請務必瞭解您使用之 Azure 服務的特定詳細數據。 例如，某些 Azure 服務會要求您在第一次部署資源時設定其可用性區域設定，而其他服務則支援稍後變更部署方法。 同樣地，某些服務功能可能無法透過每個部署方法使用。
若要深入瞭解每個 Azure 服務要考慮的特定部署選項和方法，請流覽可靠性中 樞。
範例
本節說明一些常見的使用案例，以及您通常需要針對每個工作負載考慮的主要需求。 針對每個工作負載，會根據本文所述的需求和方法，提供一或多個建議的部署方法。
企業營運應用程式
Contoso，Ltd.，是一家大型製造公司。 該公司正在實作企業營運應用程式來管理其財務程式的某些元件。
商務需求：系統管理的信息難以取代，因此數據必須可靠地保存。 架構設計人員表示，系統需要盡可能少停機，而且數據遺失也越少。 Contoso 的員工會在工作日使用系統，因此高效能對於避免讓小組成員等候很重要。 成本也是個問題，因為財務小組必須支付解決方案的費用。
建議的方法： 跨區域 備份的區域備援部署提供多層高效能的復原功能。
內部應用程式
第四咖啡是一家小型企業。 公司正在開發新的內部應用程式，員工可用來提交時程表。
商務需求：針對此工作負載，成本效益是主要考慮。 Fourth Coffee 評估了停機時間的業務影響，並決定應用程式不需要優先處理復原或效能。 公司接受 Azure 可用性區域或區域中中斷的風險，可能會暫時無法使用應用程式。
建議的方法：
舊版應用程式移轉
Fabrikam， Inc.， 正在將舊版應用程式從內部部署資料中心移轉至 Azure。 實作會使用以虛擬機為基礎的 IaaS 方法。 應用程式不是針對雲端環境所設計，應用層與資料庫之間的通訊非常 閒聊。
商務需求：效能是此應用程式的優先順序。 復原也很重要，即使 Azure 數據中心發生中斷，應用程式也必須繼續運作。
建議的方法：
- Fabrikan 應該先嘗試區域 備援部署。 他們應該確認效能符合其需求。
- 如果無法接受區域備援解決方案的效能，請考慮 使用區域性（已釘選的）部署，並在多個可用性區域（區域DR）之間進行被動部署。
醫療保健應用程式
Lamna Healthcare 公司正在 Azure 上實作新的電子健康記錄系統。
商務需求：由於此解決方案所儲存的數據本質，數據落地非常重要。 Lamna 會以嚴格的法規架構運作，其規定數據必須保留在特定位置。
建議的方法：
- 如果有多個區域符合 Lamna 的數據落地需求，則多重區域多區域部署。
- 如果只有符合其需求的單一區域，請考慮區域備援部署，或跨區域備份的區域備援部署提供單一區域解決方案
銀行系統
Woodgrove Bank 會從部署至 Azure 的大型解決方案執行其核心銀行業務。
商務需求：這是任務關鍵系統。 任何中斷都可能會對客戶造成重大財務影響。 因此，伍德格羅夫銀行的風險承受能力很低。 系統需要可能的最高可靠性層級，而架構需要降低任何可減輕之失敗的風險。
建議的方法：對於任務關鍵性系統，請使用 多區域多區域部署。 確定區域符合公司的數據落地需求。
軟體即服務 (SaaS)
Proseware， Inc.， 建置全球公司所使用的軟體。 公司的使用者群分散在地理上。
商務需求:P roseware 必須讓每個客戶選擇接近客戶的部署區域。 啟用此選項對於延遲和客戶的數據落地需求而言很重要。
建議的方法：
- 多區域多區域部署通常是 SaaS 提供者的絕佳選擇，尤其是在部署戳記模式中使用時。
- 單一區域區域 備援部署 會與全域流量加速解決方案搭配使用，例如 Azure Front Door。
相關連結
以下是多區域和多區域解決方案的一些參考架構和範例案例：
許多 Azure 服務提供如何使用多個可用性區域的指引，包括下列範例：
- Azure Site Recovery：在可用性區域之間啟用 Azure VM 災害復原
- Azure NetApp Files：瞭解 Azure NetApp Files 的跨區域複寫
- Azure 儲存體複寫
可靠性檢查清單
請參閱一組完整的建議。