次の方法で共有

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

  • [アーティクル]

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

前提条件

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

現在のランタイム バージョンの確認

アップグレードする前に現在のクラスター ランタイム バージョンを確認します (現在のクラスター ランタイム バージョンを確認する方法)。

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

Azure ポータルの使用

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

使用可能なクラスターのアップグレードを特定するための正しいタブを示す Azure portal のスクリーンショット。

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

使用可能なクラスターのアップグレードを示す Azure portal のスクリーンショット。

Azure CLI を使用する

利用できるアップグレードは、Azure CLI を使って取得できます。

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

出力で、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"
    }
  ],

使用可能なクラスター アップグレードがない場合、この一覧は空です。

クラスターの 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> /
--subscription <subscriptionID>

[Required parameters]\(必須のパラメーター\):

  • strategy-type: 更新戦略を定義します。 "Rack" (ラックごと) または "PauseAfterRack" (一度に 1 つのラックをアップグレードし、確認を待ってから次のラックに進む) を指定できます。 既定値は Rack です。 "PauseRack" 戦略を使用してクラスター ランタイムのアップグレードを実行するには、PauseRack 戦略を使用したクラスター ランタイムのアップグレードに関する記事で説明されている手順に従います
  • threshold-type: 戦略で定義されている単位で適用される、しきい値の評価方法を決定します。 これは、"PercentSuccess" または "CountSuccess" を指定できます。 既定値は PercentSuccess です。
  • threshold-value: 更新を評価するために使われる数値のしきい値。 既定値は 80 です。

省略可能なパラメーター:

  • max-unavailable: オフラインにできるワーカー ノード (つまり、一度にアップグレードされるラック) の最大数。 既定値は 32767 です。
  • wait-time-minutes: ラックを更新する前の遅延または待機期間。 既定値は 15 です。

次の例は、成功率が 60% で、一時停止が 1 分間の "ラックごと" 戦略を使用しているお客様の場合です。

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

更新を確認します。

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

この例では、ラックにプロビジョニングされるコンピューティング ノードのうち、プロビジョニングに成功した割合が 60% 未満の場合 ("ラックごと" の場合)、クラスターのデプロイは失敗します。 60% 以上のコンピューティング ノードが正常にプロビジョニングされると、クラスターのデプロイはコンピューティング ノードの次のラックに移動します。

次の例は、しきい値の種類 CountSuccess がラックあたり 10 ノードで、一時停止が 1 分間の "ラックごと" 戦略を使用しているお客様の場合です。

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

更新を確認します。

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

この例では、ラックにプロビジョニングされるコンピューティング ノードのうち、プロビジョニングに成功した数が 10 個未満の場合 ("ラックごと" の場合)、クラスターのデプロイは失敗します。 10 個以上のコンピューティング ノードが正常にプロビジョニングされると、クラスターのデプロイはコンピューティング ノードの次のラックに移動します。

Note

クラスター ランタイムのアップグレードが開始された後に update-strategy を変更することはできません。しきい値が 100% 未満に設定されている場合、正常ではないノードがアップグレードされていない可能性があるにもかかわらず、"クラスター" の状態はアップグレードが成功したことを示すことがあります。 ベアメタル マシンに関する問題のトラブルシューティングについては、「Azure Operator Nexus サーバーの問題のトラブルシューティング」を参照してください

CLI を使用してクラスター ランタイムをアップグレードする

ランタイムのアップグレードを実行するには、次の Azure CLI コマンドを使います。

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

ランタイムのアップグレードは長いプロセスです。 アップグレードでは、最初に管理ノードをアップグレードし、その後、ワーカー ノードをラックごとに順番にアップグレードします。 各ラックのワーカー ノードの 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 が表示されると、クラスターのアップグレードは完了します

進行中のクラスターのアップグレードを示す Azure portal のスクリーンショット。

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

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

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

よく寄せられる質問

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

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

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

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

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

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

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

ランタイム アップグレード中に、クラスターは Upgrading という状態になります。 ランタイムのアップグレードに失敗すると、クラスターのプロビジョニング状態は Failed になります。 インフラストラクチャ コンポーネント (ストレージ アプライアンスなど) が原因で、アップグレード中に失敗状態になる場合があります。 一部のシナリオでは、Microsoft サポートによるエラーの診断が必要になる場合があります。