共用方式為

Azure 儲存體災害復原規劃與容錯移轉

  • 發行項

Microsoft 致力於確保 Azure 服務皆能持續可用。 不過，偶爾還是有可能會發生非計劃性服務中斷。 良好災害復原方案的主要部分包括下列策略：

本文說明異地備援記憶體帳戶可用的選項，並提供開發高可用性應用程式和測試災害復原計劃的建議。

選擇正確的備援選項

Azure 儲存體會維護儲存體帳戶的多個複本，以確保即使遇到失敗，也能達成可用性和持久性目標。 不同的資料複寫方式提供不同層級的保護。 每個選項都有各自的優點，因此選擇哪個選項會視應用程式所需的復原程度而定。

本地備援儲存體 (LRS) 是成本最低的備援選項，會自動將儲存體帳戶的三個複本儲存並複寫至單一資料中心。 雖然 LRS 可在伺服器機架和磁碟機故障時保護您的資料，但資料中心內發生的火災或水災等災害則不在考量範圍內。 如果遇到這類災害，已設定使用 LRS 的所有儲存體帳戶複本可能會遺失或無法復原。

相較之下，區域備援儲存體 (ZRS) 會保留一個儲存體帳戶複本，並將其複寫至相同區域內三個不同的可用性區域。 如需可用性區域的詳細資訊，請參閱 Azure 可用性區域。

異地備援儲存體和容錯移轉

異地備援記憶體（GRS）、異地區域備援記憶體（GZRS）和讀取許可權異地區域備援記憶體（RA-GZRS）是異地備援記憶體選項的範例。 設定為使用異地備援記憶體 （GRS、GZRS 和RA-GZRS），Azure 會以異步方式將數據複製到次要地理區域。 這些區域位於數百英哩甚至數千英哩之外。 如果整個主要區域發生中斷，此層級的備援可讓您復原資料。

不同於 LRS 和 ZRS，如果主要區域發生中斷，異地備援記憶體也支援非計劃性故障轉移至次要區域。 在容錯移轉過程中，儲存體帳戶服務端點的 DNS (網域名稱系統) 項目會自動更新，使次要區域的端點成為新的主要端點。 非計劃性容錯移轉完成後，用戶端便可以開始寫入到新的主要端點。

讀取權限異地備援儲存體 (RA-GRS) 和讀取權限異地區域備援儲存體 (RA-GZRS) 也提供異地備援儲存體，但提供讀取次要端點的額外優點。 這些選項適用於專為高可用性業務關鍵應用所設計的應用程式。 如果主要端點發生中斷，為讀取次要區域所設定的應用程式可以繼續運作。 Microsoft 建議使用 RA-GZRS，以達到儲存體帳戶的最大可用性和持久性。

如需 Azure 儲存體中備援功能的詳細資訊，請參閱 Azure 儲存體備援。

規劃容錯移轉

Azure 儲存體帳戶支援三種類型的容錯移轉：

1 無法針對個別儲存體帳戶、訂用帳戶或租用戶起始 Microsoft 管理的容錯移轉。 如需詳細資訊，請參閱 Microsoft 管理的容錯移轉。
2 您可以使用客戶自控的容錯移轉選項來開發、測試及實作災害復原方案。 請勿依賴 Microsoft 管理的容錯移轉，這只會在極端情況下使用。

每種故障轉移類型都有一組唯一的使用案例、對數據遺失的對應期望，以及啟用階層命名空間的帳戶支援（Azure Data Lake Storage）。 下表摘要說明每種容錯移轉類型的這些層面：

類型 容錯移轉範圍 使用案例 預期的資料遺失 支援階層命名空間 (HNS)
客戶自控的計劃性容錯移轉 (預覽) 儲存體帳戶 主要區域和次要區域的儲存體服務端點可供使用，而且您想要執行災害復原測試。

主要區域的儲存體服務端點可供使用，但其他服務使您的工作負載無法正常運作。

主動準備大規模災害，例如可能影響區域的颶風。		 否 是
(處於預覽狀態)
客戶自控的 (非計劃性) 容錯移轉 儲存體帳戶 主要區域的儲存體服務端點變得無法使用，但次要區域可供使用。

您收到 Azure Advisory，Microsoft 建議您針對可能受中斷影響的儲存體帳戶執行容錯移轉作業。		 是 是
(處於預覽狀態)
Microsoft 管理的 整個區域 主要區域因為發生重大災害而變得無法使用，但次要區域可供使用。 是 是

下表比較每種容錯移轉類型之後的儲存體帳戶備援狀態：

下列項目的容錯轉移結果... 客戶自控的計劃性容錯移轉 (預覽) 客戶自控的 (非計劃性) 容錯移轉
...次要區域 次要區域會變成新主要區域 次要區域會變成新主要區域
...原始主要區域 原始主要區域成為新的次要區域 刪除原始主要區域的資料複本
...帳戶備援設定 儲存體帳戶轉換成 GRS 儲存體帳戶已轉換為 LRS
...異地備援設定 保留異地備援 遺失異地備援

下表摘要說明每種容錯移轉類型在容錯移轉和容錯回復程序的每個階段所產生的備援設定：

原始
組態		 After
failover		 重新啟用後
異地備援		 After
容錯回復		 重新啟用後
異地備援
客戶自控的計劃性容錯移轉
GRS GRS n/a 1 GRS n/a 1
GZRS GRS n/a 1 GZRS n/a 1
客戶自控的 (非計劃性) 容錯移轉
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 異地備援會在計劃性容錯移轉期間保留，不需要手動重新設定。

客戶自控的計劃性容錯移轉 (預覽)

計劃性故障轉移可用於多個案例，包括計劃性災害復原測試、大規模災害的主動式方法，或從非記憶體相關中斷中復原。

在計劃性容錯移轉過程中，主要區域和次要區域會互換。 原始主要區域會降級並成為新的次要區域。 同時，原始次要區域會升級並成為新的主要區域。 容錯移轉完成後，使用者可以繼續在新的主要區域中存取資料，而系統管理員可以驗證其災害復原方案。 主要區域和次要區域中都必須有儲存體帳戶，才能起始計劃性容錯移轉。

只要主要區域和次要區域在整個流程中都可供使用，預期就不會在計劃性容錯移轉和容錯回復流程中遺失資料。 如需更多詳細資料，請參閱預期資料遺失和不一致一節 (部分機器翻譯)。

若要了解這種容錯移轉類型對您的使用者和應用程式的影響，了解計劃性容錯移轉和容錯回復流程的每個步驟中發生什麼事會很有幫助。 如需此流程運作方式的詳細資料，請參閱客戶自控的 (計劃性) 容錯移轉如何運作。

重要

客戶自控的計劃性容錯移轉目前處於預覽狀態，且僅限於下列區域：

  • 法國中部
  • 法國南部
  • 印度中部
  • 印度西部
  • 東亞
  • 東南亞

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

重要

計劃性容錯移轉之後，儲存體帳戶的 [上次同步時間 (LST)] 值可能看起來過時，或在 Azure 檔案儲存體資料存在時回報為 NULL。

系統快照集會定期在儲存體帳戶的次要區域中建立，以在容錯移轉和容錯回復期間維持使用一致的復原點。 起始客戶自控的計劃性容錯移轉會導致原始主要區域成為新的次要區域。 在某些情況下，計劃性容錯移轉完成後新的次要區域沒有系統快照集可用，導致帳戶的整體 LST 值看起來過時或顯示為 Null。

由於建立、修改或刪除物件等使用者活動可觸發建立快照集，因此在計劃性容錯移轉之後發生這些活動的任何帳戶都不需要額外的注意。 不過，沒有快照集或使用者活動的帳戶可能會繼續顯示 Null LST 值，直到觸發建立系統快照集為止。

如有必要，請針對儲存體帳戶內的每個共用執行下列其中一個活動，以觸發建立快照集。 完成時，您的帳戶應該會在 30 分鐘內顯示有效的 LST 值。

  • 掛接共用，然後開啟任何檔案以供讀取。
  • 將測試或範例檔案上傳至共用。

客戶自控的 (非計劃性) 容錯移轉

如果儲存體帳戶中儲存體服務的資料端點在主要區域中變得無法使用，您可以起始非計劃性容錯移轉至次要區域。 容錯移轉完成後，次要區域會成為新的主要區域，而且使用者可以繼續存取其中的資料。

若要了解這種容錯移轉類型對您的使用者和應用程式的影響，了解非計劃性容錯移轉和容錯回復程序的每個步驟中發生什麼事會很有幫助。 如需此程序運作方式的詳細資料，請參閱客戶自控的 (非計劃性) 容錯移轉如何運作。

Microsoft 管理的容錯移轉

Microsoft可能會在極端情況下起始區域故障轉移，例如影響整個地理區域的災難性災害。 在這些事件期間，您不需要採取任何行動。 如果您的儲存體帳戶已設定 RA-GRS 或 RA-GZRS，則應用程式可以在 Microsoft 管理的容錯移轉期間從次要區域進行讀取。 不過，在容錯移轉程序完成之前，您不會有儲存體帳戶的寫入權限。

重要

您可以使用客戶自控的容錯移轉選項來開發、測試及實作災害復原方案。 請勿依賴 Microsoft 管理的容錯移轉，這可能只會在極端情況下使用。 Microsoft 管理的容錯移轉會針對整個實體單元起始，例如區域或資料中心。 無法針對個別儲存體帳戶、訂用帳戶或租用戶起始。 如果您需要選擇性地容錯移轉個別儲存體帳戶的功能，請使用客戶自控的計劃性容錯移轉。

預期資料遺失和不一致

警告

客戶自控的非計劃性容錯移轉通常會遺失一些資料，而且也可能造成檔案和資料不一致。 在災害復原方案中，請務必考慮帳戶容錯移轉對資料產生的影響，然後再起始容錯移轉。

由於資料會以非同步方式從主要區域寫入次要區域，因此在主要區域的寫入資料複製到次要之前一定會有延遲。 如果主要區域變得無法使用，則最新的寫入資料可能尚未複製到次要區域。

發生非計劃性容錯移轉時，主要區域中的所有資料都會遺失，因為次要區域會成為新的主要區域。 發生容錯移轉時，已複製到次要區域的所有資料都會保持不變。 不過，任何已寫入主要區域但尚未存在於次要區域的資料都會永久遺失。

新的主要區域已在容錯移轉之後設定為本地備援 (LRS)。

如果您的儲存體帳戶已啟用下列一或多個項目，您也可能遇到檔案或資料不一致的情況：

上次同步處理時間

[上次同步時間] 屬性表示來自主要區域的資料也已寫入次要區域的最近時間。 對於具有階層命名空間的帳戶，相同的 [上次同步時間] 屬性也適用於階層命名空間所管理的中繼資料，包括存取控制清單 (ACL)。 在上次同步時間之前寫入的所有資料和中繼資料可在次要區域中使用。 相較之下，在上次同步處理時間之後寫入的資料和中繼資料可能尚未複製到次要區域，因此可能會遺失。 在中斷期間，請使用此屬性來估計起始帳戶容錯移轉時可能會導致的資料遺失量。

作為最佳做法，請將應用程式設計成可以使用 [上次同步時間] 來評估預期的資料遺失。 例如，記錄所有寫入作業可讓您比較上次寫入作業時間與上次同步時間。 這個方法可讓您判斷哪些寫入尚未同步至次要區域，而有遺失的危險。

如需檢查上次同步時間屬性的詳細資訊，請參閱檢查儲存體帳戶的上次同步時間屬性。

Azure Data Lake Storage 的檔案一致性

已啟用階層命名空間的記憶體帳戶 複寫會在 檔案層級發生。 由於複寫是在這個層級上進行，因此主要區域發生中斷可能會導致容器或目錄中的某些檔案無法成功複寫至次要區域。 不保證儲存體帳戶容錯移轉之後容器或目錄中所有檔案的一致性。

變更摘要和 Blob 資料不一致

已啟用變更摘要之儲存體帳戶的客戶自控 (非計劃性) 容錯移轉可能會導致變更摘要記錄與 Blob 資料和/或中繼資料之間不一致。 這類不一致可能是由於變更記錄更新的非同步本質，以及主要區域和次要區域之間的資料複寫所造成。 您可以採取下列預防措施，避免發生不一致的情況：

  • 確定所有記錄都已排清至記錄檔。
  • 確定所有儲存體資料都已從主要區域複寫至次要區域。

如需變更摘要的詳細資訊，請參閱變更摘要的運作方式。

請記住，還有其他儲存體帳戶功能需要啟用變更摘要。 這些功能包括 Azure Blob 儲存體的作業備份、物件複寫，以及區塊 Blob 的時間點還原。

時間點還原不一致

針對包含區塊 Blob 的一般用途 v2 標準層儲存體帳戶，支援客戶管理的容錯移轉。 不過，若在儲存體帳戶上執行客戶管理的容錯移轉，將會重設帳戶最早的可能還原點。 區塊 Blob 的時間點還原資料只會與容錯移轉完成時間一致。 因此，您只能將區塊 Blob 還原到不早於容錯移轉完成時間的時間點。 您可以在 Azure 入口網站中儲存體帳戶的 [備援] 索引標籤上查看容錯移轉完成時間。

容錯移轉的時間和成本

客戶自控的容錯移轉起始後到完成所需的時間可能不同，但通常不到一小時。

客戶自控的計劃性容錯移轉不會在容錯移轉和後續容錯回復之後失去其異地備援，但客戶自控的非計劃性容錯移轉則會失去其異地備援。

起始客戶自控的非計劃性容錯移轉會將儲存體帳戶自動轉換成新主要區域中的本地備援儲存體 (LRS)，並會刪除原始主要區域中的儲存體帳戶。

您可以為帳戶重新啟用異地備援儲存體 (GRS) 或讀取權限異地備援儲存體 (RA-GRS)，但將資料重新複寫至新的次要區域會產生費用。 此外，任何封存的 Blob 都必須解除凍結至連線層，才能重新設定帳戶的異地備援。 這種解除凍結也會產生額外費用。 如需定價的詳細資訊，請參閱：

為您的儲存體帳戶重新啟用 GRS 之後，Microsoft 會開始將您帳戶中的資料複寫到新的次要區域。 複寫完成所需的時間取決於幾個因素。 這些因素包括：

  • 儲存體帳戶中的物件數目和大小。 複寫許多小型物件所需的時間比複寫較少且較大的對象還要長。
  • 背景複寫的可用資源，例如 CPU、記憶體、磁碟和 WAN 容量。 即時流量的優先權高於異地複寫。
  • 每個 Blob 的快照集數目 (如果適用)。
  • 資料分割策略 (如果您的儲存體帳戶包含資料表)。 複寫程序在擴充時不能超過您所使用的分割區索引鍵數目。

支援的儲存體帳戶類型

所有異地備援供應項目都支援 Microsoft 管理的容錯移轉。 此外，某些帳戶類型支援客戶管理的帳戶容錯移轉，如下表所示：

容錯移轉的類型 GRS/RA-GRS GZRS/RA-GZRS
客戶自控的計劃性容錯移轉 (預覽) 一般用途 v2 帳戶
一般用途 v1 帳戶
舊版 Blob 儲存體帳戶		 一般用途 v2 帳戶
客戶自控的 (非計劃性) 容錯移轉 一般用途 v2 帳戶
一般用途 v1 帳戶
舊版 Blob 儲存體帳戶		 一般用途 v2 帳戶
Microsoft 管理的容錯移轉 所有帳戶類型 一般用途 v2 帳戶

傳統儲存體帳戶

重要

只有使用 Azure Resource Manager (ARM) 部署模型部署的儲存體帳戶才支援客戶自控的容錯移轉。 不支援 Azure Service Manager (ASM) 部署模型，也稱為「傳統」模型。 若要讓傳統儲存體帳戶符合客戶管理的帳戶容錯移轉資格，則必須先移轉至 ARM 模型。 您必須能夠存取儲存體帳戶才能執行升級，因此主要區域目前無法處於失敗狀態。

在影響主要區域的災害期間，Microsoft 會管理傳統儲存體帳戶的容錯移轉。 如需詳細資訊，請參閱 Microsoft 管理的容錯移轉。

階層命名空間 (HNS)

重要

已啟用 Azure Data Lake Storage Gen2 之帳戶的客戶管理（非計劃性）故障轉移目前處於預覽狀態，且在所有公用 GRS/GZRS 區域中都受到支援。

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

重要

已啟用 SSH 檔案傳輸通訊協定 (SFTP) 之帳戶的客戶自控 (非計劃性) 容錯移轉目前處於預覽狀態，且僅在下列區域中受到支援：

  • (亞太地區) 印度中部
  • (亞太地區) 東南亞
  • (歐洲) 歐洲北部
  • (歐洲) 瑞士北部
  • (歐洲) 瑞士西部
  • (歐洲) 西歐
  • (北美洲) 加拿大中部
  • (北美洲) 美國東部 2
  • (北美洲) 美國中南部

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

若發生影響主要區域的重大災害，Microsoft 會針對具有階層命名空間的帳戶管理容錯移轉。 如需詳細資訊，請參閱 Microsoft 管理的容錯移轉。

不支援的功能和服務

客戶自控的容錯移轉不支援下列功能和服務：

  • Azure 檔案同步不支援客戶自控的帳戶容錯移轉。 不應該容錯移轉 Azure 檔案同步中作為雲端端點的儲存體帳戶。 容錯移轉會中斷檔案同步，並可能導致新分層的檔案意外遺失資料。 如需詳細資訊，請參閱 Azure 檔案同步災害復原的最佳做法。
  • 無法容錯移轉包含進階區塊 Blob 的儲存體帳戶。 支援進階區塊 Blob 的儲存體帳戶目前不支援異地備援。
  • 物件複寫原則中的來源或目的地帳戶皆不支援客戶管理的容錯移轉。
  • 儲存體帳戶容錯移轉不支援網路檔案系統 (NFS) 3.0 (NFSv3)。 您無法建立針對已啟用 NFSv3 的異地備援設定的記憶體帳戶。

下表可用來參考功能支援。

計劃性容錯移轉 未規劃的容錯移轉
Azure Data Lake 儲存體 支援 (預覽) 支援 (預覽)
變更摘要 不支援 支援
物件複寫 不支援 不支援
SFTP 支援 (預覽) 支援 (預覽)
NFSv3 不支援 GRS 不支援 GRS
儲存體動作 受支援1 受支援1
還原時間點 (PITR) 不支援 支援

1 如果您起始客戶管理的已規劃或非計劃性故障轉移，在帳戶容錯回復到原始主要區域之前，記憶體工作將無法在帳戶上運作。 深入了解。

容錯移轉不適用於帳戶移轉

記憶體帳戶故障轉移是用來開發和測試災害復原 （DR） 計劃的暫時解決方案，或用來從服務中斷中復原。 容錯移轉不應作為資料移轉策略的一部分。 如需如何移轉儲存體帳戶的資訊，請參閱 Azure 儲存體移轉概觀。

包含封存 Blob 的儲存體帳戶

包含封存 blob 的儲存體帳戶支援帳戶容錯移轉。 不過，客戶自控的容錯移轉完成後，必須先將所有封存的 Blob 解除凍結至連線層，才能設定帳戶的異地備援。

儲存體資源提供者

Microsoft 提供兩個 REST API 來處理 Azure 儲存體資源。 這些 API 構成您可以對 Azure 儲存體執行的所有動作基礎。 Azure 儲存體 REST API 可讓您使用儲存體帳戶中的資料，包括 Blob、佇列、檔案和資料表資料。 Azure 儲存體資源提供者 REST API 可讓您管理儲存體帳戶和相關資源。

故障轉移完成後，用戶端可以再次讀取和寫入新主要區域中 Azure 儲存體 數據。 不過，Azure 儲存體 資源提供者不會故障轉移，因此資源管理作業仍必須在主要區域中進行。 如果主要區域無法使用，您將無法在記憶體帳戶上執行管理作業。

因為 Azure 儲存體 資源提供者不會故障轉移，因此Location屬性會在故障轉移完成之後傳回原始的主要位置。

Azure 虛擬機器

Azure 虛擬機器 (VM) 不會隨著儲存體帳戶容錯移轉一起容錯移轉。 容錯移轉完成後，必須重新建立任何容錯移轉至次要區域的 VM 以回應中斷。 當虛擬機器 (VM) 關機時，帳戶容錯移轉可能會導致儲存在暫存磁碟中的資料遺失。 Microsoft 建議您遵循 Azure 中虛擬機器專用的下列高可用性和災害復原指導。

Azure 非受控磁碟

非受控磁碟會以分頁 Blob 的形式儲存在 Azure 儲存體中。 當 VM 在 Azure 中執行時，附加至該 VM 的所有非受控磁碟都會被租用。 帳戶容錯移轉無法在 Blob 上存在租用的情況下繼續進行。 在包含連結至 Azure VM 之非受控磁碟的帳戶上起始容錯移轉之前，必須先關閉磁碟。 因此，Microsoft 建議的最佳做法包括將任何非受控磁碟轉換成受控磁碟。

若要在包含非受控磁碟的帳戶上執行容錯移轉，請按照下列步驟進行：

  1. 在開始前，請記下所有非受控磁碟的名稱、其邏輯單元編號 (LUN)，以及其所附加至的 VM。 這麼做將會使於容錯移轉後重新附加磁碟的工作變得較為輕鬆。
  2. 關閉 VM。
  3. 刪除 VM，但保留非受控磁碟的虛擬硬碟 (VHD) 檔案。 請記下您刪除 VM 的時間。
  4. 等候 [上次同步時間] 更新，並確定這是比您刪除 VM 更晚的時間。 此步驟可確保在發生容錯移轉時，次要端點會使用 VHD 檔案完整更新，且 VM 會在新的主要區域中正常運作。
  5. 起始帳戶容錯移轉。
  6. 等候帳戶容錯移轉完成，且次要區域成為新的主要區域。
  7. 在新的主要區域中建立 VM，並重新附加 VHD。
  8. 啟動新的 VM。

請記住，在 VM 關閉時，儲存在暫時磁碟中的所有資料都會遺失。

複製資料作為容錯移轉替代方案

如前所述，您可以藉由設定應用程式使用為讀取次要區域所設定的儲存體帳戶，來維護高可用性。 不過，如果您不想在主要區域發生中斷期間進行容錯移轉，您可以手動複製資料作為替代方案。 AzCopy 和 Azure PowerShell 等工具可讓您將來自受影響區域中儲存體帳戶的資料，複製到未受影響區域中的其他儲存體帳戶。 複製作業完成後，您可以重新設定應用程式使用未受影響區域中的儲存體帳戶，以取得讀取和寫入可用性。

高可用性設計

您應該從一開始便針對高可用性來設計您的應用程式。 請參考下列 Azure 資源，以在設計應用程式和規劃災害復原時取得指引：

請參考下列最佳做法，以維護 Azure 儲存體資料的高可用性：

  • 磁碟：使用 Azure 備份來備份 Azure 虛擬機器所使用的 VM 磁碟。 也請考慮使用 Azure Site Recovery 來保護 VM 不受區域災害的影響。
  • 區塊 Blob：開啟虛刪除以防止物件層級刪除和覆寫，或使用 AzCopy、Azure PowerShell 或 Azure Data Movement 程式庫將區塊 blob 複製到不同區域的其他儲存體帳戶。
  • 檔案：使用 Azure 備份來備份您的檔案共用。 也可啟用虛刪除，以防止意外刪除檔案共用。 若啟用異地備援時無法使用 GRS，請使用 AzCopy 或 Azure PowerShell，將檔案複製到不同區域的其他儲存體帳戶。
  • 資料表：使用 AzCopy 將資料表資料匯出到位於不同區域的其他儲存體帳戶。

追蹤中斷

客戶可以訂閱 Azure 服務健康狀態儀表板來追蹤 Azure 儲存體和其他 Azure 服務的健康情況和狀態。

Microsoft 也建議您將應用程式設計成可以因應可能的寫入失敗。 您的應用程式應該以能警告您主要區域可能會發生中斷的方式公開寫入失敗。

另請參閱