AWS ParallelCluster 3.7.0 で Ubuntu 22.04 や専用のログインノードの追加など新たにサポートされました
2023 年 8 月 30 日に AWS ParallelCluster 3.7.0 がリリースされました。v3.6.0 から約 3 か月ぶりのマイナーアップデートです。
3.7.x 系のサポートは 2025 年 2 月 28 日までです。
AWS ParallelCluster support policy - AWS ParallelCluster
注目のアップデート
個人的に注目しているポイントや、このアップデートの目玉をピックアップしています。リリースノートからはアップデート前後の違いを把握することが難しいため、私のわかる範囲で補足します。
- ParallelCluster で利用できる OS に待望の Ubuntu 22.04 LTS を新規サポート
- 注意: SSH 接続する場合は ED25519 のキーペアを利用すること
- 新機能ログインノードをサポート
- ユーザーがログインしてジョブをサブミットできるインスタンスを追加起動できるオプション
- ヘッドノードの負荷軽減が目的
- EBS のルートボリュームの必要最小サイズが 35GB から 40 GB へ引き上げ
- Amazon File Cache を共有ストレージとして新たにサポート
- パーティション（キュー）内の複数のインスタンスタイプ指定時に優先度を指定可能になった
- 特定の設定時に memory-based scheduling が自動有効化になる仕様変更
アップデート詳細はリリースノート、ドキュメントの更新履歴をご確認ください。
- Release AWS ParallelCluster v3.7.0 · aws/aws-parallelcluster
- Release notes and document history - AWS ParallelCluster
Ubuntu 22.04 LTS が利用可能になりました
Ubuntu 22.04 LTS がリリースされてから約 1 年半遅れで ParallelCluster でも利用可能になりました。また、v3.7.0 で Ubuntu 18.04 LTS が選択できる OS の対象から削除されています。
Region: ap-northeast-1 Image: Os: ubuntu2204
注意事項
Ubuntu 20.04 LTS で動作していたカスタムブートストラップスクリプトが、Ubuntu 22.04 LTS へ OS を変更することで正常に動かないことも考えられます。
OS を変更してコンピュートノードが起動してこない場合はカスタムブートストラップスクリプトを再確認してください。私が利用していたスクリプトは Ubuntu 22.04 LTS に変更したことにより起動に失敗するようになりました。
Reference
ログインノードをオプションで建てられる
ユーザーがログインしてジョブをサブミットするための専用のログインノードを起動できるオプションが追加されました。
1 つのクラスターに対して利用者が多いオンプレミスのスパコンの様に ParallelCluster を利用されている場合ですと、ヘッドノードに大規模のユーザーアクセスが発生します。ヘッドノードのリソース消費を抑えるために、ログインノードを新設してユーザー管理をオフロードできるようになりました。
- ヘッドノードは、ジョブ管理と、コンピュートノードの管理に専念させ、ユーザー管理はログインノードへオフロード
- ログインノードは、従来ヘッドノードへログインして行っていたジョブのサブミットができる環境を提供
- ログインノードは NLB 配下で複数台起動でき負荷分散できる
- ログインノードの停止は今のところ
pcluster update-clusterコマンドで更新が必要
大学などの大規模な共同利用でみられるオンプレミスのスパコン構成っぽい構成を ParallelCluster でも取れるようになった機能追加でした。ParallelCluster 3.1.1 で AD ベースのマルチユーザー認証をサポートが追加されましたし、マルチユーザーアクセスの需要を受けての機能追加だったのではないかと推測しています。
ParallelCluster はオンプレミスのスパコンと異なり HPC クラスターを簡単に構築できますので、1 人 1 クラスターが使える「夢のお一人様クラスター」環境が容易にかつ、安価に実現できます。ユーザーの自由度か、ユーザー管理の観点で検討していただければと思います。
Reference
- ParallelCluster: Launching a Login Node · aws/aws-parallelcluster Wiki
- Login nodes - AWS ParallelCluster
- LoginNodes section - AWS ParallelCluster
EBS の最小必要サイズ変更
ヘッドノード、コンピュートノードのルートボリュームにあたる EBS の必要最小サイズが 35 GB から 40GB へ引き上げになりました。クラスターの維持費（EBS 代）が少し増えます。
ドキュメントから変更が入ったことと、最小サイズがいくつかは確認できませんでした。v3.6.0 のコンフィグを元に v3.7.0 のクラスターを作成時に以下のバリデーションエラーにより発覚しました。
{
"configurationValidationErrors": [
{
"level": "ERROR",
"type": "HeadNodeLaunchTemplateValidator",
"message": "Unable to validate configuration parameters for instance type t3.micro. Please double check your cluster configuration. Volume of size 35GB is smaller than snapshot 'snap-0ceaf01a254ee51e4', expect size >= 40GB"
},
{
"level": "ERROR",
"type": "RootVolumeSizeValidator",
"message": "Root volume size 35 GiB must be equal or greater than the volume size of the AMI: 40 GiB."
},
{
"level": "ERROR",
"type": "ComputeResourceLaunchTemplateValidator",
"message": "Unable to validate configuration parameters for instance type c6i.large. Please double check your cluster configuration. Volume of size 35GB is smaller than snapshot 'snap-0ceaf01a254ee51e4', expect size >= 40GB"
},
{
"level": "ERROR",
"type": "RootVolumeSizeValidator",
"message": "Root volume size 35 GiB must be equal or greater than the volume size of the AMI: 40 GiB."
}
],
"message": "Invalid cluster configuration."
}
ディスクサイズを明示的に書いていない場合は問題ありませんが、サイズを明示している場合は v3.7.0 より前のクラスターのコンフィグを流用するときにご注意ください。
LocalStorage:
RootVolume:
Size: 40
Encrypted: true
VolumeType: gp3
Iops: 3000
Throughput: 125
Amazon File Cache をサポート
EBS, EFS, FSx for ONTAP, FSx for OpenZFS, FSx for Lustre に加えて、Amazon File Cache も ParallelCluster のコンフィグから指定してマウント可能になりました。
主要なストレージサービスはほぼほぼサポートされました。個人的な希望は Moutpoint for Amazon S3 も ParallelCluster で正式にサポートしてくれると嬉しいです。
Reference
ノードの優先度指定
私の理解ですと以下に示すコンフィグのときに、キュー内で指定していた複数のインスタンスタイプに優先度を設定することができるようになったようです。
- StaticNodePriority のデフォルト Weight 値は 1
- DynamicNodePriority のデフォルト Weight 値は 1000
- Weight 値が低い方が優先される
MinCount: 0として、Static Node は存在しない状態のクラスターをコンフィグを例に考えてみます。従来は同じ優先度でしたがDynamicNodePriority: nで使用するインスタンスに優先度を付けられるになったという認識をしています。
また、キュー内で多くの異なる値の Weight を設定するとジョブスケジューリング速度が遅くなる可能性があるとドキュメントに記載があります。
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: SPOT
ComputeResources:
- Name: c6i8xlarge
InstanceType: c6i.8xlarge
MinCount: 0
MaxCount: 10
DisableSimultaneousMultithreading: true
DynamicNodePriority: 900
- Name: c6i12xlarge
InstanceType: c6i.12xlarge
MinCount: 0
MaxCount: 10
DisableSimultaneousMultithreading: true
DynamicNodePriority: 990
- Name: c6i16xlarge
InstanceType: c6i.16xlarge
MinCount: 0
MaxCount: 10
DisableSimultaneousMultithreading: true
DynamicNodePriority: 995
Instances 指定で複数インスタンスタイプを指定するときは AllocationStrategy で価格を優先するか、スポットの場合は起動率を優先するかの戦略を決められました。(v3.3.0 より)
- Name: queue-2
ComputeResources:
- Name: multi6i-serices-price
Instances:
- InstanceType: c6i.large
- InstanceType: m6i.large
- InstanceType: r6i.large
MinCount: 0
MaxCount: 10
DisableSimultaneousMultithreading: true
CapacityType: SPOT
AllocationStrategy: lowest-price
AllocationStrategy については以下の記事も参考にしてください。
Instances 指定なしで複数インスタンスを指定するときにユーザー側で利用するインスタンスタイプの優先度を付けられるようになったという理解です。
Reference
特定の設定時に memory-based scheduling が自動有効化になる仕様変更
使用するメモリサイズを指定したジョブをサブミットするときはEnableMemoryBasedSchedulingをtrueにすることで対応していました。（v3.2.0 より）
Instances で複数インスタンスを指定するとEnableMemoryBasedSchedulingが自動的に有効化される変更が入りました。
memory-based scheduling が有効時はジョブサブミット時に--memフラグを付けてメモリサイズを指定するのが推奨されています。自動的に有効化されることでメモリサイズ指定を意識する必要がでてくるかもしれません。
memory-based scheduling については以下の記事も参考にしてください。
Reference
- Slurm memory-based scheduling - AWS ParallelCluster
- Scheduling section - AWS ParallelCluster
- Scheduling section - AWS ParallelCluster
IMDSv2 デフォルト
ParallelCluster 3.7.0 から IMDSv2 がデフォルトになりました。IMDSv1 から IMDSv2 への移行が推奨されています。
インスタンスメタデータを参照するようなカスタムブートストラップスクリプトや、ジョブの実行処理を実装している場合はご注意ください。
IMDSv2 については以下の記事も参考にしてください。
Reference
おわりに
わかる範囲でアップデート内容を補足しました。随時アップデート内容を個別に検証して詳細をご紹介したいと思います。
