HPC
MIC
Xeon Phi
インストール

Ganglia を利用したインテル® Xeon Phi™ クラスターの監視

同カテゴリーの次の記事

インテル® Xeon Phi™ コプロセッサーを搭載したシステムで Mellanox* 社の InfiniBand アダプターを使用する

この記事は、インテル® デベロッパー・ゾーンに公開されている「Monitoring Intel® Xeon Phi™ Clusters Using Ganglia」の日本語参考訳です。

Ganglia をインストールする

MPSS User’s Guide (英語) で、基本的な Ganglia のインストール方法について触れています。その手順で見逃してはいけない重要な点を以下にまとめます:

1) ホストシステム上で Ganglia コードをビルドするには、いくつかのソフトウェア・パッケージが必要です。MPSS ユーザーガイドには、必要なパッケージのリストが含まれています。これらのパッケージの 1 つである、libConfuse (SUSE システムでは libconfuse0）は、主要な Linux* ディストリビューションには含まれていません。このコードは以下で入手できます。

RHEL ディストリビューション向け: http://www.nongnu.org/confuse/
SUSE ディストリビューション向け:
http://download.opensuse.org/distribution/{version_number}/repo/oss/suse/x86_64/

2) コプロセッサー上で使用する Ganglia ファイルは、ホスト MPSS tar ファイルと同じ場所にあるmpss-[バージョン番号]-k1om.tar ファイルにあります。MPSS ユーザーガイドで示される方法に従って、tar ファイルから抽出された rpm は、”Installing Card Side RPMs” の見出しで示される 3 つの方法の 1 つを使用して、コプロセッサーが起動されるたびに毎回インストールされます。さらに、coreutils*.k1om.rpm と libgmp*.k1om.rpm ファイルに加え、ganglia-[version].k1om.rpm、mpss-ganglia-mpss-[version].k1om.rpm、libconfuse0[version].k1om.rpm そして libapr-[version].k1om.rpm ファイルが必要です。

残りの部分 ----

インストールの代替え方法

Ganglia を使用する場合、コプロセッサー上の root ファイルシステムとして、NFS マウントされたファイルシステムを使用することに利点があります。大規模クラスターを管理されているなら、すでに実践されていることでしょう。Ganglia を使用するシステムで、NFS マウントされたファイルシステムには、3 つの利点があります。

1) コプロセッサー上のメモリースペースを節約: Ganglia は、root ファイルシステムに mpss-[バージョン番号]-k1om.tar ファイルから多くのファイルをインストールする必要があります。これにより root ファイルシステムの使用量が増加するため、root ファイルシステムが RAM ファイルシステムである場合、プログラムを実行するためのメモリーが少なくなります。

2) コプロセッサーをブートするたびに Ganglia を再インストールする必要がなくなります。新しいバージョンの MPSS をインストールする時に、一度だけ Ganglia をインストールするだけで済みます。

3) gmond.conf ファイルをコプロセッサーのファイルシステム上の /etc に置いたままで、/etc にある他の設定ファイルをトラックするバージョン管理システムを維持できます。 gmond.conf ファイルに何か変更を加え、ブートするたびに Ganglia を再インストールする場合、変更したバージョンでデフォルトの gmond.conf を上書きコピーすることを毎回確認する必要があります。

NFS を使用しない場合、代替え方法として Ganglia のインストール後に root ファイルシステムのイメージが格納されるスタティック cpio ファイルを使用します。これは、NFS ファイルシステムの利点である前述の (2) と (3) と同様の効果を持っています。 このスタティック・イメージをビルドして使用するため、ホストシステム上で次のコマンドを実行します:

ssh root@mic0 "cd / ; find . /dev -xdev ! -path "./etc/modprobe.d*" ! -path "./var/volatile/run*" | cpio -o -H newc | gzip -9" > /usr/share/mpss/boot/custom.cpio.gz
micctrl --rootdev=StaticRamFS --target=/usr/share/mpss/boot/custom.cpio

最初のコマンドは、コプロセッサーの RAM ファイルシステムの完全な圧縮 cpio ファイルを構築します。これには、コプロセッサーに接続するため ssh コマンドを使用し、/ と /dev ディレクトリーで find コマンドを実行します。その際、RAM ファイルシステム自体ではないファイル (例えば、NFS にマウントされているディレクトリー) と、/etc/modprobe.d と /var/volatile から実行状態ファイルを除外します。コプロセッサー上で、cpio アーカイブをビルドするため cipo コマンドへ find コマンドからのファイルリストをパイプし、出力を圧縮するため gzip コマンドを使用します。最後に、作成した /usr/share/mpss/boot/custom.cpio.gz ファイルをホストへ返します。2 番目のコマンドでは、デフォルトの RamFS シーケンスではなく、StaticRamFS を使用するため MPSS の設定を変更します。

コプロセッサーをブートするたびに、/var/mpss/micN.image に代わってこの cpio ファイルが使用されます。一般的に、新しい MPSS をインストールした時、/etc にあるファイル (これには、パスワード・ファイルも含まれることに注意) を変更するか追加や削除した場合、もしくは追加ソフトウェアを再構成した時にのみ、このカスタム cpio ファイルを置き換える必要があります。

どのように Ganglia を構成するか

インテル® Xeon Phi™ コプロセッサー・システム・ソフトウェア開発者ガイド (英語) では、Ganglia の概要について説明しています。このガイドは、リファレンス実装として MPSS インストール手順のデフォルト設定について説明しています。MPSS のリリースで提供されるデフォルト設定は、実際に使用するにはいくらかの変更が必要です。

シングルノード向け

インテル® Xeon Phi™ カードが装着されている単独ノード向けの最適な設定は、各コプロセッサーの gmond デーモンが直接ホスト上の gmond デーモンへ出力を送ることです。ホストからの情報も含めるなら、ホスト側の gmond デーモンの送信側から受信側へホストデータを送信する必要があります。ホスト上で実行される gmetad デーモンは、ホストの gmond からデータを受け取り、データベースに情報を抽出します。そのデータを利用するには、ホスト上に web サーバーをインストールするか、データベースと web サーバーを持つシステムの html ディレクトリーをマウントする必要がります。ノードごとに 2 つのコプロセッサーを仮定すると、単一ノードの構成は以下の様になります。

この設定を実装するには:

  • コプロセッサー上の /etc/ganglia/gmond.conf を修正します。
    – cluster セクションで、”name” が利用中のシステムに割り当てた名前に設定されていることを確認。 
    cluster {
  name = "mic_cluster" /*Cluster name, must match with every other node in the cluster
  owner = "unspecified"
  latlong = "unspecified"
  url = "unspecified"
}
    – udp_send_channel セクションで、, “host” にコプロセッサーがアクセスするホストの IP アドレスを設定し、”port” を 8649 にします。 
    udp_send_channel {
  host = 172.31.1.254
  port = 8649
  ttl = 1
}
  • ホスト上の /etc/ganglia/gmond.conf を修正します。
    – udp_recv_channel セクションの、”mcast_join” と “bind lines” をコメントアウトし、”port” を 8649 に設定します。 
    udp_recv_channel {
  /* mcast_join = 239.2.11.71 */
  port = 8649
  /* bind = 239.2.11.71 */
}
    – cluster セクションの、”name” をコプロセッサーと同じ名前に設定します。 
    cluster {
  name = "mic_cluster"
  owner = "unspecified"
  latlong = "unspecified"
  url = "unspecified"
}
    – コプロセッサーと同様にホストの情報を収集するのであれば、udp_send_channel セクションの “mcast_join = 239.2.11.71” を “host = localhost” に変更し、”port” を 8649 に設定します。 
    udp_send_channel {
  host = localhost
  port = 8649
  ttl = 1
}
    – ホストからの情報を収集しないのであれば、”udp_send_channel” セクションをコメントアウトします。
  • ホスト上の the /etc/ganglia/gmetad.conf を修正します。
    – ファイルのコメントアウトされていない最初の行が以下であることを確認します。 
    data_source "name" localhost
    “name” は、gmond.conf ファイルのクラスター名として設定されている名前と同じにします。

クラスター向け

クラスターを監視するには、いくつかの設定方法があります。もっとも簡単な設定は、gmond を各コプロセッサーに持ち、各ホストノードが gmetad のために集約される指定のノード上の gmond へデータを送信する方法かもしれません。これを行うには、各コプロセッサーの gmond.conf の udp_send_channel セクションのアドレスを、この指定ノードを指すように変更する必要がります。この設定は、下記の図のようになります。(警告 – 一部のユーザーは、コプロセッサーのアドレスがそのホスト IP アドレスを指すエイリアシングの問題で、この設定に問題が生じるかもしれません。) この設定は、下記の図のようになります。

他の設定はネットワーク・トラフィックを減少させます。それは、最初の例のようなクラスターの各ノードでデータを収集する方法です。次に、クラスターの 1 つの指定ノード、もしくはクラスター外のサーバー上に、MPSS の Ganglia ディレクトリーから html ファイルを共に、gmetad をインストールします。この指定ノードを監視する場合を除き、そこに gmond をインストールする必要はありません。そのデータを利用するには、指定ノード上に web サーバーをインストールするか、データベースと web サーバーを持つシステムの html ディレクトリーをマウントする必要がります。この設定は、下記の図のようになります。

この設定を実装するには:

  • 単独ノードの設定と同じようにコプロセッサーとホストの gmond.conf を設定します。
  • 各ホスト上で gmetad を起動しないでください。
  • 指定ノードの gmetad.conf 中で
    – ファイルのコメントアウトされていない最初の行が以下であることを確認します。 
    data_source "name" xxx.xxx.xxx.xxx
    “name” には、gmond.conf ファイルのクラスター名と同じ一意の名前を設定し、各ホストノードにある xxx.xxx.xxx.xxx が ノードの IP アドレスであることを確認します。

結論

この時点で、Ganglia のインストール作業を行います。どのシステムメトリックを監視するかは、システムの健全性 (温度、電力) や使用量 (メモリーや負荷バランス) などシステムを監視する理由に依存します。システムを監視することは、デーモンを実行するオーバーヘッドにより、プロセス実行のパフォーマンスに影響を与える可能性があることに注意してください。メトリックを選択するときは賢明に。試行して、役立つか確認します。素晴らしい監視を！！

関連記事

https://software.intel.com/en-us/articles/configuring-intel-xeon-phi-coprocessors-inside-a-cluster (英語)
https://www.izzz.us/article/mic-article/software-stack-mpss

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

関連記事