はじめに
本ガイドは私が HPC Cluster の利用を通して得られた知見をまとめたもので、公式な利用ガイドではありません。
本ガイドの内容は Oracle として公式に表明されたものではなく、日本オラクルおよび米国 Oracle Corporation は一切の責任を負いません。また、本ガイドの記載内容について My Oracle Support へお問い合わせいただいても、回答することはできません。
公式な情報としては HPC Cluster をご確認ください。
本ガイドへのコメントやフィードバックをいただけます場合は、ページ最下部にある Qiita のコメントにお寄せください。なお、個別質問への回答やフィードバックへの対応はお約束できないことを、ご了承いただけますようお願い申し上げます。
上記をご理解頂いた上で本ガイドをご利用ください。
目次
- 概要
- HPC Clusterのデプロイ
- チュートリアル
- 運用・管理
- Autoscalingについて
- 監視
- HPCアプリケーションの実行
- FAQ
- トラブルシューティング
1. 概要
本利用ガイドでは Oracle Cloud Infrastructure (以後、OCI と記載) の Marketplace または Github で公開されている HPC Cluster についてご紹介します。
HPC Cluster とは？
OCI のMarketplace または Github で提供されている HPC 環境を簡単に構築するテンプレートで Terraform と Ansible のスクリプトで構成されています。
OCI では Terraform のマネージドサービスとして Resource Manager があり、 HPC Cluster はそれを利用することで OCI の Web コンソールからウィザード形式で簡単に HPC Cluster 環境をデプロイすることができます。
HPC Cluster では以下を構成することができます。
- ヘッドノードの作成
- ユーザ管理として LDAP の構成
- ジョブスケジューラの構成
- 計算ノードの構成
- 常時起動
- Autoscaling
- 常時起動と Autoscaling の併用
- NFS による共有領域の構成
- ログインサーバに NFS Server を同居
- File Storage Service の利用
2. HPC Clusterのデプロイ
ここでは HPC Cluster の構成として最も一般的な以下のアーキテクチャ図の構築手順について解説します。
事前準備
構築の前提条件として対象テナントの Administrater 権限、またはそれに準ずる権限が割り当てられているユーザーでの操作を想定しています。
Service Limit の確認
OCI では契約内容により利用できるインスタンスの量(Core 数、Memory 数など)の制限が設定されています。本手順では BM.Optimized3.36(36core, 512GB Memory/node) というインスタンスの利用を想定しています。これに必要なリソース量が使えるか確認をしてください。
利用するリージョンを指定します：
メニューから、Gabanance & Administration の Limits, Quotas and Usages をクリックする:
Scope で AD を選択し、Resource でここで利用する BM.Optimized3.36 インスタンスで利用できる core 数と Memory 容量を指定します。まずは core 数で、cores for opti と入力しリストされる赤枠の項目をクリックします。
続いて、memory for opti と入力して赤枠の項目をクリックします。
これで現在利用が許可されている core 数と memory 容量を確認できます。
以下の例では、core 数は 500 core まで許可されており、現状 4 core 利用済みで、残り 496 core 分利用できることが分かります。
memory 容量についても 7,000 GB まで許可されており、現状 56 GB 利用済みで、残り 6,944 GB 利用できることが分かります。
BM.Optimized3.36 のほかに計算ノードとして利用されるインスタンスのshape名とLimit名の対応は以下の様になりますので、ご利用になるshapeについて確認しましょう。
| Limit Name | Shape Name |
|---|---|
| optimized3-core-count | BM.Optimized3.36, VM.Optimized3.Flex |
| optimized3-memory-count | BM.Optimized3.36, VM.Optimized3.Flex |
| standard-e5-core-count | BM.Standard.E5.192, VM.Standard.E5.Flex |
| standard-e5-memory-count | BM.Standard.E5.192, VM.Standard.E5.Flex |
| standard-e4-core-count | BM.Standard.E4.128, VM.Standard.E4.Flex |
| standard-e4-memory-count | BM.Standard.E4.128, VM.Standard.E4.Flex |
| standard3-core-count | BM.Standard3.64, VM.Standard3.Flex |
| standard3-memory-count | BM.Standard3.64, VM.Standard3.Flex |
| gpu3-count | BM.GPU3.8, VM.GPU3.1, VM.GPU3.2, VM.GPU3.4 |
| gpu4-count | BM.GPU4.8 |
| gpu-a10-count | BM.GPU.A10.4, VM.GPU.A10.1, VM.GPU.A10.2 |
OCI で利用できる Shape(インスタンスタイプ)の種類と利用料金については以下をご確認ください。
・ コンピュート・シェイプ
・ Compute Pricing
その他、多数の Cluster Network を作成する場合には以下のリソースもご確認ください。
- Compute Management
- Cluster Networks : 作成可能な Cluster Network の数
- Pool Count : Cluster Network は Instance Pool を利用して複数のノードを生成しているので、Cluster Network と同じまたはそれ以上が望ましい
- Instance Configuration Count : Instance Pool にて作成するノードの設定情報を Instance Configuration と言いそれがいくつ作成可能か。HPC Cluster の場合は、Cluster Network に対して1つの Instance Configuration が生成されるので、それと同じかそれ以上が望ましい
(Option)コンパートメントの作成
OCI はコンパートメントという論理的な区画を作成することが可能です。
コンパートメントは複数作成することができ、作成する各種リソースをその論理区画内に配置することで一つのテナント内で複数の環境を効率よく管理することができます。
HPC Cluster を環境についても専用のコンパートメントを準備することを推奨いたします。
以下の例では poc という名前のコンパートメントの作成手順です。
以後、この poc コンパートメントを対象とした手順となります。別の名前を指定した場合は読み替えてください。
ポリシーの作成
HPC Cluster を利用するに当たり以下のポリシーを root コンパートメントまたは作成したコンパートメントに設定する必要があります。
この作業には administrator 権限が必要です。権限がない場合はテナント管理者へ追加を依頼してください。
また、以下の例では適用範囲を in tenancy としていますが、適宜 in compartment <コンパートメント名> など環境に応じた適切な設定を行ってください。
allow service compute_management to use tag-namespace in tenancy
allow service compute_management to manage compute-management-family in tenancy
allow service compute_management to read app-catalog-listing in tenancy
Autoscaling を利用する場合のポリシーとそこで指定する Dynamic Group の作成
まずは Dynamic Group を作成します。Dynamic Group は任意で指定が可能です。
以下の例では適用範囲を compartment としていますが、特定のインスタンスのみとする instance.id など環境に応じた適切な設定を行ってください。
Any {instance.compartment.id = '作成した CompartmentID を記入'}
画面操作フロー：
続いて Autoscaling 用のポリシーを追加します。
以下の例では適用範囲を in tenancy としていますが、適宜 in compartment <コンパートメント名> など環境に応じた適切な設定を行ってください。
allow dynamic-group autoscaling_dg to read app-catalog-listing in tenancy
allow dynamic-group autoscaling_dg to use tag-namespace in tenancy
allow dynamic-group autoscaling_dg to manage all-resources in compartment poc
HPC Cluster の作成
以下から対象のverの手順を開いてください。
- v2.10.5 (作成中)
- v2.10.4.1 ※非推奨（AutoscalingでのCluster作成にバグあり)
- v2.10.3 作成手順
- v2.9.2 作成手順
HPC Cluster環境の削除
本手順を実行すると、HPC Clusterで作成されたヘッドノード、マネージドNFSサービス(FSS)、VCN などすべてが削除されますのでご注意ください。
また、本手順の実行するときはAutoscalingで生成されたノードは削除されたあとに実行してください。
画面左上のメニューをクリックします。
検索ボックスにstack(日本語設定の場合はスタック)と入力し、右側のStackをクリックします。
以下の様にHPC-Cluster-YYYYMMDDhhmmがリストされます。表示されなかった場合は、画面左下のCompartmentを正しく選択してください。
以下の画面に変わるので、Destroyボタンをクリックします。再確認を求められるのでそこでもdestroyボタンをクリックします。
以下の画面に切り替わります。
削除が完了すると以下の様にSUCCEEDEDとなります。
なお、この構成するための情報自体(存在しても課金は発生しない)はまだ残っています。同じものを再作成したい場合は、Applyを実行すると同じものが構成されます。不要な場合はMore actionsからDelete Stackを選択することで削除可能です。
3. チュートリアル
本項目では、作成された環境へのアクセス方法やジョブの投入など基本的な使い方を解説します。
ヘッドノードへのアクセス
作成されたヘッドノードにアクセスしてみます。
指定した公開鍵に対する秘密鍵を利用して、opc ユーザで接続します。
% ssh -i ~/.ssh/id_rsa.pub opc@xyz.xyz.xyz.xyz
The authenticity of host 'xyz.xyz.xyz.xyz (xyz.xyz.xyz.xyz)' can't be established.
ED25519 key fingerprint is SHA256:K2hUiWK7NZKIH/RmldnW5kiuEzca7wemxzNrJ1mxOyg.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Last login: Fri Sep 30 14:36:52 2022 from test-cluster-bastion.public.cluster.oraclevcn.com
[opc@test-cluster-bastion ~]$
Slurm がセットアップされているので、sinfo を実行してます。
initial cluster sizeを0して構成をしたのでNODESは0で、STATE NODELISTはn/aとなります。
[opc@test-cluster-bastion ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
compute* up infinite 0 n/a
NFS サービスのマウント状況について確認します。
指定したとおり /share がNFSマウントがされています。これはヘッドノード、計算ノードともに同様です。
[opc@test-cluster-bastion ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 25M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/mapper/ocivolume-root 39G 19G 21G 47% /
/dev/mapper/ocivolume-oled 10G 112M 9.9G 2% /var/oled
/dev/sda2 1014M 531M 484M 53% /boot
/dev/sda1 100M 5.1M 95M 6% /boot/efi
172.16.0.98:/export/cluster 39G 19G 21G 47% /nfs/cluster
172.16.6.206:/share 8.0E 26M 8.0E 1% /share
tmpfs 6.3G 0 6.3G 0% /run/user/1000
ヘッドノードは/homeと/nfs/clusterとして以下を計算ノードに共有することになります。
[opc@test-cluster-bastion ~]$ sudo exportfs
/export/cluster
172.16.0.0/24
/export/cluster
172.16.4.0/22
/home 172.16.0.0/24
/home 172.16.4.0/22
サンプルジョブの実行
ジョブスクリプトの作成
ここでは2つの計算ノードで、MPI Pingpong を実行し、RDMA が通信できることを確認するサンプルジョブスクリプトを作成します。
#!/bin/sh
#SBATCH -J sample
#SBATCH -o sample.o%J
#SBATCH -e sample.e%J
#SBATCH -n 2
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --constraint hpc-default
cd ${SLURM_SUBMIT_DIR}
source /usr/mpi/gcc/openmpi-4.1.2a1/bin/mpivars.sh
scontrol show hostname $SLURM_JOB_NODELIS | sed 's/$/ slots=1/' > ./hostfile_${SLURM_JOB_ID}
mpirun -hostfile ./hostfile_${SLURM_JOB_ID} -np ${SLURM_NTASKS} -mca pml ucx -x UCX_NET_DEVICES=mlx5_2:1 -mca coll_hcoll_enable 0 -x UCX_IB_TRAFFIC_CLASS=105 -x UCX_IB_GID_INDEX=3 -x HCOLL_ENABLE_MCAST_ALL=0 /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 pingpong
sleep 60
ジョブスクリプトで利用できる Slurm 環境変数
ジョブスクリプトにおいて便利な環境変数があります。
以下はジョブスクリプトにて利用できる Slurm の環境変数の一部になります。ご参考にしてください。
| 環境変数 | 内容 |
|---|---|
| SLURM_JOB_CPUS_PER_NODE | ジョブ実行に使用されるホストとプロセス数のリスト |
| SLURM_JOB_ID | ジョブID |
| SLURM_JOB_NAME | sbatch -J で指定したジョブ名 |
| SLURM_JOB_NODELIST | ジョブが実行されるホスト名のリスト |
| SLURM_NTASKS | sbatch -n または --ntasks で指定されたプロセス数 |
| SLURM_JOB_NUM_NODES | 割り当てられたノード数 |
| SLURM_SUBMIT_DIR | ジョブが投入されたディレクトリ |
ジョブの投入
作成した job.sh を投入します。
[opc@test-cluster-bastion ~]$ sbatch test.sh
Submitted batch job 1
※ Autoscaling による制限についてはこのあとの Autoscaling の利用 を参照し、適切な設定を行ってください。
キューの確認
作成したジョブスクリプトが実行またはキューイングされていることを確認します。
[opc@test-cluster-bastion ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
1 compute sample opc PD 0:00 2 (Nodes required for job are DOWN, DRAINED or reserved for jobs in higher priority partitions)
キューにジョブが入ったことで計算ノードの生成が開始されます。
計算ノードの生成状況は以下のディレクトリに作成毎にファイルとして出力されます。今回の場合、create_compute-1-hpc_202312260642.logというファイルに作成するクラスタの状況がテキスト形式で出力されます。
[opc@test-cluster-bastion ~]$ cd /opt/oci-hpc/logs/
[opc@test-cluster-bastion logs]$ ls -rlt
total 308
-rw-r--r-- 1 opc opc 155 Dec 26 05:49 README
-rw-rw-r-- 1 opc opc 84845 Dec 26 05:59 initial_configure.log
-rw-r--r-- 1 opc opc 207664 Dec 26 06:53 create_compute-1-hpc_202312260642.log
-rw-r--r-- 1 opc opc 13718 Dec 26 07:06 crontab_slurm_20231226.log
正しく作成が完了すると最後に以下の様なログが出力されます。
[opc@test-cluster-bastion logs]$ tail create_compute-1-hpc_202312260642.log
null_resource.configure: Creation complete after 7m3s [id=4410803580183942911]
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.
Outputs:
cluster_ocid = "ocid1.clusternetwork.oc1.ap-tokyo-1.amaaaaaaksfnvmaatwylfuacy2zq4it2rdpbi62zqgspi6gciko6s2z7xuba"
hostnames = "inst-homug-compute-1-hpc,inst-oe418-compute-1-hpc"
ocids = "ocid1.instance.oc1.ap-tokyo-1.anxhiljrksfnvmacevh3rcqafb6tiepoj4x6jyf6a7hpwg6ivl4kbwzzdxdq,ocid1.instance.oc1.ap-tokyo-1.anxhiljrksfnvmacb6twmnqhrgbaj3qlzg72ddytg6oulxf2cx7gpacj6z4q"
private_ips = "172.16.4.136,172.16.5.62"
計算ノードが起動するとジョブが実行されます。
[opc@test-cluster-bastion ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
compute* up infinite 2 mix compute-hpc-node-[137,319]
キューの状況もR(Running)となります。
[opc@test-cluster-bastion ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
1 compute sample opc R 0:33 2 compute-hpc-node-[137,319]
ジョブの実行結果の確認
ジョブを投入したカレントディレクトリに以下のファイルが生成されます。
[opc@test-cluster-bastion ~]$ ls -l sample.*
-rw-rw-r-- 1 opc opc 0 Dec 26 06:53 sample.e1
-rw-rw-r-- 1 opc opc 2342 Dec 26 06:53 sample.o1
- sample.e1: エラー出力のファイル
- sample.o1: 標準出力のファイル
sample.o1 の結果を確認してみます。ノード間でRDMAで正しく通信されたことがt[usec]の値から判断できます。
sample.o1 の結果
[opc@test-cluster-bastion ~]$ cat sample.o1
#------------------------------------------------------------
# Intel (R) MPI Benchmarks 2018, MPI-1 part
#------------------------------------------------------------
# Date : Tue Dec 26 06:53:57 2023
# Machine : x86_64
# System : Linux
# Release : 4.18.0-425.13.1.el8_7.x86_64
# Version : #1 SMP Tue Feb 21 15:09:05 PST 2023
# MPI Version : 3.1
# MPI Thread Environment:
# Calling sequence was:
# /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 pingpong
# Minimum message length in bytes: 0
# Maximum message length in bytes: 4194304
#
# MPI_Datatype : MPI_BYTE
# MPI_Datatype for reductions : MPI_FLOAT
# MPI_Op : MPI_SUM
#
#
# List of Benchmarks to run:
# PingPong
#---------------------------------------------------
# Benchmarking PingPong
# #processes = 2
#---------------------------------------------------
#bytes #repetitions t[usec] Mbytes/sec
0 1000 1.65 0.00
1 1000 1.66 0.60
2 1000 1.67 1.20
4 1000 1.67 2.40
8 1000 1.68 4.76
16 1000 1.67 9.58
32 1000 1.71 18.75
64 1000 1.83 34.98
128 1000 1.87 68.38
256 1000 2.80 91.36
512 1000 2.22 230.62
1024 1000 2.33 439.94
2048 1000 3.04 674.33
4096 1000 3.77 1086.08
8192 1000 4.86 1685.14
16384 1000 6.74 2431.68
32768 1000 9.29 3527.79
65536 640 10.76 6088.00
131072 320 16.32 8029.49
262144 160 28.67 9143.78
524288 80 50.05 10476.15
1048576 40 92.80 11298.93
2097152 20 178.44 11752.56
4194304 10 349.71 11993.68
# All processes entering MPI_Finalize
ジョブ完了後の計算ノードの状態
ジョブの実行が完了すると以下の様にidle状態となります。デフォルトでは10分間このidle状態が継続されると計算ノードが削除されます。
[opc@test-cluster-bastion ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
compute* up infinite 2 idle compute-hpc-node-[137,319]
上記idleステータスのノードが現在どのような状態として管理されているか確認してみます。
/opt/oci-hpc/logs/にあるcrontab_slurm_YYYYMMDDhhmm.logファイルを確認してみます。
too young to die : 336 とあり、idle になって 336 秒経過していることが分かります。
[opc@test-cluster-bastion ~]$ cd /opt/oci-hpc/logs/
[opc@test-cluster-bastion logs]$ tail -f crontab_slurm_20231226.log
compute-1-hpc is too young to die : 336.956929 : compute-hpc-node-137
compute-1-hpc is too young to die : 337.056984 : compute-hpc-node-319
2023-12-26 07:11:02
[] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{'compute': {'hpc-default': 2}} current_nodes
{} building_nodes
600秒が経過をするとDeleting cluster compute-1-hpcと出力され、削除が開始されたことが分かります。
['compute-hpc-node-137', 'compute-hpc-node-319']
2023-12-26 07:16:01
[] cluster_to_build
[['compute-1-hpc']] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{'compute': {'hpc-default': 2}} current_nodes
{} building_nodes
Deleting cluster compute-1-hpc
クラスタの削除ログについては同ディレクトリのdelete_compute-1-hpc_YYYMMDDhhmm.logに出力されます。
[opc@test-cluster-bastion logs]$ ls -rlt
total 352
-rw-r--r-- 1 opc opc 155 Dec 26 05:49 README
-rw-rw-r-- 1 opc opc 84845 Dec 26 05:59 initial_configure.log
-rw-r--r-- 1 opc opc 207664 Dec 26 06:53 create_compute-1-hpc_202312260642.log
-rw-r--r-- 1 opc opc 16950 Dec 26 07:16 crontab_slurm_20231226.log
-rw-r--r-- 1 opc opc 40363 Dec 26 07:16 delete_compute-1-hpc_202312260642.log
正常に完了すると以下のようなログが出力されます。
[opc@test-cluster-bastion logs]$ tail delete_compute-1-hpc_202312260642.log
oci_core_instance_configuration.cluster-network-instance_configuration[0]: Destruction complete after 1s
oci_core_app_catalog_subscription.mp_image_subscription[0]: Destroying... [id=compartmentId/ocid1.compartment.oc1..aaaaaaaar2x7pjwox73b2exbcpbz7o2x53ngpmfo7tj764nku3pprtmjlkbq/listingId/ocid1.appcataloglisting.oc1..aaaaaaaahz2xiwfcsbebmqg7sp6lhdt6r2vsjro5jfukkl5cntlqvfhkbzaq/listingResourceVersion/OracleLinux-8-RHCK-OFED-5.4-3.6.8.1-2023.05.18-0]
random_pet.name: Destroying... [id=cunning-hen]
random_pet.name: Destruction complete after 0s
oci_core_app_catalog_subscription.mp_image_subscription[0]: Destruction complete after 1s
oci_core_app_catalog_listing_resource_version_agreement.mp_image_agreement[0]: Destroying... [id=2023-12-26 06:42:09.86 +0000 UTC]
oci_core_app_catalog_listing_resource_version_agreement.mp_image_agreement[0]: Destruction complete after 0s
Destroy complete! Resources: 9 destroyed.
削除が完了するとsinfoは元の状態に戻ります。
[opc@test-cluster-bastion ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
compute* up infinite 0 n/a
4. Autoscaling
HPC Cluster には Slurm のジョブキューの状況に応じて計算ノードの自動作成、削除を行う Autoscaling スクリプトが含まれています。
ここでは Autoscaling の利用に向けた設計や設定など解説します。
動作概要
Autoscaling スクリプトでは 1 ジョブに対して 1 クラスタの自動作成・削除が可能です。
基本的な動作フローは以下の通りです。
- ジョブを投入する
- Autoscaling スクリプトが cron にて起動され、ジョブキューを確認する
- ジョブがあった場合には、そのジョブに必要なノード数のクラスタを起動する
- クラスタが起動しジョブが実行される
- ジョブが完了したら、そのクラスタはアイドル状態に入る。後続のジョブがある場合はそれが実行される。
- アイドル状態で10分経過したクラスタは、autoscaling スクリプトにて削除される
Autoscaling の設計
ここでは Autoscaling の利用に向けた設計について解説します。
・ パーティション(ジョブキュー)とそこで利用する shape の指定と制限
・ クラスタを削除するタイミングの設定
パーティション(ジョブキュー)とそこで利用する shape の指定と制限
HPC Cluster で構成される Slurm ジョブスケジューラのパーティション(ジョブキュー)やそこで起動できる計算ノードの shape の指定と制限をするファイルが /opt/oci-hpc/conf/queues.confです。
queues.conf HPC Cluster デプロイ時に生成され、以下のようなケースで設定変更を行います。
・ autoscaling で生成されるノード数の制限を変更したい
・ パーティション(ジョブキュー)で利用する shape の追加や変更したい
・ 新たなパーティション(ジョブキュー)を作成したい
・ 計算ノードで利用する OS イメージを変更したい
これらの構成例を FAQ に載せていますので具体例はそちらを参照ください。
queues.conf ファイルはHPC Clusterのverにより記載内容が追加されることがあるので、以下から対象のverの内容を確認してください。
クラスタ数や計算ノード数の制限
Autoscaling で作成できるノード数などの制限を設計します。
これらの設定により、計算ノードの作りすぎ・使いすぎ防止を行うことができ、予算に応じた利用の制御が可能となります。
この制限の設定は以下の3つのパラメータで指定を行います。
・ max_number_nodes
・ max_cluster_size
・ max_cluster_count
これらを図式化すると以下のようになります。
例えば、最大クラス多数は 1 で、最大ノード数を 4 に制限したい場合は以下のようになります。
・ max_number_nodes: 4
・ max_cluster_size: 4
・ max_cluster_count: 1
これで、作成できるクラスタ数は 1 となり、クラスタ内の最大ノード数は 4 という制限を設定できます。
クラスタアイドル時間の設定
Autoscaling 利用において計算ノードでジョブが実行されないアイドル時間が 600 秒を超えると自動削除の対象となります。
600 秒がデフォルトですが、/opt/oci-hpc/autoscaling/crontab/autoscale_slurm.sh の 15行目の idle_time 値を変更することで任意の時間に制御可能です。
# seconds for a cluster to stay alive
idle_time=600 #seconds
ログ
autoscaling では以下の2種類のログが生成されます。
- cronログ
/opt/oci-hpc/logs/crontab_slurm_YYYYMMDD.log - 計算ノード作成・削除ログ
/opt/oci-hpc/logs/<create/delete>_<queueName>-<clusterNumber>-<instance_keyword>_YYYYMMDDHHSS.log
cronログ: crontab_slurm_YYYYMMDD.logファイル
このファイルに cron で毎分動作する /opt/oci-hpc/autoscaling/crontab/autoscale_slurm.sh スクリプトの出力ファイルです。
クラスタの作成状況や起動や削除の状況が出力されます。
初期状態の出力
クラスタの作成・削除が実行されていなく、作成済みのクラスタもない状態の出力です。
2022-07-30 06:41:01
[] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{} current_nodes
{} building_nodes
クラスタ作成開始時の出力
compute2 というパーティション(ジョブキュー)で、opc ユーザにより投入された Job-ID 71 により、vm-default というインスタンスタイプ(queues.confで記載されたもの)が作成中ということが分かります。
2022-07-30 06:43:01
[[1, 'vm-default', 'compute2', 71, 'opc']] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{} current_nodes
{} building_nodes
クラスタ作成中の出力
2022-07-30 06:44:01
[[1, 'vm-default', 'compute2', 71, 'opc']] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[[1, 'vm-default', 'compute2']] cluster_building
[] cluster_destroying
{} current_nodes
{'compute2': {'vm-default': 1}} building_nodes
稼働中のクラスタが存在する場合の出力
2022-07-30 06:49:01
[] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{'compute2': {'vm-default': 1}} current_nodes
{} building_nodes
クラスタ削除開始の出力
2022-07-30 07:01:01
[] cluster_to_build
[['compute2-1-amd']] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
[] cluster_destroying
{'compute2': {'vm-default': 1}} current_nodes
{} building_nodes
Deleting cluster compute2-1-amd
クラスタ削除中の出力
2022-07-30 07:02:01
[] cluster_to_build
[] cluster_to_destroy
{} nodes_to_destroy
[] cluster_building
['compute2-1-amd'] cluster_destroying
{} current_nodes
{} building_nodes
計算ノード作成・削除ログ: <create/delete>_<queueName>-<clusterNumber>-<instance_keyword>_YYYYMMDDHHSS.logファイル
クラスタの作成や削除は Terraform や Ansible スクリプトにより実行されますが、これらのファイルはそのスクリプトによる詳細なログになります。
主にクラスタの作成や削除になにか問題があったときの調査を行う場合に参照します。
注意事項
OCI コンソールから計算ノードを削除してはいけない
Autoscaling において計算ノードの作成と削除は /opt/oci-hpc/autoscaling/crontab/autoscale_slurm.sh スクリプトがクラスタの管理(/opt/oci-hpc/autoscaling/clusters/ディレクトリ配下)をしています。
OCI コンソールから計算ノードを削除することで、ステータスの差異が生まれ予期せぬ動作をしてしまいます。
計算ノードが起動している場合のヘッドノードの停止
計算ノードの作成と削除はヘッドノードで管理しています。
計算ノードが起動している状態でヘッドノードを停止すると、計算ノードはジョブの状態と関係なく起動し続けますのでご注意ください。
queues.conf ファイルの編集時の注意
- queues.conf は YAML 形式で記述を行いますので"インデント"にご注意ください。
- 編集後、そのままでは反映されません。設定を反映させるには
/opt/oci-hpc/bin/slurm_config.shを実行することで反映させることができます。これによりslurm.confやtopology.confなど slurm の設定ファイルが更新されます。
5. 運用・管理
LDAPユーザとグループの管理
HPC Cluster の構成時にデフォルトで Configure LDAP authentication from bastion にチェックを入れた場合、ヘッドノード に LDAP Server が構成されます。
各計算ノードもこの LDAP Server を参照するように構成されるので、必要なユーザやグループはここで一元管理をすることが可能です。
ご利用のverにより以下を参照ください(各verにより一部オプションが異なるため)。
SLURMの管理
QoS設定
6. 監視
7. HPCアプリケーション
HPC Clusterで作成された環境でアプリケーションのインストールや実行時の注意事項など別ページで記載していきます。
8. FAQ
HPC Cluster を利用される場合でよくある質問についてまとめています。