墜落日記 - 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 で行くかの結論も出していないしな(爆)
ども、かなり迷走されていますね。。。。
仮想化でのHAやライブマイグレーションを考えるなら、
ストレージと仮想サーバは切り離したほうがいいと思いますが・・・。
同居させたい場合は、下記のサイトを参考にしてはいかがでしょうか？
http://nkjmkzk.net/?p=1055
ところで監視サーバは使っているのでしょうか？
要件の規模的に、必要なように見受けられます。
そういえば、iscsiのボンディングについて言及されていたと
思いますが、@ITに負荷分散の構成についての記事があります。
http://www.atmarkit.co.jp/fserver/articles/vsphere/03/03.html
FC-SANの構成の参考になりそうな記事もあります。
http://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxrYXNvdG9tb3xneDo2OTlkNWFhZWE5NjdiOTE3&pli=1
その辺りは私も呼んでいます。
ただ、やってみないと分からないのですが、VMwareのNICチーミングは仮想ゲスト間でNICのやりくりするだけみたいなので（結局はNICが固定される？）、単純な帯域拡張には使えないのではないかと思っています。
それに対してXenのボンディングとLinuxのボンディングならば同一技術でしょうし、単純な帯域拡張が可能なのではないかと。
ただ、対処からパケットの前後が保証されないUDPならまだしも、TCPをパケット単位でラウンドロビンすると場合によってはパケットの前後が入れ替わったりするので再送要求の頻度が上がったりして、単純にはいかないような気もしますが(汗々)
自分の認識と差異があるようなので、認識を記載します。
・自分の認識
ESX（ホスト）-iscsiサーバ
※格納データはゲストOSそのもの(VMDK）
・瑞輝智佳さんの認識？
ESX（ゲストOS)－iscsiサーバ
※格納データはゲストOSのDB？IOが激しいもの
ゲストOSにiscsiイニシエーターをつけ、vNICにVMDirectPathをつけてあげれば、
問題ないと思います。
ちとややこしいですが、ハードウェア的には、ストレージサーバ(SV)×1、仮想ホストサーバ(VH)×1の構成です。
通常の外向き仮想マシン(VM1s)は VH の中で稼働します。
従って、以下の様な基本的な構成になります。
・SV(iSCSI/NFS)－VH(VM1s on ESXi/XenServer)
で、SV にはファイルサーバ機能も持たせたいので CIFS 機能も持つため以下となり、
・SV(iSCSI/NFS, CIFS)－VH(VM1s on ESXi/XenServer)
開発環境として利用する仮想マシン(VM2s)は SV 上で直接動かしてディスクI/Oを稼ぎたいので以下となります。
・SV(iSCSI/NFS, CIFS, VM2s on VMware Server)－VH(VM1s on ESXi/XenServer)
ただココで、VM2s を担うはずだった VMware Server 2.0 が不安定なので、SV 上で VM2s を稼働させる次なる手段を模索しているわけです。
なるほど・・・・。
開示できるか、わかりませんが、実際にはどのようなIOが発生するのでしょうか？
DBファイル？ログ？
IOがどの程度発生するかなど・・・・。
今のお話だとSolarisのコンテナを利用したほうが良さそうに見えます。
ただ・・・Oracleのゴタゴタを考えると・・・かなり微妙ですし、
開発環境がSolarisでも問題ないとかの前提が必要になりそうですねぇ。。。
最初に気にしているのはDBの表領域の作成・拡張、巨大なダンプのインポートの時間ですね。
開発中はDBの参照・更新が頻発するので、遅いと開発速度に響きます。
まぁ～、のんびりやれという噂もありますが、基本的にマシンの処理速度で思考が寸断されるのは嫌いな質なので、少々我慢すればよいのにオーバスペックを要求したりします(笑)
XenのPCI-Passthroughですか、これは思い付かなかったですが、面白いですね。
ストレージサーバとしての機能はdomU上のDebianで、ハードディスクはPCI-Passthroughを利用して3ware SAS 9750-8iを丸ごと与えてしまって、domUのDebianからiSCSIやNFSをエキスポートしてその他のdomUの仮想ディスクを格納すれば、ストレージ管理自体も柔軟に、その他の開発用仮想マシンもXenで運用という方法が使えますか。
で、やろうと思えばXenをぶっこ抜いて物理サーバとして稼働させることも出来る………と(汗々)
私もそう思うのですが、時々使う開発環境はディスクI/Oが激しすぎるのでストレージサーバとの同居を選択しました。
外向けの仮想マシンはディスクI/Oも大したことないので仮想サーバに切り離します。
所詮は趣味の自宅サーバですから、監視サーバなんかは考えていません。
ルータがやはり自作のLinuxマシンでそちらは別個のハードウェアになっていますから、必要ならばそちらに監視させても良いかも知れませんし、OpenBlockS辺り導入して遊ぶのも良いかもしれませんね。
ただ監視させたところで通知手段の多重化も出来ないし、リカバリ手順など考えると、正直意味あるのかな？ と(笑)
まあ、その辺は人それぞれなので感じですね。
zabbix（ゲストOS）というOSSのシステムを使用していますが、サービスの再起動や、状況に応じての自動化などなどかなり便利です。
今、ゲストOSに負荷が高まったときに、別のゲストOSを起動するシェルを作っています。