meta-something

論文とか研究とか趣味のネタとか

論文紹介「Is Singularity-based Container Technology Ready for Running MPI Applications on HPC Clouds?」

タイトル

"Is Singularity-based Container Technology Ready for Running MPI Applications on HPC Clouds?"

著者

  • Jie Zhang, Xiaoyi Lu, Dhabaleswar K. Panda
    • from Network-Based Computing Laboratory, The Ohio State University

Network-Based Computing Laboratory は MVAPICH, OSU Benchmark などを開発(発表)しているHPC業界では有名なラボです。

掲載雑誌、国際会議の情報等

Proceedings of the10th International Conference on Utility and Cloud Computing (UCC '17) (ACM)

本論文はUCC'17で "Best Student Paper Award" を受賞しています。

概要

HPC向けコンテナ技術Singularityの性能への影響をHPC向けのハードウェア環境上でMPIアプリケーションを実行して実験した結果、nativeからの性能低下は最大でも8%程度だった。

もうちょっと詳しく

一般にコンテナ型仮想化技術として有名なDockerとイメージの互換性があり、HPC領域向けのコンテナ技術として有望視されているSingularityを用いたHPC向けアプリケーションのベンチマーク論文。実験ではMPIによる1対1通信,集団通信,HPCアプリケーション(Graph500NASベンチマークなど)を実行しており、また一般的なIntel Haswell CPU*2+InfiniBandのクラスターと、Intel KNL+Intel Omni Path搭載のクラスター環境で動かしている。多くの場合にSingularityを利用したケースはnativeとほぼ同等の性能を示していたが、一部では0~8%程度の性能低減が見られた。

個人的な感想

論文では様々なハードウェアアーキテクチャ(KNLの特殊なメモリ構成、大量のメニーコア)、高速なインターコネクト、仮想化技術の有無で実験を評価したと述べているが、Singularityが内部的に利用する仮想化技術がどのように他の要素に影響を及ぼすのか、に対する考察がない。また、0-8%程度の性能低減が過去文献と比較してリーズナブルであるか否かについても議論がない。そこを最も知りたかった、、

singularity.lbl.gov

Singularity公式ページのUser Guideによれば、Singularityのプロセスの流れは以下の通り。

1. Singularity application is invoked
2. Global options are parsed and activated
3. The Singularity command (subcommand) process is activated
4. Subcommand options are parsed
5. The appropriate sanity checks are made
6. Environment variables are set
7. The Singularity Execution binary is called (sexec)
8. Sexec determines if it is running privileged and calls the SUID code if necessary
9. Namespaces are created depending on configuration and process requirements
10. The Singularity image is checked, parsed, and mounted in the CLONE_NEWNS namespace
11. Bind mount points are setup so that files on the host are visible in the container
12. The namespace CLONE_FS is used to virtualize a new root file system
13. Singularity calls execvp() and Singularity process itself is replaced by the process inside the container
14. When the process inside the container exits, all namespaces collapse with that process, leaving a clean system

大雑把な流れは以下の通り(おそらく)

No. 処理
1~6 プロセス起動、サブコマンド・環境変数・オプションのパースなどの事前準備
7~10 バイナリが実行され、プロセスの名前空間を隔離する(オプションで無効化可能)
11~12 コンテナイメージのファイルシステムをホストにマウントし、プロセスから見えるルートファイルシステムを隔離する
13 コンテナの中で execvp() してコマンド実行
14 プロセスが終了すると関連プロセスおよびマウントポイント等を削除する

上の処理を見ると、性能に影響するかもしれないと考えられるのは以下の2点

後者についてはおそらく chroot() を呼んでいるだけではないか(予想)と思うが、これはファイルI/Oに特に影響を及ぼさないはず。

前者の影響がどの程度あるのかが問題になるが、プロセスの名前空間の隔離ならば以前のIBMのDocker性能評価の論文[Felter, 2015]を引用すれば、単純な計算において性能への影響は0-3%程度におさまると予想できる。IBMの論文では通信レイテンシ等のオーバーヘッドが大きいことを報告していたが、Singularityではホストに依存する通信関連の設定や依存ライブラリ・バイナリは、ホストのものをコンテナ内部にそのままマウントする形なので、事実上、仮想化による性能の影響はない(というよりも、仮想化を行っていない)はず。

論文に何も議論がなかったのでこれ以上は議論のしようがないが、今回の性能の低減は何が原因で発生しているのかを知りたい。ので、近く実験をしてみよう。

紹介スライド

www.slideshare.net