墜落日記 - 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 での運用って非常に難しいのでは？？
この辺りも色々と研究してみないとダメだなぁ～

まだまだ問題は山積だ………(涙)