次世代のクラウドのためのネストされた仮想化

KVM を使用したネストの概要

クラウド・コンピューティングは、現実に、オンライン・ビジネスのビジネス・モデルおよび開発モデルを変えましたが、現在の IaaS (Infrastructure as a Service) クラウド・モデルは、ソフトウェア開発者にかなりの制約を課しています。それは、開発者が使用しなければならないハイパーバイザーが決まっていることです。仮想マシン・イメージに対する要件がクラウド・ユーザーから選択肢を奪っており、一部のユーザーにとってはクラウドへの移行の障害になっています。けれども今や、このモデルは IBM の研究によるブレイクスルーによって変わろうとしています。「ネストされた仮想化」と呼ばれるこの技術は、より深いソリューション・スタックを可能にし、例えばゲスト仮想マシンをゲスト・ハイパーバイザー上に配置し、そのゲスト・ハイパーバイザーを、クラウドが選択したハイパーバイザー上で実行するといったことを可能にします。この記事では、ネストされた仮想化を支える概念と、この技術がクラウドをどのように改善することになるのかを探ります。

M. Tim Jones, Independent Author, .

M. Tim JonesTim は組み込みファームウェア・アーキテクトであり、著書には『Artificial Intelligence: A Systems Approach』(現在は第 2 版)、『GNU/Linux Application Programming』(第 2 版)、『AI Application Programming』(第 2 版)、『BSD Sockets Programming from a Multilanguage Perspective』があります。彼の技術的な経歴は、静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで多岐にわたっています。彼はコロラド州 Longmont 在住のソフトウェア・アーキテクトであり、著作者でもあります。



2012年 9月 20日

10 年前、「クラウド」に関するトピックが初めて紹介されていた頃、そのトピックの焦点はパブリック・インフラストラクチャー内の単純なサービスに当てられていました。けれども技術には進化が付き物です。これらのサービスも、その使用モデルとともに進化しています。同じように、コモディティー・ハードウェアでの仮想化も、導入された時点で焦点とされていたのは極めて単純な使用モデルでしたが、その可能性が理解されるようになるにつれて使用モデルも進化してきました。

さまざまなハードウェアを提供する一連のメーカーも、仮想化とクラウドの進化を目の当たりにすると、それぞれの製品を進化させ、仮想化およびクラウドのニーズをより効果的にサポートするようにしました。初期の x86 プロセッサーは仮想化には適していませんでしたが、仮想化及びプロセッサーの新しい使用モデルに対応するようにプロセッサーの内部構造を設計することで、プラットフォームの仮想化により適した環境を作り出しました。

まずは、クラウドのアーキテクチャーとこれに伴ういくつかの制約事項について簡単に紹介するところから始めます。

パブリック・クラウドのアーキテクチャー

パブリック・クラウド (パブリック環境で利用可能な仮想インフラストラクチャー) で重点が置かれているのは、マルチテナントでの使用を目的にハイパーバイザーが作り出す仮想サーバーを単純に割り振ることです。ハイパーバイザーがマルチプレクサーとして機能して、1 つの物理プラットフォームを複数のユーザーで共有できるようにします。ハイパーバイザーには、KVM (Kernel Virtual Machine) から Xen に至るまで、多数の製品が揃っています。

完全仮想化と準仮想化

ハイパーバイザーの形態には、透過的な完全仮想化ハイパーバイザーから半透過的な準仮想化ハイパーバイザーまで、複数の形態があります。どの形態が最適であるかについての議論は今でも続いていますが、興味深い点は、ほとんどのハイパーバイザーがゲスト・ツールの追加という方法で準仮想化をサポートすることです。ゲスト・ツールは、ゲスト・オペレーティング・システムの I/O 処理の効率を高めるために、ゲスト・オペレーティング・システムの内部にインストールされるため、ほとんどのハイパーバイザーは完全仮想化の機能も準仮想化の機能も提供することとなり、完全仮想化と準仮想化の違いはそれほど重要でなくなってきています。

仮想インフラストラクチャーには、ある特定の仮想環境に依存するという 1 つの制約があります。例えば、Amazon EC2 (Amazon Elastic Compute Cloud) が依存するのは Xen 仮想化です。Amazon EC2 では、そのインフラストラクチャー内で実行されるどのゲストも、AMI (Amazon Machine Image) フォーマットと呼ばれる特定の方法でパッケージ化されることを想定しています。AMI は Amazon EC2 内でのデプロイメントの基本単位であり、(オペレーティング・システムとアプリケーションのセットに基づいて) 事前に構成された数多くのタイプのいずれかにすることも、さらに手を加えてカスタムで作成することもできます。

クラウド・ユーザーにとっての障害となり得るのは、(メタデータと仮想ディスク・フォーマットからなる) この仮想マシン (VM) フォーマットです。このフォーマットとターゲットのハイパーバイザーの選択への依存性は、VM をプライベート・インフラストラクチャーからパブリック・インフラストラクチャーにマイグレーションするにしても、パブリック・インフラストラクチャー間でマイグレーションするにしても支障となります。

ネストされた仮想化のサポートは、クラウド・ユーザーに新しい抽象化をもたらします。クラウドがハイパーバイザー上で別のハイパーバイザーを仮想化できるようにサポートしていれば、VM フォーマットはクラウドには無関係となり、唯一の依存性はゲスト・ハイパーバイザー自身のフォーマットのみとなります。このような変化は、限られた 1 つの形態ですべてに対応していた第 1 世代のクラウドを、ユーザーがより大きな自由を持てる極めて柔軟な仮想インフラストラクチャーに進化させます。図 1 に、VM だけでなくハイパーバイザーに対応した仮想プラットフォームのコンテキストにおける、この新しい抽象化を図説します。この図では、仮想化の各レベルに付けた名前に注意してください。L0 はベアメタル・ハイパーバイザー、L1 はゲスト・ハイパーバイザー、L2 はゲスト VM を表します。

図 1. 従来のハイパーバイザーとネストされたハイパーバイザーの大まかな比較
従来のハイパーバイザーとネストされたハイパーバイザーの大まかな比較

この変化は、新しいインフラストラクチャー用に VM をパッケージ化することを可能にするだけではありません。VM の一式をそれぞれのハイパーバイザーと一緒にパッケージ化することも可能にします。そうなれば、プライベート・クラウド・インフラストラクチャーのユーザーは、今までよりも簡単にパブリック・クラウド・インフラストラクチャーに機能を (静的にも動的にも) マイグレーションできるようになります。図 2 にこの変化と、プライベート・インフラストラクチャーのハイパーバイザーが、ネストされたクラウドのゲスト・ハイパーバイザーに変換される様子を示します。

図 2. ネストされたクラウドのゲスト・ハイパーバイザーとホスト・ハイパーバイザー
ネストされたクラウドのゲスト・ハイパーバイザーとホスト・ハイパーバイザーを示す図

次世代のクラウド: ネストされた仮想化の紹介

ネストされた仮想化は新しい概念ではなく、これまでも IBM z/VM ハイパーバイザーに実装されてきました。IBM System z オペレーティング・システムは、それ自体がハイパーバイザーであり、プロセッサーとメモリーを仮想化するだけでなく、ストレージやネットワーク・ハードウェア・アシストなどのリソースも仮想化します。z/VM ハイパーバイザーは、パフォーマンスをハードウェアで支援する実際のネストされた仮想化の最初の実装を表します。さらに、z/VM ハイパーバイザーがサポートする VM のネストの深さには制限がありません (ただし当然、これにはオーバーヘッドの追加を伴います)。最近では、x86 プラットフォームは、進化を続けるネストされた仮想化の使用モデルに基づいて仮想化をサポートする方向へと向かっています。

ネストされた仮想化をコモディティー・ハードウェアで最初に実装したハイパーバイザーは、KVM です。この KVM に対する機能の追加は、IBM の Turtles プロジェクトで行われました。これにより、複数のハイパーバイザーを変更することなくそのまま KVM (これ自体が Linux カーネルを調整したハイパーバイザーです) 上で実行できるようになりました。Turtles プロジェクトを立ち上げる動機の一端となったのは、IBM が IBM System p および System z オペレーティング・システムに対して開発した方法で、コモディティー・ハードウェアを使用したいという願望です。このモデルでは、サーバーが組み込みハイパーバイザーを実行して、そのハイパーバイザー上でユーザーが任意のハイパーバイザーを実行することができます。この手法は仮想化コミュニティーの注目を集め、現在ではこれらの機能 (KVM に対する変更) がメインラインの Linux カーネルに統合されています。


ネストされた仮想化のアーキテクチャー

ネストされた仮想化は、これまで見たことのない独特の問題を引き起こします。このセクションでは、これらの問題のいくつかを取り上げ、KVM ではどのように対処されているかを探ります。

プロセッサーの仮想化

プロセッサー・アーキテクチャーにおける現在の仮想化サポートの欠点となるのは、ネストされた仮想化では二重の仮想化 (単一のハイパーバイザーの上に積み上げられた VM) に重点が置かれる点です。Turtles はプロセッサーの仮想化サポートを、単純な多重化によって拡張します。図 1 に示されている 3 つのレベル を思い出してください (ホスト・ハイパーバイザーとしての L0、ゲスト・ハイパーバイザーとしての L1、ゲスト VM としての L2)。最近のプロセッサーでは、L0 と L1 については効率的に処理されますが、L2 では効率性が失われてしまいます。この厳格なスタック構成を維持する代わりに、Turtles では L1 でエンティティーを多重化します。これは実質的に、ホスト・ハイパーバイザーが L1 でゲスト・ハイパーバイザーとゲスト VM を多重化できるようにするためです。したがって、仮想化命令を仮想化するのではなく、プロセッサー内に用意されているハードウェア・アシストを効率的に使用して 3 つの層をサポートします (図 3 を参照)。

図 3. ホスト (L0) ハイパーバイザーでのゲストの多重化
ホスト (L0) ハイパーバイザーでのゲストの多重化を示す図

けれども、障害となっていたのは、プロセッサーの仮想化アセットを利用することだけではありませんでした。これ以外の問題と、KVM 内でのその解決策について、ここからは探ります。

ネストされた仮想化がこの領域にもたらす興味深い問題はいくつかあります。従来の仮想化は命令セットにある程度対処し、特定の命令を直接プロセッサー上で実行し、その他の命令はトラップという手段でエミュレートすることに注意してください。ネストされた仮想化では、一部の命令は引き続き直接ハードウェア上で実行され、その他の命令はトラップされますが、トラップされた命令は、複数の層のいずれかで管理されます (これには、層間で遷移する際のオーバーヘッドを伴います)。

Turtles プロジェクトで明らかにされたとおり、このセットアップは、仮想化のプロセッサー実装における長所と短所を浮き彫りにします。その 1 つが VM 制御構造 (VMCS) の管理に関するものです。Intel の実装では、これらの構造に対する読み取りや書き込みには、ネストされたスタックを構成する層間で何回もの出入り (遷移) を要求する特権命令が必要になります。層間での遷移がもたらすオーバーヘッドは、パフォーマンスの損失として現われます。一方、AMD の実装では定期的なメモリーの読み取りと書き込みによって VMCS を管理します。したがって、ゲスト・ハイパーバイザー (L1) がゲスト VM の VMCS (L2) を変更する際に、ホスト・ハイパーバイザー (L0) が介入する必要はありません。

プロセッサーのサポートなしでネストする Turtles の多重化手法は、層間での遷移も最小限にします。仮想化での遷移は、VM を出入りするための特殊な命令 (VMexitVMentry) によって発生しますが、これにはコストがかかります。一部の VMexit には L1 ハイパーバイザーの介入が必要となりますが、他の条件 (外部割り込みなど) は、L0 だけで処理されます。L2 から L0 そして L1 への遷移を最小限にすることによって、パフォーマンスが改善される結果となります。

MMU およびメモリーの仮想化

最近のプロセッサーではページ・テーブルが支援されるようになっていますが、それ以前は、ハイパーバイザーがメモリー管理ユニット (MMU) の振る舞いをエミュレートしていました。ゲスト VM はゲスト・ページ・テーブルを作成して、ゲスト仮想アドレスからゲスト物理アドレスへの変換をサポートしていました。ハイパーバイザーは、ゲスト物理アドレスをホスト物理アドレスに変換するためのシャドー・ページ・テーブルを保持していました。ハイパーバイザーが CPU 内の物理テーブルを管理するためには、このすべての処理で、ページ・テーブルの変更をトラップする必要がありました。

Intel と AMD がこの問題を解決するために採った方法は、2 次元ページ・テーブルの追加です。Intel ではこのテーブルを EPT (Extended Page Table) と呼び、AMD では NPT (Nested Page Table) と呼んでいます。2 次元ページ・テーブルの支援により、ゲスト仮想アドレスからゲスト物理アドレスへの変換は従来のページ・テーブルでは引き続きサポートする一方、ゲスト物理アドレスからホスト物理アドレスへの変換には、2 次ページ・テーブルを使用することができます。

Turtles プロジェクトでは、ネストに対処する 3 つのモデルを導入しました。3 つのうち、最も効率性の低いモデルでは、シャドー・ページ・テーブル上でシャドー・ページ・テーブルを使用します。この方法が使用されるのは、ゲスト・ハイパーバイザーとホスト・ハイパーバイザーの両方がシャドー・ページ・テーブルを保持する場合に、ハードウェア・アシストを利用できないときだけです。2 つ目のモデルでは、2 次元ページ・テーブル上でシャドー・ページ・テーブルを使用し、これらのテーブルを L0 で管理します。効率性は高くなりますが、ゲスト VM でのページ・フォルトにより、複数の L1 Exit とオーバーヘッドが発生します。3 つ目のモデルは、L1 ハイパーバイザーの 2 次元ページ・テーブルを仮想化するというものです。L1 の 2 次ページ・テーブルをエミュレートすることにより (この場合、L0 は物理EPT/NPT を使用します)、L1 Exit もオーバーヘッドも少なくなります。Turtles プロジェクトによるこの革新は、マルチディメンショナル・ページングと呼ばれます。

I/O デバイスの仮想化

I/O デバイスの仮想化は、仮想化で最もコストのかかる側面の 1 つです。(QEMU が行う) エミュレーションには最も大きなコストが伴いますが、準仮想化のような (ゲストに I/O を認識させてハイパーバイザーと I/O を調整する) 手法によって、全体的なパフォーマンスを改善することができます。最も効率的な方式は、AMD の IOMMU (I/O Memory Management Unit: I/O メモリー管理ユニット) などのハードウェア・アシストを利用して、(DMA (Direct Memory Access: 直接メモリー・アクセス) などの操作に対して) 透過的にゲスト物理アドレスをホスト物理アドレスに変換することです。

Turtles プロジェクトでは、L0 で使用可能な物理デバイスに対して L2 ゲストが直接アクセスできるようにすることによって、パフォーマンスの改善を実現しました。これは、L0 ホスト・ハイパーバイザーが、L1 ゲスト・ハイパーバイザーの IOMMU をエミュレートするという手法です。この手法は、ゲスト Exit を最小限にすることから、オーバーヘッドの削減とパフォーマンスの改善という結果をもたらします。


ネストによるパフォーマンス

KVM 内でのネストに伴うオーバーヘッドは、使用モデルによっては無視できないものになることがわかっています。VMexit を実行するワークロード (外部割り込み処理など) は最悪の障害物になりがちですが、KVM 内の最適化により、オーバーヘッドは 6% から 14% の範囲内に収まります。ネストされた仮想化が提供する新しい機能を考えれば、このオーバーヘッドが妥当であることは確かです。今後、プロセッサーのアーキテクチャーにおける進歩によって、このオーバーヘッドはさらに改善されるでしょう。


ネストされた仮想化の使用例

現在、多くのハイパーバイザーがネストされた仮想化をサポートしていますが、その効率性は現状よりも改善できるはずです。Linux KVM は、最近の仮想化対応プロセッサー上でのネストをサポートしています。Xen ハイパーバイザーもネストされた仮想化をサポートするように変更されたことから、オープンソース・コミュニティーはこのネストされた仮想化とその潜在的な使用モデルを採用する方向へと迅速に対応を進めています。

本番環境へ導入するという観点からは、このネストされた仮想化はまだ開発の初期段階にあると言えるでしょう。これに加え、ネストによって仮想化をスケーリングするということは、物理ホストへの負荷が大きくなることを意味するため、さらに有能なプロセッサーを備えたサーバーを使用しなければなりません。

また、ネストされた仮想化は、他のコンテキストでも実行できることに注目してください。最近の OpenStack の記事では、VirtualBox をホスト・ハイパーバイザーとして使用し、QEMU (エミュレーションを提供) をゲストとして使用するネストの実例を紹介しました。これは最も効率的な構成とは言えませんが、その記事では、それほど高性能ではないハードウェアで基本機能を実証しています。詳細については、「参考文献」を参照してください。


その他のアプリケーション

将来的には、デスクトップ PC やサーバー上のファームウェアの標準構成要素として、ハイパーバイザーが組み込まれることが当たり前になるかもしれません。この使用モデルは、組み込みハイパーバイザーがオペレーティング・システムを (VM として) サポートしたり、ユーザーが選ぶ任意のハイパーバイザーをサポートしたりすることが可能になることを意味します。

こうした方法でハイパーバイザーを使用するユーザーは、新しいセキュリティー・モデルもサポートすることになります (ハイパーバイザーは、ユーザーやハッカーのコードの下層にあるため)。この概念は当初、不正な目的で使用されていました。「Blue Pill」という rootkit は、Joanna Rutkowska 氏がセキュリティー上の弱点を突いたツールとして開発したもので、実行中のオペレーティング・システム・インスタンスの下層にシン・ハイパーバイザーを挿入する手段です。Rutkowska 氏はまた、実行中のオペレーティング・システムの下層に「Blue Pill」が挿入されているかどうかを検出するために使用できる「Red Pill」というツールも開発しました。


さらに詳しく調べてください

Turtles プロジェクトは、ハイパーバイザーのネストされた仮想化が可能であることだけでなく、多くの場合、KVM ハイパーバイザーをテスト・ベッドとして使用すると効率的であることも証明しました。KVM でのネストされた仮想化の取り組みは続けられ、今ではハイパーバイザー内にネストして、複数のゲスト・ハイパーバイザーの同時実行をサポートする実装のモデルとなっています。プロセッサー・アーキテクチャーがこれらの新しい要件を満たすようになった暁には、次世代のクラウド製品におけるエンタープライズ・サーバーだけでなく、コモディティー・サーバーやデスクトップ PC においても、ネストされた仮想化が一般的な使用モデルとなるはずです。

参考文献

学ぶために

  • The Turtles Project: Design and Implementation of Nested Virtualization」を読むと、IBM Research Haifa と IBM Linux Technology Center がネストされた仮想化をサポートするように KVM を変更して最適化した方法を理解する上で参考となります。Turtles に関する OSDI プレゼンテーションも興味深い情報です。
  • R. P. Goldberg 氏による「Architecture of Virtual Machines」は、再帰的 VM をいち早く定義している論文です。この文書はかなり古いものですが (1973年に公開)、一読する価値があります。
  • Blue Pill と Red Pill は、2006年に Joanna Rutkowska 氏によって紹介されました。Blue Pill は、軽量のハイパーバイザーをルートキットとして実行中のオペレーティング・システムの下に挿入するマルウェア手法です。Blue Pill のソース・コードが公にリリースされたことはありません。
  • Linux KVM は、メインラインの Linux カーネルに統合された最初のハイパーバイザーです。KVM は効率的で本番品質のハイパーバイザーであり、仮想化コミュニティーで広く使用されています。KVM の詳細を学ぶには、「Linux カーネル仮想マシンを探る」(M. Tim Jones著、developerWorks、2007年4月) を読んでください。
  • Linux カーネルの柔軟性を示すもう 1 つの具体例として、KVM に応じた変更は、Linux をデスクトップおよびサーバー・カーネルから、完全な機能を備えたハイパーバイザーに変身させます。詳しくは、「Linux ハイパーバイザーの徹底研究」(M. Tim Jones 著、developerWorks、2009年5月) を読んでください。
  • OpenStack は、ネストされた仮想化を利用する IaaS クラウド・オファリングです。記事「Cloud computing and storage with OpenStack」では、エミュレーションによるネストされた仮想化 (VirtualBox で QEMU を実行) を具体的に説明しています。
  • developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  • Twitter で developerWorks をフォローしてください。また、この記事の著者である M. Tim Jones を Twitter でフォローすることもできます。
  • developerWorks のDemos で、初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

  • IBM SmarterCloud Enterprise に用意された製品イメージを調べてください。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=835672
ArticleTitle=次世代のクラウドのためのネストされた仮想化
publish-date=09202012