HOME / 日記 / ハイパーバイザー型一択の仮想化だけじゃダメ
Date: 2011/11/13 | | Tags: Solaris 11, Redhat Enterprise Linux, 仮想化, Container, Zone, KVM
ハイパーバイザー型仮想化は便利で、私も愛用しています。
この仮想化の最大のメリットはOSを選べることです。二つ目はライブマイグレーション(動かしたまま別のハードに移動できる)ことでしょうか。この2つのメリットは偉大です。
しかし今日は、ハイパーバイザー型の仮想化のデメリットを経験を交えつつ、Solaris11のコンテナ(Zone)の特徴の話しをしたいと思います。
システム構築をするに当たり、仮想化をして当たり前の時代になってきました。
今のように「クラウド」とか「仮想化」が叫ばれる以前から、仮想化のメリット・デメリットは語られてきていました。弊社も2001年頃から実は様々な仮想化をしていたのですが、本格的にはネットワークやストレージを含めた仮想化を3年ほど前からスタート。やはり善し悪しも含めて、ノウハウは溜まっています。
メリットはやはり、サーバーが本当の意味で「サーバー=サービスをする単位」に変わること。つまり、「サーバー≠機械」になることです。ベアメタルの物理機はもはや資源であって言葉の意味の通りの「サーバー」ではありません。この手の話はいたるところで話しましたが、やはり「サービスサイクルとファイナンシャルサイクルの分離ができる」ことが、最大のメリットとなります。
逆に、ハイパバイザ型の仮想化を使う、最大のデメリットは「遅いこと」です。
これは、最近の十分な仮想化支援機能を持ったCPUを使ったとしても、どうにもならない性能劣化があります。たとえばベアメタル上にアプリケーションサーバやDBMSなど、実際のサービスを立てて実行、一方で、(たとえば)VMware ESXなどのハイパーバイザの上に1つだけ仮想サーバを立てて同じサービスを実行してみればわかります。
あなたのサーバが「全てのサーバ(サービスの為の論理単位)」で、なんの問題も無くできれば、ハイパバイザ型仮想化システムだけで十分です。
そしてアプリケーション開発者から、「性能によるインシデントが起きるのは仮想化のせいじゃないの?」といわれたとき、完全にリジェクトし続けることができる根拠と、アプリケーション開発者を完全に説得できる説明力があれば、それで十分です。
それは無理。そんな方が今回の対象です。
どうしても無理なところは認めざるを得なく、仮想化システムの隣に、特殊な物理機を設置することになってしまったインフラエンジニアも多いとは思います。
仮想化システムと物理機のネットワークの区切りをきれいにすることは案外難しいですし、管理的にも特殊要素が増えて、苦々しく思っていることでしょう。
コンテナ型仮想化は、ある側面においては単なるプロセスパーティショニングです。
それ自体は、新しい技術ではありません。
chrootのような、ディレクトリのルートを別の箇所の閉じ込める方法に加え、FreeBSDのjailの用に互いのプロセスも見えなくしたり、LinuxのVirtuozzo/OpenVZ、lxc+cgroupのように、CPUパワーやカーネルリソースの分割を加えたりして様々な用途に使われています。
大きなメリットは、仮想化による負荷がほぼ無いことです。
1つのベアメタルにインストールされたサーバに、1つのコンテナを作りサービスを動かした場合、ベアメタルと同じ速度がでます。IO、メモリ、CPU、ディスク、どれをとっても、そのままの速度で動きます。
そのため、大きなDBMSや負荷の高いサービスを動かしたとしても、仮想化による特別なの問題は発生しません。ハードウェアリソースとサーバが密着しない、優れた環境が作れます。
ただしコンテナ型仮想化を苦々しく思ってるユーザは多々います。なぜならコンテナの中でサービスを作る人間に「制約」が大きくでることがあるためです。あるコンテナ型仮想化では、カーネルリソースが妙に少ないため、プログラムが全うに動かなかったり、バイナリパッケージを入れても妙な動作をしたり、そもそも動かなかったり。
これが、コンテナ型仮想化を使う大きなデメリットです。
昨日のブログにて書いた、仮想化技術:Solaris Container(Zone)の強化と隔離性の向上以上に掘り下げて見ましょう。
Solaris 11のコンテナ技術はこれらに比べ、次の点が優れています。
これらの特徴の結果、普通のサービスをコンテナで動かすだけではなく、ファイルサーバ型コンテナ、NATBOX型コンテナ、ロードバランサーコンテナ、FireWallコンテナなど、仮想アプライアンス的なコンテナで実現ができるほどに、隔離性が高くなっています。
また、OS標準の機能であったため、何かが違う感もあまりありません。
Solarisコンテナは以上のように、コンテナ型仮想化の問題点をなるべく拭い去り、隔離性を高めているのが特徴です。Linuxでコンテナ型仮想化に痛い目に遭ってしまった人も、Solarisのコンテナならば、結構普通に使えるのではないでしょうか。
ちなみに、Solarisコンテナの大きなデメリットは、OSを選べないことと、ライブマイグレーションができないことです。
それぞれの仮想化は臨界点ではどのように動作するでしょう?
大抵の環境では、1つのベアメタルに1つのサーバを「だけ」を上げるのはもったいないでしょうから、なんだかんだいっても複数の仮想サーバを収容するでしょう。そこで、1つの仮想サーバがベアメタルの全体まで利用してしまうと他の仮想サーバに影響を与えるため、大抵はキャップといって利用上限をかけます。
ハイパバイザ型の仮想化の場合、CPUキャップまで当たった場合、どうなるでしょうか?
これは面白いことに、その中のSYSCALLの一部が、サービス不能になるまで応答が悪くなり、ユーザランドの速度が極端に劣化します。
つまりこんな感じです。とあるプロセスのSYSが■、USR□だとして、次のような配分で使っているとします。これがベアメタルのリソースを全て与えた全開速度の時だとします。
■■■□□□□□□□
このままではベアメタル全体を使ってしまい、他の仮想サーバが動かなくなるので、このサーバを0.5CPUとします。すると、このようになります。
■■■□□
SYSCALLはほとんどのケースで実際にデバイスなどを触るのにかかってしまっている時間であるため、減らすことはできません。
さらに0.3CPUだとどうなるでしょう?
■■■
この状態で、サービスは動作不能になりインシデントとなります。ロードアベレージはみるみる増えサーバは一見停止します。
また、SYSCALLの一部がサービス不能になるまで止まるのは、パラバーチャリゼーションドライバに制御が移るためでもあります。
ハイパバイザ型のコンテキストスイッチの実体は、次のようなイメージです
ハイパバイザのコンテキストスイッチは、仮想サーバAとBを切り替えることであり、その中のカーネルA、カーネルBがそれぞれコンテキストスイッチをプロセスに対して行います。
パラバーチャリゼーションドライバを入れるとこのようになります。
プロセスAαがカーネルAに、IOを含むようなSYSCALLを投げると、それはパラバーチャリゼーションドライバを経由してハイパバイザに処理が移ります。このとき仮想サーバAがCPUを使い尽くしていたら、ハイパバイザはどうするでしょうか?
以上のように、ハイパバイザ型仮想化システムでのキャパシティプランニングでは、
ことを肝に据えておいた方がいいでしょう。
逆に、ハイパバイザ型仮想化は、他のサーバへのインパクトは少なく、キャパシティプランニングをうまくやっておけば、他のサーバのユーザに気がつかれないほどです。
コンテナ型の仮想化の場合、CPUキャップまで当たってしまった場合、どうなるでしょうか?
先ほどの例と同じように、とあるプロセスのSYSが■、USR□だとして、次のような配分で使っているとします。これがベアメタルのリソースを全て与えた全開速度の時だとします。
■■■□□□□□□□
このままではベアメタル全体を使ってしまい、他の仮想サーバが動かなくなるので、このサーバを0.5CPUとします。するとその仮想サーバはこの程度のCPUを使います。
■■■□□□
さらに0.3CPUだとどうなるでしょう?
■■■□□
これはなぜでしょうか?
コンテナ型の仮想化システムは、カーネルは共通のリソースであるためです。そのためにコンテナ型の仮想化システムはSYSCALL側にはほとんどCPUキャップがかかりません。もちろん、SYSCALLにもデバイス動作を伴うもの、伴わないものがあり、ものによってはかかるものがあるのかも知れないのですが、私の経験則上は、このような形で動作しています。
加えて、コンテナ型のコンテキストスイッチの実体は、次のようなイメージです
それぞれの仮想サーバにどうCPUを割り振るのか?ということは、1つのカーネルが重み付けで決めているため、コンテキストスイッチの入れ子が起きません。
従って、コンテナ型仮想サーバのキャパシティプランニングは、
ことを肝に銘じておくといいでしょう。あとはそのOSがどれだけコンテキストスイッチが上手なOSなのか?がテーマとなります。
もう一つ、突然出てきたメモリキャップに関してですが、これは1つのコンテナがメモリを使いすぎると、ページスキャナが動き回ってそのコンテナのメモリを積極的に解放するので、システム全体の応答性が下がります。
ちなみにもう一つあるのですが、これはちょっとブログではかけません(笑) でも普通のシチュエーションでは出会うことはまずないので、安心しましょう(笑)
ということで、仮想化システム選びというのは、実は本当に難しいのです。
インフラエンジニア的には1つの仮想化システムを選びたくなる気持ちはわかるのですが、実は1つの仮想化システムで全てを行うのは非常に非効率です。そのうち実運用にあわなくなり、特殊ルールがどんどん増えていくのが関の山でしょう。
ハイパバイザ型がいつか軽くなれば・・・。あるいはCPUがもっと高速になれば・・・。
ハイパバイザ型仮想化の問題はIOといわれ、パラバーチャリゼーションドライバを使うことで、回避をしようとしてきました。そして次にメモリ確保の問題といわれ、CPU側にもNPT(Nested Page Tables)などの支援機能が加わり、かなりのケースで仮想化のボトルネックは排除されました。
こういう問題は、仮想化システムの開発者はとっくに気がついていて、問題を拭うために日夜がんばっています。しかし構造的な問題を拭うのは難しい部分があり、どこまでいっても未来まで含めた要求仕様を超えられるのか?という問題がどこまでもつきまといます。
ということで、僕のお勧めは、隔離性の高いハイパバイザ型と、リソース利用効率の高いコンテナ型の、ハイブリッド利用です。これらをうまく配分すれば、大抵のシステムは仮想化完了です。
一般的に、仮想化選びは次の2つのトレードオフなのですが・・・
これを踏まえたところで、
面白いのは、全く違うアプローチで技術開発をしてる2社が、なんとなく似たようなところを落ち着きどころにしようとしてるところでしょうか。
それから、あともう一つ。
ハイパバイザ型仮想化で必ず考えないとならないのはライセンスとサポートです。サポートがあるOSを利用しても、1つでもサポート外だと全体が「サポート対象外」になりかねません。
この2つも肝に銘じて調査して見ると良いでしょう。