View a markdown version of this page

PCS AWS クラスターのバージョン更新のトラブルシューティング - AWS PCS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

PCS AWS クラスターのバージョン更新のトラブルシューティング

このトピックは、クラスターのスケジューラバージョンを更新するときに発生する可能性がある一般的な問題を特定して解決するのに役立ちます。

コンピューティングノードが更新後に接続に失敗する

一般的な原因

クラスターを更新すると、新しく起動したコンピューティングノードはコントローラーへの登録に失敗します。ノードは起動しますが、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 のスケジューラログ

コンピューティングノードインスタンスログ

インスタンスコンソールの出力を取得するか、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

インスタンスログの取得の詳細については、「」を参照してくださいインスタンスログを取得する

解像度

コンピューティングノードグループを更新して、新しいクラスターバージョンの互換性ウィンドウ内にスケジューラバージョンを含む 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)

ValidationException でリクエストの更新が拒否されました

一般的な原因

UpdateCluster リクエストは、更新がサポートされていないことを示すValidationExceptionエラーとともにすぐに を返します。これは、次の場合に発生します。

  • ターゲットバージョンが現在のバージョンの互換性ウィンドウ外にあります。

  • ターゲットバージョンはサポート終了 (EOL) として指定され、有効な更新ターゲットではなくなりました。

  • ターゲットバージョンが現在のバージョン以上です (ダウングレードはサポートされていません)。

解像度

ターゲットバージョンが互換性ウィンドウ外にある場合は、複数のステップで更新を実行します。各ステップは、互換性ウィンドウ内でサポートされているバージョンをターゲットにする必要があります。たとえば、23.11 から 25.11 に移行するには、まず 25.05 に更新し、クラスターが に戻るのを待ってから ACTIVE25.11 に更新します。

ターゲットバージョンが EOL の場合は、代わりにサポートされている新しいバージョンを選択します。サポートされているバージョンの詳細については、「」を参照してくださいPCS の Slurm AWS バージョン

クラスターは 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 では解析できない新しい設定ディレクティブが導入されました。互換性ウィンドウ内の他のバージョンとは異なり、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)。 AWS PCS エージェントのバージョンについては、「」を参照してくださいAWS PCS エージェントバージョン

無効な QoS 設定により、更新後にクラスターが使用できない

一般的な原因

バージョン 25.11 に更新すると、クラスターが UPDATE_FAILED 状態になるか、スケジューラが使用できなくなります。ジョブを送信したり、スケジューラコマンドを実行したりすることはできません。スケジューラログには、次のようなエラーが表示されます。

error: Invalid Allow/DenyQOS value: low fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

これは、キュー (パーティション) が AllowQOSDenyQOS、または 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 リファレンスを削除します。