Share via

Azure CLI からのクラスター ランタイムのアップグレード

  • [アーティクル]

この攻略ガイドでは、Operator Nexus を操作するために必要な Azure CLI と拡張機能をインストールする手順について説明します。

前提条件

  1. Azure CLI をインストールする必要があります。
  2. networkcloud CLI 拡張機能が必要です。 networkcloud 拡張機能がインストールされていない場合は、こちらに記載されている手順のようにしてインストールできます。
  3. アップグレードするターゲット クラスターの Azure portal にアクセスします。
  4. az login を使って、ターゲット クラスターと同じサブスクリプションにログインする必要があります
  5. ターゲット クラスターは、実行状態になっていて、すべてのコントロール プレーン ノードが正常で、コンピューティング ノードの 80% 以上が実行中で正常な状態である必要があります。

使用可能なランタイム バージョンの検索

ポータルを使用

使用できるアップグレード可能なランタイム バージョンを見つけるには、Azure portal でターゲット クラスターに移動します。 クラスターの概要ペインで、[Available upgrade versions] (利用可能なアップグレード バージョン) タブに移動します。

Screenshot of Azure portal showing correct tab to identify available cluster upgrades.

[Available upgrade versions] (利用可能なアップグレード バージョン) タブでは、現在アップグレードに利用できるさまざまなクラスター バージョンを確認できます。 オペレーターは、一覧のターゲット ランタイム バージョンから選択できます。 選んだら、クラスターのアップグレードに進みます。

Screenshot of Azure portal showing available cluster upgrades.

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 portal を使ってアップグレードの状態を確認するには、対象のクラスター リソースに移動します。 クラスターの [概要] 画面には、詳細な状態と詳細なステータス メッセージが表示されます。

detailedStatus が Updating に設定され、detailedStatusMessage にアップグレードの進行状況が示される場合、クラスターのアップグレードは進行中です。 detailedStatusMessage に表示されるアップグレードの進行状況の例としては、Waiting for control plane upgrade to complete...、Waiting for nodepool "<rack-id>" to finish upgrading... などがあります。

detailedStatus が Running に設定され、detailedStatusMessage にメッセージ Cluster is up and running が表示されると、クラスターのアップグレードは完了します

Screenshot of Azure portal showing in progress cluster upgrade.

Azure CLI でアップグレードの状態を確認するには、az networkcloud cluster show を使います。

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

出力はターゲット クラスターの情報であり、クラスターの詳細な状態と詳細なステータス メッセージが含まれるはずです。 アップグレードの進行状況をより詳細に把握するには、各ラック内の個々の BMM の状態を確認します。 この例については、リファレンス セクションの「BareMetal マシンの役割」を参照してください。

クラスターの 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" は、ラックごとに更新を行うことを意味します。 既定値は "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,
    },

よく寄せられる質問

クラスター アップグレードのストールまたはスタックの識別

ランタイムのアップグレードの間に、アップグレードが先に進んでいないのに、詳細な状態ではアップグレードがまだ進行中であることが示される場合があります。 ランタイムのアップグレードは正常に完了するまでに非常に長い時間がかかる可能性があるため、現在は一定のタイムアウトの長さは指定されていません。 そのため、クラスターの詳細な状態とログを定期的に調べて、アップグレードがいつまでもアップグレードを試みているかどうか判断することをお勧めします。

そうなっている場合は、クラスターのログ、詳細メッセージ、詳細なステータス メッセージを調べることで特定できます。 タイムアウトが発生した場合は、クラスターが同じことをいつまでも調整し続けていて、先に進まないことがわかります。 その後は、クラスターのログまたは構成されている LAW を調べて、障害が発生したかどうか、または特定のアップグレードが原因で進行しなくなっているかどうかを確認することをお勧めします。

ハードウェア障害ではアップグレードの再実行は必要ない

アップグレードの間にハードウェア障害が発生した場合、コンピューティング ノードと管理および制御ノードに設定されているしきい値が満たされている限り、ランタイム アップグレードは続行されます。 マシンが修理または交換されると、現在のプラットフォーム ランタイムの OS でプロビジョニングされ、これには対象となるバージョンのランタイムが含まれます。

ハードウェア障害が発生し、コンピューティング ノードと制御ノードのしきい値が満たされなかったためにランタイム アップグレードが失敗した場合、障害が発生したタイミングと、ラック内の個々のサーバーの状態によっては、ランタイム アップグレードの再実行が必要になることがあります。 障害の前にラックが更新された場合、ノードの再プロビジョニング時にはアップグレードされたランタイム バージョンが使われます。 ハードウェア障害が発生する前に、ラックの仕様がアップグレードされたランタイム バージョンに更新されなかった場合、マシンは以前のランタイム バージョンでプロビジョニングされます。 新しいランタイム バージョンにアップグレードするには、新しいクラスター アップグレード要求を送信します。これにより、以前のランタイム バージョンのノードのみがアップグレードされます。 前のアップグレード アクションが正常に行われたホストはアップグレードされません。

ランタイムのアップグレード後に、クラスターに "Failed" というプロビジョニング状態が表示される

ランタイムのアップグレード中、クラスターは Upgrading という状態になります。ランタイムのアップグレードがリソースに関連する理由により失敗した場合、クラスターは Failed というプロビジョニング状態になります。 この状態は、クラスターに関連するコンポーネント (StorageAppliance など) のライフサイクルにリンクされている可能性があり、Microsoft サポートによるエラーの診断が必要な場合があります。