Fibre Channel over Ethernet（FCoE）に業界が強く反応し、ほとんどのベンダーがサポートの意向を表明したことを考えると、この統合型トランスポートは最終的に、既存のファイバチャネルネットワークに取って代わる可能性が強いようです。標準化は完成に近づきつつあり、2009年4月ごろ規格が承認される見通しです。現在のドラフト規格がそのまま承認されるものと思われ、NetAppをはじめ多くのベンダーが製品発表の準備を進めています（サイドバーを参照）。

現在、ファイバチャネルテクノロジを使用している場合は、この新しいテクノロジについて今から予習しておくべきでしょう。この記事では、FCoEテクノロジに関するいくつかの重要な質問にお答えします。具体的には次のとおりです。

• FCoEとは何か
• FCoEを選ぶ理由
• FCoE実装にはどのような選択肢があるか
• どのような準備が必要か

FCoEとは何か

Fibre Channel over Ethernet（FCoE）は、T11委員会が標準化を進めている新しいプロトコル（トランスポート）です（T11はInternational Committee for Information Technology Standards [INCITS]の下部組織であり、ファイバチャネルインターフェイスを担当しています）。FCoEは、ファイバチャネルフレームをジャンボイーサネットフレームでカプセル化して、イーサネット上で転送します。2008年内の規格承認は間に合いませんでしたが、今後、承認までに規格が変更されることはなさそうです。

FCoEを選ぶ理由

FCoEの主眼は、同じ電送メディア上で異なるタイプのトラフィックを安全に共存させることによって、I/Oを統合することです。その結果、ケーブル接続の削減と簡素化、ホストごとに必要なアダプタ数の減少、電力の削減といったメリットがもたらされます。

図1) FCoEによるホストの複雑性の解消

FCoE採用への動機は、Total Cost of Ownership（TCO;総所有コスト）を削減すると同時に、既存のインフラ投資を保護し、使い慣れた手順やプロセスとの下位互換性を確保したいというニーズにあります。ファイバチャネルとイーサネットを統合し、その他のネットワーク技術を不要にするFCoEは、ネットワークの複雑性を大幅に軽減します。おそらく最初のうちは、大部分のFCoE構成はホストおよびスイッチレイヤに限定され、バックエンドアレイはFCoEではなく、引き続きネイティブのファイバチャネルで接続されるものと予測されます。そうすることで、過去何年間にもわたるファイバチャネルへの莫大なインフラ投資が保護されます。

FCoEの優れた点は、ファイバチャネルからイーサネットへの段階的な移行が可能な点です。ファイバチャネルネットワークの一部分をイーサネットスイッチで拡張したり、交換したりすることが可能であるため、1つのネットワーク技術（FC）からもう1つの技術（イーサネット）に合理的かつ整然と移行することができます。長期的には、FCoEが成功した場合、インフラのアップグレードやデータセンターの新設を行う時点で、ネイティブFCoEサポートのあるストレージアレイを検討してみてください。NetAppはネイティブFCoEをサポートすると同時に、すべてのストレージシステムで引き続きファイバチャネルをサポートします。

NetApp、QLogic、Nuova Systems（現在はCiscoの一部門）が共同発表した最近の論文(英語)では、ネットワーク統合によるビジネス上のメリットについて詳しく説明しています。

FCoEの実装

FCoEは、次の2通りの方法で実装できます。

• Converged Network Adapter（CNA）を搭載したハードウェアイニシエータ、および既存のファイバチャネルモデルに類似したハードウェアターゲットの使用






図2) 1つのCNAでFCとイーサネットの両方が1台のデバイスからサポートされ、必要なネットワークインターフェイス数が減少します。

• CNAベンダーはQlogic、Emulex、Brocadeなどの一般的なFC HBAサプライヤーですが、Intel、Broadcomなど従来のNICベンダーも、この市場に参入することは確実です。実際、この2社はT11（FC-BB-5）ワーキンググループに参加し、FCoE規格の定義に積極的に関わっています。

• ソフトウェアイニシエータおよび一般的な10ギガビットイーサネット（10GbE）NICを搭載したターゲットの使用
  
  2007年12月、IntelがLinux®用のFCoEソリューション開発を支援するソフトウェアイニシエータパッケージをリリースしました。今後1年の間に、FCoEソフトウェアイニシエータドライバを組み込んださまざまなLinuxディストリビューションが発表されるものと予測されます。現在、すべてのOSプラットフォームがiSCSI対応であるのと同じように、FCoE対応のLinuxディストリビューションが一般化するでしょう。
  
  
• このようなソフトウェア実装は、ハードウェア実装と比べて低いコストで十分に高いパフォーマンスを提供することができます。ソフトウェア実装によってサーバに生じるオーバーヘッドについては、理論上CPUサイクルの空きは豊富に残されていると考えられます。なぜなら、我々がサーバを購入する際、子供の服を買うときと同じように、アプリケーションの成長を見込んで購入しているからです。iSCSI市場では、この理論が正しいことはサーバ仮想化の実装でも証明されています。



図3) FCoEのソフトウェアイニシエータスタック

従来と変わらないもの

ファイバチャネルをすでに使用している場合、ゾーニング、LUNマッピングなどの日常的な作業はFCoEでも同様です。また、Registered State Change Notification（RSCN）、Link State Path Selection（FSPF）などの一般的なファブリックイベントも同様です。このように、FCoEへの移行は比較的簡単です。とかく変更は頭痛の種になりがちですが、既存のノウハウ、プロセス、および投資を活用し、イーサネットへの移行を容易にする新しいプロトコルは、多大なメリットをもたらします。

FCoEとiSCSIの相違

FCoEはiSCSIで使用されるTCP/IPレイヤを置き換え、イーサネットレイヤの次のような改良に依存します。

• 適切なポーズフレームの実装
• プライオリティに従ったポーズ
• TCP再試行（タイムアウト）なし
• IPルーティングなし
• ブロードキャストストームなし（ARPなし）

図4) 各ストレージプロトコルのブロックレベルでの比較

FCoEにはIPレイヤがないので、FCoEは本質的にルーティング不可能ということになります。ただし、ルーティングを実行できないという意味ではありません。すでに確立されているプロトコル（FCIPなど）を使用して、FCoEルーティングを実行することができます。

iSCSIプロトコルは、パケット損失が起こりがちなネットワークでも実装することができ、10GbEを必要としません。一方、FCoEには10GbEが必要です。また、ロスレスネットワーク（プライオリティの異なる個別のトラフィッククラスに基づくポーズフレーム要求、およびプライオリティに従ったポーズフローコントロール[PFC]をインフラコンポーネントで適切に実装）も必要です。PFCは、輻輳時にプライオリティの高いトラフィックの処理を続行し、プライオリティの低いトラフィックを停止することを目的としています。

使用する10GbEスイッチも、Data Center Ethernet（DCE）をサポートしている必要があります。DCEは、サービスクラス、効率的な輻輳制御、改良された管理機能など、広範囲の拡張機能を含む拡張イーサネットです。FCoEにはジャンボフレームのサポートも必要です。なぜなら、FCペイロードは2,112バイトあり、分割不可能だからです。iSCSIにはジャンボフレームは不要です。

ファイバチャネルはどうなるか

FCoEに注目が集まる一方、ファイバチャネルは今後どうなるのでしょうか。16ギガビットテクノロジへの移行はそれでも起こるのでしょうか。それともFCoEが主役の地位に躍り出るのでしょうか。イーサネットは今後も開発活動の中心になるのでしょうか（40GbEおよび100GbE）。現時点でわかっているかぎりでは、16Gb FCは2011年に完成予定です。FCIAは最近のプレスリリースで、16Gb FCの開発を「強力に」サポートし、同時にFCoEもサポートすると明言しています。16Gb FCは必ず実現すると私は思います。しかし、それより大きな問題は、FCoEと比べてどの程度まで普及するかという点です。この点については、まだコメントできる段階ではありません。

必要な準備

今の段階で何をしておくべきかについては、企業が置かれている状況によって異なります。ファイバチャネルに莫大な投資を行い、今後2～3年アップグレードの必要がまったくない企業では、何もしないのが得策でしょう。この期間中にアップグレードを計画している企業では、FCoEを真剣に検討すべきです。現在のFCスイッチベンダー各社がカスタマーベースの大部分をイーサネットに移行していくことを考えると、今後いずれかの時点で切り替えが必要になるでしょう。

テクノロジは多くの問題を解決できます。しかし、組織におけるグループ間の意見調整という問題は、テクノロジでは解決できません。企業でiSCSIが直面している問題の1つは、ネットワークの管轄をめぐるストレージチームとネットワークチームの小競り合いです。FC実装ではストレージグループがファブリックを担当し、iSCSIの場合はネットワークグループの担当になります。FCoEを成功させるためには、これら2つのグループが折り合いをつけ、今までにないほど緊密に協力する必要があります。これがFCoEで克服すべき最大のハードルといえます。

FCoEについてさらに詳しい情報をご希望であれば、私の同僚、Silvano Gaiが最近『Data Center Networks and Fibre Channel over Ethernet (FCoE)』という本を執筆しました。この本では、FCoEの技術を非常に詳しく解説し、FCoEスタックの各コンポーネントの機能についても説明しています。

Nick Triantos NetApp、コンサルティングシステムエンジニア NetAppのコンサルティングシステムエンジニアリンググループ所属のNickは、NetApp仮想化製品およびSANソリューションのNetAppパートナーによる開発と実装を担当しています。約15年間、SEやサポートエンジニアとして勤務した経験を持ち、HPでは顧客のサポートエンジニア（サーバグループ）と販売前の技術コンサルタント（ストレージグループ）を務めていました。Nickはブログ(英語)を運営しており、Tech OnTapにも頻繁に寄稿しています。

FCoEとiSCSIの比較

新しく登場するFCoEはiSCSIと比較してどうなのか、という当然の疑問にお答えします。

• FCoEには、10ギガビットData Center Ethernet（DCE）が必要です。
• iSCSIでもDCEは有利に働きますが、iSCSIの場合、ほとんどすべての速度で動作します。
• 初期の段階では、FCoEにはConverged Network Adapter（CNA）が必要です。
• iSCSIの導入には通常、OSで提供されるソフトウェアイニシエータを使用します。
• FCoEはルーティングできないため、FCIPなど、ルーティング用に余分のプロトコルが必要です。
• iSCSIはルーティング可能です。