翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # PCS AWS クラスターのスケジューラバージョンを更新する 以下の手順を使用して、クラスターのスケジューラバージョンを更新します。ジョブの中断を許容できるかどうかに応じて、2 つのオプションがあります。オプションの選択の詳細については、「」を参照してください[PCS AWS でのクラスターのスケジューラバージョンの更新](working-with_clusters_version_update.md)。 ## オプション 1: ローリング更新 フリートの実行中にコントローラーが更新されます。既存のノードは、ドレインされて置き換えられるまで、以前の Slurm バージョンを使用し続けます。更新後に起動された新しいノードは、ターゲットバージョンを使用します。実行中のジョブは中断されません。 **どのようなときに使うか**: + クラスターコントローラーは Slurm バージョン 24.05 以降です。 + 現在の Slurm バージョンとターゲット Slurm バージョンの両方を含む AMIs を指定できます。 ### ステップ 0 — 開始状態を確認する クラスターでコントローラーバージョン「A」 (例: 24.11) が実行されており、バージョン「B」 (例: 25.11) に移行する場合。クラスターノードから次のコマンドを使用して、フリート内のすべてのコンピューティングノードが同じメジャーバージョンを実行していることを確認します。 ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` コンピューティングノードで AWS PCS エージェントのバージョンを確認します。Systems Manager を使用してノードに接続し、ブートストラップログを確認します。 ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` ローリング更新では、すべてのコンピューティングノード AMIs で AWS PCS エージェントバージョン 1.4.0 以降が必要です。詳細については、「[AWS PCS エージェントバージョン](pcs-agent-versions.md)」を参照してください。 ### ステップ 1 — デュアルバージョン AMIs Slurm バージョン A とバージョン B の両方、および最新の PCS エージェントを含む AMIs を構築または識別します。 ** AWS ** + 最新の **PCS 対応 DLAMIs**を使用できます。このような AMIs、サポートされている最新の 3 つの Slurm バージョンが付属しています。詳細については、「[PCS での PCS 対応 DLAMI AWS の使用](working-with_ami_pcs-ready-dlami.md)」を参照してください。 + Slurm パッケージと PCS エージェントのインストール手順に従って、**カスタム AMI** AWS を構築できます。詳細については、「[PCS のカスタム Amazon AWS マシンイメージ (AMIs)](working-with_ami_custom.md)」を参照してください。 + **AWS PCS サンプル AMI ****を使用することはできません**。このような AMIs は本番稼働用ではなく、現在単一の Slurm バージョンのみが含まれています。 **注記** AMI に 2 つ以上の Slurm バージョンが含まれている場合、 AWS PCS はコントローラーに一致するバージョンを自動的に選択します。追加のバージョンをインストールしても問題は発生しません。 AMIsができたら、次の操作を行います。 1. 各コンピューティングノードグループ`UpdateComputeNodeGroup`で を呼び出して、新しいデュアルバージョン AMI を設定します。ノードは PCS AWS によって DRAIN に設定され、新しい AMI に移行されます。 1. ドレインされたノードがジョブを完了し、終了し、新しいデュアルバージョン AMI を使用してノードに置き換えられるのを待ちます。クラスター内のすべての EC2 インスタンスが、次の方法で新しい AMI を使用していることを確認します。 ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### ステップ 2 — クラスターコントローラーを更新する `UpdateCluster` をバージョン B `scheduler.version`に設定して を呼び出します。 ------ #### [ AWS マネジメントコンソール ] 1. [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/) で AWS PCS コンソールを開きます。 1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。 1. 更新するクラスターを選択し、**編集**を選択します。 1. **クラスターの詳細**で、スケジューラドロップダウンからターゲットスケ**ジューラ**のバージョンを選択します。 1. **更新**を選択してバージョン更新を送信します。 1. クラスターのステータスをモニタリングします。クラスターは更新`UPDATING`中に と表示され、完了`ACTIVE`すると に戻ります。通常、更新は 5～15 分で完了します。 ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` クラスターが に戻るまで待ちます`ACTIVE`。通常、更新は 5～15 分で完了します。 ------ このオペレーション中、コントローラーは一時的に使用できなくなります。 + コンピューティングノードでジョブを実行すると**、引き続き実行されます**。 + 更新が完了するまで、新しいジョブの送信とスケジューラコマンドは使用できません。 + 自動スケーリングは、クラスターが に戻るまで一時停止されます`ACTIVE`。 更新後、コンピューティングフリートは**混合状態**になります。更新前に実行されているノードは引き続き Slurm バージョン A の を使用します`slurmd`。新しいノードは Slurm バージョン B を使用します。これは想定されます。 **注記** フリートにバージョン A のノードがまだ含まれている間は、バージョン B に固有の Slurm 設定を追加しないでください。設定はすべてのノードに分散されます。古い は新しいパラメータを認識しない`slurmd`場合があります。 クラスターが 30 `UPDATE_FAILED`分以内に `ACTIVE`または に戻らない場合は、 AWS サポートにお問い合わせください。 ### ステップ 3 — Slurm バージョン A を実行しているノードをドレインする 以前のバージョンに残っているノードを特定してドレインします。クラスターのノードから、以下を実行します。 ``` scontrol show nodes | grep "Version=" scontrol update NodeName={{node}} State=DRAIN Reason="Slurm version update" ``` ドレインされたノードが現在のジョブを完了すると、それらは終了し、Slurm バージョン B のノードに置き換えられます。 ### ステップ 4 — Slurm バージョン B で一貫したフリートを検証する すべてのノードレポートバージョン B を確認します。クラスターのノードから以下を実行します。 ``` scontrol show nodes | grep "Version=" ``` これで、すべてのノードで Slurm バージョン B が報告されます。更新は完了です。 ## オプション 2: フルフリートのリサイクル フリート全体は、コントローラーが更新される前に終了し、ターゲットの Slurm バージョンを持つ新しい AMI からスケールアップされます。この手順はよりシンプルですが、すべてのノードと実行中のジョブを終了する必要があります。 **どのようなときに使うか**: + 両方の Slurm バージョンがインストールされている AMIs を提供することはできません。 + クラスターコントローラーはバージョン 23.11 です (オプション 1 は 23.11 クラスターでは使用できません）。 **注記** フリート全体を一度に終了すると、スケールアップ時に容量不足エラーが発生する可能性が高くなります。オフピーク時間には、リザーブドキャパシティまたはスケジューリングの使用を検討してください。 ### ステップ 0 — 開始状態を確認する クラスターでコントローラーバージョン「A」 (例: 24.11) が実行されており、バージョン「B」 (例: 25.11) に移行する場合。クラスターノードから次のコマンドを使用して、フリート内のすべてのコンピューティングノードが同じメジャーバージョンを実行していることを確認します。 ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` コンピューティングノードで AWS PCS エージェントのバージョンを確認します。Systems Manager を使用してノードに接続し、ブートストラップログを確認します。 ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` ターゲット AMIs AWS で最新の PCS エージェントを使用します。詳細については、「[AWS PCS エージェントバージョン](pcs-agent-versions.md)」を参照してください。 ### ステップ 1 — ターゲット AMIs を準備する Slurm バージョン B と最新の PCS エージェントを含む AMIs を構築または識別します。 ** AWS ** + 最新の **PCS 対応 DLAMIs**を使用できます。このような AMIs、サポートされている最新の 3 つの Slurm バージョンが付属しています。詳細については、「[PCS での PCS 対応 DLAMI AWS の使用](working-with_ami_pcs-ready-dlami.md)」を参照してください。 + Slurm パッケージと PCS エージェントのインストール手順に従って、**カスタム AMI** AWS を構築できます。詳細については、「[PCS のカスタム Amazon AWS マシンイメージ (AMIs)](working-with_ami_custom.md)」を参照してください。 + **AWS PCS サンプル AMI の使用はお勧めしません**。このような AMIs は本番稼働用に設計されていません。 ### ステップ 2 — フリート全体をスケールダウンする `maxNodeCount` 各コンピューティングノードグループの現在の `minNodeCount`と を記録します。これらはステップ 4 で復元します。 ``` for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do aws pcs get-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier "$cng" \ --query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \ --output table done ``` **警告** 次のオペレーションでは、実行中のすべてのノードとそのジョブを終了します。 すべてのコンピューティングノードグループ`0`で `minNodeCount`と `maxNodeCount` を に設定します。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` 続行する前に、クラスター`aws:pcs:cluster-id`に一致するタグが付けられたインスタンスが実行されていないことを確認します。 ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### ステップ 3 — クラスターコントローラーを更新する ------ #### [ AWS マネジメントコンソール ] 1. [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/) で AWS PCS コンソールを開きます。 1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。 1. 更新するクラスターを選択し、**編集**を選択します。 1. **クラスターの詳細**で、スケジューラドロップダウンからターゲットスケ**ジューラ**のバージョンを選択します。 1. **更新**を選択してバージョン更新を送信します。 1. クラスターのステータスをモニタリングします。クラスターは更新`UPDATING`中に と表示され、完了`ACTIVE`すると に戻ります。通常、更新は 5～15 分で完了します。 ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` クラスターが に戻るまで待ちます`ACTIVE`。通常、更新は 5～15 分で完了します。 クラスターが 30 `UPDATE_FAILED`分以内に `ACTIVE`または に戻らない場合は、 AWS サポートにお問い合わせください。 ------ ### ステップ 4 — コンピューティングノードグループを更新して容量を復元する コンピューティングノードグループごとに、新しい AMI を設定し、元の最小容量制限と最大容量制限を復元します。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --ami-id {{new-ami-id}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` クラスターがスケールアップします。すべての新しいノードは、最新の PCS エージェントを使用して Slurm バージョン B AWS を実行します。 ## 例: 複数のバージョンにわたる更新 ターゲットバージョンが現在のバージョンの互換性ウィンドウ外にある場合は、コントローラーを 1 つ以上の中間バージョンに移動し、一度に 1 ホップずつ更新する必要があります。各ホップは、現在のコントローラーバージョンの互換性ウィンドウ内でサポートされているバージョンをターゲットにする必要があります。 はコントローラーを更新する前にフリートをゼロに[オプション 2: フルフリートのリサイクル](#version_update-procedure-option2)スケールするため、コントローラーがバージョン間で移動している間、コンピューティングノードは実行されません。その結果、AMIs**最終**ターゲットバージョンを直接使用できます。ホップごとにコントローラーの更新 (ステップ 3) のみが繰り返されます。 次の例では、オプション **2 の手順を使用してクラスターを 23.11 から 25.11 に**更新します。 23.11 は 25.11 の互換性ウィンドウ外にあるため、コントローラーは 2 つのホップ (23.11 から 25.05、25.05 から 25.11) で更新されます。オプション 2 のステップに従い、ステップ 3 をホップごとに 1 つの更新に分割します。 1. **ステップ 1 — ターゲット AMIs。****最終**バージョン (25.11) と最新の PCS エージェントを使用して AMIs AWS を構築または識別します。「[ステップ 1 — ターゲット AMIs を準備する](#version_update-procedure-option2-step1)」を参照してください。 1. **ステップ 2 — フリート全体をスケールダウンします。**現在の容量を記録し (「」を参照[ステップ 2 — フリート全体をスケールダウンする](#version_update-procedure-option2-step2))、すべてのコンピューティングノードグループをゼロに設定します。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` 1. **ステップ 3a — コントローラーを 23.11 から 25.05 に更新します。**クラスターが に戻るまで待ちます`ACTIVE`。 ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.05 ``` 1. **ステップ 3b — コントローラーを 25.05 から 25.11 に更新します。**クラスターが に戻るまで待ちます`ACTIVE`。 ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.11 ``` 1. **ステップ 4 — コンピューティングノードグループを更新し、容量を復元します。**各コンピューティングノードグループに 25.11 AMI を設定し、元の容量制限を復元します (「」を参照[ステップ 4 — コンピューティングノードグループを更新して容量を復元する](#version_update-procedure-option2-step4))。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` **注記** 各コントローラーホップは、前のコントローラーホップの互換性ウィンドウ内のバージョンに配置する必要があります。有効な中間バージョンを確認するには、「」を参照してください[バージョン互換性](working-with_clusters_version_update.md#version_update-cluster-compatibility)。フリートはステップ 3a および 3b までゼロのままであるため、中間 AMI の更新は必要ありません。