論文購読
(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と呼ばれる仮想化を前提とした単一アプリケーション動作
内容
• 仮想化技術について • OSv登場の背景 • OSv • デザイン • 利点 • 関連技術との比較 • CoreOS • コンテナ • Docker仮想化技術
• 一つのマシンで複数の仮想的なマシンを動かす技術 (その上でOS/アプリケーションを実行) • 1960年代(メインフレーム時代)から研究/利用 • 利点 • ハードウェアリソースの有効活用 • 容易に仮想マシンの一時停止/複製が可能 • 簡単に開発環境を構築 • 動的マイグレーション (仮想マシンを動的に移動) • スナップショット用語
• Host - 仮想化をおこなうマシン • Guest - 仮想的に実行されるマシン. その上で動作するOSをGuest OSという.• Hypervisor / Virtual Machine Monitor (VMM)
- VMを管理する制御プログラム
Type2 VMM
• Host OSのアプリケーションとして動作
• VMWare Workstation, VMWare Fusion, VMware Player
• VirtualBox • Virtual PC • QEMU Hardware Host OS VMM Guest OS Application Guest Application
Type1 VMM
• OSを利用せずハードウェアの上のレイヤーに直接存在 • VMWare ESXi • Xen Hardware VMM Guest OS Guest Application Guest Application Guest OS明確に
Type1 / Type2に分類されないもの
• KVM (Kernel-based Virtual Machine) / bhyve
• いずれもカーネルモジュールとして実装
(KVM: Linux, bhyve: Free BSD)
Hardware Guest Application QEMU OS (Linux Kernel) Guest OS Application
Type1 / Type2 VMM の比較
• Type1 • ユーザから扱いやすい．手軽 • Type2 • ハードウェア性能をいかせる • VPS / クラウドで利用されているのはこちらPopekとGoldbergの仮想化要件
• “Formal requirements for virtualizable third generation
architectures”
Gerald J. Popek, Robert P. Goldberg (1974)
• 仮想化に求められる事 • Equivalence • VMMで動作するプログラムは実マシンで動作する場合と時間の遅れを除い て等価 • Resource Management • VMMが仮想化された資源を完全に管理すること • Efficiency • 大部分の命令は直接実マシンのCPUで実行する
PopekとGoldbergの仮想化要件
• 定理1 CPUのすべてのセンシティブ命令が特権命令であれば仮想 化可能 (十分条件) • 特権命令 • 実行するときにプロセッサがユーザモードならトラップされる命令 • センシティブ命令 • 制御センシティブ命令 • システム資源の構成を変更する命令 • 動作センシティブ命令 • システム資源の構成に依存する命令 (CPUモードの読み取りなど)• x86の命令セット • このままでは仮想化できない
x86の場合
特権命令 センシティブ命令 それ以外• ソフトウェアで命令をシミュレートする • QEMU 全ての命令をソフトウェアで実行 • VMWare センシティブな命令のみを動的に変換して実行
方法
1: バイナリ変換
• Guest OSのカーネルを修正してセンシティブな命令を実行す
る際にVMMを呼び出すようにする
• Xen
方法
3: Intel VT-x (ハードウェア支援)
• 2006年からx86に追加• Guest OSを実行しているときとそうでないときでCPUモードを
(余談) メモリアクセスの効率化
• Guest OS上のプロセスのメモリアクセス手順は， • Guest OSの仮想アドレス • → Guest OSの物理アドレス • → VMMによりHost OS側のアドレスにマッピング • 効率化のためにハードウェア的サポート機能等が存在(Intel EPT / shadow paging)
Hardware VMM
Application
近年の
VMM製品の流れ
• 1998 • VMWare 創立 • x86仮想化 • 2003 • QEMU • 2004 • Xen • 2006 • Intel VT: x86のハードウェア的仮想化サポート • (AWS) • 2007 • KVM • VirtualBox • 2008 • Hyper-V • 2013 • OSvクラウド
/VPSにおけるVirtual Machine
• ユーザはインターネット経由で外部のリソースを利用• ユーザは直接サーバを利用するのではなく，
サーバ上の仮想マシンを利用する
実際にクラウド
/VPS
で利用されている
VMM
• AWS • Xen • さくらのクラウド / さくらVPS • KVM • ニフティクラウド • VMWare • Windows Azure • Hyper-V ベース (推定)クラウド上のサービス構成例
• 一つのOS上では単一アプリケーションのみ動かすことが多い
(HTTP Server, Database, App Server…)
クラウドで実行する
OSに求められる事
• VMの形で提供される • 高速起動 • 省リソース • 高性能 • 自動デプロイ • 自動アップデート • 設定（再構成)が容易であることクラウド上のサーバの構成例
• 例) tomcatサーバ Hardware VMM Tomcat JVM Guest OS 3つの保護レイヤー → オーバヘッド大 Applicationレイヤーごとの保護機能
• Guest OS上のプロセス間でメモリ等が保護されている • 一方であるVM上のプロセスは他のVM上のプロセスにアクセ スすることは不可能 Hardware VMM Application Guest OS Application Application Guest OS重複している機能
• 保護機能 • Guest OS • プロセス間 / カーネルの保護 • VMM • VM間の保護 • ハードウェアの抽象化 • Guest OSが利用するハードウェア そのものがVMMにより抽象化されたもの Hardware VMM Tomcat JVM Guest OS クラウド上のVMで動作することを前提としたOS を設計すればこれらのオーバヘッドを減らせるのでは?OSv
• http://osv.io • クラウドでの動作を前提に最適化されたOS • 目標 • 既存のLinux実行ファイル(ELF)が動作可能 • アプリケーションはLinuxよりも速く動作する • OSのサイズを可能な限り小さくし，VMの再構成/起動時間を短くする • 新規アプリケーション向けの新しいAPIの提供 • モダンな言語で作成 (C++11が中心)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
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
対応アプリケーション
• Java (Open JDK) • Tomcat • Cassandra • Jetty • Jython • JRuby • … • Ruby • mruby • lua • memchaced • MySQL • …OSv
の特徴
• メモリ空間 • スピンロックの排除 • ネットワークチャネル • スレッドスケジューラ • 新規APIの提供 • Zero-copy API • Shrinker API • JVM Ballooning
メモリ空間
• 単一アドレス空間 / ring 0 (特権レベル0) • カーネルとアプリケーションでメモリが分かれていない • 仮想メモリ(MMU)を使用 • x86_64 のlongmodeでは仮想メモリを使わなければならない • mmap などのシステムコールに対応するため • アプリケーションのメモリ保護は言語ランタイム(JVM等)が行うスピンロック
• マルチプロセッサシステムにおいて，カーネル内でロックをか ける単純な方法 → 割り込みを禁止にする • ただしこの場合全ての割り込みが禁止されるので，適していな い → スピンロックが使用されるvoid lock(int *lock) {
while (test_and_set(lock) == 1); }
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)
Lock-holder preemption 問題の解決策
• 解決策の一つ: lock-free アルゴリズムを使う • スピンロックを使わない • アトミックな操作の組み合わせ (compare-and-swap など) • 実装が大変 • 別の方法: VMMがスピンロックを検知したらスケジューリング をおこなう • OSvでの方法 • lock-free アルゴリズムによるスピンロックを排除 • mutexをlock-freeで実装 • スケジューラをスレッドで動作させず，CPUごとにrun queueを使うネットワークチャネル
• 従来のTCP/IP: Socketレベル, TCP/IPレベルでロックが発生
• OSv: Van Jacobson’s network channel
スレッドスケジューラの特徴
• Lock-free• スケジューラは各CPUごとにrun queueを保持
• 次に実行するスレッドを決めるとき，ロックする必要がない
スレッドスケジューラの特徴
• ある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)が発生
スレッドスケジューラの特徴
• プリエンプティブなマルチタスクに対応 • タイマやIPIにより割り込まれる • tick がない • スケーラブル • O(lgN) の計算量 • 軽量なコンテキストスイッチ • アドレス空間が一つなので，ページテーブルを切り替える必要がない • x86_64のABIではFPUレジスタはcallerが保存することになっているの で，FPUレジスタの保存をしない新規
APIの提供
• 標準的なLinuxのAPI（システムコール）だけでなく，OSvの性 能を引き出すAPIを提供する • LinuxのAPIはマルチプロセス/マルチユーザを前提に設計されている • OSvではカーネルとユーザスペースが分離されていない • ページテーブルに直接アクセスできる • 言語ランタイムが新規APIを使用するように修正することで， アプリケーション性能の向上が見込める新規
API : Zero-copy API
• 通常のソケットのAPIではカーネル空間のバッファからユーザ
空間へのバッファへのコピーが発生
• OSvではこれらのコピーは不要
新規
API: Shrinker
• アプリケーションがOSvにコールバック関数を登録 • システムのメモリが少なくなったときそのコールバック関数が 呼ばれる • コールバック関数がメモリの開放をおこなう • 使用例: キャッシュ容量の動的変更JVM Ballooning
• JVMは大部分のメモリをヒープから割り当てる • JVM起動時のパラメータでヒープサイズを指定 • 性能を最大限引き出すために適切なヒープを割り当てたい → JVM Ballooning • まずJVMのヒープを最初に最大限割り当てる • メモリが足りなくなったらByteArrayの大きな配列を作る → この領域をOSに返却 (unmapping) • ByteArrayで確保されているのでその部分はGCされない他の評価結果
• 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
DNS Server
• BIND 9.8.4HTTP Server Response
• OSv: lighttpd1.3.45OSvを扱いやすくするツール: Capstan
• 高速にVMを作成/デプロイするツール (go製)• マルチプラットフォーム
• Docker(後述)のように手軽に扱える
関連技術との比較
• CoreOS• コンテナ
CoreOS
• http://coreos.com
• 軽量にカスタマイズされたLinux Distribution
• 後述のDockerと組み合わせて使用されることが多い
コンテナ
• カーネルによるリソースの名前空間の分離 • ファイルシステム • ネットワーク • プロセスID • 共有メモリ • カーネル自体は共通 • 代表的なもの • Free BSD jails (2000~) • Linux Containers (LXC)コンテナの利点
/ 欠点
• 利点 • 起動が高速 • 性能劣化が少ない • 複数の異なるバージョンのアプリケーションが実行しやすい • インスタンスを複数立ち上げる必要がない • 欠点 • ライブマイグレーションができない • 開発中 • 仮想マシン上でコンテナを使うという手段もある • ホストと別種類のOSを利用ができないDocker
• https://www.docker.com
• An open platform for distributed applications for
developers and systems
• LXCを手軽に扱えるようにしたもの • LXCのリポジトリ • コマンドラインツール • % docker run • OSvでいうCapstan (CapstanはDockerを参考にしたもの) • goで実装 • マルチプラットフォーム
Docker? OSv?
開発者の意見
• 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も同様のことをしている
