墜落日記 - 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 に上がっていたりと差が大きい。
この辺り、今後どうなるか分からないというのが最大の不安要素だったりするけど………