Azure SQL Database 標準異地備援 (Standard Geo-Replication) 功能
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 3 日所發表的文章 https://azure.microsoft.com/blog/2014/09/03/azure-sql-database-standard-geo-replication/
在這篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database 新釋出的標準異地備援 ( Standard Geo-Replication ) 功能。標準異地備援功能允許您從主要資料庫以非同步 ( asynchronously ) 的方式將已認可的交易 ( committed transactions ) 複製到預先設定妥的備援資料中心 ( Azure Regions )。
在深入討論之前，我們先整理 Azure SQL Database 所有確保業務連續性之解決方案，並且討論它們在各 Azure SQL Database 服務層級下的狀況。您可以在此篇文章中找到所有關於 Azure SQL Database 各服務層的詳細資訊。
業務連續性 ( Business continuity )
在先前關於主動異地備援 ( Active Geo-Replication ) 的文章中，已經先行定義了業務連續性的挑戰目標，而在這裡我們來快速複習一下幾個重要的概念 :
- 災難回復 Disaster recovery ( DR ) : 恢復應用程式至正常運作功能的過程。
- 時間點回復 Point in time restore : 將資料庫從人為錯誤或是資料錯誤的狀態下回復至過去的某個時間點 ( 需要在備份期間內 )
- 目標恢復時間 Recovery Time Objective (RTO) : 當錯誤發生後，系統要在多少時間內回復正常
- 目標恢復點 Recovery Point Objective (RPO) : 當錯誤發生時，可忍受的資料遺失的時間長度
下表顯示了不同服務層之間的業務連續性差異 :
業務連續性與災害復原 ( BCDR, Business Continuity and Disaster Recovery ) 相關功能 |
Basic |
Standard |
Premium |
即時還原 ( Point in Time Restore ) |
過去 7 天內的時間點 |
過去 14 天內的時間點 |
過去 35 天內的時間點 |
異地還原 ( Geo-Restore ) |
RTO<24小時 RPO<24小時 |
RTO<24小時 RPO<24小時 |
RTO<24小時 RPO<24小時 |
標準異地備援 ( Standard Geo-Replication ) |
不支援 |
RTO<2小時 RPO<30分鐘 |
RTO<2小時 RPO<30分鐘 |
主動異地備援 ( Active Geo-Replication ) |
不支援 |
不支援 |
RTO<1小時 RPO<5分鐘 |
選擇哪一種業務連續性與災難恢復 ( Business Continuity/Disaster Recovery ，BCDR ) 解決方案的關鍵因素往往與應用程式效能有關，如果您的應用程式的資料更新率 ( rate of updates ) 較低，處理的資料量也較少時，Azure SQL Database 所提供最基本異理還原 ( Geo-Restore ) 將是適合您的方案。若應用程式需要處理較大的資料量，並且對於 RPO 以及應用程式效能要求較高時，就需要使用標準異地備援 ( Standard Geo-Replication ) 來符合您的需求。至於最高階的主動異地備援 ( Active Geo-Replication ) 則是針對需要最低 RPO 以及處理大量資料異動量之需求所提供的解決方案。
當您從 Azure SQL Database Basic 服務層升級到 Premium 服務層時，您能夠選擇的業務連續性與災難恢復 ( BCDR ) 解決方案也就越多。Azure SQL Database 高階版本包含了所有入門版本服務層級的全部 BCDR 功能。
標準異地備援與主動異地備援的不同處
現在讓我們進一步了解標準異地備援的用戶驗經驗，以及它不同於主動異地備援之處。
首先，標準異地備援與主動異地備援是建立在相同的技術上，但是標準異地備援較適合資料密集寫入 ( write-intensive ) 量較少的應用情境。一般而言以下幾點考量會讓用戶決定該採用標準異地備援 :
- 目標應用程式的資料更新速率 ( update rate ) 不需要用很高之災難備援 SLA。
- 應用程式只需要簡單的恢復作業流程，而不需要太複雜的邏輯來做容錯移轉的決定。
- 這些應用程式通常有成本上的考量 ( cost sensitive )。
標準異地備援 ( Standard Geo-Replication ) 相較於主動異地備援 ( Active Geo-Replication ) 簡化如下:
- 在 Microsoft 定義的災難備援配對資料中心 ( DR paired ) 中建立一個備援資料庫 ( secondary database )。災難備援配對資料中心的列表可以在此查閱。
- 可以在主要 ( master ) 資料庫上可以看到備援的資料庫，但是除非容錯移轉完成，否則是不能夠直接連線使用備援的資料庫。
- 由於備援的資料庫平時是不能夠直接讀取的，也因此收費較便宜。
- 當 Azure 資料中心長時間停擺時才會啟用容錯移轉動作，每當 Azure 入口網站會顯示 Azure SQL Database 服務為 "degraded" 時，很可能需要花費長達一個小時的時間才會恢復正常，。
- 在 Azure 資料中心長時間停擺的狀況下，如果微軟認為復原時間會超過 24 小時，或是 Azure SQL Database 發生問題而用戶超過 24 小時沒有主動啟動容錯移轉程序，微軟會將所有使用標準異地備援的用戶資料庫自動切換到備援的資料中心。
圖一 : 為標準異地備援的典型配置。一個資料庫可以在配對的備援資料中心 ( DR paired ) 內擁有一個離線狀態的備援資料庫
如您所見，標準異地備援的重點就是讓 Azure SQL Database 資料庫從大規模的故障區域中盡速恢復，並且維持正常的運作。但是有時候要做到這點，可能還是需要更強而有力的主動異地備援 ( Active Geo-Replication ) 來完成。以下表格總結了兩者使用的差異 :
方案 |
標準異地備援 (Standard Geo-Replication) |
主動異地備援 (Active Geo-Replication) |
處理區域災害 ( Regional disaster ) |
Yes |
Yes |
災害復原演練 (DR Drills) |
Yes |
Yes |
線上應用程式更新 |
No |
Yes |
線上應用程式搬移 ( relocation ) |
No |
Yes |
讀取負載平衡 ( Read load balancing ) |
No |
Yes |
為什麼要使用標準異地備援，而不是使用 Azure SQL Database Premium 的主動異地備援?
既然 Azure SQL Database Premium 版能夠同時支援標準異地備援和主動異地備援。那在甚麼情況下您要選擇的是標準異地備援，而不是更為強大的主動異地備援呢 ?
標準異地備援被設計為一個較為簡單且便宜的災害還原解決方案 ( DR solution )，特別適合用來處理資料更新率較低的應用程式。如果 Azure SQL Database Premium 版資料庫是被用來處理大批讀取導向 ( read-oriented ) 的工作負載時，就相當適合使用標準異地備援。
當使用標準異地備援時，您無法選擇備援資料庫的資料中心位置，也不會如同主動異地備援般擁有四個具備讀取權限的備援資料庫，也無法完全控制在何時何地進行容錯移轉。但是相對的，使用標準異地備援讓您得到一個由 Microsoft 控制，較為簡單的監測方式以及容錯移轉流程。對於 Azure SQL Database Premium 用戶而言，標準異地備援和主動異地備援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版資料庫去建立一個離線的標準異地備援資料庫，同時您仍可以利用主動異地備援功能，建立多個可讀取的備援資料庫用於讀取負載平衡，以應付高密集讀取的應用情境。
資料庫容錯移轉 ( failover )
標準異地備援是專門為資料庫提供從災害停機中恢復的解決方案。除非有一個 Azure SQL Database 在主要的託管區域停止運作，否則您將無法啟動容錯移轉到配對資料中心內的備援 ( secondary ) 資料庫。也就是說若您使用標準異地備援，倘若發生用戶應用層級的資料庫停止運作，用戶是無法自行手動進行的容錯移轉，若有這類需求，用戶應該選擇使用主動異地備援。
若有一個 Azure 資料中心發生長時間停機的狀況時，微軟會針對使用 Azure SQL Database 標準異地備援的資料庫進行容錯轉移。這項措施的目標，就是要在 Azure SQL Database 停機發生後的一小時之內啟動容錯移轉，一旦啟動這項措施，用戶您開始進行容錯轉移動作，將資料庫移轉至備援資料中心的資料庫，並停止主要資料庫與備援資料庫之間的資料複製動作。
這種方法使得容錯移轉變得相當簡單，應用程式只需要判斷是否啟用容錯移轉的旗標 ( flag )，再來決定要進行容錯移轉還是等待目前資料庫復原。這兩種選擇會依據應用程式需求而有所不同。若您的應用程式比較注重不停機的高可用性 ( higher availability ) 並能容忍漏失過去一個小時已經儲存於主要資料庫內的資料，當為微軟啟用允許容錯轉移後，用戶應盡速啟用容錯移轉。倘若您的應用程式比較注重資料的完整性，已經儲的資料遺失是非常敏感 ( sensitive ) 的，雖然微軟已經允許標準異地備援用戶開始進行容錯轉移，用戶能可能願意繼續等待 Azure SQL Database 恢復正常，以避免資料庫內的資料漏失。然而，若是主要資料庫所在之 Azure 資料中心若是在發生停機後 24 小時之內都沒法復原，則標準異地備援的資料庫都會自動執行容錯移轉動作。在這種最壞狀況下，應用程式將會有 24 小時的停機時間並且會有部分資料遺失。無論是用戶自己啟動容錯移轉或是等待 24 小時讓它自行發生，用戶都需重新配置與設定您的應用程式的資料庫連線，連接到容錯轉移後的備援資料庫。
完成容錯轉移之後，您也會想要確定新的主要資料中心 ( Primary region ) 是否也受到相同的保護，因此在進行容錯移轉的過程中，Azure 會更新它的災難恢復配對資料中心 ( DR pair )，這將允許您從新的主要資料中心 ( Primary region ) 來啟動新的地理資料複製來保護它自己。由於建立新的備援區域需要花費一些時間 ( 取決於資料庫資料量大小 )，您必須承擔在建立新的備援區域的這段期間，Azure SQL Database 暫時無高可用性備援能力，並且接受在沒有保護狀態下執行應用程式的風險。最妥當的辦法就是等待容錯移轉資料庫已經有完整備援資料中心保護之後，再啟動應用程式。
建立完備原資料中心後，新的災害復原 ( DR ) 的配置如下圖所示 :
圖二 : 在容錯移轉更新完新的災難備援配對資中心之後，應用程式可以建立一個新的備援資料庫並開始資料複製動作
災害復原演練 ( Disaster Recovery Drills )
由於資料庫的容錯移轉與資料是相互關聯並且是一個具破壞性的回復方式，因此容錯移轉的整個流程應該要定期經過測試來確保應用程式能夠應付災難發生時的突發狀況。這個測試的過程叫做災壞復原演練 ( Disaster Recovery Drills )。許多國際資訊安全相關認證也要求應用程式備妥與進行災壞復原演練。雖然平時在 Azure SQL Database 正常運行的情況下，在備援資料中心內離線 ( offline ) 的備援資料庫無法真的進行容錯移轉，但是在災害復原演練時，用戶還是可以透過停止主資料庫 ( primary database ) 的地理複寫的方式，讓被援資料中心的資料庫可以被用戶啟用。來測試整體的災害復原流程。
在經過容錯移轉之後，備援資料庫將可以完全地被存取，就像主資料庫般的讓應用程式使用。在演練的過程中，資料有可能會遺失而且在這段時間主要資料中心內的資料庫並沒有受到保護，因此我們不建議客戶在實際生產用的資料庫上進行災害復原演練。我們建議您在主資料庫所在的資料中心內建立一個資料庫副本，並且使用這個副本和它的輔助區域來測試容錯轉移流程演練。
管理工具
標準異地備援提供了在主動異地備援上啟用的REST API子集。要管理標準異地備援，您可以使用這個API並且提供PowerShell指令或是使用Azure管理網站。由於這項功能還在預覽階段，因此您需要先登入到Azure SQL Database的新服務層。啟用標準異地備援最簡單的方式就是使用Azure管理網站中的"異地備援"選項。
圖三 : 使用 Azure 管理網站建立和監控離線地理輔助區的狀態
要注意的是，您可以在任何時候選擇取消地理複製。有兩種方式可以達到此效果，您可以在主資料庫上終止地理複製或是直接刪除備援的次要資料庫。
第一種方式是當您複製到錯誤的資料庫時，可以有效的終止這個動作。若您在備援資料庫建立好之前就取消這項動作，您將不會被收取任何費用，但若在備援資料庫已經建立好之後才取消，則您需要按照您使用的額度來支付費用。使用第二種方式，將會自動停止地理資料複製並且刪除備援資料庫，並且從停止的那一刻開始停止收費。
結論
標準異地備援針對擁有適度資料更新速率的應用程式，提供了一個強大的災難恢復解決方法，雖然它不如主動異地備援來的靈活，但是我們認為它還是符合大多數應用程式的需求。請告知我們您的想法，我們會認真聽取您在新的 Azure SQL Database 服務層中使用地理複製地回覆意見，您能夠在以下文章中得到更多資訊。