VMware環境では、この問題にあまり悩まずに済むかもしれない。VMware ESXでメモリがオンデマンドで提供されるからだ。仮想マシン（以下、VM）は、設定時に指定された最大メモリ割り当て量を上限として必要な分だけメモリを使用する。例えば、最大8GバイトのRAMを割り当ててVMを作成し、このVMがRAMを1Gバイトしか使っていないときは、カーネルが残りの7Gバイトを他のVMに割り当てることが可能だ。これに対し、これまでHyper-Vでは、VMにメモリ容量を固定的に割り当てることしかできなかったため、リソースの利用に無駄が生じていた。8Gバイトを割り当てた場合、VMの電源を入れるだけで8Gバイトが必要になった。

　一方、VMware ESXではVMのスワップファイル用にデフォルトで8Gバイトの空きディスク容量が必要になる。それはなぜか。結局のところ、これらのリソースはどこかで確保しておかなければならないからだ。VMがメモリブロック（物理メモリまたはスワップメモリ）を要求しているが空きメモリがないという状況は、絶対に避けなければならない。そのような状況になるとVMはクラッシュしてしまう。

　空きディスク容量の方が空きRAM容量よりも確保しやすいのは明らかであり、VMwareのスワップファイルは、RAM不足によるトラブルを軽減するために安価なストレージに配置できるようになっている。とはいえ、RAM不足によるスワップが頻発する状況も、やはり避けなければならない。VMware方式でVMにメモリを割り当てる場合の悩みは、一部のアプリケーションが割り当てられたメモリを最大限使用するように設計されていることだ。この手のメモリを食うアプリケーションが稼働するVMに最大8GバイトのRAMを割り当てると、それらは8Gバイトを丸々使ってしまう。VMwareがメモリオーバーコミット機能を宣伝する一方で、顧客に対してVMの“ライトサイジング”と適切な環境監視を行うことを推奨しているのはそのためだと思う。こうした悩みがあるため、管理者は仮想ストレージを監視しなければならないのと同様に、仮想メモリを監視する必要がある。

バルーンドライバの使い方の違い

　このようなベンダー間の考え方の違いから、製品ごとに固有の方法でバルーンドライバが使われている。VMware環境では、メモリが不足した場合にのみバルーンドライバの出番となる。このため、バルーニングが一切行われないのが本来はベストだ。バルーニングの際には、バルーンドライバがゲストOSのメモリ管理機能を利用するため、この認識は重要だ。

　バルーンドライバがゲストOSのメモリ管理機能を利用することは、VMware環境だけでなく、バルーンドライバを用いる全ての技術に共通しており、その点で全てのハイパーバイザーベンダーに関係がある。だが、VMware環境でのバルーニングにはゲストOSでスワップを発生させるというデメリットがある。スワップの発生は、回収するメモリの量や、VMに提供されるストレージのIOPS（I/O per Second：1秒当たりに処理できるI/Oアクセス）性能によっては、パフォーマンスに影響を与える可能性がある。

　Microsoftのバルーンドライバは、VMにRAMをオンデマンドで割り当てることを目的としている。これは、VMware ESXがホットアドメモリ機能でバルーンドライバを使用するのと似ている（ただし、VMware ESXのバルーンドライバの使い方の方が、よりダイナミックだ）。Microsoftは、メモリの必要量が1日を通じて変動することから、バルーンドライバを使って、あるVMからメモリを回収し、別のVMに割り当てられるようにしていると述べている。どのVMに一定量のRAMを割り当てるかを判断するシステムは、メモリバランサーと呼ばれる。

図1　Hyper-VのDynamic Memoryのアーキテクチャ《クリックで拡大》

　MicrosoftにとってのDynamic Memoryは、システムを稼働状況に応じて最適化するとともに、適切な量のメモリが割り当てられているかどうかというユーザーの心配を軽減するためのものだ。このモデルは、Microsoft技術が妥当なメモリ要求を識別することによって成り立つ。識別できないと、悪意ある人物が、メモリリークによってメモリ要求が増加していくアプリケーションを故意に作成するかもしれない。このDynamic Memory機能は現在、ゲストOSが以下のWindowsでなければ利用できない。

• Windows Server 2003／2008／2008 R2（32／64ビット版）
• Windows Vista／Windows 7のEnterprise／Ultimate Edition（32／64ビット版）

　VMwareのメモリ管理の優れている点は、メモリ管理の多くがゲストOSの外部で行われるため、メモリが幅広いゲストOSに提供されていることだ。また、VMwareは、非常に多様なOSに対応したバルーンドライバを自社で作成している。

改善の余地

　「Microsoft「Dynamic Memory」のライバルはVMwareではなくCitrix Systems（後編）」の結びで述べたように、Dynamic Memory機能がHyper-Vに追加されるのは歓迎すべきことだ。メモリ管理という仮想化の重要な領域におけるMicrosoftのこれまでの対応は芳しいものではなかっただけになおさらだ。しかし、考慮すべき重要な制約が依然として残っている。

　1つの問題は、Hyper-V R2 SP1では仮想マシンが物理メモリの容量を上回るメモリを要求する可能性があることだ。このため、Microsoftは親パーティションにメモリを割り当てる方法（“ルート予約”と呼ばれることもある）を変更しなければならなかった。この変更が行われなければ、VMが物理サーバの管理パフォーマンスを低下させる恐れがあった。

　VMwareのようなハイパーバイザーベンダーは、この問題に以前から対処してきた。例えば、VMware ESX Classic（従来型のVMware ESX）では、サービスコンソールがシステム上のメモリ容量全体に関連するメモリ予約を受ける。Hyper-V R2 SP1では、予約はMicrosoftレジストリで行われる。Windows管理者はこのレジストリキーにより、デフォルトのメモリ割り当てを調整できる。

　逆説的なことに、このことから、Hyper-Vを使用する顧客は、既存Hyper-VサーバにSP1を適用すると問題にぶつかる恐れがある。すなわち、起動するVMがこれまでより少なくなるかもしれない。これは、リブート後、新しいレジストリ設定で親パーティションのためにメモリが予約され、それに伴ってVMが使用可能なRAMの総量が減少することによって起こる問題だ。この問題は、Hyper-Vホストを最大に近い負荷で稼働させる少数の顧客に影響する。

　もう1つの問題は、Hyper-V R2 SP1では、稼働中のVMについてメモリのバッファと割り当て優先度の設定は変更できるが、スタートアップRAM（起動時のメモリ割り当て量）と最大RAM（メモリの最大割り当て量）の値を増減することはできないことだ。ほとんどの慎重な管理者は、最大RAMをデフォルトの64Gバイトよりずっと小さく設定するだろう。その場合、VMがその設定されたメモリ量を使用し、バッファも全て使用したら、そのVMを停止してメモリ割り当て量を手動で増やすしかない。

　この制約は、Hyper-VやXenServerが「動的」メモリ管理を実現するという主張を少々損なうものだ。それは幾つかの点で、われわれが過去に経験した不毛な努力にまた陥っていると私には思われる。メモリの適切な最大割り当て量とは何か。それは、アプリケーションをよく理解し、そのライトサイジングを実現することによってのみ判断できることだろう。無数のVMware管理者がVMware ESX Server 2.0のころから行ってきたように。

本稿筆者のマイク・ラベリック氏はVCP（VMware Certified Professional）の資格を持つエキスパートで、受賞経験も有する。2003年からVMwareコミュニティーに関わっている。VMwareフォーラムの管理者ならびにロンドンのVMwareユーザーグループの運営委員を務める。VMware ESX／VirtualCenterユーザー向けに無償のガイドとユーティリティを提供するWebサイト「RTFM Education」を運営する。