デスクトップの仮想化: 仮想環境への配慮と供給
Wes Miller
仮想化は、以前は一般的なテクノロジではなく、説明を必要としましたが、今ではなくてはならない有益なテクノロジにまで進化しました。おそらく皆さんは、仮想化テクノロジを、品質保証テスト、開発、Web デザイン、およびトレーニングに使用されていると思います。皆さんは、仮想化インフラストラクチャを展開して仮想化へのトレンドを作り出す、先駆者の 1 人かもしれませんし、Amazon.com や、Rackspace Inc.、またはその他のクラウド ベンダーで "クラウド" 仮想化を使用する、大勢のうちの 1 人かもしれません。
用途にかかわらず、仮想化を少しでも使用した経験があるなら、物理ハードウェアの維持にも固有のジレンマがあるように、仮想化にもさまざまな課題があることにお気付きだと思います。その多くは、物理ハードウェアとは異なる問題ですが、似ているものもあります。
ハイパーバイザーについて
"ハイパーバイザー" という言葉は、しばらくの間やたらと使用されていたので、おそらく聞いたことがあるのではないでしょうか。ハイパーバイザーは、仮想化関連のすてきな用語の 1 つでしたが、今は新しいものではなく、仮想マシン (VM) に関してのみ用いる用語になりました。ちなみに、ハイパーバイザーは、1970 年代に IBM が作った言葉です。
ハイパーバイザーとは、システム上で "仮想的に" 実行されているゲストに、一連の仮想化されたハードウェアを提供するソフトウェアで、物理ハードウェアを抽象化して、ゲスト OS で使用できるようにします。ここ数年、Microsoft Hyper-V や VMware ESX Server などの、x86 プラットフォームで実行される "タイプ 1 ハイパーバイザー" が大きな原因となり、混乱が生じました。ほとんどのユーザーが (特にクライアント システムで) 使用するハイパーバイザーは、"タイプ 2 ハイパーバイザー" です。この違いは、次のとおりです。
- タイプ 1 ハイパーバイザーは、ホスト ハードウェアで直接実行され、"ホスト OS" を必要としません。Microsoft Hyper-V と VMware ESX Server は、タイプ 1 ハイパーバイザーの一般的な例です。
- タイプ 2 ハイパーバイザーが機能するためには、ホスト OS が必要です。一般的に、タイプ 2 ハイパーバイザーは、ホスト OS で、主にユーザー モード アプリケーションとして実行されます。Microsoft Virtual PC と VMware Workstation は、タイプ 2 ハイパーバイザーの一般的な例です。
多くの場合、仮想化された SQL Server やファイル サーバーなど、"常時実行する" ワークロードには、タイプ 1 ハイパーバイザーの使用を検討することをお勧めします。最低でも、タイプ 2 よりもリソースの消費量が少なくなるというメリットがありますが、ホストによっては、アプリケーションを実行するためにユーザー ログオンが必要になる場合があり、これはミッション クリティカルなシステムにとっては適切なオプションではありません。一方で、タイプ 2 ハイパーバイザーは、"オンデマンドの" VM で使用するのが適切です。このような VM には、アプリケーションの互換性やセキュリティで保護されたアクセスをテストするための VM などがあります。
仮想化によって節約できるもの
仮想化によって節約できるものは、ハードウェアにかかる費用であるのは明確ですが、実際には言うほど簡単ではありません。確かに、ラックでマウント可能な 1U フォーム ファクターのサーバー システムが 2 台あり、このワークロードを 1 台の 1U システムに読み込む場合は、ハードウェアにかかる費用を前もって節約したことになります。ですが、これにはトリックがあります。これらの同じ 2 台のサーバー システムを、デュアルコア CPU、2 GB の RAM、および 160 GB の SATA ハード ディスクが搭載されている別個の 1U サーバー 2 台に展開する場合は、どちらも正常に実行されます。
一方、この 2 台のサーバー システムを同じハードウェア構成の 1 台のサーバーに展開する場合は、リソースを半分に分割する必要があります。とは言っても、本当に分割しますか。一般的に、タイプ 2 ハイパーバイザーでは、タイプ 1 よりも多くのリソースが必要です。
物理環境から仮想環境にワークロードを統合する方法を検討する際には、必要となる CPU、RAM、および HDD のコストを考慮に入れましょう。"いくつかの" 物理システムへの依存を OEM から取り除くことになるので、仮想化された統合は "システムを平行方向ではなく垂直方向に積み重ねること" だとよく言われます。つまり、仮想化が登場する以前よりも、1 台のシステムに対する要求水準が高くなっています。このことによって、仮想化に向こう見ずに突き進むために多くの組織が考慮に入れない、システム管理への影響がもたらされます。
仮想化によって消費されるもの
以前は、優れた仮想化ソフトウェアはかなり高価でした。しだいに市場での競争が激しくなり、さまざまな種類の仮想化ソフトウェアをかなり安価で手に入れられるようになりました。ですが、ホスト OS やハイパーバイザーなどの、重要なエンタープライズ機能のほとんどは、依然として高価です。
VM で実行することを計画しているワークロードによっては、フェールオーバーについて調べる必要があります。ゲストは破損することがあり、その結果、ホスト ハードウェアで障害が発生することがあります。仮想化によってハードウェアの信頼性が高まるわけではなく、破損する確率が変化するだけです。ミッション クリティカルなシステムについては、引き続き、VM コンテナー自体をバックアップするか (こちらを強く推奨します)、VM コンテナーに含まれているファイル システムをバックアップするかのいずれかの戦略を取る必要があります。
タイプ 2 ハイパーバイザーで、テストまたは開発のために多くのゲスト OS を仮想化しているだけの場合も、一度に (ホスト OS で) 複数のゲスト OS 実行するのに十分な RAM を割り当てる必要があります。ですが、仮想化においてしばしば見落とされる問題は、ディスク領域の消費です。
私は、仮想化をセキュリティの実験台として使用したことがあります。その際に行ったのは、VM で潜在的な攻撃を実行し、それが機能していることを確認して、ハイパーバイザーの復元またはスナップショットの機能を使用して以前のバージョンにロールバックして、再テストを行うだけです。ですが、復元による変更を繰り返すと、ディスク領域が突如制御不能になるという特徴があります。最終的には、ゲスト OS 自体に割り当てられたハード ディスクの実際のサイズをはるかに上回るほど大きくなる可能性があります。
私が頻繁に使用する VM のうちの 1 つは、ハード ディスク イメージのサイズが 50 GB ありましたが、ディスク上のサイズは 125 GB をはるかに上回っていました。移動してみるまで (その VM には、6 つの VMware スナップショットがありました)、なぜ制御不能になったのかわかりませんでした。
次に、仮想化の影響またはコストを最小限に抑えるベスト プラクティスをいくつか紹介します。
- 復元機能のあるタイプ 2 ハイパーバイザーで Windows クライアント OS を使用している場合は、必ず Windows システムの復元を無効にします。この機能が有効になっていると、システムを変更するたびにディスクが拡張します。
- 1 つ目の手順を実行する場合、復元ポイントを作成するときは忠実に区分します。
- セキュリティ テストや攻撃テストを実行している場合は、以前の時点にロールバックするのに Windows の機能を使用しません。一般的には、ハイパーバイザーの復元機能を使用します。これを使用すると、復元ポイントを使用した場合と同じ影響は受けません。
- ゲスト OS を必要最小限のリソースで実行します。
- クライアント OS が RAM をディスクに常時スワッピングする必要がないように十分な RAM を割り当てます。ただし、この結果、ホストだけでなく、すべてのゲスト OS の処理速度が低下することがあります。
- ゲストを内部で最適化して、それから外部で最適化します (詳細については、この後の最適化に関するセクションを参照してください)。両方の最適化を定期的に実行します。
VM の普及
ご覧のとおり、VM の管理はすぐに問題となり得ます。VM を簡単に複製できることは大きなメリットですが、これにより、ゲストの管理、ゲストのセキュリティによる保護、(新しいキー管理機能を活用できる Windows Vista より前の) Windows OS のライセンスの追跡、および企業秘密の漏えいからの保護に関して深刻な問題ももたらします。悪意のある従業員が、デスクトップ システム全体を持ち出すよりも、VM を USB フラッシュ ドライブや USB ハード ドライブに格納して持ち出すのはずっと簡単です。
VM の普及は、(仮想化の内情を理解している) 高度な技術を持った人々の間に特に問題をもたらします。一般的に、VM は、仮想化されたサーバー ゲストではなく、クライアント ゲストとしてより広く普及しています。
システム管理
すべての企業が、仮想化されたシステムの制御を取り戻すことに注目し始めました。マイクロソフトと VMware はどちらも、仮想化の価値そのものよりも、システム管理に意識的に重点を置いてきました。システムは、ただ仮想化しているだけで、なくなったわけではないので、これは重要な点です。
多くのシステム管理製品は、VM でもまったく問題なく実行できますが、いくつかの新しい機能を使用すると、仮想化システムをより適切に管理できます。たとえば、実行しないと更新ができない、ゲストのスリープ解除や更新などを行えます。ゼロデイ攻撃の時代において、これは重要です。あまり使用しない VM を、企業ネットワーク内での、ローカルのボットネットの構成要素にしないようにする必要があります。
システム管理のアプローチでは、ホストとゲストがあることを考慮に入れる必要があり、それぞれが適宜更新され、また、各役割が認識されるようにします。ハイパーバイザーを更新する更新プログラムの管理ソリューションが十分に設計されていないことが原因で、再起動のために真っ昼間からハイパーバイザーを終了し、同時に 4 台のミッション クリティカルなゲスト サーバーも終了するという事態は避けたいはずです。
また、このようなシステムの回復には、これまでと同じアプローチを採用する必要があります。システムを仮想化しても、レジストリの破損や VM 全体の破損が原因でシステムが破損することがないわけではありません。仮想システムのバックアップは、現在行っている物理システムのバックアップと同じくらい熱心に行ってください。
その他の考慮事項としては、ハイパーバイザーに復元機能があるかどうかが挙げられます。更新プログラムの管理について検討する際には、この機能に留意してください。更新プログラムが公開される火曜の翌日の水曜にゲストを更新して、月曜日の復元ポイントまでロールバックすると、理論上は "保護されていた" ゼロデイ攻撃による攻撃を受けることになります。復元テクノロジが、ハイパーバイザーにおけるディスク全体の以前の状態にロールバックすることで機能することを考慮すると、これは大きな問題です。というのも、以前の状態にロールバックすると、Windows や アプリケーションに適用した更新プログラムや、ウイルス対策シグネチャが失われてしまうからです。
セキュリティ ソフトウェア
復元機能とは別に、物理マシンと同じセキュリティ保護と +α を、仮想化されたゲストにも実装する必要があります。外部からの脅威に関しては、VM も物理コンピューターと同じくらい影響を受けやすく、特に違いはありません。
ですが、(常時実行していない) 重要度の低い VM では、更新プログラムやウイルス対策更新プログラムがタイムリーに適用されない点が大きく異なります。結果として、このような VM は、ゼロデイ攻撃にとって、たいへん大きな追跡できない標的となる可能性があります。これが、成熟したシステム管理ソリューションを使用すべき理由です。そのようなシステム管理ソリューションでは、上記の点が考慮され、仮想システムにも更新プログラムを適用できます。
内部の脅威はまた別の問題です。VM は、知的財産が盗まれるきっかけとなるおそれがあります。制御されていないホストで実行している VM は、データの抜け穴となる可能性があるので、この点を理解するのは重要です。まず、仮想環境が簡単にコピーできる場合は、そこに問題があります。これは特に、データへのアクセスを制御する規制遵守の要件に対応する必要がある場合に問題となります (これについては、私が執筆した 2008 年の記事、https://technet.microsoft.com/ja-jp/magazine/2008.06.desktopfiles.aspx で解説しています)。
2 点目に、私が執筆した RMS と IRM に関する記事 (https://technet.microsoft.com/ja-jp/magazine/2008.11.desktopfiles.aspx) から思い出していただけるかもしれませんが、これらの制御は、画面のキャプチャ、印刷などを防止するために、OS の機能を使用します。ですが、これらの制御はハイパーバイザーには対応していません。つまり、RMS で保護されたコンテンツがゲスト OS で表示される場合、ホスト OS ではスクリーンショットのキャプチャや画面のビデオ キャプチャの作成が可能になります。
技術的にはアナログではありませんが、この抜け穴は、"アナログの落とし穴" と別物というわけではありません。DRM で制御されているコンテンツを、このように悪用されることから保護する方法はわかりません。現実的には、もし保護できたとしても、今度は、コンテンツを同じように "悪用" できる、カメラやビデオ カメラを持っているユーザーからの保護という問題に直面します。
ディスクの最適化
ディスクの最適化は、VM に特異な問題です。次にその理由を示します。
- 一般的に、最適化には 2 つのレベルあります。私が "主要な最適化" と呼んでいる、仮想化されたディスク コンテナー自体において行われる最適化 (各ゲスト自身が対応する最適化) と、"二次的な最適化" と呼んでいる、ホスト OS のディスク上にある仮想化されたディスクを含む物理的なファイルの最適化です。
- 必要最小限のサイズで、"オンデマンド" に拡張するディスクを使用する仮想化製品では、二次的な最適化が必要になります。
- 復元機能では、ディスクが急速に膨張するだけでなく、二次的な最適化が大規模に行われます。ホスト OS のディスク領域がさらに消費され、各ゲストが使用可能なセクターを求めて競合し始めることが原因です。
- オンデマンドに拡張するディスクの大半には、必要なディスク領域が縮小するとディスクが圧縮されるという機能が用意されていません。40 GB を割り当て、最初は 10 GB しか使用せず、その後 35 GB を必要とするようになっても、ディスクは自動的には回復しないので、二次的な最適化を行う可能性の高い大きなファイルがあることになります。
仮想ディスク全体の大きさ、仮想ディスクのサイズが変化する速度、および仮想ディスクが 2 種類の最適化に影響されやすいという事実を踏まえると、最適化については、仮想システムは物理システムよりも力を入れて扱う必要があるのがわかります。
ファイルを保護するアプローチを 1 つ紹介します。
- 復元テクノロジの使用は最小限に抑えます。復元テクノロジは、ディスク ファイル全体の過剰な拡張を引き起こします。また、ホストでは仮想ディスクを構成するファイルを最適化できますが、ゲストでは復元テクノロジを簡単に最適化できません。
- まず、適切なディスクの最適化製品をゲストで使用して、定期的に実行します。
- オンデマンドのディスク拡張テクノロジを使用している場合は、次のいずれかを実行します。
a. Sysinternals の sdelete.exe ユーティリティを、sdelete –c <ドライブ文字> というコマンドを実行して使用します。<ドライブ文字> の部分は、ゼロ設定するボリュームを指定します。たとえば、sdelete –c C: というコマンドを実行すると、最適化後に、使用していないディスク領域をすべてゼロ設定します。
b. 仮想ディスク圧縮テクノロジ (ベンダーが提供している場合) を使用して、仮想ディスク コンテナーのサイズを最小限に減らします。 - VM が格納されているホスト OS のボリュームを最適化します。
多くの人がディスクの最適化を軽視しています。2007 年に執筆したディスクの最適化に関する記事 (technet.microsoft.com/ja-jp/magazine/2007.11.desktopfiles) に対して読者の皆さんから膨大な数のメールが寄せられたことからも明らかなように、ディスクの最適化はしばしば誤解を招くトピックです。ですが、仮想化システムにおいても、無視されてはいけない問題です。
今後も、仮想化がますます重要になり、広く使用されるようになるにつれ、仮想化に固有の意図していない複雑さとコストを理解しないまま、今よりも容易く "統合" というメッセージに押し流されてしまうでしょう。この記事によって、仮想化に移行したり、仮想化を維持する場合に考慮する必要がある追加のコストの一部について理解していただけたなら、さいわいです。
Wes Miller は、テキサス州オースティンにある CoreTrace 社 (CoreTrace.com、英語) の製品管理責任者です。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャーとして働いていました。Miller の連絡先は、technet@getwired.com (英語のみ) です。