容量変化の理由

容量変化の理由

ESXで約2GBも必要であった容量が、ESXiで中核機能はそのままに一気に32MBという驚異的なサイズにできたことには理由があります。

VMware社が開発したサーバー仮想化コア部分（VMKernel etc.）は、サーバー単独でその操作や管理をしたり、他社が開発するバックアップエージェントや監視エージェントなどをプラグインで利用するためには、管理用のOS環境を構築する必要がありました。

そのため、VMware社はソースが公開された汎用的なOSであるLinuxを利用して、Service Consoleと呼ばれる管理用のOS環境としてESXを構成しています（原稿執筆時点（2008年8月）の最新バージョンではRedHat Enterprise Linux 3がベースとなっています）。

実は、このService Console環境がESXの総容量の約98%を消費しており、ESXiではこの部分を取り除き、必要最小限の機能だけに研ぎ澄ますことで、32MBという容量を実現しているのです。

ESXとESXiの違いは運用にあり

ESXiでは、ESXのService Consoleにあたるものがないため、その管理方法にいくつかの違いがあります。

例えば多くの仮想サーバーを半自動的に停止する場合や、スナップショットを作成する場合、ESXではサーバーのコンソール画面からコマンドを実行したり、sshで直接Service Consoleに接続して作成しておいた汎用的なshell scriptを実行することで実現していました。

Service Consoleが無くなったESXiでは、Remote CLI（Command Line Interface）が、その代替として用意されています。Remote CLIをESXサーバー以外のほかのサーバーやクライアント環境にインストールすることにより、リモート環境から同様の操作ができるようになります。

Remote CLIはWindowsやLinuxにもインストールできるように対応していますし、バーチャルアプライアンスとしても公開されており、非常に簡単に従来のESXと同等の環境が構築可能です。その構成方法や利用方法については、次回以降で解説します。

そのほか、Service Console自体にインストールすることにより、実現していた機能を代替案に変更していく必要もあります。例えば、Service Consoleにインストールする必要のあるタイプのバックアップソフトウエアや、UPSの管理ソフトウエアなどがこれに該当します。いずれも、VMwareが用意するAPIを利用した、リモート環境からの管理方法に対応していくものと思われます。

また、本番環境での運用を考えるとパッチの適用は非常に重要です。特に昨今ではセキュリティーが重要視され、日々多くの脆弱（ぜいじゃく）性を修正するためにパッチがリリースされています。これは、RedHat Enterprise Linux 3をベースとしたService Consoleを持つESXについても同様で、本来のVMwareの仮想化コア部分に関係のない修正であっても、このService Console部分に対して多くのパッチを適用する必要がありました。その数はESXに提供されるパッチの50%以上を占めています。

ESXiは、Service Console部分がないため、こうしたパッチ適用の必要性が大幅に減ります。単純計算で、これまでのESXと比較すると、パッチ適用のために計画停止をしなければならない回数も半分以下に低減され、ひいては運用負荷の低減につながります。

次は、ESXiの設計思想について紹介します。