墜落日記 - 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 を紐付けてしまう方法を利用する。
で、ベンチマークとパフォーマンスモニタの参照………
ストレージサーバ側がロードバランシングされてねぇ～よっ！！
ううむ、うまく経路選択でロードバランシングされなかった。
どこにボトルネックが発生しているのかも含めて、まだまだ研究の余地があるなぁ～
コメントは投稿されていません。