はじめに
「最近、仮想マシンの動作がもっさりする……」 「システムの応答速度が急に落ちた……」
その原因、もしかすると 「ホストの物理メモリ不足」 が原因かもしれません。
VMware ESXi には、搭載している物理メモリの限界を超えて仮想マシンを動かすための、高度なメモリ管理機能が備わっています。 その中でも、物理メモリが足りなくなった時に発動する「救済措置」の一つが、今回解説する 「メモリバルーニング（Memory Ballooning）」 です。
名前は「風船」で可愛いのですが、実はこれが頻発している環境は 「黄色信号」 が灯っている状態。仕組みを知らずに放置すると、最悪の場合、システム全体が激重になる「スワップ」を引き起こす可能性があります。
本記事では、この「バルーニング」の仕組みをイメージ図とともに分かりやすく解説し、現場ですぐに使える確認方法を紹介します。
- メモリバルーニングの仕組み（なぜ風船？）
- vSphere Client と esxtop コマンドでの確認方法
- バルーニングが発生したら危険？判断基準と対処法
メモリバルーニングとは？
「メモリバルーニング」という名前は、文字通り「風船（Balloon）」が膨らむ動きに由来しています。 一言で言えば、「メモリが余っている仮想マシンから、こっそりメモリを回収して、足りない仮想マシンに回す技術」です。
ゲスト OS からメモリを「借りる」技術
通常、仮想マシン（ゲスト OS）は、割り当てられたメモリを「自分のもの」だと思っています。 しかし、ホスト（ESXi）全体の物理メモリが足りなくなった時、ESXi は以下のような手順でメモリを回収します。
ESXi が、メモリに余裕のある仮想マシンの VMware Tools（の中にあるバルーンドライバ）に指令を出します。
バルーンドライバが、ゲスト OS の中で風船のように膨らみ始めます（メモリを確保します）
ゲスト OS は「ドライバがメモリを使っている」と認識し、その領域を明け渡します。ESXi は、この「中身が空気（ダミー）の領域」に対応していた物理メモリを回収します。
回収した物理メモリを、本当にメモリが足りなくて困っている別の仮想マシンに割り当てます。
バルーニングは「黄色信号」
「便利な機能やん」と思われたかもしれません。確かにバルーニングは、物理メモリの限界を超えて仮想マシンを動かす（オーバーコミット）ための優れた機能です。
しかし、運用管理者にとっては「黄色信号（注意）」と捉えるべきです。
- バルーニング発生＝物理メモリが枯渇している
-
そもそもホストの物理メモリに余裕があれば、バルーニングは発生しません。これが起きている時点で、ホストは「カツカツの状態」です。
- 「スワップ」の入り口
-
バルーニングでもメモリが足りなくなると、ESXi はついに「ホストスワップ」（メモリの中身を強制的にHDD/SSD に書き出す処理）を始めます。こうなると、システムのパフォーマンスは劇的に低下（赤信号）します。
つまり、バルーニングは「スワップという最悪の事態を防ぐための、最後の砦」なのです。
メモリバルーニングの確認方法
バルーニングが発生しているかどうかを確認するには、大きく分けて2つの方法があります。 状況に合わせて使い分けるのがエンジニアの定石です。
- vSphere Client（GUI）: 過去に遡って傾向を分析したい時
- esxtop コマンド（CLI）: 今まさに起きている問題をリアルタイムで調査したい時
【GUI】vSphere Client（パフォーマンスチャート）で見る
「昨日の夜、システムが重かったらしい」といった場合、過去のログをグラフィカルに確認できる vSphere Client が便利です。 （※ここでは、現在主流の HTML5 ベースの vSphere Client での手順を解説します）
- vSphere Client で対象の 仮想マシン または ESXi ホスト を選択します。
- [監視（Monitor）] タブをクリックし、サイドメニューから [パフォーマンス（Performance）] を選びます。
- [詳細（Advanced）] ボタンをクリックします。
- 右上の [チャート オプション（Chart Options）] をクリックします。
- [メモリ（Memory）] を選択し、カウンタの中から [バルーン（vmmemctl）] にチェックを入れます。
これでグラフが表示されます。 通常、このグラフは「0」で平坦ですが、ここが山のように盛り上がっている時間帯があれば、その時にメモリバルーニングが発生していた（＝物理メモリが枯渇していた）ことになります。
【CLI】esxtop コマンドでリアルタイムに見る
現場のエンジニアがトラブルシューティングで愛用するのが、SSH で接続して使う esxtop コマンドです。 GUI よりもリアルタイム性が高く、より詳細な「生の数字」が見えるため、「今まさに重い！」 という時はこちらを使います。
- SSH で ESXi ホストにログインします。
- 以下のコマンドを実行します。
esxtop- 画面が表示されたら、キーボードの
mを押します（メモリ表示モードに切り替え）。 - 画面上の項目から
MCTLSZという列を探します。
- MCTLSZ（Memory ConTroLler SiZe）: これが「バルーンドライバによって膨らませられた（回収された）メモリサイズ（MB）」です。
GID NAME ... MCTLSZ ...
123 vm-server1 ... 1024 ... <-- 1GB 回収されている！
456 vm-server2 ... 0 ... <-- 正常（0MB）もし、この MCTLSZ の数値が 0 以外の数字（例: 1024 など）になっている場合、その仮想マシンは現在バルーニングの対象となっており、メモリを強制的に回収されている状態です。
バルーニングが発生した時の対策
「バルーニングが発生している＝物理メモリが枯渇している」ことが確認できたら、放置せずに以下の対策を検討しましょう。
まずは「リソース割り当て」を見直す
物理メモリが足りないのではなく、「設定」によって意図的にバルーニングが引き起こされているケースがあります。
- 制限（Limit）」がかかっていないか確認する
-
仮想マシンの設定で、メモリの「制限」が設定されていませんか？ 例えば、4GB のメモリを割り当てているのに、制限を「2GB」に設定していると、ESXi はその VM に対して 2GB 以上の物理メモリを使わせないように、強制的にバルーニング（やスワップ）を発動させます。 意図しない制限であれば、「無制限」に戻すことで即座に解決します。
- 予約（Reservation）」を検討する
-
データベースサーバーなど、絶対にパフォーマンスを落としたくない重要な仮想マシンがある場合、メモリの「予約」を設定します。 予約された容量分の物理メモリは常に確保（ロック）されるため、その VM に対してバルーニングが発生することはなくなります。 （※ただし、他の VM が使えるメモリが減るため、全体のバランスには注意が必要です）
物理メモリの増設か、VM の移動（vMotion）
設定に問題がなく、純粋にホストのリソース不足である場合、根本的な解決が必要です。
- VM の移動（vMotion / DRS）
-
クラスタ内の他のホストにメモリの余裕があるなら、vMotion で仮想マシンを移動させましょう。DRS（自動負荷分散）が有効なら自動で行われますが、手動で逃がすことも有効です。
仮想マシンを無停止で別ホストへ移行させる「vMotion」の仕組みや実行要件については、以下の記事で詳しく解説しています。
あわせて読みたい
【VMware】vMotion とは？3つの種類（Storage・Cross vCenter）と実行要件 はじめに VMware vSphere 環境において、仮想マシンを稼働状態のまま別の物理サーバーへ移行するライブマイグレーション技術が「vMotion」です。ハードウェアのメンテナ… - 物理メモリの増設
-
どのホストもパンパンで移動先がない場合、解決策は一つしかありません。物理メモリ（RAM）を買って増設してください。 ソフトウェアの工夫には限界があります。ハードウェアへの投資が、結局は一番コストパフォーマンスの良い解決策になることも多いです。
まとめ
本記事では、VMware のメモリバルーニングについて解説しました。
- バルーニングはゲスト OS 内でメモリを確保し、ホストへ物理メモリを返却する仕組みです。
- 動作自体は正常ですが、ホスト側の物理メモリが枯渇していることを示すサインです。
esxtop等で状況を監視し、vMotion による負荷分散やメモリ増設で対処します。
以上、最後までお読みいただきありがとうございました。
