この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
困っていた内容
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=idleSTATEを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-16clustermgtdに問題がありそうなのでヘッドノードの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の問題ではありませんでした。以下のブログにまとめていますのでご興味ありましたらご一読ください。
19
