墜落日記 - 2010年8月18日の墜落
仮想マシン、稼働成功！
先日までで、PCI パススルーにより 3ware SAS 9750-8i を仮想マシンから直接的に制御することが可能になった。
また、仮想マシンに監視ツールである 3ware Disk Manager Version 2 (3DM2) をインストールすることで、仮想マシンから物理ハードウェアである 3ware SAS 9750-8i の状態監視をすることにも成功。
VMware ESXi をストレージが物理的に接続されている環境にインストールした場合―――即ち DAS 環境での場合にストレージの状態監視が出来なくなってしまう問題にも対処可能となった。
これにより仮想マシンでありながらも仮想化されていない物理ストレージに対して直接 I/O を発生させディスクを効率よく利用可能で、状態監視まで可能なストレージサーバの技術基盤を得ることになった。
そこで本日は、仮想マシン環境上に用意されたボリュームを NFS で公開し、VMware ESXi から NFS データストアとして参照、別の仮想マシンを起動するまでにチャレンジしてみた。
ちなみにネットワーク経由のストレージとしてはオーバヘッドが幾重にも影響する NFS よりも iSCSI の方が効率的だと考えられるが、iSCSI だと VMware 専用の VMFS でフォーマットされてしまう上に、未だ Linux 上から VMFS を安全にマウントする手段は自分が知る限りでは確立されていない。
また VMFS が領域拡張に対応していないので、あとから領域追加する場合には別の VMFS と結合する必要があるなど、主に運用性、メンテナンス性の面から NFS を採用した。
今まで自分は NFS の必要性に直面したことはなかったので、今回が初めての NFS である。
しかし NFS はある意味では枯れた技術であり、取り敢えず開けるだけなら情報はいくらでもある。
また Linux NFS-HOWTO という優れた情報源もあり、有効活用させて頂いた。
NFS のエクスポートは非常に簡単に終わった。
VMware ESXi の方にも NFS データストアとしてマウントできた。
試しに NFS を提供する仮想マシンの方をシャットダウンして NFS サーバを止めてみると、VMware ESXi の方からは認識できなくなった NFS データストアがグレーアウトされる状態になった。
再び仮想マシンを起動すると NFS データストアが復旧した。
仮想マシン側がストレージサーバになる鶏と卵の関係で問題が起こるのではないかという懸念点は払拭されたと思われる。
続いて、NFS データストアをデータストアブラウザで覗いてみると、正常に中のディレクトリ構造と格納ファイルの一覧が取得できた。
良い感じだ。
気をよくしてデータストアに格納されている仮想マシンをインベントリに追加してみる。
と、ここで恒例のトラブル発生。
インベントリへの追加作業は正常に行われたが、インベントリから仮想マシンを参照できない。
インベントリに追加した仮想マシンはグレーアウトされたまま、もちろん仮想マシンの編集、起動は以ての外だ。
もしかして VMware Server 2.0 で構築した仮想マシンを単純にインベントリに追加しようとしたのがいけないのかもしれない。
ならば仮想マシンを VMware ESXi から構築して、ディスクイメージだけ移動させればよいかな？ などと軽く考えて、仮想マシンを作成してみる。
………こけた(爆)
仮想マシンの設定画面は滞りなく使えたのだけど、構成ファイルを作るところでエラーが起こって先に進めなくなった。
どうも、NFS データストアに対してアクセスできていない感触だ。
なぜ？ データストアブラウザからは見えているのに？？
ん～、しかし、そうなるとアクセス権の問題だろうか？
NFS のアクセス制御ってどうなってるんだ？
/etc/exports でのクライアント制御はしたけど、ユーザに関する制御って考えてみれば何もやってないな………
クライアント側からのアクセスはサーバ側のどのユーザで動いているんだろう？
クライアント側とサーバ側でユーザ ID が一致していれば所有権が発生してしまうとか、そういう構造なんだろうか？
だとすれば VMware ESXi はどのユーザ ID で繋ぎに来ているのだろう？
で、気になる記述を見付けた。
Linux NFS-HOWTO の記事だが、サーバの root アカウントのファイルは通常では唯一クライアント側の root からアクセスできないファイルだと言うことだ。
/etc/exports で root_squash を指定するとこの状態になる様で、クライアント側の root はサーバ側の nobody にマッピングされるとのこと。
そうするとクライアント側の root からは何も読めない状態になるわけだ。
しかもこのオプションは標準とのこと。
no_root_squash オプションを指定した覚えはないから、これが最も怪しいか？
取り敢えず物は試しと言うことで、/etc/exports のオプションに no_root_squash を追加してみたら、インベントリに正常に表示された。
やはり NFS へのアクセス権の問題だったようだ。
NFS へ接続するネットワークは対外的に繋がっていない仮想スイッチ間のやりとりと、閉鎖系ネットワークで構築する予定なので、no_root_squash を追加していてよいだろう。
で、早速仮想マシンを起動してみると………
う、動いた、動いたよ、感無量だっ！！
とうとう動いた。
VMware ESXi にインストールされた仮想マシン Debian GNU/Linux Squeeze に PCI バススルーで与えたボリュームを NFS で公開し、これを VMware ESXi の NFS データストアに登録して利用するという鶏と卵の様なストレージ設計で、動きやがったよっ！！
取り敢えず気になるディスク I/O 性能を量ってみようと言うことで、VMware Tools の更新後に、CrystalDiskMark 3.0 でもってベンチマークを取ってみた。
環境は以下の通り。
- 5 回平均
- 1000MB の Read/Write
- NFS には sync オプションを付けて、書き込みは同期させる
その結果がコレだ。
- NFS Datastore (sync), 3ware SAS 9750-8i & CHENBRO CK13601H0C03, Seagate Constellation ES ST32000644NS×4 (RAID-10)
-
Sequential Read : 784.510 MB/s
Sequential Write : 137.392 MB/s
Random Read 512KB : 693.706 MB/s
Random Write 512KB : 61.975 MB/s
Random Read 4KB (QD=1) : 47.092 MB/s [ 11497.0 IOPS]
Random Write 4KB (QD=1) : 2.387 MB/s [ 582.7 IOPS]
Random Read 4KB (QD=32) : 175.832 MB/s [ 42927.8 IOPS]
Random Write 4KB (QD=32) : 2.247 MB/s [ 548.5 IOPS]
あ～、キャッシュが効き過ぎて Read でとても SATA 7,200rpm ハードディスク×4 の RAID-10 とは思えない別次元の数字が出ています………(汗々)
Sequential Write の 137.392 MB/s は単純計算で 1099.136 Mbps なのでギリギリ 1.0Gbps の速度を超えているが、どうだろう？
仮想スイッチを通ってかつ NFS データストア上にある仮想ディスクイメージを操作しているというオーバヘッドを考えると、なかなかの数字が出ているのではないか？
で、ついでなので NFS を標準の非同期動作 (async) でエクスポートして、同様のベンチマークを取ってみた。
- NFS Datastore (async), 3ware SAS 9750-8i & CHENBRO CK13601H0C03, Seagate Constellation ES ST32000644NS×4 (RAID-10)
-
Sequential Read : 789.590 MB/s
Sequential Write : 227.408 MB/s
Random Read 512KB : 718.824 MB/s
Random Write 512KB : 223.287 MB/s
Random Read 4KB (QD=1) : 42.489 MB/s [ 10373.3 IOPS]
Random Write 4KB (QD=1) : 32.904 MB/s [ 8033.3 IOPS]
Random Read 4KB (QD=32) : 153.038 MB/s [ 37362.8 IOPS]
Random Write 4KB (QD=32) : 47.066 MB/s [ 11490.6 IOPS]
Read の別次元な数字は当然そのままとしても、Write が順当に上がった。
Random Write のパフォーマンスアップに至っては、もはや使用前⇒使用後で特番組まれそうな勢いである。
なるほど、NFS 上に配備した表領域へのアクセスが妙に速いことがあるってのは、コレか………
また、Sequential Write で 227.408 MB/s というのは、もう完全に 1.0Gbps の Ethernet の帯域を超越している。
仮想 NIC 同士を仮想スイッチで繋いで閉鎖ネットワークを構築すると、1.0Gbps の帯域の呪縛から解き放たれるわけだ。
これは場合によっては有用なテクニックかもしれん。
と言うわけで、VMware ESXi 4.1 と PCI パススルー技術を組み合わせることで、物理サーバと同様の管理能力を持ったストレージサーバと、仮想化された開発環境のプラットフォームの同居が可能になった。
Debian GNU/Linux Squeeze に VMware Server 2.0 を乗せていた時の腫れ物を触るかのような変な不具合に悩まされることもなく安定しており、最新の VMware vSphere Client 4.1 で管理できるためクライアント環境への負荷もなくなった。
これを XenServer 5.6 の方で素直に出来れば XenCenter で一括管理できる利便性を得ることも出来たのだけど、今まで VMware Server や VMware Player 上に構築した開発環境の移行の工数を考えれば、妥当なところに落ち着いたのかも知れない。
コメントは投稿されていません。