使用 Azure SQL Database 設計全域可用的服務
適用於：
Azure SQL 資料庫
使用 Azure SQL Database 建置和部署雲端服務時，您可以使用主動式異地複寫或容錯移轉群組來為區域性中斷和嚴重的故障提供恢復能力。 相同的功能可讓您建立已針對本機資料存取進行最佳化的全域分散式應用程式。 本文會討論常見的應用程式模式，包括每個選項的優缺點。
注意
如果您目前使用進階或業務關鍵資料庫和彈性集區，您可以將它們轉換成區域備援部署組態，使它們具備區域中斷復原能力。 請參閱區域備援資料庫。
情節 1：使用兩個 Azure 區域以獲得最少停機時間的業務持續性
在此情節中，應用程式具有下列特性：
- 應用程式在一個 Azure 區域中為作用中
- 所有的資料庫工作階段都需要資料的讀取和寫入權限 (RW)
- 必須共置 web 層和資料層才能減少延遲和流量成本
- 基本上，停機時間對於這些應用程式的商業風險高於資料遺失
在此情況下，當所有應用程式元件需要共同容錯移轉時，應用程式部署拓撲最適合用來處理區域性災害。 下圖顯示此拓撲。 如需地理備援，會將應用程式的資源部署至區域 A 和 B。不過，並不會使用區域 B 中的資源，直到區域 A 失敗為止。 會在兩個區域之間容錯移轉群組，以管理資料庫連線、複寫和容錯移轉。 兩個區域中的 web 服務都會設定為透過讀寫接聽程式 <failover-group-name>.database.windows.net (1) 存取資料庫。 Azure 流量管理員設為使用優先順序路由方法 (2)。
注意
這整篇文章使用 Azure 流量管理員，僅供說明用途。 您可以使用任何支援優先順序路由方法的負載平衡方案。
下圖顯示此設定在運作中斷之前的情形：
在主要區域中斷之後，SQL Database 會偵測到主要資料庫無法存取，並以自動容錯移轉原則的參數作為基礎，觸發容錯移轉至次要區域 (1)。 根據您的應用程式 SLA，可以在中斷偵測和容錯移轉本身之間設定可控制時間的寬限期。 Azure 流量管理員可能會在容錯移轉群組觸發資料庫之前，起始端點容錯移轉。 在此情況下，web 應用程式無法立即重新連線至資料庫。 但是，資料庫容錯移轉一旦完成，重新連線就會自動成功。 當失敗的區域還原並再度上線時，舊的主要區域會自動重新連線作為新的次要區域。 下圖說明容錯移轉後的設定。
注意
在容錯移轉之後認可的所有交易會在重新連線時遺失。 容錯移轉完成之後，區域 B 中的應用程式就能夠重新連線，然後重新開始處理使用者要求。 Web 應用程式與主要資料庫現在都位於區域 B，且仍維持共置。
如果在區域 B 中發生中斷情況，主要與次要資料庫之間的複寫程序就會暫停，但兩者之間的連結會維持不變 (1)。 流量管理員會偵測到區域 B 的連線已中斷，並且將端點 Web 應用程式 2 標示為「已降級」(2)。 在此情況下，不會影響應用程式的效能，但是資料庫會變成公開，因此當區域 A 失敗時，資料遺失的風險會較高。
注意
災害復原的應用程式部署設定，建議限制在兩個區域。 這是因為大部分的 Azure 地理位置只有兩個區域。 這些設定不會保護應用程式免於遭受兩個區域同時發生的重大失敗。 在這種罕見的失敗情況下，您可以使用異地復原作業，在第三個區域復原資料庫。 如需詳細資訊，請參閱災害復原後的 Azure SQL Database 指南。
一旦運作中斷情況趨緩後，次要資料庫會自動與主要資料庫同步處理。 同步處理期間，可能會影響主要區域的效能。 特定的影響取決於容錯移轉之後，新的主要區域取得的資料量。
注意
在中斷得到緩解之後，流量管理員會開始將連線路由至區域 A 的應用程式，做為較高優先順序的端點。 如果您想要在區域 B 保持主要一段時間，您應該據此變更流量管理員設定檔中的優先順序資料表。
下圖說明次要地區發生運作中斷的情形：
此設計模式的主要 優點 包括：
- 這兩個區域會部署相同的 Web 應用程式，不需要任何特定地區設定和任何其他邏輯來回應容錯移轉。
- 應用程式的效能不會受到容錯移轉所影響，因為 Web 應用程式和資料庫一律為共置。
主要的取捨是區域 B 中的應用程式資源在大部分的時間使用量過低。
情節 2：達到最大資料保留之業務持續性的 Azure 區域
這個選項最適合具有下列特性的應用程式：
- 任何資料遺失都會帶來極高的商業風險。 資料庫容錯移轉只能當作嚴重失敗造成之中斷情況時的最後手段。
- 應用程式支援唯讀和讀寫模式的作業，而且可以「唯讀模式」運作一段時間。
在此模式中，應用程式會在讀寫連接開始收到逾時錯誤時切換到唯讀模式。 Web 應用程式已部署到這兩個區域，並且包含讀寫接聽程式端點的連線，和唯讀接聽程式端點的不同連線 (1)。 流量管理員設定檔應該使用優先順序路由。 應在每個區域中啟用應用程式端點的結束點監視 (2)。
下圖說明此設定在運作中斷之前的情形：
當流量管理員偵測到區域 A 的連線失敗時，會自動將使用者流量切換到區域 B 中的應用程式執行個體。使用此模式時，請務必將資料遺失的寬限期設為夠高的值，例如 24 小時。 如果在該時間內中斷情況已趨緩，這可以確保避免遺失資料。 當區域 B 的 Web 應用程式啟動時，讀寫作業將會開始失敗。 此時應該會切換到唯讀模式 (1)。 在此模式中，要求將會自動路由到次要資料庫。 如果中斷是由重大錯誤所導致，就很有可能無法在寬限期內減輕。 到期時，容錯移轉群組就會觸發容錯移轉。 之後就可以使用讀寫接聽程式，而連線不會再失敗 (2)。 下圖說明復原程序的兩個階段。
注意
如果主要區域的運作中斷情況在寬限期內趨緩，流量管理員就會偵測到主要區域中的連線恢復，然後將使用者流量切換回到區域 A 中的應用程式執行個體。該應用程式執行個體會繼續使用區域 A 的主要資料庫以讀寫模式運作，如先前圖表中所示。
如果是在區域 B 中發生中斷情況，流量管理員會在區域 B 中偵測到失敗的結束點 web-app-2，並將它標記為「已降級」(1)。 在此同時，容錯移轉群組會將唯讀接聽程式切換至區域 A (2)。 此中斷不會影響終端使用者體驗，但會在中斷期間公開主要資料庫。 下圖說明次要地區發生失敗的情形：
一旦中斷情況趨緩，次要資料庫會立即與主要資料庫同步處理，唯讀接聽程式會切換回區域 B 中的次要資料庫。在同步處理期間，主要資料庫的效能可能會根據需要進行同步處理的資料量而稍微受到影響。
此設計模式有幾個 優點：
- 在暫時性運作中斷期間避免資料遺失。
- 停機時間僅取決於流量管理員多快偵測到連線失敗，而這是可設定的。
取捨是指應用程式必須能夠在唯讀模式下運作。
商務持續性計劃：針對雲端災害復原選擇應用程式設計
特定的雲端災害復原策略可以合併或擴充這些設計模式，以完全滿足應用程式的需求。 如先前所述，您選擇的策略取決於您想要提供給客戶的 SLA 和應用程式部署拓樸。 為了協助指導您做決定，下表是以復原點目標 (RPO) 和預估復原時間 (ERT) 作為基礎來比較各種選擇。
| 模式 | 復原點目標 (RPO) | ERT |
|---|---|---|
| 災害復原的主動-被動部署，使用共置資料庫存取 | 讀寫存取 < 5 秒 | 失敗偵測時間 + DNS TTL |
| 應用程式負載平衡的主動-主動部署 | 讀寫存取 < 5 秒 | 失敗偵測時間 + DNS TTL |
| 資料保留的主動-被動部署 | 唯讀存取 < 5 秒 | 唯讀存取 = 0 |
| 讀寫存取 = 0 | 讀寫存取 = 失敗偵測時間 + 遺失資料的寬限期 |
後續步驟
- 如需商務持續性概觀和案例，請參閱 商務持續性概觀
- 若要深入了解作用中異地複寫，請參閱作用中異地複寫。
- 若要深入了解容錯移轉群組，請參閱容錯移轉群組。
- 如需主動式異地複寫與彈性集區的相關資訊，請參閱彈性集區災害復原策略。