仮想化時代のネットワーク「イーサネット・ファブリック」とは?(後編) | 東京エレクトロンデバイス

複数のスイッチを仮想的に1台として扱うには、古くからスタックが利用されている。ただし、スタックはスイッチ間を接続するには原則として専用のインタフェースが必要だ。また、スイッチの物理的な接続の構成には制約がある。それに対して、イーサネットファブリックは、手軽に柔軟な構成でスイッチ間を接続した上で仮想的に1台のスイッチとして扱うことができる。さらに、将来的な拡張も簡単だ。
こうしたイーサネットファブリックの特徴を実際に確認するために、今回の後編では、Brocade製のイーサネットファブリックに対応したVDXシリーズのスイッチを利用し、検証を行った。
なお、この検証はVDXシリーズの販売と構築を行っている東京エレクトロンデバイスの協力を得て行っている。

検証に利用した機器

今回のイーサネットファブリック構築の検証で利用した機器は、Brocade VDX 6710 スイッチとBrocade VDX 6720 スイッチだ。

モデル	1000BASE-Tポート	1/10G SFP＋	台数
VDX6710-54	48ポート	6ポート	2
VDX6720-24	–	24ポート	1
VDX6720-60	–	60ポート	1

検証内容は

• 2台のVDXスイッチでの基本的なイーサネットファブリックの構築
• 4台のVDXスイッチへのイーサネットファブリックの拡張と経路の切り替えの確認

となる。
なお、VDXスイッチの設定はコマンドラインのみだが、Ciscoライクなコマンド体系となっている。Cisco機器を扱った経験があれば、特に迷うことなく設定することができるだろう。

基本的なイーサネットファブリックの構築

まず、VDX6710-54(RB1)とVDX6720-60(RB2)で基本的なイーサネットファブリックの構築を行った。筆者はイーサネットファブリックの機器の設定はまったく初めてだったのだが、驚くほど簡単にイーサネットファブリックの構築が完了した。手順は次のとおりだ。
(1) VCS IDとRbridge-IDを設定する
(2) 機器の再起動
(3) ケーブルの配線
まず、VDXスイッチにVCS IDとRbridge IDを設定する。VCS(Virtual Cluster Switching)とはBrocade独自のイーサネットファブリック技術だ。VCS IDはファブリックを識別するIDで、同じVCS IDを持つVDXスイッチは仮想的に1台のスイッチとなる。そして、ファブリック内の各VDXスイッチを識別するための情報がRbridge-IDだ。VCS IDとRbridge IDの設定コマンドは以下のようになる。

[x]:設定で入力するVCS ID、[y]:設定で入力するRbridge ID
イーサネットファブリックの設定コマンドは基本的にこれだけでよい。今回の検証では、VCS IDは1とし、Rbridge-IDとしてRB1には1をRB2には2を設定した。設定する前は「どんな設定を行うものか」と構えていたのだが、あっけないほど簡単に設定は完了だ。以下は、RB2へのVCS IDとRbridge-IDの設定ログである。

このログにあるようにVCS IDとRbridge-IDを設定すると再起動が求められる。再起動には10分弱の時間がかかるが、再起動に少し時間がかかる印象だ。しかし、一度、イーサネットファブリックを構築してしまえば、頻繁に再起動するような必要はないので特に問題にはならないだろう。
再起動が完了するとイーサネットファブリックを構成するVDXスイッチのインタフェースの番号はRbridge-ID/Slot/Port IDのようにRbridge-IDを反映したものに変更される。Slot番号はボックス型の製品の場合は0で固定だ。
RB1のインタフェース番号は「1/0/～」RB2のインタフェース番号は「2/0/～」のようになる。そして、インタフェースの識別はCiscoライクで、先頭にインタフェース種別を付加する。ギガビットイーサネットのインタフェース種別は「GigabitEthernet」、10Gイーサネットのインタフェース種別は「TenGigabitEthernet」である。RB2はVDX6720-60のモデルで60ポートの10Gイーサネットインタフェースを持つ。つまり、RB2の1番目のインタフェースは「TenGigabitEthernet2/0/1」というように識別できる。
続いてはケーブルの配線だ。イーサネットファブリックを構成するためには、スイッチ間を10Gイーサネットインタフェースで接続する必要がある。RB1とRB2を10Gイーサネットインタフェースで配線し、また、通信確認用のPCを以下のように配線した。

※ここでは、割愛しているがPCが接続される通常のイーサネットリンクではVLAN1のアクセスポートとしての設定を行っている。
これで最もシンプルなイーサネットファブリックの構築は完了だ。なお、設定の手順として先に物理的なケーブル配線を行っていてももちろん問題はない。ここまでの構築作業で時間にして15分もかからないぐらいで、その時間の大部分は再起動に要する時間だった。いかに簡単にイーサネットファブリックを構築できるかがおわかりいただけるだろう。
そして、イーサネットファブリックが正常に構築できているかどうかはshow vcsコマンドを利用する。show vcsコマンドで、VCSを構成するRbridgeの情報を確認できる。また、show fabric route topologyコマンドでイーサネットファブリックの接続構成を確認できる。以下は、実際の検証時のshowコマンドのログだ。

RB1とRB2は仮想的に1台のレイヤ2スイッチと同等に動作するので、PC1とPC2のMACアドレスを学習してMACアドレステーブルに登録する。show mac-address-tableコマンドでMACアドレステーブルを確認すると、次のような結果となった。

PC1からPC2へPingを実行すると問題なく接続性を確認することができた。
さらに、イーサネットファブリックの最も簡単な拡張として、RB1とRB2間のリンクをもう1本追加した。通常のレイヤ2スイッチであれば、スイッチ間を2本のリンクで接続すると片方はスパニングツリーによってブロックされる。2本のリンクを使って負荷分散するためには、別途、リンクアグリゲーションの設定が必要だ。
ところが、イーサネットファブリック環境では「つなぐだけ」だ。特に何も設定せずともRB1とRB2間の2本のリンクで負荷分散できるようになる。RB1-RB2間のリンクをもう1本追加して、以下のように配線した。

リンクを追加したあと、show fabric route topologyコマンドを見ると、RB1-RB2間は20Gbpsのリンクで接続されているのと同等であることがわかる。

つまり、空いているポートがあれば、どんどんRbridge間を接続するとイーサネットファブリックのパフォーマンスと冗長性を向上させることができる。しかも、まったく追加の設定は必要ない。

イーサネットファブリックの拡張と経路の切り替え

次に3台以上のVDXスイッチを使ったイーサネットファブリックの構築を行った。VDX間の接続は、特に難しく考える必要はない。とにかくVDXスイッチ間がつながっていればそれでよい。これは通常のレイヤ2スイッチを使っている環境と比べると、大きな違いだ。スイッチをループ構成に接続すると、スパニングツリーによって特定のポートがブロックされる。イーサネットフレームの転送経路が最適化されるようにするためには、スパニングツリーの細かい制御が必要だ。さらに負荷分散をしようとすると、VLAN単位でしかできない。

一方、イーサネットファブリックでは、つながっていれば自動的に最適なファブリックリンクを利用できるようになる。検証時には4台のVDXスイッチを以下のように配線して、イーサネットファブリックを拡張した。RB3、RB4をファブリックに追加する手順はまったく同じだ。VCS IDとRbridge IDを設定して再起動すればよい。

次にイーサネットファブリックの経路の切り替えも検証した。そのために、RB4でshow fabric route topologyを見てイーサネットファブリックのRB1～RB4の接続の構成を確認した。

これによりPC1とPC2間の経路を判断できる。PC1はRB2にPC2はRB4に接続されているので、Dst RB-IDの列で宛先のRbridge 2に注目する。すると、PC1からPC2への経路は、
1.PC1→RB2(Te2/0/1)→RB1(Te1/0/53)→RB4→PC2
2.PC1→RB2(Te2/0/2)→RB3(Te3/0/2)→RB4→PC2
の2通りとなる。
2つの経路で負荷分散されるが、この場合はフロー単位の負荷分散となる。たとえば、PC1からPC2へ継続的にPingを実行した場合はどちらかの経路だけを利用する。検証時に、PC1からPC2へ100ms単位で継続的にPingを実行すると、1.の経路を利用していた。そこで、RB1とRB4間のケーブルを抜くと、Pingの結果は1回だけ失敗して、すぐに応答が返ってくるようになった。つまり、経路の切り替えは100ms程度で行われているということが確認できた。
スパニングツリーではこれほど高速な経路の切り替えはできない。現在ではスパニングツリーとして高速なRSTP(Rapid STP)が一般的だが、RSTPでの切り替えは数秒程度かかる。

そして、最後にPC1-PC2間の通信経路の最適化を行った。これもまったく難しく考える必要がない。PC1とPC2が接続されているRB2-RB4間を接続するだけである。この経路の最適化の作業は通信がオンラインのときにでもほとんどパケットロスなしに行うことができる。PC1からPC2へ100msec単位で継続的にPingを実行しながら、RB2-RB4間を接続した。すると、Pingはまったく失敗せずに応答が返ってきていることを確認できた。
このときのPC1とPC2間の新しい経路はRB4でshow fabric route topologyコマンドから、
PC1→RB2(Te2/0/3)→RB4→PC2
となることがわかる。

まとめ

サーバの仮想化環境が当たり前になってきている現在、それに応じたネットワークインフラを構築することが非常に重要となっている。特に仮想サーバを集約している物理サーバは、パフォーマンスと信頼性、拡張性に優れたネットワークインフラに接続しなければならない。今回の検証を行ったことで、パフォーマンスと信頼性、拡張性に優れたネットワークインフラを構築する上で、イーサネットファブリックは非常に強力な技術であるということを実感した。
データセンタや大企業のサーバファームだけではなく、さまざまなネットワーク環境で利用されるようになっていくだろう。今回の記事がイーサネットファブリック導入の参考となれば幸いだ。

今回の検証は、東京エレクトロンデバイスの新宿オフィス内で行った。同オフィスは、大規模の検証センターを備えている。

>> 仮想化時代のネットワーク「イーサネット・ファブリック」とは?(前編)

本記事はマイナビニュース2013年9月の掲載内容を転載したものです。