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

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

タ金田憲二大山恵弘　米澤明憲　

（東京大学）

コモディティクラスタの普及

• かつてないほど一般に浸透– 個人・ワークグループ用として　　　　　　　

　　　　　　　　　　　　　　　 4~32 ノード程度のクラスタを所有するのが、　普通になっている

クラスタの利用における問題点

• 利便性が低い例）複数のマシンに分散した CPU やディス

クを大域的に管理する機構の欠如– 一般のクラスタ利用者には、致命的な問題

本研究の目標• クラスタ上に単一システムイメージを構

築– 大域プロセス空間– 大域ファイルシステム– …

計算機科学を専門としない一般の人でも、小・中規模クラスタを簡便に利用できるよう

にする

• 仮想マシンモニタを利用する

本研究のアプローチ

実機と同等の処理が可能な仮想マシンを構築するミドルウェアシステム例） VMware Workstation

• ネットワークで結合された複数のマシン上に　　　　　　　　　　　　　　　　　　　　　 SMP マシンを仮想的に構築する

N台のシングルプロセッサマシン

Nプロセッサからなる仮想 SMP マシン

仮想化

我々が提案する仮想マシンモニタ

仮想マシンの動作デモ

• 8 台の物理マシン上に 8-way の SMP マシンを仮想的に構築する

• ゲスト OS 上で立ち上げたプロセスが、それぞれ異なる物理マシン上で並列に実行される

プロセッサ

メモリ

プロセッサ

メモリ

プロセッサ

メモリ…物理マシン群

仮想マシンプロセッサ

メモリ

プロセッサ … プロセッサプロセスプロセスプロセス

仮想マシンの動作デモ仮想 SMP マシン上で動いている Linux の端末

それぞれの実マシンのCPU 負荷

我々のアプローチの利点 ( その1)

• 既存の並列プログラムを（ほとんどの場合）無変更のまま、実行可能– 科学技術計算から Web サーバまで– 多少の改変で Linux カーネルも

• プロセス管理機構やファイルシステムを分散環境上で利用可能

• 仮想マシンを様々な目的に応用可能– サンドボックスとしての利用– 仮想マシンの実行状態の保存・復元– …

我々のアプローチの利点 ( その2)

残りの発表の流れ

• 我々の仮想マシンモニタの概要• ハードウェアの仮想化• 共有メモリの一貫性制御の仮想化• 予備実験• 関連研究• まとめと今後の課題

我々の仮想マシンモニタの概要

•提供される仮想マシンの特徴•仮想資源と実資源の対応付け

仮想マシンの特徴 ( その 1)

• ISA レベルの仮想化※VMWare ， Xen などと同様

仮想マシン

ユーザアプリ

ISAゲスト OS

システムコール

仮想マシンモニタ


• 仮想マシンの ISA ≒ 実マシンの ISA

実マシンのISA実マシン

ユーザアプリホスト OS

仮想マシン

ユーザアプリゲスト OS

仮想マシンモニタ

仮想マシンのISA


• 既存の OS を仮想マシン上で走らせるためにはカーネルに修正を加える必要がある

• ただし、ほとんどの修正は自動化できる– 手動で加える変更も、ほぼ自明のもの

例）カーネル空間のベースアドレスの変更

※LilyVM [H. Eiraku et al. BSDCon’03] と同様の設計


• 仮想マシン・実マシン共に Linux/IA-32 を対象– 一般に広く普及しているので– 既存研究の資産が利用しやすいので

仮想資源と実資源の対応例

プロセッサ

メモリディスク

実マシン

プロセッサ


実マシン

仮想 SMPプロセッサ


プロセッサ

仮想資源と実資源の対応例

プロセッサ

モニタプロセス


実マシン

プロセッサ



実マシン

仮想 SMPプロセッサ


プロセッサ

ハードウェアの仮想化


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

– 特権命令、割り込み、…

• 共有メモリ–ページング、一貫性制御、…

• I/O デバイス– ハードディスク、 APIC 、タイマー、…






LiLyVM とほぼ同様LiLyVM とほぼ同様






LiLyVM とほぼ同様LiLyVM とほぼ同様

我々独自の点

基本的な実装方針

• 一つの仮想プロセッサごとに，　　　　　　　　　　　　　　　　　　以下の 2つのユーザプロセスを用意


VM プロセス

ゲスト OS を native に実行する

VM プロセスの実行を監視し、必要に応じて仮想化処

理をエミュレーションする

システムの基本動作サイクル


VM プロセス

実行を再開

ゲスト OS を native 実行

命令などの実行をエミュレー

ション

実行を捕捉

システムの動作例


VM プロセス

…lgdtl 0xa01002c2

…シグナル発生

特権命令の実行（ GDTRへの書き込み）

シグナルを捕捉

VM プロセスの実行を再開

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

共有メモリの一貫性制御の仮想化

•IA-32 のメモリモデルの概要•Simple な一貫性制御アルゴリズム•アルゴリズムの改良にむけて

共有メモリの一貫性制御の仮想化

• ある仮想プロセッサが行った書き込みを、他の仮想プロセッサに反映させる必要がある– IA-32 メモリモデルを満たすように

IA-32 のメモリモデルの概要

•以下の制約を満たす– Processor consistency– Write atomicity

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

Processor Consistency (1/2)

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

PU1write X to p

PU2

read from pread from p

=

X

書き込み反映

read from p=

X

=

?

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

Processor Consistency (2/2)

PU1write X to p

write Y to q

write Z to r

PU2 PU3

Write Atomicity

PU1 PU2 PU3write X to p

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

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

同期命令

PU1 PU2 PU3

mfence

write X to p

write Y to q

• 一時的にメモリ一貫性を強める例） mfence 命令

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

Simple な一貫性制御アルゴリズム

• 特に IA-32 のメモリモデルに特化しない–ページ単位での、メモリの共有・非共有の管

理– Write invalidate プロトコル– single writer, multiple readers

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

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

各ページに割り当てられる状態

• RW：読み書き共に可能• RD：読み込みのみ可能• INV: 読み書き共に不可能



RWプロセッサ 0のメモリページ 0

…RDページ 1

INVページ 2

INVプロセッサ 1のメモリ …RD RW

INVプロセッサ 2のメモリ …INV INV




…RDページ 1

INVページ 2



ページの状態が RW であるプロセッサは同時に一つ

他のプロセッサのページの状態は INV




…RDページ 1

INVページ 2



ページの状態が RD であるプロセッサは複数存在する場合がある

ページの状態の更新

•以下のアクセスが発生した際に、ページの状態が更新される– 状態が INV であるページへの読み書き– 状態が RD であるページへの書き込み

仮想プロセッサ 0がページ 2に読み込みを行った場合


…RDページ 1

INVページ 2



RD

RD

(i) プロセッサ 0 以外のページ 2を書き込み禁止にする

(ii) プロセッサ 0のページ 2を読み込みのみ可能

にする

仮想プロセッサ 0がページ 2に書き込みを行った場合


…RDページ 1

RDページ 2

INVプロセッサ 1のメモリ …RD RD


(i) プロセッサ 0 以外のページ 2を読み書き禁止にする

(ii) プロセッサ 0のページ2を読み込み書き可能にす

るRW

INV

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

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

アルゴリズムの最適化の例

• Multiple writes– 同一ページに対して複数の仮想プロセッサ

が同時に書き込み可能にする– ただし、 Processor Consistency は満た

しつつ

PU1 PU2

mfence

Write X to p

Write Y to q

Write Z to r

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

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

書き込み結果を反映

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


1. 全てのページを書き込み禁止にする

…

Write X to pWrite Y to qWrite Z to r

mfence

Memory MemoryPU1 PU2

X

Y

Z


2. ページに対して書き込みがあると　– そのページのコピー (= twin) を作成する– そのページへの書き込みを許可する

p

q

r


mfence

PU1MemoryTwins

PU2Memory


3. mfence 命令を実行する時に，– twin と現在のメモリを比較して diff を作成

する– diff をリモートマシンに送信する

p

q

r


mfence

MemoryTwins Memory

X

Y

Z

PU1 PU2

予備実験

予備実験

システムの基本性能の評価　実験内容

– 仮想マシン上で、互いに独立なタスクを並列実行• フィボナッチ x 8 プロセス

　実験環境– CPU: Intel Xeon 2.4 GHz– メモリ : 2GB– ネットワーク : 1000Base– ゲスト・ホスト OS: Linux 2.4

並列フィボナッチの性質

•主に、以下の処理で仮想化が必要となる– fork などのシステムコールの発行– ライブラリの読み込みなどによる

ハードディスクへのアクセス– 共有メモリの一貫性制御

例）プロセススケジューリングを行う際に、異なるプロセッサが同一ページにアクセスする

並列フィボナッチの速度向上

• タスクの粒度が粗ければ、台数効果が出た– fib(46) の時、 8 プロセッサで約6.6倍の速度向上

0

1

2

3

4

5

6

7

1 2 4 8

プロセッサ数

速度向

上比

fib(46)

fib(44)

fib(42)

fib(40)

fib(38)

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

（単位：秒）

Page fetch にかかる時間の分布

• 大半の fetch 処理は、数ミリ秒以内に完了• 一部の fetch 処理だけ、数十ミリ秒必要

Fetch された仮想アドレスの分布

カーネル空間

ユーザ空間

実験の考察

• False sharing によるオーバヘッドが大きい– 当然といえば当然

• 改善案はいくつか考えられる– 一貫性制御アルゴリズムの改良

• Multiple writes の実現

– ゲスト OS の改変• ゲスト OS を Linux2.6 にするだけでも、

性能が改善するかも

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

Documents

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