SDNの現在位置と新たなアプローチ　データセンターネットワーク最新動向

仮想サーバー環境でのネットワーク運用状況

　ハードウェア面での取り組みとして、まず、新しいネットワーク規格の導入による高速化が主な手段として挙げられる。Ethernetの進化は着実に進んではいるものの、現時点でのLANの主流は10ギガビットEthernet（10GbE）で、この速度が主流になって久しい。また、用途によっては1GbEもいまだに現役で活用されているところもあろう。

　サーバー接続に関して言えば、サーバー仮想化の広範な普及によって、ネットワークインタフェースに対する要求も多様化していった。物理サーバーを仮想化し複数の仮想サーバーに分割して活用する場合、ネットワークインタフェースも高速なポートが1つあるよりも、低速でも多数のポートを確保できるほうが使い勝手がよいという事情からだ。10GbEまではともかく、その上の40GbEや100GbEといった規格になると価格が跳ね上がる。そのため、むしろ低価格な1GbEを複数利用して各仮想サーバーに確実に帯域を割り当てるやり方のほうが一般的だと思われる。

　仮想サーバーの成り立ちからして当然ではあるが、データセンターに多数収容されるWeb系のサービスを稼働するサーバー個々に要求されるパフォーマンスレベルはさほど高いものではない。このことは、物理サーバーのプロセッサ処理能力を複数の仮想サーバーに割り当てても問題なく対応できていることからもわかる。ネットワーク接続に関しても同様で、WAN経由でアクセスしてくるユーザーが期待するレベルのレスポンスが実現できればよく、際限なく高速化する必要に迫られることはない。

並列化を軸とした運用面での工夫改善が必要

　一方で、HPC（High Performance Computing）やビッグデータ分析処理などの用途ではサーバー間で大量のデータのやりとりが発生する場合があり、ここでは現状のネットワーク帯域では足りないという状況も生じている。ただし、Apache Hadoopが広く使われている状況を見てわかるとおり、こうした分野でも分散化／並列化によって現実的な解決を目指す方向が主流であり、物理層を高速化することで正面突破を目指すような状況にはなっていない。

　Ethernetの規格自体の進化は今後も継続するものの、技術的には飛躍的な高速化はもう望めそうにない。実際に提案されている高速規格を見ても既存規格を内部的に複数束ねて十分な総帯域を確保する手法がほとんどだ。そのため、並列化を軸とした運用面での工夫改善で帯域幅の確保を行っていくというアプローチが当面続くものと考えられる。

Ethernetの制約を回避する試み

　Ethernetファブリックは、もともとは「STPを排除する」ことで注目されたネットワークアーキテクチャである。STP（Spanning Tree Protocol）は、Ethernetで禁止されているループ経路を発見し、当該経路を遮断することでネットワークの正常性を保つプロトコルである。そもそものEthernetがシンプルなアクセスコントロール機構やブロードキャストによるアドレス解決（ARP）などによってデバイスの複雑化を回避し、低コストで高速なネットワークを実現することに主眼に置くため、こうした制約が生まれることになった。

　Ethernetのループ経路禁止の制約は、現在のLAN環境においては「並列化による帯域確保が困難」という問題につながる。サーバー接続の際にも、万一の機器故障に備えてあらかじめ複数のネットワーク接続を用意しておくことは一般的な手法と言える。しかし、例えば1台のサーバーに対して2本のEthernetケーブルを接続した場合、この2本を同時に有効にはできない。禁を破ってループ経路を構成してしまうことになるからだ。

　そこで、STPを用いて一方を遮断し予備経路としておき、メインの経路に何らかの障害が生じて通信不能になったことが検出された際には、STPによって予備経路の遮断が解除され、回線の切り替えが行われるという仕組みが生まれた。

　この仕組みは、バックアップという観点では正しい動作だが、リソースの有効活用という観点からすれば「存在するリソースの半分しか活用できていない」無駄があることになる。

　上述したようにEthernet規格自体の高速化が技術やコストの面から困難になった今、比較的安価に導入可能な1GbEや10GbEを複数本束ねて帯域拡大を図る手法が検討されるが、単純に複数のインタフェースを接続するだけでは帯域拡大にはならないのである。

Ethernetファブリックのメリット

　こうしたEthernetの仕様上の制約を回避し、複数経路を同時に使えるような手法はないだろうかという検討がなされた。そこで、新たなベンダー独自仕様として製品化されたのがEthernetファブリックである（図4）。

図4：従来のEthernetとEthernetファブリックの比較（出典：ブロケード コミュニケーションズ システムズ）

　メッシュ状に構成したネットワークのすべてのリンクを活用して負荷分散や耐障害性の向上につなげるというEthernetファブリックの手法は、Ethernet以外のネットワークではむしろ普通に行われていることだ。例えば、この分野の製品化で先行したブロケード コミュニケーション システムズは、SANスイッチの技術を応用してEthernetファブリックを実現している。

　わかりやすく言うなら、インテリジェントなスイッチを用いることで、STPを使わずにループ経路がネットワークの健全性を損なうことを避け、複数の経路を同時併用できるように制御しているということだ。逆に言えば、スイッチに実装された独自機能であるため、基本的には単一ベンダー製品で統一された環境でないとEthernetファブリックを構成できないという問題がある。

　つまり、マルチベンダー環境にはならないのだが、環境が統一されるメリットのほうを取れば複数のスイッチを仮想的に統合して1つの巨大な仮想スイッチのように見せることができる。これによって運用管理が簡素になり、スイッチの追加によってネットワークのトポロジーがどう変わるかといった問題に煩わされることなく、シンプルに「スイッチを追加すれば利用可能な総帯域が拡大する」という発想で、スケールアウト型拡張が実現できるようになる。

Ethernetファブリックの制約

　このように、Ethernetファブリックのメリットは明快で、エンタープライズユーザーを中心に導入事例も多い。特に仮想サーバーを多数運用する環境や、SDNによるオーバーレイネットワークを構築するような環境では、下層の物理ネットワークをEthernetファブリックとすることで十分な帯域を確保しつつ運用管理の負担を増大させないシンプルなL2ネットワークを実現できるメリットが評価されている。

　しかし、Ethernetファブリックにもいくつかの制約があり、特に大規模な事業者での採用が進まない理由ともなっている。最大の制約は、ファブリックを構成できるスイッチ数に上限が存在することだ。これは、スイッチの追加をシステム側で自動的に認識するなどの仮想統合による運用管理の簡略化機能が提供されていることからも容易に推測できることだが、無制限に規模を拡大していくことはできない。ベンダーや製品仕様によって異なるものの、おおよそ数十台規模で上限に達する。

　もちろん、各スイッチに実装されているポート数を掛け合わせて算出される総ノード数は相当な規模に達する。そのため、一般的なエンタープライズユーザーの環境でスイッチ数の仕様上の上限がシステム規模の制約となった例はないというのがベンダー側の主張だ。大規模クラウドサービス事業者のネットワークの規模はそれこそエンタープライズユーザーとはケタが違うレベルであり、早々にEthernetファブリックは採用できないという結論が出たようだ。

　一方で、経路を並列化できるメリットなどには捨てがたいものがあることから、ハイパー／メガスケールのクラウドサービス事業者がそれぞれ独自の工夫で実装を試みたのがIPファブリックということになる。

IPファブリックの特徴

　IPファブリックを理解するうえでのポイントは次の2つである。

1.特定のベンダー／特定の技術による実装ではなく、インターネット標準に基づいてユーザー側で実装されたものである
2.仮想サーバーの実用化以来、ネットワークの大前提となっていたL2ネットワークの制約がついに取り払われている

　IPファブリックという名称からもうかがえるとおり、基本的な実装はIP層（L3）から上のプロトコル群によって行われている。ループ経路を正しくハンドリングできないのはEthernetの仕様上の制約であり、これはL2でネットワークを構築する際には避けて通ることができない大問題となるが、ネットワークをL3にすればいろいろな解決策が生まれてくる。実際に、L3で経路制御されているWANの世界では複数の経路を同時に運用して帯域確保を行いつつネットワーク全体の耐障害性を高めるという手法が普通に行われている。

　そして、複数存在する経路のうちのどこにパケットを通すかという判断のために各種のルーティングプロトコルが存在し、これによって問題が生じないように制御できる仕組みがすでに確立されている。IPファブリックでは、こうしたインターネット／WAN環境で運用されている技術を、従来LAN技術でカバーしてきたサーバールーム内部まで持ち込むことでL2ネットワークに起因する制約を取り払った格好だ（図5）。

図5：IPファブリックの概念図。レイヤ2スイッチングではなくL3ルーティングでファブリックを構成（出典：ジュニパーネットワークス）

大規模ネットワーク発のアプローチ

　IPファブリックはその確立にあたって、特定ベンダーによる開発や標準化団体による規格制定といったプロセスを経たわけではない。グーグルやフェイスブックなどのハイパースケール企業が、自分たちが必要とする環境を自力で構築したという経緯から生まれた技術だ。したがって、「これがIPファブリックだ」と言えるような定義や典型例があるわけではない。強いて言うなら“フェイスブック流”“グーグル流”“マイクロソフト流”といったいくつかのパターンを示せるといった程度の大まかな分類になる。

　そのような経緯から、各社がそれぞれ自社の環境を詳細に公表しているとは限らず、多少情報が古かったり、独自のノウハウの部分が秘匿されていたりする可能性もある。おおむね共通する要素としては、サーバーの直前のところまでL3でパケットを制御する仕組みをとり、サブネットの粒度はラック単位からサーバー単位までいろいろなパターンがあるようだ。

　こうすると、サーバールーム内に膨大な数のネットワークが並列し、それが網の目状に複雑に相互接続されている状況ができあがるが、実のところこの状況はインターネットのありようそのものだとも言える。

　つまり、IPファブリックは、L3ネットワークを採用することで従来の技術では明確に分かれていたLANとWANの境界をなくし、サーバールームの内部もインターネットと同じ技術、同じ手法で接続／管理していくアプローチだととらえることができよう。

典型的なパターンとしては、ファブリックを構成するスイッチをそれぞれ独立したAS（Autonomous System：自律システム）と位置づけ、BGP（Border Gateway Protocol）でルーティングする仕組みとなる。ファブリックの拡大はASの追加であり、これはインターネット上で日々行われていることそのものだ。ゆえに、規模の上限としては「現状のインターネットと同等規模まで問題なく拡張可能」という考え方になる。事実上、サイズの上限は無制限だと言ってよい。

最大の課題は複雑な運用管理

　IPファブリックにはEthernetファブリックに比べて明らかに劣っている点もある。それは運用管理性の部分だ。

　ベンダー固有の運用管理インタフェースが提供されるEthernetファブリックでは、ファブリック全体をあたかも単一の仮想スイッチであるかのようにシンプルに管理することが可能で、構成の詳細は隠蔽されることになる。逆に、IPファブリックの場合はスイッチをASとして動作させるために個々に正しい設定を行わなければならないなど、構成の詳細を正しく理解しつつ適切な運用管理を行う手間が避けられないのである。

　つまり、後発の技術としてEthernetファブリックのいくつかの欠点を解消してはいるものの、それを完全に置き換えられるわけではない。企業の場合、現状、IPファブリックを必要とするのは、標準的なエンタープライズネットワークの規模を越える大規模な環境を抱える大手企業に限られるだろう。

　一方で、データセンターやクラウドサービス事業者の場合は、規模によってはIPファブリックの導入でかなりのメリットを得られると考えられる。実際、IDCフロンティアは2016年7月下旬に発表した事業戦略の中で「Data Centric Cloud」というコンセプトを掲げてシームレスなデータ利用を重視するネットワークを構築するという方針を明らかにしている。その際、一環としてIPファブリックの導入を表明している。

　このとき同社は「CLOS Fabric」という用語を使っているのだが、IPファブリックに「CLOS Fabric」という呼称を与えたのはジュニパーネットワークスだと言われている。Ethernetファブリック製品も手がけてきた同社は、データセンターネットワークの次の姿として、L3ルーティングの利点に着目したIPファブリックの実装に積極的に取り組んでおり、顧客企業のネットワークでの導入支援などを行っている（図6）。

図6：データセンターネットワークはEthernetファブリックからIPファブリックへ（出典：ジュニパーネットワークス）

「L2接続を放棄する」か否か

　IPファブリックに関して最後に残る問題は、L2接続を放棄するという点だ。そもそもL2接続によるネットワークがこれほどまでに利用されるようになったのは、サーバー仮想化が広範に普及し、仮想マシン（VM）を動作中のまま別のサーバーに移動できるライブマイグレーション機能が活用されるようになったためだ。

　ライブマイグレーションでは、サーバーの状態を一切変更せずに別の物理サーバー上にVMを移動させるために、IPアドレスも変更せずに使い続けられなくてはならない。しかし、IPアドレスは内部にネットワーク部を含んでおり、つまり同じIPアドレスを使い続けるためには同じネットワーク内にとどまっている、すなわちL3境界を越えずにL2の範囲内にとどまっている必要がある。このため、サーバー仮想化の利用拡大に伴ってサーバー接続のためのネットワークがL2のままで大規模化する状況に陥ったという経緯だ。

　この制約を回避してL3ネットワークでもよいという形になれば多くの問題が解消できるわけだが、現状では、あれこれ工夫してL3に移行するよりもL2を維持するほうがまだましという考え方が主流だ。

　IPファブリックでは、仮想化のためにL2を維持することは放棄し、L3への移行を前提とする。その結果、仮想サーバーのライブマイグレーションはそのままでは行えないという問題があるが、この点に関しては、前半で述べたオーバーレイ型ネットワーク仮想化を組み合わせることで問題を回避することができる。

　ライブマイグレーションの前後で仮想サーバーをホストする物理サーバーがL3境界を越えていたとしても、オーバーレイネットワークによるトンネリングを活用することでIPアドレスを変更することなく運用を継続することが可能になる。もちろんシステム的には複雑になるし、どこでトンネリングを行うかによっては耐障害性にも影響が生じるだろう。

　物理サーバー間でトンネルを構築する場合には、物理サーバーが障害を起こしてダウンした場合にはトンネルが切断されてしまうリスクがある。スイッチ側でトンネリングの処理を行えば耐障害性という観点からはサーバーよりは安心だが、スイッチがトンネリングに対応したものである必要が出てくる。

　こうして、さまざまに制約があることから、仮想サーバーの柔軟な運用を第一に考えるのであればやはりIPファブリックよりもL2ネットワークを維持するほうが手間はかからないと思われる。判断のポイントは、サーバーファームとしてどのくらいの規模が必要かという点であり、Ethernetファブリックや従来型のL2ネットワークで足りる規模であればそのまま、その制限を超える規模まで拡張するのであればIPファブリックに移行という判断が成り立つ。

　IPファブリックの実用化は、米国ではここ数年でほぼ完成の域に達しつつあると見られている。こうした動向を受けて、日本国内では今年に入ってからにわかに脚光を浴び始めているという状況だ。データセンター事業者やクラウドサービス事業者が今後のネットワークアーキテクチャを考える際には、新たに検討すべき選択肢として無視できない存在になってきたと言える。