Azure 檔案儲存體的災害復原和容錯移轉
Microsoft 致力於確保 Azure 服務皆能持續可用。 不過，可能會發生非計劃性服務中斷，且您應該已備妥災害復原 (DR) 計劃來處理區域性服務中斷。 災害復原計畫相當重要的一部分，便是準備在主要端點無法使用的情況下容錯移轉到次要端點。 本文說明與災害復原 (DR) 和儲存體帳戶容錯移轉相關的概念和程序。
重要
如果儲存體同步服務也已容錯移轉，Azure 檔案同步只會支援儲存體帳戶容錯移轉。 這是因為 Azure 檔案同步需要儲存體帳戶和儲存體同步服務位於相同的 Azure 區域。 如果只有儲存體帳戶已容錯移轉，同步處理和雲端階層處理作業將會失敗，直到儲存體同步服務容錯移轉至次要區域為止。 如果您想要容錯移轉的儲存體帳戶，其中包含用作 Azure 檔案同步中雲端端點使用的 Azure 檔案共用，請參閱 Azure 檔案同步災害復原最佳做法和 Azure 檔案同步伺服器復原。
客戶自控的計劃性容錯移轉 (預覽)
客戶自控的計劃性容錯移轉可用於多個案例，包括計劃性災害復原測試、主動回應大規模災害，或從與儲存體無關的中斷復原。
在計劃性容錯移轉過程中，主要區域和次要區域會互換。 原始主要區域會降級並成為新的次要區域。 同時，原始次要區域會升級並成為新的主要區域。 容錯移轉完成後，使用者可以繼續在新的主要區域中存取資料，而系統管理員可以驗證其災害復原方案。 主要區域和次要區域中都必須有儲存體帳戶，才能起始計劃性容錯移轉。
只要主要區域和次要區域在整個過程中都可供使用，預期就不會在計劃性容錯移轉和容錯回復過程中遺失資料。 如需更多詳細資料，請參閱預期資料遺失和不一致一節。
若要了解這種容錯移轉類型對您的使用者和應用程式的影響，了解計劃性容錯移轉和容錯回復程序的每個步驟中發生什麼事會很有幫助。 如需此程序運作方式的詳細資料，請參閱客戶自控的 (計劃性) 容錯移轉如何運作。
重要
客戶自控的計劃性容錯移轉目前處於預覽狀態，且僅限於下列區域：
- 法國中部
- 法國南部
- 印度中部
- 印度西部
- 東亞
- 東南亞
請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。
若要選擇加入預覽版，請參閱在 Azure 訂用帳戶中設定預覽版功能，並將 AllowSoftFailover 指定為功能名稱。 此預覽功能的提供者名稱為 Microsoft.Storage。
重要
計劃性容錯移轉之後，儲存體帳戶的 [上次同步時間 (LST)] 值可能看起來過時，或在 Azure 檔案儲存體資料存在時回報為 NULL。
系統快照集會定期在儲存體帳戶的次要區域中建立，以在容錯移轉和容錯回復期間維持使用一致的復原點。 起始客戶自控的計劃性容錯移轉會導致原始主要區域成為新的次要區域。 在某些情況下，計劃性容錯移轉完成後新的次要區域沒有系統快照集可用，導致帳戶的整體 LST 值看起來過時或顯示為 Null。
由於建立、修改或刪除物件等使用者活動可觸發建立快照集，因此在計劃性容錯移轉之後發生這些活動的任何帳戶都不需要額外的注意。 不過，沒有快照集或使用者活動的帳戶可能會繼續顯示 Null LST 值，直到觸發建立系統快照集為止。
如有必要，請針對儲存體帳戶內的每個共用執行下列其中一個活動，以觸發建立快照集。 完成時，您的帳戶應該會在 30 分鐘內顯示有效的 LST 值。
- 掛接共用，然後開啟任何檔案以供讀取。
- 將測試或範例檔案上傳至共用。
復原計量和成本
若要制定有效的災害復原策略，組織必須了解：
- 在中斷時可承受多少資料遺失 (復原點目標或 RPO)
- 需要多快能夠還原商務功能和資料 (復原時間目標或 RTO)
災害復原的成本通常會隨著較低或零 RPO/RTO 而增加。 在災害發生後幾秒鐘內必須啟動並執行且無法承受任何資料遺失的公司，將會為災害復原付出更多代價，而 RPO/RTO 數字較高的公司付出的代價較少。 Azure 提供可與各種 RPO 和 RTO 需求搭配使用的解決方案。
選擇正確的備援選項
Azure 檔案儲存體提供不同的備援選項，可保護您的資料，避免從暫時性硬體失敗、網路和電源中斷到自然災害等非計劃性事件。 所有 Azure 檔案共用都可以使用本地備援 (LRS) 或區域備援儲存體 (ZRS)。 如需詳細資訊，請參閱 Azure 檔案儲存體備援。
Azure 檔案儲存體針對使用異地備援儲存體 (GRS) 和異地區域備援儲存體 (GZRS) 設定的標準儲存體帳戶支援帳戶容錯移轉，以防止區域性中斷。 透過帳戶容錯移轉，您可以在主要端點無法使用時，為您的儲存體帳戶起始容錯移轉程序。 容錯移轉會更新次要端點以成為儲存體帳戶的主要端點。 容錯移轉完成後，用戶端便可以開始寫入到新的主要端點。
GRS 和 GZRS 仍會有資料遺失的風險，因為資料會以非同步方式複製到次要區域，這表示寫入主要區域之前的延遲會複製到次要區域。 在發生服務中斷的情況下，尚未複製到次要端點的主要端點寫入作業將會遺失。 這表示如果無法復原主要區域，影響主要區域的失敗可能會導致資料遺失。 最近寫入主要區域與上次寫入次要區域之間的間隔即為 RPO。 Azure 檔案儲存體的 RPO 通常低於 15 分鐘，但目前並沒有關於將資料複寫至次要區域所花費時間的 SLA。
重要
進階 Azure 檔案共用不支援 GRS/GZRS。 不過，您可以在兩個 Azure 檔案共用之間同步，以達到異地備援。
高可用性設計
您應該從一開始便針對高可用性來設計您的應用程式。 請參考這些 Azure 資源來取得設計應用程式並針對災害復原進行規劃的指引：
- 設計適用於 Azure 的復原應用程式：概述在 Azure 中架構高可用性應用程式的重要概念。
- 復原檢查清單：確認應用程式已針對高可用性實作最佳設計做法的檢查清單。
- 使用異地備援設計高可用性應用程式：提供建立應用程式的設計指引，以針對 SMB 檔案共用利用異地備援儲存體。
我們也建議您將應用程式設計成可以因應可能的寫入失敗。 您的應用程式應該以能警告您主要區域可能會發生中斷的方式公開寫入失敗。
作為最佳做法，請設計應用程式以確認 [上次同步時間] 屬性來評估預期的資料遺失。 例如，如果您記錄所有寫入作業，則您可以比較最後一次的寫入作業與 [上次同步時間]，來判斷哪些寫入尚未被同步到次要區域。
追蹤中斷
您可以訂閱 Azure 服務健康狀態儀表板來追蹤 Azure 檔案儲存體和其他 Azure 服務的健康情況和狀態。
了解帳戶容錯移轉程序
客戶管理的帳戶容錯移轉可讓您在主要區域因任何原因而無法使用的情況下，將整個儲存體帳戶容錯移轉到次要區域。 當您強制對次要區域進行容錯移轉時，客戶端便可以在容錯移轉完成時，開始將資料寫入到次要端點。 容錯移轉通常需要花費一小時的時間。 建議您在起始帳戶容錯移轉之前盡可能暫止工作負載。
若要了解如何起始帳戶容錯移轉，請參閱起始帳戶容錯移轉。
帳戶容錯移轉的運作方式
在正常情況下，用戶端會將資料寫入主要區域中的儲存體帳戶，且該資料會以非同步方式複製到次要區域。 下圖顯示出主要區域可用的案例：
如果主要端點因任何原因而無法使用，用戶端將無法繼續寫入到儲存體帳戶。 下圖顯示出主要端點變成無法使用，但尚未發生任何復原的案例：
客戶針對次要端點起始帳戶容錯移轉。 容錯移轉程序會更新由 Azure 儲存體提供的 DNS 項目，使次要端點變成您儲存體帳戶的新主要端點，如下圖所示：
在 DNS 項目已更新且要求被導向到新的主要端點之後，異地備援帳戶的寫入權限就會還原。 容錯移轉之後，現有的儲存體服務端點會維持不變。 檔案控制代碼和租用不會在容錯移轉時保留，因此客戶端必須卸載並重新掛接檔案共用。
重要
容錯移轉完成之後，儲存體帳戶會在新的主要端點/區域中被設定為本地備援。 若要繼續複寫到新的次要端點，請再次設定該帳戶的異地備愿。
請記住，將本機備援儲存體帳戶轉換為使用異地備援，會產生成本和時間。 如需詳細資訊，請參閱容錯移轉的時間和成本。
預期資料遺失
警告
帳戶容錯移轉通常會產生一些資料遺失。 請務必了解起始帳戶容錯移轉的含意。
由於資料是以非同步方式從主要區域寫入至次要區域，如果主要區域變得無法使用，則最新的寫入可能尚未複製到次要區域。
當您強制進行容錯移轉時，主要區域中的所有資料都會遺失，因為次要區域會成為新的主要區域。 新的主要區域已在容錯移轉之後設定為本地備援。
發生容錯移轉時，已複製到次要區域的所有資料都會保持不變。 不過，任何已寫入主要區域但尚未複製到次要區域的資料將會永久遺失。
檢查上次同步時間屬性
[上次同步時間 (LST)] 屬性能指出來自主要區域的資料保證已寫入次要區域的最近時間。 在 [上次同步時間] 之前所寫入的所有資料都會存在於次要區域上，但在 [上次同步時間] 之後所寫入的資料則有可能尚未寫入次要區域，並可能會遺失。 在發生中斷時，請使用此屬性來估計起始帳戶容錯移轉可能會導致的資料遺失程度。
為了確保檔案共用在容錯移轉發生時處於一致狀態，系統會每隔 15 分鐘在主要區域中建立一個系統快照集，並複寫到次要區域。 容錯移轉至次要區域時，共用狀態會以次要區域中的最新系統快照集為基礎。 如果主要區域中發生失敗，次要區域可能位於主要區域後方，因為對主要區域的所有寫入都尚未複寫到次要區域。 由於異地延遲或其他問題，次要區域中的最新系統快照集可能早於 15 分鐘。
所有在 LST 之前對主要區域進行的寫入作業都已成功複寫到次要區域，而這表示可從次要區域讀取這些項目。 任何在上次同步時間之後對主要區域進行的寫入作業可能，也可能尚未複寫到次要區域，而這表示您可能對其進行讀取作業。
您可使用 Azure PowerShell、Azure CLI 或用戶端程式庫來查詢 [上次同步時間] 屬性的值。 上次同步時間屬性是 GMT 日期/時間值。 如需詳細資訊，請參閱檢查儲存體帳戶的上次同步時間屬性。
容錯回復到原始主要區域時請小心
如前所述，在您從主要區域容錯移轉到次要區域之後，您的儲存體帳戶在新的主要區域中會被設定為本地備援。 然後，您可以在新的主要區域中設定帳戶的異地備援。 當帳戶在容錯移轉後設定異地備援時，新的主要區域會立即開始將資料複製到新的次要區域，也就是原始容錯移轉之前的主要區域。 不過，將新主要區域中的現有資料全部複製到新的次要區域可能會花費一些時間。
在儲存體帳戶重新設定異地備援之後，您可以起始容錯回復，從新的主要區域回到新的次要區域。 在此情況下，容錯移轉之前的原始主要區域會再次變成主要區域，並設定為本地備援或區域備援，視原始主要設定是 GRS 或 GZRS 而定。 這會使容錯移轉後主要區域 (原來的次要區域) 中的所有資料遺失。 在容錯回復之前，如果儲存體帳戶中大部分的資料都還沒有複製到新的次要區域，則可能會發生大量資料遺失。
若要避免重大資料遺失，請在容錯回復之前檢查 [上次同步時間] 屬性。 比較 [上次同步時間] 與上次資料寫入到新主要區域的時間，以評估預期的資料遺失。
在容錯回復作業之後，您可以將新的主要區域重新設定為異地備援。 如果原來的主要區域已設定 LRS，您可以將它設定為 GRS。 如果原來的主要區域已設定 ZRS，您可以將它設定為 GZRS。 如需其他選項，請參閱變更儲存體帳戶的複寫方式。
初始化帳戶容錯移轉
您可以從 Azure 入口網站、PowerShell、Azure CLI 或 Azure 儲存體資源提供者 API 來起始帳戶容錯移轉。 如需如何起始容錯移轉的詳細資訊，請參閱起始帳戶容錯移轉。
Microsoft 管理的容錯移轉
在區域因嚴重災害而遺失的極端情況下，Microsoft 可能會起始區域容錯移轉。 在此情況下，您不需要採取任何動作。 在 Microsoft 管理的容錯移轉完成之前，您將無法取得儲存體帳戶的寫入權限。