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

Transcription

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

2 2 中心に紹介する論文 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 presentation/kivity OSv と呼ばれる仮想化を前提とした単一アプリケーション動作に最適化された OS について

3 3 内容 仮想化技術について OSv 登場の背景 OSv デザイン 利点 関連技術との比較 CoreOS コンテナ Docker

4 4 仮想化技術 一つのマシンで複数の仮想的なマシンを動かす技術 ( その上で OS/ アプリケーションを実行 ) 1960 年代 ( メインフレーム時代 ) から研究 / 利用 利点 ハードウェアリソースの有効活用 容易に仮想マシンの一時停止 / 複製が可能 簡単に開発環境を構築 動的マイグレーション ( 仮想マシンを動的に移動 ) スナップショット

5 5 用語 Host - 仮想化をおこなうマシン Guest - 仮想的に実行されるマシン. その上で動作する OS を Guest OS という. Hypervisor / Virtual Machine Monitor (VMM) - VM を管理する制御プログラム VMM には大きく分けて Type1 と Type2 が存在

6 6 Type2 VMM Host OS のアプリケーションとして動作 VMWare Workstation, VMWare Fusion, VMware Player VirtualBox Virtual PC QEMU Guest Application Guest OS Application VMM Host OS Hardware

7 7 Type1 VMM OS を利用せずハードウェアの上のレイヤーに直接存在 VMWare ESXi Xen Guest Application Guest OS Guest Application Guest OS VMM Hardware

8 8 明確に Type1 / Type2 に分類されないもの KVM (Kernel-based Virtual Machine) / bhyve いずれもカーネルモジュールとして実装 (KVM: Linux, bhyve: Free BSD) Guest Application Guest OS Application QEMU OS (Linux Kernel) Hardware

9 9 Type1 / Type2 VMM の比較 Type1 ユーザから扱いやすい. 手軽 Type2 ハードウェア性能をいかせる VPS / クラウドで利用されているのはこちら

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

11 11 Popek と Goldberg の仮想化要件 Formal requirements for virtualizable third generation architectures Gerald J. Popek, Robert P. Goldberg (1974) 仮想化に求められる事 Equivalence VMM で動作するプログラムは実マシンで動作する場合と時間の遅れを除いて等価 Resource Management VMM が仮想化された資源を完全に管理すること Efficiency 大部分の命令は直接実マシンの CPU で実行する

12 12 Popek と Goldberg の仮想化要件 定理 1 CPU のすべてのセンシティブ命令が特権命令であれば仮想化可能 ( 十分条件 ) 特権命令 実行するときにプロセッサがユーザモードならトラップされる命令 センシティブ命令 制御センシティブ命令 システム資源の構成を変更する命令 動作センシティブ命令 システム資源の構成に依存する命令 (CPU モードの読み取りなど )

13 13 x86 の場合 x86 の命令セット 特権命令 それ以外 センシティブ命令 このままでは仮想化できない

14 14 方法 1: バイナリ変換 ソフトウェアで命令をシミュレートする QEMU 全ての命令をソフトウェアで実行 VMWare センシティブな命令のみを動的に変換して実行

15 15 方法 2: 準仮想化 Guest OS のカーネルを修正してセンシティブな命令を実行する際に VMM を呼び出すようにする Xen

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

17 17 ( 余談 ) メモリアクセスの効率化 Guest OS 上のプロセスのメモリアクセス手順は, Guest OS の仮想アドレス Guest OS の物理アドレス VMM により Host OS 側のアドレスにマッピング 効率化のためにハードウェア的サポート機能等が存在 (Intel EPT / shadow paging) Application Guest OS VMM Hardware

18 18 近年の VMM 製品の流れ 1998 VMWare 創立 x86 仮想化 2003 QEMU 2004 Xen 2006 Intel VT: x86 のハードウェア的仮想化サポート (AWS) 2007 KVM VirtualBox 2008 Hyper-V 2013 OSv

19 19 クラウド /VPS における Virtual Machine ユーザはインターネット経由で外部のリソースを利用 ユーザは直接サーバを利用するのではなく, サーバ上の仮想マシンを利用する Internet

20 20 実際にクラウド /VPS で利用されている VMM AWS Xen さくらのクラウド / さくら VPS KVM ニフティクラウド VMWare Windows Azure Hyper-V ベース ( 推定 )

21 21 クラウド上のサービス構成例 一つの OS 上では単一アプリケーションのみ動かすことが多い (HTTP Server, Database, App Server )

22 22 クラウドで実行する OS に求められる事 VMの形で提供される 高速起動 省リソース 高性能 自動デプロイ 自動アップデート 設定 ( 再構成 ) が容易であること

23 23 クラウド上のサーバの構成例 例 ) tomcat サーバ Application Tomcat JVM Guest OS VMM 3 つの保護レイヤー オーバヘッド大 Hardware

24 24 レイヤーごとの保護機能 Guest OS 上のプロセス間でメモリ等が保護されている 一方である VM 上のプロセスは他の VM 上のプロセスにアクセスすることは不可能 Application Application Application Guest OS Guest OS VMM Hardware

25 25 重複している機能 保護機能 Guest OS プロセス間 / カーネルの保護 VMM VM 間の保護 ハードウェアの抽象化 Guest OS が利用するハードウェアそのものが VMM により抽象化されたもの Tomcat JVM Guest OS VMM Hardware クラウド上の VM で動作することを前提とした OS を設計すればこれらのオーバヘッドを減らせるのでは?

26 26 OSv クラウドでの動作を前提に最適化されたOS 目標 既存のLinux 実行ファイル (ELF) が動作可能 アプリケーションはLinuxよりも速く動作する OSのサイズを可能な限り小さくし,VMの再構成/ 起動時間を短くする 新規アプリケーション向けの新しいAPIの提供 モダンな言語で作成 (C++11が中心)

27 27 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

28 28 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 カーネルは一つのプロセスのみをサポートする

29 29 対応アプリケーション Java (Open JDK) Tomcat Cassandra Jetty Jython JRuby Ruby mruby lua memchaced MySQL

30 30 OSv の特徴 メモリ空間 スピンロックの排除 ネットワークチャネル スレッドスケジューラ 新規 API の提供 Zero-copy API Shrinker API JVM Ballooning

31 31 メモリ空間 単一アドレス空間 / ring 0 ( 特権レベル 0) カーネルとアプリケーションでメモリが分かれていない 仮想メモリ (MMU) を使用 x86_64 の longmode では仮想メモリを使わなければならない mmap などのシステムコールに対応するため アプリケーションのメモリ保護は言語ランタイム (JVM 等 ) が行う

32 32 スピンロック スピンロック例 : void lock(int *lock) { while (test_and_set(lock) == 1); } マルチプロセッサシステムにおいて, カーネル内でロックをかける単純な方法 割り込みを禁止にする ただしこの場合全ての割り込みが禁止されるので, 適していない スピンロックが使用される

33 33 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)

34 34 Lock-holder preemption 問題の解決策 解決策の一つ : lock-free アルゴリズムを使う スピンロックを使わない アトミックな操作の組み合わせ (compare-and-swap など ) 実装が大変 別の方法 : VMM がスピンロックを検知したらスケジューリングをおこなう OSv での方法 lock-free アルゴリズムによるスピンロックを排除 mutexをlock-freeで実装 スケジューラをスレッドで動作させず,CPUごとにrun queueを使う

35 35 ネットワークチャネル 従来の TCP/IP: Socket レベル, TCP/IP レベルでロックが発生 OSv: Van Jacobson s network channel

36 36 スレッドスケジューラの特徴 Lock-free スケジューラは各 CPUごとにrun queueを保持 次に実行するスレッドを決めるとき, ロックする必要がない run queue の偏りをなくす為に load balancer スレッドを用意

37 37 スレッドスケジューラの特徴 ある CPU が別の CPU のスレッドを呼び出す方法 N 個の CPU に対し,N 個の Lock-free queue を用意 ( 合計 N^2) 各 CPU は空でないキューを表すビットマスクを持つ CPU s が CPU d のスレッドを起こしたいとき, queue(s,d) にそのスレッドを追加する CPU d における CPU s のビットマスクが有効になる CPU d の inter-processor interrupt (IPI) が発生 CPU d は reschedule する

38 38 スレッドスケジューラの特徴 プリエンプティブなマルチタスクに対応 タイマや IPI により割り込まれる tick がない スケーラブル O(lgN) の計算量 軽量なコンテキストスイッチ アドレス空間が一つなので, ページテーブルを切り替える必要がない x86_64 の ABI では FPU レジスタは caller が保存することになっているので,FPU レジスタの保存をしない

39 39 新規 API の提供 標準的な Linux の API( システムコール ) だけでなく,OSv の性能を引き出す API を提供する Linux の API はマルチプロセス / マルチユーザを前提に設計されている OSv ではカーネルとユーザスペースが分離されていない ページテーブルに直接アクセスできる 言語ランタイムが新規 API を使用するように修正することで, アプリケーション性能の向上が見込める

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

41 41 新規 API: Shrinker アプリケーションが OSv にコールバック関数を登録 システムのメモリが少なくなったときそのコールバック関数が呼ばれる コールバック関数がメモリの開放をおこなう 使用例 : キャッシュ容量の動的変更

42 42 JVM Ballooning JVM は大部分のメモリをヒープから割り当てる JVM 起動時のパラメータでヒープサイズを指定 性能を最大限引き出すために適切なヒープを割り当てたい JVM Ballooning まず JVM のヒープを最初に最大限割り当てる メモリが足りなくなったら ByteArray の大きな配列を作る この領域を OS に返却 (unmapping) ByteArray で確保されているのでその部分は GC されない

43 評価結果 43

44 44 他の評価結果 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

45 45 DNS Server BIND 9.8.4

46 46 HTTP Server Response OSv: lighttpd Linux Server: Apache 2.4.7

47 47 OSv を扱いやすくするツール : Capstan 高速に VM を作成 / デプロイするツール (go 製 ) マルチプラットフォーム Docker( 後述 ) のように手軽に扱える YAML

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

49 49 CoreOS 軽量にカスタマイズされたLinux Distribution 後述のDockerと組み合わせて使用されることが多い ただし最近 Docker と決別した

50 50 コンテナ カーネルによるリソースの名前空間の分離 ファイルシステム ネットワーク プロセス ID 共有メモリ カーネル自体は共通 代表的なもの Free BSD jails (2000~) Linux Containers (LXC)

51 51 コンテナの利点 / 欠点 利点 起動が高速 性能劣化が少ない 複数の異なるバージョンのアプリケーションが実行しやすい インスタンスを複数立ち上げる必要がない 欠点 ライブマイグレーションができない 開発中 仮想マシン上でコンテナを使うという手段もある ホストと別種類のOSを利用ができない

52 52 Docker An open platform for distributed applications for developers and systems LXC を手軽に扱えるようにしたもの LXC のリポジトリ コマンドラインツール % docker run OSv でいう Capstan (Capstan は Docker を参考にしたもの ) go で実装 マルチプラットフォーム

53 53 Docker? OSv?

54 54 開発者の意見 Glauber Costa: "I once heard that hypervisors are the living proof of operating system's incompetence. The failure of operating systems (LinuxCon Europe 2012) : OS はタスクごとに CPU やメモリを分けることができない ハイパーバイザの分離機能は OS が持つべきでは? コンテナ コンテナは VM より今は速いかもしれないが, 将来もそうであるとは限らない コンテナの速さの要はリソースの重複の排除 OSv も同様のことをしている

55 55 開発者の意見 OSv の方が, コンテナよりもより自然な抽象化をおこなっている OSv は多くのクラウド上のアプリケーションが VM 上で一つだけ動いているという事実に基づいて開発されている シンプルなデザイン

56 56 議論 Docker ( コンテナ ) vs OSv ( 仮想化 ) 手間が少ない方か効率の良い方か? OSv の方がセキュリティは高いといえる どちらが一方を完全に上回っているということはない Docker のようにコミュニティが活発化することが OSv 普及の鍵ではないか (Capstan) 果たしてそこまで最適化する需要があるのか? ハードウェア性能の向上