Google Cloud HPCクラスター(Schedmd-Slurm-GCP)各ノードのNFS共有・マウント状況

Google Cloud のクラウドHPC環境としてSchedmd-Slurm-GCPのHPCクラスターを構築しました。各ノード間で共有されているディレクトリを調査しました。

大村保貴

2021.07.11

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

Schedmd-Slurm-GCPのHPCクラスター環境を構築しました。各ノード間で共有されているディレクトリを確認する機会がありましたのでまとめます。

確認結果

コントローラーノードから各ノードへ特定ディレクトリが共有されている。

検証環境

Schedmd-Slurm-GCP

項目	値
バージョン	4.0.0
オペレーティングシステム	CentOS 7
パッケージの内容	Slurm 20.11.4

構築方法

各ノードのNFS共有・マウント状況

HPCクラスター間でデータや、設定ファイルを共有する必要があります。ログインノード、コントローラーノード、コンピューノードの合計3ノードを個別に状況を確認します。

ログインノード

コントローラーノードから4個のディレクトリがマウントされていました。

$ df -h
Filesystem                                           Size  Used Avail Use% Mounted on
devtmpfs                                             3.9G     0  3.9G   0% /dev
tmpfs                                                3.9G     0  3.9G   0% /dev/shm
tmpfs                                                3.9G  8.5M  3.9G   1% /run
tmpfs                                                3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda2                                             30G   11G   20G  36% /
tmpfs                                                3.9G   52K  3.9G   1% /tmp
/dev/sda1                                            200M   12M  189M   6% /boot/efi
blog-sample-cluster-controller:/usr/local/etc/slurm   30G   11G   20G  36% /usr/local/etc/slurm
blog-sample-cluster-controller:/etc/munge             30G   11G   20G  36% /etc/munge
blog-sample-cluster-controller:/home                  30G   11G   20G  36% /home
blog-sample-cluster-controller:/apps                  30G   11G   20G  36% /apps
tmpfs                                                783M     0  783M   0% /run/user/0
tmpfs                                                783M     0  783M   0% /run/user/1347777605

コントローラーノード

NFS共有状況を確認します。ログインノードにマウントされていたディレクトリがエクスポートされています。

$ showmount -e
Export list for blog-sample-cluster-controller:
/apps                *
/home                *
/etc/munge           *
/usr/local/etc/slurm *

コントローラーノードの/dev/sda2のディスクサイズには気をつけた方が良さそうです。HPCクラスター構築時のデフォルトサイズが30GBだったので、デフォルトのままHPCクラスターをデプロイしています。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  8.5M  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda2        30G   11G   20G  36% /
tmpfs           3.9G   56K  3.9G   1% /tmp
/dev/sda1       200M   12M  189M   6% /boot/efi
tmpfs           783M     0  783M   0% /run/user/0
tmpfs           783M     0  783M   0% /run/user/1347777605

コンピューノード

テストジョブを投げてコンピューノードを起動させ確認しました。ログインノードと同様にコンピューノードのディレクトリがマウントされています。

$ df -h
Filesystem                                           Size  Used Avail Use% Mounted on
devtmpfs                                             3.9G     0  3.9G   0% /dev
tmpfs                                                3.9G     0  3.9G   0% /dev/shm
tmpfs                                                3.9G  8.5M  3.9G   1% /run
tmpfs                                                3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda2                                             30G   11G   20G  36% /
tmpfs                                                3.9G   52K  3.9G   1% /tmp
/dev/sda1                                            200M   12M  189M   6% /boot/efi
blog-sample-cluster-controller:/usr/local/etc/slurm   30G   11G   20G  36% /usr/local/etc/slurm
blog-sample-cluster-controller:/apps                  30G   11G   20G  36% /apps
blog-sample-cluster-controller:/home                  30G   11G   20G  36% /home
blog-sample-cluster-controller:/etc/munge             30G   11G   20G  36% /etc/munge
tmpfs                                                783M     0  783M   0% /run/user/1347777605

NFS共有ディレクトリの内容を確認

コントローラーノードから共有されているディレクトリには何が保存されているのか？ログインノードから確認してみます。

/home

ログインノードにログインしたユーザのホームディレクトリは、コントローラーノードから共有されたディレクトリがマウントされているパスでした。

$ ll /home
total 0
drwx------ 3 cloud-hpc-image-guitar         cloud-hpc-image-guitar          74 Jan 28 08:26 cloud-hpc-image-guitar
drwx------ 3 hongbolu                       hongbolu                        74 Jan 28 08:26 hongbolu
drwx------ 3 jianyang                       jianyang                        74 Jan 28 08:26 jianyang
drwxr-xr-x 2 ohmura_yasutaka_classmethod_jp ohmura_yasutaka_classmethod_jp 171 Jul 10 01:54 ohmura_yasutaka_classme
thod_jp
drwx------ 3 tannerlove                     tannerlove                      74 Jan 28 08:26 tannerlove

/usr/local/etc/slurm

Slurmの設定ファイルが共有されていました。気になるのはデフォルトでslurmdbd.confが用意されています。Slurmで利用するデータベースとの接続設定などを記述するファイルです。Slurmではデータベースとの接続は推奨されているもののオプション扱いです。設定内容も確認してみましょう。

$ ll /usr/local/etc/slurm/
total 16
-rw-r--r-- 1 slurm slurm  153 Jul 10 00:59 cgroup.conf
-rw-r--r-- 1 slurm slurm 4485 Jul 10 00:59 slurm.conf
-rw------- 1 slurm slurm  720 Jul 10 00:59 slurmdbd.conf

StorageHostがlocalhostを指しています。コントローラーノードにMySQL系のデータベースが存在しているのでしょうか。

slurmdbd.conf

#ArchiveEvents=yes
#ArchiveJobs=yes
#ArchiveResvs=yes
#ArchiveSteps=no
#ArchiveSuspend=no
#ArchiveTXN=no
#ArchiveUsage=no

AuthType=auth/munge
AuthAltTypes=auth/jwt
AuthAltParameters=jwt_key=/var/spool/slurm/jwt_hs256.key

DbdHost=blog-sample-cluster-controller
DebugLevel=debug

#PurgeEventAfter=1month
#PurgeJobAfter=12month
#PurgeResvAfter=1month
#PurgeStepAfter=1month
#PurgeSuspendAfter=1month
#PurgeTXNAfter=12month
#PurgeUsageAfter=24month

LogFile=/var/log/slurm/slurmdbd.log
PidFile=/var/run/slurm/slurmdbd.pid

SlurmUser=slurm

StorageLoc=slurm_acct_db

StorageType=accounting_storage/mysql
StorageHost=localhost
StoragePort=3306
StorageUser=slurm
StoragePass=""
#StorageUser=database_mgr
#StoragePass=shazaam

ログインノードからsacctコマンドを打ってみました。Slurmのジョブ実行履歴が確認できました。コントローラーノードにデフォルトでSlurmのデータベースを持っておりジョブ実行履歴を記録しているようです。ここの話は長くなるのでまた別の機会に調べます。

$ sacct
       JobID    JobName  Partition    Account  AllocCPUS      State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
2               test.sh         p1                     1     FAILED      2:0
2.batch           batch                                1     FAILED      2:0
3               test.sh         p1                     1     FAILED      2:0
3.batch           batch                                1     FAILED      2:0
4               test.sh         p1                     1     FAILED      2:0
4.batch           batch                                1     FAILED      2:0
5               test.sh         p1                     1  COMPLETED      0:0
5.batch           batch                                1  COMPLETED      0:0

Slurmの設定ファイルも確認します。全文は長いため折りたたみます。

折りたたみ

slurm.conf

# slurm.conf file generated by configurator.html.
# Put this file on all nodes of your cluster.
# See the slurm.conf man page for more information.
#
ControlMachine=blog-sample-cluster-controller
#ControlAddr=
#BackupController=
#BackupAddr=
#
AuthType=auth/munge
AuthInfo=cred_expire=120
AuthAltTypes=auth/jwt
#CheckpointType=checkpoint/none
CredType=cred/munge
#DisableRootJobs=NO
#EnforcePartLimits=NO
#Epilog=
#FirstJobId=1
#MaxJobId=999999
#GroupUpdateForce=0
#GroupUpdateTime=600
#JobCheckpointDir=/var/slurm/checkpoint
#JobCredentialPrivateKey=
#JobCredentialPublicCertificate=
#JobFileAppend=0
#JobRequeue=1
#JobSubmitPlugins=1
#KillOnBadExit=0
#LaunchType=launch/slurm
#Licenses=foo*4,bar
#MailProg=/bin/mail
#MaxJobCount=5000
#MaxStepCount=40000
#MaxTasksPerNode=128
MpiDefault=none
#MpiParams=ports=#-#
#PluginDir=
#PlugStackConfig=
#PrivateData=jobs
LaunchParameters=enable_nss_slurm,use_interactive_step

# Always show cloud nodes. Otherwise cloud nodes are hidden until they are
# resumed. Having them shown can be useful in detecting downed nodes.
# NOTE: slurm won't allocate/resume nodes that are down. So in the case of
# preemptible nodes -- if gcp preempts a node, the node will eventually be put
# into a down date because the node will stop responding to the controller.
# (e.g. SlurmdTimeout).
PrivateData=cloud

ProctrackType=proctrack/cgroup

#Prolog=
#PrologFlags=
#PropagatePrioProcess=0
#PropagateResourceLimits=
#PropagateResourceLimitsExcept=Sched
#RebootProgram=

ReturnToService=2
#SallocDefaultCommand=
SlurmctldPidFile=/var/run/slurm/slurmctld.pid
SlurmctldPort=6820-6830
SlurmdPidFile=/var/run/slurm/slurmd.pid
SlurmdPort=6818
SlurmdSpoolDir=/var/spool/slurmd
SlurmUser=slurm
#SlurmdUser=root
#SrunEpilog=
#SrunProlog=
StateSaveLocation=/var/spool/slurm
SwitchType=switch/none
#TaskEpilog=
TaskPlugin=task/affinity,task/cgroup
#TaskPluginParam=
#TaskProlog=
#TopologyPlugin=topology/tree
#TmpFS=/tmp
#TrackWCKey=no
#TreeWidth=
#UnkillableStepProgram=
#UsePAM=0
#
#
# TIMERS
#BatchStartTimeout=10
#CompleteWait=0
#EpilogMsgTime=2000
#GetEnvTimeout=2
#HealthCheckInterval=0
#HealthCheckProgram=
InactiveLimit=0
KillWait=30
MessageTimeout=60
#ResvOverRun=0
MinJobAge=300
#OverTimeLimit=0
SlurmctldTimeout=120
SlurmdTimeout=300
#UnkillableStepTimeout=60
#VSizeFactor=0
Waittime=0
#
#
# SCHEDULING
#MaxMemPerCPU=0
#SchedulerTimeSlice=30
SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
#
#
# JOB PRIORITY
#PriorityFlags=
#PriorityType=priority/basic
#PriorityDecayHalfLife=
#PriorityCalcPeriod=
#PriorityFavorSmall=
#PriorityMaxAge=
#PriorityUsageResetPeriod=
#PriorityWeightAge=
#PriorityWeightFairshare=
#PriorityWeightJobSize=
#PriorityWeightPartition=
#PriorityWeightQOS=
#
#
# LOGGING AND ACCOUNTING
#AccountingStorageEnforce=associations,limits,qos,safe
AccountingStorageHost=blog-sample-cluster-controller
#AccountingStorageLoc=
#AccountingStoragePass=
#AccountingStoragePort=
AccountingStorageType=accounting_storage/slurmdbd
#AccountingStorageUser=
AccountingStoreJobComment=YES
ClusterName=blog-sample-cluster
#DebugFlags=powersave
#JobCompHost=
#JobCompLoc=
#JobCompPass=
#JobCompPort=
JobCompType=jobcomp/none
#JobCompUser=
#JobContainerType=job_container/none
JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/linux
SlurmctldDebug=info
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdDebug=info
SlurmdLogFile=/var/log/slurm/slurmd-%n.log
#
#

# Use Prolog/EpilogSlurmctld to make job to node one-to-one.
# enable_placement=true with c2-standards creates placement groups
# enable_placement=true w/out c2-standards creates one-to-one mappings of nodes.
# must set OverSubscribe=Exclusive on the corresponding partitions.
PrologSlurmctld=/slurm/scripts/resume.py
EpilogSlurmctld=/slurm/scripts/suspend.py

# POWER SAVE SUPPORT FOR IDLE NODES (optional)
SuspendProgram=/slurm/scripts/suspend.py
ResumeProgram=/slurm/scripts/resume.py
ResumeFailProgram=/slurm/scripts/suspend.py
SuspendTimeout=300
ResumeTimeout=300
ResumeRate=0
#SuspendExcNodes=
#SuspendExcParts=
SuspendRate=0
SuspendTime=300
#
SchedulerParameters=salloc_wait_nodes
SlurmctldParameters=cloud_dns,idle_on_node_suspend
CommunicationParameters=NoAddrCache
GresTypes=gpu
#
# COMPUTE NODES
NodeName=DEFAULT CPUs=1 RealMemory=7552 State=UNKNOWN
NodeName=blog-sample-cluster-compute-0-[0-9] State=CLOUD
PartitionName=p1 Nodes=blog-sample-cluster-compute-0-[0-9] MaxTime=INFINITE State=UP DefMemPerCPU=7552 LLN=yes Default=YES

/app

OpemMPIのディレクトリが共有されていました。

$ ll /apps
total 0
drwxr-xr-x 3 root root 21 Mar 12 22:18 modulefiles
drwxr-xr-x 3 root root 35 Mar 12 22:18 ompi

$ tree -L 2 /apps
/apps
├── modulefiles
│   └── openmpi
└── ompi
    ├── openmpi -> /apps/ompi/v4.1.x
    └── v4.1.x

/etc/munge

MUNGEはHPCクラスター環境で利用される資格情報を作成、検証を行う認証サービスです。コンピューノードとの認証用の鍵をコントローラーノードで共有しています。

$ sudo ls -l /etc/munge/
total 4
-r-------- 1 munge munge 1024 Jul 10 00:59 munge.key

おわりに

NFS共有されているディレクトリは忘れたころに何が共有されているんだっけ？と調べ直しがよくあったのでまとめました。当初はSlurmの設定ファイルを確認したくてNFS共有されているディレクトリを捜索していたのですが、Slurm用のデータベースをデフォルトで構築されるとは予想していませんでした。HPCクラスター単体でみると最初から用意されていて嬉しいですね。

Google Cloud HPCクラスター(Schedmd-Slurm-GCP)各ノードのNFS共有・マウント状況

確認結果

検証環境

構築方法

各ノードのNFS共有・マウント状況

ログインノード

コントローラーノード

コンピューノード

NFS共有ディレクトリの内容を確認

/home

/usr/local/etc/slurm

/app

/etc/munge

おわりに

参考

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

Google Cloud HPCクラスター(Schedmd-Slurm-GCP)各ノードのNFS共有・マウント状況

確認結果

検証環境

構築方法

各ノードのNFS共有・マウント状況

ログインノード

コントローラーノード

コンピューノード

NFS共有ディレクトリの内容を確認

/home

/usr/local/etc/slurm

/app

/etc/munge

おわりに

参考

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

関連記事

AWS ParallelCluster で Apptainer を利用して Trinity を実行してみた

AWS ParallelCluster 3.3.0 から 3.9.0 特定の操作により共有ストレージのデータが削除される問題と対処方法について

AWS ParallelCluster で Apptainer を実行する Apptainer on ParallelCluster の実装方法

AWS 上で HPC 環境構築用の CloudFormation テンプレート集を提供する HPC Recipes for AWS について

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！