vExpert Advent Calendarも2週目に突入。ちっともやり遂げられるかどうか、ネタが続くのかどうか、どちらも自信がありません！(^_^;) さーて、そんな先の不安なひとまず置いておいて、今週もいってみましょう！
そもそも、自律分散というネットワークの仕組みはよくできている
SDNやらOpenFlowやらが流行って？きて、なんだか『旧来のネットワークはもはや古くて、SDNこそが新しいネットワークだ』的な風潮がちょっとあるような気もするのですが、実際のところは今までのネットワークのままで特に困っていない場合も多いのではないでしょうか。各ネットワークデバイスが他に依存することなく「それぞれが自律的に動作」しつつも「標準化プロトコル仕様に基づいて情報交換をする」ことなどによって非常に小規模なものからインターネットのような世界規模のものまでもの「面としてのネットワーク通信を成立させている」という仕組みは、改めて考えてみると とてもよくできていると思います。管理・使用上におけるシングルポイントが存在しませんし、ルールにさえ則っていれば、誰かが全体を把握して管理する必要がない、という仕組みであったからこそ、ネットワークは成り立ってきたのです。きっと、多くのネットワークがこれからも、10年後も、これまでの方法で管理されていくことになるでしょう。
しかし唯一、自律分散よりも集中管理の方がメリットが大きくなる場合がありうるネットワークが「データセンターにおけるネットワーク」です。なぜならば、データセンターにおけるネットワークは「サーバ仮想化に追随する『柔軟性』」と「インフラ基盤をささえる『可用性』」、さらには「個別管理というよりも全体管理のための『自動化』」などのニーズと必要性が高くなる使い方も増えつつあり、これらの課題を解決するためには、自律分散よりも集中管理の方が適していることもあるからです。
では、どうやってネットワークは集中管理すればいいのでしょうか？ネットワークにおいては「つながり」の技術ですので管理ツールそのものよりも、集中管理を実現するための方法が注目を集めています。本エントリーではOpenFlowやonePKなどという方法もありますが、今回はそれらはおいておいて<(_ _)>オーバーレイプロトコル、という方法について考えていきたいと思います。
オーバーレイプロトコルをどう使うのか
オーバーレイプロトコルはその名の通り、物理ネットワーク*1への依存を断ち切って、どんなネットワークトポロジーであろうとも疎通を可能としようとするやり方です。たとえESXiホスト間のセグメントが分離していようとも、仮想スイッチ(VTEP / Virtual Tunnel End Point)間でトンネルを張ることによって論理的なL2接続を構成します。粗い言い方をしてしまえば、物理ネットワークには単純にIPレベルでの相互到達性だけを求め、それ以外はすべて論理的なオーバーレイプロトコルで集中管理を実現しよう、という方式です。
オーバーレイプロトコルは仮想スイッチにおける実装から始まり、CiscoのNexus 1000VやVMwareのvCloud Network & Security (vNS)におけるVXLAN対応や、Microsoft Hyper-V / System Center Virtual Machine Manager (SCVMM)におけるNVGRE対応、旧NiciraのOpen vSwitch拡張のSTT対応などがよく知られている実装例かと思います。しかし別にオーバーレイプロトコルは仮想スイッチのためだけの仕様ではありませんので、物理スイッチや各種物理ネットワークデバイスにおける対応も現在は各ベンダーが対応を進めています*2。
仮想スイッチでのオーバーレイプロトコル
仮想スイッチを中心としてVXLANなどのオーバーレイプロトコルを使用する場合、基本的には仮想マシンに対して「物理ネットワークに依存しない」論理ネットワークを提供することになります。メリットとしては、仮想マシンを管理する管理ツール自身を使ってサーバ仮想化とネットワーク仮想化の両方をまとめて管理できる点でしょう。インフラを構成しているサーバが全て(もしくはその大半が)仮想マシンなのであれば、管理ポイントが1箇所となり、論理的なサーバとネットワークを一元管理することが可能となります。ただし、このネットワークに物理サーバが接続したり、そもそもオーバーレイとなっていないネットワークとの接続点としては、ゲートウェイを配置してオーバーレイとアンダーレイを結びつける必要があります。少なくとも1箇所にはかならずゲートウェイとなる箇所を構成する必要があるはずです。
また、物理ネットワークに依存しないとはいえ、物理ネットワークがなくてはオーバーレイネットワークも成り立ちませんし、最終的にはオーバーレイネットワークの性能は物理ネットワークに依存することとなりますので、仮想スイッチでのオーバーレイネットワークを使用する場合であってもその下の物理ネットワークにはファブリックネットワークが推奨されます。確かに、すべてのパスがアクティブで、ネットワーク自身がその機能として冗長性や可用性を担保するファブリックネットワークは、オーバーレイネットワークに足りない部分を補完して安定した物理ネットワークを提供する構成として、最適といえるでしょう。
物理スイッチでのオーバーレイプロトコル
物理スイッチを中心としてVXLANなどのオーバーレイプロトコルを使用する場合、自身ではオーバーレイプロトコルをしゃべらない物理サーバをオーバーレイネットワークに自然に組み込むことができますが、逆に仮想スイッチの扱いについては対応が必要となります。なぜなら、仮想スイッチが存在している場合、物理スイッチがVTEPとなってしまうと仮想スイッチがあるために仮想マシンまでのステップができてしまうからです。最も単純な対応方法は、物理サーバに対しては物理スイッチが、仮想マシンに対しては仮想スイッチがVTEPとなる構成をとることですが、その場合はどのように物理スイッチと仮想スイッチの両方に対して統合的な管理を実現するか考慮する必要がありますし、VTEPに対応した仮想スイッチも合わせて用意しなければならないということになります。
ただ残念なのは、現在VXLAN対応をうたっている物理スイッチにおけるVXLAN実装のほとんどが、VXLAN-VLANゲートウェイとしての役割であることです。物理サーバをVXLANに組み込むために必要な機能ではあるのですが、物理サーバのためのVXLANオーバーレイネットワークへの出入り口としての役割だけではあまり価値を出せていない使い方であるような気がしています。また、物理スイッチにおけるVXLAN実装はブリッジング機能のみが搭載されており、分散ルーティングには対応していません。
オーバーレイプロトコルと分散スイッチング／分散ルーティング
ここまでで見てきたように、オーバーレイプロトコルは基本的に論理的にL2ネットワークを構成する技術です。オーバーレイプロトコルを使用する上で分散スイッチングは必須というわけではありませんが、実際には分散スイッチングを構成する仮想スイッチ＝Hypervisorについて、物理ネットワークへの接続構成を制限しないための仕組みがオーバーレイプロトコルであるともいえます。このように、分散スイッチングとオーバーレイプロトコルは相性が非常に良いというか、基本的には組み合わせて使う仕組み同士であるといえるでしょう。
対して、分散ルーティングは一見すると、オーバーレイネットワークによってせっかく物理ネットワークにおけるL3境界を越えてL2ネットワークを広げたのに、そこにL3境界をわざわざ持ち込む仕組みとも言えるわけですが、分散ルーティングなきオーバーレイネットワークは「論理的に分離されたオーバーレイネットワークのセグメント間で通信したい場合は、いったんどこかのゲートウェイを通じてルーティングされて折り返されてこなければならなくなる」わけで、こちらもまたオーバーレイネットワークを使用するのであれば必要な仕組みともいえるかと思います。
必要なのはオーバーレイプロトコルそのものではない
さて、ここまでオーバーレイプロトコルについて書いてきたわけですが、そもそもの原点に立ち返ってみると、ユーザにとってはオーバーレイプロトコルを使うこと自体は目的ではありません。変な言い方ですが、オーバーレイプロトコル自体に価値があるのであれば、すでに数年前にVXLANが登場した時点で、多くのユーザが飛びついていたはずです。しかし実際には、多くのユーザがすでにVXLANを使用してはいますが、データセンターにおけるネットワーク構成において主流にはまだなってはいません。冒頭に書いた通り、オーバーレイプロトコルは集中管理を実現するための手段です。オーバーレイプロトコルを仕組みとしてどう活用するか、ということが重要です。そしてさらに書けば、『オーバーレイプロトコルを活用して何をしたいのか』こそが最も重要な点といえます。
次回は、オーバーレイプロトコルと集中管理を組み合わせることによって、どんなことが可能となるのか、という点について書いてみたいと思います。はたして、次回はどうなるのでしょうか？^_^;
vExpert Advent Calendar 明日は、データセンタークイーン^_^; こと @mihiguch さんのBlog 『インフラエンジニアあるある日記』 です！
