OCI: HPC Cluster v2.10.x 利用ガイド

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

公式な情報としては [HPC Cluster](https://cloudmarketplace.oracle.com/marketplace/en_US/listing/67628143) をご確認ください。

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

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

# 目次
1. 概要
2. HPC Clusterのデプロイ
3. 利用チュートリアル
5. 運用・管理
5. Autoscalingについて
6. 監視
7. HPCアプリケーションの実行
8. FAQ
9. トラブルシューティング

# 1. 概要
本利用ガイドでは Oracle Cloud Infrastructure (以後、OCI と記載) の [Marketplace](https://cloudmarketplace.oracle.com/marketplace/en_US/listing/67628143) または [Github](https://github.com/oracle-quickstart/oci-hpc) で公開されている 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をk
    - File Storage Service の利用


# 2. HPC Clusterのデプロイ
ここでは HPC Cluster の構成として最も一般的な以下のアーキテクチャ図の構築手順について解説します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/efef13ac-20e6-dbb8-6594-7dc13bd4746b.png)

## 事前準備
構築の前提条件として対象テナントの Administrater 権限、またはそれに準ずる権限が割り当てられているユーザーでの操作を想定しています。

### Service Limit の確認
OCI では契約内容により利用できるインスタンスの量(Core 数、Memory 数など)の制限が設定されています。本手順では BM.Optimized3.36(36core, 512GB Memory/node) というインスタンスの利用を想定しています。これに必要なリソース量が使えるか確認をしてください。

利用するリージョンを指定します：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/143a0209-1c55-602d-b3af-fb1aaae4787f.png)

メニューから、`Gabanance & Administration` の `Limits, Quotas and Usages` をクリックする:
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/f0754c68-d591-13f6-b1d8-9156e78467b6.png)

Scope で AD を選択し、Resource でここで利用する BM.Optimized3.36 インスタンスで利用できる core 数と Memory 容量を指定します。まずは core 数で、`cores for opti` と入力しリストされる赤枠の項目をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/3d8bf080-08b9-e12c-ac90-2b729a6a43ad.png)

続いて、`memory for opti` と入力して赤枠の項目をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/01e44ef6-f4d0-e87e-5de7-4f52d6eb71ba.png)

これで現在利用が許可されている core 数と memory 容量を確認できます。
以下の例では、core 数は 500 core まで許可されており、現状 4 core 利用済みで、残り 496 core 分利用できることが分かります。
memory 容量についても 7,000 GB まで許可されており、現状 56 GB 利用済みで、残り 6,944 GB 利用できることが分かります。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/872bccfd-c890-a9c0-b60a-e96a0317ba1c.png)

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(インスタンスタイプ)の種類と利用料金については以下をご確認ください。
[・ コンピュート・シェイプ](https://docs.oracle.com/ja-jp/iaas/Content/Compute/References/computeshapes.htm)
[・ Compute Pricing](https://www.oracle.com/cloud/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 コンパートメントを対象とした手順となります。別の名前を指定した場合は読み替えてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/fc7262c2-aae6-f908-3643-16fb1802ccd8.png)

### ポリシーの作成
HPC Cluster を利用するに当たり以下のポリシーを`root`コンパートメントまたは作成したコンパートメントに設定する必要があります。
ポリシー名は任意で問題ありませんが、ここでは`for_HPC_Cluster_Stack`とします。
この作業には`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
   ```


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/d3db38f0-f53d-42c7-99e4-cac9e4b28e8e.png)



### Autoscaling を利用する場合のポリシーとそこで指定する Dynamic Group の作成
Autoscalingを利用するには、ヘッドノードがインスタンスプリンシパルによりterraformのコードを実行可能にする必要があります(インスタンスの作成、削除をするため)。
まずは Dynamic Group を作成します。Dynamic Group名は`autoscaling_dg`とします。
以下の例では適用範囲を compartment としていますが、特定のインスタンスのみとする `instance.id` など環境に応じた適切な設定を行ってください。

```
Any {instance.compartment.id = '作成した CompartmentID を記入'}
```

画面操作フロー：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/795260c2-b147-d651-c554-2d5e58b443ca.png)



続いて Autoscaling 用のポリシーを追加します。
ポリシー名は任意で問題ありませんが、ここでは`for_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
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/3238769b-5d54-b2bb-c4ff-ff2efd0701ce.png)

## HPC Cluster の作成

以下から対象のverの手順を開いてください。
- v2.11.0 (本ガイドの対象外。マイナーバージョンのアップデートにより利用方法が多少変わるため)
- [v2.10.6.4 作成手順](https://qiita.com/itokazu/items/9cac119c4c4a3caa6c9a) 
- [v2.10.3 作成手順](https://qiita.com/itokazu/items/996869070d97eae04bb5) 
<!-- 
- [v2.9.2 作成手順](https://qiita.com/itokazu/items/39f4e8e5c263bb958ad6)
-->

## (オプション: HPC Cluster環境の削除)
本手順を実行すると、HPC Clusterで作成されたヘッドノード、マネージドNFSサービス(FSS)、VCN などすべてが削除されますのでご注意ください。
また、本手順の実行するときはAutoscalingで生成されたノードは削除されたあとに実行してください。

画面左上のメニューをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/c10633e2-3e92-cb68-759d-1c5c58ad8401.png)

検索ボックスに`stack`(日本語設定の場合は`スタック`)と入力し、右側の`Stack`をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/01480f04-dac2-3c7b-81f1-21d0f3545486.png)

以下の様に`HPC-Cluster-YYYYMMDDhhmm`がリストされます。表示されなかった場合は、画面左下の`Compartment`を正しく選択してください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/ffdb7510-8e2a-6046-7f0b-aa7024709ffc.png)

以下の画面に変わるので、`Destroy`ボタンをクリックします。再確認を求められるのでそこでも`destroy`ボタンをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/f2f920bc-a23d-fe49-8312-32f3160cb862.png)

以下の画面に切り替わります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/b88a0c74-69cc-5f80-a5a6-03f18d1cb56d.png)

削除が完了すると以下の様に`SUCCEEDED`となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/29812cfa-e455-4b8a-aa57-e4fd86d264c9.png)

なお、この構成するための情報自体(存在しても課金は発生しない)はまだ残っています。同じものを再作成したい場合は、`Apply`を実行すると同じものが構成されます。不要な場合は`More actions`から`Delete Stack`を選択することで削除可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/a23e7d57-ed1b-1eb4-6ed5-9d525f78a13c.png)



# 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
```

Autoscalingを利用する場合、ポリシーとDynamic Group設定が有効かを事前に確認しましょう。
以下のコマンドを実行して、エラーにならないことを確認します。

```
[opc@poc-controller ~]$  oci os ns get --auth instance_principal
{
  "data": "idqcucnenh88"
}
```

## サンプルジョブの実行

### ジョブスクリプトの作成

ここでは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]`の値から判断できます。

<details><summary>　sample.o1 の結果</summary>

<div>

```
[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
```
</div>
</details>


### ジョブ完了後の計算ノードの状態
ジョブの実行が完了すると以下の様に`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 クラスタの自動作成・削除が可能です。
基本的な動作フローは以下の通りです。
1. ジョブを投入する
2. Autoscaling スクリプトが cron にて起動され、ジョブキューを確認する
2. ジョブがあった場合には、そのジョブに必要なノード数のクラスタを起動する
2. クラスタが起動しジョブが実行される
2. ジョブが完了したら、そのクラスタはアイドル状態に入る。後続のジョブがある場合はそれが実行される。
2. アイドル状態で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の内容を確認してください。

- [v2.9.2](https://qiita.com/itokazu/items/09423861d8d4c2a3d121)
- [v2.10.4.1](https://qiita.com/itokazu/items/4dd1bbdc54f3f7e13e55)



### クラスタ数や計算ノード数の制限
Autoscaling で作成できるノード数などの制限を設計します。
これらの設定により、計算ノードの作りすぎ・使いすぎ防止を行うことができ、予算に応じた利用の制御が可能となります。

この制限の設定は以下の3つのパラメータで指定を行います。
・ max_number_nodes
・ max_cluster_size
・ max_cluster_count

これらを図式化すると以下のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108605/7d578178-ad6a-005f-fd8d-79da0cd8da19.png)

例えば、最大クラス多数は 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 スクリプトにより実行されますが、これらのファイルはそのスクリプトによる詳細なログになります。
主にクラスタの作成や削除になにか問題があったときの調査を行う場合に参照します。

## :warning:注意事項:warning:
### :warning::warning::warning:OCI コンソールから計算ノードを削除してはいけない
Autoscaling において計算ノードの作成と削除は `/opt/oci-hpc/autoscaling/crontab/autoscale_slurm.sh` スクリプトがクラスタの管理(`/opt/oci-hpc/autoscaling/clusters/`ディレクトリ配下)をしています。
OCI コンソールから計算ノードを削除することで、ステータスの差異が生まれ予期せぬ動作をしてしまいます。

### :warning::warning::warning:計算ノードが起動している場合のヘッドノードの停止
計算ノードの作成と削除はヘッドノードで管理しています。
計算ノードが起動している状態でヘッドノードを停止すると、計算ノードはジョブの状態と関係なく起動し続けますのでご注意ください。


### :warning: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により一部オプションが異なるため)。
- [v2.9.x](https://qiita.com/itokazu/items/cacccb548632127a693f)
- [v2.10.x](https://qiita.com/itokazu/items/25ace87c5c6851f1c11f)

## SLURMの管理
### QoS設定
- [ユーザーが投入できるジョブ数を制限する](https://qiita.com/itokazu/items/28cb38d6588482876fb1)



# 6. 監視
- [ジョブキューの監視](https://qiita.com/itokazu/items/62b9e46df72ed98ca369)
- [Cluster Network作成・削除の通知設定](https://qiita.com/itokazu/items/677df0806214acada95b)

# 7. HPCアプリケーション
HPC Clusterで作成された環境でアプリケーションのインストールや実行時の注意事項など別ページで記載していきます。
- [OpenFOAM v2312のインストールとテスト実行](https://qiita.com/itokazu/items/7e5cedcb5cba935b72de)
- [OpenFOAM v2106のインストールとテスト実行](https://qiita.com/itokazu/items/4e535e6d1ce69791da44)
- [STAR-CCM+の実行に関する情報](https://qiita.com/itokazu/items/ffdb308224a5ada34796)


# 8. FAQ
HPC Cluster を利用される場合でよくある質問についてまとめています。

- [MPI関連](https://qiita.com/itokazu/items/3ee3fa06aaf2ef3eb951)
- [Autoscaling関連](https://qiita.com/itokazu/items/b67d258e1d22ba489c1e)
- [プリポストノード関連](https://qiita.com/itokazu/items/4ddd157c519b746afacc)
- [その他](https://qiita.com/itokazu/items/cb4f019342eb6e0d66c8)



# 9. トラブルシューティング
- [計算ノード関連](https://qiita.com/itokazu/items/8591104ebd64dae21d69)
- [MPI関連](https://qiita.com/itokazu/items/de3539456f47f07d30da)
- [Autoscaling関連](https://qiita.com/itokazu/items/a62c872a9fc556f18ed6)