ここでは、専門的な構造や技術を、ある程度噛み砕いて説明します。
変な例えを用いているので、若干ズレが生じているかもしれませんがご了承ください。
インテル® バーチャライゼーション・テクノロジーとは、
仮想化をハードウェアレベルでサポートする技術の事で、大きく分けて下記3つの機能があります。
1.VT-x
2.VT-i
3.VT-d
詳細は後ほど説明することにしまして・・・
インテル® バーチャライゼーション・テクノロジーの詳細に入る前に、まずは前提となる仮想化の説明から進めます。
ここでいう仮想化はコンピュータの仮想化で、具体的にはPCやサーバーになります。
物理的な1台のマシンで、複数台のマシンを実現することを仮想化と言い、仮想化で構築した複数のマシンのことをバーチャルマシン(VM)と呼びます。
また各VMにインストールされたOSはゲストOSと呼びます。
一つのCPU、一つのNIC、一つのメモリといったハードウェアリソースを複数のVMで共有することが可能です。
1台のマシンを購入すれば、複数のサーバーが立てられる、なんだかお得です。
また仮想化には現在大きく分けて2つの実現方法
1.ハイパーバイザ型
2.ホストOS型
に分類されます。
今回のお題には直接的な関係はないので簡単に説明すると、ハイパーバイザ型は土台にVMMをインストールし、その上にゲストOSをインストールします。
ホストOS型は、土台にOSをインストールしそのアプリとしてVMMをインストール、さらにその上にゲストOSをインストールします。
【マシンの分離と独立】
各VMは独立して扱われます。
上の図で説明しますと、仮想サーバー３から仮想サーバー１は物理的に分離した、別のサーバーマシンとして扱うことができます。
例えば、仮想サーバー1を企業のサーバーとし、仮想サーバー３をサーバーではなく一個人のクライアントPCとして構築し、実際にアクセスしてみるといった事も可能です。
【カプセル化】
一つのVMをファイルパッケージとして扱い、カプセル化されています。
具体的には、OSやインストールしたソフトだけでなく、ハードウェアやBIOSもファイルで管理されており、一つのパッケージとして扱われます。
【ハードウェア非依存】
仮想化バーチャルマシンモニタ(VMM)というソフトが必要になり、物理ハードウェアはこのVMMによってリソース配分が行われ、各VM毎に仮想的なハードウェア環境が構築されます。
ユースケース毎に異なってくると思いますが、主なメリットは下記になります。
【物理マシンの削減】
1台のマシンで、複数のマシンを実現できるためコストの削減や省スペース化に有効です。
【ハードウェアリソースの有効活用】
最近のコンピュータは非常に高性能です。
このレビューのために提供頂いたCore-i7 3770は4コア8スレッドで、ハイパーバイザによっては8コアもしくはシングルコアの8CPUとして扱う事も可能です。
例えば、ちょっとしたWebサーバーやファイルサーバーを構築する場合、このCPUはオーバースペックで性能を持て余す事になるでしょう。
仮想化によって複数台のVMでCPUリソースを扱うことにより、本来の性能を使い切る事が可能になります。
【マシンの複製が容易】
仮想化されていない場合、同じマシンを複数台用意する場合は、OSのインストールにアプリのインストールとそれらの設定が台数分必要になります。
しかしVMの場合はカプセル化されているため、ファイルパッケージをコピーするだけで、同じマシンの複数台作成が容易に可能です。
これは、似たようなサーバーを複数台立てたい場合や、サーバーアプリ開発の過程でステップ単位でバックアップを取ったり、クラッシュテストをする場合のテスト環境を複製したりする場合に容易に行えるため非常に便利です。
【マシンの移植が容易】
カプセル化とハードウェア非依存によるメリットです。
1台のマシンに１つのOSを入れた場合、他のマシンにHDDだけ移して稼動させることは基本的には不可能です。全く同じハードウェア構成なら可能かもしれませんが、構成が異なる場合はシステムが不安定になることが考えられます。
仮想化している場合、ハードウェアへの依存が非常に低いため、構成の異なるマシンでも容易に移植が可能です、またカプセル化されているため最短の場合コピーするだけで運用が可能になります。
これはサーバーメンテナンス時にサーバーを(ほぼ)止めずに運用したい場合や、サーバーのハードウェア増強が簡単に行えるといったことが可能になります。
VT-xは命令系統の扱いををハードウェアレベルでサポートします。
まずソフトウェアは、CPUのリングプロテクションというアーキテクチャを利用して、ハードウェアにアクセスします。レベル概念を用いて、ハードウェアへのアクセスを保護する機構です。
レベルの数値が低いほど権限が強く、数値が高いほど権限が弱くなります。
OSやVMMを含めた全てのソフトウェアは、いずれかのレベルに属します。
基本的には、ハードウェアに直接アクセスできるのはLEVEL0であり、それより高いレベルは、一つ下のレベルに対し正しい手順でアクセスする必要があります。
基本的にOSはLEVEL0に属するものとして設計されています。
実際にはCPUの状態で管理されており、LEVEL0のソフトウェアの命令を処理する時は、LEVEL0状態に遷移します、そしてLEVEL1のソフトウェアの命令を処理する時はLEVEL1状態に遷移します。LEVEL1状態の時にLEVEL0のハードウェアを直接アクセスする命令が要求された場合は権限違反としてエラーで返します。
この様に信頼性や安全性が高いソフトウェアのみハードウェアアクセスの権限を許すことによって、安全にハードウェアを操作する事が可能になります。
変な例えですが・・・
会社で予算が必要な場合、平社員(LEVEL3)が勝手にお金を持ち出して使うことはできないのと一緒です。上長(LEVEL2)に会議(CPUモード3)の場で提案して承認を得る、その上長はさらに上長(LEVEL1)に会議(CPUモード2)で提案、役職が上になるほど提案時の理由付け(正しい手順でのアクセス)がしっかりしていないと承認されません。
また、平社員が勝手に会社のお金に手をつけようとしたらおそらく懲戒(エラー)でしょう。
ここで、ハードウェアレベルで仮想化をサポートしていないマシンに、仮想化環境を構築すると、ゲストOSはLEVEL1にVMMがLEVEL0に割り振られます。
やっぱり変な例えですが・・・
OS部長はOS課長へと降格し、部長の座にはVMMが就きます。
課長(OS)は、今までどおりの権限で予算を扱おうとしますが(ハードウエアアクセス)、部長(VMM)はそれを監視します。
課長には予算を引き出す権限がないので、金庫のお金は取り出せません。(権限違反でありCPUからエラー)
複数の課(VM)で予算が必要になりました。
課が多ければ多いほど、予算会議が多ければ多いほど部長(VMM)は忙しくなり、各予算の審議や予算割り振りが大変になります。
しかも、予算会議だけではなく、他の会議(仮想化に影響しない処理命令)もあるので振り分けが大変です。
そこでVT-xの登場です。
具体的にはリングプロテクションに加え、仮想化独自の2つのレベル(状態)を追加しました。
これをバーチャルマシンエクステンション(VMX)と呼びます。
1.VMX rootモード
2.VMX non-rootモード
仮想化環境ではVMMにVMX rootを、ゲストOSにVMX non-rootを割り当てます。
VMX non-root時に仮想化に影響のある命令を受け付けると、CPUが感知しエラーを発生しさらにVMX rootに状態遷移してVMMに処理を移します。
ハードウェアレベル（CPU）でゲストOSの命令を判断して状態を切替え、さらに(ほぼ）VMM専用のモードが設けられたためVMMの処理を単純化できパフォーマンスが向上します。
厳密には上記の他に、従来のLEVEL0～LEVELxの概念のある普通のモードが加わります。
またバーチャルマシンコントロールストラクチャ(VMCS)というアーキテクチャも追加。
これはVMやVMMの処理を切替える際の処理中データを構造化してデータセットとして扱うものです。決められた形のデータの形になるため、ハードウェアレベルでも扱いやすく、VMMでも処理を単純化することができるため、パフォーマンスの向上につながります。
更には、VMXとVMCSを扱うための命令が追加されており、今まで複雑な処理をVMMでこなしていたものがハードウェアレベルで実装されるため、処理速度の向上やVMMの処理の簡素化につながり、やはりパフォーマンスの向上につながります。
そして拡張ページテーブル(EPT)の追加。
メモリはVMMによって各VMで競合しないように振り分けられます、その際ゲストOSからは普通のメモリ空間と認識させる必要があるためアドレスの変換が発生します。
そのアドレスの変換処理をハードウェアレベルでサポートするのがEPTです。
くどいようですが、ハードウェアでの処理ですのでVMMのソフトウェア処理と比較しパフォーマンスは向上します。
ちょっと息抜きをしましょう。
VT-iはVT-ｘと機能的には殆ど一緒です。
違うのは搭載されるCPUが異なるという点で、Itanium系のCPUに搭載されています。
ということで、説明は割愛いたします。
VT-dはI/OのDMAをVMで直接行えるようハードウェアレベルでサポートします。
ここで言うI/OはUSBやPCI-eやNICなどのコンピュータの周辺機器が対象です。
この機能はCPUでなく、主にチップセット側がサポートします。
DMAとはダイレクトメモリアクセスと言って、各I/Oとメモリ上のデータをCPUを介さずに直接やりとりするアーキテクチャの事です。そうすることによりCPUで遠回りすることなく、ショートカットができるのと、CPUの消費も低減できるためI/Oとのデータ通信速度が向上します。
前述したようにメモリはVM共通で利用しているため、やはりアドレスの変換が発生します。
ゲストOSが指定するメモリアドレスは仮想メモリのアドレスであり、I/Oが参照しようとしている物理メモリのアドレスとは異なります。
そのアドレス変換をチップセット側でサポートします、さらにはチップセットに変換テーブル用の記憶領域を設け、VMMに問い合わせることなくアドレスの変換が可能になります。
さてどの様に検証しましょう。
ESXIで仮想化
今回はVMMとしてESXIを利用します。
VMwar社の仮想化ソフトウェアです、IT業界ではかなり著名なソフトウェアです。
VMware vSphere Hypervisorをダウンロードして仮想化するマシンにインストールしましょう。
今回検証用に提供頂いたマシンを組み上げ、そこにインストールします。
今回は、PCの組み立て、インストールや設定手順メインテーマではないので軽くさらっと流していきます。
ESXIはハイパーバイザ型の仮想環境です。ですのでPCを組み上げた直後にOSを入れる必要はなく、いきなりESXIをインストールします。
また仮想化用マシンにアクセスするための別PCが必要になります。
インストールが終われば仮想用マシンはこの様な画面になり、IPv4とIPv6のアドレスが表示されています。仮想化用PC本体では、超基本的な設定しかすることはなく、仮想化環境の構築する機能ありませんので基本的に放置になります。
後は管理用の別PCからリモート接続により仮想環境を構築していくことになります。
管理用PCからブラウザで仮想化用PCのアドレスにアクセスすると、この様なサイトが表示されます。矢印のリンクをクリックして、管理用PCから仮想化用サーバーを設定するクライアントソフトをダウンロードし管理用PCにインストールします。
インストールしたらとりあえず仮想化用PCにリモート接続。
仮想化用PCのアドレスにアカウントとパスワードを入力。
この様なクライアントリモートツールが立ち上がります。
早速VMを構築。
仮想マシンタブ選択＞何もないところでコンテキスト＞新規仮想マシンを選択。
おまかせなら標準、細かく決めたいならカスタムを。今回は標準を選択。
サーバー名を入力、思いっきり日本語ですが出来れば2バイト文字じゃない方がいいかもしれません、しかし今回は日本語でOKでした。
割り当てる物理HDDを選択。
インストールするゲストOSの種類を選択。
割り当てるNICを選択。実はESXIはそこそこハード用件が厳しくて、認識してくれないNICが結構ある様子です。
NICが一つも認識できない場合はESXIのインストール時にエラーが出て、インストールが完了しません。回避策としてはESXIインストールイメージにNICのドライバを含めパッチを当てるツールがありますので、そちらを参考に。
VMに割り当てるHDDの容量を入力。OSの用件を満たした値以上にしましょう。
また、HDD領域の確保方法について選択できますので、任意で。
これにてVMの設定が完了。
2台のVMを構築した状態です。
次はゲストOSのインストール。
立ち上げたいVMを選択して再生ボタンを押下。
仮想マシンコンソールの起動を押下。
はじめにタブとサマリタブの間の上くらいにあります。
これでVMの画面が立ち上がります。
インストールメディアのあるドライブを選択、実物のメディアなら管理用PCの光学ドライブからインストールが可能です。またイメージファイルであれば管理用PC、仮想化用PCどちらに置いてもアクセス可能です。任意のものを選択。
タウカンのマークに似たリセットボタンを押下してインストール開始。
SENT-OSのインストール。
別VMにはWindowsXPをインストール。
最終的にはUbuntuを含めた3台のVMを起動。
今回は全てクライアントOSで起動しましたが、1台はWebサーバー、もう一台はWindowsクライアントPCとして構築し、Webサーバーの構築テストなどを行うことも可能です。
仮想化のメリットである1台の物理マシンで複数の仮想マシンを構築できることの恩恵は計り知れません。
仮想化のまた別のメリット、カプセル化について説明します。
まずは仮想化用マシンを選択(左のIPアドレスの箇所)＞構成タブ＞ハードウェア欄のストレージを選択＞VMを構築したHDD選択＞コンテキスト＞データストアの参照
これで仮想化用マシンのデータストアが閲覧できます。
ここにカプセル化されたVMの実体があります。下記の写真で草津温泉フォルダが草津温泉マシンのカプセル化されたフォルダになります。
この中にハードウェア設定、BIOS、OS、データの全てが入っています。
そしてこのデータストアはWindowsのエクスプローラーと似た操作で扱えますので、コピー＆ペーストするだけで、VMの複製が簡単に行えます。
また左から5番目のデータベースに緑色の下矢印で、管理用のリモートPCにダウンロードできますので、バックアップも容易です。
さらには管理用リモートPCにダウンロードしたVM環境を、別のESXIがインストールされたマシンにアップロードすれば、VMの移植も簡単に行えます。
補足として、このデータストアは構築したVMから参照できますので、イメージファイルを置いておけば、ドライブ代わりにも利用可能です。応用すればOSのイメージファイルをここに置いておけば、ここからインストールも可能です。(管理用リモートPCのHDDからもできます)
実際にVMを複製してみました。
操作としては新しいフォルダを作成し、草津温泉フォルダの中身を全てコピー。
これだけでVMの複製が完了します。後は複製したVMは起動時に「コピーしましたか？」みたいな事を聞かれるので、ウィザードに沿って進めれば問題なく起動する事が可能です。
さて本題中の本題です。
気合入りすぎて、吹き出しから「テク」がはみ出してしまいました。
正直、この検証方法が正しいとの確信はありませんが、とりあえずやってみましょう。
まずはWindowsのVMを2台構築します。
マシンに搭載したCore i7-3770の4コア8スレッドを8コアで仮想します。
そして2台のVMにめいっぱい割り振りましょう。
どちらも8コア、リソースの奪い合い必至状態にします。
Windowsは仮想マシンであっても台数分のライセンスが必要になりますのでご注意下さい。
そして一旦仮想化用PCを再起動しBIOS設定。
Intel Virtualization Technologyと
Intel Virtualization Technology for Directed I/OをDisableに。
ここで前座
検証その①
インストールするVMMに依存するとは思われますが、ESXIの場合は
Intel Virtualization Technologyがサポートされたハードウェア環境でなければ
ゲストOSとして64BitOSは起動できません。
エラーが出てこの通り。
さて本命中の本命です。
8コアをフルフルで割り振った2台のWindowsPCを起動。
何をするかと言えばCineBenchでパフォーマンステスト。
Intel Virtualization Technology
Intel Virtualization Technology for Directed I/O
共にDisable状態で
3.66と3.72
仮想化用マシンを再起動してBIOS設定
今度は
Intel Virtualization Technology
Intel Virtualization Technology for Directed I/O
共にEnable
さてパフォーマンスは向上するのか。
Intel Virtualization Technology
Intel Virtualization Technology for Directed I/O
共にEnable状態で
3.77と3.77
微妙な差と思うなかれ、CineBenchでの0.1は非常に大きいのですよ。
証拠にcore-i7の3770を持ってしても両方足して8程度。
これは誤差と言うには大きすぎる差分だと考えています。
しかも両方3.77に揃ったのは偶然でしょうか？それとも
Intel Virtualization Technologyのおかげでタスク分配が適切に行われた結果？
これはわかりません。
個人的な見解ではありますが、CineBenchでトータル0.16の差がついたのは
Intel Virtualization Technologyの効果だと考えています。
今回は2台のVMでそこそこの負荷テストではありましたが、これが3台4台と増えるにつれ
またWebサーバー等のI/Oアクセスが非常に多くなる環境では、効果はもっと顕著に現れるのではないでしょうか。
ZIGSOWにログインするとコメントやこのアイテムを持っているユーザー全員に質問できます。