共用方式為


透過本機與區域備援達到可用性 - Azure SQL 受控執行個體

適用於:Azure SQL 受控執行個體

本文說明 Azure SQL 受控執行個體架構如何透過本機備援達到可用性,以及透過區域備援達到高可用性。

重要

區域備援組態處於公開預覽狀態,適用於一般用途服務層級,且通常適用於業務關鍵服務層級。

概觀

SQL 受控執行個體是已安裝所有適用修補程式的 Windows 作業系統上,最新穩定版本的 SQL Server 資料庫引擎上執行。 SQL 受控執行個體會自動處理重要的維護工作,例如修補、備份、Windows 和 SQL 資料庫引擎升級,以及基礎硬體、軟體或網路失敗等非計劃性事件。 當修補或容錯移轉執行個體時,如果您在應用程式中採用重試邏輯,則停機時間不明顯。 即使在最關鍵的情況下,Azure SQL 受控執行個體也可以快速復原,確保您的資料隨時可用。 大多數的使用者不會注意到升級是持續進行的。

根據預設,Azure SQL 受控執行個體可透過本機備援達到可用性,讓您的執行個體可在下列期間使用:

  • 客戶起始的管理作業,導致短暫停機
  • 服務維護作業
  • 下列項目的問題與資料中心中斷:
    • 機架,為您服務提供動力的機器於此處執行。
    • 實體機器,裝載執行 SQL 資料庫引擎的 VM。
    • 虛擬機器,執行 SQL 資料庫引擎
  • SQL 資料庫引擎的其他問題
  • 其他潛在非計劃性本機中斷

預設可用性解決方案旨在確保認可的資料絕不會因為失敗而遺失、維護作業不會影響到您的工作負載,以及執行個體不會是您軟體架構中的單一失敗點。

不過,當整個區域發生中斷時,若要對資料的影響降到最低,您可以啟用區域備援來達到高可用性。 若沒有區域備援,容錯移轉會在本機的相同資料中心內進行,這可能導致在中斷解決之前無法使用執行個體,唯一復原方式是利用災害復原解決方案,例如透過 容錯移轉群組或異地備援備份的異地還原來進行。 如欲深入了解,請檢閱商務持續性概觀

高可用性可保護您免受以下各項影響,進而提升服務可靠性:

  • 構成資料中心的可用性區域

根據服務層級,有兩個不同的可用性架構模型:

  • 遠端存放模型是以一般用途下一代一般用途服務層級中的計算和儲存體分隔為基礎,此服務層級仰賴遠端存放的可用性和可靠性,以及由 Azure Service Fabric 管理的計算叢集的可用性。 此可用性模型的適用標的是預算導向、可容許效能在維護活動期間些許下降的商務應用程式。
  • 本機存放區模型是資料庫引擎程序叢集為基礎,該程序仰賴具有本機存放區的業務關鍵服務層級中的可用性資料庫引擎節點的仲裁。 此本機存放區模型是以具有高交易率且需要高 IO 效能的任務關鍵性應用程式為目標。 高可用性架構可確保將維護活動期間對工作負載的影響降至最低。

如需不同服務層級之特定 SLA 的詳細資訊,請檢閱 Azure SQL 受控執行個體的 SLA

透過本機備援達到可用性

本機備援可用性是以將計算節點和資料儲存在主要區域中的單一資料中心為基礎,並在發生本機故障 (例如小規模的網路或電源故障) 時保護您的資料。 如果在某個區域內發生火災或洪水之類的大規模災害,則可能會失去計算節點上儲存體帳戶和資料的所有複本,所有儲存體帳戶複本或無法復原。 因此,若要在使用本機備援可用性選項時進一步保護您的資料,請考慮針對資料庫備份使用更具復原性的儲存體選項。

一般用途服務層級

一般用途服務層級使用遠端存放可用性架構。 下圖顯示四個不同的節點,分別具有個別的計算和儲存層。

圖:顯示計算與儲存體的區隔。

遠端存放可用性模型包含兩層:

  • 無狀態計算層,會執行資料庫引擎程序,而且只包含暫時性和快取資料,例如已連結 SSD 上的 tempdbmodel 資料庫,以及記憶體中的計畫快取、緩衝集區與資料行存放區集區。 此無狀態節點是由 Azure Service Fabric 操作,可初始化資料庫引擎、控制節點的健康情況,並在必要時執行容錯移轉至其他節點。
  • 具狀態資料層,包含 Azure Blob 儲存體中所儲存的資料庫檔案 (.mdf.ldf)。 Azure Blob 儲存體具有內建資料可用性和備援功能。 本機備援可用性是以將資料儲存至本地備援儲存體 (LRS) 為基礎,這會在主要區域中的單一資料中心內複製資料三次。 其保證將會保留記錄檔中的每筆記錄或資料檔案中的頁面,即使是資料庫引擎程序損毀也一樣。

每當升級資料庫引擎或作業系統,或者偵測到失敗時,Azure Service Fabric 都會將無狀態資料庫引擎程序移至另一個包含足夠可用容量的無狀態計算節點。 Azure Blob 儲存體中的資料不受移動的影響,而資料/記錄檔會連結至新初始化的資料庫引擎程序。 此程序保證高可用性,但因為新的資料庫引擎程序從冷快取開始,所以大量工作負載在轉換期間可能會發生一些效能降低。

下一代一般用途服務層級

注意

下一代一般用途服務層級升級目前為預覽狀態。

下一代一般用途是現有一般用途服務層級的架構升級,使用升級的遠端存放層,將執行個體資料和記錄檔儲存在受控磁碟上,而不是儲存於分頁 Blob 並在本機進行維護。

業務關鍵服務層級

業務關鍵服務層級會使用本機存放區可用性模型,此模型會將計算資源 (資料庫引擎程序) 和儲存體 (本機連結的 SSD) 整合在單一節點上。 藉由將計算和儲存體複寫至節點,即可達到高可用性。

圖:資料庫引擎節點的叢集。

基礎資料庫檔案 (.mdf/.ldf) 會放在連接的 SSD 儲存體上,以提供極低延遲 IO 給工作負載。 使用類似 SQL Server Always On 可用性群組的技術,實作高可用性。 叢集包含單一主要複本,可供讀寫客戶工作負載存取,以及最多三個包含資料複本的次要複本 (計算和儲存體) 存取。 主要複本會循序將變更持續推送至次要複本,並確保資料在認可每個交易之前,至少會保存足夠數量的次要複本。 此程序可保證如果主要複本或可讀取次要複本因任何原因而不可用,一律可容錯移轉至完全同步的目標複本。 容錯移轉是由 Azure Service Fabric 所起始。 一旦次要複本變成新的主要複本,就會建立另一個次要複本,以確保叢集有足夠數量的複本來維護仲裁。 容錯移轉完成後,Azure SQL 連線會自動重新導向至新的主要複本 (或基於連接字串的可讀取次要複本)。

本機存放區可用性模型具有額外的優點,包括將唯讀 Azure SQL 連線重新導向至其中一個次要複本的能力。 這項功能稱為讀取縮放。其會從主要複本提供 100% 額外的計算容量,而無需額外費用來卸載唯讀作業,例如分析工作負載。

透過區域備援達到高可用性

區域備援可用性是以將複本放在主要區域中的三個 Azure 可用性區域為基礎。 每個可用性區域都是具有獨立電源、冷卻和網路的個別實體位置。

依照預設,系統會在相同的資料中心內建立本機存放區可用性模型的節點叢集。 隨著 Azure 可用性區域的推出,SQL 受控執行個體會將不同複本放置到相同區域的不同可用性區域。 為了避免發生單一失敗點,系統也會跨多個區域複寫控制環。 然後,控制平面流量會路由傳送至同時部署於可用性區域的負載平衡器。 Azure 流量管理員 (ATM) 會控制從控制平面路由傳送至負載平衡器的流量。

藉由使用區域備援設定,您無須進行任何應用程式邏輯變更,即可讓您的業務關鍵或一般用途執行個體在面對一組更大規模的失敗情況 (包括災難性的資料中心服務中斷) 時,也能夠復原。 您可以將任何現有的業務關鍵或一般用途執行個體轉換成區域備援設定。

因為區域備援執行個體在不同資料中心 (資料中心彼此之間有些距離) 內都有複本,所以增加的網路延遲可能會導致交易認可時間增加,因而影響某些 OLTP 工作負載的效能。 您一律可以停用區域備援設定來回到單一區域設定。 此程序是類似於一般服務層級目標升級的線上作業。 在此程序結束時,執行個體或集區會從區域備援環移轉成單一區域環,或反之亦然。

若要開始使用 SQL 受控執行個體的區域備援,請檢閱設定區域備援

一般用途服務層級

在一般用途服務層級,區域備援的達成方式是將無狀態計算節點放在不同可用性區域,然後依賴可設定狀態的區域備援儲存體 (ZRS),該儲存體所連結的節點目前包含作用中 SQL 資料庫引擎流程。 當發生中斷時,SQL 資料庫引擎流程會在其中一個無狀態節點變成作用中狀態,然後存取可設定狀態儲存體的資料。

下圖示範一般用途服務層級的區域備援架構:

一般用途服務層級的區域備援架構圖表。

注意

對於一般用途服務層級,區域備援目前為預覽版。

業務關鍵服務層級

在業務關鍵服務層級,區域備援的達成方式是將計算與儲存體複本放在不同可用性區域,然後使用基礎 Always On 可用性群組技術,將資料變更從主要執行個體複寫到其他可用性區域的待命複本。 當發生中斷時,會進行自動容錯移轉,可將其中一個待命複本順暢轉換為主要複本。

下圖示範業務關鍵服務層級的區域備援架構:

業務關鍵服務層級的區域備援架構圖表。

測試應用程式錯誤復原

可用性是 SQL 受控執行個體平台的基礎,可為您的資料庫應用程式提供透明的運作。 不過,我們了解您可能想要測試在計劃性或非計劃性事件期間起始的自動容錯移轉作業對應用程式有何影響,然後再將其部署到生產環境。 您可藉由呼叫特殊 API 來重新啟動受控執行個體,以手動觸發容錯移轉。 因為重新開機作業會產生干擾,而且大量的作業可能會對平台造成壓力,所以每個受控執行個體每 15 分鐘只允許一次容錯移轉呼叫。

在真實容錯移轉期間,當 SQL 服務在不同節點成為主要節點時,連線執行個體會失敗。 若要模擬容錯移轉,請叫用重新啟動 SQL 流程的命令,以便模擬啟動服務,就像發生容錯移轉一樣。 不過,相較於模擬容錯移轉,在真實容錯移轉期間,無法連線期間可能更長,因為在真實容錯移轉期間,SQL 流程會在叢集內的另一部虛擬機器成為主要複本 (無論是在本機,或者如已啟用區域備援,則在其他區域),且在模擬容錯移轉期間,SQL 流程會在現有虛擬機器重新啟動。

本節的手動容錯移轉命令在本機備援與區域備援組態的行為通常會相同,其只會在本機重新啟動 SQL 流程,而不會起動另一節點的容錯移轉,但存在些許例外。 此本機容錯移轉不同於容錯移轉群組所發生的容錯移轉。

您可以使用 PowerShell、REST API 或 Azure CLI 來起始本機容錯移轉:

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover SQL 受控執行個體 - 容錯移轉 az sql mi failover 可用來從 Azure CLI 叫用 REST API 呼叫

結論

Azure SQL 受控執行個體和 Azure SQL 受控執行個體具有與 Azure 平台高度整合的內建高可用性解決方案。 服務仰賴 Service Fabric 偵測失敗和復原、仰賴 Azure Blob 儲存體進行資料保護,以及仰賴可用性區域提高容錯。 此外,業務關鍵服務層級、SQL 受控執行個體會使用 SQL Server Always On 可用性群組技術來進行資料庫複寫和容錯移轉。 這些技術的組合可讓應用程式完全了解混合式儲存體模型的優點,並支援最嚴苛的 SLA。

下一步