仮想化が進んで今では普通に使われるようになっていますが、いまだにハイパーバイザーの仕組みを理解していない IT 管理者の方もいます。一番困るのは VMware Workstation や VMware Fusion のような仮想化と、VMware ESXi や Microsoft Hyper-V などの仮想化を混同して「仮想化は性能出ないからなぁ」と言っている人に時々出会ったりします。
なので、ちょっと軽めにコンピューティングの仮想化について、絵で説明してみます。絵はもしかしたら「どこかで見たことあるなぁ」というのあると思いますが、オリジナルは私が昔書いたものでそれが VMware 社の資料として使われているだけです。今回の絵はそれを思い出しながらちょっと vSphere については 7 対応にして書いてみました。
仮想化の肝、ハイパーバイザーの違い
コンピューティングの仮想化はハードウエアをソフトウエアでエミュレーションして実現します。そのため、物理ハードウエアを利用する仮想マシンに対して「あなたはこのデバイスを占有していますよ」と見えるようにハードウエアに実装されているデバイスをコントロールします。このコントロールするのがハイパーバイザーと仮想デバイスです。そして、このハイパーバイザーがハードウエアに対してどの位置にあるかによってタイプが変わります。
- 物理ハードウエアのままの構成：下図で一番左が物理ハードウエアの上にオペレーティングシステムを入れアプリケーションを動かす「レガシー」な構成です。昨今は普通に仮想化が利用されているのにもかかわらず。まだまだほとんどのサーバーまたはすべてのサーバーをこの物理ハードウエアのまま運用している企業も少なからずあるんですよね。そういうところは特別な理由があるか IT 担当者の人が勉強不足で仮想化を理解していないんではないかと思ったりしています。
- タイプ1 ハイパーバイザー：VMware vSphere や Microsoft Hyper-V、Linux の Xen Server や KVM で利用されている構成です。先の物理のオペレーティングシステムの所にハイパーバイザーが入ります。この図を見ていただくとわかる通り、物理ハードウエアの制御はハイパーバイザーが行い様々な抽象化機能を利用してハイパーバイザー上に作られた仮想環境上の仮想マシンにあたかも占有しているようにリソースを渡します。その際ハイパーバイザーはハードウエアの仮想化支援機能を利用してオーバーヘッドが限りなく少なくなるようにするため、現在のタイプ1ハイパーバイザーではシングルインスタンスの環境では物理とそん色ない性能を出すことが出来ます。これはそれぞれの仮想環境にたいしてハイパーバイザーのスケジューラーが直接ハードウエアをコントロールしているため出せるわけです。
- タイプ2ハイパーバイザー：VMware Workstation や VMware Player、VMware Fusion のような、物理ハードウエアにインストールされたオペレーティングシステムの上で動かすタイプのハイパーバイザーです。この場合は間にオペレーティングシステムが介在してしまうので、ハイパーバイザーは物理ハードウエアを直接操作することが出来ません。そのため物理ハードウエアの性能をそのまま使うことが出来ず大きなオーバーヘッドが発生します。「仮想化は性能出ないからなぁ」と言っている人のほとんどはこのタイプ2ハイパーバイザーとタイプ1ハイパーバイザーを混同しています。
ハイパーバイザーの構造の違い
同じように見えるタイプ1ハイパーバイザーですが、それぞれ実装のしかたが大きく異なります。元々ハイパーバイザーとして登場した VMware ESXi では必要な機能をコントロールすることに特化したカーネル部分と個別に変更しなければならない追加コンポーネント部分（vib で提供されます）だけで構成されているため、ハイパーバイザーのフットプリントはだいぶ機能が拡張された ESXi 6.7 でも 141 MB しかありません。（ESXi 7 はとても大きくなる気がしますが。）それに対して Linux では約 2.6GB、Windows Server 2016 の Core Hyper-V に至っては 6.6 GB もあります。これが単純に比較できるものではないのですが、それだけ多くのモジュールを必要としていることになります。それはもしかしたらハイパーバイザーには直接不要なコンポーネントも含まれるかもしれませんが、それだけではなくハイパーバイザーの構造の違いも影響しています。
VMware vSphere ESXi：
ESXi ではシンプルなカーネルと必要最低限の vib のコンポーネントで構成されます。そして全てカーネル内で仮想マシンのコントロール、仮想スイッチのコントロールなどを行ないます。図にはありませんがネットワークの仮想化 NSX やストレージの仮想化 vSAN も同様に vib でハイパーバイザーに対してコンポーネントとして追加されます。次の vSphere 7 では Project Pacific というコードネームで Kubernetes を組み入れるということが行われますが、これは Kubernetes を使うときに利用する Kubelet に対して vSphere 上でそれを代替えする Spherelet というものが用意されます。多分 vib で提供されるのかなと思ったりしていますが、現在提供されているβ版でも実態は見ることができないので今後の情報待ちですが、カーネル部分に近いところに取り込まれたりすると ESXi がデグレートしないか心配になりますね。
Microsoft Hyper-V：
Windows Server インストール後に Hyper-V モジュールを組み込んでハイパーバイザーに変えます。なので、基本的には Windows そのままなので場合によっては Hyper-V が動いている Windows Server に既存アプリを並行して動かすこともできてしまいます。でも、これは Hyper-V 上の仮想マシンと同じレベルでそのアプリが動くということになるので普通はしませんね。
構造的には親パーティションでハイパーバイザー上の仮想マシン（子パーティション）を管理します。なので親パーティションと子パーティションの間でバスを経由してのやり取りが発生します。また、このような構造をとるため子パーティションのオペレーティングシステムには親パーティションとやり取りするための専用のモジュールのインストールが必要になります。またパフォーマンス向上のために ParaVirtualization Driver などを使う必要があったりと快適に動かすために気を遣う点が多くなります。今はあまり使われなくなってきている Xen Server も、基本的にはこの Hyper-V と同じ構造です。Hyper-V は 2.0 でこの構造になったのでそれまでの 1.0 とは互換性無くなったのですが、メインフレームの仮想化の仕組みに近いこの形はもしかしたら正統派の仮想化の仕組みかもしれません。
Linux KVM:
Linux に実装されているリソースやセキュリティなどをセパレートする仕組みをコントロールして他のハイパーバイザーと同様に仮想マシン型で動作する環境として出てきたものです。Linux では先に Xen が実装されていたのですが、いろいろあって後から出てきた KVM が先に Linux 標準機能として実装されました。その結果、早いうちから仮想化に取り組んでいたデーターセンター業者やクラウドベンダーでは仮想化機能に Xen を使用しているところも多い（AWS EC2 の古いほうや Oracle Cloud、日本の Linux ベースのクラウドベンダー などですね）のですが、今は Linux で仮想化するところは Xen ではなく KVM を使用しています。
KVM では Linux標準の機能のスケジューラーによりメモリーマネージャー、プロセス・スケジューラー、I/Oスタック、デバイスドライバー、セキュリティ・マネージャー、ネットワークスタックなどをコントロールし仮想マシンに対してリソースを割り当てていきます。そのため、追加モジュール不要で KVM を有効にするだけで使えるので手軽です。ただ構造的にはやはり仮想マシン側に専用のモジュールを必要とするので、そのモジュールが提供されていないと使えません。
。
