墜落日記 - 2010年8月の墜落
2010年8月31日
Link Aggregation を使ってみた
本日は自分の「生まれてきちゃって御免なさい記念日」なので、ダメ押しの浪費をしてみた。
CPU のグレードもコア数も落としたはずなのになにげに良く動くストレージサーバと仮想ホストなので、より開発環境として有効活用できるようにメモリを発注。
それぞれ 16GB とする予定。
分かっちゃいたコトだけど、仮想化で環境集約すると CPU 処理性能よりもメモリ容量で先に限界が来るみたいだね。
購入しているメモリは ACTICA ACT4GHR72R8G1333M (DDR3-1333 Registered ECC DIMM) なので、マザーボード X8SIE-LN4 の仕様上は 6 本・32GB まで差せる筈だけど、現実的には 24GB が限界かな？
あと、現状のファイルサーバを潰した後に弾き出される 1.0TB×4 のハードディスクを収納するためにエンクロージャを発注。
こちらは例によって SUPERMICRO CSE-M35T-1B v2.0 で、結局 CSE-M35T-1B が都合３基、最大 15 本のハードディスクをぶっさせる環境となる。
現状で SAS×4、SATA×4、予定で更に SATA×4 が刺さるので、あと 3 本分の余裕が。
９月には某所のオフ会もあるし、RAD Studio の年間サポートもまだ払っていないので、順調に赤貧ダイブ敢行中の自分である。
閑話休題。
昨日は NFS、iSCSI それぞれのストレージの転送速度を比較したが、今度はロードバランシングを考えてみたい。
NFS、iSCSI も、ピーク時の帯域は物理層の 1.0Gbps という上限値によって制限を受けた。
シーケンシャルリードの場合、これは大体 7200rpm の SATA ハードディスク１本分くらいの転送速度である。
ランダムアクセスの場合にはハードディスクの処理性能が帯域に追いつかないので、ストレージ側で RAID 構成などを行えば 7200rpm の SATA ハードディスク１本分の性能を越える転送能力を得ることは出来るが、その程度である。
物理層の 1.0Gbps という制限は最後までボトルネックなのである。
ここで XenServer と Linux で構築した iSCSI ストレージの組み合わせであれば、複数の NIC をひとまとめにして単純な帯域拡張と冗長化が出来る。
これらは Linux が備えているボンディングの機能で、ラウンドロビンでパケット単位の振り分けを行うことで実現できるようだ。
（実際にやったこと無いから効果の程は知らんけどね）
ちなみに。
この Linux のボンディングで採用しているラウンドロビンでのパケット単位の振り分けは、特に TCP パケットの場合にはパケットの前後関係が送信側と受信側でずれてしまう可能性が高くなり、再送要求が増えてしまう可能性があると思う。
この辺りの問題を押さえるためにどのように処理しているのかも興味があるのだけど、取り敢えず本題ではないのでそのうちに。
で、話を戻す。
VMware ESXi の NIC チーミングでは XenServer と異なり、ボンディングによる単純な帯域拡張は出来ない。
VMware ESXi が可能なのは、複数のパスから１つのパスを「選択する」だけで、パスが選択された後の通信に於いては 1.0Gbps の帯域による制限を依然として受けてしまう。
従って、VMware ESXi の帯域拡張は、如何に効率的にパスを「選択する」かによる。
ここで iSCSI ターゲットへの帯域拡張を考えてみる。
XenServer と Linux iSCSI ストレージの関係ならば、それぞれが１個ずつの IP アドレスを持って、複数の NIC を束ねてボンディングすれば解決だと思うが、前述のように VMware ESXi の場合にはそう簡単にはいかない。
まず iSCSI ターゲット側には物理的に複数の NIC（ここでは２つを想定する）を用意して、それぞれ 192.168.0.10、192.168.0.11 の IP アドレスを与えたい。
この２つの IP アドレスで同じ iSCSI ターゲットに接続できる様に用意するのだ。
これで理論上 1.0Gbps×2 の 2.0Gbps の帯域が確保できることになる。
しかし、ここで問題になるのが、自分の環境ではストレージサーバ自体が仮想化されているため、仮想 NIC と物理 NIC の関係性は保証外、ということだ。
これを解決するには以下の様なプランが考えられる。
まず２つのポートグループを同一の仮想スイッチ上に構築する。
仮想マシンには用意した２つのポートグループにそれぞれ対応する仮想 NIC を与えて、IP アドレスをそれぞれ 192.168.0.10、192.168.0.11 と与える。
続いて、２つのポートグループに対してフェイルオーバー順序をそれぞれ明示的に指定、ポートグループで固定したい物理 NIC を「有効なアダプタ」に、別のポートグループで利用する物理 NIC は「未使用のアダプタ」に振り分けることで、特定のポートグループで特定の物理 NIC しか使わないように設定する。
これにより、192.168.0.10 と 192.168.0.11 で強制的に物理 NIC を分割することが出来るだろう。
本来は PCI パススルーにより物理 NIC を占有させたかったのだが、どうにもこうにも動かないので苦肉の策だ。
で、厄介なのは iSCSI イニシエータ側の設定だ。
ストレージネットワーク用に 192.168.0.20 の IP アドレスを与えた仮想 NIC を用意し、仮想スイッチに物理 NIC を２つ追加、ポートグルーブに対して NIC チーミングを設定。
iSCSI のパスに上記の２つの経路のパスをそれぞれ与えてロードバランシングしても、特定の物理 NIC に帯域が偏ってしまう様だ。
これを回避するために iSCSI Port Binding を利用する方法が以下の記事で紹介されている。
これは大雑把に言うと、上記で iSCSI ターゲットの２つのポートグループに対して物理 NIC を固定化したような方法を iSCSI イニシエータ側の VMkernel ポートにも行い、それぞれの VMkernel ポートを明示的に iSCSI イニシエータに登録してパスを拡張するという方法だ。
そうすると、iSCSI ターゲット側パス２系統と、iSCSI イニシエータ側パス２系統で、都合４系統のパスが認識されるようになる。
これは NIC チーミングの機能を利用せず、旧来の Fibre Channel SAN なんかで利用されている方法を持ち込んだイメージだ。
この方法は、正直言ってやや面倒くさい。
しかも VMware ESXi の管理コンソール上での作業も必須になるため、VMware vSphere Client から明示的に状況が確認できない。
なので、我が家では次善の策を試してみようと思う。
ここで選択肢にあがるのが Link Aggregation である。
Link Aggregation に関しては以下の記事が詳しい。
VMware ESXi では NIC チーミングのロードバランシングの設定で「IP ハッシュに基づいたルート」を設定すると Link Aggregation になる。
Link Aggregation は IEEE 802.3ad で規定されていても負荷分散に関する具体的な方法は特に記述がないとのことだが、VMware ESXi では送出元と送出先の IP アドレスのペアから算出されるハッシュ値を用いて物理 NIC を選択するので、上記で面倒くさい設定をしている部分をスッ飛ばして、ロードバランスが出来る筈だ。
つまり、「192.168.0.20⇔192.168.0.10」と「192.168.0.20⇔192.168.0.11」では当然物理 NIC が分離され効果的に選択される筈なのである。
iSCSI のパス選択はラウンドロビンにしておくダケでよいだろう。
ちなみに、Link Aggregation では L2 スイッチ側の対応も欠かせないが、こんなこともあろうかと IEEE 802.3ad に対応したスマートスイッチ NETGEAR GS108Tv2 を購入しているので、万事 OK だ。
プランは出来たので、早速作業開始だ。
仮想ホスト側の仮想 NIC に 192.168.0.20 の IP を与え、仮想スイッチには２つの物理 NIC を与える。
NIC チーミングのロードバランシングは「IP ハッシュに基づいたルート」を選択する。
パスの選択はラウンドロビンを明示的に選択、パスを I/O によって自動的に振り分ける様に設定する。
これで VMware ESXi 側の Link Aggregation の準備は出来た筈。
ついでにストレージサーバ側の構成も調整。
ストレージサーバを担う仮想マシンに２つの仮想 NIC を接続、仮想スイッチにも物理 NIC を２つを設定して、ポートグループの NIC チーミングのロードバランシングを「IP ハッシュに基づいたルート」に設定する。
ストレージサーバ側に２つの IP アドレスを持たせたのは無論ストレージパスを２つ構成させるためで、ストレージサーバ側も Link Aggregation による物理 NIC のロードバランシングを期待する。
スマートスイッチ NETGEAR GS108Tv2 はウェブブラウザから入れる管理画面でもって、仮想ホストとストレージサーバのそれぞれのポートグループに対して Link Aggregation の設定を有効にしてみた。
NETGEAR GS108Tv2 は合計４系統の Link Aggregation グループを設定することが出来るが、今回は２ポートずつの合計４ポートで、２系統の Link Aggregation グループを構築した。
で、いよいよ仮想ホスト側で iSCSI ストレージより仮想マシンを２つ起動して、その２つの仮想マシンから同時にベンチマークを走らせてみた。
VMware vSphere Client のパフォーマンスモニタと、実際の GS108Tv2 の LED で眺めていると、仮想ホスト側もストレージサーバ側も物理 NIC に対してほぼ均等にロードバランシングされていることを確認した。
Link Aggregation は正常動作していると思われる、思われるのだが………
ロードバランシングが正常に働いている割には処理能力は合計すると物理 NIC ひとつ分だ(爆)
どういうワケか、仮想マシン単品で走らせた場合の性能の大凡半分程度の性能しか双方の仮想マシンで出てこない。
物理 NIC の帯域を VMware vSphere Client のパフォーマンスモニタで眺めてみても、それぞれの帯域に余裕がある。
これはどういうことだ………？
全く同じベンチマークを同時に同一のアレイに対して働かせたから性能が落ちたか………？
仕方ない。
状況が分からないので、SATA で組んだアレイから、SAS で組んだアレイに仮想マシンをひとつコピーして、コチラでベンチマークを取ってみることにする。
そうすれば同一アレイ上で同時に２つのベンチマークが走ったコトによる負荷集中は避けられると思う。
で、再度ベンチマーク………結果は確かに変わった。
SATA アレイ×２で実施したベンチマークの結果よりも、SATA アレイと SAS アレイで分割して実施したベンチマークの結果の方が平均的に向上している。
ほぼ同時に開始したシーケンシャルリードも双方共に 70～75MB/s 程度で出ているので、合計の帯域は 140～150MB/s 程度が出ていると思われる。
少なくとも 1.0Gbps の物理 NIC 単品で出せる数字ではないだろう。
しかし何だろう？ もう少し出ても良いような気がするのだけど？
では、仮想ホスト側とストレージサーバ側双方で Link Aggregation していたのを、ストレージサーバ側を固定パスにしてみようか。
手法は上記の明示的なフェイルオーバ順序の設定で、強制的にポートグループと物理 NIC を紐付けてしまう方法を利用する。
で、ベンチマークとパフォーマンスモニタの参照………
ストレージサーバ側がロードバランシングされてねぇ～よっ！！
ううむ、うまく経路選択でロードバランシングされなかった。
どこにボトルネックが発生しているのかも含めて、まだまだ研究の余地があるなぁ～
2010年8月30日
仮想ホスト構築開始
ストレージサーバの構築で長いこと足踏みしていたので、そろそろ仮想ホストの構築に移行したい。
早いところ仮想ホストを構築して環境を再構築しなければ、現行のサーバを回しっぱなしにしなければならなくなってしまう。
ま～現在のトコロは現行のサーバに故障する予兆は出ていないけど、流石にもう古いし………
ということで、まずは電源配線工事から(爆)
今まで電源配線はあまり計画的に行っていなかったので、UPS に唐突に無線 LAN のアクセスポイントがぶら下がって電源コネクタを一個塞いでしまっていたりと無駄が多い。
消費電力が小さい物と、サーバ仮想化により将来的に無くなってしまうマシンの電源をマルチタップに集約し、UPS 本体の電源コネクタに余裕を作り、仮想ホストとストレージサーバの電源を差す余裕を作る………のに、２時間(爆)
なにげにもう今夜はダメだと力尽きる重労働(汗々)
で、ルータだのファイルサーバだの小型サーバが群がっているラックに、組んだまましばらく眠っていた仮想ホストを設置、KVM スイッチに繋いで LAN ケーブルをぶっさして VMware ESXi をインストール。
インストール自体は全く問題なく進行し、NFS ストレージと iSCSI ストレージを接続、それぞれの環境のインベントリへの登録が完了した。
で、仮想マシンの起動試験………こちらも問題なし。
ちなみに１台目の仮想ホストの名前は『ブリュンヒルデ（brunnhilde）』と命名した。
ワーグナーの『ニーベルングの指輪』に登場するワルキューレ姉妹の長女の名前で、仮想ホストが増えていった場合には同様にワルキューレ姉妹の名前を付けていくつもり。
ただ、ブリュンヒルデ以外の姉妹の順番はイマイチ分からなかったので、語感の好みにより以下の順番で命名する予定。
- ブリュンヒルデ - brunnhilde
- オルトリンデ - ortlinde
- ロスヴァイセ - rossweisse
- ヘルムヴィーゲ - helmwige
- シヴェルトライテ - schwertleite
- ヴァルトラウテ - waltraute
- ジークルーネ - siegrune
- グリムゲルデ - grimgerde
- ゲルヒルデ - gerhilde
とは言っても、実際には増えたとしても精々ロスヴァイセまでだと思うのだけど(汗々)
で、早速ディスク I/O のベンチマーク。
まずは NFS ストレージ。
NFS に限らず VMware ESXi のマルチパス構成ではパケット単位でのラウンドロビンは行わないため、仮想マシンごとにパス構成が分離できたとしても、P2P での帯域拡張は望めない。
従って、1.0Gbps という物理的な上限がある中でのベンチマークとなる。
なお、SAN を構成するネットワークは L2 スイッチ NETGEAR GS108Tv2 を核にして、ストレージの I/O 以外のトラフィックは流れない閉鎖系を構成した。
- NFS Datastore (async), 1.0Gbps, NETGEAR GS108Tv2 (L2), 3ware SAS 9750-8i & CHENBRO CK13601H0C03, Seagate Constellation ES ST32000644NS×4 (RAID-10)
-
Sequential Read : 109.011 MB/s
Sequential Write : 108.661 MB/s
Random Read 512KB : 105.567 MB/s
Random Write 512KB : 104.022 MB/s
Random Read 4KB (QD=1) : 12.020 MB/s [ 2934.6 IOPS]
Random Write 4KB (QD=1) : 11.888 MB/s [ 2902.3 IOPS]
Random Read 4KB (QD=32) : 113.495 MB/s [ 27708.6 IOPS]
Random Write 4KB (QD=32) : 53.425 MB/s [ 13043.1 IOPS]
なんか順当に落ちたなぁ～
仮想スイッチしか通っていない時と比較するのは流石に可哀相だけど、なかなかに切ないスコアになってしまった。
大凡の性能は 7200rpm の SATA ハードディスク 1 本分くらいと言ったところか。
ランダムアクセス性能が SATA ハードディスク 1 本分よりも総じて高いので、実際の体感速度はそれよりも勝るかもしれないけど。
続いて、同環境で iSCSI ストレージ。
こちらは同一の iSCSI ターゲットに２つの IP アドレスでマルチパスを構築しているが、諸事情から仮想スイッチを通ってしまっているため、ちと微妙かも知れぬ。
（PCI パススルーだと Intel 82574L が使えなかった）
- iSCSI Datastore (iSCSI Enterprise Target), 1.0Gbps, NETGEAR GS108Tv2 (L2), 3ware SAS 9750-8i & CHENBRO CK13601H0C03, Seagate Constellation ES ST32000644NS×4 (RAID-10)
-
Sequential Read : 110.808 MB/s
Sequential Write : 108.526 MB/s
Random Read 512KB : 107.386 MB/s
Random Write 512KB : 69.678 MB/s
Random Read 4KB (QD=1) : 11.890 MB/s [ 2902.8 IOPS]
Random Write 4KB (QD=1) : 2.476 MB/s [ 604.6 IOPS]
Random Read 4KB (QD=32) : 115.946 MB/s [ 28307.1 IOPS]
Random Write 4KB (QD=32) : 2.522 MB/s [ 615.7 IOPS]
やはりネットワーク帯域により性能が頭打ちになっているので、ピーク時性能は NFS と大して変わらず。
ただ、NFS は非同期機能により書き込み応答速度が平均して向上しているので、ダイレクトに書き込みを発生させて I/O 待ちを行う iSCSI が書き込みで平均して劣っている模様。
むむむ、これは微妙だ。
iSCSI だとマルチパス構成でラウンドロビンなどを利用すればある程度は VMware ESXi 側にマルチパスを任せておけると思う。
しかし NFS ではストレージサーバ側で明示的に複数の IP アドレスで NFS をエクスポートして、仮想ホスト側で NFS ストレージを複数設定する様にでもしない限りはマルチパスが出来ない。
しかも固定パスとなるので、ストレージパスの冗長性能は向上しないし、柔軟性もない。
だが書き込み性能は NFS の方が平均的に上だ。
さて、どうしてくれようか………？
ちなみに、iSCSI ターゲットへ向かうパスが仮想スイッチを通ってしまっている件に関して。
予定では 3ware 9750-8i と同様に PCI パススルーを利用して、４系統ある Intel 82574L の内の２系統をストレージサーバを担う仮想マシンに占有させてしまうつもりだった。
しかし VMware ESXi 上でパススルーして、仮想マシン上の Debian GNU/Linux Squeeze からも PCI デバイスが認識できたにもかかわらず（lspci でも列挙された）、利用できなかった。
ロードされているモジュールをリストアップすると e1000e もあったのでモジュール自体はロードされている様なのだけど、本来出現するべき eth2、eth3 が現れない。
Debian GNU/Linux Squeeze を直接インストールした際にはちゃんと認識していたのだけど、どうにも理由が分からない。
dmesg をから該当する部分を 0b:00.0 をキーに抽出すると、こんな感じで出ていた。
[ 0.398328] pci 0000:0b:00.0: reg 10 32bit mmio: [0xd9e20000-0xd9e3ffff]
[ 0.398517] pci 0000:0b:00.0: reg 18 io port: [0x5000-0x501f]
[ 0.399810] pci 0000:0b:00.0: reg 1c 32bit mmio: [0xd9e04000-0xd9e07fff]
[ 1.418737] e1000e 0000:0b:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 1.418963] 0000:0b:00.0: 0000:0b:00.0: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts.
[ 1.419125] 0000:0b:00.0: 0000:0b:00.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts.
[ 1.522167] e1000e 0000:0b:00.0: PCI INT A disabled
[ 1.527135] e1000e: probe of 0000:0b:00.0 failed with error -2
………すまん、俺には何のことかぜんっぜん、分からん。
取り敢えずハードウェアとしては認識しているのだけど、拡張 MSI でも MSI でも初期化できないから使わない………という意味だろう。
そもそも、MSI (Message Signaled Interrupts) って何だ？
こちらの記事によると割り込み関連の仕組みのようだが？
仮想スイッチを通っていたり VMware ESXi の NIC チーミングの管理下にあったりするとパスの挙動が分かりにくくなるから本音は避けたい。
これはフェイルオーバー順序を明示的に指定して、仮想 NIC と物理 NIC の対応を強制してしまおうか………？
うむ、なかなか上手く行かない物だ。
2010年8月29日
iSCSI ストレージの構成を試してみる
ちょっと間が開いてしまったが、最近色々と忙しくてサーバ構築が手に付かなかった。
未だに外向きの仮想ホストを VMware ESXi で行くか、XenServer で行くか迷っている自分だが、なんか色々と VMware ESXi の設定を VMware vSphere Client から眺めていると、NFS だとマルチパス構成が取れないっポイ。
ま～考えてみれば当たり前なんだけど、明示的かつ物理的に複数の NIC を異なる IP で設定しないと、NFS の場合のマルチパスは難しそう。
それにたとえ出来たとしても固定パスに近い状態で、ロードバランスしてくれないのではないかとの疑問も………
というわけで、今回は iSCSI ターゲットを構築してみる。
iSCSI はハードディスクの接続規格である SCSI のプロトコルを TCP パケットに乗っけて Ethernet 上を飛ばしてしまう規格だ。
現在構築中の Debian GNU/Linux Squeeze では iSCSI Enterprise Target のパッケージが用意されている様なのでコチラを利用する。
で、ここで若干厄介な問題に遭遇。
iSCSI ターゲット自体は以下のコマンドで簡単に導入できるのだが………
aptitude install iscsitarget
カーネルモジュール iscsi_trgt がインストールされない。
これが Lenny なら iscsitarget-modules-2.6.26-2-amd64 パッケージが用意されているのだけど、なんか Squeeze ではコレに相当するパッケージが見付からない。
あるのはソースコードパッケージのみ、だ。
仕方ないので、DKMS 版のカーネルモジュールのソースコードパッケージを取得する。
最初に DKMS をインストールする。
aptitude install dkms
続いて、DKMS 版のカーネルモジュールのソースコードパッケージをインストールする。
aptitude install iscsitarget-dkms
すると勝手にカーネルモジュールがコンパイルされ、無事にインストールが完了した。
初めて DKMS を使ってみたが、なんかよく分からない動きをする。
あとで気が向いたらよくよく調べてみよう。
続いて iSCSI ターゲットに公開する論理ボリュームを作成し、/etc/iet/ietd.conf と /etc/default/iscsitarget も設定して iSCSI ターゲットを起動してみた。
インストールさえ出来てしまえばこちらの問題はほとんど無し。
VMware vSphere Client から VMware ESXi の iSCSI ソフトウェアイニシエータを有効にして、iSCSI ターゲットを検索してみると、正常に見付かったのでそのままストレージとして構成。
ためしに VMware vSphere Client で既存の Windows Server 2003 R2 Standard Edition のテンプレート環境をコピーして起動してみた。
あ～………動かん………？
モジュール DevicePowerOn のパワーオンに失敗しました。
scsi0:0 用の仮想 SCSI デバイスを作成できません。「/vmfs/volumes/ ... /WS2003SE_iSCSI/sda.vmdk」
ディスク scsi0:0 を開けませんでした。サポートされていないか無効なディスク タイプ 8 です。ディスクがインポートされていることを確認してください。
こちらの仮想ディスクは元々 VMware Player 3.0 で構築した物を、VMware ESXi 4.1 の NFS ストレージへコピーした物。
NFS ストレージ上で仮想マシンを起動した際には問題なく起動したのだが、iSCSI ストレージへコピーするとダメというのは何故だ？
iSCSI ストレージ上に直接作った仮想マシンのハードディスクだとちゃんと認識するので、NFS ストレージからコピーした仮想ディスクの方に問題があるということか？
データストアブラウザで確認すると、コピー元とコピー先でサイズが違うし、iSCSI 上に直接作った仮想ディスクともサイズが違う。
VMware ESXi に SSH でログインして仮想ディスクの状況を見てみると、元々のディスクは固定サイズだったはずなのに、何故かコピー先の仮想ディスクはシンプロビジョニングされた様な 2GB 分割状態。
iSCSI 上で直接作った仮想ディスクはちゃんとフラット？
ためしに VMware ESXi に SSH でログインしたまま、cp コマンドでもって仮想マシンをコピーしてみる。
で、起動すると………
動いた。
どうもデータストアブラウザで仮想ディスクをコピーした際に変なことされるようだ。
原因は別途調べなければなるまいな。
さてさて、iSCSI ストレージ上で仮想マシンが無事に動いたところで、実は最初にやりたかったのはディスク I/O のベンチマーク。
仮想スイッチのみ経由している NFS と同様に仮想スイッチのみ経由している iSCSI でどの程度の性能が出るのか確認したい。
NFS の方は SATA 7,200rpm 2.0GB×4 で RAID-10 構成したアレイ上に構築した論理ボリュームを ext4 でマウントして公開している。
iSCSI の方は NFS と同様にSATA 7,200rpm 2.0GB×4 で RAID-10 構成したアレイ上に構築した論理ボリュームを直接に公開している。
従って iSCSI の方がファイルシステム等のオーバヘッドが生じない分だけ有利な筈だが、非同期動作にすると劇的に性能が上がった NFS がドコまで食い下がれるのだろうか？
で、結果がこれだ。
- iSCSI Datastore (iSCSI Enterprise Target), 3ware SAS 9750-8i & CHENBRO CK13601H0C03, Seagate Constellation ES ST32000644NS×4 (RAID-10)
-
Sequential Read : 520.213 MB/s
Sequential Write : 147.417 MB/s
Random Read 512KB : 454.080 MB/s
Random Write 512KB : 63.644 MB/s
Random Read 4KB (QD=1) : 42.457 MB/s [ 10365.4 IOPS]
Random Write 4KB (QD=1) : 2.328 MB/s [ 568.5 IOPS]
Random Read 4KB (QD=32) : 107.872 MB/s [ 26336.1 IOPS]
Random Write 4KB (QD=32) : 2.330 MB/s [ 568.8 IOPS]
前回の NFS での結果も乗せてみる。
- 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]
なんと、仮想スイッチだけしか通していない状態では iSCSI よりも NFS の方が総じて高性能であるとの結果が出た。
というよりも iSCSI は NFS の同期動作時とほぼ同程度の転送能力しか得られなかった。
NFS の場合には同期でも非同期でも性能が変わらなかったシーケンシャルリードが、iSCSI の場合に低いことは疑問点だけど、取り敢えずここから考えると非常に簡単な結論が導き出せると思う。
iSCSI は SCSI のプロトコルのラッパーでしかないので、ディスク I/O レベルでのキャッシュが効きにくい。
NFS でも同期動作時では iSCSI と同程度の性能であったため、NFS の非同期動作は非常に大きい効果を発揮していることが分かる。
ちなみに。
現在構築している仮想環境のストレージは、仮想マシンに PCI パススルーによって SAS アダプタを割り当てて、仮想マシンから NFS や iSCSI をエクスポートして利用するという、「鶏と卵」状態での構築となっている。
ここでどうも、iSCSI の場合には問題が起こるようだ。
NFS ストレージの場合、まだストレージサーバを担う仮想マシンが起動していない場合では、データストア一覧で当該ストレージから取得されたデータストアが利用不能だとグレーアウトされる状態になる。
その後、ストレージサーバを担う仮想マシンを起動して NFS が利用可能になると、おそらくネットワーク状態をポーリングしているのだろう、自動的に当該ストレージから取得されたデータストアが利用不能状態から復帰する。
しばらく待てばインベントリの仮想マシン一覧も正常に取得されるようになる。
しかし iSCSI の場合、そうはいかないようだ。
iSCSI ストレージの場合、まだストレージサーバを担う仮想マシンが起動していない場合では、データストア一覧から当該ストレージから取得されたデータストアがサクッと情け容赦なく消えてしまう。
しかもその後、ストレージサーバを担う仮想マシンを起動して iSCSI が利用可能になっても、ストレージアダプタで iSCSI ターゲットを認識しなくなってしまうし、当然データストアは復旧されない。
NFS の様な相手側が落ちていることも前提に入れなければならないストレージと違い、iSCSI の場合には iSCSI ターゲットが落ちていないことを前提としている節がある。
自分の環境が特殊なのは認めるが、正直これでは非常に使いづらいので何とかしたい。
しかし、何故か何度ストレージアダプタの再スキャンを行っても iSCSI ターゲットが認識されない。
一端認識できなくなった iSCSI ターゲットは二度と接続できないなんてナンセンスな仕様はあり得ないと思うので、試しに Windows 7 の iSCSI イニシエータから接続しようとしてみたら、CHAP 認証がどうにもうまくいかない。
iSCSI Enterprise Target の CHAP 認証を無効化してから再度 Windows 7 からの接続を試行すると成功した。
で、続いて VMware ESXi から iSCSI ターゲットを認識しに行ってみたら、今度は認識した。
う～ん、CHAP 認証に失敗していたってコトなんだろうか？
だったらそうだと言って欲しいんだけど、最初に接続できたのは何だったんだ？
ここで再度ストレージサーバを担う仮想マシンをシャットダウンして、iSCSI ターゲットを無効化してみる。
で、仮想ホストを再起動………
やはり iSCSI は自動的に復旧しない。
手動で再スキャンをかけてやると iSCSI ターゲットを認識して、iSCSI ターゲットから構築していたデータストアが復活（！？）した。
グレーアウトされることもなく抹消されていたデータストアがポコッと出現したのである。
何故に NFS ストレージの時と動作が違うのか問いただしたい心境だ。
ここでもう一度ストレージサーバを担う仮想マシンをシャットダウンして、iSCSI ターゲットを無効化してみる。
で、仮想ホストを再起動。
ストレージサーバを担う仮想マシンを起動して、今回は手動での再スキャンをかけずに延々と待ってみるが、30分放置してダメだった。
やはり自動復旧はしない模様、手動再スキャンでやっと復旧した。
これ、停電なんかで UPS と連動して自動シャットダウンさせた際に、自動再起動の順番が非常にタイトな状況になるってことだよな？
VMware ESXi の起動よりも iSCSI ストレージの起動の方が確実に早くないと復旧できない。
結構面倒くさいぞ、これ………(汗々)
なにげに、データセンターの様な非常に管理された電源設備を持っているところではなく、精々 UPS との連動程度しか投資できない自宅なんかの場合、iSCSI での運用って非常に難しいのでは？？
この辺りも色々と研究してみないとダメだなぁ～
まだまだ問題は山積だ………(涙)
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 上に構築した開発環境の移行の工数を考えれば、妥当なところに落ち着いたのかも知れない。
2010年8月17日
VMware vSphere Hypervisor で思い付きを形にしてみたらハングアップした
先日の思い付きを形にしてみた。
ダメで元々の VMDirectPath を試してみようと思い立ったのである。
最初に VMware vSphere Hypervisor (VMware ESXi 4.1) をインストールする。
で、クライアントには VMware vSphere Client 4.1 を導入して管理する体制を整える。
VMware vSphere Client で接続してみると、VMware vSphere Hypervisor だけではろくな容量を食わないから、32GB の SSD の 24.3GB ほどがローカルストレージとして残った。
取り敢えず最近の ESXi は遊んでいないので、PCI パススルーがどのように提供されているかを確認する。
すると非常に直感的に PCI デバイスの PCI パススルーの設定があることに気付いた。
取り敢えずそれだけ確認して、ゲスト OS をインストールしてみる。
VMware ESXi 4.1 にはまだ Debian GNU/Linux Squeeze のテンプレートは無いので、"Other Linux 2.6.x kernel 64-bit" を選択してインストール。
インストールも滞りなく完了した。
この辺りは VMware Server 2.0 でも慣れ親しんでいるので非常にスムーズ。
Debian GNU/Linux Squeeze のインストールが完了したら一端終了。
3ware SAS 9750-8i と 2 つの物理 NIC を PCI パススルー指定して、3ware SAS 9750-8i を PCI デバイスとしてゲスト OS に割り当てる。
で、ゲスト OS を起動して lspci でデバイスを確認すると、3ware SAS 9750-8i が問題なく繋がっていた。
続いて lvm2 パッケージを導入して LVM を使える状態にすると、3ware SAS 9750-8i に繋がっているアレイ上に構築しっぱなしの LVM を唐突に認識、pvs や lvs などで確認できるようになった。
むむ、これはもしや、PCI パススルーに成功している！？(嬉)
あまり期待していなかっただけに、これは朗報だ。
上手く行けば VMware ESXi 4.1 で環境構築の方向性を確定できる。
しかし、もはや当然の如く問題は発生するのだ。
いい加減に糞重いリモートクライアントで作業しているのが億劫になったので外部から SSH で接続しようと、ssh パッケージをインストール。
sshd の設定をしてクライアントから SSH で接続………失敗した？
おかしい、設定は間違っていないはずだ。
取り敢えずネットワークの導通を確認しようと、ゲスト OS からクライアント側へ ping を飛ばしたら………ゲスト OS がハングアップした。
Management Network とゲスト OS のネットワークを同一にしていたせいか、VMware vSphere Client からも接続できなくなった。
VMware ESXi 自体が死んだのかと思って VMware ESXi 4.1 をインストールした実機の画面を見てみると、VMware ESXi 自体は死んでいない。
実機から直接に再起動をかけると仮想ホストは無事に再起動した。
どうも、仮想 NIC か仮想スイッチかが死んでいるのではないかと思われる。
しかし apt の設定の後に外部のリポジトリからパッケージを取得しているので、最初からネットワークが死んでいたとも考えられない。
PCI パススルーが干渉したかと思って、PCI デバイスを取り外し、PCI パススルーも解除して VMware ESXi 自体も再起動する………現象変わらず、ping でハングアップ。
こ、これは、PCI パススルー関係なくハングアップしくさっているではないくぁ！？(汗々)
VMware Tools をインストールしていないコトによる問題か？
VMware Tools がインストールされていない場合、パフォーマンス面の問題は出たとしても落ちることはないと思うのだけど？
なんにしろ PCI パススルーなんてけったいな技術も使っていないのにハングアップというのは穏やかではない。
と言うか、どうしてこう、素直にいかないのか(涙)
愚痴のひとつも言いたくなるなぁ～………(涙)
取り敢えず、色々と試してみる。
VMkernel ポートと仮想マシンポートを仮想スイッチ単位と物理 NIC 単位で完全に分離してもダメだった。
仮想マシンポートだけでなく VMkernel ポートも止まってしまった。
………って、あれ？
VMware ESXi の Management Network に割り当てた IP アドレスと、ゲスト OS の IP アドレスが衝突している………？
どうしてどっちも 172.30.100.10 なんだ？
Management Network の方は 172.30.100.20 の予定だったんだが？
もしかして、これけ？ これなのけ？
仮想マシンを起動して、クライアント側に ping を打ってみると………
だぁ～っ！！ 届いたぁ～っ！？ これかぁ～っ！？
深呼吸して、落ち着いて、自分を指差して心の声を張り上げよう。
みなさんっ！！ 馬鹿ですっ！！ 馬鹿がココにいますっ！！
くだらない、実にくだらない問題を解決できたので、再度 3ware SAS 9750-8i の PCI パススルーに挑戦してみる。
VMware vSphere Client でホスト自体を選択し、[構成]→[ハードウェア詳細設定]→[パススルーの構成...] と順に押下する。
するとパススルー可能なデバイスの一覧が出るので、01:00.0 の「3ware Inc 9750 SAS2/SATA-II RAID PCIe」をパススルーする設定にして、VMware ESXi 自体を再起動する。
再起動したら、パススルーしたデバイスを割り当てたい仮想マシンを選択し、[仮想マシンの設定の編集]を押下して設定画面を開く。
で、[追加...]を押下すると PCI デバイスが選択可能になっているので、ウィザードに従ってパススルーしたデバイスを直結する。
で、仮想マシンを起動。
ハングアップすることなく無事に起動したら lspci コマンドで認識された PCI デバイスの一覧を見てみる。
すると………
03:00.0 RAID bus controller: 3ware Inc 9750 SAS2/SATA-II RAID PCIe (rev 03)
きた、きた、きたぁ～っ！！
PCI パススルーの設定をした 3ware SAS 9750-8i がゲスト OS からしっかりと認識されていた。
続いて lvdisplay で論理ボリュームの情報を見てみる。
きた、きた、きたぁ～っ！！ きたってばよぉ～っ！！
以前に Debian GNU/Linux Squeeze を直接インストールして構成した論理ボリュームがしっかりと認識されていた。
で、気をよくしてマウントしてみると、ちゃんと中が見えた。
PCI パススルーによって仮想マシンに物理ハードディスクを認識させ、物理ハードディスクに直接構成されたパーティションテーブルや論理ボリュームを認識させることに成功した。
これで仮想マシンからの書き込みは物理ハードディスクに極小のオーバヘッドによって書き込まれるし、仮想環境の障害の際にも中身のサルベージが可能になった。
取り敢えず /etc/fstab に書き込んで再起動確認………ちゃんとマウントされた。
なんかすげぇ～嬉しい(爆)
この後 NFS を構成して NFS をストレージとして VMware ESXi に認識させ、仮想ゲストを起動するまで作業しなければ今回のプランが成功したとは言えないのだけど、今夜はもう眠い。
連日 3 時過ぎまで作業していると流石に寝落ちの危険性が出てきた。
なので、おやすみぃ～………
2010年8月16日
XenServer 5.6 上での PCI パススルーに大苦戦
物は試しと言うことで、ストレージサーバに XenServer 5.6 を導入し、PCI パススルーに挑戦してみた。
XenServer 5.6 の導入は至極順当に完了した。
SATA に接続されている SSD を sda と順当に認識して、問題なくインストールは完了。
例によって 3ware SAS 9750-8i は認識しないが、ココまで来たら慣れっこだ。
で、SSD の残り領域に Debian GNU/Linux Squeeze をインストールして、早速 PCI パススルーに挑戦してみる。
PCI パススルーは Xen 3.2 から対応しているようだが、XenServer 5.6 は Xen 3.4 ベースなので対応は出来ると思う。
ただ、Xen での PCI パススルーの情報はボチボチ見付かっても、XenServer での PCI パススルーの情報はほとんど無い。
Citrix のフォーラムで英語の方に若干のやりとりがある程度だ。
それら断片的な情報をつなぎ合わせて、手順を構築してみた。
まず lspci コマンドで 3ware SAS 9750-8i を識別する BDF を取得する。
すると「01:00.0 RAID bus controller: 3ware Inc 9750 SAS2/SATA-II RAID PCIe (rev 03)」という項目が見付かるので、ここで BDF は 01:00.0 と取得できる。
更に /etc/rc.local に以下を記述して、dom0 から 3ware SAS 9750-8i を切り離す。
BDF=0000:01:00.0
modprobe pciback
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
ここで dom0 を再起動して、dmesg | grep pciback で起動ログを調べてみると、BDF 0000:01:00.0 が切り離されているっぽい。
lspci コマンドが吐き出すリストからは消えないのだろうか？ とか思ってみるが、消えるのが正しいのか、消えないのが正しいのか、確証無し。
さらに仮想マシンに PCI デバイスを割り当てる設定を行う。
まず xe vm-list で仮想マシンの UUID を調査する。
で、取得した UUID と BDF を元にして、以下の様にしてパラメータを設定してやる。
xe vm-param-set uuid=<UUID> other-config:pci=0/0000:01:00.0
で、以下の様に打ってパラメータを確認すると、確かに「pci: 0000:01:00.0」が追加されているのが見て取れた。
xe vm-param-list uuid=<UUID> | grep other-config
これで手筈は整ったかな？ ということで、レッツ、仮想マシン、起動っ！！
ハングアップ(爆)
lspci コマンドを叩かせても貰えず、仮想マシンはホストごとハングアップした。
最初、間抜けにも BDF を 03:00.0 と間違えてホストごとハングアップしたのだけど、その時は単純にハードウェアを探しに行って逝ってしまった様だった。
しかし BDF を正しく 01:00.0 と修正してやると、デバイス自体は見付かったがちょっかいかけようとして逝ってしまった様に見える。
同じハングアップでも、両者でタイミングが明確に違うのだ。
これは例えば dom0 から実は切り離されていなかったなど根本的に手続きが足りないのか、手順はあっていて 3ware SAS 9750-8i が PCI パススルー動作できない仕様なのか、切り分けが難しい。
手順に自分なりの明確な根拠がないから判断基準がない。
これは困ったぞ………(汗々)
ああ、あと微妙な思い付き。
これも先日の日記へのコメントでヒントを貰ったのだけど、VMware vSphere も 4.0 から VMDirectPath という名前で PCI パススルーに対応しているらしい。
ただ、VMDirectPath は感触的にはネットワークデバイスの直結を念頭にしているらしく、3ware SAS 9750-8i を直結できるか否かは微妙だ。
さて、仮に VMDirectPath が利用できるとして、どのような組み合わせが出来るだろうか？
まずストレージサーバの SSD には VMware vSphere Hypervisor を載せる。
VMware vSphere Hypervisor だけでは当然 SSD は駄々余りなので、最初のストレージを構築する。
最初のストレージに格納される仮想マシンはストレージサーバを構築する Debian GNU/Lunux Squeeze だ。
仮想マシンへ VMDirectPath で与える I/O デバイスは何にするか？
当然、3ware SAS 9750-8i は与える必要があるし、これは直接認識しなければ 3DM2 で管理も出来ない。
あとは 4 系統ある eth のうち、2 系統を VMDirectPath で与えてしまおうか？
そうすると eth×2 のボンディングを構成できるので、外部の仮想ホストへのストレージ提供の帯域を確保できる。
ストレージサーバ内部の仮想ホストへのストレージは仮想 NIC 同士が仮想スイッチを介して直接やりとりすれば良いかな？
仮想スイッチと繋がるだけの内部ネットワークだと物理 NIC と繋げる必要もないだろう。
で、万が一ここまで上手く行ってしまったとしたら、XenServer の時と同様に鶏と卵のような関係になるストレージサーバ内部のストレージを VMware vSphere Hypervisor がちゃんと使えるか？ という部分が問題になる。
VMware vSphere Hypervisor が起動した段階ではまだ最初の仮想マシンは上がっていないので、当然最初の仮想マシンが提供するネットワークストレージは存在しない。
最初の仮想マシンを起動してネットワークストレージが有効になってから、後続の仮想マシンを起動できるように遅延起動を設定したりも必要だし、そもそも VMware vSphere Hypervisor 起動時では認識不能なネットワークストレージを自動的に切り離したりしはしないか？ という疑問も解消せねばならない。
XenServer での PCI パススルーが成功すれば全ての仮想マシンを XenCenter で管理できる利便性を得られるのだけど、ストレージサーバのみが VMware vSphere Client で、その他の仮想ホストの管理は XenCenter と使い分けるのも致し方ないかな？
う～ん、疲れてきた………(汗々)
2010年8月15日
VMware Server 2.0 の不安定現象に関する考察
Debian GNU/Linux Squeeze に無理矢理入れた VMware Server 2.0 がカーネルも変えていないのに原因不明の vmware-config.pl の再実行を要求してくる現象に関して。
どうも色々とからかってみると、仮想マシンを起動してから停止した後に、vmnet カーネルモジュールが正常にリムーブできていないことが問題のような気がしてきた。
VMware Server 2.0 はカーネルモジュールとして vmnet、vmci、vmmon、vsock の４つをロードする仕様のようだ。
で、OS 起動後に仮想マシンを一度も起動していない場合、
/etc/init.d/vmware stop
でデーモンを停止させるとこれらは正常にリムーブされる。
しかし仮想マシンを一度でも起動／停止してから同様にデーモンを停止させようとすると、Virtual ethernet サービスの停止に失敗し、vmnet カーネルモジュールのみ参照数 1 で残留する。
このまま今度は、
/etc/init.d/vmware start
でデーモンを起動すると、vmnet カーネルモジュールの参照数は残留した参照数と合わせて最初の 13 から 14 に増えてしまう。
ここで更にデーモンを停止させると、Virtual ethernet サービスに加えて今度は自動実行の仮想マシンを制御するらしい Virtual machines と VMware Server Host Agent の停止に失敗する。
ps でプロセスを見てみると、vmware-watchdog と webAccess が順当に残っている。
この状態で更にデーモンを起動しようとすると、vmware-config.pl の再実行を要求してくる様だ。
ここから推論するに、vmnet カーネルモジュールを中心に問題が起こっているっぽい。
ここで vmware-config.pl を実行してもサービスが停止できないために怒られる。
仕方ないので、vmware-watchdog と webAccess を順番に殺し、vmnet カーネルモジュールを強制的にリムーブする。
ここで vmnet カーネルモジュールには参照数があるので rmmod に -f オプションを付けないとリムーブできないことに注意。
再度 vmware-config.pl を実行するとカーネルモジュールがビルドされて、目出度く VMware Server 2.0 が再起動する。
ここで仮想マシンを起動せずにデーモンの上げ下げを繰り返しても現象は出ない。
やはり vmnet カーネルモジュールが正常にリムーブできないのが問題のようだ。
なるほど、これならストレージ容量の再認識のためだけに VMware Server 2.0 を再起動してしまって問題が起こった現象に一致する。
vmnet カーネルモジュールが正常にリムーブされない現象は自分の拙い Linux 知識では調査しきれないけど、少なくとも確実に現象を出せる様になった。
つまり確実に現象が出せる事象を回避すればよいわけだが………実運用に入ったら仮想マシンの上げ下げならまだしも、VMware Server 2.0 の上げ下げなんか連発しないなぁ～(汗々)
実は問題ないのかもしれん………(汗々)
あと、Windows XP Mode 上の Internet Explorer 6.0 から VMware Virtual Infrastructure Web Access を利用すると悲しいほどにトラブル無しで利用できることが判明した。
先日の日記へのコメントに面白い提案があった。
こちらの記事であるが、Xen だと PCI パススルーが使えるので、ストレージコントローラ（記事では SATA コントローラ）を PCI パススルーで特定の domU に割り当ててしまう方法だ。
そもそもの問題を考えてみる。
- 今回の仮想化の中で、開発環境も仮想化したい
- 開発環境はディスク I/O が重いので SAN では帯域不足で効率が悪い
- 結果として開発環境の仮想マシンはストレージサーバと同居する
- ストレージサーバ自体を仮想ホストとすると、ストレージ管理は仮想ホストに依存し、外部の仮想ホストへの iSCSI や NFS のエクスポート、CIFS のファイルサーバ機能などは仮想マシンが担うことになる
- ストレージサーバのハードウェアに障害があった場合、CIFS で公開されていたファイル群は仮想化されたハードディスクイメージの中となるのでサルベージするまでがとても遠い
- XenServer の dom0 をファイルサーバとして利用する手もあるが、XenServer のバージョンアップの度にファイルサーバを構築し治すのはナンセンス極まる
ここで XenServer の PCI パススルーを利用する事を前提に考えると、こうなる。
- ストレージサーバにまず XenServer をインストール
- XenServer で 3ware SAS 9750-8i は PCI パススルーし、domU に割り当てる
- domU では 3ware SAS 9750-8i に繋がっているアレイに Debian インストールする
- domU にインストールした Debian でファイルサーバ機能を構築する
- domU の Debian から iSCSI や NFS をエクスポートし、その他の domU のストレージを格納する
- その他の domU に構築された仮想マシンのストレージは、iSCSI や NFS だとしても同一ホスト上のネットワークであり、多分帯域が充分に稼げる
dom0 が認識するネットワークストレージを dom0 が管理する domU がエクスポートしているという鶏と卵みたいな関係になってしまうが、これは全ての問題を満足する手法かもしれない。
ストレージサーバのハードウェアに障害があった場合でも、ハードディスクが PCI パススルーで直接的に制御されているのであれば別のマシンにつなぎ替えて中身を取り出すのもそう難しい話ではないだろうし、場合によっては XenServer の層を無くしてしまって domU を物理サーバとして直接起動するなんてことも出来るかもしれない。
しかも全ての開発環境、外向けサーバ群が XenCenter で一括管理できる。
問題は SAN に繋がるネットワークが domU から見ると通常のネットワークで、dom0 から見るとストレージネットワークにして通常のネットワークというところか。
こちらの記事で実際に構築できているので可能なのかと思うが、通常のネットワークとストレージネットワークが同一というのは、DMZ に置くような外向きの仮想ホストではセキュリティ的に危なっかしくて使えないな手段だね(汗々)
（仮想マシンが乗っ取られたらストレージネットワークが丸見え）
内側にあるストレージサーバだからこそ出来る荒技か。
あとはファイルサーバとして構築された domU は、仮想マシンにもかかわらずハードウェアと密結合になるので移動できないという問題が発生するが、もともとストレージサーバは物理環境として構築しようとしていたわけだから、これを問題と認識する必要はない。
ただ、ざっと見渡したところ、XenServer の 5.5 日本語マニュアル、5.6 英語マニュアルに PCI パススルーの記述は見当たらない。
試してみるとすれば、もとになった Xen の情報を調査するしかあるまいな………
2010年8月13日
VMware Infrastructure Client 2.5 だと仮想ハードウェアのバージョンが下がる？
なんか先日起こった地域 IP 網設備故障は、割と方々でニュースになっていたらしい。
- 神奈川の一部地域でNTT東日本の加入電話やフレッツ回線が利用できない状態に
- [続報]NTT東日本の回線トラブル、おおむね回復へ
- 横浜市で電話・ネット不通、８時間後に復旧
- 不通の電話７万４６００回線復旧 横浜市内のＮＴＴ
NTT 東日本故障受付担当に電話が通じて収容ビルの電源設備故障だと聞いた時に「これは大事になるな」と直感したけど、たしかに大事になった模様。
自分、事象を認識してから問題を切り分けて光回線側に問題があると結論し、原因に辿り着くまで約１時間だったけど。
辿り着けなかった人は半日はタップリ混乱したってコトだよな。
う～ん、情報インフラってホント、クリティカルだよなぁ～
EMOBILE とは言え代替手段を確保しておいてホントに良かったよ。
実は NTT の回線でここまで非道いのはそうそう起こらないから貴重な体験だったかもしれん(爆)
昨日、Windows XP Mode にて VMware Infrastructure Client 2.5 が無事に動いたことで VMware Server 2.0 運用のクライアント側の問題は解決できたと思っていたのだけど、どうやらそう単純な話ではないようだ。
VMware Virtual Infrastructure Web Access から仮想マシンを作った場合、仮想ハードウェアのバージョンが 7 になるが、VMware Infrastructure Client 2.5 から作った場合には 4 になるらしい。
VMware Infrastructure Client 2.5 からバージョン 7 の仮想ハードウェアは起動や停止は出来ても編集が出来ないようだ。
ま～バージョン 4 とバージョン 7 の間に如何ほどの差があるのか不明だけど。
仮想ハードウェアのバージョンが接続するクライアントに依存するってのも美しくない実装だとは思うのだけど。
あと仮想ハードディスクを構築する際、イメージファイルのファイル名を指定できるのは VMware Virtual Infrastructure Web Access だけで、VMware Infrastructure Client 2.5 の方は仮想マシン名からの固定設定となってしまう。
さらに VMware Infrastructure Client 2.5 も時々（ただし、それなりの頻度で）サーバ側から切断されてしまう。
（もしかしたら、もう Windows XP Mode 上の Internet Explorer 6.0 から VMware Virtual Infrastructure Web Access を利用するというのが取り得る手段の中で最もベターなのかもしれない）
vmware-config.pl の再実行もまたワケ分からんタイミングで要求された。
今度はソースコードの位置は変えずに、ただストレージ内で利用しなくなった仮想ディスクを直接消してもストレージ残容量の認識が変わらないので再起動しようとしたらコケて、vmware-config.pl の再実行を要求された。
というかストレージの残容量くらい都度認識しても良さそうな物を、何わざわざ内部管理しているのか？
（よくよく見たら "Refresh Datastore" というコマンドがあった）
Windows 版はそれほどでもなかったけど、Linux 版の VMware Server 2.0 って、まさに腫れ物に触るような感触だよな。
中身を知らない素人かつ個人的な感想としては、この辺りの問題は Linux カーネルの根本的な設計問題にも一因があるんじゃないかという気もする。
なんにしろ、正直とてもじゃないが実運用には使いたくないレベルだ。
で、実は問題もある。
VMware Server 2.0 は開発環境で使う程度で、常時起動の実運用環境で利用するつもりはない。
だから VMware Server 2.0 が少々へそ曲がりでも困ることはない。
ただ、VMware Server 2.0 がストレージサーバを巻き込んで落ちたりした日には、実運用している仮想マシン群を道連れにしてしまう。
この辺りの危険性に関してもある程度考えてやらないとなるまい。
しかし、いい加減そろそろ仮想ホストの方の環境構築もおっぱじめないと、ストレージサーバの VMware Server 2.0 だけで足踏みが長すぎる。
ハードウェア的な取り敢えずの起動は確認したとは言え、その後の耐久的な動作確認もせにゃならんし、変にハード障害とかあったらどないしよ………(汗々)
VMware vSphere Hypervisor で行くか XenServer で行くかの結論も出していないしな(爆)
2010年8月12日
VMware Infrastructure Client 2.5 は Windows XP Mode で快適に
本日、ちょっとした用事で秋葉原に出向いた後、帰宅してまたストレージサーバにインストールした VMware Server 2.0 を弄ってみた。
目的は Windows Server 2003 R2 Standard Edition と同 Enterprise Edition のテンプレートを構築すること。
だったのだが………
VMware Server 2.0 が起動しなくなっていた(汗々)
別にカーネル変えていないのに、唐突に vmware-config.pl でカーネルモジュールを作り直せと仰る。
ワケ分からん。
展開したソースコードの場所を移したりはしたけど、それ以外は何もしていない。
なのにこれは如何な物か？
取り敢えず vmware-config.pl の再実行で復旧したけど、原因も分からずに vmware-config.pl の実行を要求されたのが実に解せん。
VMware Virtual Infrastructure Web Access も時々おかしな動作をする。
ただ、問題が仮想環境なのか VMware Virtual Infrastructure Web Access のサーバなのか、クライアントなのか判別が付かない。
そもそも Internet Explorer 8 なのがいけないのかもしれないが、VMware Infrastructure Client 2.5 のリモートコンソールが利用できない現状、VMware Virtual Infrastructure Web Access 以外に手はない。
そもそもストレージサーバに VMware Server 2.0 を放り込んだのは、自分なりの変な要件があってのことだ。
予算的な問題から帯域の大きい SAN が組めない現状、ディスク I/O が大量に発生する仮想ゲストやデータベースは物理的にストレージが直結されている環境で動かす以外にない。
またストレージサーバには単純な CIFS によるファイルサーバ機能を持たせたかった。
XenServer ならば Domain-0 で管理ツールの類が使えるから管理上もなんとかなるという見方もあるが、XenServer の LVM の管理は外部から手を出すと色々と面倒な部分があるようで、長ったらしい UUID の LV 名やら VG 名やらを許容しなければならず、しかもその中身が VDI だとすれば 何か障害あった際のデータのサルベージが遠すぎる。
では Domain-0 で色々やれば良いかというと、XenServer のバージョンアップ時に揮発する環境で細かい設定は繰り返したくない。
結果、ストレージサーバは物理環境でその他の要件を満たし、かつホストベースのハイパーバイザで仮想環境を構築する必要があった。
そうすると選択肢は限られてしまう。
ホストベースのハイパーバイザなら、その他には今も活発に開発されている VirtualBox がある。
しかしどうもこれ、お試し記事ばかりで実運用のノウハウが見えない。
VirtualBox を紹介している記事はまるで当然のように X で GUI を起動して設定している。
これは暗に VirtualBox をインストールした環境に X がインストールされているか、X サーバが存在する状態を想定しているということだ。
自分、サーバ用途で利用する Linux に X 入れる趣味はないし、そもそも Linux で GUI を使う習慣はない。
もちろん PC X サーバも導入していない。
そうなると VirtualBox は管理できない、ということになる。
VRDP で接続ったって、それは仮想マシン作って起動した後の話でしょ？
VirtualBox は VMware Server の位置付けではなく、VMware Player の位置付けと解釈した方がよいってことなのだろう。
そうすると、結局 VMware Server 2.0 に戻らざるを得なくなる。
なんとしても VMware Server 2.0 には動いてもらわないと困るのである。
CentOS なら最新の 5.5 でも 2.6.18 ベース固定なので安定するかもしれんなぁ～
今度はカーネルが古いせいで色々とドライバが足りなくなってしまうかもしれんけど、少なくとも 3ware SAS 9750-8i のドライバは RHEL 5.4 用はあるようだからなんとかなるかもしれん。
ただ、Red Hat Linux 7.3 から Debian GNU/Linux Sarge に乗り換えた時に、あまりにもあまりの便利さに愕然として Debian GNU/Linux に慣れすぎてしまったというのもある(笑)
それ以来ずっと Debian GNU/Linux だったから、CentOS がエライ面倒くさく感じるようになってしまって………(汗々)
と、取り留めもない文句はここまでにして。
積極的に VMware Server 2.0 を運用状態に推移させるため、まずはクライアント側の問題の解決に乗り出す。
最新の VMware Infrastructure Client は VMware Server 2.0 には対応せず、VMware Infrastructure Client 2.5 の導入が必要。
しかし VMware Infrastructure Client 2.5 ではリモートコンソールが真っ白けっけになってしまって使い物にならない。
この原因は現在のところ分かっていない。
ま～現在 Windows 7 Ultimate のしかも 64bit 版だから、動かなかったとしても不思議はないが。
VMware Virtual Infrastructure Web Access は最新の Firefox ではログイン画面すら出ない。
最新の Chrome ではログイン画面は出せるけどリモートコンソールプラグインがインストールできず、しかも不定期に VMware Virtual Infrastructure Web Access がエラーを吐く。
Internet Explorer 8 では信頼サイトに登録することで一通りの作業は出来る様になるが、やはり不定期に VMware Virtual Infrastructure Web Access がエラーを吐く。
では最後の手段はどうするか？
VMware Infrastructure Client 2.5 は VMware Player 3.0 上にインストールした Windows XP Professional では動作した。
しかし VMware Player 3.0 上にインストールした Windows XP Professional にインストールされた VMware Infrastructure Client 2.5 では、文字通り VMware Player 3.0 を起動し、Windows XP Professional を起動し、VMware Infrastructure Client 2.5 を起動するという面倒くさい手続きを踏まねばならない。
よし、ならば Windows XP Mode ならばどうだ！？
ま～こんな日記を読んでくれている人ならば説明するのも釈迦に説法だろうが、Windows XP Mode は Windows 7 で利用できる互換性維持の最終手段で、Windows Virtual PC 上にインストールされた Windows XP Professional を透過的に利用する機能である。
VMware Player 3.0 は確かに Windows XP Mode よりもパフォーマンス面で優れているが、Windows XP Mode の特徴は、Windows XP Mode 上にインストールされたアプリケーションをスタートメニューから呼び出すことが出来て、しかも自動的に Windows Virtual PC 上の Windows XP Professional が起動して透過的に利用する事が出来る優れた操作感覚にある。
（ぅわ、俺が Microsoft 誉めてるよっ！？）
で、早速 Windows XP Mode を導入。
Windows XP Mode は初めての導入だが、そう難しいことはない。
こちらの記事を参考にすれば切ないほどに簡単だ。
Windows XP Mode の導入を行って環境をちょこちょこと調整して、いよいよ VMware Infrastructure Client 2.5 を導入すると………
動いた、すこぶる調子がよい。
これなら VMware Virtual Infrastructure Web Access いらん。
透過的に起動する Windows Virtual PC 上の Windows XP Professional も、待てないほどの時間ではない。
（SSD の I/O 性能に Core i7-980X のパワーも寄与しているとは思うが）
何よりもスタートメニューからワンクリックで自動起動するから楽なモンだ。
ショートカットをデスクトップにコピーすればダブルクリック一発である。
いや、なにげにこれは良くできてる。
（ぅわ、俺が Microsoft 誉めてるよっ！？ ←珍しいことなので二度言いました）
と言うことで、VMware Infrastructure Client 2.5 は Windows XP Mode で快適に利用する事が吉となった。
しかも、どう考えても Windows 7 上に直接インストールした時よりもパフォーマンス良いし。
これならクライアント側の問題は解決だ。
次はサーバ側の問題を追及したいところだけど、カーネル変えずに vmware-config.pl の再実行を要求されたという事象をどうやって再現させるか………？
また悪魔の証明が待っているような気がする………
2010年8月11日
地域 IP 網設備故障、というか収容ビルの電源設備故障
昨日、恵比寿の呑み収めということで、行きつけの店でしこたま呑んで、東急東横線の人身事故で帰れなくなって、仕方なくタクシーで帰宅して、昼過ぎまで寝て、カップラーメン喰って、ネットワークに繋いだら、繋がらなかった。
真っ先に自作ルータの故障を疑った………問題なし。
ONU の故障を疑った………たぶん問題なし。
しかし PPPoE の認証がタイムアウトする。
ノートを開いてフレッツ接続ツールを EMOBILE 経由でダウンロードしてみると、これが電波状態がイマイチで遅い遅い。
その間にも PPPoE の接続やら試していると、唐突に繋がった。
ワケ分からないので、NTT 東日本の故障状況を確認しに行ったら、ドンピシャだった。
う～ん、自作ルータは PPPoE が切断されると自動再接続に行くようになっているから、場合によっては気付かなかったかもしれんなぁ～………(汗々)
と思ったら、また切れた。
今度はなかなか回復しない。
NTT 東日本故障受付担当のダイアルは混み合っていて全然繋がらない。
故障状況は「平成22年8月11日（水）12:56～」のまま更新されない。
回復にはまだまだ時間がかかるらしい。
あ、NTT 東日本故障受付担当に繋がった………て、通信設備故障ではなくて収容ビルの電源設備故障ですかっ！？
おひおひ、トラブルの規模がでかくなってるよ、マジでっ！？
通信設備故障なら余程のことがない限り復旧見込みは立てられようが、収容ビルの電源設備故障となると自体は深刻になる。
復旧の見込みは簡単には建てられない。
NTT 東日本故障受付担当に怒鳴ったところで拉致あかないし、腰据えて待つ他あるまい。
………ふむ。
外部ネットワークが使えないってことは Debian のパッケージもリポジトリから取れないってことだし、VMware Server 2.0 上に構築した Windows Server 2003 に DBMS でもインストールして、手持ちで一番馬鹿でかいデータのインポートでもして遊んでみようか。
状況確認だけなら EMOBILE で出来るし、故障情報は携帯からでも見られる。
しかし遊ぶ手段がことごとくネットワークに依存しているよなぁ～俺。
断絶されて凄くよく分かったよ………(汗々)
今までネットワーク断絶されたのって、そもそも旅行に行っていてネットワークの必要がない時とかで、その他はほとんど毎日なんらかの形でネットワークに繋がっていたからなぁ～
ネットワークトラブルでへろへろしていたら、RAD Studio の新版、RAD Studio XE の情報が舞い込んできた。
９月初旬の発売らしい。
詳しい新規機能はおいおい調べるとして、Subversion クライアントがゃっと統合されるらしい。
もともと Tools API にはバージョン管理機能との連動があったようだから遅すぎる対応かと思うけど、ま～これでやっと開発環境から標準で Subversion リポジトリと連動できるようになるわけだ。
同一製品の旧バージョンが利用可能と言うところも、実は地味に嬉しい。
と言うのも、実は仕事で Delphi 7 で作ったプログラムが現役なのである。
安定稼働しているから弄る必要はないとは言え、いざ弄る場合には古い Delphi 7 を引っ張り出さないとならない。
「同一製品の旧バージョンが利用可能」というのがどのような形式になるのか分からないが、地味に意味がある対応だと思う。
あ～、年間サポート支払い、来てたっけなぁ～
払い込まなきゃだなぁ～………
2010年8月9日
VMware Server 2.0 耐久試験
11 時間耐久会議（途中昼飯 40 分含む）を終えてヘトヘトになって帰ってきて、今度はストレージサーバにインストールした VMware Server 2.0 の耐久試験をおっぱじめてみた。
昨晩、VMware Server 2.0 のリモートコンソールをシャットダウンするのとほぼ同時に VMware Server 2.0 自体がスッこけた様に見えた現象が再現するか否か、悪魔の証明に果敢に挑んでいる。
本当にそれらに因果関係があるのか、確証を得たい。
因果関係があれば対応策を考えなければならないし、どうしても解決できないなら VirtualBox などのホスト OS 型のハイパーバイザへの乗り換えも考えなければならない。
（さもなければプライベート用の仮想ホストを考えるか）
ドコまで確認すれば因果関係が無いと判断できるのかが不明なので、悪魔の証明なのである。
で、取り敢えずディスク I/O を発生させるためにも、Windows Server 2003 Standerd Edition のインストールを敢行。
ちなみに仮想 CPU は無固定で 2 個割り当て、メモリは 1024MB 設定した。
仮想ディスクは取り敢えず 32GB 単発だ。
ストレージサーバ自体のパフォーマンスを top コマンドで確認しつつ、ディスクアレイの健康状態を 3DM2 で確認しつつ、VMware Server 2.0 のパフォーマンス状態を VMware Infrastructure Client で確認しつつ、リモートコンソールは VMware Infrastructure Web Access のプラグインを利用して作業。
Windows Update に接続してパッチをドガドガ落としてきたり、VMware Tools をインストールするトコロまでこなしてみた。
top コマンドによる CPU 使用率はユーザプロセスで平均 2% 未満、時々システムプロセスが上がるけど、ほとんどアイドル状態。
ディスクアレイも問題なし。
VMware Infrastructure Client のパフォーマンスモニタの見方はイマイチ分からないけど、ヤバゲな感じはない。
なんちゅ～か、すこぶる快適。
昨日の摩訶不思議なトラブルが嘘のようだ。
やはりディスクアレイがデグレした瞬間に問題が起こったということなのだろうか？
取り敢えず一晩走らせて様子を見ようか………？
2010年8月8日
ストレージサーバ構築開始
なんか先週はバタバタと忙しかった。
計画やらなにやら、課長だ部長だ専務だと呼び出され、当日の急ぎの作業を中断して打合せに出てみれば最後には「食事行くか、今夜はもう仕事なんかする気ないやろ」と有難いお言葉を頂いてしまったり(笑)
と言うわけで、金曜日の夜は強固な意志で帰宅して根性据えてストレージサーバと仮想ホストを本組みし、土曜日は昼過ぎまでタップリと惰眠をむさぼり（というか起きられなかった）、OS のインストールをおっぱじめてみた。
まずはストレージサーバ構築に着手。
3ware SAS 9750-8i で大苦戦
意気揚々と Debian GNU/Linux (Lenny) をインストールしたのだが、3ware SAS 9750-8i でトラブル発生。
アレイを認識しない。
考えてみれば Debian にとっては極端に新しいハードウェアのひとつだよな、油断した(汗々)
で、ちょっと調べてみると 3ware SAS 9750-8i のドライバダウンロードページからのナレッジベース 14546 に情報があった。
9750 シリーズがネイティブに対応されたのは Linux カーネル 2.6.33 以降とのことで、今回インストールを実行している Debian GNU/Linux (Lenny) のカーネルは 2.6.26 ベース。
ドライバは自分で入れなければならない様だ。
（ちなみに先日フリーズされたばかりの Squeeze も 2.6.32 ベースなのでネイティブには対応していないとかいう罠が）
取り敢えず「Debian 5.3 (aka 5.0.3) Lenny kernel 2.6.26-2-682 / 2.6.26-2-amd64」を選択して Go! で飛び、ドライバを取ってくる………
と思ったら、3ware SAS 9750-8i を認識するようにドライバをアップグレードした Debian インストーラの ISO が転がっていた(爆)
ドライバを取ってきてコンパイルするか、出来合の適応済みインストーラを利用するか、しばらく悩んだ挙げ句、出来合の適応済みインストーラに逃げる(爆)
………しかしやはりトラブル発生。
どうも、この Debian インストーラ、インストール時点で 3ware SAS 9750-8i は認識するけど、インストール後に起動すると認識しなくなってしまうらしい(爆)
インストール時点では見えていた sdb やら sdc やらが見えなくなってしまった(涙)
全く意味ないし。
何のための適応済みインストーラか？？(汗々)
結局カーネルと戯れねばならないかと四苦八苦かつ七転八倒。
取っかかりまでは来ていると思うのだけど、自分、Linux は使うばかりでカーネルコンパイルはおろか、デバイスドライバすらコンパイルしたことがない。
ホント、こういう所は Windows って楽で良いよな～
夜が明けて解決しないところで、挫折。
クローズされたばかりの次期 Debian GNU/Linux (Squeeze) に特攻(爆)
インストールを敢行してみると、2.6.32 ベースの Squeeze でも 3ware SAS 9750-8i は認識した。
2.6.33 からバックポートされているらしい。
半年以上遅れたとは言え Squeeze はもう testing ではなく stable に向けての作業に入っている段階だから、ある程度は安定していると考えて良いだろう。
この際だからもうすぐ終わる Lenny ではなく Squeeze でいこうか。
3DM2 でも大苦戦
3ware SAS 9750-8i を認識したのに気をよくして、LVM でヘコヘコとしばらく遊んでみる。
146GB×4 の SAS RAID-10 は fdisk てせも良いけど、2.0TB×4 の SATA RAID-10 は 2.0TB 超なので GPT でないとダメだから、GPT 対応版の fdisk であるところの gdisk パッケージが必要になるとか、色々と素人丸出しな遊び方。
で、いつまでも遊んでいても仕方ないので、3DM2 (3ware Disk Manager Version2) を入れてみる。
ナレッジベース 15778 によると http://jonas.genannt.name/ にあるとのことなので行ってみると、無造作にそのまま置いてある(笑)
最新版を取ってきて、dpkg でインストールしてみた。
インストールされると作成される /etc/3dm2/3dm2.conf を開いて RemoteAccess パラメータを 0 から 1 に変更するとリモートからの HTTPS 接続を受け付けるようになる。
で、https://(ServerName or IP):888/ で接続すると、使いやすいと定評のある 3DM2 の画面が現れた。
で、ここでもやはりヘコヘコとしばらく遊んでみる。
ん～、たしかにコレは使いやすいかもしれん、というか良くできてる、使いやすい。
取り敢えずアラームメールの送信テストをしてみようか。
"3DM 2 Settings" を開いて "E-mail notification" を設定、"Send Test Message" を実行してみる。
………飛んでこない………ってか、3DM2 がハングアップしてないか！？
わざわざメールサーバの設定を持っているんだからローカルの sendmail には依存しないと思うし、メールサーバに接続した痕跡もないし？
おぉ～いぃ～、一番重要な機能が動かないってどういう了見だよぉ～(涙)
んで、なかなか原因が分からないので http://jonas.genannt.name/ からではなく、LSI のダウンロードページにある「3DM2 & CLI Linux 10.2 code set」を試してみた。
こちらでもメール送信するとハングアップする現象は変わらないが、以下のメッセージがコンソールに吐き出された。
3dm2: relocation error: /lib/libnss_files.so.2: symbol __rawmemchr, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
ちょ、おま、glibc 2.2.5 って、古くないけ？
glibc はカーネルを始め多くのドライバ、アプリケーションが依存している C 標準ライブラリだが、これを変更するってことは環境の地殻変動が起こると言うことなのではないか？
流石にコレは、どう解決したらよいのか皆目見当も付かん。
（こういうことがあるから被依存度の高すぎるライブラリって嫌いだ）
むぅ～、一番欲しい情報は CLI 版の tw_cli で以下のようにすると取れるから、
tw_cli /c0 show
これを定期的に取得してメール配信する方向で逃げてしまおうか。
シェル書いてコンソール出力をフィルタしてメールで飛ばすって今もやっている方法だし………
VMware Server 2.0 はどうにかなった？ いや、まだキビシイ(涙)
続いて VMware Server 2.0.2 を入れてみる。
ストレージサーバに何故に VMware Server かと言うと、外部公開しない開発用のサーバ―――主に Windows 系―――を放り込むためである。
ストレージサーバには仮想ホスト向けの iSCSI や NFS のサーバ、単純なファイル共有、SVN などのサーバにもなってもらう予定なので、XenServer の Domain-0 の様にいつドコでバージョンアップで潰されるか分からない環境よりも、少々パフォーマンスに劣ってもホスト OS 付きのハイパーバイザの方が勝手がよい。
なので、勢い VMware Server となるわけである。
で、VMware Server でも色々と苦戦。
パッケージを取ってくるなどの定型的な処理はどうとでもなったが、色々と面倒くさい手続きを踏むことになった。
まずカーネルのヘッダファイル群が必要で、これを用意する必要がある。
GCC は Squeeze 標準の 4.4 ではなく、カーネルをコンパイルした際の 4.3 を用意する必要がある。
しかもどうやらカーネル 2.6.30 以降では正常に動かないらしく（！？）、パッチが必要と来た。
パッチはこちらの記事より入手、利用方法も書かれているので単純、手に入れたパッケージ raducotescu-vmware-server-linux-2.6.3x-kernel-f271f27.tar.gz を展開して出てくるシェル vmware-server-2.0.x-kernel-2.6.3x-install.sh を実行する。
ターゲットとなる VMware Server のパッケージは VMware-server-2.0.2-203138 系の様だ。
実行を開始するとあとはほとんどメッセージに従うだけで良い。
インストールが完了したら https://(ServerName or IP):8333/ui/ にアクセスして、動作していることを確認しよう。
（Firefox 3.6.8 だと動かなかったので IE8 で確認した）
取り敢えず動いたけど、これでカーネルの更新は事実上出来ないことになった。
カーネルの更新をしてしまうと、きっと VMware Server は動かない(汗々)
まぁ～ Debian は基本的に stable リリースのカーネルは変わらないし、大丈夫かな？
で、面倒くさいので VMware vSphere Client から操作しようと考えた。
しかし今後 VMware vSphere Hypervisor を利用する事を考えて VMware vSphere Client 4.1 をインストールして接続してみるも「必要なクライアント サポート ファイルをサーバから取得して、インストールする必要があります」とかほざいて失敗して接続できず。
VMware vSphere Client 4.0 も正体不明のエラーでダメ。
結局、VMware Infrastructure Client 2.5 まで戻る羽目に………
お話にならん！！
VMware Infrastructure Client 2.5 をインストールした状態で VMware vSphere Client 4.1 をインストールしても同居できないし、まったく話にならん。
………って、あれ？
VMware vSphere Client 4.1 をインストールした後に VMware Infrastructure Client 2.5 をインストールすると、別に 4.1 は消えていないような気がする？
インストールフォルダを眺めてみると、C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client の配下に 2.5 と 4.1 が並んでいるし、起動は別途 Launcher の下のプログラムっぽい？
これってもしかして、接続先によってクライアントが自動的に切り替わっている？
もしかして………
お話になった！？
これで良いのかもしれん………
取り敢えず VMware Server の動作確認もかねて Windows Server 2003 Standard Edition でも放り込んでみよう………
で、またトラブル。
なんかもう疲れてきたけど、なんか今度はストレージサーバ側の問題じゃないような気がしてきた。
まず VMware Infrastructure Client 2.5 から仮想マシンを起動すると、起動はしているっぽいけどリモートコンソールが真っ白けっけ。
念のため IE8 から Web Access に接続してみると、こんどはリモートコンソールプラグインが IE8 のセキュリティに引っ掛かっているっぽい(汗々)
状況が掴めないので Windows XP Pro に VMware Infrastructure Client 2.5 をインストールして確認してみると、仮想マシンはちゃんと起動しているっぽい。
"Operationg System not found" とメッセージが出ている POST 画面が出ていた。
で、試しに VMware Infrastructure Client 2.5 から仮想ゲストをリセットしてみると………
VMware Server ごと落ちました(爆)
あ、いや、なんか SATA の RAID-10 がデグレしているな？
一度に複数の問題が起こってしまったから切り分けが難しい………
取り敢えず IE8 を管理者モードで起動すると Web Access から無事にリモートコンソールプラグインは起動できたけど、スマートではない。
ストレージサーバを信頼済みサイトに登録して保護モードを無効にしてしまおう。
VMware Infrastructure Client 2.5 から真っ白になる問題は管理者モード関係なく発生するようだ。
こちらは更なる調査が必要だけど、IE8 で Web Access が利用できるのであれば、リモートコンソールプラグインを利用するのは最初のセットアップの時だけだから何とかなるかも？
あとは VMware Server ごと落ちた理由を探さねば………
………ああ、そういえば昨晩は徹夜してたんだった………ま、瞼が………
2010年8月3日
ストレージサーバ仮組み
荷物が邪魔なので、ストレージサーバを仮組みしてみた。
仮組みと言っても本当に仮組み。
ケース MVK R-77B Plus にマザーボード SUPERMICRO X8SIE-LN4 を配置して CPU Intel Xeon X3470 とメモリと電源くっつけただけ。
あ～、あとバッテリバックアップユニットくっつけた 3ware SAS 9750-8i も接続してみた。
SAS エキスパンダ CHENBRO CK13601H0C03 はケースの中に配置したけど電源も入れていないしもちろん SAS も繋いでいない。
起動用ドライブの intel X25-E も拡張スロットに 2.5 インチハードディスクや SSD を設置するパーツと共に配置しただけ。
光学ドライブもケースに入れただけの状態。
エンクロージャ SUPERMICRO CSE-M35T-1B v2.0 は２つ設置しておいたが、流石に 5 インチベイ 6 段に 3.5 インチハードディスク 10 台が入ろうという姿を見ると、
おおぉぉ～………いっつ、あ、すとれぃじさぁばぁ～………(汗々)
と無駄に感動してみる。
とにかく前面パネルが凄いことになった(笑)
もう一つ CSE-M35T-1B を買ってきて 15 台 OK 状態に解脱しようか………折角エキスパンダも仕入れていることだし(汗々)
で、取り敢えず電源を入れてみると、全く問題なく起動。
う～ん、トラブルの１つも予測していたのだけど拍子抜けした。
まぁ～原因不明で忍耐不能のトラブルで再起不能に陥るのは勘弁してほしいので、助かるっちゃ～助かるんだけどね(汗々)
ちなみにケース MVK R-77B Plus、前に 10 基ある 5 インチベイの 4 基、3 基、3 基の間に仕切り板があると書いたけど、仕切り板があるままではエンクロージャ CSE-M35T-1B を複数投入するのには無理があるようだ。
仕切り板の厚みの分だけ高さが足りなくなる。
しかしこの仕切り板は無理なく取り外すことが出来るので、事実上 5 インチベイ 10 基がフリーレイアウト状態に出来る。
これは非常に助かる拡張性だ。
多数の 5 インチベイを持っていてフリーレイアウトと言うと、他には Abee AS Enclosure 80X があるが、こちらは重量が 11.2kg と MVK R-77B Plus の倍近く重い上に 5 インチベイ自体が 9 基となるので、ちょっと値は張るが軽量かつ無類の拡張性を求めたいのであれば MVK R-77B Plus は悪くない。
………天版のトラブルさえなければ満点あげても良かったんだけど(汗々)
さて、ストレージサーバの OS は何にしようかな？
やっぱ最近使い慣れてきたし Debian GNU/Linux かな？
2010年8月2日
何も月曜日に全部揃わなくても………
本日、緊急のトラブルシュートで久しぶりにドガドガと仕事でコーディングして、美しさの欠片もないコードをガッツリと置き換えて少しだけ美しくして帰宅したら、弩デカイ箱が部屋の前に鎮座していた………
あ～、出荷連絡、来てなかった気がするんだが………？？
仕入先からの直送か？ 荷札丸めて捨てちゃったから分からん。
最後のデカ物であるストレージサーバ用ケース MVK R-77B Plus にハードディスク×４と凄い荷物になることが分かっているので、事前に出荷連絡貰わないと大変なことになる。
そういえば Able も EC-JOY も入荷した側からドカドカと別送してくれたもんだから配送業者が来るわ帰るわと凄いことになったし、こちらには今後こういう凄い発注する時は一括配送でお願いするようにしようと心に誓う(汗々)
なんにしろ、全てが揃った。
全てが揃ったのだが、なんちゅ～か、よりにもよって月曜日である。
しかも残業帰りであるからして、検品するダケで精一杯である。
しかしそのまま積んだ日にはいくらなんでも場所を取りすぎるし、地震でもきて生き埋めになった日には目も当てられん。
仕方ないので片っ端から全部引っ張り出して、緩衝材捨ててダンボールたたんで、取り敢えず自分が這い出る隙間だけは作った。
なんか装備ばっかり凄くてロクな仕事しないフリーランスのプログラマの仕事部屋の様相を呈してきた………って、一歩間違えばそのままか、俺(汗々)
後は組んでいけばケースの中にパーツ群が収まっていくから部屋にも余裕が出てこよう。
さて、本日は MVK R-77B Plus の感想だけ。
MVK R-77B Plus は E-ATX で対応したフルアルミのサーバケースで、5 インチベイが 10 基もある拡張性に優れている。
にも関わらずフルアルミのおかげもあって非常に軽く（6.4kg）、片手でもひょいっと持ち上げられる。
エッジの加工も割と良好で危ない部分はなく、開口部もしっかりしていて作業がしやすそうだ。
ただ一点、非常に愕然としたことがある。
この MVK R-77B Plus は天版に 12cm ファンを取り付けるための穴が開いていて、天版用の網まで付いているのだけど、この天版の穴を塞ぐためのオプションパーツもある。
しかしこのオプションパーツ MVK R-FC00、なんか付属のネジと雌ネジのピッチがあっていないのである。
付属のネジはよくあるケースファンなんかをくっつけるピッチの広い平木ネジなのだが、MVK R-FC00 本体側に切ってある雌ネジはどう見ても圧倒的にピッチが短い。
当然、雌ネジが切ってある部分はアルミニウムとなっており、少々の力でねじったところでネジは入らない。
PC/AT 互換機の一般的な自作ツールキットのネジではでれも径もピッチも合わないし、もうタップでも持ってきてネジを切り直してやらないとダメなのである。
他のトコロが良かっただけに、これは随分と残念な仕事である。
仕方ない、実はあまり天版にゴチャゴチャと機能が付いているのは好きではないのだけど（サーバとかは特にキーボードとかを放置しっぱなしにするので）、12cm 静音ファンでも仕入れてきてくっつけてしまうかな………
2010年8月1日
UPS のバッテリ交換
長らく放置していた UPS のバッテリ交換だが、先週に発注していた交換用バッテリが届いていたので、この土日で入れ替えてみた。
今回仕入れたのは APC の RBC6L、Smart-UPS 1000 に対応した交換用バッテリだ。
交換方法は至って簡単。
オンラインでも交換できるので、サーバを落とさず UPS からバッテリを抜き抜いて、ケーブルすっこ抜いて、交換用バッテリを全く逆の手順で取り付けて完了。
作業時間、約 10 分。
ただ、入れ替えただけではバッテリ交換 LED が消えないので、バッテリの充電がされていることを確認して早々にセルフテストを行ってしまう。
そうすると交換されたバッテリを認識してバッテリ交換 LED が消え、正常動作に戻る。
5 時間に一度のピーチクパーチク喧しいアラートも消え、平和になった。
ちなみに 5 時間に一度のピーチクパーチク喧しいアラートを放置して約 1 年。
その間にまともな停電が無くて良かった良かった(汗々)
UPS 購入は 2003 年 1 月、本格的に利用を開始したのは 2003 年 8 月からだから、まるまる 7 年間の利用。
ただし、前述の通りアラートを放置して約 1 年は経っていたはずなので、都合 6 年くらいの寿命と言うことか。
ん～、思ったより長いな。
実際 UPS のバッテリなんか 3 年間も保てば御の字だと思うんだけど、思ったより停電が少なかったのが幸いしたか。
さて、次期サーバ用のパーツも着々と揃いつつあるが、予測に反して在庫を持たずに注文確定からの手配となる Able からの荷物が本日で全部届いた。
だけど、ストレージサーバ用ケース MVK R-77B Plus を発注したショップがメモリとハードディスク、仮想ホスト用の電源を巻き込んで出荷連絡すらなく未着。
お盆休みに入る前にどうにかして欲しい物だけど………(汗々)
そういえば、数日前に日経新聞に『“マイクロソフト化”進むグーグルのジレンマ』という記事が載っていたな。
ここ数年は自分も同じ事を考えていたのだけど、日経新聞にまで書かれるようじゃかなり本格的になってきたということだな。
ま～、今回のヤフーとグーグルの検索機能の提携を受けての記事だろうけどね。
なんちゅ～か、グーグルがいつまで自分達がクールだと自己欺瞞できるか、ちょっとした見物だよな(嘲笑)
………ああ、あとアップル、お前もな(爆)
