FSx for Lustre を使いたいときだけ起動する AWS ParallelCluster のクラスター環境を構築 Amazon Linux2 編

2022.08.31

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

AWS ParallelCluster でクラスター作成時に FSx for Lustre を作成しクラスターとともに管理することは ParallelCluster のコンフィグで簡単に実現できます。クラスターのライフサイクルから FSx for Lustre を完全に切り離したより自由度の高い Lustre が欲しいです。Lustre を使いたいときだけ起動し、計算が終わったら Lustre を削除する構成例と手動セットアップ手順を紹介します。

構成例

Lustre 利用時

Lustre 未使用時

検証環境

検証で使用する OS は Amazon Linux 2 です。Lustre Client のインストールはyumを利用します。他の OS 場合は一部手順が異なる部分もあります。

項目
ParallelCluster 3.2.0
OS Amazon Linux 2
Package Manager yum
CPU Intel
Head node t3.micro
Compute node t3.micro
FSx for Lustre Deploy type Persistent 2
Lustre version 2.12
Lustre Client 2.10

FSx for Lustre のバージョンは2.12ですが、ヘッドノード、コンピュートノードにインストールする Lustre Client のバージョンは2.10です。2.10から2.12へ接続可能なため問題はありません。

Amazon FSx for Lustre version 2.10 and version 2.12 both support access from the 2.10 versions of the Lustre client.

Installing the Lustre client - FSx for Lustre

FSx for Lustre 作成からマウントまでの手順

Amazon Linux 2 から Lustre へのマウントは以下のドキュメントを参考にしています。

FSx for Lustre を作成する

本構成では FSx for Lustre だけ作成・削除を簡単に行えることが大事です。Lustre 作成・削除の手軽に実行するために CloudFormation のパラメーターを用意しました。CloudFormation テンプレートは以下のリポジトリに保存してあります。

bigmuramura/cfn-lustre-persistent2-s3

CreateLustreToggleの値を変更して Lustre の作成・削除をコントロールできます。

  • tureにすると Lustre を作成します
  • falseにすると Lustre を削除します

Lustre と統合させる S3 バケット名を入力するパラメーターがあります。

統合させたい S3 バケット名をそのまま入力してください。S3 バケットの赤枠の名前をコピペすれば OK です。

既存の S3 バケットの設定(バケットポリシー)によっては上手く統合できない可能性があります。同リポジトリ内に S3 バケットを作成するテンプレートも置いてあります。必要に応じてお使いください。

CreateLustreToggletrue指定で必要パラメーターを入力してスタックを作成すると10分ほどで FSx fro Lustre が起動します。

FSx for Lustre と S3 バケットを統合する

FSx for Lustre をキャッシュレイヤーとして利用し、ストレージは S3 を利用します。 設定方法は実行したスタックの出力タブに必要コマンドを出力してあります。コピペして実行するだけです。

マウントした Lustre 内に bucket1 というディレクトリが作成されます。そのディレクトリ内の読み書きが S3 バケットと同期されます。bucket1名前は任意に指定できます。コピペしたコマンドではbucket1としていますがわかりやすい名前に修正しても問題ありません。

コマンドを実行するときは FSx for Lustre と S3 に対して権限がないと実行できません。最小権限で ParallelCluster のクラスターを生成する環境や、デフォルトのヘッドノードの IAM ロールの権限では足りないため注意してください。

実行サンプル

$ aws fsx create-data-repository-association --file-system-id fs-0e16f70b91b745b98 --file-system-path /bucket1 --batch-import-meta-data-on-create --data-repository-path s3://test-lustre-s3 --s3 "AutoImportPolicy={Events=[NEW,CHANGED,DELETED]},AutoExportPolicy={Events=[NEW,CHANGED,DELETED]}"

実行結果

{
    "Association": {
        "AssociationId": "dra-0d751162f1219161a",
        "ResourceARN": "arn:aws:fsx:ap-northeast-1:123456789012:association/fs-0e16f70b91b745b98/dra-0d751162f1219161a",
        "FileSystemId": "fs-0e16f70b91b745b98",
        "Lifecycle": "CREATING",
        "FileSystemPath": "/bucket1",
        "DataRepositoryPath": "s3://test-lustre-s3",
        "BatchImportMetaDataOnCreate": true,
        "ImportedFileChunkSize": 1024,
        "S3": {
            "AutoImportPolicy": {
                "Events": [
                    "NEW",
                    "CHANGED",
                    "DELETED"
                ]
            },
            "AutoExportPolicy": {
                "Events": [
                    "NEW",
                    "CHANGED",
                    "DELETED"
                ]
            }
        },
        "Tags": [],
        "CreationTime": "2022-08-27T15:57:54.684000+09:00"
    }
}

FSx for Lustre のデータリポジトリタブを確認すると、S3 バケットの統合設定が追加されます。

--batch-import-meta-data-on-createオプションにより統合後、S3 バケットのメタデータのインポートを実行します。メタデータのインポートを実行しないと、S3 バケット上に存在している既存オブジェクトがマウントしたヘッドノード、コンピュートノードから参照することができません。

S3 バケットのオブジェクト数にも依るとは思うのですがインポートに10分以上かかることもあります。オブジェクト数が少なくても10分以上待つことの方が体感では多いです。

Lustre 作成とメタデータのインポートの処理を合わせると準備に最低でも10分以上の待ち時間が発生します。ちょっとコーヒーを飲んで休憩でもしましょう。

なぜ Lustre 作成時に S3 バケットをリンクしないのですか?

Lustre 作成時に S3 バケットリンク設定は可能です。しかし、S3 バケット統合済みで作成した Lustre をマウントすると、マウントした Lustre ディレクトリlsコマンドを実行するとプロンプトが返ってこなく固まるケースによく遭遇しました。対策として S3 バケットのリンクは Lustre 作成後に実行して回避しています。

ヘッドノードに Lustre をマウントする

マウントコマンドは実行したスタックの出力タブに出力してあります。コピペして実行するだけです。

ヘッドノードにログインします。Lustre Client のインストールと、Lustre マウント用のディレクトリを作成します。ディレクトリ名は任意なのですが、コピペしたマウントコマンドのマウント先は/mnt/lustre指定になっていますので修正してください。

sudo amazon-linux-extras install -y lustre2.10
sudo mkdir -p /mnt/lustre

コピペしたコマンドを実行してマウントします。

$ sudo mount -t lustre -o noatime,flock fs-0e16f70b91b745b98.fsx.ap-northeast-1.amazonaws.com@tcp:/xta2fbmv /mnt/lustre

マウント確認

bucket1が Lustre に統合した S3 バケットとやりとりできるディレクトリです。

$ ll /mnt/lustre/
total 33
drwxr-xr-x 2 root root 33280 Aug 27 07:06 bucket1

S3 バケットのオブジェクトを Lustre を介して読み書きできます。表示されているファイルはもともと Lustre 経由で書き込みしていたファイルです。

$ ls -l /mnt/lustre/bucket1/
total 3
-rw-rw-r-- 1 ec2-user ec2-user   0 Aug 22 11:04 aaaaaa.txt
-rw-rw-r-- 1 ec2-user ec2-user  13 Aug 23 01:01 bbbbbbbbb.txt
-rw-rw-r-- 1 ec2-user ec2-user   4 Aug 22 11:10 b.txt
-rw-rw-r-- 1 ec2-user ec2-user   0 Aug 22 11:01 c2.txt
-rw-rw-r-- 1 ec2-user ec2-user   0 Aug 21 13:55 c3.txt
-rwxr-xr-x 1 root     root     110 Aug 21 10:38 index.html
-rw-rw-r-- 1 ec2-user ec2-user  14 Aug 23 00:54 test.txt

index.htmlrootユーザーになっているのは、S3 バケットに直接アップロードしたオブジェクトです。必要に応じて所有者、グループを変更してください。

sudo chown ec2-user. /mnt/lustre/bucket1

chown -Rで実行したいですが S3 上のオブジェクト数が多いと時間がかかると思います。Lustre 上の読み書きはsudoでつけて実行することも検討した方がよいです。

一度ファイルが多いので掃除します。S3 バケット上からもファイル(オブジェクト)が削除されます。

$ rm /mnt/lustre/bucket1/*.txt

コンピュートノードに Lustre をマウントできるようにする

コンピュートノードは起動のたびに設定を入れる必要があります。 postinstall.shから Lustre Client のインストールと、マウントコマンドを実行するように設定します。

postinstall.sh

#! /bin/bash

amazon-linux-extras install -y lustre2.10
mkdir -p /mnt/lustre
sudo mount -t lustre -o noatime,flock fs-0e16f70b91b745b98.fsx.ap-northeast-1.amazonaws.com@tcp:/xta2fbmv /mnt/lustre
chown ec2-user. /mnt/lustre

手間なところは Lustre を作成・削除するたびに Lustre の ID が変わるため、postinstall.shの修正が必要です。

コンピュートノードから Lustre へアクセスしてみる

Lustre と統合した S3 バケットにファイルを書き込むテストジョブを作成しました。

test.sh

#! /bin/bash

echo $HOSTNAME >> /mnt/lustre/bucket1/msg.txt

ヘッドノードでジョブをサブミットします。

$ sbatch -p debug-2 test.sh

しばらく待つと Lustre にmsg.txtが書き込まれています。ホスト名もコンピュートノードのものでした。コンピュートノードから Lustre へのアクセスが確認できました。

$ ll /mnt/lustre/bucket1/
total 1
-rwxr-xr-x 1 root     root     110 Aug 21 10:38 index.html
-rw-rw-r-- 1 ec2-user ec2-user  35 Aug 27 07:37 msg.txt

$ cat /mnt/lustre/bucket1/msg.txt
debug-2-dy-debug-run-postinstall-1

作成・削除可能な Lustre を ParallelCluster から扱う方法は以上です。

テンポラリーな Lustre の運用方法

Lustre の作成・削除方法と、Lustre を再作成したとき ParallelCluster に必要な設定変更を紹介します。

Lustre 削除

一度スタックを作成したあとは、スタックの更新から既存テンプレートの使用を選択します。

falseを選択することで Lustre を削除し課金を停止できます。S3 バケットと統合したディレクトリ(bucket1)に書き込んだファイルは S3 に保存されています。今回マウントしたパス(/mnt/lustre)の例ですとbucket1ディレクトリと同階層に保存したファイルは失われます。

Lustre 再作成とクラスターの設定変更

Lustre を再作成するときはtrueに変更して更新をかけてください。(削除の反対の手順)

FSx for Lustre と S3 バケットを統合するから同じステップを実行します。以下のサイクルです。

  1. スタックをtrueに更新して Lustre を作成
  2. S3 バケットを統合
  3. ヘッドノードに Lustre をマウント
  4. postinstall.shの修正
  5. 計算が終わったらスタックをfalseに更新して Lustre を削除

おわりに

手動対応の箇所が多いため時間あるときに自動化するよう改良したいと思います。手動対応でも需要があるかもしれませんので紹介しました。