從 Azure CLI 升級叢集運行時間

發行項
01/19/2024

本操作指南說明安裝必要 Azure CLI 和與操作員 Nexus 互動所需的擴充功能的步驟。

必要條件

必須安裝安裝 Azure CLI。
networkcloud需要 CLI 擴充功能。 networkcloud如果未安裝擴充功能，可以遵循此處所列的步驟來安裝。
要升級目標叢集 Azure 入口網站的存取權。
您必須透過登入與目標叢集相同的訂用帳戶 az login
目標叢集必須處於執行中狀態，且所有控制平面節點狀況良好，且計算節點處於執行中且狀況良好狀態的 80+%。

尋找可用的運行時間版本

透過入口網站

若要尋找可用的可升級運行時間版本，請流覽至 Azure 入口網站中的目標叢集。在叢集的概觀窗格中，流覽至 [可用的升級版本] 索引標籤 。

從 [可用的升級版本] 索引標籤中，我們可以看到目前可用於升級的不同叢集版本。運算子可以從列出的目標運行時間版本中選取。選取之後，繼續升級叢集。

透過 Azure CLI

可用的升級可透過 Azure CLI 擷取：

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

在輸出中，您可以找到 availableUpgradeVersions 屬性並查看 targetClusterVersion 欄位：

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

如果沒有可用的叢集升級，清單會是空的。

使用 CLI 升級叢集運行時間

若要執行運行時間的升級，請使用下列 Azure CLI 命令：

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

運行時間升級是一個漫長的程式。升級會先升級管理節點，然後依機架依背景工作節點的機架排列。當每個機架有 80% 的背景工作節點和 100% 的管理節點已成功升級時，就會將升級視為完成。當機架中的背景工作節點正在升級時，工作負載可能會受到影響，不過所有其他機架中的工作負載不會受到影響。建議您根據此實作設計考慮工作負載放置。

升級所有節點需要數小時的時間，但如果其他進程，例如韌體更新，也屬於升級的一部分，則可能需要更多時間。由於升級程式的長度，建議您定期檢查叢集的詳細數據狀態，以取得升級的目前狀態。若要檢查升級的狀態，請觀察叢集的詳細狀態。此檢查可透過入口網站或 az CLI 完成。

若要透過 Azure 入口網站檢視升級狀態，請流覽至目標叢集資源。在叢集的 [ 概觀 ] 畫面中，會提供詳細狀態以及詳細的狀態消息。

若要透過 Azure CLI 檢視升級狀態，請使用 az networkcloud cluster show。

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

輸出應該是目標叢集的資訊，而叢集的詳細狀態和詳細狀態消息應該會出現。如需升級進度的詳細深入解析，可以檢查每個機架中的個別 BMM 狀態。此範例會在BareMetal Machine角色下的參考區段中提供。

使用叢集 updateStrategy 設定運行時間升級的計算臨界值參數

下列 Azure CLI 命令可用來設定執行時間升級的計算臨界值參數：

az networkcloud cluster update --name "<clusterName>" --resource-group "<resourceGroup>" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> wait-time-minutes=<waitTimeBetweenRacks>

必要自變數：

strategy-type：定義更新策略。在此情況下，「機架」表示更新會逐機架進行。默認值為 “Rack”
threshold-type：決定應如何評估閾值，並套用策略所定義的單位。預設值為 “PercentSuccess”。
threshold-value：用來評估更新的數值臨界值。預設值是 80。

選擇性自變數：

max-unavailable：可以脫機的背景工作節點數目上限，也就是一次升級機架。預設值為 32767。
wait-time-minutes：更新機架前的延遲或等候期間。預設值為 15。

命令的範例用法如下：

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

成功執行命令時，指定的 updateStrategy 值將會套用至叢集：

  "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    },

常見問題集

識別叢集升級停滯/停滯

在運行時間升級期間，升級可能會無法向前移動，但詳細數據狀態會反映升級仍在進行中。 因為運行時間升級可能需要很長的時間才能順利完成，因此目前未指定任何設定的逾時長度。因此，建議您定期檢查叢集的詳細數據和記錄，以判斷升級是否無限期地嘗試升級。

我們可以查看叢集的記錄、詳細訊息和詳細狀態消息，來識別這種情況的時機。如果發生逾時，我們會發現叢集會持續在相同無限期地協調，而不會向前移動。叢集的詳細狀態訊息會反映 "Cluster is in the process of being updated." 從這裡，建議您檢查叢集記錄或設定的 LAW，以查看是否有失敗，或導致進度不足的特定升級。

硬體失敗不需要升級重新執行

如果升級期間發生硬體故障，只要符合計算和管理/控制節點的設定閾值，運行時間升級就會繼續。一旦修正或取代計算機，就會使用目前平臺運行時間的OS進行布建，其中包含運行時間的目標版本。

如果發生硬體故障，且運行時間升級失敗，因為計算和控制節點不符合閾值，可能需要重新執行運行時間升級，視失敗發生的時間和機架中個別伺服器的狀態而定。如果機架在失敗前更新，則在重新布建節點時，將會使用升級的運行時間版本。如果機架規格在硬體故障前未更新為升級的運行時間版本，則會使用先前的運行時間版本布建計算機。若要升級至新的運行時間版本，請提交新的叢集升級要求，且只有具有舊版運行時間的節點才會升級。在先前升級動作中成功主機不會。

在運行時間升級之後，叢集會顯示「失敗」布建狀態

在運行時間升級期間，叢集會在運行時間升級失敗時進入狀態 Upgrading ，因為資源相關，叢集會進入 Failed 布建狀態。此狀態可以連結至與叢集相關的元件生命週期（例如儲存體 Appliance），而且可能需要診斷 Microsoft 支持失敗。

Share via