このハウツー ガイドでは、Azure API と標準の運用手順を使用して再現可能なエンドツーエンドのアップグレードをユーザーが管理できるように設計された Nexus クラスターをアップグレードするためのステップ バイ ステップ テンプレートを提供します。 通常の更新プログラムは、システムの整合性を維持し、製品の最新の改善を利用するために重要です。
概要
クラスター ランタイム アップグレード テンプレートの概要
ランタイム バンドル コンポーネント: これらのコンポーネントでは、トラフィックの動作に影響を与えたり、サーバーの再起動が必要になる可能性があるアップグレードに対してオペレーターの同意が必要です。 Nexus Cluster の設計により、継続的なワークロード操作を維持しながら更新プログラムを適用できます。
ランタイムの変更は、次のように分類されます。
- ファームウェア/BIOS/BMC 更新プログラム: 新しいサーバー制御機能をサポートし、セキュリティの問題を解決するために必要です。
- オペレーティング システムの更新プログラム: オペレーティング システムの新機能をサポートし、セキュリティの問題を解決するために必要です。
- プラットフォームの更新: 新しいプラットフォーム機能をサポートし、セキュリティの問題を解決するために必要です。
[前提条件]
このテンプレートを使用してクラスターをアップグレードするための前提条件
必須のパラメーター
このドキュメントで使用されるパラメーター
- <ENVIRONMENT>: - インスタンス名
- <AZURE_REGION>: - インスタンスの Azure リージョン
- <CUSTOMER_SUB_NAME>: サブスクリプション名
- <CUSTOMER_SUB_ID>: サブスクリプション ID
- <NEXUS_VERSION>: Nexus リリース バージョン (2504.1 など)
- <NNF_VERSION>: Operator Nexus Fabric リリース バージョン (例: 8.1)
- <NF_VERSION>: アップグレード用の NF ランタイム バージョン (5.0.0 など)
- <NFC_NAME>: 関連するネットワークファブリック制御装置 (NFC)
- <CM_NAME>: 関連付けられたクラスター マネージャー (CM)
- <CLUSTER_NAME>: クラスター名
- <CLUSTER_RG>: クラスター リソース グループ
- <CLUSTER_RID>: クラスター ARM ID
- <CLUSTER_MRG>: クラスターマネージド リソース グループ
- <CLUSTER_CONTROL_BMM>: クラスター コントロール プレーンの baremetalmachine
- <CLUSTER_VERSION>: アップグレードのランタイム バージョン
- <DEPLOYMENT_THRESHOLD>: コンピューティングデプロイのしきい値
- <DEPLOYMENT_PAUSE_MINS>: 現在のラックが展開しきい値を満たすと、次のラックに移動するまでの待ち時間
- <MISE_CID>: デバイス更新プログラムのデバッグ出力における Microsoft.Identity.ServiceEssentials (MISE) の相関 ID
- <CORRELATION_ID>: デバイス更新プログラムのデバッグ出力での操作の関連付け ID
- <ASYNC_URL>: デバイス更新プログラムのデバッグ出力の非同期 (ASYNC) URL
デプロイ データ
デプロイ データの詳細
- Nexus: <NEXUS_VERSION>
- NC: <NC_VERSION>
- NF: <NF_VERSION>
- Subscription Name: <CUSTOMER_SUB_NAME>
- Subscription ID: <CUSTOMER_SUB_ID>
- Tenant ID: <CUSTOMER_SUB_TENANT_ID>
Azure CLI コマンドのデバッグ情報
Azure CLI コマンドのデバッグ情報を収集する方法
--debugで発行された Azure CLI デプロイ コマンドには、コマンド出力に次の情報が含まれています。
cli.azure.cli.core.sdk.policies: 'mise-correlation-id': '<MISE_CID>'
cli.azure.cli.core.sdk.policies: 'x-ms-correlation-request-id': '<CORRELATION_ID>'
cli.azure.cli.core.sdk.policies: 'Azure-AsyncOperation': '<ASYNC_URL>'
実行時間の長い非同期操作の状態を表示するには、 az restを指定して次のコマンドを実行します。
az rest -m get -u '<ASYNC_URL>'
コマンドの状態情報が、詳細情報またはエラー メッセージと共に返されます。
"status": "Accepted""status": "Succeeded""status": "Failed"
エラーが発生した場合は、サポート要求を開くときに、 <MISE_CID>、 <CORRELATION_ID>、状態コード、詳細メッセージを報告します。
事前チェック
クラスターのアップグレードを開始する前の事前チェック
CM とクラスターのプロビジョニングと詳細な状態を検証します。
Azure CLI にログインし、
<CUSTOMER_SUB_ID>を選択または設定します。az login az account set --subscription <CUSTOMER_SUB_ID>CM の
SucceededがProvisioning stateであることを確認します。az networkcloud clustermanager show -g <CM_RG> --resource-name <CM_NAME> --subscription <CUSTOMER_SUB_ID> -o tableクラスターの状態
Detailed statusがRunningされていることを確認します。az networkcloud cluster show -g <CLUSTER_RG> --resource-name <CLUSTER_NAME> --subscription <CUSTOMER_SUB_ID> -o table注
CM
Provisioning stateがSucceededされず、かつクラスターDetailed statusがRunningされていない場合、問題が解決されるまでアップグレードを停止してください。ベアメタル マシン (BMM) の
Detailed status状態がRunningであることを確認します。az networkcloud baremetalmachine list -g <CLUSTER_MRG> --subscription <CUSTOMER_SUB_ID> --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,cordonStatus:cordonStatus,powerState:powerState,kubernetesVersion:kubernetesVersion,machineClusterVersion:machineClusterVersion,machineRoles:machineRoles| join(', ', @),createdAt:systemData.createdAt}, &name)" -o tableBMM ごとに次のリソースの状態を検証します (スペアを除く)。
- ReadyState: True
- プロビジョニングステート: 成功しました
- DetailedStatus: プロビジョニング済み
- コルドンステータス: 非封鎖
- PowerState: オン
1 つのコントロール プレーン BMM には、次の BMM ステータス プロファイルを持つスペアとしてラベルが付けられます。
- ReadyState: 偽
- プロビジョニングステート: 成功しました
- 詳細状態: 利用可能
- コルドンステータス: 非封鎖
- PowerState: Off
テナント ワークロードのプロファイルを収集します。
az networkcloud virtualmachine list --sub <CUSTOMER_SUB_ID> --query "reverse(sort_by([?clusterId=='<CLUSTER_RID>'].{name:name, createdAt:systemData.createdAt, resourceGroup:resourceGroup, powerState:powerState, provisioningState:provisioningState, detailedStatus:detailedStatus,bareMetalMachineId:bareMetalMachineIdi,CPUCount:cpuCores, EmulatorStatus:isolateEmulatorThread}, &createdAt))" -o table az networkcloud kubernetescluster list --sub <CUSTOMER_SUB_ID> --query "[?clusterId=='<CLUSTER_RID>'].{name:name, resourceGroup:resourceGroup, provisioningState:provisioningState, detailedStatus:detailedStatus, detailedStatusMessage:detailedStatusMessage, createdAt:systemData.createdAt, kubernetesVersion:kubernetesVersion}" -o tableこのドキュメントに含まれていない必要なチェックと構成の更新については、Operator Nexus リリース ノートを確認してください。
アップグレード手順
クラスター ランタイムのアップグレード手順の詳細
クラスターのアップグレード設定の既定値
ハードウェアの検証とプロビジョニングに合格するコンピューティング BMM の割合の既定のしきい値は 80% で、Racks 間の既定の一時停止は 1 分です。
update-strategyでは、次の設定を使用できます。
-
Rack- 現在のラックのコンピューティングしきい値が満たされたら、各ラックを一度に 1 つずつアップグレードし、次のラックに移動します。 次のラックを開始する前に、<DEPLOYMENT_PAUSE_MINS> だけ一時停止します。 -
PauseAfterRack- 現在のラックのコンピューティングしきい値が満たされたら、ユーザー API 応答が次のラックに進むのを待ちます。
updateStrategyが設定されていない場合、既定値は次のようになります。
"updateStrategy": {
"maxUnavailable": 32767,
"strategyType": "Rack",
"thresholdType": "PercentSuccess",
"thresholdValue": 80,
"waitTimeMinutes": 1
}
既定とは異なるデプロイしきい値と待機時間を設定する
az networkcloud cluster update -n <CLUSTER_NAME> -g <CLUSTER_RG> --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=<DEPLOYMENT_THRESHOLD> wait-time-minutes=<DEPLOYMENT_PAUSE_MINS> --subscription <CUSTOMER_SUB_ID>
重要
100% しきい値が必要な場合は、事前チェック中に報告された BMM 状態を確認し、アップグレードに進む前にすべての BMM が正常であることを確認します。
更新を検証する:
az networkcloud cluster show -n <CLUSTER_NAME> -g <CLUSTER_RG> --subscription <CUSTOMER_SUB_ID>| grep -A5 updateStrategy
"updateStrategy": {
"maxUnavailable": 32767,
"strategyType": "Rack",
"thresholdType": "PercentSuccess",
"thresholdValue": <DEPLOYMENT_THRESHOLD>,
"waitTimeMinutes": <DEPLOYMENT_PAUSE_MINS>
}
PauseAfterRack戦略を使用してクラスターアップグレードを実行する方法
PauseAferRack 戦略を使用すると、各コンピューティング ラックが構成されたしきい値に達した後、次のラックに進むよう API 呼び出しを要求することで、アップグレードを制御できます。
PauseAfterRackを使用するように戦略を構成するには:
az networkcloud cluster update -n <CLUSTER_NAME> -g <CLUSTER_RG> --update-strategy strategy-type="PauseAfterRack" wait-time-minutes=0 threshold-type="PercentSuccess" threshold-value=<DEPLOYMENT_THRESHOLD> --subscription <CUSTOMER_SUB_ID>
更新を検証する:
az networkcloud cluster show -g <CLUSTER_RG> -n <CLUSTER_NAME> --subscription <CUSTOMER_SUB_ID>| grep -A5 updateStrategy
"updateStrategy": {
"maxUnavailable": 32767,
"strategyType": "PauseAfterRack",
"thresholdType": "PercentSuccess",
"thresholdValue": <DEPLOYMENT_THRESHOLD>,
"waitTimeMinutes": 0
ポータルまたは CLI からアップグレードを実行する
Azure portal からアップグレードを開始するには、[クラスター リソース] に移動し、[
Update] をクリックし、[ <CLUSTER_VERSION>] を選択してから、UpdateAzure CLI からアップグレードを実行するには、次のコマンドを実行します。
az networkcloud cluster update-version --subscription <CUSTOMER_SUB_ID> --cluster-name <CLUSTER_NAME> --target-cluster-version <CLUSTER_VERSION> --resource-group <CLUSTER_RG> --no-wait --debug必要に応じて、さらにトラブルシューティングを行うには、ASYNC URL と関連付け ID の情報を収集します。
cli.azure.cli.core.sdk.policies: 'mise-correlation-id': '<MISE_CID>' cli.azure.cli.core.sdk.policies: 'x-ms-correlation-request-id': '<CORRELATION_ID>' cli.azure.cli.core.sdk.policies: 'Azure-AsyncOperation': '<ASYNC_URL>'アップグレードの問題のサポート チケットを開くときに、この情報を Microsoft サポートに提供してください。
PauseAfterRack戦略中にアップグレードを続行する方法
コンピューティング ラックが成功しきい値を満たすと、アップグレードはユーザーがオペレーターに指示してアップグレードを続行するまで一時停止します。
次のコマンドを使用して、ラックのデプロイしきい値を満たした後にコンピューティング ラックを一時停止した後にアップグレードを続行します。
az networkcloud cluster continue-update-version -g <CLUSTER_RG> -n <CLUSTER_NAME> --subscription <CUSTOMER_SUB_ID>
クラスターの状態を監視する
az networkcloud cluster list -g <CLUSTER_RG> --subscription <CUSTOMER_SUB_ID> -o table
クラスター Detailed status には Running が表示され、アップグレードが完了すると、 Detailed status message に "クラスターが稼働しています。" と表示されます。
ベア メタル マシンの状態を監視する
az networkcloud baremetalmachine list -g <CLUSTER_MRG> --subscription <CUSTOMER_SUB_ID> -o table
az networkcloud baremetalmachine list -g <CLUSTER_MRG> --subscription <CUSTOMER_SUB_ID> --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,cordonStatus:cordonStatus,powerState:powerState,kubernetesVersion:kubernetesVersion,machineClusterVersion:machineClusterVersion,machineRoles:machineRoles| join(', ', @),createdAt:systemData.createdAt}, &name)" -o table
BMM ごとに次の状態を検証します (スペアを除く)。
- ReadyState: True
- プロビジョニングステート: 成功しました
- DetailedStatus: プロビジョニング済み
- コルドンステータス: 非封鎖
- PowerState: オン
- KubernetesVersion: <新しいバージョン>
- マシンクラスターのバージョン: <NEXUS_VERSION>
クラスターと BMM のアップグレードエラーのトラブルシューティング方法
次のトラブルシューティング ドキュメントは、BMM アップグレードの問題の復旧に役立ちます。
トラブルシューティングで問題が解決しない場合は、Microsoft サポート チケットを開きます。
- Azure CLI 出力でエラーを収集します。
- Azure portal または Azure CLI からクラスターと BMM の操作状態を収集します。
- クラスターまたは BMM のアップグレードエラーに対する Azure サポート 要求を作成し、クラスターと VM の ASYNC URL、関連付け ID、および操作状態と共にエラーを添付します。
アップグレード後のタスク
アップグレード後のタスクの詳細な手順
Operator Nexus リリース ノートを確認する
アップグレード後に必要なバージョン固有のアクションについては、Operator Nexus リリース ノートを確認してください。
Nexus インスタンスの検証
Nexus インスタンス準備テスト (IRT) を使用して、すべての Nexus インスタンス リソースの正常性と状態を検証します。
IRT を使用しない場合は、Azure CLI を使用してすべての Nexus Instance コンポーネントのリソース検証を実行します。
# Check `ProvisioningState = Succeeded` in all resources
# NFC
az networkfabric controller list -g <NFC_RG> --subscription <CUSTOMER_SUB_ID> -o table
az customlocation list -g <NFC_MRG> --subscription <CUSTOMER_SUB_ID> -o table
# Fabric
az networkfabric fabric list -g <NF_RG> --subscription <CUSTOMER_SUB_ID> -o table
az networkfabric rack list -g <NF_RG> --subscription <CUSTOMER_SUB_ID> -o table
az networkfabric fabric device list -g <NF_RG> --subscription <CUSTOMER_SUB_ID> -o table
az networkfabric nni list -g <NF_RG> --fabric <NF_NAME> --subscription <CUSTOMER_SUB_ID> -o table
az networkfabric acl list -g <NF_RG> --fabric <NF_NAME> --subscription <CUSTOMER_SUB_ID> -o table
az networkfabric l2domain list -g <NF_RG> --fabric <NF_NAME> --subscription <CUSTOMER_SUB_ID> -o table
# CM
az networkcloud clustermanager list -g <CM_RG> --subscription <CUSTOMER_SUB_ID> -o table
# Cluster
az networkcloud cluster list -g <CLUSTER_RG> --subscription <CUSTOMER_SUB_ID> -o table
az networkcloud baremetalmachine list -g <CLUSTER_MRG> --subscription <CUSTOMER_SUB_ID> --query "sort_by([]. {name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,cordonStatus:cordonStatus,powerState:powerState,machineRoles:machineRoles| join(', ', @),createdAt:systemData.createdAt}, &name)" -o table
az networkcloud storageappliance list -g <CLUSTER_MRG> --subscription <CUSTOMER_SUB_ID> -o table
# Tenant Workloads
az networkcloud virtualmachine list --sub <CUSTOMER_SUB_ID> --query "reverse(sort_by([?clusterId=='<CLUSTER_RID>'].{name:name, createdAt:systemData.createdAt, resourceGroup:resourceGroup, powerState:powerState, provisioningState:provisioningState, detailedStatus:detailedStatus,bareMetalMachineId:bareMetalMachineIdi,CPUCount:cpuCores, EmulatorStatus:isolateEmulatorThread}, &createdAt))" -o table
az networkcloud kubernetescluster list --sub <CUSTOMER_SUB_ID> --query "[?clusterId=='<CLUSTER_RID>'].{name:name, resourceGroup:resourceGroup, provisioningState:provisioningState, detailedStatus:detailedStatus, detailedStatusMessage:detailedStatusMessage, createdAt:systemData.createdAt, kubernetesVersion:kubernetesVersion}" -o table
注
IRT 検証は、Nexus インスタンスのすべてのコンポーネントにわたるネットワークとワークロードの完全な機能テストを提供します。 単純な検証では、機能テストは提供されません。
リンクス
クラスターアップグレードのリファレンス リンク
クラスターアップグレードのリファレンス リンク: