JP2017199155A - コンピュートリソース管理システムおよびコンピュートリソース管理方法 - Google Patents

Abstract

【課題】激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性を確保する。【解決手段】コンピュートリソース管理システムＳは、サービスが動作可能なリソースをそれぞれ備える複数のエリア３を管理する。リソースは、激甚災害時に他のエリア３へのサービスの移動を要する激甚対応有り使用中リソース３２と空きリソース３１とを含む。コンピュートリソース管理システムＳは、複数のエリア３のうち一つのエリア３が有する空きリソース３１にサービスを増設した場合における複数のエリア３のうち激甚対応有り使用中リソース３２を最も多く含むエリア３と、このエリア３に含まれる激甚対応有り使用中リソース３２の数とを特定し、激甚対応有り使用中リソース３２の数以上の空きリソース３１を有する他のエリア３の数が２以上ならば、サービスを増設可能と判断する増設判断部１１を備える。【選択図】図１

Description

本発明は、コンピュートリソースの管理を行うコンピュートリソース管理システムおよびコンピュートリソース管理方法に関する。

近年のキャリアサービスや金融サービスなどでは、激甚災害時にもサービスの継続が可能な高い品質が求められている。そのため、複数のエリアに複数のコンピュートリソースを分散して配置することが行われている。ここでコンピュートリソースとは、ＣＰＵ（Central Processing Unit）、メモリ等から構成される情報処理能力を有する物理装置や、これら物理装置上に構築された仮想装置などであり、各種サービスを動作可能である。以下、コンピュートリソースを単に「リソース」と記載する。このリソースは、サービスの動作有無や特性により「空きリソース」と、「激甚対応有り使用中リソース」と、「激甚対応無し使用中リソース」とに大別される。

空きリソースとは、サービスが動作していないリソースのことをいう。激甚対応有り使用中リソースは、サービスが動作しており、かつ、このサービスを激甚災害時に救済する必要があるリソースのことをいう。激甚対応無し使用中リソースは、サービスが動作しており、かつ、このサービスを激甚災害時に救済する必要がないリソースのことをいう。サービス提供事業者は、各使用中リソースで動作するサービスを激甚災害時に救済する必要があるか否か、予め決定する。
激甚災害等で１箇所のエリアのリソースが全て使用不可となった場合、このエリアの使用中リソースで動作していたサービスを、他のエリアの空きリソースに移動させることで、この使用中リソースで動作していたサービスを救済することが行われている。これにより、激甚災害時にもサービスの継続が可能となる。なお、移動先のエリアは運用上の制約等により１箇所のエリアとする。これは、１つのエリアの複数の使用中リソースで動作していたサービスを、複数のエリアの空きリソースに分散して設定し、ネットワークを設定すると、復旧時間が容認できないほど大きくなってしまうためである。

このような複数のリソースを連携する技術としてはOpenStackがある。OpenStackとは、多数のサーバコンピュータを一体的に運用して情報インフラを構築することができるソフトウェアである。OpenStackによれば、自社システムを運用するためのプライベートクラウドを構築し、またはパブリッククラウドを構築して顧客にクラウドサービスを提供することができる。

非特許文献１には、OpenStackのフィルタについて記載されている。フィルタのスケジューラは、新しいインスタンスが作成される場所での情報に基づいた意思決定を行うために、フィルタリングと重み付けをサポートする。
非特許文献２には、OpenStackにて計算ホストを予約する発明が記載されている。

"Filter Scheduler",[online],OpenStack Foundation,[平成２８年４月５日検索],<URL:http://docs.openstack.org/developer/nova/filter_scheduler.html> "Blazer",[online],Wikipedia,[平成２８年４月５日検索],<URL:https://wiki.openstack.org/wiki/Blazar>

サービス増設等のために新たに空きリソースを使用する場合、OpenStack等の既存技術では、激甚災害時に必要なリソースが考慮されない。そのため激甚発生時に備えたリソースが確保できなくなるおそれがある。
また、サービス増設等のために新たに空きリソースを使用する場合、激甚災害への対応の有無によってリソースの使用可否が異なる。そのため、「激甚発生時のリソースを確保」を最小限にするためには、サービス特性である激甚対応の有無を考慮に入れた使用可否判断を行う必要がある。
そこで、本発明は、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性を持たせることが可能なコンピュートリソース管理システムおよびコンピュートリソース管理方法を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明では、サービスが動作可能なリソースをそれぞれ備える複数のエリアを管理するコンピュートリソース管理システムであって、前記リソースは、激甚災害によるサービスの停止時に当該サービスの他のエリアへの移動を要する要救済リソースと、サービスが動作していない空きリソースとを含み、前記複数のエリアのうち一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定し、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が２以上ならば、前記一つのエリアが有する空きリソースにサービスを増設可能と判断する判断手段、を備えることを特徴とするコンピュートリソース管理システムとした。

このようにすることで、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性を持たせることができる。

請求項２に記載の発明では、前記判断手段は、前記複数のエリアのうち前記一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定し、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が１かつ当該他のエリアが含む要救済リソースの数以上の空きリソースを有するエリアが存在したとき、前記一つのエリアが有する空きリソースにサービスを増設可能と判断する、ことを特徴とする請求項１に記載のコンピュートリソース管理システムとした。

このようにすることで、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性とリソースの有効活用を両立するができる。

請求項３に記載の発明では、前記判断手段は、前記複数のエリアのうち空きリソースを含まないエリアが有ったならば、前記一つのエリアが有する空きリソースにサービスを増設不能と判断する、ことを特徴とする請求項１または２に記載のコンピュートリソース管理システムとした。

このようにすることで、各エリアに空きリソースを確保して故障時の予備とすることができる。

請求項４に記載の発明では、前記複数のエリアそれぞれが有する前記要救済リソースの数、および前記複数のエリアそれぞれが有する前記空きリソースの数を格納する記憶手段、を備えることを特徴とする請求項１ないし３のいずれか１項に記載のコンピュートリソース管理システムとした。

このようにすることで、システム間の通信を抑制しつつ短時間にサービスの増設可否を判断することができる。

請求項５に記載の発明では、前記判断手段が前記一つのエリアが有する空きリソースにサービスを増設可能と判断したならば、当該一つのエリアが有する空きリソースにサービスを増設する増設手段、を備えることを特徴とする請求項１ないし４のいずれか１項に記載のコンピュートリソース管理システムとした。

このようにすることで、実際にサービスを増設することができる。

請求項６に記載の発明では、前記増設手段により空きリソースにサービスが増設される複数のエリア、を備えることを特徴とする請求項５に記載のコンピュートリソース管理システムとした。

このようにすることで、増設したサービスを顧客に提供可能となる。

請求項７に記載の発明では、サービスが動作していない空きリソース、およびサービスが動作中のリソースであり、激甚災害によるサービスの停止時に当該サービスの他のエリアへの移動を要する要救済リソースをそれぞれ備える複数のエリアを管理するコンピュートリソース管理方法であって、前記複数のエリアのうち一つのエリアが有する空きリソースにサービスの増設指示を受け付けるステップと、前記一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定するステップと、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が２以上ならば、前記一つのエリアが有する空きリソースにサービスを増設可能と判断するステップと、を含むことを特徴とするコンピュートリソース管理方法とした。

このようにすることで、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性を持たせることができる。

請求項８に記載の発明では、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が１かつ当該他のエリアが含む要救済リソースの数以上の空きリソースを有するエリアが存在したとき、前記一つのエリアが有する空きリソースにサービスを増設可能と判断するステップ、を含むことを特徴とする請求項７に記載のコンピュートリソース管理方法とした。

このようにすることで、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性とリソースの有効活用を両立するができる。

本発明によれば、激甚災害発生時の対応に必要なリソースを適切に確保し、激甚災害時のサービス継続性を持たせることが可能となる。

本実施形態におけるコンピュートリソース管理システムの構成図である。 本実施形態におけるリソース増設処理を示すフローチャートである。 更新前と更新後の各エリアを説明する図である。 比較例のコンピュートリソース管理システムの構成図である。 比較例のリソース増設処理を示すフローチャートである。 激甚災害時のリソース移動処理を示すフローチャートである。 災害発生前の各エリアの状態と、災害発生後にリソースを移動した各エリアの状態とを説明する図である。 災害発生前後の各エリアの状態を説明する図である。

以降、比較例について各図を参照して詳細に説明したのち、本発明を実施するための形態を説明する。

《比較例》
図４は、比較例のコンピュートリソース管理システムＳａの構成図である。
比較例のコンピュートリソース管理システムＳａは、コンピュートリソース管理装置１Ａと、これに指示を行う保守者端末２と、管理対象であるエリア＃１（３ａ）、エリア＃２（３ｂ）、エリア＃３（３ｃ）を含んで構成される。以下、エリア＃１（３ａ）、エリア＃２（３ｂ）、エリア＃３（３ｃ）を特に区別しないときは、単にエリア３と記載する場合がある。コンピュートリソース管理システムＳａは、例えば電話システムであるが、これに限られない。

コンピュートリソース管理装置１Ａは、例えばＣＰＵとメモリ等から構成された装置であり、このＣＰＵが不図示のコンピュートリソース管理プログラムを実行することにより、コンピュートリソース操作部１２が具現化される。コンピュートリソース操作部１２は、各エリア３のコンピュートリソースに対して増設／減設／移動などを指示するものである。このコンピュートリソース操作部１２の処理の一部を、後記する図５で説明する。

コンピュートリソース情報１３は、各エリア３が有するリソース情報をそれぞれ格納する記憶手段である。コンピュートリソース情報１３については、後記する図７と図８で詳細に説明する。

エリア３は、サービスが動作可能なコンピュートリソースの集合であり、かつ激甚災害時において同時にコンピュートリソースの集合が使用不可となる範囲のことをいう。以下、コンピュートリソースのことを単にリソースという。リソースは、空きリソース３１と、激甚対応有り使用中リソース３２と、激甚対応無し使用中リソース３３とに分けることができる。
空きリソース３１は、サービスが動作していないリソースのことをいう。激甚対応有り使用中リソース３２は、サービスが動作しているリソースであり、かつ、このサービスを激甚災害時に救済する必要があるもの（要救済リソース）をいう。激甚対応無し使用中リソース３３は、サービスが動作しているリソースであり、かつ、このサービスを激甚災害時に救済する必要が無いものをいう。

図４にてエリア＃１（３ａ）は、４個の空きリソース３１と、１個の激甚対応有り使用中リソース３２と、１個の激甚対応無し使用中リソース３３とを含んでいる。エリア＃２（３ｂ）は、２個の空きリソース３１と、４個の激甚対応有り使用中リソース３２と、１個の激甚対応無し使用中リソース３３とを含んでいる。エリア＃３（３ｃ）は、３個の空きリソース３１と、１個の激甚対応有り使用中リソース３２と、２個の激甚対応無し使用中リソース３３とを含んでいる。

図５は、比較例のリソース増設処理を示すフローチャートである。
コンピュートリソース操作部１２は、例えば保守者端末２からリソースの増設指示を受けると、一連のリソース増設処理を開始する。
最初、コンピュートリソース操作部１２は、各エリア３に対して増設指示を行い（ステップＳ２０）、増設指示結果をコンピュートリソース情報１３にも反映させて（ステップＳ２１）、図５の処理を終了する。

図６は、激甚災害時のリソース移動処理を示すフローチャートである。
激甚災害等で１箇所のエリア３のリソースが全て使用不可となった場合は、他のエリア３の空きリソース３１上でサービスを移動させて動作させる。具体的にいうと、コンピュートリソース操作部１２は、激甚災害等を受けた１箇所のエリア３と、そのエリア３が有する激甚対応有り使用中リソース３２の数とを特定する（ステップＳ３０）。そして、コンピュートリソース操作部１２は、特定した数以上の空きリソース３１を有する他のエリア３の数を判定する（ステップＳ３１）。

コンピュートリソース操作部１２は、他のエリア３の数が１以上ならば（ステップＳ３１：１以上）、他のエリア３のうち１つを選択して、激甚災害等を受けたエリア３が有する激甚対応有り使用中リソース３２で動作していたサービスを移動させる（ステップＳ３２）。これにより、激甚災害時であっても激甚対応有り使用中リソース３２で動作していたサービスを救済して継続させることができる。

図７（ａ）〜（ｃ）は、災害発生前の各エリア３の状態と、災害発生後にリソースを移動した各エリア３の状態とを説明する図である。図７（ａ）〜（ｃ）は、コンピュートリソース情報１３を示している。
図７（ａ）は、災害発生前の各エリア３の状態を示しており、図４に示したものと同一である。

図７（ｂ）は、エリア＃２（３ｂ）にて災害発生後の、各エリア３の状態を示している。
エリア＃２（３ｂ）は、激甚災害の発生により空きリソース３１と、激甚対応有り使用中リソース３２と、激甚対応無し使用中リソース３３とが全て０個に変化する。エリア＃２（３ｂ）の４個の激甚対応有り使用中リソース３２で動作していたサービスは、エリア＃１（３ａ）に移動する。
これにより、エリア＃１（３ａ）の空きリソース３１は４個から０個に、激甚対応有り使用中リソース３２は１個から５個に変化する。これ以外は、図７（ａ）に示した状態と同様である。
なお、エリア＃３（３ｃ）も、図７（ａ）と同様に、３個の空きリソース３１と、１個の激甚対応有り使用中リソース３２と、２個の激甚対応無し使用中リソース３３とを含んでいる。

図７（ｃ）は、図７（ａ）に示した災害発生前の状態からエリア＃１（３ａ）にて災害発生した後の、各エリア３の状態を示している。
エリア＃１（３ａ）は、激甚災害の発生により空きリソース３１と、激甚対応有り使用中リソース３２と、激甚対応無し使用中リソース３３とが全て０個に変化する。エリア＃１（３ａ）の１個の激甚対応有り使用中リソース３２は、エリア＃３（３ｃ）に移動する。
エリア＃３（３ｃ）の空きリソース３１は３個から２個に、激甚対応有り使用中リソース３２は１個から２個に変化する。エリア＃１（３ａ）は更に、２個の激甚対応無し使用中リソース３３を有する。
なお、エリア＃２（３ｂ）は、図７（ａ）と同様に、２個の空きリソース３１と、４個の激甚対応有り使用中リソース３２と、１個の激甚対応無し使用中リソース３３とを含んでいる。

図８（ａ），（ｂ）は、災害発生前後の各エリア３の状態を説明する図である。図８（ａ），（ｂ）は、コンピュートリソース情報１３を示している。
図８（ａ）は、災害発生前の各エリア３の状態を示している。
エリア＃１（３ａ）は、図７（ａ）とは異なり、２個の空きリソース３１と、１個の激甚対応有り使用中リソース３２と、３個の激甚対応無し使用中リソース３３とを含んでいる。つまり、図７（ａ）で示した状態において、２個の激甚対応無し使用中リソース３３が増設されると、図８（ａ）で示した状態となる。
エリア＃２（３ｂ）は、図７（ａ）と同様に、２個の空きリソース３１と、４個の激甚対応有り使用中リソース３２と、１個の激甚対応無し使用中リソース３３とを含んでいる。エリア＃３（３ｃ）は、３個の空きリソース３１と、１個の激甚対応有り使用中リソース３２と、２個の激甚対応無し使用中リソース３３とを含んでいる。

図８（ｂ）は、エリア＃２（３ｂ）にて災害発生後の、各エリア３の状態を示している。
エリア＃２（３ｂ）は、激甚災害の発生により空きリソース３１と、激甚対応有り使用中リソース３２と、激甚対応無し使用中リソース３３とが全て０個に変化する。しかし、エリア＃２（３ｂ）の４個の激甚対応有り使用中リソース３２で動作していたサービスは、エリア＃１（３ａ）にもエリア＃３（３ｃ）のいずれにも移動することができない。よってエリア＃２（３ｂ）の４個の激甚対応有り使用中リソース３２で動作していたサービスは中断してしまう。
このように比較例では、サービスの増設を行った結果、激甚災害の発生時にサービスを救済できずに中断する事象が発生する。

《本実施形態》
図１は、本実施形態におけるコンピュートリソース管理システムＳの構成図である。
本実施形態のコンピュートリソース管理システムＳは、コンピュートリソース管理装置１と、これに指示を行う保守者端末２と、管理対象であるエリア＃１（３ａ）、エリア＃２（３ｂ）、エリア＃３（３ｃ）を含んで構成される。

コンピュートリソース管理装置１は、例えばＣＰＵとメモリ等から構成された装置であり、このＣＰＵが不図示のコンピュートリソース管理プログラムを実行することにより、増設判断部１１とコンピュートリソース操作部１２とが具現化される。増設判断部１１は、各エリア３のリソースに対する増設の可否を判断するものである。コンピュートリソース操作部１２は、各エリア３のリソースに対して増設／減設／移動などを指示するものである。この増設判断部１１とコンピュートリソース操作部１２の処理の一部を、後記する図２で説明する。

コンピュートリソース情報１３は、各エリア３が有するリソース情報をそれぞれ格納する記憶手段である。このコンピュートリソース情報１３により、増設判断部１１は、各エリア３が有するリソースに問い合わせることなく、各リソースの状態を知ることができる。コンピュートリソース情報１３については、後記する図３で詳細に説明する。

エリア３は、比較例と同様に、サービスが動作可能なコンピュートリソースの集合であり、かつ激甚災害時において同時にリソースの集合が使用不可となる範囲のことをいう。リソースが空きリソース３１と、激甚対応有り使用中リソース３２と、激甚対応無し使用中リソース３３とに分けられるのも、比較例と同様である。
空きリソース３１は、サービスが動作していないリソースのことをいう。激甚対応有り使用中リソース３２は、サービスが動作しているリソースであり、かつ、このサービスを激甚災害時に救済する必要があるもの（要救済リソース）をいう。激甚対応無し使用中リソース３３は、サービスが動作しているリソースであり、かつ、このサービスを激甚災害時に救済する必要が無いものをいう。

図２は、本実施形態におけるリソース増設処理を示すフローチャートである。
増設判断部１１とコンピュートリソース操作部１２は、例えば保守者端末２からリソースの増設指示を受けると、一連のリソース増設処理を開始する。
最初、増設判断部１１は、不図示のＲＡＭ（Random Access Memory）等の作業領域にコンピュートリソース情報１３のデータをコピーし（ステップＳ１０）、増設指示の内容をこの作業領域に反映する（ステップＳ１１）。次いで増設判断部１１は、空きリソース３１が無いエリア３の数を判定する（ステップＳ１２）。増設判断部１１は、空きリソース３１が無いエリア３の数が１以上ならば（ステップＳ１２：１以上）、保守者端末２にエラーを応答して（ステップＳ１８）、図２の処理を終了する。これにより増設判断部１１は、各エリア３が空きリソース３１を有さない状態を防ぐことができる。これにより、各エリア３が有する激甚対応有り使用中リソース３２および激甚対応無し使用中リソース３３のうち何れか１個が故障等で停止しても、このリソースで動作していたサービスを空きリソース３１で救済可能である。

増設判断部１１は、空きリソース３１が無いエリア３の数が０ならば（ステップＳ１２：０）、激甚対応有り使用中リソース３２の数が最大となるエリア３と、その数とを特定する（ステップＳ１３）。

更に増設判断部１１は、特定した激甚対応有り使用中リソース３２の数以上の空きリソース３１を有する他のエリア３の数を判定する（ステップＳ１４）。増設判断部１１は、他のエリア３の数が０ならば、保守者端末２にエラーを応答して（ステップＳ１８）、図２の処理を終了する。増設判断部１１は、他のエリア３の数が２以上ならば（ステップＳ１４：２以上）、そのいずれかに対してコンピュートリソース操作部１２に増設指示を行わせる（ステップＳ１７）。

増設判断部１１は、他のエリア３の数が１ならば（ステップＳ１４：１）、空きリソース３１が最大となるエリア３と、そのエリア３の激甚対応有り使用中リソース３２の数とを特定する（ステップＳ１５）。更に増設判断部１１は、特定した激甚対応有り使用中リソース３２の数以上の空きリソース３１を有するその他のエリア３の数を判定する（ステップＳ１６）。増設判断部１１は、その他のエリア３の数が０ならば、保守者端末２にエラーを応答して（ステップＳ１８）図２の処理を終了し、その他のエリア３の数が１以上ならば、コンピュートリソース操作部１２に増設指示を行わせる（ステップＳ１７）。
ステップＳ１７の増設指示の後、増設判断部１１は、作業領域に反映した増設指示結果をコンピュートリソース情報１３にも反映させて（ステップＳ１９）、図２の処理を終了する。

図３（ａ），（ｂ）は、更新前と更新後の各エリア３を説明する図である。図３（ａ），（ｂ）は、コンピュートリソース情報１３が反映された作業領域を示している。以下の説明にて、適宜図１と図２を参照する。
図３（ａ）は、更新前の各エリア３の例を示しており、前記した図１の状態と同様である。
仮に、図２のステップＳ１１にて増設指示内容を反映された作業領域が、図３（ａ）に示した状態であるとして、図２のステップＳ１２以降の増設判断処理を行う。するとステップＳ１３にて激甚対応有り使用中リソース３２の数が最大となるエリア＃２（３ｂ）が特定され、その激甚対応有り使用中リソース３２の数が４個として特定される。その後ステップＳ１４にて、４個の激甚対応有り使用中リソース３２を移動するため、４個以上の空きリソース３１を有するエリア３がエリア＃１（３ａ）として特定され、これに適合するエリア３は１個である。

次いで増設判断部１１は、空きリソース３１が最大となるエリア３をエリア＃１（３ａ）として特定し、このエリア＃１（３ａ）の激甚対応有り使用中リソース３２の数を１個と特定する（ステップＳ１５）。増設判断部１１は、１個以上の空きリソース３１を有する他のエリア３の数を２個と判定するので、コンピュートリソース操作部１２が増設指示を行うことができる（ステップＳ１７）。

このとき、エリア＃１（３ａ）、エリア＃２（３ｂ）、エリア＃３（３ｃ）のいずれか１つが激甚災害によって停止しても、停止したエリア３が有する激甚対応有り使用中リソース３２で動作していたサービスを、他のエリア３の空きリソース３１に移動可能である。

図３（ｂ）は、更新後の各エリア３の例を示している。ステップＳ１１にて、増設指示内容を反映された作業領域が、図３（ｂ）に示した状態となる。
ここでは、エリア＃１（３ａ）に２個の激甚対応無し使用中リソース３３が増設されたので、激甚対応無し使用中リソース３３の数は３となり、空きリソース３１の数は２となる。この作業領域に対して図２のステップＳ１２以降の増設判断処理を行うと、ステップＳ１３にて激甚対応有り使用中リソース３２の数が最大となるエリア＃２（３ｂ）が特定され、その激甚対応有り使用中リソース３２の数が４個として特定される。しかし、ステップＳ１４にて、４個以上の空きリソース３１を有するエリア３を特定しようとするが、これに適合するエリア３は存在せず、０個である。よって増設判断部１１は、保守者端末２にエラーを応答する（ステップＳ１８）。

ステップＳ１８の後に処理を終了するので、各エリア３の実際の状態は、図３（ａ）に示した更新前のままである。このとき、エリア＃１（３ａ）、エリア＃２（３ｂ）、エリア＃３（３ｃ）のいずれか１つが激甚災害によって停止しても、停止したエリア３が有する激甚対応有り使用中リソース３２で動作していたサービスを、他のエリア３の空きリソース３１に移動可能である。
このようにして本実施形態では、激甚災害の発生時にサービスを救済できるか否かを判断した後にサービス増設を行う。よって激甚災害発生時の対応に必要なリソースを必要最小限確保し、激甚災害時のサービス継続性とリソースの有効活用を両立することができる。

（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｄ）のようなものがある。
（ａ） リソースの数は３個に限られない。
（ｂ） 各フローチャートは例であり、各ステップ中に他のステップが挿入されていてもよく、限定されない。
（ｃ） 各リソースは物理装置であってもよく、また物理装置上に構成された仮想マシンであってもよい。
（ｄ） 増設判断部１１がリソースの増設指示を受けるのは、保守者端末２による指示に限られず、例えばZabbixやCeliometerなどが実行されている監視装置による指示であってもよく、限定されない。

Ｓ，Ｓａ コンピュートリソース管理システム
１，１Ａ コンピュートリソース管理装置
１１ 増設判断部 （判断手段）
１２ コンピュートリソース操作部 （増設手段）
１３ コンピュートリソース情報 （記憶手段）
２ 保守者端末
３ａ エリア＃１
３ｂ エリア＃２
３ｃ エリア＃３
３１ 空きリソース
３２ 激甚対応有り使用中リソース （要救済リソース）
３３ 激甚対応無し使用中リソース

Claims (8)

1. サービスが動作可能なリソースをそれぞれ備える複数のエリアを管理するコンピュートリソース管理システムであって、
   前記リソースは、激甚災害によるサービスの停止時に当該サービスの他のエリアへの移動を要する要救済リソースと、サービスが動作していない空きリソースとを含み、
   前記複数のエリアのうち一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定し、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が２以上ならば、前記一つのエリアが有する空きリソースにサービスを増設可能と判断する判断手段、
   を備えることを特徴とするコンピュートリソース管理システム。
2. 前記判断手段は、
   前記複数のエリアのうち前記一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定し、前記要救済リソースの数以上の空きリソースを有する他のエリアの数が１かつ当該他のエリアが含む要救済リソースの数以上の空きリソースを有するエリアが存在したとき、前記一つのエリアが有する空きリソースにサービスを増設可能と判断する、
   ことを特徴とする請求項１に記載のコンピュートリソース管理システム。
3. 前記判断手段は、
   前記複数のエリアのうち空きリソースを含まないエリアが有ったならば、前記一つのエリアが有する空きリソースにサービスを増設不能と判断する、
   ことを特徴とする請求項１または２に記載のコンピュートリソース管理システム。
4. 前記複数のエリアそれぞれが有する前記要救済リソースの数、および前記複数のエリアそれぞれが有する前記空きリソースの数を格納する記憶手段、
   を備えることを特徴とする請求項１ないし３のいずれか１項に記載のコンピュートリソース管理システム。
5. 前記判断手段が前記一つのエリアが有する空きリソースにサービスを増設可能と判断したならば、当該一つのエリアが有する空きリソースにサービスを増設する増設手段、
   を備えることを特徴とする請求項１ないし４のいずれか１項に記載のコンピュートリソース管理システム。
6. 前記増設手段により空きリソースにサービスが増設される複数のエリア、
   を備えることを特徴とする請求項５に記載のコンピュートリソース管理システム。
7. サービスが動作していない空きリソース、およびサービスが動作中のリソースであり、激甚災害によるサービスの停止時に当該サービスの他のエリアへの移動を要する要救済リソースをそれぞれ備える複数のエリアを管理するコンピュートリソース管理方法であって、
   前記複数のエリアのうち一つのエリアが有する空きリソースにサービスの増設指示を受け付けるステップと、
   前記一つのエリアが有する空きリソースにサービスを増設した場合における前記複数のエリアのうち要救済リソースを最も多く含むエリアと当該エリアに含まれる当該要救済リソースの数とを特定するステップと、
   前記要救済リソースの数以上の空きリソースを有する他のエリアの数が２以上ならば、前記一つのエリアが有する空きリソースにサービスを増設可能と判断するステップと、
   を含むことを特徴とするコンピュートリソース管理方法。
8. 前記要救済リソースの数以上の空きリソースを有する他のエリアの数が１かつ当該他のエリアが含む要救済リソースの数以上の空きリソースを有するエリアが存在したとき、前記一つのエリアが有する空きリソースにサービスを増設可能と判断するステップ、
   を含むことを特徴とする請求項７に記載のコンピュートリソース管理方法。

Images