墜落日記 - 最新の墜落
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 での運用って非常に難しいのでは？？
この辺りも色々と研究してみないとダメだなぁ～
まだまだ問題は山積だ………(涙)
