使用分散式可用性群組將 SQL 伺服器遷移到 AWS - AWS Prescriptive Guidance

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

使用分散式可用性群組將 SQL 伺服器遷移到 AWS

由普拉芬瑪莎拉 (AWS) 創作

來源:內部部署 SQL 伺服器

目標:EC2 上的 SQL Server

R 類型:主體變更

環境:PoC 或試驗

技術:資料庫; 移轉

工作負載:微軟

AWS 服務:Amazon EC2

Summary

Microsoft SQL 伺服器永遠在可用性群組提供高可用性 (HA) 和嚴重損壞修復 (DR) 解決方案的 SQL 伺服器。可用性群組包含接受讀取/寫入流量的主要複本,以及最多八個接受讀取流量的次要複本。具有兩個或多個節點的 Windows Server 容錯移轉叢集 (WSFC) 上設定可用性群組。

Microsoft SQL Server 永遠在分散式可用性群組提供解決方案來設定兩個獨立的 WFSC 之間的兩個不同的可用性群組。屬於分散式可用性群組的可用性群組不需要位於相同的資料中心。一個可用群組可位於現場部署,另一個可用群組可位於不同網域上的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上的 Amazon Web Services (AWS) 雲端上。 

此模式概述了使用分散式可用性群組,將屬於現有可用性群組一部分的現場部署 SQL Server 資料庫遷移到具有在 Amazon EC2 上設定可用性群組的 SQL Server 資料庫的步驟。透過遵循此模式,您可以將資料庫遷移到 AWS 雲端,在轉換期間最少的停機時間。資料庫在轉換後立即在 AWS 上具有高度可用性。您也可以使用此模式將基礎作業系統從現場部署變更為 AWS,同時保留相同版本的 SQL Server。

先決條件和限制

先決條件

  • 作用中的 AWS 帳戶

  • AWS Direct Connect 或 AWS Site-to-Site VPN

  • 在現場部署和 AWS 上兩個節點上安裝的相同版本 SQL Server

產品版本

  • SQL Server 版本 2016 及更新版本

  • SQL Server Enterprise Edition

Architecture

來源技術堆疊

  • Microsoft SQL Server Database 隨時在現場部署上的可用性群組

目標技術堆疊

  • 在 AWS 雲端上的 Amazon EC2 上,具有始終開啟可用性群組的微軟 SQL 伺服器資料庫

遷移架構

術語

  • 世界財務委員會 1 — 世界財務委員會

  • 世界金融中心 2 — AWS 雲端上的世界金融中心

  • AG 1 — 第一個可用性群組,位於 WSFC 1

  • AG 2 — 第二個可用性群組,位於 WSFC 2

  • SQL Server 主要複本 — AG 1 中的節點被視為全域主要的所有寫入

  • SQL Server 轉寄站 — 從 SQL Server 主要複本以非同步方式接收資料的 AG 2 中的節點

  • SQL Server 次要複本 — 從主要複本或轉寄站同步接收資料的 AG 1 或 AG 2 中的節點

Tools

  • AWS Direct Connect— 透過標準乙太網路光纖纜線,AWS Direct Connect 將您的內部網路連結至 AWS Direct Connect 位置。有了這個連線,您可以建立虛擬界面直接連往公有 AWS 服務,繞過您的網路路服務供應商。

  • Amazon EC2— Amazon Elastic Compute Cloud (Amazon EC2) 在 AWS 雲端提供可擴展的運算容量。您可使用 Amazon EC2 按需要啟動任意數量的虛擬伺服器,並且您可以向外擴展或擴展。

  • AWS Site-to-Site VPN— AWS Site-to-Site VPN 支援建立站台虛擬私有網路 (VPN)。您可以將 VPN 設定為在 AWS 上啟動的執行個體和您自己的遠端網路之間傳遞流量。

  • 微軟 SQL Server Management Studio— Microsoft SQL Server Management Studio (SSMS) 是用於管理 SQL Server 基礎架構的整合式環境。它提供了一個使用者介面和一組工具與 SQL Server 互動的豐富指令碼編輯器。

Epics

任務描述所需技能
在 AWS 上建立 WSFC。

在具有兩個 HA 節點的 Amazon EC2 執行個體上建立 WSFC 2。您將使用此容錯移轉叢集在 AWS 上建立第二個可用性群組 (AG 2)。

系統管理員、系統管理員
在 WSFC 2 上建立第二個可用性群組。

使用 SSMS,在 WSFC 2 中的兩個節點上建立 AG 2。WSFC 2 中的第一個節點會做為轉寄站。WSFC 2 中的第二個節點將充當 AG 2 的次要複本。

在這個階段,沒有資料庫可用於 AG 2。這是設定分散式可用性群組的起點。

DBA,開發人員
在 AG 2 上建立沒有復原選項的資料庫。

備份內部部署可用性群組 (AG 1) 上的資料庫。 

將資料庫還原到轉寄站和 AG 2 的次要複本沒有復原選項。還原資料庫時,請指定具有足夠磁碟空間供資料庫資料檔和記錄檔使用的位置。

在這個階段,資料庫處於還原狀態。它們不是 AG 2 或分散式可用性群組的一部分,而且它們不會同步處理。

DBA,開發人員
任務描述所需技能
在 AG 1 上建立分散式可用性群組。

若要在 AG 1 上建立分散式可用性群組,請使用CREATE AVAILABILITY GROUPDISTRIBUTED選項。

  1. 使用LISTENER_URLAG 1 和 AG 2 的端點位址。

  2. 適用於AVAILABILITY-MODE,請使用ASYNCHRONOUS_COMMIT以避免網路延遲 (如果有的話)。這不會影響資料庫的效能。

  3. 對於 FAILOVER_MODE,請使用 MANUAL。它是與分散式可用性群組搭配使用的唯一可用性模式。

  4. 若要在 AG 2 上手動還原資料庫,並在較大的資料庫上有更多控制權,請使用MANUALforSEEDING_MODE

DBA,開發人員
在 AG 2 上建立分散式可用性群組。

若要在 AG 2 上建立分散式可用性群組,請使用ALTER AVAILABILITY GROUPDISTRIBUTED選項。

  1. 使用LISTENER_URLAG 1 和 AG 2 的端點位址。

  2. 適用於AVAILABILITY-MODE,請使用ASYNCHRONOUS_COMMIT以避免網路延遲 (如果有的話)。這不會影響資料庫的效能。

  3. 對於 FAILOVER_MODE,請使用 MANUAL。它是與分散式可用性群組搭配使用的唯一可用性模式。

  4. 若要在 AG 2 上手動還原資料庫,並在較大的資料庫上有更多控制權,請使用MANUALforSEEDING_MODE

分散式可用性群組是 AG 1 和 AG 2 之間建立。

AG 2 中的資料庫尚未設定為參與資料流程從 AG 1 到 AG 2。

DBA,開發人員
將資料庫新增至 AG 2 上的轉寄站和次要複本。

將資料庫新增至分散式可用性群組,藉由使用ALTER DATABASESET HADR AVAILABILITY GROUP選項轉寄站和 AG 2 上的次要複本中。 

這會啟動 AG 1 和 AG 2 上的資料庫之間的非同步資料流程。 

全域主要會寫入、同步傳送資料至 AG 1 上的次要複本,並以非同步方式傳送資料至 AG 2 上的轉寄站。AG 2 上的轉寄站會同步傳送資料至 AG 2 上的次要複本。

DBA,開發人員
任務描述所需技能
使用 DMV 和 SQL 伺服器記錄檔。

使用動態管理檢視 (DMV) 和 SQL Server 記錄檔,監視兩個可用性群組之間的資料流程狀態。 

有興趣監控的 DMV 包括sys.dm_hadr_availability_replica_statessys.dm_hadr_automatic_seeding

如需轉寄站同步處理的狀態,請監視同步狀態在轉寄站上的 SQL Server 記錄檔。

DBA,開發人員
任務描述所需技能
停止主要複本的所有流量。

停止 AG 1 中的主要複本的傳入流量,以便沒有寫入活動發生在資料庫和資料庫已準備好進行移轉。

App 擁有者, 開發人員
變更 AG 1 上分散式可用性群組的可用性模式。

在主要複本上,將分散式可用性群組的可用性模式設定為同步。 

將可用性模式變更為同步之後,資料會同步從 AG 1 中的主要複本傳送至 AG 2 轉寄站。

DBA,開發人員
檢查這兩個可用性群組中的 LSNS。

檢查 AG 1 和 AG 2 中的最後一個記錄檔序號 (LSNS)。因為沒有寫入發生在 AG 1 中的主要複本中,資料會同步處理,而最後一個 LSNS 的可用性群組應該相符。

DBA,開發人員
將 AG 1 更新為次要角色。

當您將 AG 1 更新為次要角色時,AG 1 會失去主要複本角色,並不接受寫入,並且兩個可用性群組之間的資料流程會停止。

DBA,開發人員
任務描述所需技能
手動容錯移轉至 AG 2。

在 AG 2 轉寄站上,變更分散式可用性群組,以允許資料遺失。因為您已經檢查並確認 AG 1 和 AG 2 上的最後一個 LSNS 相符,資料遺失不是問題。

當您允許在 AG 2 轉寄站上的資料遺失時,AG 1 和 AG 2 的角色變更:

  • AG 2 會成為主要複本和次要複本的可用性群組。

  • AG 1 會成為具有轉寄站和次要複本的可用性群組。

DBA,開發人員
變更 AG 2 上分散式可用性群組的可用性模式。

在 AG 2 中的主要複本上,將可用性模式變更為非同步。

這會變更資料移動從 AG 2 到 AG 1,從同步到非同步。此步驟是為了避免 AG 2 和 AG 1 之間的網路延遲 (如果有的話),而且不會影響資料庫的效能。

DBA,開發人員
開始將流量傳送到新的主要複本。

更新連接字串,以使用 AG 2 上的接聽程式 URL 端點傳送流量至資料庫。

AG 2 現在接受寫入,並將資料傳送至 AG 1 中轉寄站,以及將資料傳送至 AG 2 中自己的次要複本。資料以非同步方式從 AG 2 移至 AG 1。

App 擁有者, 開發人員
任務描述所需技能
卸除 AG 2 上的分散式可用性群組。

監控移轉的計劃時間長度。然後卸除 AG 2 上的分散式可用性群組,以移除 AG 2 和 AG 1 之間的分散式可用性群組安裝程式。這會移除分散式可用性群組組態,並停止從 AG 2 到 AG 1 的資料流程。 

此時,AG 2 在 AWS 上具有高度可用性,其中包含可進行寫入的主要複本和相同可用性群組中的次要複本。

DBA,開發人員
解除委任現場部署伺服器。

解除委任 WSFC 1 中屬於 AG 1 一部分的內部部署伺服器。

系統管理員、系統管理員

相關資源