スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

KVMについて

※今回も過去のブログのまとめです

Redhatが、Qumranetを買収してサポートはしているものの、イマイチ流行らないKVMという印象です。そもそも、VMwareやXenとはアーキテクチャが大きく異なります。VMwareやXenはハイパーバイザ型になっているが、KVMはホストOS型です。ただ、仮想化環境を使う側としては、どちらもやれることにはそこまで大きな違いが無いというのが実情です。運用系ツールはVMwareが良いものの、実際に購入するとなると安いほうがいいわけで、VMwareよりもKVMを選択することもありえると思います。

本当にKVMに弱点はないのでしょうか?細かく調べたわけではないですが、1つのCPU(コア)を使い切れないシステムを仮想化する時にはKVMは不利だと考えています。というのは、シカゴで行われたredhat summitの資料を見ていて気がついたのですが、XENに比べ、KVMはユーザー数(ゲストOS数)が多くなると性能が劣化するようです。OLTP系のオンラインショップのようなアプリで検証したらしのですが、要するに軽いアプリケーションが沢山実行されるケースにおいては不利、ということになりそうです。

どういうことかというと、KVMの場合、CPUのコアをVCPUとしてプロセスに対して割り当てます。その割り当て方が微妙でCPUとVCPUが1:1でなければならないようです(Reahatの説明では)。つまり、クアッドコアの4CPU(ソケットといったほうがいいでしょうか?)であれば、16コアの仮想CPUとなります。ただ、1つのプロセスがCPUを使い切れれば効率がいいのですが、実際にはなかなかそんな都合のいいアプリは存在しません。そういったことから、先ほどの例だとVCPUを16以上に設定しようとすると(ユーザー数が多くなると)性能が悪くなるようです。

これは小さいアプリケーションを仮想化する時にも同じ現象が起きるわけで、そもそもリソースを使い切れない小さいサービスをまとめてリソースを有効活用する、という仮想化の目的にマッチしません。一見すると、KVMは性能が良いベンチマークが出やすいので、勘違いしてしまいそうでしが、仮想化本来の目的を考えると、(現状では)あまりいい製品ではないのかもしれません。

逆に、その点が解決すれば、KVMはOS、CPUと連動しているのでいい製品になるかもしれません。ただ、現状では発展途上と言わざるを得ず、まだまだかなあという印象だ。それよりもXENのほうが、採用する企業も多く、OracleVMやPAN ManagerもXENベースであるので、発展するように思います。Redhatの戦略はOSに抱き合わせで売ってシェアを奪いたいのでしょうが(MSが得意な戦略))そもそもVM上でJavaを動かしてしまえばOSは不要になるので(そういう製品の登場のウワサもチラホラ)、そんな簡単にシェアを奪えないと思う。

ちなみに、実コア以上にVCPUを割り当てられないといっても、仮想化環境ではCPUよりもメモリがボトルネックになるので、そこがネックであればCPUの問題はその次になるかもしれません。

最後に、仮想化製品はVMwareが圧倒的に有利ですが、使う側からするとシェアNO.1という強みはかなり大きいです。どういう点でメリットが出てくるかというと、VMwareを採用する企業が多いので、特にMWベンダーがVMware上だとサポートする傾向にあるのです。仮想化製品を利用する側からすると、上に乗るMWが正式にサポートされる、されないというのは大きな問題で、たとえあるMWがサポートされていなかったとしても、VMwareならサポートします、と言ってもらえやすいのです。ただ、そこへKVM(Hyper-V、Xenも同様)でもサポートして欲しいという依頼をしても、なかなか対応してもらえないのです。そういったことから、現状ではKVMは不利だ(使う側からすると不便だ)と感じてしまうのです。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。