Machine Learning向けのGPUクラスタ構築ツールNVIDIA/deepopsを触って見た話

Kota Tsuyuzaki
nttlabs
Published in
9 min readApr 24, 2019

こんにちは。NTT研究所の露崎です。

今日は機械学習等によく使われるGPUを複数台束ねてクラスターとして扱うために必要なツールのデプロイを自動化するツール “deepops” を紹介し、仮想環境での実行方法について解説します。

本稿のターゲットは主に、GPUサーバの管理を既に行なっている、または導入を検討されている方などのシステム管理者と考えています。

GPUと機械学習とdeepops

GPUは元々高精細な画像や動画のレンダリングなどに用いられていたハードウェアで近年機械学習(Machine Learning)やその一分野の深層学習(Deep Learning)などの演算器としてさかんに用いられてきています。しかし、一般的なCPUに比べ高価なため、コスト効率を上げるためには複数枚を集中管理し、ユーザの利用に合わせてリソースをシェアする方式が重要になってきます。

このリソースシェアの仕組みを実現するため、GPUの搭載されたサーバの管理やリソース共有を自動化する仕組みがdeepopsです。deepopsはGPUメーカであるNVIDIA社がOpen Source Softwareとして公開しているツールです。具体的にはGPUクラスタ環境に必要なソフトウェアをインストールするためのShellとAnsible Playbookの集合体になっています。

NVDIA® DGX™ Data Center Reference Design (Fig.3 DGX POD management software)

これは、deepopsのSoftware Stack図です。deepopsでは最小構成で “Management Node”、 “Login Node”、 “計算ノード(図中のDGX-1)”の3つのマシン(Virtual Machine可)を必要とします。deepopsではクラスタ管理システムとしてKubernetes、Slurmをサポートし、それらを実行するためのContainerソフトウェアと管理者向けのPrometheus、Grafana、DCGMなどといった管理ツール群などをサポートします。まだ調査中ですが他にも、KubeflowやAuth、外部NFS Storageとの接続など、機械学習の基盤として必要なソフトウェアは一通りサポートする方針のようです。

仮想環境での動作実験

それでは早速、手元の仮想環境動かして見たいと思います。今回はとりあえずインストールされるコンポーネントや使用感を見たいので手元のMacBook Proで試してみます。構築後にわかったことですが1世代前の16GBメモリ、2 core i7 CPUの環境で、割と動作がギリギリだったので、これよりTinyな環境の場合は別のクラウド環境などの利用を検討した方がよいと思います。

それでは、内容を見ていきます。deepopsでは仮想環境を構築するためのVagrantのレシピを公開しているのでこれを見ていきます。

が、vagrant_startup.shを読んでいていきなり壁に当たりました。どうやらrhel系かdebian系のlibvirt/KVMしかサポートしていないようで、Mac上のVirtualBoxに入れるには事前準備と少々コードの変更が必要でした。これからその手順について紹介します。

事前準備

rhel、debianだとvagrant_startup.shを流すだけで必要なパッケージをリポジトリからインストールしてくれるのですが、Mac上ではそれができないのでVirtualBox環境とVagrant環境を手動で構築していきます。

まず、VirtualBoxをVirtualBox公式からVagrantをVagrant公式から持ってきてインストールします。

インストールしたら次にVagrantのプラグインを以下のコマンドでインストールします。

vagrant plugin install vagrant-host-shell vagrant-scp vagrant-mutate

次に、公開鍵の準備をします。VagrantではセットアップしたマシンへSSH接続に使う鍵の配置を行うので、公開鍵の設定をしておきます。参考となる手順はこちらです。既存の公開鍵を利用する場合にはこちらの手順は不要です。

最後にVagrantfileをVirtualBox用に書き換えます。私の場合は以下のように変更しました。

主な変更点は

  • BOX_IMAGEをUbuntuに変更(自分が慣れているOSのため)
  • VagrantのProviderをlibvirtとVirtualBoxに場合分け
  • ちょっとNW構成やVMのSpecをいじった

です。VMのSpecについてはこの後のKubernetesのセットアップでメモリを多く使っておりクラスタのセットアップをしただけでSwapし始めたりAnsible Playbookがコケたりする事があったので変更しています。この辺の値は環境に依存すると思いますので、上記設定で動かなかったらホストマシンと相談しながら適宜リソースを増やすなどしてみてください。

クラスタ構築

事前準備が整ったので以下のコマンドで仮想マシンをセットアップします。

cd virtual
vagrant up --provider=virtualbox

これで virtual-login virtual-mgmt virtual-gpu01 の3台の仮想マシンが起動します。各マシンには vagrant ssh <host名> でログインできます。この時点ではまだクラスタは設定されていません。

マシンが起動したら、Kubernetesをセットアップします。通常はVirtual Mahcineのホストからセットアップスクリプトを実行可能なのですが、セットアップスクリプトで /etc/os-release を参照している箇所があり、今回利用しているMacOSでは変更なしに利用できませんでした。また全スクリプトを一個ずつ確認しながら流すのは大変なのでUbuntuをインストールした virtual-login ノードで残りのセットアップスクリプトを流すことにします。実行する手順は以下の通りです。

vagrant ssh virtual-login
git clone https://github.com/NVIDIA/deepops

そして、Kubernetesの設定周りをVMの環境に合わせて編集します。

余談ですが、この辺で使っているk8s_inventory.shなどはkubernetes-sigで管理されているkubespray を使っているようです。

ファイルの編集をしたら、クラスタ設定用のスクリプトを実行します。

deepops/virtual/cluster_up.sh

このコマンドで実行されるスクリプト、Ansibleが全て流れればKubernetesのセットアップが完了します。動作確認のため kubectl を実行してみましょう。

kubectlの実行結果

これでKubernetesのセットアップは完了しました。必要に応じてkubeflowやrookなど欲しいコンポーネントがあればこの辺からスクリプトを選んで流していけば良いでしょう。

なお、今回のVirtualBoxはホストオンリーアダプタで実行しているので一行目の k8s_environments.shで読み込んでいる admin.conf をホストのMac側に持ってきてMac用のkubectlバイナリを使えばMac側からもKubernetesをコントロール可能です。

Mac、VirtualBoxなどの少しつまづく部分はありましたが、Kubernetesそのものについて細かいAnsibleなどの変更はほとんどなく、2ノードのKubernetesをセットアップすることができました。

まとめ

コンテナ管理用のツールとしてDockerやKubernetes、環境のデプロイツールであるAnsibleなど、個々のパーツはそれぞれ一般的に広く使われているものの、実際に組み合わせて0から構築しようとすると自作のAnsible Playbookが必要になったり、その管理が面倒になりがちです。場合によっては新しいバージョンに追従するために同じような事をするPlaybookが複数できてしまって困っている運用者もいると思います。

deepopsはこうした課題を “GPUクラスタ向けのデプロイツール” をOSSで標準的に使えるようにする取り組みとして、とても注目できる存在と思います。とりわけ、今回の仮想環境の検証では大きなつまづきやバグを踏む事なく実行できた点、kubesprayなどの他のOSSをきちんとforkせずに利用している点、kubeflowなどエコシステムのデプロイツールについても積極的に取り組んでいる点など個人的にはとても好感を持てます。

今回、仮想環境での大まかな動作については確認できたので、次はベアメタル環境などに挑戦し、機会があればまたBlogなどで報告できればと思います。

おわりに

また,私たちNTTはオープンソースコミュニティで共に活動する仲間を募集しています.ぜひ弊社 ソフトウェアイノベーションセンタ紹介ページや,採用情報ページをご覧ください.

--

--

Kota Tsuyuzaki
nttlabs
Writer for

Research Engineer at Nippon Telegraph and Telephone Corporation (NTT). OpenStack Swift core team member, OpenStack Storlets Project Team Lead.