目次


オーバーコミットを使用した KVM ホストでのリソース管理

リソースをオーバーコミットしてワークロードを統合する

Comments

仮想化は、ワークロードを統合できるようにすることによって、効率性の向上を約束します。しかし、仮想マシンの集約密度を最大限に高めると同時に、優れたパフォーマンスを維持するのは、極めて難しい課題となる可能性があります。その理由としては、以下の 2 つが挙げられます。

  • ワークロードによるリソース (CPU、メモリー、ネットワーク帯域幅やストレージ・アクセスなど) の使用率は、時間によって変化します。これらのリソースを需要に応じて動的に割り当てることができれば、オーバーコミットによって仮想マシンの集約密度をさらに高めることが可能です。
  • 最適なリソース管理もまた、システムの構成やハードウェアのセットアップなどといった要因に左右されます。

この両方の要素に対応した管理ストラテジーを開発する 1 つの方法は、ポリシー言語で一連のルールを作成することです。作成したポリシーをそれぞれ固有の条件に合わせてチューニングすれば、統合とパフォーマンスという 2 つの目標のバランスを効果的にとることができます。

この記事では、オーバーコミットを積極的に推し進めるのに伴う問題について詳しく探り、これらの問題に対処するための手段として、ポリシー駆動型管理ツールを提案します。そして、このツールを一般的な KVM 環境にデプロイし、2 つの異なるワークロードを管理します。さらに、この演習の結果を評価し、最後に締めくくりとして、その他の作業項目および将来性のある研究テーマを提案します。

オーバーコミットに伴う問題

KVM でのメモリー・オーバーコミットを徹底的に調査するには、Linux のメモリー管理自体を調べることから始めなければなりません。Linux は仮想メモリーの概念に基づくことから、意図的にメモリー・オーバーコミット技術を採用しています。

プロセスによって要求されたメモリー・ページは、実際に使用されるまで割り当てられません。代わりに Linux のページ・キャッシュを使用して、複数のプロセスが共有ページを介してファイルにアクセスすることによって、メモリーを節約します。メモリーが使い果たされると、システムは使用頻度の低いページをディスクにスワップアウトしてメモリーを解放します。完璧とは言えませんが、これらの手法により、割り当てられるメモリーの量と実際に使用されるメモリーの量との間に大きな差が生まれます。

KVM 仮想マシンは通常のプロセスであるため、標準的なメモリー管理技術が適用されます。けれども通常のプロセスとは異なり、KVM ゲスト内にはオペレーティング・システムがネストされています。このことは、メモリー・オーバーコミットに 2 つの重要な面で影響を及ぼします。KVM ゲストでは、通常のプロセスよりもメモリー・オーバーコミットの対象になる可能性が高くなります。なぜなら、ゲストの最小メモリー要件と最大メモリー要件には、使用量の変動によって大きな差が開くためです。

この変動を十分に利用することが仮想化の魅力の中核となりますが、これは必ずしも簡単なことではありません。ホストが KVM ゲストに割り当てるメモリーを管理していると同時に、ゲスト・カーネルも同じメモリーを管理しています。ホストとゲストとの間に何らかの連携が取れていなければ、ホストのメモリー・マネージャーも、ゲストのメモリー・マネージャーも、キャッシングとスワッピングに関して最適な決定を下すことができません。このことから、メモリー使用の効率性が低下し、パフォーマンスが劣化する可能性があります。

Linux では仮想化に特有のメモリー・オーバーコミットに対処するために、さらに以下のメカニズムを追加しています。

  • メモリー・バルーニング: ホストがゲストに対し、割り当てられたメモリーの一部を解放するように命令することで、その解放されたメモリーを別の用途に使用できるように、ホストとゲストが協力して行う手法です。この手法は、メモリー・プレッシャーの対象をホストからゲストに転換するのに役立ちます。
  • KSM (Kernel Same-page Merging): カーネル・スレッドを使用して、事前に特定されたメモリー領域を走査し、同一内容のページを 1 つのページにマージして重複するメモリー領域を解放します。このようなメモリー共有によって最も利益を得られるのは、多数の一様な仮想マシンを実行するシステムです。
  • その他のリソース管理機能: 例えば Cgroups には、仮想マシンの間で動的にリソースを入れ換えられるメモリー・オーバーコミットのアプリケーションがあります。

これらのメカニズムは、オーバーコミットされたメモリーを効果的に管理するためのフレームワークとなりますが、すべてのメカニズムに共通する重要な制約があります。それは、構成およびチューニングを外部エンティティーによって行わなければならないことです。仮想スタックの個々のコンポーネントにはチューニングの決定を行うだけの情報がないため、自動構成を使用することはできません。

例えば、ホストのメモリーが不足しているかどうかを判断し、パフォーマンスに悪影響を与えることなくゲストからバルーニングするメモリーの量を決定するには、単一の QEMU プロセスだけでは対処しきれません。これらの決定を行うには、管理ポリシーと、ホストとそのゲストに関するリアルタイムの情報を組み合わせなければ不可能です。

KSM でのこの問題を解決するため、メモリー共有の可能性とメモリーの必要に応じてチューニング可能なパラメーターを動的に管理する、ksmtuned というデーモンが作成されました。けれども、ksmtuned は 1 つのメカニズムを単独で管理することから、包括的なソリューションの一部として組み込むことはできません。

どのオーバーコミット・メカニズムにしても、それを使用することで、ホストとゲストのメモリー管理システムの操作に抜本的な影響を及ぼします。したがって、複数のメカニズムを同時に使用すると、副次的な影響が出ることはほぼ確実です。図 1 に、メモリー・バルーニングと KSM との相互作用を示します。

図 1. メモリー・バルーニングが KSM に与える影響
メモリー・バルーニングが KSM に与える影響
メモリー・バルーニングが KSM に与える影響

上記の例では、バルーニングのプレッシャーが増えると、KSM のページ共有能力が弱まってきます。ゲストのバルーン・ドライバーは、ホスト・ページを共有できるかどうかを考慮することなく、バルーニング対象のページを選択します。しかし共有ページをバルーニングするのは誤りです。それは、実際にメモリーを節約することなく、ゲストからリソースを取り上げることになるからです。効率性を最大限にするためには、このような相互作用を予測して管理する必要があります。

それぞれに異なる目標を達成するように設計されたアーキテクチャーを使用することで、無数の構成に KVM ベースの仮想化をデプロイすることができますが、仮想マシンの統合を次々に推し進めていくと、パフォーマンス面での妥協が必要になります。人々は状況に応じて、仮想マシンの統合とパフォーマンスとのバランスを取っています。

メモリー・オーバーコミットは、メモリー以外のすべてのシステム・リソースの需要を増加させることになります。メモリー・キャッシュに対するプレッシャーによって、ディスクまたはネットワーク I/O が増大することになり、ページ回収アクティビティーの増加は、ゲストが使用する CPU サイクルの増大につながります。

これらの問題に対処するのが、メモリー・オーバーコミットを管理するために新しく設計されたデーモン、MOM (Memory Overcommitment Manager) です。

MOM による動的管理

図 2 に、MOM (Memory Overcommitment Manager) デーモンを示します。

図 2. MOM (Memory Overcommitment Manager)
MOM (Memory Overcommitment Manager)
MOM (Memory Overcommitment Manager)

MOM は、ホストおよびゲストの統計収集、ポリシー・エンジン、そしてバルーニングと KSM の制御ポイントのための柔軟なフレームワークを提供します。MOM では、管理者がリアルタイムの状態に応じて動的にシステムのチューニング可能パラメーターを調整するオーバーコミット・ポリシーを構成し、一層優れたレベルのメモリー・オーバーコミットを実現することができます。

MOM は libvirt を使用して、ホストで稼働する仮想マシンのリストを管理し、ホストとゲストに関するデータを一定の収集間隔で収集します。データは、複数のソースから収集することが可能です (ホストの /proc インターフェース、libvirt API、virtio-serial、またはゲストとのネットワーク接続)。収集されたデータはポリシー・エンジンで使用できるように編成されます (ネットワークおよびディスク・デバイス・ドライバーの標準は virtio です。この場合、唯一ゲストのデバイス・ドライバーだけが仮想環境で実行していることを「認識」し、ハイパーバイザーと連携してゲストがハイパフォーマンスのネットワークおよびディスク操作を実現できるようにします。要するに、virtio が、準仮想化のパフォーマンス面でのメリットの大部分をもたらすということです)。

ポリシー・エンジンは基本的に、単純なポリシー言語で作成されたプログラムを理解する小さなインタープリターです。MOM は、ユーザーが指定したポリシーを、収集されたデータを使用して定期的に評価します。ポリシーにより、ゲストのメモリー・バルーンの膨張や KSM 走査レートの変更などといった構成の変更がトリガーされる場合もあります。

MOM フレームワークは、この分野での開発が進むにつれ、追加データ・ソースからデータを収集し、新しいメモリー・オーバーコミット・メカニズムを制御するように拡張されていくはずです。

MOM の評価

MOM と、オーバーコミットされたメモリーの管理における MOM の効率性とを評価するため、これから 2 つの仮想化ワークロードを検討します。

  • 最初に検討するワークロードでは、事前に規定されたメモリー・アクセス・パターンに応じて量が変化する匿名メモリーを使用するように仮想マシンが構成されています。
  • 2 番目に検討するワークロードでは、LAMP ベンチマークを使用します。このベンチマークでは、各仮想マシンが独立した MediaWiki インスタンスとして機能します。

2 つのワークロードのそれぞれについて、メモリー・バルーニングと、KSM を制御する MOM ポリシーを評価します。ホストのスワッピングを避けるために、各ゲストのメモリー・バルーンはホストとゲストのメモリー・プレッシャーに応じて動的に調整します。KSM の調整は、メモリー・プレッシャーおよび共有可能なメモリー量に基づき、ksmtuned と同じアルゴリズムを使用して行います。

2 つのワークロードのシナリオ

Memknobs ワークロードのシナリオでは、Memknobs という単純なプログラムを使用してメモリー・プレッシャーを生み出します。その方法は、カーネルのメモリー回収アルゴリズムに対抗するパターンで、匿名メモリー・ページを割り当て、アクセスするというものです。Memknobs は一定サイズのバッファーを割り当て、そのバッファーのページをループ処理して各ページに書き込みます。繰り返し処理ごとにバッファーのサイズを少しずつ変えながら Memknobs を繰り返し呼び出すことで、ゲストは I/O コンポーネントなしでメモリーにバインドしたワークロードをシミュレートすることができます。ホストにメモリーをオーバーコミットするために、個々のインスタンスが固有のパターンでメモリーを使用する 32 の仮想マシンに Memknobs をデプロイしました。

Cloudy ワークロードのシナリオでは、Cloudy というオープン・スイートを使用して、ディスク I/O コンポーネントで現実的なワークロードを生成しました。Cloudy は簡単にセットアップできる LAMP ベンチマークです。Cloudy は、仮想化のスケーラビリティーを測定してリソース・オーバーコミットによる影響を明らかにします。このシナリオでは、複数の仮想マシンを MediaWiki サーバーとして構成し、Wikipedia のページで各ウィキをロードして、ランダムにイメージ・データを生成します。

このシナリオでは、すべてのインスタンスを使用した状態でスループットと応答時間を測定するために、JMeter テスト計画が組み込まれています。JMeter テスト計画は、定常状態のワークロードを生成するようにも、複数の仮想マシン・グループの間で負荷を交互に変えてワークロードに変動をもたらすようにも構成することができます。負荷の量とタイプは、一定時間に送信されるリクエストの数、同時ユーザーの数、ランダムに生成されるウィキ・イメージ・ファイルのサイズを変えることによって変更することができます。また、PHP アクセラレーターを使用することで、CPU 使用量を無視できる程度にまで減らすことができます。このワークロードは、かなりの量の I/O を生成することができ、仮想マシンのイメージ・ストレージ・デバイスにアクセスする際に使用可能な帯域幅に影響されやすくなっています。

ポリシー

この記事でのメモリー・バルーニング・ストラテジーは、ホストのスワッピングを防ぎ、代わりにメモリー・プレッシャーをゲストに移すことを目的としています。ゲストのページ・アクセス情報を持たないホストは、スワップするページを選択する際に、LRU アルゴリズムを正しく適用することができません。さらに、ワークロードのメモリー使用に関するほとんどの情報を持っているのは、ゲスト・オペレーティング・システムです。したがって、ゲスト・オペレーティング・システムでなら、最適なページ交換を決定することができます。

このポリシーはメモリー・バルーニングを利用して、すぐに解放可能なホスト・メモリーのプールを維持します。解放可能なメモリーを定義するのは、/proc/meminfo にレポートされた MemFreeBuffersCache の合計です。このプールが全メモリー容量の 20 パーセント未満にまで小さくなると、メモリー・バルーニングが開始されます。ゲストへのプレッシャーは、ホストのメモリー・プレッシャーのレベルに応じて加えられます。最初に空きメモリーから回収されるため、未使用のメモリーが多いゲストのバルーニングが最も大きくなります。十分なバルーン・プレッシャーになると、ゲストはキャッシュに入れられたページをキャッシュから削除して、スワッピングを開始します。メモリー・プレッシャーが低下すると、バルーンが縮小されてメモリーがゲストに戻されます。

シナリオで使用する KSM チューニング・アルゴリズムは、ksmtuned のチューニング・アルゴリズムと一致するように設計されています。このアルゴリズムではまず、空きメモリーのしきい値に応じて、カーネル・スレッドを有効にするかどうかを決定します。シナリオで設定するしきい値は、ホストの全メモリー容量の 20 パーセントです。ホストで以下の 2 つの条件が両方とも揃わない限り、KSM の実行が許可されます。

  • 空きメモリーがしきい値を超えていること
  • 全メモリー容量から空きメモリーしきい値を引いた量が、すべての仮想マシンに割り当てられたメモリー合計を超えていること

この 2 つの条件はそれぞれ、ホストにメモリー・プレッシャーがかかっているかどうか、仮想化が責任を果たせるかどうかをテストするためのものです。ksmd が不要なときに、これをオフに切り換えることで、CPU サイクルを節約することができます。

ksmd が有効になっている場合、その操作は合計メモリー・サイズとメモリー・プレッシャーに応じてチューニングされます。走査が完了してから次の走査が始まるまでのスリープ時間は、ホストのメモリー・サイズに基づいて調整されます。メモリー・サイズが 16GB のホストの場合、デフォルトのスリープ時間は 10 秒です。メモリー・サイズがこれよりも大きいマシンでは、スリープ時間は短くなり、逆にメモリー・サイズが小さいマシンでは、スリープ時間は長くなります。走査間隔ごとに走査するページの数は、空きメモリーの量によって増減します。空きメモリーが空きメモリーしきい値よりも少ない場合、走査レートは 300 ページ分増加します。そうでない場合は、50 ページ分減らされます。走査するページ数の許容範囲は 64 から 1250 です。

結果

この実験は、IBM BladeCenter® HS22 で行いました。このシステムには、EPT (Extended Page Table) 対応の 16 の論理 CPU と、48GB の RAM が搭載されています。ストレージ容量および帯域幅の増加には、専用の 10 ギガビット Ethernet LAN で接続された外部 NFS アプライアンスで仮想マシン・イメージをホストすることによって対応しました。この実験では、Memknobs ワークロードのシナリオと Cloudy ワークロードのシナリオを使って、MOM ポリシーの有効性を評価しました。各シナリオでのパフォーマンスへの影響を測定するために、MOM ポリシーを有効にした場合と有効にしない場合の両方で、それぞれ 1 時間のテストを行いました。

Memknobs ワークロードのシナリオ

この実験には、それぞれ 2GB の RAM と 1 基の VCPU を搭載した 32 の仮想マシンを用意しました。Memknobs メモリー・ロード (図 3 を参照) を校正し、定期的なスワッピング・アクティビティーが発生するだけのメモリー・プレッシャーがホストにかかるようにしました。実験を通じて、望ましいホストの振る舞いを生み出すパターンを生成することができました。

図 3. Memknobs のメモリー・アクセス・パターン
Memknobs のメモリー・アクセス・パターン
Memknobs のメモリー・アクセス・パターン

Memknobs プログラムは、繰り返し処理ごとにアクセスすることのできたページ数を追跡します。このスループット値は、1 秒あたりにアクセスしたメモリー量 (メガバイト単位) としてレポートされます。異なる実験同士の比較を容易にするために、ゲストごとの平均スループットを計算し、その値を 32 の仮想マシンで合計することによって、平均スループットの合計スコアを求めます。表 1 で比較しているのは、異なる MOM ポリシーのそれぞれを使用して得たスコアです。

表 1. MOM ポリシーの結果: Memknobs の平均スループットの合計
MOM ポリシー結果
未使用4331.1
KSM のみ4322.6
KSM およびバルーニング5399.5

上記の結果から、メモリー・バルーニングを使用すると、スループットが 20 パーセント近くも向上することがわかります。KSM はこのワークロードでのページ共有に極めて有効でしたが、それでもパフォーマンスの向上には関与していません。図 4 では、メモリー・バルーニングを使用して Memknobs を実行した場合と、メモリー・バルーニングを使用しないで実行した場合のスワップ・アクティビティーを比較しています。

図 4. Memknobs のスワップの比較
Memknobs のスワップの比較
Memknobs のスワップの比較

MOM ポリシーを有効にすると、スワップ・アクティビティーは事実上ゲスト内で集中して行われます。その結果、スワップ操作の合計数は半分に削減されました。

Cloudy ワークロードのシナリオ

Cloudy を環境に適した大きさにするため、32 の仮想マシン MediaWiki インスタンスを構成しました。このワークロードは、Memknobs ほどにはメモリーを使用しません。確実にメモリーにバインドしたゲストにするため、各 VM には 1GB の RAM しか割り当てませんでした。仮想マシンのフットプリントの減少を補うために、15,714 の大きなページを確保しました。これで事実上、ホストが使用できるメモリーは 16GB に減ります。

JMeter テスト計画は、仮想マシンごとに 1 秒あたり平均 16 のリクエストを送るように構成しました。これにより、システムがオーバーコミットされていない場合でもリソースのボトルネックが生じることのない、適度な負荷が生成されます。JMeter は、実行する各リクエストに関する統計を記録します。このシナリオでは、サービス品質 (QoS) メトリックをリクエストの所要時間の 95 パーセンタイル値 (ミリ秒) として計算します。インスタンスの平均スループットは、完了したすべてのリクエストの合計サイズ (キロバイト) を参加ゲスト数で割った値です。

表 2 に、KSM とメモリー・バルーニング MOM ポリシーを有効にした場合、および有効にしなかった場合の QoS とスループットの結果を示します。

表 2. Cloudy の QoS およびスループット
VM 数MOM ポリシーQoSスループッ
1無効1669710007
32無効3240774555
32有効3231764762

VM を 1 つだけ使用して実行した場合の結果は、制約のないホストでのパフォーマンスを示すために記載しています。このデータからわかる重要な結果は、Memknobs のパフォーマンスを飛躍的に向上させた MOM ポリシーが、Cloudy ワークロードのシナリオでは何の成果も上げていないことです。このワークロードで主にメモリーを使用しているのは匿名メモリーではなく、ファイル I/O であり、ごくわずかなスワップ・アクティビティーしか観測されていません。代わりに、メモリー・オーバーコミットがホストとゲストのページ・キャッシュにプレッシャーを加えることから、システムが作業用セットをより小さなメモリーにロードして保持しようとする結果、I/O が増大しています (図 5 を参照)。

図 5. 単一のゲストでメモリー・バルーニングが I/O に与える影響
単一のゲストでメモリー・バルーニングが I/O に与える影響
単一のゲストでメモリー・バルーニングが I/O に与える影響

大きなページを確保してホストで使用可能なメモリーを減らすという方法は、メモリーを制限する上で効果的ですが、ホストのメモリー管理アルゴリズムに微妙に影響を及ぼす可能性があります。将来的には、この実験を 16GB の物理メモリーを搭載したマシンで繰り返し、できるだけ現実的なシナリオでシステムを評価する必要があります。

結果の分析

以上で説明した 2 つの異なるワークロードの調査による結果を比較すると、1 つの明らかな結論に達します。それは、メモリーをオーバーコミットする場合には、システムとそのワークロードのあらゆる側面を考慮しなければならないということです。「すべてに万能」な管理ポリシーというものは存在しません。

計画されている改善内容

まだ初期段階ではあるものの、この研究により、KVM でのリソース・オーバーコミットの状態が進展することは確かです。そのため、多くの改善が計画されているとともに、現在進められている改善もあります。

現在、ホストとゲストの間の通信に標準化された方法はありません。現在使用されている方法 (ホスト・ゲスト間のネットワーク通信など) は、ホストと各ゲストでの手動による構成とセットアップ、オペレーティング・システムの種類とバージョンによって指示された方法、データ・センターのネットワーク構成、そして仮想マシンのデバイス・モデルによって変わってきます。この問題を単純化するために私たちが目標としているのは、virtio-serial やエミュレーションされたシリアルを含め、複数のデータ転送をサポートできる QEMU に通信メカニズムを統合することです。チャネルのゲスト側は、オープンソースのマルチプラットフォーム QEMU ゲスト・ツール・パッケージでサポートします。このようなメカニズムであれば、MOM のゲスト統計データの収集機能を向上させるとともに、コピー/ペースト・タスクや管理タスクなどの機能にも幅広く使用することができます。

この記事で明らかなように、オーバーコミット・ポリシーは、役に立つ場合もあれば、悪影響をもたらす場合もあります。安全にデプロイできるようにするためには、パフォーマンスの妨げになるポリシーであってはなりません。MOM ポリシーは、管理操作が期待する結果をもたらさない場合には、その操作をロールバックするという保護対策を追加することで、改善できるはずです。

現在、KVM には非常に有効に連携する CPU 共有メカニズムがあります。ゲスト CPU が hlt 命令を実行するときには、自発的に CPU 時間を他のゲストに譲ります。同じようなゲスト駆動型プロトコルでメモリー・リソースを譲れるとしたら、メモリー・オーバーコミットによるパフォーマンスの影響を低減させることができます。

コミュニティーが KVM でのオーバーコミットを改善する可能性のある新しい機能を開発した場合、その機能のサポートは、MOM インフラストラクチャーに統合されることになります。例えば、私たちは cgroups ベースの RSS 制限のサポートを有効にして、バルーニング・ディレクティブを強制し、協力的でないゲストや悪意のあるゲストからシステムを保護することを計画しています。

まとめ

仮想化のメリットを最大限に生かす上で極めて重要なリソース・オーバーコミットは、徹底的な研究と開発が必要なテーマです。Linux 仮想化が進化するにつれ、オーバーコミットのベスト・プラクティスも進化していくことでしょう。効率性を最大限に高め、段階的な改善を進めていくには、ポリシー駆動による全体的な手法でオーバーコミットを管理するのが最善の方法です。

謝辞

ここに名前を挙げたい同僚は数多くいますが、特に、Anthony Liguori 氏と Karl Rister 氏に感謝の気持ちを表したいと思います。彼らのアドバイスと技術的な専門知識が、Memory Overcommitment Manager およびこの研究の構想と開発の助けになりました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Cloud computing
ArticleID=630734
ArticleTitle=オーバーコミットを使用した KVM ホストでのリソース管理
publish-date=02082011