JP2015041938A - ネットワーク制御方法 - Google Patents

Abstract

【課題】本発明は、ＯＦＣ間のメッセージングによる同期を必要とせず、稼働中のＯＦＣの複製をライブクローン技術により作成するというシンプルな制御により、ネットワークへの新サービスの追加や需要の拡大、および、突発的な制御処理用トラヒックの増加等に対してもサービスを提供できるネットワーク制御方法を提供することを目的とする。
【解決手段】本願発明のネットワーク制御システムは、ソフトウェア制御を用いてスイッチの出力経路を制御するＳＤＮコントローラと、前記スイッチと前記ＳＤＮコントローラ間の制御トラヒック及び前記ＳＤＮコントローラのリソースに基づいて前記ＳＤＮコントローラが過負荷状態であることを判定し、過負荷状態にあるＳＤＮコントローラのライブクローンを生成するＳＤＮコントローラ制御部と、を備える。
【選択図】図２

Description

本発明は、ＳＤＮコントローラを用いたネットワーク制御方法に関する。

ソフトウェア制御が可能なネットワーク（ＳＤＮ：Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）の一つの技術要素として、ネットワークノードの機能をネットワークルーチング機構（ノードのデータ転送機能）とコントローラ機構（ノードでの制御ソフトウェア・ルーチング制御機能）とに、分離できるようにインタフェースを公開し、ネットワーク制御をプログラマブルにすることにより、柔軟な経路制御や構成変更等が容易に実現可能となる機構が注目されている。ＳＤＮではコントローラがネットワークの全情報を集め、一元的に定義し、ソフトウェアを活用した集中制御処理に基づいて、ネットワーク全体を制御できる特徴を持つ。コントローラは、スイッチ制御用のソフトウェアを配備することにより、スイッチの動作を制御できる。ＳＤＮの実現方法の１つとして、オープンフロー（ＯｐｅｎＦｌｏｗ：非特許文献１など）と呼ばれるネットワークプラットフォームの標準化が進められ、オープンソースによる実装と同時に企業によるシステム／製品群が市場に出てきている。

しかしながら、上記スイッチの動作情報の未設定や新しい機能やサービスの追加等に起因する、スイッチとコントローラの間の制御用トラヒックの急激な増加に対しては、上記のコントローラの処理能力は逼迫し、コントローラのスケーラビリティは、保障できない状況が生じ得る。また、当該のコントローラに故障が発生した場合の対策に関しては、当該の技術が開示されていないのが現状である。また、ＳＤＮを実現するコントローラに関しては、ＮＥＣが開発し、オープンソースとして公開したＴｒｅｍａや、スタンフォード大学で開発されたＢｅａｃｏｎ、ＮＯＸ／ＰＯＸ等があるが、本願で開示する技術は、いずれのコントローラに対しても、同様に適用することが可能である。

すなわち、現時点におけるＳＤＮ実現上の技術的な課題の一つは、ネットワークで提供されるサービスに対して、一時的に発生するネットワークへのアクセス集中や、スイッチの動作として登録されていない新しいトラヒックフローを含めた、急激なトラヒック増加や、コントローラの故障に対して、迅速に当該のコントローラの処理能力の増大化や、代替えとなるシステムを割り当てるための、メカニズムが確立されていない状況にある。

図１に、ＳＤＮの基本構成の一例を示す。一般的なオープンフロースイッチの構成を示す。オープンフロースイッチでは、従来のルータ等のネットワーク機器が持つ機能を、オープンフローコントローラ（以下、ＯＦＣと記す。）９２とフローテーブルの内容に基づいてパケットを転送するオープンフロースイッチ（以下、ＯＦＳと記す。）９１とに分離されている。ＯＦＣ９２は、ＯＦＳ９１内のスイッチ１１へのパケット処理動作や統計処理機能等の制御行う。ＯＦＳ９１は、スイッチ１１と、フローテーブル１２を備える。スイッチ１１は、ＯＦＣ９２の指示に従い、入力トラヒックのフロー情報に基づいて、パケットに対するルーチング等の処理（アクション）を行う。ネットワーク管理者は、入力トラヒックのフローの優先処理方法、廃棄方法および、経路設定方法等のアクションを、事前に、フローテーブル１２内のフローエントリーにインストラクションとして登録する。このフローエントリー内のインストラクション等のパケット処理に関わる制御内容は、ＯＦＳ９１の外部にあるＯＦＣ９２からのソフトウェアにより管理される。ＯＦＳ９１は登録されたフローテーブル１２に対して、パケットトラヒックの処理に関わるマッチングルールを適用して、マッチしたフローエントリーに示された転送処理を当該パケットに対して行う。

ＯＦＳ９１は、自身のフローテーブル１２にて未定義のトラヒックフローが到着した場合、ＯＦＣ９２に未定義フローに対する動作（アクション）を問い合わせる場合がある。ＯＦＣ９２は未定義フローに対する動作を、当該ＯＦＳ９１に指示する。ＯＦＳ９１に入力されるトラヒックフローに対して、予めフローテーブル１２（インストラクション等のアクションリスト）に未登録のトラヒックフローが増えた時には、ＯＦＳ９１とＯＦＣ９２との間でこの制御メッセージのやり取りが多数発生する。また、ＯＦＣ９２ではＯＦＳ９１に指示すべきフローエントリー決定のための処理負荷が増大する。このように、オープンフロー制御機構（パケット処理の制御機構）に対して、制御トラヒック量およびトラヒック処理量が、想定した負荷量の閾値以上に増大し、ＯＦＣ９２により管理するネットワークの制御が困難になる危険性があった。

すなわち、集中制御方式を前提とした現状のＯＦＣ（制御用サーバ）９２によるネットワーク制御では、コントローラへ加わる制御用トラヒックの処理能力が過剰になり、通信サービスを継続できない事態が発生し得る。

従来、これらのトラヒックに対する対処方法としては、ユーザに対して、一時的に利用を控えるように通知する方法や、強制的にＯＦＣ９２への制御用のトラヒックを、ＯＦＳ９１の前段または、ＯＦＳ９１内で、遮断又は廃棄する手法が一般的であった。ユーザの通信サービスの継続に関わる信頼性の向上、および、今後の新しい形態の通信トラヒックの増加にも対応できる必要があり、従来の方式に代わる新たな技術の開発が求められていた。

一方、サーバの仮想化技術の進歩により、新たなサービスの追加が必要となった場合においても、複数の物理的なリソースを、ユーザ要望に適うように、要求される処理能力に応じて、随時、適切に組み合わせて同時に活用することが可能である。例えば、ＯＦＣ９２に代表されるネットワーク制御用の通信機器を適切に配備して、新しいサービスを実施するために必要な処理能力を増強することも可能である。

非特許文献２、非特許文献３には、ＯＦＣ９２を複数の物理的なリソースで構成される分散環境上に実装することで、信頼性と可用性の保証を実現する例が示されている。非特許文献２は、ＯＦＣ９２が備えるべきデータを分散データベース上に構築し、ＯＦＣ９２を介して実装されるネットワークアプリケーションに対して適切なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供することにより、ＯＦＣ９２の分散化を実現している。非特許文献３は、データを分散データベース上で管理すると共に、複数のＯＦＣ９２間で通信を行うことで同期をとる方法が示されている。また、特許文献１には、複数のＯＦＣ９２を配備し、負荷状態に応じてＯＦＣ９２が制御するＯＦＳ９１の使用数を変化させることで、負荷分散、消費電力の削減、可用性の保証を行う方式が述べられている。

特開２０１３−３０８６３号公報

Ｏｐｅｎ Ｎｅｔｗｏｒｋｉｎｇ Ｆｏｕｎｄａｔｉｏｎ ｗｈｉｔｅ ｐａｐｅｒ，"Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ：Ｔｈｅ Ｎｅｗ Ｎｏｒｍ ｆｏｒ Ｎｅｔｗｏｒｋｓ"，ＯＮＦ Ｗｈｉｔｅ Ｐａｐｅｒ，Ａｐｒｉｌ １３，２０１２ Ｋ．Ｋｏｐｏｎｅｎ ｅｔ ａｌ．，"Ｏｎｉｘ： Ａ Ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｎｔｒｏｌ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｌａｒｇｅ−ｓｃａｌｅ Ｐｒｏｄｕｃｔｉｏｎ Ｎｅｔｗｏｒｋｓ"，Ｉｎ ｔｈｅ Ｐｒｏｃ． ｏｆ ｔｈｅ ９ｔｈ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ （ＯＳＤＩ １０），Ｖａｎｃｏｕｖｅｒ，Ｃａｎａｄａ，Ｏｃｔｏｂｅｒ ２０１０ Ａ．Ｔｏｏｔｏｃｉａｎ ａｎｄ Ｙ．Ｇａｎｊａｌｉ，"ＨｙｐｅｒＦｌｏｗ：Ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｒｏｌ Ｐｌａｎｅ ｆｏｒ ＯｐｅｎＦｌｏｗ"，Ｉｎ ｔｈｅ Ｐｒｏｃ． Ｏｆ ＮＳＤＩ Ｉｎｔｅｒｎｅｔ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｗｏｒｋｓｈｏｐ／Ｗｏｒｋｓｈｏｐ ｏｎ Ｒｅｓｅａｒｃｈ ｏｎ Ｅｎｔｅｒｐｒｉｓｅ Ｎｅｔｗｏｒｋｉｎｇ（ＩＮＭ／ＷＲＥＮ），Ｓａｎ Ｊｏｓｅ，ＣＡ，ＵＳＡ，Ａｐｒｉｌ ２０１０

しかしながら、いずれの文献にも、地理的に分散したコントローラをライブクローン作成技術により、ダイナミックにリアルタイムで構築し、大規模な仮想サーバとして、ネットワーク制御用に活用するための技術については開示がなされていない。

本発明は、稼働中のＯＦＣの複製をライブクローン技術により作成するというシンプルな制御により、ネットワークへの新サービスの追加や需要の拡大、および、突発的な制御処理用トラヒックの増加等に対してもサービスを提供できるネットワーク制御方法を提供することを目的とする。

本願発明のネットワーク制御システムは、
ソフトウェア制御を用いてスイッチの出力経路を制御するＳＤＮ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）コントローラと、
前記スイッチと前記ＳＤＮコントローラ間の制御トラヒック及び前記ＳＤＮコントローラのリソースに基づいて前記ＳＤＮコントローラが過負荷状態であることを判定し、過負荷状態にあるＳＤＮコントローラのライブクローンを生成するＳＤＮコントローラ制御部と、
を備える。

本願発明のネットワーク制御システムでは、前記ＳＤＮコントローラ制御部は、前記ライブクローンの生成に必要なリソースの処理速度又はメモリ容量を含む条件を、過負荷状態にあるＳＤＮコントローラのリソースに基づいて決定し、決定した条件を満足する仮想マシンを構築してもよい。

本願発明のネットワーク制御システムでは、１つの前記ＳＤＮコントローラは、データの同期されている複数のデータベースを備え前記複数のデータベースのうちの１つが、前記ＳＤＮコントローラ制御部からの指示に従い、当該データベースに記憶されているデータを複製する機能をもつと共に、前記仮想マシンは、前記複数のデータベースのうちの利用可能な他の１つを参照して、前記スイッチの接続処理を行ってもよい。

本願発明のネットワーク制御システムでは、複数の前記ＳＤＮコントローラが共通の前記スイッチの出力経路を制御し、前記複数のＳＤＮコントローラに備わる前記データベースは、前記スイッチの出力経路を制御するための同一内容のフローテーブルを格納していてもよい。

本願発明のネットワーク制御システムでは、前記ＳＤＮコントローラ制御部は、前記ＳＤＮコントローラに故障が発生したことを判定し、故障が発生したＳＤＮコントローラのライブクローンを生成してもよい。

本願発明のネットワーク制御方法は、
ソフトウェア制御を用いてスイッチの出力経路を制御するＳＤＮコントローラの制御方法であって、
前記スイッチと前記ＳＤＮコントローラ間の制御トラヒック及び前記ＳＤＮコントローラのリソースに基づいて前記ＳＤＮコントローラが過負荷状態であることを判定する判定手順と、
過負荷状態にあるＳＤＮコントローラのライブクローンを生成する制御手順と、
を有する。

本願発明のネットワーク制御方法では、前記制御手順において、前記ライブクローンの生成に必要なリソースの処理速度又はメモリ容量を含む条件を、過負荷状態にあるＳＤＮコントローラのリソースに基づいて決定し、決定した条件を満足する仮想マシンを構築してもよい。

本願発明のネットワーク制御方法では、１つの前記ＳＤＮコントローラは、データの同期されている複数のデータベースを備え、前記制御手順において、前記複数のデータベースのうちの１つが、前記ＳＤＮコントローラ制御部からの指示に従い、当該データベースに記憶されているデータを複製する機能をもつと共に、前記仮想マシンは、前記複数のデータベースのうちの利用可能な他の１つを参照して、前記スイッチの接続処理を行ってもよい。

本願発明のネットワーク制御方法では、複数の前記ＳＤＮコントローラが共通の前記スイッチの出力経路を制御し、前記複数のＳＤＮコントローラに備わる前記データベースは、前記スイッチの出力経路を制御するための同一内容のフローテーブルを格納してもよい。

本願発明のネットワーク制御方法では、前記判定手順において、前記ＳＤＮコントローラに故障が発生したことを判定し、前記制御手順において、故障が発生したＳＤＮコントローラのライブクローンを生成してもよい。

なお、上記各発明は、可能な限り組み合わせることができる。

本発明によれば、稼働中のＯＦＣの複製をライブクローン技術により作成するというシンプルな制御により、ネットワークへの新サービスの追加や需要の拡大、および、突発的な制御処理用トラヒックの増加等に対してもサービスを提供できるネットワーク制御方法を提供することができる。

ＯＦＳ用いたＳＤＮの基本構成の一例を示す。 オープンフローコントローラのライブクローン化の一例を示す。 ライブクローンの実施形態１を示す。 ライブクローンの実施形態２を示す。 ライブクローンの実施形態２を示す。 ライブクローン作成時の接続動作の一例を示す。 ライブクローン作成を実施する方法の一例を示す。 ＯＦＳを組み合わせた構成例を示す。 複数のＯＦＣの利用形態の一例を示す。 複数のＯＦＣの利用形態（プロキシとなるＯＦＣを利用）の一例を示す。 クラウドサーバ群からの任意のＯＦＣへの接続例を示す。 一変数をリソースの資源とし、割り当てを、最適化するアルゴリズムの一例を示す。 多変数をリソース資源として、リソース割り当てを最適化するアルゴリズムの一例を示す。 多変数をリソース資源として、リソース割り当てを最適化するアルゴリズムの一例（つづき）を示す。 地域分散されたオープンフローコントローラの拡張方法の一例を示す。

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

本発明は、予想できない制御トラヒック量の増大が、一時的に生じた場合、あるいは、継続して発生する場合に対して、クラウド等のコンピューティング、およびネットワークリソースを前提とした仮想リソース環境を効率的に活用し、ネットワーク制御装置あるいは、オープンフロー制御機構（パケット処理制御機構）を仮想化されたクラウドを活用することにより、大規模な処理能力を動的に確保するための技術手段を開示するものである。本発明は任意のＳＤＮコントーラに適用できるが、以下の実施形態ではＳＤＮコントローラの一例としてＯＦＣについて説明する。

図１に示すＳＤＮにおけるネットワーク制御を考えた場合、ＯＦＣ９２の位置する制御レイヤ８２の上位に、ネットワークアプリケーション９３を配備する方法が一般的である。この場合、ネットワークアプリケーション９３は、ＯＦＣ９２の上位に存在し、新しいネットワーク制御用のアプリケーションソフトウェアを導入する場合や、ネットワーク制御用の経路計算アルゴリズムを変更する場合など、通常のネットワーク管理や監視機能を更改する場合などに活用する。ＳＤＮに関する標準化はＡＰＩも含め、まだ十分には進んでおらず、各ＯＦＣ９２の実装に依存してアプリケーション９３も実装されているのが現状である。本発明における記述では、既存のＯＦＣ９２とアプリケーションが１つの物理または仮想マシン（図中においてはＶＭと表記する。）上に実装されている場合において、クラウドの等の仮想環境を活用することにより、高可用性、高拡張性、リソースの有効活用を、ダイナミックかつシンプルに実現するネットワーク制御メカニズムを開示する。将来的にＯＦＣ９２とアプリケーション９３間のＡＰＩが定まった場合は、最も処理能力の変動が想定されるＯＦＣ９２の処理能力に対して本発明を適用することも実施形態として有効である。

図２に本発明の実施形態として、ＯＦＣ９２に対して、ライブクローン作成を行うためのメカニズムの概要を示す。ＯＦＳ９１（ＯＦＳ＃１〜ＯＦＳ＃ｎ）に対して、各ＯＦＳ９１を制御するＯＦＣ９２として仮想的なＯＦＣ＃１が割り当てられる。仮想的なＯＦＣ＃１は、１つの仮想マシン７１＃１上で稼働させることも可能であるが、負荷状態によって複数の仮想マシン７１＃１及び仮想マシン７１＃２で稼働させることも可能である。

ＯＦＳ９１とＯＦＣ９２で構成されるネットワークに対して、別途ＯＦＣリソースコントローラ９５を設ける。ＯＦＣ９２がＳＤＮコントローラとして機能し、ＯＦＣリソースコントローラ９５がＳＤＮコントローラ制御部として機能する。ＯＦＣリソースコントローラ９５は、ＯＦＣ９２をどのような仮想／物理構成で実現するかを管理し、制御する機構である。ＯＦＣリソースコントローラ９５は、オープンフロー制御トラヒック監視機能９５１、ＯＦＣリソース負荷監視機能９５２、ライブクローン制御機能９５３、ロードバランス制御機能９５４を持つ。

本実施形態に係るＳＤＮコントローラの制御方法は、ソフトウェア制御を用いてコントローラとスイッチの対応付けを制御する方法であって、判定手順と、制御手順と、を順に有する。判定手順では、オープンフロー制御トラヒック監視機能９５１及びＯＦＣリソース負荷監視機能９５２を機能させる。制御手順では、ライブクローン制御機能９５３を機能させる。ライブクローン制御機能９５３を機能させた後に、ロードバランス制御機能９５４を機能させる。

オープンフロー制御トラヒック監視機能９５１は、ＯＦＳ９１に流入するトラヒックのうち、ＯＦＣ９２へ転送される制御トラヒック量を監視する。
ＯＦＣリソース負荷監視機能９５２は、ＯＦＣ９２のリソース（ＣＰＵ負荷、メモリ容量、Ｉ／Ｏ転送量等）を監視する。

ライブクローン制御機能９５３は、ＯＦＣ９２が過負荷であることを検知する。例えば、ライブクローン制御機能９５３は、オープンフロー制御トラヒック監視機能９５１により観測された制御トラヒック量が、事前に設定された閾値を超えると過負荷を検知する。また、ライブクローン制御機能９５３は、ＯＦＣリソース負荷監視機能９５２により観測された、ＯＦＣ９２のリソースが事前に設定された閾値を超えると過負荷を検知する。

ライブクローン制御機能９５３は、過負荷状態を検知すると、仮想マシン７１（ＯＦＣ）のライブクローンが必要と判断する。また、現在過負荷状態ではないが、今後過負荷になる可能性がある場合も仮想マシン７１（ＯＦＣ）のライブクローンが必要と判断する。ライブクローン制御機能９５３は、クラウドのリソースを管理し、仮想マシン７１のライブクローンをどのリソースに生成するかを判断し、ライブクローンを作成する。このとき、ライブクローン制御機能９５３は、ライブクローン作成指示をＶＭ７１に通知する。

ロードバランス制御機能９５４は、ライブクローンの生成が完了すると、負荷分散を行うために制御トラヒックの分配を指示するロードバランス指示を仮想マシン７１のほか、該当のＯＦＳ９１やロードバランサに対して指示する。ここでは、処理能力を増やすために、ライブクローンを作成する場合を示したが、仮に、ＯＦＣ＃１が何らかの状況（故障発生や、別のアプリケーションの実施等）が発生した場合には、ライブマイグレーションを行うことにより、他のクラウドのリソースを活用するように、制御動作を実施することも同様に可能である。

ＯＦＳ９１やＯＦＣ９２とは別の媒体上で構成することが好ましい機能をまとめて、ＯＦＣリソースコントローラ９５上に配備する。オープンフロー制御トラヒック監視機能９５１は、ＯＦＳ９１内に配備する方法、ＯＦＣ９２内に配備する方法、ＯＦＣリソースコントローラ９５上に配備する方法がある。また、ＯＦＣリソース負荷監視機能９５２は、ＯＦＣ９２内に配備する方法、ＯＦＣリソースコントローラ９５上に配備する方法がある。ライブクローン制御機能９５３とロードバランス制御機能９５４は、ＯＦＣリソースコントローラ９５上に配備するのが望ましい。各機能の配備は、この物理的論理的構成に縛られるものではなく、例えば、ロードバランス制御機能９５４のみを別の物理構成上に実装することは、ＯＦＣリソースコントローラ９５をクラウド上で実現し分散制御を行う実施形態も考えられる。

オープンフロー制御トラヒック監視機能９５１は、ＯＦＳ９１とＯＦＣ９２間のトラヒック量があらかじめ定められた閾値以上であると高負荷であると検知し、ライブクローン制御機能９５３に通知する。また、ライブクローン制御機能９５３やロードバランス制御機能９５４がオープンフロー制御トラヒック量に関する情報を所望する場合に、当該情報を提供する。

オープンフロー制御トラヒック監視機能９５１をＯＦＳ９１内に配備する場合は、オープンフローとは全く別の機構で、ＯＦＣとやり取りされる制御トラヒック量を監視する方法や、オープンフローの機構を利用してコントローラ９５に対するトラヒックフローをフローテーブル１２内に定義し、フローテーブル１２のカウント機能を利用して監視する方法等がある。

オープンフロー制御トラヒック監視機能９５１をＯＦＣ９２内に配備する場合は、オープンフローとは全く別の機構で、ＯＦＳ９１とやり取りされる制御トラヒック量を監視する方法や、オープンフローの機構を利用して、ＯＦＣ９２に対するトラヒックフローをフローテーブル１２内に定義し、フローテーブル１２の内のカウンタ値をＯＦＣ９２経由で取得することで監視する方法がある。このトラヒック監視機能は、ＯＦＣリソースコントローラ９５上に配備する他にも、ＯＦＳ９１やＯＦＣ９２とは別の監視センターに配備する場合でも、同等な機能を実現するネットワーク制御が可能となることは、いうまでもない。

ＯＦＣリソース負荷監視機能９５２は、ＯＦＣ９２の仮想マシン７１のリソースを監視し、リソースの使用状況、負荷状況があらかじめ定められた閾値以上であると高負荷であると検知し、ライブクローン制御機能９５３に通知する。また、ライブクローン制御機能９５３やロードバランス制御機能９５４が各ＯＦＣ９２の仮想マシン７１のリソース情報を所望する場合に、当該情報を提供する。

ライブクローン制御機能９５３は、
（１）どの仮想マシン７１を選択して複製又は縮退するか、
（２）どのような手順でライブクローンを実施するか、
を決定して実行する。オープンフロー制御トラヒック監視機能９５１により過負荷が報告された場合、またはＯＦＣリソース負荷監視機能９５２より過負荷が報告された場合に、当該ＯＦＣ９２を構成する仮想マシン７１のライブクローンが必要と判断する。それ以外にも、定期的に、オープンフロー制御トラヒック監視機能９５１からオープンフロー制御トラヒック情報と、ＯＦＣリソース負荷監視機能９５２からリソース情報を取得し、将来的に過負荷が予想される場合に当該仮想マシン７１のＯＦＣ９２のライブクローンが必要と判断する。

一方、ＯＦＳ９１に加わる負荷が定常的に減少し、現在配備されているＯＦＣ９１に割り当てられたクラウド内のリソースが明らかに余剰であることが、トラヒック量の監視結果により明らかになった場合には、上記に述べたＯＦＣ９２用のリソースを減少させるための制御を行う（減設）必要がある。どの番号のＯＦＣ９２を減設するかを決定する場合には、一般には、減設の影響により、処理能力の減少効果が少ない順番に選択する方法が、安全である。しかしながら、クラウド内での、他のアプリケーションの処理状況により、減設する場合の優先順位は、異なる場合も存在し、上記の方法に限定されるものではないことは明らかである。

ライブクローン制御機能９５３が、ライブクローン生成方法を決定し、ライブクローンを作成する場合には、次の２通りの方法が考えられる。
第１の方法：フローテーブル１２の全情報を格納したデータベースの情報も一緒にコピーし、全く同等のサーバとして用いる。
第２の方法：フロー制御に最小限必要となる情報はコピーするが、全情報コピーを対象とせず、新しいフローテーブル１２の情報のみを追記したサーバとして用いる。

第１の方法は、信頼性を高めるための冗長制御が実現できるライブクローンとして用いる場合であり、通常は、負荷分散装置（ロードバランサ）と接続して使用される。一方、第２の方法は、緊急的にトラヒックが増えそうな場合を予め予測して、緊急時に行う処理に適する。そのため、ＯＦＣ９２用のサーバ処理能力に余剰能力等の、余裕が出てきた時点で、第２の方法の形態から第１の方法の形態に移行する運用方式が好ましい。

一般に、ライブクローンを作成する場合の、レプリケーション技術はデータベースの内容の一貫性を保ちながら、情報を複製する技術として活用され、同じデータを複数のデータベースに格納する際に用いられる。任意のＯＦＣ９２が、他のＯＦＣ９２内のデータベース（ＤＢ）７２へのアクセス時には、ある時点では、１つのＯＦＣ９２のみがマスターとして動作し、他のＯＦＣ９２からの要求を待ち合わせるための同期処理のメカニズムを用いることにより実現できる。

例えば、異なるＯＦＣ９２間で特定のデータベース内のファイルへのアクセスを、一時的には、１つのプロセスに制限し、アクセス競合による、デッドロック等を防止するメカニズム（ファイルロックを適用した複製）を利用することもできる。また、データベース内容のレプリケーションは、一般には、専用の管理システムで行うこともでき、マスタースレーブ・システムを構成する場合には、マスター側では、更新を記録し、その内容をスレーブ群に通知する場合もあるが、この方法に限定される必要はないことはいうまでもない。なお、この場合にはスレーブ側は、更新を正しく実施した旨を示すためのメッセージを送り、後続する新たな更新要求を受け付けられる状態であることの通知を行うことが必要である。

図３にライブクローンの模式図を示す。ＯＦＣ＃１−１からＯＦＣ＃１−２への単純なライブクローンは、動作中の仮想マシン７１の実体であるイメージファイルとメモリ内容を複製すれば良いが、イメージファイルの複製は、一般に長い時間を要するため、新たな工夫が必要である。そこで、図３に示すように、イメージファイルを大きく二つに分ける。一つはライブクローン（作成）時に異なる内容でクローン先の仮想マシン７１＃２に引き継ぐマスターイメージファイル７３であり、もう一つはライブクローン（作成）時にも全く同一内容でクローン先の仮想マシン７１＃２に引き継ぐイメージファイル７２である。ＯＦＣ９２を対象にする場合は、異なる内容で引き継ぐマスターイメージ７３はＯＳ等のシステム本体に相当し、同一内容で引き継ぐイメージはフローテーブル１２の全情報を格納したデータベースファイル（ＤＢ）７２に相当する。更に異なる内容で引き継ぐＯＳ等を含んだイメージファイルも二段階に分け、全ての仮想マシン７１の標準かつ共通となるＯＳ等のシステムをマスターイメージ７３とし、仮想マシン７１毎に異なる設定情報やログ情報等は、マスターイメージ７３よりも仮想マシン７１に近いところに差分ファイル７４として装備する。

図３に、ライブクローンによる仮想マシン７１の第１の複製例を示す。仮想マシン７１＃１の複製として仮想マシン７１＃２をライブクローンしているが、ＯＳ等の標準かつ共通部分はマスターイメージ７３として共有しつつ、仮想マシン７１＃１独自の設定情報や、仮想マシン７１＃１が起動してからの実行ログ等の変更部分は仮想マシン７１＃１の側の差分ファイル７４＃１に保存し、仮想マシン７１＃２独自の設定情報や、仮想マシン７１＃２が起動してからの実行ログ等の変更部分は、仮想マシン７１＃２の側の差分ファイル７４＃２に保存するように配置している。差分ファイル７４に存在しない、標準かつ共通部分は、仮想マシン７１＃１、仮想マシン７１＃２共にマスターイメージ７３にアクセスに行く。また、仮想マシン７１＃１から仮想マシン７１＃２に完全に同一で引き継ぐべきＤＢ７２の部分は、同じイメージをアクセスするものとしている。これにより、ライブクローン時のイメージのコピー作業を無くし、クローンされる仮想マシン７１用の差分ファイル７４の作成だけで、新たなライブクローンを起動することが可能になる。

図４に、ライブクローンによる仮想マシンの第２の複製例を示す。仮想マシンの第２の複製例では、図３の構成に加えて、データベースの高信頼化技術として標準的なレプリケーション（ｒｅｐｌｉｃａｔｉｏｎ）を行うことにより、標準状態でＤＢ７２をＤＢ７２＃１とＤＢ７２＃２に二重化している。クローン後では、ＤＢ７２のレプリケーションを中止して、二重化したＤＢ７２を切り離した上で、各々のＤＢ７２を異なる仮想マシンに割り当てることにより、ＤＢ７２へのアクセスが性能低下の要因にならないようにしている。更にライブクローン後に、ＤＢ７２の高信頼化のためのレプリケーションを再度開始し、ＤＢ７２＃１とＤＢ７２＃２の各々で、別の二重化を開始するべきである。この実現形態の例を、図５の実施形態２に示す。

図５に、ライブクローンによる仮想マシンの第３の複製例を示す。仮想マシンの第３の複製例の場合、仮想マシン７１＃１がアクセスしているＤＢ７２＃１のレプリケーションとしてＤＢ７２＃３を、仮想マシン７１＃２がアクセスしているＤＢ７２＃２のレプリケーションとしてＤＢ７２＃４を作成して、二重化を実施している。ＯＦＣ９２を構成する各仮想マシン７１の処理の殆どは、制御用トラヒックと一致するフローテーブル１２を、フローテーブル１２の全情報を格納したＤＢ７２から検索し、その検索結果をＯＦＳ９１に新規のフローテーブル１２として返信する処理である。そのため、ライブクローンにより新しい仮想マシン７１＃２を生成して、ＣＰＵリソースとメモリリソースを拡張することにより、上記の処理を、より多くの仮想マシン７１に分散させることが可能となり、一台の仮想マシン７１当たりに加わる負荷の減少に伴い、応答処理の高速化が期待できる。

しかしながら、図７（ａ）に示すように、フローテーブル１２の全情報を格納したＤＢがライブクローンされた仮想マシン７１間で共有された場合、ＣＰＵリソースとメモリリソースに余裕がある場合でも、ＤＢのファイルへのアクセスがボトルネックとなって、期待される応答の高速化が得られないことが生じ得る。このような場合には、レプリケーションのようなＤＢ７２の複製技術とライブクローン技術を結び付け、図７（ａ）に示すＤＢ７２の複製を実現している状態から、図７（ｂ）のようなライブクローンを行うことにより、ＤＢファイルへのアクセスに関わるリソースを拡張でき、応答の高速化を実現することが可能となる。

図３のライブクローン実施形態１においても、図４、図５のライブクローン実施形態２においても、クローンされた仮想マシン７１は、クローン元の仮想マシン７１と同一機能と同一のＤＢファイルを備えるが、異なるコントローラとして機能する。そのため、クローン元の仮想マシン７１で使用中のセッション（ＴＣＰセッション、ＳＳＬセッション、オープンフローの制御セッション）をクローンされた仮想マシン７１に引き継ぐことは出来ない。ＴＣＰセッションやＳＳＬセッションはＯＦＳ９１がクローンされた仮想マシン７１にセッションを繋ぎ直すことにより容易に回復可能であるが、オープンフローの制御セッション（ＰａｃｋｅｔＩｎ→ＦｌｏｗＭｏｄ→ＰａｃｋｅｔＯｕｔ）の扱いは注意すべきである。例えば、クローン元の仮想マシン７１がＯＦＳ９１＃ｎの制御をクローンされた仮想マシン７１に引き継がせる場合、ＯＦＳ９１＃ｎに対してＦｌｏｗＭｏｄを送信済のセッションについては、続くＰａｃｋｅｔＯｕｔをクローン元から送るが、ＯＦＳ９１＃ｎからＰａｃｋｅｔＩｎを受け取っただけのセッションはクローン元では処理せず、残ったＰａｃｋｅｔＯｕｔを送り終わった時点でＯＦＳ９１＃ｎとのＴＣＰ接続を切断することにより、ＯＦＳ９１＃ｎに対して、ＰａｃｋｅｔＩｎをクローンされた仮想マシン７１に再送信するように促すための処理が必要になる。仮想マシン７１を縮退する場合も同様の配慮が必要である。

一般には、ＣＰＵリソースとメモリリソースの拡張に対する要求と、ＤＢファイルへのアクセス能力に対する要求の双方のバランスを取りながら、図３に示すライブクローンと、図４に示すライブクローンとを混合させたライブクローンを逐次行うことにより、適切な処理能力の増強を、仮想マシン環境で達成することが可能となる。

図６に、ＯＦＣ９２を２重化することにより、クラウド上にライブクローンを作成する際に、現状の処理能力を減少させることなく、ＯＦＣ９２を動作可能とするための接続動作の一例を示す。ＯＦＣリソースコントローラ９５から、ライブクローン作成指示がサイト１のＯＦＣ９２に行われた場合（Ｓ３０１）、第１のサイトのＯＦＣ９２＃１は、ＯＦＳ９１との接続処理を一方の仮想マシン７１＃１で行いながら（Ｓ３０２及びＳ３０３）、他方の仮想マシン７１＃３で第２のサイトのＯＦＣ９２＃２へのコピーを作成する（Ｓ３０４）。すなわち、Ｓ３０３及びＳ３０４のデータ転送が同時並行処理することにより、第１のサイトのＯＦＣ９２＃１−１が、ライブクローンを第２のサイトに作成する時の処理能力の劣化を抑止できる。またＯＦＣ９２＃１−１とＯＦＣ９２＃１−２が同一のサイトにある場合も同様に、本メカニズムが適用できることは言うまでもない。

急激な制御用トラヒックの増大により、連続してライブクローンの作成を行う場合、フローテーブル１２の全情報を格納したＤＢ７２の共有や複製・レプリケーションが全体の性能を決定する上での重要課題となる。例えば図６に示すように、仮想マシン７１＃１のライブクローンをＣＰＵリソースやメモリリソース的には余裕の有る仮想マシン７１＃２に作成する場合に、仮想マシン７１＃２と現在使用されているＤＢ７２の間のネットワークの遅延が大きい場合、あるいは利用可能な伝送帯域が狭い場合に、ＤＢ７２を共有する時や、あるいは、複製する時には、より多くの処理時間を必要とするため、仮想マシン７１＃２をライブクローンしたことによっても、応答処理の高速化は実現出来ない可能性がある。

マスターイメージ７３に関しては、全仮想マシン７１で共通の内容なので、図３に示すように、オープンフロークラウド内の複数個所に同じイメージを事前に配備することによりこのような問題は回避出来る。しかしながら、ＤＢ７２の事前配備は困難であるため、現在使用されているＤＢ７２から、低遅延でかつ広帯域なネットワークで接続された場所の仮想マシン７１を優先的に選択し、複数ライブクローンすると共に、ＤＢ７２の複製・レプリケーションを作成することが好ましい。

図７に、オープンフロー制御トラヒック監視機能９５１、ＯＦＣリソース負荷監視機能９５２の情報から、ライブクローン制御機能９５３がＯＦＣ処理能力の増加を判断し、次々と逐次的に複数のライブライブクローンの作成を実施する場合の基本的な２つの方法例を示す。図７（ａ）に示す第１の方法は、マスターとなる最初に設置されたＯＦＣ９２＃１から、他の、コントローラ機能の実装可能なクラウド上のリソースに対して、順次、ＯＦＣ９２＃１を固定して、これを用いてライブクローンを増やす場合の方法である。この方法は、マスターとなるＯＦＣ９２の処理能力に、相当の余剰処理能力があり、信頼性が高い場合や、従属となるＯＦＣ９２間の伝送距離が短い、データセンター内に限定された場合には適用可能である。仮に、マスターのＯＦＣ９２とその配下に置かれる、各種の従属のＯＦＣ９２との間の伝送帯域が逼迫する状況が明らかである場合には、伝送帯域が十分に確保されている区間においてはこの方法を用いることが好ましい。

従属のＯＦＣ９２が遠隔地にある場合や、マスターのＯＦＣ９２の処理能力が、不足している場合、あるいは上述したように、マスターのＯＦＣ９２からいくつかの従属のＯＦＣ９２へ直接接続するための、伝送帯域が不足する場合には、図７（ｂ）に示す第２の方法を用いることが好ましい。第２の方法は、コピーをされるＯＦＣ９２＃１をマスタコントローラに固定せず、コピー後は、逐時、マスターの機能を移動する。この方法は、仮に、マスターのＯＦＣ９２が故障した場合にも、マスターのＯＦＣ９２を容易に変更することができる特徴をもち、システム全体の耐故障性を向上する場合にも適用することが可能である。

上述の技術は、現在サービスされているクラウドサービスにおいて、カスタマのポータルサイトからの要求に応じて、仮想マシン７１のリソースの割り当てを行い、新たな仮想マシン７１を、ステップ・バイ・ステップ的に増やせるメカニズムを盛り込むことにより達成することができる。このメカニズムにより、ネットワーク内でコントローラの処理能力が逼迫する場合においても、安定したサービスの継続（ＢＣＰ：Ｂｕｓｉｎｅｓｓ Ｃｏｎｔｉｎｕｉｔｙ Ｐｌａｎ）を実現することができる。

ロードバランス制御機能９５４は、ライブクローン制御機能９５３により複製されたＯＦＣ９２間の負荷分散と、複数のＯＦＣ９２間の負荷分散の２つの負荷分散を組み合わせて実施する。

ライブクローンにより複製されたＯＦＣ９２に対して適切にオープンフロー制御メッセージを分配するための制御方法について説明する。オープンフロー制御メッセージの分配は、負荷分散装置をＯＦＳ９１の内部、または、クラウド内の複数のＯＦＣ９２を管理するＯＦＣリソースコントローラ９５の中、またはクラウド内に独立に配備することにより実現する。ライブクローンによりセッション情報も引き継ぐため、パケットの転送を適切な仮想マシン７１に対して行うことにより負荷分散を実現できる。ライブクローン実施時にアドレスの再構成を行う場合は、クローン元のＯＦＣ９２とＯＦＳ９１間のセッションを維持するための機構を持つことが必要なことは言うまでもない。

図８に、ＯＦＳ９１の構成例を示す。
図８（ａ）に示すＯＦＳ９１は、Ｌ３（レイヤ３の処理）スイッチと負荷分散装置とを物理的に接続してスイッチ１１の機能を実現する。図８（ｂ）に示すＯＦＳ９１は、複数のオープンフロースイッチを物理的に接続してスイッチ１１の機能を実現する。図８（ｃ）に示すＯＦＳ９１は、仮想的なＬ３スイッチと仮想的な負荷分散装置とを物理的に接続してスイッチ１１の機能を実現する。図８（ａ）に示す装置構成は、原理的にＯＦＳ９１の制御ソフトウェアを複数種類設けることにより、図８（ｂ）に示すＯＦＳ９１のみによる物理構成で、図８（ｃ）に示す論理構成と同等の装置を構成することも可能である。ＯＦＳ９１の機能は、ここに示した例に限定されるものではないが、これら各種機能の実現に必要となる、ＯＦＳ９１のアクション用制御コマンドの種別の例、および、定義可能なヘッダ情報の種別の例を以下に示す。

フローに対するアクションに指定できるコマンドには、例えば次のものがある。
Ｆｏｒｗａｒｄ：パケットを特定の物理ポートに転送する。
Ｄｒｏｐ：パケットを破棄する。
Ｍｏｄｉｆｙ−Ｆｉｅｌｄ：パケットヘッダの値を指定した値に書き換える。
Ｓｔｏｒｅ：パケットを一時、共通バッファに格納する。
ｃｏｐｙ：パケットをコピーし、複数ポートにマルチキャストする。
ｄｉｖｉｄｅ：パケットを分割し、複数ポートにマルチキャストする。
ｅｎｃｒｙｐｔｉｏｎ：パケットの中身を暗号化する。
Ｅｎｑｕｅｕｅ：パケットを指定したキューバッファに格納する。

オープンフローで定義可能なヘッダの情報としては、例えば、物理ポート番号、送信元ＭＡＣアドレス、送信先ＭＡＣアドレス、Ｅｔｈｅｒタイプ、ＶＬＡＮ ＩＤ、ＶＬＡＮプライオリティ、送信元ＩＰアドレス、送信先ＩＰアドレス、ＩＰプロトコル種別、ＩＰＴＯＳ情報、送信元Ｌ４ポート番号、送信先Ｌ４ポート番号、ＭＰＬＳラベル番号、及び閉域サービス識別番号がある。

ロードバランス制御機能９５４の、複数のＯＦＣ９２間の負荷分散方法を、以下に説明する。図９に示すように、ＯＦＳ９１は自身に対する設定情報として使用可能なＯＦＣ９２の情報を複数保持し、同時に複数のＯＦＣ９２とオープンフロー制御用のコネクションを確立することが可能である。例えば、ある１つのＯＦＣ９２＃２をマスターとして使用し、その他のＯＦＣ９２＃１及び＃３をスレーブとして利用する使用形態や、全てのＯＦＣ９２＃１から＃３を同等の制御機能を持つＯＦＣ９２として、全てのＯＦＣ９２に対して制御トラヒックを転送できる使用形態も可能である。

また、図１０に示すように、ＯＦＳ９１は、例えば、ＯＦＣ９２のプロキシとして動作を行わせるＯＦＣ９２＃１と接続し、プロキシとして動作するＯＦＣ９２＃１が、各ＯＦＣ９２＃２〜＃４に処理を振り分けることも、同様に可能である。

図１１は対象とするクラウドサーバ群がｎ個の処理能力を異にするＯＦＣ９２＃１〜ＯＦＣ９２＃ｎを含む場合の接続構成である。図１１の構成は、図９及び図１０の形態を一般化したものである。例えば、ＯＦＳ９１内に配備されたＯＦＣ９２へ届けるための制御用のトラヒック負荷量測定を実施するオープンフロー制御トラヒック監視機能９５１が過負荷状態を観測し、ロードバランス制御機能９５４にて、新たなＯＦＣ９２への接続が必要であると判断されると、不荷分散の制御を実施し、当該新たなＯＦＣ９２へ接続される。この場合、最も簡単な新たな接続先ＯＦＣ９２を選択する方法の例として、ＯＦＣ９２＃毎に、要求されるリソース種別は１つであり、かつこのリソースにおける処理能力の相対値の大きさが異なり、仮に処理能力の大きさが、例えば、ＯＦＣ９２＃１の処理能力＞ＯＦＣ９２＃２の処理能力＞……＞ＯＦＣ９２（＃ｎ−１）の処理能力＞ＯＦＣ９２＃ｎの処理能力の順番であると仮定した場合には、処理能力の高い順に、当該番号のＯＦＣ９２を割り当てることが好ましい。

一方、ＯＦＳ９１から定期的に各ＯＦＣ９２の処理能力に影響を来さない範囲で、応答レスポンス時間を得るための問い合わせ用メッセージを送出する方法も有効である。この場合は、応答レスポンス時間の最も短い、当該番号のＯＦＣ９２を最優先に選択すべきと判断することも可能である。あるいは、上記２つの判断方法に、適切な重みづけを行って評価する方法が、より好ましい場合があり、以下にその例を説明する。例えば、最も簡単な場合として、新たなＯＦＣ９２の割り当てを決定する際の要求条件として、リソース種別１（ＣＰＵ処理能力）、リソース種別２（余剰なメモリ容量）があり、これらのリソースの要求値を同時に満足する必要がある場合を仮定する。

ここでは、議論を簡単にするため、ライブクローンの対象となり得る、全てのリソース種別１は、同一の規格（クロック周波数、単位時間当たり命令実行処理数回数など）を想定し、ギブソンミックスやコマーシャルミックスに対応する処理能力等については、当該のリソース種別が未使用時には、同一の能力をもつことを仮定する。リソース種別２に関しても、同一の規格を想定する。この場合、ＯＦＣ９２で扱うべき、制御用のトラヒックが増えたことに対して、例えば、リソース種別１には、３０（相対値）の能力が必要であり、リソース種別２には、４０（相対値）の能力が必要である場合を仮定する。

実際には、例えばリソース種別１は、例えば１００ ＭＩＰＳ（Ｍｉｌｌｉｏｎ Ｉｎｓｔｒｕｃｔｉｏｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）×割り当て可能なＣＰＵ使用率を、勘案することが必要であるが、ここでは、それらの、割り当て可能とすべき条件等を全て併せて考慮し、単純な、「相対値」に変換した値として、すでに、上記の条件にも配慮した「相対値」を活用する。

ここで、各種の、割り当て可能なリソース種別が存在する、使用可能なＯＦＣ９２として＃５、＃６、＃７、＃８、＃９があり、例えば＃５は（リソース１：２０、リソース２：５０）、＃６は（リソース１：４０、リソース２：２０）、＃７（リソース１：２８、リソース２：３５）、＃８（リソース１：３０、リソース２：４５）、＃９（リソース１：３０、リソース２：５０）であったとする。この場合は、条件に適合するのは、＃８と＃９であるが、要求条件に最も近いＯＦＣ９２＃は、ＯＦＣ９２＃８であるため、＃８を選択し、ライブクローンを作成すれば良い。

更に複雑な事例として、リソース１には、６０（相対値）の能力が必要であり、リソース２には、７０（相対値）の能力が必要である場合を仮定する。この場合には、単独では、満足できるＯＦＣ９２＃は見つからないため、２つ以上のＯＦＣ９２＃を組み合わせる必要があり、この場合、組み合わせる数は、極力、少ないことが実用上は好ましい。上記の条件の場合は、ＯＦＣ９２＃５とＯＦＣ９２＃６とを組み合わせることが、最も好ましい。

上記の例では、リソース１とリソース２のみを考慮したが、新たなリソース３として、例えば、応答遅延時間の短さを、レスポンス能力と見なし、相対値として、５０を付け加えることを考える。ここで、リソース３が最も、高い優先順位を持つものと仮定し、重み付け係数を「２」と仮定すると、必要なリソース３は、５０×２＝１００と設定できる。このため、要求条件を満足するＯＦＣ９２＃の探索に当っては、以下の条件を満足するＯＦＣ９２＃を、選択すれば良い。

＃５、＃６、＃７、＃８、＃９のＯＦＣ９２は、リソース３の要素に関わる重み付け係数を考慮すると、例えば＃５は（リソース１：２０、リソース２：５０、リソース３：７０）、＃６は（リソース１：４０、リソース２：２０、リソース３：４０）、＃７（リソース１：２８、リソース２：３５、リソース３：１００）、＃８（リソース１：３０、リソース２：４５、リソース３：６０）、＃９（リソース１：３０、リソース２：５０、リソース３：６５）となり、前提となる条件は、以下の通りである。
（１）リソース１は６０以上で最も６０に近い
（２）リソース２は７０以上で最も７０に近い
（３）リソース３は１００以上で最も１００に近い

単独のＯＦＣ９２＃では、各リソースの要素に関わる条件の全てを、満足することはできず、＃５と＃６を組み合わせで使用する方法が、最も好ましい。

以上に述べた例では、いずれも、各リソースの値は、加算して評価することができることを前提にして、条件を満足する組み合わせ（単独の場合も含む）に対して、最も要求値に近い組み合わせを選ぶ方法を示した。しかしながら、この例に限定されず、例えば、各リソースの要素の要求値の２乗の和を評価する場合であっても、同様の方法で、最も適切な組み合わせを選ぶことができることは言うまでもない。仮に、満足できる組み合わせが、一つも存在しない場合には、最も、要求条件に近い組み合わせを選択することで、対応することが、実用上は好ましい。

一方、対象となるＯＦＣ９２の数やリソースの種別数が非常に大きくなった場合には、ヒューリスティックに容易に適切なＯＦＣ９２を選ぶことは困難である。この場合は、ナップザック問題を解く手法と類似した手法を活用することにより、解決手段を提供することができる。まず、第一段階として、一変数を対象とした場合のリソース種別の割り当て資源を最適化するアルゴリズムを図１２に示す。

ここでは、対象ＯＦＣ９２の数が非常に大きく、世界中の全てのＯＦＣ９２を対象にすること現実的ではないため、先ず当該のリソース種別の判断が可能なＯＦＣ数を、当面、ｎ個あると仮定し、それらに対するリソース量の読み出し（サンプリング）を特定の、または、適切なＯＦＣ９２の中から、行った前提のもとに、図１２の制御フローの内容を説明する。

ステップＳ１０１：対象としたリソース種別を「Ｄ」として、適用可能な複数のＯＦＣ９２のもつ、第１種のリソースに関わるリソースベクトルＤを、以下のように定義する。
Ｄ＝（ｎ個の要素からなるベクトル）＝（Ｄ０，Ｄ１，…Ｄ（ｎ−１））
ステップＳ１０２：リソースの状態Ｄ０（＝Ｄ［０］， Ｄ［１］， Ｄ［１］，…． Ｄ［ｎ−１］）を記録する。ここで、ａはリソース合計の目的値、ｍは繰り返し回数の上限値である。ｃｔは繰り返しのカウンタ、ｓ０はリソース合計の暫定値である。初期値として考えられる最悪の値を入れておく。
ステップＳ１０３：リソース合計ｓが目的とする値ａを超えるまで加える。
ｓ＝ｓ＋Ｄ［ｉ］、ｉ＝ｉ＋１
ステップＳ１０４：ｓがｓ０より良い値を実現できたときＤ０＝Ｄ、ｉ０＝ｉ、ｓ０＝ｓとして記録を更新する。
ステップＳ１０５：ｃｔ＜ｍのときＤを並べ替えてステップＳ１０３からの処理を繰り返す。

ここで、Ｄの並べ替えの方法としては、ｎをベクトルＤの長さとして、
（数１）
ｒ１＝ｒａｎｄｏｍ（ｎ）
ｒ２＝ｒａｎｄｏｍ（ｎ）
ｘ＝Ｄ［ｒ１］
Ｄ［ｒ１］＝Ｄ［ｒ２］
Ｄ［ｒ２］＝ｘ
のように２つずつ並べ替える方法や、Ｆｉｓｈｅｒ−Ｙａｔｅｓ ｓｈｕｆｆｌｅなどを用いてＤ全体を並べ替える方法があるが、これらの特定の並べ方に限定されないことはいうまでもない。現実的に収束する速度が早いものを適切に選択すれば良い。

ステップＳ１０６：ｃｔ≧ｍとなったら、記録しておいたＤ０、ｉ０、ｓ０を出力して終了する。

上述した方法は、容易に多変数のリソース種別を持つ場合の、最適な組み合わせを求めるアルゴリズムに拡張することが容易である。図１３及び図１４に、概要フローを示す。
ステップＳ２０１：リソース種別として、ｋ変数からなるデータＤを、特定または、任意の複数のＯＦＣ９２からサンプリングする。この場合Ｄはｎ行ｋ列の行列である。
ステップＳ２０２：リソースの状態Ｄ０を記録する。ａ＝（ａ０，ａ１，……，ａ（ｋ−１））はリソース合計の目的値、ｍは繰り返し回数の上限である。ｃｔは繰り返しのカウンタ、ｓ００はリソース合計差分の暫定値である。初期値として考えられる最悪の値を入れておく。

ステップＳ２０３〜Ｓ２０８：ｊ番目のリソース合計ｓｊが目的値ａｊを超えるまで加える。ここで、ｓｊは以下の式で表わされる。
（数１）
ｓｊ＝ｓｊ＋Ｄ［ｉ，ｊ］
ｓ＝｜ｓ０−ａ０｜＋……＋｜ｓｊ−ａｊ｜＋……＋｜ｓ（ｋ−１）−ａ（ｋ−１）｜
明らかに、ｓが小さいことは記録されたＤ０が最適解に近いことを表している。特にｓ００＝０のときは最適解が得られたことを保証できる。

ステップＳ２０４：ｓがｓ００より良い値を実現できたときＤ０＝Ｄ、ｉ０＝ｉ、ｓ００＝ｓとして記録を更新する。
ステップＳ２０５：ｃｔ＜ｍのときＤを並べ替えてステップＳ２０３からの処理を繰り返す。
ここで、Ｄの並べ替えの方法としてはｎをＤの行数とし、ｒ番目の行ベクトルをＤ［ｒ，］として、
（数２）
ｒ１＝ｒａｎｄｏｍ（ｎ）
ｒ２＝ｒａｎｄｏｍ（ｎ）
ｘ＝Ｄ［ｒ１，］
Ｄ［ｒ１，］＝Ｄ［ｒ２，］
Ｄ［ｒ２，］＝ｘ
のように２行ずつ並べ替える方法やＦｉｓｈｅｒ−Ｙａｔｅｓ ｓｈｕｆｆｌｅなどを用いてＤ全体を並べ替える方法があるが、これに限定される必要のないことは、いうまでもない。
並べ替えを行った結果、同じものが、出現されることがなければ、どのような並べ替えアルゴリズムを用いても良い。

ステップＳ２０６：ｃｔ＞＝ｍとなったら記録しておいたＤ０、ｉ０、ｓ００を出力して終了する。

一方、新たに発生するトラヒックフローに対して、図１０に記載の方法によりプロキシとなるＯＦＣ９２に対して割り振りルールを指定することで、イベントの種類毎に、それぞれ使用するＯＦＣ９２の番号を指定して、当該の処理を、特定のＯＦＣ９２に分担させるための機能分散の手法を用いて、機能別にＯＦＣ９２を配備することが可能であることは言うまでもない。

また図９に記載のマスター／スレーブ方式の複数ＯＦＣ利用形態においては、新たなＯＦＣ９２が割り当てられた後は、当該の新たなコントローラがをマスターとする旨を、ＯＦＳ９１に迅速に通知することが好ましい。

上記には、ライブクローン制御機能９５３により複製されたＯＦＣ９２間の負荷分散制御方法と、複数のＯＦＣ９２間の負荷分散制御方法を別々に記載したが、適宜組み合わせて使用する制御方法を適切に混在できることは、言うまでもない。

ＯＦＣ９２の処理能力がダイナミックに変動する場合には、各ＯＦＣ９２から一定の周期で、その時点でのリソース処理能力を、ライブクローン制御機能９５３、ロードバランス制御機能９５４に通知することにより、ＯＦＣリソースコントローラ９５は最新の状況を把握できる。当該のＯＦＣリソースコントローラ９５は、この情報に基づいて、次に割り当てるべきＯＦＣ９２＃や次にライブクローンを行うべきＯＦＣ９２＃を決定することができる。

図１５は、地域サーバ群＃１、＃２、＃３に対応して、ＯＦＳ９１が存在した時に、それぞれのサーバ群から、未定義フロートラヒックが対応するＯＦＳ９１＃に流入し、対応するＯＦＣ９２＃に向けて制御トラヒックが発生した場合の基本的なネットワーク構成を示すものである。図１５では、ＯＦＣ９２＃１内に仮想マシン７１＃２〜７１＃ｒが生成され、ＯＦＣ９２＃２内に仮想マシン７１＃２〜７１＃ｓが生成され、ＯＦＣ９２＃３内に仮想マシン７１＃２〜７１＃ｔが生成される場合を示す。制御用トラヒック量が予め規定された閾値を超えたことを検知すると、それぞれのＯＦＣ９２＃に、予め割り当てられた、オープンクラウドのサイトへ接続し、当該のオープンクラウドのサイトでは、必要な処理能力に応じて、クローン作成あるいは、ライブマイグレーションを逐次、実施する。当該のリソースの量が十分確保されている場合には、その範囲の中で、要求に応じて、適切に、ＯＦＣ９２を拡張することができる。

地域サーバ群＃１、＃２、＃３があった場合に、それぞれの地域サーバ群から未定義フロートラヒックがＯＦＳ９１に流入し、対応するＯＦＣ９２＃に向けて制御トラヒックが発生した場合に、ＯＦＣ９２が処理すべき制御用トラヒックが、予め規定された閾値を超えたことを検知すると、共通的に使用可能な、オープンクラウドのサイト（ＯＦＣ９２＃１）へ接続してもよい。この場合、ＯＦＣ９２＃１で、接続要求に応じて必要な処理能力に対応できるための、ライブクローン化を逐次実施し、所望の処理能力を達成するための基本構成である。

以上、説明したように、本発明の特徴は
集中制御を前提とした、ネットワーク制御方式において、
（１）クラウドのもつ仮想サーバのリソースを有効に活用し、
（２）ネットワークを集中制御するコントローラの処理能力のダイナミック制御を、
（３）トラヒックの急激な増加やネットワーク機器の故障等の状況に応じて
（４）リアルタイムに、同一クラウド内、および異なるクラウド間に跨る範囲において、開示した技術は、
既存のクラウドが保有するリソースを、要求されるリソースに関わる条件を満足できるように、最大限に活用して、融通性の高いコントローラ（ネットワーク制御系）を構築できる特徴をもつ。

すなわち、開示した技術はクラウドを活用し、ネットワーク制御系を構築する場合に、最初から最大負荷に応じた設備を備えることを不要とし、必要に応じて処理能力を増減できる融通性を具備するものである。さらに、開示した技術は、ライブクローンを用いた制御を行うことにより、既存のシステムの流用が可能であると共に、シンプルな制御（ライブクローンの複製や削除）で上記特徴を達成できる。不要になったネットワーク制御用のリソースに関しては、逐次、ライブクローンを解放する等のプロシージャ―を組み込むことにより、稼働中のクラウドのリソースを有効に活用できることができ、最新のトラヒック処理状況に見合う、制御系の処理能力を備えるネットワーク構成を実現できる。

このように、ネットワークソフトウェアを、クラウド上で、大規模に仮想化できるメリットを、十分に発揮することができる。また、開示した本技術は、ＳＤＮに代表されるオープンフロータイプのネットワークに適用できるだけでなく、ＮＧＮや既存の携帯電話網の制御やオペレーションシステムの処理能力の増強にも適用でき、適用対象範囲は極めて広い。以上説明したように、本技術は安全なネットワークを、実現する上での基盤技術として活用でき、今後の情報通信産業を発展させる上で、極めて大きな意義を持つ。

本発明は情報通信産業に適用することができる。

１１：フローテーブル
１２：スイッチ
７１：仮想マシン
７２：データベース（ＤＢ）
７３：マスターイメージ
７４：差分ファイル
８１：インフラストラクチャーレイヤ
８２：制御レイヤ
８３：アプリケーションレイヤ
９１：オープンフロースイッチ（ＯＦＳ）
９２：オープンフローコントローラ（ＯＦＣ）
９３：ネットワークアプリケーション
９４：ホスト
９５：ＯＦＣリソースコントローラ
９５１：オープンフロー制御トラヒック監視機能
９５２：ＯＦＣリソース負荷監視機能
９５３：ライブクローン制御機能
９５４：ロードバランス制御機能

Claims (10)

1. ソフトウェア制御を用いてスイッチの出力経路を制御するＳＤＮ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）コントローラと、
   前記スイッチと前記ＳＤＮコントローラ間の制御トラヒック及び前記ＳＤＮコントローラのリソースに基づいて前記ＳＤＮコントローラが過負荷状態であることを判定し、過負荷状態にあるＳＤＮコントローラのライブクローンを生成するＳＤＮコントローラ制御部と、
   を備えるネットワーク制御システム。
2. 前記ＳＤＮコントローラ制御部は、
   前記ライブクローンの生成に必要なリソースの処理速度又はメモリ容量を含む条件を、過負荷状態にあるＳＤＮコントローラのリソースに基づいて決定し、決定した条件を満足する仮想マシンを構築する、
   請求項１に記載のネットワーク制御システム。
3. １つの前記ＳＤＮコントローラは、データの同期されている複数のデータベースを備え、
   前記複数のデータベースのうちの１つが、前記ＳＤＮコントローラ制御部からの指示に従い、当該データベースに記憶されているデータを複製する機能をもつと共に、
   前記仮想マシンは、前記複数のデータベースのうちの利用可能な他の１つを参照して、前記スイッチの接続処理を行う、
   請求項２に記載のネットワーク制御システム。
4. 複数の前記ＳＤＮコントローラが共通の前記スイッチの出力経路を制御し、
   前記複数のＳＤＮコントローラに備わる前記データベースは、前記スイッチの出力経路を制御するための同一内容のフローテーブルを格納している、
   請求項３に記載のネットワーク制御システム。
5. 前記ＳＤＮコントローラ制御部は、前記ＳＤＮコントローラに故障が発生したことを判定し、故障が発生したＳＤＮコントローラのライブクローンを生成する
   、
   請求項１から４のいずれかに記載のネットワーク制御システム。
6. ソフトウェア制御を用いてスイッチの出力経路を制御するＳＤＮコントローラの制御方法であって、
   前記スイッチと前記ＳＤＮコントローラ間の制御トラヒック及び前記ＳＤＮコントローラのリソースに基づいて前記ＳＤＮコントローラが過負荷状態であることを判定する判定手順と、
   過負荷状態にあるＳＤＮコントローラのライブクローンを生成する制御手順と、
   有するネットワーク制御方法。
7. 前記制御手順において、前記ライブクローンの生成に必要なリソースの処理速度又はメモリ容量を含む条件を、過負荷状態にあるＳＤＮコントローラのリソースに基づいて決定し、決定した条件を満足する仮想マシンを構築する、
   請求項６に記載のネットワーク制御方法。
8. １つの前記ＳＤＮコントローラは、データの同期されている複数のデータベースを備え、
   前記制御手順において、
   前記複数のデータベースのうちの１つが、前記ＳＤＮコントローラ制御部からの指示に従い、当該データベースに記憶されているデータを複製する機能をもつと共に、
   前記仮想マシンは、前記複数のデータベースのうちの利用可能な他の１つを参照して、前記スイッチの接続処理を行う、
   請求項７に記載のネットワーク制御方法。
9. 複数の前記ＳＤＮコントローラが共通の前記スイッチの出力経路を制御し、
   前記複数のＳＤＮコントローラに備わる前記データベースは、前記スイッチの出力経路を制御するための同一内容のフローテーブルを格納している、
   請求項８に記載のネットワーク制御方法。
10. 前記判定手順において、前記ＳＤＮコントローラに故障が発生したことを判定し、
    前記制御手順において、故障が発生したＳＤＮコントローラのライブクローンを生成する
    、
    請求項６から９のいずれかに記載のネットワーク制御方法。

Images