「iSCSIはFCと比較して遅い」という認識が持たれていますが、iSCSIの問題は速度よりもCPU負荷と安定性にこそあった気がします。
Fiber ChannelはHost Bus Adapter (HBA), Fiber Channel Switch (FCSW) のいずれもが非常に高価であったにもかかわらず、ネットワークストレージを必要とするニーズが非常に高まったために、思った以上に一般化してしまいました。FC HubもすぐにFC Switchが取って代わり、処理速度も下位互換性を確保しつつ1Gbps - 2Gbps - 4Gbpsと順調に伸び、SANはせっかくのネットワークストレージの規格であるにもかかわらず、クローズドなストレージネットワークを構成したために、個別のシステムごとにFCSWを使ってSANが構成されていったという事情もあるかと思います。
iSCSIは規格としてはだいぶ前からあったものの、FCのHBAのようにハードウェアイニシエーターの普及が遅かったために、どうしてもOS側の対応が必要とされ、結果としてCPU負荷のあるソフトウェアイニシエーターを使わざるを得ない状況となり、普及が遅れてしまった気がします。
数年前からNICにはTCP/IP Offload Engine (TOE) 機能が搭載され、TCP/IPに関する処理をCPU側からNIC側で処理する仕組みが出てきました。TCP/IPの処理はあまり目立ちませんが、OSが処理する以上、一定のCPUリソースを使う処理だったわけですが、その負荷をCPUにかけずに済ませてしまおうという発想です。そして今年、TOEに加えてiSCSIをNIC側で処理するiSCSI Offload Engine (iOE) 機能を搭載するNICが登場、一般化しそうです。これにより、iSCSIをCPUに負荷をかけずに処理することができるようになります。TCP/IPの処理がCPUに与える負荷は数%ですが、iSCSIは10-20%程度の負荷を与えますので、その負荷からCPUが解放されるメリットは少なくありません。
さらに、iOEを使用することのメリットは、OSによるソフトウェア処理を必要としないため、iSCSI Bootが可能になること、そしてやはり、iSCSIが安定して使用できるようになることが大きいのではないかと思います。サーバとストレージ間の経路を冗長化し、どこかに障害が発生した場合に経路がFailoverされて継続できるようにする仕組みなどは、HBAを使ったFCではかなり安定して動作するイメージがありますが、どうもそのあたりがソフトウェアイニシエーターを使うiSCSIでは安定性に欠けていた気がします。iOEを使えば、そうした不安定さもだいぶなくなるのではないかと期待しています。
SANと異なり、全体が統合されているが故になかなか10Gbpsが普及しないEthernetですが、iSCSIストレージとサーバ間の通信用途としてついに普及するのでしょうか。iOEと10Gbps Ethernetの組み合わせによって、iSCSIの普及に拍車がかかるか、今年はターニングポイントになるかもしれません。
http://support2.jp.dell.com/docs/network/BroadCom/R125805/ja/features.htm
https://enterprisezine.jp/article/detail/292?p=1
