日野原です。

最近いろいろなところで仮想化と言う言葉を聞くようになってきました。
私も開発環境ではいろいろなところで仮想化技術のお世話になっていますが、ricollab のような場所では仮想化技術は役立つのでしょうか。

よく耳にする仮想化技術の導入事例のほとんどは、「たくさんあるレガシーなサーバを仮想化技術を使うことで集約し、コストを削減した」と言うものです。しかしこれではこれから Web 上のサービスとやっていこうという我々の心には届きません。

ではどういう使い方だとうれしいでしょうか。

まず、開発環境としての使い方では、Windows マシン上で VMWare や coLinux を使って開発している人は多いと思います。

また、実験環境を作るときには仮想マシンが活躍します。
我々の例でいうと、実運用環境は DB やアプリ、ロードバランサなど何台ものサーバで構成されているのですが、社内ネットワークにある実験環境では同じ台数のサーバを準備するのはもったいないので xen を使って2台のマシンで同等の環境を構成しています。当然一台あたりに割り当てられるメモリや CPU の資源は少なくなるのでパフォーマンステストなどはできませんが、一台が停止してもサービス全体は止めないとか、アプリケーションのデプロイのテストなどはこの環境で十分です。

それでは、実運用環境ではどうでしょう。

まず一つ、実サーバを用意せずに Amazon EC2 を利用すると仮想化技術の恩恵にあずかることになりますね。
ただ、これでは「自分で仮想化している！」という実感がわきません。私だけ?
今後は必要になってくることだとは思っていますが、今のところはちょっとおいておきます。

次に考えたのは、実サーバ上には仮想マシンのホストとなる最低限の環境だけ用意し、アプリや DB と言った役割のサーバはすべて仮想マシンで提供するといった形態です。そして、故障対策として予備機を仮想マシンのホストだけインストールした状態で置いておきます。

これだと、一台のサーバが壊れて代替機を準備するとき、空いている予備機にイメージをコピーするだけでいいと言うメリットがあります。
でもこれは kickstart などの設定をちゃんとしてインストールを自動化おけばたいして変わらないですね。それにその方が仮想化によるパフォーマンスの劣化も気にしなくていいのでわざわざ仮想化するメリットがあまり感じられません。

では仮想マシンのイメージを実サーバに2つ以上おけるサイズにしておいて、一台が壊れたときに同じ役割のイメージを他の稼働しているサーバ上で動かすようにすればどうでしょう。

これならば予備機をもし切らしている場合でも代わりが作れるし、よさそうですね。ただ、たとえば一つの実サーバ上に DB サーバ用の仮想マシンが2台載ってしまうと HDD アクセスなどが大変なことになりそうなので、CPU を主に使うアプリサーバとメモリとディスク容量を主に使う DB サーバを一緒にするなど、載せるイメージをうまく配分する必要はありそうです。

などといろいろ考えて楽しんでいるのですが、実はそんなことよりも先に ricollab の単一故障点をなくさないといけないのです…

Tags: ricollab, virtualization, xen