2/27の「TRILLはEthernetになにをもたらすのか」エントリーの続き、みたいな感じです。
Brocade VDX 6720の全体的な解説としては、@ITの記事をご参照下さい。このエントリーではあえてTRILLを中心とした部分にフォーカスするために全体的な説明はしておりませんので、先にこちらの記事を読んで頂いた方がよいかもしれません。
また、より深く知りたい方は、こちらのThinkITの記事がオススメです。
■TRILLにおけるストレージネットワーク技術の活用
標準技術としてのTRILLはL2ルーティングプロトコルとしてIS-ISを用いることで策定が進められていますが、現在 仕様の確定に先行してリリースされているBrocade VDXではBrocadeが開発したルーティング技術であるFSPF (Fabric Shortest Path First)が使われています*1。FSPFはBrocadeがFibre Channelネットワークのために開発した技術ですが、それをEthernetに持ち込んでいるところがBrocadeらしいやり方です*2。
それ以外にも、TRILLスイッチにおけるMACアドレス学習の仕組みとしてFibre ChannelにおけるName Serviceを拡張したEthernet Name Service (eNS)を使うように実装するなど、Brocadeは徹底的にFibre Channelにおいて培ってきた技術をEthernet / DCBの世界に持ち込み、シビアな要求に答えてきた実績を持つストレージネットワーク技術を活用してDCB市場では全面的に競合することになるCiscoなどに対する優位性を築こうという戦略に出ています。
ストレージネットワークではもはや当たり前ともいえる「管理」「コントロール」「データ」の3つのプレーンを明確に分けた実装は、これまでのEthernetスイッチネットワークではないものでした(逆に、だからこそマルチベンダーによるネットワークが簡易に構成できるというメリットもありました)。
これらプレーンごとの実装を分離し、管理範囲をそれぞれのプレーンごとに構成することができる仕組みは今後DCBとしてLANとSANが統合されていく流れの中では重要な要素となっていくことになるでしょう。願わくば、この仕組みが標準化され、マルチベンダーで問題なく動作する様になればよいのですが…。
■TRILLに設定は(ほとんど)いらない
TRILLのメリットはいろいろとありますが、最大のメリットは自動化(自律制御)によるシンプル化といえるでしょう。ネットワークトポロジーがどのような構成になっていようとも対応することが可能で*3、TRILL対応スイッチが追加で接続されても問題が発生する可能性は基本的にはなく*4、複数経路さえ確保されていればノードに意識させないレベルでの冗長性が備わっています*5。
設定という設定も特には不要で、Brocade VDXの場合はVCSが有効化されていて、VCS IDが同一で、RBridge IDが既存と重複さえしていなければあとはつなぐだけ。これらの設定に必要な実際のコマンドも「vcs rbridge-id ** vcs-id xx enable」でおしまい。もしVCS IDが間違っていたりRBridge IDが重複していたとしても単に既存のEthernet Fabricに参加できないだけなのでSTPのように「つなげたら影響してしまう」ような問題が発生しないというだけでもネットワーク管理者にとっては大きなメリットといえるでしょう*6。
仮想化の普及・一般化によりサーバ内にソフトウェアスイッチが構成されるなど、ネットワークがますます複雑になっていく中で、完全に全体を把握した管理者だけがネットワーク構成を管理して設定する運用はかなり難しくなっています。だからこそ、いい意味で「よきに計らってくれる」自動化の仕組みを持つTRILLは今後のL2ネットワークでは必ず必要な技術となっていくはずです。
■Ethernet Fabric
BrocadeはVirtual Cluster Switching (VCS)という名称で自社のネットワーク技術をアピールしており、その技術を実装した製品としてVDXシリーズ(現時点ではVDX 6720シリーズのみ)をリリースしているわけですが*7、VCSは3つの要素 "Ethernet Fabric" "Distributed Intelligence" "Logical Chassis" を含んでいます。これらの要素により実現されることを端的に書けば、スイッチ間連携により「単一管理ではないが協調動作する論理スイッチ」を実現する仕組みといえるかと思います。
SANスイッチにおけるFabricのメリットとしては、Zoning設定をスイッチ単位でやらなくてよくて便利、ぐらいにか考えていない場合が多いですが、EthernetスイッチがFabric化するとなかなか便利です。最近はEthernetスイッチにおいても統合的な管理を実現する仕組みが次第に登場しつつありますが、それらの多くがあくまでも一元的に管理できるようにしているだけで、統合的な管理・制御を実現しているわけではありませんでした。対して、Ethernet Fabricによって統合されたEthernetスイッチ群(=Fabric)ではそれぞれのEthernetスイッチにおいて自律的に通信を処理しつつも全体的にはあたかも1台の論理スイッチ(Logical Chassis)に接続しているかのようなレイヤーとして捉えることができるようになります。スイッチの追加や削除、パスの増強や縮退などが無停止・無操作で実現できるのはもちろん、仮想マシンのような論理的なノードが通信経路をあちこちに移動させても(仮想マシンの配置があちこちに移動されたとしても)それに追随できるポリシーを定義すること*8ができるなど、EthernetのFabric化はサーバの仮想化、ストレージの仮想化と並んで、ネットワークの仮想化を実現する中心的な仕組みとして今後のネットワークでは必須となるのではないかと思います。
■TRILLの拡張予想
TRILLの根幹をなす仕組みである、「EhternetフレームをEthernetフレームでカプセル化してL2ルーティングする」仕組みは、単にTRILL対応スイッチ間でEthernetフレームを転送するだけではなく、拡張していくと面白いネットワークを構成することができそうです。
たとえば、特定の宛先MACを持ったEthernetフレームだけはロードバランサに転送するような仕組みも考えられますし、IDS的に通信を監視する仕組みを組み込んでしまうこともできそうです(フレーム単位での転送となりますのでやりすぎるとパフォーマンス面が心配ですが)。送信元と送信先のノードでは「送信してから届くまでにどんな処理がされたのか」について一切意識せずに(させずに)こうした拡張ができそうなところがポイントです。こうした仕組みが実装されれば、L2スイッチでサンドイッチされたロードバランサのような、これまで当たり前にみられたネットワークの物理的な構成方式は変化していくことになりそうです。これまではネットワークの拡張・高機能化はL3以上のレイヤーで実現されてきていましたが、L2レベルにおける高機能化が今後どのように発展していくことになるのか、とても注目しています。
■TRILLの課題
まずはベンダーロックインの問題です。
残念なことにTRILLが完全なベンダー互換性を持った仕様となる日が来ることはあまり期待できそうにありません。LANの覇者CiscoとSANの覇者Brocadeが正面から激突することとなるDCB市場では今のところ、デファクトスタンダードとしての地位を確立させて「俺が標準」とジャイアニズム？を主張できるポジションを得たベンダーはまだありません(そもそも、これから本格的に立ち上がってくる市場です)。標準化に準拠するかたちでの実装は進められていますが、それでも未確定であったり調整が進まない部分についてはBrocadeを含め各社がそれぞれの思惑でそれぞれのやりかたでの実装が行われ、そうした実装には当然ながら互換性がありません。
また、マルチベンダー問題は構成レベルでもいくつかあります。たとえば、現在のVDXの仕様ではTRILLトポロジーを構成するEthernet Fabricに所属するスイッチ同士の間にはVDX以外のスイッチがあってはならないこととなっています。TRILLがDCBとして実装されていることや、そもそもTRILLにおけるトポロジー管理のためにはTRILLで管理できない経路が存在してはいけないこととなるためには仕方がないこととはいえますが、今後のDCBが本格的に普及し始める中では、一定の機能範囲については標準化されマルチベンダー性が確保されることを望みます。
Brocadeの実装仕様によるEthernet FabricにおけるTRILLの課題としては、eNSによるMACアドレス学習の分散同期を必要としているため、MACアドレステーブルのエントリー数が大きくなってしまうことが挙げられるかと思います。単一のEthernet Fabric内に構成されたスイッチでは、どのノードがどのスイッチのどのポートに接続されているかについて全てのスイッチが共通の認識を持っている必要があり、つまりは同じMACアドレステーブルを持っていないといけません(そうでないと、どの経路でEthernetフレームを転送すればよいのかがわからなくなります)。物理サーバが主役の時代ならともかく、現在は仮想サーバが本格的に普及しているため、1つのEthernetポートの先には数十の仮想マシンMACアドレスがエントリーされる場合が多くあるでしょう。24ポートモデルであっても、1台当たりのMACアドレスエントリー数が数百になることは十分あり得ます。Brocade VDX 6720の仕様上のMACアドレスエントリー数は32000ということなので十分だとは思いますが、それでも検証済みエントリー数は現時点では2000とのことなので、当面は最大でもVDX 6720が数台程度の範囲でEthernet Fabricを構成することになると思われます。
最後に、LANとSANが必要とするネットワーク構成に違いがあることも課題かもしれません。基本的に単一性が重視されるLANに対して、SANは障害範囲を確実に区分して冗長性を確保するために複数ネットワークに物理的に分離することが重視されていました(多くの場合は。例外ももちろんあります)。FC SANでも、SANスイッチ間の接続をわけて2 Fabricにする構成は当たり前のように構成されてきました。ところがDCBではこれらが共存することとなるため、こうした矛盾をどのように回避していくのか、今後本格的にDCBが普及していく中で、新しい標準的な構成パターンが定まってくことになるでしょう。
*1:標準仕様が確定されれば対応することになると思われますが…
*2:FSPFはOSPFのように、リンクステート型のルート情報収集と最短経路アルゴリズムによってルーティングテーブルを作成・伝播します
*3:さすがに、同じ筐体のポート同士を結線するようなことはやっちゃダメでしょうけど…。そういうことやっちゃったらどうなるんでしょう？中の人！(^_^;)
*4:STPのように、スイッチを追加したら思わぬところでブロックが発生するなんてトラブルはごめんだ！
*5:ただし、物理的な機器ですので「中途半端に壊れる」ことによるリスクは当然ありますが、それはどんな機械でもまぬがれえない宿命でしょう。Brocade VDXの場合も、ハートビートタイマーを使うなどしてできる限りの対応が可能なように実装されているようです。
*6:往々にして、STPが構成されたネットワークにスイッチを接続すると、思わぬところにブロックポートが構成されたりします
*7:ちょっとややこしい
*8:AMPP：Automatic Migration of Port Profile
