特別企画

スケールアウト、フラッシュ技術、ビッグデータに注力するNetApp

 もう忘れ去りそうな勢いで時間が経過してしまったが、2012年12月6日に東京都内でNetAppの技術者向けカンファレンス「NetApp Innovation 2012 Tokyo」が開催された。当日は午前中の基調講演から午後の主要な技術セッションまでフルタイムで聴講したが、基調講演と技術セッションを横断的に見ていくと、「スケールアウト」「フラッシュ技術」「ビッグデータ」の3つが重要なキーワードであることが分かった。

 そこで今回は、これらのキーワードを切り口としながら、NetAppのストレージ技術が今後どのような方向に進化していくのかを見ていきたい。

NetApp Innovation 2012 Tokyo会場入り口

NetAppのスケールアウト型ソリューション:Clustered Data ONTAP

 1番目のキーワードは「スケールアウト」である。これは、いわゆるスケールアウト型のストレージアーキテクチャを指している。

 スケールアウト型ストレージといえば、これまではEMC IsilonスケールアウトNASやHP 3PARユーティリティ・ストレージのような規模感の大きな製品が中心だったが、近年ではもう少し小ぶりな製品へとすそ野が広がりつつある。例えば、iSCSIでの接続が可能なDell EqualLogic PSシリーズやHP StoreVirtualストレージ(LeftHand OS搭載製品)などが挙げられる。

 また、分散ファイルシステムを採用したものなら、だいたいスケールアウト型と呼べることもあり、オブジェクトストレージ製品、複数の汎用サーバーと専用ソフトウェアを組み合わせたソリューション、さらにはソフトウェア単体で提供されているものさえある。

 そのような中で、NetAppもスケールアウト型に分類されるストレージアーキテクチャを本格的に投入している。それが、Data ONTAP 8世代のCluster-modeである。

 Cluster-modeの詳細については、筆者が2011年に寄稿した記事を参照していただくとして、実はこのCluster-modeという呼び名はすでに過去のものだ。現在は、「Clustered Data ONTAP」と改名され、従来の7-modeが通常のData ONTAP、Cluster-modeがClustered Data ONTAPと呼ばれている。

 これからのデータセンター事情を踏まえると、ストレージコントローラを単体で運用するのではなく、複数のストレージコントローラを横に並べてスケールアウトさせていく形が主流になるとNetApp自身は予測している。だからこそ、Cluster-modeが決して特別なものではないということを伝えるため、あえてClustered Data ONTAPという名称に変更したのだという。

 ただし、技術者の中では7-mode、Cluster-modeという呼び名が浸透しており、しばらくの間は混乱を来すのではなかろうか。実際、イベント会場ではCluster-modeという用語が当たり前のように飛び交っていた。

Clustered Data ONTAPの概要(出典:ネットアップ株式会社、以下同様)。Clustered Data ONTAPは、複数のNetApp FASシステムを束ねてひとつに見せるようなスタイルをとる。ノード間にブロック単位でデータをあまねく分散させるのではなく、あくまでもユーザーの運用ポリシーに従ってボリューム単位でデータを分散させる形がとられる。ノード数に比例してアクセス性能をリニアに伸ばすのではなく、複数のノードに負荷を適切に分散させることでシステム全体の性能を引き出すのが狙いだ。このため、他社が主張するスケールアウト型の仕組みとはかなり毛色が異なる

Clustered Data ONTAPを採用した日本国内の事例を初披露

 Clustered Data ONTAPの導入実績も着実に増やしている。2011年には全世界で200のインストール数にとどまっていたが、2012年12月にはすでに1000を超えている。

 また、これまでなら保守的といわれる日本の顧客がClustered Data ONTAPに対して特に強い関心を寄せているとのこと。実際、2011年のイベントではClustered Data ONTAPの技術概要を伝えるにとどまったが、2012年のイベントではClustered Data ONTAPを採用した国内事例が一般に初めて紹介された。これは大きな一歩といえる。

 技術セッションで紹介された国内事例は、製造系顧客の次世代ストレージ基盤(エンタープライズIT環境)、公共系顧客および製造系顧客のシミュレーション環境向け高性能ファイルサーバー(いずれもテクニカルコンピューティング向け)、サービスプロバイダのメールサービス用ストレージである。

 これらの案件で共通しているのは、ノンストップのオペレーションや予測できない将来のニーズにも柔軟に対応できる、優れたスケーラビリティを求めていることだ。当初は、HPC(High Performance Computing)向けなどの大容量ストレージが主な適用分野だったが、今後はビジネスの成長が著しく、システムの停止が決して許されないクラウド基盤を中心とするエンタープライズITでの需要が急増しそうだ。

Clustered Data ONTAPのインストール数。全世界では1000件を突破しており、そのうち日本での導入実績は4件である。ただし、日本企業からの引き合いがかなり強いらしく、これからの追い上げが期待される。Data ONTAP 8.2では機能追加も予定されていることから、Data ONTAP 8.2の登場を待って導入に踏み切る顧客も出てくるもようだ

Clustered Data ONTAPならではの運用方法を理解することが先決

 Clustered Data ONTAPは、導入にあたって気をつけなければならない点もある。技術セッションでは、株式会社インターネットイニシアティブ(以下、IIJ)によるClustered Data ONTAPの検証結果が報告されたが、やはりユーザー自身がClustered Data ONTAPの運用方法をきちんと理解していることが大切とのこと。

 セッションではかなりハイレベルな技術情報が提供されたが、主要なところではVserver(クラスタ内に構成される仮想的なストレージコンテナ)の設定方法が7-modeのvFiler(マルチテナント構成時に作成される仮想的なファイラー)を作る手順よりも複雑なこと、ノード数によってストレージコントローラ間のHA設定を変えなければならないこと(2ノード時のみHA設定を有効化、4ノード以上はHA設定を無効化)、I/F名の命名規則が7-modeよりも厳格化されていることなどが挙げられた。

 また、IIJの実機検証を通じて800項目以上もの評価が行われたが、その中でも特に興味深かったのがLIFマイグレーション時のダウンタイムだ。LIFは、クラスタ内の任意の物理ポートを動的に割り当てた論理ポートで、クライアントからの接続口として使用される。LIFマイグレーションは、この物理ポートとの対応を切り替える操作にあたる。

 IIJによれば、NFS接続時には約1秒でマイグレーションが完了したが、CIFS接続時にはActive Directoryへの問い合わせがあるために10~15秒を要したとのこと。

 切り替え先のポートで問い合わせ情報がキャッシュされていれば短時間の接続断ですむが、キャッシュされていなければ接続断の時間が延びる。せっかくクラスタを構成しても10秒以上の接続断があってはノンストップオペレーションとは言いがたい。

 セッション会場では、こうした問題を解決する方法のひとつとして、LIFのロードバランス機能を用いてCIFS向けのLIFを2本以上用意するアプローチが提示されていた。

「フラッシュ技術」を高速・不揮発性キャッシュとして活用するNetApp

 2番目のキーワードは「フラッシュ技術」である。エンタープライズ向けのフラッシュ技術は、NAND型フラッシュメモリを搭載した3.5/2.5インチフォームファクタのドライブ(SSD)からスタートし、当初はHDDを置き換える存在として期待されていた。

 しかし、フラッシュメモリには容量単価の高さや書き換え回数の制約など、いくつかの課題もあることから、多くのエンタープライズ環境ではHDDとフラッシュメモリを使い分けるアプローチが現実的な落としどころとなりつつある。NetAppは、そのような使い分けのアプローチを積極的に推し進めるベンダーのひとつだ。

 NetAppは、ストレージコントローラに内蔵するPCI Expressタイプのリード専用キャッシュソリューション「Flash Cache」を広く展開してきた。Flash Cacheは、ローカリティの高いリード処理の高速化に効果を発揮し、エンタープライズIT分野では仮想デスクトップ基盤に見られるユーザーOS環境のブートストームやログインストーム、一斉のウイルスチェックなどによるストレージへの過負荷を抑える目的で採用されている。

 そして、2012年以降は、新たなキャッシュソリューションとして「Flash Pool」にも力を入れている。Flash Poolは、ストレージコントローラもしくはディスクシェルフ内のSSDをHDDに対するリード/ライトキャッシュとして活用する機能である。SSDを利用しているので容量を稼ぎやすく、またライトにも効く点がFlash Poolの大きな特徴だ。

 Flash Poolのキャッシュ領域は、ディスクシェルフ内のSSDをRAID-DP(二重パリティRAID)で束ねることで信頼性を担保している。また、キャッシュ領域を管理するメタデータを不揮発メモリ上に置くことで、障害対応やメンテナンスによってストレージコントローラを一時的に停止させたとしてもキャッシュ内容はクリアされない。これにより、システムの再稼働後に時間をかけてキャッシュを温め直す必要がなく、すぐにも最高のキャッシュ性能が得られる。

ストレージコントローラに内蔵されるFlash Cacheモジュール。外観はPCI Expressタイプの拡張カードそのものである
Flash Poolは、ディスクシェルフ内のSSDによって提供されるリード/ライトキャッシュである。多くのストレージ製品は、SSDを高速ストレージ領域として直接的に利用するが、NetAppはあくまでもHDD領域に対するキャッシュとして活用する

サーバー内蔵型フラッシュをNetApp製品と連携させる『Flash Accel』

 NetAppは、さらなるキャッシュ階層としてサーバー内蔵型フラッシュを活用する「Flash Accel」を2013年内に出荷する予定だ。Flash Accelは、サーバー内蔵型フラッシュをData ONTAPと密接に連携させる専用ソフトウェアである。

 Flash CacheとFlash PoolはNetApp FASシステムの配下にあるので、両者を効率よく管理できるが、サーバー内蔵型フラッシュはサーバーの配下にあるため、そのままではストレージ側のキャッシュ(Flash Cache、Flash Pool)と連携できない。そこで、サーバー側に新たなソフトウェア(Flash Accel)を導入し、サーバー内蔵型フラッシュもNetApp FASシステムのキャッシュ機能とうまく同調させようとしたわけだ。

 Flash Accelは、サーバー内蔵型フラッシュとしてPCI Express接続の拡張カードや単体ドライブ(SSD)をサポートしている。ただし、キャッシュ性能を最大限に引き出す意味でもPCI Expressカードの利用が前提となる。NetAppは、サーバー内蔵型フラッシュの推奨製品としてFusion-ioのioDrive2を挙げている。

 実は、Fusion-io自身もサーバー内蔵型のPCI Expressカードと専用ソフトウェアを組み合わせたストレージ高速化ソリューション「directCache」を提供している。製品の目的だけを見ればFlash Accelと競合するソリューションになるわけだが、両社によればNetApp FASシステムを使う場合にはFlash Accelを、それ以外のストレージシステムを使う場合にdirectCacheを採用してほしいとのこと。まあ、オトナの回答といえようか。

HDDとフラッシュベースのキャッシュ階層を組み合わせたVST

 NetAppは、Flash Cache、Flash Pool、Flash Accelという3つのフラッシュ技術がそろったこともあり、これらのフラッシュ技術を組み合わせたVST(Virtual Storage Tier)を積極的に展開し始めている。VSTは、ワークロードに基づいてデータの優先度をリアルタイムに判断し、HDDとフラッシュメモリにデータを最適配置するストレージ自動階層化のための技術である。

 海外では、オールフラッシュ・データセンターが提唱されるなど、フラッシュ技術に対する注目は日々高まっている。NetAppもそれに呼応するようにVSTを推進しているわけだが、同社はあくまでもフラッシュ技術をキャッシュとして位置付けている。

 一方で、プライマリストレージとして利用可能なオールフラッシュ・ストレージ(PCI Expressタイプではなく従来ながらの筐体タイプ)も次々と登場している。主要なところでは、IBM(旧Texas Memory Systems) RamSanシリーズ、Violin Memoryフラッシュメモリアレイ、Kaminario K2 SSD Storage、Pure Storage FlashArrayなどが挙げられる。

 オールフラッシュを積極的に推進しているストレージベンダーは、総じてスタートアップ企業が中心であり、彼らのビジネスが今後どれくらい成長するかは未知数である。近年では、スタートアップ企業が単独で大きく成長することが難しいご時世なので、Texas Memory SystemsがIBMに買収されたように、これらのスタートアップ企業も大手ベンダーのフラッシュソリューションを支える形で吸収される可能性も考えられる。

 いずれにせよ、フラッシュ技術をメインのストレージ領域として利用する形態は間違いなく増えていく。だからこそ、NetAppもキャッシュ用途にとどまらず、メインのストレージ領域としてもフラッシュ技術をフルに活用していける体制を整えるべきではないか。自社で開発するもよし、魅力あるスタートアップ企業を買収するもよしである。

NetAppが提唱するVST(Virtual Storage Tier)。大容量のHDDとフラッシュ技術に基づく3つのキャッシュ階層を組み合わせることで、アクセス性能とコストパフォーマンスを最大化するのが狙いだ

Hadoop環境に向けたNetAppのトータルソリューション「NOSH」

 3番目のキーワードは「ビッグデータ」である。ビッグデータは、ストレージ業界で流行語大賞がとれそうなほどよく耳にする言葉だが、これまでは言葉ばかりが先行していて、その中身は単なる大容量ストレージだったというケースも多く見受けられた。

 ビッグデータの本質は、膨大なデータを単に保管することではなく、その保管されたデータを徹底的に分析し、その中から企業にとって有用な情報を抽出するところにある。つまり、ビッグデータのソリューションは、コンピューティング、ストレージ、さらにはこれらを接続するネットワークまでを網羅すべきものなのだ。

 最近では、こうしたトータルソリューションが次々と登場するようになり、ビッグデータの世界がようやく軌道に乗り始めたように感じている。

 NetAppも、ストレージベンダーという立ち位置から、ビッグデータに対するソリューションを新たに打ち出している。そのひとつが、Hadoop環境をターゲットにした『NetApp Open Solution for Hadoop(以下、NOSH)』である。

 NOSHは、ネームノードやデータノード向けのストレージにNetApp製品を採用しながら、HadoopディストリビューションとしてClouderaのCDH(Cloudera's Distribution, including Apache Hadoop)を組み合わせている。

 特に日本国内では、ネットアップ株式会社、Cloudera株式会社、新日鉄住金ソリューションズ株式会社が、NOSHに基づく企業向けHadoopソリューションにおける協業を発表しており、日本の顧客を全面的にサポートしていく構えだ。

ネームノードにNetApp FASシステム、データノードにEシリーズを採用

 NOSHは、ネームノード向けにNetApp FASシリーズ、データノード向けにEシリーズを採用している。

 Hadoopは、複数のデータノードにレプリカを持たせることでノード障害によるデータ損失の危険性を低減しているが、ネームサーバー側の不具合によってデータの配置を管理しているメタデータを失ってしまえば意味がない。

 こうしたHadoopの弱点は以前から指摘されてきたが、最新のCDH4.1ではネームノードがアクティブ/スタンバイのHA構成(HDFS HA)となり、単一障害点(SPOF)ではなくなった。そこで、NOSHはネームノードをHA構成とすることに加え、その共有ストレージとしてNetApp FASシステムを採用することにより、エンタープライズ利用に適した信頼性を確保している。

 一方、データノード向けにはEシリーズが採用されている。NOSHでは、リファレンス構成において4台のデータノードに対して1台のEシリーズを割り当てる。また、データノードとの接続には、6Gbps SASやFibre Channelが使用される。

 データノードのストレージワークロードは、その大半がリード処理であり、しかも非常に高いスループットが要求される。既存のNetApp FASシステムでこのようなニーズに応えようとすると、非常に大がかりで高額なシステムになってしまう。そこで、高スループットと高密度に特化した製品ライン「Eシリーズ」が新たに開発されたのだ。

NetApp Open Solution for Hadoop(NOSH)の構成例。NOSHは、HA構成のネームノードにNetApp FASシリーズ、データノードにEシリーズ、HadoopディストリビューションにClouderaのCDH(Cloudera's Distribution, including Apache Hadoop)をそれぞれ採用している

高スループット・高密度に特化して設計されたNetAppのEシリーズ

 Eシリーズのアーキテクチャそのものは、NetAppが一から開発したわけではなく、2011年3月に買収したLSI Corporationの外部ストレージ関連子会社(Engenio)から獲得している。例えば、ミッドレンジ向けとして発売しているNetApp E2600は、買収前の2010年当時にEngenioが発表したEngenio 2600と基本仕様は一緒だ。

 NetApp E2600は、2Uラックモデルで12~24台、4Uラックモデルで60台のHDDを内蔵でき、ディスクシェルフの増設によって180~192台まで拡張が可能である。NOSHの典型的なシステム構成では、このNetApp E2600と4台のデータノードを組み合わせる形がとられている。

 ただし、NetApp E2600だけでは大規模なシステム環境をカバーしきれないことから、NetAppはEngenioのプラットフォームに基づく上位モデルとしてNetApp E5400もラインアップに加えている。NetApp Innovation 2012 Tokyoの会場では、日本で初めてE5400の実機も披露された。

 さて、そんなEシリーズに関して筆者がひとつだけ疑問に思ったのは、ストレージOSとしてData ONTAPを搭載していないことだ。

 NetAppは、Data ONTAPというストレージOSを中核としながら成長を遂げてきた企業だ。同社は、ストレージシステムを構成するハードウェア部分を「もはやコモディティなのでどうでもいい」とまで言い切っている。また、上位モデルから下位モデルまで、あまねくData ONTAPを搭載することで真のユニファイドアーキテクチャを達成してきた。

 そんな会社がData ONTAPを搭載しないEシリーズをいったいどのように考えているのだろうか。少なくとも現時点でのEシリーズは、NetAppの独自性がみじんも感じられない単なるディスクボックスである。将来的には、ビッグデータ関連の用途に最適化されたData ONTAPを搭載するなど、NetAppならではの独自性が垣間見られるような取り組みが求められるのではなかろうか。

日本で初披露されたNetApp E5400ストレージシステム。4Uラックサイズに60台ものドライブを収容できる高密度設計がとられている。ただし、Data ONTAPは搭載されておらず、NetApp製品ならではのオーラがいまいち感じられない

 ほかの大手ストレージベンダーが、製品ラインごとに異なるアーキテクチャやストレージOSを採用しているのに対し、NetAppは創業当初からData ONTAPのみにこだわり続けてきた。筆者は、このような職人気質ともいえる頑固さに何となく惹かれていた。

 NetAppは、2012年会計年度で62.3億ドルもの売り上げを達成しており、今やIT企業の中ではかなり大きな部類に入る。企業規模が大きくなればいろいろ大変なのも分かるが、できればData ONTAPにこだわる姿勢はこれからも維持してもらいたいと思っている。そんなことを考えながら、また2013年に開催されるイベントを楽しみに待ちたい。

(伊勢 雅英)