FCとiSCSIについて考察してみます。
多くの場合争点となるのは以下のポイントだと思います。
性能
一般にFCの方が性能的に優れていると認識されています。これはFC DiskかSAS Diskかというディスクの違いもありますが、明らかに違うのはネットワークの帯域でしょう。iSCSIが利用するバックボーンはEthernetであり現在ほとんどのiSCSIネットワークは1GbpsのEthernetで構成されています。10Gbpsの機材も販売されはじめていますが、コストがまだまだ高いのが現状です。一方FCのネットワークでは4Gbpsが主流で、理論値ではGigabit Ethernet約4倍の差があります。（また、8GbpsのFCも出てきつつありますね） ということでそもそもはこの帯域の差をもって「iSCSIだと性能が不安だ」ということになっていると思います。
10Gbpsを使わない限りこの差があるのは事実ですが、ストレージの性能とはネットワーク帯域だけではありません。ストレージの性能にはボトルネックになり得るポイントがいくつかありますよね。
1.サーバ側のネットワークポートの帯域幅
2.ストレージ側のネットワークポートの帯域幅
3.サーバのCPU
4.ストレージのコントローラ
5.ストレージのディスク
この中で1と2の「ネットワーク帯域幅」がiSCSiとFCで性能に明らかな差がある部分です。しかしこの中には帯域幅よりも先にボトルネックとなりがちなポイントがあります。
5ストレージのディスクです。
ディスクの本数にもよりますが12本程度のディスクでランダムRead/Writeの負荷をかけると、帯域幅という面では1Gbpsにも到達しないでしょう。実際はストレージには複数のポートが装備されているので帯域的にはかなり余裕のある状態です。となるとFCとiSCSIの差はなくなります（ディスク自体がFC, SASと違う場合にはその部分は依然として残る）。実際とあるストレージ機器ではFCモデルとiSCSIモデルでシーケンシャルRead/WriteではFCが勝るものの、ランダムRead/Writeではどちらも同じIOPSになっています。となると「うちはストレージの負荷がかなり高いからiSCSIなんて無理だよー」と思っている人もその負荷がランダムRead/WriteであるならばFCにこだわるよりもより「ディスクの本数を増やす」ことに注力すべきでしょう。あるいはSSDというのも熱い選択肢だと思います。
コスト
FCストレージ自体がそもそもはハイエンドというイメージがあり、iSCSIは廉価というイメージがあります。実際はFCストレージでも価格のこなれたローエンドの機種も存在します。しかしFCスイッチやHBAはEthernetのL2スイッチやNICと比べて相当に高価であることは間違いありません。HBA等はたかだかカードだと思って見積もりをとってみるとその価格に驚きます。結果的にFCの方がコスト高になる傾向にあることは事実だと思います。
そしてこれはあまり注目されることはありませんが、特に仮想化環境で重要な要素に「管理性」があると思っています。
管理性
例えば一つのESXi上で20個のゲストOS（仮想マシン）を起動するとします。そしてそれぞれのゲストOSに対して専用のボリューム（Logical Unit）を作成して割り当てる場合、2通りの方法があります。一つは一度dom0でボリュームを認識し、それをゲストOSに貸し出す方法。これはFC, iSCSIともに可能です。もう一つはdom0は関知せずゲストOSが直接ストレージに接続してボリュームを認識する方法です。
後者はPCIパススルー等の特殊な手法を除いてFCでは実装できません。iSCSIのみで実現可能です。後者はdom0で貸し出すボリュームをマネージする必要がなくなるので管理作業（ボリュームをゲストOSに貸し出すという作業）を一つ省くことができ、よりシンプルです。そして重要なのがアクセス制御です。前者のdom0でボリュームをマネージする形態では20個のゲストOS用のボリュームをすべてdom0が「仕分け」しなければいけません。このボリュームはこのゲストOS、このボリュームはこのゲストOS・・・といった具合です。数が多くなるほどオエッとなる作業ですよね。一方iSCSIであればイニシエータIQN等で簡単にアクセス制御をかけることができます。つまりあらかじめストレージ側でボリュームの設定さえしておけば、すべてのゲストOSは同じようにストレージに接続するだけで自分用の領域だけが見える、という状態にできます。この場合仕分けは必要なくなるのでかなり管理が楽になるはずです。Linuxでは通常iSCSIイニシエータIQNはOS毎にランダムな値が自動生成されて/etc/iscsi/initiatorname.iscsiに設定されています。ただしこれは任意に設定することが可能です。僕は自分のVMテンプレートに、起動時にホスト名を元にイニシエータIQNを自動設定するロジックを組み込んでいます。
そうすることでいちいちゲストOSのイニシエータIQNを調べなくても、あらかじめ予測してストレージ側で設定しておくことが可能です。
＊ちなみにこのイニシエータIQNによるアクセス制御は「セキュリティ」を意識したものではなく、「適切なボリュームに間違いなく接続するため」のものです。セキュリティを意識するのであればさらにCHAP認証等が必要でしょう。
ということで特にFCを必要とする要件がない限りはiSCSIの方がお薦めだと思っています。
ただしサーバ側のネットワークポートの帯域が詰まった場合には少し工夫が必要です。最も単純なのはゲストOS毎にアタッチする物理ネットワークポートを切り替えることですが、これは少しばかりモサい運用であると言わざるを得ません。Bondingで帯域を増やせれば一番楽ですが、スイッチを冗長化した構成でActive/ActiveのBondingを動かすには注意が必要で、Active/Standbyのようにおいそれとは動きません。方式も単純なラウンドロビンから802.3adのようなプロトコルまであるため、機器の相性を確認しながらネットワークを慎重に構成する必要があるでしょう。あとはBondingではなくDevice Mapper Multipath等を使ったマルチパス。ただしマルチパスもストレージとの相性があり、とあるストレージは「このマルチパスドライバじゃないとダメ」とかいろいろあるので少し混沌としています。
このあたりは一口にどればベストと言い切るのは難しいところです。
共通して言えることは、
- iSCSIは試してみるべき。食わず嫌いは勿体ない。
- 負荷の特性を知るべき。その結果によって帯域が必要なのかディスクのスループットが必要なのか見極める。
- ディスクのスループットが必要な場合は単価の低い機器でディスク本数を増やすのがベスト。SSDも素晴らしい選択肢。