クラウド コンピューティング: 仮想化の種類
仮想化には、いくつかのアプローチ (種類) があり、それぞれ適している状況が異なります。
Kai Hwang、Jack Dongarra、Geoffrey Fox
出典: 『Distributed and Cloud Computing: From Parallel Processing to the Internet of Things』(Syngress、2011 年)
概して、仮想マシン (VM) アーキテクチャには、ハイパーバイザー、ホスト ベースの仮想化、および準仮想化という 3 つの種類があります。これらの種類は、仮想化層の位置によって区別されています。ハイパーバイザーは、仮想マシン モニター (VMM) と呼ばれることもあります。
ハイパーバイザーのアーキテクチャ
ハイパーバイザーでは、CPU、メモリ、ディスク、ネットワーク インターフェイスなどのベアメタル デバイスによるハードウェア レベルの仮想化がサポートされています。ハイパーバイザー ソフトウェアは、物理ハードウェアと OS の間に直接存在します。この仮想化層は、VMM またはハイパーバイザーと呼ばれます。
ハイパーバイザーでは、ゲスト OS とアプリケーションに対してハイパーコールを行います。ハイパーバイザーは、Microsoft Hyper-V などのマイクロカーネル アーキテクチャの形を取ることもあれば、VMware ESX などのモノリシック ハイパーバイザー アーキテクチャの形を取ることもあります。
マイクロカーネル ハイパーバイザーには、基本的で不変的な機能 (物理メモリの管理、プロセッサのスケジューリングなど) のみが実装されており、デバイス ドライバーやその他の可変的なコンポーネントは実装されていません。一方、モノリシック ハイパーバイザーには、デバイス ドライバーの機能も含め、前述の機能がすべて実装されています。
このため、マイクロカーネル ハイパーバイザーのハイパーバイザー コードのサイズは、モノリシック ハイパーバイザーのコードよりも小さくなります。基本的にハイパーバイザーは、物理デバイスを展開済みの VM で使用する専用の仮想リソースに変換できる必要があります。
Xen のアーキテクチャ
Xen は、英国ケンブリッジ大学が開発したオープンソースのハイパーバイザー プログラムです。Xen システムの中核となるコンポーネントは、ハイパーバイザー、カーネル、およびアプリケーションで、この 3 つのコンポーネントの構成が重要になります。
Xen は、ポリシーとメカニズムを切り離すマイクロカーネル ハイパーバイザーです。Xen ハイパーバイザーにすべてのメカニズムが実装され、ポリシーは Domain 0 で処理されます。ネイティブに提供されるデバイス ドライバーはありません。Xen ハイパーバイザーでは、ゲスト OS が物理デバイスに直接アクセスするためのメカニズムのみが提供されます。
そのため、Xen ハイパーバイザーのサイズはかなり小さく保たれています。Xen では、ハードウェアと OS の間に位置する仮想環境を提供します。多くのベンダーが商用の Xen ハイパーバイザーを開発中で、Citrix XenServer や Oracle VM は、その一例です。
他の仮想化システムと同様に、ハイパーバイザー上では、多くのゲスト OS を実行できます。ただし、すべてのゲスト OS が同等に作成されているわけではなく、1 つのゲスト OS が他のゲスト OS を制御しています。制御機能を持つゲスト OS は Domain 0 と呼ばれ、その他のゲスト OS は Domain U と呼ばれます。Domain 0 は、Xen の特権があるゲスト OS です。Domain 0 は、使用可能なファイル システム ドライバーがない Xen の起動時に、最初に読み込まれます。Domain 0 は、ハードウェアに直接アクセスして、デバイスを管理するように設計されています。したがって、Domain 0 の役割の 1 つは、ゲスト ドメイン (Domain U ドメイン) にハードウェア リソースを割り当ててマッピングすることです。
たとえば、Xen は Linux を基盤としており、セキュリティ レベルは C2 です。Xen の管理 VM は Domain 0 と呼ばれ、同じホストに実装されている他の VM を管理する特権を持っています。Domain 0 が危険にさらされると、ハッカーがシステム全体を制御することが可能になります。
したがって、VM システムでは、Domain 0 のセキュリティを強化するセキュリティ ポリシーが必要です。VMM として機能する Domain 0 により、ユーザーがファイルの操作と同じくらい簡単に、VM の作成、コピー、保存、読み取り、変更、共有、移行、およびロールバックを実行できます。ところが、これが原因で、ソフトウェア ライフサイクルとデータの有効期間中にセキュリティの問題が発生します。
従来は、コンピューターの有効期間は直線的に考えることができました。現在、コンピューターの状態は、ソフトウェアの実行に従って単調に進行する点で考える必要があります。この期間に、構成の変更、ソフトウェアのインストール、更新プログラムの適用を行います。
このような環境では、VM の状態は "木" と似ていると言えます。どの時点でも N 個の異なる枝に実行を分岐することが可能で、複数の VM のインスタンスが、この木のあらゆる位置に、いつでも存在することが可能です。VM では、実行中に前の状態にロールバックしたり (構成エラーを修正するためなど)、同じ位置から何度も再実行したり (動的コンテンツの分散や "実行中の" システム イメージの循環の手段としてなど) できます。
完全仮想化によるバイナリ変換
ハードウェアの仮想化は、実装テクノロジによって、完全仮想化とホスト ベースの仮想化の 2 種類に分類できます。
完全仮想化では、ホスト OS を変更する必要がありません。完全仮想化では、バイナリ変換を使用して、機密性が高く仮想化できない命令の実行をトラップして仮想化します。ゲスト OS とインストールされているアプリケーションには、重要ではない命令と重要な命令が混在しています。
ホスト ベースのシステムでは、ホスト OS とゲスト OS の両方を使用し、ホスト OS とゲスト OS の間に仮想化ソフトウェア層が構築されます。
完全仮想化
完全仮想化では、重要ではない命令はハードウェアで直接実行され、重要な命令は検出されて VMM へのトラップに置換され、ソフトウェアでエミュレートされます。ハイパーバイザーと VMM のどちらのアプローチも、完全仮想化と見なせます。
重要な命令だけが VMM にトラップされる理由は、バイナリ変換によって大規模なパフォーマンスのオーバーヘッドが発生する可能性があるためです。重要ではない命令は、ハードウェアを制御することもシステムのセキュリティを侵害することもありませんが、重要な命令にはその可能性があります。そのため、重要ではない命令をハードウェアで実行すると、効率を向上できるだけでなく、システムのセキュリティも確保できます。
このアプローチは、VMware などの多くのソフトウェア企業が採用しています。VMM では、命令ストリームをスキャンして、特権があって制御や動作に影響する可能性が高い命令を特定します。このような命令を特定すると、VMM にトラップして、VMM で命令の動作をエミュレートします。このエミュレーションで使用する手法は、バイナリ変換と呼ばれます。
このように、完全仮想化では、バイナリ変換と直接実行を組み合わせています。ゲスト OS は、基盤となるハードウェアから完全に分離されています。そのため、ゲスト OS では、ゲスト OS が仮想化されていることが認識されません。
完全仮想化で実行するバイナリ変換にかなり時間がかかるため、完全仮想化のパフォーマンスは、最適ではないことがあります。大量の I/O が発生するアプリケーションの完全仮想化は困難です。バイナリ変換では、コード キャッシュを使用して変換済みの重要な命令を格納し、パフォーマンスを向上しますが、メモリ使用量のコストが増大します。通常、x86 アーキテクチャ上での完全仮想化のパフォーマンスは、ホスト コンピューターの 80 ～ 97% です。
ホスト ベースの仮想化
もう 1 つの VM アーキテクチャでは、ホスト OS に仮想化層をインストールします。ハードウェアの管理は、依然として、このホスト OS で行われます。ゲスト OS は、仮想化層にインストールされ、仮想化層で実行されます。場合によっては、VM で専用アプリケーションを実行することもあります。また、ホスト OS で直接実行できるアプリケーションもあります。
このホスト ベースのアーキテクチャには、いくつかのメリットがあります。まず、ユーザーはホスト OS を変更する必要なく、この VM アーキテクチャをインストールできます。仮想化ソフトウェアでは、ホスト OS を使用してデバイス ドライバーやその他の下位レベルのサービスを提供できます。そのため VM の設計が簡略化され、展開が容易になります。
また、ホスト ベースのアプローチは、多くのホスト コンピューターの構成に適しています。ただし、ハイパーバイザー/VMM のアーキテクチャに比べて、ホスト ベースのアーキテクチャのパフォーマンスは低くなることがあります。たとえば、アプリケーションによってハードウェアへのアクセスが要求されると、4 層に及ぶマッピングが必要になるので、パフォーマンスが大きく低下します。また、ゲスト OS の Internet Security and Acceleration (ISA) が基盤となるハードウェアの ISA と異なる場合は、バイナリ変換を適用する必要があります。ホスト ベースのアーキテクチャには柔軟性がありますが、パフォーマンスが低いため実用的ではありません。
準仮想化
準仮想化では、ホスト OS を変更する必要があります。準仮想化された VM では、ユーザー アプリケーション側で大幅な OS の変更を必要とする特殊な API が提供されます。パフォーマンスの低下は仮想化システムにとって重大な問題です。物理コンピューターを使用する場合よりも処理速度が大幅に遅ければ、VM を使用したいと考える人はいません。
仮想化層は、コンピューターのソフトウェア スタック中のさまざまな位置に挿入できます。しかし、準仮想化では、仮想化のオーバーヘッド削減を目的としているので、ゲスト OS のカーネルだけを変更することでパフォーマンスを向上します。ゲスト OS が準仮想化されている場合、ゲスト OS では、インテリジェントなコンパイラの支援により、仮想化できない OS の命令をハイパーコールに置き換えます。
従来の x86 プロセッサには、リング 0、1、2、および 3 という 4 つの命令実行リングが用意されています。リングの番号が小さくなるほど、実行する命令の特権が高くなります。OS では、ハードウェアとリング 0 で実行する特権がある命令を管理し、ユーザー レベルのアプリケーションはリング 3 で実行されます。準仮想化の好例は、Kernel-based Virtual Machine (KVM) です。
x86 プロセッサを仮想化すると、仮想化層はハードウェアと OS の間に挿入されます。x86 リングの定義によれば、仮想化層はリング 0 にも挿入される必要があります。リング 0 で複数の命令が実行されると、問題が発生するおそれがあります。しかし、ゲスト OS のカーネルを仮想化向けに変更すると、ハードウェアでカーネルを直接実行できなくなります。
準仮想化ではオーバーヘッドが削減されますが、別の問題が発生します。まず、変更していない OS もサポートする必要があるので、互換性と移植性が確保されるとは限らず、準仮想化された OS では、OS のカーネルを大幅に変更しなければならない可能性があるので、管理コストが高くなります。
また、準仮想化によるパフォーマンスの向上は、ワークロードの変化に大きく左右されるという問題があります。ただし、準仮想化は、完全仮想化と比べると、比較的容易で実用的です。完全仮想化の主な問題は、バイナリ変換におけるパフォーマンスの低さです。バイナリ変換の速度を向上することは困難です。そのため、多くの仮想化製品では、準仮想化アーキテクチャを採用しています。広く普及している Xen、KVM、および VMware ESX は、その良い例です。
KVM は、ハードウェア支援による準仮想化ツールで、パフォーマンスを向上し、変更されていないゲスト OS (Windows、Linux、Solaris、およびその他の各種 UNIX) をサポートしています。
KVM は、Linux の準仮想化システムで、Linux バージョン 2.6.20 カーネルの一部です。既存の Linux カーネルで、メモリ管理とスケジューリングのアクティビティが実行され、KVM でその他の処理が実行されるので、コンピューター全体を制御するハイパーバイザーよりも単純です。
完全仮想化では、特権があって機密性が高い命令を実行時に解釈してエミュレートしますが、準仮想化では、このような命令をコンパイル時に制御します。ゲスト OS カーネルは変更され、特権があって機密性が高い命令がハイパーバイザーや VMM へのハイパーコールに置き換えられます。Xen は、このような準仮想化アーキテクチャの一例です。
特権がある命令は、ハイパーバイザーへのハイパーコールによって実装されます。命令がハイパーコールに置き換えられると、変更されたゲスト OS で元のゲスト OS の動作がエミュレートされます。UNIX システムでは、システム コールによって割り込みやサービス ルーチンが実行されます。ハイパーコールは、Xen の専用サービス ルーチンに適用されます。
これらの多種多様な仮想化アーキテクチャには、さまざまなメリットとデメリットがあります。各アーキテクチャを調査することで、最適なアーキテクチャを環境に適用できます。
.jpg)
Kai Hwang は、南カリフォルニア大学のコンピューター エンジニアリングの教授であり、中国の清華大学の客員教授長でもあります。彼は、カリフォルニア大学バークレー校で EECS (電気工学およびコンピューター サイエンス) の博士号を取得しました。コンピューター アーキテクチャ、デジタル演算、並列処理、分散システム、インターネット セキュリティ、およびクラウド コンピューティングに関して幅広い執筆活動を行っています。
.jpg)
Jack Dongarra は、テネシー大学の電気工学およびコンピューター サイエンスの特別教授で、オークリッジ国立研究所の特別研究員、マンチェスター大学の招聘研究員でもあります。彼は、スーパーコンピューターのベンチマーク、数値分析、線形代数ソルバー、および高性能コンピューティングの分野における先駆者で、これらの分野に関して幅広い執筆活動を行っています。
.jpg)
Geoffrey Fox は、インディアナ大学の情報科学、コンピューティング、および物理学の特別教授で、情報科学およびコンピューティング研究科の副学部長でもあります。彼は、英国のケンブリッジ大学で博士号を取得しました。並行アーキテクチャ、分散プログラミング、グリッド コンピューティング、Web サービス、およびインターネット アプリケーションについての包括的な研究と幅広い執筆活動でよく知られています。
©2011 Elsevier Inc. All rights reserved. Syngress (Elsevier の事業部) の許可を得て掲載しています。Copyright 2011. 『Distributed and Cloud Computing: From Parallel Processing to the Internet of Things』(Kai Hwang、Jack Dongarra、Geoffrey Fox 著)この書籍と類似書籍の詳細については、elsevierdirect.com (英語) を参照してください。