AWS ParallelCluster コンピュートノードが終了するまでの時間設定

AWS ParallelClusterは計算したいときに好きな分だけクラウドの計算リソースを使って、使った分だけ課金される、そんな素敵で経済的なクラスター環境です。

コンピュートノードがジョブ処理終了後、コンピュートノードが削除されるまでの動作を検証しました。

結論

• コンピュートノードはジョブ待ちの状態が一定時間超えると終了（Terminate）する
  • デフォルトの設定値は10分で終了
• 削除までの待ち時間はAWS ParallelClusterの設定ファイルで変更できる
• ただし、クラスター作成時に 待ち時間の設定項目を明示的に記述した場合に限る

検証環境

基本動作

AWS ParallelClusterのコンピュートノードの動作を復習します。

コンピュートノードの起動台数は0台の状態からのスタートです。

1. ジョブスケジューラにジョブを登録するとコンピュートノードが起動します。
2. 起動したコンピュートノードはジョブ実行します。
3. ジョブ終了後、次のジョブを待ちで 一定時間 待機します。
4. 一定時間経過後、ジョブが割り当てられなければ 終了（Terminate） します。

一定時間は10分がデフォルト値です。つまり、ジョブ終了後10分以内に追加のジョブがコンピュートノードに割り当てられなければ 暇しているので削除 されます。浮いた計算リソースは解放し、使った分だけ課金される良心的なクラスター環境が標準設定になっています。

Parallelclusterの設定項目

一定の待機時間を変更にするには2箇所あります。

[cluster]セクション

クラスター作成後に変更ができない項目です。変更する予定があるなら最初に設定しないと後々変更できないため注意してください。

管理名をcustomしています。

[cluster xxx]
...
scaling_settings = custom

• [cluster] section - AWS ParallelCluster

[scaling]セクション

管理名customの設定内容は別のセクション[scaling]に記述します。[scaling]セクションはこの設定を記述しない限り存在しないので新規でセクションごと記述することになります。

書式： [scaling 管理名]

[scaling custom]
scaledown_idletime = 10

scaledown_idletimeの 10分 はクラスター作成後に変更できます。10分指定でクラスターを作成するとデフォルト値と同じです。 クラスター作成後に 変更できる項目 であるため、デフォルト値でも設定しておくと柔軟性を持たせられます。

• [scaling] section - AWS ParallelCluster

検証クラスターコンフィグ全文

コンピュートノードはマルチキューモードを設定しています。コンピュートノードがオンデマンド起動と、スポットインスタンス起動するかをパーティションで分けています。

scaledown_idletimeは 5分 設定にしました。オンデマンドと、スポットともに設定値が有効か検証します。

下記の項目は環境に依存します。

• aws_region_name
• key_name
• s3_read_resource
• vpc_id
• master_subnet_id
• compute_subnet_id
• use_public_ips

# v2.10.2
[aws]
aws_region_name = us-east-1

[aliases]
ssh = ssh {CFN_USER}@{MASTER_IP} {ARGS}

[global]
cluster_template = default
update_check = true
sanity_check = true

[cluster default]
key_name = sandbox-key-useast1
scheduler = slurm
# --- HeadNode Setting ---
base_os = ubuntu1804
master_instance_type = c5.large
master_root_volume_size = 30
# --- Custom Shared EBS ---
ebs_settings = custom1
# --- Netowrk Setting ---
vpc_settings = default
# --- Compute Setting ---
queue_settings = ondemand, spot
# --- PostInstall Setting ---
s3_read_resource = arn:aws:s3:::pcluster-postinstall/*
# --- Scaling Setting ---
scaling_settings = custom
# --- Tag ---
tags = { "Name" : "Scaling-test-Cluster" }

[vpc default]
vpc_id = vpc-07edfc27679c9ca80
master_subnet_id = subnet-0ab2754446b2f87a4
compute_subnet_id = subnet-0ab2754446b2f87a4
use_public_ips = true

[queue ondemand]
compute_resource_settings = ondemand_resource
placement_group = DYNAMIC

[queue spot]
compute_resource_settings = spot_resource
placement_group = DYNAMIC
compute_type = spot

[compute_resource ondemand_resource]
instance_type = c5.large
max_count = 16

[compute_resource spot_resource]
instance_type = c5.large
max_count = 16

# --- EBS Setting ---
[ebs custom1]
shared_dir = /shared
volume_type = gp3
volume_size = 10
volume_iops = 3000
volume_throughput = 125
encrypted = true

# --- Scaling ---
[scaling custom]
scaledown_idletime = 5

コンピュートノード削除までの動作確認

検証クラスターコンフィグをもとにクラスターを作成しました。

テストジョブを作成します。日付を返すだけです。

test.sh

#! /bin/bash
date

テストジョブを登録します。ジョブ登録からジョブ開始までの時間を確認したかったため、dateコマンドを打っています。

$ date && sbatch -n 1 -p ondemand test.sh
Thu Mar 11 08:28:39 UTC 2021
Submitted batch job 2
$ date && sbatch -n 1 -p spot test.sh
Thu Mar 11 08:28:46 UTC 2021

ジョブはキューに入りました。Partition違いで合計2台のコンピュートノードの起動待ちしています。

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 2  ondemand  test.sh   ubuntu CF       0:10      1 ondemand-dy-c5large-1
                 3      spot  test.sh   ubuntu CF       0:04      1 spot-dy-c5large-1

Partition Ondemand

ジョブの終了時間を確認します。CloudWatch Logsのクラスターのロググループから[computenode-instance-id].slumdにログが保存されています。コンピュートノードのインスタンスIDはダッシュボードから確認すると早いです。コンピュートノード終了後、時間が経ちダッシュボードから確認できない場合は手間ですが素直にログを漁りましょう。

キューに登録時のジョブIDは2番でした。[2.batch]の [n.batch] 表記の n がジョブIDを示しています。

[2021-03-11T08:31:32.381] [2.batch] done with job

コンピュートノード削除される直前のログを確認します。[computenode-instance-id].computemgtdにヘッドノードの clustermgtd からコンピュートノードへ1分間隔でハートビート打っている様子を確認できます。

2021-03-11 08:36:03,460 - [slurm_plugin.common:is_clustermgtd_heartbeat_valid] - INFO - Latest heartbeat from clustermgtd: 2021-03-11 08:35:11.365942+00:00

ジョブの終了時刻が8:31であり、最後のハートビート受信のログが8:36でした。5分空いたら削除設定のクラスターであるため、意図通り動作しています。

clustermgtdとは

ヘッドノードで動作するクラスター管理のデーモンです。

主な動作は下記になります。

• 非アクティブなパーティションのクリーンアップ
• 異常な Amazon EC2 インスタンス管理（Amazon EC2 ヘルスチェックの失敗）

詳細はドキュメントを参照ください。

• AWS ParallelCluster processes - AWS ParallelCluster
• aws-parallelcluster-node/clustermgtd.py at develop · aws/aws-parallelcluster-node

Paratiton Spot

オンデマンドと同様のログを確認します。

ジョブの終了時間を確認します。スポットインスタンスのインスタンスIDを確認し[computenode-instance-id].slumdログを確認します。

ジョブID3の終了を確認できました。

[2021-03-11T08:31:02.516] [3.batch] done with job

[computenode-instance-id].computemgtdから最後のハートビートのログを確認できました。

2021-03-11 08:36:03,493 - [slurm_plugin.common:is_clustermgtd_heartbeat_valid] - INFO - Latest heartbeat from clustermgtd: 2021-03-11 08:35:11.365942+00:00

スポットインスタンスもオンデマンドと同様に8:31にジョブが終了し、8:36が最後のハートビートの受信記録です。

HeadNode

ヘッドノードの[hedadnode-instance-id].computemgtdを確認すると、コンピュートノードの 終了（Terminate） 指示を出しているのがわかります。

2021-03-11 08:37:11,346 - [slurm_plugin.clustermgtd:_handle_powering_down_nodes] - INFO - Resetting powering down nodes: (x2) ['ondemand-dy-c5large-1(10.1.11.253)', 'spot-dy-c5large-1(10.1.11.243)']

AWS ParallelCluster v2.9.0以降はコンピュートノードのオートスケールに Slurm Workload Manager (Slurm) が使用されています。そのため、slurm_plugin である clustermtgd が管理しています。

ちなみにv2.8.0以前はAutoScalingGroupと、AWS ParallelClusterのnodewatcherの組み合わせでコンピュートノードの台数を管理していました。

まとめ

• scaling_settingsをクラスター作成時に設定しておくことで柔軟性を持たせられる
• コンピュートノードはジョブを実行していない時間が一定時間経過すると、ヘッドノードから終了（Terminate）の指示が出る
• 一定時間はユーザが任意に設定できる値である
• ただし、scaling_settingsを事前設定済みの場合に限る

おわりに

ある程度連続してジョブが登録される状況でscaling_settingsを短い時間設定にすると、コンピュートノードが都度起動することになります。起動してジョブを処理開始までの時間も課金対象です。待機時間を短くして節約しようとしても、起動までのオーバヘッドを考えると案外節約になっていない可能性もあります。短めに設定する場合は要ご検討ください。

検証では素のコンピュートノードを起動しているため、ジョブ投入から3分ほどでジョブを開始できています。実環境で利用する際はpostinstallを利用してコンピュートノード起動時に何かしらライブラリのインストールや、設定を入れることになります。ジョブ投入からジョブ開始まのオーバヘッドは最低5分以上を見ておいたほうが良いでしょう。