AWS ParallelCluster で作成済みのクラスターに対して、クラスターのコンフィグを変更して設定反映させるための作業手順を紹介します。
以前 bash 向けの手順を作成したものを fish ユーザー向けにブラッシュアップしました。
既存クラスターの設定反映手順まとめ
変更対象の既存のクラスター名を確認します。
pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'
確認したクラスター名と、設定変更したコンフィグファイルを変数に入れます。
set CLUSTER_NAME [Target Cluster name]
set CONFIG_NAME [Your config file]
コンピュートフリートを停止します。STOPPED
の表示を確認できれば正常です。
pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
sleep 3
end
既存クラスターへ設定を反映する前にドライランを実行してコンフィグをチェックします。Request would have succeeded, but DryRun flag is set.
確認できれば正常です。
pcluster update-cluster --cluster-name $CLUSTER_NAME \
--cluster-configuration $CONFIG_NAME \
--dryrun true
既存クラスターに設定を反映させます。UPDATE_COMPLETE
の表示を確認できれば正常です。
pcluster update-cluster --cluster-name $CLUSTER_NAME \
--cluster-configuration $CONFIG_NAME
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
sleep 3
end
コンピュートフリートを開始します。RUNNING
の表示を確認できれば正常です。
pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
sleep 3
end
以上で作業完了です。
実際に試したときの作業記録
実際に既存クラスターの設定を変更したときのコマンドの実行ログを参考までに紹介します。
実行環境
pclsuter
コマンドの実行環境は Docker コンテナで用意したものを利用しています。
変更内容
コンピュートノードのパーティションqueue1
の最大起動ノード数を 20 台から 50 台へ変更します。
# ------ Compute 1 ------
- Name: queue1
ComputeResources:
- Name: queue1
Instances:
- InstanceType: m7i.8xlarge
- InstanceType: m7a.4xlarge
MinCount: 0
MaxCount: 50
重要なこと
既存クラスターの設定値は変更可能なものと、変更不可なものがあります。また変更可能あっても変更には条件があるものもあります。事前に対象の設定綱目のUpdate policy
を確認しましょう。
今回変更するMaxCount
はコンピュートフリートが停止状態であれば変更可能と記載があります。
Scheduling section - AWS ParallelCluster
クラスター名確認
クラスター名の一覧を出力しました。v380
の名前で作成されている既存のクラスターの設定を変更します。
# pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'
v380 3.8.0 ap-northeast-1
環境変数に登録
確認したクラスター名と、クラスターのコンフィグファイル名を環境変数に入れます。
# set CLUSTER_NAME v380
# set CONFIG_NAME v380released.yaml
コンピュートフリートの停止
停止コマンドを実行して約 40 秒後にコンピュートフリートはSTOPPED
の状態になりました。
# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
sleep 3
end
{
"status": "STOP_REQUESTED",
"lastStatusUpdatedTime": "2024-02-11T03:13:53.844Z"
}
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOPPING
STOPPING
STOPPED
STOPPED
ドライラン実行
クラスターのコンフィグチェックのために一度ドライランを実行します。Request would have succeeded, but DryRun flag is set.
確認できれば基本問題ありません。
バリデーションのメッセージでマルチ AZ 起動時は AZ 跨ぎのデータ転送料に留意しなさいとご丁寧に教えてくれました。また、設定変更箇所であるqueue1
のMaxCount
数の変更前と、変更後の値が表示されています。
# pcluster update-cluster --cluster-name $CLUSTER_NAME \
--cluster-configuration $CONFIG_NAME \
--dryrun true
{
"validationMessages": [
{
"level": "INFO",
"type": "MultiAzRootVolumeValidator",
"message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
}
],
"message": "Request would have succeeded, but DryRun flag is set.",
"changeSet": [
{
"parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
"requestedValue": 50,
"currentValue": 20
}
]
}`
既存クラスターへコンフィグを反映
クラスターのコンフィグを既存クラスターへ反映させます。アップデートコマンドを実行して約 50 秒後にクラスターの CloudFormation スタックはUPDATE_COMPLETE
の状態になりました。
# pcluster update-cluster --cluster-name $CLUSTER_NAME \
--cluster-configuration $CONFIG_NAME
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
sleep 3
end
{
"cluster": {
"clusterName": "v380",
"cloudformationStackStatus": "UPDATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/v380/eaecf760-a463-11ee-bfc6-06ad6f88204d",
"region": "ap-northeast-1",
"version": "3.8.0",
"clusterStatus": "UPDATE_IN_PROGRESS",
"scheduler": {
"type": "slurm"
}
},
"validationMessages": [
{
"level": "INFO",
"type": "MultiAzRootVolumeValidator",
"message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
}
],
"changeSet": [
{
"parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
"requestedValue": 50,
"currentValue": 20
}
]
}
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_COMPLETE
UPDATE_COMPLETE
コンピュートフリートの開始(再開)
開始コマンドを実行して約 15 秒後にコンピュートフリートはRUNNING
の状態になりました。
# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
while true
pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
sleep 3
end
{
"status": "START_REQUESTED",
"lastStatusUpdatedTime": "2024-02-11T03:24:44.683Z"
}
START_REQUESTED
START_REQUESTED
STARTING
STARTING
RUNNING
RUNNING
変更変更箇所の確認
ヘッドノードにログインしてパーティションの設定を確認しました。
設定を変更前に確認したパーティションの様子です。queue1
は 20 ノードまでと表示されています。
# Before
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
test1* inact infinite 10 idle~ test1-dy-test1-[1-10]
queue1 inact infinite 20 idle~ queue1-dy-queue1-[1-20]
設定変更後に確認したパーティションの様子です。50 ノードと表示されています。
# After
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
test1* up infinite 10 idle~ test1-dy-test1-[1-10]
queue1 up infinite 50 idle~ queue1-dy-queue1-[1-50]
queue1
パーティションの最大起動台数の変更に成功しました。
おわりに
最近クラスターの設定変更する機会が多く、fish ユーザーの身としては以前作成した手順が使いづらかったこともあり、fish 向けに書き直しました。以前作成した bash での変更手順の方をお客様へ案内する機会は多いと思うのですが、fish 使ってるお客様がいたら同様にプログを案内して済む様に作成しました。
また、実際に私が運用していると--dryrun true
のオプションを頻繁に--dry-run true
と誤った書き方してエラーになることが多かったのでドライランコマンドも手順に盛り込みました。多少改善が図られています。