分析SAN とは何ですか？NVMe over Fabrics (NVMeF) アレイは SAN ですか？ Datrium は SAN ではないと言っています。E8 は… 多分そうだと思います。
Wikipedia によると、ストレージ エリア ネットワーク (SAN) とは、「統合されたブロック レベルのデータ ストレージへのアクセスを提供するネットワークです。SAN はファイルの抽象化は提供せず、ブロック レベルの操作のみを提供します。ただし、SAN 上に構築されたファイル システムはファイル レベルのアクセスを提供し、共有ディスク ファイル システムとして知られています。」
Techopedia によると、「ストレージエリアネットワーク (SAN) は、統合されたブロックレベルのストレージへのアクセスを提供する、安全な高速データ転送ネットワークです。SAN により、ストレージデバイスのネットワークが複数のサーバーからアクセス可能になります。」
かなり単純なように思えますが、NVMeF アレイに影響する問題があります。
Techterms では、「SAN は複数のコンピュータからアクセスできるストレージデバイスのネットワークです。ネットワーク上の各コンピュータは、SAN 内のハードドライブに、コンピュータに直接接続されたローカルディスクのようにアクセスできます。」と説明されています。
これにより、個々のハードドライブを複数のコンピューターで使用できるようになり、異なるマシン間で情報を簡単に共有できるようになります。
Datriumにとって、これが決定的な点です。共同創業者兼CTOのヒューゴ・パターソン氏は、シリコンバレーのプレスツアーグループに対し、「共有シャーシ内のNVMeは内蔵ドライブのように見えます。つまり、共有データではありません。SANでもありません。その上でVMFS（VMwareファイルシステム）を実行することはできません」と述べました。
ダトリウムCTOヒューゴ・パターソン
SANユーザーはストレージシャーシだけでなく、データやドライブも共有できると言っている。しかし、NVMeFアレイユーザーはデータもドライブも共有できない。なぜだろう？
このアイデアは、コンピュータ、クライアントデバイス、またはサーバーにローカルドライブを持つことから始まります。ローカルドライブはホストにローカルでプライベートであり、他のコンピュータからはアクセスできません。NVMeドライバを介してアドレス指定されるPCIe接続のSSDがこれに該当します。
NVMeFでは、ホストサーバーからNVMeFアレイ内のドライブへのリモートダイレクトメモリアクセスが行われます。ホストサーバーは別のローカルドライブを認識し、そのドライブをホストサーバーに割り当て、マッピングします。他のサーバーはそのドライブにアクセスできないため、そのドライブ（複数可）上のデータにアクセスすることはできません。
では、ドライブを抽象化して、何らかのドライブ/ボリュームマネージャを追加しましょう。どこに追加しますか？アレイコントローラで追加します。アレイコントローラはすべてのドライブを認識し、すべてのIO要求を受け取ります。しかし、これを行うとエンドツーエンドのNVMeFが機能しなくなり、レイテンシが増加し、IO操作が長くなります。つまり、「NVMeFとローカルドライブのアクセス速度は等しい」という考え方が崩れ、Datriumのスライドに示されているように、コントローラのボトルネックが発生します。
NVMeF を介してアレイのドライブにホスト サーバーが直接アクセスできる場合、アレイは実質的にコントローラーレスとなり、Datrium のスライドに示されているように、単なるフラッシュ ドライブの束 (JBOF) になります。
DatriumはNVMeドライブをサポートしていますが、NVMeFアレイを製品ラインに組み込んでいません。検討中です。同社によると、アレイ内のNVMeFではホスト・アレイ間のネットワーク遅延の問題を解決できないとのことです。
E8の視点
DatriumにはNVMeFアレイがありません。Startup E8には、デュアルポートNVMeF JBOD（6.4TB SSD x 24）があります。NVMeFアレイやJBOFがSANであるかどうかについて、E8はどうお考えですか？
創業者兼CEOのZivan Ori氏は次のように述べています。「SAN？それはファイバーチャネルやSCSIと関連しています。私はNVMeFと呼びたいと思います。これはSANの代替、あるいは次世代SANです。SANと呼ぶと少し混乱するかもしれません。」
オリ氏は、デュアルコントローラアレイは、RDMAリンクを直接駆動するサーバーがなければ、NVMeFのメリットを享受できないと考えています。もしそうでない場合、RDMAパスを離れてアレイコントローラスタックを使用する必要があり、その手間の分だけレイテンシが増加します。オリ氏は、これはPureが今後取り組むべき課題だと考えています。
E8のお客様がE8 JBOFでデータを共有したい場合はどうなるでしょうか？ クラスター化されたファイルシステムが一つの解決策となり、彼はSAS統計分析アプリケーションを実行しているデータウェアハウスのお客様の事例を紹介しました。E8のシステムがインストールされる前は、SASアプリケーションはローカルNVMe SSDを搭載したサーバーで実行されていました。
その後、XFS の代わりに GPFS (IBM の Spectrum Scale 並列ファイルシステムソフトウェア) が使用され、SAS ノードは E8 共有 NVMe ストレージへの IO アクセスを並列化しました。
コントローラーレベルのインテリジェンスの分散
E8 のシステムでは、以下のスライドの左下の図に示すように、アクセスする各サーバーにエージェントが存在します。
興味深いことに、Datriumも同様のコンセプトを採用しています。アレイ内のコントローラーロジックを、アクセスサーバーの上流に分散配置しています。NVMe JBOF環境でストレージアレイコントローラーのような機能を提供するには、アクセスサーバーロジックが必要であるとDatriumは考えています。
上記の Datrium スライドの最後のポイントは、「より多くのことを行うには、サーバーベースのデータ管理が必要です。」です。
つまり、従来はアレイ コントローラによって実行されていたボリューム管理タイプの機能は、NVMeF IO 要求がサーバーによって開始される前に、アクセスするサーバーで何らかの方法で実行する必要があると考えられます。
さらに、NVMeF JBOF にアクセスするサーバーが複数ある場合、データ アクセスを調整できるように、このボリューム管理機能をアクセスするサーバー間で分散する必要があると思われます。
プレスツアーでNVMeF JBOFがデータ共有SANではない理由を7枚のスライドで説明したDatrium社は、おそらくこの問題を解決する技術を開発中だろうと思われます。そうでなければ、なぜ7枚のスライドを使って、なぜ現時点で開発されていないのかを長々と説明するのでしょうか？®
