クラウド&データセンター完全ガイド:特集

データセンター選定のポイント2014

クラウド時代に注目を集めるイーサネットファブリック[Part4]

[Part4] クラウド時代に注目を集めるイーサネットファブリック

ネットワークに関する現在の話題の中心は、SDN(Software-Defined Networking)およびSDNとクラウドオーケストレーションの連携といったところだ。一方、上位レイヤを支える物理層の最新アーキテクチャとしてイーサネットファブリック(Ethernet Fabric)があらためて脚光を浴びているという動きもある。本パートでは、イーサネットファブリックにまつわる現在の状況について整理する。 text:渡邉利和

従来型イーサネットの課題

 現在ではSDNの発展がネットワークアーキテクチャを根本的に変革する動きが進行中だが、従来のイーサネットネットワークのアーキテクチャの変更に対する取り組みは、クラウド時代の到来直前のサーバー仮想化の普及段階から始まっている。

 特に、稼働中の仮想サーバーを異なる物理サーバー間で自在に移動させるライブマイグレーションの実用化によって、従来のネットワークアーキテクチャの限界が明らかになった。

 従来のイーサネットネットワークの基本的な設計では、ネットワークを十分に小さなレイヤ3(L3)ネットワークに分割することで運用管理対象を小さく維持するという発想が主流だった。同時に、L3でのネットワーク分割はトラフィックの経路を限定し、帯域を無駄なく活用するためにも重要だった(図1)。

図1:L3スイッチを中心にしたネットワーク構成

 イーサネットは、もともと1本の「バックボーンケーブル」の帯域を全ノードで共用する形のネットワークだった。現在ではノード側のコネクタとスイッチ/ハブ側のコネクタを1本のネットワークケーブルで直結する形のハブ&スポーク型の結線が主流となっているため意識されにくいが、イーサネットの基本的なアーキテクチャは一斉同報型のメディア共有型ネットワークである。

 また、イーサネットでは共有されるメディアに対するアクセス制御をごくシンプルな機構にとどめることでシステムを単純化しているという大きな特徴がある。このことは、急速なコストダウンに大きく寄与したが、一方でさまざまな制約を生むことにもなった。

 その1つとして挙げられるのが、「ループ経路が許容されない」という問題だ。イーサネットはシステム上「パケットがどの経路を通るか」を強く規制しないため、同じ目的地に到達する経路が複数存在する場合、同じパケットが重複して届くという問題が生じる。ブリッジなどのパケットの送出先制御にMACアドレスを利用する機器では、同じパケットが異なる経路で到着することは制御の混乱の原因にもなる。

 こうした理由から、従来のイーサネットの設計では「ループ経路=複数の経路を通じて同一のノードに到達できる状態」を作らないことが重要なノウハウとなってきた。

 一方で、重複経路が許容されることのメリットも存在する。まずは、ネットワーク障害発生時に備えた代替経路の確保が可能になる点が挙げられる。また、同時に複数の経路を利用することができれば、帯域を足し合わせることでより大容量の通信が可能になる(トランキングと呼ばれる)ことも考えられる。

 このうち、代替経路の確保という部分に関しては、従来はSTP(スパニングツリー・プロトコル)を利用した制御を行うことで対応してきた経緯がある。STPは、ネットワーク上でループした経路を発見し、これを遮断することでネットワーックの正常な稼働を保障するプロトコルだ。障害発生時に備えた代替経路を準備する場合は、この“予備経路”をSTPによってあらかじめ遮断された状態にしておき、本来の経路が障害等の理由で利用できなくなった場合にこの遮断状態を解除することで迂回経路を使った通信を可能にする、という手法を採る。

 ややトリッキーな手法だが、基本的にループ経路を許容しないイーサネットで障害時に備えた代替経路を準備するためには他に適切な方法がなかったのも確かだ。ただし、STPベースの代替経路がうまく動作するように適切にネットワークを設計し、稼働状態をモニタリングし、運用し続けるのは負担も大きく、大規模なネットワーク運営者の本音は「できることならSTPはやめたい」というものだった(図2)。

図2:従来型のデータセンターネットワークが抱えるジレンマ(出典:日本アバイア)

ネットワーク設計を変えたサーバー仮想化の進展

 こうした状況の中でサーバー仮想化技術が進化し急速に普及し始めると、ライブマイグレーションを前提とした新たなネットワーク設計が求められるようになった。ライブマイグレーションは、稼働中の仮想サーバー(仮想マシン)を別の物理サーバー上に移動させる技術だ。このとき、仮想サーバーの稼働環境は何も変化しないことが大前提となる。外部からのアクセスも移動前後で何も変わらずに実現できてこそのライブマイグレーションである。

 そうなると、当然ながら仮想サーバーに割り当てられているIPアドレスが変化するようなことはあってはならないので、ライブマイグレーションのためには同じIPアドレスを使い続けられるよう、移動の前後で同一のL3ネットワーク内部にとどまっている必要がある。これを別の言葉で言い換えれば、「ライブマイグレーションのためには物理サーバー群がフラットなL2ネットワークに接続されている必要がある」ということになる。

 仮想サーバーを大規模に運用し、かつライブマイグレーションのメリットを最大限に生かすとなると、ネットワークは従来型のL3で細分化された形ではなく、フラットで大規模なL2ネットワークに多数のノードが接続されたものに変わる必要がある。その結果、ネットワークの運用管理担当者は従来ネットワークをL3で分割することで避けることができていた「イーサネットネットワークの大規模化に伴うパフォーマンスの劣化」や「運用管理の複雑さ」「障害発生に備えた代替経路確保の煩雑さ」といった問題点に再び直面せざるをえなくなったのである。

イーサネットファブリック――仮想化/クラウド時代のL2ネットワーク

 サーバー仮想化の急速な普及を受けて、課題解決のための有力なアプローチとして注目されたのがイーサネットファブリック(Ethernet Fabric)である。

 ファブリックという考え方自体は以前からあり、特にFC-SAN(Fibre Channel Storage Area Networking)の分野では当たり前に利用されている。イーサネットファブリックはSANの世界のFCファブリックと同様の環境をイーサネットでも実現しようとしたものであり、FC-SANスイッチの分野をリードしてきたブロケード コミュニケーションズ システムズが最初に製品化に取り組んだのもいわば必然の流れであった。

 従来のイーサネットは、個々に独立したスイッチ/ルータに個別に設定を行い、全体で一貫した動作を実現するための整合性の維持は運用管理者の努力に期待するといったアーキテクチャだった。これに対し、ファブリックでは複数台のインテリジェントなファブリックスイッチが仮想的に統合された1台の論理スイッチを構成するイメージとなる(図3)。

図3:従来のイーサネットとイーサネットファブリックの比較(出典:ブロケード コミュニケーションズ システムズ)

 ループ経路の存在が許容されなかったスイッチ間の接続経路は論理スイッチ内部に存在する“論理的な内部バス”といった扱いになるため、ファブリックスイッチの機能によって制約を取り払うことができる。実際にファブリックではスイッチ間をメッシュ状に接続しておき、複数の経路を並列的に利用することで帯域拡大を図りつつ、障害発生時には代替経路として活用するのが標準のトポロジーとなる。

 ネットワークの帯域の拡大は、シンプルにファブリックスイッチを追加することで実現でき、かつ特別な設定を必要としないため、運用管理面での負担は大幅に軽減される。ノード数が多くなりがちな仮想サーバーのための大規模なL2フラットネットワークを実現するためには理想的なネットワークアーキテクチャだと言える。

 このように、イーサネットファブリックは仮想サーバーの利用拡大に伴ってアーキテクチャの変革をいわば余儀なくされたデータセンターネットワークの新たなソリューションとして注目されたのだが、その後出現したSDNが急速に注目を集める中でやや地味な位置づけになっていた感も正直なところある。

 イーサネットファブリックはL2の物理層のアーキテクチャなのに対し、SDNはより上位のソフトウェアレイヤの話ではある。したがって、本来は独立して扱うべきものだが、ユーザーから見た場合の大きなメリットとして「運用管理負担の軽減」という要素が共通するためか、結果として後から登場したSDNがより新しいソリューションとして注目されるようになった面もあるかもしれない。とはいえ、SDNがある程度の落ち着きを見せつつある現在、物理層のあるべき姿として、あらためてイーサネットファブリックに注目が集まる状況ができてきたようだ。

目下の課題は、ネットワークのビッグデータ対応

 現在、ブロケードはイーサネット・スイッチの分野でも急速に存在感を高めている。同社によると日本国内のデータセンターネットワークのシェアでは僅差で2位につけた調査結果もあるとのことで、FC-SANだけでなく、イーサネットインフラでも主要ベンダーの一角を占める存在に成長している。そんな同社が、FC-SAN分野の豊富な経験を生かして他社に先駆けて実現したのがイーサネットファブリックだということになる。

 同社によれば、イーサネットファブリックはデータセンターを中心に着実に普及しつつある段階だという。その背後には、ビッグデータ対応をはじめとするデータ量/トラフィックの増大があり、増え続けるトラフィックを効率よくさばくためにも従来型からファブリックへのネットワークインフラの進化が必要とされているということだ。

 ビッグデータというとIoT(Internet of Things)に代表されるような各種センサーネットワークによる自動的なデータ生成を受け続けるようなシステムが思い浮かぶが、そうしたデータ収集を行うユーザーのみに関係する特殊な要件というわけではない。デジタルカメラやスマートフォンによる動画撮影など、今では誰もが大量のデジタルデータを日常的に生成する状況になっていることから、メールサーバーやファイルサーバーのストレージ消費は増大する一方だ。

 しかも、データ量が増えるのと歩調を合わせ、ネットワークの帯域も拡大しないとデータの移動がままならない。見落としがちだが重要な着眼点として指摘されたのが、分散型ストレージの問題だ。

 ストレージの分野では従来型の大規模RAIDボックスの代わりに大量のIAサーバーを配置し、各サーバーに内蔵されたHDDを仮想統合することで巨大な分散ストレージとして使用するシステムが普及し始めている。容量拡張がしやすいスケールアウト型ストレージを安価に構築できることで注目を集めているのだが、サーバー間の接続はイーサネットで行うため、ネットワークの見直しが必要になるケースもあるようだ。

 分散ストレージではデータ喪失を避けるためにデータのコピーを複数のサーバーに分散させる。コピーの数は信頼性の設定によるが、3重コピーくらいはごく普通に行われる。これは例えば、ストレージに1GBのデータを保存しようとした場合、内部的には3GBのデータに増量されるわけだし、かつ分散ストレージを構成する多数のサーバー間に分散して記録するための大量のトラフィックが発生するということである。

 「ネットワークに新たなサーバーノードを追加するだけで容量と処理性能をリニアにスケールアップできる」というのがこうした分散型スケールアウトストレージの謳い文句だが、その接続先となるネットワークには相当な拡張性が求められ、現実的にはイーサネットファブリックのようなインフラが望ましいということになる。

ファブリックの進化

 クラウドやSDNが急速に進化を続けていることもあり、ファブリック側の進化も続いている。まずは、運用管理面での統合が進行しつつある。運用管理負担の軽減という目的はいずれのソリューションも共通して掲げるところであり、それぞれがバラバラに取り組んだ結果組み合わせが複雑化するという状況は避けたいところだ。結果的には最上位に位置づけられるクラウドオーケストレータ(※注1)に対応し、これらから制御できるようなインタフェースを用意するというかたちで統合が進んでいるのが現状だが、イーサネットファブリックも同様だ。

 ちなみにブロケードでは、オープンソースのSDNコントローラ開発プロジェクトである「OpenDaylight」や、クラウドオーケストレータのOpenStackを積極的にサポートしており、これらと同社のファブリックインフラをスムーズに統合できるよう対応を進めている。図4は、Brocade OpenStackプラグインを用いて、OpenStackによるクラウドオーケストレーションにイーサネットファブリックを対応させたイメージだ。

 また、同社独自の取り組みとしては、マルチテナント対応を容易に実装できるようにするための「Brocade VCS(Virtual Cluster Switching)Virtual Fabric」や、ハードウェアサポートによるオーバーレイ型ネットワーク仮想化への対応強化がなされているのが先進的な取り組みと言える部分だろう。

図4:Brocade OpenStackプラグインを用いた、OpenStackクラウドオーケストレーションへのイーサネットファブリックの対応(出典:ブロケード コミュニケーションズ システムズ)

 一方で、やや地味な感もある対応としては、従来10Gbpsを中心に対応が進められてきたファブリックスイッチのポート対応に1Gbpsや100Mbps対応が追加されている点が挙げられる。これは一種の後方互換性確保の取り組みだが、現在イーサネットが使われているすべての領域をファブリックでカバーできるようにする、というカバレッジ拡大の取り組みと位置づけることができるだろう。現在のファブリックは一部の先進ユーザーが選択するやや特殊な環境、というイメージもあるが、将来的にはイーサネットと言えば当然ファブリック、という状況に転換する可能性もないとは言えない。

 SDNをベースに考えた場合、特にオーバーレイ型のネットワーク仮想化を活用する場合は下層のネットワークインフラは特に変更せず、既存のものをそのまま使うことができる、と言う点が優位点としてアピールされることが多い。そのため、オーバーレイ型のネットワーク仮想化技術を導入すればネットワークの物理インフラについては特に何も考えなくてもよい、と誤解してしまいがちだが、そうではない。最終的にネットワークの能力は物理インフラで規定されるため、仮想化によって運用管理や構成変更が容易になったとしても、帯域幅の拡大や耐障害性の向上といった要件にソフトウェアのみで対応するのは無理がある。実際には、仮想化による柔軟性を最大限に生かすためには堅牢で拡張性に優れた物理インフラが存在することが大前提となる。上位レイヤでのソフトウェアベースのサービスの導入に比べれば、物理インフラの更新や新規導入は時間を要するが、今後数年間の更新タイミングでイーサネットファブリックの導入を検討することはデータセンター事業者にとってもユーザーにとってもいわば必須の要件となってくるのではないだろうか。

※注1:コンピュート、ストレージ、ネットワーキングのクラウド構成要素を標準のコンポーネントとインタフェースからプロビジョニングするオーケストレーション・フレームワーク。OpenStackやCloudStackなどの仕様がある)

(データセンター完全ガイド2014年春号)