33
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

(株)日立製作所 サービスコンピューティング研究部Advent Calendar 2019

Day 16

Slurm HPCクラスタとKubernetesを同居させてみた(前編)

Last updated at Posted at 2019-12-19

はじめに

こんにちは、(株)日立製作所 研究開発グループ サービスコンピューティング研究部の小林です。

DockerやKubernetesに代表されるコンテナ技術がWebアプリ開発を始め様々な場面で使われるようになりました。最近ではHPC向けのコンテナランタイムとしてSingularityが開発され、より一層コンテナ活用の幅が広がりそうですね。

本日のアドベントカレンダーでは、HPCジョブスケジューラの一つであるSlurmクラスタとコンテナオーケストレータのKubernetesクラスタを同居させSingularityベースのワークロードを双方から実行可能な環境を構築してみます。

アドベントカレンダーではHPCジョブスケジューラの一つであるPBS関する記事もあるので興味がある方は要チェックです。

なぜ同居させるのか

データ分析技術の多様化

従来のデータ分析に関するいくつかの主要な動向として、HPCクラスタを用いた大規模バッチ処理や並列同期型のシミュレーションなどが挙げられます。また、新しいデータ分析の潮流として機械学習や深層学習も一般的になりつつあります。
機械学習に関する技術開発は近年一層活発に行われ、開発技術がコンテナイメージとして公開されています。更にはコンテナのスケーラビリティや可搬性/再現性を最大化するコンテナオーケストレータとしてKubernetesが台頭し、コンテナを用いた機械学習のワークフローを管理するKubeflowなどの便利技術なども続々と開発されています。

HPCジョブスケージューラへのコンテナ統合

一方で、従来のHPCクラスタを用いたバッチ/パラレルジョブにコンテナ技術を取り入れる動きがあります。HPCジョブスケジューラの一つであるSlurmではコンテナ化されたジョブの実行をサポートし始めたり、HPCでの実行を想定したコンテナランタイムであるSingularityなども登場したことを受け、HPCジョブスケジューラとコンテナの距離は縮まっています。

HPCジョブとコンテナアプリのワークロード統合

更には、Kubernetes側からも従来のHPCジョブとコンテナベースの処理のワークロード統合を示唆するブログ記事や、Singularity用のKubernetes対応コンテナランタイムインターフェース(CRI)としてSingularity-CRIが開発されています。

特に、Singularity-CRIの登場により、HPCクラスタの多量のリソースの以下のような柔軟な活用が可能になります。

  • 従来のHPCジョブ実行
  • 実験作業の再現性確保が容易なコンテナベースのHPCジョブ実行
  • GPUなどの潤沢なリソースを投入した高スケールなコンテナベースのデータ分析

構成

SlurmとKubernetes(K8s)の同居クラスタを作ります。UbuntuベースのマスタサーバにはSlurmとK8sのマスタとして役割を、ワーカサーバには同じくSlurmとK8sのワーカとしての役割を実行させます。

また、K8sのコンテナランタイムには、一般的なDocker(Containerd)ではなくSingularityを使います。

fig1.png

手順

概要

手順の概要を示します。マスタサーバとワーカサーバではデーモンや依存ソフトで共通するものも多いので、作業が分岐する場合は適宜言及します。

  1. Slurmクラスタを構築する
    1. マスタ/ワーカ共通準備
    2. Slurmマスタの構築
    3. Slurmワーカの構築 (本日はここまで)
  2. Singularityを導入する(マスタ/ワーカ共通)
    1. Singularityの導入
    2. Singularity-CRI(Sycri)の導入
  3. K8sクラスタを構築する
    1. マスタ/ワーカ共通準備
    2. K8sマスタの構築
    3. K8sワーカの構築
    4. CNIの設定

1. Slurmクラスタを構築する

1.1. マスタ/ワーカ共通準備

Slurmサーバの構築方法は公式のQuickStartを参照します。
依存ツールのライブラリが足りないエラーが起きたのでこちらのサイトも参考にしています。

まずは認証用のMUNGEをインストールします。

sudo apt update
sudo apt install -y munge libmunge-dev libmunge2
sudo systemctl start munge && sudo systemctl enable munge

MUNGEはデーモンを起動すると認証用の秘密鍵を/etc/munge/munge.keyに作成します。この秘密鍵はSlurmクラスタのマスタ・ワーカで共通のものを使うので1.3.にてマスタの鍵をコピーします。また、MUNGE/var/log/munge以下にログを出力しますが、フォルダ所有者がユーザMUNGEでない場合起動に失敗する場合があります。

最新版のSlurmを入手してインストールします。執筆時点での最新版はslurm-19.05.4です。
インストール前に、依存するライブラリ等を導入していきます。

sudo apt install -y build-essential python

続いてSlurmをソースコードからビルドします。ビルド後にMUNGEのライブラリに参照できないエラーが出たのでconfigureのフラグを追加しました。

wget https://download.schedmd.com/slurm/slurm-19.05.4.tar.bz2
tar --bzip -x -f slurm*tar.bz2
cd slurm-19.05.4
sudo ./configure --with-munge="/usr/bin/munge"
sudo make && sudo make install

Slurm関連のサービスファイルを/etc/systemd/system/以下にコピーします。

sudo cp /home/ubuntu/slurm-19.05.4/etc/*.service /etc/systemd/system/

また、公式のSuper Quick Start7 NOTEにあるように、Slurm用のユーザを作成します。

sudo adduser slurm

Slurmユーザは、/var/run/spool, /var/log/syslogへの参照や書込権限が必要なのでグループなりユーザに権限を付与します。環境によってポリシーが異なると思いますが、rootグループなどにslurmユーザを加えて適宜必要なフォルダにグループ権限を与えるなどの対応があると思います。

1.2. Slurmマスタの構築

Slurmマスタサーバを構築します。構築前にMUNGEサービスが正常に動いていることをsystemctl status mungeなどで確認しておきましょう。
マスタサーバ構築では、Slurmクラスタのコンフィグ作成が主な作業になります。コンフィグの作成はSlurmが提供するWebGUIに必要事項を入力して出力されるファイルを/usr/local/etc/slurm.confに配置します。

私はUbuntuサーバ版を入れてしまったので、他のPCからブラウザアクセスして作成することにしました。設定のためだけにapache2を入れてhttp://HOSTNAME:80/html2/configurator.easy.htmlにアクセスします。

sudo apt install -y apache2
sudo ln -s /home/ubuntu/slurm-19.05.4/doc/html /var/www/html/html2

サーバの設定に必要なリソース情報は下記のコマンドで適宜取得します。

# CPU関連
lscpu | grep -E '^Thread|^Core|^Socket|^CPU\('
> CPU(s):              2
> Thread(s) per core:  1
> Core(s) per socket:  1
> Socket(s):           2
# メインメモリ関連
free -m
>             total        used        free      shared  buff/cache   available
> Mem:           7976         102        5514           0        2359        7570
> Swap:             0           0           0

ひとしき入力し終えたらsubmitボタンを押して得られる情報を/usr/local/etc/slurm.confとして出力します。
マスタサーバではslurmctldをサービスとて起動します。

sudo systemctl start slurmctld && sudo systemctl enable slurmctld

起動後にCan't open PID file /var/run/slurmctld.pid (yet?) after start: No such file or directoryなどのエラーが出る場合がありますが、適宜ユーザやフォルダの権限を見直します。

1.3. Slurmワーカの構築

ワーカで実施するべき作業は大きく2つです。

  • MUNGEの秘密鍵をマスタサーバから入手し利用
  • Slurmのコンフィグをマスタサーバから入手し利用

作業がうまく行かない場合は、マスタサーバとワーカサーバのMUNGEサービスやslurm関連サービスがキチンとActiveになっているか適宜確認します。

MUNGEインストール後、マスタサーバのmunge.keyをコピーしてMUNGEサービスを再起動します。

sudo scp SOME_USER@SLURM_MASTER:/etc/munge/munge.key SONE_USER@SLURM_WORKER:/ect/munge/munge.key
sudo systemctl restart munge

エラー無くサービスが起動できたことを確認します。

Slurmをインストール(サービスファイルのコピー含め)したのち、Slurmコンフィグをコピーして利用します。

sudo scp SOME_USER@SLURM_MASTER:/usr/local/etc/slurm.conf SONE_USER@SLURM_WORKER:/usr/local/etc/slurm.conf
sudo chown root:root /usr/local/etc/slurm.conf
sudo start slurmd && sudo systemctl enable slurmd

ここまで完了し、SlurmマスタサーバでMUNGESlurmCtldが、ワーカサーバでMUNGESlurmdが正常稼働していること確認してからマスタサーバでsinfoを実行します。AVAILupならSlurmクラスタの起動完了です。

sinfo
> PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
> debug*       up   infinite      1   idle test-slurm2

前編のおわりに

本日の投稿ではSlurmKubernetesの同居クラスタ構築に関して、システム構成とSlurmクラスタの構築手順を紹介しました。後編の投稿ではSingularityとSingularity-CRIを利用して稼働するKubernetesクラスタの構築手順とクラスタのサンプル実行を紹介したいと思います。

33
17
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
33
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?