サーバプロビジョニングツール「Warewulf v4」の紹介

Diary
サーバプロビジョニングツール「Warewulf v4」の紹介
Page content

任意の構成で大量にサーバを構築

多数の計算ノード・演算ノードを連携させてジョブを実行する、いわゆる計算機環境・スパコン環境・HPC環境の運用現場を想像してみます。計算ノードはラックマウント型サーバの一種で、物理的に数百台の規模でラック内に設置されています。そのような計算ノードを大量に、任意の構成で工数をかけずに構築する「サーバプロビジョニング」は、運用には必須の技法のひとつです。また、サーバプロビジョニングの管理ツールとして、扱いやすいものが常に求められています。

最近の私は、それなりの台数の計算ノードのOS更新を行う業務において、「Warewulf」という老舗のサーバプロビジョニング管理ツールの、新バージョンを扱いました。このツールに関する日本語の情報がほとんど見当たらず、特に新バージョンのv4に関してはまだ皆無なので、簡単ですがWarewulf v4の紹介を行いたいと思います。

Warewulfとは

最初にWarewulfとは。Wikipediaにページがありましたので次にリンクします。ただし、過去のWarewulf v3をふまえて書かれている内容だと思われます。

過去のv3

そのWarewulf v3の本家サイトは次のURLです。v3はここ数年更新がされていない様子で、かつ、ドキュメント内にリンク切れもあるようです。

今回取り上げるv4

今回取り上げるのは、「The next generation of Warewulf.」と銘打っている次の「Warewulf v4」です。v3はPerlで書かれていましたが、v4はGoLangでリライトされています。

計算ノードをdisklessで起動する

Warewulfは、DHCPサーバとTFTP/HTTPサーバと配信イメージを統合して設定・管理するツールと言うこともでき、計算ノードのPXE起動を司ります。計算ノードを起動するときのWarewulf v4の働きは、具体的には次のようになります。

  1. 計算ノードはPXEで起動して、Warewulfサーバは計算ノードへ起動イメージを配信する
  2. 計算ノードへ配信されたイメージはメモリ上で展開され (＝ローカルストレージを使わない)、計算ノードはそのイメージで起動する

Warewulf v4は完全に「diskless」前提の設計になっていて、計算ノードの物理メモリ空間の一部をストレージ領域として確保しています。そのため、計算ノード1台あたりの実装メモリの全てをOSが使えることはなく、数GBは差し引いて考えておく必要があります。また、PXE起動した計算ノードのOSからはローカルストレージがもちろん見えるので、マウントして読み書きすることは可能です。

余談ですが、過去のwarewulf3の利用時には、次の2つのモードを使い分けていました。この場合は起動にローカルストレージを使う前提でした。

  • イメージ配信モード: 計算ノードはPXEで起動して、Warewulfサーバから配信されるイメージが計算ノードのローカルストレージに書き込まれる
  • 通常モード: 計算ノードはローカルストレージから起動する (正確には、計算ノードはPXEで起動して、Warewulfサーバから「ローカルストレージで起動せよ」という応答を受けて (応答がない場合はタイムアウトを経て)、ローカルストレージのイメージで起動する)

イメージ構成をレイヤーで管理する

Warewulf v4の特徴として挙げたい、実際に扱って「これは使い勝手が良い」と強く感じたポイントは、次のように各種のレイヤーに分けて配信イメージの構成が管理できるところです。

レイヤー内容例
Runtime OverlayOS起動中に定期的に上書きされるファイル/etc/hostsなど (ノード個別)
System OverlayOS起動時に下位レイヤーに上書きされるファイルネットワーク設定や/etc/hostnameなど (ノード個別)
Containerソフトウェア構成に沿ったファイルyum installで導入するパッケージなど (ノード共通)
Kernelkernelとkernel module

配信イメージの構成がこのようにレイヤーで分離されていることにより、

  • サービス提供中の計算ノードへソフトウェアを追加導入する場合のイメージを、「Container」レイヤーだけを差し替えることで準備する
  • ハードウェア (たとえばInfiniBand) 搭載機と非搭載機のイメージの差異を、「Kernel」と「Container」のレイヤーのみを調整することで吸収する
  • サービス提供中・OS起動中に変更されるファイルは「Runtime Overlay」で扱う

といった、変更部分を最小範囲に留めた、逆に言えば共通部分を大きく持たせたイメージ管理ができます。

さらに、前述のように、Warewulf v4はdiskless前提なので、Warewulfサーバで変更した構成を計算ノードへ反映するには、計算ノードを1度再起動するだけですばやく済みます。各計算ノードのローカルストレージへのイメージ書き込みの面倒を見る必要がありません。この時間的・工数的なメリットは、大量の計算ノードを相手に作業しているときにはとても大きいです。

おすすめします

サーバプロビジョニングの管理ツールとして、私はWarewulf以外を扱った経験がありません。しかしながら、今回取り上げたWarewulf v4は近年のHPC環境に馴染むスグレモノであり、disklessでの起動が問題とならない環境ならば選択候補の一つになり得るかもと思います。さわりだけの非常に簡単な紹介でしたが、もし機会あればお試しください。そろそろ、Pre-release状態のv4.1.0がリリースされる頃かもしれません。

ちなみに、CentOSやRocky Linuxに関わっているGregory M. Kurtzer氏が、Warewulfの開発を率いています。

参考リンク