developersIO
I4i インスタンスを AWS ParallelCluster で動かしてみた

I4i インスタンスを AWS ParallelCluster で動かしてみた

HPCAWSAWS ParallelCluster 3
FacebookHatena blogX
2022.05.14

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

第2世代の AWS Nitro SSDを搭載した I4i インスタンスタイプが登場しました。高速・大容量のローカル AWS Nitro SSD ストレージ搭載するインスタンスタイプを AWS ParallelCluster で利用可能なのか動作検証しました。

ローカルストレージはインスタンスストアと呼ばれる非永続的なストレージです。

確認結果

  • AWS ParallelCluster 3.1.3 のクラスターで I4i.8xlarge の起動を確認
  • コンピュートノードのインスタンスストアは /scratch ディレクトリに自動マウントされる
  • スポットインスタンスの提供あり
  • ap-northeast-1（東京）ではまだ利用できません（現時点: 2022/5/14）

相性の良い使い方

AWS ParallelCluster と組み合わせて利用する際の相性の良い点と、ローカル AWS Nitro SSD ストレージの注意事項

  • 一時ファイル、中間ファイルを大量に生成するようなワークロード
  • 高速なインスタンスストアを活かすのであれば単一ノードで実行するアプリケーション向き
    • 最大 vCPU 128core（Hyper-Threading 無効化時は 64core）
    • 最大メモリ 1TiB 最大ローカル AWS Nitro SSD ストレージ 30TB
  • ストレージコストの最適化
    • 高速なストレージ（インスタンスストア）を計算中の間だけ利用するためコスパが高い
      • コンピュートノードの停止とともにインスタンスストアのデータは消失する
      • 実行結果など残したいデータは永続ストレージ（S3 バケットなど）へ退避する必要がある

クラスター作成準備

キューの2番目にi4iインスタンスタイプを起動するクラスターを作成します。

項目 値
AWS ParallelCluster 3.1.3
Job Scheduler Slurm
OS Ubuntu 20.04 LTS
CPU Intel
Simultaneous Multi-Threading 無効
CloudWatch Dashboard 作成しない
Placement group 有効

スポットインスタンスは提供されていましたのでコンピュートノードではスポットで利用します。

$ aws ec2 describe-instance-types --instance-types i4i.8xlarge --region us-east-2 | jq '.InstanceTypes[].SupportedUsageClasses[]'
"on-demand"
"spot"

サンプルコンフィグ

実行環境依存のパラメータは適時変更してご利用ください。

  • SubnetId:
  • SubnetIds:
  • KeyName:
  • BucketName:
  • Script:
Region: us-east-2
Image:
  Os: ubuntu2004
Monitoring:
  Logs:
    CloudWatch:
      Enabled: true
      RetentionInDays: 30
      DeletionPolicy: "Delete"
  Dashboards:
    CloudWatch:
      Enabled: false
Tags:
  - Key: Name
    Value: SampleCluster
HeadNode:
  InstanceType: t3.micro
  Networking:
    ElasticIp: false
    SubnetId: subnet-06bef5c18e9a5f4c6
  Ssh:
    KeyName: sandbox-key-useast2
  LocalStorage:
    RootVolume:
      Size: 35
      Encrypted: false
      VolumeType: gp3
      Iops: 3000
      Throughput: 125
  Iam:
    S3Access:
      - BucketName: hpc-dev-postinstall-files
        EnableWriteAccess: False
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 5
  SlurmQueues:
    # --- Queue 1 ---
    - Name: debug
      ComputeResources:
        - Name: debug
          InstanceType: t3.micro
          MinCount: 0
          MaxCount: 10
          DisableSimultaneousMultithreading: true
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 35
            Encrypted: false
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      Networking:
        SubnetIds:
          - subnet-06bef5c18e9a5f4c6
        # PlacementGroup:
        # Enabled: true
      CustomActions:
        OnNodeConfigured:
          Script: s3://hpc-dev-postinstall-files/sample-ubuntu-docker/postinstall.sh
      Iam:
        S3Access:
          - BucketName: hpc-dev-postinstall-files
            EnableWriteAccess: False
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

    # --- Queue 2 ---
    - Name: i4i
      ComputeResources:
        - Name: large8x
          InstanceType: i4i.8xlarge
          MinCount: 0
          MaxCount: 10
          DisableSimultaneousMultithreading: true
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 35
            Encrypted: false
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      Networking:
        SubnetIds:
          - subnet-06bef5c18e9a5f4c6
        PlacementGroup:
          Enabled: true
      CustomActions:
        OnNodeConfigured:
          Script: s3://hpc-dev-postinstall-files/sample-ubuntu-docker/postinstall.sh
      Iam:
        S3Access:
          - BucketName: hpc-dev-postinstall-files
            EnableWriteAccess: False
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

コンピュートノードのCustomActionsは Docker をインストールしています。詳細は以下のリンクをご確認ください。

クラスター作成

クラスター作成コマンドを実行して10分ほど待ちます。ヘッドノードが起動したらログインします。

pcluster create-cluster -n I4iParallelcluster -c sample-i4i-parallelcluster.yml

コンピュートノードの確認

ヘッドノードからテストジョブを投げてコンピュートノードを起動させました。

ローカルストレージのマウント状況

/scratchにマウントされていました。dが付与されたインスタンスタイプ同様に AWS ParallelCluster はローカルストレージを自動マウントしてくれました。

$ df -h
Filesystem                             Size  Used Avail Use% Mounted on
/dev/root                               34G   18G   17G  51% /
devtmpfs                               124G     0  124G   0% /dev
tmpfs                                  124G     0  124G   0% /dev/shm
tmpfs                                   25G  1.1M   25G   1% /run
tmpfs                                  5.0M     0  5.0M   0% /run/lock
tmpfs                                  124G     0  124G   0% /sys/fs/cgroup
/dev/loop0                              27M   27M     0 100% /snap/amazon-ssm-agent/5163
/dev/loop2                              62M   62M     0 100% /snap/core20/1405
/dev/loop1                              56M   56M     0 100% /snap/core18/2344
/dev/loop3                              68M   68M     0 100% /snap/lxd/22753
/dev/loop4                              44M   44M     0 100% /snap/snapd/15177
/dev/loop5                              45M   45M     0 100% /snap/snapd/15534
10.0.1.12:/home                         34G   17G   18G  49% /home
10.0.1.12:/opt/parallelcluster/shared   34G   17G   18G  49% /opt/parallelcluster/shared
/dev/loop6                              62M   62M     0 100% /snap/core20/1434
/dev/mapper/vg.01-lv_ephemeral         6.8T   89M  6.5T   1% /scratch
10.0.1.12:/opt/intel                    34G   17G   18G  49% /opt/intel
10.0.1.12:/opt/slurm                    34G   17G   18G  49% /opt/slurm
tmpfs                                   25G   40K   25G   1% /run/user/1000

ここまでで確認できたこと

  • AWS ParallelCluster 3.1.3 で i4i の起動をサポート
  • ローカル AWS Nitro SSD ストレージは/scratchにマウントされる

自動マウント設定はどこに入っているのか？

/scratchのマウント設定は起動テンプレートに書き込まれています。起動テンプレートはクラスター作成時に CloudFormation（CDK）から生成されます。

aws-parallelcluster/cluster_stack.py at 85bc7b7aebd9cadaab9b9059ba9daf48bb4c5cf9 · aws/aws-parallelcluster

こちらは実際のクラスター作成後に生成された起動テンプレートです。

ストレージ設定確認するとephemeral0 - 23までの設定が入っています。

なぜ0から23なのか調べると、インスタンスストアの仮想デバイス数と同数でした。つまり、考えられるインスタンスストアはすべてマッピングする準備はしてある起動テンプレートになっているんですね。

Amazon EC2 インスタンスストア - Amazon Elastic Compute Cloud

実際のマウント処理はユーザーデータから呼び出している chef のスクリプトではないかと思いますがまだ動作を追いきれてないです。

2022/5/25追記
マウント処理を追いかけましたのでご興味あればご覧ください

おわりに

勉強になったのは ParallelCluster 3系からは AutoScaling Group は使わなくなりましたが、2系から引き続き起動テンプレートは使われていたことを知りました。 2系はコンピュートノードの管理に AutoScaling Group を使っていましたが、3系からは Slurm ジョブスケジューラの場合は clustermgtd デーモンで管理されるように変更となっています。

この記事をシェアする

FacebookHatena blogX

関連記事

AMD EPYC (Zen 4) 向けの C++ ビルド環境を作成して OpenBLAS で行列計算を試してみた
大村 保貴
2025.10.31
AWS PCS が EC2 インスタンスの置き換えなしのコンピュートノード再起動機能をサポートしました
大村 保貴
2025.10.24
AWS PCS でジョブの自動再キューイングをサポートした Slurm 25.05 がリリースされました
大村 保貴
2025.10.23
Amazon EC2 の各インスタンスの物理コア数と 1 コアあたりの単価を一覧で確認する方法
大村 保貴
2025.10.22