(57)【要約】【課題】ＭＡＮＯによって管理される仮想ネットワーク仮想環境において、既存のＤＮＳのドメイン名とＩＰアドレスの割当てを最適化することにより、ＶＮＦの負荷を分散する。【解決手段】ＭＡＮＯは、ＶＮＦに割当てられたハードウェア資源の負荷情報と、各々の仮想ネットワーク機能部の選択優先度を保持するＶＮＦ情報テーブルを有している。ＭＡＮＯは、ＶＮＦに割当てられたハードウェア資源を実現する仮想プラットフォームに、ＶＮＦに割当てられたハードウェア資源の負荷情報を問合せ、ＶＮＦに割当てられたハードウェア資源の負荷情報に基づき、ハードウェア資源の負荷が少ないＶＮＦの選択優先度を上げるようにＶＮＦの選択優先度を設定する。【選択図】  図２
2017143477.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェア資源が割当てられネットワーク機能をソフトウェアを実行することにより実現する一つ以上の仮想ネットワーク機能部と、
ハードウェア資源とソフトウェア資源を調停し、前記仮想ネットワーク機能部を管理する仮想ネットワーク管理部とを有する仮想ネットワークシステムであって、
前記仮想ネットワーク管理部は、
前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報と、各々の仮想ネットワーク機能部の選択優先度を保持する仮想ネットワーク機能部情報テーブルを有し、
前記仮想ネットワーク管理部は、前記仮想ネットワーク機能部に割当てられたハードウェア資源を実現するプラットフォームに、前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報を問合せ、
前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報に基づき、ハードウェア資源の負荷が少ない仮想ネットワーク機能部の選択優先度を上げるように前記仮想ネットワーク機能部の選択優先度を設定することを特徴とする仮想ネットワークシステム。
【請求項２】
さらに、ＤＮＳサーバを有し、
前記仮想ネットワーク管理部は、前記仮想ネットワーク機能部に対して、ＤＮＳ正引きにおいて前記選択優先度が低い前記仮想ネットワーク機能部が選ばれないようにＤＮＳリソースレコードを更新するＤＮＳリソースレコード更新通知を発行し
前記仮想ネットワーク機能部は、前記ＤＮＳサーバにそのＤＮＳリソースレコード更新通知を転送することを特徴とする請求項１記載の仮想ネットワークシステム。
【請求項３】
さらに、ＤＮＳサーバを有し、
前記仮想ネットワーク管理部は、前記ＤＮＳサーバに対して、ＤＮＳ正引きにおいて前記選択優先度が低い前記仮想ネットワーク機能部が選ばれないようにＤＮＳリソースレコードを更新するＤＮＳリソースレコード更新通知を発行することを特徴とする請求項１記載の仮想ネットワークシステム。
【請求項４】
前記仮想ネットワーク管理部は、ＤＮＳリソースレコードに基づきＤＮＳ正引きを行ない、前記ＤＮＳリソースレコードを更新する機能を有するＤＮＳ機能部を有し、ＤＮＳ正引きにおいて前記選択優先度が低い前記仮想ネットワーク機能部が選ばれないようにＤＮＳリソースレコードを更新することを特徴とする請求項１記載の仮想ネットワークシステム。
【請求項５】
前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報は、ハードウェア資源のＣＰＵ使用率、メモリ使用率、収容セッション数、通信遅延時間のいずれか又はそれらの組合せであることを特徴とする請求項１記載の仮想ネットワークシステム。
【請求項６】
ハードウェア資源が割当てられネットワーク機能をソフトウェアを実行することにより実現する一つ以上の仮想ネットワーク機能部と、
ハードウェア資源とソフトウェア資源を調停し、前記仮想ネットワーク機能部を管理する仮想ネットワーク管理部とを有する仮想ネットワークシステムのネットワーク負荷分散方法であって、
前記仮想ネットワーク管理部は、
前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報と、各々の仮想ネットワーク機能部の選択優先度を保持する仮想ネットワーク機能部情報テーブルを有し、
前記仮想ネットワーク管理部は、前記仮想ネットワーク機能部に割当てられたハードウェア資源を実現するプラットフォームに、前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報を問合せるステップと、
前記仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報に基づき、ハードウェア資源の負荷が少ない仮想ネットワーク機能部の選択優先度を上げるように前記仮想ネットワーク機能部の選択優先度を設定するステップと、
前記仮想ネットワーク管理部は、前記仮想ネットワーク機能部に対して、ＤＮＳ正引きにおいて前記選択優先度が低い前記仮想ネットワーク機能部が選ばれないようにＤＮＳリソースレコードを更新するＤＮＳリソースレコード更新通知を発行するステップと、
前記仮想ネットワーク機能部は、ＤＮＳサーバにそのＤＮＳリソースレコード更新通知を転送するステップとを有することを特徴とするネットワーク負荷分散方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想ネットワークシステム、及び、ネットワーク負荷分散方法に係り、特に、仮想ネットワーク環境において、ＩＰアドレスを割当てるＤＮＳ機能を利用しているときに、複数の仮想ネットワークコンポーネントの負荷を分散させるのに好適な仮想ネットワークシステム、及び、ネットワーク負荷分散方法に関する。
【背景技術】
【０００２】
ＤＮＳ（Domain Name System）は、ＩＰプロトコルを前提とするインターネットの名前解決手段として広く用いられており、移動通信用のＬＴＥ（Long Term Evolution）（登録商標）ネットワークにおいても、各ＥＰＣ（Evolved Packet Core）ノードのアドレス設定がＤＮＳサーバに登録されている。ここで、ＥＰＣノードとは、多様な無線アクセスを収容できるようにしたネットワークアーキテクチャにおけるネットワークノードである。ＥＰＣノードは、他ＥＰＣノードへ接続する際、ＤＮＳに問合せをし、ＤＮＳの応答に含まれているアドレスを有するＥＰＣノードへ接続する。ＤＮＳは、登録時に設定したＤＮＳリソースレコードの優先度にしたがって各ＥＰＣノード（ＭＭＥ／Ｓ−ＧＷ／Ｐ−ＧＷ／ＳＧＳＮ）を選択している。
【０００３】
しかしながら、ネットワークへの集中アクセスなどにより障害が発生した場合、ＬＴＥネットワーク内の各ＥＰＣノードに負荷の偏りが生じる。上記ＤＮＳの動作では、ＥＰＣネットワーク内の各ＥＰＣノードの負荷バランスを考慮した選択を行うことができず、ＤＮＳ初期登録時のＤＮＳリソースレコードの優先度にしたがって各ＥＰＣノードを選択してしまうため、過負荷状態のＥＰＣノードを選択してしまう可能性がある。その場合、当該ＥＰＣノードの負荷がさらに上昇し、通信障害が発生する可能性がある。
【０００４】
このような環境において、ネットワーク負荷分散に関する技術として、特許文献１がある。特許文献１には、ＥＰＣネットワークにおいて、使用するＥＰＣノードを、ＤＮＳサーバに設定登録されているＤＮＳレコード内の選択優先度に基づいてＤＮＳサーバで選択することによって、各ＥＰＣノード負荷を分散させることが開示されており、「動的にＤＮＳリソースレコードを更新することが可能なＤＤＮＳ（Ｄｙｎａｍｉｃ  ＤＮＳ）サーバ機能をＤＮＳサーバに備えるとともに、ＤＮＳサーバに自ＥＰＣノードのＤＮＳリソースレコードとして登録されているＮＡＰＴＲレコードやＳＲＶレコードをＥＰＣノード名（つまりＥＰＣノードのＩＰアドレスに対応付けられたＥＰＣノード名）から特定することが可能な補充ＮＡＰＴＲレコードを新たに追加することによって、過負荷状態に陥ったＥＰＣノードからの更新要求に応じて、当該ＥＰＣノードのＤＮＳリソースレコードを特定することを可能にし、当該ＥＰＣノードの選択の優先度を低下させる状態に更新し、他のＥＰＣノードを選択し易くすることを特徴とする」（段落番号００３３）という記載がある。
【０００５】
一方、近年、これまではハードウェアで機器で提供されていたネットワークの機能を仮想化環境（ソフトウェア）で実現するＮＦＶ（Network Functions Virtualization、ネットワーク仮想化）技術が注目されている。ネットワーク仮想化に関して、標準化団体であるＥＴＳＩ（European Telecommunications Standards Institute）の提唱するＮＦＶのアーキテクチャによれば、ＬＴＥネットワークのＥＰＣノードは、ネットワーク機能を実現するためのソフトウエアパッケージであるＶＮＦ（Virtualized network function）コンポーネント上で稼動することになる。そして、このアーキテクチャにおいては、ネットワークでの仮想化環境を管理するＭＡＮＯ（Management and orchestration）コンポーネントを有しており、必要に応じてＶＮＦ数を増減させる、又はＶＮＦの処理性能を変化させることができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第１２／１７２７２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１の技術は、各ＥＰＣノードが予め設定された閾値を用いて自ノードの負荷状態を判断する。しかし、上述の仮想環境では、ＭＡＮＯによりＶＮＦの処理性能を変更することができるため、特許文献１の技術による閾値の算出が困難となる。さらに、ＭＡＮＯがＶＮＦの数を増加させる場合、新しいＶＮＦのＤＮＳリソースレコードはＤＮＳに登録されず、他ＶＮＦは当該ＶＮＦを選択することができない。また、ＶＮＦを減少させる場合、ＶＮＦはＤＮＳから削除されず、他ＶＮＦは当該ＶＮＦを選択してしまうことがある。上記により、ＭＡＮＯによって管理される仮想環境では、従来のＤＮＳ技術では、ＶＮＦの負荷を分散することができないという問題がある。そして、過負荷状態のＶＮＦを選択してサービスを提供する場合、当該ＶＮＦの負荷がさらに上昇し、通信障害が発生する可能性がある。
【０００８】
本発明は、上記問題点を解決するためになされたもので、その目的は、ＭＡＮＯによって管理される仮想ネットワーク仮想環境において、既存のＤＮＳのドメイン名とＩＰアドレスの割当てを最適化することにより、ＶＮＦの負荷を分散することができるネットワーク負荷分散方法を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するための仮想ネットワークシステムの構成は、ハードウェア資源が割当てられネットワーク機能をソフトウェアを実行することにより実現する一つ以上の仮想ネットワーク機能部と、ハードウェア資源とソフトウェア資源を調停し、仮想ネットワーク機能部を管理する仮想ネットワーク管理部とを有するものである。そして、仮想ネットワーク管理部は、仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報と、各々の仮想ネットワーク機能部の選択優先度を保持する仮想ネットワーク機能部情報テーブルを有している。仮想ネットワーク管理部は、仮想ネットワーク機能部に割当てられたハードウェア資源を実現するプラットフォームに、仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報を問合せ、仮想ネットワーク機能部に割当てられたハードウェア資源の負荷情報に基づき、ハードウェア資源の負荷が少ない仮想ネットワーク機能部の選択優先度を上げるように仮想ネットワーク機能部の選択優先度を設定する。
【発明の効果】
【００１０】
本発明によれば、ＭＡＮＯによって管理される仮想ネットワーク仮想環境において、既存のＤＮＳのドメイン名とＩＰアドレスの割当てを最適化することにより、ＶＮＦの負荷を分散することができるネットワーク負荷分散方法を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】一般的な仮想ネットワークシステムの構成を示す図である。
【図２】第一の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。
【図３】ＶＮＦ情報テーブルの一例を示す図である。
【図４】ＤＮＳリソースレコードの一例を示す図である。
【図５】第一の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。
【図６】第一の実施形態に係るネットワーク負荷分散方法のＶＮＦがＤＮＳ正引き要求を行なったときの処理を示すシーケンス図である。
【図７Ａ】ＶＮＦ情報テーブルの変更の例を示す図である（レコード追加）。
【図７Ｂ】ＶＮＦ情報テーブルの変更の例を示す図である（フィールド更新）。
【図７Ｃ】ＶＮＦ情報テーブルの変更の例を示す図である（レコード削除）。
【図８】ＤＮＳリソースレコードの変更の例を示す図である。
【図９】第二の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。
【図１０】第二の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。
【図１１】第三の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。
【図１２】第三の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。
【図１３】第三の実施形態に係るネットワーク負荷分散方法のＶＮＦがＤＮＳ正引き要求を行なったときの処理を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、本発明に係る各実施形態を、図１ないし図１３を用いて説明する。
【００１３】
〔実施形態１〕
以下、本発明に係る第一の実施形態を、図１ないし図８を用いて説明する。
【００１４】
先ず、図１を用いて一般的な仮想ネットワークシステムの構成について説明する。  
図１は、一般的な仮想ネットワークシステムの構成を示す図である。
【００１５】
本実施形態の仮想ネットワークシステムのアーキテクチャは、ＥＴＳＩの提唱するＯＰＮＦＶに基づいて説明する。
【００１６】
ＶＮＦ１２は、ネットワーク機能をソフトウェアで実行するコンポーネントである。ＭＡＮＯ１１は、システムにおけるハードウェアリソース（資源）と、ソフトウェアリソースを管理し、両者の間を調停するコンポーネントである。
【００１７】
仮想プラットフォーム２０は、ＣＰＵ（Central Processing Unit）３１、ストレージ３２、ネットワーク３３などのハードウェアリソースを有する物理サーバ３０を仮想化したものであり、両者の間には、物理レイヤ２５が設定されている。
【００１８】
ＶＮＦ１２は、仮想プラットフォーム２０を介して、現実の物理サーバ３０のリソースを利用するようになっており、ＶＮＦ１２、仮想プラットフォーム２０は、共に、ＭＡＮＯ１１のＡＰＩにより、指示と制御を受ける。
【００１９】
ＭＡＮＯ１１は、オーケストレーター（Orchestrator）１１０、ＶＮＦマネージャ１２０、仮想インフラマネージャ１３０のサブコンポーネントよりなる。ＶＮＦマネージャ１２０は、仮想ネットワークシステムのＶＮＦ１２を管理し、仮想インフラマネージャ１３０は、仮想プラットフォーム２０と物理サーバ３０を管理し、両者の間を取り持つコンポーネントである。オーケストレーター１１０は、ＶＮＦマネージャ１２０と仮想インフラマネージャ１３０を調停するＭＡＮＯ１１の中心的なコンポーネントである。
【００２０】
次に、図２を用いて第一の実施形態に係る仮想ネットワークの動作と構成とデータフローについて説明する。  
図２は、第一の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。
【００２１】
ＭＡＮＯ１１は、通信網を介して各ＶＮＦ１２を管理している。ＭＡＮＯ１１は、機能を実現するサブユニットとしてＶＮＦ管理機能部１１１、ＶＮＦ負荷分散部１１３、データとしてＶＮＦ情報テーブル１１２を有する。
【００２２】
ＶＮＦ管理機能部１１１は、ＶＮＦ情報テーブル１１２を更新し、ＶＮＦ負荷分散部１１３のＶＮＦの選択優先度の変更の指示を与えるユニットである。ＶＮＦ管理機能部１１１は、一定時間ごとに、仮想プラットフォーム２０に負荷情報要求Ｓ１０１を発行し、負荷情報通知Ｓ１０２を受取る。そして、負荷情報通知に含まれるＣＰＵ使用率をＶＮＦ情報テーブル１１２に格納する。ＶＮＦ情報テーブル１１２は、各ＶＮＦ１２を管理するテーブルであり、後に詳説する。そして、一定時間ごとに、ＶＮＦ負荷分散部１１３にＶＮＦ選択優先度更新通知を送信する。
【００２３】
ＶＮＦ負荷分散部１１３は、ＶＮＦ情報テーブル１１２の情報に基づいて各ＶＮＦの選択優先度を算出し、選択優先度をＶＮＦ情報テーブル１１２に保存する。ここで、選択優先度とは、ＤＮＳによりＩＰアドレスが割当てられるときのＤＮＳのリソースレコードにおける優先度を決定するために用いられる優先度である。
【００２４】
そして、ＭＡＮＯ１１は、ＶＮＦ１２に対してＤＮＳレコード更新要求Ｓ２０１を行う。各ＶＮＦ１２は、このＤＮＳレコード更新要求Ｓ２０１を受けて、ＤＤＮＳクライアント機能部１２１を用いて、ＤＮＳサーバ１３に対してＤＮＳリソースレコードの更新要求Ｓ２０２を行う。
【００２５】
ＤＮＳサーバ１３には、各ＶＮＦのＤＮＳリソースレコード１３３が登録されており、各ＶＮＦのＤＮＳリソースレコードの優先度にしたがって各ＶＮＦを選択する機能を有する。また、ＤＮＳサーバ１３は、ＤＮＳリソースレコード１３３を動的に更新するＤＤＮＳ機能部１３２を備えている。
【００２６】
そして、ＶＮＦ１２からＤＮＳリソースレコードの更新要求を受け取った際に、その更新要求に対応して該当するＤＮＳリソースレコードを動的に更新する。
【００２７】
この状態で、ＶＮＦ０（１２）からＶＮＦ１，２，３…（１２）にアクセスする場合を考える。ＶＮＦ０（１２）は、ＤＮＳクライアント機能１２２を用いてＤＮＳサーバ１３にドメインネームをパラメタとしてＤＮＳ正引き要求Ｓ３０１を行う。
【００２８】
ＤＮＳサーバ１３は、ＤＮＳ正引き部１３１により、ＤＮＳリソースレコード１３３を参照し、設定された優先度を考慮して、パラメタとして指定されたドメインネームに対応するＩＰアドレスを返答Ｓ３０２する。
【００２９】
ＶＮＦ０（１２）は、受取ったＩＰアドレスにより、ＶＮＦ１，２，３…（１２）のいずれかにアクセスする。したがって、この仕組みにより、ＶＮＦ１，２，３…（１２）は、負荷が少ない場合に、ＤＮＳリソースレコード内において、優先度の高い割当てを受けられるので、ＶＮＦ０（１２）は、負荷の少ないＶＮＦにアクセスすることになる。この結果、ネットワークシステム内での負荷が分散される。
【００３０】
次に、図３及び図４を用いて第一の実施形態に係るネットワーク負荷分散方法に用いられるデータ構造について説明する。  
図３は、ＶＮＦ情報テーブルの一例を示す図である。  
図４は、ＤＮＳリソースレコードの一例を示す図である。
【００３１】
ＶＮＦ情報テーブル１１２は、各ＶＮＦの情報を保持するテーブルであり、図３に示されるように、ＶＮＦ−ＩＤ３１、ＶＮＦ名３２、ＩＰアドレス３３、ＣＰＵ使用率３４、選択優先度３５のフィールドを有する。
【００３２】
ＶＮＦ−ＩＤ３１は、ＶＮＦを一意的に識別するためのＩＤを格納するフィールドである。ＶＮＦ名３２は、そのＶＮＦにつけられた名前を格納するフィールドである。ＩＰアドレス３３は、そのＶＮＦに割当てられたＩＰアドレスを格納するフィールドである。ＣＰＵ使用率３４は、そのＶＮＦを稼動させる仮想プラットフォーム２０にマッピングされている物理サーバ３０のＣＰＵ３１の使用率（フル使用を１００％とした場合の割合）である。選択優先度３５は、ＤＮＳリソースレコードの優先度の更新要求を出すときの基になる優先度であり、本実施形態では、ＶＮＦのＣＰＵ使用率が低いほど優先度が高く設定されるものとし、優先度が高いほど値が小さく設定され、最も優先度の高いＶＮＦの優先度が１に設定されるものとす。
【００３３】
ＤＮＳリソースレコード１３３は、ＤＮＳサーバ１３において、ＤＮＳとＩＰの対応やそれに付随する様々な制御情報を格納するためのレコードである。
【００３４】
本実施形態では、実際のＤＮＳリソースレコードを簡略したモデルを説明することとする。
【００３５】
本実施形態のＤＮＳリソースレコード１３３は、図４に示されるように、ドメイン名１３３１、ＩＰアドレス１３３２、優先度１３３４の各フィールドからなる。ドメイン名１３３１、ＩＰアドレス１３３２は、それぞれドメイン名１３３１とＩＰアドレス１３３２が対応することを示している。この例では、同じドメイン名「ｄｏｍａｉｎＡ」に対して、異なったＩＰアドレス「ＩＰａ，ＩＰｂ，…」が対応しているものとしている。優先度１３３４は、ドメイン正引き要求があって、同じドメイン名があったときに、どのレコードにＩＰアドレスを返すかに関する優先度であり、優先度が高いものからそのＩＰアドレスを返すことを意味する。この例では、Ａの場合が一番優先度が高いものとし、Ｂ、Ｃ…と続くものとする。
【００３６】
次に、図５ないし図８を用いて第一の実施形態に係るネットワーク負荷分散方法の処理について説明する。  
図５は、第一の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。  
図６は、第一の実施形態に係るネットワーク負荷分散方法のＶＮＦがＤＮＳ正引き要求を行なったときの処理を示すシーケンス図である。  
図７Ａ〜図７Ｃは、ＶＮＦ情報テーブルの変更の例を示す図である。  
図８は、ＤＮＳリソースレコードの変更の例を示す図である。
【００３７】
先ず、ＭＡＮＯ１２のＶＮＦ管理機能部１１１は、仮想プラットフォーム２０に対して、一定時間ごとに、負荷情報要求を発行し（Ｓ１０１）、負荷情報通知を受取る（Ｓ１０２）。
【００３８】
次に、負荷情報通知に基づき、図３に示したＶＮＦ情報テーブル１１２のＣＰＵ使用率３４を変更する（Ｓ１）。また、その他のＶＮＦの情報変更、ＶＮＦの追加、又はＶＮＦの削除が実施された場合、ＶＮＦ情報テーブル１１２に対してＶＮＦ情報の更新を行う（Ｓ１）。
【００３９】
そして、ＶＮＦ機能管理部１１１は、ＶＮＦ情報テーブル１１２の更新後に、ＶＮＦ負荷分散部１１３に、ＶＮＦ選択優先度更新通知を行う（Ｓ２）。
【００４０】
そして、ＶＮＦ負荷分散部１１３が、すべてのＶＮＦ１２に対し、選択優先度３５を再計算して、それに基づいてＣＰＵ使用率３４の多いものの選択優先度を下げるように設定を行う。
【００４１】
例えば、図７Ａ（ａ）のＶＮＦ情報テーブル１１２を保持している場合に、「ＶＮＦ３」の名称のＶＮＦが追加される場合、ＶＮＦ機能管理部１１１により、ＶＮＦのＶＮＦ−ＩＤ３１、ＶＮＦ名３２、ＩＰアドレス３３、ＣＰＵ使用率３４がそれぞれ設定される。このときに、図７Ａ（ａ）のように「ＶＮＦ１」名称のＶＮＦ（レコード３０１）が、ＣＰＵ使用率「６０％」、選択優先度「２」、「ＶＮＦ２」名称のＶＮＦ（レコード３０２）が、ＣＰＵ使用率「５０％」、選択優先度「１」であり、追加する「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）がＣＰＵ使用率「４０％」のときには、図７Ａ（ｂ）に示されるように、「ＶＮＦ３」の名称のＶＮＦの選択優先度を一番高くなるように、選択優先度「１」とし、「ＶＮＦ１」名称のＶＮＦの選択優先度「３」に下げ、「ＶＮＦ２」の名称のＶＮＦの選択優先度「２」に下げるように、ＶＮＦ負荷分散部１１３が設定する。
【００４２】
次に、ＶＮＦ情報テーブル１１２に対してＶＮＦ選択優先度の更新が実行された（Ｓ３）後、ＶＮＦ負荷分散部１１３がすべてのＶＮＦに対し、ＤＮＳリソースレコードの更新要求を行う（Ｓ２０１）。そして、ＤＮＳリソースレコードの更新要求を受信したＶＮＦ１２のＤＤＮＳクライアント機能部１２１は、ＤＮＳサーバ１３に対してＤＮＳリソースレコードの更新要求を行う（Ｓ２０２）。
図７Ａの場合のように、ＶＮＦ情報テーブル１１１が更新された場合、ＤＮＳリソースレコードの更新要求（Ｓ２０１、Ｓ２０２）の内容は、「ＶＮＦ１」の名称のＶＮＦ（レコード３０１）の選択優先度の更新、「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）の選択優先度の更新、及び「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）のレコードの追加である。ＤＮＳサーバ１３は、前記ＤＮＳリソースレコードの更新要求を受け取った際に、該更新要求に対応して、図８に示されるように、ＤＮＳリソースレコード１３３の更新を行う。すなわち、図８（ａ）のＤＮＳリソースレコード１３３のレコード４０１が、「ＶＮＦ１」の名称のＶＮＦ（レコード３０１）、ＤＮＳリソースレコード１３３のレコード４０２が、「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）に対応し、追加した「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）を追加したことにより、図８（ｂ）のＤＮＳリソースレコード１３３のレコード４０３が追加される。
【００４３】
そして、ＤＮＳリソースレコード１３３のレコード４０３の優先度が「Ａ」、レコード４０２の優先度が「Ｂ」、レコード４０３の優先度が「Ｃ」になるようにそれぞれ設定される。図８の例では、優先度は分かりやすく模式的に示したが、実際には、ＤＮＳリソースレコードのＮＡＰＴＲレコード、又はＳＲＶレコードを更新する（特許文献１の段落番号００５８〜段落００６０などを参照）。
【００４４】
また、図７Ｂ及び図７Ｃを用いてＶＮＦ情報テーブルを変更する別の例を説明する。
図７Ｂ（ａ）の「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）及び「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）のそれぞれのＩＰアドレス３３、ＣＰＵ使用率３４が、図７Ｂ（ｂ）に示されるように変更されたとする。このときには、選択優先度３４の欄は、ＣＰＵ使用率３４が低いものほど大きくなるように、「ＶＮＦ１」の名称のＶＮＦ（レコード３０２）の選択優先度「１」、「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）の選択優先度「３」、「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）の選択優先度「２」となるように変更される。
図７Ｂの場合のように、ＶＮＦ情報テーブル１１１が更新された場合、ＤＮＳリソースレコードの更新要求（Ｓ２０１、Ｓ２０２）の内容は、「ＶＮＦ１」の名称のＶＮＦ（レコード３０１）の選択優先度の更新、「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）の選択優先度の更新、及び「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）のＩＰアドレス更新、「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）のＩＰアドレス更新である。
【００４５】
ＤＮＳサーバは、この要求を受けて対応するＤＮＳリソースレコード１３３の内容を更新する。
【００４６】
また、図７Ｃ（ａ）に示される「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）が削除されたとする。このときには、「ＶＮＦ１」の名称のＶＮＦ（レコード３０２）の選択優先度「２」、「ＶＮＦ２」の名称のＶＮＦ（レコード３０２）の選択優先度「１」となるように変更される。
図７Ｃの場合のように、ＶＮＦ情報テーブル１１１が更新された場合、ＤＮＳリソースレコードの更新要求（Ｓ２０１、Ｓ２０２）の内容は、「ＶＮＦ１」の名称のＶＮＦ（レコード３０１）の選択優先度の更新、「ＶＮＦ３」の名称のＶＮＦ（レコード３０３）の削除である。
【００４７】
ＤＮＳサーバは、この要求を受けて対応するＤＮＳリソースレコード１３３の内容を更新する。
【００４８】
ＤＮＳリソースレコード１３３を更新した後、図６に示されるように、アクセス元のＶＮＦ０（１２）は、ＤＮＳサーバ１３に対して、ＤＮＳ正引き要求をおこなう（Ｓ３０１）。
【００４９】
ＤＮＳサーバ１３は、ＤＮＳリソースレコード１３３の優先度にしたがって、ＶＮＦ０（１２）のＩＰアドレスを返答する（Ｓ３０２）
そして、アクセス元のＶＮＦ０（１２）は、そのＩＰアドレスにより、対応するＶＮＦ１，２，３…（１２）をアクセスする（Ｓ３０３）。
【００５０】
上記処理によって、ＤＮＳがＣＰＵ使用率の低いＶＮＦを優先して選択したため、仮想環境のネットワーク全体の負荷が分散される。
【００５１】
以上のように、本実施形態によれば、ＭＡＮＯによって管理される仮想環境において、ＶＮＦの負荷に応じて、ＶＮＦのＤＮＳリソースレコードを動的に更新し、負荷の高いＶＮＦの接続優先度を下げ、負荷の低いＶＮＦの接続優先度を上げることにより、ネットワーク全体の負荷を分散することができる。
【００５２】
〔実施形態２〕
以下、本発明に係る第二の実施形態を、図９及び図１０を用いて説明する。  
図９は、第二の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。
図１０は、第二の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。
【００５３】
第一の実施形態では、ＤＤＮＳクライアント機能部がＶＮＦ１２に設けられていたが、本実施形態では、ＭＡＮＯ１１にＤＤＮＳクライアント機能部が設けられた構成を有する。
【００５４】
以下、第一の実施形態と比較して異なった所を中心に説明する。
【００５５】
ＭＡＮＯ１１は、機能を実現するサブユニットとしてＶＮＦ管理機能部１１１、ＶＮＦ負荷分散部１１３、データとしてＶＮＦ情報テーブル１１２に加えて、さらに、機能を実現するサブユニットとしてＤＤＮＳクライアント機能部１１４を有している。
【００５６】
ＤＤＮＳクライアント機能部１１４のＤＮＳリソースレコードの更新をＤＮＳサーバ１３に要求する機能は、第一の実施形態と同様である。
【００５７】
システムの動作としては、図１０に示されるように、ＶＮＦ負荷分散部１１３がＭＡＮＯ１１内部のＤＤＮＳクライアント機能部１１４に対してＤＮＳリソースレコード更新要求Ｓ４をすることが異なっている。
【００５８】
この要求を受けて、ＤＤＮＳクライアント機能部１１４は、ＤＮＳサーバ１３に対してＤＮＳリソースレコード更新要求Ｓ４０１を行う。
【００５９】
ＶＮＦがＤＮＳ正引き要求を行う場合の処理は、第一の実施形態の図６のシーケンス図と同様である。
【００６０】
本実施形態は、各々のＶＮＦ１２がＤＤＮＳクライアント機能部を持たなくてもよいという利点がある。
【００６１】
〔実施形態３〕
以下、本発明に係る第三の実施形態を、図１１ないし図１３を用いて説明する。  
図１１は、第三の実施形態に係る仮想ネットワークシステムにおける各コンポーネント間における構成とデータフローを示す図である。  
図１２は、第三の実施形態に係るネットワーク負荷分散方法のＤＮＳ更新リソース更新までの処理を示すシーケンス図である。  
図１３は、第三の実施形態に係るネットワーク負荷分散方法のＶＮＦがＤＮＳ正引き要求を行なったときの処理を示すシーケンス図である。
【００６２】
第一の実施形態では、ＤＮＳの機能を提供するＤＮＳサーバ１３が外部のサーバとして設けられていた。本実施形態では、ＤＮＳの機能を提供するＤＮＳ機能部がＭＡＮＯの内部に設けられたものである。
【００６３】
以下、第一の実施形態及び第二の実施形態と比較して異なって所を中心に説明する。
【００６４】
ＭＡＮＯ１１は、機能を実現するサブユニットとしてＶＮＦ管理機能部１１１、ＶＮＦ負荷分散部１１３、データとしてＶＮＦ情報テーブル１１２に加えて、さらに、機能を実現するサブユニットとしてＤＮＳ機能部１３０を有している。
【００６５】
ＤＮＳ機能部１３０は、さらに、ＤＮＳ正引き部１３１、ＤＤＮＳ機能部１３２、ＤＮＳリソースレコード１３３を備えている。各々の機能とデータの内容は、第一の実施形態と同様である。
【００６６】
本実施形態のＤＮＳリソースレコード更新要求は、図１２に示されるように、ＶＮＦ負荷分散部１１３から同じＭＡＮＯ１１にあるＤＮＳ機能部１３０に対してなされる（Ｓ５）。
【００６７】
これを受けて、ＤＮＳ機能部１３０のＤＤＮＳ機能部１３２は、ＤＮＳリソースレコード１３３の内容を更新する。
【００６８】
また、ＶＮＦがＤＮＳ正引き要求を行う場合の処理は、ＤＮＳリソースレコード１３３を更新した後、図１３に示されるように、アクセス元のＶＮＦ０（１２）は、ＭＡＮＯ１１に対して、ＤＮＳ正引き要求をおこなう（Ｓ６０１）。
【００６９】
ＭＡＮＯ１１のＤＮＳ機能部１３０内のＤＮＳ正引き部１３１は、ＤＮＳリソースレコード１３３の優先度にしたがって、ＶＮＦ０（１２）のＩＰアドレスを返答する（Ｓ６０２）
そして、アクセス元のＶＮＦ０（１２）は、そのＩＰアドレスにより、対応するＶＮＦ１，２，３…（１２）をアクセスする（Ｓ６０３）。
【００７０】
本実施形態では、ＭＡＮＯ１１がＤＮＳ機能をかねるため、外部にＤＮＳサーバを用意しなくてもよいという利点がある。また、各々のＶＮＦ１２に対してＤＮＳリソースレコード１３３を更新するためのＤＤＮＳ機能部を用意しなくてもよいという利点もある。
【００７１】
〔その他の実施形態〕
上記の実施形態のネットワーク負荷分散方法によれば、ＣＰＵ使用率を利用しＶＮＦの選択優先度を計算するが、メモリ使用率、収容セッション数、通信遅延時間など、又は上記の組み合わせにより選択優先度を計算することが可能であり、必ずしもＣＰＵ使用率に限定されるものではない。
【００７２】
また、「ＶＮＦ情報テーブル」の表現にてＶＮＦに関する情報を説明したが、ＶＮＦに関する情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＶＮＦ情報テーブル」を「ＶＮＦ情報」と呼ぶことができる。
【符号の説明】
【００７３】
１１…ＭＡＮＯ装置
１２…ＶＮＦ装置
１３…ＤＮＳサーバ
１１１…ＶＮＦ管理機能部
１１２…ＶＮＦ情報テーブル
１１３…ＶＮＦ負荷分散部
１１４…ＤＤＮＳクライアント機能部（ＭＡＮＯ）
１２１…ＤＤＮＳクライアント機能部（ＶＮＦ）
１３０…ＤＮＳ機能部
【図１】
2017143477.tif 000003
【図２】
2017143477.tif 000004
【図３】
2017143477.tif 000005
【図４】
2017143477.tif 000006
【図５】
2017143477.tif 000007
【図６】
2017143477.tif 000008
【図７Ａ】
2017143477.tif 000009
【図７Ｂ】
2017143477.tif 000010
【図７Ｃ】
2017143477.tif 000011
【図８】
2017143477.tif 000012
【図９】
2017143477.tif 000013
【図１０】
2017143477.tif 000014
【図１１】
2017143477.tif 000015
【図１２】
2017143477.tif 000016
【図１３】
2017143477.tif 000017