探索 IaaS 高可用性和災害復原解決方案
有許多不同的功能組合，可以部署在 Azure for IaaS 中。 本節將涵蓋 Azure 中五個常用的 SQL Server 高可用性和災害復原 (HADR) 架構範例。
單一區域高可用性範例 1 – Always On 可用性群組
如果您只需要高可用性，而不需要災害復原，則設定 (可用性群組) AG 是其中一個最普遍的方法，無論您在何處使用 SQL Server。 下圖是單一區域中一個可能 AG 看起來像什麼的範例。
為什麼此結構值得考慮？
此架構會藉由在不同虛擬機器 (VM) 上具有多個複本來保護資料。
如果適當地實作，此架構可讓您實現復原時間目標 (RTO) 和復原點目標 (RPO)，而且只遺失最少資料或完全沒有資料遺失。
此架構提供易用的標準化方法，讓應用程式可以存取主要和次要複本 (如果將使用唯讀複本等物件的話)。
此架構會在修補情節期間提供增強的可用性。
此架構不需要任何共用儲存體，因此其復雜程度低於使用容錯移轉叢集執行個體 (FCI) 時。
單一區域高可用性範例 2 – Always On 容錯移轉叢集執行個體
在引進 AG 之前，FCI 是實作 SQL Server 高可用性的最熱門方式。 不過，FCI 是在實體部署為主流時所設計的。 在虛擬化世界中，FCI 不會以其在實體硬體上所做的方式提供許多相同的保護，因為 VM 很少會發生問題。 FCI 的設計旨在防範網路卡故障或磁碟故障之類的問題，這兩者不可能發生在 Azure 中。
話雖如此，FCI 在 Azure 中還是有其地位。 其可以運作，只要您對提供和不提供的內容有正確的期望，FCI 就是一個完全可以接受的解決方案。 下圖來自 Microsoft 文件，顯示 FCI 部署在使用儲存空間直接存取時看起來像什麼的高階檢視。
為什麼此結構值得考慮？
FCI 仍然是熱門的可用性解決方案。
共用儲存體案例正在利用 Azure 共用磁碟之類功能進行改善。
此架構符合 HA 的大部分 RTO 和 RPO (但不會處理 DR)。
此架構提供易用的標準化方法，讓應用程式可以存取 SQL Server 的叢集執行個體。
此架構會在修補情節期間提供增強的可用性。
災害復原範例 1 – 多區域或混合式 Always On 可用性群組
如果您是使用 AG，有一個選項是跨多個 Azure 區域設定 AG，或可能將 AG 設定為混合式架構。 這表示包含複本的所有節點都會參與相同的 WSFC。 這會假設有良好的網路連線，尤其若這是混合式設定的話。 其中一個最大的考量是 WSFC 的見證資源。 此架構需要 AD DS 和 DNS 皆可在每個區域中使用，而且如果這是混合式解決方案，也可能會在內部部署中使用。 下圖顯示使用 Windows Server 在兩個位置上設定的單一 AG 看起來像什麼。
為什麼此結構值得考慮？
此架構是經過證實的解決方案；這與目前在 AG 拓撲中具有兩個資料中心並無不同。
此架構會使用 SQL Server 的 Standard 和 Enterprise Edition。
AG 自然提供具有額外資料複本的備援。
此架構會使用一項同時提供 HA 和 D/R 的功能
災害復原範例 2 – 分散式可用性群組
分散式 AG 是 SQL Server 2016 中引進的僅限 Enterprise Edition 功能。 其與傳統 AG 不同。 分散式 AG 是由多個 AG 組成，而不是具有一個基礎 WSFC，其中所有節點都包含參與某個 AG 的複本，如上述範例所述。 包含讀寫資料庫的主要複本稱為全域主要複本。 第二個 AG 的主要複本稱為轉寄站，並會將該 AG 的次要複本保持同步。基本上，這是 AG 的 AG。
此架構可讓您更輕鬆地處理仲裁之類的事情，因為每個叢集都會維護自己的仲裁，這表示其也有自己的見證。 無論您是將 Azure 用於所有資源，還是使用混合式架構，分散式 AG 都可以運作。
下圖顯示分散式 AG 設定範例。 有兩個 WSFC。 想像每個 WSFC 位於不同的 Azure 區域中，或一個在內部部署上，另一個在 Azure 中。 每個 WSFC 都有一個具有兩個複本的 AG。 AG 1 中的全域主要複本會將 AG 1 的次要複本以及轉寄站保持同步，此轉寄站亦是 AG 2 的主要複本。 該複本會將 AG 2 的次要複本保持同步。
為什麼此結構值得考慮？
如果所有節點都遺失通訊，此架構會將 WSFC 分隔為單一失敗點
在此架構中，有一個主要複本未同步處理所有次要複本。
此架構可提供從某個位置到另一個位置的容錯回復。
災害復原範例 3 – 記錄傳送
記錄傳送是針對 SQL Server 設定災害復原的最舊 HADR 方法之一。 如上述，測量單位是交易記錄備份。 除非已規劃切換至暖待命，確保不會遺失資料，否則很可能發生資料遺失。 發生災害復原時，即使是最小的災害，最好也是假設一律有一些資料遺失。 下圖來自 Microsoft 文件，顯示記錄傳送拓撲範例。
為什麼此結構值得考慮？
記錄傳送是已使用 20 多年的「試過為真」功能
記錄傳送很容易部署和管理，因為其是以備份和還原為基礎。
記錄傳送可容忍不健全的網路。
記錄傳送符合災害復原的大部分 RTO 和 RPO 目標。
記錄傳送是保護 FCI 的好方法。
災害復原範例 4 – Azure Site Recovery
對於不想以 SQL Server 為基礎來實作災害復原方案的人，他們可能會選擇 Azure Site Recovery。 不過，大部分的資料專業人員仍偏好以資料庫為中心的方法，因為其 RPO 通常較低。
下圖來自 Microsoft 文件。 顯示 Azure 入口網站用來為 Azure Site Recovery 設定複寫的位置。
為什麼此結構值得考慮？
Azure Site Recovery 不只使用 SQL Server。
Azure Site Recovery 可符合 RTO，也可能可符合 RPO。
Azure Site Recovery 會作為 Azure 平台的一部份提供。