(57)【要約】【課題】仮想化技術で構築されたサービスに対して、動作上の物理リソースに問題が発生しても、サービスの中断時間を短縮すること。【解決手段】サービス管理装置１は、リソースデータ管理部１３のリソースデータをもとに、ＶＭの使用リソース要件を満たすエリアの候補集合を抽出し、その抽出した候補集合に属する１つのエリアを配置先エリアとし、抽出した候補集合に属する１つ以上のエリアを予備配置先エリアとする配置先計算部１４と、配置先計算部１４の計算結果に従って、ＶＭを配置先エリアの配置先リソースに配置するとともに予備配置先エリアにＶＭの予備配置先リソースを確保し、その配置後の配置先リソースの故障発生時には、配置先リソースから予備配置先リソースにＶＭを再配置する配置制御部１６とを有する。【選択図】図４
2019139533.tif 000002
【特許請求の範囲】
【請求項１】
使用リソース要件が規定された配置対象の仮想機能部を指定した配置要求を受け付ける配置対象受付部と、
前記仮想機能部の配置先の候補となる各エリアから収集された、前記仮想機能部を稼働させるために提供可能なリソースをリソースデータとして管理するリソースデータ管理部と、
前記リソースデータ管理部のリソースデータをもとに、前記仮想機能部の前記使用リソース要件を満たすエリアの候補集合を抽出し、その抽出した前記候補集合に属する１つのエリアを配置先エリアとし、抽出した前記候補集合に属する１つ以上のエリアを予備配置先エリアとした配置構成データを計算する配置先計算部と、
前記配置構成データに従って、前記仮想機能部を前記配置先エリアの配置先リソースに配置するとともに前記予備配置先エリアに前記仮想機能部の予備配置先リソースを確保し、
その配置後の前記配置先リソースの故障発生時には、前記配置先リソースから前記予備配置先リソースに前記仮想機能部を再配置するように制御する配置制御部とを有することを特徴とする
配置構成装置。
【請求項２】
前記配置先計算部は、前記候補集合から提供可能リソースが最も少ないエリアを前記仮想機能部の前記配置先エリアとして選択し、前記候補集合から前記予備配置先エリアを選択するための所定のポリシに合致するエリアを前記仮想機能部の前記予備配置先エリアとして選択することを特徴とする
請求項１に記載の配置構成装置。
【請求項３】
前記配置先計算部は、前記所定のポリシに従って、前記配置先エリアと同じエリアを前記予備配置先エリアとして選択し、
前記配置制御部は、前記配置先エリア内の故障した前記配置先リソースと同じエリア内に確保されている前記予備配置先リソースに、前記仮想機能部を再配置することを特徴とする
請求項２に記載の配置構成装置。
【請求項４】
前記配置先計算部は、前記所定のポリシに従って、前記配置先エリアと異なるエリアを前記予備配置先エリアとして選択し、
前記配置制御部は、前記配置先エリア内の故障した前記配置先リソースと異なるエリア内に確保されている前記予備配置先リソースに、前記仮想機能部を再配置することを特徴とする
請求項２に記載の配置構成装置。
【請求項５】
前記配置先計算部は、前記所定のポリシに従って、配置対象の前記仮想機能部とは別の前記仮想機能部がすでに稼働しているエリアを、配置対象の前記仮想機能部における前記予備配置先エリアとして選択することを特徴とする
請求項２に記載の配置構成装置。
【請求項６】
前記配置対象受付部は、すでに配置された前記仮想機能部についての前記使用リソース要件が変更された旨を受け付けると、変更後の前記使用リソース要件に基づいて、前記配置構成データを前記配置先計算部に再計算させるとともに、その再計算された前記配置構成データに基づいて、前記仮想機能部の前記配置先リソースおよび前記予備配置先リソースを更新するように前記配置制御部に制御させることを特徴とする
請求項１に記載の配置構成装置。
【請求項７】
使用リソース要件が規定された配置対象の仮想機能部を指定した配置要求を受け付ける配置対象受付部と、
前記仮想機能部の配置先の候補となる各サーバから収集された、前記仮想機能部を稼働させるために提供可能なリソースをリソースデータとして管理するリソースデータ管理部と、
前記リソースデータ管理部のリソースデータをもとに、前記仮想機能部の前記使用リソース要件を満たすサーバの候補集合を抽出し、その抽出した前記候補集合に属する１つのサーバを配置先サーバとし、抽出した前記候補集合に属する１つ以上のサーバを予備配置先サーバとした配置構成データを計算する配置先計算部と、
前記配置構成データに従って、前記仮想機能部を前記配置先サーバの配置先リソースに配置するとともに前記予備配置先サーバに前記仮想機能部の予備配置先リソースを確保し、
その配置後の前記配置先リソースの故障発生時には、前記配置先リソースから前記予備配置先リソースに前記仮想機能部を再配置するように制御する配置制御部とを有することを特徴とする
配置構成装置。
【請求項８】
配置対象受付部と、リソースデータ管理部と、配置先計算部と、配置制御部とを有する配置構成装置により実行される配置構成方法であって、
前記配置対象受付部は、使用リソース要件が規定された配置対象の仮想機能部を指定した配置要求を受け付け、
前記リソースデータ管理部は、前記仮想機能部の配置先の候補となる各エリアから収集された、前記仮想機能部を稼働させるために提供可能なリソースをリソースデータとして管理し、
前記配置先計算部は、前記リソースデータ管理部のリソースデータをもとに、前記仮想機能部の前記使用リソース要件を満たすエリアの候補集合を抽出し、その抽出した前記候補集合に属する１つのエリアを配置先エリアとし、抽出した前記候補集合に属する１つ以上のエリアを予備配置先エリアとした配置構成データを計算し、
前記配置制御部は、
前記配置構成データに従って、前記仮想機能部を前記配置先エリアの配置先リソースに配置するとともに前記予備配置先エリアに前記仮想機能部の予備配置先リソースを確保し、
その配置後の前記配置先リソースの故障発生時には、前記配置先リソースから前記予備配置先リソースに前記仮想機能部を再配置するように制御することを特徴とする
配置構成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配置構成装置、および、配置構成方法に関する。
【背景技術】
【０００２】
１台の物理マシン上に、複数の仮想マシン（ＶＭ：Virtual Machine）を動作させることにより、物理マシンの細かい設定作業の負担を軽減させるとともに、マシン構成を柔軟に変更できる。このようなサーバ仮想化技術と同様に、ネットワーク機能も物理デバイスに依存しないように仮想化する試みが行われている。
ＳＤＮ（Software-Defined Networking）は、ソフトウェア技術によりネットワークを仮想化する技術であり、ＶＭに相当するような仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。これにより、ネットワークの運用管理を効率化することができる。
【０００３】
特許文献１には、ＶＮＦをネットワークサービスとして管理する装置が記載されている。この装置は、複数のオペレータから非同期にネットワークサービスが生成要求されるときに、ネットワークサービスを動作させるリソースを複数のオペレータに重複して割り当てることを回避するように調停する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−１４３４５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＳＤＮの浸透により、データセンタやクラウドなどでもＶＮＦの採用が増えている。このような商用利用においては、仮想技術であっても、従来の物理リソースを提供するときと同等のＳＬＡ（Service Level Agreement）が求められることもある。例えば、物理リソースに故障が発生したとしても、その復旧するまでにサービスを中断する時間の許容時間がＳＬＡとして求められる。
【０００６】
一方、特許文献１などの従来の仮想化技術では、リソースの利用効率を最適化するなどの故障が発生しない状況での配置最適化は行われていた。しかし、故障が発生してから復旧するまでの中断時間を最小化するという観点での最適化は考慮されていない。
以下、図１１〜図１６を参照して、サービスの中断時間のＳＬＡを満たすときの問題を詳細に説明する。以下では、ＳＬＡを遵守する対象の仮想化技術をＶＭとして例示するが、ＶＮＦの場合も同様である。
【０００７】
図１１は、各エリアに割り当てられているＶＭを示す説明図である。
「配置先エリア」とは、ＶＭが配置される先のエリアである。例えば、ＶＭ１の配置先エリアは「エリアＡ」であり、ＶＭ３の配置先エリアは「エリアＢ」である。
「配置先リソース」とは、配置先エリア内で配置されたＶＭが動作のために使用する計算機資源や通信資源である。例えば、ＶＭ１の配置先リソースは、エリアＡ内に存在する物理サーバの計算機資源と、その物理サーバに接続されるネットワークの通信資源である。
【０００８】
図１２は、図１１の状態からＶＭの再配置先を空ける処理を示す説明図である。
エリアＢ内のＶＭ３の配置先リソースに故障が発生したとする（×印）。エリアＣはエリアＢ内の配置先リソースと同等の配置先リソースを提供できるが、エリアＤは同等の配置先リソースを提供できないとする。
このとき、エリアＣで稼働中のＶＭ５をエリアＤに再配置することで、エリアＣ内の配置先リソースを空けておく。
【０００９】
図１３は、図１１の状態から再配置先として空いたリソースにＶＭを再配置する処理を示す説明図である。
エリアＢ内のＶＭ３は、図１２で配置先リソースを空けておいたエリアＣ内に再配置される。これにより、ＶＭ３はエリアＢで配置先リソースに故障が発生した後でも、エリアＣで復旧して稼働を再開することができる。
しかし、故障が発生した後に再配置先を準備するような事後的な対応では、ＶＭ３の中断期間が長期化してしまうので、ＶＭ３の復旧時間の観点でのＳＬＡを満たさなくなってしまう。
【００１０】
図１４は、使用リソース要件を区別して、各エリアに割り当てられているＶＭを示す説明図である。
「使用リソース要件」は、ＶＭごとに定められており、ＶＭが実行するのに要するリソースの種類や分量を示す。例えば、図１４では細線で囲まれたＶＭ（ＶＭ１，ＶＭ３）は、少ないリソースでも動作する第１使用リソース要件が定められている。一方、太線で囲まれたＶＭ（ＶＭ２，ＶＭ４）は、細線で囲まれたＶＭよりも多いリソースで動作する第２使用リソース要件が定められている。
「提供可能リソース」は、各エリアがＶＭを動作させるために提供することができるリソースである。
例えば、第１使用リソース要件を満たすが第２使用リソース要件を満たさない程度の提供可能リソースを有するエリアＸは、細線で囲まれている。一方、第１使用リソース要件も第２使用リソース要件も満たす程度の提供可能リソースを有するエリアＹは、太線で囲まれている。
【００１１】
図１５は、図１４の状態から使用リソース要件が低いＶＭを再配置したときの説明図である。ＶＭ１は第１使用リソース要件（少ないリソース）で動作するので、提供可能リソースも少ない予備配置先エリア＝エリアＸ内に再配置される。
図１６は、図１４の状態から使用リソース要件が高いＶＭを再配置したときの説明図である。ＶＭ２は第２使用リソース要件（多いリソース）で動作するので、提供可能リソースも多い予備配置先エリア＝エリアＹ内に再配置される。
このように、図１４〜図１６では使用リソース要件を考慮して予備配置先エリアを決定する必要がある。つまり、故障が発生した後に再配置先を用意するときに、使用リソース要件も考慮する場合にはさらに中断時間が長期化してしまう。
【００１２】
そこで、本発明は、仮想化技術で構築されたサービスに対して、動作上の物理リソースに問題が発生しても、サービスの中断時間を短縮することを、主な課題とする。
【課題を解決するための手段】
【００１３】
前記課題を解決するために、本発明の配置構成装置は、以下の特徴を有する。
本発明は、使用リソース要件が規定された配置対象の仮想機能部を指定した配置要求を受け付ける配置対象受付部と、
前記仮想機能部の配置先の候補となる各エリアから収集された、前記仮想機能部を稼働させるために提供可能なリソースをリソースデータとして管理するリソースデータ管理部と、
前記リソースデータ管理部のリソースデータをもとに、前記仮想機能部の前記使用リソース要件を満たすエリアの候補集合を抽出し、その抽出した前記候補集合に属する１つのエリアを配置先エリアとし、抽出した前記候補集合に属する１つ以上のエリアを予備配置先エリアとした配置構成データを計算する配置先計算部と、
前記配置構成データに従って、前記仮想機能部を前記配置先エリアの配置先リソースに配置するとともに前記予備配置先エリアに前記仮想機能部の予備配置先リソースを確保し、
その配置後の前記配置先リソースの故障発生時には、前記配置先リソースから前記予備配置先リソースに前記仮想機能部を再配置するように制御する配置制御部とを有することを特徴とする。
【００１４】
これにより、故障発生の前でも故障発生の後でも、使用リソース要件を満たすリソース上で仮想機能部を稼働させることができる。そして、あらかじめ仮想機能部の再配置先としての予備配置先リソースが、故障発生前に用意されている。よって、故障発生時には、仮想機能部の再配置先を検索する処理を省略し、ただちに仮想機能部を予備配置先リソースに再配置させることで、仮想機能部が提供するサービスの中断時間を短縮することができる。
【００１５】
本発明は、前記配置先計算部が、前記候補集合から提供可能リソースが最も少ないエリアを前記仮想機能部の前記配置先エリアとして選択し、前記候補集合から前記予備配置先エリアを選択するための所定のポリシに合致するエリアを前記仮想機能部の前記予備配置先エリアとして選択することを特徴とする。
【００１６】
これにより、１つのエリアに仮想機能部が集中して配置されるので、リソースの利用効率を高めることができる。なお、他の配置済みの仮想機能部にリソースを使用されることで、残った提供可能リソースが少ないエリアほど、多くの仮想機能部が配置済みである傾向にある。
【００１７】
本発明は、前記配置先計算部が、前記所定のポリシに従って、前記配置先エリアと同じエリアを前記予備配置先エリアとして選択し、
前記配置制御部が、前記配置先エリア内の故障した前記配置先リソースと同じエリア内に確保されている前記予備配置先リソースに、前記仮想機能部を再配置することを特徴とする。
【００１８】
これにより、他のエリアでは満たせないような厳しい使用リソース要件が指定された仮想機能部であっても、その厳しい使用リソース要件を満たす程度に提供可能なリソースが豊富なエリア内に集中して、仮想機能部を配置および再配置することができる。
【００１９】
本発明は、前記配置先計算部が、前記所定のポリシに従って、前記配置先エリアと異なるエリアを前記予備配置先エリアとして選択し、
前記配置制御部が、前記配置先エリア内の故障した前記配置先リソースと異なるエリア内に確保されている前記予備配置先リソースに、前記仮想機能部を再配置することを特徴とする。
【００２０】
これにより、配置先エリアだけでなく他のエリアまで予備配置先エリアの選択肢が広がることで、保有するすべてのサーバリソースを有効に活用して予備配置先エリアを確保できる。
【００２１】
本発明は、前記配置先計算部が、前記所定のポリシに従って、配置対象の前記仮想機能部とは別の前記仮想機能部がすでに稼働しているエリアを、配置対象の前記仮想機能部における前記予備配置先エリアとして選択することを特徴とする。
【００２２】
これにより、稼働中の仮想機能部と、別の仮想機能部用の予備配置先リソースとが同じエリア内に混在する。よって、予備配置先リソースだけしか存在しないエリアが減ることで、遊休状態のリソースを過剰に常時備えておくような非効率なリソース運用を減らすことができる。
【００２３】
本発明は、前記配置対象受付部が、すでに配置された前記仮想機能部についての前記使用リソース要件が変更された旨を受け付けると、変更後の前記使用リソース要件に基づいて、前記配置構成データを前記配置先計算部に再計算させるとともに、その再計算された前記配置構成データに基づいて、前記仮想機能部の前記配置先リソースおよび前記予備配置先リソースを更新するように前記配置制御部に制御させることを特徴とする。
【００２４】
これにより、使用リソース要件が低い状態で配置された仮想機能部に対して、新たに事業間の契約により使用リソース要件を引き上げるような、変化するＳＬＡに応じた柔軟なネットワーク運用が可能となる。
【発明の効果】
【００２５】
本発明によれば、仮想化技術で構築されたサービスに対して、動作上の物理リソースに問題が発生しても、サービスの中断時間を短縮することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施形態に係わる各エリアに割り当てられている配置先リソースおよび予備配置先リソースを示す説明図である。
【図２】本実施形態に係わる図１の状態から配置先リソース上のＶＭ１を予備配置先リソースに再配置する処理を示す説明図である。
【図３】本実施形態に係わる図１の状態から予備配置先リソースの再計算処理を示す説明図である。
【図４】本実施形態に係わるリソース管理システムの構成図である。
【図５】本実施形態に係わる配置先計算部の処理を示す説明図である。
【図６】本実施形態に係わる配置構成データ管理部の一例を示すテーブルである。
【図７】本実施形態に係わるリソース管理システムの処理を示すシーケンス図である。
【図８】各エリアに割り当てられているＶＭを示す説明図である。
【図９】図８の状態からＶＭ上のリソースに故障が発生したときの説明図である。
【図１０】図９の状態から再配置先としたエリアＸが利用不可能である状況を示す説明図である。
【図１１】各エリアに割り当てられているＶＭを示す説明図である。
【図１２】図１１の状態からＶＭの再配置先を空ける処理を示す説明図である。
【図１３】図１１の状態から再配置先として空いたリソースにＶＭを再配置する処理を示す説明図である。
【図１４】使用リソース要件を区別して、各エリアに割り当てられているＶＭを示す説明図である。
【図１５】図１４の状態から使用リソース要件が低いＶＭを再配置したときの説明図である。
【図１６】図１４の状態から使用リソース要件が高いＶＭを再配置したときの説明図である。
【発明を実施するための形態】
【００２７】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２８】
まず、本発明の概要について、図１〜図３を参照して説明する。
図１は、各エリアに割り当てられている配置先リソースおよび予備配置先リソースを示す説明図である。
「予備配置先エリア」とは、配置先エリア内で配置されたＶＭが故障発生などにより稼働が困難になったときに、新たな配置先エリアとなるように故障発生前に指定されたエリア（避難場所）である。
「予備配置先リソース」とは、故障発生後に再配置されたＶＭが使用するために、予備配置先エリア内に確保されたリソースである。例えば、図１では、図１４と同様に、使用リソース要件が高いＶＭ３，４と、予備配置先リソースが多い予備配置先エリア＝エリアＤとを太線で囲んでいる。なお、使用リソース要件は、例えば、ＳＬＡで規定された要件である。
【００２９】
ここで、本実施形態では、故障が発生する前のＶＭの配置段階において、配置対象のＶＭごとに新規の配置先リソースと、将来の故障に備えて再配置するときの予備配置先リソースとを組み合わせて確保しておくように配置構成することを、主な特徴とする。
例えば、ＶＭ１の配置先リソースは配置先エリア＝エリアＡに用意されるとともに、そのＶＭ１の予備配置先リソースは予備配置先エリア＝エリアＢに用意される。同様に、ＶＭ２の予備配置先リソースもエリアＢに用意されるので、エリアＢには、ＶＭ１とＶＭ２それぞれの予備配置先リソースが用意される（図では「ＶＭ１＆２」と表記）。
一方、使用リソース要件が高いＶＭ３，４の予備配置先エリアは、予備配置先リソースが多いエリアＤである（図では「ＶＭ３＆４」と表記）。つまり、ＶＭの使用リソース要件を考慮して、配置先エリアだけでなく予備配置先エリアについても決定される。
【００３０】
図２は、図１の状態から配置先リソース上のＶＭ１を予備配置先リソースに再配置する処理を示す説明図である。ＶＭ１の配置先エリアで配置先リソースに故障が発生すると、図１であらかじめ用意しておいた予備配置先エリアにＶＭ１を迅速に再配置できる。
つまり、故障した後に予備配置先リソースを探索するような図１１〜図１３の方式に比べ、故障する前に予備配置先リソースを確保しておく図１〜図３の方式は、サービスの中断時間を短縮することができる。
【００３１】
図３は、図１の状態から予備配置先リソースの再計算処理を示す説明図である。図１の細線で囲まれたＶＭ２は使用リソース要件が低かったが、図３において太線で囲まれたＶＭ２は使用リソース要件が高いものに変更されたとする。
このように、使用リソース要件がＶＭの配置後に変更されたとしても、予備配置先リソースをエリアＢからエリアＤに変更するように（図では「ＶＭ２＆３＆４」と表記）、配置構成を柔軟に再計算することもできる。
【００３２】
図４は、リソース管理システムの構成図である。リソース管理システムは、ＮＷ管理システム２１と、ＮＷ収集システム２２と、ＮＷ制御システム２３と、リソース提供システム２４と、サービス管理装置（配置構成装置）１とがネットワークで接続されて構成される。ＮＷはネットワークの略である。
サービス管理装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
【００３３】
リソース提供システム２４は、サービスを提供するために、図１〜図３で説明したＶＭや、ＶＮＦなどの仮想機能部を動作させるためのリソース（配置先リソース、予備配置先リソース）を提供する計算機環境（物理サーバ、物理ネットワークデバイス）である。１つ以上の物理サーバは、１つのエリアとしてグループ化されている。
ＮＷ収集システム２２は、リソース提供システム２４の各リソースに対して、提供可能リソースを測定する。提供可能リソースは、以下に例示するスペックを１つまたは複数組み合わせたものである。
・ＣＰＵのスペック（コア数、クロック数などの計算能力）
・メモリのスペック（転送速度、記憶容量など）
・ネットワークのスペック（通信帯域、遅延、パケットロス率などのネットワークの品質指標）
【００３４】
ＮＷ制御システム２３は、リソース提供システム２４の各リソースに対して、図１〜図３に例示したような配置構成データを反映させることで、配置先リソースに仮想機能部を配置し、予備配置先リソースに仮想機能部の再配置先を確保する。
ＮＷ管理システム２１は、サービス管理装置１を介してリソース提供システム２４への各種要求を管理者に入力させるためのシステムである。各種要求とは、例えば、仮想機能部を新規に配置させるための配置要求や、すでに配置された仮想機能部を故障時に再配置させるための再配置要求である。
以上説明したＮＷ管理システム２１、ＮＷ収集システム２２、および、ＮＷ制御システム２３は、リソース提供システム２４の設定や管理を自動化するためのオーケストレータとして動作する。
【００３５】
サービス管理装置１は、配置対象受付部１１と、配置構成データ管理部１２と、リソースデータ管理部１３と、配置先計算部１４と、ポリシデータ管理部１５と、配置制御部１６とを含めて構成される。
配置対象受付部１１は、配置対象である仮想機能部（ＶＭ、ＶＮＦ）について、その使用リソース要件を含めた配置要求を受け付ける（図３で示した使用リソース要件の変更要求も受け付ける）。なお、使用リソース要件は、ＮＷ収集システム２２が収集する提供可能リソースとして前記した各種のスペックを用いて表現され、例えば、ＶＭのカタログやＶＮＦのカタログ内のパラメータとして通知される。
【００３６】
リソースデータ管理部１３は、ＮＷ収集システム２２が収集したリソース提供システム２４の各提供可能リソースを管理する。
配置先計算部１４は、配置対象受付部１１が受け付けた使用リソース要件と、リソースデータ管理部１３が管理する提供可能リソースとを照合することで、使用リソース要件を提供可能な配置先エリアと予備配置先エリアとを配置構成データとして計算する。
配置構成データ管理部１２は、配置先計算部１４の計算結果である配置構成データを管理する。
配置制御部１６は、リソースデータ管理部１３が管理する配置構成データに従って、配置先リソースおよび予備配置先リソースをＮＷ制御システム２３に制御させる。
【００３７】
ポリシデータ管理部１５は、配置先計算部１４の計算に用いられる各種ポリシ（エリア選択ポリシ、リソース確保ポリシ）を、ＮＷ管理システム２１を介して管理者から受け付けて保持する。エリア選択ポリシは図６で後記し、以下はリソース確保ポリシを説明する。
同じ予備配置先エリアに複数のＶＭの予備配置先リソースが確保されていた場合、予備配置先エリアに確保される予備配置先リソースの総量は、例えば、以下のリソース確保ポリシに従って計算される。例えば、同じ予備配置先エリアに、第１ＶＭ用の予備配置先リソース＝３Ｍ（[bps]の通信帯域）と、第２ＶＭ用の予備配置先リソース＝２Ｍとが確保されていたとする。
【００３８】
（１）リソース確保ポリシ＝「リソース効率優先」の場合、予備配置先リソースの総量＝max(3,2)＝３Ｍとする（関数maxは引数の最大値を返す）。これにより、同じ予備配置先エリア内に確保された予備配置先リソースのうち、いずれか１つのＶＭが故障しても、そのＶＭについて確実に復旧することができる。
【００３９】
（２）リソース確保ポリシ＝「耐障害性優先」の場合、予備配置先リソースの総量＝groupmax({3,2},1)+groupmax({3,2},2)＝５Ｍとする。関数groupmax(M,N)はＭ集合のうち、Ｎ番目に大きい数を抽出する。
これにより、甚大災害時などのＮ重故障が発生した場合でも、同じ予備配置先エリア内に予備配置先リソースを確保しておいたＮ個のＶＭを、同時に回復させることができる。なお、前記の「予備配置先リソースの総量」の式は、「予備配置先リソースの総量＝groupmax(M,1)+groupmax(M,2)+…+groupmax(M,N)」と一般化できる。
【００４０】
図５は、配置先計算部１４の処理を示す説明図である。前記したように、配置先計算部１４は、使用リソース要件を提供可能な配置先エリアと予備配置先エリアとを配置構成データとして計算する。このため、配置先計算部１４は、使用リソース要件を提供可能なエリアの集合を候補集合として抽出しておく。
例えば、提供可能リソース＝３ＭのエリアＡと、提供可能リソース＝２ＭのエリアＢと、提供可能リソース＝１０ＭのエリアＣとがリソースデータ管理部１３に登録されている。そして、配置対象受付部１１は、使用リソース要件＝２ＭのＶＭ１と、使用リソース要件＝５ＭのＶＭ２とを配置要求として受け付けたとする。
配置先計算部１４は、ＶＭ１については２Ｍ以上の提供可能リソースを有するエリアＡ，Ｂ，Ｃを候補集合とする。一方、配置先計算部１４は、ＶＭ２については５Ｍ以上の提供可能リソースを有するエリアＣだけを候補集合とする。このように、配置先計算部１４は、ＶＭやＶＮＦごとの使用リソース要件と、エリアごとの（またはエリア内の物理サーバごとの）提供可能リソースとを通信品質などのスペック情報でマッチングする。
【００４１】
図６は、配置構成データ管理部１２の一例を示すテーブルである。配置先計算部１４は、図５で説明したようにエリアの候補集合から、配置先エリアと予備配置先エリアとを選択した配置構成データを作成する。
ＶＭ１については３つのエリアＡ，Ｂ，Ｃをメンバとする候補集合から、配置先エリア＝エリアＡと、予備配置先エリア＝エリアＢとが選択されている。ＶＭ２については、４つのエリアＡ，Ｂ，Ｃをメンバとする候補集合から、配置先エリア＝エリアＡと、予備配置先エリア＝エリアＢ，Ｃとが選択されている。
なお、選択する予備配置先エリアの数は、管理者が指定した冗長度によって決定される。例えば、冗長度が２の場合には、２つのエリア（＝１つの配置先エリア＋１つの予備配置先エリア）とし、冗長度が３の場合には、３つのエリア（＝１つの配置先エリア＋２つの予備配置先エリア）とする。
また、ＶＭ４のように、そもそも候補集合のメンバが１つのエリアしか存在しないときには配置先エリアだけ決定する。
【００４２】
ここで、ポリシデータ管理部１５に格納される「エリア選択ポリシ」とは、候補集合からどのように配置先エリアや予備配置先エリアを選択するかを決定するためのポリシである。以下にエリア選択ポリシを例示する。
（ポリシ１）候補集合から提供可能リソースが最も少ない配置先エリアを選択し、その配置先エリアを除外して、提供可能リソースが少ない順に１つ以上の予備配置先エリアを選択する。これにより、特定のエリアにＶＭが集中して配置されるので、通常時には使用されない提供可能リソースを過剰に常時備えておくような非効率なリソース運用を減らすことができる。
（ポリシ２）予備配置先エリアと配置先エリアとを同じエリアとして選択する。つまり、配置先リソースの物理サーバと、予備配置先リソースの物理サーバとは同じエリアに属する。
（ポリシ３）予備配置先エリアと配置先エリアとを異なるエリアとして選択する。
（ポリシ４）他のＶＭがすでに稼働しているエリア（他のＶＭにとっての配置先エリア）と同じエリアを、今回の候補集合から予備配置先エリアとして選択する。
（ポリシ５）候補集合から消費電力が少ない提供可能リソースを有するエリアを優先的に選択する。
【００４３】
図７は、リソース管理システムの処理を示すシーケンス図である。
まず、Ｓ１１〜Ｓ１７では、１つめのＶＭ−Ａについての配置処理を説明する。
Ｓ１１において、配置対象受付部１１は、ＶＭ−Ａの配置要求をＮＷ管理システム２１から受け付ける。この配置要求には、配置対象であるＶＭ−Ａの使用リソース要件が「通信帯域を３Ｍ[bps]使用する」ことがＶＮＦカタログ内のパラメータとして記載されている。
なお、図７では、使用リソース要件の一例として通信帯域だけを用いたが、これは説明をわかりやすくするために簡素化しただけであり、使用リソース要件が通信帯域という１つのスペックだけに限定したものではない。ＮＷ収集システム２２が収集する提供可能リソースとして説明したように、使用リソース要件も、ＣＰＵのスペック、メモリのスペック、ネットワークのスペックを単体で、または、複数種類のスペックを組み合わせて表現される。
【００４４】
Ｓ１２〜Ｓ１４において、リソースデータ管理部１３は、Ｓ１１のＶＭ−Ａの配置先を探すために、ＮＷ収集システム２２を介して各エリアＡ〜Ｃのサーバに対して提供可能リソースを要求する。
各サーバは、自身の提供可能リソース（現時点でのスペックの測定結果など）をリソースデータ管理部１３に応答する。ここでは、エリアＡの提供可能リソースが１０Ｍ（Ｓ１２）、エリアＢの提供可能リソースが５Ｍ（Ｓ１３）、エリアＣの提供可能リソースが１Ｍ（Ｓ１４）であったとする。
【００４５】
Ｓ１５において、配置先計算部１４は、Ｓ１２〜Ｓ１４で応答された各提供可能リソースが、ＶＭ−Ａの（Ｓ１１の）使用リソース要件を満たしているか否かを判定する。ここでは、３Ｍ以上のリソースを有するエリアＡ，Ｂは使用リソース要件を満たし、エリアＣは使用リソース要件を満たさないと判断された。
そして、配置先計算部１４は、ＶＭ−Ａの候補集合から、提供可能リソースが１番少ない配置先エリア＝エリアＢと、提供可能リソースが２番目に少ない予備配置先エリア＝エリアＡとを選択する旨の配置構成データを作成する。
Ｓ１６において、配置制御部１６は、配置構成データに従って、配置先リソース＝３Ｍ分を使用するＶＭ−ＡをエリアＢに配置し（Ｓ１６）、ＶＭ−Ａの予備配置先リソース＝３Ｍ分をエリアＡに確保する。
【００４６】
次に、Ｓ２１〜Ｓ２７では、２つめのＶＭ−Ｂについての配置処理を説明する。
Ｓ２１において、配置対象受付部１１は、ＶＭ−Ｂの配置要求をＮＷ管理システム２１から受け付ける。この配置要求には、配置対象であるＶＭ−Ｂの使用リソース要件が「通信帯域を１Ｍ[bps]使用する」ことがＶＮＦカタログ内のパラメータとして記載されている。
【００４７】
Ｓ２２〜Ｓ２４において、リソースデータ管理部１３は、Ｓ２１のＶＭ−Ｂの配置先を探すために、ＮＷ収集システム２２を介して各エリアＡ〜Ｃのサーバに対して提供可能リソースを要求する。各サーバは、自身の提供可能リソースをリソースデータ管理部１３に応答する。
エリアＡの提供可能リソースは、Ｓ１２では１０Ｍであったが、Ｓ１７で確保された予備配置先リソース＝３Ｍ分だけ減少した結果、Ｓ２２では７Ｍとして応答される。
エリアＢの提供可能リソースは、Ｓ１３では５Ｍであったが、Ｓ１６で使用された配置先リソース＝３Ｍ分だけ減少した結果、Ｓ２３では２Ｍとして応答される。
エリアＣの提供可能リソースは、Ｓ１４と同様に、Ｓ２４でも１Ｍとして応答される。
【００４８】
Ｓ２５において、配置先計算部１４は、Ｓ２２〜Ｓ２４で応答された各提供可能リソースが、ＶＭ−Ｂの（Ｓ２１の）使用リソース要件を満たしているか否かを判定する。ここでは、１Ｍ以上のリソースを有するすべてのエリアＡ，Ｂ，Ｃが使用リソース要件を満たす。
そして、配置先計算部１４は、ＶＭ−Ｂの候補集合から、提供可能リソースが１番少ない配置先エリア＝エリアＣと、提供可能リソースが２番目に少ない予備配置先エリア＝エリアＢとを選択する旨の配置構成データを作成する。
配置制御部１６は、この配置構成データに従って、エリアＣの配置先リソースにＶＭ−Ｂを配置し（Ｓ２６）、エリアＢにＶＭ−Ｂの予備配置先リソースを確保する（Ｓ２７）。
【００４９】
ここで、エリアＢのサーバに故障が発生したとする（Ｓ３０）。この故障によりエリアＢでの以降のＶＭの稼働が困難となる。そこで、エリアＢのサーバは、自身で稼働させていたＶＭを他のエリアに退避（再配置）させる。Ｓ１６で配置されたＶＭ−Ａが該当するので、エリアＢのサーバは、配置制御部１６からの制御指示に従い、Ｓ１７で確保された予備配置先エリア＝エリアＡの予備配置先リソースであるサーバに、ＶＭ−Ａを再配置する（Ｓ３１）。
【００５０】
このように、あらかじめＶＭごとに配置先リソースと予備配置先リソースとの組み合わせが対応づけられて用意されており、使用リソース要件を満たす予備配置先エリアが故障発生前にあらかじめ確保されている。これにより、配置先リソースで故障が発生したＶＭは、予備配置先リソースへの再配置が迅速に実行されるので、ＳＬＡに定義された故障回復時間を満たすことができる。
つまり、現状の設備リソース利用状況から最適配置構成にするまでのＶＭの再配置処理を事前に準備しておくことで、故障後の復旧にかかる時間を削減でき、故障によるサービス遮断時間を短縮できる。
【００５１】
ところで、Ｓ３２では、故障したエリアＢのサーバ上にＶＭ−Ｂの予備配置先リソースが存在していた場合である。この場合、ＶＭ−Ｂは現時点ではエリアＣの配置先リソースで稼働しており（Ｓ２６）、エリアＢの故障の直接の被害は受けていない。しかし、将来的にエリアＣでも故障が発生したときには、ＶＭ−Ｂの予備配置先リソースが存在しないことになる。
よって、Ｓ３２のような場合では、配置先計算部１４は、配置構成データを再計算した結果としてＶＭ−Ｂの新たな予備配置先エリア＝エリアＡを求め、故障したエリアＢの予備配置先リソースを、稼働中のエリアＡの予備配置先リソースへと変更することが望ましい。
【００５２】
以上説明した本実施形態では、配置先計算部１４は、使用リソース要件を提供可能なエリアの集合を候補集合として抽出しておく（図５）。そして、配置先計算部１４は、候補集合のエリアから、配置先エリアと予備配置先エリアとを組み合わせて選択する（図６）。
これにより、配置先リソースが故障した場合でも、使用リソース要件を満たす別の予備配置先リソースがすでに用意されているので、迅速にＶＭやＶＮＦを再配置することで、サービスの中断時間を短縮化できる。
【００５３】
前記の実施形態では、リソース提供システム２４の「エリア」に着目して、配置先計算部１４が作成する配置構成データ（配置先エリアと予備配置先エリア）について説明した。以下では、他の実施形態として、リソース提供システム２４が提供する個々の「サーバ」に着目して、配置先計算部１４が作成する配置構成データについて説明する。この説明では、以下のように読み替える。
・「エリアの候補集合」を「サーバの候補集合」に読み替える。サーバの候補集合とは、配置対象受付部１１が受け付けた配置対象の仮想機能部の使用リソース要件を満たす、リソース提供システム２４のサーバの集合である。
・「配置先エリア」を「配置先サーバ」に読み替える。配置先サーバとは、配置先計算部１４が作成する配置構成データにおいて、配置対象の仮想機能部の配置先となるサーバである。
・「予備配置先エリア」を「予備配置先サーバ」に読み替える。予備配置先サーバとは、配置先計算部１４が作成する配置構成データにおいて、配置先サーバの故障時において再配置先となるサーバである。
【００５４】
例えば、図７のＳ１１〜Ｓ１７の各処理は、前記の読み替えにより、以下のように置き換わる。
Ｓ１１において、配置対象受付部１１は、使用リソース要件が規定された配置対象の仮想機能部を、配置要求として受け付ける。
Ｓ１２〜Ｓ１４において、リソースデータ管理部１３は、Ｓ１１で受け付けた仮想機能部の配置先を探すために、ＮＷ収集システム２２を介してリソース提供システム２４の各サーバに対して提供可能リソースを要求する。
Ｓ１５において、配置先計算部１４は、Ｓ１２〜Ｓ１４で応答された各サーバの提供可能リソースが、Ｓ１１の使用リソース要件を満たすようなサーバの集合を、候補集合として抽出する。
そして、配置先計算部１４は、抽出されたサーバの候補集合から、例えば、提供可能リソースが１番少ない配置先サーバと、提供可能リソースが２番目に少ない予備配置先サーバとを選択する旨の配置構成データを作成する。
配置制御部１６は、Ｓ１１で受け付けた仮想機能部をＳ１５の配置先サーバの配置先リソースに配置し（Ｓ１６）、その予備配置先リソースをＳ１５の予備配置先サーバに確保する（Ｓ１７）。
【００５５】
以下では、比較例として、物理層の実装としてホットスペアによる冗長化技術を例示する。中断時間を最小化するという観点では、ホットスペアも同等の効果を得ることができる。しかし、サービス中断時間のＳＬＡに合わせてホットスペアのための予備設備を構築するには、設備の導入費用や維持費用などのコストがかかってしまう。なお、物理マシン上の仮想マシンに対してホットスペアを用意するのは、その物理マシン１台を対象とするだけで済む。しかし、物理ネットワーク上の仮想ネットワーク機能に対しては、エンドツーエンドで広範囲にホットスペアを用意することとなり、大きなコストがかかる。
【００５６】
図８は、各エリアに割り当てられているＶＭを示す説明図である。エリアＸには、現時点ではどのＶＭも割り当てられておらず、ホットスペアとして用意されている。
図９は、図８の状態からＶＭ上のリソースに故障が発生したときの説明図である。エリアＢ内のＶＭ３に故障が発生したとする（×印）。そこで、エリアＸにＶＭ３を再配置しようとする。
図１０は、図９の状態から再配置先としたエリアＸが利用不可能である状況を示す説明図である。エリアＸ内にホットスペアとして用意していた物理サーバが実は壊れていたということも起こりうる。なぜなら、ホットスペアでは通常時には動作を行わないため、休眠状態が長くなってしまい、稼働チェックが疎かになることもあるためである。
【００５７】
一方、本実施形態においては、図７のＳ１２〜Ｓ１４などでＮＷ収集システム２２が実際に提供可能リソースを収集することで、予備配置先リソースの稼働状況も随時チェックされる。これにより、動作可能な予備配置先リソースを用意できる。
さらに、本実施形態のサービス管理装置１では、図３に示したように、使用リソース要件の変更にも柔軟に対応可能である。一方で、ホットスペアではハードウェアリソースとして冗長化を行うため、使用リソース要件の変更が発生したときには、冗長化構成を再構築するために大きなコストがかかってしまう。
【００５８】
なお、本実施形態においては、本発明に係る配置構成データとして、図１に示す４つのＶＭと、４つのエリアとで説明したが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービス管理装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
【符号の説明】
【００５９】
１      サービス管理装置（配置構成装置）
１１    配置対象受付部
１２    配置構成データ管理部
１３    リソースデータ管理部
１４    配置先計算部
１５    ポリシデータ管理部
１６    配置制御部
２１    ＮＷ管理システム
２２    ＮＷ収集システム
２３    ＮＷ制御システム
２４    リソース提供システム
【図１】
2019139533.tif 000003
【図２】
2019139533.tif 000004
【図３】
2019139533.tif 000005
【図４】
2019139533.tif 000006
【図５】
2019139533.tif 000007
【図６】
2019139533.tif 000008
【図７】
2019139533.tif 000009
【図８】
2019139533.tif 000010
【図９】
2019139533.tif 000011
【図１０】
2019139533.tif 000012
【図１１】
2019139533.tif 000013
【図１２】
2019139533.tif 000014
【図１３】
2019139533.tif 000015
【図１４】
2019139533.tif 000016
【図１５】
2019139533.tif 000017
【図１６】
2019139533.tif 000018