vSphere 4.1のベースとなるハイパーバイザーのESX/ESXi 4.1

　2010年の1月に、VMwareのvSphere 4.0を紹介したが、昨年7月にはvSphere 4.1がリリースされている。少し遅くなったが、今回から数回にわたって、vSphere 4.1の機能を紹介していく。前回の記事では、vCenterの機能、vMotion、HAなどを紹介した。今回のミニ特集では、vShield ZonesなどvSphere 4.1で追加された機能を紹介していく予定だ。

■次期バージョンではESXiに一本化

　今回は、vSphere 4.1の機能を紹介する前に、vSphere 4.1のベースとなるハイパーバイザーのESX/ESXi 4.1に関して解説していく。

ESX/ESXiの違い。次バージョンからは、ESXiのみになる（出展：vForum, 2010年11月, ヴイエムウェア株式会社、スクリーンショットを除き以下同じ）

　VMwareでは、vSphere 4.1のリリース時に、2011年にリリースされる次期バージョン（通常であれば、7月か8月にリリースされるのではないかと見られる）では、ハイパーバイザーはESXiに一本化されると発表した。このため、ESXを利用しているユーザーは、ESXiへの移行が推奨されている。

　ESXとESXiの差は、サービスコンソールの有無だ。ESXには、Linux（Red Hat Enterprise Linux：RHEL）をベースに、一部の機能を拡張した、サービスコンソールと呼ばれる管理用OSが搭載されている。サービスコンソールは、管理者とのUIだけでなく、サードパーティ製のエージェントやvCenterエージェントを動かすためのプラットフォームとして使われている。

　しかし、ハイパーバイザー上にカスタマイズされたRHELが搭載されているため、ESXのプログラムサイズ自体が大きくなっていた。ESXのプログラムの90％が、サービスコンソールに使われているRHELといわれていたほどだ。

　そこで開発されたのが、ESXから、サービスコンソールとして利用しているRHELを削除し、ハイパーバイザーだけにしたESXiだ。RHELを削除したことで、ESXiのプログラムサイズは約100MBと、非常にコンパクトになった。


ESXとESXiの違いは、サービスコンソールをサポートしているかどうか。ハイパーバイザーの無償エディションは、ESXiのみ（名称がVMware vSphere Hypervisorに変わった）	ESXとESXiは、コードが共通化されている。ただし、ESXには、サービスコンソールとしてRed Hat Enterprise Linux（RHEL）が搭載されている

ESXのアーキテクチャ。ハイパーバイザーのVMkernelは、小さいが、RHELのサービスコンソールのプログラムが大きい	ESXiのアーキテクチャ。サービスコンソールのRHELが搭載されていない分、プログラムサイズが小さくなっている

　ただし、ESXiでは、サービスコンソールがなくなったため、サービスコンソール経由で提供されていた機能を実現するために、改良されている部分もある。

　例えば、リモートアプリケーションからハードウェアを管理するためのインターフェイスとしてCIM（Common Information Model）が採用された。CIMは、CIM BrokerとCIM Providerで構成されており、各ハードウェアベンダーが独自のCIM Providerを開発すれば、自社のハードウェアに追加されている機能（センサーなど）を監視できるようになる。


サービスコンソールが搭載されていないESXiでは、CIMベースのインターフェイスによって、さまざまな管理が行えるようになっている	CIMインターフェイスが公開されたことにより、サードパーティが独自のCIMプロバイダーを追加して、独自ハードウェアの監視が行える

　ESXiもESXと同じくHDDにインストールするのが一般的なインストールだ。

　また、サーバーベンダーが、ディスクレスでブートする組み込み型のEmbeddedタイプがOEM提供され、USBメモリやSDメモリなどにESXiをインストールされている。Embeddedタイプは、OEMへのみ提供されているが、昨年の年末企画で紹介した手順を使えば、個人ユーザーでもUSBメモリやSDメモリでブートするESXiを構築することも可能だ。

■vSphere Clientの統合

　以前紹介していたESXi 4.0では、リモートPCからアクセスするためのvSphere Clientが、ハイパーバイザー側にも収録されていた。ESXi 4.1からは、ハイパーバイザー側には収録されなくなっている。

　しかし、vSphere Clientがなくなったわけではない。ESXi 4.1がインストールされているサーバーにWebブラウザでアクセスすると、vSphere Clientをダウンロードするためのリンクが表示される。ここをクリックするとVMwareのWebサイト（www.vmware.com）から、vSphere Clientのインストール用パッケージをダウンロードすることができる。

　vSphere ClientをVmwareのWebサイトからダウンロードしなければならなくなったが、その分ハイパーバイザー側をコンパクトにすることができているようだ。ちなみに、vCenter Serverのイメージには、vSphere Clientのプログラムファイルが同梱されている。


ESXiには、vCLI、PowerCLIが搭載されている	WebブラウザからESXiをインストールしたサーバーにアクセス。vSphere Clientのダウンロードリンクが表示されている	ダウンロードしたvSphere ClientでESXiサーバーにアクセス

■Tech Support Mode

　前述したように、ESXiはサービスコンソールが削除されたている。しかし、RHELベースのサービスコンソールが削除された代わりに、ESXi 4.1には、Userworldといわれる、限定されたユーザープロセスを実行させるコンソールTech Support Mode（ESXi Shell）が用意されている。Tech Support Modeを利用すれば、ESXiにトラブルが起こった時などコンソールから操作することが可能になる。

　Tech Support Modeは、サーバーのコンソールから直接操作するLocal Tech Support Modeと、SSHを利用してリモートからコンソールを利用するRemote Tech Support Modeが用意されている。


ESXiには、Tech Support Modeというコンソールが用意されている	以前は、隠しコマンドで利用できたが、ESXi 4.1から正式にメニューに追加された

Tech Support Modeというコンソールでは、ESXi Shellが動作している。SSHを使えば、リモートからアクセスも可能。コマンドは、POSIXのサブセット	Tech Support Modeは、このメニューで設定する

■その他の新機能

ESXiでのスクリプトインストールのサポート

　以前はESXでのみスクリプトを使ったインストールがサポートされていた。ESXiは、対話式のインストールしか行えなかった。このため、多数のサーバーにESXiをインストールする場合は、手間がかかった。

　ESXi 4.1では、ESXと同じスクリプトを使ったインストールがサポートされた。これにより、PXEブートを使ってネットワーク経由で、無人インストールが可能になった。ただし、ESXi Embeddedではこの機能は利用できない。

iSCSIからのブート
　ESXi 4.1には、iSCSI Boot Firmware Table（iBFT）を利用したブート機能がサポートされた。この機能を利用するには、iBFTに対応したNICとESXi 4.1が必要になる（ESXでは利用できない）。

　iSCSIブートを利用するためには、NICのオプション設定で、iSCSIを利用するためネットワークの設定やLUNの設定など行う。正しく設定されていれば、ESXiのメニューにターゲットとなるiSCSIのLUNが表示される。このメニューで、ブートするドライブを指定すればOKだ。

ディスクIOのリソース管理
　ESX/ESXi 4.1では、ディスクIOのリソース管理が可能になった。この機能を使えば、仮想マシンが使用するディスクIOのアクセス性能を制限することができる。例えば、開発環境の仮想マシン、それほど優先度の高くない仮想マシンなどが、IOリソースを占有しないようにすることが可能だ。IOリソースの優先度（高、標準、低）を設定すれば、サーバーで動作している仮想マシンのIOアクセスに対する優先度が設定できる（カスタムを使えばIOPSの数値で設定可能）。

CPUコア数を引き上げ
　ESX/ESXi 4.1 Update1では、最大160個の論理プロセッサがサポートされている。先日Intelが発表したXeon E7プロセッサは、10コア（20スレッド）をサポートしている。このE7を8ソケット使用した大規模なサーバーにもvSphere 4.1は対応している。

USBデバイスのパススルー機能
　ESX/ESXi 4.1では、サーバーに接続されたUSBデバイスを仮想マシンがパススルーで利用できるようになった。この機能は、VMware Workstationなどで提供されている機能と同じだ。

　対応しているUSBデバイスとしては、ソフトウェアのプロテクションキーとして使われているUSBのドングルなどが主だ。詳細に関しては、VMwareのHPを参照にしてほしい。

Virtual SMPにおける改良
　以前のESX/ESXiなどでは、仮想マシンにインストールしたOSが古いもので、マルチコア環境へ対応していない場合は、4つの仮想CPUを割り当てても、結局OSが認識する2つ仮想CPUしか認識しないことがあった。

　ESX/ESXi 4.1では、仮想マルチコア構成という機能が追加された。この機能を利用すれば、仮想マシンに4つの仮想CPUを割り当てても、4つのCPUが搭載されたSMP環境ではなく、4つの仮想CPUコアを持つ1ソケットのCPUとして利用できる。この機能を使うことで、古いOSでも、割り当てた4つの仮想CPUが使用できる。

メモリ圧縮機能の搭載
　ESX/ESXi 4.0では、メモリ管理機能として、同じ情報を持つメモリページを見つけて、1つにまとめるメモリ共有機能が搭載されていた。この機能を利用すれば、サーバー上にVDI環境を構築した場合、同じOSが多数仮想マシンにインストールされるため、同じメモリページが多数存在することになる。これを1つにまとめることで、サーバーのメモリ効率がアップした。

　さらに、ESX/ESXi 4.1では、「メモリ圧縮」機能が追加された。物理メモリが不足した場合、ハイパーバイザは一部のメモリページをハードディスク上にスワップアウトするが、ESX/ESXi 4.1ではその前にまず「メモリページの圧縮」を試みる。その結果、元のサイズの2分の1以下になる場合はスワップアウトは行わず、メモリページの圧縮処理を行うことで空き物理メモリ領域を確保する。

　圧縮しても2分の1以下にならない場合は圧縮処理は行わず、従来通りメモリページをディスク上にスワップアウトし、空き物理メモリ領域を確保する。これにより、結果的にメモリ不足になった場合の性能低下を大幅に抑えることができるようになった。

vCenter Serverの64ビット化
　もう1つ重要なアップデートは、vCenter Serverが64ビット化されたことだ。vSphere4.0では、vCenter Serverは32ビットアプリケーションだった。このため、管理できるESX/ESXiホストの数、管理できる仮想マシンの数などに制限があった。vCenter Serverが64ビット化されたことで、管理できる数が大幅にアップした。

　さらに、vCenter Serverが使用するデータベースも64ビット版がサポートされた。これにより、性能もアップしている。

	vCenter 4.0 （32bit）	vCenter 4.1 （64bit）
管理可能なESXホストの数	200	1000
動かせる仮想マシンの数	2000	10000
作成可能な仮想マシンの数	3000	15000

　次回は、vSphere 4.1のネットワークやストレージなど、ハイパーバイザー以外のアップデート部分の機能紹介をしていくつもりだ。その後、実際にvShieldなどをテストしていく予定にしている。