この記事でわかること
- Slurmクラスターの全体構成図
- slurmdbd（ジョブの実行履歴管理）の役割と設計
- Prometheus + Grafanaによる監視構成
- 各コンポーネントが「なぜ必要か」の設計思想
この記事はこんな人向け
- Slurmの概念は理解できた、次に全体像を把握したい
- GPUクラスターの監視をどう設計すればいいかわからない
- 構築前に「何を用意すればいいか」を整理したい
この記事はシリーズの第2回です。
第1回：Slurmってなに？GPUクラスターを複数人で使うときに必要な理由を説明する
1. 全体構成図
まず今回のクラスター全体を図で示します。
各ノードの役割をまとめます。
| ノード | 動くサービス | 役割 |
|---|---|---|
| ログインVM | slurm-client / munge | ユーザーのジョブ投入口 |
| コントローラーVM | slurmctld / slurmdbd / munge | ジョブ管理の司令塔 |
| GPUノード × 12 | slurmd / munge / node_exporter / dcgm_exporter | ジョブの実行・メトリクス収集 |
| 監視VM | Prometheus / Grafana | メトリクス収集・可視化 |
| DBaaS（MariaDB） | - | ジョブの実行履歴管理 |
2. slurmdbd：ジョブの実行履歴管理
slurmdbdとは
slurmdbdはSlurmのデーモンのひとつで、ジョブの実行履歴をデータベースに記録・管理します。
「誰がいつ何のジョブをGPU何枚で何時間回したか」をすべてDBに蓄積します。
これがあることで：
- チームごとのGPU使用量の把握
- 使いすぎているユーザーへの制限（QoS）
- コスト計算・レポーティング
が可能になります。
なぜDBaaSを使ったのか
slurmdbdのバックエンドにはMySQLかMariaDBが必要です。
今回はFPT CLOUDのDBaaSを使いました。
理由はシンプルで、コントローラーVM上にDBを立てると：
- VMが落ちたときにジョブ履歴も消えるリスクがある
- DBの管理（バックアップ・冗長化）を自前でやる必要がある
DBaaSであればその辺りはマネージドで任せられます。
slurmdbdの構成図
3. 監視構成：Prometheus + Grafana
なぜ監視が必要か
GPUクラスターは「動いているかどうか」だけでなく、どれだけ使われているかを把握することが重要です。
- GPUが使われていないのにジョブがキューで詰まっていないか
- 特定ノードだけGPU温度が異常に高くないか
- ノードがいつの間にかダウンしていないか
これらを人間が目視で確認するのは無理です。監視の仕組みが必要です。
監視の全体構成
各Exporterの役割
node_exporter
各GPUノードで動かすExporterです。
CPU使用率・メモリ・ディスク・ネットワークなどOSレベルのメトリクスを収集します。
dcgm_exporter
NVIDIAが提供するGPU向けのExporterです。
GPU使用率・メモリ使用量・温度・電力消費などGPU固有のメトリクスを収集します。
GPU温度や使用率をリアルタイムで把握するには dcgm_exporter が必須です。
slurm_exporter
Slurmのジョブ状態・ノード状態をメトリクスとして公開するExporterです。
「現在実行中のジョブ数」「キュー待ちのジョブ数」「ノードの状態」などが取得できます。
主要メトリクス一覧
| メトリクス | Exporter | 用途 |
|---|---|---|
| CPU使用率 | node_exporter | ノードの負荷確認 |
| メモリ使用量 | node_exporter | メモリ枯渇の検知 |
| GPU使用率 | dcgm_exporter | GPUの稼働状況確認 |
| GPU温度 | dcgm_exporter | 異常発熱の検知 |
| GPUメモリ使用量 | dcgm_exporter | OOMの予兆検知 |
| 実行中ジョブ数 | slurm_exporter | クラスターの稼働状況 |
| キュー待ちジョブ数 | slurm_exporter | ジョブの詰まり検知 |
| ノード状態 | slurm_exporter | ノードダウンの検知 |
4. 設計のポイントまとめ
今回の設計で意識したことを整理します。
slurmdbdはDBaaSに分離する
コントローラーVMとDBを同居させるとSPOF（単一障害点）になります。
ジョブ履歴は運用上重要なデータなので、DBaaSで分離するのが安全です。
監視は専用VMに分離する
PrometheusとGrafanaをコントローラーVMから切り出すことで、
監視基盤とジョブ管理基盤が互いに影響しない構成になります。
コントローラーVMに負荷が集中するのを避ける意味でも有効です。
監視はExporterを役割ごとに分ける
OS・GPU・Slurmそれぞれ専用のExporterを使い分けることで、
問題発生時に「どのレイヤーで何が起きているか」を切り分けやすくなります。
まとめ
- slurmdbdはジョブの実行履歴管理を担い、バックエンドにMariaDBが必要
- DBaaSを使うことでDB管理の手間とリスクを減らせる
- PrometheusとGrafanaは監視専用VMに分離することで責務を明確に分けられる
- 監視はnode_exporter・dcgm_exporter・slurm_exporterの3つで構成
- 各Exporterを役割ごとに分けることで障害の切り分けが楽になる