ファブリックについてBrocadeさんに聞いて来ました [Interop Tokyo 2012]

2012/6/20-2

ファブリックについてBrocadeブースで聞いて来ました。

Q: 御社が考えるファブリックって何ですか?

ブロケードは、マルチプロトコルがマルチパスで動くフラットかつインテリジェントなL2ネットワークがファブリックだと考えています。とりわけ、データセンタにあるL3や Firewall、ロードバランサ、ストレージ暗号化装置などのネットワークインテリジェンスが接続される基盤となるネットワークがファブリックです。イメージでいうと、筐体型スイッチに様々な機能を持つラインカードを挿入すると筐体全体が高機能化するように、ファブリックを基盤とすれば、ルータや物理アプライアンスや仮想アプライアンスなどを接続することでデータセンターネットワーク自体を高機能化できるというイメージです。

ネットワークエンジニアの方々は、やはりイーサネットファブリックに注目されることが多いのですが、ブロケードはFC(Fiber Channel)のパイオニアでもありますので、ファイバチャネルであったりInfinibandのようなメモリ間転送であったり、そういうものを含めてマルチプロトコルが動くもの、たとえば、ネットワークやストレージIO、メモリ転送といったものを一面でサービス提供できるネットワークのことを「ファブリック」として考えています。

ストレージIOやメモリ転送が同居するので、ファブリックにはいくつかの特徴的な機能性が求められます。一つは設定なしで使用でき、自律動作することです。たとえば、メモリやストレージを使用する際にいちいち細かい設定をすることは現実的ではありません。簡単かつ可用性に優れたネットワークサービスが求められます。二つ目は、上記のとおり、LANとSANの混在が必要になります。ここでのSANにはストレージとともに、システムという意味もあります。三つ目はサーバ仮想化レイヤやクラウドオーケストレーションレイヤとの自動連携です。これは今話題のキーワードでいうと、Software-Defined Network ということになります。

Q: 技術的視点で見たファブリックを教えて下さい

ファブリックとしては、既に実現しているように、複数のスイッチがあっても一つのスイッチに見えます。そのため、スイッチ間のコンフィギュレーションは自動的に共有されたり、冗長パスもできるようになります。我々ブロケードには実績に裏付けされたファイバチャネルファブリックの技術を蓄積していますので、イーサネットファブリックにもFCの技術を使っています。具体的には、各スイッチでは協調動作するファブリックサービスというものが動いています。 各スイッチ間でマックアドレスを共有したり、コンフィグレーションを共有するなど、各種ステータスやアラート系のイベントを全てのスイッチで共有化することで、物理的に分かれていても全体が一つのスイッチとして見えるようにすることを実現しています。

Q: スタックとの違いを教えて下さい

見え方としてはスタックに近いと思うのですが、スタックとの大きな違いはマスタがないことです。 通常のスタックだとマスタがいてスレーブがいるのが通常であり、マスタが落ちるとコンフィグレーションの同期などをどうしましょうという話になるのですが、ファブリックではマスタもスレーブもありません。 ファブリックスイッチのもう一つの特長は個々のスイッチが自律制御をして動くというのがポイントです。 隣接スイッチと自発的に情報交換することでスタックのようにコンフィギュレーションのステータスを同期して動きます。 たとえば、所属するネットワークグループの中で1台や2台がいなくなったとしても、あるいは機器が壊れたなどでポートがリンクダウンしても、その都度最適な構成は何かを自分で考えて自分で判断するというネットワークを構成できるというのが特長です。

なので、スタックのようにマスタが死ぬというような状況が起きたとしても、ファブリックは全く止まりません。 止まったところは自動的に切り離されて、それ以外のところは何事もなかったように自立制御されて動くネットワークを作れるのがファブリックの魅力の一つだと思います。

Q: 今回、別々の機種同士でスタックが可能となるミックス&マッチスタッキングできる機器が展示されていますが、そのような機能を利用するよりもファブリックを利用した方が良いということですか?

そこはケースバイケースだと思っています。

ファブリックの限界という話にもなってくるのですが、ファブリックは全てのスイッチ間で同期を取らなければなりません。 それは異なる視点から見れば実は弱点になる場合があります。 弊社だけではなく、恐らく他社さんも同じだと思うのですが、同期を取るためにはある程度の範囲内でしか使えないということがあるからです。 つまり、スイッチ間同期の遅延をある程度の値以下に保てる環境でなければファブリックを組めないというのがファブリックの限界なのです。

一方スタックを使えば、そういったところでの自由度が高いと言えます。 同期しなければならないという命題では、スタックの方が実績がありますし、制約も少ないかも知れません。

Q: ファイバチャネルはkm単位での距離での通信が可能だったと思いますが、それを考えるとファブリックも同様の距離で利用可能だったりしないんですか?

それは、弊社を含めて各社が現在対応しようとしているところだと思います。

ファイバチャネルとイーサネットファブリックの大きな違いとしては、ファイバチャネルというのはフレーム転送というのをBB Credit(Buffer-to-Buffer Credit)というフレーム単位の個数管理という形で制御をしているので、遠距離になったとしても何個送って何個受け取ったのかを正確に制御できる点です。

一方、イーサファブリックの基盤はイーサネットなので、いくら高品質化したとしてもバッファリング処理になってしまうので、距離が伸びてイーサフレームを一つ一つチェックするかというと、そこまではできません。 そこは、ファブリックというよりもイーサネットそのものの限界と考えております。

Q: スタックとファブリックでコストに違いはありますか?

もう一つ大きな違いはコストだと思います。 そういう意味ではコストというのは大きいと思います。

例えば、キャンパスみたいにイーサネットだけで良いところにファブリックを入れてみようとしても、単純にコストだけで考えると、レガシーイーサネットを入れた方が安くなるのは事実です。 しかし、これは機器の導入コストとして見た場合にそう見えるというだけであって、実際管理コストまでを含めて考えたときにどちらが良いかというと異なる結論に行きつく場合があります。というのも、実はこうした分野でのファブリックの導入は今年に入ってから広がっています。

例えばある企業さんでは、キャンパスネットワークにファブリックを用いてスイッチを一元管理できるということ評価し、ビル内のフロア跨ぎネットワークのコアスイッチ部分でファブリックを導入されています。 そういう意味では、スタックとファブリックは導入コストが違うというのがあったのですが、今後はやはりイニシャルコストが高くても運用を考えると楽だからファブリックにしたいというニーズは増えて来るかと思います。

Q: ファブリックってどこでどのように売れているのでしょうか?いつごろから売れていますか?

2011年に我々がリリースさせて頂いた時には、完全にデータセンターで仮想化環境を利用するお客様がメインでした。 クラウドやバーチャルホスティングといったサービスをされているお客様にもてはやされて、そこにドンドン投入されていきました。

2012年になってからデータセンター事業者さんだけではなく、キャリアバックボーンであったり、キャンパスでも使えるとか、ビッグデータのネットワークや、VDIも含めた仮想化基盤を作りたいといった部分でもファブリックの便利さというのが浸透しはじめて業種を問わなくなりつつあります。 それが2012年の状況です。 よってブロケードとしては2011年は皆様の検討・検証段階、かつ、先進的なデータセンター様が使われるだけのものという位置づけだったのですが、2012年は業種を問わずにファブリックの利便性をご利用になられたいお客様が導入されて利用していただいています。

特にキャンパス系だとSTP(Spanning Tree Protocol)を排除したいというお客様のところにも浸透が始まったテクノロジーであり製品であると考えています。

Q: 今後、イーサネットファブリックはどう発展していくと思いますか?

今後としてですが、いつくかあると思います。

ひとつは距離の制約をどうやってとっぱらうかが課題でありチャレンジです。 ブロケードとしては、イーサネットファブリックの延伸をファイバチャネル同様に10kmまで伸ばす取り組みをやっと最近できるようになりました。 あと、やはりそれ以上に10kmでは足りないというお客様のために長距離ファブリック接続、たとえば東京大阪間、東京大陸間といったところでもファブリックを結合する技術を来年リリースする予定です。 そういうものを実現することによって、イーサネット環境だけではなく、ストレージやメモリ転送を含めてファブリックがどこでも使える状況を作って行くのが課題と同時にチャレンジです。

ポート数台数制限というのも課題です。 先ほど言った通り、スイッチポート数でどこまで収容できるのか、そこもチャレンジだと思います。

Q: スイッチ数として24台ですか?

現在スイッチ数として24台ですが、この24台というのは、実環境で検証済みが24台1200ポートというのが私達がお伝えしている所です。 計算上は8000ポートまで対応可能なテクノロジーとなっています。 しかし、やはり、それら全てのスイッチに対してコンフィギュレーション同期等を実現するかや、いかにスケールしていくかというのは現状課題だと考えています。

24台というのは、弊社検証センターで実測や動作検証を行った実証済みの台数であり、設計値ではないんです。 そこが面白いところで、他社さんは設計値を公開しているところもあり、弊社の24台という数値を「そこが限界」と捉えている方々がいらっしゃるようですが、それは制約ではなく検証済みの値なのになぁ」と思うところだったりもします。

ファブリックの面白いところは、伸縮自在である点があげられます。

エンタープライズのお客様で良くあるのですが、検証環境と本番環境を分けて実装されていることがあります。 開発が終わると開発環境を潰して、本番環境へと移行したりします。

従来のSTPですと、スイッチを外す時にはSTPの設定を行い直してから外すなど、非常に煩雑です。 スイッチ一台外すのに、どれだけコンフィグを変更しなければならないのかというぐらい煩雑になります。

しかしファブリックは、大げさに言うとプラグ&プレイといえるぐらい、ケーブルを抜いて挿すだけでネットワークとして動作します。 そういった従来にはない手軽さがファブリックの特長であると考えています。

STPと違ってマルチパスができるのも大きな特長です。 ブロケードの場合はTRILLを使っていますが、それで冗長化を組んでいます。 それによって最短経路はどこかを割り出しています。 ブロケードの場合は、そこはL2でのリンクステートプロトコルなので、15年来の実績があるファイバチャネルの技術で実現しています。

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!