描述適用於 Azure 虛擬機器的 Azure 高可用性和災害復原功能

已完成

Azure 提供三個主要選項來增強 IaaS 部署的可用性:

  • 可用性設定組 (Availability Sets)

  • 可用性區域

  • Azure Site Recovery

這三個選項都在虛擬機器 (VM) 之外,而且不知道在虛擬機器中執行的工作負載類型為何。

可用性設定組

可用性設定組可讓您針對單一資料中心內的 Azure 相關維護和單一失敗點提供運作時間。 這是最先引進 Azure 平台的其中一個可用性功能,其實際上可視為您 VM 的反親和性規則。 也就是說,如果您在可用性設定組或記錄傳送配對中有兩部 SQL Server VM,則這兩個 VM 保證永遠不會在相同的實體伺服器上執行。

可用性設定組會分成容錯網域和更新網域,以支援基本 Azure 基礎結構的這兩個更新。 容錯網域是資料中心內的伺服器集合,其使用相同的電源和網路,資料中心內最多可以有三個容錯網域,如下圖所示的 FD 0、1 和 2。 更新網域 (下圖中標示為 UD 的項目) 表示可同時重新啟動的虛擬機器群組和基礎實體硬體。 不同的更新網域都會確實分隔。

容錯網域和更新網域

可用性設定組和區域無法防止客體系統內的失敗,例如作業系統或 RDBMS 損毀;這就是為什麼您需要執行其他解決方案 (例如 AG 或 FCI) 來確保您符合 RTO 和 RPO。 可用性設定組和區域都是為了限制 Azure 層級的環境問題影響而設計,例如資料中心失敗、實體硬體失敗、網路中斷和電源中斷。

針對多層式應用程式,您應該將應用程式的每一層放在其本身的可用性設定組中。 例如,如果您建立的 Web 應用程式具有 SQL Server 後端和 Active Directory Domain Services (AD DS),則您會為每個階層 (Web、資料庫和 AD DS) 建立可用性設定組。

可用性設定組不是分隔 IaaS VM 的唯一方式。 Azure 也會提供可用性區域,但這兩者無法合併。 您可以選擇其中一個。

可用性區域

可用性區域負責處理 Azure 中的資料中心層級失敗。 每個 Azure 區域皆由許多資料中心所組成,而這些資料中心之間具有低延遲的網路連線。 當您在支援可用性區域的區域中部署 VM 資源時,您可以選擇將這些資源部署到區域 1、2 或 3。 區域是 Azure 區域內唯一的實體位置,也就是資料中心。

區域編號是邏輯表示法。 例如,假設有兩個 Azure 訂閱者將 VM 部署至自己訂閱中的區域 1,這並不表示這些 VM 位於相同的實體 Azure 資料中心。 此外,因為距離的關係,區域部署中可能會有一些額外的延遲。 您應測試 VM 之間的延遲,以確保延遲符合效能目標。 在大部分情況下,往返延遲將會小於 1 毫秒,以支援可用性群組等功能中的同步資料移動。 您也可以將 Azure SQL Database 部署到可用性區域。

Azure Site Recovery

Azure Site Recovery 會為 Azure 層級上的 VM 提供更高的可用性,並可與裝載 SQL Server 的 VM 搭配使用。 Azure Site Recovery 會透過將 VM 從一個 Azure 區域複寫到另一個 Azure 區域,來為該 VM 建立災害復原解決方案。 如先前所述,此功能並不知道 SQL Server 正在 VM 中執行,而且也不知道有關交易的任何資訊。 雖然 Azure Site Recovery 可以符合 RTO,但可能不符合 RPO,因為其不會考量到資料在 SQL Server 內的位置。 Azure Site Recovery 中指定的每月 RTO 為兩小時。 雖然大部分的資料庫專業人員可能偏好使用以資料庫為基礎的方法來進行災害復原,但如果 Azure Site Recovery 符合您的 RTO 和 RPO 需求,其不失為一個好方法。