例えば、CPU数に応じたライセンス形態となっているアプリケーションならば、動いているハードウェア全体のCPU数を数えるのか、仮想サーバに割り当てられているCPU数だけを数えればいいのかが明確化されていない場合もある。さらに、仮想サーバでは検証していないという理由から、そもそも製品サポートが受けられないかもしれない。
契約的に問題はないのか、またセキュリティなどのリスクはどうなるのかといったことも含め、仮想化環境下で古いアプリケーションやOSが動くということと動かすべきかということは別問題と認識すべきだ。ユーザーは、このあたりのリスクをすべて承知の上で、古い環境を存続させる必要がある。むしろこれは、緊急避難的措置と理解し、結局は新たな環境に移植するか、新規に別のアプリケーションに乗り換えることを検討したほうがいいのかもしれない。実験的、試用的な仮想化、これが1.0ということになる。
サーバ仮想化2.0から3.0へ
サーバ仮想化のリスクについては、先進的な企業はすでに気がついているだろう。現状は、そういったリスクを承知の上でサーバ仮想化を活用し始めているのだ。
「コンソリデーションによる管理コストの削減を目的にサーバの仮想化を活用するというのが、サーバ仮想化2.0だ」とIDCの井出氏は言う。
従来の実験的なサーバ仮想化の利用から、コンソリデーションを目的とした利用に入り、すでに現状はサーバ仮想化2.0の時代に入っていると井出氏は説明する。1.0との違いは、シビアな使い方をしていない業務用トランザクションシステムであれば、仮想サーバの上で動かし始めているということだ。仮想化というと、かつてはつかみどころのない不安定な技術で実現されているのではという不安もあった。最近になって、サーバ仮想化のベース技術は大きく変化していないが、多くの人がサーバ仮想化を利用することで技術的にこなれてきたのだろうと井出氏は言う。実環境としての仮想化、これが2.0ということになる。
ただし、井出氏は「サーバ仮想化で物理的なサーバの数は減少しても、オペレーション対象が減るわけではないので、運用管理コストが根本的に削減できるわけではない」と指摘する。
ベンダーは、現状の2.0からさらに次のステップをすでに目指している。根本的に運用管理コストを減らすためには、データセンター全体があたかも1台のブレードサーバで動いているような柔軟な構成を実現するサーバ仮想化が必要なのだ。ここまで来れば、次世代のサーバ仮想化3.0ということになるだろう。
これは、アプリケーションからみれば、ワークロードが増えた時に自動的にリソースが追加されるといった利用形態だ。そして対象地域も広がり、ヘテロジニアスな環境でも仮想化が利用される状況になる。VMwareでいうならば、VMotionを活用して、仮想サーバを異なる仮想環境間で自由に移動させて利用するといった技術が必要になる。
