探索高可用性和災害復原選項

15 分鐘

若要預想虛擬機器 (VM) 的解決方案，您必須先了解 IaaS 式部署的可用性選項。

基礎結構即服務和平台即服務

在可用性方面，IaaS 或 PaaS 的選擇會有所差異。使用 IaaS 時，您有虛擬機器表示您有已安裝 SQL Server 的作業系統。負責 SQL Server 的管理員或群組可以選擇高可用性和災害復原 (HADR) 解決方案，並且對該解決方案的設定方式有很高的掌控權。

使用以 PaaS 為基礎的部署 (例如 Azure SQL Database) 時，HADR 解決方案會內建於功能中，通常只需要啟用即可。可以設定的選項非常少。

由於這些差異，IaaS 或 PaaS 的選擇可能會影響 HADR 解決方案的最終設計。

適用於 Azure 虛擬機器的 SQL Server HADR 功能

使用 IaaS 時，您可以使用 SQL Server 所提供的功能來提高可用性。在某些情況下，您還可以將這些功能與 Azure 層級的功能結合，以進一步提高可用性。

下表顯示 SQL Server 中的可用功能

功能名稱	保護
Always On 容錯移轉叢集執行個體 (FCI)	執行個體
Always On 可用性群組 (AG)	Database
記錄傳送	Database

SQL Server 的執行個體是 SQL Server 的完整安裝 (二進位檔，執行個體內的所有物件包括登入作業、SQL Server Agent 作業和資料庫)。執行個體層級保護表示可用性功能中會納入整個執行個體。

SQL Server 中的資料庫會包含終端使用者和應用程式所使用的資料。有 SQL Server 依賴的系統資料庫，以及為了讓使用者和應用程式使用而建立的資料庫。 SQL Server 的執行個體一律都有自己的系統資料庫。資料庫層級保護表示資料庫中所有項目，或使用者或應用程式資料庫交易記錄中擷取的所有項目，都會視為可用性功能的一部分。存在於資料庫之外或未擷取到交易記錄中的任何項目 (例如 SQL Server Agent 作業和連結的伺服器) 都必須以手動方式處理，以確保目的地伺服器在已規劃或未規劃的容錯移轉事件中，可以像主要伺服器一樣運作。

FCI 和 AG 都需要基礎叢集機制。對於在 Windows Server 上執行的 SQL Server 部署而言，這指的是 Windows Server 容錯移轉叢集 (WSFC)，而對於 Linux 而言，這是 Pacemaker。

Always On 容錯移轉叢集執行個體

FCI 會在安裝 SQL Server 時進行設定。 SQL Server 的獨立執行個體無法轉換為 FCI。系統會為 FCI 指派唯一名稱，以及與叢集中基礎伺服器或節點不同的 IP 位址。名稱和 IP 位址也必須與基礎叢集機制不同。應用程式和終端使用者將會使用 FCI 的唯一名稱來進行存取。此抽象化可讓應用程式無須知道執行個體的執行位置。 Azure 架構的 FCI 與內部部署 FCI 之間的一個主要差異是，Azure 需要內部負載平衡器 (ILB)。 ILB 可用來確保應用程式和終端使用者可以連線到 FCI 的唯一名稱。

當 FCI 容錯移轉到叢集的另一個節點時 (無論是以手動方式起始或因為問題而發生)，整個執行個體會在另一個節點上重新啟動。這表示容錯移轉程序會完整地停止和啟動 SQL Server。任何連線到 FCI 的應用程式或終端使用者都將在容錯移轉期間中斷連線，而且只有可處理此中斷並從中復原的應用程式才能自動重新連線。

在另一個節點上啟動時，執行個體會經歷復原程序。 FCI 會與失敗點一致，因此技術上不會遺失任何資料，但任何需要復原的交易都會在復原過程中遺失資料。如先前所述，由於這是執行個體層級保護，因此所有必要項目 (登入作業、SQL Server Agent 作業等) 都已存在，所以在資料庫就緒之後，就可以一如往常地繼續執行業務。

FCI 需要一個資料庫複本，但這也是其單一失敗點。為了確保另一個節點可以存取資料庫，FCI 需要某種形式的共用儲存體。針對以 Windows Server 為基礎的結構，這可以透過 Azure 進階檔案共用、iSCSI、Azure 共用磁片、儲存空間直接存取 (S2D) 或支援的第三方解決方案 (例如 SIOS DataKeeper) 來達成。使用 SQL Server Standard 版本的 FCI 最多可以有兩個節點。 FCI 也需要使用 Active Directory Domain Services (AD DS) 和網域名稱服務 (DNS)，這表示 AD DS 和 DNS 都必須在 Azure 中的某處執行，如此 FCI 才能運作。

使用 Windows Server 2016 或更新版本時，FCI 可以使用儲存體複本來建立 FCI 的災害復原解決方案，而不需要使用記錄傳送或 AG 之類的其他功能。

Always On 可用性群組

AG 是在 SQL Server 2012 Enterprise 版本中引進的，而且也在 SQL Server 2016 之後開始在 Standard 版本中提供。在 Standard 版本中，AG 可以包含一個資料庫，而在 Enterprise 版本中，AG 可以有一個以上的資料庫。雖然 AG 與 FCI 有些相似處，但大部分還是不同的。

FCI 和 AG 之間的最大差異是 AG 提供資料庫層級保護。主要複本是加入 AG 的執行個體，其中包含讀取/寫入資料庫。次要複本是主要複本透過記錄傳輸來傳送交易以保持同步的地方。主要複本之間的資料移動可以是同步或非同步的。任何次要複本上的資料庫都會處於載入狀態，這表示其可以接收交易，但在該複本變成主要複本之前，不能成為可完整寫入的複本。 Standard 版本中的 AG 最多只能有兩個複本 (一個主要複本、一個次要複本)，而 Enterprise 版本最多可支援 9 個複本 (一個主要複本、八個次要複本)。次要複本會從資料庫備份進行初始化，或是從 SQL Server 2016 開始，您可以使用稱為「自動植入」的功能來進行初始化。自動植入會使用記錄串流傳輸，透過已設定的端點將備份串流到可用性群組中每個資料庫的次要複本。

AG 使用接聽程式來提供抽象化。接聽程式的運作方式就像是指派給 FCI 的唯一名稱，而且其具有自己的名稱和 IP 位址，並且不同於任何其他項目 (WSFC、節點等等)。接聽程式也需要 ILB，而且會經歷停止和啟動。應用程式和終端使用者可以使用接聽程式來連線，但不同於 FCI，如有需要，您可不必使用接聽程式。您可以直接連線到執行個體。使用 Enterprise 版本時，Enterprise 版本中的次要複本也可以視需要設定為唯讀存取，並可用於資料庫一致性檢查 (DBCC) 和備份等其他功能。

相較於 FCI，AG 可以有更短的容錯移轉時間，這是其受歡迎的其中一個原因。雖然 AG 不需要共用儲存體，但每個複本都有一份資料副本，這會增加資料庫的副本總數和整體儲存體成本。儲存體是每個複本本身的儲存體。例如，如果主要複本上的資料庫資料使用量是 1 TB，則每個複本也會有相同的使用量。如果有五個複本，則表示您需要 5 TB 的空間。

請記住，任何存在於資料庫外部或未在資料庫交易記錄中擷取的物件，都必須在需要成為新主要複本的任何其他 SQL Server 執行個體上手動建立及納入考量。您須負責的物件範例包括 SQL Server Agent 作業、執行個體層級的登入作業和連結的伺服器。如果您可以使用 Windows 驗證或使用自主資料庫搭配 AG，則可以簡化存取動作。

許多組織可能會面臨實作高可用性結構的挑戰，而且可能只需要 Azure 平台所提供的高可用性，或使用 Azure SQL 受控執行個體之類的 PaaS 解決方案。在查看 Azure 平台解決方案之前，還有另一項您應該知道的 SQL Server 功能：記錄傳送。

記錄傳送

記錄傳送在 SQL Server 早期就已存在。這項功能是以備份、複製和還原為基礎，而且是為 SQL Server 實現 HADR 最簡單的方法之一。記錄傳送主要用於災害復原，但也可用來提高本機可用性。

記錄傳送 (例如 AG) 會提供資料庫層級保護，這表示您仍然需要考量 SQL Server Agent 作業、連結的伺服器、執行個體層級的登入作業等。記錄傳送本身不提供抽象化，因此切換至參與記錄傳送的另一部伺服器時必須能夠接受名稱變更。如果無法這麼做，可以使用 DNS 別名之類的方式，其可在網路層進行設定，以嘗試緩解名稱變更問題。

記錄傳送機制很簡單：首先，在主要伺服器上進行來源資料庫的完整備份，在另一個執行個體 (也就是次要伺服器或暖待命) 上以載入狀態 (STANDBY 或 NORECOVERY) 將其還原。這個新的資料庫副本就是所謂的次要資料庫。內建於 SQL Server 的自動化程序會接著自動備份主要資料庫的交易記錄，將備份複製到待命伺服器，最後將備份還原到待命伺服器。