AWS ParallelClusterのクラスター開発を効率的に行うためのTIPS

quiver

2020.07.13

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

AWS ParallelClusterを使って新規HPC環境を構築する場合、開発中に何度も $ pcluster create を実行したり、トラブルシュートすることになるかと思います。

クラスターの構築には時間がかかるし、コンポーネントは複雑に絡み合っているし、インスタンスの利用費は高額です。

そこで、開発時のトライアル&エラーを効率的に回すためのTIPSをいくつかまとめてみました。

クラスター作成時のロールバックを無効化

AWS ParallelCluster を使ってクラスターを作成すると、裏では AWS CloudFormation を使ってリソースが作成されます。

クラスターcreate時にエラーが発生すると、デフォルトではCloudFormationスタックのロールバックが走ります。

エラー時にロールバックしないオプション--norollbackを渡しましょう。エラー発生時点までのクラスター環境にアクセスし、エラー原因を調査できます。

$ pcluster create debug -c test.ini \
  --norollback
Beginning cluster creation for cluster: debug
Creating stack named: parallelcluster-debug
Status: parallelcluster-debug - CREATE_FAILED
Cluster creation failed.  Failed events:
  - AWS::CloudFormation::Stack parallelcluster-debug The following resource(s) failed to create: [MasterServerWaitCondition].
  - AWS::CloudFormation::WaitCondition MasterServerWaitCondition Received FAILURE signal with UniqueId i-09534da8fca4c924b

$ pcluster list
debug  CREATE_FAILED  2.7.0

ロールバックを無効化したおかげで、失敗時点のリソースが残っています。

AWS ParallelCluster 用の AMI を直接起動して動作確認

AWS ParallelClusterで起動するサーバーは、ジョブスケジューラーやコンパイラーなどHPC 向けのソフトウェア群がインストール済みの AMI から起動されています。

AMI は「AWS ParallelCluster のバージョン」 x 「プラットフォーム」の組み合わせごとに存在し、2.7.0 向けの Amazon Linux 2 の AMI であれば aws-parallelcluster-2.7.0-amzn2-hvm-202005172030 というようなAMI名です。

ノードに初期セットアップを検証したいときは、これら AMI を利用しましょう。

AWS ParallelCluster向けAMIの構成を把握

上述の通り、AWS ParallelClusterでサーバーを起動する場合、専用のソフトウェア群をインストールしたAMIから起動されます。

インストール済みパッケージ

gcc のような一般的なパッケージは、yumからそのままインストールしています。

ジョブスケジューラーなど特殊なプログラムは /opt 以下にインストールされています。

$ ls /opt/
amazon  aws  chef  intel  parallelcluster  rh  sge  slurm  torque

lustre クライアントのように、amazon-linux-extras でインストールされているものもあります。

$ amazon-linux-extras
...
 32  lustre2.10=latest        enabled      \
        [ =2.10.5  =2.10.8  =stable ]
...

環境変数の設定

/opt のようなイレギュラーなパスにインストールしたパッケージも正しく使えるように、環境変数をゴニョゴニョしています。

$ ls -1 /etc/profile.d/
256term.csh
256term.sh
bash_completion.sh
colorgrep.csh
colorgrep.sh
colorls.csh
colorls.sh
csh.local
efa.sh
flatpak.sh
lang.csh
lang.sh
less.csh
less.sh
modules.csh
modules.sh
pyenv.sh
qt.csh
qt.sh
sh.local
slurm.csh
slurm.sh
vim.csh
vim.sh
vte.sh
which2.csh
which2.sh

環境変数が正しく設定されているおかげで、起動直後からHPC系パッケージを利用できます。

$ module av

---------------------- /usr/share/Modules/modulefiles -----------------------
dot                        modules
libfabric-aws/1.9.0amzn1.1 null
module-git                 openmpi/4.0.3
module-info                use.own

-------------- /opt/intel/impi/2019.7.217/intel64/modulefiles/ --------------
intelmpi
$ which mpicc
/opt/amazon/openmpi/bin/mpicc

プロセスの起動方式によっては、環境変数がうまく設定されないケースもあるため、ご注意ください。

pre_install/post_install は CloudFormation の cfn-init を利用

設定ファイルの pre_install/post_install セクションを利用すると、ノードのブートストラップ時にスクリプトを実行させることができます。

...
[cluster default]
...
pre_install = s3://BUCKET/install.sh
...

この処理は、内部的には AWS CloudFormation の cfn-init で実現されています。

この処理に起因するログは、ノード内の cfn-init のログファイル、Amazon Linux 2 であれば /var/log/cfn-init* を確認しましょう。

例として、post-install 処理が失敗すると、以下のようなログが出力されます。

2020-07-12 15:59:57,479 P17932 [INFO] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-07-12 15:59:57,479 P17932 [INFO] Config shellRunPostInstall
2020-07-12 15:59:57,480 P17932 [INFO] ============================================================
2020-07-12 15:59:57,480 P17932 [INFO] Command runpostinstall
2020-07-12 16:00:00,265 P17932 [INFO] -----------------------Command Output-----------------------
2020-07-12 16:00:00,266 P17932 [INFO] 	hello from post-install
2020-07-12 16:00:00,266 P17932 [INFO] 	/tmp/tmp.VRgIMOUiLF: line 3: non-existent-command: command not found
2020-07-12 16:00:00,266 P17932 [INFO] 	parallelcluster: fetch_and_run - Failed to run boot_as_master postinstall, s3://BUCKET/install.sh failed with non 0 return code: 127
2020-07-12 16:00:00,266 P17932 [INFO] ------------------------------------------------------------
2020-07-12 16:00:00,266 P17932 [ERROR] Exited with error code 1

ノードログは CloudWatch Logs に転送される

AWS ParallelCluster 2.6.0 からノードの主要ログはデフォルトで CloudWatch Logsに転送されるようになっています。

Integration with Amazon CloudWatch Logs - AWS ParallelCluster

命名規則

ロググループ名 : /aws/parallelcluster/cluster-name (例:/aws/parallelcluster/testCluster)
ログストリーム名 : {hostname}.{instance_id}.{logIdentifier} (例:ip-172-31-10-46.i-02587cf29cc3048f3.nodewatcher)