AWS ParallelCluster ヘッドノードのインスタンスタイプをマネジメントコンソールから変更した後に update-cluster を実行するとどうなるのか確認した
AWS ParallelCluster のヘッドノードのインスタンスタイプの変更は正規の更新方法（pcluster update-cluster）では許可されていません。とは言えどヘッドノードは EC2インスタンスですのでマネジメントコンソール、AWS CLI を利用して AWS ParallelCluster の管理（クラスターのコンフィグ）外から変更操作はできます。
仮にヘッドノードのインスタンスタイプをマネジメントコンソールから変更したあとに更新可能なパラメータを正規の方法で変更かけようすると、ヘッドノードのインスタンスタイプ変更による差分を検知して更新は失敗するのでしょうか？
素朴な疑問を解決するべく試してみました。
確認結果
- ヘッドノードのインスタンスタイプを手動で変更しても
pcluseter update-clusterコマンドで更新はできる- 変更するパラメータによっては更新に失敗する可能性はあります
- アップデートポリシーで許可されていないパラメータを変更しているため、不具合があったり、サポートも受けられない可能性は高い
ヘッドノードのインスタンスタイプについて
AWS ParallelCluster のクラスターを作成後、大きく分けると変更できるパラメータと、変更できないパラメータが存在します。詳細なアップデートポリシーの定義は以下のリンクをご参照ください。
Using pcluster update-cluster - AWS ParallelCluster
HeadNodeセクションのInstanceTypeについては変更不可なアップデートポリシーと説明されています。
Update policy: If this setting is changed, the update is not allowed.
HeadNode section - AWS ParallelCluster
pcluster update-clusterコマンドではインスタンスタイプを変更できないことが確認できました。インスタンスタイプの変更により、intel から arm へ CPU アーキテクチャも変更できてしまうため、ヘッドノード単体の問題では済まなくなり影響が大きいことから許可されないのも納得できます。
ヘッドノードのインスタンスタイプ変更
マネジメントコンソールからヘッドノードのインスタンスタイプを変更します。
作成したクラスターのヘッドノードのインスタンスタイプは t3.micro です。
マネジメントコンソールからインスタンスタイプをc6i.largeへ変更しました。ぽちぽち押すだけでスペックを簡単に変更できるのは本当に便利ですよね。
クラスターコンフィグのInstanceTypeで指定した値と実際のリソースに差分が生まれました。
HeadNode:
InstanceType: t3.micro
Networking:
ElasticIp: false
SubnetId: subnet-035be95eeaa091603
動作確認
コンピュートノードを制御しているのはヘッドノードですので機能するのかジョブを登録してみます。
テスト用のスクリプトを用意しました。
#! /bin/bash #SBATCH -p cpu-spot #SBATCH -N 1 hostname
ジョブを投げてみました。このあとコンピュートノードを呼び出せるのかが問題です。
$ sbatch test.sh
Submitted batch job 9
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
9 cpu-spot test.sh ubuntu CF 0:05 1 cpu-spot-dy-large-1
コンピュートノードはいつもどおり起動してきました。
ヘッドノードのインスタンスタイプを変更しても動作しているように思えます。
コンフィグ変更
クラスターのコンフィグを変更してpclsuter update-clusterでクラスターに更新をかけてみます。
更新するパラメータはコンピュートノードの最大起動数を変更してみます。現在は 10台起動できる cpu-spot を 20台まで起動できるようにします。
$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST cpu-spot* up infinite 10 idle~ cpu-spot-dy-large-[1-10] high-cpu-spot up infinite 10 idle~ high-cpu-spot-dy-large16x-[1-10]
MaxCountを20にしました。
SlurmQueues:
# --- Queue 1 ---
- Name: cpu-spot
ComputeResources:
- Name: large
InstanceType: c6i.large
MinCount: 0
MaxCount: 20
DisableSimultaneousMultithreading: true
クラスターの停止
クラスターの設定変更する前に一度クラスターの停止のステータスにする必要があります。ヘッドノードを停止すれば OK というわけではないです。
まず作成したクラスター名を確認しないとコマンド打てないため、pcluster list-clustersでサッと確認すると早いです。クラスターが複数台あるときは対象を誤らないように注意してください。
> pcluster list-clusters
{
"clusters": [
{
"clusterName": "DockerOnParallelcluster",
"cloudformationStackStatus": "UPDATE_COMPLETE",
"cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/DockerOnParallelcluster/59b85490-c3a7-11ec-b7c8-0e8a0cc9f27b",
"region": "ap-northeast-1",
"version": "3.1.3",
"clusterStatus": "UPDATE_COMPLETE"
}
]
}
この先、クラスター名は頻出するため変数に入れておきます。
CLUSTER_NAME=DockerOnParallelcluster
クラスター停止コマンドを打ちます。
pcluster update-compute-fleet --cluster-name ${CLUSTER_NAME} \
--status STOP_REQUESTED
{
"status": "STOP_REQUESTED",
"lastStatusUpdatedTime": "2022-05-20T08:55:13.516Z"
}
クラスターのアップデート
最大起動数を20台に変更したコンフィグを引数にpclsuter update-clusterコマンドを実行します。
pcluster update-cluster --cluster-name ${CLUSTER_NAME} \
--cluster-configuration sample-docker-on-parallelcluster.yml
ParallelCluster のクラスターは CDK で管理されています。チェンジセットの結果が返ってきました。
【アップデート】CloudFormationに事前にリソースがどう変更されるのかを確認できる「Change Sets」が追加されました！ | DevelopersIO
{
"cluster": {
"clusterName": "DockerOnParallelcluster",
"cloudformationStackStatus": "UPDATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/DockerOnParallelcluster/59b85490-c3a7-11ec-b7c8-0e8a0cc9f27b",
"region": "ap-northeast-1",
"version": "3.1.3",
"clusterStatus": "UPDATE_IN_PROGRESS"
},
"changeSet": [
{
"parameter": "Scheduling.SlurmQueues[cpu-spot].ComputeResources[large].MaxCount",
"requestedValue": 20,
"currentValue": 10
}
]
}
ドリフトがあり、ヘッドノードのインスタンスタイプに差分がありますという結果を期待してのですがUPDATE_IN_PROGRESSということで更新がかかっています。
CloudFormation のスタックを直接確認してみると更新中ですね。そもそものお話だったのですが差分があるのかのチェックは走っていませんでした。
そして、正常に更新が終わりました。
クラスターの開始
最大起動台数は20台になったのか確認するためクラスターを再開させます。
pcluster update-compute-fleet --cluster-name ${CLUSTER_NAME} \
--status START_REQUESTED
{
"status": "START_REQUESTED",
"lastStatusUpdatedTime": "2022-05-20T09:11:12.321Z"
}
ヘッドノードから状態確認
cpu-spotの最大起動台数が20台になっていますね。更新成功です。
$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST cpu-spot* up infinite 20 idle~ cpu-spot-dy-large-[1-20] high-cpu-spot up infinite 10 idle~ high-cpu-spot-dy-large16x-[1-10]
意外と成功しました。
ドリフトは検出されるのか？
ヘッドノードのドリフトは検出されるのか確認してみます。
ちゃんと検出されました。
と思ったのですが、インスタンスタイプのではなくタグが違うという差分でした。となると、インスタンスタイプを変更しなくても差分は検出されるのではないかという新しい疑問が生まれました。
今回はヘッドノードのインスタンスタイプを外部から変更したあとにpcluster update-clusterを実行したらどうなるのかという疑問を解消するための検証でしたので、別の機会に確認したいと思います。
まとめ
ヘッドノードのインスタンスタイプをマネジメントコンソールから変更した状態で、pcluster update-clusterを実行しても差分を検知せず更新可能であった。
- クラスターの更新時にドリフトのチェックは走らない
pcluster update-clusterで更新した箇所が手動変更している部分だと当然エラーになり更新失敗する可能性がある
おわりに
ヘッドノードのインスタンスタイプは一体どこで管理されているのか謎が深まってしまいました。CloudFormation のテンプレート内にはt3.microの記述はあるため、時間あるときに ParallelClusetr の裏側を探ってみます。
