Oracle Cloud Infrastructure Advent Calendar 2022Day 20

OCI: HPC Cluster 利用ガイド

Last updated at 2024-05-16Posted at 2022-12-19

はじめに

本ガイドは私が HPC Cluster の利用を通して得られた知見をまとめたもので、公式な利用ガイドではありません。
本ガイドの内容は Oracle として公式に表明されたものではなく、日本オラクルおよび米国 Oracle Corporation は一切の責任を負いません。また、本ガイドの記載内容について My Oracle Support へお問い合わせいただいても、回答することはできません。

公式な情報としては HPC Cluster をご確認ください。

本ガイドへのコメントやフィードバックをいただけます場合は、ページ最下部にある Qiita のコメントにお寄せください。なお、個別質問への回答やフィードバックへの対応はお約束できないことを、ご了承いただけますようお願い申し上げます。

上記をご理解頂いた上で本ガイドをご利用ください。

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 を利用される場合でよくある質問についてまとめています。

9. トラブルシューティング

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up