設定 SQL Server 的災害復原
本文說明如何協助保護應用程式的 SQL Server 後端。 您可以使用 SQL Server 商務持續性和災害復原 (BCDR) 技術與 Azure Site Recovery 的組合達成此目標。
開始之前，請確定您瞭解 SQL Server 的災害復原功能。 這些功能包括：
- 容錯移轉叢集
- Always On 可用性群組
- 資料庫鏡像
- 記錄傳送
- 使用中的地理複寫
- 自動容錯移轉群組
結合 BCDR 技術與 Site Recovery
您選擇用來復原 SQL Server 執行個體的 BCDR 技術，應該根據您的復原時間目標 (RTO) 和復原點目標 (RPO) 需求，如下表所述。 結合 Site Recovery 與您所選技術的容錯移轉作業，以協調整個應用程式的復原。
| 部署類型 | BCDR 技術 | SQL Server 的預期 RTO | SQL Server 的預期 RPO |
|---|---|---|---|
| Azure VM 上的 SQL Server 基礎結構即服務 (IaaS) 虛擬機器 (VM) 或內部部署。 | Always On 可用性群組 | 使次要複本成為主要複本所花費的時間。 | 由於複寫至次要複本是非同步，因此會遺失一些資料。 |
| Azure VM 上的 SQL Server IaaS VM 或內部部署。 | 容錯移轉叢集 (Always On FCI) | 在節點之間進行容錯移轉所花費的時間。 | 因為 Always On FCI 使用共用存放裝置，所以在容錯移轉時，可以使用儲存體執行個體的相同檢視。 |
| Azure VM 上的 SQL Server IaaS VM 或內部部署。 | 資料庫鏡像 (高效能模式) | 強制服務所花費的時間，使用鏡像伺服器做為暖待命伺服器。 | 複寫不是同步進行。 鏡像資料庫可能會稍微落後主體資料庫。 延遲通常很小。 但是如果主體或鏡像伺服器的系統負載過重，則可能會變得巨大。 記錄傳送可以作為資料庫鏡像的補充。 這是非同步資料庫鏡像的理想替代方案。 |
| SQL 作為 Azure 上的平台即服務 (PaaS)。 此部署類型包含單一資料庫和彈性集區。 |
作用中異地複寫 | 觸發容錯移轉之後的 30 秒。 容錯移轉至其中一個次要資料庫啟動時，所有其他次要複本會自動連結至新的主要複本。 |
五秒的 RPO。 主動式異地複寫使用 SQL Server 的 Always On 技術。 其會使用快照集隔離，以非同步方式將主資料庫上認可的交易複寫到次要資料庫。 保證次要資料永遠不會有部分交易。 |
| SQL 作為在 Azure 上使用主動式異地複寫的 PaaS。 此部署類型包含受控執行個體、彈性集區和單一資料庫。 |
自動容錯移轉群組 | 一小時的 RTO。 | 五秒的 RPO。 自動容錯移轉群組會在主動式異地複寫上提供群組語義。 但使用相同的非同步複寫機制。 |
| Azure VM 上的 SQL Server IaaS VM 或內部部署。 | 使用 Azure Site Recovery 進行複寫 | 一般來說，RTO 會少於 15 分鐘。 若要深入瞭解，請閱讀 Site Recovery 所提供的 RTO SLA。 | 應用程式一致性為一小時，而當機一致性為五分鐘。 如果您希望尋找較低的 RPO，請使用其他 BCDR 技術。 |
注意
當您使用 Site Recovery 協助保護 SQL 工作負載時，有幾個重要的考量：
- Site Recovery 是應用程式中立的。 Site Recovery 可協助保護任何部署在支援作業系統上的 SQL Server 版本。 若要深入瞭解，請參閱複寫機器的復原支援矩陣。
- 您可以選擇使用 Site Recovery 在 Azure、Hyper-V、VMware 或實體基礎結構上進行任何部署。 請遵循如何使用 Site Recovery 協助保護 SQL Server 叢集一文結尾的指導方針。
- 確定電腦上觀察到的資料變更率是在 Site Recovery 限制內。 變更率是以每秒的寫入位元組數來測量。 對於執行 Windows 的電腦，您可以選取工作管理員中的 [效能] 索引標籤，以查看此變更率。 觀察每個磁碟的寫入速度。
- Site Recovery 支援儲存空間直接存取上的容錯移轉叢集實例複寫。 若要深入瞭解，請參閱如何啟用儲存空間直接存取複寫。
當您將 SQL 工作負載遷移至 Azure 時，建議您在 Azure 虛擬機器上套用 SQL Server 的效能指導方針。
應用程式的災害復原
Site Recovery 透過復原計畫的協助，來協調測試容錯移轉和整個應用程式的容錯移轉。
有一些必要條件可確保您的復原方案會根據您的需求完全自訂。 任何 SQL Server 部署通常都需要 Active Directory 部署。 也需要您應用程式層的連線能力。
步驟 1：設定 Active Directory
在次要復原網站上設定 Active Directory，讓 SQL Server 正常運作。
- 小型企業：您有一些應用程式，以及內部部署網站的單一網域控制站。 如果您想要容錯移轉整個網站，請使用 Site Recovery 複寫。 此服務會將網域控制站複寫至次要資料中心或 Azure。
- 中型至大型企業：您可能需要設定額外的網域控制站。
- 如果您有大量應用程式、Active Directory 樹系，並且想要依應用程式或工作負載進行容錯移轉，請在次要資料中心或 Azure 中設定另一個網域控制站。
- 如果您使用 Always On 可用性群組復原至遠端網站，請在次要網站或 Azure 中設定另一個網域控制站。 此網域控制站用於已復原的 SQL Server 執行個體。
本文中的指示假設在次要位置中有網域控制站。 若要深入瞭解，請參閱使用 Site Recovery 協助保護 Active Directory 的程序。
步驟 2：確定與其他層的連線能力
在目標 Azure 區域中執行資料庫層之後，請確定您已與應用程式和 Web 層連接。 事先採取必要的步驟，以驗證並測試容錯移轉的連線能力。
若要瞭解如何設計應用程式以進行連線考慮，請參閱下列範例：
步驟 3：與 Always On、主動式異地複寫和自動容錯移轉群組交互操作
BCDR 技術 Always On、主動式異地複寫和自動容錯移轉群組都具有在目標 Azure 區域中執行 SQL Server 的次要複本。 應用程式容錯移轉的第一個步驟，是將此複本指定為主要複本。 此步驟假設您在次要區域中已經有網域控制站。 如果您選擇進行自動容錯移轉，則可能不需要此步驟。 只有在資料庫容錯移轉完成之後，才會容錯移轉您的 Web 和應用層。
注意
如果您已使用 Site Recovery 協助保護 SQL 電腦，則只需要建立這些電腦的復原群組，並在復原方案中新增其容錯移轉。
使用應用程式和 Web 層虛擬機器建立復原方案。 下列步驟顯示如何加入資料庫層的容錯移轉：
匯入將 Resource Manager 虛擬機器和傳統虛擬機器兩者中 SQL 可用性群組容錯移轉的指令碼。 將指令碼匯入您的 Azure 自動化帳戶。
將 ASR-SQL-FailoverAG 指令碼新增為復原計畫第一個群組的前置動作。
依照指令碼中的指示來建立自動化變數。 此變數提供可用性群組的名稱。
步驟 4：執行測試容錯移轉
某些 BCDR 技術 (例如 SQL) Always On 原本不支援測試容錯移轉。 只有在使用此類技術時，才建議使用下列方法。
在 Azure 中裝載可用性群組複本的 VM 上，設定 Azure 備份。
觸發復原計劃的測試容錯移轉之前，從上一步所使用的備份來復原 VM。
在已從備份還原的 VM 中強制執行仲裁。
將接聽程式 IP 位址更新為測試容錯移轉網路中可用的位址。
使接聽程式連線。
確定容錯移轉網路中的負載平衡器有一個 IP 位址，從對應至每個可用性群組接聽程式的前端 IP 位址集區，並在後端集區中有 SQL Server VM。
在稍後的復原群組中，針對此復原方案新增應用層的容錯移轉，然後再加入您的 Web 層。
進行復原計畫的測試容錯移轉，以測試應用程式的端對端容錯移轉。
進行容錯移轉的步驟
在步驟 3 中新增指令碼並在步驟 4 中進行驗證之後，您便可執行步驟 3 中所建立復原方案的容錯移轉。
在測試容錯移轉和容錯移轉復原計畫中，應用程式和 Web 層的容錯移轉步驟應該相同。
如何協助保護 SQL Server 叢集
對於執行 SQL Server Standard Edition 或 SQL Server 2008 R2 的叢集，建議您使用 Site Recovery 複寫協助保護 SQL Server。
Azure 到 Azure 和內部部署至 Azure
複寫至 Azure 區域時，Site Recovery 不提供來賓叢集支援。 SQL Server Standard Edition 也不會提供低成本的災害復原解決方案。 在此案例中，建議您將 SQL Server 叢集保護至主要位置中的獨立 SQL Server 執行個體，並在次要資料庫中加以復原。
在主要 Azure 區域或內部部署站台上設定其他獨立 SQL Server 執行個體。
設定此執行個體做為您協助要保護的資料庫鏡像。 在高安全性模式下設定鏡像。
在 Azure、Hyper-V 或 VMware VM 和實體伺服器的主要網站上設定 Site Recovery。
使用 Site Recovery 複寫將新的 SQL Server 執行個體複寫至次要站台。 因為這是高安全性鏡像副本，因此會與主要叢集同步處理，但是會使用 Site Recovery 複寫進行複寫。
容錯回復考量
針對 SQL Server Standard 叢集，在未規劃的容錯移轉之後進行容錯回復需要 SQL Server 備份和還原。 這項作業是透過重新建立鏡像，從鏡像執行個體至原始叢集進行。
常見問題集
使用 Site Recovery 時，SQL Server 如何獲得授權？
SQL Server 的 Site Recovery 複寫會在軟體保證災害復原權益下討論。 此涵蓋範圍適用於所有 Site Recovery 案例：內部部署至 Azure 的災害復原和跨區域 Azure IaaS 災害復原。 如需詳細資訊，請參閱 Azure Site Recovery 定價。
Site Recovery 支援我的 SQL Server 版本嗎？
Site Recovery 是應用程式中立的。 Site Recovery 可協助保護任何部署在支援作業系統上的 SQL Server 版本。 若要深入瞭解，請參閱複寫機器的復原支援矩陣。
Azure Site Recovery 是否可與 SQL 異動複寫搭配運作?
由於 Azure Site Recovery 使用檔案層級複製，SQL 無法保證相關聯 SQL 複寫拓撲中的伺服器在 Azure Site Recovery 容錯移轉時會保持同步。 這可能導致 logreader 和/或散發代理程式因 LSN 不符而失敗，從而中斷複寫。 若您在複寫拓撲中針對發行者、散發者或訂閱者容錯移轉，則必須重建複寫。 建議將訂用帳戶重新初始化至 SQL Server。
下一步
- 深入瞭解 Site Recovery 架構。
- 針對 Azure 中的 SQL Server，深入瞭解在次要 Azure 區域中復原的高可用性解決方案。
- 針對 SQL Database，深入瞭解在次要 Azure 區域中復原的商務持續性和高可用性選項。
- 針對位於內部部署 SQL Server 的電腦，深入瞭解 Azure 虛擬機器中的復原高可用性選項。