淺談實現SQL Server遠距離異地容災
SQL Server 從2012 推出 SQL Alwayson 以來，使我們對SQL Server數據庫容災產生翻天覆地的變化。 其優點很明顯
1、不依賴於特殊硬件
2、可以跨越子網
3、現在已經可以支持到9個副本，包括一個主副本和兩個同步提交輔助副本。
於是我們誕生了像如下圖的容災方案，跨越數據中心的方案，如異地容災。 也有用戶使用此方案實現雲端和本地的數據容災，並且還可以實現故障轉移。
看起來也是很完美的方案，實施的過程中很多用戶發現alwayson會無緣無故的出現故障。在配置過程中可以配置HealthCheckTimeout 屬性以放寬SQL Server的check 時長。
此屬性的默認值爲 60,000 毫秒（60 秒）。 最小值爲 15,000 毫秒（15 秒）。
但是設置了這個參數也會出現問題。因爲在通常的alwayson的依賴於windows 羣集WSFC運行，WSFC雖然現象可以跨越子網，實現多子網的羣集，但是WSFC也需要依賴於心跳進行CHECK系統是否正常。而這個對網絡要求穩定性較高。心跳的時間要求如下 。
| Parameter | Default | Range |
|---|---|---|
| SameSubnetDelay | 1000 milliseconds | 250-2000 milliseconds |
| CrossSubnetDelay | 1000 milliseconds | 250-4000 milliseconds |
| SameSubnetThreshold | 5 | 3-10 |
| CrossSubnetThreshold | 5 | 3-10 |
因此會出現情況，由於物理距離，雲上和本地的延遲不可避免，再由於網絡的波動，會導致windows羣集心跳認爲對方故障，而出現alwayson故障。
因此在運維層面來講，會出現很多的問題。雖然alwayson解決了數據的容災備份的問題，但是網絡很難實現遠距離的高質量的要求。
SQL 2016 有了新的功能，來幫助實現新的構架，滿足跨區域容災備份的要求，並且實現性能橫向的擴展。
分佈式可用性組
這個功能就是 ：分佈式可用性組
分佈式可用性組可爲跨多個數據中心的可用性組提供更加靈活的部署方案。 對於過去在災難恢復等方案中使用日誌傳送等功能的情況，現在甚至可以使用分佈式可用性組。 不過，與日誌傳送不同，分佈式可用性組不得包含延遲的事務應用程序。 這意味着，對於錯誤更新或刪除數據的人爲過失事件，可用性組或分佈式可用性組無法提供幫助。
分佈式可用性組是鬆散耦合的，在這種情況下，這意味着它們無需單個 WSFC 羣集，並且它們由 SQL Server 維護。 由於 WSFC 羣集是單獨進行維護的，且最初在這兩個可用性組之間異步同步，因此很容易在其他站點配置災難恢復。 每個可用性組中的主要副本都同步其自己的次要副本。
-
分佈式可用性組僅支持手動故障轉移。 在切換數據中心的災難恢復情況下，不應配置自動故障轉移（除極少數例外）。
-
很可能無需爲多站點或子網 WSFC 羣集設置某些傳統項或參數（如 CrossSubnetThreshold），但仍需瞭解數據傳輸的另一層的網絡延遲。 不同之處在於，每個 WSFC 羣集都維護其自身的可用性；羣集並非包含四個節點的大型實體。 如上圖所示，實際有兩個單獨的雙節點 WSFC 羣集。
-
建議採用異步數據移動，因爲此方法將用於災難恢復目的。
-
如果在主要副本和第二個可用性組的至少一個次要副本之間配置同步數據移動，並在分佈式可用性組上配置同步移動，則分佈式可用性組將等待，直到所有同步副本確認它們具有數據。
單個分佈式可用性組最多可擁有 16 個次要副本，具體視需要而定。 因此，它最多可擁有 18 個副本供讀取，包括不同可用性組的兩個主要副本。 此方法意味着，多個站點可實現近實時訪問，以便向各應用程序報告。與僅使用單個可用性組相比，分佈式可用性組可幫助擴大隻讀場。 分佈式可用性組可通過兩種方式擴大可讀副本：可使用分佈式可用性組中第二個可用性組的主要副本來創建另一個分佈式可用性組，即使數據庫未處於恢復狀態。還可以使用第一個可用性組的主要副本來創建另一個分佈式可用性組。換句話說，就是主要副本可以參與兩個不同的分佈式可用性組。 下圖顯示 AG 1 和 AG 2 均參與分佈式 AG 1，而 AG 2 和 AG 3 參與分佈式 AG 2。 AG 2 的主要副本（或轉發器）是分佈式 AG 1 的次要副本和分佈式 AG 2 的主要副本。
下圖顯示 AG 1 爲兩個不同分佈式可用性組的主要副本：分佈式 AG 1（包含 AG 1 和 AG 2）和分佈式 AG 2（包含 AG 1 和 AG 3）。
在前面兩個示例中，三個可用性組中至多可以具有 27 個副本，這些副本可用於只讀查詢。
無論是那種分佈式的方案，好處都顯而易見，每個環境中都有一個羣集，因此羣集的檢測可靠性能夠解決，而遠程的容災由alwayson去完成，在數據庫層完成,這樣更加穩定。
分佈式可用性組是一種特殊類型的可用性組，它跨兩個單獨的可用性組。 加入分佈式可用性組的可用性組無需處於同一位置。 它們可以是物理也可以是虛擬的，可以在本地、公有云中或支持可用性組部署的任何位置。 這包括跨域甚至跨平臺 - 例如一個可用性組託管在 Linux ，一個託管在 Windows 上。 只要兩個可用性組可以進行通信，就可以使用它們配置分佈式可用性組。
在SQL 2017 裏面創建alwayson時候可以有三個選項：widows 故障轉移羣集、external、None
-
Windows Server 故障轉移羣集
當可用性組託管在屬於 Windows Server 故障轉移羣集的 SQL Server 的實例上時使用，以實現高可用性和災難恢復。 適用於所有受支持的 SQL Server 版本。
-
EXTERNAL
當可用性組託管在由外部羣集技術（例如 Linux 上的 Pacemaker）管理的 SQL Server 的實例上時使用，以實現高可用性和災難恢復。 適用於 SQL Server 2017 (14.x) 及更高版本。
-
NONE
當可用性組託管在不由羣集技術管理的 SQL Server 的實例上時使用，以實現讀取縮放和負載均衡。 適用於 SQL Server 2017 (14.x) 及更高版本。
因此在SQL 2017 環境中是可以不依賴於windows 羣集，也可以跨越操作系統，提供了更多的容災的方案。 特別是私有云和公有云之間的數據同步和容災實現。