共用方式為

Azure SQL 受控執行個體中的維護時段

  • 發行項

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

維護時段功能可讓您設定 Azure SQL 受控執行個體資源的維護排程，讓具影響力的維護事件可預測，並且對您的工作負載減少干擾。

注意

維護時段功能只會防止來自升級或排程維護的規劃影響。 無法防止所有容錯移轉原因；在維護時段之外可能造成短暫連線中斷的例外狀況，包括硬體失敗和其他重新設定。

事先通知可讓客戶將通知設定為在任何計劃性事件前最多 24 小時傳送。

概觀

Azure 會定期執行 SQL 受控執行個體資源的計劃性維護。 在維護事件期間，SQL 受控執行個體完全可用，但是會受限於 SQL 受控執行個體可用性服務等級協定 (SLA) 內短暫的重新設定。

維護時段適用於不具執行個體重新設定復原能力的生產工作負載，而且無法吸收由計劃性維護事件所造成的短暫連線中斷。 藉由選擇您偏好的維護時段，將其安排在尖峰上班時間外，您可以將計劃性維護的影響降到最低。 復原性工作負載和非生產工作負載可能會依賴 Azure SQL 的預設維護原則。

維護時段是免費的，而且可以在建立時或針對現有的資源進行設定。 您可以使用 Azure 入口網站、PowerShell、CLI 或 Azure API 來設定。

重要

設定維護時段是一項長時間執行的非同步作業，類似於變更 Azure SQL 資源的服務層級。 資源可在作業期間使用，但在作業結束時所發生的短暫重新設定除外，即使在中斷長時間執行的交易時，通常也會持續最多 8 秒的時間。 若要將重新設定的影響降到最低，您應該在尖峰時間以外的時間執行作業。

使用維護時段獲得更多可預測性

根據預設，Azure SQL 維護原則會在當地每天上午 8 點到下午 5 點期間封鎖大部分具影響力的更新，以避免在一般尖峰上班時間期間發生任何中斷。 本地時間取決於託管資源的 Azure 區域位置，而且可能會依照當地時區定義來觀察日光節約時間。

在維護期間，資料庫仍可供使用，但某些更新可能需要容錯移轉。 系統預設維護時段 (下午 5 點到上午 8 點) 將大部分的活動限制在這個時間，但緊急更新可能會在這個時間之外發生。 若要確保所有更新只會在維護期間發生，請選取非預設選項。

可以從兩個非預設維護時段中選擇，將維護更新時段調整為適合您的 Azure SQL 資源的時間：

  • 工作日時段：當地時間下午 10:00 到上午 6:00，週一 - 週四
  • 週末時段：當地時間下午 10:00 到上午 6:00，週五 - 週日

列出的維護時段天數表示每八小時維護時段的開始日期。 例如，「當地時間下午 10:00 到上午 6:00，週一 - 週四」表示維護時段從當地時間每天 (週一到週四) 下午 10:00 開始，並且在當地時間隔日 (週二到週五) 上午 6:00 完成。

一旦進行維護時段選取並完成服務設定，就只會在您選擇的時段期間進行計劃性維護。 雖然維護事件通常會在單一時段中完成，但其中有些可能會跨越兩個以上的相鄰時段。

重要

Azure SQL 受控執行個體遵循一項安全部署實務，確保在 Azure 配對的區域不會同時進行部署。 不過，由於無法預測哪個區域會先升級，因此不保證部署順序。 有時您的主要執行個體會先升級，有時則可能是次要執行個體。

  • 如果您的 SQL 受控執行個體具有容錯移轉群組，且群組與 Azure 區域配對不一致，您應該為主要和次要 SQL 受控執行個體選擇不同的維護時段排程。 例如，您可以為您的異地次要執行個體選取 [工作日] 維護時段，為您的異地主要 SQL 受控執行個體選取 [週末] 維護時段。

  • 在非常罕見的情況下，任何延後的動作可能會造成嚴重的影響，例如套用重大安全性修補程式，可能會暫時覆寫已設定維護時段。

進階通知

您可以設定維護通知，以警示您 Azure SQL 受控執行個體即將推出的計劃性維護事件。 警示會提前 24 小時抵達，在維護期間開始前，以及在維護結束時。 如需詳細資訊，請參閱預先通知。

功能可用性

支援的訂用帳戶類型

設定和使用維護時段適用於下列供應項目類型：隨用隨付、雲端解決方案提供者 (CSP)、Microsoft Enterprise 合約或 Microsoft 客戶合約。

僅限開發/測試使用的供應項目不符合 (例如隨用隨付開發/測試或 Enterprise 開發/測試)。

注意

Azure 供應項目是您擁有之 Azure 訂用帳戶的「類型」。 例如，採用隨用隨付費率的訂用帳戶、Azure in Open 和 Visual Studio Enterprise 皆為 Azure 供應項目。 每個供應項目或方案各有不同的條款和權益。 您的供應項目或方案會顯示在訂用帳戶的概觀上。 如需將您的訂用帳戶切換至不同供應項目的詳細資訊，請參閱將 Azure 訂用帳戶變更為其他供應項目。

支援的服務等級目標

選擇預設值以外的維護時段可以在所有 SLO 上使用，Azure SQL 受控執行個體集區除外。

Azure SQL 受控執行個體區域支援維護時段

為 Azure SQL 受控執行個體選擇預設值以外的維護時段目前適用於下列區域。

閘道維護

在 Azure SQL 受控執行個體中，閘道節點會託管於虛擬叢集內，並具有與 SQL 受控執行個體相同的維護時段。

重要

建議使用重新導向連線原則，將維護事件期間的中斷次數降至最低，請參閱連線類型。

Azure SQL 受控執行個體的考量

Azure SQL 受控執行個體包含服務元件，託管在專用的隔離虛擬機器集合上，這些虛擬機器會在客戶的虛擬網路子網路內執行。 這些虛擬機器會以群組方式組織，形成虛擬叢集，可託管多個受控執行個體。 由於針對相同子網路中的執行個體設定的維護時段可能會影響虛擬叢集和虛擬叢集管理作業內的虛擬機器群組數目，因此在設定維護時段之前，需要考慮一些事項。

維護時段設定是一項長時間執行的作業

託管在相同虛擬機器群組中的所有執行個體都會共用相同的維護時段。 根據預設，所有受控執行個體都託管於具有預設維護時段的群組中。 如果您在建立執行個體時或建立之後，指定另一個維護時段，則執行個體會放入具有對應維護時段的個別機器群組中。 如果叢集中不存在這類群組，則會建立新的群組，以容納執行個體的新組態。 如果您將虛擬叢集中的其他執行個體設定為使用相同的維護時段，這些執行個體也會新增至群組，這表示可能需要調整群組的大小。 將執行個體新增至新的電腦群組，以及調整現有電腦群組的大小，可能會增加作業的持續時間以設定維護時段。

設定受控執行個體維護時段的預期持續時間，可以使用執行個體管理作業的預估持續時間來計算。

重要

當您設定維護時段時，作業的最後一個步驟需要重新設定執行個體，通常會持續最多 8 秒鐘，即使它中斷長時間執行交易也一樣。 若要將影響降至最低，請設定尖峰上班時間以外的維護時段。

IP 位址空間需求

根據虛擬叢集 IP 位址配置，子網路中每個新虛擬機器群組都需要其他 IP 位址。 變更現有受控執行個體的維護時段也需要暫時額外 IP 容量，類似於調整各服務層級的虛擬核心數目時。

IP 位址變更

在子網路的 IP 位址範圍內，設定或變更維護時段會將執行個體的 IP 位址變更為不同的 IP 位址。

重要

請確定網路安全性群組 (NSG) 和防火牆規則不會在 IP 位址變更之後封鎖資料流量。

虛擬叢集管理作業的序列化

影響虛擬叢集的作業，例如服務升級或虛擬叢集調整大小 (例如新增節點或移除不必要的計算節點) 會進行序列化。 因此，在上一個作業完成之前，無法啟動新的虛擬叢集作業。 如果維護時段在進行中的維護作業完成之前關閉，則會保留進行中的維護作業，直到下一個維護時段為止。 在此期間提交的其他管理作業也會保留，並在原始持續維護作業完成之後，於下一個維護時段期間或之後繼續執行。 維護作業所花費的時間超過叢集內每個虛擬機器群組單一維護時段的情形並不常見，但是如果維護作業非常複雜，還是有可能會發生。

虛擬叢集管理作業的序列化是一般行為，也適用於預設維護原則。 設定維護時段排程時，兩個相鄰時段之間的期間可能是數天。 雖然罕見，如果維護作業跨越兩個時段，則新提交的作業可保留數天，可能會封鎖需要其他計算節點的作業，例如建立新的執行個體或調整現有執行個體的大小。

擷取維護事件清單

Azure Resource Graph 是一項 Azure 服務，其旨在延伸 Azure 資源管理。 Azure Resource Graph Explorer 會透過大規模查詢一組指定訂用帳戶的能力，提供有效率且高效能的資源探索，讓您可以有效地治理環境。

您可以使用 Azure Resource Graph Explorer 來查詢維護事件。 如需如何執行這些查詢的簡介，請參閱快速入門：使用 Azure Resource Graph Explorer 執行您的第一個 Resource Graph 查詢。

若要檢查訂用帳戶中所有 SQL 受控執行個體的維護事件，請在 Azure Resource Graph 總管中使用下列範例查詢：

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

如需範例查詢的完整參考，以及如何跨 PowerShell 或 Azure CLI 等工具加以使用，請瀏覽 Azure Resource Graph 的 Azure 服務健康情況範例查詢。

相關內容