イーサネットとFCの未来

これら2つのプロトコルは長い間異なるニッチに住んでいましたが、お互いに競争し始めたときがきました。 イーサネットが文字通りの意味で速度を上げており、 FCが常にフィールドで唯一のプレーヤーと考えられてきたところから上昇し始めていることがはっきりとわかります。 ブロックアクセスの両方で、イーサネットで動作するFCに代わるものがあります：IP- SAN 、 FCoEおよびその他のタイプ。これらはファイル（ SMB 、 NFS ）、 RDMAおよびオブジェクトです。

この記事は、プロトコルを比較することを目的としたものではなく、 データセンターネットワークの進化に関する簡単な時系列の説明を目的としています。





*一部のイベントでは、正確な日付はありません。 日付ごとに修正と追加を送信し、参照を確認してください。 タイムライン。

イーサネットの問題

1Gbのリリースにより、イーサネットはフレーム損失に関連する多くの子供時代の病気を失います。 2002年と2004年に、最も一般的なイーサネット10 Gb /秒標準が採用されました。 このプロトコルは、新しい64b / 66bコーディングアルゴリズム（スループット10 * 64/64 Gb）を使用してスループットを改善します。 2007年には、100万個の10Gbポートが販売されました。

イーサネット40 Gb /秒およびイーサネット100 Gb /秒は、2010年に標準化された同じ64b / 66bコーディングアルゴリズムを使用します。一部のメーカーは、2008年に将来の40/100 Gb標準のドラフトの実装を提供しています。

データセンターのブリッジング

DCB標準（ロスレスイーサネットとも呼ばれる）は、IEEE 802.1とIETFの2つの独立したグループによって2008年から2011年に開発されました。これらの標準に基づいて市場で入手可能な製品には、 DCEとCEEの 2つの異なる用語が適用されます：

DCBおよびCEEの詳細については、対応するシスコの記事「 DCBおよびFCoEプロトコルに基づくLANおよびSANデータセンターネットワークの統合 」を読んで質問することをお勧めします 。

コンバージド拡張イーサネット

FC伝送用のイーサネットが最終決定された（2008〜2011）ことに注意する必要がありますが、ここではTRILLは適用されません。 FCoEを実装するために、次のようなFCのバッファー間ローンをシミュレートするメカニズムが開発されました：Priority Flow Control 802.1Qbb（Draft 2008、Standard 2011）、Bandwidth Management 802.1Qaz（Draft 2008、Standard 2011）およびCongestion Management（帯域幅の予約、ドロップの欠如）802.1Qau（ドラフト2006、スタンダード2010）。 FCoEは、Ciscoスイッチで初めて登場しました。

FCのスピードの見通し

2014年時点のFC 8は、 FCとFCoEの間で最も人気があります。

2011年から利用可能なFC 16は、2014年に広く流通し始めました。

FC 32、リリースプロジェクトは2016年に予定されています（予測）。

FC 128、リリースプロジェクトは2016年に予定されています（予測）。

純粋なブロックストレージ

すべての「純粋なブロックストレージ 」がファイルゲートウェイを取得します。 当時のストレージシステムの大手メーカーの元ヘッドの有名なフレーズ「Real deal FC 」（2008年）は、 FC データセンターネットワークが最良の選択であることを強調しました。 ただし、IBMはSONAS（2010）を開発しており、日立はファイルアクセスを提供するためにBlueArc（2011）を購入しています。EMCとHPはWindowsサーバーを使用してSMBおよびLinux for NFSを介してアクセスを提供します 。 上記のすべては、 iSCSIを使用する機能も提供します。

このさまざまなオプションでは、基本的にイーサネットが使用されます。

イーサネット上のファイルプロトコル

1997年、OracleとNetAppは、 NASストレージにあるデータベースのソリューションをリリースしました。 イーサネットを使用するファイルプロトコルは、負荷の高いミッションクリティカルなアプリケーションで使用されます。 ファイルプロトコルの進化により、以前はブロックFCのみを使用していたアプリケーションでイーサネットが使用されるようになりました。 2004年、オラクルはNetApp FASストレージを使用したOracle On-Demand Austin（USA）Data Centerを立ち上げました。



マイクロソフトは、 SMB 3.0プロトコルの新しいバージョン（2012）を開発しました。現在、仮想化、 データベースなどの重要なアプリケーションは、ネットワークフォルダーに配置できます。 多くのストレージベンダーは 、このプロトコルの将来のサポートをすぐに発表します。 2013年、NetAppは、Microsoftと協力して、 SMB 3.0でHyper-Vを、 SMB 3.0でMS SQLを起動しました。

NFSネットワークフォルダー内のデータベースファイルを見つけるために、新しいdNFS機能がOracle 11g（2007） データベースに追加されました。

NFS v4.0（2003）-プロトコルは名前空間のパラダイムを変更します。 サーバーは、複数のファイルシステムをエクスポートする代わりに、多くの実際のファイルシステムから組み立てられた1つの擬似ファイルシステムをエクスポートし、重要なこととして、 データセンターネットワークに新しい高可用性機能を提供します。 したがって、データは単一の専用サーバーによって検索および提供されながら、グローバルな名前空間を維持できます。 これは、クラスターシステムの構築と非常に密接に相互接続されており、その実装を大幅に簡素化します。

NFS v4.1、 pNFS- （2010）パラレルNFSでは、クライアントは再インストールせずに「最近接」リンクを介してファイルにアクセスできます。 2012年、NetAppとRedHatは、Clustered OntapおよびRHEL 6.2のpNFSをサポートするためのコラボレーションを発表しました。

IP上で実行されるプロトコルの利点は、そのようなネットワークのブロードキャストドメインを分割するルーティング機能に起因する場合もあります。 SMB 3.0およびNFS 4.0プロトコルについては、 WANでの作業の最適化がアーキテクチャ的に構築されました。

コンバージドデバイス

2009年のCisco Nexusシリーズなどの統合ネットワークスイッチの発売により、従来のFC SANネットワークとイーサネットネットワークを統合できるようになり、IT部門はビジネスニーズの変化に柔軟に対応できるようになりました。 NetAppは初めて、統合ネットワークと複数の単線プロトコルのサポートを開始します（2010）。 当初、 FCoE伝送は光学系とTwinaxケーブルを介してのみサポートされていました。

オンボード10Gbアダプターは2012年に銅製ポート付きで登場します。

2013年に続き、 SFP +コネクタを備えた第2世代のオンボードCNA 2アダプタが登場し、イーサネットとFC 8 / FC 16の両方に使用できます。



CNAアダプターのリリースにより、 データセンターネットワークでFCoEとイーサネットを使用できるようになり、両方の利点を最大限に活用できるようになり、さまざまな問題を解決するために最適なプロトコルを使用できるようになります。

NetApp ストレージシステムでのCNA 2アダプターの普及（2014年）の開始により、 FCoEとイーサネットまたは「クリーン」 FC 8 / FC 16を同時に使用できるようになりました。 1GbEのみ。 CNAアダプターと共に、たとえばNetApp EシリーズストレージシステムでFC /イーサネットロボットモードを切り替えることができる収束型SFP +トランシーバーが表示されます。

イーサネット上のオブジェクトストレージ

オブジェクトストレージはますます人気を集めており、2013年にSeagateはイーサネットインターフェイスを備えたキネティックオブジェクトハードドライブを発売します。 そして2014年、HGSTはOpen Ethernetハードドライブをリリースしました。 NetAppは2010年にStorageGRID （以前のBycast Inc.の製品）を購入しました。これは2001年のオブジェクトストレージの最初のインストールです。

スケーリングとクラスタリング

NASクラスタリングの主要なソリューションの1つはSpinnaker Networksでした。これはStart Upとして開始され、2003年にNetAppに買収されました。その開発は、NetApp FAS ストレージシステム用の最新のClustered Ontap OSの基礎となりました。

FCブロックアクセスを提供する最大のストレージクラスターは、NetApp FAS 6200/8000の8ノードに到達しますが、競合他社は通常4ノード以下です。 ファイルプロトコルの場合、ノードの数は何倍も大きくなることがあります-NetApp（2013） FAS 6200/8000（ SMB 、 NFS ）の場合は24ノード。 また、オブジェクトストレージの場合、ノードの数は理論的には無制限です。 必要に応じて拡張できる比較的高価なクラスターノードが現代の世界では、1台の高価なスーパーコンピューターが使用される「メインフレームアプローチ」とは対照的に、より好ましい選択肢になります。



多くの場合、 LUNの最大サイズは多くのことを望まれます。16TBに達し、ホスト側とストレージ側の両方でLUNの数に制限があります 。 クラスター化されたストレージシステムでは、このしきい値は消えていません。多くの場合、松葉杖ソリューションを使用して、ホスト上のソフトウェアレベルで複数のLUNを組み合わせてより大きなボリュームを取得します。 ファイルボールはパタバイトを占有し、数ペタバイトの巨大な論理ネットワークフォルダーを取得するために簡単にスケーリングできます。NetAppFAS ストレージシステムでは、 SMBおよびNFSプロトコル経由でアクセスするInfinite Volumeテクノロジーを使用してこれを実現します。

ThinProvitioning＆Snapsots

最初のスナップショットテクノロジーは、1993年にNetAppによって開発および実装され、シンプロビジョニングテクノロジーは2001年に最初に導入され、2003年に3Par ストレージに、2004年にNetApp FASに次いで導入されました。 SMB 、 NFS 、 FCを使用したイーサネットへの接続にもかかわらず、使いやすさの点で、「ファイル」および「ブロック」プロトコルとの「ジャンクション」でのシンプロビジョニングとスナップショットは互いに大きく異なります。

そのため、たとえば、「シン」 LUNを使用し、同時にストレージシステム上の場所が「 なくなる 」場合、すべての適切なストレージシステムはそのようなLUNをオフラインにするため、アプリケーションはそこに書き込みを試みず、データを損ないません。 スナップショットが現在のファイルシステムのスペース全体を「使い果たし」、シンLUNにデータ自体のスペースを残さない場合にも、同様の状況が発生します。 また、「シン」 LUNの不快な機能は、常に「成長」することでした。LUNの 「上」にあるファイルシステムレベルでデータが削除されても、このLUNのストレージはそれについて何も知りません。

同時に、ファイル共有のために、「設計による」という細かい計画が用意されており、スペースの終わりがネットワークフォルダーをオフラインに変換することはありません。

機能借入

そのため、Windows 2012では、RedHat Enterprise Linux 6.2（2011）およびVMWare 5.0（2011）は、 SCSI SBC -3標準（多くの場合SCSIシンプロビジョニングと呼ばれる）で定義された論理ブロックプロビジョニング機能を実行できます。実際には「薄く」、その上の場所は「実際に終了」し、記録操作を禁止します。 したがって、OSはそのようなLUNへの書き込みを停止する必要があり、オフラインに切り替えられず、読み取り専用のままになります（別の質問は、アプリケーションがこれにどのように応答するかです）。 また、この機能により、スペース再利用を使用できるようになり、実際のデータを削除した後、 LUNを減らすことができます 。 したがって、 LUNは現在、ファインプランニングモードでより適切に機能しています。 したがって、8年後、Thin Provisioning Awarenessはストレージ （2003）からホスト（2011）に移行しました。

クラスター化されたホストソリューションについては、ネットワークフォルダーとは異なり、1つのホストのみが1つのLUNで長時間動作（読み取りおよび書き込み）できました。 他のすべてのホストは、このLUNのみを読み取ることができました。 しかし、ここでも、しばらくしてブロックレベルまたはリージョンレベルのロックメカニズムが決定されました。LUNを論理セクションに分割し、複数のホストに「自分の」セクションのみに書き込む機能を提供できます。 ネットワークフォルダーの場合、この機能はプロトコル設計に組み込まれており、当初から存在しています。

一方、ネットワークフォルダーにはマルチパスと同様の機能はありません。これにより、ファイルを要求するクライアントは、いくつかの方法または最短パスでファイルにアクセスできます。 これは常にファイルプロトコルに欠けていたため、 pNFSが登場しました。この欠陥の一部はLACPでカバーされ、 vPCテクノロジーを使用して複数のスイッチ間でトラフィックのバランスを取ることができました。

おわりに

どうやら、機能がさらに借用され、プロトコルがまとめられます。 収束は、上記のイベントを考慮すると、避けられない未来と見なされます。 これにより、2つのプロトコルは、 データセンターネットワークのアプリケーション領域でさらに厳しい戦いを強いられます。 ブロックFCプロトコルを介してアクセスするクラスターストレージシステムの実装には、より複雑なアーキテクチャ、 LUNのサイズとその数に関する技術的な制限があります 。これは、増え続けるデータとクラスタリングパラダイムの現代の世界でこのプロトコルの将来の開発に関与せず、この方向でのさらなる開発が必要です。 また、イーサネットの速度はFCをはるかに上回っており、 FCの将来に影響を与える可能性があります。したがって、 FCはイーサネット内を移動し、 FCoEの形でそこにとどまるという仮定があります。 実際、差は8年です。つまり、2016年には100Gb 2008と128Gb です。FCとFCoEを選択する場合は、この記事に注意してください。



ここでは、IP over FCやその他のさまざまなプロトコルの組み合わせなどの一般的なオプションではなく、 データセンターのインフラストラクチャ設計で最も頻繁に使用されるプロトコルの組み合わせのみを考慮し、将来のトレンドを形成することに注意してください。



テキストのエラーに関するメッセージをLANに送ってください。

反対にコメントと追加はコメントしてください