こんな夜中にOpenFlowでネットワークをプログラミング!:第1回 OpenFlowって何だ!?|gihyo.jp … 技術評論社

OpenFlowが注目される背景

OpenFlowが注目される理由を説明するには,ネットワークの仮想化を説明する必要があります。ネットワークの仮想化という言葉に正式な定義はありませんが,世の中では「1台のネットワーク機器を複数の機器に論理分割する」「複数のネットワーク機器を1台のネットワーク機器として扱えるようにする」という意味で利用されることが多いようです。

クラウドが普及するにつれてネットワークの仮想化が重要視されるようになりました。図2は1つのプラットフォームを複数のテナントで共用する例です。ネットワーク機器ごとに仮想化の設定が必要となるため,設定ミスの増加が懸念されます。また,仮想化の世界では設定ミスがプラットフォームを共有する他社に影響を及ぼす可能性があり,設定変更を従来よりも慎重に行う必要があります。

図2 既存のネットワーク仮想化技術の課題

図2 既存のネットワーク仮想化技術の課題

仮想化のもう一つの特長に「仮想サーバが物理サーバ間を移動する」があります。そして,仮想サーバの移動に合わせてネットワーク側の設定も変更する必要があります(図3)。仮想サーバが移動した場合,最低でも仮想スイッチやL2スイッチのVLAN設定を変更する必要があります。他にも仮想スイッチのQoS(Quality of Service)設定の変更や,移動前に仮想スイッチに蓄えられたトラフィックなどの統計情報をクリアし,移動先の仮想スイッチに付け替える処理が必要です。

クラウド利用者は意識することは少ないと思いますが,クラウド運用者には従来よりも複雑な保守/運用が要求されています。このようにネットワークの仮想化は多くの課題を抱えていますが,これらの課題の大部分を解決可能なOpenFlowに注目が集まっています。

図3 ライブマイグレーション時の課題

図3 ライブマイグレーション時の課題

OpenFlowの基本動作

ここからはOpenFlowの基本的な動作について説明します。OpenFlowは「OpenFlowスイッチ」と「OpenFlowコントローラ」の2種類で構成されます。OpenFlowスイッチは自身に投入されたフローエントリと呼ばれるルールに沿って動作します。OpenFlowコントローラはOpenFlowスイッチにフローエントリを書き込みます。OpenFlowスイッチとOpenFlowコントローラ間は「OpenFlowプロトコル」により情報をやり取りします。OpenFlowスイッチとOpenFlowコントローラ間はTCP/IPで通信します。よってスイッチとコントローラ間にL2スイッチなどのネットワーク機器が存在しても問題ありません。

より具体的なイメージを持っていただくため,図を用いて説明します。図4はOpenFlowを動かすための最小構成の例(注4)です。図4で示すとおり,OpenFlow スイッチはOpenFlow コントローラから投入されたフローエントリを保持しています。サーバ1はOpenFlowスイッチの1番L1ポートに接続されており,サーバ2は2番L1ポートに接続されています。管理L1ポートはOpenFlowスイッチがOpenFlowコントローラと通信を行うために利用する特別なL1ポートです。図4を用いて,いくつかの通信パターンを説明します。

図4 OpenFlowの最小構成例

図4 OpenFlowの最小構成例

注4)
話が複雑になるので最小構成で説明しますが,本来は1つのOpenFlowコントローラで複数のOpenFlowスイッチをコントロールします。

サーバ1からサーバ2にHTTPリクエストを送信する場合

サーバ1からサーバ2上で動作するWebサーバに対してHTTPリクエストを送るパターンを考えてみます。HTTPなので送信先L4ポート番号は80番です。OpenFlowスイッチはサーバ1から送信されたHTTPリクエストを受け取り,そのパケットがフローエントリのヘッダフィールドにマッチするか調べます。HTTPリクエストはサーバ1から送信されているので「L1ポート番号=1」になります。また,送信先ポート番号はHTTPなので「送信先L4ポート番号=80」になります。以上により,このパケットは1番のフローエントリ(図4でNoが1であるフローエントリ)にマッチすることがわかります。1番のフローエントリのアクションを見ると2番ポートからパケットを送信すればよいとわかるので,OpenFlowスイッチはHTTPリクエストをサーバ2に転送します。

サーバ1からサーバ2に対してPingを送信する場合

続いて,サーバ1からサーバ2に対してPing(ICMPエコー)を送信するパターンを考えてみます。サーバ1から送信されたパケットなので「L1ポート番号=1」になり,Pingなので「プロトコル種別=ICMP」になります。以上により,2番目のフローエントリにマッチすることがわかり,OpenFlowスイッチはアクションに書かれたとおりパケットを破棄します。

サーバ2からサーバ1に対してPingを送信する場合

それではサーバ2からサーバ1にPingを送信した場合はどうなるのでしょうか。サーバ2から送信されたパケットなので「L1ポート番号=2」となりますが,OpenFlowスイッチは「L1ポート番号=2」にマッチするフローエントリを持っていません。この場合,OpenFlowスイッチは管理L1ポート経由でOpenFlowコントローラに受信したパケットをどのように制御するべきか問い合わせます。問い合わせを受けたOpenFlowコントローラはOpenFlowスイッチにフローエントリを新たに書き込み(注5),パケットをどのように制御するかOpenFlowスイッチに指示します。

OpenFlowスイッチにどのようなフローエントリを書き込むかはすべてプログラムにより自由に制御できます。OpenFlowスイッチはフローエントリが書き込まれると,有効期限が切れるまでその情報を保持し続けます。よって,再びサーバ2からサーバ1にPingが送信された場合,OpenFlowスイッチはOpenFlowコントローラに問い合わせることなしにパケットを制御できます。

注5)
フローエントリを書き込まずにパケットを処理することも可能ですが,ここでは説明しません。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中