この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
CfnCluster の標準設定では、モニタリングシステムとして Ganglia がインストールされます。老舗ともいえる Ganglia ですが、その特徴と、使い方を簡単にご紹介します。
CfnCluster での Ganglia
最初に画面をみてただいたほうが早いので、まずは CfnCluster を使ってクラスタを起動してください。
今回この記事を書くにあたって作成した環境の構築手順は、最後のほうに記載しましたので参考にしてください。
そうして cfncluster コマンドからクラスタを起動すると、起動時に下記のようなメッセージが出力されるかと思います。
$ cfncluster create hpc-lab01
Beginning cluster creation for cluster: hpc-lab01
Creating stack named: cfncluster-hpc-lab01
Status: cfncluster-hpc-lab01 - CREATE_COMPLETE
MasterPublicIP: 18.182.xxx.xxx
MasterPrivateIP: 10.1.0.197
GangliaPublicURL: http://18.182.xxx.xxx/ganglia/
GangliaPrivateURL: http://10.1.0.197/ganglia/このメッセージは cfncluster status コマンドでも再表示させることができますが、このうちの GangliaPublicURL が Ganglia へアクセスするための URL になります。
上記 URL へアクセスすると、下記のような、一種の懐かしさを覚えるような画面が表示されると思います。これが Ganglia の Web UI になります。
使い方はみてみると分かると思いますが、まずは適当にグラフ（画像）をクリックしたり、左上の「Grid > 」とあるところからプルダウンメニューをたどってもらえると良いかと思います。この画面で何か設定がおかしくなることはまずないので、あちこち見て回ってみてください。
注意
初期状態で作成される SG は 80/tcp と 22/tcp が 0.0.0.0/0 でオープンされています
CfnCluster でクラスタを起動する際、マスターノードにアタッチするために cfncluster-クラスタ名-MasterSecurityGroup-XXXXXXXXXXXXX という名前のセキュリティグループが作成されます。こちらは 80/tcp と 22/tcp が 0.0.0.0/0 でオープンされているので、まず必要な範囲に修正することを検討ください。手元で確認した範囲でいえば、下記の設定で十分かと思われますが、必要に応じて適宜設定してください。
- 80/tcp (HTTP) ... 作業者の手元の端末（ブラウザ）のグローバルIPアドレス
- 22/tcp (SSH) .... 同上、あるいは作業ノード（cfncluster）にアタッチされているセキュリティグループのどれかひとつ
Ganglia の概説
ここで簡単に Ganglia そのもののご紹介をします。
Ganglia は、クラスタやグリッドといったHPC環境のための、スケーラブルな分散モニタリングシステムです。
( Ganglia is a scalable distributed monitoring system for high-performance computing systems such as clusters and Grids. )
公式サイトのトップにそう書いてあるように、最初から分散コンピューティング環境をターゲットに開発されたモニタリングシステムです。[^monitoring]
履歴をたどると 2002 年 まで遡れますが、この頃は AWS (2006) はおろか Ruby on Rails (2004) すら世に出ておらず、当然 Intel のハードウェア仮想化支援（VT-x）もなく（2005）そもそも 64bit ですらなく（AMD64の最初のリリースが 2003年）、VMware は ESXi の前身の ESX がリリースされたばかり（2001）で Xen もまだ GA （2003）前、Linux の利用が盛んになりだしてはいますが、未だ CentOS（2004）も Ubuntu（2004）もない頃です。Windows XP と Mac OS X の最初のバージョンの発売が 2001 年と言うことで、ぎりぎりこのあたりでしょうか。1 性能が問われるサーバといえば Sun Microsystems や HP などの UNIX 機が一般的だった時代です。
このような歴史をもつソフトウェアですが、これは当時から数百台〜数千台のオーダーのクラスタ化されたコンピュータ群の CPU やメモリリソースを一元管理する目的で設計されています。ざっくりとした構成は下記のようになります。
| Parts名 | 概説 |
|---|---|
gmond |
各ノード上で動作し、CPU利用率やメモリ使用量などのメトリクスを収集する |
gmetad |
各 gmond が収集したメトリクスデータを回収し保存する |
| ganglia-web | gmetad が保存したデータを表示するための Web UI |
gmond が収集するメトリクスはカスタマイズ可能ですが、CfnCluster から起動された初期状態だと下記の項目が収集されます。
- CPU利用率
- User / System / Idle / Nice / Wait I/O / aidle2
- ロードアベレージ（LA）
- 1分平均 / 5分平均 / 15分平均
- 総起動プロセス数 / 総実行中プロセス数
- メモリ使用量
- 空きメモリ / 共有メモリ / バッファ / キャッシュ
- 空きスワップ容量
- ネットワーク
- 送信 Byte 数 / パケット数
- 受信 Byte 数 / パケット数
- ディスク
- 総容量 / 空き容量 / 最大ディスク使用量
構成としては一般的な、各監視対象ノードにインストールされた Agent プロセスとそのデータを収集・保存するするコレクタープロセスという体をとりますが、特徴なのはその構成要素が非常に軽量・シンプルに出来ていることでしょうか。また最初から「多数のノードをまとめてモニタリングする」という目的から、UIや設定ファイルもその目的にそった設計となっています。データの保存には RRD (Round-Robin Database) という軽量な時系列データベースが採用されていますが、これもまた目的にかなうものです。
CfnCluster での Ganglia (再び)
CfnCluster における Ganglia は下記のような特徴をそなえます。
- 20秒間隔のメトリクス収集・グラフ化
- 最初から用意されたダッシュボード
- 増減したノードの自動反映
これらの要素はもちろん CloudWatch でも同等〜それ以上に設定・作り込むことが可能ですが、最初から統一化された UI と共に立ち上がってくることに価値があるかと思います。
20秒間隔のメトリクス収集・グラフ化
こちらは CPU 利用率のグラフです。試しにちょっとしたテストジョブを流して何度か負荷をかけたときの様子です。
・・・といってもよく分からないと思いますが、実際に Ganglia の Web UI をご覧になって頂くと、20秒ごとにアップデートされていくのが分かるかと思います。
最初から用意されたダッシュボード
CfnCluster が起動したノードの状況がひとめで分かるよう、積み上げグラフやダッシュボードが最初から用意されています。CfnCluster はカスタマイズ可能ですので足りなければ追加することも可能ですが、そもそもクラスタを起動するだけで最低限のモニタリングが出来るよう設計されています。
増減したノードの自動反映
こちらもクラスタ向けならば当然の機能です。今回時間をおきながら、各ノードのCPUやメモリにまんべんなく負荷をかけるようなテストジョブ3を流してみました。その時のスクリーンショットがこちらです。上段の2つのグラフで、CPU 数や総メモリ量が増減していることが分かるかと思います。これは AutoScaling の設定によって自動的にノードが増減したものですが、これにあわせて、操作者が何かしら設定ファイルを修正したり、Web から何か操作した、などということはしておりません。
また最下段をみると、「down」と書かれているノードが並んでいるかと思います。これらは AutoScaling によって停止されたノードで、いま起動していなくても稼働時のグラフをあとから参照することが可能です。
まとめ
HPC クラスタを運用する上で、モニタリングは要です。ボトルネックがあるのはノードの数か、ノードひとつひとつの性能か、その両方か、あるいはネットワークか・・・などなど。クラウド型の HPC クラスタであれば、足りないと思ったらその場で増強が可能ですし、不要であれば即座に停止できます。
最近は HPC 管理ソフトウェアに組み込みのモニタリング機能を使うことが多いかもしれませんが、手軽に使い出すことが出来る Ganglia を覚えておくと便利なこともあるかもしれません。
付録
今回この記事を書くにあたって、環境を構築したときのメモを備忘録がわりに貼っておきます。もし「 CfnCluster ってどういうもの？」という方がいたら参考にしてください。
- VPC（とサブネットとセキュリティグループ）は新規に作成
- 作業用ノードはそのVPC上にEC2を起動（Amazon Linux2）
- 作業用ノードには
AdministratorAccess権限の IAM ロールを付与 - EIP付与
- 作業用ノードには
- 作業用ノード上に
pyenvとcfnclusterをインストール - 作業用ノードから CfnCluster を起動し、クラスタ・マスターノード・コンピュートノードを起動
- インスタンスタイプ等はデフォルトのまま4
- クラスタの起動には 10分〜15分ほどかかった
$ export AWS_DEFAULT_REGION=ap-northeast-1
$ cfncluster configure
$ cfncluster create hpc-lab01- マスターノード用のSGを修正
- 上述
- 負荷をあげるためのテストジョブをマスターノード上に準備
- 当時最新の Ruby 2.5.1 を
configuremakeするだけのジョブです。5 - 負荷を上げるのが目的なので
make installはしません。
- 当時最新の Ruby 2.5.1 を
$ ssh <マスターノードのIPアドレス>$ cd /shared/
$ curl -O https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.1.tar.gz
$ vim build_ruby.sh
$ chmod +x build_ruby.shbuild_ruby.shの内容は下記にしました。- NFS上で上書きし合わないよう、コンピュートノードのホストの名前でサブディレクトリを作成しています
#!/bin/bash
SRC=/shared/ruby-2.5.1.tar.gz
DIR=ruby-2.5.1
cd $HOME && \
rm -rf $DIR
tar xzf - < $SRC && \
cd $DIR/ && \
./configure && make -m- ジョブの投入（
qsub）
# 1回投入
$ qsub ./build_ruby.sh
Your job 1 ("build_ruby.sh") has been submitted
$
# 4回投入
$ for i in `seq 1 4`; do qsub ./build_ruby.sh ; done
Your job 2 ("build_ruby.sh") has been submitted
Your job 3 ("build_ruby.sh") has been submitted
Your job 4 ("build_ruby.sh") has been submitted
Your job 5 ("build_ruby.sh") has been submitted
$- 投入された〜実行中のジョブの状況は
qstatコマンドで確認できます
$ qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
11 0.55500 build_ruby ec2-user r 07/23/2018 10:07:41 all.q@ip-10-1-0-169.ap-northea 1
12 0.55500 build_ruby ec2-user r 07/23/2018 10:07:41 all.q@ip-10-1-0-127.ap-northea 1
13 0.55500 build_ruby ec2-user qw 07/23/2018 10:07:38 1注釈
- 以上 Wikipedia 調べ。ちなみに任天堂 DS は 2004 年、PlayStation2 は 2000 年だそうです。x86 アーキテクチャのサーバ機もありましたが、筆者の観測範囲内では、OS は Linux と並んで FreeBSD や所謂 Intel Solaris が採用されていた印象です。もちろん Windows が必要な場合は Windows 2000 Server でした ↩
- ソースコードに含まれる README によると Percent of time since boot idle CPU とのことで、OSが起動してから現在までのあいだの CPU Idle 時間の割合のようです ↩
-
tar xzf ruby-2.5.1.tar.gz && configure && make↩ - この程度であればマスターノードは t2.nano でも問題ないと思いますが、NFS サーバになるので、実運用上はある程度の性能が必要と思います ↩
- 適当なCPU負荷とDisk I/Oが数分以上続くタスクをと考えて思いついただけなので、特に深い意味があるわけではありません ↩