適用於：
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 上的
tempdb和model資料庫，以及記憶體中的計畫快取、緩衝集區與資料行存放區集區。 此無狀態節點是由 Azure Service Fabric 操作，可初始化資料庫引擎、控制節點的健康情況，並在必要時執行容錯移轉至其他節點。 - 具狀態資料層，包含 Azure Blob 儲存體中所儲存的資料庫檔案 (
.mdf和.ldf)。 Azure Blob 儲存體具有內建資料可用性和備援功能。 本地備援可用性是以將您的資料儲存在本地備援儲存體 (LRS) 為基礎，這種儲存體會在主要區域內的單一資料中心中將您的資料複製三次。 其保證將會保留記錄檔中的每筆記錄或資料檔案中的頁面，即使是資料庫引擎程序損毀也一樣。
每當升級資料庫引擎或作業系統，或者偵測到失敗時，Azure Service Fabric 都會將無狀態資料庫引擎程序移至另一個包含足夠可用容量的無狀態計算節點。 Azure Blob 儲存體中的資料不受移動的影響，而資料/記錄檔會連結至新初始化的資料庫引擎程序。 此程序保證高可用性，但因為新的資料庫引擎程序從冷快取開始，所以大量工作負載在轉換期間可能會發生一些效能降低。
下一代一般用途服務層級
次世代通用服務是對現有通用服務層級的架構升級，利用升級後的遠端儲存層將實例資料與日誌檔案儲存在 彈性 SAN 上，取代頁面塊。
下一代通用服務層級的區域冗餘目前仍處於預覽階段。 預覽版也支援 Premium 系列硬體上的 區域 冗餘記憶體。
Important
新一代一般用途區域備援需要 Azure 彈性 SAN 區域備援儲存體 (ZRS)。 因此，在某些支援 SQL 受管理執行個體 區域冗餘的多區域區域中，無法提供此服務。 關於 Elastic SAN ZRS 可用性，請參閱「建立並部署 Azure 彈性 SAN」。
業務關鍵服務層級
業務關鍵服務層級會使用本機存放區可用性模型，此模型會將計算資源 (資料庫引擎程序) 和儲存體 (本機連結的 SSD) 整合在單一節點上。 可用性是藉由將計算和記憶體複寫至其他節點來達成。
基礎資料庫檔案 (.mdf/.ldf) 會放在連接的 SSD 儲存體上，以提供極低延遲 IO 給工作負載。 可用性是使用類似 SQL Server Always On 可用性群組的技術來實作。 叢集包含一個主要副本，供客戶工作負載進行讀寫，另有最多三個次要副本（計算和儲存體），其中包含資料副本。 主要複本會持續依序將變更推送至次要複本，以確保在認可每筆交易之前，資料已持久保存於足夠數量的次要複本上。 此程序可保證，若主要複本或可讀取的次要複本因任何原因而無法使用，始終會有一個已完全同步的複本可供容錯移轉。 容錯移轉是由 Azure Service Fabric 所起始。 一旦次要複本成為新的主要複本，就會建立另一個次要複本，以確保叢集具有足夠的複本數來維持仲裁。 容錯移轉完成後，Azure SQL 連線會自動重新導向至新的主要複本（或依連線字串而定，導向至可讀取的次要複本）。
另一項額外好處是，本機儲存體可用性模型還能將唯讀 Azure SQL 連線重新導向至其中一個次要複本。 這項功能稱為 讀取擴展。它可額外提供 100% 的計算容量，且無需額外費用，將分析工作負載等唯讀作業自主要複本卸載出去。
透過區域備援達到高可用性
區域備援可用性是透過將複本部署在主要區域內的三個 Azure 可用性區域來實現的。 每個可用性區域都是具有獨立電源、冷卻和網路的個別實體位置。
根據預設，本機記憶體可用性模型的節點叢集會在相同的數據中心內建立。 隨著 Azure 可用性區域的推出，SQL 受控執行個體會將不同複本放置到相同區域的不同可用性區域。 為了消除單點故障，控制環也會在多個區域間進行備援部署。 然後，控制平面流量會被路由到同樣部署在多個可用區域的負載平衡器。 從控制平面路由到負載平衡器的流量是由 Azure 流量管理員 (ATM) 控制。
透過區域冗餘配置，你可以讓你的業務關鍵、通用或次世代通用實例具備韌性，能抵禦更多故障，包括災難性資料中心故障，且不需更改應用程式邏輯。 你可以將現有實例轉換成區域冗餘配置。 下一代通用服務層級的區域冗餘目前仍處於預覽階段。
由於區域冗餘實例在不同資料中心有副本，彼此間有一定距離，增加的網路延遲可能會增加交易提交時間，進而影響部分 OLTP 工作負載的效能。 您一律可以停用區域備援設定來回到單一區域設定。 此程序是類似於一般服務層級目標升級的線上作業。 在此流程結束時，執行個體會從區域備援環移轉至單一區域環，或反向移轉。
若要開始使用 SQL 受控執行個體的區域備援，請檢閱設定區域備援。 檢閱 Azure SQL 受控實例 的區域備援可用性 。
一般用途服務層級
在一般用途服務層級中，區域備援是透過將無狀態計算節點放置在不同的可用性區域中來實現，然後再依賴會連結到目前承載作用中 SQL 資料庫引擎程序之節點的具狀態區域備援儲存體 (ZRS)。 當發生中斷時，SQL 資料庫引擎流程會在其中一個無狀態節點變成作用中狀態，然後存取可設定狀態儲存體的資料。
下圖示範一般用途服務層級的區域備援架構：
下一代一般用途服務層級
下一代通用服務層級的區域冗餘目前仍處於預覽階段。 區域冗餘配置將服務元件分散於可用區域，並使用升級後的 Elastic SAN 遠端儲存層。 預覽版支援 Premium 系列硬體的彈性記憶體，因此你可以獨立於 vCore 數量來調整記憶體。
次世代通用區域冗餘需要 Azure 彈性 SAN 區域冗餘儲存（ZRS），但某些支援 SQL 受管理執行個體 區域冗餘的多區域區域無法使用此功能。 關於 Elastic SAN ZRS 可用性，請參閱「建立並部署 Azure 彈性 SAN」。
業務關鍵服務層級
在業務關鍵服務層級，區域備援的達成方式是將計算與儲存體複本放在不同可用性區域，然後使用基礎 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 受控執行個體 會自動執行內部連線測試，監控服務可靠性並加速問題偵測。 這些測試每 10 秒從 SQL 管理實例子網內的內部 IP 位址執行一次，對網路吞吐量與服務效能的影響微乎其微。 其中一個測試透過嘗試使用已知失敗的憑證（）登入，驗證端對端連線，該憑證AzureSQLConnectivityChecker會在稽核日誌、擴展事件及 SQL 錯誤日誌中產生預期失敗的登入紀錄。 這些紀錄很正常，並不代表有安全問題。 欲了解更多資訊，包括如何在日誌中識別測試簽名，請參閱 自動內部連接測試。
結論
Azure SQL 受控執行個體具備與 Azure 平台深度整合的內建高可用性解決方案。 服務仰賴 Service Fabric 偵測失敗和復原、仰賴 Azure Blob 儲存體進行資料保護，以及仰賴可用性區域提高容錯。 此外，業務關鍵服務層級、SQL 受控執行個體會使用 SQL Server Always On 可用性群組技術來進行資料庫複寫和容錯移轉。 這些技術的組合可讓應用程式完全了解混合式儲存體模型的優點，並支援最嚴苛的 SLA。