AWS ParallelCluster コンピュートノードのSTATEをdownからidleへ強制的に戻したいときの対処方法について

sinfoで表示されるSTATEをscontrol updateコマンドで強制的に状態を変更する方法を紹介します。
2021.10.08

困っていた内容

sinfoから確認できるSTATEが全ノードdown#状態になってしまいました。ジョブ投げてもなにも反応がありません。切り分けのためにも初期状態に戻し、コンピュートノードが起動しない原因を探りたいです。STATEをdown#からidleへ変更方法を紹介します。

環境

項目
ParallelCluster 3.0.0
OS Ubuntu 20.04 LTS
CPU Graviton2
HeadNode m6g.large
ComputeNode c6g.8xlarge

状況

ジョブを実行してもコンピュートノードは起動すらしませんでした。squeueから確認するとReqNodeNotAvail, UnavailableNodes:のメッセージが表示されます。

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 5  cpu-spot motorBik   ubuntu PD       0:00     16 (ReqNodeNotAvail, UnavailableNodes:cpu-spot-dy-c6g8xlarge-[1-16])

sinfoから確認するとSTATEがdown#となっています。初期状態はidle~です。

$ sinfo
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpu-spot*        up   infinite     16  down# cpu-spot-dy-c6g8xlarge-[1-16]
cpu-spot*        up   infinite      4  idle~ cpu-spot-dy-c6g8xlarge-[17-20]

ちなみに全ノードdown状態でジョブを追加登録するとNodes required for job are DOWN, DRAINED or reserved for jobs in higher priority partitionsのメッセージが表示されるようになります。

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                12  cpu-spot  test.sh   ubuntu PD       0:00      1 (Nodes required for job are DOWN, DRAINED or reserved for jobs in higher priority partitions)

ドキュメントから各エラーメッセージの意味を確認します。

ReqNodeNotAvailとは

Some node specifically required by the job is not currently available. The node may currently be in use, reserved for another job, in an advanced reservation, DOWN, DRAINED, or not responding. Nodes which are DOWN, DRAINED, or not responding will be identified as part of the job's "reason" field as "UnavailableNodes". Such nodes will typically require the intervention of a system administrator to make available.

DeepL翻訳

そのジョブで必要とされるノードが、現在利用できません。そのノードは、現在使用中、他のジョブのために予約されている、事前予約中、DOWN、DRAINED、または応答していない可能性があります。DOWN、DRAINED、または応答しないノードは、ジョブの "reason "フィールドの一部として、"UnavailableNodes "として識別されます。このようなノードを使用可能にするには、通常、システム管理者の介入が必要となります。

Down状態とは

The node is unavailable for use. Slurm can automatically place nodes in this state if some failure occurs. System administrators may also explicitly place nodes in this state. If a node resumes normal operation, Slurm can automatically return it to service. See the ReturnToService and SlurmdTimeout parameter descriptions in the slurm.conf(5) man page for more information.

DeepL翻訳

そのノードは使用できません。Slurm は、何らかの障害が発生した場合、自動的にノードをこの状態にすることができます。システム管理者が明示的にノードをこの状態にすることもできます。ノードが正常な動作を再開した場合、Slurm は自動的にそのノードをサービスに戻すことができます。詳細は、slurm.conf(5) man ページの ReturnToService と SlurmdTimeout パラメータの説明をご覧ください。

オンプレミスのHPC環境とは異なり、クラウドHPC(AWS ParallelCluster)ではコンピュートノードは常時存在していません。必要なときに必要な台数サーバが起動してきて計算します。ですので「ノードが正常な動作を再開した場合」が起こりうるのか定かではありません。ノードのSTATEを強制的に変更できるか試してみます。

対処

scontrol updateを使ってSTATEを強制変更できます。原因切り分けのためにもdown状態を解除し、idle状態へ戻してみます。

ノード名の確認

sinfo-Rオプションを問題のあるノードと、理由が表示され確認しやすいです。 問題のあるノードのSTATEはdown, drained, fail, failingを指します。

$ sinfo -R
REASON               USER      TIMESTAMP           NODELIST
Failure when resumin root      2021-10-08T07:42:46 cpu-spot-dy-c6g8xlarge-[1-16]

sinfo -Rlとすると、現在のノードの状態(STATE)も追加されちょっと便利です。1ノード単位で表示されるため、多数ノードに問題があるときは表示される行数が多くなります。

$ sinfo -Rl
Fri Oct 08 11:40:10 2021
REASON               USER         TIMESTAMP           STATE  NODELIST
Failure when resumin root(0)      2021-10-08T09:12:01 down#  cpu-spot-dy-c6g8xlarge-1
Failure when resumin root(0)      2021-10-08T09:14:31 down#  cpu-spot-dy-c6g8xlarge-2
Failure when resumin root(0)      2021-10-08T09:27:01 down#  cpu-spot-dy-c6g8xlarge-7
...snip...

STATE強制変更

sudo付けてscontrolを実行しようとするとPATHが通ってなく実行できませんでした。 スーパーユーザーに切り替えて作業を行います。

sudo su -

scontrol updateコマンドを使います。nodename=にはsinfoで表示されるNODELISTの表示名を入力します。state=ideleと指定します。

scontrol update nodename=cpu-spot-dy-c6g8xlarge-[1-16] state=idle

STATEをidele~状態に戻せました。

# sinfo
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpu-spot*        up   infinite     20  idle~ cpu-spot-dy-c6g8xlarge-[1-20]

これで初期状態へ強制的に戻せました。

おわりに

結局のところ原因がわかっていません。ヘッドノードのslurm_resume.logを確認すると以下のエラーメッセージが確認できました。

ERROR - No valid clustermgtd heartbeat detected, clustermgtd is down! Please check clustermgtd log for error.

/var/log/parallelcluster/slurm_resume.log

2021-10-08 12:25:00,858 - [slurm_plugin.common:expired_clustermgtd_heartbeat] - ERROR - Clustermgtd has been offline since 2021-09-18 08:43:41.894590+00:00. Current time is 2021-10-08 12:25:00.853393+00:00. Timeout of 300 seconds has expired!
2021-10-08 12:25:00,858 - [slurm_plugin.resume:_resume] - ERROR - No valid clustermgtd heartbeat detected, clustermgtd is down!
Please check clustermgtd log for error.
Not launching nodes cpu-spot-dy-c6g8xlarge-16

clustermgtdに問題がありそうなのでヘッドノードのclustermgtdを確認してみたもののエラーメッセージはなく手がかりがありません。

/var/log/parallelcluster/clustermgtd

2021-09-18 08:42:41,876 - [slurm_plugin.clustermgtd:_terminate_orphaned_instances] - INFO - Checking for orphaned instance
2021-09-18 08:43:36,729 - [slurm_plugin.clustermgtd:_get_config] - INFO - Reading /etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf
2021-09-18 08:43:36,731 - [slurm_plugin.clustermgtd:manage_cluster] - INFO - Managing cluster...
2021-09-18 08:43:36,744 - [slurm_plugin.clustermgtd:_manage_compute_fleet_status_transitions] - INFO - Current compute fleet status: RUNNING
2021-09-18 08:43:36,745 - [slurm_plugin.clustermgtd:manage_cluster] - INFO - Retrieving nodes info from the scheduler
2021-09-18 08:43:41,799 - [slurm_plugin.clustermgtd:_get_ec2_instances] - INFO - Retrieving list of EC2 instances associated with the cluster
2021-09-18 08:43:41,893 - [slurm_plugin.clustermgtd:_perform_health_check_actions] - INFO - Performing instance health check actions
2021-09-18 08:43:41,893 - [slurm_plugin.clustermgtd:_maintain_nodes] - INFO - Performing node maintenance actions
2021-09-18 08:43:41,894 - [slurm_plugin.clustermgtd:_maintain_nodes] - INFO - Following nodes are currently in replacement: (x0) []
2021-09-18 08:43:41,894 - [slurm_plugin.clustermgtd:_terminate_orphaned_instances] - INFO - Checking for orphaned instance

クラスターの設定に間違いがあったのかと思いコンフィグファイルを流用し、CPUをAMDのインスタンスに変更したクラスターを新規に作成しました。コンピュートノードは問題なく起動し問題ありませんでした。 リリース間もないAWS ParallelCluster 3.0.0 と Graviton2のインスタンスの組み合わせを疑いたくなります。あえて地雷を踏むためにGraviton2を使ってはいるものの解決方法が見つからなくて今回ばかりは参っています。

ちなみに過去にGraviton2で動作した実績はあります。ですので、一概に組み合わせが悪いわけではないと思っています。

追記
原因がわかりました。Graviton2の問題ではありませんでした。
以下のブログにまとめていますのでご興味ありましたらご一読ください。

参考