NetApp Data Fabric所感

·ONTAPは、LUNとボリュームを使って構築された物理的なワークロード向けのもので、データ ファブリックには適していない

·SolidFireでも同じアーキテクチャーが使用されているため、VM単位でサービス品質を設定することができない

·最先端のデータセンターを構築するためには、新たな方法を採用したスケーリングと自動化のソリューションが必要

2016年9月末、毎年恒例のNetApp Insightイベントが開催され、NetAppがデータ ファブリックに関する大々的なビジョンを発表ています。このビジョンは理解に値するものの、基盤となるコンポーネントに関しては不安が残る内容でした。ONTAPは全くの時代遅れであるうえ、SolidFireはNetAppと同じくLUNとボリュームで構成されており、単純にどちらも最先端のデータセンターには適していないのではないか?

1.ONTAP: データ ファブリックは主にONTAPから構成されています。しかし多くの方が既にお気づきのとおり、ONTAPは使い勝手が良いとは言えません。

Clustered ONTAPの当初のコンセプトは、データセンターの拡張やフットプリント内のデータ移動を容易にすることでした。しかし、フットプリント内でデータを移動する場合、ボリューム全体は移動せずに、仮想マシン(VM)を移動できるようにする必要があります。ストレージを拡張するためにLUNとボリュームを拡張することが必要なようでは、データ ファブリックの意味がありません。

2.SolidFire: ONTAPは古いテクノロジを再び流行らせようという試みに見えますが、一方のSolidFireは、NetAppのコレクションの中では比較的画期的な製品です。それゆえInsightでも大々的に取り上げられ、データ ファブリックのビジョンの一部と位置付けられていました。

では、SolidFireはNetAppと比べて最先端のデータセンターにどのくらい適しているのでしょうか?SolidFireのあるCTOメンバーは先日、以下のような記事を書いています。「現在NetAppはすべてのVVOL開発をSolidFireプラットフォームで行っています。なぜなら、VMwareのお客様がNFSだけで十分でVVOLを必要としていないからではなく、アーキテクチャーをとても重視しているからです」。

これはたいへん皮肉な話です。アーキテクチャーを重視していると言いますが、SolidFireはNetAppと同様にLUNとボリュームをベースに構築されています。LUNやボリュームは最先端のデータセンターで利用されているユニットではないため、容量、パフォーマンス、人材を効率的に使用することはできません。実際、SolidFire独自のメタデータに関する問題により、ドライブは2 TBに制限されています(現在のストレージ デバイスの多くが4TBまたは8TBドライブを使用しています)。

そして、アーキテクチャーに関する欠点は、SolidFireの長年のセールス ポイントであるサービス品質(QoS)にも見ることができます。SolidFireでQoSを設定できるのはLUNのみで、LUN上のすべてのVMに同じポリシーが適用されます。また、QoSを自動化するためには、vSphere Enterprise Plusが必要です。SolidFireは基本的にQoSの自動化に対応しておらず、vSphereの管理者やストレージ管理者が値を決める必要があります。しかし、vSphereの管理者もストレージ管理者も、そのLUNに適切な値を本当に理解しているでしょうか?ノイジー ネイバー(うるさい隣人)の問題を回避するために、仮想環境用のストレージはもっとスマートである必要があります。

RAIDレベルも、RAID4を延長にWAFLファイルシステムとの整合性、相性が良い技術を先駆的に採用してきた同社ですが、オールフラッシュの時代では、フラッシュとの相性はいまいちとされています。VIF、MultiStoreといった主要な技術は非常に魅力的で、NAS(NFS, CIFS)は長年の歴史に裏打ちされた実装となっていると思いますが、過去のHDDをベースに、ONTAPのカーネルに多くの機能実装を行ってきた結果、非常に複雑で運用管理性が損なわれている状況に至っていると感じています。