キーポイント

• ONTAPは、LUNとボリュームを使って構築された物理的なワークロード向けのもので、データファブリックには適していない
• SolidFireでも同じアーキテクチャーが使用されているため、VM単位でサービス品質を設定することができない
• 最先端のデータセンターを構築するためには、新たな方法を採用したスケーリングと自動化のソリューションが必要

2016年9月末、毎年恒例のNetApp Insightイベントが開催され、NetAppがデータファブリックに関する大々的なビジョンを発表しました。このビジョンは理解に値するものの、基盤となるコンポーネントに関しては不安が残る内容でした。ONTAPは全くの時代遅れであるうえ、SolidFireはNetAppと同じくLUNとボリュームで構成されており、単純にどちらも最先端のデータセンターには適していません。まるで70年代に流行ったポリエステル生地（ファブリック）のシャツのようです。ファブリックに汗だくになるほど無駄な労力をかけたくないのであれば、以下の点について考えてみてください。

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

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

そのためTintriは、これとは異なるアプローチでスケールアウトアーキテクチャーを開発し、2016年5月にリリースしました。そのアプローチは型破りだと形容されますが、それこそが重要なポイントです。企業では必要に応じて容量やパフォーマンスを追加する必要があるため、TintriはオールフラッシュとハイブリッドのVMstoreから構成される単一かつ疎結合のフェデレーションされたプールをスケールアウトできるようにしました。しくみはコンピューティングをスケーリングする場合と同じで、新しいVMstoreを追加すると、フットプリント全体の各VMの最適な配置がTintri VMスケールアウトによって自動的に提案されます。

このようなアプローチが可能なのは、ファイルシステムが根本的に異なるからです。Tintri by DDNでは、最先端のデータセンターにおいて一般的なVM（まもなくコンテナーも）のみを利用します。詳細なTOSにより、レプリケーション、クローニング、スナップショット作成、QoS、分析など、あらゆる操作をVM単位で実行することができます。

NetAppとの違いは、最も基本的なストレージタスクにおいても明らかです。NetAppで使用可能なパフォーマンスを評価するには、数時間（または数日）かけて10もの手順を踏む必要があります。一方、Tintriの場合はこの情報がダッシュボードに表示されるので、推測をしたり、無駄な時間がかかることはありません。なぜならTintriのファイルシステムは、仮想化やクラウドと同じユニットを利用するからです。

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

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

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

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

TintriのVASファイルシステムなら、任意のVM用にQoSポリシーを作成できるほか、VMのグループ用にポリシーを設定し、新たに追加したVMが同じプロパティを共有する場合に、そのポリシーを自動的に適用することができます。そのため、VMの数が500台の時点で設定したポリシーは、5万台を突破しても有効です。そのうえ、Tintriは100万台のVMでも管理することができます。それは、SolidFireを含むNetAppのポートフォリオでは不可能なことです。

Tintriはこのようなメリットをお約束しますが、実際のお客様の声をお伝えした方がもっと皆様のご参考になるかと思います。そこで私たちは、お客様にNetAppのLUNとボリュームで運用する場合とVMに最適化されたTintriのストレージで運用する場合の違いについて尋ねてみました。お話を伺ったお客様の中には、TintriとNetAppをサイドバイサイドで実行しているお客様や、すべての仮想化ワークロードをNetAppからTintriに移行したお客様がいます。以下は、こうしたお客様からいただいた声の一部です。

「誤解を恐れずに言えば、これまでNetAppに満足していました。ところが、Tintriに移行してみると状況は一変しました。ライセンス形態は非常にわかりやすく、パフォーマンスも期待以上です。アップグレードはずっとスムーズになり、パフォーマンスの測定も驚くほど簡単です。Tintri VMstoresに移行して本当に良かったです！」

ファーマン大学、システム管理者、Cathy Frazier氏

「Data ONTAPからTintriへの移行はすばやく簡単だったうえ、移行によって多くのメリットを得ることができました。パフォーマンスと容量がすぐに向上したほか、かつてLUNとボリュームのサイズを変更するのにかかっていた無駄な管理作業が不要になりました。」

CMC、IT責任者、Geoff Grice氏

「ついに解放されました！」

VMware、シニア エンジニア、Brian Sweeney氏

「Tintriと比べると、最新と言われているNetAppのシステムはまだまだ古いです。」

C3 Group、ITマネージャー、Matt Crape氏

「NetAppを使っていたころは、ディスク使用率が100%になったままで遅延がひどく、仕事を切り上げるしかないこともありました。同じVMをTintriに移行してからは、遅延はまったく発生していません。」

Life-Science Innovations、システム管理者、Tim Starkenburg氏