VMware ESxi 3.5 Update 4と Xen Server 5.0 Update 3をちょっと使ってみた感想と妄想と邪推

ESXiに関しては、サーバマシンのローカルHDDを使えてないので、ネットワークがGbEtherだったり、FibreChannelとかでSANを組めない以上、パフォーマンスに関して何がわかるということでもなかった。
比較できるのは、管理ツールの機能と使い勝手くらい。それにしたって、管理機能については無償で試せる部分は限られているし、個人所有のサーバ資源(10台以下)をいじってる限りにおいて、管理システムの出来のよさを評価する意味も薄い。

それでもなおかつ、自分が中規模のオフィスのサーバ管理者だったら、、という前提で考えてみたとき、ポイントになるんじゃねーか、と思ったところをだらだら書いてみる。あとで見直すためのエントリです。

  • VMwareディスクレスサーバ+SANのベンダー出来合いを買ってくるのが安全
    • ハイパーバイザの対応しているデバイスの要件にあったハードウェアを探すのが大変だし、サポートHWのリストに載っていないマシン上のデバイスがいつまでもサポートされるとも限らない
    • なんでこんなことになるかというと、完全仮想化でずっとやってきたVMwareは、hardwareのドライバの中身にまで深くコミットした開発体制になってるんじゃないかと邪推。一方、Xenは、ドライバはDom-0等に丸投げなので、要するにREHL(すなわちCentOS)で動くハードなら問題は起き難い。(全く問題無いわけじゃないけど、要するにハードウェアから見えているメモリ空間の管理が、ハイパーバイザと整合していればいい)ただし、RedHatKVMで行くと表明している以上、今後はXenもDom-0のベースをどうするかで苦労するのではないかと思う。そこでMicrosoftあたりの動向が気になる。逆に、「H/Wベンダーの上得意製造システム」であるVMwareは「生かさず殺さず」で生き延びそうな気がする。
  • HW監視機能については、無償評価版ではイマイチ
    • サーバを止めないためには、危機的状況になる前に状況を把握するのが大事だが、その辺の造りこみを試すことはできなかった。
    • 簡単な話、停電があってUPSからシャットダウンするとなった場合、NFSサーバを先に落としちゃったりしたらまずいわけだ。こういうスケジュールがうまく組めるように管理システムにシームレスに組み込まれててほしい。それは極秘運用ノウハウです、っていう業界じゃダメだろ。
      • (2009/4/14追記)この場合、triageのためのサーバのpriorityと、サービスを継続するのに必要なdependencyをあらかじめしっかり把握してなきゃいけない。その上で、負荷バランスやresourceの制限、H/Wメンテナンスのタイミングを勘案してのlive migration管理機能がないと混乱の元になるだけだろう。
  • ネットワーク設定をサードパーティのセキュリティ/負荷分散製品と組み合わせる工夫も無償版じゃぁ、わからない
    • SANのネットワークはプライベートで、ロードバランサーのバックエンドからはDSRしたい、とか、サーバが集積されればやりたいことはたくさんでてくる。それがlive migrationしても崩れないようにしなくてはいけないのだから、このあたりのAPIをどうするか、が、本当は鍵なんだと思うのだけど、、、
      • (2009/4/14追記)migrationならば、ネットワークのアドレスは変わらないのが建前だから、ここんところはあまり問題にならないはずだ。本当にうまくいくかどうかは絶対に検証が必要だけど。
      • (2009/4/14追記)ネットワークの構成については、VMware Infrastructure(VI) Clientだと、ESXiがインストールされているサーバを選択して>Configurationタブ選択>hardware pane内のNetworkのリンクを選択することで、確認できる。参照:VMware ESXi 構成ガイド (PDF) そして、構成をいじりたい場合(VLAN切ったりしたい場合)には、VI Clientのネットワークの追加ウィザードを使うことになるようだ。(あとで読む:http://www.vmware.com/files/jp/pdf/vi3_35_25_admin_guide_ja.pdf:title=VMware ESXi基本システム管理])暇がもしあれば、関連ドキュメントは一通り読みたいところだけどなぁ→ページが見つかりません - Japan
  • VMwareはシステムのバックアップに対してXenに一歩先んじていると感じる
    • イメージのクローンはどちらでも簡単だ。そして、システムのスナップショットを取るだけならば、LVM上にイメージを置いとけばいいけれど、ファイル単位で差分を管理したいとなると、仮想化のシステムがなんらかの関与をすることになる。そのあたりについて、VMwareVMware Cosolidated Backup(VCB)というメカニズムを打ち出して、バックアップソフトのベンダーもそれに対応した製品を出している。仮想化のメリットの一部として、Disaster Recoveryなどが取りざたされる現在では、営業面では結構重要なポイントだろう。(自分ならdrbdとかでhot standbyしとけばいいじゃんとか思うけど、そんなシステムを管理者が手作業で作るのか、サポートのある製品を買ってくるのか、は大違いだ)ちなみに、LVMと組み合わせての差分バックアップについては、Xen Server 5.1のfeatureだ(現在β公開)
  • 既存仮想サーバイメージの取り込みについての差
    • たとえば、自分はすでにXen 3.xで仮想化したサーバを何台か運用しているのだが、これをXen Server5.xにすぐに持ってこられるか、というと、そうではない。P2Vツールがあるようだが、これを既存のXen3.xサーバについて実行するのは、たとえ可能でも納得しがたい。一方、VMwareの場合は、既存イメージをimportできるようになっている。この問題についての本当の勝負は、それぞれの仮想イメージの相互転用ができるかどうか、なのだろうけれど、それまで顧客をひきつけるための信頼感という点ではVMwareのほうがリードしていると感じる。
  • じゃぁ、VMwareXenのどっちを選ぶのか?俺は?企業は?
    • 実際の導入コストを考えると、いきなりSANを組むなんて、そうそうできません。HP ML115を100台買うより高いかもしれない!!ここで思考停止しちゃうケースは非常に多いと思う。
    • でも、さらに高い固定費を食う管理者を雇うよりは、サポートコストとの差額でお釣りがくる、という考え方もできる。
    • さらに、仮想化の(おそらく多くの企業にとって)本来の目的であるhigh availabilityの実現のためのサーバ要素の冗長化やDisaster Recovery Planを真剣に考えた場合には、どっちみちH/Wベンダーの動向が重要だし、長期にわたってサポートされる(compatibility listに載る)機種となれば選択肢は限られてしまう。
    • ただし、Xenのminimalismとopensourceであることの強みも無視できない。本当に強力で巨大なサーバシステムを自前でチューニングして運用するような部署ならば、ドライバ等Dom-0機能の維持のコストの比率は無視できるほど小さいと思える。

2009/4/14追記 オープンソースの運用管理ソフトもVMware ESXi対応なんて謳ってる

OSSの運用管理ソフト「Hinemos」がVM管理の新機能 − @IT