Fluid Numerics を使用して WRF 気象予測モデルを実行するSlurm-GCP

1. はじめに

最終更新日: 2021-05-05

作業内容

この Codelab では、Slurm ジョブ スケジューラを使用して、Google Cloud に自動スケーリング ハイ パフォーマンス コンピューティング（HPC）クラスタをデプロイします。Spack を介して WRF® がインストールされたこのクラスタをデプロイする Terraform デプロイの例を使用します。次に、このインフラストラクチャを使用して、 CONUS 2.5 km ベンチマークまたは CONUS 12 km ベンチマークを実行します。

学習内容

• Google Cloud Platform で HPC クラスタを運用するための Identity and Access Management（IAM）ポリシーを構成する方法
• Slurm ジョブ スケジューラを使用してクラウドネイティブ HPC クラスタをデプロイする方法
• Slurm バッチジョブを使用して Google Cloud で WRF® を並列実行する方法

必要なもの

• SSH 認証鍵がアタッチされた Gmail アカウント、または Google Workspace、 Cloud Identity
• 課金が有効になっている Google Cloud Platform プロジェクト
• GCP プロジェクトのプロジェクト オーナーのロール
• 十分な Compute Engine の割り当て（480 個の c2 vCPU と 500 GB の PD-Standard ディスク）

2. 構成

Google Cloud API を有効にする

Google Cloud リソースを作成して使用するには、API を有効にする必要があります。

gcloud services enable compute.googleapis.com 

IAM ポリシーを設定する

HPC では、システム管理者とシステム ユーザーが明確に区別されます。システム管理者は通常、「ルートアクセス」権限を持ち、コンピューティング リソースを管理および運用できます。システム ユーザーは通常、ジョブの実行にリソースを使用するだけでよい研究者、科学者、アプリケーション エンジニアです。

Google Cloud では、OS Login API は Google Workspace、Cloud Identity、Gmail アカウントから POSIX ユーザー情報をプロビジョニングします。また、OS Login は GCP の Identity and Access Management（IAM） システムと統合され、ユーザーが Linux システムで権限を昇格できるかどうかを判断します。

このチュートリアルでは、システム管理者と Compute Engine 管理者のロールを割り当てていることを前提としています。次のタスクを完了するのに十分な権限を付与するように IAM ポリシーを構成します。

• Google Compute Engine（GCE）VM インスタンスの作成/削除
• GCE VM インスタンスへの SSH 接続

このチュートリアルを完了するために必要な IAM ロールを自分に付与するには、Google Cloud コンソールで次の操作を行います。

1. [ツールとサービス] メニューから [IAM と管理] > [IAM] に移動します。
2. ページの上部にある [追加] をクリックします。
3. [新しいメンバー] に Google Workspace アカウント、Cloud Identity アカウント、または Gmail アカウントを入力します。
4. Compute 管理者、Compute OS Login、サービス アカウント ユーザーのロールを追加します。
5. [保存] をクリックします。

オプション: コンソール UI がここに表示されているものと一致しない場合は、次の gcloud コマンドを実行すると同じ結果が得られます。YOUR_PROJECT と EMAIL_ADDRESS は、実際のプロジェクトとメールアドレスに置き換えてください。

• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/iam.serviceAccountUser –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.osLogin –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.admin –member="user:EMAIL_ADDRESS"

これで、ログインに HPC クラスタの作成を開始するために必要な権限が付与されました。

正しいロールを割り当てたことを確認するには、Cloud Shell を開き、次のコマンドを実行します。YOUR_PROJECT と EMAIL_ADDRESS は、実際のプロジェクトとメールアドレスに置き換えてください。

$ gcloud projects get-iam-policy YOUR_PROJECT --flatten="bindings[].members" --format='table(bindings.role)' --filter="bindings.members=user:EMAIL_ADDRESS"

このコマンドを実行すると、次の出力が生成されます。

ROLE
roles/compute.osLogin
roles/iam.serviceAccountUser
roles/compute.admin

注意: サードパーティの SSH（OpenSSH など）を使用してクラスタに接続する場合は、OS Login を使用して SSH 認証鍵を Cloud Identity プロファイルにアタッチしてください。 SSH 認証鍵を Cloud Identity プロファイルに追加する方法の詳細をご覧ください。

3. 割り当てが少ない場合: Terraform を使用して自動スケーリング HPC クラスタをデプロイする

このセクションでは、Slurm ジョブ スケジューラを含む自動スケーリング HPC クラスタをデプロイします。 使用するマシンタイプが小さく、使用する vCPU の数が少ないことを除いて、割り当てが多い場合と同じです。

重要: 新しいプロジェクトの C2 CPU のデフォルトの割り当ては通常 24 個の vCPU です。割り当てが多く、CONUS 2.5 km ベンチマークを実行する場合は、このセクションと次のセクションをスキップできます。

1. GCP で Cloud Shell を開きます。
2. FluidNumerics/slurm-gcp リポジトリのクローンを作成します。

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. WRF ディレクトリに移動します。

cd  ~/slurm-gcp/tf/examples/wrf

4. Terraform プランを作成して確認します。環境変数 WRF_NAME、WRF_PROJECT、WRF_ZONE を設定して、クラスタの名前、GCP プロジェクト、デプロイ先のゾーンを指定します。

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME="wrf-small"

5. Terraform を初めて実行する場合は、init コマンドを実行する必要があります。

terraform init

6. make コマンドを使用してプランを作成します。これにより、terraform が実行されます。

make plan

注: NFS でのファイル IO パフォーマンスを向上させるには、コントローラのディスクサイズを 2.5 TB に増やし、controller_disk_type を pd-ssd に変更します。ディスクサイズを変更するには、basic.tfvars.tmpl を編集して controller_disk_size_gb = 2500 を追加します。または、Lustre ファイル システムを使用することをおすすめします。

注意: ゾーンを選択するときは、C2 インスタンスを使用できるゾーンを選択してください。 利用可能なリージョンとゾーンの詳細

プロジェクトの割り当て制限の詳細については、Google Cloud コンソールの [割り当て] ページにすべての割り当てが一覧表示されます。[上限名: C2 CPU] を検索します。選択したゾーンで使用可能な C2 CPU が表示されます。

7. クラスタをデプロイします。インストールと設定のプロセスには最長で 2 時間ほどかかることがあります。デプロイ中に、WRF とそのすべての依存関係がインストールされます。

make apply

8. 前の手順で作成したログインノードに SSH で接続します。 このノードは前の手順で確認できます（おそらく wrf-small-login0 という名前です）。 これを行うには、コンソール メニュー項目 [Compute Engine] -> [VM インスタンス] の VM インスタンスのリストの横にある [SSH] ボタンをクリックします。

オプション: 次の gcloud コマンドを実行すると、ログインノード名が特定され、SSH で接続されます。

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

9. ログインノードに接続したら、クラスタの設定を確認するために、wrf モジュールが使用可能であることを確認します。

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. /apps/share/conus-12km に次の内容が含まれていることを確認します。

$  ls -1 /apps/share/conus-12km/
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

注: このデプロイでは、schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7 VM イメージを使用してビルドされたカスタム イメージを使用します。他のオペレーティング システム用の WRF は、Github の fluidnumerics/hpc-apps-gcp リポジトリを使用してビルドできます。

4. CONUS 12 km ベンチマークを実行する

CONUS 12 km ベンチマークを実行するには、Slurm バッチジョブを送信します。 このベンチマークの入力デッキは、wrf-gcp VM イメージの /apps/share/benchmarks/conus-12km に含まれています。

このセクションでは、クラスタのログインノードに SSH で接続する必要があります。

1. /apps/share から wrf-conus.sh バッチファイルの例をコピーします。

cp /apps/share/wrf-conus12.sh ~/

2. テキスト エディタで wrf-conus.sh を開き、--partition と --ntasks が正しく設定されていることを確認します。タスクの数は、ジョブの起動に使用する MPI ランクの数に設定する必要があります。このデモでは、タスクの数はジョブに使用される vCPU の数と同じで、使用可能な割り当てを超えないようにしてください。

注: クラスタで使用可能なパーティションは sinfo で一覧表示できます。このデモでは、タスクの数は MPI ランクの数と同じです。

#!/bin/bash
#SBATCH --partition=wrf
#SBATCH --ntasks=24
#SBATCH --ntasks-per-node=8
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-12km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

3. sbatch を使用してバッチジョブを送信します。

sbatch wrf-conus12.sh

注: コンピューティング ノードは、ジョブの送信時に必要に応じて作成されます。最初のジョブの送信では、ジョブが開始するまでに最長で 3 分ほどかかることがあります。

4. ジョブが完了するまで待ちます。このベンチマークは 6 時間の予測を実行するように構成されており、24 ランクで完了するまでに約 3 時間かかります。squeue を使用してジョブのステータスをモニタリングできます。
5. ジョブが完了したら、rsl.out.0000 の内容を確認して、「wrf: SUCCESS COMPLETE WRF」というステートメントが表示されていることを確認します。ジョブを複数回実行した場合（構成設定を間違えて再実行する必要があった場合など）、数値サフィックスは異なります。

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

5. 割り当てが多い場合: Terraform を使用して自動スケーリング HPC クラスタをデプロイする

このセクションでは、GCP に Slurm ジョブ スケジューラを含む自動スケーリング HPC クラスタをデプロイします。

重要: 新しいプロジェクトの C2 CPU のデフォルトの割り当ては通常 24 個の vCPU です。これでは、大規模な CONUS 2.5 km ベンチマークを実行するには十分ではありません。480 個の vCPU の割り当てがある場合は、この Codelab のこの部分を実行できます。

1. GCP で Cloud Shell を開きます。
2. FluidNumerics/slurm-gcp リポジトリのクローンを作成します。

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. WRF ディレクトリに移動します。

cd  ~/slurm-gcp/tf/examples/wrf

4. Terraform プランを作成して確認します。環境変数 WRF_NAME、WRF_PROJECT、WRF_ZONE、WRF_MAX_NODE、WRF_MACHINE_TYPE を設定して、クラスタの名前、GCP プロジェクト、デプロイ先のゾーン、ノードの最大数、マシンタイプを指定します。CONUS 2.5 km ベンチマークでは、480 個の MPI ランクでジョブを実行するために、少なくとも 8 個のノードを使用できる c2-standard-60 インスタンスを使用することをおすすめします。

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME=wrf-large
export WRF_MAX_NODE=5
export WRF_MACHINE_TYPE="c2-standard-60"

5. 上記で実行していない場合は、terraform init を実行して Terraform を起動する必要があります。

terraform init

6. make コマンドを使用してプランを作成します。

make plan

注: NFS でのファイル IO パフォーマンスを向上させるには、コントローラのディスクサイズを 2.5 TB に増やし、controller_disk_type を pd-ssd に変更します。ディスクサイズを変更するには、basic.tfvars.tmpl を編集して controller_disk_size_gb = 2500 を追加します。または、Lustre ファイル システムを使用することをおすすめします。

注意: ゾーンを選択するときは、C2 インスタンスを使用できるゾーンを選択してください。 利用可能なリージョンとゾーンの詳細

プロジェクトの割り当て制限の詳細については、Google Cloud コンソールの [割り当て] ページにすべての割り当てが一覧表示されます。[上限名: C2 CPU] を検索します。選択したゾーンで使用可能な C2 CPU が表示されます。

7. クラスタをデプロイします。インストールと設定のプロセスには最長で 2 時間ほどかかることがあります。デプロイ中に、WRF とそのすべての依存関係がインストールされます。

make apply

8. 前の手順で作成したログインノードに SSH で接続します。 このノードは前の手順で確認できます（おそらく wrf-large-login0 という名前です）。 これを行うには、コンソール メニュー項目 [Compute Engine] -> [VM インスタンス] の VM インスタンスのリストの横にある [SSH] ボタンをクリックします。

オプション: 次の gcloud コマンドを実行すると、ログインノード名が特定され、SSH で接続されます。

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

2 番目のコマンドを実行すると、Slurm ログインノードに接続されます。

9. ログインノードに接続したら、クラスタの設定を確認するために、wrf モジュールが使用可能であることを確認します。

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. /apps/share/conus-2.5km に次の内容が含まれていることを確認します。

$ ls -1 /apps/share/conus-2.5km
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
gfs.0p25.2018061700.f000.grib2
gfs.0p25.2018061700.f003.grib2
gfs.0p25.2018061700.f006.grib2
gfs.0p25.2018061700.f009.grib2
gfs.0p25.2018061700.f012.grib2
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

注: このデプロイでは、schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7 VM イメージを使用してビルドされたカスタム イメージを使用します。他のオペレーティング システム用の WRF は、Github の fluidnumerics/hpc-apps-gcp リポジトリを使用してビルドできます。

6. CONUS 2.5 km ベンチマークを実行する

CONUS 2.5 km ベンチマークを実行するには、Slurm バッチジョブを送信します。 このベンチマークの入力デッキは、wrf-gcp VM イメージの /apps/share/benchmarks/conus-2.5km に含まれています。

このセクションでは、クラスタのログインノードに SSH で接続する必要があります。

6. /apps/share から wrf-conus.sh バッチファイルの例をコピーします。

cp /apps/share/wrf-conus2p5.sh ~/

7. テキスト エディタで wrf-conus.sh を開き、--partition と --ntasks が正しく設定されていることを確認します。パーティションは c2-60 に設定する必要があります。タスクの数は、ジョブの起動に使用する MPI ランクの数に設定する必要があります。このデモでは、タスクの数はジョブに使用される vCPU の数と同じで、使用可能な割り当てを超えないようにしてください。

注: クラスタで使用可能なパーティションは sinfo で一覧表示できます。このデモでは、タスクの数は MPI ランクの数と同じです。

#!/bin/bash
#SBATCH --partition=c2-60
#SBATCH --ntasks=480
#SBATCH --ntasks-per-node=60
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-2.5km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

8. sbatch を使用してバッチジョブを送信します。

sbatch wrf-conus2p5.sh

注: コンピューティング ノードは、ジョブの送信時に必要に応じて作成されます。最初のジョブの送信では、ジョブが開始するまでに最長で 3 分ほどかかることがあります。

9. ジョブが完了するまで待ちます。このベンチマークは 6 時間の予測を実行するように構成されており、480 ランクで完了するまでに約 1 時間かかります。squeue を使用してジョブのステータスをモニタリングできます。
10. ジョブが完了したら、rsl.out.0000 の内容を確認して、「wrf: SUCCESS COMPLETE WRF」というステートメントが表示されていることを確認します。ジョブを複数回実行した場合（構成設定を間違えて再実行する必要があった場合など）、数値サフィックスは異なります。

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

7. 完了

この Codelab では、自動スケーリングのクラウドネイティブ HPC クラスタを作成し、Google Cloud Platform で並列 WRF® シミュレーションを実行しました。

クリーンアップ

この Codelab で使用したリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

プロジェクトの削除

課金を停止する最も簡単な方法は、Codelab 用に作成したプロジェクトを削除することです。

注意 : プロジェクトを削除すると、次の影響があります。

• プロジェクト内のすべての要素が削除されます。この Codelab で既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。appspot.com URL など、プロジェクト ID を使用する URL を保持するには、プロジェクト全体を削除するのではなく、プロジェクト内の選択したリソースを削除します。

複数の Codelab とクイックスタートを検討する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て制限を超えないようにできます。

1. Cloud コンソールで [リソースの管理] ページに移動します。[リソースの管理] ページに移動
2. プロジェクト リストで、削除するプロジェクトを選択し、[Delete ] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

個々のリソースの削除

1. Cloud Shell を開き、wrf のサンプル ディレクトリに移動します。

cd  ~/slurm-gcp/tf/examples/wrf

2. make destroy を実行して、すべてのリソースを削除します。

make destroy