(57)【要約】【課題】コントローラの負荷を上昇させることなく、仮想ネットワークの監視を実現するネットワークシステムを提供する。【解決手段】ネットワークシステムは、複数のスイッチと、コントローラと、管理装置と、を含む。コントローラは、複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築する。管理装置は、複数のスイッチからなる物理ネットワークと仮想ネットワークを管理する。コントローラは、管理装置からの仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを複数のスイッチのなかから選択する。代理スイッチは、管理装置から要求された管理情報を保持していない場合には、保持していない管理情報を他のスイッチから取得する。【選択図】図１
2019186822.tif 000002
【特許請求の範囲】
【請求項１】
複数のスイッチと、
前記複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築する、コントローラと、
前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する、管理装置と、
を含み、
前記コントローラは、前記管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択し、
前記代理スイッチは、前記管理装置から要求された管理情報を保持していない場合には、前記保持していない管理情報を他のスイッチから取得する、
ネットワークシステム。
【請求項２】
前記コントローラは、
前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知し、
前記代理スイッチは、前記問い合わせ情報に基づき、前記要求された管理情報を取得する、請求項１に記載のネットワークシステム。
【請求項３】
前記代理スイッチは、前記問い合わせ情報を参照し、
前記要求された管理情報を自装置の内部に保持している場合には、前記内部に保持している管理情報を前記管理装置に返信し、
前記要求された管理情報を他のスイッチが保持している場合には、前記要求された管理情報を前記他のスイッチから取得して前記管理装置に返信する、請求項２に記載のネットワークシステム。
【請求項４】
前記代理スイッチは、
前記内部に保持している管理情報と前記他のスイッチから取得した管理情報を統合し、前記統合された管理情報を前記管理装置に返信する、請求項３に記載のネットワークシステム。
【請求項５】
前記管理装置は、ＳＮＭＰ（Simple Network Management Protocol）を用いて前記仮想ネットワークノードの管理情報を取得し、
前記問い合わせ情報には、
取得対象となる前記仮想ネットワークノードのオブジェクト識別子と、前記取得対象となるオブジェクト識別子を保持するスイッチのアドレスと、前記取得対象となるオブジェクト識別子を保持するスイッチから取得するオブジェクト識別子に関する情報と、が含まれる、請求項２乃至４のいずれか一項に記載のネットワークシステム。
【請求項６】
前記取得対象となるオブジェクト識別子を保持するスイッチから取得するオブジェクト識別子に関する情報は、プライベートＭｉＢ（Management information Base）である、請求項５に記載のネットワークシステム。
【請求項７】
前記代理スイッチは、前記プライベートＭｉＢに格納された情報を所定期間参照されない場合に、前記所定期間参照されないプライベートＭｉＢに格納された情報を削除する、請求項６に記載のネットワークシステム。
【請求項８】
複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築し、
前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択し、
前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知する、コントローラ。
【請求項９】
複数のスイッチと、
前記複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築する、コントローラと、
前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する、管理装置と、
を含むネットワークシステムにおいて、
前記管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択するステップと、
前記代理スイッチは、前記管理装置から要求された管理情報を保持していない場合には、前記保持していない管理情報を他のスイッチから取得するステップと、
を含む、仮想ネットワーク監視方法。
【請求項１０】
複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築するコントローラに搭載されたコンピュータに、
前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択する処理と、
前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム、コントローラ、仮想ネットワーク監視方法及びプログラムに関する。
【背景技術】
【０００２】
近年、ネットワークの仮想化の進歩により、Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ（ＳＤＮ）が普及している。ＳＤＮの普及により、物理ネットワークを論理的に制御することでより柔軟なネットワークを構成することが可能になっている。非特許文献１は、ＳＤＮを構築するにあたり用いられるオープンフロースイッチの仕様書である。
【０００３】
特許文献１は、仮想化システムが運用管理サーバからの要求を全て受け、必要な情報の収集および変換を代理で実施する技術を開示している。また、特許文献２は、ＶＰＮ（Virtual Private Network）上に作成された仮想ネットワークを監視する際の代理応答手段を開示している。特許文献３は、ＳＮＭＰ（Simple Network Management Protocol）マネージャが仮想ポートに対してＳＮＭＰ要求した際に、受信したスイッチが仮想と物理の変換を実施し、代理応答を実施する技術を開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１２９５２８号公報
【特許文献２】特開２００５−３５４４２６号公報
【特許文献３】特表２００３−５０４９６１号公報
【非特許文献】
【０００５】
【非特許文献１】ＯｐｅｎＦｌｏｗ  Ｓｗｉｔｃｈ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｖｅｒｓｉｏｎ  １．５．１  （Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ０ｘ０６）、ＯＮＦ、［ｏｎｌｉｎｅ］、［平成３０（２０１８）年４月３日検索］、インターネット〈URL: https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【０００６】
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
【０００７】
ＳＤＮにより制御されたネットワークは、設定情報の管理やセキュリティにおいては有用である。しかし、一つの物理リソースの上に複数の仮想ネットワークが展開されるため、一か所の物理障害が複数の仮想ネットワークへ影響してしまう。そのため、ＳＤＮにより制御されるネットワークは、物理障害の影響が大きくなりやすく、ネットワークの監視が以前にも増して重要になってきている。
【０００８】
ここで、仮想化されたネットワークは物理的なノードとして存在するわけではないため、ＳＮＭＰのようなＮｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（ＮＭＳ）が持つ監視技術との親和性が低い。そのため、性能監視やトポロジーの監視など既存のＮＭＳが有する機能を利用できないことが多い。
【０００９】
また、既存の監視手段に合わせて仮想ネットワーク情報を提供することも考えられるが、仮想ネットワーク情報はスイッチを制御するコントローラが保持している場合が多い。そのため、コントローラから全ての仮想ネットワーク情報を問い合わせる（取得する）となると、コントローラの負荷上昇が問題となる。さらに、コントローラが必要な情報を持っておらず、物理ネットワークノードへ問い合わせが必要な場合、コントローラと物理ネットワークノード（スイッチ）間で頻繁に通信が必要になり、さらに負荷が高まってしまう。
【００１０】
上記に記載した通り、仮想化されたネットワークでは障害に対する監視がますます重要になってきているが、既存の監視技術との親和性およびコントローラの負荷上昇など多くの問題がある。
【００１１】
このように、既存の分散システムとして動いていたネットワークとは異なり、多くのネットワークの仮想化技術は、ネットワークに存在するノードを集約管理することで仮想化を実現している。その構造上、仮想ネットワークノードの情報を取得するには、多くの場合コントローラに問い合わせる必要がある。しかし、既存のコントローラはネットワーク制御機能に重きを置いており、制御しているネットワークの監視や可視化機能については既存監視技術が有する機能に及ばない。それだけでなく、既存のＮＭＳの監視技術との親和性も悪いため、ネットワークの仮想化技術には監視面において大きな問題点が存在する。
【００１２】
なお、上記問題点は上記特許文献１乃至３に開示された技術を適用しても解決することができない。
【００１３】
特許文献１では、仮想化システムが全てを管理するため、シンプルな構成ではあるが、負荷が仮想化システムに集中する問題がある。例えば、オープンフローで管理されたネットワークでは、当該仮想化システムはコントローラが該当する。作成されている仮想ネットワークの数にも依存するが、当該文献の手法では、コントローラに非常に大きな負荷がかかることが見込まれる。オープンフローでは、コントローラへの負荷はそのままネットワーク障害へ繋がるため、負荷の集中が大きな問題となり得る。
【００１４】
特許文献２では、運用管理サーバと仮想ネットワーク間にＰＥ（Provider Edge ）ルータ(エッジルータ)の存在が前提となっている。当該文献に開示された技術では上記ＰＥルータが代理取得、応答、情報保存の全てを担っているため、基点となるネットワークノードの負荷が大きいという問題がある。
【００１５】
特許文献３では、前提としてＳＮＭＰマネージャがどの物理スイッチがどの仮想ポート情報をもつのかを把握している必要がある。通常のＳＮＭＰマネージャによる監視では、監視対象のＩＰ（Internet protocol）アドレスで情報の取得を行うため、上記の制限は不利益が大きい。
【００１６】
本発明は、コントローラの負荷を上昇させることなく、仮想ネットワークの監視を実現することに寄与するネットワークシステム、コントローラ、仮想ネットワーク監視方法及びプログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【００１７】
本発明乃至開示の第１の視点によれば、複数のスイッチと、前記複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築する、コントローラと、前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する、管理装置と、を含み、前記コントローラは、前記管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択し、前記代理スイッチは、前記管理装置から要求された管理情報を保持していない場合には、前記保持していない管理情報を他のスイッチから取得する、ネットワークシステムが提供される。
【００１８】
本発明乃至開示の第２の視点によれば、複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築し、前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択し、前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知する、コントローラが提供される。
【００１９】
本発明乃至開示の第３の視点によれば、複数のスイッチと、前記複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築する、コントローラと、前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する、管理装置と、を含むネットワークシステムにおいて、前記管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択するステップと、前記代理スイッチは、前記管理装置から要求された管理情報を保持していない場合には、前記保持していない管理情報を他のスイッチから取得するステップと、を含む、仮想ネットワーク監視方法が提供される。
【００２０】
本発明乃至開示の第４の視点によれば、複数のスイッチを制御し、仮想ネットワークノードからなる仮想ネットワークを構築するコントローラに搭載されたコンピュータに、前記複数のスイッチからなる物理ネットワークと前記仮想ネットワークを管理する管理装置からの前記仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを前記複数のスイッチのなかから選択する処理と、前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００２１】
本発明乃至開示の各視点によれば、コントローラの負荷を上昇させることなく、仮想ネットワークの監視を実現することに寄与するネットワークシステム、コントローラ、仮想ネットワーク監視方法及びプログラムが、提供される。
【図面の簡単な説明】
【００２２】
【図１】一実施形態の概要を説明するための図である。
【図２】第１の実施形態に係るネットワークシステムの概要を説明するための図である。
【図３】物理ノードと仮想ノードのマッピングの一例示す図である。
【図４】コントローラが作成する問い合わせ表マスターデータの一例を示す図である。
【図５】コントローラが各代理スイッチに配布する問い合わせ表の一例を示す図である。
【図６】第１の実施形態に係るコントローラとスイッチの処理構成の一例を示す図である。
【図７】スイッチがＳＮＭＰパケットを受信した時の問い合わせ処理の一例を示すフローチャートである。
【図８】コントローラ及びスイッチの問い合わせ表更新処理の一例を示すフローチャートである。
【図９】第２の実施形態に係るネットワークシステムの概要を説明するための図である。
【図１０】物理ノードと仮想ノードのマッピングの一例示す図である。
【図１１】問い合わせ表の一例を示す図である。
【図１２】第２の実施形態におけるｓｙｓｔｅｍに関する問い合わせ表の一例を示す図である。
【図１３】第３の実施形態に係るネットワークシステムの概要を説明するための図である。
【図１４】第３の実施形態におけるｓｙｓｔｅｍに関する問い合わせ表の一例を示す図である。
【図１５】第３の実施形態におけるｓｙｓｔｅｍに関する問い合わせ表の一例を示す図である。
【図１６】第３の実施形態に係るスイッチのＳＮＭＰリクエストを受信した場合の動作の一例を示すフローチャートである。
【図１７】コントローラのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００２３】
初めに、本願開示における以下の単語の定義について記載する。
【００２４】
・物理ネットワークノード（物理ノード）
物理ネットワークノードは、物理スイッチや物理ルータなどの通信を中継する機能を持つノードである。
【００２５】
・仮想ネットワークノード（仮想ノード）
仮想ネットワークノードは、仮想スイッチや仮想ルータなどの仮想的に通信を中継する機能を有し、コントーラにより物理ノード上で仮想的に実現されるノードである。
【００２６】
・ＳＮＭＰリクエスト
ＳＮＭＰリクエストは、ＳＮＭＰマネージャが送信するＳＮＭＰメッセージのうち、Get RequestやGetNext RequestなどＭｉＢ（Management information Base）を要求するＳＮＭＰパケットのことを示す。
【００２７】
・ＳＮＭＰレスポンス
ＳＮＭＰレスポンスは、ＳＮＭＰエージェントが送信するＳＮＭＰメッセージのうち、Get Responseなど、ＳＮＭＰリクエストへの応答のためのＳＮＭＰパケットのことを指す。
【００２８】
続いて、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。
【００２９】
一実施形態に係るネットワークシステムは、複数のスイッチ１０１と、コントローラ１０２と、管理装置１０３と、を含む（図１参照）。コントローラ１０２は、複数のスイッチ１０１を制御し、仮想ネットワークノードからなる仮想ネットワークを構築する。管理装置１０３は、複数のスイッチ１０１からなる物理ネットワークと仮想ネットワークを管理する。コントローラ１０２は、管理装置１０３からの仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを複数のスイッチ１０１のなかから選択する。代理スイッチは、管理装置１０３から要求された管理情報を保持していない場合には、保持していない管理情報を他のスイッチ１０１から取得する。
【００３０】
上記ネットワークシステムでは、仮想ネットワークノード（仮想ノード）の管理情報を複数のスイッチ１０１に分散して配置する。管理情報が複数のスイッチ１０１に分散して配置されるため、各代理スイッチには、管理装置１０３からの要求に対する必要な管理情報が保持されていないことがあり得る。この場合、各代理スイッチは、要求された管理情報を保持する他のスイッチ１０１から必要な管理情報を収集し、管理装置１０３からの要求に応答する。即ち、上記ネットワークシステムでは、コントローラやスイッチの負荷（ネットワーク負荷）を低減するため、代理応答する機器を分散配置している。
【００３１】
以上のように、複数のスイッチ１０１がコントローラ１０２で制御されており、物理ネットワークが仮想化されているネットワークにおいて、仮想ネットワークの監視をコントローラ１０２又は特定のスイッチ１０１に負荷を集中させることなく実現する。より具体的には、物理ネットワークをＳＮＭＰで監視するような手順により仮想ネットワークの監視、管理を実現する。当該実現のため、コントローラ１０２は、仮想ネットワークを作成する機能と、作成した仮想ネットワークノードと物理ネットワークノードのポートをマッピングする機能と、を備える。さらに、コントローラ１０２は、マッピング情報をもとに問い合わせ表（問い合わせ情報）を作成する機能と、作成した問い合わせ表を通知する機能と、を備える。また、スイッチ１０１は、代理応答するにあたって不足情報があった場合、問い合わせ表に基づき必要な情報を収集する機能を備える。コントローラ１０２にてマッピング情報をもとに作成された問い合わせ表はスイッチ１０１に通知される。スイッチ１０１は、通知された問い合わせ表を記憶することで、スイッチ１０１にて受信した仮想ネットワークノード宛のＳＮＭＰリクエストに代理応答することを可能とする。その結果、仮想ネットワークノードのＳＮＭＰ監視及びその負荷分散が実現される。
【００３２】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
【００３３】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００３４】
初めに、図２を参照しつつ、第１の実施形態に係るシステム（ネットワーク監視システム）の概略を説明する。
【００３５】
図２に示すコントローラ１０はスイッチ２０−１、スイッチ２０−２、スイッチ２０−３を制御し、物理ネットワークと仮想ネットワークのマッピングを行うＳＤＮコントローラ（制御装置）である。コントローラ１０は、複数のスイッチ２０−１〜２０−３を制御し、仮想ネットワークノードからなる仮想ネットワークを構築する。
【００３６】
スイッチ２０−１、スイッチ２０−２、スイッチ２０−３はＳＤＮコントローラによって制御されるＳＤＮスイッチである。
【００３７】
なお、以降の説明において、スイッチ２０−１〜２０−３を区別する特段の理由がない場合には単に「スイッチ２０」と表記する。他の構成についても同様に表記する。
【００３８】
コントローラ１０は、例えば、非特許文献１に記載されているオープンフローコントローラ相当の機器である。また、スイッチ２０は、非特許文献１に記載されているオープンフロースイッチ相当の機器である。これらの基本動作は、非特許文献１に記載されているので説明を省略する。
【００３９】
ＮＭＳ３０は物理ネットワークおよび仮想ネットワークを監視する監視装置（ネットワーク管理システム）である。ＮＭＳ３０は、複数のスイッチ２０からなる物理ネットワークと仮想ネットワークを管理する装置である。ＮＭＳ３０は、ＳＮＭＰを用いて物理ネットワークノード、仮想ネットワークノードの管理情報を取得する。但し、ＮＭＳ３０が使用するプロトコルをＳＮＭＰに限定する趣旨でない。
【００４０】
なお、図２の構成は例示であって、スイッチ２０等の数を限定する趣旨ではないことは勿論である。
【００４１】
初めに、仮想ネットワーク作成時の動作について説明する。第１の実施形態では、仮想ネットワークの作成操作において、物理ネットワークとのマッピングおよび管理ＩＰアドレスの設定が重要となる。これらの設定変更を契機に後述する問い合わせ表（ＳＮＭＰ問い合わせ表）が作成され、当該作成された問い合わせ表がスイッチ２０に通知される。これらの動作について詳しく記載する。
【００４２】
例えば、コントローラ１０は、仮想スイッチとしてｖｂｒｉｄｇｅ４０−１、ｖｂｒｉｄｇｅ４０−２、仮想ルータとしてｖｒｏｕｔｅｒ５０のインスタンスを作成する。さらに、コントローラ１０は、図２のようにｖｂｒｉｄｇｅ４０−１とｖｂｒｉｄｇｅ４０−２をｖｒｏｕｔｅｒ５０と接続する。また、コントローラ１０は、各ｖｂｒｉｄｇｅ４０の仮想インターフェイスと各スイッチ２０の物理ポートを１対１でマッピングし、図３のように設定したとする。なお、図３では、物理ネットワークノードのインターフェイスに関し、スタック可能なボックス型の表記を採用している。
【００４３】
コントローラ１０は、マッピングの際、同じｖｂｒｉｄｇｅ４０にマッピングされたスイッチ２０の物理ポートは同じサブネットに属し、異なるｖｂｒｉｄｇｅ４０にマッピングされている物理ポートとは異なるサブネットに属するようにする。例えば、ｖｂｒｉｄｇｅ４０−１のＩＦ（Interface）１が１７２．１６．０．０／１６のネットワークに属していた場合、ＩＦ２、ＩＦ３にマッピングされたスイッチ２０の物理ポートも同じ１７２．１６．０．０／１６に属するようにする。換言すれば、ｖｂｒｉｄｇｅ４０−２のＩＦ１、ＩＦ２にマッピングされたスイッチ２０の物理ポートは１７２．１６．０．０／１６とは別のサブネットに属することになる。よって、同じスイッチ２０の物理ポート間の通信でもマッピングされたｖｂｒｉｄｇｅ４０が異なれば、ｖｒｏｕｔｅｒ５０を介したＬ３（レイヤ３）転送で通信が行われる。なお、本願開示ではｖｒｏｕｔｅｒ５０とｖｂｒｉｄｇｅ４０間の通信は物理インターフェイスを介さず、スイッチ２０内で論理的に処理されるものとする。そのため、仮想ネットワークノード間の仮想インターフェイスは物理ポートにマッピングされない。
【００４４】
次に、コントローラ１０は、作成した仮想ネットワークノードの管理ＩＰアドレスとその管理ＩＰアドレスに実際に応答する代理スイッチを設定する。つまり、コントローラ１０は、管理装置であるＮＭＳ３０からの仮想ネットワークノードに対する管理情報取得要求に応答する代理スイッチを複数のスイッチ２０のなかから選択する。
【００４５】
管理ＩＰアドレスは仮想ネットワークノードをＳＮＭＰ監視するためのアドレスである。なお、コントローラ１０は、仮想ネットワークノードにマッピングされた複数のスイッチ２０から任意の方法でいずれか１つを選択して代理スイッチとする。例えば、図２、図３の例では、ｖｂｒｉｄｇｅ４０−１という仮想ネットワークノードにスイッチ２０−１、２０−２がマッピングされており、スイッチ２０−１が代理スイッチとして選択されている。また、ｖｂｒｉｄｇｅ４０−２の代理スイッチとしてスイッチ２０−２が選択されている。なお、スイッチ２０の負荷分散の観点からは、特定のスイッチ２０が多くの代理スイッチとして動作しないことが望ましい。
【００４６】
コントローラ１０は、代理スイッチへ仮想ネットワークノードの管理ＩＰアドレスを通知して、割り当てられた仮想ネットワークノードの管理ＩＰアドレス宛てのＡＲＰ（Address Resolution Protocol）に応答させる。例えば、図２のようにｖｂｒｉｄｇｅ４０−１に１９２．１６８．５０．１１／２４の管理ＩＰアドレスが設定され、代理スイッチとしてスイッチ２０−１が指定される。この場合、当該管理ＩＰをスイッチ２０−１に通知しておくことで、ｖｂｒｉｄｇｅ４０−１宛のパケットがスイッチ２０−１に届くようになる。
【００４７】
スイッチ２０が代理スイッチとして指定された初期状態では、未だ代理スイッチが仮想ネットワークノードのＭｉＢ情報を有していないため、代理スイッチは、担当する仮想ネットワークノード宛のＳＮＭＰパケットを受信しても応答することができない。そこで、コントローラ１０は、問い合わせ表を用いて代理スイッチにＭｉＢ情報を収集させる。問い合わせ表とは、仮想ネットワークノードのＭｉＢ情報（管理情報）がどのスイッチ２０のＭｉＢ情報に対応しているかを示したものである。このように、問い合わせ表は、仮想ネットワークノードの管理情報を保持するスイッチ２０に関する情報を含む情報である。
【００４８】
問い合わせ表の作成には、仮想ネットワークと物理ネットワークのマッピング情報が必要となる。そのため、マッピング情報をもつコントローラ１０が問い合わせ表のマスターデータ（原本）を作成する。例えば、コントローラ１０は、図４に示す問い合わせ表マスターデータを作成する。図４を参照すると、仮想ネットワークノードごとに各ＯＩＤ（Object IDentifier；オブジェクト識別子）の問い合わせ先（スイッチ２０のアドレス；管理情報の所有者）と元のＯＩＤに対する差分情報（補足情報、補正情報）が記載されている。
【００４９】
コントローラ１０は、作成した問い合わせ表を各代理スイッチに通知する。その際、コントローラ１０は、作成した問い合わせ表マスターデータから、各スイッチ２０がＳＮＭＰ応答を代理する仮想ネットワークノードの問い合わせ表を抽出し、当該抽出した問い合わせ表を対応するスイッチ２０に通知する。例えば、図５に示すように、スイッチ２０−１はｖｂｒｉｄｇｅ４０−１の代理スイッチであるため、スイッチ２０−１に対して当該仮想ブリッジに関する問い合わせ表が通知される。各代理スイッチはこの表を使用して、必要なＭｉＢ情報を収集し、代理応答をする。
【００５０】
当該処理について、図２の構成を使用して説明する。ｖｂｒｉｄｇｅ４０−２宛てにifIndex.1を要求するＳＮＭＰパケットが送信されたとする。ｖｂｒｉｄｇｅ４０−２の代理スイッチはスイッチ２０−２であるため、スイッチ２０−２がこのパケットを受信する。受信後、スイッチ２０−２は問い合わせ表を確認する。問い合わせ表から必要な情報はスイッチ２０−１が保持していることが分かるため、スイッチ２０−２は、スイッチ２０−１へifIndex.1を要求するＳＮＭＰパケットを送信する。スイッチ２０−２は、ifIndex.1の情報を受信後、その情報をＳＮＭＰパケットに格納してＮＭＳ３０へ返信する。当該返信により、スイッチ２０−２は代理応答を終了する。
【００５１】
なお、仮想ネットワーク宛のＳＮＭＰの代理応答をコントローラ１０にさせる方法もある。しかし、この方法は問い合わせ表が不要である利点があるが、コントローラ１０の負荷上昇が懸念される。コントローラ１０の負荷は全ネットワークへ影響が出る可能性があるため、本願開示ではこれを理由にコントローラ１０に代理取得させない方法を選択している。
【００５２】
また、図４、図５に示す表では、あえて問い合わせ先のＯＩＤ（Object IDentifier）を直接記載せず、元のＯＩＤに対する差分情報（差分値）を記載している。例えば、図５の３行目に示す「−１」は元のＯＩＤである「IfIndex.3」に対し、当該元のＯＩＤから「１」を減算した「ifIndex.2」を取得することを示している。このように、第１の実施形態では、取得対象の管理情報（ＯＩＤ）に対する差分により問い合わせ先のスイッチから取得する管理情報を相対的に指定している。このような差分情報を用いた管理情報の指定により、問い合わせ表が持つ情報量を減ずることができる。その結果、スイッチ２０の記憶容量削減が実現できる。
【００５３】
さらに、スイッチ２０が記憶する問い合わせ表も全ての仮想ネットワークノードの問い合わせ表を記憶するのではなく、代理する仮想ネットワークノードの表を記憶させることでスイッチ２０が使用する記憶容量を削減している。例えば、図２においてスイッチ２０−１はｖｂｒｉｄｇｅ４０−２とｖｒｏｕｔｅｒ５０の代理スイッチではないため、これらノードに関する問い合わせ表を記憶する必要がない。よって、スイッチ２０−１はｖｂｒｉｄｇｅ４０−１の問い合わせ表に限って記憶する（図５参照）。
【００５４】
次に、ＳＮＭＰリクエスト受信時の動作について説明する。なお、既に図２のように仮想ネットワークが作成され、物理ネットワークノードとのマッピングがされており、各スイッチ２０も図５に示す問い合わせ表を記憶しているものとする。
【００５５】
ＮＭＳ３０から図２のようにＳＮＭＰリクエストが送信され、スイッチ２０−２が受信したとする。スイッチ２０−２では、まず受信したＳＮＭＰリクエストが仮想ネットワークノード宛か自スイッチ宛かどうかを確認する。スイッチ２０−２は、自スイッチ宛であれば、通常のＳＮＭＰ応答を実施する。一方、スイッチ２０−２は、仮想ネットワークノード宛のＳＮＭＰリクエストであれば、問い合わせ表を参照して問い合わせ先のスイッチ２０にＳＮＭＰパケットを送信する。その際、スイッチ２０−２は、問い合わせ表に記載された補足情報に従い問い合わせ先のスイッチ２０から取得する管理情報（ＯＩＤ）を指定する。
【００５６】
問い合わせ先のスイッチ２０では、通常のＳＮＭＰ処理を実施し、スイッチ２０−２へ応答する。スイッチ２０−２では問い合わせた情報を統合（マージ）して、ＮＭＳ３０へＳＮＭＰレスポンスを送信する。なお、問い合わせ表にＯＩＤが見つからなかった場合は、スイッチ２０−２は、ｎｏＳｕｃｈＮａｍｅ等のエラーステータスでＳＮＭＰ応答する。
【００５７】
図２ではｖｂｒｉｄｇｅ４０−２の全てのｉｆＩｎｄｅｘを要求するＳＮＭＰリクエストがスイッチ２０−２に送信されたときのシーケンス番号（数字とピリオドの組み合わせ）を図示している。スイッチ２０−２はｖｂｒｉｄｇｅ４０−２のｉｆＩｎｄｅｘ．２以外のＭｉＢを持っていない。そのため、問い合わせ表をもとに各スイッチ２０へＳＮＭＰリクエストを送信する。本例では、スイッチ２０−２は、ｉｆＩｎｄｅｘ．１についてはスイッチ２０−１へＳＮＭＰリクエストを送信する。ｉｆＩｎｄｅｘ．３とｉｆＩｎｄｅｘ．４については、スイッチ２０−２は、スイッチ２０−３へＳＮＭＰリクエストを送信する。スイッチ２０−２では各スイッチ２０へ送信したＳＮＭＰの応答を受信後、それらの情報をマージしてＮＭＳ３０へＳＮＭＰレスポンスを送信する。なお、ＮＭＳ３０へ送信するＳＮＭＰパケットの送信元ＩＰアドレスをｖｂｒｉｄｇｅ４０−２とすることで、ＮＭＳ３０からはｖｂｒｉｄｇｅ４０−２から応答があったかのように見せかける。
【００５８】
このように、複数のスイッチ２０のなかから選択された代理スイッチは、ＮＭＳ３０から要求された管理情報（ＯＩＤ）を保持していない場合には、当該保持していない管理情報を他のスイッチ２０から取得する。その際、代理スイッチは、問い合わせ表に基づき、ＮＭＳ３０から要求されたＯＩＤを取得する。より具体的には、代理スイッチは、問い合わせ表を参照し、要求された管理情報を自装置の内部に保持している場合には、当該内部に保持している管理情報をＮＭＳ３０に返信する。対して、代理スイッチは、要求された管理情報を他のスイッチが保持している場合には、当該要求された管理情報を当該他のスイッチから取得してＮＭＳ３０に返信する。また、要求された管理情報が複数のスイッチ２０に分散されて配置されている場合には、スイッチ２０は、自装置の内部に保持している管理情報と他のスイッチから取得した管理情報を統合（マージ）し、統合された管理情報をＮＭＳ３０に返信する。
【００５９】
続いて、各装置の処理構成（処理モジュール）について説明する。
【００６０】
図６は、コントローラ１０とスイッチ２０の処理構成の一例を示す図である。なお、ＮＭＳ３０に関しては、既存の装置を使用できるためその説明を省略する。
【００６１】
コントローラ１０は、仮想ネットワーク管理部２０１、スイッチ制御部２０２、問い合わせ表管理部２０３から構成される。
【００６２】
仮想ネットワーク管理部２０１は、仮想ネットワークノードの情報を記憶する。仮想ネットワーク管理部２０１は、システム管理者等から仮想ネットワークに対する操作があったときに、操作に合わせて記憶している仮想ネットワーク情報を更新する。
【００６３】
また、仮想ネットワーク管理部２０１は、更新内容に合わせてスイッチ制御部２０２および問い合わせ表管理部２０３に更新内容を通知する機能を備える。例えば、仮想ネットワークノード情報の更新により、仮想ネットワークノードと物理ネットワークノードとの間のマッピングに変更があった場合、仮想ネットワーク管理部２０１は、スイッチ制御部２０２を介してスイッチ２０へその情報を通知する。その結果、スイッチ制御部２０２により、スイッチ２０の転送テーブルが変更される。
【００６４】
また、仮想ネットワークノードの管理ＩＰアドレスの更新操作があった場合は、仮想ネットワーク管理部２０１は、問い合わせ表管理部２０３にその情報を通知して問い合わせ表の更新を行う。さらに、仮想ネットワーク管理部２０１は、スイッチ制御部２０２を介して全てのスイッチ２０にも当該情報を通知する。
【００６５】
スイッチ制御部２０２は、仮想ネットワークの更新内容に合わせてスイッチ２０と通信し、スイッチ２０がもつ転送テーブルおよび問い合わせ表の制御を担う処理モジュールである。例えば、仮想ネットワーク管理部２０１からマッピング変更の通知があった場合、スイッチ制御部２０２は、マッピング通りにパケットが転送されるように関連するスイッチ２０に制御命令（制御情報、フローエントリ、処理規則）を送信する。スイッチ制御部２０２は、スイッチ２０の制御に成功後、更新したマッピング情報を問い合わせ表管理部２０３に通知し、問い合わせ表の更新を行う。
【００６６】
スイッチ制御部２０２は、問い合わせ表管理部２０３から更新された問い合わせ表を受け取ったら、関連するスイッチ２０（代理スイッチ）に問い合わせ表を送信し、各スイッチ２０が持つ問い合わせ表の更新を行う。また、代理スイッチの変更があった場合、スイッチ制御部２０２は、同時に２つのスイッチ２０がＡＲＰ応答しないように先に旧代理スイッチに代理スイッチの解除通知をする。このとき、スイッチ制御部２０２は、例えば、仮想ネットワークノードが削除される場合には、関連する問い合わせ表もあわせて削除するように旧代理スイッチに通知する。スイッチ制御部２０２は、削除成功後、新代理スイッチへＡＲＰ応答するように管理ＩＰアドレスの通知、および、関連する問い合わせ表の通知を行う。
【００６７】
スイッチ２０がコントローラ１０の制御下におかれた際、スイッチ制御部２０２は、そのスイッチ２０の接続ＩＰアドレスを管理ＩＰアドレスとして問い合わせ表管理部２０３に記憶させる。具体的には、スイッチ制御部２０２は、スイッチ名とともにＩＰアドレスを問い合わせ表管理部２０３に通知する。
【００６８】
問い合わせ表管理部２０３は、上述の問い合わせ表（問い合わせ情報）を管理する処理モジュールである。問い合わせ表には、取得対象となる仮想ノードのＯＩＤと、当該取得対象のＯＩＤを保持するスイッチ２０のアドレスと、取得対象となるオブジェクト識別子を保持するスイッチ２０から取得するＯＩＤに関する情報と、が含まれる。
【００６９】
また、問い合わせ表管理部２０３は、物理と仮想の両方のネットワークノードの管理ＩＰアドレスを管理ＩＰテーブルとして記憶する。問い合わせ表管理部２０３は、仮想ネットワーク管理部２０１もしくはスイッチ制御部２０２から管理ＩＰアドレスに関する更新通知があった場合、その更新を行う。
【００７０】
問い合わせ表管理部２０３は、全仮想ネットワークノードに関する問い合わせ表をマスターデータ（原本；例えば、図４に示すデータ）として保持する。問い合わせ表管理部２０３は、スイッチ制御部２０２からマッピング情報の更新が通知されたら、その更新情報をもとにマスターデータの更新を行う。
【００７１】
さらに問い合わせ表管理部２０３は、制御下のスイッチ２０が保持する問い合わせ表も管理する。マスターデータが更新された後、スイッチ２０が持つ問い合わせ表の更新を必要とする場合、スイッチ制御部２０２を介してスイッチ２０に更新内容を送信し、スイッチ２０が持つ問い合わせ表の更新を行う。
【００７２】
スイッチ２０は転送制御部２１１、問い合わせ部２１２、問い合わせ表記憶部２１３から構成される。
【００７３】
転送制御部２１１は、スイッチ２０が持つ転送テーブルの更新および転送自体の機能を備える。例えば、コントローラ１０から制御命令（制御情報、フローエントリ、処理規則）を受信した場合、命令通りに転送するように自身の転送テーブルを変更する。また、仮想ネットワークノードの管理ＩＰアドレスの割り当て通知を受信した場合、転送制御部２１１は、自スイッチに仮想インターフェイスを作成し、そこに通知された管理ＩＰアドレスを割り当てる。
【００７４】
問い合わせ部２１２は、仮想ネットワークノード宛のＳＮＭＰパケットを受信した際に、必要な情報を収集するための問い合わせ処理を担う処理モジュールである。例えば、仮想ネットワークノード宛のＳＮＭＰパケットが転送制御部２１１から送信されてきた場合、問い合わせ部２１２は、要求しているＯＩＤを取得し、問い合わせ表記憶部２１３に当該問い合わせ先情報が存在するか否かを確認する。当該情報が存在しなければ、問い合わせ部２１２は、ＳＮＭＰの応答にエラーステータスとしてｎｏＳｕｃｈＮａｍｅを設定して送信する。問い合わせ先情報があれば、問い合わせ部２１２は、問い合わせ先にＭｉＢを要求するＳＮＭＰパケットを生成し、転送制御部２１１を介して送信する。問い合わせ処理により、必要なＭｉＢ情報を収集後、問い合わせ部２１２は、大元のＳＮＭＰパケットへ応答するため、データを整形して返信を行う。
【００７５】
問い合わせ表記憶部２１３は、スイッチ２０がもつ問い合わせ表を記憶および管理する処理モジュールである。問い合わせ表の更新契機は、コントローラ１０から問い合わせ表の更新通知を受信した場合に限られる。
【００７６】
続いて、図面を参照しつつ、第１の実施形態に係るシステムの動作を説明する。
【００７７】
図７は、スイッチ２０が自スイッチ宛もしくは自スイッチに割り当てられている仮想ネットワークノード宛のＳＮＭＰパケットを受信した時の問い合わせ処理のフローチャートである。
【００７８】
スイッチ２０がＳＮＭＰパケットを受信すると、初めに、宛先ＩＰアドレスが仮想ネットワークノード宛のＩＰアドレスであるかどうかを確認する（ステップＳ３０１）。自身の管理ＩＰアドレス宛であれば、スイッチ２０は、通常のＳＮＭＰ応答を実施し、処理を終える（ステップＳ３０２）。
【００７９】
宛先ＩＰアドレスが仮想ネットワークノード宛であれば、スイッチ２０は、スイッチ２０自身がもつ問い合わせ表に当該仮想ネットワークノードに対応する問い合わせ先の情報があるかどうかを確認する（ステップＳ３０３）。対応する情報がなければ、スイッチ２０は、エラーステータスにｎｏＳｕｃｈＮａｍｅ等を設定し、送信元に返却する（ステップＳ３０４）。
【００８０】
対応する情報があれば、スイッチ２０は、問い合わせ先が自ノードかどうかを確認する（ステップＳ３０５）。自ノードではない場合、スイッチ２０は、問い合わせ先へＭｉＢを要求するＳＮＭＰのパケットを送信し、代理でＭｉＢ情報を取得する（ステップＳ３０６）。問い合わせ先が自ノードであれば、スイッチ２０は、対応情報を内部取得する（Ｓステップ３０７）。ステップＳ３０３で問い合わせ先が複数あった場合、未だ問い合わせていないＭｉＢがあれば、スイッチ２０は、ステップＳ３０５の処理に戻る（ステップＳ３０８）。全ての問い合わせが完了した後、スイッチ２０は、収集したＭｉＢ情報をマージし（ステップＳ３０９）、スイッチ２０は、大元のＳＮＭＰに応答する形で返信する（ステップＳ３１０）。
【００８１】
図８は、コントローラ１０及びスイッチ２０の問い合わせ表更新処理のフローチャートである。問い合わせ表の更新契機は３つあり、仮想ネットワークノードの管理ＩＰアドレスの変更（ステップＳ４０１）、登録されている代理スイッチの変更（ステップＳ４０２）、および仮想ネットワークの構成変更（ステップＳ４０３）の操作があったときである。
【００８２】
これらの変更操作の後に、初めに、コントローラ１０が記憶している問い合わせ表のマスターデータ（原本）から対応する項目の削除を行う（ステップＳ４０４）。管理ＩＰアドレスの変更であれば、コントローラ１０は、旧管理ＩＰアドレスに関連する問い合わせ表をマスターデータから削除する。ここでは、問い合わせ表が実際に反映されている設定と矛盾することがないように、コントローラ１０は、先に削除だけを実施する。
【００８３】
マスターデータから削除後、コントローラ１０は、削除した問い合わせ表をもつスイッチ２０が存在するか否かを確認する（ステップＳ４０５）。当該スイッチ２０が存在するのであれば、コントローラ１０は、当該スイッチ２０へ問い合わせ表の削除通知を送信する（ステップＳ４０６）。その後、コントローラ１０は、各操作に関連する制御命令をスイッチへ送信し（ステップＳ４０７）、命令の成否を確認する（ステップＳ４０８）。
【００８４】
制御命令の設定に成功した場合、コントローラ１０は、マスターデータへ問い合わせ表の追加を行う（ステップＳ４０９）。契機となった変更操作が管理ＩＰアドレスの変更であれば、コントローラ１０は、新管理ＩＰアドレスに関連する問い合わせ表をマスターデータに追加する。
【００８５】
その後、コントローラ１０は、追加した問い合わせ表に関連するスイッチ２０が存在するか否かを確認し（ステップＳ４１０）、存在するのであれば、コントローラ１０は、当該スイッチ２０に対し追加通知を送信する（ステップＳ４１１）。
【００８６】
スイッチの問い合わせ表更新完了後、コントローラ１０は、各操作の成功通知を返却し（ステップＳ４１２）、処理を終了する。
【００８７】
仮にステップＳ４０８で命令の設定に失敗した場合、コントローラ１０は、ステップＳ４０４でマスターデータから削除した問い合わせ表の復元を行う（ステップＳ４１３）。マスターデータの復元に合わせて、コントローラ１０は、問い合わせ表の復元が必要なスイッチ２０が存在するか確認し（ステップＳ４１４）、存在すれば当該スイッチ２０へ追加通知を送信する（ステップＳ４１５）。コントローラ１０は、問い合わせ表の復元完了後、各操作の失敗通知を返却し（ステップＳ４１６）、処理を終了する。
【００８８】
第１の実施形態では、既存のネットワーク監視技術であるＳＮＭＰを使用して、仮想ネットワークの監視をすることができる。これにより、既存のＮＭＳ３０が持つＳＮＭＰで取得できる情報を利用した機能、例えば、ＳＮＭＰでスイッチから各インターフェイスの隣接スイッチ情報やＡＲＰ情報を取得してスイッチ間のトポロジーを検出する機能を利用できる。あるいは、各インターフェイスの統計情報を取得し、エラーパケット数の推移をグラフ化する機能なども利用することができる。
【００８９】
また、第１の実施形態では、仮想ネットワークのＳＮＭＰ監視方法として代理応答の手段を用いている。この場合、コントローラ１０に代理応答させる方法が情報の管理の観点からは簡易な方法である。しかし、コントローラ１０に全てのＳＮＭＰに対し代理応答させてしまうと、負荷が甚大なものとなってしまう。そこで本願開示では、制御下のスイッチ２０に必要な情報を与えることで、スイッチ２０が代理応答することを可能にし、負荷分散を実現している。さらに、代理応答するスイッチ自身が必要な情報を持っていることも、負荷低減の実現に寄与する。
【００９０】
ここで、負荷低減の例として、図２のｖｂｒｉｄｇｅ４０−１とｖｂｒｉｄｇｅ４０−２の全てのインターフェイスのＭｉＢを要求するＳＮＭＰパケットを受信したときの負荷を比較する。
【００９１】
コントローラ１０が全てに代理応答する場合、以下のＳＮＭＰ送受信処理が必要となる。全インターフェイス分のＳＮＭＰリクエスト受信（７回）およびレスポンス送信処理（７回）が必要となる。さらに、必要な情報をスイッチへ問い合わせるためのＳＮＭＰリクエスト送信（７回）およびレスポンス受信処理（７回）が必要となる。
【００９２】
第１の実施形態のようにスイッチ２０に代理応答させる場合、以下のＳＮＭＰ送受信処理が必要となる。スイッチ２０−１において、ｖｂｒｉｄｇｅ４０−１のインターフェイス分のＳＮＭＰリクエスト受信（３回）およびレスポンス送信処理（３回）が必要となる。また、スイッチ２０−１において、別のスイッチ２０へ問い合わせるためのＳＮＭＰリクエスト送信（１回）およびレスポンス受信処理（１回）が必要となる。スイッチ２０−２において、ｖｂｒｉｄｇｅ４０−２のインターフェイス分のＳＮＭＰリクエスト受信（４回）およびレスポンス送信処理（４回）が必要となる。また、スイッチ２０−２において、別のスイッチ２０へ問い合わせるためのＳＮＭＰリクエスト送信（３回）およびレスポンス受信処理（３回）が必要となる。
【００９３】
上記により、スイッチ２０に代理応答させた場合、問い合わせ回数が３回分低減される。これは、スイッチ２０へ直接ＳＮＭＰを代理応答させることにより、そのスイッチがもつ情報については外部への問い合わせが不要になるためである。
【００９４】
なお、第１の実施形態は、上記特許文献１〜３にて生じていた問題、不利益、不都合の解消が可能である。具体的には、特許文献１では、仮想化システムの負荷上昇が問題となるが、本願開示では、コントローラ１０等の負荷を軽減するため、代理取得、代理応答、情報保存する機器を分散配置している。特許文献２では、基点となるエッジルータの負荷が大きいという問題があるが、本願開示では、運用管理サーバと仮想ネットワークの間にエッジルータを置く必要がなく、構成上の制限がない。特許文献３では、ＳＮＭＰマネージャが物理スイッチがどの仮想ポート情報を持つのか把握している必要があるが、本願開示では、監視対象のＩＰアドレスだけで仮想ネットワークの監視を実施しており、上記のような制限はない。
【００９５】
［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。
【００９６】
第１の実施形態の問い合わせ表は、仮想インターフェイスと物理インターフェイスが１対１の対応関係になっていることを想定している。つまり、仮想インターフェイスのＭｉＢエントリーが対応するスイッチ２０のＭｉＢエントリーとも対応関係になっている前提があったため、補足情報に相対表現を使用していた。
【００９７】
しかし、ネットワーク仮想化技術においてには、一つの物理インターフェイスに対し、複数の仮想インターフェイスがマッピングされる場合がある。この場合、仮想インターフェイスに対応するＭｉＢエントリーがスイッチ側に存在しない可能性があり、図４、図５のような相対表現では必要な情報の取得が困難となる可能性がある。
【００９８】
そこで、補足情報を絶対表現で表現することにより実現する方法を第２の実施形態として説明する。第２の実施形態では、図９及び図１０のように物理ネットワークノードと仮想ネットワークノードの対応付けが行われているものとする。
【００９９】
第２の実施形態では、スイッチ２０の動作が第１の実施形態と異なる点がある。スイッチ２０は、コントローラ１０から仮想インターフェイスとのマッピングの制御命令が来た場合、当該マッピング通りに転送テーブルを変更する。さらに、当該変更に加え、スイッチ２０は、仮想インターフェイスの統計情報やＡＲＰ情報などをコントローラ１０から指定されたプライベートＭｉＢへ格納する。つまり、第２の実施形態では、取得対象となるＯＩＤを保持するスイッチ２０（問い合わせ先のスイッチ２０）から取得するＯＩＤに関する情報には、プライベートＭｉＢ（Management Information Base）が設定される。
【０１００】
例えば、スイッチ２０−２のポート１／０／２のＶＬＡＮ１００にｖｂｒｉｄｇｅ４０−１のＩＦ５をマッピングしたとする。この際、スイッチ２０−２は、コントローラ１０から指定されたプライベートＭｉＢにポート１／０／２のＶＬＡＮ１００のｉｆＩｎｄｅｘに相当する情報を設定し、その後も必要に応じてその情報の更新を行う。なお、ここではｉｆＩｎｄｅｘを例に説明しているが、限定するものではなく、ブリッジＭｉＢなど別のＭｉＢでもよい。
【０１０１】
コントローラ１０から指定されるプライベートＭｉＢに関し、代理スイッチが他のスイッチ２０から管理情報（ＭｉＢ）を取得可能とするように、問い合わせ表に当該情報を含める。例えば、図９、図１０のマッピングであれば、ｉｆＩｎｄｅｘに関する問い合わせ表は図１１のようになる。これにより、第１の実施形態と同様の問い合わせ処理にて、仮想ネットワークノード宛のＳＮＭＰリクエストに応答できるようになる。
【０１０２】
また、第２の実施形態の問い合わせ表を用いることで、コントローラ１０だけが保持しているような仮想ネットワークノードのｓｙｓＮａｍｅなどのｓｙｓｔｅｍ情報もＳＮＭＰで取得することが可能になる。
【０１０３】
例えば、ｓｙｓｔｅｍに関する情報を代表スイッチのプライベートＭｉＢに設定し、図１２のようにｓｙｓｔｅｍに関する問い合わせ表を作成する。ここでの代表スイッチは、仮想ネットワークノードのｓｙｓｔｅｍ情報を受け持つスイッチ２０のことである。本例では、コントローラ１０が保持している情報をスイッチ２０に持たせることで、ＳＮＭＰ応答をスイッチ２０までにとどめ、コントローラ１０の負荷を軽減している。
【０１０４】
但し、ｓｙｓｔｅｍ情報はコントローラ１０が管理している情報のため、更新するにはコントローラ１０からの通知が必要となる。よって、更新頻度が高い情報の場合、スイッチ２０に当該情報を管理させることで負荷が高くなってしまう可能性もある。そこで、更新頻度が多い情報であればコントローラ１０のプライベートＭｉＢに設定し、更新頻度が少ない情報であればスイッチ２０のＭｉＢに設定することで、負荷を軽減できる。
【０１０５】
以上のように、第２の実施形態では、問い合わせ先のスイッチ２０から取得する管理情報を直接指定することで、１つの物理インターフェイスに複数の仮想インターフェイスがマッピングされている場合でも仮想ノードの管理を行うことができる。
【０１０６】
［第３の実施形態］
続いて、第３の実施形態について図面を参照して詳細に説明する。
【０１０７】
第２の実施形態の方法では、スイッチ２０が仮想ネットワークノードのＭｉＢを持つ必要があるため、問い合わせ表の肥大化だけでなく、ＭｉＢ情報も肥大化する可能性がある。この問題に対し、プライベートＭｉＢとして覚えるＭｉＢ情報をコントローラ１０が管理して回避する方法を第３の実施形態として説明する。
【０１０８】
第３の実施形態の概要図を図１３に示す。第３の実施形態の物理ネットワークと仮想ネットワーク、およびマッピングについては第２の実施形態と同じである。図１３に示すシーケンス番号は、ｖｂｒｉｄｇｅ４０−１のｓｙｓｔｅｍ情報に対するＳＮＭＰリクエストが送信された場合の手順を示す。
【０１０９】
図１４は、コントローラ１０が保持している各スイッチ２０のｓｙｓｔｅｍに関する問い合わせ表マスターデータの一例を示す。図１５は、各スイッチ２０が保持しているｓｙｓｔｅｍに関する問い合わせ表の一例を示す。
【０１１０】
図１５を参照すると、図１５では、スイッチ２０−１がｖｂｒｉｄｇｅ４０−１のｓｙｓｔｅｍ情報を保持していないが、第３の実施形態ではプライベートＭｉＢのエントリーに一定時間経過することで削除される動的エントリーとする。より具体的には、代理スイッチであるスイッチ２０−１は、プライベートＭｉＢに格納された情報が所定期間参照されていない場合に、当該プライベートＭｉＢに格納された情報を削除する。当該削除動作により、スイッチ２０−１ではｖｂｒｉｄｇｅ１のｓｙｓｔｅｍ情報が削除されている。このように、第３の実施形態では、代理スイッチは、所定期間参照されていないプライベートＭｉＢに格納された情報を削除する。
【０１１１】
また、本例では、スイッチ２０でＳＮＭＰリクエストを受信した際に、プライベートＭｉＢの確認および更新処理が追加される。追加処理を図示したものが図１６のフローチャート図となる。追加処理は図７の問い合わせ処理のステップＳ３０５とステップＳ３０７の間に実施される処理である。そのため、図１６では、図７のステップＳ３０５とステップＳ３０７の間の処理を抜粋して図示している。
【０１１２】
図１６を参照し、スイッチ２０−１に対し、ｖｂｒｉｄｇｅ４０−１のｓｙｓｔｅｍ情報を要求するＳＮＭＰリクエストが送信されたときの動作を例に第３の実施形態を説明する。まず、スイッチ２０−１でＳＮＭＰリクエストを受信後、宛先を確認し、ｖｂｒｉｄｇｅ４０−１宛のものであることを確認する（ステップＳ３０１）。次の処理として、スイッチ２０−１は、問い合わせ表にて問い合わせ先情報の有無を確認する（ステップＳ３０３）。スイッチ２０−１は、問い合わせ先が自ノードであることを確認後（ステップＳ３０５）、ＭｉＢ情報を保持しているか確認する（ステップＳ７０１）。
【０１１３】
本例ではスイッチ２０−１は、ｖｂｒｉｄｇｅ４０−１のｓｙｓｔｅｍ情報のＭｉＢを保持していない状態のため、コントローラ１０へ該当ＭｉＢを要求する（ステップＳ７０２）。スイッチ２０−１は、取得した情報を自身のプライベートＭｉＢに記憶し（ステップＳ７０３）、内部取得処理を実行する（ステップＳ３０７）。他に問い合わせ先はないため（ステップＳ３０８）、スイッチ２０−１は、取得したデータを整形し（ステップＳ３０９）、ＮＭＳ３０へ返信し（ステップＳ３１０）、処理を終了する。
【０１１４】
以上のように、第３の実施形態では、各スイッチ２０におけるプライベートＭｉＢの保持及び削除をコントローラ１０が制御することで、各スイッチ２０が記憶するＭｉＢ情報を削減する。
【０１１５】
［ハードウェア構成］
ネットワークシステムを構成する各装置のハードウェア構成を説明する。
【０１１６】
図１７は、コントローラ１０のハードウェア構成の一例を示す図である。コントローラ１０は、図１７に例示する構成を備える。例えば、コントローラ１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インターフェイス１３及び通信手段であるＮＩＣ（Network Interface Card）１４等を備える。なお、図１７に示す構成は、コントローラ１０のハードウェア構成を限定する趣旨ではない。コントローラ１０には、図示しないハードウェアも含まれていてもよい。
【０１１７】
メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）等である。
【０１１８】
入出力インターフェイス１３は、図示しない入出力装置のインターフェイスとなる手段である。入出力装置には、例えば、表示装置、操作デバイス等が含まれる。表示装置は、例えば、液晶ディスプレイ等である。操作デバイスは、例えば、キーボードやマウス等である。
【０１１９】
上述のコントローラ１０の各処理モジュールは、例えば、メモリ１２に格納されたプログラムをＣＰＵ１１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段があればよい。
【０１２０】
なお、スイッチ２０やＮＭＳ３０もコントローラ１０と同一のハードウェア構成とするこができるので説明を省略する。
【０１２１】
［変形例］
上記第１乃至第３の実施形態にて説明したネットワークシステムは例示であって、システムの構成を限定する趣旨ではない。例えば、コントローラ１０から制御されない通常のスイッチがシステムに含まれても良い。
【０１２２】
また、上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態は、内容が相反しない範囲で組み合わせることができる。
【０１２３】
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、ＳＤＮを利用したネットワーク仮想化、ネットワーク監視等に好適に適用可能である。
【０１２４】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係るネットワークシステムのとおりである。
［付記２］
前記コントローラは、
前記仮想ネットワークノードの管理情報を保持するスイッチに関する情報を含む問い合わせ情報を作成すると共に、前記作成した問い合わせ情報を前記代理スイッチに通知し、
前記代理スイッチは、前記問い合わせ情報に基づき、前記要求された管理情報を取得する、好ましくは付記１に記載のネットワークシステム。
［付記３］
前記代理スイッチは、前記問い合わせ情報を参照し、
前記要求された管理情報を自装置の内部に保持している場合には、前記内部に保持している管理情報を前記管理装置に返信し、
前記要求された管理情報を他のスイッチが保持している場合には、前記要求された管理情報を前記他のスイッチから取得して前記管理装置に返信する、好ましくは付記２に記載のネットワークシステム。
［付記４］
前記代理スイッチは、
前記内部に保持している管理情報と前記他のスイッチから取得した管理情報を統合し、前記統合された管理情報を前記管理装置に返信する、好ましくは付記３に記載のネットワークシステム。
［付記５］
前記管理装置は、ＳＮＭＰ（Simple Network Management Protocol）を用いて前記仮想ネットワークノードの管理情報を取得し、
前記問い合わせ情報には、
取得対象となる前記仮想ネットワークノードのオブジェクト識別子と、前記取得対象となるオブジェクト識別子を保持するスイッチのアドレスと、前記取得対象となるオブジェクト識別子を保持するスイッチから取得するオブジェクト識別子に関する情報と、が含まれる、好ましくは付記２乃至４のいずれか一に記載のネットワークシステム。
［付記６］
前記取得対象となるオブジェクト識別子を保持するスイッチから取得するオブジェクト識別子に関する情報は、プライベートＭｉＢ（Management Information Base）である、好ましくは付記５に記載のネットワークシステム。
［付記７］
前記代理スイッチは、前記プライベートＭｉＢに格納された情報を所定期間参照されない場合に、前記所定期間参照されないプライベートＭｉＢに格納された情報を削除する、好ましくは付記６に記載のネットワークシステム。
［付記８］
前記取得対象となるオブジェクト識別子を保持するスイッチから取得するオブジェクト識別子に関する情報は、前記取得対象となる前記仮想ネットワークノードのオブジェクト識別子に対する差分値である、好ましくは付記５に記載のネットワークシステム。
［付記９］
前記代理スイッチは、
前記仮想ネットワークノードに対するＡＲＰ（Address Resolution Protocol）リクエストに応答する、好ましくは付記１乃至８のいずれか一に記載のネットワークシステム。
［付記１０］
上述の第２の視点に係るコントローラのとおりである。
［付記１１］
上述の第３の視点に係る仮想ネットワーク監視方法のとおりである。
［付記１２］
上述の第４の視点に係るプログラムのとおりである。
なお、付記１０〜付記１２の形態は、付記１の形態と同様に、付記２の形態〜付記９の形態に展開することが可能である。
【０１２５】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０１２６】
１０、１０２  コントローラ
１１  ＣＰＵ
１２  メモリ
１３  入出力インターフェイス
１４  ＮＩＣ
２０、２０−１〜２０−３、１０１  スイッチ
３０  ＮＭＳ
４０、４０−１、４０−２  ｖｂｒｉｄｇｅ
５０  ｖｒｏｕｔｅｒ
１０３  管理装置
２０１  仮想ネットワーク管理部
２０２  スイッチ制御部
２０３  問い合わせ表管理部
２１１  転送制御部
２１２  問い合わせ部
２１３  問い合わせ表記憶部
【図１】
2019186822.tif 000003
【図２】
2019186822.tif 000004
【図３】
2019186822.tif 000005
【図４】
2019186822.tif 000006
【図５】
2019186822.tif 000007
【図６】
2019186822.tif 000008
【図７】
2019186822.tif 000009
【図８】
2019186822.tif 000010
【図９】
2019186822.tif 000011
【図１０】
2019186822.tif 000012
【図１１】
2019186822.tif 000013
【図１２】
2019186822.tif 000014
【図１３】
2019186822.tif 000015
【図１４】
2019186822.tif 000016
【図１５】
2019186822.tif 000017
【図１６】
2019186822.tif 000018
【図１７】
2019186822.tif 000019