(57)【要約】【課題】サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計すること。【解決手段】サービスチェイン設計装置１は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ判定部１３が判定した冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する冗長化判定部３１とを有する。【選択図】図１
2019213028.tif 000002
【特許請求の範囲】
【請求項１】
ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする
サービスチェイン設計装置。
【請求項２】
前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする
請求項１に記載のサービスチェイン設計装置。
【請求項３】
前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする
請求項２に記載のサービスチェイン設計装置。
【請求項４】
前記第２判定部は、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載のサービスチェイン設計装置。
【請求項５】
前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部は、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。
【請求項６】
前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部は、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。
【請求項７】
サービスチェイン設計装置は、第１判定部と、第２判定部と、冗長度計算部とを有しており、
前記第１判定部は、ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定し、
前記第２判定部は、前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定し、
前記冗長度計算部は、前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算することを特徴とする
サービスチェイン設計方法。
【請求項８】
請求項７に記載のサービスチェイン設計方法を、コンピュータである前記サービスチェイン設計装置に実行させるためのサービスチェイン設計プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラムに関する。
【背景技術】
【０００２】
システムに障害が発生するまえに予備の計算機をあらかじめ用意しておき、障害発生時には予備の計算機に処理を切り替える手法は、冗長化と呼ばれる。この冗長化により耐障害性に優れた信頼性の高いシステムを提供できる。サービスの信頼性を高める方法として、サービスの構成要素（経路、各種装置、アプリケーション等）を２重化するなどの冗長構成が採用される。
特許文献１には、ネットワーク全体を複数に分割したサブネットワーク内の冗長通信経路の設計をする際に、冗長化された複数の経路候補のうち、ファイバ重複、ノード重複、管路重複などのハードウェア資源を共用するような経路候補をなるべく用いない通信経路出力手段が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１５０４４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
既存のネットワークサービスにおいて、各種ネットワーク機能は物理装置（アプライアンス）で提供されていた。そのため、ネットワーク機能の提供元となる物理装置が固定されてしまい、柔軟性に欠けていた。そこで、物理装置を用いて仮想装置（ＶＭ：Virtual Machine）を構築する仮想化技術を、ネットワーク資源にも適用する試みが普及しつつある。
ＮＦＶ（Network Function Virtualization）は、各種ネットワーク機能を仮想装置（ソフトウェア）で提供する仮想化技術である。仮想装置によりネットワーク機能の配置に柔軟性が生まれることで、ユーザごとの個別の要望に柔軟に対応することができる。
ＮＦＶ技術により仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。ＶＮＦは、例えば、vCPE（Virtualized Customer Premises Equipment）、vRouter、vMitigator、vFW（Virtualized Firewall）、vLB（Virtualized Load Balancer）、vDPI（Virtualized deep packet inspection）である。
【０００５】
ＶＮＦをユーザごとに柔軟に選択・利用可能とする技術を、サービスチェイニングという。サービスチェイニングによって提供される一連のサービスをサービスチェインという。
サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで1つのサービスとして提供する。
【０００６】
図７は、サービスチェインの説明図である。
まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。ここで、各サービスチェインが利用するVNFには、アクセスが混んでいて負荷の高いVNFと、アクセスが空いていて負荷の低いVNFとでばらつきが発生する。以下、各サービスチェインが利用するVNFの詳細について、図８を参照して説明する。
【０００７】
図８は、図７の物理的なネットワークシステム上に構築されたサービスチェインの詳細な説明図である。
符号１０９は、図７の各サービスチェイン[A,B,C]が始点から終点までに通過する物理資源、仮想資源を順に辿った経路を示す。
サービスチェインＡは、始点の物理ノードN1から、VM3上のVNF「F2」と、終点のVM5上のVNF「F3」とを利用する。
サービスチェインＢは、始点の物理ノードN1から、VM5上のVNF「F3」と、終点のVM1上のVNF「F1」とを利用する。
サービスチェインＣは、始点の物理ノードN3から、VM6上のVNF「F4」と、VM5上のVNF「F3」と、終点のVM3上のVNF「F2」とを利用する。
つまり、VNF「F3」は３つのサービスチェインＡ〜Ｃに使用され、VNF「F2」は２つのサービスチェインＡ，Ｃに使用され、VNF「F1」はサービスチェインＢだけに使用され、VNF「F4」はサービスチェインＣだけに使用される。
【０００８】
また、テーブル２０９ａは、サービスチェインごとの収容ユーザ数を示すものであり、サービスチェインＡが最大の100人のユーザを収容している。そして、テーブル２０９ｂは、VNFIDで示されるVNFごとに着目したサービスチェインの状況を示す。符号１０９の説明で前記したように、VNF「F3」は３つのサービスチェインＡ〜Ｃに使用され（つまり、サービス数＝３）、これらのサービスチェインのユーザ数の総和（＝１８０）が最大なので、故障時の影響度が他のVNFよりも大きいものとなっている（図示ではハッチングで強調）。
【０００９】
ここで、ネットワークの冗長設計の話題に戻る。特許文献１などで示唆されているように、信頼性の観点では、ネットワークを複数の経路で冗長化するときには、なるべく多くの物理資源を用意することで、共通に用いる物理資源を少なくすることが好ましい。なぜなら、共通に用いる物理資源が障害によりダウンしてしまうと、その物理資源を用いる冗長経路の全てが同時に利用不可能となってしまい、障害発生後の切替対象から外れてしまうからである。
【００１０】
一方で、ネットワーク運営者の観点からは、ネットワークの冗長設計において、予備として用意する冗長化用の物理資源は、そのまま平常時には遊休資源となってしまうため、リソースの無駄使いになってしまう。よって、コストの観点では、なるべく冗長化用の物理資源が少ない方が好ましい。
【００１１】
以上、信頼性の観点と、コストの観点とを統合的に考えると、ネットワークの冗長設計においては、故障時の影響度が高い重要な箇所は手厚く冗長化を行うことで信頼性を確保しつつ、故障時の影響度が少ない箇所は冗長化の度合いを下げることでコストを節約するような、メリハリの取れたバランスのよい設計が求められる。
例えば、図７，図８のようなサービスチェインの構成では、故障時に多くのユーザに影響を与える（つまり、サービスを中断させてしまい、多くのユーザに待ち時間の不便を強いてしまう）VNF「F3」を他のVNFよりも優先して冗長化を手厚くすることが望ましい。
【００１２】
そこで、本発明は、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することを、主な課題とする。
【課題を解決するための手段】
【００１３】
前記課題を解決するために、本発明のサービスチェイン設計装置は、以下の特徴を有する。
本発明は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする。
【００１４】
これにより、ＶＮＦを利用するサービスチェインの数や、ＶＮＦが収容するユーザの数という、直接的にサービスやユーザに影響するパラメータを重要度として冗長化対象ＶＮＦを選択することで、信頼性の高いサービスチェインの設計が可能となる。さらに、重要なＶＮＦを冗長化対象ＶＮＦとして絞り込むことで、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
【００１５】
本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする。
【００１６】
これにより、ルートの後方であるほど高い重要度とする重みが選択された場合には、サービスチェインのルート後方になるほど冗長化されやすくなるので、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
また、前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みが選択された場合でも、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
【００１７】
本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする。
【００１８】
これにより、サービス内容の重みやユーザの重みが選択された場合には、重要なサービスや重要なユーザをかかえるＶＮＦが優先的に冗長化されるので、ユーザの満足度を高めることができる。
【００１９】
本発明は、前記第２判定部が、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする。
【００２０】
これにより、変動するＶＮＦの負荷が高くなったＶＮＦが優先的に冗長化されるので、より実用的な信頼性設計が可能となる。
【００２１】
本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする。
【００２２】
これにより、複数のＶＮＦ間や、複数の冗長ルート間で重複するハードウェア資源を減らすことにより、１つのハードウェア資源が故障しても、生存するＶＮＦや生存する冗長ルートを多く確保し、信頼性の高い設計が可能となる。
【００２３】
本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする。
【００２４】
これにより、設定変更の対象となる装置が少なくなるため、業務が容易となり、当該設定変更による他サービスへの影響リスクも低減することができる。
【発明の効果】
【００２５】
本発明によれば、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施形態に係わるサービスチェイン設計装置の構成図である。
【図２】本実施形態に係わるサービスチェイン設計装置が扱うサービスチェインに関するデータの構成図である。
【図３】本実施形態に係わる図２のサービスチェインＢ上のＶＮＦが冗長化された後のデータの構成図である。
【図４】本実施形態に係わる冗長化対象ＶＮＦ判定部の処理例を示す説明図である。
【図５】本実施形態に係わる冗長化対象ＶＮＦ判定部の処理例を示す説明図である。
【図６】本実施形態に係わる冗長化対象ＶＮＦ決定部の処理例を示す説明図である。
【図７】サービスチェインの説明図である。
【図８】図７の物理的なネットワークシステム上に構築されたサービスチェインの詳細な説明図である。
【発明を実施するための形態】
【００２７】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２８】
図１は、サービスチェイン設計装置１の構成図である。
サービスチェイン設計装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
【００２９】
サービスチェイン設計装置１が扱うサービスチェインに含まれるＶＮＦについて、以下のように定義する。
まず、サービスチェイン設計装置１は、物理的なネットワークシステム上で動作する全ＶＮＦのうち、故障時に多くのユーザに影響を与える重要なＶＮＦを「冗長化対象ＶＮＦ」として指定する。例えば、図８のVNF「F3」は、冗長化対象ＶＮＦの一例である。
次に、サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」に対して所定の基準を満たしたときに、その冗長化対象ＶＮＦを実際に冗長化するＶＮＦ（以下「冗長化実行ＶＮＦ」）として決定する。つまり、「全ＶＮＦ→冗長化対象ＶＮＦ→冗長化実行ＶＮＦ」という段階を経て実際に冗長化するＶＮＦが決定される。換言すると、冗長化対象ＶＮＦに選出されただけでは、まだ実際に冗長化するＶＮＦか否かは未確定の状態である。
【００３０】
サービスチェイン設計装置１は、各種データを格納するデータベースとして、ポリシー／閾値管理ＤＢ２１と、サービスチェイン構成情報ＤＢ２２と、収容情報管理ＤＢ２３と、性能値収集ＤＢ２４と、冗長化対象ＶＮＦ管理ＤＢ２５とを有する。
サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」を選出するための処理部として、サービスチェイン生成要求受付部１１と、サービスチェイン生成要求分解部１２と、冗長化対象ＶＮＦ判定部（第１判定部）１３と、冗長化対象ＶＮＦ決定部１４とを有する。
サービスチェイン設計装置１は、選出された「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」として決定するための処理部として、冗長化判定部（第２判定部）３１と、冗長化決定部３２と、冗長度計算部３３と、冗長度決定部３４と、ＶＮＦ配置決定部３５と、冗長ルート計算部３６と、冗長ルート決定部３７とを有する。
さらに、冗長ルート決定部３７は、決定された「冗長化実行ＶＮＦ」を実際に冗長化するために、サービスチェイン設計装置１外部のサービスチェインコントローラ要求受付部３８と接続される。
以下、図２，図３の具体例を元に、これらのサービスチェイン設計装置１の各構成要素を明らかにする。
【００３１】
図２は、サービスチェイン設計装置１が扱うサービスチェインに関するデータの構成図である。
符号１０１は、図８の符号１０９のサービスチェインＡ〜Ｃに対して、新たにサービスチェインＤを追加したものである。これらのサービスチェインＡ〜Ｄは、VNF「F1」〜「F5」という５つのＶＮＦを利用する。
テーブルＴ００は、図８のテーブル２０９ａと同様に、符号１０１の各サービスチェインＩＤＴ０１の収容ユーザ数Ｔ０２を示す。サービスチェイン単体でみると、最大のユーザ数200人を収容するサービスチェインＤが最も影響力の高いサービスチェインであるといえる。
【００３２】
テーブルＴ１０，Ｔ２０，Ｔ３０は、図８のテーブル２０９ｂと同様に、ＶＮＦＩＤＴ１１で示されるＶＮＦごとに着目したサービスチェインの状況を示す。図８のテーブル２０９ｂと同様に、収容サービスチェインＩＤＴ１２と、収容数Ｔ２０（サービス数Ｔ２１、ユーザ数Ｔ２２）とが、ＶＮＦＩＤＴ１１ごとに対応づけられている。さらに、図２では、ＶＮＦＩＤＴ１１ごとの性能値Ｔ３０（値１を100%とするＣＰＵ使用率）も、対応づけられている。
このような各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０は、サービスチェイン生成要求受付部１１が受け付けた各サービスチェインを、サービスチェイン生成要求分解部１２が分解して求めたものである。
そして、各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０の内容を冗長化対象ＶＮＦ判定部１３がサービス数Ｔ２１が最大であるＶＮＦを判定した結果、強調図示したVNF「F3」が冗長化対象ＶＮＦ決定部１４により「冗長化対象ＶＮＦ」として決定される。
【００３３】
図３は、図２のサービスチェインＢ上のVNF「F3」が冗長化された後のデータの構成図である。
符号１０２は、図２の符号１０１と同様に、図７の物理的なネットワークシステム上に構築されたサービスチェインＢを示す。
符号１０１と符号１０２とを比較すると、符号１０２のサービスチェインＢは、始点ノードN1からの迂回路「N3→N7→N11→VM6→N11→N7→N3→N1→N2→N4→N8」上に、２つめのVNF「F3」が冗長化されている。
【００３４】
テーブルＴ１１，Ｔ４０（サービス数Ｔ４１、ユーザ数Ｔ４２、性能値Ｔ４３）は、冗長化判定部３１が「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とするか否かを判定に使用される閾値をＶＮＦＩＤＴ１１ごとに対応づけたものである。例えば、サービス数Ｔ４１の「≧５（５以上）」とは、図２のサービス数Ｔ２１が５以上になったときに、「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とする旨を示している。
つまり、図２の段階ではサービス数Ｔ２１＝３なので、サービス数Ｔ４１の「≧５」を満たさないので、冗長化判定部３１は、冗長化対象ＶＮＦ「F3」は、まだ冗長化実行ＶＮＦとはしない旨を判定する。一方、VNF「F3」を利用するサービスチェイン数がさらに２つ増加し、VNF「F3」のサービス数Ｔ４１の「≧５」を満たすようになったら、冗長化決定部３２は、冗長化対象ＶＮＦ「F3」を冗長化実行ＶＮＦとする旨を決定する。
【００３５】
テーブルＴ１１，Ｔ５０（サービス数Ｔ５１、ユーザ数Ｔ５２、性能値Ｔ５３）は、冗長度計算部３３が冗長化実行ＶＮＦ「F3」をどのように冗長化するかを具体的に計算するために参照される。例えば、強調図示したサービス数Ｔ５１の「２≦（２以下）」とは、冗長化実行ＶＮＦ「F3」を冗長化することにより、１つの箇所のVNF「F3」あたり、そのF3を利用するサービスチェイン数が２以下の状態になるようにする旨を示す。
よって、冗長度決定部３４は、冗長化前はサービスチェイン数「５」を収容していた１箇所のVNF「F3」を、新規に２つ生成して合計３箇所のVNF「F3」が存在するように、つまり、合計３箇所なので冗長度＝３を決定する。つまり、サービス数Ｔ５１の「２≦（２以下）」を満たすため、それぞれのVNF「F3」の収容サービス数がそれぞれ「１つ、２つ、２つ」になるように、５つのサービスチェインを分散させればよい。
つまり、冗長化決定閾値Ｔ４０よりも冗長化直後の閾値Ｔ５０を低い値とすることで、１回冗長化した後、すぐに２度目の冗長化決定の判定がおりないように余裕をもたせている。
【００３６】
ＶＮＦ配置決定部３５は、新規に２つ生成するVNF「F3」の配置を決定する。ここで、新旧含め、合計３つのVNF「F3」は、全て異なる物理サーバ上に配置することが望ましい。
冗長ルート計算部３６と、新規に２つ生成するVNF「F3」を通過するサービスチェインのルート（経路）も新規に生成する。例えば、符号１０２で示したように、サービスチェインＢにおいては、VNF「F3」の前に存在する始点ノードN3から分岐し、VNF「F3」が存在するノードN11上のVM6を通過し、サービスチェインＢの終点側のノードN8に合流するルートが、冗長ルート計算部３６によって新規に計算される。
ここで、冗長ルート計算部３６は、符号１０２の例では、始点側（N1）と終点側（N8）だけが分岐前後で重複しているように、各新規経路は可能な限り重複させないようにすることが望ましい。
冗長ルート決定部３７は、冗長ルート計算部３６の計算結果を受け、サービスチェインコントローラ要求受付部３８に対して新規経路を設定するように指示する。
【００３７】
以上、図２，図３を参照して、サービスチェイン設計装置１の各処理部の具体例を用いた説明を行った。
以下では、サービスチェイン設計装置１の各処理部および各データベースの内容について、一般化した説明を行う。まず、符号２１〜２５で示す各データベースが、格納するデータ内容について、図２，図３で説明したテーブルＴ００〜Ｔ５０を参照しつつ説明する。
【００３８】
ポリシー／閾値管理ＤＢ２１は、ＶＮＦＩＤＴ１１ごとの冗長化決定閾値Ｔ４０と、ＶＮＦＩＤＴ１１ごとの冗長化直後の閾値Ｔ５０とを格納する。ここで「ポリシー」とは、ＤＢには直接格納されていないが、「サービス数Ｔ４１を冗長化判定部３１の判定に用いる」もしくは、「ユーザ数Ｔ４２および性能値Ｔ４３を組み合わせて冗長化判定部３１の判定に用いる」などの事前設定情報である。
サービスチェイン構成情報ＤＢ２２は、図２の符号１０１で示したような、サービスチェインＩＤＴ０１ごとの各サービスチェインの構成要素を格納する。例えば、サービスチェインＡの構成要素「N1→L1→N2→L4→N5→L10→N9→VL3→VM3→F2(T11)→VL3→N9→L11→N6→L12→N10→VL5→VM5→F3(T11)」が、サービスチェイン構成情報ＤＢ２２に格納される。
【００３９】
収容情報管理ＤＢ２３は、サービスチェインＩＤＴ０１ごとの収容情報として、収容ユーザ数Ｔ０２、当該サービスチェインに収容されるＶＮＦＩＤＴ１１、および、収容数Ｔ２０を格納する。
性能値収集ＤＢ２４は、ＶＮＦＩＤＴ１１ごとに測定され、収集された性能値Ｔ３０として、図２に例示したＣＰＵ使用率や、図示省略した遅延時間、使用帯域、使用メモリ、使用プロセス数、トラヒック送受信量、処理速度などを１つまたは複数の組み合わせ値として格納する。
冗長化対象ＶＮＦ管理ＤＢ２５は、冗長化対象となったＶＮＦＩＤＴ１１（図２では、Ｆ３）と、その収容サービスチェインＩＤＴ１２とを格納する。
【００４０】
次に、符号２１〜２５で示す各データベースを用いて、各処理部の動作を説明する。
サービスチェイン生成要求受付部１１は、新規サービスチェインの生成オーダを受け付ける。
サービスチェイン生成要求分解部１２は、サービスチェイン生成要求受付部１１が受け付けたオーダ内容の分解処理を行い、その結果をサービスチェイン構成情報ＤＢ２２、および、収容情報管理ＤＢ２３に書き出す。
【００４１】
冗長化対象ＶＮＦ判定部１３は、以下に示すように、各データベースを参照して、全ＶＮＦから冗長化対象ＶＮＦを選択するために必要なデータを取得する。
・サービスチェイン構成情報ＤＢ２２から、サービスチェインを構成するＶＮＦ情報を取得する。
・ポリシー／閾値管理ＤＢ２１から、冗長化対象ＶＮＦを決定するポリシー情報を取得する。
・収容情報管理ＤＢ２３から、各サービスチェインに収容されているユーザ数／サービス数などを取得する。
・性能値収集ＤＢ２４から、各サービスチェインに収容されているＶＮＦの性能値情報を取得する。
【００４２】
そして、冗長化対象ＶＮＦ判定部１３は、以下に列挙する手法のいずれかにより、冗長化対象ＶＮＦの候補を選択する。どの手法を用いるかは、取得したポリシー情報で指定される。
（手法１１）収容サービスチェイン数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１２）収容ユーザ数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１３）特に重要な機能をサービスとして提供しているＶＮＦ（例：緊急対応用サービスを提供するＶＮＦなど）を、冗長化対象ＶＮＦとすることを許可する。
（手法１４）重要ユーザを収容しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１５）サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図４で後記）。
（手法１６）前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図５で後記）。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を１つ以上用いて、冗長化対象ＶＮＦを決定する（詳細は図６で後記）。
なお、収容サービスチェイン数、収容ユーザ数などのパラメータは、冗長化対象ＶＮＦを決定するための重要度のパラメータである。
【００４３】
冗長化判定部３１は、冗長化対象ＶＮＦ決定部１４により決定された冗長化対象ＶＮＦを、冗長化実行ＶＮＦとするか否かを判定する。この判定処理は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照して、現在値（実測値）が閾値を超過しているかどうかを、判定基準の閾値ごとに比較する処理である。以下に、判定基準を列挙する。
（基準２１）収容サービスチェイン数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２２）収容ユーザ数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２３）性能値（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
冗長化決定部３２は、冗長化判定部３１の結果（１つ以上の閾値超過の可否）をもって、最終的に冗長化対象ＶＮＦを冗長化実行ＶＮＦとするか否かを決定する。冗長化決定部３２は、例えば、（基準２１）および（基準２２）それぞれの閾値が共に超過していたら冗長化を決定する。
【００４４】
冗長度計算部３３は、冗長化判断のパラメータ（収容サービスチェイン数、収容ユーザ数、性能値）が、任意の閾値以下になるように分割し、分割した分のＶＮＦを新規に生成する。そのため、冗長度計算部３３は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照する。
冗長度決定部３４は、冗長度計算部３３の結果（１つ以上の冗長度）を用いて、対象ＶＮＦの新規生成数を決定する。例えば、収容サービスチェイン数に着目した場合は対象ＶＮＦの新規生成数は２となり、性能値に着目した場合は新規生成数が３となるような場合を考える。冗長度決定部３４は、２と３との最大数を採用し、最終的にはＶＮＦの新規生成数を３と決定する。
【００４５】
ＶＮＦ配置決定部３５は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、冗長化実行ＶＮＦがそれぞれ可能な限り別々の物理サーバ上に配置されるように、新規生成したＶＮＦの配置を決定する。これにより、１つの物理サーバが故障した場合でも、他の物理サーバが生存していれば、いずれかの冗長化実行ＶＮＦが機能し続けることで、信頼性を高めることができる。
【００４６】
冗長ルート計算部３６は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、ＶＮＦ配置決定部３５が決定した各新規生成ＶＮＦの配置をもとに、冗長ルートを計算する。以下に、冗長ルートの計算手法を列挙する。冗長ルート計算部３６は、（手法３１）〜（手法３３）のうちの少なくとも１つを用いて、冗長ルートを計算する。
（手法３１）サービスチェインごとに、冗長化対象となるＶＮＦの直前／直後のＶＮＦが存在するサーバ（もしくは、始点／終点ノード）と、新規ＶＮＦが存在するサーバとの間の新規経路を、ダイクストラ法などで算出する。
（手法３２）冗長化された複数の同種ＶＮＦにおいて、既に割り当てられている経路は計算の対象外とする。もしくは、より共有されていない経路を選択する。このように、経路重複を発生させないことで、現用系および予備系の経路双方が故障することによるサービス断の発生を予防することができる。
（手法３３）冗長化対象となるＶＮＦの直前にｖＬＢ（virtual Load Balancer）などのロードバランサを配置する。そのロードバランサを経由して複数の冗長化実行ＶＮＦ（既存ＶＮＦおよび新規ＶＮＦ）それぞれを通過する冗長ルートを生成してもよい。ただし、この場合、仮想経路は互いに分離されていても、物理経路が分離されているとは限らない。
【００４７】
冗長ルート決定部３７は、冗長ルート計算部３６の結果（１つ以上の冗長ルート）を用いて、新規生成したＶＮＦの冗長ルートを決定する。決定された冗長ルートは、サービスチェイン構成情報ＤＢ２２に追加される。
サービスチェインコントローラ要求受付部３８は、冗長ルート決定部３７から以下の設定情報を受け取り、その設定情報を物理ネットワークに反映させる。
・冗長化実行ＶＮＦのＶＮＦＩＤ
・冗長化実行ＶＮＦの生成数
・冗長化実行ＶＮＦの配置先の物理サーバＩＤ
・冗長化実行ＶＮＦを通過する新規の冗長ルートの情報
以上、図１〜図３を参照して、サービスチェイン設計装置１の各構成要素の詳細を説明した。以下、図４〜図６を参照して、冗長化対象ＶＮＦ判定部１３および冗長化対象ＶＮＦ決定部１４の一部の処理を補足説明する。
【００４８】
図４は、冗長化対象ＶＮＦ判定部１３の（手法１５）の処理例を示す説明図である。
冗長化対象ＶＮＦ判定部１３は、（手法１５）として、サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることとした。ここで、「重要なポジションに存在するＶＮＦ」とは、以下の２通りである。
（Ａ）サービスチェインの最後に位置するＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」と、サービスチェインＣの「Ｆ２」とが、それぞれ一番最後に位置する。
（Ｂ）サービスチェインにおけるＶＮＦの位置によって重み付けし（チェインの後方に位置するほど、重要度としての重みを大きくし）、一番重みの大きいＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」は、同じサービスチェインＡの「Ｆ２」よりも後方に位置しているので、重みが前方の「Ｆ２」の０．５よりも大きい１．０に設定されている。そして、テーブル２０３に示すように、サービスチェイン全体での重みの合計値をＶＮＦごとに求め、その最大値１．６６となる「Ｆ３」を、重要なポジションに存在するＶＮＦとする。
【００４９】
なお、（Ａ）や（Ｂ）のように重みを設定した理由は、次の通りである。サービスチェインは、ルートの始点から順番に（シーケンシャルに）、ＶＮＦで処理される。例えば、チェインの最後のＶＮＦが故障した場合、一番最初から処理をやり直す必要がある。つまり、ルートの前段で実施した処理は無駄となり、全てやり直しとなってしまう。従って、チェインの後方のＶＮＦになればなるほど、重要（冗長化対象）となるようにした。
【００５０】
図５は、冗長化対象ＶＮＦ判定部１３の（手法１６）の処理例を示す説明図である。
冗長化対象ＶＮＦ判定部１３は、（手法１６）として、前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることとした。前段で多くのリソースを消費しているＶＮＦは、例えば、ＶＮＦごとに、前段処理で使用しているリソースの割合によって重み付けし、一番重みの大きいＶＮＦとして求めることができる。
図５の例では、テーブル２０４に示すように、重い処理か否かを判断する材料として、ＶＮＦごとの「リソース使用率」をみる。リソース使用率が大きい程、より重い処理を実行しているためである。
【００５１】
そして、符号１０４の例では、サービスチェインＡの「Ｆ２」は、テーブル２０４を参照するとリソース使用率＝０．７である。そして、（自身のＶＮＦの重み）＝（サービスチェインにおける前段のリソース使用率）＋（自身のリソース使用率）という累積和の計算により、冗長化対象ＶＮＦ判定部１３は、各ＶＮＦの重みを求める。つまり、図４の（手法１５）と同様に、チェインの後方のＶＮＦになればなるほど、重要度としての重みを増加させた。
サービスチェインＡの「Ｆ２」の重み＝（自身のリソース使用率＝０．７）となり、
サービスチェインＡの「Ｆ３」の重み＝（前段のリソース使用率＝０．７）＋（自身のリソース使用率＝０．８）＝１．５となる。
同様に、冗長化対象ＶＮＦ判定部１３は、サービスチェインＢのＦ３，Ｆ１の重みも求める。
そして、冗長化対象ＶＮＦ判定部１３は、重みの最大値＝１．６となるＦ１を、冗長化対象ＶＮＦとする。
【００５２】
さらに、冗長化対象ＶＮＦ判定部１３は、図５の（手法１６）で求めた各リソース使用率の重みに対して、図４の（手法１５）で説明したように、サービスチェイン全体での重みの合計値が最大値となるＶＮＦを、冗長化対象ＶＮＦとしてもよい。例えば、図５の３つのＶＮＦについては、以下のように、重みの合計値が求まる。
・「Ｆ１」の重みの合計値＝１．６
・「Ｆ２」の重みの合計値＝０．７
・「Ｆ３」の重みの合計値＝２．３（＝１．５＋０．８）
よって、重みの合計値が最大の「Ｆ３」が、冗長化対象ＶＮＦとなる。
【００５３】
図６は、冗長化対象ＶＮＦ決定部１４の処理例を示す説明図である。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を２つ以上組み合わせて、冗長化対象ＶＮＦを決定してもよい。以下、その具体例を説明する。
テーブル２０５は、ＶＮＦごとに、収容ユーザ数が最大であるＶＮＦ（手法１２）を決定するためのユーザ数（つまり、図２で示した収容数Ｔ２０のうちのユーザ数Ｔ２２）と、前段で多くのリソースを消費しているＶＮＦ（手法１６）を決定するためのリソース使用率とを抜粋したものである。
まず、図５で説明したように、（手法１６）に従って、各ＶＮＦの重みを計算する。例えば、サービスチェインＡのＦ３の重み＝０．７＋０．８＝１．５である。
次に、ＶＮＦごとに、（手法１６）の重み×（手法１２）のユーザ数の積を求める。例えば、サービスチェインＡのＦ３の積＝（重み１．５）×（ユーザ数１８０）＝２７０となる。この積が他のどのＶＮＦの積よりも大きいので（つまり、重要度が最大値となるので）、冗長化対象ＶＮＦ決定部１４は、Ｆ３を冗長化対象ＶＮＦとして決定する。
【００５４】
以上説明した本実施形態では、サービスチェイン設計装置１が、サービスチェインに使用されるＶＮＦを冗長化することで、サービスチェインを動的かつ信頼性を高めた設計を行う方法を示した。
【００５５】
なお、比較例として、同じＶＮＦの集合を提供可能なサービスチェインを複数用意し、いずれか１つのサービスチェインに問題が発生した場合に、他のサービスチェインに切り替えるという運用方法が想定される。ただし、この比較例では、複数のサービスチェインに共有されるＶＮＦが故障した場合、故障したＶＮＦから他のＶＮＦに切り替える過程で多くのサービスまたはユーザに影響が及んでしまう。
例えば、あるＶＮＦが１００個のサービスチェインに共有されている場合、本ＶＮＦが故障すると、一度に１００個のチェインが予備系に切り替わる。結果、１００種のサービス影響と、本サービスチェインに収容されている多数のユーザに影響を及ぼしてしまう。
【００５６】
一方、本実施形態では、サービスチェイン設計装置１が、多数のユーザに影響を及ぼしてしまうような、特に重要なＶＮＦを冗長化対象ＶＮＦとして個別に多重化することで、サービスチェイン全体の信頼性をより高めることができる。さらに、比較例のようなサービスチェイン単位での冗長化と、本実施形態の重要なＶＮＦ単位での冗長化とを併用することで、より高い信頼性を確保できる。
【００５７】
また、本実施形態では、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とをそれぞれ個別の機能部として用意することで、最初に冗長化対象とするＶＮＦを決定し、次に対象ＶＮＦの各種閾値を観測し、冗長化を行う構成を示した。その代わりに、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とを１つの機能部としてサービスチェイン設計装置１内に実装してもよい。その場合、運用中の全ＶＮＦの各種閾値を観測しながら、冗長化対象ＶＮＦを決定し、同時に冗長化を行うようにサービスチェイン設計装置１が動作する。
【００５８】
なお、本実施形態においては、本発明に係るサービスチェイン設計装置１は、図２に示すように、４種類のサービスチェインＡ〜Ｄを扱うこととしたが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービスチェイン設計装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
【符号の説明】
【００５９】
１      サービスチェイン設計装置
１１    サービスチェイン生成要求受付部
１２    サービスチェイン生成要求分解部
１３    冗長化対象ＶＮＦ判定部（第１判定部）
１４    冗長化対象ＶＮＦ決定部
２１    ポリシー／閾値管理ＤＢ
２２    サービスチェイン構成情報ＤＢ
２３    収容情報管理ＤＢ
２４    性能値収集ＤＢ
２５    冗長化対象ＶＮＦ管理ＤＢ
３１    冗長化判定部（第２判定部）
３２    冗長化決定部
３３    冗長度計算部
３４    冗長度決定部
３５    ＶＮＦ配置決定部（配置決定部）
３６    冗長ルート計算部
３７    冗長ルート決定部
３８    サービスチェインコントローラ要求受付部
【図１】
2019213028.tif 000003
【図２】
2019213028.tif 000004
【図３】
2019213028.tif 000005
【図４】
2019213028.tif 000006
【図５】
2019213028.tif 000007
【図６】
2019213028.tif 000008
【図７】
2019213028.tif 000009
【図８】
2019213028.tif 000010