作成日 | 2014/5/2 |
---|---|
更新日 | - |
SDN/OpenFlowとは?
SDNとはSoftware-Defined Networkingの略であり、ソフトウェアでネットワークを定義することを示します。これはネットワークを構成するためのシステムアーキテクチャとなります。従来のネットワーク機器はネットワークの機能を定義するためのソフトウェアとパケット転送などの処理を行うハードウェアで構成されますが、ユーザが制御できるのは機器ベンダが開発したソフトウェアにて提供される設定用のユーザインタフェースのみとなります。ハードウェアを制御するためのAPIは非公開であるため、機器ベンダ以外が満たしたいネットワークの機能を独自に定義できませんでした。
図 1 ネットワーク機器に対する外部操作
この非公開となっていたAPIを標準化したものがOpenFlowです。これまでは機器ベンダが提供するネットワークの機能(L2スイッチやL3スイッチなど)のみをユーザが活用してネットワークを設計する必要がありましたが、ハードウェアを制御するためのインタフェースの公開によりそれ以外の機能もユーザが独自に開発することが可能となります。さらにハードウェアとソフトウェアを分離できるようになり、ネットワークを制御するコントローラを外部化することにより一元管理することも可能となります。
図 2 OpenFlowによるハードウェアとソフトウェアの分離
サーバ機器がメインフレームからオープン化されたことにより、ベンダ独自の規格で垂直統合されて開発に時間を要する状況から、標準的な規格で水平分散されて次々と新たな技術要素が登場するようになりましたが、SDN/OpenFlowによりそれと同じような変革がネットワーク機器でも起ころうとしています。
図 3 サーバとネットワークにおけるオープン化
OpenFlowの標準化に関する歴史を以下に記載します。標準化団体ONF(Open Networking Foundation)のボードメンバ(2014年4月時点では、Deutsche Telekom、Facebook、Goldman Sachs、Google、Microsoft、NTT Communications、Verizon、Yahoo)が最終的な意思決定して仕様が策定されます。ボードメンバはユーザ企業や学術関係者を中心に構成されており、機器ベンダがボードメンバに含まれていないことから、開発者の視点よりもユーザの視点を重視した仕様策定が行われる体制であることがわかります。
表 1. OpenFlow標準化の歴史
時期 |
OpenFlowの標準化動向 |
---|---|
2008年~ |
米Clean Slate Programの中で、スタンフォード大学を中心に提唱され、OpenFlowスイッチングコンソーシアムとして研究開発が進む |
2009年12月 |
OpenFlowプロトコル1.0 (標準化) |
2011年2月 |
OpenFlowプロトコル1.1(標準化) MPLS Tags/Tunnels、Multi-Tablesなどに対応 |
2011年3月 |
Open Networking Foundation設立 |
2011年12月 |
OpenFlowプロトコル1.2(標準化) IPv6、フローマッチング柔軟化、コンフィグなどに対応 |
2012年4月 |
OpenFlowプロトコル1.3(標準化) Cookie、メータなどに対応 |
OpenFlowの基本動作
OpenFlowで制御されるネットワークは、OpenFlowスイッチ、OpenFlowコントローラにより構成され、スイッチとコントローラ間はOpenFlowプロトコルでやりとりされます。
図 4 OpenFlowを構成する3つの要素
OpenFlowスイッチに接続されるサーバや既存のネットワークからパケットが送信されると、以下の流れで宛先までパケットを転送されます。
1. OpenFlowスイッチのポートにパケットが到達する。
2. OpenFlowスイッチは自身が保持するフローテーブルから該当のパケットに対する制御ルールを検索します。
3. フローテーブル上に該当する制御ルールが見つからなかった場合は、OpenFlowスイッチはOpenFlowコントローラに対して制御ルールが見つからなかったことを通知します。
4. 通知を受信したOpenFlowコントローラは該当のパケットに対する制御ルールを生成します。
5. 制御ルールに基づいて、OpenFlowコントローラはそのパケットを経由させるOpenFlowスイッチに対して送信します。
6. 制御ルールを受信したOpenFlowスイッチはフローテーブルに制御ルールを格納し、パケットを制御ルールに従って宛先まで転送します。
7. 次回以降のパケットはOpenFlowスイッチのフローテーブルに既に制御ルールが存在することから、OpenFlowコントローラは関与することなくOpenFlowスイッチのみでパケットが転送されます。
図 5 OpenFlowにおけるパケット転送の基本動作
これは、OpenFlowコントローラによるリアクティブ型のパケット転送の一例となります。OpenFlowスイッチを経由して通信される内容が事前に把握できている場合は、パケットの到達まで待機することなくOpenFlowコントローラから制御ルール(フローエントリと呼ばれます)をOpenFlowスイッチに事前に設定しておくプロアクティブ型のパケット転送も可能です。
OpenFlowスイッチのフローテーブルには、
・パケット(OpenFlowではフローと呼ばれます)を識別するためのヘッダフィールド
・マッチしたフローに対するアクション
の組み合わせであるフローエントリが格納されています。OpenFlowスイッチが受信したパケットのヘッダ情報は、フローエントリのヘッダフィールドと比較され、もし該当するフローエントリが存在する場合はそのフローエントリに定義されたアクションが実行されます。
表 2. OpenFlow 1.0で利用可能なヘッダフィールド
レイヤ |
ヘッダフィールド |
---|---|
レイヤ1 |
イングレスポート(物理ポート番号) |
レイヤ2 |
送信元MACアドレス、宛先MACアドレス、イーサタイプ、 |
レイヤ3 |
送信元IPアドレス、宛先IPアドレス、IPプロトコル、ToS |
レイヤ4 |
送信元ポート/ICMPタイプ、宛先ポート/ICMPコード |
表 3. OpenFlow 1.0で利用可能なアクション
アクション |
説明 |
---|---|
Forward |
パケットを指定したポートに転送する。 (OpenFlowプロトコルでカプセル化して、管理ポートからOpenFlowコントローラに転送することも可能) |
Drop |
パケットを破棄する |
Enqueue |
パケットを指定したキューに格納する(オプション) |
Modify-Field |
パケットのフィールドを書き換える(オプション) |
HinemosによるOpenFlowネットワークの管理
OpenFlowではフローエントリという制御情報をOpenFlowスイッチが保持しており、そのフローエントリはOpenFlowコントローラから一元的に管理できます。ネットワークの健全性を担保するため、OpenFlowスイッチおよびOpenFlowコントローラの状態把握とフローエントリの整合性の確保が非常に重要となります。
従来からのスイッチの管理
スイッチの死活状態、搭載されたメモリ消費量、トラフィック処理量、ポートのLink Up/Down、その他のハードウェア故障を把握する必要があります。HinemosではSNMPなどの標準プロトコルで実装された監視機能を提供しており、複数のベンダで構成されたネットワークに対するこれらの運用管理の効率化を実現します。
OpenFlowスイッチ特有の管理
penFlowスイッチ特有のリソースであるフローテーブルの状態変化・フローエントリ単位でのトラフィック処理量、OpenFlowコントローラの死活状態・CPUやメモリなどのリソース消費量、OpenFlowスイッチとOpenFlowコントローラの接続状態などの把握も重要となります。Hinemosのオプション製品の1つである「Hinemos仮想ネットワーク管理オプション」により、これらの情報を単一のコンソールから管理可能となり、ユーザはOpenFlowで組み上げられたネットワークの健全性を担保できます。
OpenFlowによる自動化運用
また、ユーザ自身がOpenFlowプロトコルの全容を把握し、フローエントリを作成することはネットワーク運用上の負担を増大させるだけでなく、ネットワーク構築や運用のコストの増大にもつながります。その課題に対して、「Hinemos仮想ネットワーク管理オプション」では、OpenFlowスイッチにより構成されるアンダーレイネットワークと、ユーザが必要とする論理ネットワークをOpenFlowコントローラが自動的にマッピングして、そのマッピングに基づくフローエントリを自動的に生成します。そのため、ユーザは必要とするネットワークセグメントやルーティングテーブルなどを論理ネットワークとしてOpenFlowコントローラに設定するだけでよく、従来のようにL2スイッチやルーターの冗長化などを意識することすら不要となります。
OpenFlowの利用形態の一つであるネットワーク仮想化により、Opex(運用コスト)の削減に成功した企業が増えてきています。ネットワークの簡素化、運用の非属人化に関する詳しい情報は「ネットワーク仮想化特集」へ。
関連情報
お問い合わせ