わかった！ VMware/KVM/Dockerはこんな感じ

この記事はWeChatの公開アカウント「プログラミング技術宇宙」から転載したもので、著者はXuanyuan Zhifengです。この記事を転載する場合は、Programming Technology Universe の公開アカウントにお問い合わせください。

クラウド コンピューティングの時代では、コンピューティング リソースはインターネットの水と電気になったと、当時ポニー マー氏が言っていました。

[[331658]]

さまざまなクラウド プラットフォームを通じて、仮想ホスト、Web サーバー、データベース、オブジェクト ストレージなどのさまざまなサービスを実現できます。

クラウド コンピューティングの繁栄の背後には、仮想化技術という重要な貢献者がいます。仮想化技術がなければ、クラウド コンピューティングは不可能であると言っても過言ではありません。

仮想化と聞いて何を思い浮かべますか?一般的に使用されている 3 つの仮想マシン スイートである VMware、VirtualPC、VirtualBox から、人気の KVM やコンテナー テクノロジである Docker まで、さまざまなものがあります。

これらのテクノロジー間の関係はどのようなもので、その背後にある技術原理は何か、違いは何なのか、そしてそれぞれの適用シナリオはどのようなものでしょうか。

この記事を読んだ後、誰もが上記の質問に答えられるようになると思います。

歴史的背景

仮想化技術とは何ですか?

Wikipedia での説明は次のとおりです。

仮想化（技術）とは、コンピュータのさまざまな物理リソース（CPU、メモリ、ディスク領域、ネットワークアダプタなど）を抽象化して変換し、1つまたは複数のコンピュータ構成環境に分割および組み合わせることができるように提示するリソース管理技術です。

コンピューターの場合、下から順に、物理ハードウェア層、オペレーティング システム層、アプリケーション層の 3 つの層に簡単に分けることができます。

1974 年、2 人のコンピュータ科学者、Gerald Popek 氏と Robert Goldberg 氏が「仮想化された第 3 世代アーキテクチャの形式要件」という重要な論文を発表し、仮想化の 3 つの基本条件を提案しました。

• 同等性: プログラムは、ローカル コンピューターと仮想マシンで実行した場合に同じ結果を示す必要があります (実行時間の違いを除く)
• セキュリティ: 仮想マシンは互いに分離され、ホストコンピュータからも分離されています。
• パフォーマンス: ほとんどの場合、仮想マシン内のコード命令は物理 CPU で直接実行され、少数の特殊命令は VMM によって実行できます。

では、コンピューターの基盤となる物理リソースの仮想化とセグメンテーションをどのように実現するのでしょうか?コンピュータ技術の発展の歴史において、タイプ I 仮想化とタイプ II 仮想化という 2 つの有名なソリューションがあります。

タイプ I 仮想化

タイプ II 仮想化

図のVMMはVirtual Machine Monitorの略で、より専門的な用語ではHyperVisorとも呼ばれます。

2 つの仮想化ソリューションの違いは、次の図から明確にわかります。

タイプI: ハードウェア上に直接、複数の分離されたオペレーティングシステム環境を構築する

タイプ II: ホスト オペレーティング システムに依存し、その上に複数の独立したオペレーティング システム環境を構築します。

私たちがよく知っている VMware には、実際には 2 つの製品ラインがあります。 1 つは VMware ESXi で、ベアメタル上に直接インストールされ、追加のオペレーティング システムは必要ありません。これは仮想化の最初のタイプに属します。もう 1 つは VMware WorkStation です。これは一般ユーザーには馴染み深く、2 番目のタイプの仮想化に属します。

上記の仮想化ソリューションを実装するにはどうすればよいでしょうか?

典型的なアプローチは、トラップとシミュレーション技術である

それはどういう意味ですか？簡単に言えば、通常の状況では、仮想マシン内のコード命令は実行のために物理 CPU に直接配置されます。いくつかの機密命令が実行されると、例外がトリガーされ、制御フローが VMM に引き渡され、VMM は対応する処理を実行して仮想コンピュータ環境を作成します。

しかし、この従来の仮想化ソリューションは、Intel x86 アーキテクチャで問題が発生しました。

完全仮想化: VMware バイナリ変換テクノロジー

8086 時代の 16 ビット実アドレス動作モードとは異なり、x86 アーキテクチャは 32 ビット時代に入ってから、保護モードや仮想メモリなどの一連の新しいテクノロジを導入しました。同時に、セキュリティ上の理由から、アプリケーション コードとオペレーティング システム コードは分離されており、その実装方法は x86 プロセッサの動作状態に依存します。

これらは、よく知られている x86 プロセッサの 4 つの「リング」Ring0 ～ Ring3 です。

オペレーティング システムのカーネル コードは最高権限の Ring0 状態で実行され、アプリケーションは最も外側の最低権限の Ring3 状態で動作します。残りの Ring1 と Ring2 は、基本的に主流のオペレーティング システムでは使用されません。

ここで説明する権限には、次の 2 つのレベルの制約があります。

• アクセス可能なメモリ空間
• 実行可能な特権命令

2 番目のポイントである特権命令に焦点を当てましょう。

CPU 命令セットには、ハードウェア I/O 通信、メモリ管理、割り込み管理などの機能に使用される特殊な命令がいくつかあります。これらの命令は Ring0 状態でのみ実行でき、特権命令と呼ばれます。これらの操作は、明らかにアプリケーションが自由に実行できるものではありません。 Ring3 動作状態のアプリケーションがこれらの命令を実行しようとすると、CPU はそれを自動的に検出し、例外をスローします。

仮想化テクノロジーの話題に戻りましょう。前の定義で述べたように、仮想化とは、コンピューティング リソースを論理レベルまたは物理レベルで分割して、独立した実行環境を構築することです。

前述のトラップとシミュレーション方法によれば、仮想マシン内のオペレーティング システムを含むプログラムは、低権限の Ring3 状態で均一に実行できます。仮想マシン内のオペレーティング システムがメモリ管理、I/O 通信、割り込みなどの操作を実行すると、特権命令が実行され、例外がトリガーされます。物理マシンは例外を VMM にディスパッチし、VMM は対応するシミュレーション実行を実行します。

これは仮想化を実装するための理想的なモデルですが、x86 アーキテクチャ CPU では克服できないハードルに遭遇します。

何が問題ですか？

上で説明した理想的なモデルを振り返ると、このモデルを実現するための前提は、機密命令を実行するときに例外をトリガーし、VMM が介入して仮想環境をシミュレートする機会を与えることです。

しかし、現実には、x86 アーキテクチャの CPU 命令セットには、特権命令ではなく、Ring3 状態で実行できる命令がいくつかありますが、これらの命令は仮想マシンに敏感であり、直接実行することはできません。一度実行されると、例外はトリガーされず、VMM は介入できず、仮想マシンが公開されます。

これにより、仮想マシンのコード命令に予期しないエラーが発生します。さらに深刻なことに、実際の物理コンピュータの動作に影響を及ぼし、いわゆるセキュリティの分離や仮想化の同等性は問題外になります。

この問題を解決し、x86 アーキテクチャ CPU が仮想化をサポートできるようにするにはどうすればよいでしょうか?

VMware と QEMU は 2 つの異なる道を歩んできました。

VMware はバイナリ変換テクノロジーを独創的に提案しました。 VMM は、仮想マシンのオペレーティング システムとホスト コンピューターの間のブリッジの役割を果たし、仮想マシンで実行される命令をホストの物理コンピューターで実行するための適切な命令に「変換」して、仮想マシンでのプログラムの実行をシミュレートします。これは、Java 仮想マシンが Java バイトコードを実行するプロセスとして簡単に理解できます。違いは、Java 仮想マシンはバイトコードを実行するのに対し、VMM は CPU 命令の実行をシミュレートすることです。

パフォーマンスを向上させるために、すべての命令がシミュレートされるわけではないことにも留意してください。 VMware はここで多くの最適化を行いました。一部の「安全な」命令については、直接実行させるのがよい考えです。そのため、VMware のバイナリ変換テクノロジには直接実行も組み込まれています。

仮想マシンのオペレーティング システムの場合、VMM は、プロセッサ、メモリ、クロック、I/O デバイス、割り込みなどの基盤となるハードウェア デバイスを完全にシミュレートする必要があります。つまり、VMM は、仮想マシンのオペレーティング システムで使用するために、純粋なソフトウェアの形式でコンピューターを「シミュレート」します。

コンピュータを完全にシミュレートするこの技術は、完全仮想化とも呼ばれます。そうすることの利点は明らかです。仮想マシン内のオペレーティング システムは仮想マシン内にあることを感知できず、コードを変更する必要がなく、直接インストールできます。デメリットも考えられます。完全にソフトウェアでシミュレートされ、変換や翻訳が実行されるので、パフォーマンスが心配です。

QEMU は完全なソフトウェア レベルの「シミュレーション」です。一見すると VMware と似ているように見えますが、本質はまったく異なります。 VMware は、元の CPU 命令シーケンスを、実行用に処理された CPU 命令シーケンスに変換します。一方、QEMU は CPU 命令セット全体を完全にシミュレートして実行します。これは「解釈実行」に似ています。両者のパフォーマンスは比較になりません。

準仮想化: Xen カーネルのカスタマイズ

完全仮想化があるように、それに対応する準仮想化も存在します。前述のように、命令が機密であるため、完全に仮想化された VMM はこれらの命令をキャプチャし、物理コンピューターに影響を与えることなく仮想マシン オペレーティング システムのニーズを満たす実行プロセスを完全にシミュレートする必要があります。

しかし、単純に聞こえますが、シミュレーション プロセスは実際には非常に複雑で、多くの基礎技術が関係しており、このようなシミュレーションには時間と労力がかかります。

オペレーティング システム内でセンシティブな命令を実行するすべての場所がインターフェイス呼び出し (HyperCall) に変更され、インターフェイス プロバイダー VMM が対応する処理を実装すると、ハードウェア プロセスのキャプチャやシミュレーションなどの多くの作業が削減され、パフォーマンスが大幅に向上します。

これが準仮想化であり、この技術の代表が2003年に誕生したオープンソースプロジェクトのXenです。

このテクノロジーの最大の問題の 1 つは、オペレーティング システムのソース コードを変更し、それに応じた適応作業を行う必要があることです。これは Linux のようなオープンソース ソフトウェアでは許容範囲であり、せいぜい少し作業が増えるだけです。しかし、Windows のようなクローズドソースの商用オペレーティング システムの場合、コードを変更することは夢物語にすぎません。

ハードウェア支援仮想化 VT/AMD-v

結局のところ、x86 アーキテクチャの CPU は従来の仮想化モードを自然にサポートしていないため、ソフトウェア ベンダーは x86 上で仮想化を実装するためのさまざまな他の方法を考え出す必要があるのです。

CPU 自体が仮想化のサポートを追加したらどうなるでしょうか?

ソフトウェアベンダーが全力を尽くして x86 プラットフォームの仮想化を実現した直後、プロセッサメーカーも仮想化技術の巨大な市場を認識し、ハードウェアレベルの仮想化サポートを開始し、仮想化技術の急速な発展を正式に促進しました。

最も代表的なものは、Intel の VT シリーズ テクノロジーと AMD の AMD-v シリーズ テクノロジーです。

ハードウェア支援仮想化の詳細は比較的複雑です。つまり、新世代の CPU では、元の Ring0 ～ Ring3 の動作状態の下に動作モードと呼ばれる概念が導入されています。 VMX ルート操作と VMX 非ルート操作の 2 つのモードがあります。各モードには、Ring0 ～ Ring3 の動作状態の完全なセットがあります。前者は VMM が動作するモードであり、後者は仮想マシン内の OS が動作するモードです。

VMM が動作するレベルは、リング -1 と呼ばれることもあります。 VMM は、CPU が提供するプログラミング インターフェイスを通じて、どの命令をハイジャックしてキャプチャするかを構成し、仮想マシンのオペレーティング システムを制御できます。

つまり、仮想マシンでのコードの実行を制御するために、元の VMM では「仲介者」を使用して変換と実行を行う必要がありました。これで、新しい CPU は VMM に「そんなに面倒なことはする必要はない」と伝えます。事前に、どの命令とイベントに興味があるかを教えてください。これらの命令が実行され、これらのイベントが発生したときに通知し、制御できるようになります。ハードウェア レベルで完全にサポートされているため、パフォーマンスは当然大幅に向上します。

上記は、ハードウェア支援仮想化テクノロジーについての簡単な説明です。実際、メモリ仮想化、I/O 仮想化など、より多くの要素が含まれており、VMM にさらなる利便性をもたらし、VMM の設計と開発が大幅に簡素化されます。 VMM では高額なシミュレーション実行コストを支払う必要がなくなり、全体的な仮想化パフォーマンスも大幅に向上しました。

VMware はバージョン 5.5 でハードウェア支援仮想化のサポートを導入し、2011 年のバージョン 8.0 で正式に完全にサポートしました。そのため、仮想マシンを作成するときに、元のバイナリ変換実行を使用するか、ハードウェア支援仮想化に基づく新しいテクノロジを使用するか、どちらの仮想化エンジン テクノロジを使用するかを選択できます。

同時に、XEN はバージョン 3.0 からハードウェア支援仮想化のサポートも追加し、それ以降、Windows システムも XEN ベースの仮想マシンで実行できるようになりました。

KVM-QEMU

ハードウェア支援による仮想化のサポートにより、仮想化技術は爆発的な成長を見せ始めています。 VirtualBox、Hyper-V、KVMなどの技術が次々と登場しています。中でも、オープンソースの KVM テクノロジーは、クラウド コンピューティングの分野で有名になりました。

KVM は Kernel-based Virtual Machine の略で、カーネルベースの仮想マシンを意味します。

基盤となる仮想化テクノロジーの点では、KVM は VMware の後続バージョンと同様に、ハードウェア支援による仮想化に基づいています。違いは、VMware は独立したサードパーティ ソフトウェアとして、Linux、Windows、MacOS などのさまざまなオペレーティング システムにインストールできるのに対し、KVM は仮想化テクノロジとして Linux カーネルに統合されていることです。 Linux カーネル自体がハイパーバイザーであると考えることができ、これは KVM という名前の意味でもあります。したがって、このテクノロジは Linux サーバーでのみ使用できます。

KVM テクノロジーは QEMU と組み合わせて使用​​されることが多く、KVM-QEMU アーキテクチャと呼ばれます。前述のように、x86 アーキテクチャ CPU 向けのハードウェア支援仮想化テクノロジが誕生する以前から、QEMU は仮想化を実現するために一連のソフトウェア シミュレーション手法をすでに採用していましたが、このソリューションでの実行パフォーマンスは非常に低いものでした。

KVM 自体はハードウェア支援仮想化に基づいており、CPU とメモリの仮想化のみを実装します。しかし、コンピュータにはCPUやメモリだけでなく、さまざまなI/Oデバイスが必要ですが、KVMはこれらを担当していません。この時、QEMUとKVMが接続されていました。修正された QEMU は外部デバイスの仮想化を担当し、KVM は基盤となる実行エンジンとメモリの仮想化を担当しました。これら 2 つは互いに補完し合い、新世代のクラウド コンピューティング仮想化ソリューションの寵児となりました。

コンテナテクノロジー - LXC と Docker

変換とシミュレーションに基づく完全仮想化テクノロジ、準仮想化テクノロジ、または CPU ハードウェアのサポートによる完全仮想化テクノロジのいずれであっても、仮想化の目標は、基盤となる物理ハードウェア、オペレーティング システム、およびアプリケーション実行のための完全な環境を備えた完全なコンピューターです。

仮想マシン内のプログラムが実際の物理マシン上で実行されているのと「同様の」効果を達成できるようにするために、その背後にある HyperVisor は多くの作業を実行し、「大きな」代償を払ってきました。

HyperVisor は多くのことを行っていますが、仮想マシン内のプログラムに、これが本当に必要なことなのか尋ねたことがありますか?おそらく、HyperVisor が与えすぎたため、ターゲット プログラムは「そんなに頑張る必要はありません」と言ったのでしょう。

確かに、仮想マシン内のプログラムが「別の実行環境だけが必要なので、完全なコンピューターを仮想化するためにそれほどの労力をかける必要はありません」と言うような状況があります。

これを実行するとどのような利点がありますか?

コンピュータを仮想化するのと、分離されたプログラム実行環境を仮想化するのとでは、どちらがコストがかかりますか?答えは明らかに前者です。 10 台の仮想マシンを同時に仮想化すると物理マシンの負荷が重くなる場合がありますが、同時に 100 台の仮想実行環境を簡単に処理できるため、リソースを最大限に活用できるという大きなメリットがあります。

近年非常に人気となっているコンテナ技術は、この指導理念のもとに誕生しました。

コンピュータを完全に仮想化する仮想化テクノロジーとは異なり、コンテナ テクノロジーはオペレーティング システム レベルでの仮想化に似ています。オペレーティング システム環境を仮想化するだけで済みます。

LXC テクノロジーは、このソリューションの代表的なものです。正式名称はLinuX Containerです。 Linux カーネルの Cgroups テクノロジーと名前空間テクノロジーのサポートを通じて、オペレーティング システム ファイル、ネットワーク、およびその他のリソースを分離し、ネイティブ オペレーティング システム上に別の領域を分離して、その中でアプリケーションを実行します。この空間の形状はアプリケーションを格納するコンテナに似ているため、コンテナ技術と呼ばれています。

あまり適切ではない例え話ですが、もともと寝室が 3 つあった家が、家主によって 3 つの 1 寝室スイートに改装されました。各 1 ベッドルーム スイートにはバスルームとキッチンが備わっており、そこに住む人々にとって完璧な家となっています。

現在、大手メーカーの間で人気がある Docker テクノロジーの基本原理は、LXC と根本的に変わりません。実際、初期の頃、Docker は LXC の高レベルのカプセル化を直接ベースとしていました。 Docker は LXC に基づいてさらに一歩進んで、実行環境内の各コンポーネントと依存関係を独立したオブジェクトにパッケージ化し、移植と展開を容易にします。

コンテナ技術の利点は軽量であることです。分離されたスペース内のすべてのプログラム コード命令は、翻訳または変換する必要がなく、CPU 上で直接実行できます。最下層では全員が同じオペレーティング システムを使用し、ソフトウェア レベルでは論理的な分離によって個別のスペースが形成されます。

コンテナ技術の欠点は、セキュリティが仮想化技術ほど高くないことです。結局のところ、ソフトウェア レベルでの分離は、ハードウェア レベルでの分離よりもはるかに弱いのです。分離された環境システムと外部のホストは同じオペレーティング システム カーネルを共有します。カーネルの脆弱性を悪用して攻撃が開始されると、プログラムはコンテナの制限を突破して脱出し、ホスト コンピュータを危険にさらし、セキュリティが失われます。

超軽量仮想化爆竹

仮想完全コンピューターは分離性に優れていますが、サイズが大きすぎます。一方、シンプルなコンテナー テクノロジは軽量すぎて、ソフトウェア分離のみに頼るには安全性が不十分です。両方の利点を組み合わせ、軽量かつ安全な妥協案はあるでしょうか?

近年、超軽量仮想化という考え方の人気が高まっており、Amazonが立ち上げたFirecrackerはその代表例です。

Firecracker は、仮想化技術の強力な分離性とコンテナ技術の軽量性を組み合わせて、microVM の概念を提案します。基盤となる KVM 仮想化テクノロジを使用して各 microVM を強力に分離し、分離された仮想マシンでは、多数の無駄な機能をカットした合理化されたマイクロ オペレーティング システムを実行します。これらはコンテナ専用に設計されたマイクロ OS です。

超軽量仮想化が新たなトレンドになっています。 AWSのfirecrackerに加え、GoogleのgVisorやIntel主導のNEMUもこの分野で取り組みを始めています。

要約する

この記事では、仮想化テクノロジの基本的な概念と基本的な要件について簡単に説明します。初期の x86 アーキテクチャでは従来の仮想化ソリューションがサポートされていなかったため、ソフトウェア ベンダーは初期の VMware WorkStation や Xen に代表されるソフトウェア シミュレーションを通じてのみ仮想化を実装できるということが紹介されました。

しかし、純粋にソフトウェアに頼ると、結局パフォーマンスのボトルネックが発生します。幸いなことに、Intel と AMD は CPU ハードウェア レベルでの仮想化サポートをタイムリーに開始し、ソフトウェア メーカーもすぐに追随して適応したため、仮想化のパフォーマンス エクスペリエンスが大幅に向上しました。この時期の代表的なものとしては、VMware WorkStation、Hyper-V、KVM などの新しいバージョンが挙げられます。

近年、クラウドコンピューティングとマイクロサービスの徹底的な発展に伴い、仮想化技術の仮想粒度は、粗いものから細かいものへと徐々に変化してきました。初期のコンピュータ全体の仮想化から、その後のオペレーティングシステムのみの仮想化、そしてマイクロサービスに必要な環境の仮想化まで、Docker に代表されるコンテナ技術はこの期間に輝いてきました。