大規模な低コストストレージを実現するNVMe-oF™ ネットワーク内のEthernet Bunch of Flash
NVMe over Fabrics（NVMe-oFTM）は、データセンター内のコンピューティングとストレージの分離を可能にする先端技術です。マイクロンは、Marvell、Foxconn-Ingrasys、NVIDIAなどの主要なテクノロジーパートナーと連携して、NVMe-oFの強みを最大限に発揮させる取り組みを行っています。さらに、NVMe-oFを用いて大規模なフラッシュストレージへのアクセスを最適化する不均質性メモリストレージエンジン（HSE）など、新テクノロジーの導入も行っています。
NVMe-oFとは
NVMe-oFは、文字どおり、NVMeプロトコルをネットワークに拡張するもので、現在SSDを制限しているサーバーシャーシを超えて到達範囲を拡大します。NVMeは2011年から存在していますが、ファブリック拡張は2016年に初めて標準化されました。NVMe-oFはNVMeを活用するため、軽量で効率性の高いコマンドセット、マルチコア認識、プロトコル並列処理など、すべてのメリットを引き継いでいます。NVMe-oFは、Fibre Channel、InfiniBand、Ethernetなどの一般的なファブリックをすべてサポートしているため、ネットワークにまったく依存しません。図1 NVMeとNVMe-oFモデルの比較。さらに、ユーザーが利用できるさまざまなネットワークやネットワークトランスポート。
図1：NVMeとNVMe-oFモデルの比較
RoCE v2とNVMe-TCPという、関連するEthernetトランスポートが2つあります。それぞれに強みと弱みがあります。RoCE v2は低レイテンシーですが、専用のRDMA対応NIC（RNIC）が必要です。NVMe-TCPトランスポートは高レイテンシーで、CPU使用量も大きいですが、専用のRNICは不要です。その代わりに、標準的なNICを使用します。現在、RoCE v2の方が市場に普及しています。
NVMe over Fabricsのメリット
NVMeだけの場合は、基本的に、拡張方法として採用できるのはPCIeスイッチを用いるサーバーシャーシまたはラックに制限されます。これはストレージを拡張するのに十分に有効な方法ですが、範囲と到達範囲が限られているともいえます。NVMe-oFを利用する場合、事実上、データセンター全体にわたって無制限にストレージを接続できます。
現在、NVMe-oFは定着しています。多くのユーザーがこのテクノロジーを採用して、オールフラッシュアレイ（AFA）をサーバーに接続しています。ただし、NVMe-oFのメリットをすべて実現するには、コンピューティングとストレージを完全に分離する必要があります。コンピューティングとストレージの両方を必要に応じてプロビジョニングできるように、NVMe SSDのプールがネットワークを介してサーバーのプールに提供されるようにします。図2に示すように、分散化によりストレージの拡張性と共有性が向上し、構成可能性が実現します。
図2：コンピューティングとストレージの分離
分散ストレージで考慮すべきもう1つの側面がストレージサービス（データ保護、複製、圧縮など）です。ストレージサービスは、サーバーで管理することも（オンロードモデル）、実際のストレージに近いデータ処理ユニット（DPU）にオフロードすることもできます。トレードオフが必要です。オンロードモデルは消費するCPUサイクルとネットワーク帯域幅が増えますが、コストを最小限に抑えることが可能です。その一方で、オフロードモデルはコストが増加しますが、プロビジョニングによってはボトルネックが生じる可能性があります。大規模で低コストなストレージを追求していくと、TCO（総所有コスト）のメリットから、オンロードアタッチドストレージ戦略に辿り着きます。
EBOF、JBOF、JBODとは
「Bunch of Flash」をNVMe-oFネットワークに接続するには、Ethernet Bunch of Flash（EBOF）を使用する方法と、Just a Bunch of Flash（JBOF）を使用する方法があります。JBOFとJBOD（Just a Bunch of Disks）を混同しないように注意してください。JBODは通常、NVMe over PCIeを使用してラックのストレージを拡張する目的で使用されます。EBOFとJBOFは、NVMe-oFを使用してデータセンター全体にストレージを拡張する目的で使用されます。図3に示すように、JBOFはPCIeスイッチを使用してSSDにファンアウトしますが、EBOFはEthernetスイッチを使用してSSDにファンアウトします。JBOFとEBOFはどちらもNVMe-oFを使用してサーバーに接続します。
図3：NVMe-oFネットワークに関するEBOFとJBOFの比較
2つのアプローチには、EthernetスイッチとPCIeスイッチという分かりやすい違い以外にも、NVMeからNVMe-oFへの変換が行われる場所が異なります。JBOFの場合、変換またはブリッジは1つ以上のDPU（DPUとSSDの数は1対1）を用いたシェルフの周辺で行われます。EBOFの場合、ブリッジはSSDキャリアまたはエンクロージャで実行されます（ブリッジとSSDの数は1対1）。JBOFには、ストレージサービスの実行にDPUの処理能力を活用するというメリットがありますが、ボトルネックが生じる可能性があったり、EBOFモデルよりもコストや電力消費量が高くなったりというデメリットがあります。ブリッジとSSDが1対1ではない場合、コストのトレードオフとボトルネックが発生します。
私たちは、Marvell 88SN2400とFoxconn-Ingrasys EBOFを使用してテストを行っています。
マイクロンは、MarvellとFoxconn-Ingrasysとの連携を通じて、さまざまなアプリケーションとワークロードのNVMe-oF環境でMicron 7300メインストリームNVMe SSDをテストしてきました。
このテストについてご説明する前に、Foxconn-Ingrasys EBOFについてと、Marvellの88SN2400コンバートコントローラとPrestera® CX 8500スイッチについてご紹介します。
Marvellの88SN2400は、クラウドとエンタープライズのデータセンター向けのNVMe-oF SSDコンバーターコントローラです。これをMarvellのスイッチと組み合わせることで、NVMeとNVMe-oF間の変換または「ブリッジ」が可能になります。88SN2400コンバーターコントローラはFoxconn-Ingrasys EBOFの重要なコンポーネントであり、Micron 7300 SSDと組み合わせることで、優れた高性能2Uストレージシェルフ（最大73.1GB/秒の帯域幅、最大2,000万のIOP）が生まれます。図4は、2Uエンクロージャに24個のU.2スロットを備えたFoxconn-Ingrasys EBOFについて示した図です。
図4：Foxconn-Ingrasys EBOF
図5は、Marvell 88SN2400コンバーターコントローラを搭載したFoxconn-Ingrasys SSDキャリアについて示した図です。
図5：88SN2400コンバーターコントローラを備えたFoxconn-Ingrasys U.2キャリア
Foxconn-Ingrasys U.2キャリアは標準的なU.2 SSDフォームファクターを採用しています。U.2キャリアは、パスの冗長性を必要とするアプリケーションに対応するために、デュアルEthernetポートをサポートしています。また、NVMe SSDのドライブ側には単一のPCIe Gen3 x4を備えています。
Marvellの88SN2400コンバーターコントローラは、RoCE v2とNVMe-TCPトランスポートの両方をサポートしています。ただし、私たちが行ったテストはRoCE v2を重視しました。
NVIDIA GPUDirect Storage（GDS）での拡張について
マイクロンはNVIDIA GPUDirect Storage（GDS）を用いて、人工知能と機械学習ワークロードのさまざまな作業でSSDを活用してきました。私たちは、Marvellの88SN2400コンバーターコントローラを搭載したFoxconn-Ingrasys EBOFをNVIDIA DGX™ A100システムに接続して、ファブリック環境での拡張について知りたいと考えました。これは、NVMe-oF環境でGDSを使用する場合と使用しない場合の両方で帯域幅とレイテンシーを比較する、シンプルなGDSIO（GPUDirect Storage I/O）ツールテストです。
図6：EBOFを搭載したDGX™ A100
図6では、8つのコンピューティングネットワークポートのうち6つを使用して、NVIDIA DGX™ A100に直接接続されたMicron 7300 SSDを搭載したEBOFが掲載されていますが、600 GB/秒のネットワーク帯域幅が利用できます。GDSを有効にすることで、GDSの無効時に使われる高レイテンシーのバウンスバッファをスキップして、ピア間で直接データを移転できるようになります。このテストでは、ワークロードに対してSSDの性能を結集し（約61GB/秒）、最大限に引き出しています。今後のテストでは、Ethernetスイッチを追加し、EBOFの数をさらに増やす予定です。
このテストの詳細については、FMS2020のAIトラックで確認できます。ウェス・バスク（ストレージソリューション主幹エンジニア）によるプレゼンテーション「AIワークロードに与えるストレージの影響の分析」をご確認ください。
NVMe-oFがHSEによって拡張を実現する仕組み
マイクロンでは、いくつかの魅力的なテクノロジーに取り組んでいますが、その1つが不均質性メモリストレージエンジン（HSE）です。HSEは、ストレージクラスメモリ（SCM）とSSDのパフォーマンスを向上させるフラッシュ向けストレージエンジンです。また、すべてを大規模に展開しながら、書き込み増幅が減るため、SSDの寿命も延びます。NVMe-oFの採用は、HSEを用いてさらに拡張するための理想的な方法です。ファブリックアタッチドストレージにおけるHSEの効果を検証するため、MongoDBとYCSB（Yahoo! Cloud Serving Benchmark）を用いて複数のテストを実施しました。図7では、ローカルのMicron 7300 SSDを用いたデフォルトの内蔵MongoDBストレージエンジン（WiredTiger）と、EBOFでMicron 7300 SSDを用いたマイクロンのHSEとの比較です。
図7：WiredTigerとHSEの比較
MongoDBとローカルSSDを用いた従来のWiredTigerストレージエンジンと比較すると、ファブリック環境でのHSEの方が劇的な効果が見られます。私たちは、ストレージの拡張性を高めると同時に、1秒あたりのYCSBの動作を最大5倍改善し、レイテンシーを42%削減することに成功しました。
このテストの詳細については、FMS 2020でのプレゼンテーションで確認できます。スジット・ソマンデパリ（ストレージソリューション主幹エンジニア）によるプレゼンテーション「NVMe over Fabricsによるストレージの拡張」をご確認ください。
NVMe-oFの今後の展望
NVMe-oFは、最終的にはデータセンターの全面的な分散を実現するテクノロジーです。データセンターの全面的な分散が実現すれば、アプリケーションを構成し、コストパフォーマンスに優れる方法で適切な量のコンピューティングとストレージを動的にプロビジョニングすることが可能になります。
現在、NVMe SSDをEBOFやJBOFと接続してブリッジする場合、低コストのブリッジまたはDPUベースのプラットフォームが使用されています。将来的には、ネイティブNVMe-oF SSDがTCOを減らし、パフォーマンスを向上させることが予想されます。
マイクロンは、NVMe-oFアプリケーション向けに最適化された能力と機能を備えた次世代のデータセンターSSDを設計しています。