翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # PCS AWS クラスターのバージョン更新のトラブルシューティング このトピックは、クラスターのスケジューラバージョンを更新するときに発生する可能性がある一般的な問題を特定して解決するのに役立ちます。 + [コンピューティングノードが更新後に接続に失敗する](#update-troubleshooting-nodes-fail) + [ValidationException でリクエストの更新が拒否されました](#update-troubleshooting-validation-error) + [クラスターは UPDATING 状態のままです](#update-troubleshooting-stuck-updating) + [更新後にクラスターが UPDATE\_FAILED 状態になる](#update-troubleshooting-update-failed) + [設定解析エラーによりコンピューティングノードが起動しない](#update-troubleshooting-config-parse) + [無効な QoS 設定により、更新後にクラスターが使用できない](#update-troubleshooting-qos-bootloop) ## コンピューティングノードが更新後に接続に失敗する ### 一般的な原因 クラスターを更新すると、新しく起動したコンピューティングノードはコントローラーへの登録に失敗します。ノードは起動しますが、`sinfo`出力には表示されず、コンピューティングノードグループはインスタンスを繰り返し循環することがあります。これは、コンピューティングノードグループの AMI に、新しいコントローラーバージョンの互換性ウィンドウ外のスケジューラバージョンが含まれている場合に発生します。 たとえば、クラスターを 24.11 から 25.11 に更新しても、コンピューティングノードグループが Slurm 23.11 の AMI を使用している場合、23.11 が 25.11 の互換性ウィンドウ外にあるため、新しいインスタンスは接続できません。 ### 診断方法 この問題は、次の 2 つの場所でログを確認することで確認できます。 **スケジューラログ** スケジューラのログ記録が有効になっている場合は、CloudWatch Logs のスケジューラログに次のようなエラーがないか確認してください。 ``` error: unpack_header: protocol_version 10240 not supported error: slurm_unpack_received_msg: [{{ip-10-0-1-23}}] Incompatible versions of client and server code ``` これらのエラーは、互換性のないスケジューラバージョンのコンピューティングノードがコントローラーに接続しようとしていることを示しています。スケジューラのログ記録の設定については、「」を参照してください[PCS AWS のスケジューラログ](monitoring_scheduler-logs.md)。 **コンピューティングノードインスタンスログ** インスタンスコンソールの出力を取得するか、Systems Manager 経由で接続し、ブートストラップログに次のようなエラーがないか確認します。 ``` error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server error: _establish_configuration: failed to load configs error: slurmd initialization failed ``` インスタンスログの取得の詳細については、「」を参照してください[インスタンスログを取得する](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs)。 ### 解像度 コンピューティングノードグループを更新して、新しいクラスターバージョンの互換性ウィンドウ内にスケジューラバージョンを含む AMI を使用します。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} ``` クラスターと互換性のあるスケジューラのバージョンを確認するには、「」を参照してください[バージョン互換性](working-with_clusters_version_update.md#version_update-cluster-compatibility)。 正しいスケジューラバージョンでカスタム AMIs「」を参照してください[PCS AWS 用の Amazon マシンイメージ (AMIs)](working-with_ami.md)。 ## ValidationException でリクエストの更新が拒否されました ### 一般的な原因 `UpdateCluster` リクエストは、更新がサポートされていないことを示す`ValidationException`エラーとともにすぐに を返します。これは、次の場合に発生します。 + ターゲットバージョンが現在のバージョンの[互換性ウィンドウ](https://slurm.schedmd.com/upgrades.html#compatibility_window)外にあります。 + ターゲットバージョンはサポート終了 (EOL) として指定され、有効な更新ターゲットではなくなりました。 + ターゲットバージョンが現在のバージョン以上です (ダウングレードはサポートされていません）。 ### 解像度 ターゲットバージョンが互換性ウィンドウ外にある場合は、複数のステップで更新を実行します。各ステップは、互換性ウィンドウ内でサポートされているバージョンをターゲットにする必要があります。たとえば、23.11 から 25.11 に移行するには、まず 25.05 に更新し、クラスターが に戻るのを待ってから `ACTIVE`25.11 に更新します。 ターゲットバージョンが EOL の場合は、代わりにサポートされている新しいバージョンを選択します。サポートされているバージョンの詳細については、「」を参照してください[PCS の Slurm AWS バージョン](slurm-versions.md)。 ## クラスターは UPDATING 状態のままです ### 一般的な原因 クラスターは想定よりも長く (20 分以上) `UPDATING`状態を維持します。これは、更新プロセス中の一時的な内部問題が原因で発生する可能性があります。 ### 解像度 AWS PCS は、 `UPDATING`状態でスタックしているクラスターを自動的に復旧します。クラスターが 30 `UPDATE_FAILED`分以内に `ACTIVE`または に戻らない場合は、 AWS サポートにお問い合わせください。 ## 更新後にクラスターが UPDATE\_FAILED 状態になる ### 一般的な原因 クラスターは更新中に `UPDATE_FAILED`状態に移行します。これは、一時的なサービスエラーにより更新が正常に完了できない場合に発生する可能性があります。 ### 解像度 同じ`UpdateCluster`リクエストを再度送信して、更新を再試行します。`UPDATE_FAILED` 状態のクラスターは、新しい更新リクエストを受け入れます。更新が引き続き失敗する場合は、 AWS サポートにお問い合わせください。 ## 設定解析エラーによりコンピューティングノードが起動しない ### 一般的な原因 クラスターを更新すると、コンピューティングノードは起動に失敗し、`sinfo`出力に表示されません。コンピューティングノードインスタンスログには、次のようなエラーが表示されます。 ``` error: _parse_next_key: Parsing error at unrecognized key: {{HashPlugin}} error: Invalid DebugFlag: {{AuditRPCs}} fatal: Unable to process configuration file ``` これは、スケジューラバージョン 23.11 を実行しているコンピューティングノードが新しいクラスターバージョンから設定を受信した場合に発生します。23.11 以降のスケジューラバージョンでは、23.11 では解析できない新しい設定ディレクティブが導入されました。[互換性ウィンドウ](https://slurm.schedmd.com/upgrades.html#compatibility_window)内の他のバージョンとは異なり、23.11 コンピューティングノードは認識されない設定キーで致命的なエラーが発生するため、新しいクラスターに接続できません。 この問題は、カスタム AMI が v1.4.0 より前の AWS PCS エージェントバージョンを使用している場合にも発生する可能性があります。古いエージェントバージョンは、コンピューティングノードデーモンの自動バージョンフォールバックをサポートしていません。 ### 解像度 以下の要件に従ってカスタム AMI を再構築します。 + スケジューラバージョン 24.05 以降 + AWS PCS エージェントバージョン 1.4.0 以降 次に、コンピューティングノードグループを更新して新しい AMI を使用します。 ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} ``` カスタム AMIs「」を参照してください[PCS AWS 用の Amazon マシンイメージ (AMIs)](working-with_ami.md)。 AWS PCS エージェントのバージョンについては、「」を参照してください[AWS PCS エージェントバージョン](pcs-agent-versions.md)。 ## 無効な QoS 設定により、更新後にクラスターが使用できない ### 一般的な原因 バージョン 25.11 に更新すると、クラスターが `UPDATE_FAILED` 状態になるか、スケジューラが使用できなくなります。ジョブを送信したり、スケジューラコマンドを実行したりすることはできません。スケジューラログには、次のようなエラーが表示されます。 ``` error: Invalid Allow/DenyQOS value: {{low}} fatal: Partition {{my-queue}} has an invalid DenyQOS ({{low}}), please check your configuration ``` これは、キュー (パーティション) が `AllowQOS`、`DenyQOS`、または Slurm アカウンティングデータベースに存在しない`QOS`設定を通じて QoS 名を参照する場合に発生します。Slurm 25.11 では、スケジューラの起動時に QoS リファレンスのより厳格な検証が導入されました。以前のバージョンでは、存在しない QoS 名への参照をエラーなしで許可していました。 ### 解像度 バージョン 25.11 に更新する前に、キュー設定で参照されるすべての QoS 名がアカウンティングデータベースに存在することを確認します。ログインノードに接続し、次のコマンドを実行して QoS が存在するかどうかを確認します。 ``` sacctmgr show qos where name={{low}} format=name ``` QoS が存在しない場合は、更新を試みる前に作成します。 ``` sacctmgr add qos {{low}} ``` または、キューの Slurm カスタム設定を更新して、クラスターを更新する前に `AllowQOS`、、または `QOS`パラメータを削除することで`DenyQOS`、キュー設定から QoS リファレンスを削除します。