SDNの基本動作とアジャイルな開発が可能なSDN実装、「Trema」：TremaでSDNを手のひらに（1）（1/2 ページ）
IT関連イベントや勉強会などで注目を浴びたSDN/OpenFlow。この記事では「Trema」を例に、自分の手で実際にOpenFlowを「いじってみる」のに必要な情報を解説していきます。
SDN/OpenFlowとはどんなモノか
IT関連イベントや勉強会などで万能の釜（聖杯）のように語られ、注目を浴びたSDN/OpenFlow（もっとも近頃では、日本でのSDN/OpenFlow注目度のカオスさは収まり、落ち着きが出てきましたが）。いったいSDN/OpenFlowとはどんなモノなのでしょうか。
「SDN/OpenFlow」と記載していますが、まずはSDNとOpenFlowを分けて紹介していきます。
SDNとはざっくり言うと、「ソフトウェアからネットワークを制御しよう」という仕組みです。
この仕組みは、ソーシャル系サービス（Facebook、Google、Twitterなど）において、ユーザープログラムから各サービスを利用するためのAPIが提供されている状態に似ています。最近はソーシャル系サービスだけでなく、Amazon Cloud（AWS）やNIFTY CloudなどのクラウドサービスでもAPIを提供するなど、エンジニア（プログラマ）がインフラ資源を制御できるAPIが提供されるという流れがあります。SDNもこの流れに乗って、ネットワークにもAPIを付けたイメージと考えればよいでしょう。
OpenFlowは、SDNを実現する技術の1つです。けっして「SDN＝OpenFlow」ではなく、SDNの中にOpenFlowが含まれる形になります。もちろん、OpenFlow以外のSDN実装の名前がすぐに思いつかないぐらいに「SDN＝OpenFlow」というイメージが世の中に浸透しているのが実情ですが、OpenFlowはあくまでSDNの一形態である点は忘れてはいけません。
なお、「SDN＞OpenFlow」であるにもかかわらず、「SDN＝OpenFlow」のような印象が強く浸透しているのは、いくつかあるSDN実装の中で、OpenFlowはオープンな標準技術である点が大きな要因だと考えられます。OpenFlowはベンダ依存の規格ではなく、各社からの意見を取り入れたオープンな規格で、仕様策定と規格の標準化はONF（Open Networking Foundation）と呼ばれる非営利団体によって進められています。
オープンな仕様である特徴を持つという意味で、OpenFlowは、現在世界で広く利用されているオープンソースOS、Linuxによく似ています（その登場がカオス的な注目を浴びている点も含め、似ているように思います）。現時点で、Linux界におけるRedHat的な存在が生まれてくるかどうかは不明ですが、期待されているのも事実です。
以上、まずはSDN/OpenFlowがどういったものなのかをざっくり紹介しましたが、すでにOpenFlowに関する情報はネット上にあふれるほど存在しています。そこで、「OpenFlowが注目される背景」などの解説は飛ばして、SDN/OpenFlowを自分の手でいじってみるための前準備に入りたいと思います。
SDN/OpenFlowをいじってみる前に
やはり「OpenFlowを知るために、ネット上の情報を読むだけでなく、実際にOpenFlowをいじってみたい」と思うエンジニアは多いのではないでしょうか（私自身、実際にいじってみないと納得できないエンジニアの1人だったりします）。
そこでここでは、OpenFlowをいじる前に、最低限押さえておきたい情報をまとめてみます。
OpenFlowでできること、できないこと
OpenFlowに関する解説記事を読むと、そのメリットとしてしばしば、「従来のネットワークが抱える問題点（4096個のVLANしか作成できない制限）が解決できること」「同一IPが複数存在できること」などが紹介されています。しかし、それらがOpenFlowの持つ機能のすべてというわけではありません。
例えば、VLANの制限問題については「VXLAN」などでも対応可能で、OpenFlow以外にも解決手段が存在します。そもそもOpenFlowは、そのような制限を解決するためだけに存在するわけではありません。
OpenFlowは、VLANの制限や、同一IPが複数存在してはならないといった従来のネットワークの制約を受けない「柔軟なネットワークをソフトウェアで実現できる」ことに意味があります。
ここで「ソフトウェアで実現できる」と記載したのにはわけがあります。OpenFlowは、次の項の「OpenFlowを構成する2つの要素」で紹介するように、ソフトウェアが存在しなければ実現できないからです。ネットワーク機器の箱だけを用意すれば、この「柔軟なネットワーク」が実現できるわけではない点に留意してください。
OpenFlowを構成する2つの要素
繰り返しになりますが、OpenFlowはソフトウェアでネットワークを制御する仕組みですので、ネットワーク機器以外に、制御を行うためのソフトウェアが存在します。このソフトウェアは「OpenFlowコントローラ」と呼ばれ、OpenFlowに対応したスイッチを「OpenFlowスイッチ」と呼びます。
OpenFlowコントローラは、従来のネットワーク機器におけるアドレス学習、ルーティング、経路制御、帯域制御などの処理を行います。一方OpenFlowスイッチは、パケットの伝送処理を、主にOpenFlowコントローラの指示に従って実施する箱になります。いわば、頭と手のような関係です。
このOpenFlowコントローラとOpenFlowスイッチがOpenFlowを構成する2つの要素です。そして、これら2つの要素をつなぐプロトコルが「OpenFlowプロトコル」ということになります。
OpenFlowコントローラ
OpenFlowコントローラは、OpenFlowがオープンな仕様ということもあり、さまざまな実装が公開されています。
主だったものだけでも、「Trema」「NOX」「POX」「Floodlight」などが挙げられます。それぞれ利用できるプログラミング言語が異なりますので、自分の得意なプログラミング言語が利用できるものを選択すればよいでしょう。なお、Floodlightは標準でREST APIを提供しており、言語への縛りが緩いため、プログラミングに抵抗がある人にも利用しやすいかもしれません。
| 名前 | プログラミング言語 | 開発元URL |
|---|---|---|
| Trema | C、Ruby | http://trema.github.com/trema/ |
| NOX | C++ | http://www.noxrepo.org/nox/about-nox/ |
| POX | Python | http://www.noxrepo.org/pox/about-pox/ |
| NOX-Classic | C++、Python | https://github.com/noxrepo/nox-classic/wiki |
| Floodlight | Java（REST API） | http://floodlight.openflowhub.org/ |
OpenFlowコントローラにプログラミング言語がひも付けられるのには理由があります。ここで紹介したOpenFlowコントローラは、正確には「プログラミングフレームワーク」と呼ぶべきものであり、「OpenFlowを扱うためのライブラリ群」と言った方がイメージしやすいでしょう。本来のOpenFlowコントローラは、ユーザーが作成したプログラム本体に当たります。
OpenFlowスイッチ
OpenFlowスイッチとは、すなわちネットワーク機器本体です。基本的には、ネットワーク機器ベンダから提供されるOpenFlow対応の機器を利用します。OpenFlowスイッチには物理スイッチ以外にも仮想スイッチもあり、OpenFlow対応仮想スイッチとしては「openvswitch」が有名です。
Copyright © ITmedia, Inc. All Rights Reserved.