Azure VM中的SQL 高可用與DR

以下將介紹在Azure VM中的SQL Server的幾種不同高可用(High Availability)與災難復原(disaster recovery)，以下簡稱HADR。

第一種: Single Region的HA — Always On availability groups

如果只需要高可用性，而不需要DR，則設定 (availability group) AG 是其中一個最普遍的方法(如下圖範例)。

這個架構的效益:

• 此架構會藉由在不同VM上具有多個複本來保護資料。
• 如果適當地實作，此架構可讓實現RTO和RPO，而且只遺失最少資料或完全沒有資料遺失。
• 此架構提供易用的標準化方法，讓應用程式可以存primary 與 secondary replicas (如果將使用read-only replicas等物件的話)。
• 此架構會在上補丁的期間提供強化的可用性。
• 此架構不需要任何shared storage，因此其復雜程度低於使用FCI(failover cluster instance) 時。

第二種: Single Region的HA — Always On Failover Cluster Instance

在導進 AG 之前，FCI 是實現 SQL Server 高可用性的最普遍方式。 不過，FCI 是在實體機部署為主流時所設計的。 在虛擬化世界中，FCI 不會以其在實體硬體上所做的方式提供許多相同的保護，因為 VM 很少會發生問題。 FCI 的設計旨在防範網路卡故障或磁碟故障之類的問題，這兩者不可能發生在 Azure 中。

話雖如此，FCI 在 Azure 中還是有用。 只要我們接受它做甚麼及不能做甚麼，FCI 就是一個完全可以接受的解決方案。 下圖來自 Microsoft 文件，呈現 FCI 部署在使用Storage Spaces Direct的high-level view。

此方式的效益:

• FCI 仍然是普遍的可用性解決方案。
• Shared storage的方式正在利用Azure Shared Disk之類功能進行改善。
• 此架構符合 HA 的大部分 RTO 和 RPO (但不會處理 DR)。
• 此架構提供易用的標準化方法，讓應用程式可以存取 SQL Server 的clustered instance。
• 此架構會在上補丁的期間提供強化的可用性。

第三種: Disaster Recovery — Multi-Region或Hybrid Always On availability group

如果我們是使用 AG，有一個選項是跨多個 Azure Region設定 AG，或可能將 AG 設定為混合式架構。 這表示包含replicas的所有節點都會參與相同的 WSFC。 這個前提是Region的網路效能非常強大，尤其若這是混合式設定的話。 其中一個最大的考量是 WSFC 的witness resource。 此架構需要 AD DS 和 DNS 皆可在每個Region中使用，而且如果這是混合式解決方案，也可能會在地端機房中使用。 下圖顯示使用 Windows Server 在兩個位置上設定的單一 AG 的範例。

此架構的效益:

• 此架構是經過證實的解決方案；這與目前在 AG 拓撲中具有兩個資料中心並無不同。
• 此架構會使用 SQL Server 的 Standard 和 Enterprise Edition。
• AG 本質上提供具有額外資料複本的redundancy。
• 此架構同時具有 HA 和 DR 的功能

第四種: Disaster Recovery — Distributed availability group

Distributed AG 是 SQL Server 2016 之後才有的功能，而且只有Enterprise 版本才有。 其與傳統 AG 不同。 Distributed AG 是由多個 AG 組成，而不是具有一個基礎 WSFC，其中所有節點都包含參與某個 AG 的replica，如上述範例所述。 包含read/write資料庫的primary replica稱為global primary。 第二個 AG 的primary replica稱為forwarder and keeps the secondary replica(s)，並會將該 AG 的secondary replica(s)保持同步。基本上，這是 AG 的 AG。

此架構可容易處理仲裁之類的事情，因為每個叢集都會維護自己的仲裁，這表示其也有自己的見證(quorum)。 無論是整個架構都在Azure上，還是使用混合式架構，Distributed AG 都可以運作。

下圖顯示Distributed AG 設定範例。 有兩個 WSFC。 每個 WSFC 位於不同的 Azure Region中，或一個在地端機房上，另一個在 Azure 中。 每個 WSFC 都有一個具有兩個replicas的 AG。 AG 1 中的global primary replica會將 AG 1 的secondary replica(s)以及forwarder and keeps the secondary replica(s)保持同步，此forwarder and keeps the secondary replica(s)亦是 AG 2 的primary replica。 這個replica會將 AG 2 的secondary replica(s)保持同步。

此架構的效益:

• 如果所有節點都通訊失效，此架構會將 WSFC 分隔為single point of failure
• 在此架構中，有一個primary replica不會同步處理所有的secondary replicas。
• 此架構可提供從某個位置到另一個位置的failing back。

第五種: Disaster Recovery — Log shipping

Log shipping是針對 SQL Server 設定DR的最古老 HADR 方法之一。 如上述，量測的單位是 transaction log backup。 除非已規劃warm standby，確保不會遺失資料，否則這種方式很可能發生資料遺失。 發生DR時，即使是最小的災害，最好也是假設一律有一些資料遺失。 下圖來自 Microsoft 文件log shipping topology範例。

此架構的效益:

• Log shipping是已使用 20 多年的「tried-and-true」功能
• Log shipping很容易部署和管理，因為其是以Backup和Restore為基礎。
• Log shipping可容忍不太穩定的網路。
• Log shipping送符合災害復原的大部分 RTO 和 RPO 目標。
• Log shipping是保護 FCI 的好方法。

第六種:Azure Site Recovery

對於不想以 SQL Server 為基礎來進行DR方案的人，他們可能會選擇 Azure Site Recovery(因為是以VM為主體)。 因為可能他們對SQL Server不熟。不過，只要是DBA仍偏好以資料庫為中心的方法，因為其 RPO 通常較低。而且公司可能比較有錢。以下為 Azure Site Recovery 設定Replica的位置。

此架構的效益:

• Azure Site Recovery 不只使用 SQL Server。
• Azure Site Recovery 可符合 RTO，也可能可符合 RPO。
• Azure Site Recovery 會作為 Azure 平台的一部份提供。

組織可以在一個或多個 Azure Region中部署這以上這些架構，但有許多組織都必須或想要擁有可橫跨地端機房和 Azure 的解決方案，或是能從 Azure 到另一個公有雲的解決方案。 此類型的結構稱為混合式解決方案。

PaaS 解決方案的本質並未設計成允許傳統的混合式解決方案。 HADR 是根據 Azure 基礎架構來提供的。 但有一些例外狀況。 例如，SQL Server 的transactional replication feature可以設定為從位於地端環境 (或另一個雲端) 的publisher複寫到 Azure SQL Managed Instance subscriber (但反過來則不行)。

由於混合式解決方案依賴傳統基礎結構，因此都會以 IaaS 為基礎。 混合式解決方案相當實用。 不僅可以用來協助遷移至 Azure，混合式架構最常見的使用方式是為地端系統建立強大的DR解決方案。 例如，可以在 Azure 中新增 AG 的secondary replica。 這表示任何相關聯的基礎架構都必須存在，例如 AD DS 和 DNS。

對於擴充至 Azure 的混合式 HADR 解決方案而言，最重要的考量是網路量能。 沒有大頻寬可能表示達不到 RTO 和 RPO。 Azure 有一個稱為 ExpressRoute 的網路專線。 如果 ExpressRoute 不是組織能夠有錢玩的東西，有不要用 site-tosite VPN，因為走Internet已經很慢了。還讓它增加overhead來做，更慢。

雖然與傳統上認定的混合式不同，但 Azure 也可以作為資料庫備份的目的地，以及作為備份的cold & archival storage。