単一システムイメージを提供するための仮想マシンモニタ

単一システムイメージを提供するための仮想マシンモニタ

金田憲二 *# 大山恵弘 * 米澤明憲 *

* 東京大学 # 日本学術振興会

クラスタが隆盛を極める PC の性能向上・価格低下

数台の PC で， 10 年前のスパコンに近い性能– TOP500 中の 70% 以上をクラスタが占める

個人・グループで小・中規模クラスタを所有

クラスタの利便性は著しく低い• 計算資源の管理が困難

例）クラスタ上の全プロセスの状態を取得するには？

• 並列アプリの開発が困難例） MPI や PVM などのメッセージパッシング型が

大半

• …

本研究の目標• クラスタの簡便な利用を可能にする

– Easy to manage– Easy to develop

クラスタ上に単一システムイメージを構築する例）共有メモリ空間，大域プロセス空間

本研究のアプローチ仮想マシンモニタ（ VMM ）を利用する

実機と同等の処理が可能な仮想マシンを構築するミドルウェアシステム例） VMware [1] ， Xen [2] ， LilyVM [3]

[1] http://www.vmware.com/[2] P. Barham et al.SOSP’03[3] H. Eiraku et al. BSDCon’03

設計・実装する VMM

クラスタ上に仮想的に SMP マシンを構築する

クラスタ

仮想 SMP マシン

仮想化

本アプローチの利点• 既存の OS が仮想マシン上で動作する分散資源を簡便に管理できる

例） ps コマンドや kill コマンドによるプロセス管理

• 共有メモリ用の並列アプリが動作する並列アプリを簡便に記述・実行できる

– 科学技術計算から web サーバまで例） make コマンドやシェルスクリプトの利用

並列タスクの実行デモ

…実マシン

仮想マシン

ゲスト OS (Linux)

VMM

ホスト OS ホスト OS ホスト OS

並列タスクの実行デモ

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

仮想マシンの特徴• ISA レベルでの仮想化

– IA-32 アーキテクチャを対象• Para-virtualization

C.f.) Xen 、 LilyVM

ユーザアプリホスト OS

実マシン

ユーザアプリゲスト OS

仮想マシンモニタ仮想マシン

仮想マシン ISA ≒ 実マシン ISAOS が仮想マシン上で動く

仮想マシンと実マシンの対応

実マシン

仮想マシン

仮想マシンと実マシンの対応仮想プロセッサと実プロセッサは 1 対 1に対応

実マシン

仮想マシン

仮想マシンと実マシンの対応実マシンのメモリの一部を仮想マシン用として確保

実マシン

n MB n MB

n MB

仮想マシン

仮想マシンと実マシンの対応どれかの実マシンにある I/O デバイスを仮想マシン用に確保

仮想マシン

実マシン

ディスクイメージ

基本的な実装方針1 つの仮想プロセッサごとに，　　　　　　　　　　　　　　　　　　以下の 2 つのユーザプロセスを用意

モニタプロセス

VM プロセスゲスト OS を native に実行

する

VM プロセスの実行を監視し、必要に応じてハードウ

ェアの仮想化処理を行う

VMM の動作例

モニタプロセス

VM プロセス

…lgdtl 0xa01002c2

…シグナル発生

特権命令の実行（ GDTR への

書き込み）

シグナルを捕捉

VM プロセスの実行を再開

実マシンのメモリ上のどこかに仮想マシンの GDTR の値を格納

仮想化を必要とするハードウェア資源

• プロセッサ– 特権命令、割り込み、…

• 共有メモリ– アドレス空間、一貫性制御

• I/O デバイス– ハードディスク、シリアル端末、タイマー、…


以下の資源をユーザレベルで仮想化する• プロセッサ

– 特権命令、割り込み、…• 共有メモリ

– アドレス空間、一貫性制御• I/O デバイス

– ハードディスク、シリアル端末、タイマー、…

LilyVM [H. Eiraku et al. 03] とほぼ同様な点


以下の資源をユーザレベルで仮想化する• プロセッサ

– 特権命令、割り込み、…• 共有メモリ

– アドレス空間、一貫性制御• I/O デバイス

– ハードディスク、シリアル端末、タイマー、…

我々の VMM に独自な点

共有メモリの一貫性制御の仮想化• ある仮想プロセッサが行った書き込みを、

他の仮想プロセッサに反映させる– IA-32 メモリモデルを満たすように

IA-32 のメモリモデルの概要• 以下の制約を満たす

– Processor consistency– Write atomicity

• 同期命令を提供する– 一時的にメモリ一貫性を強めることが可能

プロセッサ 1write X to p

プロセッサ 2

read from pread from p

=

X

書き込み反映

read from p=

X

=

?

Processor Consistency (1/2)

• あるプロセッサが行った書き込みは，– 同一プロセッサには，すぐに反映される– 異なるプロセッサには，遅れて反映されうる

プロセッサ 1write X to p

write Y to q

write Z to r

プロセッサ 2 プロセッサ 3

Processor Consistency (2/2)

• あるプロセッサが行った書き込みは，同じ順序でリモートプロセッサに反映される

プロセッサ 1プロセッサ 2 プロセッサ 3write X to p

（アドレス pに対する）読み書きは，この間に　　　　　　　　　　発生しない

Write Atomicity

• 書き込みはリモートプロセッサに atomicに　　　　　　　　反映される

プロセッサ 1 プロセッサ 2 プロセッサ 3

mfence

write X to p

write Y to q

同期命令• 一時的にメモリ一貫性を強める

例） mfence 命令• 書き込みがリモートプロセッサに反映されたことを保障

• ページ単位での、メモリの共有・非共有の管理– Multiple-reader/single-writer

• 同一ページへ読み込みは、複数のプロセッサが同時に行える

• 同一ページへの書き込みは、1 つのプロセッサしか同時に行えない

– Write invalidate

現在の一貫性制御アルゴリズム

議論～アルゴリズムの改良にむけて～

• IA-32 のメモリモデルを考慮したより効率的なアルゴリズムにしたい

アルゴリズムの最適化の例• Multiple writes

– 同一ページに対して複数の仮想プロセッサが同時に書き込み可能にする

– ただし、 IA-32 のメモリモデルは満たしつつ

プロセッサ 1 プロセッサ 2

mfence

Write X to p

Write Y to q

Write Z to r p, q, rへの書き込み結果を送信

書き込み結果を反映

• 直列化命令実行時に，ローカルの書き込みを他の全てのマシンに反映させる

Multiple Writes の実現方法 (1/4)


• 全ページを書き込み禁止にする

Write X to pWrite Y to qWrite Z to r

mfence ローカルメモリ

ローカルメモリ

仮想プロセッサ 1 仮想プロセッサ2


• ページに対して書き込みがあると　–そのページの複製を作成する–そのページへの書き込みを許可する


mfence

p q r

仮想プロセッサ 1 仮想プロセッサ2

ページの複製


• mfence 命令を実行する時に，– 複製と現在のメモリを比較して差分を作成す

る–差分を遠隔プロセッサに送信する


mfence

仮想プロセッサ 1

p q r

仮想プロセッサ2

差分を作成

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（単位：秒）

CPU: Intel Xeon 2.4 GHz Memory: 2GBHost & Guest OS: Linux 2.4

fib: フィボナッチ数を計算する

getpid: システムコールを 100,000 回実行する

ls: 数百のファイルの情報を表示する

gcc: C プログラムをコンパイルする

システムコール呼び出しやI/O デバイスへのアクセス

のオーバヘッドが非常に大き

い

• 互いに独立したプロセスを 8 つ並列に実行

0

2

4

6

8

1 2 4 8

Number of processors

Spe

edup

fi b( 46)

fi b( 44)

fi b( 42)

fi b( 40)

fi b( 38)

CPU: Intel Xeon 2.4 GHz Memory: 2GBNetwork: 1 Gigabit EthernetHost & Guest OS: Linux 2.4

仮想 SMP マシン上での並列プログラムの実行

fib(44) の実行時間の内訳

プロセッサ数

全実行時間 Native Shmem Misc Idle

1 180.0 177.8 0.0 2.2 0.0

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（単位：秒）

共有メモリの仮想化のオーバヘッドが増大

Native: ゲスト OS が native に実行されていた時間

Shmem: 共有メモリの一貫性制御にかかる時間

Misc: 一貫性制御以外の VMM の処理時間

Idle: 仮想マシンが hlt 命令を実行していた時間

ゲスト OS がスケジューリングに失敗している

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

関連研究 (1/3)

• クラスタ上に仮想 ccNUMA を構築する VMM例） vNUMA [1] 、 Virtual Iron [2]

[1] M. Chapman USENIX’05 [2] http://www.virtualiron.com/

• 以下の点が異なる– 対象とするアーキテクチャ– VMM の実装方式– メモリの一貫性制御

詳細な性能比較は今後の課題

関連研究 (1/3)

• クラスタ上に仮想 ccNUMA を構築する VMM例） vNUMA [1] 、 Virtual Iron [2]

[1] M. Chapman USENIX’05 [2] http://www.virtualiron.com/

詳細が未公開のため、十分な比較は行えていない

関連研究 (2/3)

• Linux カーネルを改変した分散 OS例） MOSIX [3] 、 Kerighed [4] 、 OpenSSI [5]

– カーネル改変に多大な手間を必要とする

[3] A. Barak et al. FGCS’98[4] C. Morin et al. Euro-Par’03[5] http://openssi.org/

我々の VMM が必要とするカーネルの改変はごく一部

関連研究 (3/3)

• クラスタ用ミドルウェアシステム例） Score [6] 、 Condor [7] 、 GLUnix [8]

– 個々のシステムの仕様に精通する必要がある

[6] http://www.pccluster.org/[7] M. Litzkow et al. ICDCS’88[8] D. P. Ghormely et al. Software Practice and Experinece‘98

我々の VMM では、既存の Linux等の OS の

インターフェースをそのまま使用できる

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

まとめ• 単一システムイメージを提供するための

　　仮想マシンモニタ– クラスタ上に仮想 SMP マシンを構築– 共有メモリへのアクセスが少ない粗粒度タス

クで高性能を達成

今後の課題• メモリの一貫性制御アルゴリズムの改良• 動的な物理マシンの増減の隠蔽

–物理マシン数が動的に変化しても常に一定数の仮想プロセッサを提供

• 耐故障性の導入

ご清聴ありがとうございました

ソースコードは、以下の URL から取得可能http://www.yl.is.s.u-tokyo.ac.jp/projects/vincs/

単一システムイメージを 提供するための仮想マシンモニタ

Documents

単一システムイメージを提供するための仮想マシンモニタ