オペレーティングシステム論文購読 (2015/1/27) 味曽野雅史

中心に紹介する論文

• OSv: optimizing the operating system for virtual machines Avi Kivity, Dor Laor, Glauber Costa, Pekka Enberg, Nadav Har’El, Don Marti, and Vlad Zolotarov (Cloudius Systems) USENIX ATC’14: 2014 USENIX Annual Technical Conference https://www.usenix.org/conference/atc14/technical-sessions/presentation/kivity

• OSvと呼ばれる仮想化を前提とした単一アプリケーション動作に 適化されたOSについて

2

内容

• 仮想化技術について • OSv登場の背景 • OSv

•  デザイン •  利点

• 関連技術との比較 •  CoreOS •  コンテナ

•  Docker

3

仮想化技術

• 一つのマシンで複数の仮想的なマシンを動かす技術 (その上でOS/アプリケーションを実行)

•  1960年代(メインフレーム時代)から研究/利用 • 利点

•  ハードウェアリソースの有効活用 •  容易に仮想マシンの一時停止/複製が可能 •  簡単に開発環境を構築 •  動的マイグレーション (仮想マシンを動的に移動) •  スナップショット

4

用語

• Host - 仮想化をおこなうマシン

• Guest - 仮想的に実行されるマシン. その上で動作するOSをGuest OSという.

• Hypervisor / Virtual Machine Monitor (VMM) - VMを管理する制御プログラム VMMには大きく分けてType1とType2が存在

5

Type2 VMM

• Host OSのアプリケーションとして動作 •  VMWare Workstation, VMWare Fusion, VMware Player •  VirtualBox •  Virtual PC •  QEMU

Hardware

Host OS

VMM

Guest OS

Application

Guest Application

6

Type1 VMM

• OSを利用せずハードウェアの上のレイヤーに直接存在 •  VMWare ESXi •  Xen

Hardware

VMM

Guest OS

Guest Application

Guest Application

Guest OS

7

明確にType1 / Type2に分類されないもの

• KVM (Kernel-based Virtual Machine) / bhyve • いずれもカーネルモジュールとして実装

(KVM: Linux, bhyve: Free BSD)

Hardware

Guest Application

QEMU

OS (Linux Kernel)

Guest OS

Application

8

Type1 / Type2 VMM の比較

•  Type1 •  ユーザから扱いやすい．手軽

•  Type2 •  ハードウェア性能をいかせる •  VPS / クラウドで利用されているのはこちら

9

VMMは実際に何をしているのか?

10

PopekとGoldbergの仮想化要件

•  “Formal requirements for virtualizable third generation architectures” Gerald J. Popek, Robert P. Goldberg (1974)

• 仮想化に求められる事 •  Equivalence

•  VMMで動作するプログラムは実マシンで動作する場合と時間の遅れを除いて等価

•  Resource Management •  VMMが仮想化された資源を完全に管理すること

•  Efficiency •  大部分の命令は直接実マシンのCPUで実行する

11

PopekとGoldbergの仮想化要件

• 定理1 CPUのすべてのセンシティブ命令が特権命令であれば仮想化可能 (十分条件)

• 特権命令 •  実行するときにプロセッサがユーザモードならトラップされる命令

• センシティブ命令 •  制御センシティブ命令

•  システム資源の構成を変更する命令 •  動作センシティブ命令

•  システム資源の構成に依存する命令 (CPUモードの読み取りなど)

12

•  x86の命令セット

• このままでは仮想化できない

x86の場合

特権命令

センシティブ命令

それ以外

13

• ソフトウェアで命令をシミュレートする • QEMU 全ての命令をソフトウェアで実行

• VMWare センシティブな命令のみを動的に変換して実行

方法1: バイナリ変換

14

• Guest OSのカーネルを修正してセンシティブな命令を実行する際にVMMを呼び出すようにする

• Xen

方法2: 準仮想化

15

方法3: Intel VT-x (ハードウェア支援) •  2006年からx86に追加 • Guest OSを実行しているときとそうでないときでCPUモードを変えて，Guest OS実行時のセンシティブ命令をトラップする

16

(余談) メモリアクセスの効率化

• Guest OS上のプロセスのメモリアクセス手順は， •  Guest OSの仮想アドレス •  → Guest OSの物理アドレス •  → VMMによりHost OS側のアドレスにマッピング

• 効率化のためにハードウェア的サポート機能等が存在 (Intel EPT / shadow paging)

Hardware

VMM

Application

Guest OS

17

近年のVMM製品の流れ •  1998

•  VMWare 創立 •  x86仮想化

•  2003 •  QEMU

•  2004 •  Xen

•  2006 •  Intel VT: x86のハードウェア的仮想化サポート •  (AWS)

•  2007 •  KVM •  VirtualBox

•  2008 •  Hyper-V

•  2013 •  OSv

18

クラウド/VPSにおけるVirtual Machine

• ユーザはインターネット経由で外部のリソースを利用 • ユーザは直接サーバを利用するのではなく， サーバ上の仮想マシンを利用する

Internet

19

実際にクラウド/VPSで利用されているVMM

• AWS •  Xen

• さくらのクラウド / さくらVPS •  KVM

• ニフティクラウド •  VMWare

• Windows Azure •  Hyper-V ベース (推定)

20

クラウド上のサービス構成例

• 一つのOS上では単一アプリケーションのみ動かすことが多い (HTTP Server, Database, App Server…)

http://aws.amazon.com/jp/solutions/case-studies/outsmart/

21

クラウドで実行するOSに求められる事

• VMの形で提供される • 高速起動 • 省リソース • 高性能 • 自動デプロイ • 自動アップデート • 設定（再構成)が容易であること

22

クラウド上のサーバの構成例

• 例) tomcatサーバ

Hardware

VMM

Tomcat

JVM

Guest OS 3つの保護レイヤー → オーバヘッド大

23

Application

レイヤーごとの保護機能

• Guest OS上のプロセス間でメモリ等が保護されている • 一方であるVM上のプロセスは他のVM上のプロセスにアクセスすることは不可能

Hardware

VMM

Application

Guest OS

Application Application

Guest OS

24

重複している機能

• 保護機能 •  Guest OS

•  プロセス間 / カーネルの保護 •  VMM

•  VM間の保護

• ハードウェアの抽象化 •  Guest OSが利用するハードウェア

そのものがVMMにより抽象化されたもの

Hardware

VMM

Tomcat

JVM

Guest OS

クラウド上のVMで動作することを前提としたOS を設計すればこれらのオーバヘッドを減らせるのでは?

25

OSv

•  http://osv.io • クラウドでの動作を前提に 適化されたOS • 目標

•  既存のLinux実行ファイル(ELF)が動作可能 •  アプリケーションはLinuxよりも速く動作する •  OSのサイズを可能な限り小さくし，VMの再構成/起動時間を短くする •  新規アプリケーション向けの新しいAPIの提供 •  モダンな言語で作成 (C++11が中心)

26

OSvのデザイン

•  Library OSという考え方 / Unikernels •  対象: x64, aarch64

KVM, Xen, VMWare, VirtualBox, EC2, GCE で動作 •  VMの中で一つのアプリケーションのみを動かす

•  単一メモリ空間 •  forkなし •  VMサイズ: 20MB~

•  小限のハードウェアサポート •  一部の機能は外部のプロジェクトのものを利用

•  ネットワークスタック(TCP/IP) : Free BSD •  Cライブラリヘッダ : musl libc •  ZFS ファイルシステム : Free BSD •  ACPIドライバ : ACPICA project

•  BSD License

27

Unikernels

• Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj Singh, Thomas Gazagnaire, Steven Smith, Steven Hand and Jon Crowcroft Unikernels: Library Operating Systems for the Cloud (ASPLOS’13)

•  Library OS • カーネルは一つのプロセスのみをサポートする

28

対応アプリケーション

•  Java (Open JDK) •  Tomcat •  Cassandra •  Jetty •  Jython •  JRuby •  …

• Ruby • mruby •  lua • memchaced • MySQL • …

29

OSvの特徴

• メモリ空間 • スピンロックの排除 • ネットワークチャネル • スレッドスケジューラ • 新規APIの提供

•  Zero-copy API •  Shrinker API

•  JVM Ballooning

30

メモリ空間

• 単一アドレス空間 / ring 0 (特権レベル0) •  カーネルとアプリケーションでメモリが分かれていない

• 仮想メモリ(MMU)を使用 •  x86_64 のlongmodeでは仮想メモリを使わなければならない •  mmap などのシステムコールに対応するため

• アプリケーションのメモリ保護は言語ランタイム(JVM等)が行う

31

スピンロック

• マルチプロセッサシステムにおいて，カーネル内でロックをかける単純な方法 → 割り込みを禁止にする

• ただしこの場合全ての割り込みが禁止されるので，適していない

　→ スピンロックが使用される

void lock(int *lock) { while (test_and_set(lock) == 1); }

スピンロック例:

32

Lock-holder preemption 問題

• VMMは，仮想CPU(VCPUs)を物理CPU上でスケジューリングして実行している •  VCPU1がロックを保持 •  VMMによるCPUのスケジューリング •  VCPU2がスピンロックでロック待ち → 再びVMMによりVCPU1が実行されるまで待つことになる → Lock-holder Preemption 問題

•  Thomas Friebel and Sebastian Biemueller : “How to Deal with Lock Holder Preemption” Xen Summit North America (2008)

33

Lock-holder preemption 問題の解決策

• 解決策の一つ: lock-free アルゴリズムを使う •  スピンロックを使わない •  アトミックな操作の組み合わせ (compare-and-swap など) •  実装が大変

• 別の方法: VMMがスピンロックを検知したらスケジューリングをおこなう

• OSvでの方法 •  lock-free アルゴリズムによるスピンロックを排除 •  mutexをlock-freeで実装 •  スケジューラをスレッドで動作させず，CPUごとにrun queueを使う

34

ネットワークチャネル

• 従来のTCP/IP: Socketレベル, TCP/IPレベルでロックが発生 • OSv: Van Jacobson’s network channel

http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf

35

スレッドスケジューラの特徴

•  Lock-free • スケジューラは各CPUごとにrun queueを保持

•  次に実行するスレッドを決めるとき，ロックする必要がない

•  run queueの偏りをなくす為に load balancer スレッドを用意

36

スレッドスケジューラの特徴

• あるCPUが別のCPUのスレッドを呼び出す方法 •  N個のCPUに対し，N個のLock-free queueを用意 (合計N^２） •  各CPUは空でないキューを表すビットマスクを持つ •  CPU s が CPU dのスレッドを起こしたいとき,

queue(s,d) にそのスレッドを追加する → CPU d におけるCPU sのビットマスクが有効になる → CPU d のinter-processor interrupt (IPI)が発生

•  CPU d はrescheduleする

37

スレッドスケジューラの特徴

• プリエンプティブなマルチタスクに対応 •  タイマやIPIにより割り込まれる

•  tick がない • スケーラブル　

•  O(lgN) の計算量

• 軽量なコンテキストスイッチ •  アドレス空間が一つなので，ページテーブルを切り替える必要がない •  x86_64のABIではFPUレジスタはcallerが保存することになっているの

で，FPUレジスタの保存をしない

38

新規APIの提供

• 標準的なLinuxのAPI（システムコール）だけでなく，OSvの性能を引き出すAPIを提供する •  LinuxのAPIはマルチプロセス/マルチユーザを前提に設計されている •  OSvではカーネルとユーザスペースが分離されていない •  ページテーブルに直接アクセスできる

• 言語ランタイムが新規APIを使用するように修正することで，アプリケーション性能の向上が見込める

39

新規API : Zero-copy API • 通常のソケットのAPIではカーネル空間のバッファからユーザ空間へのバッファへのコピーが発生

• OSvではこれらのコピーは不要 → Zero-copy API

40

新規API: Shrinker • アプリケーションがOSvにコールバック関数を登録 • システムのメモリが少なくなったときそのコールバック関数が呼ばれる

• コールバック関数がメモリの開放をおこなう • 使用例: キャッシュ容量の動的変更

41

JVM Ballooning

•  JVMは大部分のメモリをヒープから割り当てる •  JVM起動時のパラメータでヒープサイズを指定 • 性能を 大限引き出すために適切なヒープを割り当てたい → JVM Ballooning

• まずJVMのヒープを 初に 大限割り当てる • メモリが足りなくなったらByteArrayの大きな配列を作る → この領域をOSに返却 (unmapping)

• ByteArrayで確保されているのでその部分はGCされない

42

評価結果

43

他の評価結果

•  Ian Briggs, Matt Day, Eric Eide, Yuankai Guo, Peter Marheine Performance Evaluation of OSv for Server Applications (2015)

• DNS および HTTP Serverの評価 • CPU: Xeon E5530 • メモリ: 12GB • VMM: Xen 4.4 • Gigabit Ethernet

44

DNS Server • BIND 9.8.4

45

HTTP Server Response

• OSv: lighttpd1.3.45 •  Linux Server: Apache 2.4.7

46

OSvを扱いやすくするツール: Capstan

• 高速にVMを作成/デプロイするツール (go製) •  マルチプラットフォーム

• Docker(後述)のように手軽に扱える • YAML

47

関連技術との比較

• CoreOS • コンテナ

•  Docker

48

CoreOS

•  http://coreos.com • 軽量にカスタマイズされたLinux Distribution • 後述のDockerと組み合わせて使用されることが多い

•  ただし 近Dockerと決別した

49

コンテナ

• カーネルによるリソースの名前空間の分離 •  ファイルシステム •  ネットワーク •  プロセスID •  共有メモリ

• カーネル自体は共通 • 代表的なもの

•  Free BSD jails (2000~) •  Linux Containers (LXC)

50

コンテナの利点 / 欠点

• 利点 •  起動が高速 •  性能劣化が少ない •  複数の異なるバージョンのアプリケーションが実行しやすい •  インスタンスを複数立ち上げる必要がない

• 欠点 •  ライブマイグレーションができない

•  開発中 •  仮想マシン上でコンテナを使うという手段もある

•  ホストと別種類のOSを利用ができない

51

Docker •  https://www.docker.com • An open platform for distributed applications for

developers and systems •  LXCを手軽に扱えるようにしたもの

•  LXCのリポジトリ •  コマンドラインツール

•  % docker run

• OSvでいうCapstan (CapstanはDockerを参考にしたもの)

•  goで実装 •  マルチプラットフォーム

52

Docker? OSv?

http://osv.io/blog/blog/2014/06/23/containers-hypervisors-part-3/

53

開発者の意見

•  https://plus.google.com/+OsvIo/posts/fgzsepcScTa • Glauber Costa: "I once heard that hypervisors are the

living proof of operating system's incompetence”. The failure of operating systems (LinuxCon Europe 2012) : https://lwn.net/Articles/524952/

• OSはタスクごとにCPUやメモリを分けることができない • ハイパーバイザの分離機能はOSが持つべきでは? → コンテナ

• コンテナはVMより今は速いかもしれないが，将来もそうであるとは限らない •  コンテナの速さの要はリソースの重複の排除 •  OSvも同様のことをしている

54

開発者の意見

• OSvの方が，コンテナよりもより自然な抽象化をおこなっている

• OSvは多くのクラウド上のアプリケーションがVM上で一つだけ動いているという事実に基づいて開発されている •  シンプルなデザイン

55

議論

• Docker (コンテナ) vs OSv (仮想化) •  手間が少ない方か効率の良い方か? •  OSvの方がセキュリティは高いといえる

• どちらが一方を完全に上回っているということはない • Dockerのようにコミュニティが活発化することが

OSv普及の鍵ではないか (Capstan)

• 果たしてそこまで 適化する需要があるのか? •  ハードウェア性能の向上

56