共用方式為


升級和更新 Azure Service Fabric 叢集

Azure Service Fabric 叢集是您所擁有,但部分由 Microsoft 管理的資源。 本文會說明何時及如何更新 Azure Service Fabric 叢集的選項。

自動升級與手動升級

請一定要確保 Service Fabric 叢集一律會執行支援的執行階段版本。 每當 Microsoft 宣布發行新的 Service Fabric 版本時,從當日起至少 60 天後,舊版就會標示為結束支援。 新的版本會於 Service Fabric 小組部落格上宣布。

叢集執行的版本在到期前 14 天會產生健全狀況事件,使您的叢集進入警告健全狀態。 在您升級至支援的執行階段版本之前,叢集會停留在警告狀態。

您可以將叢集設定為會在 Microsoft 發行 Service Fabric 升級時自動接收,也可以手動地從目前支援的版本清單中選擇。 您可以在 Service Fabric 叢集資源的 [Fabric 升級] 區段中找到這些選項。

在叢集資源的 [網狀架構升級] 區段中選取 [自動或手動升級],Azure 入口網站。

您也可以設定叢集的升級模式,並使用 Resource Manager 範本選取執行階段版本。

自動升級是建議的升級模式,因為此選項可確保叢集保持在受支援狀態,並受益於最新的修正程式和功能,同時也可讓您使用 Wave 部署策略,以最不會干擾工作負載的方式來排程更新。

注意

如果您將現有叢集變更為自動模式,該叢集會註冊加入從新版本開始的下一個升級期間。 新的版本會於 Service Fabric 小組部落格上宣布。 每個升級期間都會選擇最可行的升級路徑,請參閱支援的版本。 手動升級模式會觸發立即升級。

自動升級的 Wave 部署

使用 Wave 部署時,您可以根據工作負載選取升級的成熟度等級,以將升級對於叢集的干擾降到最低。 例如,您可以為各種 Service Fabric 叢集設定「測試 ->階段 ->生產」Wave 部署管線,先測試執行階段升級的相容性,再套用到生產工作負載。

若要加入 Wave 部署,請 (在其部署範本中) 為叢集指定下列其中一個 Wave 值:

  • Wave 0:一有新的 Service Fabric 組建發行就更新叢集。 適用於測試/開發叢集。
  • Wave 1:在新組建發行一週 (七天) 後再更新叢集。 適用於生產階段前/預備叢集。
  • Wave 2:在新組建發行兩週 (14 天) 後再更新叢集。 適用於生產叢集。

您可以註冊要收到電子郵件通知,以在叢集升級失敗時使用通知內所附的連結來獲得進一步的協助。 請參閱 自動升級的 Wave 部署以便開始。

自動升級階段

Microsoft 會維護 Azure 叢集中執行的 Service Fabric 執行階段程式碼和組態。 視情況需要,我們會對軟體執行受監視的自動升級。 升級的項目可能是程式碼、組態或兩者。 為了將這些升級對應用程式造成的影響降至最低,升級會透過下列階段來執行:

階段 1:使用所有叢集健康狀態原則執行升級

在這個階段,升級會一次進行一個升級網域,而已在叢集中執行的應用程式會繼續執行,而不會產生任何停機時間。 升級期間會遵守 (節點健康情況和應用程式健康情況的) 叢集健康情況原則。

如果不符合叢集健康情況原則,則升級會復原,並傳送電子郵件給訂用帳戶的擁有者。 電子郵件中包含下列資訊:

  • 我們必須回復叢集升級的通知。
  • 建議的修復動作 (如果有的話)。
  • 距離我們執行階段 2 之前的天數 (n)。

如果有任何升級因為基礎結構方面的原因而失敗,我們會試著多執行幾次相同的升級。 在電子郵件寄送日期的 n 天之後,我們會繼續進行階段 2。

如果符合叢集健康狀態原則,則升級會被視為成功並標示為完成。 在此階段執行初次升級或重新執行任何升級期間,可能會發生這種情形。 執行成功時不會傳送電子郵件確認,以避免傳送過多的電子郵件。 收到電子郵件表示遇到正常作業以外的狀況。 我們預期大部分的叢集升級都會成功,並不會影響您的應用程式可用性。

階段 2:僅使用預設健康狀態原則執行升級

此階段的健康狀態原則的設定方式為,升級開始時健康狀態良好的應用程式數目在升級程序期間會維持不變。 和階段 1 一樣,階段 2 的升級會一次進行一個升級網域,而已在叢集中執行的應用程式會繼續執行,而不會產生任何停機時間。 升級期間會遵守叢集健康狀態原則 (綜合節點健康狀態和所有在叢集中執行之應用程式的健康狀態)。

如果不符合生效的叢集健康狀態原則,則會回復升級。 然後系統會傳送一封電子郵件給訂用帳戶的擁有者。 電子郵件中包含下列資訊:

  • 我們必須回復叢集升級的通知。
  • 建議的修復動作 (如果有的話)。
  • 距離我們執行階段 3 之前的天數 (n)。

如果有任何升級因為基礎結構方面的原因而失敗,我們會試著多執行幾次相同的升級。 在 n 天到達的前幾天會傳送提醒電子郵件。 在電子郵件寄送日期的 n 天之後,我們會繼續進行階段 3。 您必須認真看待我們在階段 2 寄送的電子郵件並採取補救動作。

如果符合叢集健康狀態原則,則升級會被視為成功並標示為完成。 在此階段執行初次升級或重新執行任何升級期間,可能會發生這種情形。 執行成功不會有任何電子郵件確認。

階段 3:使用積極的叢集健康狀態原則執行升級

此階段的這些健康狀態原則的目的是升級完成,而不是應用程式的健康狀態。 有些叢集升級會在這個階段結束。 如果您的叢集進入這個階段,表示您的應用程式很可能會變成狀況不良和 (或) 失去可用性。

類似其他兩個階段,階段 3 升級會一次進行一個升級網域。

如果不符合叢集健康狀態原則,則會回復升級。 如果有任何升級因為基礎結構方面的原因而失敗,我們會試著多執行幾次相同的升級。 之後,便會鎖住叢集,使它不會再收到支援和 (或) 升級。

系統會傳送含有這項資訊的電子郵件給訂用帳戶擁有者,其中也會附上修復動作。 我們預期不會有任何叢集會進入階段 3 失敗的狀態。

如果符合叢集健康狀態原則,則升級會被視為成功並標示為完成。 在此階段執行初次升級或重新執行任何升級期間,可能會發生這種情形。 執行成功不會有任何電子郵件確認。

手動升級的自訂原則

您可以針對手動的叢集升級來指定自訂原則。 每次您選取新的執行階段版本時便會套用這些原則,以觸發系統來啟動叢集的升級。 如果您不覆寫原則,則會使用預設值。 如需詳細資訊,請參閱設定手動升級的自訂原則

其他叢集更新

除了升級執行階段外,您可能還需要執行一些其他動作,才能讓叢集保持在最新狀態,包括下列各項:

管理憑證

Service Fabric 會使用您建立叢集時指定的 X.509 伺服器憑證,以保護叢集節點之間的通訊以及驗證用戶端。 您可以在 Azure 入口網站或使用 PowerShell/Azure CLI,新增、更新或刪除叢集和用戶端的憑證。 若要深入了解,請參閱新增或移除憑證

開啟應用程式連接埠

您可以透過變更與節點類型相關聯的負載平衡器資源屬性來變更應用程式連接埠。 您可以使用 Azure 入口網站,也可以使用 PowerShell 或 Azure CLI。 如需詳細資訊,請參閱開啟叢集的應用程式連接埠

定義節點屬性

有時候您可以確保工作負載只在叢集中的特定節點類型上執行。 例如,某些工作負載可能需要 GPU 或 SSD,而有些則不用。 針對叢集中的每種節點類型,您可以將自訂節點屬性新增至叢集節點。 條件約束是陳述式,會附加至針對一或多個節點屬性選取的個別服務。 放置條件約束會定義應該執行服務的位置。

如需使用放置條件約束、節點屬性及如何定義它們的詳細資訊,請參閱節點屬性和放置條件約束

新增容量計量

對於每個節點類型,您可以加入您要在應用程式中用來報告負載的自訂容量計量。 如需使用容量度量報告負載的詳細資訊,請參閱《Service Fabric 叢集 Resource Manager 文件》的描述您的叢集度量和負載

自訂叢集的設定

在叢集上可以設定許多不同的組態設定,例如叢集和節點屬性的可靠性層級。 如需詳細資訊,請參閱 Service Fabric 叢集網狀架構設定

注意

針對在 10.0CU6、10.1CU5 和 9.1CU12 之前使用運行時間版本的叢集,如果您修改或計劃修改 FileStoreService 的任何 NTLM 設定,則叢集節點重新啟動時預期會有一些停機時間。 此重新啟動會系結至升級週期期間發生的清除。

此行為已變更為 10.0CU6、10.1CU5 和 9.1CU12,而且在執行這些版本或更新版本的叢集上不應該重新啟動任何節點。

如需 Service Fabric 版本設定的詳細資訊,請參閱 版本頁面

升級叢集節點的作業系統映像

為 Service Fabric 叢集節點啟用自動的作業系統映像升級是最佳做法。 為了達到此目的,您需要滿足幾個叢集需求並採取幾項步驟。 另一個選項是使用修補程式協調流程應用程式 (POA),這個 Service Fabric 應用程式可在 Service Fabric 叢集上將作業系統修補自動化,而不需要停機。 若要深入了解這些選項,請參閱修補 Service Fabric 叢集中的 Windows 作業系統

下一步