第3回　ネットワーク業界の地殻変動、そして次世代のクラウドへ

はじめに

OpenFlowはネットワークの動作をプログラムにより制御できる技術です。今回はOpenFlowが業界に与えるインパクトや、クラウドへのOpenFlow の適用例について説明します。

OpenFlowが業界に与えるインパクト

OpenFlowが業界に与えるインパクトを説明するため、まずは従来のスイッチとOpenFlowスイッチの違いを説明します。

従来のスイッチは、1台のスイッチの中にパケット伝送機能、パケット制御機能、設定機能が実装されています（図1⁠）⁠。一方、OpenFlowではパケット制御機能と設定機能がスイッチから分離されOpenFlowコントローラに集約されるため、複数のスイッチの一元管理が可能になります（図2⁠）⁠。

OpenFlowの世界では、OpenFlowのスイッチの動作やスイッチとコントローラ間の通信はすべて標準で規定されるため、各ベンダが販売するOpenFlowスイッチ間に大きな機能差はなくなります。このようなネットワーク機器の標準化の動きを「ネットワーク機器のオープン化」と呼びます。サーバのオープン化によりメインフレームの大部分はIAサーバに置き換わりました。ネットワーク機器も、OpenFlowによりコモディティ化が進む可能性があります。

従来のネットワーク機器販売ビジネスは、ハードウェアの調達やプロトコルスタックの整備が必要で、ソフトウェアベンダが容易に参入できる分野ではありませんでした。しかし、OpenFlowが市場に浸透すると、ソフトウェアベンダでもOpenFlowコントローラの開発を行い、ネットワークビジネスに参入することが可能になります。また、OpenFlowコントローラの設定をGUI化すれば、ベンダごとに異なる機器設定を覚えずに、絵を描く要領でネットワーク構築や設定変更ができます。このように、一般的なネットワーク知識さえあれば誰でもネットワーク設定を安全に実施できる環境が整うと、ネットワーク構築ビジネス自体が縮小していく可能性もあります。

OpenFlowは運用を劇的に変えるかもしれま

せん。第2回で説明したとおり、OpenFlowはスイッチの三重化、四重化が容易なため、ネットワーク機器を多重化しておき、故障してもスイッチの交換はしないという「運用保守レス」も可能です。

OpenFlowでは、OpenFlowコントローラがすべてのネットワーク制御を行います。よって、サーバ側からOpenFlow コントローラ経由でネットワークをオンデマンドに変更するような新しいサービスも実現できます。

OpenFlowに対してはさまざまな見方が存在しますが、筆者は、従来のネットワーク機器では不可能であったサービスを実現し、サービス全体の付加価値を向上させると考えています。

クラウドへのOpenFlowの適用

続いて、OpenFlowを適用したクラウドアーキテクチャの例について、従来型のクラウドと比較して説明します。ここで紹介するアーキテクチャは、筆者が所属するNTTデータのR&D部門で検討されている方式の一例です。

従来型クラウドのアーキテクチャ

従来型クラウドでは、クラウドセットを複数並べることで全体をスケールアウトさせる構成が主流です（図3⁠）⁠。クラウドセットを複数並べる理由はいくつか考えられます。たとえば、クラウドセット内で利用するVLAN（VirtualLAN）の数がプロトコルで規定される上限に達した場合は、新規にクラウドセットを追加する以外に大規模化する方法はありません。また、従来型クラウドは仮想マシン上にソフトウェアをインストールすることでロードバランサ機能や故障監視機能を実現している点も特長です。

OpenFlowを用いた次世代クラウドアーキテクチャ

図4は、OpenFlowを用いた次世代クラウドのアーキテクチャのイメージです。しくみは後述するとして、まずは次世代アーキテクチャの特長を整理します。

サーバ装置を追加すると、同時にネットワーク機能も増強される

従来型クラウドでネットワーク機能[1]を増強するには、ネットワーク機能がインストールされた仮想マシンを用意し、それを適切に配備する必要がありました。これに対して、OpenFlowを用いた次世代クラウドではその必要はありません。次世代クラウドでは、適切にセットアップされたサーバ装置（ハードウェア）を追加するだけで、同時にネットワーク機能も増強されます。

ネットワーク機能が単一故障点にならない

従来型クラウドでは、故障に備えてネットワーク機能を二重化するのが一般的です。運悪く2台とも故障した場合は、システムが停止します。しかし、OpenFlowを用いた次世代クラウドでは、ネットワーク機能を各サーバ装置で分散実行することで、ネットワーク機能の単一故障点化を回避し、信頼性を向上させることができます。

マルチネットワーク構成の実現

OpenFlowを用いると、共通基盤上で仮想的に構築される各テナントのネットワーク構成を自由に定義できます。従来型クラウドでは、ハードウェアのトポロジ（接続形態）を定める物理構成と仮想的に構築される論理構成は同じ構成である必要がありました（図5⁠）⁠。しかし、OpenFlowを用いる次世代クラウドでは、各テナントで物理構成とは異なる論理構成を実現できます（図6⁠）⁠。

同一のL2セグメントに多数のサーバを配置できる

従来型クラウドに限らず一般的なシステム全体に言える話ですが、ARP（Address ResolutionProtocol）処理がL2スイッチに大きな負荷をかけるので、1つのL2セグメント内には1,000台程度しかサーバを配置できない場合があります。そのため、設計上は1つのL2セグメント内に10,000台のサーバを配置させたいが、ハードウェア側の性能上限がネックで、複数のL2セグメントを用意する場合があるのです。しかし、OpenFlowではブロードキャスト処理をOpenFlowコントローラで模擬することで、原理的には1つのL2セグメント内に10,000台規模のサーバを配置することも可能です[2]⁠。

次世代クラウドの実現方法

以降では、OpenFlowを用いた次世代クラウドの詳細について説明します。

論理ネットワーク構成とネットワークエミュレーション

前回説明したとおり、仮想ルータ機能や仮想ファイアウォール機能はOpenFlowスイッチにさまざまな制御ルールを書き込むことで実現します。このようにOpenFlowスイッチに制御ルールを書き込むことで実現される仮想的なネットワークを「論理ネットワーク構成」と呼ぶことにします。

図7に論理ネットワーク構成の例を示します。この論理ネットワーク構成上で、仮想サーバ（host1）から仮想サーバ（host2）に対してパケットを送信することを考えてみましょう。途中でファイアウォール（fw1）を通過するので、パケットはフィルタリングルールにマッチし破棄されるかもしれません。また、パケットがルータ（router）を通過すると、EthernetフレームのMACアドレス部分が書き換えられます。このようにパケットが論理ネットワーク上を通過することで、パケットが目標とする仮想サーバに到達可能であるかを判断したり、パケットが書き換えられる場所を特定したりすることを「ネットワークエミュレーション」と呼ぶことにします。

MPLSを用いたパケット転送

OpenFlowを用いた一般的なネットワーク制御方法では、OpenFlowスイッチに対して、

送信元MACアドレスがサーバ1と同様
送信先IPアドレスがサーバ2と同様

の場合に、「⁠サーバ2にパケットを転送する」という具合に制御ルールを書き込みます。

小規模なシステムにOpenFlowを適用する場合は、このような制御ルールの書き込み方で問題ありません。しかし、クラウドのようにネットワークが大規模な場合は問題が生じます。上述のように送信元MACアドレスと送信先IPアドレスを利用してOpenFlow スイッチに制御ルールを書き込む場合、仮想サーバが10,000台存在すると制御ルールの総数は最低でも10,000×（10,000－1）＝99,990,000ルールとなり、1台のOpenFlowスイッチに書き込める制御ルールの数を大きく超過する可能性があります（制御ルールを書き込める最大数は実装に依存します⁠）⁠。この問題を回避するため、NTTデータではMPLS（Multi-Protocol Label Switching）を利用することを検討しています（図8⁠）⁠。

OpenFlow スイッチA～C にはMPLS ラベルの値が割り当てられているとします（ここではOpenFlowスイッチCにMPLSラベル1という値が割り当てられたと仮定します⁠）⁠。その状態で、サーバ1上に存在する仮想マシンからサーバ2に向けてパケットが送信されるケースを考えます。

サーバ1 からOpenFlow スイッチA にパケットが送出されるときに、パケットにMPLSラベル1が付加されます（しくみは後述⁠）⁠。OpenFlowスイッチAからスイッチCまでの転送はMPLSラベルを利用して行います。具体的にはOpenFlowスイッチAはパケットに付加された「MPLSラベル1」という値を見て、パケットがOpenFlowスイッチC向けのパケットだと理解し、OpenFlow スイッチC に近いOpenFlowスイッチBにパケットを転送します。同様に、スイッチBはスイッチCにパケットを転送します。OpenFlowスイッチCまでパケットが到達した場合は、MPLSラベルに加え、送信元MACアドレスや送信先IPアドレスを見て転送先のサーバを決定します。

各OpenFlowスイッチにどのようなMPLSラベルが割り当てられているかはOpenFlowコントローラが把握しており、パケットが適切に転送されるように各OpenFlowスイッチに制御ルールを書き込みます。このアーキテクチャを採用すると、OpenFlowスイッチの数が250台の場合、OpenFlowスイッチに書き込む制御ルール数も250＋αに抑えることができます（+αの数は、OpenFlowスイッチに仮想スイッチ経由で接続される仮想マシン数により変化します⁠）⁠。

次世代クラウドの基本構成

続いて、OpenFlowを用いた次世代クラウドの構成について説明します。サーバ装置上で動作する管理マシン[3]には、図9のようにOpenFlow対応の仮想スイッチとOpenFlowコントローラがインストールされます。OpenFlowネットワーク上に存在するOpenFlowスイッチは、伝送用OpenFlowコントローラの指示に従い、MPLSラベルに基づいて転送制御を行います[4]⁠。DataStoreは、「⁠各仮想マシンがどのサーバ装置上で動作しているか」や「テナントごとの論理ネットワーク構成」を情報として保持するデータベースです。サーバ装置Bはサーバ装置Aと同じ構成です。今回は説明の都合上、サーバ装置が2台の場合を例にしていますが、本来は多数存在します。

以降、図9を基に、サーバ装置A上の仮想マシンAからサーバ装置B上に存在する仮想マシンに対して通信を行う場合の動作を説明します。通信時に利用される論理ネットワーク構成は図7と同じであるとします。

① 仮想マシンAは仮想スイッチAにパケットを送信する
② 仮想スイッチAは、パケットを受信したことをOpenFlowコントローラAに通知する
③ パケット受信の通知を受けたOpenFlowコントローラAは、仮想スイッチAが受信したパケットの送信元MACアドレスを検索キーにしてDataStoreから情報を取得し、どのテナントの、どの仮想サーバから送信されたパケットなのかを判断する。そして、仮想マシンAが所属する論理ネットワーク構成（図7と同様の情報）をDataStoreから取得し、ネットワークエミュレーションにより「パケットが最終的にどの仮想マシンに送信されるか」と「パケットのどの部分が書き変わるか」を算出する。再びDataStoreにアクセスし、パケットが最終的に送信される仮想マシンの近傍に存在するOpenFlow スイッチのMPLS ラベル値を得る。最後にOpenFlowコントローラAは、先ほど取得したMPLSラベル値の付加やMACアドレスの書き換えなどを行うように仮想スイッチAに対して制御ルールを書き込む
④ 仮想スイッチAは、OpenFlowコントローラAから書き込まれた制御ルールに従い、バッファに保持されているパケットを書き換え、OpenFlowネットワークにパケットを転送する
⑤ OpenFlowネットワーク（MPLSベース）内では、MPLSラベルを基にパケットを転送する。最終的にサーバ装置Bまでパケットが転送される
⑥ サーバ装置Bでは、サーバ装置B内の仮想スイッチがOpenFlowコントローラの指示によりMPLSラベルの削除などの処理を行い、最終的にサーバ装置B内の適切な仮想マシンにパケットを届ける

ここで説明したシーケンスでは、仮想スイッチAはパケットを受信したことをOpenFlowコントローラAに通知していますが、仮想スイッチAに既に制御ルールが書き込まれている場合はその必要はありません。このアーキテクチャでは、テナントごとに異なる論理ネットワーク構成を定義できます。そして、各仮想マシンが所属する論理ネットワーク構成を用いてネットワークエミュレーションを行います。このしくみにより、図7に示すようなマルチネットワーク構成を実現しています。

仮想マシンAからサーバ装置B上の仮想マシンに対して通信を行う場合、基本的にはサーバ装置A 上のOpenFlowコントローラでネットワークエミュレーションが行われ、ルーティングやファイアウォールなどの処理が行われます。同様にサーバ装置B上の仮想マシンから仮想マシンAに対して通信を行う場合は、仮想マシンB上のOpenFlowコントローラにて処理が行われます。このように、OpenFlowを用いた次世代クラウドアーキテクチャではネットワーク機能の処理が各サーバ装置上で分散実行されるため、ネットワーク機器へ負荷が集中するという問題は生じません。

OpenFlowによるARP応答のシミュレーション

OpenFlowを用いたクラウドシステムでは、原理的には10,000台規模の仮想マシンを同一のL2セグメントに配置可能です。

たとえば、図9で仮想マシンAがARP要求を送信した場合、従来は仮想スイッチAが全ポートからパケットを送信するブロードキャスト処理を行います。しかし、OpenFlowの場合、仮想スイッチAはブロードキャストを行う必要はありません。

ARP要求を受信したことは仮想スイッチAからOpenFlowコントローラAに伝えられ、OpenFlowコントローラAはネットワークエミュレーションによりARP応答を返すべき仮想マシンを特定します。ARP応答を返すべき仮想マシンが存在する場合は、OpenFlowコントローラが仮想マシンの代わりにARP応答パケットを生成し、ARP要求を送信した仮想マシンAに対してARP応答を返送します。

次世代クラウドでは、このような方法でL2スイッチの負荷を軽減できます。

まとめ～今後の課題

本稿では、NTTデータのR&D部門で検討している次世代クラウドの概要を説明しました。今後の検討課題は、伝送用OpenFlowコントローラが単一故障点である点の改善でしょう。伝送用OpenFlowコントローラが管理するOpenFlowスイッチはMPLSベースでパケット転送を行うため仕組みが単純であり、コントローラの分散化は比較的容易だと考えられます。

次回は、OpenFlowをより具体的に理解していただくため、実際にOpenFlowが動作する環境をオープンソースを用いて構築する予定です。