KVMハイパーバイザー型一択の仮想化だけじゃダメハイパーバイザー型仮想化は便利で、私も愛用しています。この仮想化の最大のメリットはOSを選べることです。二つ目はライブマイグレーション(動かしたまま別のハードに移動できる)ことでしょうか。この2つのメリットは偉大です。今日は、ハイパーバイザー型の仮想化のデメリットを経験を交えつつ、Solaris11のコンテナ(Zone)の特徴の話しをしたいと思います。ハイパーバイザー仮想化の問題システム構築をするに当たり、仮想化をして当たり前の時代になってきました。今のように「クラウド」とか「仮想化」が叫ばれる以前から、仮想化のメリット・デメリットは語られてきていました。弊社も2001年頃から実は様々な仮想化をしていたのですが、本格的にはネットワークやストレージを含めた仮想化を3年ほど前からスタート。善し悪しも含めて、ノウハウは溜まっています。メリットはやはり、サーバーが本当の意味で「サーバー=サービスをする単位」に変わること。「サーバー≠機械」になることです。ベアメタルの物理機はもはや資源であって言葉の意味の通りの「サーバー」ではありません。この手の話はいたるところで話しましたが、やはり「サービスサイクルとファイナンシャルサイクルの分離ができる」ことが、最大のメリットとなります。逆に、ハイパバイザ型の仮想化を使う、最大のデメリットは「遅いこと」です。これは、最近の十分な仮想化支援機能を持ったCPUを使ったとしても、どうにもならない性能劣化があります。ESXなどのハイパーバイザの上に1つだけ仮想サーバを立てて同じサービスを実行してみればわかります。あなたのサーバが「全てのサーバ(サービスの為の論理単位)」で、なんの問題も無くできれば、ハイパバイザ型仮想化システムだけで十分です。アプリケーション開発者から、「性能によるインシデントが起きるのは仮想化のせいじゃないの?」といわれたとき、完全にリジェクトし続けることができる根拠と、アプリケーション開発者を完全に説得できる説明力があれば、それで十分です。そんな方が今回の対象です。しても無理なところは認めざるを得なく、仮想化システムの隣に、特殊な物理機を設置することになってしまったインフラエンジニアも多いとは思います。仮想化システムと物理機のネットワークの区切りをきれいにすることは案外難しいですし、管理的にも特殊要素が増えて、苦々しく思っていることでしょう。コンテナ型仮想化の特徴コンテナ型仮想化は、ある側面においては単なるプロセスパーティショニングです。それ自体は、新しい技術ではありません。chrootのような、ディレクトリのルートを別の箇所の閉じ込める方法に加え、FreeBSDのjailの用に互いのプロセスも見えなくしたり、LinuxのVirtuozzo/OpenVZ、lxc+cgroupのように、CPUパワーやカーネルリソースの分割を加えたりして様々な用途に使われています。大きなメリットは、仮想化による負荷がほぼ無いことです。1つのベアメタルにインストールされたサーバに、1つのコンテナを作りサービスを動かした場合、ベアメタルと同じ速度がでます。IO、メモリ、CPU、ディスク、どれをとっても、そのままの速度で動きます。そのため、大きなDBMSや負荷の高いサービスを動かしたとしても、仮想化による特別なの問題は発生しません。ハードウェアリソースとサーバが密着しない、優れた環境が作れます。コンテナ型仮想化を苦々しく思ってるユーザは多々います。コンテナの中でサービスを作る人間に「制約」が大きくでることがあるためです。あるコンテナ型仮想化では、カーネルリソースが妙に少ないため、プログラムが全うに動かなかったり、バイナリパッケージを入れても妙な動作をしたり、そもそも動かなかったり。これが、コンテナ型仮想化を使う大きなデメリットです。Container(Zone)の強化と隔離性の向上以上に掘り下げて見ましょう。11のコンテナ技術はこれらに比べ、次の点が優れています。CPUリソースの制御、コア単位の委譲FSSに加え、CPUをコア単位で占有させることができます(当然、トータルでの効率は下がります)。一定以上のカーネルリソース(SHM、Lockmem)の制限ディスクのFS単位の委譲ZFSのデータセット単位で、FSを委譲できます。特定のNICをコンテナに委譲できます。ハイパバイザ仮想化のように、仮想NICや仮想スイッチ、NATを作って、仮想NICを委譲することもできます。OSのバージョンの混在SPARCではSolaris8のユーザランド以降、x86ではSolaris10のユーザランドの移設ができます。カーネルだけ11を使い、ユーザランドだけ古いものを使うイメージです。余談ですが、Illumosにはlxといって、Illumosカーネルの上で、Linuxのコンテナを動かすことができます。OpenSolarisについていた機能です。IllumosにはKVMもあります。OSの標準の機能OSの標準の機能であるため、OSが提供しているほぼ全てのミドルウェアが動作します。これらの特徴の結果、普通のサービスをコンテナで動かすだけではなく、ファイルサーバ型コンテナ、NATBOX型コンテナ、ロードバランサーコンテナ、FireWallコンテナなど、仮想アプライアンス的なコンテナで実現ができるほどに、隔離性が高くなっています。OS標準の機能であったため、何かが違う感もあまりありません。Solarisコンテナは以上のように、コンテナ型仮想化の問題点をなるべく拭い去り、隔離性を高めているのが特徴です。Linuxでコンテナ型仮想化に痛い目に遭ってしまった人も、Solarisのコンテナならば、結構普通に使えるのではないでしょうか。ちなみに、Solarisコンテナの大きなデメリットは、OSを選べないことと、ライブマイグレーションができないことです。臨界点の動作それぞれの仮想化は臨界点ではどのように動作するでしょう?大抵の環境では、1つのベアメタルに1つのサーバを「だけ」を上げるのはもったいないでしょうから、なんだかんだいっても複数の仮想サーバを収容するでしょう。そこで、1つの仮想サーバがベアメタルの全体まで利用してしまうと他の仮想サーバに影響を与えるため、大抵はキャップといって利用上限をかけます。ハイパバイザ型の仮想化の場合、CPUキャップまで当たった場合、どうなるでしょうか?これは面白いことに、その中のSYSCALLの一部が、サービス不能になるまで応答が悪くなり、ユーザランドの速度が極端に劣化します。とあるプロセスのSYSが■、USR□だとして、次のような配分で使っているとします。このままではベアメタル全体を使ってしまい、他の仮想サーバが動かなくなるので、このサーバを0.5CPUとします。すると、このようになります。■■■□□SYSCALLはほとんどのケースで実際にデバイスなどを触るのにかかってしまっている時間であるため、減らすことはできません。0.3CPUだとどうなるでしょう?■■■この状態で、サービスは動作不能になりインシデントとなります。ロードアベレージはみるみる増えサーバは一見停止します。SYSCALLの一部がサービス不能になるまで止まるのは、パラバーチャリゼーションドライバに制御が移るためでもあります。仮想サーバB:カーネルBプロセスBαプロセスBβハイパバイザのコンテキストスイッチは、仮想サーバAとBを切り替えることであり、その中のカーネルA、カーネルBがそれぞれコンテキストスイッチをプロセスに対して行います。パラバーチャリゼーションドライバを入れるとこのようになります。プロセスAαがカーネルAに、IOを含むようなSYSCALLを投げると、それはパラバーチャリゼーションドライバを経由してハイパバイザに処理が移ります。このとき仮想サーバAがCPUを使い尽くしていたら、ハイパバイザはどうするでしょうか?以上のように、ハイパバイザ型仮想化システムでのキャパシティプランニングでは、CPU飽和があっという間にサービスダウンに繋がることを肝に据えておいた方がいいでしょう。逆に、ハイパバイザ型仮想化は、他のサーバへのインパクトは少なく、キャパシティプランニングをうまくやっておけば、他のサーバのユーザに気がつかれないほどです。コンテナ型の仮想化の場合、CPUキャップまで当たってしまった場合、どうなるでしょうか?先ほどの例と同じように、とあるプロセスのSYSが■、USR□だとして、次のような配分で使っているとします。このままではベアメタル全体を使ってしまい、他の仮想サーバが動かなくなるので、このサーバを0.5CPUとします。するとその仮想サーバはこの程度のCPUを使います。■■■□□□さらに0.3CPUだとどうなるでしょう?■■■□□これはなぜでしょうか?コンテナ型の仮想化システムは、カーネルは共通のリソースであるためです。そのためにコンテナ型の仮想化システムはSYSCALL側にはほとんどCPUキャップがかかりません。SYSCALLにもデバイス動作を伴うもの、伴わないものがあり、ものによってはかかるものがあるのかも知れないのですが、私の経験則上は、このような形で動作しています。仮想サーバB:プロセスBβそれぞれの仮想サーバにどうCPUを割り振るのか?ということは、1つのカーネルが重み付けで決めているため、コンテキストスイッチの入れ子が起きません。従って、コンテナ型仮想サーバのキャパシティプランニングは、SYSCALLが非常大きいプロセスを動作させられると、他のサーバに少なからず影響があるメモリにキャップに関しては、当たらないように余裕を持つ。ことを肝に銘じておくといいでしょう。あとはそのOSがどれだけコンテキストスイッチが上手なOSなのか?がテーマとなります。一つ、突然出てきたメモリキャップに関してですが、これは1つのコンテナがメモリを使いすぎると、ページスキャナが動き回ってそのコンテナのメモリを積極的に解放するので、システム全体の応答性が下がります。普通のシチュエーションでは出会うことはまずないので、安心しましょう(笑)仮想化選びのコツ:ハイブリッド型のススメということで、仮想化システム選びというのは、実は本当に難しいのです。インフラエンジニア的には1つの仮想化システムを選びたくなる気持ちはわかるのですが、実は1つの仮想化システムで全てを行うのは非常に非効率です。そのうち実運用にあわなくなり、特殊ルールがどんどん増えていくのが関の山でしょう。ハイパバイザ型がいつか軽くなれば・・・。CPUがもっと高速になれば・・・。ハイパバイザ型仮想化の問題はIOといわれ、パラバーチャリゼーションドライバを使うことで、回避をしようとしてきました。Tables)などの支援機能が加わり、かなりのケースで仮想化のボトルネックは排除されました。いう問題は、仮想化システムの開発者はとっくに気がついていて、問題を拭うために日夜がんばっています。構造的な問題を拭うのは難しい部分があり、どこまでいっても未来まで含めた要求仕様を超えられるのか?という問題がどこまでもつきまといます。いうことで、僕のお勧めは、隔離性の高いハイパバイザ型と、リソース利用効率の高いコンテナ型の、ハイブリッド利用です。これらをうまく配分すれば、大抵のシステムは仮想化完了です。コンテナ型これを踏まえたところで、Solarisのコンテナは、一般のコンテナ以上に隔離性を高めた。LinuxのKVMは、一般のハイパバイザより隔離性を若干犠牲にして、リソース効率を上げた。面白いのは、全く違うアプローチで技術開発をしてる2社が、なんとなく似たようなところを落ち着きどころにしようとしてるところでしょうか。それから、あともう一つ。ハイパバイザ型仮想化で必ず考えないとならないのはライセンスとサポートです。サポートがあるOSを利用しても、1つでもサポート外だと全体が「サポート対象外」になりかねません。ハイパバイザが、そのゲストOSをサポートしているか?そのゲストOSは、そのハイパバイザで動くことをサポートしているか?この2つも肝に銘じて調査して見ると良いでしょう。日記2014年、明けましておめでとうございます2015年、謹賀新年2017年、新年明けまして、おめでとうございます。恭賀新年2010年、本年もよろしくお願いします。releaseのレポジトリのバージョンが上がってる・・・OpenSolaris、Solaris(予定)のVPSレンタルサーバ、Phase2Serverについて(の本音(笑))OpenSolaris、始まった!OpenSolarisでATOKきたー!OpenSolarisでMovabletypeを簡単インストールOpenSolarisでSuExecOpenSolarisでmp3やwmaの音楽を聴いたりするOpenSolarisでscansnap、名刺ファイリングソフトで名刺を管理OpenSolarisでとっても簡単にMovabletypeをインストールするOpenSolarisのVirtualBoxでDirectXOpenSolarisのjavaをアップデートをしてみたOpenSolarisのインストール後の手順を再び!OpenSolarisのパワーマネジメントの様子をみてみるOpenSolarisのレンタルサーバ、Phase2Serverをリリースしました。BETA1VirtualBoxのvdiファイルからzfsのzvolのrawイメージに変換VirtualBoxのディスクフォーマットの速度比較VirtualBox上のWindowsから、親OSのOpenSolarisマシン上のディスクアクセスを快適にするWEBサイトを簡単更新。mod_auth_pgなんですが・・・pigz(マルチスレッドで動作するマルチコアに最適なgzip互換ソフトウェア)を試すpingではまるproftpd、pdns-recursor、postfixをOpenSolarisで。びぎなーず」で、Linuxユーザ向けのセッションやります。いい加減にWPAにするか・・・だからマジンシアは滅びたまた砂金を探す作業をしていたわけですが・・・・。して単3、使わない?ケータイが壊れた・・・ケータイ話。続きシステム管理者補佐のアルバイトの募集(静岡市)ジャストプレイヤー株式会社、11月2日で10周年です。ジャストプレイヤー株式会社2012年。