墜落日記 - 2010年7月の墜落
2010年7月28日
サーバパーツ、続々届く
日曜日にまとめて発注したサーバパーツが、昨日と今日で続々と届いている。
方々に分散して発注したため、自宅に帰ると大小様々なダンボールが山積みになっている状態。
家族に白い目で見られる(爆)
予測の通り、注文後の手配で在庫を待たない Able Online からは出荷連絡も来ていない。
こちらは来週だろう。
その他、ハードディスクとストレージサーバ用のケースを発注したところからも出荷連絡が来ていない。
こちらケースの手配に手間取ると思われ。
なので、ケースはおろかメモリもマザーボードも届いていないので、組むに組めない。
CPU は来たのにね(笑)
さてさて、なんか SAS/SATA RAID カードであるトコロの 3ware SAS 9750-8i と、36 ポート 24 台の SAS エキスパンダ CHENBRO CK13601H0C03 を発注している矢先に、LSI 製品のラインナップに最大 28 ポートの SAS/SATA RAID カードが加わったらしい。
内部 16 ポート、外部 4 ポートの LSI MegaRAID SAS 9280-16i4e と 内部 24 ポート、外部 4 ポートの LSI MegaRAID SAS 9280-24i4e だ。
3ware ブランドにも 3ware SAS 9750-16i4e と 3ware SAS 9750-24i4e が加わったらしい。
ん～、しまったなぁ～、運が悪かったなぁ～、もう少し待てば良かった。
SAS エキスパンダ CHENBRO CK13601H0C03 は SAS/SATA 共に 3.0Gbps なので、6.0Gbps で多ポートのこれらは魅力的だよなぁ～
実売価格が如何ほどか分からないから一概に待てばよいかというと微妙だけど。
10 万円以下で販売されるのであれば、ちょっと切ないことになるなぁ～………(汗々)
で、国内サイトではまだ価格が見付からないので、海外サイトで価格を調べてみる。
ん～ 3ware SAS 9750-16i4e が $839.56、3ware SAS 9750-24i4e が $1235.95 かぁ～
アメリカドルだろうから日本円にして 73,595 円と、108,343 円かぁ～、おのれ円高(涙)
お、よくよく見たら OLIOSPEC だと 111,800 円と 163,800 円で予約受付中か。
相変わらず素速いラインナップ拡充だ。
でも OLIOSPEC って玄人的な品揃えは抜群だけど最安値ってことはないから、最安値を狙うともう少し下がるよな。
でも 10 万円と 15 万円前後かな？ ちょっと暗い一安心(爆)
2010年7月25日
サーバパーツ、まとめて発注
サーバパーツをまとめて発注した。
あ、「発注」と言えば「発注」のボイスキーで変身して戦うギャグマンガあったな。
たしか『時給戦士スマイルバン』だ。
ロリでエロなコミック誌だった筈のレモンピープルで連載されておきながら、ロリでもエロでもないギャグマンガだったのが凄いよな。
閑話休題。
サーバパーツをまとめて発注した。
色々と考えていたのだけど、下手の考え休むに似たりと言うか、案ずるより産むが易しと言うか、ま～取り敢えずそんな感じである。
仮想ホストもストレージサーバも安くなったばかりの Intel Xeon X3470 で構成。
マザーボードも Intel NIC を 4 系統持つ SUPERMICRO X8SIE-LN4 を共に選択し、メモリは取り敢えず 4.0GB×2 の 8.0GB ずつ。
ストレージサーバ側にもメモリを奢ったのはキャッシュとして利用したいというのもあるけど、外部公開しない開発用の仮想ゲストをストレージサーバ側で動かそうとしているが故。
仮想ホスト側では実際に動かして CPU やメモリの負荷状態を調査し、メモリ増量か、仮想ホスト多重化か、静観かを決める予定だ。
ま～現状の自宅サーバの処理量なら Intel Xeon X3470 で充分だと思う。
仮想ホスト側の起動ドライブには Transcend の 16GB SLC の SSD でる TS16GSSD25S-S を選択。
VMware vSphere Hypervisor なら 16GB もの広大な容量は要らないのだけど、XenServer にする場合にはこのくらいは必要になりそうなので。
（見たところ 8GB もあれば充分そうだが？）
仮想ホスト側のケースは、仮想ホストの多重化の可能性も考慮して ATX マザーボードと ATX 電源に対応しながらスリムケースという SCYTHE SARA2-BK を選択。
電源の長さが 1,400mm までに制限されてしまうが、ストレージも自分で持たないし、グラフィックスに電力持って行かれることもないので ZIPPY-400W typeR で充分だろう。
ストレージサーバ側の起動ドライブには Intel のエンタープライズ向け SLC SSD である X25-E の 32GB を突っ込んだ。
データ領域は 3ware SAS 9750-8i を核に構成。
SAS、146GB、15,000rpm ハードディスク Seagate Cheetah15K.6 ST3146356SS×4 の RAID-10 (≒282GB) と、SATA、2.0TB、7,200rpm ハードディスク Seagate Constellation ES ST32000644NS×4 の RAID-10 (≒4,0TB) を奢る。
ま、色々と紆余曲折があって Seagate Cheetah15K.6 ST3146356SS×4 が余っているのでこんな構成になった。
SAS の方は外部公開しない開発用の仮想ゲストのイメージを、SATA の方は外部公開する仮想ゲストのイメージとファイルサーバ容量に割り当て予定。
SAN の帯域の関係で SAS のストレージを公開したところで帯域に頭打ち喰らうの分かっているので(汗々)
さらに、24 台まで SAS/SATA を接続できるエキスパンダ CHENBRO CK13601H0C03 も導入。
SATA 側は CHENBRO CK13601H0C03 を経由して 3ware SAS 9750-8i にぶら下げる予定。
エキスパンダは初挑戦だ。
これで内蔵ハードディスクをうりゃうりゃと追加できる上に、外付けのハードディスクケースにも対応できる。
（いつその恩恵に与るのか全くもって不明だが）
将来的な容量増加にも備えて、ストレージサーバ側のケースは MVK R-77B Plus を選択。
フルタワーケースだがアルミ製で 6.4kg と非常に軽く、10 個もの 5 インチベイを装備しているため拡張性は抜群。
一応、5 インチベイは 4 段、3 段、3 段の構成で仕切り板があるので注意が必要だが、SUPERMICRO CSE-M35T-1B が 3 つも入った上に光学ドライブまで装備できるのだから大満足だ。
（ちみなに MVK R-77B Plus、インターネット上での情報が限られており確信が持てるだけの材料が得られなかったので MVK に直接問い合わせたら、翌日には様々な写真付きで回答をくれた）
SAN を構成するスイッチには 1.0Gbps L2 スマートスイッチ、NETGEAR GS108Tv2 を発注。
IEEE 802.11ad にも対応するが、これは念のためで、多分使うことはないだろう。
NETGEAR GS108Tv2 は IEEE 802.11ad に対応するスマートスイッチとしては現実的な価格で手に入る選択肢だ。
流石に Allied Telesis は高いわ………(汗々)
ついでに去年辺りからピーピーと喧しい APC の UPS、Smart-UPS 1000 の交換バッテリも発注。
見積は各パーツ単位で最安値近傍のショップをチョイス。
最安値ばかり追いかけて分散しすぎると振込手数料、送料などで結局同じになってしまったりするので、少々の価格差ならば集約。
基本的には今まで使ったことのあるショップが大勢を占めたが、今回から Able Online を考慮に入れた。
Able Online は SUPERMICRO などのサーバパーツの品揃えが豊富で、価格的にもとてもリーズナブルだ。
ただ、基本的に在庫を持たない方針らしいので急ぎには使えないという欠点がある。
おそらく今回の自宅サーバ構築は Able Online からの発送待ちという状況になるだろう。
で、全てが正常に片付けば 60 万円の大出費(涙)
微妙に SAS ケーブルが足りなくなってしまったとかありそうなのでもう数万円増えるかもしれず。
９月末までにエンバカデロの年間サポートサービスも更新せにゃならんし、キビシイ出費だなぁ～(涙)
最安値を調べていくとちょくちょく御目見得する PC-IDEA。
普通扱わないような変な商品があったり、妙に安かったりするのだけど、こちらは基本的に無視する方針が自分の中では決まっている。
なんだろう？ 直接喰らったことはないがなんだか危険臭がするのだ(汗々)
というか、そもそも興隆商事って代理店だろ？
小売無視して代理店が低価格で暴れ回っちゃダメだろ、普通(汗々)
2010年7月20日
グッドタイミング X3470
なんか、Intel のデスクトップ向け CPU 価格改定の中に Xeon X3470 が紛れ込んでいた。
なんと $589 から $328 と、実に 44.3% の大幅な値下げだ。
Xeon X3470 はメインストリーム向けの Nehalem である Lynnfield コアの CPU だ。
一極集中サーバからストレージサーバ＋仮想ホストの構成に変更した際に見積金額がドガッと上がってしまったので、それまで X5650×2 の構成で考えていたのを、ストレージサーバ、仮想ホスト共に X3460×1 で再見積した。
万が一 X3460 単発の仮想ホストで処理能力の限界が来てしまったら、また X3460 辺りで安く作るという発想に切り替えたのだが、この場合ハッキリ言って電気代は度外視だ。
X3470 にしなかったのは X3460⇔X3470 の性能差に対して価格差が大きすぎたためで、費用対効果が微妙だったから。
今回の価格改定で X3470 が X3460 並みの値段になってしまったので、心置きなく X3470 が選択できる。
（X3460 の方は値下げしなかったので価格差が極端に詰まった形だ）
X5600 シリーズのラインナップ拡充は 2011 年 2 月予定とのことなので、6 コア Xeon の価格が下がるのは大分先になるだろうから、予算を鑑みても X3470 が妥当な選択肢になろう。
なんか、ホントにもうドウでもよくなってきているのだけど、Apple が iPhone4 のアンテナ受信強度問題を、コトもあろうに「他の端末だってあるじゃんっ！！」と駄々をこねるような暴挙に出たらしい。
この馬鹿、クレーム問題抱えている時に最もやってはいけないコトをやらかした。
まったく、RIM もいい迷惑だ。
たしかに端末の持ち方、方向によって電波強度が変わることはある、というか、それは当たり前だ。
だから各端末とも少々の持ち方の変化でも対応できるように設計を行っている。
しかし Apple は今回単純に設計ミスを犯した。
だが、自分から言わせてもらえば、設計ミスが悪いわけではない。
そりゃ～設計ミスを出さないのは非常に重要だが、いざ出してしまった場合の事後対応は設計ミスを出さないことと同等か、それ以上に重要なのだということを忘れてやしないか？
一連の騒動を冷ややかに眺めていたが、Apple の対応は杜撰だとか稚拙だとかそんなチャチなものでは断じてなく、もっととんでもない構造的欠陥を露呈させているように思う。
Google にも言えることだが、それは Apple が自分の身の丈を把握していないということだ。
Apple は確かにクールだ。
いや言い換えよう、クールだった。
なんでクールだったのか？ それは今までずっと挑戦者だったからだ。
Apple の最初の敵は IBM という巨人だった。
その IBM は当時もうひとつのクールな挑戦者だった Microsoft によって打ち倒された。
そして Microsoft はクールではなくなった………挑戦者ではなくなったからだ。
しかし Apple は IBM に Microsoft が取って代わる中で、常にクールであり続けた。
IBM の替わりに Microsoft というクールではない新たな敵が現れたからだ。
つまり Apple は挑戦者であり続けたが為に、クールであり続けることが出来た。
それはマイノリティであり続けたが為、と言い換えても良い。
ほら思い出せ、Apple が何かやる度に銀座の Apple ストアに並んでいた連中はマイノリティそのものではなかったかっ！！(爆)
しかし Apple は iPod や iTunes などにより挑戦者から主役の座に躍り出た。
iPhone がスマートフォンの巨大勢力に育っていることを否定できる者はいないだろう。
Apple はマイノリティからマジョリティにかわり、挑戦する側から挑戦される側にかわった。
そうすると何が変わるか？
簡単なことだ。
Microsoft が挑戦者だった時代、メディアは IBM を敵役にして Microsoft をクールだと褒め称えた。
しかし Microsoft が挑戦者ではなくなったら、メディアは Microsoft の失敗を論うのに余念がない。
Apple にも同じ事が起こるのだ。
マイノリティが失敗したところで歯牙にもかけてもらえない。
挑戦者が失敗したところで「頑張ったね」と労ってもらえる。
しかしマジョリティが失敗したら「そら見たことか」とボロクソに叩かれる。
メディアはマジョリティが失敗するその時を、暗い情念でもって虎視眈々と狙っているのだ。
それが現実だ。
Apple は自分を取り巻く環境が変化してしまったことを認識していないように思う。
認識していないから今回のような問題が起こったのではないか？
Apple が自分自身の現状を認識しない限り、おそらく同じような問題は起こり続けるだろう。
あ～、昔は俺も Apple に憧れてたんだけどなぁ～
今はホント、どうでもよいわ(汗々)
2010年7月19日
XenServer の感触
XenServer を選択肢に入れてみたはいいけど XenServer 自体は使ったことがない。
XenServer の利用には Linux の知識が必要とか言われているけど、どの程度の Linux の知識が必要とされているのかも定かではない。
なので、仮想ゲスト自体は作れなかったとしても感触を確かめるために VMware Player 3.0 の中に XenServer 5.6 を放り込むという暴挙を試みた。
結論から言うと、取り敢えず動いた(笑)
ただ、仮想ゲストはまだ作っていない。
Domain-0 の Linux はインストール時に設定した root ユーザのパスワードで SSH2 にてログイン出来た。
実環境では root でいきなりログイン出来ちゃうこととか、パスワード認証だけで入れちゃうこととか、この辺りのセキュリティは色々と調整しないとまずいかな。
情報を得たかった XenServer のストレージ管理は、Strage Repository (SR) という単位で行うらしい。
Strage Repository を作成するには、NFS 上の VHD ファイルか、iSCSI か、FC が必要になる。
ローカルストレージを Strage Repository として利用したい場合、XenCenter からは追加できない模様。
Domain-0 に入ってブロックデバイスなりパーティションなりを LVM 化してマウントしないといけないようだ。
例えば、hdb 全体を Strage Repository として登録したいなら Domain-0 で以下のようにするらしい。
xe sr-create name-label="Local Strage 1" type=lvm device-config:device=/dev/hdb
パーティション単位ならこんな感じだ。
xe sr-create name-label="Local Strage 2" type=lvm device-config:device=/dev/hda3
すると即座に XenCenter 側に Strage Repository が認識され、利用できるようになる。
削除したい場合は、
xe pbd-list
で解放したい PBD の UUID を調査し、
xe pbd-unplug uuid=...
xe pbd-destroy uuid=...
さらに
xe sr-list
で削除した Strage Repository の UUID を調査し、
xe sr-forget uuid=...
で忘れさせる………らしい。
まだコマンドの詳しい内容は調査中。
自分、Linux の Logical Volume Manager (LVM) は今まで触ったことないので、ちょっとまとめる。
LVM では、物理パーティションなどをまず Physical Volume (PV) として確保する。
それら Physical Volume を論理的にひとまとめにして Volume Group (VG) を構築する。
そして Volume Group の中に Logical Volume (LV) を作成し、各ディレクトリにマウントする仕掛けになっているらしい。
これにより物理パーティションを抽象化した柔軟な領域管理が行えるようだ。
XenServer でローカルディスクを利用する場合、Strage Repository にはどうもこの Volume Group が相当するらしい。
前述の xe sr-create で構築した Strage Repository の中に仮想ディスクを作成すると、Logical Volume が増えたことが lvscan コマンドから確認できた。
Logical Volume の中身はまだ見ていない。
しかし１つ疑問が。
xe sr-create コマンドでは Physical Volume の作成から Volume Group の作成、Strage Repository への登録まで一気にやってしまった。
しかし既存の Volume Group を登録したい場合、どのようになるのだろう？
例えば XenServer 自体をクリーンインストールせざるを得ない場合などに、既存の Volume Group を Strage Repository へ登録して既に作成済みの仮想マシンを再利用できないと非常に具合が悪い。
で、調べていくと一応方法はあるらしい。
"xe help --all" でコマンド一覧を調べ、"sr-introduce" コマンドが怪しいと思ったので検索したら出てきた。
んが、なんでこんなに面倒なんだ？
VM メタデータの収集？ VMware の *.vmx ファイルみたいにゃ簡単に読み書きできないってこと？
Volume Group の認識がなんで UUID？ 名前でいいじゃん？ ローカルなんだし？
あの XenServer が勝手に付ける分かりにくい Volume Group 名を変えちゃダメってこと？
でも UUID から Volume Group が認識できるってことは Volume Group の UUID を調べる方法はあるってコトだよな？
って言うか、どうして Volume Group が直接 Strage Repository へマウントされていないわけ？
PBD ってなんぞ？ 物理ブロックデバイス？ XenServer ホストと SR 間のコネクタ？
ちなみに Volume Group 名を変えたら再起動後に Strage Repository を認識しなくなった？
UUID から Volume Group 名を機械的に生成、認識しているらしい？
またも疑問符だらけ。
様々なストレージの種類を抽象化するための仕組みだとは思うけど、勉強が足りん………(汗々)
取り敢えず日本語化されている XenServer 5.5 管理者ガイドでもって勉強しよう。
この辺りがクリアになれば、無理にストレージサーバ構成を取らなくても良くなるんだけど………
基本的な感触としては、Strage Repository に登録したらその後は Domain-0 から触れてはいけない感じ？
ちなみにこちらにも記述はあったが、XenServer の再インストール、アップグレードインストール時に仮想ゲスト用のストレージを選択する画面でストレージ選択してしまうとパーティション情報が問答無用で初期化されてしまうらしい。
なんちゅ～危ない作りをしてるんだ！？
でも障害時の復旧手段とか考えたら VMware の VMFS と違ってまだ LVM でいじれる分だけマシかなぁ～？
ん～ VMFS も Linux にマウントできるようにならないかなぁ～？
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 も選択肢に入れて吟味してみよう。
2010年7月16日
dynabook RX3 を触ってみた
最近忙しくて、打合せに打ち合わせの連続、たまに自分の席に遊びにいく状態。
ちょっと疲れてしまったので、気晴らしに横浜のヨドバシカメラを散策。
本当は秋葉原の方がヨドバシカメラ以外にも色々と気晴らしに見て回るところは多いのだけど、秋葉原は帰宅とは逆方向になってしまうので戻りが大変。
横浜なら自宅の最寄り駅を通過することはするけど、戻り時間は格段に短いので時間効率が良いのである。
んで、ブラブラと上から下まで見て回って、次期ストレージサーバで利用する予定の空き PCI スロットを利用して 2.5 インチ HDD/SSD を格納できるマウンタだけ購入。
帰ろうと思って、ふと思い至る。
そうだ、RX3 を見てみよう(爆)
dynabook RX3 でいくつか気になる点がある。
１つはキーボードの打鍵感覚で、dynabook SS RX1 を購入した最後のトリガである打鍵感覚が維持されているかを確かめたかった。
あとは 16:9 の解像度になってしまったモニタの品質だ。
ま～ノート PC のモニタに IPS だなんだと極端な品質指向はないので自分的に最低限が保たれていればよい。
で、キーボードの打鍵感覚はそんなに悪い感じではなかった。
アイソレーション設計のキーボードは正直あまり好きではないのだけど、ま～思ったほど悪くはないという感じか。
モニタは dynabook SS RX2 までの半透過型液晶よりは良いと思うけど、そんなに極端に良いわけではなさそうで、及第点って感じかな？
ただ、やはり 16:9 の解像度はダメだ、見難い。
ビジネスノートであれば文書の視認性を考えても 16:10 の方が良いと思うのだけど。
たしかにパソコンの文書は横書きが多く横幅が広いと助かるのも事実、eclipse だってソースコードの左右に色々とビューを開いて作業効率を上げている。
しかし例えば PDF や オフィス文書などは縦方向の解像度が必要だし、ソースコードだって上下方向の視認性は必要だ。
Windows 7 はタスクバーが太くなってしまったし縦方向の解像度は蔑ろに出来ないのである。
そもそもビジネスノートなのに映画でも見るような 16:9 解像度にする必然性が自分には理解できない。
なんとか 16:10 解像度に戻してくれないものか(汗々)
あとは不安要素は重さだ。
ヨドバシカメラでは盗難防止のためかバッテリが外されていたので確証はないが、dynabook SS RX1 を持ち上げた時の圧倒的な軽さではなくなってしまった。
たしかに他社の同性能ノートからすれば軽い部類には入るけど、インパクトとしては不充分かな？ という感じがする。
総合的には非常に魅力的なマシンなんだけど「ご、ごるぁっ東芝！？ てめぇ、なんてぇコトしゃあがるっ！？ コンチクショーっ！！」とか言いながらポチッとやってしまうパンチ力はまだ無いかな？
ま、今後の展開に期待ということで。
さて、そろそろストレージサーバくらいは組み始めたいと思う今日この頃。
仮想ホストとの SAN は 1.0Gbps NIC を束ねて iSCSI でいこうか。
イマイチ VMware vSphere Hypervisor (VMware ESXi) のストレージパスのラウンドロビンの情報が掴めていないが、もはや試してみる他はあるまい。
不安だからと 10Gbps NIC を入れたりした日には、その帯域を使い切るだけのサーバ集約がないと費用対効果が悪すぎるという問題もある。
前にも書いたが、10Gbps の L2 スイッチを個人宅で導入するというのは現状では非現実的なので、結果としてストレージサーバと仮想ホストの P2P となってしまう。
そのため、10Gbps NIC が 5.2 万円とすると仮想ホストを一台増やす度に 10.4 万円が NIC ダケで消えていく計算になり、さらにストレージサーバ側の PCIe バスの本数に仮想ホストの台数が制限されてしまう。
それに、そもそも 10Gbps の帯域を有効に使うというのは個人宅の自宅サーバではかなり大変なことである。
前述の通り P2P 接続になってしまうから、仮想ホスト側に 10Gbps を必要とするだけのサーバ集約が可能な性能を待たせなければ帯域に対して性能がアンバランスだ。
それにストレージサーバ側も生半可な構成では 10Gbps の帯域を使い切る前にハードディスクの処理能力で転送速度が頭打ちになるだろう。
つまり 10Gbps の帯域を使い切るだけの土壌を構築するためには、自宅サーバとしては全く無用な投資を強いられるわけだ。
ま～ NIC だけやたらオーバスペックっちゅ～のも自己満足の極みで面白いっちゃ面白いけど(汗々)
まぁ～、何というか、VMware vSphere Hypervisor がダメなら XenServer で試してみるって手もあるよな、単純に。
別に VMware である事に必然性もないわけで、むしろ Linux ベースの Domain-0 で色々と設定できる XenServer の方が柔軟にできるだろう。
VMware の End User License Agreement (EULA) に「採用された手法の審査と承認が終わるまで第三者によるパフォーマンステストはいかなるものも認めない」という項目があったり、2006 年 6 月以前はベンチマーク比較の公開を一切禁止していたりしたせいで、VMware vSphere Hypervisor と Xen の比較などが見当たらなかったりするが、XenServer が対応されている範囲を考えれば余程のことがない限り充分に実用に値するところまで来ていると思うし………
2010年7月14日
サーバ集約とストレージ集約
VMware の新版、VMware vSphere 4.1 がリリースされた。
それに伴い、従来まで VMware ESXi Single Server としてリリースされていた無償・単体のハイパーバイザーは VMware vSphere Hypervisor という名前に変更された。
（2010-07-15 現在、ダウンロードページでは ESXi 4.1 と表記されている）
ハイパーバイザーとしての機能強化は追々把握しておこう。
で、本日の本題はここから。
現在進めている自宅サーバの仮想化だが、この検討には大きく分けて２つの課題の解消がある。
まず第一にあるのは、2003 年夏から稼働して老朽化している基幹サーバのリプレースだ。
すぐに壊れる予兆があるわけではないが、保守部品が手に入りにくくなっているし、マザーボード自体が逝ったらアウトだ。
第二にあるのは、現在一極集中しているサーバ機能を分散化しメンテナンス性を高めることにある。
現在は基幹サーバの Apache HTTP Server ダケで通常の WWW も、SVN リポジトリも、ウェブメールも全てまかなっているし、メールサーバも基幹サーバに同居しているので、バージョンアップの影響範囲が大きく手間がかかる。
これを分散管理することで手間を省きたい。
第一の問題だけであれば、無理して仮想化する必要はない。
しかし第二の問題があるので、ハードウェアが分散して CPU やストレージの利用効率を下げた上に電力効率まで下げるよりは、仮想化してサーバ集約しようという発想だ。
仮想化してサーバ集約すれば今後発生しうる環境増加や、一時的に必要になるような開発環境の構築などにもプライベートクラウド的な運用が出来るようになるので一石二鳥。
今回、ここにファイルサーバの機能も集約して、本格的なストレージ集約をかけてしまおうかとも考えている。
現在ファイルサーバは I-O DATA の NAS である HDL-GT1.0 と、ATOM CPU の小型マシンに外付け RAID ボックスをぶら下げた２台構成を、Windows Server 2003 の DFS で集約している。
しかし HDL-GT1.0 を購入したのも大分前だし、RAID ボックスの方は eSATA で繋がっているだけの外付けなので障害検知が出来ない。
これらを集約し、一元化したストレージ管理の元に置けば管理性も上がるだろう。
ワークステーションに入っている開発用仮想マシンもサーバ系に関しては集約してしまって良いから、このディスクイメージもまとめてしまえる。
とか考えて必要容量を見積もってみたら、2TB じゃ心許なくなりました(爆)
当初の構想としては、RAID ボックスのハードディスクの内容を一時的に待避して、積んである 1.0TB のハードディスク×4 を新ストレージサーバに移行しようかと考えていたのだけど、そうすると RAID-10 で 2.0TB の総容量となる。
ここの元々のデータを戻し、更に HDL-GT1.0 と仮想マシンのデータを足すと、近い将来に満杯になる容量まで届いてしまった。
と言うわけで、3.0TB ないし 4.0TB が欲しい。
1.0TB×4 で RAID-5 なら 3.0TB いけるけど原則として RAID-5 は信頼していない。
そうなると 2.0TB×4 の RAID-10 で 4.0TB というのが妥当な選択肢。
で、もちろんそんなハードディスクは持っていない。
2.0TB×4 のハードディスクをストレージサーバ構築予算に追加すると………あぎゃ～っ！？
2010年7月12日
VMware の仮想化の明暗と今後の仮想化分野
VMware の仮想化を利用するようになって久しい。
最初は有償製品である VMware Workstation を利用したが、初めて仮想化を利用した時のカルチャーショックは凄まじかった。
その後 VMware Server が無償化されてこちらに移行したため VMware Workstation は使わなくなってしまった。
VMware Server をメインで利用していたが、VMware Player が 3.0 で仮想マシンの作成に対応したことと Windows 7 の導入をキッカケに VMware Player をメインに利用するようになった。
そして VMware ESXi の導入を検討している今に至る。
（VMware ESXi 4.1 が出るとすれば素晴らしいタイミングだ）
で、この VMware 製品、どうもここ最近はラインナップの明暗が明確に分かれている様だ。
もっとも注力されているのはベアメタルのハイパーバイザーである VMware ESX を核とした製品群で、これは主にデータセンターなどで運用される大規模仮想化や企業内部の小規模仮想化を含めたサーバ仮想化に主眼を置いている。
VMware ESX から管理機能などこそぎ落として小型化した VMware ESXi が無償で配布されているが VMware ESXi 単体で出来る範囲の仮想化は限られており、より大規模、高可用性も視野に入れたエンタープライズ級での様々な統合管理製品が収益源となっている。
13 日には新たに VMware vSphere 4.1 が発表されるらしいが、それと同時に VMware ESXi 4.1 も発表されるかもしれない。
対して、同じサーバ仮想化に主眼を置きながらもホストを持つハイパーバイザー製品である VMware Server は終息方向だ。
VMware Server はホスト OS で開発作業をしながら背後で開発サーバを稼働させるようなスタイルにはマッチしており、また VMware ESX で仮想ホストとストレージサーバの分割を前提としないような小規模の仮想化や、ハードウェア予算が捻出できないための緊急措置として入れる仮想化にもよくマッチする。
仮想マシンをサービス起動できるので、この辺りも後述の VMware Workstation や VMware Player とは差別化される部分だ。
インストールに要するハードウェア要件も VMware ESXi に比較すればはるかに緩やかで、非常に小回りの利くソリューションだ。
しかし VMware Server はその他の無償の仮想化製品に対抗するため無償化せざるを得なかったこともあって、VMware 社にとっても収益源として魅力的ではなくなった。
その他の製品ラインとしては VMware Player がある。
元々は仮想マシンを動かすことにのみ特化して、仮想マシンを作ることが出来なかった VMware Player であるが、3.0 から大幅に機能強化された。
以前は VMware Server や有償製品である VMware Workstation で仮想マシンを構築する必要があったのだが、高度な機能が必要なければ VMware Workstation が必要なくなってしまっている。
（この辺りは Windows 7 の XP Mode 対抗技術ということか）
VMware Workstation は VMware Player に開発者向けの高度な機能が付いた製品として位置付けられるが、実際には逆だ。
その他にも VMware View などのデスクトップ仮想化の製品ラインがいくつかある。
今後、VMware の仮想化ソリューションは整理されていくのだろうか？
おそらく、サーバ仮想化ソリューションはそうだ。
VMware Server は終息し、VMware ESX を核とした製品群に統一されるだろう。
VMware ESX もサービスコンソールを廃止すれば VMware ESXi に一本化できるし事実 VMware 社はそうしたいようなので、VMware ESXi を無償で、VMware ESXi を取り巻く管理製品群を有償でという方針になるだろう。
クライアント仮想化ソリューションはどうだろう？
VMware Player は 3.0 での機能追加により VMware Workstation の領域に大きく食い込んでしまっており、VMware Workstation の収益源としての弱体化を促している可能性がある。
しかし VMware Workstation は一貫して有償製品、VMware Workstation への R&D 投資はある程度は維持されるだろうが、VMware Workstation の収益性を維持するためにも VMware Player の機能強化はそれほど劇的ではないのではないかと考えられる。
VMware Player にも緩やかな終息が待っているのかもしれない。
仮想化分野は今後もさらに激戦区となっていくだろう。
現在は老舗の VMware が名実含めて一日の長があるが、今後は分からない。
追撃する Hyper-V、Xen、KVM も含めて、今後の動向に注視したい。
2010年7月11日
VMware ESXi の NIC チーミングは P2P でも有効か？
本日は参議院選挙の投票日。
正直、どこの誰に入れようと、どの党に入れようと、何も変わらないと思う。
きれい事言っていたって規模の小さい党じゃ独力では何も出来ないし、連立で徒党を組んだところで意志決定が遅くなるだけ。
ねじれが発生するとやはり意志決定が遅くなって緊急時と言っていい現状で全てにおいて手を拱くような事態になりかねないし、かといって民主党一党独裁にしても意志決定は早くなるだろうが、そもそもその意志が妥当かどうかなんて検証されていない。
日本相撲協会と一緒で永田町ももう生き存えているだけの化石に過ぎない。
何も期待など出来はしないだろう。
そんな状況でドコに入れろと？
もう決定された意志が妥当か否かなど分からずとも、取り敢えず何らかの手が打てる状況にかけるしかないのかな？
閑話休題。
自宅サーバ環境の仮想化を含めた刷新を練っている今日この頃だが。
先日、ひとつ明確な方針展開のキッカケを得た。
元々は消費電力などの関係と設置スペースなどからストレージと仮想ホストを一極化したサーバを考えていたのだけど、色々と考えているとストレージサーバと仮想ホストサーバを分割化したサーバも悪くないと思い始めていた。
ただ、どちらの選択をするにしてもそれぞれネックはある。
- 一極化サーバ構想でのネック
-
ストレージのヘルスチェックをどのようにするか？
仮想環境からの物理ハードウェアの制御は出来ない、vMA (vSphere Management Assistant) からは出来るか？
- 分割化サーバ構想でのネック
-
確実な SAN の帯域確保の方法は？
FC SAN を組むだけの経済的余裕があるなら最初から悩んでいないが、NIC チーミングの技術的課題と有効性は？
先日、ストレージを構築するのに導入予定だった Adaptec RAID 5805 に関して Adaptec への問い合わせていた回答を得た。
その回答によると、やはり vMA 上からでも ASM (Adaptec Strage Manager) によるストレージのヘルスチェックが出来ないらしい。
他のベンダにも問い合わせていたわけではないが、Adaptec から出来ない旨の回答を得てしまったので、一極化サーバ構想は捨てざるを得なくなった。
そうすると分割化サーバ構想で進める以外に方法はなくなる。
で、分割化サーバ構想でネックとなっている SAN の帯域確保を考える。
帯域確保自体には NIC チーミングによるロードバランシングが取り得ることまでは分かっており、ロードバランシングに関しては IEEE 802.3ad に Link Aggregation として標準化されている。
しかし VMware ESXi と Linux が会話する場合、IEEE 802.3ad が必要なのだろうか？
（Linux の bonding モジュールの mode=4 と、VMware ESXi の IP ハッシュベースのロードバランシングアルゴリズムが共に IEEE 802.3ad となっている）
IEEE 802.3ad が必要だとすると、L2 スイッチも LACP (Link Aggregation Control Protocol) を含む IEEE 802.3ad に対応したスマートスイッチが必要になる。
ただ、IEEE 802.3ad が必要なアルゴリズムも VMware ESXi 側に用意されている他のアルゴリズムも含めて全て仮想マシンに対して物理 NIC が決まるアルゴリズムのように思えるので、仮想マシンに均等に負荷がかかった場合にはロードバランシングが有効だとしても、“単一の仮想マシン⇔ストレージサーバ”という P2P に近い通信だと帯域向上には役立たないような気もする？
Linux の bonding モジュールの mode=0 と共存できるとしてもリードは速くなってもライトは速くできないような気もする？
Linux の bonding モジュールの mode=0 はラウンドロビンだからパケットの前後関係が狂うこともあり得るので TCP のリトライ発生率が上がる可能性もある？
で、ここまでは仮想ゲストへの帯域確保の話だと思うのだけど、じゃあ VMkernel レベルの NFS や iSCSI の帯域はどうなるの？
もしかして、素直に 10Gbps の NIC 買って P2P の方が安上がりで確実なんてネタになりかねないか？
もう疑問符だらけ(汗々)
手元にある VMware の資料は VMware 徹底入門だけど、これ、VMware ESXi 3.0 が基本で時として 3.5 に言及される程度、最新の 4.0 には対応していないところも情報の限界。
ITpro によると VMware vSphere 4 からストレージパスのラウンドロビンによるロードバランシングが正式サポートされたらしいので、VMware ESXi 4.0 でも当然対応されている筈、この利用が意味があるかもしれない。
この辺りを突き詰めてレポートを作ってくれている人は居ないみたい―――見付けられないだけかもしれんが。
SAN の帯域確保の問題が解決できれば、ネットワーク構成の概要はほぼ終わっている。
現在、我が家には 4 系統のネットワークがある。
ひとつは当然 WAN (Wide Area Network) で、もうひとつは自分が使うプライベートネットワーク、これに公開サーバを格納する DMZ (DeMilitarized Zone) ネットワークと、情報セキュリティリテラシーの低い人間 (主に家族) なんかが端末を繋ぐネットワークが続く。
この上記 4 つのネットワークと隔絶された第 5 のストレージ用ネットワークが重なり、ストレージサーバと仮想ホストを繋ぐだけだ。
さて、どうしようか？
元々 L2 スイッチは企業向けなどを買おうとしていたけど、IEEE 802.3ad の事を考えるとそれだけではなくスマートスイッチが必要になる。
へたに IEEE 802.3ad 未対応の L2 スイッチを買ってから買い直す羽目になると手痛い出費だが、P2P 通信のロードバランシングはしてくれなさそうな IEEE 802.3ad のために高価なスマートスイッチを購入するのも正直どうかと思う。
ラウンドロビン前提なら IEEE 802.3ad 要らんよな………
ここでふと疑問に思う。
NIC チーミングにおけるラウンドロビンってどうやってるんだろう？
L2 レベルのネットワークにおいては、IP アドレスは MAC アドレスに変換されて通信が確立する。
従って、IP 接続を確立する前に IP アドレスを MAC アドレスに変換する手続き――― ARP パケットのブロードキャストをして IP アドレスを MAC アドレスに変換するわけだけど、ARP パケットの構造は IP アドレスと MAC アドレスの一対一だ。
そこから疑問が生じる。
自分がパケットの送信側である場合には物理 NIC は負荷分散できるが、自分が受信側である場合、送信側に宛先の MAC アドレスをラウンドロビンさせられない。
よしんば ARP パケットがブロードキャストされる度に返答する MAC アドレスを変えることが出来たとしても、ARP パケットはコストが高い処理なので通常 ARP テーブルに記憶される。
従って一度返答した MAC アドレスは一定期間は固定されてしまう。
ARP パケットに対して複数の MAC アドレスを返答したとしても、今度は送信側に MAC アドレスをラウンドロビンしてもらうことを期待する必要がある。
そうすると、送信側はロードバランシングできたとしても、受信側を確実にロードバランシングすることは出来ないわけで、P2P 通信においては結果的には帯域は増やせないことになる。
この辺りをどうやって解決しているんだろうか？
結局手動でパスを分ける設定が必要になってしまうのだろうか？
しかし………
なんか VMware ESXi の導入が面倒になってきた(爆)
VMware ESXi を導入しようとして、DAS はダメ、SAN のネットワーク帯域がどうのと面倒な調査を強いられる。
VMware Server ならばホスト OS 側で調整をすれば良いので、非常に導入が簡単だ。
ハードウェア的なリスク集中はするが、ホスト OS に内部ネットワークに対するサービスを持たせ、仮想ゲストに外部ネットワークに対するサービスを持たせれば、一台の強力なハードウェアだけで全てをまかなうことが出来る。
たしかにホスト OS の層があるので VMware ESXi よりもオーバヘッドが大きいとか、ホスト OS が複雑だとバージョンアップ頻度が多くなるからサービス停止の確率が上がるとかいくつか問題はあるけど、企業システムで必要とするような高可用性が必要ないんであれば全く問題ない筈で………(汗々)
ただ、VMware Server は 2008/10/29 に 2.0.0、2009/03/31 に 2.0.1、2009/10/26 に 2.0.2 と進化しているけど、その間に VMware ESX は 3.5 から 4.0 に上がっていたりと差が大きい。
この辺り、今後どうなるか分からないというのが最大の不安要素だったりするけど………
2010年7月7日
Visual Studio で快適に仕事がしづらいワケ
ここ数日、仕事で Visual Studio 2005 の VisualBasic を弄っている。
ま～元々 VisualBasic は嫌いな言語の１つだったんだけど、.Net になって以降は少しだけ、ほんの少しだけ見直している。
で、最近興味のある言語も実は C# だったりする。
C# のストイックなまでの開発者寄りの仕様が悪くない。
でも、Visual Studio 2005 を使っていて常に思うのが、エディタ機能の超絶な使いにくさだよなぁ～
Borland 系 IDE や eclipse に慣れているってのもあるんだけど、ソースコードを縦横に駆け巡る感触がどうにも掴めない。
ソリューションエクスプローラは必要最低限の機能を持ってはいるけど、ソースコードの可視化機能が残念すぎ。
昔からの伝統でエディタの上部にプルダウンでクラスやメソッドを選べる様になっているけど、そもそもコレが史上最悪に使いにくい。
ソースコードの編集に連動して更新されるアウトライン機能があればいいじゃないか。
しかし Visual Studio でアウトライン機能を調べてみると大暴投としか思えない機能が出てくる。
ソースを "#Region *" ～ "#End Region" で括って見えなくしてアウトライン機能ですって言われても「アホですね」としか言い様がない。
デザイナなんかが自動的に変更して、初心者プログラマには触られたくないソースコード部分を隠すのに Region を利用するってのなら納得できるが、プログラマが書くソースコードも Region で括られた日には視認性が極端に下がって苦痛以外の何物でもない。
しかも Region で括られた部分は標準で閉じられていて、開いた箇所を覚えておく機能や、一気に開く機能すらない。
プロジェクト方針で全てのメソッドを Region で囲めなんて決まった日には、それはもう苦痛を通り越して悪夢である。
アウトラインで構造を想像しろと言われても、自分で組んだわけでもないソースコードではよほど厳密な（しかし非現実的な）コーディング規約が決まっていない限りメソッドの粒度はプログラマによりまちまちだし、一貫しているプログラマは希だから、想像しようにも振り幅が大きすぎる。
で、基本的に他人のソースコードを読む時は上から下まで流して眺めて全体の構成とプログラマの特性を大凡で掴もうとするのだけど、Region で閉じられているとこれがパパッと出来ない。
かといって、これをやらずに点から読み解こうとすると想像の斜め下を行くソースコードの方が多いので解読するのに異様な労力と精神力を強いられる。
ハッキリ言って、苛つく、そんなプロジェクト方針を提言した奴に殺意すら湧く、と言うか、即刻死ね(爆)
ソースコードは閉じたい時だけ閉じるを標準にリニアで見せて、ソースコードのアウトラインを抜き出して別途にツリー表示する「アウトラインと言って通常想像する方の機能」があればよい。
そっちの方がよほどにソースコードを縦横無尽に駆け巡れる。
本物の男たちは Region なんて使わない。
Region なんてコードを無駄に長く書いてステップ数だけ稼ごうとする Quiche Eaters のためにあるのだ。
（※The Real Programmer Stories 風）
あと気になるのは、ソースコードから定義へ移動したり、戻ったりという機能。
特に戻る機能の粒度が細かすぎる様だ。
「定義への移動」と「戻る」の粒度が一致していた方が、ソースコードを縦横無尽に駆け巡るには丁度良い。
ここ何やってるの？ と思って潜って色々と調べた後に、元の場所に戻れなくなるってのは思考をぶった切られて苛つく。
キーアサインが独特なのも面倒だ。
Visual Studio 2008 とか最新の Visual Studio 2010 とかで機能改善されているのかもしれないが、Visual Studio 2005 までバージョンを積み上げたにも関わらず実装されなかった基本的な機能が今更追加されているとも思えず。
と言うわけで、Visual Studio は機能点数としては充分に実用的だと思うのだけど、この辺りの地味に開発効率に響いてくる部分の問題で、どうにも食指が動かない。
どうしたモンかなぁ～？？
折角 MSDN にも契約していることだし、Visual Studio 2010 でも放り込んで試してみようかしらん？
ちなみに、前述の「アウトラインと言って通常想像する方の機能」はどうやら代替手段があるっぽい。
Microsoft Visual Studio 2005 IDE Enhancements というツールがあって、この中の Source Code Outliner が期待する機能に近い。
最初から付けとけよ、と思う。
Borland 系 IDE や eclipse 使いはこちらの Microsoft Visual Studio 2005 IDE Enhancements は必須ではないか？
惜しむらくは、フォームではコード表示の場合に Source Outliner、デザイナ表示の場合にドキュメントアウトラインと自動的に切り替わることが出来ないこと。
というかドキュメントアウトラインがコードのアウトライン表示に対応していないのがそもそもの問題なんだけどな。
って、これ、Visual Studio 2008 や 2010 には標準で付いてるんだろうか………？
追記。
Visual Studio 2010 Professional を入れてみた。
ダメだった………(爆)
いや、おかしいだろ、常識的に考えて！？
Microsoft Visual Studio 2010 IDE Enhancements はまだかっ！？
2010年7月5日
SAN を構築するとして、iSCSI vs NFS を考えてみる
自宅サーバの仮想化でストレージサーバの構想を日夜練っている自分だが。
今度は iSCSI と NFS の性能差と Ethernet の帯域問題をヌボォ～と考えてみたい。
と言っても、実測する環境が揃っているわけではない。
ワークステーション機の VMware Player に複数の Linux 仮想マシンを作って試しても良いけど、物理的な帯域制限が発生しなくなってしまう状態でテストしても意味無さそうだし、さりとてテストするためのハードウェア環境はない。
あ～、予備役ノートに Linux 環境構築してみるって手もあるかなぁ～？？
でも VMware ESXi が放り込める空きハードがないや………
色々と調べていくと、Quad core Xeon X7350 (2.93GHz)×4 と 128GB の RAM で構成される仮想ホストに、14GB RAM、仮想CPU×2、Windows Server 2003 R2 で構成される仮想ゲストを 8 系統走らせてバックエンドのストレージにアクセスした際の、FC (4Gbps) と iSCSI (1Gbps)、NFS (1Gbps) の負荷テストを行ったホワイトペーパーなんて変わり種もあったりした。
なんかこのホワイトペーパーでは帯域が違うにもかかわらず傾向が似通っていて、処理能力にも極端な開きがない様に思えるが………？
他にも 100Mbps 環境で NFS と iSCSI とローカルディスクを比較しているレポートもあった。
流石にローカルディスクには及ぶべくもないが、Write が NFS で平均 7.73MB/s、iSCSI で平均 36.1MB/s と随分開きが出ている。
自分で測定しているわけではないので鵜呑みにするわけにはいかないが、iSCSI は NFS に比してそんなにアドバンテージがあるのだろうか？ と疑問を持ってみる。
そもそも 36.1MB/s って 100Mbps の帯域を越えている転送速度だと思うが、Write キャッシュが多分に働いていると考えるのが妥当なのではないか？
たしかに iSCSI は NFS の様にファイルシステムを経由していないブロックデバイスとして認識されるので転送能力自体のポテンシャルはあると思うが、余計なファイルシステムを挟んでいないだけでこれほどに違うとも思えない。
しかしこれだけ出るのなら検討しても良いのかと思う。
iSCSI は CPU 負担が高いと言われているのも懸念点だが、iSCSI が登場した 2003 年当時と現在では CPU の処理能力も全く異なる。
2003 年当時はオフロードエンジンを積んだ HBA が無いとソフトウェア実装だけでは CPU 処理能力を喰いまくった iSCSI も、現在の CPU の処理能力ならばなんとかなるかもしれない。
（2003 年と言えば Northwood コアの Pentium 4 が最新で、Prescott コアは話題に上る程度の時代だ）
2003 年当時は 100Mbps の Ethernet が一般的だったが、現在は 1Gbps が主流だし、ジャンボフレームを利用すれば転送能力の向上と共に CPU 処理能力の節約にもなるだろう。
10Gbps の Ethernet が普及したら帯域の問題は一挙に解決するに違いない―――というか今度は生半可なストレージでは処理能力を超えそうだけど(汗々)
ま～ 10Gbps の Ethernet は HBA 同士の P2P 接続なら現在でもやって出来ないことはないかな？
価格が落ちないのは L2 スイッチの方で 10Gbps の HBA なら 5.5 万円程度で買えるので、2 枚買ってきて直結すれば似非 SAN の出来上がり。
しかし現状ソコまで余計な予算を投入できないし、前述の通り生半可なストレージでは処理能力が追いつかないから意味もないだろう。
それに NIC チーミングを前提にした方が後々の仮想ホストの増加なども考えた際に安価な L2 スイッチを利用できるのでリーズナブルだ。
仮想ホストの台数分だけストレージサーバ側に 10Gbps NIC をぶっ差すのは流石に現実的ではない。
でも、もしもの時のために 8 レーンの PCI-E を余らせておくようにしようか？(爆)
などと漠然と考えながら眺めていても、その物ズバリなレポートをしている人は居ない。
高い買い物だから人柱になるのは洒落にならんのだけど………(汗々)
環境整えてから自分で測定する結果が最も信頼できる結果だと思うけど、ストレージサーバ前提で環境組んでから万が一 iSCSI も NFS もパフォーマンスが出なかったとか言った日には、DAS に移行するのは無理だしなぁ～
結局、俺等みたいな趣味の範疇で尖ったことする輩は多かれ少なかれ人柱ってことか(爆)
2010年7月4日
ストレージサーバにチーミングは必須かな？？
自宅サーバの仮想化でストレージサーバの構想を日夜練っている自分だが。
ストレージサーバと仮想ホストの組み合わせで環境を構築すると柔軟性は上がるのだけど、やはり仮想ゲスト用にマウントしたストレージとの通信速度がネックになりそうな不安がどうしても拭えない。
そもそも現実的に予算の許す一般的な Ethernet の最大通信速度は 1.0Gbps だが、これは NIC や L2 スイッチなんかもちゃんとしたモノを使った上での理論値だ。
ま～現状では VMware ESXi を前提としている以上、NIC は Intel のサーバ向けしか考慮していないのだけど、それでも最大が 1.0Gbps なのである。
TCP/IP のオーバヘッドなど一切合切無視してロス無しで計算しても 125MB/s の転送速度しか出ないのである。
実際には 100MB/s も出れば御の字と言えよう。
ちなみにこの 100MB/s という数字はどの程度の物かというと、過去に取ったベンチマークが良い参考になる。
過去に取ったベンチマークで CrystalDiskMark 3.0 x64 を利用して ICH10R に直接ぶら下げた SATA ハードディスク Seagate ST3500320NS (7,200rpm) が出したシーケンシャルリードの速度が 109MB/s であるから、どんなに頑張って通信品質を整えたところで SATA ハードディスク 1 本分の転送速度しか出ないということである。
ま～実際にはハードディスク側のランダムアクセス性能に引き摺られることになるので 1 本分しか出ないと言うことはないのだけど、何にしろ RAID 組んで応答性能を向上させてもネットワークの帯域に制限されて I/O 性能が奮わないのは自明の理だ。
この辺りが iSCSI や NFS でストレージを実装した場合の考慮すべき点である。
ちなみに iSCSI HBA を導入してもこの問題は変わらない。
iSCSI HBA の役割は CPU 負荷の高い iSCSI イニシエータの処理をハードウェアに委譲することであり、そもそものボトルネックである Ethernet の帯域を増やすモノではない。
（中には後述の NIC チーミングの機能を持つ物もあるようだが）
さて、だからといって 4.0Gbps や 8.0Gbps の FC を導入するのは以ての外なので、その他の方法を検討する。
基本的にどんな分野でも発想としてはあるのが、低性能な物でも束にして使えば高性能な物に匹敵できるという発想で、ハードディスクの RAID なんかは有名な例だ。
NIC も例外ではなく、NIC チーミングという手段で複数の NIC を束ねて帯域を増やすという試みがある。
単純な話だが、1 本で 1.0Gbps なら束にしたら？ という発想である。
VMware ESXi には仮想スイッチに複数の物理 NIC を接続して利用する NIC チーミングの機能がある。
NIC チーミングを利用するとロードバランシングによる負荷分散で帯域を拡張できる上に、ひとつの NIC が死んでもネットワークを止めないフェイルオーバーを実現できる。
今回の主目的はロードバランシングなのでフェイルオーバーはオマケだが、これを利用すれば帯域を稼ぐことが出来るだろう。
一方、Linux で構築するストレージサーバ側も bonding で同様にチーミング出来る筈だ。
1.0Gbps を 2 本束ねれば理論上 250MB/s の転送速度が確保でき、これは SAS 15,000rpm のハードディスク単発の転送能力を充分にまかなえる帯域だ。
SATA 7,200rpm のハードディスクなら 2 本で RAID-0 した場合の転送速度も充分にまかなえる。
SAS 15,000rpm のハードディスクを 2 本で RAID-0 した場合の転送速度にはシーケンシャルアクセスでは及ばないが、ランダムアクセスなら問題なかろう。
1.0Gbps を 3 本束ねれば 375MB/s なのでかなり余裕が出るが、当面の用途としては 2 本束ねただけで充分だろうか？
というか 3 本以上束ねる気ならば、ストレージサーバにも仮想ホストにも追加で NIC を放り込まないとならない(汗々)
最初から NIC を 4 系統積んでいるマザーボードを考えていたけど、早くも NIC が枯渇するか！？
問題は、VMware ESXi の NIC チーミングと Linux の bonding がちゃんと互いに会話できるか？ という一点に集約される。
そもそも NIC チーミングって仕様として纏まっているんかい？ と聞きたい。
ちなみにこれは余談だけど。
昔の話で記憶も曖昧でソースに辿り着けなかったのだけど、たしか NAS 製品のメーカー技術者へのインタビューだかで馬鹿なことが書いてあった。
日本市場だと NAS のセールスポイントは基本的に価格と容量なのだけど、アメリカ市場だとハードディスクの回転数がセールスポイントになるらしい。
しかし上記でウジウジと悩んでいるように、1.0Gbps のネットワークに CIFS や NFS で公開する NAS なのだからネットワーク帯域の方がボトルネックになって転送速度が頭打ちになる。
更に NAS 製品は元々 RAID で耐障害性とアクセス性を上げているモノがほとんどだから、5400rpm の低速ドライブで消費電力と廃熱を抑えた方が利口だ。
しかしアメリカ市場だと 7200rpm の高回転ハードディスクを積まないと買って貰えないそうである。
全く意味がない(汗々)
流石はアメリカ人、伊達に Muscle is Justice なハリウッド映画で育ってないな(爆)
2010年7月3日
ストレージサーバ構成の検討
東芝ノート PC、dynabook RX3 の直販モデルに新たなラインナップが加わった。
特に目を惹くのが上位機種である RX3W/9MWMA だ。
これらは初期状態でメモリが 8GB 積んである上に WiMAX も搭載した現在での最上位機種となる。
まだ SSD は 128GB のままだし、CPU も Core i5-520M 止まりなので食指は動かないが、少しずつラインナップが拡充されて来つつあるようだ。
さてさて、自宅サーバ環境の計画を日夜練り続けている今日この頃だが。
当初の構想と違った方向性での見積を考えてみた。
今までは応答性の良いまともな SAN を組むには予算的にも床の強度、電気代的にもキビシイと考えて、DAS 前提の一点豪華主義を考えていたのだけど、ストレージサーバと仮想ホストを分けるともしかしたら丁度良い構成になるのではないかと思い始めている。
実は情けない話だが、VMware ESX のストレージは DAS (Direct Attached Storage)、iSCSI、FC (Fibre Channel) 以外にも NFS (Network File System) が利用できることを失念し続けていたことに遅まきながら気付いたのが発端だ(爆)
FC で組む SAN はエンタープライズ分野では一般的だが、如何せん予算が膨大になるのは想像に難くない。
FC の HBA (Host Bus Adapter) はシングルチャネルですら 10 万円を越えるので、即却下である。
FCoE (Fibre Channel over Ethernet) は問題外。
iSCSI はソフトウェア実装だと CPU 側にかかる負担が大きかったりするが、だからと言ってオフロード・エンジンの採用を考えると結果的に FC と同様の規模の予算がかかってしまうし、そこまでしても現在の Ethernet の予算的な限界である 1.0G を越えられない。
(10G の NIC は出始めたが L2 スイッチが絶望的な値段だ)
FC はダメ、iSCSI もダメ、そうなるとなし崩し的に DAS しかないかと考えていたのだけど、NFS が利用できるんであれば極端な I/O 性能が必要ないフロントのサーバは NFS 上の仮想マシンで充分になるのでは？ と考えたわけだ。
で、構想はこうだ。
まず Linux ベースのストレージサーバを構築し、基本的に全てのストレージ管理を任せてしまう。
こちらは極端に大きい CPU 処理能力は要らないから、Lynnfield の Intel Xeon X3440 辺りでも充分だろう。
ストレージサーバには大容量ボリュームを管理させて、必要に応じて NFS、CIFS などの用途に合わせたプロトコルでボリュームを提供させる。
そうすると現在のファイルサーバの用途も集約できるから、1.0TB のハードディスク×4 も転用を考慮できてリーズナブルだ。
それにストレージ管理だけでは Xeon X3440 は確実に処理能力が余るので、VMware Server 2.0 辺りを導入して開発用仮想ホストの役割も持たせてしまったり、I/O 性能が必要なデータベースサーバの役割も持たせてしまっても良い。
なによりストレージサーバとして構築すれば様々なツールがハイパーバイザーに邪魔されずに駆使できるので管理性も良いだろう。
（VIMA もあるけどな）
仮想ホストの方は、ストレージサーバ側に一部の用途が負荷分散されるので一点豪華主義な性能は要らなくなる。
Intel Xeon X5650 辺りを単発積んだ機体にメモリはそれなりに積んでおいて、ストレージ は VMware ESXi を乗せるだけの小さな分だけでよい。
仮想ゲストが利用するボリュームはストレージサーバへ NFS で接続する。
ハードディスクを内蔵しないからケースは必要最低限の小さい物でよいので、省スペースにもなろう。
また、仮想ホストは下手に自作せずとも薄型で省電力なサーバを見繕ってきて使ってしまっても良いかな？
ま～、そうなるとブレードは良い選択肢だけど流石にそれは無理だ(爆)
唯一気をつけなければならないのは、様々な通信が行き交うネットワークから SAN で利用するネットワークを隔絶しないと帯域が圧迫されてしまう程度か？
少しまともな L2 スイッチを仕入れてきてもう一系統ネットワークを構築する必要がある。
基本的に Windows ネットワークを隔絶すれば下逸フラッシュ(爆)の被害も受けないわけだし。
そうすると仮想ホストに求められる条件に、2 系統の NIC が装備されていることが追加される。
ストレージサーバ側も最低限 2 系統だが、3 系統あると柔軟なネットワークが構築出来るので考慮したい。
ちみなにストレージサーバ構成で大容量ハードディスクの転用も考慮に入れて予算を弾くと 5 万円程度安くなる見通し。
さて、どうすっか―――？
