本頁是否能提供幫助?
您對此內容的意見反應十分重要。 請告訴我們您的想法。
其他意見反應?
剩餘 1500 個字元
匯出 (0) 列印
全部展開

Azure 業務續航力技術指引

更新日期: 2015年3月

作者:Patrick Wickline、Jason Roth

參與者與審稿者:Luis Carlos Vargas Herring、Drew McDaniel、David Magar、Ganesh Srinivasan、Milan Gada、Nir Mashkowski ,Harsh Mittal、Sasha Nosov、Selcin Turkarslan、Cephas Lin、Cheryl McGuire、Bill Mathers、Mandi Ohlinger、Sidney Higa、Michael Green、Heidi Steen、Matt Winkler、Shayne Burgess、Larry Franks、Brad Severtson、Yavor Georgiev、Glenn Gailey、Tim Ammann、Ruppert Koch、Seth Manheim、Abhinav Gupta、Steve Danielson、Corey Sanders、John Deutscher

為符合高可用性和災害復原需求,需具備兩方面的知識:1) 詳細了解雲端平台功能的技術,以及 2) 如何適當地建構分散式服務。本文涵蓋前者,即 Azure 平台涉及業務續航力的功能和限制。不過其中也將概述非本文所著重的架構和設計模式。讀者應該查閱<其他資源>一節提供的資料以取得設計指引。

本文資訊歸納為以下幾個章節:

  • 1. 從本機失敗復原:實體硬體 (如磁碟機、伺服器和網路裝置) 可能全部失效,而負載尖峰時可能會耗盡資源。本節描述 Azure 在這些狀況下為維持高可用性所提供的功能。

  • 2. 從 Azure 地區耗損復原:廣泛性的失敗較為罕見,但也有可能發生。整個地區可能由於網路失敗而遭隔離,或因天然災害導致實體受損。本節說明如何使用 Azure 的功能,建立跨不同地理位置區域的應用程式。

  • 3. 從內部部署復原到 Azure:雲端已大幅改變災害復原的經濟體系,使得組織能夠利用 Azure 架設第二個網站以供進行復原。這可透過花費少量成本建置和維護次要資料中心的方式完成。本節說明 Azure 所提供用於將內部部署資料中心延伸到雲端的功能。

  • 4. 從資料損毀或意外刪除的情況復原:應用程式可能會有錯誤導致損毀資料,而操作員也有可能不慎誤刪重要資料。本節說明 Azure 提供用於備份資料和還原至先前時間點的功能。

  • 5. 其他資源:涵蓋 Azure 關於可用性和災害復原的其他重要資源。

應用程式可用性主要面臨兩大威脅:裝置 (如磁碟機和伺服器) 發生失敗,以及關鍵資源 (如計算資源) 在尖峰負載狀況下耗盡。Azure 提供一套資源管理、彈性、負載平衡及資料分割的功能組合,以啟用高可用性因應這些狀況。部分的上述功能將由所有雲端服務自動執行,但有時候應用程式開發人員���須完成若干額外事項方可獲益於這些功能。

所有由 Azure 託管的雲端服務都是一個或多個 Web 角色或背景工作角色的集合。特定角色可同時執行一個或多個執行個體。執行個體的數目取決於組態。角色執行個體是透過稱為網狀架構控制器 (FC) 的元件加以監視和管理。FC 會自動偵測及回應軟體和硬體失敗。

  • 每個角色執行個體都是在其自身的虛擬機器 (VM) 中執行,並透過客體代理程式 (GA) 與其 FC 通訊。GA 會收集資源和節點度量,包括 VM 使用狀況、狀態、記錄檔、資源使用量、例外狀況和失敗狀況。FC 將依可設定的間隔查詢 GA,且當 GA 無法回應時就會重新啟動 VM。

  • 如果發生硬體故障,相關聯的 FC 會將所有受影響的角色執行個體移至新的硬體節點,並重新設定網路以將流量路由傳送到該處。

為獲益於這些功能,開發人員要確保所有服務角色都應避免在角色執行個體上儲存狀態。相反地,所有永續性資料皆應存取自耐久儲存體,例如 Azure 儲存體服務或 Azure SQL 資料庫。如此便能將要求交由任何角色處理。這也表示角色執行個體隨時可以關機,而不會造成服務的暫時性或永續性狀態不一致。

將狀態儲存於角色外部的這項需求有幾個含意。例如,這意味著對給定的 Azure 儲存體資料表所做的一切相關變更,在可行的情況下應透過單一實體群組交易加以變更。當然,由單一交易進行所有變更未必始終都可行。請務必格外留意,確保角色執行個體若一旦失敗,致使長時間執行而跨越服務的永續性狀態更新達兩次以上的作業中斷時,並不會造成問題。如果另一個角色嘗試重試這類作業,則應該預防並處理只有部分工作完成的情況。

以跨多家商店分割資料的服務為例,如果背景工作角色在重新放置分區時關機,即有可能並未完成分區重新放置,或是另一個背景工作角色又接替從頭開始該項作業,而可能造成資料遭遺棄或資料損毀。為避免發生問題,長時間執行的作業必須具有等冪性 (可重複而無副作用) 且/或能以累加方式重新開始 (可從最近的失敗點繼續)。

  • 要具有等冪性,長時間執行的作業應該無論執行幾次都達到同樣的效果,即使是在執行期間中斷亦然。

  • 要能以累加方式重新開始,長時間執行的作業應該包含較少量不可部分完成作業的序列,並將其進度記錄於耐久儲存體,以使每個後續的引動過程都從其前項停止處接續。

最後,所有長時間執行的作業都應該重複叫用,直到作業成功為止。例如,背景工作角色可能會將佈建作業放入 Azure 佇列,並且只有在作業成功時才將其從佇列移除。記憶體回收可能需要清除已由中斷的作業所建立的資料。

每個角色執行的執行個體初始數目是由每個角色的組態所決定。管理員應該根據預期的負載,最初設定每個角色執行兩個以上的執行個體。不過,角色執行個體可以隨著使用模式變更,輕鬆地向上或向下調整。這可透過 Azure 入口網站、Windows PowerShell、服務管理應用程式開發介面或協力廠商工具來完成。FC 會自動佈建該角色的任何新執行個體並將其插入負載平衡器。

您可以使用 Azure 自動調整 (預覽),讓 Azure 自動根據負載調整角色。若使用自動調整應用程式區塊 (WASABi) 之類的架構,還能以程式設計方式為雲端服務內建及設定自動調整。

FC 使用兩種類型的磁碟分割:升級網域和故障網域。

  • 升級網域是用來以群組方式升級服務的角色執行個體。Azure 會將服務執行個體部署至多個升級網域。若是就地升級,FC 將停用整個升級網域內的所有執行個體,然後加以升級再重新啟動,接著移至下一個升級網域。這種方式可避免整個服務在升級程序期間變成無法使用。

  • 容錯網域會定義硬體或網路的潛在失敗點。任何角色若具有一個以上的執行個體,FC 將確保其執行個體分散到多個容錯網域,以避免遭隔離的硬體故障造成服務中斷。Azure 中所有伺服器和叢集失敗的風險��是由容錯網域控管。

依照 Azure SLA,Microsoft 保證若有兩個以上的 Web 角色執行個體部署至不同的容錯網域和升級網域,則這些執行個體將在至少 99.95% 的時間內具有外部連線能力。有別於更新網域,您無法控制容錯網域的數目。Azure 會自動配置容錯網域,並將角色執行個體分散至其中。系統至少會將每個角色的前兩個執行個體放入不同的容錯網域和升級網域,以確保至少有兩個執行個體的任何角色都能符合 SLA。如下圖所示。

容錯網域隔離 (簡化檢視)

送至 Web 角色的所有傳入流量都會通過無狀態負載平衡器,再由後者將用戶端要求分配給各角色執行個體。個別的角色執行個體並沒有公開 IP 位址,而且無法直接從網際網路定址。Web 角色都是無狀態,所以可將任何用戶端要求路由傳送到任何角色執行個體。系統每隔 15 秒會引發 StatusCheck 事件。這可用來指出角色是否已備妥要接收流量,或是仍在忙碌中而應將其帶離負載平衡器的輪替循環。

Azure 虛擬機器就高可用性而言,在許多方面與 PaaS 計算角色有所不同。某些情況下,您必須完成額外事項方能確保高可用性。

有別於 PaaS 角色執行個體,虛擬機器即使搬遷位置,儲存在該虛擬機器磁碟機上的資料仍將保存。Azure 虛擬機器是使用以 Blob 形式存在於 Azure 儲存體中的 VM 磁碟。由於 Azure 儲存體可用性的特質使然,儲存在虛擬機器磁碟機上的資料同樣具有高可用性。請注意 D:磁碟機是這項通則的一個例外。D:磁碟機其實是位於託管 VM 的機架伺服器上的實體儲存體,因此一旦回收 VM 後其資料就會遺失。D:磁碟機僅供做為暫時儲存體使用。

Azure 與生俱來即了解 PaaS 應用程式 (Web 角色和背景工作角色) 中的諸層,所以能夠正確地將其分散到各個容錯網域及更新網域。相對地,您必須使用可用性設定組手動定義 IaaS 應用程式中的諸層。IaaS 需仰賴可用性設定組以符合 SLA。

Windows Azure VM 的可用性設定組

在上圖中,IIS 層和 SQL 層是指派給不同的可用性設定組。這可確保將每一層的所有執行個體分散到各個容錯網域,以使其執行個體都有硬體備援,且在更新期間不至於被關閉。

如果 VM 應該接受流量分配,您就必須將雲端服務中的 VM 分組,並由特定的 TCP 或 UDP 端點進行負載平衡。如需詳細資訊,請參閱虛擬機器負載平衡。如果 VM 接收來自其他來源 (例如佇列機制) 的輸入,便不需要負載平衡器。負載平衡器會使用基本健全狀況檢查,判斷是否應將流量傳送至節點。您也可以自行建立探查,實作應用程式專屬的健全狀況度量來判斷 VM 是否應該接收流量。

Azure 儲存體是 Azure 的基準型耐久性資料服務,可提供 Blob、資料表、佇列和 VM 磁碟儲存體。此服務將組合運用複寫和資源管理,為單一資料中心提供高可用性。Azure 儲存體可用性 SLA 保證將在至少 99.9% 的時間內會成功且正確處理格式正確的要求,以新增、更新、讀取和刪除資料,而儲存體帳戶也會連接網際網路閘道。

Azure 儲存體促進資料耐久性的方式,是將所有資料的多個複本交由特定地區內位於完全獨立的實體儲存子系統中不同的磁碟機維護。資料會進行同步複寫,並先認可所有複本後再認可寫入動作。Azure 儲存體具有堅實的一致性,保證讀取一定會反映最近的寫入動作。此外,系統會持續掃描資料的複本,以偵測及修復位元腐壞,這對於儲存之資料的完整性通常是容易被忽略的威脅。服務只要使用 Azure 儲存體,便能因複寫而獲益。服務開發人員不需要完成任何額外事項即可從本機失敗復原。

2012 年 6 月 7 日之後建立的儲存體帳戶,都可成長至最大達 200 TB (舊版的上限為 100 TB)。如果需要額外的空間,應用程式必須設計成運用多個儲存體帳戶。

虛擬機器的 VM 磁碟是儲存為 Azure 儲存體中的分頁 Blob,因此其耐久性及延展性屬性與 Blob 儲存體完全相同。由於這樣的設計,即使執行 VM 的伺服器失敗而必須重新啟動另一部伺服器上的 VM,該虛擬機器磁碟上的資料也仍得以保存。

Microsoft Azure SQL Database 提供資料庫代管服務,讓應用程式可快速佈建及查詢關聯式資料庫、將資料插入其中。它會提供許多熟悉的 SQL Server 功能,同時減少了硬體負擔、組態、修補和恢復功能。

note附註
Azure SQL 資料庫 並未提供相當於 SQL Server 的 1:1 功能,且其目的是為了滿足特別適合雲端應用程式的一組不同需求 (彈性延展、可減少維護成本的資料庫代管服務等)。如需詳細資訊,請參閱資料序列:Azure 虛擬機器中的 SQL Server 與 SQL Database 的比較

Azure SQL 資料庫 會針對節點層級失敗提供內建的恢復功能。所有寫入資料庫的內容都會使用仲裁認可技術自動複寫到兩個或多個背景節點 (主要複本和至少一個次要複本必須先確認此活動會寫入交易記錄,然後才能將交易視為成功並傳回)。萬一發生節點失敗,資料庫會自動容錯移轉到其中一個次要複本。這將造成用戶端應用程式暫時性連接中斷。因此,所有 Microsoft Azure SQL Database 用戶端都必須實作某種形式的暫時性連接處理。如需詳細資訊,請參閱搭配 SQL Azure 使用暫時性錯誤處理應用程式區塊

每個資料庫在建立時,都會設定大小上限。目前可用的大小上限是 150GB。當資料庫遇到大小上限時,它會拒絕其他 INSERT 或 UPDATE 命令 (依然可以查詢和刪除資料)。

在資料庫內,Microsoft Azure SQL Database 是使用網狀架構來管理資源。不過,這並非網狀架構控制器,而是使用環形拓撲偵測失敗。叢集內的每個複本都有兩個相鄰複本,且各複本將負責偵測相鄰複本何時關閉。複本一旦關閉,其相鄰複本便會觸發重新組態代理程式 (RA) 以在另一部電腦上重新建立該複本。系統將提供引擎節流,確保邏輯伺服器並未佔用單一電腦的過多資源或超出電腦的實體限制。

應用程式的需求若超出 150GB 資料庫限制,就必須實作向外延展方法。使用 Microsoft Azure SQL Database 向外延展的執行方式是跨多個 Azure SQL 資料庫 手動分割資料,又稱為分區化。這種向外延展方法提供使成本隨著延展趨近於線性成長的機會。彈性成長或隨選容量可以隨著成本累加而視需要增多,因為資料庫是根據每天使用的實際大小平均值計費,而非根據可行的大小上限值。

若在 Azure 虛擬機器上安裝 SQL Server 2014 (IaaS),您就可以利用 SQL Server 傳統的可用性功能,例如 AlwaysOn 可用性群組或資料庫鏡像。請注意,相較於非虛擬化的內部部署 IT 基礎結構,Azure VM、儲存體和網路有著截然不同的作業特性。在 Azure 中,若要成功實作 HADR SQL Server 方案,您必須了解這些差異並設計方案配合它們。

當您在 Azure 中實作高可用性方案時,Azure 的可用性設定組可讓您將高可用性節點放在不同的容錯網域和升級網域。明確而言,可用性設定組採用了 Azure 的概念。這是您應該遵循的最佳作法,無論使用 AlwaysOn 可用性群組、資料庫鏡像或其他方式,都可以確定資料庫確實具有高可用性。如果沒有遵循這個最佳作法,您可能有系統是高可用性的錯誤假設,但實際上所有節點同時失敗,因為它們不巧放在 Azure 資料中心的相同容錯網域。此建議不適用於記錄傳送,因為既要提供災害復原功能,您即應確保伺服器是在不同的 Azure 資料中心位置 (地區) 執行。依照定義,這些資料中心位置是不同的容錯網域。

若要將 Azure VM 放在相同的可用性設定組中,您必須將 VM 部署在相同的雲端服務。只有在相同雲端服務中的節點可以參與相同的可用性設定組。此外,VM 應該位於相同的 VNet,以確保在服務修復後仍能維持其 IP,從而減少 DNS 更新次數。

您可以在 Azure 中使用 AlwaysOn 可用性群組或資料庫鏡像,為 SQL Server 資料庫實作高可用性方案。

下圖說明 Azure 虛擬機器中執行的 AlwaysOn 可用性群組的架構。此圖表是摘錄自 Azure 虛擬機器中的 SQL Server 高可用性和災害復原這篇深入探討本主題的文章。

Windows Azure 中的 AlwaysOn 可用性群組

您也可以在 Microsoft Azure 入口網站中使用 AlwaysOn 範本,在 Azure VM 上自動佈建 AlwaysOn 可用性群組的端對端部署。如需詳細資訊,請參閱 Microsoft Azure 入口網站映像庫中的 SQL Server AlwaysOn 服務

下圖說明在 Azure 虛擬機器上使用資料庫鏡像的情形。此圖表同樣摘錄自 Azure 虛擬機器中的 SQL Server 高可用性和災害復原這篇主題深入探討文章。

Windows Azure 中的資料庫鏡像
note附註
請注意,以上兩種架構都需要網域控制站。不過,資料庫鏡像也可搭配伺服器憑證使用,如此便不需要網域控制站。

Azure 雲端服務是建置在 Azure 上,因此可獲益於前述的平台功能而得從本機失敗復原。在某些情況下,您可以採取特定動作提高具體案例的可用性。

存取控制服務 (ACS) 2.0 每天會備份一次所有命名空間,並將其儲存在安全的異地位置。當 ACS 操作人員判斷在其中一個 ACS 地區資料中心發生了無法復原的資料遺失時,ACS 將嘗試還原最近的備份來復原客戶的訂用帳戶。由於備份頻率的緣故,可能會有多達 24 小時的資料遺失。如需詳細資訊,請參閱存取控制服務 (災害復原)

為了防範 Azure 服務匯流排發生暫時性中斷,請考慮建立耐久的用戶端佇列。這樣就能暫時使用替代的本機儲存機制,以儲存無法加入至服務匯流排佇列的訊息。應用程式可以決定要如何在服務復原後處理暫時儲存的訊息。如需詳細資訊,請參閱隔離服務匯流排應用程式以防止服務匯流排中斷和嚴重損壞。如需詳細資訊,請參閱服務匯流排 (災害復原)

關於 Azure 行動服務的可用性有兩項考量。首先,請定期備份與行動服務相關聯的 Azure SQL 資料庫。其次還要備份行動服務指令碼。如需詳細資訊,請參閱在發生災害時復原行動服務。萬一行動服務發生暫時性中斷,您可能就必須暫時使用替代的 Azure 資料中心。如需詳細資訊,請參閱行動服務 (災害復原)

與 HDInsight 相關聯的資料預設是儲存於 Azure Blob 儲存體,其具有由 Azure 儲存體所指定的高可用性與耐久性屬性。與 Hadoop MapReduce 作業相關聯的多重節點處理,是在 HDInsight 視需要所佈建的暫時性 Hadoop 分散式檔案系統 (HDFS) 上完成。由 MapReduce 作業產生的結果預設也是儲存於 Azure Blob 儲存體,故而處理過的資料在 Hadoop 叢集解除佈建之後仍具有耐久性且維持高可用性。如需詳細資訊,請參閱HDInsight (災害復原)

 

服務/領域 檢查清單

計算 (PaaS)

  • 為每個角色至少設定兩個執行個體。

  • 將狀態保存於耐久性儲存體,而非角色執行個體。

  • 正確地處理 StatusCheck 事件。

  • 盡可能將相關的變更包裝在交易中。

  • 確認背景工作角色的工作具有等冪性且能夠重新開始。

  • 持續叫用作業直到作業成功為止。

  • 考慮採取自動調整策略。

虛擬機器 (IaaS)

  • 請勿使用 D:磁碟機做為永續性儲存體。

  • 將服務層的電腦分組為可用性設定組。

  • 設定負載平衡以及選擇性探查。

儲存體

  • 當資料或頻寬超出配額時,使用多個儲存體帳戶。

SQL 資料庫

  • 實作重試原則以處理暫時性錯誤。

  • 使用資料分割/分區化做為向外延展策略。

虛擬機器上的 SQL Server 2014 (IaaS)

  • 遵照上述有關虛擬機器方面的建議。

  • 使用 SQL Server 高可用性功能,例如 AlwaysOn。

存取控制服務 (可用性)

  • 無須採取其他可用性步驟因應本機失敗。

服務匯流排 (可用性)

  • 考慮建立耐久的用戶端佇列以用於備份。

行動服務 (可用性)

  • 定期備份與行動服務相關聯的 Azure SQL 資料庫。

  • 備份行動服務指令碼。

HDInsight (可用性)

  • 無須採取其他可用性步驟因應本機失敗。

Azure 實際上與邏輯上劃分為稱為地區的單位。地區是由距離相近的一個或多個資料中心所組成。本文撰寫時,Azure 總共有八個地區 (4 個在北美洲、2 個在亞洲、2 個在歐洲)。

在罕見的情況下,整個地區內的設備可能會變成無法存取,例如由於網路失敗或因天然災害而徹底失聯。本節說明可供建立應用程式分散至各地區的 Azure 功能。地區的設計是要盡量降低某個地區的失敗可能影響到其他地區的機率。

要將計算執行個體分散至各地區,達成的方法是在每個目標地區建立個別的雲端服務,並且將部署封裝發行至每個雲端服務。不過請注意,將流量分散到不同地區的雲端服務這項工作必須由應用程式開發人員實作或憑藉流量管理服務。

事先研判應部署的備用角色執行個體數目以利於災害復原是容量規劃的一個重要環節。規模完整的次要部署可確保需要容量時隨取即用,但實際上也會使成本倍增。一般常見的模式是備妥剛好足以執行關鍵服務的小型次要部署。建議您至少建立一個小型次要部署,用於儲備容量同時測試次要環境的組態。

note附註
訂用帳戶配額不屬於容量保證項目。配額只算是信用額度限制。若要獲得容量保證,必須在服務模型中定義所需的角色數目,而且必須部署這些角色。

各地區的流量達成負載平衡需要藉助於流量管理方案。Azure 提供 Azure Traffic Manager。您也可以利用提供類似的流量管理功能的協力廠商服務。

目前已有多種替代策略可實作跨地區的分散式計算。這類策略必須視特定的業務需求及應用程式的情況量身訂製。概括而言,方法可分為 3 大類別:

  • 發生災害時重新部署:這種方法是在發生災害時從頭重新部署應用程式。其適用於不需要保證復原時間的非關鍵任務應用程式。

  • 暖備援 (主動/被動):在替代地區建立次要託管服務並部署角色,以保證最起碼的容量,但是各角色不接收生產流量。應用程式若尚未設計成要將流量分散到各地區,即適用這種方法。

  • 熱備援 (主動/主動):應用程式設計成接收多個地區的生產負載。每一個地區的雲端服務可能會設定為較高於 DR 用途所需的容量。或者,雲端服務可能在發生災害和進行容錯移轉時視需要向外延展。這種方法需要大幅投資於應用程式的設計,但其顯著的優點包括復原時間短又有保障、可連續測試所有復原位置,以及能夠有效運用容量。

關於分散式設計的完整討論已超出本文的範圍。下列文件針對這些案例提供了詳細的指引。

IaaS VM 的復原在許多方面與 PaaS 計算的復原相似,不過由於 IaaS VM 包括 VM 和 VM 磁碟,兩者間有著幾項重要的差異。

  • 使用 Blob 複製應用程式開發介面複製 VM 磁碟:為了要在多個地區建立 VM,必須將 VM 磁碟複製到替代地區。由於 VM 磁碟其實就是 Blob,使用標準 Blob 複製應用程式開發介面即可達此目的。

  • 將資料磁碟與作業系統磁碟隔開:IaaS VM 有一項重要的考量,即是若不重新建立 VM 就無法變更作業系統磁碟。如果您的復原策略是在發生災害後重新部署,這便不成問題。但是,若您使用暖備援方法儲備容量則可能會有問題。要確切實作這一點,必須將正確的作業系統磁碟部署至主要位置與次要位置,而且應用程式資料務必存放到另一部磁碟機。如果可行,請使用該兩處位置皆可獲提供的標準作業系統組態。在容錯移轉之後,您必須將資料磁碟機連接至次要 DC 內的現有 IaaS VM。使用 CopyBlob 應用程式開發介面,將資料磁碟的快照集複製到遠端站台。

  • 多個 VM 磁碟進行地理容錯移轉後的潛在一致性問題::VM 磁碟是實作成 Azure 儲存體 Blob,具有相同的地理複寫特性 (請參閱下文)。VM 磁碟保證在地理容錯移轉後處於損毀一致的狀態,但不保證各磁碟之間的一致性,因為地理複寫是以非同步且獨立的方式複寫。這在某些情況下 (例如使用磁碟條狀配置時) 可能會造成問題。如為這類情況,則進行地理容錯移轉後可能需要完成額外事項以還原一致性。為確保備份的正確性,請使用備份產品如 Data Protection Manager 備份及還原應用程式資料。

在 Azure 中,Blob、資料表、佇列和 VM 磁碟依預設都會進行地理複寫。這也稱為地理備援儲存體 (GRS)。GRS 是將儲存體資料複製到相距數百英哩位於特定地理區域內配對的資料中心。GRS 的設計是為了提供額外的耐久性,以防萬一發生重大的資料中心災害。Microsoft 會控制何時進行容錯移轉,而且容錯移轉受限於重大的災害,也就是原始主要位置被視為無法在合理的時間內復原。某些情況下,這段時間可能需要好幾天。資料通常會在幾分鐘內複寫,不過 SLA 尚未涵蓋同步處理間隔。

進行地理容錯移轉並不會變更存取帳戶的方式 (URL 和帳戶金鑰將維持不變),但是儲存體帳戶在容錯移轉過後會移至另一個地區,因而可能影響到需要與儲存體帳戶維繫同地區關係的應用程式。即便服務和應用程式未要求儲存體帳戶位於相同的資料中心,礙於跨資料中心延遲和頻寬費用的因素,暫時將流量遷往容錯移轉地區亦不失為明智之舉。整體災害復原策略或可將此納入考量。

除了 GRS 所提供的自動容錯移轉外,Azure 還引進了一種服務,可讓您讀取您在次要儲存體位置中的資料複本。這稱為讀取權限 - 地理備援儲存體 (RA-GRS)。

如需 GRS 和 RA-GRS 預覽的詳細資訊,請參閱 Azure 儲存體備援選項和讀取權限地理備援儲存體

您必須知道地理複寫會將資料複寫至何處,方能據以針對需要與儲存體維繫同地區關係的資料,將其他執行個體部署至對應的位置。下表顯示主要位置與次要位置配對:

 

主要 次要

美國中北部

美國中南部

美國中南部

美國中北部

美國東部

美國西部

美國西部

美國東部

北歐

西歐

西歐

北歐

東南亞

東亞

東亞

東南亞

中國東部

中國北部

中國北部

中國東部

巴西南部

美國中南部

地理複寫是包含在 Azure 儲存體的現行定價中,稱為地理備援儲存體。如果您不想讓資料進行地理複寫,則可為您的帳戶停用地理複寫。此即稱為本機備援儲存體,將以低於地理複寫儲存體的折扣價格收費。

地理容錯移轉一旦發生,將會公佈於 Azure 服務健全狀況儀表板。不過,應用程式可以藉著監視其儲存體帳戶的地理區域,實作自動化的偵測方法。這可用來觸發其他復原作業,例如啟動其儲存體遷往所在地理區域的計算資源。透過服務管理應用程式開發介面,使用取得儲存體帳戶屬性即可進行查詢。相關的屬性包括:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • 如同 VM 磁碟一節所討論,容錯移轉後無法保證各 VM 磁碟之間的資料一致性。為確保備份的正確性,請使用備份產品如 Data Protection Manager 備份及還原應用程式資料。

Azure Azure SQL 資料庫 的復原可利用基本、標準或高階層的「時間點還原」來達成。如需詳細資訊,請參閱 Azure SQL Database 備份和還原

除了使用「時間點還原」以外,您可以使用 Azure Azure SQL 資料庫 匯入/匯出服務,手動將資料庫匯出至 Azure 儲存體 Blob。您可以使用三種方法來實作:

  • 使用不同資料中心的儲存體帳戶,匯出至 Blob

  • 使用相同資料中心的儲存體帳戶匯出至 blob,並���仰賴 Azure 儲存體地理複寫來複製到不同的資料中心。

  • 匯入至您的內部部署 SQL Server。

如需實作詳細資料,請參閱 MSDN 文章:Azure SQL Database 的業務續航力

有兩個建議選項可將 IaaS 上執行的 SQL Server 資料庫還原至替代的 Azure 資料中心:使用儲存體 Blob 的跨區域 AlwaysOn 可用性群組或備份及還原。

您也可以使用資料庫鏡像,但 SQL Server 的未來版本將會移除這項功能。使用資料庫鏡像因應災害復原時,主體和鏡像伺服器必須執行於不同的 Azure 資料中心。這表示您必須使用伺服器憑證部署,因為 Active Directory 網域無法跨多個 Azure 資料中心,除非透過內部部署網路路由傳送流量。下圖說明其設定方式。

Windows Azure 中的資料庫鏡像 (DR)

下圖說明使用 Azure 儲存體 Blob 的標準備份及還原。

Windows Azure 中的 Backup to Blog

如需詳細資訊,請參閱 Azure 虛擬機器中的 SQL Server 高可用性和災害復原

當嘗試在多個 Azure 地區執行雲端服務時,您必須考量每一項相依性的隱含意義。下列各節提供服務專屬的指引,將假設您必須在替代的 Azure 資料中心內使用相同的 Azure 服務。這牽涉到組態和資料複寫工作。

請注意,在某些情況下,這些步驟有助於緩和特定服務中斷的後果,而不是整個資料中心發生的事件。就應用程式來說,特定服務發生中斷可能只是受拘限,並且需要暫時將服務移轉到替代的 Azure 地區。

存取控制服務 (ACS) 使用未跨越 Azure 地區的獨一無二命名空間名稱。ACS 2.0 每天會備份一次所有命名空間,並將其儲存在安全的異地位置。萬一發生災害,ACS 操作人員可能會使用最近的備份,嘗試復原客戶位於遠端 Azure 地區的訂用帳戶。由於備份頻率的緣故,可能會有多達 24 小時的資料遺失。地區容錯移轉沒有適用的 SLA,而且復原時間可能需要好幾天 (視案例而定)。

客戶若要在替代地區使用 ACS,必須在該地區設定 ACS 命名空間。建議凡是擔心資料可能遺失的 ACS 2.0 客戶都應檢閱 ACS 2.0 管理服務。此介面可讓管理員管理其命名空間以及匯入和擷取所有相關資料。透過使用此介面,ACS 客戶便能夠針對比 ACS 目前提供的資料一致性層級更高的層級來開發自訂備份與還原解決方案。如需其他可用性考量,請參閱存取控制服務 (可用性)

如同 ACS,服務匯流排也使用未跨越 Azure 地區的獨一無二命名空間。因此,首要需求便是在替代地區設定必要的服務匯流排命名空間。不過,關於佇列內訊息的耐久性另有一些考量。您可以採取幾種策略,跨越 Azure 地區複寫訊息。如需這些複寫策略和其他災害復原策略的詳細資訊,請參閱隔離服務匯流排應用程式以防止服務匯流排中斷和嚴重損壞。如需其他可用性考量,請參閱服務匯流排 (可用性)

若要將 Azure 網站移轉到次要 Azure 地區,您必須有該網站可供發行的備份。如果不是整個 Azure 資料中心全面中斷,也許可以使用 FTP 下載網站內容最近的備份。接著在替代地區建立新的網站,除非該處已有網站用於儲備容量。將網站發行至新的地區,並進行任何必要的組態變更。這類變更可能包括資料庫連接字串或其他地區性的特定設定。必要時,加入網站的 SSL 憑證並且變更 DNS CNAME 記錄,以將自訂網域名稱指向重新部署的 Azure 網站 URL。

在次要 Azure 地區,為應用程式建立備份行動服務。另外再將 Azure SQL 資料庫 還原至替代地區。接著使用 Azure 命令列工具,將行動服務移至替代地區。然後設定讓行動服務使用還原的資料庫。如需有關這項程序的詳細資訊,請參閱在發生災害時復原行動服務。如需其他可用性考量,請參閱行動服務 (可用性)

與 HDInsight 相關聯的資料預設是儲存於 Azure Blob 儲存體。HDInsight 要求 Hadoop 叢集處理 MapReduce 作業必須與包含所分析之資料的儲存體帳戶共置於相同的地區。如果您使用了 Azure 儲存體適用的地理複寫功能,一旦主要地區因故已經無法使用,屆時您就能夠存取複寫至次要地區的資料。您可以在資料複寫至該地區後於當地建立新的 Hadoop 叢集並繼續處理這些資料。如需其他可用性考量,請參閱HDInsight (可用性)

現階段若要從 Azure 地區耗損復原,您必須有多個 SQL Reporting 執行個體位於不同的 Azure 地區。這些 SQL Reporting 執行個體應該存取相同的資料,且該份資料應有其自身的復原方案以因應災害發生。您也可以保存每份報表 RDL 檔案的外部備份副本。

Azure 媒體服務的編碼及資料流處理各有不同的復原方法。一般而言,資料流處理在發生地區性中斷期間較為事關重大。為對此預做準備,您應在兩個不同的 Azure 地區各有一個媒體服務帳戶。這兩個地區都應存放編碼的內容。發生失敗期間,您可以將資料流處理流量重新導向至替代地區。任一個 Azure 地區都可以執行編碼處理。如果編碼處理有時間緊迫性,例如播報現場活動實況,您就必須備妥在發生失敗期間提交工作至替代資料中心。

組態檔提供最快速的方法讓您可在替代的 Azure 地區設定虛擬網路。在主要 Azure 地區內設定虛擬網路之後,匯出目前網路的虛擬網路設定至網路組態檔。一旦主要地區發生中斷情況,即從預存的組態檔還原虛擬網路。接著設定其他雲端服務、虛擬機器或跨單位設定以搭配新的虛擬網路使用。

 

服務/領域 檢查清單

計算 (PaaS)

  • 擬定跨地區災害復原策略。

  • 了解在替代地區儲備容量的權衡取捨。

  • 使用流量路由工具,例如 Azure Traffic Manager (CTP)。

虛擬機器 (IaaS)

  • 將 Blob VM 磁碟資源複製到替代資料中心。

  • 執行 VM 磁碟或磁碟內容的定期備份。

儲存體

  • 切勿停用儲存體資源的地理複寫。

  • 了解容錯移轉發生時進行地理複寫的替代地區。

  • 針對由使用者控制的容錯移轉策略,建立自訂備份策略。

SQL Database (災害復原)

  • 使用 Azure SQL 資料庫 時間點還原。

  • 將 Azure SQL 資料庫 匯出至 Blob 儲存體。

  • 根據前述有關儲存體方面的考量,建立災害復原方案。

虛擬機器上的 SQL Server (災害復原)

  • 使用跨地區 AlwaysOn 可用性群組或資料庫鏡像。

  • 交替使用備份及還原至 Blob 儲存體。

存取控制服務 (災害復原)

  • 在替代地區設定 ACS 命名空間。

  • 使用 ACS 2.0 管理服務建立自訂備份解決方案。

服務匯流排 (災害復原)

  • 在替代地區設定服務匯流排命名空間。

  • 考量自訂的跨地區訊息複寫策略。

網站 (災害復原)

  • 在主要地區外部保存網站備份。

  • 若是發生局部性中斷,則嘗試透過 FTP 擷取目前的網站。

  • 規劃將網站部署至替代地區內現有或新的網站。

  • 規劃應用程式與 DNS CNAME 記錄兩方面的組態變更。

行動服務 (災害復原)

  • 在替代地區建立備份行動服務。

  • 管理相關聯 Azure SQL 資料庫 的備份以供容錯移轉期間進行還原。

  • 使用 Azure 命令列工具遷移行動服務。

HDInsight (災害復原)

  • 在已有複寫之資料的地區建立新的 Hadoop 叢集。

SQL Reporting (災害復原)

  • 在另一個地區維護替代的 SQL Reporting 執行個體。

  • 維護單獨的計畫專供將目標複寫至該地區。

媒體服務 (災害復原)

  • 在替代地區建立媒體服務帳戶。

  • 在兩處地區對相同的內容進行編碼以便支援資料流容錯移轉。

  • 發生中斷情���時,提交編碼工作至替代地區。

虛擬網路 (災害復原)

  • 使用匯出的虛擬網路設定,在另一個地區重新建立虛擬網路。

Azure 提供一套完整的服務,可讓您將內部部署資料中心延伸至 Azure 以實現高可用性和災害復原:

  • 網路:透過虛擬私人網路,安全地將內部部署網路延伸至雲端。

  • 計算::使用內部部署 Hyper-V 的客戶可將其現有的 VM「隨取即遷移」至 Azure。

  • 儲存體:StorSimple 可將檔案系統延伸至 Azure 儲存體。Azure 備份服務提供將檔案和 Azure SQL 資料庫 備份到 Azure 儲存體的功能。

  • 資料庫複寫:透過 SQL 2014 可用性群組,可針對內部部署資料實作高可用性和災害復原。

Azure 虛擬網路可讓您在 Azure 中建立邏輯上隔離的區段,然後利用 IPsec 連接安全地將此區段連接到內部部署資料中心或單一用戶端電腦。虛擬網路既方便您運用 Azure 可擴充的隨選基礎結構,也提供了連接至內部部署資料和應用程式的能力,包括 Windows Server、大型主機及 UNIX 上執行的系統。如需詳細資訊,請參閱此處

使用內部部署 Hyper-V 的客戶可將其現有的 VM「隨取即遷移」至 Azure 以及執行 Windows Server 2012 的服務提供者,而不需要對 VM 進行變更或轉換 VM 格式。如需詳細資訊,請參閱管理磁碟及映像

您可以從數個選項擇其一,使用 Azure 做為內部部署資���的備份站台。

StorSimple 會安全地以透明的方式整合內部部署應用程式的雲端儲存體,並且提供 單一應用裝置賦予高效能分層式本機和雲端儲存體、即時封存、雲端型資料保護與災害復原。如需詳細資訊,請參閱 StorSimple -- 雲端整合式儲存 -- 說明及用途

Azure 備份服務可讓您利用 Windows Server 2012、Windows Server 2012 Essentials 及 System Center 2012 Data Protection Manager 中熟悉的備份工具,在雲端進行備份。這些工具提供了與備份的儲存位置無關的備份管理工作流程,無論是本機磁碟或 Azure 儲存體皆適用。當資料備份到雲端之後,授權的使用者可以輕鬆地將備份復原到任何伺服器。

之後進行增量備份時,只有變更的檔案才會傳輸到雲端,如此可確保有效使用儲存體空間、降低頻寬耗用,並支援多個資料版本的時間點復原。您也可以選擇使用其他功能,例如資料保留原則、資料壓縮和資料傳輸節流處理。使用 Azure 做為備份位置最明顯的優點就是自動「異地」備份。這樣便不需要額外顧慮現場備份媒體的安全防護。如需詳細資訊,請參閱 Azure Backup 概觀搭配 Azure 備份使用 DPM

您可以使用 AlwaysOn 可用性群組、資料庫鏡像、記錄傳送,以及透過 Azure Blob 儲存體備份及還原,在混合式 IT 環境中為 SQL Server 資料庫實作災害復原方案。所有這些方案都是使用 Azure 虛擬機器上執行的 SQL Server。

AlwaysOn 可用性群組可用於內部部署和雲端兩側都有資料庫複本的混合式 IT 環境。其情形如下圖所示,此圖表是摘錄自 Azure 虛擬機器中的 SQL Server 高可用性和災害復原這篇主題深入探討文章。

混合式 IT 中的 AlwaysOn 可用性群組

採用以憑證為基礎的設定時,資料庫鏡像也能橫跨內部部署伺服器和雲端。下圖說明其概念。

混合式 IT 中的資料庫鏡像

記錄傳送可用於同步處理內部部署資料庫與 Azure 虛擬機器中的 SQL Server 資料庫。

混合式 IT 中的記錄傳送

最後,您可以直接將內部部署資料庫備份到 Azure Blob 儲存體。

混合式 IT 中的 Backup to Blog

如需詳細資訊,請參閱 Azure 虛擬機器中的 SQL Server 高可用性和災害復原Azure 虛擬機器中的 SQL Server 備份和還原

 

服務/領域 檢查清單

網路

  • 使用虛擬網路安全地將內部部署連接至雲端。

運算

  • 在 Hyper-V 和 Azure 之間重新放置 VM。

儲存體

  • 利用 StorSimple 服務以使用雲端儲存體。

  • 使用 Azure 備份服務���

資料庫

  • 考慮在 Azure VM 上使用 SQL Server 當做備份。

  • 設定 AlwaysOn 可用性群組。

  • 設定以憑證為基礎的資料庫鏡像。

  • 使用記錄傳送。

  • 將內部部署資料庫備份到 Azure Blob 儲存體。

本節討論由於應用程式錯誤或操作員失誤造成資料損毀或不慎刪除時的復原案例。

請注意,雖然 Azure 儲存體會透過自動化複本提供資料恢復功能,這並不會防止您的應用程式程式碼 (或開發人員/使用者) 因為意外或不小心的刪除、更新等作業而損毀資料。在遇到應用程式或使用者錯誤時維護資料精確度需要更進階的技術,例如使用稽核記錄在次要儲存體位置複製資料。開發人員可以利用 Blob 快照集功能,建立 Blob 內容的唯讀時間點快照集。這類快照集可以當做 Blob 資料精確度解決方案的基礎。

雖然 Blob 和資料表都很持久,但是它們總是代表資料的目前狀態。從不必要的資料修改或刪除復原時,可能需要將資料還原到先前的狀態。您���以充分利用 Azure 所提供的功能來儲存和保留時間點複本,以達成這個目標。

如果是 Azure Blob,您可以使用 blob 快照集功能來執行時間點備份。對於每個快照集,您只需要針對上一個快照集狀態之後將差異儲存在 blob 中所需的儲存體付費。快照集取決於它們所依據的原始 blob 是否存在,因此,建議採取複製到另一個 blob 或甚至另一個儲存體帳戶的作業,以確保備份資料有受到適當的保護,不會遭到意外刪除。若為 Azure 資料表,您可以針對不同的資料表或 Azure Blob 製作時間點複本。您可以在這裡找到針對資料表和 blob 執行應用程式層級備份的詳細指導方針與範例:

Azure SQL 資料庫 有幾個業務續航力 (備份、還原) 選項可以使用。透過資料庫複製功能或 DAC 匯入/匯出服務可複製資料庫。資料庫複製會提供交易一致的結果,但是 bacpac (透過匯入/匯出服務) 則不會。這兩個選項都是以資料中心內的佇列型服務形式執行,而目前尚未提供完成時間 SLA。

note附註
請注意,資料庫複製和匯入/匯出服務對於來源資料庫會有極大的負載,而且可能觸發資源競爭或節流事件 (底下的<共用資源和節流>一節會加以描述)。

Microsoft Azure SQL Database 的時間點備份是使用 Azure SQL Database 複製命令來完成。您可以使用這個命令,在相同的邏輯資料庫伺服器或不同的伺服器上建立交易一致的資料庫複本。在任何一種情況下,資料庫複本都具有完整的功能,而且與來源資料庫之間完全獨立。您建立的每個複本都代表一個時間點復原選項。您可以將新的資料庫重新命名為來源資料庫名稱,藉以完全復原資料庫狀態。或者,您也可以使用 Transact-SQL 查詢,從新的資料庫復原特定資料子集。如需有關 SQL Database 的其他詳細資料,請參閱 Azure SQL Database 的業務續航力

IaaS 形式的 SQL Server 有兩個選項:傳統備份和記錄傳送。使用傳統備份可讓您還原到特定的時間點,但是復原過程緩慢。還原傳統備份需要從最初的完整備份開始著手,再套用該次備份後所建立的任何備份。第二個選項是設定記錄傳送工作階段,將記錄備份的還原延後 (例如,延後兩小時)。這樣就有了緩衝��可從主要資料庫發生錯誤的情況下復原。

某些 Azure 平台服務會將資訊儲存在使用者所控制的儲存體帳戶或 Azure SQL 資料庫 中。如果帳戶或儲存體資源遭到刪除或損毀,將可能造成服務發生嚴重錯誤。基於此,請務必維護備份以讓您可在這些資源遭到刪除或損毀時重新建立。

對於 Azure 網站和 Azure 行動服務,您必須備份及維護相關聯的資料庫。對於 Azure 媒體服務和虛擬機器,您必須維護相關聯的 Azure 儲存體帳戶和該帳戶中的所有資源。例如,就虛擬機器而言,必須備份和管理 Azure Blob 儲存體中的 VM 磁碟。

 

服務/領域 檢查清單

儲存體

  • 定期備份重要的儲存體資源。

  • 考慮使用 Blob 的快照集功能。

資料庫

  • 使用資料庫複製命令建立時間點備份。

虛擬機器上的 SQL Server 備份 (IaaS)

  • 使用傳統備份和還原技術。

  • 建立延後的記錄傳送工作階段。

網站

  • 備份及維護相關聯的資料庫 (如果有)。

行動服務

  • 備份及維護相關聯的資料庫。

媒體服務

  • 備份及維護相關聯的儲存體資源。

虛擬機器

  • 備份及維護 Blob 儲存體中的 VM 磁碟。

Failsafe:具有恢復功能的雲端架構指引:提供建置具恢復功能雲端架構的指引、採用 Microsoft 技術實作這些架構的指引,以及針對特定案例實作這些架構的訣竅。

Azure 應用程式災害復原與高可用性:提供可用性和災害復原的詳細概觀。內文涵蓋手動複寫參考資料和交易資料所面臨的挑戰。最後幾個章節摘要說明不同類型跨 Azure 資料中心賦予最高層級可用性的 DR 拓撲。

Azure SQL Database 的業務續航力:專門著重在 Azure Azure SQL 資料庫 涉及可用性的技術,主要集中討論備份與還原策略。如果您的雲端服務使用 Azure SQL 資料庫,您即應檢閱這份文件及其相關資源。

Azure 虛擬機器中的 SQL Server 高可用性和災害復原:討論使用基礎結構代管服務 (IaaS) 託管資料庫服務時的各種可用性選項。文中討論 AlwaysOn 可用性群組、資料庫鏡像、記錄傳送和備份/還原。請注意,在示範如何運用這些技術的相應章節內另有幾個教學課程。

Azure 雲端服務中大規模服務設計的最佳作法:著重於開發可高度擴充的雲端架構。多數有助於提升延展性的技術也能夠提高可用性。此外,如果您的應用程式在負載增加時無法擴充延展,延展性就會變成可用性問題。

Azure 虛擬機器中的 SQL Server 備份和還原

顯示:
© 2015 Microsoft