スケーラブルな運用が可能に

64ビットWindowsは仮想化にうってつけ

仮想化がホットなトピックとなっている最大の理由は、仮想化をサポートするインフラが整備できるようになったことだろう。そうしたインフラの要素として64ビットWindowsがある。

公開 2008年07月10日 09時22分

更新 2012年09月04日 18時51分

著者

Christa Anderson

[TechTarget]

印刷する

　仮想化は今ホットなトピックだ――。アプリケーション仮想化、OS仮想化、プレゼンテーション仮想化など、仮想化を実現する技術はいずれも、そのような触れ込みで紹介されているはずだ。

　だが実のところ、これらの技術は以前からあり、登場してかなりの年数がたっているものもある。マルチユーザーWindows技術は1992年からさまざまな形で存在し、Windows 2000でWindowsの主要な要素となった。VMwareは創業以来、仮想化されたサーバやクライアントの普及を推進している。SoftGridは2006年にMicrosoftに買収されるずっと前から、アプリケーションの隔離やストリーミングを行う技術を売り込んできた。人々の支持も広がっていた。

　では、なぜ仮想化は2年前ではなく、2008年の今ホットなトピックとなっているのか。

　幾つかの理由が考えられる。まず、仮想化ソフトウェアの機能がリリースごとに向上しており、その結果、仮想化されたコンピュータのパフォーマンスが、仮想化されていない場合に近づいてきている。また、環境に優しいコンピューティングソリューションへの関心の高まりを背景に、リモートアクセスやサーバ統合への関心も増大している。

　だが、仮想化がホットなトピックとなっている最大の理由は、仮想化をサポートし、仮想化環境のスケーラブルな運用を可能にしながら、高い利便性を提供するインフラが整備できるようになったことだろう。そうしたインフラの要素として、信頼性の高い高速なLANやWANとともに64ビットWindowsがある。

　実際、64ビットWindowsは仮想化を支える重要な要素だ。仮想化の大きなボトルネックの1つはメモリだからだ。物理メモリ（コンピュータに搭載されたDIMM）と仮想メモリ（OSが使用中のデータとアプリケーションを保存する場所）の関係から見てみよう。

　32ビットシステムでは、Windowsは最大4Gバイトの仮想メモリをアドレス指定できる。2Gバイトの仮想メモリが、OSの中核機能をサポートするカーネルモードプロセス間で共有され、残る2Gバイトが各ユーザーモードプロセスに個別に割り当てられ、それらはそれぞれほかのユーザーモードプロセスと隔離される。ユーザーモードプロセスに割り当て可能な仮想メモリアドレスの数は膨大に思えるかもしれない。各プロセスはいずれも、2Gバイトの仮想メモリ領域全体を専用に利用できると認識するからだ。

　しかし、仮想メモリを有効に利用するには、必要になったデータをOSが取り出せるように、メモリマネージャが仮想アドレスを物理アドレスに変換できなければならない。Windowsではこの変換をページング方式で実現している。この方式では、データを保存するページ、ページのインデックスを持つページテーブル、ページテーブルエントリのレコードの組み合わせにより、どのように仮想アドレスを物理アドレスに変換するかが決定される。

　32ビットWindowsの仮想アドレスから物理アドレスへの変換方式では、通常の場合、最大4Gバイトの物理メモリしか利用できない。アドレス長が32ビットだからだ。4Gバイトを超えるデータを扱う場合は、ページファイルというHDD領域へのメモリスワップが必要になる。ページファイルはRAMを補完するが、RAMより低速だ。

　問題は、仮想化されたシステム上では、大量のユーザーモードプロセスが発生することだ。MicrosoftのHyper-VやVMwareのVMware ESXのような技術を使えば、1台のコンピュータ上でのデスクトップ仮想化で半ダース程度のユーザーをサポートできるかもしれない。また、Microsoftのターミナルサービスを使えば、1台のコンピュータ上でのアプリケーション仮想化で数十人、あるいは数百人のユーザーをサポートできるかもしれない。利用するアプリケーションはユーザーによってさまざまだろうし、それらのアプリケーションはすべて、もともとシングルユーザーコンピュータ用に設計されたものだ。仮想化プラットフォームは、メモリをできるだけ節約するように設計されているが、結局、アプリケーションの多大なメモリ要求にさらされる。

　PC仮想化には、ターミナルサーバセッションの場合より大きな問題が付きまとう。個々の接続ユーザーをサポートするには、OS全体を仮想化しなければならないことだ。また、仮想化の機能向上の代償もある。利便性が乏しければ人々は仮想化を採用しないため、機能向上が進められている。だが、仮想化されたプラットフォームが仮想化されていないプラットフォームとほとんど遜色ない機能を提供するのであれば、そのためのリソースが必要になる。例えば、Windows Server 2008のターミナルサービスで提供されるモニタスパニングをサポートするには、シングルモニタの場合より多くのメモリが要求される。表示スペースが大きくなるからだ。

　このため、こうした機能を適切にサポートできる十分なメモリを積んだ効率的な仮想化プラットフォームが必要になる。ターミナルサーバの小規模な導入では、32ビットOSがプラットフォームとして利用されてきた。だが、大規模な導入では、適切なプロセッササポートを備え、I/Oボトルネックの軽減が可能なディスクトポロジを持つ64ビットプラットフォームが必要だ。このことは、デスクトップの代替を目的にOS仮想化を導入する場合にも同様に当てはまる。そのため、MicrosoftのHyper-Vは、64ビットOS上でしか動作しない。ただし、32ビットOSをHyper-Vのゲストとしてインストールすることはできる。

　もちろん、64ビットOSにも難点はある。まず、64ビットプロセスは32ビットプロセスより多くのメモリを使用する。このため、64ビット環境は、4Gバイトを超えるメモリを利用できて便利というよりも、それだけのメモリがすぐに必要になってしまうという面がある。さらに、64ビットOSは64ビットドライバを必要とするが、こうしたドライバはなかなか入手しにくい。しかし、64ビットOSは、導入するには十分な計画を立てる必要があるが、人々が求めている仮想化をサポートするのにほぼ必須だ。それだけに、今後ますます重要な役割を果たすことになる。

本稿筆者のクリスタ・アンダーソン氏は元ターミナルサービスMVPで、現在はMicrosoftのターミナルサービスチームのプログラムマネジャーを務めている。最新の著書「Windows Terminal Services Resource Kit」がMicrosoft Pressから近く出版される。スクリプティングの権威として国際的に有名で、著書として「Windows Terminal Services, The Definitive Guide to MetaFrame XP」など、共著書として「Mastering Windows 2003 Server」などがある。

印刷する