SLURM

SLURMは米国ローレンス・リバモア国立研究所[Lawrence Livermore National Laboratory, LLNL]によって2002年に初期開発が行われ, その後SchedMD社が中心的な開発および商用サポートを担っている.学術研究機関から産業界まで広く採用され, 現在では世界の主要なHPCクラスタ, 特にTOP500スーパーコンピュータの半数以上で標準的なジョブ管理システムとして利用されている.

その設計はモジュラー構造を採り, 主に以下の構成要素からなる.第一に, SLURMctld[コントローラデーモン]は, クラスタ全体の状態管理およびジョブスケジューリングを統括する中核プロセスであり, 通常は高可用性のためにプライマリ・バックアップ構成で運用される.第二に, SLURMd[ノードデーモン]は各計算ノード上で動作し, ジョブの起動・実行・監視・状態報告を担当し, リソース使用状況をSLURMctldに報告する.第三に, SLURMdbd[データベースデーモン]は, ジョブの履歴・会計情報・ユーザ統計・QOS[Quality of Service]設定などを永続的に保持するデータ管理コンポーネントであり, 通常はMySQLまたはMariaDBなどのリレーショナルデータベースと連携して動作する.さらに, SLURMrestd[REST APIデーモン]はHTTPベースのAPIを提供し, 外部アプリケーションやポータルからのジョブ操作・監視を可能にしている.

SLURMのスケジューリング機構は, 先着順[FIFO], バックフィル[Backfill], 優先度ベース[Priority/Multifactor], フェアシェアリング[Fair-Share], トポロジー認識型スケジューリングなどのアルゴリズムをサポートし, プラグインによる柔軟な拡張が可能である.MPI[Message Passing Interface]やOpenMP, さらにはハイブリッド並列ジョブの実行も透過的に扱うことができる.ジョブ操作には, sbatch[バッチジョブ投入], srun[ジョブステップ実行], salloc[リソース確保], squeue[キュー確認], scancel[ジョブ停止], sinfo[ノード・パーティション情報表示], sacct[アカウンティング情報照会]などのコマンドが用いられる.

SLURMはパーティション[論理的ノードグループ], QOS[Quality of Service], リソース予約, ジョブ依存関係[依存実行・連鎖ジョブ]などの高度な機能を提供する.プラグインアーキテクチャにより, スケジューラ, 認証, アカウンティング, ネットワーク, ノード選択などを柔軟にカスタマイズできる.また, DockerやSingularity[現Apptainer]などのコンテナランタイムとの統合, GRES[Generic Resource Scheduling]によるGPU等の専用リソース管理, オンプレミスとクラウド資源の統合運用[Elastic Computing]にも対応している.

このようにSLURMは, クラスタ上での大規模分散計算を効率的かつ公平に管理するための拡張性の高い分散制御型ワークロードマネージャであり, HPCの運用基盤における中心的役割を担っている.その柔軟性・スケーラビリティ・オープン性により, 学術研究機関から産業界まで幅広く採用されている.

一方, Kubernetes[k8s]は, コンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するためのコンテナオーケストレーションプラットフォームであり, SLURMとは設計思想および適用領域が根本的に異なる.Kubernetesは, Googleによって開発され2014年にオープンソース化され, Cloud Native Computing Foundation[CNCF]の管理下で発展してきた.その主眼はWebサービスやマイクロサービス, クラウドネイティブアプリケーションの運用にあり, 高可用性・自己修復・宣言的構成管理・継続的デプロイメントを重視する.

SLURMとKubernetesの根本的相違は, ワークロードの性質とスケジューリング哲学にある.SLURMは, 有限の計算タスク[ジョブ]を効率的にバッチ処理することを目的とし, ジョブの開始時刻・実行時間・優先度・公平性・会計情報を厳密に管理する.一方Kubernetesは, 持続的に稼働するサービスの安定運用を目的とし, Pod[コンテナ群]を自動的に再起動・再配置することで望ましい状態を維持する.Kubernetesではジョブキューやフェアシェアリングといった概念は標準で存在せず, HPC的なスケジューリングを行うためにはVolcanoやKueueなどの拡張が必要となる.

リソース管理の観点でも, SLURMはノード間の物理的配置, NUMA構成, ネットワークトポロジーを考慮し, MPIジョブなどの密結合型並列処理に最適化されている.一方Kubernetesは, リソースリクエスト／リミットに基づく論理的なリソース管理を行い, 低レイテンシ通信やジョブ配列制御といったHPC固有要件は標準で想定していない.

SLURMはまた, ユーザおよびプロジェクト単位でのアカウンティング, フェアシェア制御, QOSベースの優先度管理などを標準で備える.これに対しKubernetesは, ネームスペース単位のリソースクォータ管理は可能であるものの, ジョブ単位の会計や課金機構は標準では提供していない.

ネットワークとストレージの扱いにおいても, SLURMはInfiniBandやOmni-PathなどのHPC向け高速インターコネクト, LustreやGPFSといった共有ファイルシステムとの統合を前提とするのに対し, KubernetesはSoftware Defined Networking[SDN]およびContainer Storage Interface[CSI]によりクラウド環境での動的・抽象的リソース管理を行う.

結論として, SLURMは科学技術計算・工学シミュレーション・大規模データ解析などバッチ型・密結合並列型HPCワークロードに最適化された成熟したシステムであり, Kubernetesはクラウドネイティブ・マイクロサービス型ワークロードに特化したプラットフォームである.両者は近年統合的に運用されることも増えつつあるが, 設計思想・スケジューリング哲学・リソースモデルの差異により, 現時点では依然として明確に補完関係にある.

Mathematics is the language with which God has written the universe.