エントリーを書き始めたら前置き部分だけでちょっと長めの文章となってしまったので、グダグダ感は多少ありますが…公開しちゃいます…。最近、Blogエントリー書けていなかったもので…。3月に1つもエントリーも公開していないってのも…寂しいな、とm(_ _)m
Hypervisorにおける仮想スイッチはその名の通り、論理的な(ソフトウェア)スイッチです。基本的には、L2レベルでEthernetフレームをスイッチングする処理を行います。VLANタグの付加や取り外し、トラフィックシェーピング、QoS制御、ACLコントロール、SPAN/RSPAN等々、様々な機能を提供していることもありますが、とはいっても基本はMACアドレスに基づく通信制御を行うことこそが役割といえます。そういう意味では、物理スイッチと物理サーバの関係性をそのままソフトウェア化したものが仮想スイッチと仮想マシンの関係、ともいえます。
物理サーバのみでシステムのインフラ基盤が構成されていた時代、当然サービスを提供する窓口となる「表」のネットワークは上位スイッチ側に結線されて通信が行われていましたが、たとえばフロントエンドのWeb/APサーバとバックエンドのDBサーバを繋いだり、バックアップサーバと各サーバを繋いだりといった「裏」のネットワークは、(実装方式としては物理的／論理的なバリエーションはあるにせよ)いわゆる表側のネットワークとは区分されて「閉じた」ネットワークとして構成されていました。物理サーバは物理的、つまりは「静的」に存在していますので、ある日突然接続先のスイッチが変化するなどといったことは基本的にはほぼないという前提でシステムを構成することができていたわけです。
しかし仮想化がインフラ基盤に組み込まれることがもはや標準となった現在では、仮想マシンは物理的な制限を超えて、(構成された範囲で、ではありますが)自由にサービスを止めることなくホストサーバ間を移動できることが当たり前となりました。このように動的となったインフラ基盤においては、いわゆるバックエンド用のネットワークもサーバの動的な移動に追随して(継続して)使用できる様にするために、フロントエンド用のネットワークと同じように上位スイッチ側に向けて構成し、仮想マシンとなったノードがどこの物理サーバホスト上に移動しようともネットワークへの接続性を維持できるように構成する必要がでてきたわけです。このため、同じ論理構成のシステムを構築するとしても、物理サーバのみで構成する場合と仮想サーバのみ(もしくは、仮想サーバを含む混在)で構成する場合とでは、分類に必要となるVLAN数は(これまで隔離されていたためにVLAN IDが重複していたとしても問題がなかったり、スイッチローカルのポートVLANで事足りていたり、またはVLANによる論理分割を必要としなかったネットワークもそれぞれ区分できるように構成する必要があるために)非常に多く必要となり、さらには動的な移動に追随してネットワーク接続性を維持し続けることができるように設計する必要が出てきたわけです。
このように、全てのネットワークを表側に向けて構成するようになると、意外と多くのネットワークが必要となってきます。VLANの制約は約4000、1システムを構成するネットワークがそれぞれ10ずつ必要だったとすると400システム分、ということになりますのでかなりの大規模な統合基盤でない限りは問題になることはなさそうに思えますが、実際に4000個のVLANを構成して実運用に耐えるレベルで動作することができるスイッチは多くはありません。また、その規模の場合に全てのスイッチでVLANを通してMACアドレスを学習させるような使い方はあまり良いとはいえなさそうな気がします。もしくは、Private VLANを活用する、という方式も考えられますが、Private VLANはIPサブネットとVLANを分離することはできても結局はVLAN数の制約を突破するものではありませんし、CommunityとIsolateだけでの区分の仕組みは実装しようとしてみると柔軟性があるとはあまりいえません。
こうした課題に対処するために、物理サーバの枠を超えて一元的に管理できるスイッチ機能として分散仮想スイッチが登場し、さらにはL2ネットワークをL3を超えて拡張できるようにVXLANなどのオーバーレイな仕組みが登場してきました。仮想マシンが移動した際に仮想マシン／ゲストOS側の構成を変更することなくネットワークに対する接続性を維持させるためには、どうしてもL2ネットワークを拡大・延伸していく必要があったためです。
このようにL2フラットなネットワークが拡大・延伸されていったとしても、IPサブネット構成としてはそのままであれば、L3レベルの論理的なネットワークとしては「そのまま」で物理的な制約の枠を広げたこととなります。このようにネットワークが横に*1極端に広がったため、これまで特定の物理スイッチの中だけで完結していた通信も仮想マシンの配置状況によっては透過的に(ゲストOSとしては認識しないかたちで)多数のスイッチや場合によってはルータをも超えて通信していることになっている可能性もあるわけですし、さらにはL3-L7のサービスを実装する方式についてもこれまでとは異なる対応が必要となってきます。
現在、L2のみならずネットワークに拡張性と柔軟性を組み入れていく方式は様々な実装方式が乱立しています。
- スイッチ間通信にルーティングの概念を持ち込むFabric的な実装
- 既存ネットワーク環境そのままでも実装を進めることができるOverlay方式のL2拡張
- VXLANやNVGRE、STTなど
- スイッチングやルーティングと行った概念を超えてのフローベースやポリシーベースでの通信制御
- OpenFlowやCisco OnePKなど
- データセンター間のL2延伸と位置ID情報のIPアドレスからの分離
これらは理由があって仕様や実装が定められ、これまでネットワークが抱えていた制約や限界を突破するためにこれらの仕組みは生み出されたわけですが、それぞれが一長一短、メリットデメリットがあり万能な解決策や突破口があるわけではありません。
…などと、つらつらと書いていたらだいぶ大風呂敷を広げたエントリーになってしまいました。あまりに長いエントリーを書いてもなんですので、今回は次回へのエントリー編、ということでこのあたりまでとしたいと思います。
次回からは反動ではないですがこまかいちょっとした機能(でも重要なポイント)に焦点を当てたエントリーを書いていきたいと思います。まずは、拡張されて動的になったL2に対応するためのL3以上の機能実装まわりについて書く…つもりではいます。
次回予告編は…そうですね、このあたりのYouTube動画をご覧下さいませ。どこかのアニメの予告編のように、まったく違う展開を迎えるかも、ですけれども！(^_^;)
