墜落日記 - 2010年7月18日の墜落
XenServer という選択肢
最近は暇を見ては XenServer を調査している。
自宅サーバを仮想化するに当たり今までは VMware vSphere Hypervisor を考えていたのだけど、VMware vSphere Hypervisor しか考えないと選択の幅が非常に狭くなるという問題がある。
最大の問題は、VMware vSphere Hypervisor には管理コンソールがないことだ。
管理コンソールがないから Direct Attached Storage (DAS) 構成しようとするとハードウェアのヘルスチェックがお座なりになってしまう。
vSphere Management Assistant (vMA) でも動かない管理エージェントは数多いようだ―――少なくとも Adaptec Strage Manager (ASM) は動かないと Adaptec サポートから回答があった。
vMA は仮想アプライアンスであるが故に、物理ハード監視のためのレイヤーとしては使えないということか。
この時点で VMware vSphere Hypervisor を選択する限り Storage Area Network (SAN) 構成を取らざるを得ないのが確実となる。
RAID 組んだから平気？ そんなものサーバ運用したことのない小便タレの世迷い言だ(爆)
SAN 前提だと、今度は帯域の問題が浮上する。
エンタープライズ分野では Fibre Channel (FC) は一般的だが、FC は専用の Host Bus Adapter (HBA) が高価であったり、構築に専門知識が必要になったりと、自宅サーバ仮想化の範疇を大きく超える。
ではその他の SAN の構築手段として何があるかと言われると、Network File System (NFS) と Internet Small Computer System Interface (iSCSI) だか、これらは TCP/IP ネットワーク上に構築されるが故に取り敢えず組むには安上がりだ。
しかし現在の Ethernet の帯域は民生用では 1.0Gbps が精々、10Gbpos の HBA も無理すれば手に入る価格帯まで落ちてきているが 10Gbps 対応の L2 スイッチを仕入れようとすると非現実的な価格になるため、ストレージと仮想ホストの 1 対 1 構成になってしまう。
そうすると複数の NIC を束ねて帯域を拡大する NIC チーミング、ないしボンディングという手法を使うことになるわけだが、VMware vSphere Hypervisor の NIC チーミングは負荷分散は出来ても帯域拡張という目的は達さないらしい。
つまり仮想マシンにストレージパスを専用で割り当てるような設定をしたとしても使える帯域は 1.0Gbps が限界、1.0Gbps というのは単純計算で 125MB/s だが、これは SATA のハードディスク 1 本分程度の転送速度であるから、高負荷な I/O が発生する処理には不向きだ。
もちろん自宅サーバで FC SAN を組む剛の者がいても面白いし、仮想ホスト毎に 10Gbps の NIC を増やしていくという選択肢もある。
しかし今度はそれだけの投資をして確保した帯域を使い切れるだけの仮想ホスト性能と、その仮想ホスト性能を活かすだけのサーバ集約をしなければ費用対効果が悪すぎる。
以上より、VMware vSphere Hypervisor は自宅サーバ仮想化で充分なパフォーマンスをリーズナブルに得ることが難しい、という結論に達せざるを得なくなる。
しかしこれは VMware vSphere Hypervisor が全くの役立たずだと言っているわけではない。
VMware vSphere Hypervisor がスコープとしているのが、FC SAN を組むのが当たり前の大規模なサーバ仮想化に軸足を置いているためだ。
要は鶏を割くに焉んぞ牛刀を用いんということだ。
ま～ VMware が歴史的に殿様商売していたが故の問題という側面も否定できないが………
では他の選択肢ではどうだろう？
無償で入手できて、管理ツール類も充実していて、導入実績がある選択肢というと、次ぎに上がるのは XenServer だろうか。
Microsoft の Hyper-V という選択肢もあるが、無償版を利用した際の管理性だとか考えると今回は検討から除外する。
MSDN 契約はしているので Windows Server 2008 も使いたい放題だけど、外部公開する自宅サーバを開発用だと言い張るのは無理がある(笑)
で、XenServer である。
XenServer はオープンソースで開発されている Xen をベースに、Citrix 社が管理ツールなどを拡充して公開している仮想化ソリューションである。
Xen 自体は Amazon の商用ウェブサービス Elastic Compute Cloud (EC2) で採用されていることが有名だ。
しかもこの XenServer、去年の 2 月 23 日の Citrix 社の発表により複数サーバを管理する XenCenter や、ライブマイグレーション技術 XenMotion なども含めたエンタープライズ級の機能群が無償公開された。
無償公開されている機能点数で比較した場合、もはや VMware vSphere Hypervisor に太刀打ちできる物ではなくなっている。
（Citrix 社の収益源がどのようになるのかが心配になるほどの大盤振る舞いだ）
XenServer のアーキテクチャの特徴は、管理ドメインである Domain-0 の存在だ。
Xen のハイパーバイザーは確かにハードウェア上で直接動作するが、ハードウェアの認識、制御の大多数は管理ドメインである Domain-0 にインストールされた Linux が行う。
Domain-U と呼ばれる仮想ゲストの空間から発生した I/O は Domain-0 の Linux を通してハードウェアに伝えられる仕組みだ。
この仕組みの最大の利点は、利用可能なハードウェアの条件が「Linux の Inbox ドライバ、ないしサードパーティによる Linux 用ドライバがあること」のみという柔軟性にある。
昨今の Linux のハードウェアサポートはかなり充実してきており、余程の特殊なハードウェアでないかぎりは仮想サーバを組むに当たって問題になることはあるまい。
これはドライバ層まで自己でまかなっているが故に対応ハードウェアを揃えるだけで四苦八苦する VMware vSphere Hypervisor との大きな差となる。
例えば、前述した DAS のヘルスチェックの問題だが、Domain-0 に監視ツールをインストールすることでいとも簡単に解決する。
手厚い Linux サポートで定評がある 3ware 社の RAID カードなどの場合、Domain-0 に 3ware Disk Manager Version 2 (3DM2) をインストールすれば、Web ベースの RAID 管理ツールが利用できる。
NIC チーミングの問題もそうだ。
Domain-0 の Linux と、ストレージサーバの Linux とが互いにボンディングで通信すれば、P2P 通信においても帯域拡張が期待できる。
つまり、VMware vSphere Hypervisor で発生していた DAS 問題も SAN 問題も全て解決してしまうことになる。
XenServer を選択することによってハードウェア設計の柔軟性は途端に上がるのだ。
これは検討しない理由はない。
で、XenServer を一方的に褒めちぎっても仕方ないので、XenServer の懸念点も。
まず、Xen の生い立ちがそもそも準仮想化にあったこと。
VMware が行っている完全仮想化と異なり、準仮想化には仮想化される OS 側の対応が必要になる。
Linux などのオープンソースではカーネルが準仮想化に対応すれば良いが、Windows などのプロプライエタリではそうはいかない。
現在の Xen ではこの問題を解決するために完全仮想化もサポートしているが、今度は CPU 側に仮想化支援機能が必須となる。
もっとも、「サーバハードウェアを新調する」ことを前提とすれば仮想化支援機能の付いていない CPU を選択することなどないから、これは問題とはなりにくい。
問題となるのはお下がりのハードウェアなどで取り敢えず仮想化してみたいなどのカジュアルな用法に制限がある、という程度である。
次の問題が、利点にもなっている Domain-0 の存在。
Domain-0 にインストールされているのが通常の Linux であるから、インストールに要する容量が大きくなる。
VMware vSphere Hypervisor が最低 70MB なのに対して、XenServer の場合は最低 16GB と比較にならないほど大きい。
これは容量が大きいことを問題としているのではなく、容量が大きい ⇒ 構成プログラムが多い ⇒ バグが混入する蓋然性が大きい、という問題に発展しうることにある。
VMware vSphere Hypervisor にバグがないなどとは口が裂けても言えないが、Domain-0 が大きい分だけ数学的にはバグの発生率は高くなる。
これは計画停止の頻度上昇を招いてしまう危険性がある。
Domain-0 のドライバが Xen に最適化されていないことも問題となる。
VMware vSphere Hypervisor の Inbox ドライバが VMware vSphere Hypervisor に最適化されているのに対して、XenServer の Domain-0 のドライバは汎用なので、これが I/O のボトルネックになってしまう可能性も否定できない。
もっとも、I/O ボトルネックの問題は、それなりに集約度が高い高負荷環境にならない限りは顕在化しない可能性があり、自宅サーバ仮想化程度の範疇であれば I/O ボトルネックの問題を無視しても汎用性を取った方が得策という考え方もある。
仮想化ソリューションを展開している各社はとかく他社のソリューションを否定したがるが、使う側からしてみれば得手不得手を認識して適材適所で用いるのが理性的な回答だ。
VMware vSphere Hypervisor が大規模仮想化以外には使いづらいというのならば XenServer という選択肢もあるし、サポート窓口を統一したいというのなら Hyper-V もありだろう。
自宅サーバ仮想化程度の範疇であれば、正直 VMware vSphere Hypervisor も XenServer もパフォーマンスにそう違いはないだろう。
ならば導入障壁の低い方や使い勝手の良い方を選択したとしても問題は無い。
XenServer も選択肢に入れて吟味してみよう。
VMware vSphere HypervisorのソフトウェアiSCSIイニシレータ（またはNFSクライアント）はvmkernel（VMware vSphere Hypervisorの核になっているカーネル。ESXiの場合は管理コンソールもここと通信を行う）からターゲットまでパスを引くので、仮に10G NICをストレージパスに使用しても、仮想ホスト事に10G NICは不要だと思うのですが。
仮想ホスト自体のネットワークに10Gが必要な場合は当然10G NICが必要となりますが、さすがにそこまでのネットワーク負荷はないと思われる上に、Webサーバのように多数のクライアントからの接続で負荷がかかるのであれば、NICチーミング＆IPベースの負荷分散で十分吸収できると思われます。（この場合は802.1ADのHUBが必要っぽいですが）
まぁ、クロスケーブルでESXiホストとiSCSIターゲットを接続すると、そこが単一障害点となり、リンクトラブルが発生すると仮想ホストが全滅してしまうのが問題ではありますが。
私が「仮想ホスト」と言っているのはVMware vSphere Hypervisorを突っ込むハードウェア自体のことなので、airwingさんの言う「ESXiホスト」と同義になります。
「仮想ゲスト」を増やす度に10GbpsのNICを増やすヘマはやりません(笑)
言葉の定義が曖昧で申し訳ないです。
帯域に関してはWAN側、LAN側、SAN側で状況が変わってきます。
自宅サーバではWAN側の帯域はFTTHでもベストエフォートの100Mbpsが精々でしょうから、Webサーバのように多数のクライアントから続々来たところでたかが知れています。
なので単一障害点になることを承知で1.0Gbps一本でも充分です。
LAN側も割り切って使えば1.0Gbpsで充分でしょう。
ですが、仮想ゲストにデータベースを放り込んだ場合、完全なオンメモリデータベースとでも言うのでない限りはストレージに対して大量のI/Oが発生します。
巨大なデータベースのインポート処理や、WAN側から来るたかが知れたリクエストでもレスポンスを返す処理の複雑性によってI/O負荷は飛躍的に高まります。
なので裏方に当たるSAN側、すなわち仮想ホスト（ESXiホスト）⇔ストレージサーバの帯域は必要になってしまうのです。
ま～データベースはストレージサーバ側で物理的に走らせるという手段もありますけど、この帯域が確保できる保証がない限りＮＧですね。
VMware vSphere HypervisorのNICチーミングがこの辺りを保証してくれないのならば、XenServerもありだと思います。
おかしいなぁと思いつつ、コメントを書いておりました。
読解力がなく申し訳ありません。
（個人用途でESXiサーバを複数たてることを想像できなかったので・・・）
複数たてるならいっそEssentialライセンスを購入してESXサーバとかもありかもしれませんが、ライセンス維持費が馬鹿になりませんしねぇ。
Xenは使ったことがないので、何とも言えません。
Hyper-Vは「思ったより動く」というのが感想ですが、ゲストがほぼMS製OSに制限されてしまうのもネックですね。
実は私もその想定はなかったのですが、ストレージサーバ＋仮想ホストの構成で見積をきった途端に仮想ホスト側の性能をドガッと落とさないと大幅予算オーバという問題が生じてしまったので。
性能を一極集約した仮想ホストを作るよりも、それなりの性能で必要に応じて増やす方が初期投資が抑えられることに気付きました。
そういうわけで10Gbps NICのP2Pの場合は「仮想ホストを増やす＝10Gbps NIC×2を増やす」の等式が成り立ってしまうという計算をしました。
滅茶苦茶に非現実的です(笑)
仰るとおり、ライセンス維持費用がかかりすぎるので洒落になりませんね。
VMware のライセンス形態が変わりつつあるようで、将来的なライセンス維持費もとても個人で支払える範囲ではなくなってしまう可能性がありますしね。
Hyper-V は上記の通り、今回は想定に入れていません。
仰るとおり仮想ゲストが Microsoft OS に限定されてしまうと言うのも、Linux ゲストばかりの自分としては全く的外れですしね(汗々)