使用可用性區域和區域的建議

  • 發行項

適用於此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：05 在不同的層級新增備援，特別是針對重要流程。 根據識別的可靠性目標，將備援套用至計算、數據、網路和其他基礎結構層。

相關指南：高可用性多區域設計 | 備援

本指南說明決定何時要跨可用性區域或區域部署工作負載的建議。

當您設計 Azure 的解決方案時，您必須決定要部署在區域中的多個可用性區域，還是部署到多個區域。 此決策會影響解決方案的可靠性、成本和效能，以及小組操作解決方案的能力。 本指南提供影響決策的主要商務需求、您可以考慮的方法、每個方法的取捨，以及每個方法對 Azure Well-Architected Framework 核心要素的影響。

決定最適合您解決方案使用的 Azure 區域是一個重要選擇。 選取 Azure 區域指南說明如何在多個地理區域中選取及操作。 您選擇如何在解決方案中使用區域和可用性區域，也會影響 Well-Architected 架構的數個要素：

  • 可靠性：您選擇的部署方法可協助您降低各種風險類型。 一般而言，藉由將您的工作負載分散到更地理分散的區域，即可達到更高的復原能力。
  • 成本優化：某些架構方法需要部署比其他資源更多的資源，這會增加您的資源成本。 其他方法涉及跨異地分隔的可用性區域或區域傳送數據，這可能會導致網路流量費用。 此外，也請務必考慮管理資源的持續成本，當您有完整的商務需求時，這通常較高。
  • 效能效率：可用性區域會透過高頻寬、低延遲的網路連結連線在一起，這足以讓大部分工作負載啟用跨區域的同步復寫和通訊。 不過，如果您的工作負載已經過測試，而且對跨區域的網路等待時間很敏感，您可能需要考慮實際找出工作負載的元件，以在通訊時將延遲降到最低。
  • 營運卓越：複雜的架構需要更多心力來部署、設定和管理。 此外，針對高可用性解決方案，您可能需要規劃如何故障轉移至一組次要資源。 故障轉移、容錯回復和透明地重新導向流量可能很複雜，特別是需要手動步驟時。 將部署和管理程序自動化是很好的作法。 如需詳細資訊，請參閱營運卓越要素指南，包括 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 是小型企業。 該公司正在開發新的內部應用程式，員工可用來提交時程表。

商務需求：針對此工作負載，成本效益是主要考慮。 Fourth Coffee 評估停機時間的業務影響，並決定應用程式不需要設定復原或效能的優先順序。 公司接受 Azure 可用性區域或區域中中斷的風險，可能會讓應用程式暫時無法使用。

建議的方法：

舊版應用程式移轉

Fabrikam， Inc.， 正在將舊版應用程式從內部部署資料中心移轉至 Azure。 實作會使用以虛擬機為基礎的 IaaS 方法。 應用程式不是針對雲端環境所設計，而且應用層與資料庫之間的通訊非常 聊天。

商務需求：效能是此應用程式的優先順序。 復原也很重要，即使 Azure 數據中心發生中斷，應用程式也必須繼續運作。

建議的方法：

醫療保健應用程式

Lamna Healthcare 公司正在 Azure 上實作新的電子健康記錄系統。

商務需求：由於此解決方案儲存的數據本質，數據落地非常重要。 Lamna 會以嚴格的法規架構運作，該架構會要求數據必須保留在特定位置。

建議的方法：

銀行系統

Woodgrove Bank 會從部署至 Azure 的大型解決方案執行其核心銀行作業。

商務需求：這是任務關鍵性系統。 任何中斷都可能造成客戶的重大財務影響。 因此，Woodgrove Bank 具有非常低的風險承受能力。 系統需要可能的最高可靠性層級，而架構需要降低任何可減輕失敗的風險。

建議的方法：對於任務關鍵性系統，請使用 多區域多區域部署。 確定區域符合公司的數據落地需求。

軟體即服務 (SaaS)

Proseware Inc.建置全球公司所使用的軟體。 公司的使用者基底廣泛分散於地理上。

商務需求:P roseware 必須讓每個客戶選擇接近客戶的部署區域。 啟用此選項對於延遲和客戶的數據落地需求而言很重要。

建議的方法：

以下是多區域和多區域解決方案的一些參考架構和範例案例：

許多 Azure 服務提供如何使用多個可用性區域的指引，包括下列範例：

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單