Slurm:galera cluster(mariadb)を使った冗長構成②

# 始めに

前回の続きですが出だしは前回の記述をそのまま掲載します。

#概要

最初slurmのactive/standbyを検証してみようかと考えていたのですが、DBの切替めんどいなぁっ、スクリプト書いて切り替えるぐらいなら、active/activeにトライしてみようと思い立ち挑戦することにしました。ただ厳密に言えば、slurm自身にactive/activeの機能はありません。

slurmctld,slurmdbd共にactive/standby機能があるので、ちゃんとフェイルオーバーするのかも検証していきたいと思います。

今回の記事はいつもお世話になっている Server Worldの記事を参考にmariadbとgalera clusterのインストールと設定をしていきます。

https://www.server-world.info/query?os=Ubuntu_22.04&p=mariadb&f=1


### ざっくり構成としてはこんな感じです
![スクリーンショット 2025-03-12 20.53.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/ec8f8374-3031-40ad-b1a7-2b83b127dd80.png)


前回はgalera clusterの設定まで終わりました。
次には、slurmのインストールですが、これは以前も書いたのでスキップして、
設定だけ記述していきます。


```:/etc/default/slurmd(ワーカーノード側の設定)
#プライマリ、セカンダリの順に記述します。
SLURMD_OPTIONS="--conf-server slurm2411m:6817,slurm2411m2:6817"
```

```:slurm2411m:/etc/slurm/slurmdbd.conf
# slurmDBD info
DbdAddr=10.100.100.71
DbdHost=slurm2411m
DbdBackupHost=slurm2411m2
SlurmUser=slurm
DebugLevel=verbose
LogFile=/var/log/slurm/slurmdbd.log
PidFile=/var/run/slurm/slurmdbd.pid

# Database info
StorageType=accounting_storage/mysql
StoragePass=slurm
StorageUser=slurm
StorageLoc=slurm_acct_db24

```

```:slurm2411m2:/etc/slurm/slurmdbd.conf
# slurmDBD info
DbdAddr=10.100.100.69
#プライマリとバックアップを入れ替える
DbdHost=slurm2411m22
DbdBackupHost=slurm2411
SlurmUser=slurm
DebugLevel=verbose
LogFile=/var/log/slurm/slurmdbd.log
PidFile=/var/run/slurm/slurmdbd.pid

# Database info
StorageType=accounting_storage/mysql
StoragePass=slurm
StorageUser=slurm
StorageLoc=slurm_acct_db24

```


```:slurm2411m:/etc/slurm/slurm.conf
SlurmctldHost=slurm2411m
SlurmctldHost=slurm2411m2
lurmctldTimeout=10
AccountingStorageHost=slurm2411m
AccountingStorageBackupHost=slurm2411m2

```

```:slurm2411m2:/etc/slurm/slurm.conf
SlurmctldHost=slurm2411m
SlurmctldHost=slurm2411m2
lurmctldTimeout=10
#こちらもプライマリとセカンダリを入れ替える
AccountingStorageHost=slurm2411m2
AccountingStorageBackupHost=slurm2411m
```

```:bash:slurm2411m(プライマリ側)
systemctl start slurmdbd
systemctl start slurmctld
```

```:bash:ワーカーノード
systemctl start slurmd
```

```:bash:slurm2411m(セカンダリ側)
systemctl start slurmdbd
systemctl start slurmctld
```



以上で検証環境の設定は終わりです。

では実際に検証に入っていきます。


### 検証１：プライマリ側のslurmdbdを停止したときの挙動

この検証では、プライマリ側のslurmdbdを停止してもsacctが使えるかどうかを見ていきます。
slurmdbdはジョブ投入には影響がないので、一応そこも確認します。


![スクリーンショット 2025-03-13 19.39.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/06312775-fb94-4f37-847d-aef3bc7b47a1.png)


本来ならログインノードを立てるべきなんでしょうが、今回用意していないので、ワーカーノード側から検証します。

まず正常に動いている事を確認します。
```:bash:ワーカー側

(base) testuser@slurm2411c1:/work/temp$ sbatch normal.sh 
Submitted batch job 26
(base) testuser@slurm2411c1:/work/temp$ sbatch normal.sh 
Submitted batch job 27

(base) testuser@slurm2411c1:/work/temp$ sacct
JobID           JobName  Partition    Account  AllocCPUS      State ExitCode 
------------ ---------- ---------- ---------- ---------- ---------- -------- 
10              test.sh   standard                     8  COMPLETED      0:0 
10.batch          batch                                8  COMPLETED      0:0 
11              test.sh   standard                     8  COMPLETED      0:0 
11.batch          batch                                8  COMPLETED      0:0 
12              test.sh   standard                     8  COMPLETED      0:0 
12.batch          batch                                8  COMPLETED      0:0 
13              test.sh   standard                     8  COMPLETED      0:0 
13.batch          batch                                8  COMPLETED      0:0 
14              test.sh   standard                     8  COMPLETED      0:0 
14.batch          batch                                8  COMPLETED      0:0 
15              test.sh   standard                     8  COMPLETED      0:0 
15.batch          batch                                8  COMPLETED      0:0 
16              test.sh   standard                     8  COMPLETED      0:0 
16.batch          batch                                8  COMPLETED      0:0 
17              test.sh   standard                     8  COMPLETED      0:0 
17.batch          batch                                8  COMPLETED      0:0 
18              test.sh   standard                     8  COMPLETED      0:0 
18.batch          batch                                8  COMPLETED      0:0 
19              test.sh   standard                     8  COMPLETED      0:0 
19.batch          batch                                8  COMPLETED      0:0 
20              test.sh   standard                     8  COMPLETED      0:0 
20.batch          batch                                8  COMPLETED      0:0 
21              test.sh   standard                     8  COMPLETED      0:0 
21.batch          batch                                8  COMPLETED      0:0 
22              test.sh   standard                     8  COMPLETED      0:0 
22.batch          batch                                8  COMPLETED      0:0 
23              test.sh   standard                     8  COMPLETED      0:0 
23.batch          batch                                8  COMPLETED      0:0 
24              test.sh   standard                     8  COMPLETED      0:0 
24.batch          batch                                8  COMPLETED      0:0 
25              test.sh   standard                     8  COMPLETED      0:0 
25.batch          batch                                8  COMPLETED      0:0 
26              test.sh   standard                     8    RUNNING      0:0 
26.batch          batch                                8    RUNNING      0:0 
27              test.sh   standard                     0    PENDING      0:0 

(base) testuser@slurm2411c1:/work/temp$ squeue
JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
27  standard  test.sh  testuser PD       0:00      1 (Resources)
26  standard  test.sh  testuser  R       0:06      1 slurm2411c1

```

正常に動いている事を確認したので、プライマリ側のslurmdbdを停止します。
予想外だったのが、ログ出力には特段なにもメッセージが表示されなかった。

これはログレベルの問題かも。

sacctのコマンドをエラー無く実行出来たらslurmdbdのセカンダリにアクセス出来ている。
念のためsqueue,sbatchも問題無いか確認

```:bash:ワーカー側

sacct

squeue

sbatch normal.sh
sbatch normal.sh


```

slurmdbdを再開するとslurmctld.logに以下のログが出力され、プライマリ側のslurmdbdが復旧した事が分かる。しかしセカンダリに切り替わったメッセージが出ないのが解せない。

```:slurm2411m:/var/log/slurm/slurmctld.log
 accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd
```

### 検証２：セカンダリ側のslurmdbdを停止したときの挙動

![スクリーンショット 2025-03-14 8.11.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/3b41f493-0b8f-45e7-a4d9-d56820735b0b.png)


セカンダリは、上記手順をセカンダリ側で行いましたが、プライマリと同様で問題無く動作したので割愛します

### 検証３：両方のslurmdbdを停止したときの挙動

![スクリーンショット 2025-03-14 8.17.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/95bef4c3-b6f2-40c0-8dc1-b58038d3e220.png)

では、両方停止しているときはどんな状態になるのか試してみます。

```:bash:ワーカーノードで実行
squeue
JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
29  standard  test.sh  testuser  R       0:05      1 slurm2411c1

(base) testuser@slurm2411c1:/work/temp$ sbatch normal.sh 
Submitted batch job 30

(base) testuser@slurm2411c1:/work/temp$ sacct
sacct: error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
sacct: error: Sending PersistInit msg: Connection refused
sacct: error: Problem talking to the database: Connection refused
```

このようにジョブの投入や実行には影響はありませんが、ジョブの統計情報を確認することが出来なくなりました。


```:slurm2411m:/var/log/slurm/slurmctld.log

[2025-03-13T20:54:16.323] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:54:16.323] error: Sending PersistInit msg: Connection refused
[2025-03-13T20:54:26.001] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:54:26.001] error: Sending PersistInit msg: Connection refused
[2025-03-13T20:54:45.001] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:54:45.001] error: Sending PersistInit msg: Connection refused
[2025-03-13T20:55:03.001] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:55:03.001] error: Sending PersistInit msg: Connection refused
[2025-03-13T20:55:21.001] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:55:21.001] error: Sending PersistInit msg: Connection refused
[2025-03-13T20:55:31.001] error: _open_persist_conn: failed to open persistent connection to host:slurm2411m2:6819: Connection refused
[2025-03-13T20:55:31.001] error: Sending PersistInit msg: Connection refused

[2025-03-13T20:56:00.291] accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd
[2025-03-13T20:56:12.022] accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd

```
slurmdbdが両方とも通信出来ない事で定期的にエラーメッセージが出力されています。
そしてslurmdbdを両方とも復旧(サービス再開）したときのログが上記になります。

この後にsacctは問題無く実行出来るようになりました。
ここまではジョブの実行に影響がない検証でしたが、今度はslurmctld本体の障害について検証していきます。

### 検証４：プライマリ側のslurmctldを停止したときの挙動

![スクリーンショット 2025-03-14 8.29.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/ef910c2a-7c5b-42b3-b128-813ead2e8185.png)


まずはプライマリのslurmctldを停止します。

そうするとセカンダリのslurmctld.logには以下のようなメッセージが表示されます。


```:slurm2411m2:/var/log/slurm/slurmctld.log
[2025-03-14T08:49:21.132] error: ControlMachine slurm2411m not responding, BackupController1 slurm2411m2 taking over
[2025-03-14T08:49:21.132] Terminate signal SIGTERM received
[2025-03-14T08:49:21.136] accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd
[2025-03-14T08:49:21.177] Recovered state of 1 nodes
[2025-03-14T08:49:21.178] Recovered JobId=32 Assoc=0
[2025-03-14T08:49:21.179] Recovered JobId=33 Assoc=0
[2025-03-14T08:49:21.179] Recovered JobId=34 StepId=batch
[2025-03-14T08:49:21.179] Recovered JobId=34 Assoc=0
[2025-03-14T08:49:21.179] Recovered JobId=35 Assoc=0
[2025-03-14T08:49:21.179] Recovered information about 4 jobs
[2025-03-14T08:49:21.179] Recovered state of 1 partitions
[2025-03-14T08:49:21.180] Recovered state of 0 reservations
[2025-03-14T08:49:21.181] Running as primary controller
[2025-03-14T08:49:24.012] error: Node slurm2411c1 appears to have a different slurm.conf than the slurmctld.  This could cause issues with communication and functionality.  Please review both files and make sure they are the same.  If this is expected ignore, and set DebugFlags=NO_CONF_HASH in your slurm.conf.
```

slurmctlTimeout=10にしているので比較的早くフェイルオーバー(takeover）が発生しましたが、デフォルトだと１２０秒かかります。

またプライマリとセカンダリのslurm.confは微妙に設定が違うためワーカーノードと設定が違うとのメッセージが表示されます。これを解消するには``` scontrol reconfigure ```を実行しますが、今回は行いませんでした。

それではプライマリのslurmctldを再開する場合も見ていきます。

```:slurm2411m:/var/log/slurm/slurmctld.log
[2025-03-14T08:53:05.019] accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd
[2025-03-14T08:53:05.043] Recovered state of 1 nodes
[2025-03-14T08:53:05.044] Recovered JobId=32 Assoc=0
[2025-03-14T08:53:05.044] Recovered JobId=33 Assoc=0
[2025-03-14T08:53:05.044] Recovered JobId=34 Assoc=0
[2025-03-14T08:53:05.044] Recovered JobId=35 StepId=batch
[2025-03-14T08:53:05.044] Recovered JobId=35 Assoc=0
[2025-03-14T08:53:05.044] Recovered JobId=36 Assoc=0
[2025-03-14T08:53:05.044] Recovered JobId=37 Assoc=0
[2025-03-14T08:53:05.044] Recovered information about 6 jobs
[2025-03-14T08:53:05.045] Recovered state of 0 reservations
[2025-03-14T08:53:05.045] Running as primary controller
[2025-03-14T08:53:05.055] error: slurm_send_node_msg: [socket:[456585]] slurm_bufs_sendto(msg_type=RESPONSE_JOB_INFO) failed: Unexpected missing socket error
```
再開時にエラーが出ていますが、これはまだ完全にプライマリに戻らないうちに、コマンドsacct/squeueなどを実行するとこういうエラーが表示されますが一時的な問題です。

```:slurm2411m2:/var/log/slurm/slurmctld.log
[2025-03-14T08:52:36.552] Performing RPC: REQUEST_CONTROL
[2025-03-14T08:52:36.552] Terminate signal SIGTERM received
[2025-03-14T08:53:05.000] error: _slurm_rpc_shutdown_controller: REQUEST_CONTROL reply but backup not completely done relinquishing control.  Old state possible
[2025-03-14T08:53:05.001] Saving all slurm state
[2025-03-14T08:53:05.247] slurmctld running in background mode
[2025-03-14T08:53:07.989] error: Invalid RPC received MESSAGE_NODE_REGISTRATION_STATUS while in standby mode
```

上記は一部問題があります。

> error: _slurm_rpc_shutdown_controller: REQUEST_CONTROL reply but backup not completely done relinquishing control.  Old state possible 

正常に終了出来なかったため、ステータス情報が古い可能性があるとのメッセージがあります。事実、もう一回プライマリをダウンさせると、２度目のフェイルオーバーは失敗します。
これを解消するためには、一度プライマリが正常に戻った段階で、セカンダリのslurmctldを再起動する必要があります。この問題は後日追跡調査する予定

### 検証５：セカンダリ側のslurmctldを停止したときの挙動

![スクリーンショット 2025-03-14 12.52.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3856269/c858ccd4-1843-4447-9ec9-37cb009e5b28.png)


```:slurm2411m:/var/log/slurm/slurmctld.log

[2025-03-14T14:19:18.001] error: _shutdown_bu_thread:send/recv slurm2411m2: Connection refused
[2025-03-14T14:19:28.002] error: _shutdown_bu_thread:send/recv slurm2411m2: Connection refused
[2025-03-14T14:19:38.001] error: _shutdown_bu_thread:send/recv slurm2411m2: Connection refused

```
セカンダリを停止すると上記のように``` Connection refused ```が定期的に発生します。
ただしセカンダリなので、ワーカーノード側での実行には何一つ影響はありません。

セカンダリのslurmctldを再起動しても特段プライマリ側にはログが出力されません。

セカンダリのslurmctld.logでは通常通りのログが出力されるだけです。

```:slurm2411m2:/var/log/slurm/slurmctld.log
[2025-03-14T14:20:06.954] slurmctld version 24.11.1 started on cluster cluster(2175)
[2025-03-14T14:20:06.955] lua: initialized
[2025-03-14T14:20:06.956] slurmctld running in background mode

```

### 最後に

検証自身は他にも行っていますが、長くなったので掲載するのは以上です。

正直slurmはあまり冗長構成をしなくてもいいかなと個人的には思います。  
理由はサービス障害があっても結構すんなりサービス再起動で治るし、  
サーバー自体のハードウェア故障があった場合は、slurm以外にも大きく影響するので、
slurmだけの冗長構成は意味がないです。

ただし、既に他のサービスを冗長構成を組んでいる場合は、slurmも冗長構成を組むのはゆうこうで