FCoE, 10GbE本格普及前夜のストレージ接続プロトコル選択

NetAppでは従来より、Tech OnTapを通じて現場の皆様に様々なトピックスをお届けしていました。ところが、「内容が高度すぎて理解できない…」などのコメントを頂戴することもあります。そこで今号から不定期となりますが、過去のTech OnTapの記事からいくつかをピックアップして、その解説をご用意します。単なる技術解説ではなく、その背景にある知識なども詳しくご紹介していますので、ストレージに関する知識と選球眼を養うことができると自負しています。4月からインフラ管理の部門に着任した担当者様はもちろん、NetApp運用のエキスパートの方にも是非お読みいただきたい内容です。

ストレージのコスト構造の全面見直し・・・

「コスト削減のため、インフラ保守をSIerに一任するのはやめるから、キッチリ勉強しておくように」「インフラコスト削減の調査企画書を1ヶ月後までに用意して。よろしくね」

一部加筆修正していますが、この話はあるお客様からお聞きしたものです。4月の新年度を迎え、こうした指示を受けババを引かされた気分の方も、あるいは隣のご担当者様が指示を受けて「助かった…」と胸をなで下ろしている方もいるかもしれません。

なぜこのような話から始めるのでしょうか?それは、ストレージのコストはITインフラのなかでも非常に高い比重を占めているものであり、この部分を聖域化するわけには行かなくなっているからです。こちらをご覧下さい。
 














図1)IDC Perspectives Study, 2008
このグラフは、IDCによる2008年の調査結果で、ITインフラに占めるコスト構造の割合を示したものです。ストレージはサーバに次ぐ2番目の順位にあります。サーバに関しては、仮想化技術の大幅な進展と普及により、コスト削減が目に見える形で進んでいますが、ストレージ部分に関してのコスト構造は従来から大きな変化はありません。

では、「ストレージのコスト構造の全面見直しだ!」、と考えてみても、一体どのようなことが出来るのでしょうか?多くのお客様においてストレージは、SIerが一括納入/保守を実施しており、現場で知識を高めてもできることは限られていたのが実情ではないでしょうか?しかし、ストレージの知識を高めることで、適材適所を見極め、より少数のストレージを賢く使い倒す方法は存在します。

Tech OnTap 2009年8月号では『ストレージ戦略におけるFCoEとiSCSI』 というタイトルで 、最新プロトコルであるFCoEを題材にした記事を掲載しました。この「接続プロトコル」というキーワードは、ストレージベンダが好んで使うものですが、皆様はあまり意識しないのではないでしょうか?しかし、似たように見える接続プロトコルにも大きな違いが潜んでおり、その適性を見誤ると大きなコスト要因になってしまうのです。そうしたことからも「どのプロトコルでつなぐ?」ということは、インフラ管理者が是非ともおさえておきたいポイントです。

なぜ今、プロトコルの議論なのか?

こたえは10Gbイーサネット(以下10GbEと省略)の急速な普及です。以下のIEEEによる資料にもあるとおり、10GbEの本格的な普及が始まるのが今年と見られています。













出所: 『40GbE Market Potential』
図2)10GbEおよび超高速イーサネットの普及予測

これにはさまざまな理由が考えられますが、大きく3つの理由を取り上げたいと思います。

まず最大の要因は、ポート単価の漸減であると言えるでしょう。最近では価格競争力に優れる10GbEスイッチなどの広まりにより、ポート単価も市場実勢価格で見ると、最も廉価なケースでは6万円台にまで下がってきているという状況にあります。

つぎに、サーバ仮想化による高集積化やマルチメディアコンテンツの普及による広帯域、低遅延のニーズの高まりが挙げられます。10GbEもの速度を必要とするサービスは、もはや限られた業種・用途のものではなくなりつつあるのです。
最後に、ストレージネットワーキングへの適用という観点からは、Fibre Channel Over Ethernet (以下、FCoEと省略)の規格策定と対応製品の広まりです。従来、FC上でしか実現しえなかった高信頼のストレージネットワーキングも、次世代イーサネットをベースにしたFCoEであれば実現可能になってきているのです。こうしたポイントが背景にあるからこそ、今から大いに検討に値するのが10GbEそしてその上位のプロトコルの違いなのです。

おさらい~そもそも、どのようなプロトコルがあるのか??

NFS/CIFS
iSCSI
FCoE
Fibre Channel
プロトコルタイプ
ファイルI/O
ブロック I/O
ネットワークタイプ
イーサネット
拡張 型イーサネット
ファイバチャネル
リンクスピード
1Gb~ 10Gb
10Gb
4Gb~8Gb
相互接続性
高い
サポートマトリク スに準拠する必要あり
表 1:接続プロトコルによる違い:仕様編

上記に記載した内容は、規格として策定されているもので、NetAppに限らずどのストレージベンダの実装でも違いはありません。各社により多少の表現の違いはありますが、NFS/CIFSをサポートするストレージをNASストレージ、ブロックアクセス系の各種プロトコルをサポートするストレージをSANストレージと呼ぶこともあります。(iSCSIなどイーサネット系ブロックアクセスストレージを、便宜上IP-SANストレージと呼ぶ場合もあります)2009年8月号のiSCSIとFCoEというのは、上記の区分では、拡張型イーサネットを利用するかしないか、と見ることもできるのです。

さて、上記の表をご紹介すると、導入および構築コストの違いに議論が発展することがあります。いうまでもなく、イーサネットベースであれば、スイッチやNICなどが、ファイバチャネルベースの製品と比べて相対的に安価である、というのがその背後にある考え方です。 この考えは部分的には正解ですが、ファイバチャネルベースの製品も年々低価格化がすすんでおり、また個別案件単位での市場実勢価格で評価すると必ずしも決定的な差にはならないケースも見あたります。そこで今回は、単純な価格の議論ではなく、もう少し違った観点から議論を進めたいと思います。具体的な視点は以下の3点です:

  • NetAppでの実装の違いと設計上の考慮点
  • 性能の差異
  • 仮想サーバ環境における運用の差異

1. NetAppでの実装の違いと設計上の考慮点

さらに掘り下げて見ていきましょう。まずは先ほどの表を拡張したものをご紹介します。

NFS/CIFS
iSCSI
FCoE
Fibre Channel
サーバのマウント対象
ボリューム(FlexVol)
ボリューム(FlexVol)上に作成するLUN
作成/監視の対象
Aggregate, FlexVol
Aggregate, FlexVol, LUN
バックアップ/リカバリの単位/center>
バックアップ/リカバリの単位
FlexVolまたはLUN
表 2:接続プロトコルによる違い:NetAppにおける実装および運用編

上記の表のとおり、ブロックアクセス系のプロトコルでは、LUNを利用することがわかります。この違いを図式化したのが図3です。













図3)接続方式による実装の違い
 
端的な違いは、ファイルシステムの場所です。向かって左は、WAFLというNetApp独自のファイルシステムでフォーマットされたFlexVolをそのまま利用します。
一方ブロック系プロトコルの場合は、FlexVol上にファイルとして作成されたLUN“ファイル”をOSのファイルシステムでフォーマットしてマウントして利用するのです。なお、一つのFlexVolのなかには、複数のLUNを作成することも可能です。。
さて、ここで触れておかねばならないのは、NetAppの持つバックアップの機構であるSnapshotです。SnapshotはFlexVolの単位で動作します。この仕様を考慮すると、単に大きなFlexVolを作成すればよいという訳ではなく、バックアップ運用を考慮した設計をする必要があるのです。具体的には、バックアップ要件の異なるLUNは一つのFlexVolに入れないというものです。1つのFlexVolには1つのLUNという設計が理想的ではありますが、この点はお客様の要件に応じて調整してください。

2. プロトコルによる性能の差異

前節では、プロトコルによるアーキテクチャの違いについて考えてきました。この話題を取り上げると、「NetAppの実装はオーバーヘッドが多く、性能が出ないのではないか?(NASでしか使えないのではないか?)」というご質問をいただくことがあります。特に、LUNをファイルとしてWAFL上に実装するという点です。
x およそあらゆるコンピュータにおいて、何らかのオーバーヘッドは性能劣化の理由以外の何物でもなく、通常はそれの除去を考えます。しかし我々は、NetAppの大きな特長である簡単かつ高速なオペレーションを実現する上で、SnapshotおよびWAFLファイルシステムは不可欠であると考えました。そのため、それを前提としたパフォーマンス改善に全精力を傾け、その結果、オーバーヘッドが少ないと考えられるアーキテクチャのSAN専用機と比較した場合でも全く遜色のない結果を示すまでになっているのです。













図4)SPC-1ベンチマークでの性能比較
図4は、業界標準ベンチマークであるSPC-1を利用して、FAS3040と同等性能と考えられる競合他社の製品とを比較したものです。SPC-1とは、 耳慣れないキーワードかもしれませんが、より実運用に近いワークロードとSnapshotなどの機能を組み込んだテストによるもので、接続にはNFSでは なく、FCを利用します。

向かって左側のBaselineでの比較も興味深いものがありますが、特筆にあたいするのは、Snapshot取得時の性能劣化の低さです。NetAppはいまだにNASでしか利用できないというイメージが一部にあるようですが、この結果が示すとおり、性能面でも全く問題なく利用できるレベルに達しているのです。

3. 仮想サーバ環境における運用の差異

ここまで、プロトコルによるアーキテクチャと性能の差を見てきました。しかし、実際のプロトコル選びというものは、上位のアプリケーションやミドルウエアに大きく依存するものなのです。そこで本節では、最近最も関心の高い、仮想サーバソフトウェアとの組み合わせという観点でのプロトコル選びを見ていきたいと思います。まずはじめに、主要な仮想化エンジンがどのプロトコルをサポートしているかについて見ていきます。

(50音順)
NFS
CIFS
iSCSI
FCoE
Fibre Channel
プロトコルタイプ
ファイルI/O
ブロックI/O
Oracle VM
x
x
Citrix XenServer
x
x
Microsoft Hyper-V
x
x
VMware vSphere
x
x
注:2010年5月時点。筆者調べ
表 3:主要な商用ハイパーバイザーの接続プロトコルサポート状況


このように各社の実装により、そもそも選択できるプロトコルが限られてくるという違いがあります。なおFCoEについては、各社ともに非対応ではなく未対応である、という状況ととらえていただくのが妥当と考えます。
では複数のプロトコルをサポートしている仮想化エンジンを利用する場合には、なにを選べば良いのでしょうか?ここで取り上げたいポイントは拡張性および柔軟性です。

例えば、現在最大シェアを持つVMware製品をNFSおよびSANで利用する場合を比較してみます。VMware vSphere では、ストレージ領域をDatastoreという名称で呼んでいます。このDatastore内に、各仮想マシンの実態であるVMDKファイルが配備されます。各仮想マシンでの運用に伴い、データが蓄積されてくると、最終的にはDatastoreが足りなくなるという状況になり、拡張の必要がありますが、ここで大きな差がうまれます。例えばNFSの場合は、FlexVolを拡張するだけでDatastoreのサイズ拡張が完了します。ところが、FCなどブロックアクセス系で利用している場合は、複数のステップを必要とします。またNFSでの利用時は、必要に応じて、オンラインでの縮小も可能ですので、例えば割り当てすぎた場合などでも簡単に対応することが可能です。

このような違いがうまれる理由は、先述のとおり、ファイルI/OとブロックI/Oとでは、ファイルシステムの位置が違うという点です。NFSであれば、FlexVolの伸縮は全てNetAppのWAFLファイルシステム上で完結しますが、他方の場合は、OSファイルシステムまで含めた考慮が必要となるためです。

まとめ

今回は、10GbEの一層の市場トレンドをベースに、各ストレージプロトコルの特徴を見てきました。特定のプロトコルの利用を推奨する意図での記事ではないため、どのように選択するべきか、最後に検討の順番をチェック項目形式でご紹介したいと思います。

プロトコル選択のポイント:

ステップ1: アプリケーションの要件を確認
表3のように、アプリ要件により使用不可能なプロトコルも存在するため

ステップ2: 性能要件を確認
アプリの特性やユーザI/Oの特性から、必要な帯域を算定する。
NetAppが発行しているプロトコルごとの性能比較テクニカルレポートなども参考に。

  • Ethernet:1GbE または 10GbE
  • Fibre Channel:4Gb または 8Gb
  • FCoE:10GbE
ステップ3: コストとのバランス
製品購入コストに加え、保守費用および技術員の習熟度合いなども検討。

ステップ4: 将来性と投資保護

石渡 達也

アライアンス・マーケティング担当マネージャ 2001年 一橋大学大学院修了、サン・マイクロシステムズ入社。ハイエンドサーバの導入コンサルティング、プロジェクトマネージャなどを経験後、ネットアップに入 社。通信・メディア業界等のプリセールスSEを経て現職。

 
関連情報