AWS ParallelCluster 3.7.0 で Ubuntu 22.04 や専用のログインノードの追加など新たにサポートされました

久々のアップデートなので大きな機能追加ありました！

#HPC

#AWS ParallelCluster 3

#AWS

大村保貴

2023.08.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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 を新規サポート
1. 注意: SSH 接続する場合は ED25519 のキーペアを利用すること
新機能ログインノードをサポート
1. ユーザーがログインしてジョブをサブミットできるインスタンスを追加起動できるオプション
2. ヘッドノードの負荷軽減が目的
EBS のルートボリュームの必要最小サイズが 35GB から 40 GB へ引き上げ
Amazon File Cache を共有ストレージとして新たにサポート
パーティション（キュー）内の複数のインスタンスタイプ指定時に優先度を指定可能になった
特定の設定時に memory-based scheduling が自動有効化になる仕様変更

アップデート詳細はリリースノート、ドキュメントの更新履歴をご確認ください。

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

Image section - AWS ParallelCluster

ログインノードをオプションで建てられる

ユーザーがログインしてジョブをサブミットするための専用のログインノードを起動できるオプションが追加されました。

1 つのクラスターに対して利用者が多いオンプレミスのスパコンの様に ParallelCluster を利用されている場合ですと、ヘッドノードに大規模のユーザーアクセスが発生します。ヘッドノードのリソース消費を抑えるために、ログインノードを新設してユーザー管理をオフロードできるようになりました。

ヘッドノードは、ジョブ管理と、コンピュートノードの管理に専念させ、ユーザー管理はログインノードへオフロード
ログインノードは、従来ヘッドノードへログインして行っていたジョブのサブミットができる環境を提供
- ログインノードは NLB 配下で複数台起動でき負荷分散できる
- ログインノードの停止は今のところpcluster update-clusterコマンドで更新が必要

大学などの大規模な共同利用でみられるオンプレミスのスパコン構成っぽい構成を ParallelCluster でも取れるようになった機能追加でした。ParallelCluster 3.1.1 で AD ベースのマルチユーザー認証をサポートが追加されましたし、マルチユーザーアクセスの需要を受けての機能追加だったのではないかと推測しています。

ParallelCluster はオンプレミスのスパコンと異なり HPC クラスターを簡単に構築できますので、1 人 1 クラスターが使える「夢のお一人様クラスター」環境が容易にかつ、安価に実現できます。ユーザーの自由度か、ユーザー管理の観点で検討していただければと思います。

Reference

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

SharedStorage section - AWS ParallelCluster

ノードの優先度指定

私の理解ですと以下に示すコンフィグのときに、キュー内で指定していた複数のインスタンスタイプに優先度を設定することができるようになったようです。

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 指定なしで複数インスタンスを指定するときにユーザー側で利用するインスタンスタイプの優先度を付けられるようになったという理解です。