を見て、OpenDaylight についてすっかり忘れていたので、ざっくりと SDN から記憶を辿って調べ直してみました。
目次
OpenFlow の登場
SDN (Software Defined Network) という言葉が流行るきっかけになったのは、OpenFlow スイッチの登場からだったと思います。
従来はネットワークの物理線の接続を変更したり、ネットワークスイッチにログインしなければ、構成変更できなかったネットワークを、複数のOpenFlow スイッチに命令を行い、パケットのフローを変更してしまう事で物理接続されたネットワークの上に仮想的なネットワークを構成する事ができるようになりました。
ただ、もともと VLAN には、タグ VLAN という考え方があって、同じスイッチポートを流れるパケットでも、同じタグのついたパケットを同じ仮想ネットワークに所属するパケットとしてグループわけを行い、別々のネットワーク宛てのパケットとして取り扱う事ができました。
ある意味、これも「仮想ネットワーク」だったと思います。ただしこういう設定を行うには、各スイッチにログインして設定を行う必用がありました。物理結線を無視して設定しても当然意味のない設定になってしまいますので、物理結線を見ながら、各スイッチの設定を行っていきます。
OpenFlow では複数のネットワークスイッチを統合的に管理する「コントローラー」を設け、「コントローラー」から各スイッチを一括管理する事で、物理ネットワーク結線とは別に、その上に仮想ネットワークを作り出せるようになりました。「SDN (Software Defined Network)」という言葉を生み出したのは、こうした背景があります。
「コントローラー」は各スイッチを構成する機能ですが、もともとはこの機能はネットワークスイッチの筐体の中に、一緒に埋め込まれていたものです。
従来のネットワークスイッチから「コントローラー」の機能を分離して外に取り出したイメージになります。同時に「コントローラー」機能を取り出されたネットワークスイッチは、データを流す器（うつわ）として「データプレーン」と呼ばれるようになりました。
OpenFlow は、Nicira Networks という会社により開発され、ONF (Open Networking Foundation) によって標準化されています。
Nicira Networks は後に、VMware に買収されます。
OpenFlow スイッチの特徴で大きなものは、複数の 「OpenFlow スイッチ」をとりまとめる「OpenFlow コントローラー」が必用になります。
「Open Flow コントローラー」は、各「OpenFlow」スイッチに命令を出す事で、「OpenFlowスイッチ」間で結ばれた物理ネットワーク上に、物理構成に縛られない仮想的なネットワークを作り出す事ができます。
こららの SDN の動きは、既存の Network 機器ベンダーからは歓迎されませんでした。なぜならば、ベンダー独自の技術で囲い込んでいたものが、オープンな規格に取って変わられる事は、ネットワーク機器のコモディティ化を招き価格破壊に繋がると思われたからです。
この時点で大規模なデータセンターなどでは、x86サーバーの多くが「ホワイトボックス」と呼ばれる、IBMやHPやDELL等のサーバー以外の「無印」のサーバーが、幅を利かせるようになっていました。これらのサーバーの基本チップはコモディティ製品で構成されており、付加価値を入れて独自色を出す事が難しくなっていました。ネットワークベンダーは同様な事が、ネットワーク機器の世界で起きるのを恐れていたのです。
2011年に NEC が世界初の商用 OpenFlow Switch をリリース
OpenFlow の開発自体は Nicira という USのスタンフォード大学発のベンチャーで行われていましたが、OpenFlow の商用スイッチをいち早くリリースしたのは日本のNEC でした。2011年3月でした。
当時は OpenFlow は日本が一番熱狂している。という雰囲気もあったと思います。
2011年に NTT Data の方が作られている、こちらの JANOG の資料を見ると、当時の OpenFlow の開発状況とユースケースが垣間見られます。
上記の JANOGの資料の OpenFlow のユースケースが良くまとまっているので、そのまとめ方をお借りすると
- マルチテナント対応 (クラウド環境のネットワークをテナント毎に分離）
- ライブマイグレーション対応 (仮想マシンのサーバー筐体間の移動のためのネットワーク構成）
- 運用自動化 (各ネットワークスイッチにログイン、マルチベンダー毎のコマンドの違いによる運用負荷の回避）
- 帯域の有効活用 (スパニングツリーで発生するブロッキングポートを作らないためポートが有効活用できる）
等が OpenFlow の活用方法としてあげられています。
2012年4月に Google は DataCenter 間のネットワークを、OpenFlow で管理している事を発表しました。
Google の事例は DC間の接続ですが、当時は OpenFlow のユースケースは、DC内 / 外 の周辺が想定されていました。が、当時 DataCenter 事業者と会話していた筆者としては、実際に DataCenter での使用はまだ時期尚早と思われていた雰囲気もありました。DC内のネットワークは、ある程度テンプレ化されており、人手で十分管理できる。というのが大半の感触でした。
OpenFlow の父と言ってもよいであろう Casado 氏は、メディアのインタビューで OpenFlow の DC内での使用について以下のような事を語っています。
Casado氏 私は（OpenFlowによるトラフィックステアリングとは）違うSDNを推進することになりました。「OpenFlow自体について騒ぎ立てることには意味がない」と、早くから言っていました。WANやキャンパスネットワークならいいですが、データセンター内においてOpenFlowを（トラフィックステアリングに）使うことは意味がないと、早い時期に気付きました。また、物理スイッチを制御するのは複雑すぎると判断しました。
当時の OpenFlow の事例として有名なのは、東京駅の構内ネットワークの事例だと思います。
現在でも東京駅の工事は続いてますが、拡張、変化し続ける当時の東京駅のネットワーク構成を集中管理で自由に変更できるという、ユースケースとしてはとてもフィットした事例に見えました。
このシステムは 2015年10月時点で、山手線の全駅に拡張された事が発表されています。
駅以外にも、ビル内のネットワークもテナントの入れ替わりによってネットワーク機器の増強や構成変更が必用で需要がありそうな気がするのですが、どうなんでしょう。
ハイパーバイザー上の仮想スイッチによる SDN
一方で世の中は VMWare が席巻しており、物理サーバー上には、VM(仮想マシン) がたくさん起動しており、それらの VMware はサーバー上の同じネットワークにぶら下がっているという構成が一般的でした。
そして、同時に異なる物理サーバー上の VMのネットワークを VLAN を通して物理的に同じネットワークに所属させる。と言う方法も多くの場合必須の構成として一般的に行われていました。
この構成が行われていたのは、例えば、ある物理サーバー上の VM を無停止でもう一つの物理サーバー上に移動させる vMotion を使用するためでした。サーバーのメンテナンスというのは必ず発生するもので、その際に VM を止めないで別の筐体に逃がしてあげる事ができる機能が vMotion でした。
VM を停止させてないで、移動させるためには、移動前と移動後で当然同じネットワークセグメントに所属していなければいけないため、2つの物理サーバー間を VLAN で結んで同じ 「192.168.10.xxx」のようなネットワークに所属させておくという事がテンプレの構成として一般的に行われていたのです。
2009年5月 VMware が vDS を vSphere 4 で発表
異なる物理サーバー筐体を L2スイッチを介して物理的に接続されていますが、一つのスイッチのポートにぶら下がる全てのサーバー筐体が同じネットワークに所属するという事は、贅沢すぎて通常ありません。
2つの物理サーバー筐体がつながるポートを同じネットワークして構成するには、ネットワーク管理者に連絡して、各サーバーが繋がっているネットワークスイッチのポート同士を同じネットワークになるように VLAN を設定してもらわないといけません。
サーバー上で新しい VMware のネットワークを作るのは VMware の管理者が vCenter という管理ツールを作ってできますが、そのネットワークを隣の筐体まで延伸するには、サーバーの外に設置されたネットワークスイッチの管理者に連絡し、設定を変更してもらわないといけません。ただし想像がつくように管理者が分かれるこの作業を行うには、時間がかかります。
ここでもネットワークの構成をソフトウェアで簡単に変更したい。という需要があり、vSphere 上で稼働するソフトウェアとしての仮想スイッチと、コントローラーが生み出される事になります。
VMwareは、2009年5月に発表した、vSphere 4から、筐体間をまたいで仮想スイッチを構成する vDS (vSphere Distributed Switch) を提供しはじめました (vSphere 4.0の新機能)。
vDS は、vSphere がインストールされた筐体上で稼働する仮想スイッチです。
複数のvDS は、vCenter という管理ソフトで一括構成されるようになっていました。OpenFlow と同じように「コントローラー」＋「データプレーン」の構成で言うと vCenter は「コントローラー」にあたります。
vSphere 上にインストールされた仮想スイッチ(vDS) 間は、トンネリングで結ぶ事であたかも一つの仮想スイッチとして動作する事ができます。物理的には分散しているものの、仮想的な一つのスイッチとして動作するのが vDS です。
一方の仮想ネットワークから外にパケットが出る時は、そのパケットは仮想スイッチによってカプセル化が行われます。そして筐体をまたいで、相手の仮想スイッチに届いた時にカプセル化が解除され、相手の仮想ネットワーク無いの指定された宛先にパケットが届きます。
サーバーの箱同士は、同じL2セグメントに所属していなくても、ネットワークの疎通さえ取れていれば問題なく、トンネリングにより同じネットワーク (192.168.10.xxx のような）として取り扱えるようになったのです。
VMware は VXLAN と呼ばれるトンネリング方式を使用していました。
2012年2月 Nicira が NVP を発表
一方で、2012年2月に Nicira は、NVP (Nicira Network Virtulaization Platform」を発表します(記事)。
NVP は、コントーラーとなる「NVP Controller Cluster」と「Open vSwitch(OVS)」で構成されていました。
OVS は、Xen, KVM, ESXi 等のハイパーバイザー上で動作する仮想スイッチとする事で、NVP はプラットフォームに縛られないソフトウェアとして登場しました。ここが VMware との大きな違いです。
各物理サーバー上のハイパーバイザー上で動作する OVS を、NVP Controller で一括に変更する構成で、これも「コントローラー」＋「データプレーン」の典型的なアーキテクチャーに沿ったものです。
Nicira が使用した方式は GRE (Generic Routing Encapsulation) と呼ばれる方式で、これは Nicira が開発したものでは無く、既にある技術を OVS 間のトンネリングに活用したものでした。
また Nicira 独自の STTというトンネリング方式もサポートしていました。
トンネリングにおいては、パケットのカプセリング / カプセリング解除がオーバーヘッドとなり通信速度を落としてしまうのは技術的な必然でしたが、STTはパフォーマンスをあまり落とさずにトンネリングを行う事ができるとされる技術でした（記事)。
VMware の vSwitch は、VMware の世界だけで閉じたものでしたが、ここで Nicira がハイパーバイザー関係無く統合的に操作できる製品が登場しました。
AWS を含め多くのクラウドベンダーは、Xen を使っています 。現在もマジョリティかどうかはわかりませんが、仮想化ハイパーバイザーとしては、KVMよりも Xen の方が早く立ち上がったため、パブリッククラウドでは、Xen 一般的でした。
つまりこの時点で、Nicira のソリューションは、OpenFlow だけでなく、マルチ・ハイパーバイザー上の仮想スイッチをカバーする事で、パブリッククラウドとオンプレの領域をカバーするソリューションだったと言って良いと思います。
2012年7月 VMware が Ncira を買収
個人的には Nicira が Open化の流れを掴んで、マジョリティになるのかな。と思っていましたが、意外な事に 2012年7月に VMware は Nicira を買収します（記事）
買収された製品は「VMWare NSX」という形で VMware 製品に統合されていきます。
2013年4月 ミドクラが MidNet を発表
一方で日本発の SDN ソリューションである ミドクラ社の MidNet という製品 ( オープンソース化 )という製品もこの時期に登場しています。
当初は DataCenter 内の仮想ネットワークを目指していましたが、2019年6月にソニーセミコンダクターソリューションズに買収されており、発表内容から見ると IoTデバイスを結んだ仮想ネットワークの方向性を想定しているようです。
2013年6月 IBM が IBM SDN for VMware Edition を発表
SDN の将来性を考えると、他のベンダーもこの領域に乗り込んで来ないわけはなく、IBM は 2013年6月に SDN VE for VMware Edition という製品で VMware 環境で使える SDN 製品を発表しました。
さらに、2014年2月に OpenFlow、KVM の環境に対応したバリエーションを追加します（OpenFlow はコントローラーのソフトのみを提供。OpenFlow スイッチは一般的なものを使用する想定）
これらのコントローラーは、OepnStack Neutron の API に対応したため、OpenStack 経由で VMware / KVM という異なるハイパーバイザー環境を統合的に管理できるようになりました。
VMware が引っ張るのは VMware 環境に依存した製品、一方 IBM が目指したのは、全プラットフォームに対応した垣根の無い製品でした。
Nicira が VMware に取り込まれた事で、今後、Openなアーキテクチャーに寄り添った SDN はIBMが引っ張っていくかと思われましたが、2014年1月に IBM は、x86アーキテクチャーで動いていたソフトウェア製品群と x86サーバーのHWビジネスを Lenovo に売却する事を発表し、事実上これらの製品はディスコンされる事になります。
2013年9月 Juniper が OpenContrail を発表
Juniper が 2013年9月に OSS プロジェクトとして OpenContrail を発表します。OSS としてソースを公開しながら、商用版も販売するというスタイルです。
Contrail は、「Contrail SDNコントローラー」と「Contrail vRouter」という2つのコンポーネントから構成されます。KVM と Xen をサポートする形で登場しました。
仮想スイッチの役割をする vRouter 間 (正確には vRouter フォワーディーングプレーンというカーネルスペースの機能) をトンネリングで結ぶ方式ですが、トンネリングの方式として、「MPLS over GRE」「MPLS over UDP」「VXLAN」をサポートしていました ( Contrail Architecture）
2018年3月に OpenContrail は、Juniper から Linux Foundation へホストが移管され、「Tungsten Fabric (タングステン･ファブリック)」とプロジェクト名を変えています（記事)
「Tungsten Fabric」 をベースにした Juniper の商用版は、Contrail という名前を引き続き使用しています。
2015年1月 OVN (Open Virtual Network) が発表
Linux 等で採用されている OVS (Open vSwitch) のサブプロジェクトして OVN が立ち上がりました (アナウンス)
データプレーン上の制御対象としてはOVSを採用し OVS をコントローラーが統括して管理する方式です。
OVS が前提なので、OVS が採用さている KVM や Xen 等での使用がターゲットでした。(と当時はまだ開発中だった Hyper-V 用の OVS)
コントローラーと CMS (Cloud Management System) をつなぐプラグインとして OpenStack 用のプラグインから開発がはじまりました。現在では Kubernetes 用のプラグイン (ovn-kubernetes) なども存在 (まだ開発中？）しています。
2019年2月に OVS とはレポジトリが分割され、単独プロジェクトになっています。
ホップ･バイ･ホップとオーバーレイ方式
SDNのアーキテクチャーは大きく二つに分かれます。
ホップ･バイ･ホップ方式
OpenFlow のようにスイッチに入って来たパケットを一つ一つ見て、そのパケットに適合するルールに従って次の宛先に送り出す方式を「ホップ･バイ･ホップ」方式と呼びます。
オーバーレイ方式
VMware の vDS や Nicira の NVP のように、物理的に独立したL2ネットワークを、一つのL2 ネットワークに見せるために、L2ネットワーク間をトンネリングで結ぶために使用されます。
L3ネットワーク上に仮想の L2 ネットワークを作成する事から「オーバーレイ方式」と呼ばれます。また L2ネットワークを、遠くへ伸ばす事から「L2延伸」という言葉も良く使われます。
トンネリングで使用されるカプセリングの方式としては、以下のものがあります。
- VXLAN (Virtual eXtensible Local Area Network) - VMware が VMware 製品の中で使用。
- NVGRE (Network Virtualization using Generic Encapsulation) - Microsoft が Hyper-V 等で使用
- STT (Statless Transport Tunneling) - Nicira が自社製品で使用。VMWare NSX に引きつがれる。
- Geneve (Generic Network Virtualization Encapsulation) STT に変わるものとして VMware NSX-T で採用
OpenDaylight プロジェクト
SDN の流れの中で、いろいろな SDN 技術が登場してきました。
様々な SDN コントローラーや、外部からコントロール可能なネットワーク機器を統一的に扱いたい。とは誰しも思う所であります。
OpenDaylight は、そう言った装置に対する共通のインターフェイスを作成しようという OSS プロジェクトです。
共通のインターフェイスは「Open Daylight API」と呼ばれる REST API 群です。
この REST API 群によって、
- OpenFlow Enabled Device (スイッチ）
- Linux 等で使用されている仮想スイッチである 「Open vSwitch」
- その他のソフトウェア、物理デバイス
を制御できるようになります。
例えば、OpenFlow の場合は、OpenDaylight API の要求を、OpenFlow Controler の命令にフォーマットを変換するようなプラグイン（ドライバー的なもの）を作成する事で、OpenDaylight API しか知らないエンジニアに OpenFlow スイッチを構成させる事ができるようになりました。
OpenDaylight API から見ると、異なる種類の仮想スイッチも同じように取り扱える必用があります。それを実現するのが SAL (Service Application Layer) になります。
もちろんこうした抽象化によって、各ソフトウェアユニークな機能というのは、見えなくてなってしまう。というデメリットもあります。
OpenDaylight 自体も「SDNコントローラー」であり、各種 SDN の「コントローラー」を同じ方式で扱えるように見せるための「コントローラ－」になります。
SDN の現在
2020年時点で、SDN 関連の記事もみかけなくなっています。
個人的には SDN の世界が一つの共通アーキテクチャーができ、誰でも簡単に使えるように広く広まっていくのかな。という想像をしていたのですが、技術的な課題があった所に、適切な SDN 技術が使われ、あえてそれらの技術を統一する必用も無かった。という事なのかなと思います。
一方で、Google Trend け検索ワードとしての人気を見ると、2011年の8月にピークを見せた後、2020年2月に至るまで意外と落ち込みを見せていません。
無くなってはいないが、使われるべき所では辺り前に使われる技術として、脈々と継続している。と言う事が想像されます。
