単一システムイメージを 提供するための仮想マシンモニタ 金田憲二*# 大山恵弘* 米澤明憲* * 東京大学 # 日本学術振興会

クラスタが隆盛を極める PCの性能向上・価格低下 数台のPCで，10年前のスパコンに近い性能 個人・グループで小・中規模クラスタを所有 TOP500中の70%以上をクラスタが占める 個人・グループで小・中規模クラスタを所有 まず研究の背景について述べます。 近年では、PCの性能向上や価格低下が目覚しく、それに伴い、複数のPCをネットワークで結合してクラスタを構築するというのが、非常に盛んになっています。 例えば、PCの性能向上に伴って、PCを4台くらい集めてクラスタを構成すれば、10年前のスーパーコンピュータとほぼ同等の10GFlopsくらいの性能を達成することができます。 実際、コンピュータの性能を競い合うTOP500というコンテストでは、そのうち70%以上をクラスタが占めるようになっています。 また、PCの価格低下にともない、そうしたクラスタを、小・中規模のものであれば個人・グループで所有するというのも、現実的になってきています。

クラスタの利便性は著しく低い 計算資源の管理が困難 並列アプリの開発が困難 … 例）クラスタ上の全プロセスの状態を取得するには？ 例）MPIやPVMなどのメッセージパッシング型が大半 … しかし、こうしてクラスタは広く世間に普及し始めてきているにも関わらず、その利用に際しては、依然として様々な問題があります。 この研究では特に、クラスタの利便性が低いという問題に焦点を置きます。 例えば、クラスタの各ノードにLinuxなどのOSをインストールしただけでは、CPU、メモリ、ディスクといった計算資源を管理・有効利用するのが難しいという問題があります。 よくある話としては、クラスタ上で今現在走っている全プロセスの状態を取得し、最も負荷のかかっていないノードを知りたい場合を考えます。 1台のSMPマシンであれば、psなどの使い慣れたコマンドを実行するだけで十分事が足りるのですが、 クラスタの場合は、分散OSや、何か特殊なミドルウェアシステムが必要であったりします。 そのため、ユーザは、普段使い慣れていない、それぞれのシステムが提供する独自の機能を使いこなさなければならず、利便性が損なわれます。 また、別の例としては、並列アプリの開発が困難であることも、クラスタの利便性を下げる要因として挙げられます。 クラスタ上での最も一般的な並列プログラミング環境は、やはりMPIやPVMなどのメッセージパッシングモデルに基づくものです。そのため、一般的に言って、共有メモリを仮定したSMPマシン上でのプログラミングと比較して、難しく手間のかかるものとなっています。

本研究の目標 クラスタの簡便な利用を可能にする  クラスタ上に単一システムイメージを構築する Easy to manage Easy to develop  クラスタ上に単一システムイメージを構築する 例）共有メモリ空間，大域プロセス空間 そこで、本研究の目標ですが、以上に述べた問題を解決し、クラスタ上の計算資源の管理や、並列アプリの記述・実行を、ユーザが簡便にできるようにすることです。 より具体的には、クラスタ上に単一システムイメージを構築し、共有メモリ空間や大域プロセス空間などを提供することを目指します。

本研究のアプローチ 仮想マシンモニタ（VMM）を利用する 実機と同等の処理が可能な仮想マシンを 構築するミドルウェアシステム 例）VMware [1]，Xen [2]，LilyVM [3] こうした単一システムイメージを提供することを目指す既存研究は、もちろん、数多くあるのですが、 それらの研究と異なり、我々は、仮想マシンモニタ (VMM)を利用するというアプローチをとります。 仮想マシンモニタというのは、VMWare workstationのようなものをイメージして頂けると分かり易いのですが、実マシンと同等の処理が可能な仮想マシンを、ソフトウェアでエミュレーションするシステムです。 例えば、仮想マシンモニタを使うことによって、Linuxの走っている実マシン上に仮想マシンを構築し、その仮想マシン上でWindowsを走らせることなどが可能になります。 本研究では、この仮想マシンモニタ(VMM)を利用することによって、単一システムイメージを構築します。 [1] http://www.vmware.com/ [2] P. Barham et al.SOSP’03 [3] H. Eiraku et al. BSDCon’03

設計・実装するVMM クラスタ上に仮想的にSMPマシンを構築する 仮想SMPマシン 仮想化 クラスタ より具体的には、我々は、クラスタ上に仮想的にSMPマシンを構築するVMMを設計・実装します。 例えば、我々のシステムは、 8台のシングルプロセッサマシンからなるクラスタが与えられた時に、8-wayのSMPマシンを仮想的に構築することができます。 ユーザは、この仮想SMPマシン上でLinuxなどのOSを走らせて、さらにそのゲストOS上から並列アプリケーションを記述・実行します。 クラスタ

本アプローチの利点 既存のOSが仮想マシン上で動作する  分散資源を簡便に管理できる 共有メモリ用の並列アプリが動作する 例）psコマンドやkillコマンドによるプロセス管理 共有メモリ用の並列アプリが動作する  並列アプリを簡便に記述・実行できる 科学技術計算からwebサーバまで 例）makeコマンドやシェルスクリプトの利用 既存研究と比較して、本アプローチの利点としては、以下の2つが挙げられます。 1つ目の利点は、カーネルに多少の変更を加えるだけで、既存のOSが仮想マシン上で動作することです。 これによって、既存のOSと同じインターフェースのままで、分散資源を簡便に管理できます。 例えばSMP用のLinuxをゲストOSとして仮想マシン上で走らせて、psコマンドやkillコマンドによってプロセスを管理するといったことも可能になります。 2つ目の利点は、共有メモリ用の並列アプリがゲストOS上で動作することです。 科学技術計算からwebサーバまで様々な並列アプリを簡便に記述・実行できます。 場合によっては、makeコマンドやシェルスクリプトなどユーザが慣れ親しんだツールを使って、並列ワークフローを記述・実行するといったことも可能になります。

並列タスクの実行デモ … ゲストOS (Linux) 仮想 マシン VMM ホストOS ホストOS ホストOS 実マシン 研究の詳細について説明する前に、実際に我々のシステムを使って並列タスクを実行する様子を、デモムービーでお見せします。 このデモの環境では、8台のPCからなるクラスタがあり、VMMは、そのクラスタ上に、8-waySMPマシンを仮想的に構築します。その仮想SMPマシン上では、ゲストOSとしてLinuxが走っています。 実マシン …

並列タスクの実行デモ では、実際に簡単なデモムービーをお見せします。 画面中央のウィンドウが、仮想マシン上で走っているLinuxの端末です。 画面左上のグラフが、各マシンのCPU負荷を表しています。棒が高くなるほど負荷が高いことを意味しています。 このLinux上でいくつかプロセスをforkします。 すると、forkされたプロセスがゲストOSのスケジューラによって、各仮想プロセッサに割り当てられてます。 そして、最終的には、その仮想プロセッサをエミュレーションする、物理マシン上でプロセスは実行されます。 左上の棒グラフからも負荷の分散されている様子が分かります。 そして、もちろん、通常のLinuxの同様、シグナルの送信などによって、プロセスを制御することができます。 例えば、killコマンドを使ってプロセスを終了させることなどができます。

残りの発表の流れ VMMの設計 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題 残りの発表の流れですが、このスライドに示されているようになっています。 まず、我々のVMMの設計についてより詳細に述べます。 次に、そのVMMをどう実装するかについて概説します。 その後、我々のシステムの特徴でもある、共有メモリの一貫性制御の仮想化をどう実現するかについて、 特に焦点をおいて説明をします。 そして、予備実験、関連研究、まとめと今後の課題という順で述べます。 (6:00)

残りの発表の流れ VMMの設計 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題

仮想マシンの特徴 ISAレベルでの仮想化 Para-virtualization IA-32アーキテクチャを対象 C.f.) Xen、LilyVM ユーザアプリ ゲストOS 仮想マシン 仮想マシンISA ≒ 実マシンISA 仮想マシンモニタ OSが仮想マシン上で動く ユーザアプリ ホストOS まず、仮想マシンモニタによって構築される仮想マシンが、どういった特徴をもつかについて、説明します。 まず仮想マシンの第1の特徴として、 ISAレベルでの仮想化であることが挙げられます。 ユーザアプリとOSとの間のシステムコールレベルで仮想化すると設計も可能ですが、 今回は、OSとハードウェアとの間のISAレベルで仮想化を行い、仮想マシン上ではOSが動作するようにします。 また、特に本研究では、最も広く普及していると言えるIA-32アーキテクチャを対象とします。 仮想マシンの第2の特徴として、 XenやLilyVM等と同様、Para-virtualizationであることが挙げられます。 仮想マシンのISAは、実マシンのISAとほぼ同一ですが、一部だけ異なる点があります。 今回、仮想マシンのISAと実マシンのISAとを同一のものとはしないで、Para-virtualizationを選択した理由としては、 Para-virtualizationによって、少ない実装コストで十分な性能を持つ仮想マシンを実現することができるからです。 ただし、今回の発表では時間の関係上詳しくは割愛しますが、Para-virtualizationには、既存のOSを仮想マシン上で走らせるためには、そのOSのカーネルの一部を改変する必要があるという欠点があります。 実マシン

仮想マシンと実マシンの対応 仮想マシン 実マシン 次に、この仮想マシンのプロセッサ、メモリ、I/Oデバイスといったハードウェア資源が、実マシンのハードウェア資源とどう対応づけられるかについて説明します。 実マシン

仮想マシンと実マシンの対応 仮想プロセッサと実プロセッサは1対1に対応 仮想マシン 実マシン まずプロセッサの対応付けですが、仮想プロセッサと実プロセッサは1対1に対応します。 例えば、2個のプロセッサをもつ仮想SMPマシンを構築するためには、複数の実マシンから総計2個のプロセッサを確保する必要があります。 実マシン

仮想マシンと実マシンの対応 実マシンのメモリの一部を 仮想マシン用として確保 n MB 仮想マシン 実マシン n MB n MB 次に、メモリの対応付けについて説明します。 実マシンのメモリの1部を、仮想マシンのそれとして利用します。 より具体的には、n MBの共有メモリを仮想化するためには、各仮想プロセッサごとにn MBのメモリを実マシンから確保する必要があります。 実マシン n MB n MB

仮想マシンと実マシンの対応 どれかの実マシンにあるI/Oデバイスを 仮想マシン用に確保 仮想マシン ディスクイメージ 実マシン どれか1つの実マシンにあるデバイスを、仮想マシンのそれとして使用します。 例えばハードディスクの場合、実マシンのどれかに置かれたファイルを、ディスクイメージとして利用します。 シリアル端末の場合も同様に、どれかの実マシンの仮想端末を、仮想マシンのシリアル端末として利用します。 (2:30) 実マシン

残りの発表の流れ VMMの設計 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題

VMプロセスの実行を監視し、必要に応じてハードウェアの仮想化処理を行う 基本的な実装方針 1つの仮想プロセッサごとに，　　　　　　　　　　　　　　　　　　以下の2つのユーザプロセスを用意 ゲストOSをnativeに実行する VMプロセス VMプロセスの実行を監視し、必要に応じてハードウェアの仮想化処理を行う 我々は、ホストOSを改変することなく、ユーザレベルのみでVMMを実装するという方針をとりました。 具体的には、1つの仮想プロセッサごとに、VMプロセスとモニタプロセスという2つのユーザプロセスを用意します。 VMプロセスは、仮想マシンのプロセッサのうちのどれか1つを担当し、ゲストOSをnativeに実行します。 モニタプロセスは、そのVMプロセスの実行を監視し、必要に応じてハードウェアの仮想化処理を行います。 モニタプロセス

実マシンのメモリ上のどこかに 仮想マシンのGDTRの値を格納 VMMの動作例 … lgdtl 0xa01002c2 特権命令の実行（GDTRへの 書き込み） シグナル発生 VMプロセス シグナルを捕捉 VMプロセスの実行を再開 それでは、より具体的に、この2つのプロセスがどう動作するかについて、例を通して説明します。 例えば、VMプロセスが、GDTRという特殊なレジスタへ書き込みを行う命令を実行しようとしていたとします。この命令は、特権命令と呼ばれるもので、ユーザプロセスからは実行することができず、実行しようとするとシグナルが発生します。 モニタプロセスは、この特権命令実行時に発生したシグナルを、ptraceシステムコールを用いて捕捉します。 そして、仮想マシンのプログラムカウンターやメモリを参照して、VMプロセスが実行しようとしていた命令を特定し、その命令をエミュレーションします。 この場合、VMプロセスは、GDTRレジスタへの書き込み命令を実行しようとしていたので、それをエミュレーションします。具体的には、メモリ上に格納している仮想マシンのGDTRレジスタの値を更新します。 もし、これ以降GDTRレジスタへの読み込み命令が実行される際には、このメモリ上に格納しているGDTRレジスタの値を読み込むようにします。 そして、このエミュレーション処理が終了したら、仮想マシンのプログラムカウンターを命令サイズだけ増やしてから、VMプロセスの実行を再開させます。 モニタプロセス 実マシンのメモリ上のどこかに 仮想マシンのGDTRの値を格納

仮想化を必要とするハードウェア資源 プロセッサ 共有メモリ I/Oデバイス 特権命令、割り込み、… アドレス空間、一貫性制御 ハードディスク、シリアル端末、タイマー、… 以上に述べた実装方針に従って、このスライドに載せてあるようなハードウェア資源を仮想化する必要があります。 例えば、プロセッサの特権命令や、メモリのページング機構などが、仮想化の必要な処理の例として挙げられます。

LilyVM [H. Eiraku et al. 03] とほぼ同様な点 仮想化を必要とするハードウェア資源 LilyVM [H. Eiraku et al. 03] とほぼ同様な点 以下の資源をユーザレベルで仮想化する プロセッサ 特権命令、割り込み、… 共有メモリ アドレス空間、一貫性制御 I/Oデバイス ハードディスク、シリアル端末、タイマー、… そして、これらのハードウェア資源の仮想化においては、筑波大学のeiraku君が開発しましたLilyVMを、多くの点で基にしています。 例えば、ページング機構の仮想化などは、LilyVMとほぼ同様の実装となっています。

仮想化を必要とするハードウェア資源 我々のVMMに独自な点 以下の資源をユーザレベルで仮想化する プロセッサ 共有メモリ I/Oデバイス 特権命令、割り込み、… 共有メモリ アドレス空間、一貫性制御 I/Oデバイス ハードディスク、シリアル端末、タイマー、… それではLilyVMとは異なり、我々のシステムに独自の実装である点は何かというと、このスライドに載せてあるものが挙げられます。 特に共有メモリの一貫性制御がもっとも特徴的であるため、以降の発表では、この共有メモリの一貫性制御に焦点を置いて、説明を進めていきたいと思います。 (3:00) (計11:00?)

残りの発表の流れ VMMの設計 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題

共有メモリの一貫性制御の仮想化 ある仮想プロセッサが行った書き込みを、 他の仮想プロセッサに反映させる IA-32メモリモデルを満たすように まず、そもそもメモリの一貫性制御とは何なのかということですが、もっとも単純には、あるプロセスが行った書き込み結果をリモートプロセスに反映させることです。 どう書き込みがリモートに反映されるかについては、IA-32のマニュアルにメモリモデルに関する仕様があり、それを満たす必要があります。 以降では、まずIA-32のメモリモデルについて説明し、そのあと、 IA-32のメモリモデルを満たす一貫性制御アルゴリズムについて概説します。

IA-32のメモリモデルの概要 以下の制約を満たす 同期命令を提供する Processor consistency Write atomicity 同期命令を提供する 一時的にメモリ一貫性を強めることが可能 IA-32のメモリモデルですが、基本的には、Processor consistencyと呼ばれる制約と、Write atomicityと呼ばれる制約の二つを満たすように書き込みを反映させます。 そして、この二つの制約に加えて、一時的にメモリ一貫性を強める役割を果たす、同期命令というものを提供しています。

Processor Consistency (1/2) あるプロセッサが行った書き込みは， 同一プロセッサには，すぐに反映される 異なるプロセッサには，遅れて反映されうる プロセッサ1 プロセッサ2 write X to p 書き込み反映 read from p = ? read from p それではまず、Processor consistencyという制約が、何を保障するのかについて説明します。 メモリモデルがProcessor consistencyを満たすという時は、あるプロセッサが行った書き込みは，同一プロセッサに対しては，すぐに反映されることが保障されています。自分と異なるプロセッサに対しては，すぐに反映されるとは保障されておらず、遅れて反映されることがあります。 　例えば、このスライドにあるように二つのプロセッサPU1とPU2があるとします。矢印の方向に沿って時間が経過しているとします。このとき、PU1がアドレスpに対してXという値を書き込んだとします。この書き込み結果は、自プロセッサに対しては、すぐに反映されます。例えば、書き込み後にPU1が同じアドレスpから読み込みを行うと、さきほど書き込んだ値Xが得られることが保障されています。 それに対して、PU1の書き込みは、リモートプロセッサであるPU2には、書き込み直後に反映されるとは限らず、遅れて反映される場合があります。この場合、PU2は、PU1のアドレスpへの書き込み後に読み込みを行ったとしても、値がXにならず、しばらくたって、書き込み結果が反映された後で、読み込んだ値がXになります。 = X read from p = X

Processor Consistency (2/2) あるプロセッサが行った書き込みは， 同じ順序でリモートプロセッサに反映される プロセッサ1 プロセッサ2 プロセッサ3 write X to p write Y to q write Z to r Processor consistencyは、他にも、「あるプロセッサが行った書き込みが、同じ順序でリモートプロセッサに反映される」ということを保障します。 例えば、PU1が値Xをアドレスpに書き込み、その後、値Yをアドレスqに書き込み、その後、値Zをアドレスrに書き込んだとします。この場合、リモートプロセッサPU2とPU3に対して、それぞれ同じ順番で書き込みが反映されることが保障されます。

（アドレスpに対する）読み書きは，この間に 発生しない Write Atomicity 書き込みはリモートプロセッサにatomicに　　　　　　　　反映される プロセッサ1 プロセッサ2 プロセッサ3 write X to p （アドレスpに対する）読み書きは，この間に　　　　　　　　　　発生しない 次に、Write Atomicityが何を保障するかについて説明します。 Write atomicityは、「書き込みがリモートプロセッサにatomicに反映される」ことを保障します。つまり、書き込みがリモートプロセッサに反映されるときは，全てのプロセッサに対して同時に反映され、一つのプロセッサに反映され、他のプロセッサにまだ反映されていない間に、書き込みが発生したのと同じアドレスに対する読み書きは起こらないことを保障します。 例えば、PU1がアドレスpに対して書き込みを行ったとします。それがリモートプロセッサPU2に反映されるのと、PU3に反映されるのとの間に、アドレスpに対する読み書きが発生しないことが保障されています。

同期命令 一時的にメモリ一貫性を強める 例） mfence命令 プロセッサ1 プロセッサ2 プロセッサ3 write X to p 書き込みがリモートプロセッサに反映されたことを保障 プロセッサ1 プロセッサ2 プロセッサ3 write X to p write Y to q 以上の制約に加えて、IA-32は、同期命令と呼ばれる一時的にメモリ一貫性を強める命令を提供しています。 例えば、同期命令の一つであるmfence命令は、その命令が実行された時には、それ以前に行われた書き込みがリモートプロセッサに反映されていることを保障します。このスライドの場合ですと、PU1がmfenceを実行した時点で、それ以前に実行した二つの書き込みは、リモートプロセッサPU2とPU3に反映されていることが保障されます。 mfence

現在の一貫性制御アルゴリズム ページ単位での、メモリの共有・非共有の管理 Multiple-reader/single-writer 同一ページへ読み込みは、 複数のプロセッサが同時に行える 同一ページへの書き込みは、 1つのプロセッサしか同時に行えない Write invalidate このIA-32のメモリモデルを満たすように、一貫性制御アルゴリズムを実現する必要があります。 現在のシンプルな実装では、ページ単位で、メモリの共有・非共有を管理します。 このアルゴリズムの特徴のひとつは、Multiple-reader/single-writerプロトコルということです。 つまり、同一ページへ読み込みは複数のプロセッサが同時に行えるが、同一ページへの書き込みは1つのプロセッサしか同時に行えないということです。 もうひとつの特徴は、Write invalidate方式ということです。 あるページに書きこみが発生した時点で、もし遠隔プロセッサにそのページが複製があった場合に、その複製は破棄されます。

議論 ～アルゴリズムの改良にむけて～ IA-32のメモリモデルを考慮した より効率的なアルゴリズムにしたい しかし、もちろん、このシンプルなアルゴリズムは余り効率が良いものではありません。 今後、よりIA-32のメモリモデルを考慮し、それに適した、より効率的な共有メモリの一貫性制御アルゴリズムを開発を目指します。

アルゴリズムの最適化の例 Multiple writes 同一ページに対して複数の仮想プロセッサが 同時に書き込み可能にする ただし、IA-32のメモリモデルは満たしつつ 具体的には、アルゴリズムの最適化の例として、現在のシンプルなアルゴリズムでは、あるページに対して、同時にひとつのプロセッサしか書き込み可能であったのですが、それを改良し、同一ページに対して複数の仮想プロセッサが同時に書き込み可能にすることを目指します。 ただし、先ほど述べましたIA-32のメモリモデルは満たすようにします。

Multiple Writesの実現方法 (1/4) 直列化命令実行時に，ローカルの書き込みを他の全てのマシンに反映させる プロセッサ1 プロセッサ2 Write X to p Write Y to q p, q, rへの書き込み結果を送信 Write Z to r Multiple Writesの実現方法としては、直列化命令実行時に，ローカルの書き込みを他の全てのマシンに反映させることを考えています。 例えば、 このとき、他の遠隔プロセッサが同一ページの複製を持っていたとしても、その複製を破棄しません。 すぐに遠隔プロセッサに反映させるということをせず、mfenceなどの直列化命令が実行された時点で、それまでに行われた書き込みを反映させます。 Processor consistency は満たされる。 この方式によって、かつ、IA-32のメモリモデルをProcessor consistency は満たされる。 書き込み結果を反映 mfence

Multiple Writesの実現方法 (2/4) 全ページを書き込み禁止にする 仮想プロセッサ1 仮想プロセッサ2 Write X to p Write Y to q Write Z to r mfence このアルゴリズムは、具体的には、以下のように動作します。 まず、全てのページを書き込み禁止にし、仮想マシンの実行を開始します。 ローカルメモリ ローカルメモリ

Multiple Writesの実現方法 (3/4) ページに対して書き込みがあると　 そのページの複製を作成する そのページへの書き込みを許可する 仮想プロセッサ1 仮想プロセッサ2 Write X to p Write Y to q Write Z to r mfence p q r ページの複製

Multiple Writesの実現方法 (4/4) mfence命令を実行する時に， 複製と現在のメモリを比較して差分を作成する 差分を遠隔プロセッサに送信する 差分を作成 仮想プロセッサ1 仮想プロセッサ2 Write X to p Write Y to q Write Z to r mfence p q r

残りの発表の流れ VMMの設計 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題 次に、我々が行った予備実験について述べます。

VMMの性能測定 特権命令などの仮想化処理によるオーバヘッド  仮想シングルプロセッサマシン上での 逐次プログラムの実行時間を測定 共有メモリの仮想化によるオーバヘッド  仮想SMPマシン上での 並列プログラムの実行時間を測定 具体的には、我々はこのVMMのプロトタイプを実装し、その性能測定を行いました。 まず、共有メモリの仮想化処理以外の、特権命令などの仮想化処理によるオーバヘッドを測定するために、仮想シングルプロセッサマシン上で逐次プログラムを走らせ、その実行時間を測定しました。 次に、共有メモリの仮想化によるオーバヘッドを測定するために、仮想SMPマシン上で並列プログラムを走らせ、その実行時間を測定しました。

仮想シングルプロセッサマシン上での逐次プログラムの実行 プログラム名 実マシン上での実行時間 (P) 仮想マシン上での実行時間 (V) オーバヘッド (V / P) fib 22.6 22.1 0.97 getpid 0.05 18.1 354 ls 0.03 6.64 255 gcc 0.14 0.98 6.81 （単位：秒） システムコール呼び出しや I/Oデバイスへのアクセスの オーバヘッドが非常に大きい fib: フィボナッチ数を計算する getpid: システムコールを100,000回実行する ls: 数百のファイルの情報を表示する gcc: Cプログラムをコンパイルする このスライドに載せてある表が、仮想シングルプロセッサマシン上での逐次プログラムの実行時間を示しています。 実験に用いた逐次プログラムは、フィボナッチ数を計算するプログラム、ただシステムコールを大量に呼ぶだけのプログラム、ハードディスクにアクセスしファイルの情報を表示するプログラム、Cのコンパイラとなっています。 これらのプログラムを実機上と仮想マシン上とで実行したときの実行時間を比較すると、システムコール呼び出しやI/Oデバイスへのアクセスのオーバヘッドが非常に大きいことが分かります。 今後は、このオーバヘッドを削減するために、XenやVmwareといった既存のVMMによって開発された最適化手法を適応することが考えられます。 CPU: Intel Xeon 2.4 GHz Memory: 2GB Host & Guest OS: Linux 2.4

仮想SMPマシン上での 並列プログラムの実行 互いに独立したプロセスを8つ並列に実行 次に、仮想SMPマシン上での並列プログラムの実行時間を測定しました。 具体的には、CPUパワーを消費する互いに独立したプロセスを8つ並列に走らせ、仮想SMPマシンのプロセッサ数を変化させながら、その実行時間を測定しました。 その結果を、このスライドのグラフが示しています。 グラフの横軸が仮想SMPマシンのプロセッサ数を表し、縦軸が速度向上比を表しています。 fib(n)は、n番目のフィボナッチ数の計算を意味しています。 このグラフから、実行させるタスクの粒度が十分大きければ台数効果が出ているのですが、 粒度が小さいときには性能がスケールしていないことが分かります。 CPU: Intel Xeon 2.4 GHz Memory: 2GB Network: 1 Gigabit Ethernet Host & Guest OS: Linux 2.4

ゲストOSがスケジューリングに失敗している fib(44)の実行時間の内訳 共有メモリの仮想化のオーバヘッドが増大 プロセッサ数 全実行時間 Native Shmem Misc Idle 1 180.0 177.8 0.0 2.2 2 90.3 87.9 1.0 1.1 0.3 4 52.4 43.7 3.0 0.4 5.3 8 27.9 22.1 3.7 0.1 2.0 （単位：秒） ゲストOSがスケジューリングに失敗している よりオーバヘッドの原因について調べるために、 fib(44)の実行時間の内訳をとりました。 Native、Shmem、Misc、idleというのが、それぞれ、ゲストOSがnativeに実行されていた時間、共有メモリの一貫性制御にかかる時間、それ以外にかかったVMMの処理時間、仮想マシンがhlt命令を実行していた時間を表します。 この表から、当然のことですが、プロセッサ数が増えるにつれて共有メモリの仮想化のオーバヘッドが増大していることが分かります。また、これはシステムのバグが原因であることも考えられるのですがゲストOSがスケジューリングに失敗しており、それがオーバヘッドになっていることも分かります。 以上の実験結果から、今後の課題として、共有メモリの一貫性制御の効率化などが重要であることが分かります。 (3:30) Native: ゲストOSがnativeに実行されていた時間 Shmem: 共有メモリの一貫性制御にかかる時間 Misc: 一貫性制御以外のVMMの処理時間 Idle: 仮想マシンがhlt命令を実行していた時間

残りの発表の流れ VMMの概要 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題

関連研究 (1/3) クラスタ上に仮想ccNUMAを構築するVMM 以下の点が異なる  詳細な性能比較は今後の課題 例）vNUMA [1]、Virtual Iron [2] 以下の点が異なる 対象とするアーキテクチャ VMMの実装方式 メモリの一貫性制御  詳細な性能比較は今後の課題 それでは関連研究について説明します。 関連研究として、まず、我々と同じように、分散環境上にマルチプロセッサマシンを仮想的に構築する仮想マシンモニタが挙げられます。 一つはvNUMAというもので、これは、複数のItanumのマシン上に、仮想的にccNUMAを構築するシステムです。 我々のシステムと比較して、いくつかの点が異なります。 まず、我々のVMMがIA-32アーキテクチャを対象としているのに対して、vNUMAはItaniumを対象としています。 VMMの実装方式も、我々のVMMがホストOSの上に位置するのに対して、vNUMAでは実ハードウェア上に直にVMMが位置します。 詳細な性能比較は今後の課題です。 また、Virtual Ironというものも、我々と関連するシステムですが、詳細が未公開のため、十分な比較はまだ出来ていません。 [1] M. Chapman USENIX’05 [2] http://www.virtualiron.com/

詳細が未公開のため、 十分な比較は行えていない 関連研究 (1/3) クラスタ上に仮想ccNUMAを構築するVMM 例）vNUMA [1]、Virtual Iron [2] 詳細が未公開のため、 十分な比較は行えていない それでは関連研究について説明します。 関連研究として、まず、我々と同じように、分散環境上にマルチプロセッサマシンを仮想的に構築する仮想マシンモニタが挙げられます。 一つはvNUMAというもので、これは、複数のItanumのマシン上に、仮想的にccNUMAを構築するシステムです。 我々のシステムと比較して、いくつかの点が異なります。 まず、我々のVMMがIA-32アーキテクチャを対象としているのに対して、vNUMAはItaniumを対象としています。 VMMの実装方式も、我々のVMMがホストOSの上に位置するのに対して、vNUMAでは実ハードウェア上に直にVMMが位置します。 詳細な また、Virtual Ironというものも、我々と関連するシステムですが、詳細が未公開のため、十分な比較はまだ出来ていません。 [1] M. Chapman USENIX’05 [2] http://www.virtualiron.com/

我々のVMMが必要とする カーネルの改変はごく一部 関連研究 (2/3) Linuxカーネルを改変した分散OS 例）MOSIX [3]、Kerighed [4]、 OpenSSI [5] カーネル改変に多大な手間を必要とする 我々のVMMが必要とする カーネルの改変はごく一部 また、関連研究として、Linuxカーネルを改変した分散OSが挙げられます。 こうした分散OSとしては、MOSIX、Kerighed、 OpenSSIなどが挙げられます。 これらのOSは、例えば大域プロセス空間などが提供し、ユーザは既存のOSと同じインターフェースのまま、クラスタを利用することができます。 しかし、これらの方式には、カーネル改変に多大な手間を必要とし、カーネルのバージョンアップに対応するのが困難であるという問題があります。 それに対して、我々のVMMでは、カーネルが必要とする改変が、ごく一部であるという利点があります。 [3] A. Barak et al. FGCS’98 [4] C. Morin et al. Euro-Par’03 [5] http://openssi.org/

既存のLinux等のOSの インターフェースをそのまま使用できる 関連研究 (3/3) クラスタ用ミドルウェアシステム 例）Score [6]、Condor [7]、GLUnix [8] 個々のシステムの仕様に精通する必要がある 我々のVMMでは、 既存のLinux等のOSの インターフェースをそのまま使用できる また、 Score、Condor 、GLUnixなどのクラスタ用ミドルウェアシステムも、関連研究として挙げられます。 これらのマシンを使うと、例えばクラスタの全ノードへの遠隔ジョブ投入などが可能になります。 しかし、これらのシステムの欠点として、個々のシステムのもつ、それぞれ独自の仕様に精通する必要があります。 それに対して、我々のVMMでは、既存のLinux等のOSのインターフェースをそのままクラスタ上で使用できるという利点があります。 [6] http://www.pccluster.org/ [7] M. Litzkow et al. ICDCS’88 [8] D. P. Ghormely et al. Software Practice and Experinece‘98

残りの発表の流れ VMMの概要 基本的な実装方針 共有メモリの一貫性制御の仮想化 予備実験 関連研究 まとめと今後の課題

まとめ 単一システムイメージを提供するための 仮想マシンモニタ クラスタ上に仮想SMPマシンを構築 単一システムイメージを提供するための　　仮想マシンモニタ クラスタ上に仮想SMPマシンを構築 共有メモリへのアクセスが少ない粗粒度タスクで高性能を達成 本発表では、単一システムイメージを提供するための仮想マシンモニタについて述べました。 この仮想マシンモニタは、クラスタ上に仮想SMPマシンを構築するというものです。 共有メモリへのアクセスが少ない粗粒度タスクの実行において、高性能を達成しました。

今後の課題 メモリの一貫性制御アルゴリズムの改良 動的な物理マシンの増減の隠蔽 耐故障性の導入 物理マシン数が動的に変化しても 常に一定数の仮想プロセッサを提供 耐故障性の導入 今後の課題としては、まず、メモリの一貫性制御アルゴリズムの改良が挙げられます。 その他にも、動的な物理マシンの増減の隠蔽として、物理マシン数が動的に変化しても一定数の仮想プロセッサを提供するといったことや、耐故障性の導入が今後の課題として挙げられます。

ご清聴ありがとうございました ソースコードは、以下のURLから取得可能 http://www.yl.is.s.u-tokyo.ac.jp/projects/vincs/