從全區域服務中斷復原
Azure 會以實體和邏輯方式分割成稱為區域的單位。 區域是由一或多個鄰近的數據中心所組成。 許多區域和服務也支援 可用性區域，可用來針對單一數據中心的中斷提供更多復原能力。 請考慮使用具有可用性區域的區域來改善解決方案的可用性。
在罕見的情況下，整個可用性區域或區域中的設施可能會因為網路失敗而變得無法存取。 或者，由於自然災害，設施可能會完全遺失。 Azure 具有建立跨區域和區域分散的應用程式的功能。 這類散發有助於將某個區域或區域中失敗可能會影響其他區域或區域的可能性降到最低。
雲端服務
資源管理
您可以在每個目標區域中建立個別的雲端服務，然後將部署套件發佈至每個雲端服務，以跨區域散發計算實例。 不過，應用程式開發人員或流量管理服務必須實作跨不同區域的雲端服務散發流量。
判斷預先部署災害復原的備用角色實例數目，是容量規劃的重要層面。 擁有完整規模的次要部署可確保容量已在需要時可供使用;不過，這實際上增加了成本的兩倍。 常見的模式是擁有小型次要部署，足以執行重要服務。 這個小型次要部署是個好主意，既要保留容量，又要測試次要環境的設定。
注意
訂用帳戶配額不是容量保證。 配額只是信用額度限制。 若要保證容量，必須在服務模型中定義所需的角色數目，而且必須部署角色。
負載平衡
若要對跨區域的流量進行負載平衡，需要流量管理解決方案。 Azure 提供 Azure 流量管理員。 您也可以利用提供類似流量管理功能的第三方服務。
策略
許多替代策略都可用於跨區域實作分散式計算。 這些必須針對應用程式的特定商務需求和情況量身打造。 概括而言，方法可以分成下列類別：
在災害時重新部署：在此方法中，應用程式會在災害發生時從頭開始重新部署。 這適用於不需要保證復原時間的非關鍵應用程式。
暖備援 （主動/被動）：次要託管服務是在替代區域中建立，且角色會部署以保證最小容量;不過，角色不會接收生產流量。 此方法適用於尚未設計為將流量分散到區域的應用程式。
熱備援 （主動/主動）：應用程式的設計目的是要接收多個區域中的生產負載。 每個區域中的雲端服務可能設定為容量高於災害復原目的所需的容量。 或者，雲端服務可能會在災害和故障轉移時視需要相應放大。 這種方法需要對應用程式設計進行大量投資，但它有顯著的好處。 其中包括低且保證的復原時間、對所有復原位置的持續測試，以及有效率地使用容量。
分散式設計的完整討論超出本檔的範圍。 如需詳細資訊，請參閱 Azure 應用程式 的災害復原和高可用性。
虛擬機器
在很多方面，基礎結構即服務 （IaaS） 虛擬機 （VM） 的復原類似於平臺即服務 （PaaS） 計算復原。 不過，有一個重要的差異，因為 IaaS VM 同時包含 VM 和 VM 磁碟。
使用 Azure 備份 建立應用程式一致的跨區域備份。 Azure 備份 可讓客戶跨多個 VM 磁碟建立應用程式一致的備份，並支援跨區域復寫備份。 您可以選擇在建立時異地復寫備份保存庫，以執行此動作。 備份保存庫的復寫必須在建立時設定。 稍後無法設定。 如果區域遺失，Microsoft讓客戶可以使用備份。 客戶能夠還原至任何已設定的還原點。
將數據磁碟與作業系統磁碟分開。 IaaS VM 的重要考慮是，您無法在不重新建立 VM 的情況下變更作業系統磁碟。 如果您的復原策略是在災害后重新部署，則這不是問題。 不過，如果您使用暖備援方法來保留容量，則可能是個問題。 若要正確實作此作業，您必須將正確的操作系統磁碟部署至主要和次要位置，而且應用程式數據必須儲存在個別的磁碟驅動器上。 可能的話，請使用可在這兩個位置上提供的標準操作系統組態。 故障轉移之後，您必須將數據磁碟驅動器附加至次要DC中的現有IaaS VM。 使用 AzCopy 將數據磁碟的快照集複製到遠端月臺。
請注意多個 VM 磁碟異地故障轉移之後的潛在一致性問題。 VM 磁碟會實作為 Azure 儲存體 Blob，而且具有相同的異地複寫特性。 除非使用 Azure 備份，否則不會保證磁碟之間的一致性，因為異地復寫是異步的，而且會獨立複寫。 個別 VM 磁碟保證會在異地故障轉移之後處於當機一致狀態，但跨磁碟不一致。 在某些情況下，這可能會造成問題（例如，在磁碟等量分割的情況下）。
使用 Azure Site Recovery 跨區域複寫應用程式。 使用 Azure Site Recovery 時，客戶不需要擔心將數據磁碟與操作系統磁碟或潛在的一致性問題分開。 Azure Site Recovery 會將在實體和虛擬機上執行的工作負載從主要月臺（內部部署或 Azure 中）復寫到次要位置（在 Azure 中）。 當客戶的主要月台發生中斷時，可以觸發故障轉移，以快速將客戶傳回作業狀態。 還原主要位置之後，客戶就可以容錯回復。 它們可以輕鬆地使用恢復點與應用程式一致快照集進行複寫。 這些快照集會擷取磁碟數據、所有記憶體內部數據和所有進程內交易。 Azure Site Recovery 可讓客戶將復原時間目標 （RTO） 和恢復點目標 （RPO） 保留在組織限制內。 客戶也可以輕鬆地執行災害復原演練，而不會影響生產環境中的應用程式。 客戶可以使用復原方案來排序在多個 VM 上執行的多層應用程式的故障轉移和復原。 他們可以在復原方案中將機器群組在一起，並選擇性地新增腳本和手動動作。 復原計劃可以與 Azure 自動化 Runbook 整合。
儲存體
使用 Blob、數據表、佇列和 VM 磁碟記憶體的異地備援記憶體進行復原
在 Azure 中，Blob、數據表、佇列和 VM 磁碟預設都會進行異地複寫。 這稱為異地備援記憶體 （GRS）。 GRS 會將記憶體數據復寫至位於特定地理區域內數百英里的配對數據中心。 GRS 的設計目的是為了在發生重大數據中心災害時提供額外的持久性。 Microsoft控制故障轉移發生的時間，且故障轉移僅限於在合理時間內將原始主要位置視為無法復原的主要災害。 在某些情況下，這可以是數天。 雖然服務等級協定尚未涵蓋同步處理間隔，但數據通常會在幾分鐘內復寫。
如果發生異地故障轉移，將不會變更帳戶的存取方式（URL 和帳戶密鑰不會變更）。 不過，記憶體帳戶會在故障轉移之後位於不同的區域中。 這可能會影響需要其記憶體帳戶區域親和性的應用程式。 即使對於不需要相同數據中心內記憶體帳戶的服務與應用程式，跨數據中心的延遲可能是暫時將流量移至故障轉移區域的令人信服的原因。 這可能會納入整體災害復原策略。
除了 GRS 提供的自動故障轉移之外，Azure 還引進了一項服務，可讓您讀取次要記憶體位置中數據的複本。 這稱為讀取許可權異地備援記憶體 （RA-GRS）。
如需 GRS 和 RA-GRS 記憶體的詳細資訊，請參閱複寫 Azure 儲存體。
異地復寫區域對應
請務必知道數據在異地復寫的位置，以便知道在何處部署需要與記憶體區域親和性的其他數據實例。 如需詳細資訊，請參閱 Azure 配對區域。
異地複寫價格
異地復寫包含在目前 Azure 儲存體 定價中。 這稱為異地備援記憶體 （GRS）。 如果您不想要異地複寫數據，您可以停用帳戶的異地複寫。 這稱為本地備援記憶體 （LRS），相較於 GRS，它會以折扣價格收費。
判斷是否已發生異地故障轉移
如果發生異地故障轉移，這將會張貼至 Azure 服務健康情況儀錶板。 不過，應用程式可以藉由監視其記憶體帳戶的異地區域，來實作自動化的偵測方式。 這可用來觸發其他復原作業，例如在其記憶體移至的異地區域中啟用計算資源。
Database
SQL Database
Azure SQL 資料庫 提供兩種類型的復原：異地還原和主動式異地複寫。
異地復原
基本、標準和進階資料庫也可使用異地還原 。 當資料庫因為裝載您資料庫所在的區域中發生事件而無法使用時，它會提供預設復原選項。 與時間點還原類似，異地還原依賴異地備援 Azure 記憶體中的資料庫備份。 它會從異地復寫的備份複本還原，因此可復原主要區域中的記憶體中斷。 如需詳細資訊，請參閱將 Azure SQL 資料庫 或故障轉移至次要複本。
作用中異地複寫
作用中異地復 寫適用於所有資料庫層。 它專為具有比異地還原可提供更積極復原需求的應用程式所設計。 使用主動式異地復寫，您可以在不同區域的伺服器上建立最多四個可讀取的次要複本。 您可以起始故障轉移至任何次要複本。 此外，主動式異地復寫可用來支援應用程式升級或重新配置案例，以及唯讀工作負載的負載平衡。 如需詳細資訊，請參閱設定 Azure SQL 資料庫 的作用中異地複寫和起始故障轉移。 如需如何在不停機的情況下設計和實作應用程式和應用程式升級的詳細數據，請參閱使用 Azure SQL 資料庫 和管理雲端應用程式的滾動升級 SQL 資料庫 主動式異地複寫。
Azure 虛擬機器上的 SQL Server
在 Azure 虛擬機器 中執行的 SQL Server 2012 和更新版本，有各種不同的選項可供復原和高可用性。 如需詳細資訊，請參閱 Azure 虛擬機器 中 SQL Server 的高可用性和災害復原。
其他 Azure 平台服務
嘗試在多個 Azure 區域中執行雲端服務時，您必須考慮每個相依性的影響。 在下列各節中，服務特定指引假設您必須在替代 Azure 數據中心使用相同的 Azure 服務。 這牽涉到組態和數據復寫工作。
注意
在某些情況下，這些步驟有助於減輕服務特定的中斷，而不是整個數據中心事件。 從應用程式的觀點來看，服務特定的中斷可能就像限制一樣，而且需要暫時將服務移轉至替代 Azure 區域。
服務匯流排
Azure 服務匯流排 會使用不跨越 Azure 區域的唯一命名空間。 因此，第一個需求是在替代區域中設定必要的服務總線命名空間。 不過，佇列訊息的持久性也有考慮。 跨 Azure 區域復寫訊息有數種策略。 如需這些復寫策略和其他災害復原策略的詳細資訊，請參閱將應用程式與 服務匯流排 中斷和災害隔離的最佳做法。
應用程式服務
若要將 Azure App 服務 應用程式，例如 Web Apps 或 Mobile Apps，移轉至次要 Azure 區域，您必須擁有可供發行的網站備份。 如果中斷未涉及整個 Azure 數據中心，則可能可以使用 FTP 來下載網站內容的最新備份。 然後，除非您先前已這麼做來保留容量，否則請在替代區域中建立新的應用程式。 將月臺發佈至新的區域，並進行任何必要的組態變更。 這些變更可能包括資料庫 連接字串 或其他區域特定設定。 如有必要，請新增網站的SSL憑證，並變更 DNS CNAME 記錄，讓自定義功能變數名稱指向重新部署的 Azure Web 應用程式 URL。
HDInsight
與 HDInsight 相關聯的數據預設會儲存在 Azure Blob 儲存體 中。 HDInsight 要求 Hadoop 叢集處理 MapReduce 作業必須與包含所分析資料的記憶體帳戶相同區域共置。 如果您使用的是可供 Azure 儲存體 的異地複寫功能，您可以在因為某些原因而無法使用主要區域時，存取複寫數據的次要區域中的數據。 您可以在已復寫數據的區域中建立新的 Hadoop 叢集，並繼續處理。
SQL Reporting
此時，從 Azure 區域的遺失復原需要不同 Azure 區域中的多個 SQL 報告 實例。 這些 SQL 報告 實例應該存取相同的數據，而且在發生災害時，該數據應該有自己的復原計劃。 您也可以針對每個報表維護 RDL 檔案的外部備份複本。
媒體服務
Azure 媒體服務 有不同的編碼和串流復原方法。 一般而言，串流在區域性中斷期間更為重要。 若要為此做好準備，您應該在兩個不同的 Azure 區域中有一個 媒體服務 帳戶。 編碼的內容應該位於這兩個區域中。 在失敗期間，您可以將串流流量重新導向至替代區域。 您可以在任何 Azure 區域中執行編碼。 如果編碼具有時間敏感性，例如在即時事件處理期間，您必須準備好在失敗期間將作業提交至替代數據中心。
虛擬網路
組態檔提供在替代 Azure 區域中設定虛擬網路的最快方式。 在主要 Azure 區域中設定虛擬網路之後， 將目前網路的虛擬網路設定 匯出至網路組態檔。 如果主要區域中發生中斷， 請從預存組態檔還原虛擬網路 。 然後，設定其他雲端服務、虛擬機或跨單位設定，以使用新的虛擬網路。
有 VNET 相關資源需要納入考慮（例如 NSG、DNS、路由表）。 基礎結構即程式代碼中所述的方法，是每次產生相同環境的方法，而且您可以在新的區域中部署。
災害復原的檢查清單
雲端服務 檢查清單
- 檢閱本檔 雲端服務 一節。
- 建立跨區域災害復原策略。
- 瞭解替代區域中保留容量的取捨。
- 使用流量路由工具，例如 Azure 流量管理員。
虛擬機器 檢查清單
- 檢閱本檔 虛擬機器 一節。
- 使用 Azure 備份 跨區域建立應用程式一致的備份。
記憶體檢查清單
- 檢閱本檔的記憶體一節。
- 請勿停用記憶體資源的異地複寫。
- 了解發生故障轉移時異地復寫的替代區域。
- 建立使用者控制故障轉移策略的自定義備份策略。
SQL 資料庫 檢查清單
虛擬機器 檢查清單上的 SQL Server
- 檢閱本檔 虛擬機器 一節上的 SQL Server。
- 使用跨區域 AlwaysOn 可用性群組或資料庫鏡像。
- 或者，使用備份和還原至 Blob 記憶體。
服務匯流排 檢查清單
- 檢閱本檔 服務匯流排 一節。
- 在替代區域中設定 服務匯流排 命名空間。
- 請考慮跨區域訊息的自定義複寫策略。
App Service 檢查清單
- 檢閱本檔的 App Service 區段。
- 維護主要區域以外的月臺備份。
- 如果中斷部分，請嘗試使用 FTP 擷取目前的月臺。
- 規劃將月臺部署至替代區域中的新月臺或現有月臺。
- 規劃應用程式和 DNS CNAME 記錄的設定變更。
HDInsight 檢查清單
- 檢閱本檔的 HDInsight 區段。
- 使用復寫的數據，在區域中建立新的 Hadoop 叢集。
SQL 報告 檢查清單
- 檢閱本檔 SQL 報告 一節。
- 在不同的區域中維護替代 SQL 報告 實例。
- 維護個別的計劃，以將目標複寫至該區域。
媒體服務 檢查清單
- 檢閱本檔 媒體服務 一節。
- 在替代區域中建立 媒體服務 帳戶。
- 編碼這兩個區域中的相同內容以支援串流故障轉移。
- 如果發生服務中斷，請將編碼作業提交至替代區域。
虛擬網絡 檢查清單
- 檢閱本檔 虛擬網絡 一節。
- 使用導出的虛擬網路設定，在另一個區域中重新建立它。