(1)、(2)の続きです。
FC SANの場合、基本的にはソフトウェア制御をすることはないのでFC通信のための専用アダプタHBAを用います。FCプロトコル部分はすべてハードウェア制御されますので、サーバOS側はSCSIとしてのマルチパスを制御するドライバによってマルチパス制御を行うことになります。iSCSI SANの場合も、FCと同様に専用アダプタiSCSI HBAを用いる場合はFCの場合と動作はまったく同様です。しかしiSCSIの場合はWindows, Linux, Solaris, そしてVMware ESXなどの主流なOSがのきなみ標準でiSCSI Software Initiatorを搭載したため、iSCSIプロトコルをソフトウェア的に制御する構成が多く用いられるようになりました。Software Initiatorを用いることによるデメリットはデバイスドライバレベルでのソフトウェア制御であるためにFirmwareレベルで実装されているFCなどと比較してどうしてもOSがソフトウェア的に処理する＝CPUリソースを消費すること、OSが起動した後にドライバとしてロードされるため、FC BootのようなOS起動前に対応が必要となる構成ができないことなどがありましたが、データ用のネットワークブロックストレージとして用いるには特に支障はなかったことと、CPUもマルチコア化によって多少のCPU負荷はまったく問題がない状況となったことなどによって、Software Initiatorを用いたiSCSIプロトコルの利用が普及したといえるかと思います。1GbEレベルであればハードウェア処理の場合と比較して、Software Initiatorを用いた場合であっても通信速度面での性能はまったく遜色がないレベルであったこともiSCSIのソフトウェア制御を普及させた要因の1つといえるかもしれません。
しかし今後は10GbEの普及、そしてiOE搭載NICの普及によって状況は変わっていくでしょう。iOE搭載NICの場合、IPアドレスの割り当てなどの管理はOS側に依存しますが、MACアドレスは通常の通信用とは別にiSCSI用が用意されているなど、ネットワークアダプタとしてはiSCSI制御部分はほとんどHBAに近いものとなっています。Firmwareを構成することによってiSCSI Bootも可能となっています。また、10GbEレベルの通信処理となるとCPU負荷もそれなりにはなるため、iSCSIのオフロード化を推し進める要素となるでしょう。
※http://cloud.watch.impress.co.jp/epw/cda/parts/image_for_link/42627-13894-6-1.htmlよりパクリ(^_^;)
iSCSIの独自性ともいえる実装がリダイレクトをプロトコル仕様として実装していることでしょう。ここはネットワークとしてTCP/IPを用いていることをメリットを活用しているといえるかもしれません。WWNもしくはポートでZoningすることにより、形としてはネットワークでありながらも実際には1対1の紐付けを必要とするFC SANでは冒頭書いたようにマルチパスドライバによってマルチパスを制御するしかありませんが、iSCSIの場合はサーバ側からは隠匿したかたちで、サーバに対しては透過的にマルチパス制御やロードバランスを実装することができるわけです。
iSCSIリダイレクトをどのように実装するのかについてはiSCSIストレージ側次第ではありますが、使い方としては負荷分散とマルチパス制御がポイントとなるでしょう。負荷の低いポートへリダイレクトすることによって負荷を自動的にバランシングすることができますし、個別ポートのIPアドレスではなく仮想IPに対してiSCSIセッションを接続させるような仕様とすれば、サーバ側ではパスを一切制御することなくマルチパスを実現することができます。
概要の話ってどのレベル感で書くべきなのか、なかなか難しいですね。このシリーズ？はこれでひとまずおしまいです。
