使用 Azure SQL Database 彈性集區的應用程式災害復原策略

適用於：Azure SQL 資料庫

Azure SQL Database 提供許多功能，以在災難事件發生時確保應用程式的商務持續性。 彈性集區和單一資料庫支援相同類型的災害復原 (DR) 功能。 本文說明數種利用這些 Azure SQL Database 商務持續性功能的彈性集區災害復原策略。

本文使用下列標準的 SaaS ISV 應用程式模式︰

現代化雲端型 Web 應用程式會為每位終端使用者佈建一個資料庫。 ISV 有許多客戶，因此會使用多個資料庫 (稱為租用戶資料庫)。 因為租用戶資料庫通常會有無法預測的活動模式，所以 ISV 會使用彈性集區，在一段時間之後，讓資料庫成本預測性變高。 彈性集區也可在使用者活動尖峰時簡化效能管理。 除了租用戶資料庫之外，應用程式也會使用數個資料庫來管理使用者設定檔、安全性、收集使用模式等等。個別租用戶的可用性不會影響整個應用程式的可用性。 不過，管理資料庫的可用性和效能對應用程式的功能而言十分重要，且如果管理資料庫離線，整個應用程式也會離線。

本文會討論涵蓋各種案例 (從成本導向創業應用程式以至具有嚴格可用性需求的應用程式) 的 DR 策略。

注意

如果您目前使用進階或業務關鍵資料庫和彈性集區，您可以將它們轉換成區域備援部署組態，使它們具備區域中斷復原能力。 請參閱區域備援資料庫。

案例 1. 成本導向創業

我想要創業，而且成本極為有限。 我想要簡化應用程式的部署和管理，而且我可以為個別客戶提供受限的 SLA。 但是我想要確保整個應用程式絕不會離線。

若要滿足簡單性需求，請將所有租用戶資料庫部署到您所選擇 Azure 區域中的單一彈性集區，並將管理資料庫部署為異地複寫的單一資料庫。 對於租用戶的災害復原，請使用異地還原，這不需要額外成本。 若要確保管理資料庫的可用性，請使用容錯移轉群組將它們異地複寫到另一個區域 (步驟 1)。 此案例中災害復原組態的持續成本等於次要資料庫的總成本。 下圖說明此組態。

如果主要區域中斷，下圖說明讓您的應用程式上線的復原步驟。

• 容錯移轉群組開始將管理資料庫自動容錯移轉到 DR 區域。 應用程式會自動重新連線到新的主要區域，並且會在 DR 區域中建立所有新的帳戶和租用戶資料庫。 現有的客戶會看到其資料暫時無法使用。
• 使用與原始集區 (2) 相同的組態來建立彈性集區。
• 使用異地還原來建立租用戶資料庫 (3) 的複本。 您可以考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

您的應用程式目前在 DR 區域中已重新上線，但有些客戶在存取其資料時會經歷到延遲。

如果服務是暫時中斷，則在 DR 區域完成所有資料庫還原之前，Azure 可能已復原主要區域。 在此情況下，請安排將應用程式移回主要區域。 此程序會採取下圖上所說明的步驟。

• 取消所有未處理的異地還原要求。
• 將管理資料庫容錯移轉到主要區域 (5)。 復原區域之後，舊的主要已自動成為次要。 現在，它們會再次切換角色。
• 變更應用程式的連接字串，使其重新指向主要區域。 現在，系統會在主要區域中建立所有新的帳戶和租用戶資料庫。 部分現有客戶會發現其資料暫時無法使用。
• 請將 DR 集區中的所有資料庫都設定為唯讀，確保在 DR 區域 (6) 中無法修改它們。
• 對於已在復原後變更之 DR 集區中的每個資料庫，重新命名或刪除主要集區 (7) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (8)。
• 刪除 DR 集區 (9)

您的應用程式目前在具有主要集區中所有可用租用戶資料庫的主要區域中已上線。

優點

這項策略的重要 優點 是資料層備援的持續成本很低。 Azure SQL Database 會自動備份資料庫，不會重寫應用程式，也不需額外費用。 只有在還原彈性資料庫時，才會產生成本。

取捨

取捨在於所有租用戶資料庫的完整復原需要很長的時間。 時間長短取決於您在 DR 區域中起始的總還原次數，和租用戶資料庫的整體大小。 即使您將某些租用戶還原的優先順序設地高於其他還原，還是會與在相同區域中起始的所有其他還原競爭，因為服務將會進行仲裁和節流，以將對現有客戶資料庫的整體影響降到最低。 此外，除非在 DR 區域中建立新的彈性集區，否則無法啟動租用戶資料庫的復原。

案例 2. 具有分層服務的成熟應用程式

我已熟悉試用版客戶和付費客戶具有分層服務供應項目和不同 SLA 的 SaaS 應用程式。 對於試用版客戶，我必須盡可能降低成本。 試用版客戶可能需要停機時間，但我想要減少其可能性。 對於付費客戶，任何停機時間都是風險。 因此，我想要確定付費客戶一律可以存取其資料。

若要支援此案例，請將試用版租用戶與付費租用戶分開，方法是將它們放入個別的彈性集區中。 試用版客戶的每個租用戶的 eDTU 或虛擬核心較低，SLA 也因復原時間較長而較低。 付費客戶所在集區中每個租用戶的 eDTU 或虛擬核心和 SLA 都較高。 為了保證最低的復原時間，我們會對付費客戶的租用戶資料庫進行異地複寫。 下圖說明此組態。

與第一個案例相同，管理資料庫會相當活躍，因此針對它使用單一異地複寫的資料庫 (1)。 這可確保新客戶訂用帳戶、設定檔更新和其他管理作業的可預測效能。 主要管理資料庫複本所在區域是主要區域，而次要管理資料庫複本所在區域是 DR 區域。

在主要區域中所佈建的「付費」集區中，付費客戶的租用戶資料庫會有使用中資料庫。 在 DR 區域中佈建同名的次要集區。 每個租用戶都會異地複寫到次要集區 (2)。 這會使用容錯移轉來快速復原所有租用戶資料庫。

如果主要區域中斷，下圖說明讓您的應用程式上線的復原步驟：

• 將管理資料庫立即容錯移轉到 DR 區域 (3)。
• 變更應用程式的連接字串，使其指向災害復原區域。 現在，系統會在 DR 區域中建立所有新的帳戶和租用戶資料庫。 現有試用版客戶會發現其資料暫時無法使用。
• 將付費租用戶的資料庫容錯移轉到 DR 區域中的集區，以立即還原其可用性 (4)。 因為容錯移轉是快速中繼資料層級變更，請考慮透過使用者連接來依需要觸發個別容錯移轉的最佳化。
• 如果因為次要資料庫在仍是次要複本時只需要擁有處理變更記錄的容量，而造成次要集區 eDTU 或虛擬核心值大小低於主要集區，請立即增加集區容量來容納所有租用戶 (5) 的完整工作負載。
• 使用試用版客戶資料庫 (6) 之 DR 區域中的相同名稱和組態，建立新的彈性集區。
• 建立試用版客戶的集區之後，請使用異地還原，將個別試用版租用戶資料庫還原到新的集區 (7)。 請考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

您的應用程式目前在 DR 區域中重新上線。 所有付費客戶都可以存取其資料，而試用版客戶在存取其資料時會經歷到延遲。

當 Azure 在您於 DR 區域中還原應用程式「之後」 復原主要區域時，您可以繼續在該區域中執行應用程式，也可以決定容錯回復到主要區域。 如果在完成容錯移轉程序「之前」復原主要區域，請考慮立即容錯回復。 此容錯回復會採取下圖中所說明的步驟：

• 取消所有未處理的異地還原要求。
• 容錯移轉管理資料庫 (8)。 復原區域之後，舊的主要會自動成為次要。 現在，它再次變成主要。
• 容錯移轉付費租用戶資料庫 (9)。 同樣地，復原區域之後，多個舊的主要會自動成為多個次要。 現在，它們再次變成主要。
• 將 DR 區域中變更的已還原試用版資料庫設定為唯讀 (10)。
• 對於已在復原後變更之試用版客戶 DR 集區中的每個資料庫，重新命名或刪除試用版客戶主要集區 (11) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (12)。
• 刪除 DR 集區 (13)。

注意

容錯移轉作業是非同步的。 若要將復原時間降到最低，請務必以至少 20 個資料庫的批次執行租用戶資料庫的容錯移轉命令。

優點

這項策略的重要 優點 在於它可為付費客戶提供最高的 SLA。 它也保證會在建立試用版 DR 集區時，立即將新的試用版解除封鎖。

取捨

取捨在於因付費客戶的次要 DR 集區的成本，此設定會增加租用戶資料庫的總成本。 此外，如果次要集區的大小不同，則除非完成 DR 區域中的集區升級，否則付費客戶的效能在容錯移轉之後會較低。

案例 3. 具有分層服務的分散式應用程式

我已有完善且提供分層服務的 SaaS 應用程式。 我想要將非常積極的 SLA 提供給付費客戶，並在中斷時將影響風險降到最低，因為即使是短暫中斷也可能造成客戶不滿。 付費客戶務必一律可以存取其資料。 試用版是免費的，而且在試用期間未提供 SLA。

若要支援這種情況，請使用三個不同的彈性集區。 將大小相同且每個資料庫都具有高 eDTU 或虛擬核心的兩個集區佈建到兩個不同的區域，以包含付費客戶的租用戶資料庫。 包含試用版租用戶的第三個集區可在每個資料庫具有較低 eDTU 或虛擬核心，並佈建到兩個區域中的其中一個。

為了保證中斷期間的最低復原時間，我們會在這兩個區域使用 50% 的主要資料庫來異地複寫付費客戶的租用戶資料庫。 同樣地，每個區域都有 50% 的次要資料庫。 因此，如果區域離線，則只會影響 50% 的付費客戶資料庫，且只須對這個部分進行容錯移轉。 其他資料庫會保持不變。 下圖說明此組態：

與先前的案例相同，管理資料庫會相當活躍，因此請將它們設定為單一異地複寫的資料庫 (1)。 這可確保新客戶訂用帳戶、設定檔更新和其他管理作業的可預測效能。 區域 A 是管理資料庫的主要區域，而區域 B 會用於復原管理資料庫。

付費客戶的租用戶資料庫會也會一併異地複寫，但在區域 A 與區域 B (2) 之間有分割的主要複本和次要複本。 因此，中斷所影響的租用戶主要資料庫可以容錯移轉到其他區域，並變成可用。 完全不會影響另一半的租用戶資料庫。

下圖說明在區域 A 中斷時要採取的復原步驟。

• 將管理資料庫立即容錯移轉到區域 B (3)。
• 變更應用程式的連接字串以指向區域 B 中的管理資料庫。修改管理資料庫，確定系統是在區域 B 中建立新的帳戶和租用戶資料庫，而且那裡也有現有的租用戶資料庫。 現有試用版客戶會發現其資料暫時無法使用。
• 將付費租用戶的資料庫容錯移轉到區域 B 中的集區 2，以立即還原其可用性 (4)。 因為容錯移轉是快速中繼資料層級變更，所以您可以考慮透過使用者連接來依需要觸發個別容錯移轉的最佳化。
• 現在，因為集區 2 只包含主要資料庫，所以集區中的總工作負載會增加，而且可以立即增加其 eDTU 大小 (5) 或虛擬核心數量。
• 使用試用版客戶資料庫 (6) 之區域 B 中的相同名稱和組態，建立新的彈性集區。
• 建立集區之後，請使用異地還原，將個別試用版租用戶資料庫還原到集區 (7)。 您可以考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

注意

容錯移轉作業是非同步的。 若要將復原時間降到最低，請務必以至少 20 個資料庫的批次執行租用戶資料庫的容錯移轉命令。

您的應用程式目前在區域 B 中已重新上線。所有付費客戶都可以存取其資料，而試用版客戶在存取其資料時會經歷到延遲。

復原區域 A 時，您需要決定是否要將區域 B 用於試用版客戶或容錯回復到使用區域 A 中的試用版客戶集區。其中一個準則可能是在復原後修改多少百分比的試用版租用戶資料庫。 不論決策為何，您都必須重新平衡兩個集區之間的付費租用戶。 下圖說明當試用版租用戶資料庫容錯回復至區域 A 時的程序。

• 取消試用版 DR 集區的所有未處理異地還原要求。
• 容錯移轉管理資料庫 (8)。 復原區域之後，舊的主要已自動成為次要。 現在，它再次變成主要。
• 選取哪些付費租用戶資料庫要容錯回復到集區 1，以及起始容錯移轉到其次要 (9)。 復原區域之後，集區 1 中的所有資料庫都已自動成為次要資料庫。 現在，其中的 50% 會再次變成主要。
• 將集區 2 的大小減少為原始 eDTU (10) 或虛擬核心數量。
• 將區域 B 中的所有已還原試用版資料庫設定為唯讀 (11)。
• 對於已在復原後變更之試用版 DR 集區中的每個資料庫，重新命名或刪除試用版主要集區 (12) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (13)。
• 刪除 DR 集區 (14)。

優點

這項策略的重要 優點 如下：

• 它支援付費客戶的最積極 SLA，因為這樣可確保中斷不會影響 50% 以上的租用戶資料庫。
• 它保證在復原期間建立試用版 DR 集區時，立即將新的試用版解除封鎖。
• 它允許更有效率地使用集區容量，因為集區 1 和集區 2 中 50% 的次要資料庫比主要資料庫還不活躍。

取捨

主要 取捨 如下：

• 對於連接到區域 A 的使用者，其管理資料庫的 CRUD 作業的延遲低於連接到區域 B 的使用者，因為它們是針對管理資料庫的主要來執行。
• 需要更複雜的管理資料庫設計。 例如，每個租用戶記錄都具有必須在容錯移轉和容錯回復期間變更的位置標記。
• 除非完成區域 B 中的集區升級，否則付費客戶的效能可能會低於正常情況。

摘要

本文著重於SaaS ISV 多租用戶應用程式所使用之資料庫層的災害復原策略。 您選擇的策略應該要根據應用程式的需求，例如商務模型、您想要提供給客戶的服務等級協定、預算限制等等。上述的各個策略都有大致列出其優點和取捨，供您做出明智的決策。 此外，特定應用程式可能包含其他 Azure 元件。 所以您必須檢閱其商務持續性指引，並安排使用元件來復原資料庫層。 若要深入了解如何管理 Azure 中資料庫應用程式的復原，請參閱設計災害復原的雲端解決方案。

後續步驟

• 若要了解 Azure SQL Database 自動備份，請參閱 Azure SQL Database 自動備份。
• 如需商務持續性概觀和案例，請參閱 商務持續性概觀。
• 若要了解如何使用自動備份進行復原，請參閱 從服務起始的備份還原資料庫。
• 若要了解更快速的復原選項，請參閱主動式異地複寫和容錯移轉群組。
• 若要了解如何使用自動備份進行封存，請參閱 資料庫複製。