JP5632820B2 - 広域分散構成変更システム - Google Patents

Description

本発明は、仮想サーバで構成される情報処理システム、データセンタ等の技術に関し、特に、仮想サーバで構成されるシステムを広域に分散するシステムにおいて適切にリソースを割り当てて構成変更を行う技術に関する。

データセンタを利用したＩＣＴのサービス停止を防ぐためにシステムの冗長化構成が採られるようになっている。しかし、冗長化構成が採られたシステムが同一の地域に設置されている場合、大規模な災害が発生すると当該すべてのシステムが停止してしまい、サービスを提供することができなくなる。これを解決（対処）するために、システムを地理的に異なる複数の拠点間に分散した冗長化構成を採ることにより、サービスの停止を防ぐことができる。

上記システムを構成するサーバを仮想サーバ等で構築し、データセンタに配置する。これらの仮想サーバは、各データセンタにバックアップを作成しコールドスタンバイとしておく。例えばあるデータセンタにて災害が発生した場合、被災していない別のデータセンタでサーバを起動することにより、サービスの停止を最低限に抑えることができる。このようなシステムを実現するためには、下記の課題が存在する。

即ち、各拠点で仮想サーバのリソース使用状況をリモートから参照・表示できる機能、およびユーザシステムを分散配置する機能、を持つシステムが必要となる。

仮想サーバのリソースの分散配置に関する先行技術例としては、特開２０１０−２８２４２０号公報（特許文献１）が挙げられる。特許文献１の技術では、物理サーバの性能情報から稼働する仮想サーバを稼働させる物理サーバを特定している。しかし、広域に分散する場合は、物理サーバの性能だけでなく、回線速度も考慮する必要があるため、不十分である。

特開２０１０−２８２４２０号公報

上述のように、仮想サーバ等で構成されるデータセンタ（拠点）を広域に分散して配置し被災時などにもサービスを維持するシステム（冗長化システムをコールドスタンバイとして災害時には複数のデータセンタ間にシステムを分散配置するシステム等）の実現のためには、各拠点の仮想サーバのリソース使用状況などをリモートから参照・表示できる機能、及び適切にリソースを割り当てて構成変更を行うシステム構成変更の機能などが必要となる。

本発明の主な目的は、仮想サーバで構成される情報処理システム（データセンタ等）の技術において、上記機能（拠点の仮想サーバのリソース使用状況のリモート参照機能、システム構成変更機能など）を持つシステムを実現でき、これにより例えば大規模な災害発生時にもデータセンタが提供するＩＣＴのサービスの停止時間を少なくすることができることである。

本発明のうち代表的な形態は、複数のデータセンタ、そのシステム、及びその仮想サーバを対象として管理する情報処理システム（広域分散構成変更システム）等であって、以下に示す構成を有することを特徴とする。

本システムでは、各拠点（データセンタ）のシステムの仮想サーバのリソース使用状況などをリモートから参照・表示できる機能、及びシステム（仮想サーバ）の構成変更の機能などを備え、例えばある第１のデータセンタ（拠点）で災害が発生した場合、被災していない他のデータセンタ（拠点）のリソースの使用状況を参照し、１つのデータセンタで第１の拠点のシステム（仮想サーバ）を全て稼働（起動）できる場合は、当該１つのデータセンタに集約して仮想サーバを起動し、上記集約できない場合は、複数のデータセンタに分散して仮想サーバを起動する。

本システムは、例えば、複数のデータセンタ、そのシステム、及びその仮想サーバを対象として管理する運用基盤システムを含んで成る。システム（ユーザシステム）を構成する１つ以上の仮想サーバは１つ以上のデータセンタに配置される。運用基盤システムは、複数の各々のデータセンタのシステムの仮想サーバの状態を監視する処理を行う監視部と、複数の各々のデータセンタのシステムの仮想サーバのリソース使用状況を第１のテーブルに管理する処理を行う広域分散リソース管理部と、複数の各々のデータセンタのシステムの仮想サーバに関する構成変更の処理を行う構成変更部とを有する。第１のテーブルは、各データセンタのリソースの使用量と空き容量と回線速度と、各システムの各仮想サーバのリソースの使用量とを管理する。監視部により第１のデータセンタの利用不可の状態を検知した時、リソース管理部によるリソースの使用状況の参照に基づいて、構成変更部により、第１のデータセンタのシステムの仮想サーバについて、移動先とする、１つ以上のデータセンタを検索して決定し、当該移動先のデータセンタで当該第１のデータセンタのシステムの仮想サーバを起動させる処理を行う。

本発明のうち代表的な形態によれば、仮想サーバで構成される情報処理システム（データセンタ等）の技術において、上記機能（拠点の仮想サーバのリソース使用状況のリモート参照機能など）を持つシステムを実現でき、これにより例えば大規模な災害発生時にもデータセンタが提供するＩＣＴのサービスの停止時間を少なくすることができることである。

本発明の一実施の形態のシステムにおける正常稼働時のシステム全体構成を示す図である。 正常稼働時の各データセンタのリソース使用状況テーブルを示す図である。 正常稼働時の各サーバのリソース使用状況テーブルを示す図である。 サーバ移動ポリシーテーブルを示す図である。 災害発生時の仮想サーバ起動先のデータセンタの決定方法の処理フローを示す図である。 データセンタＡ災害発生後のシステム全体構成を示す図である。 正常稼働時の各データセンタのリソース使用状況を示す図である。 データセンタＡ災害発生後の各データセンタのリソース使用状況を示す図である。 災害復旧直後の各データセンタのリソース使用状況テーブルを示す図である。 災害復旧直後の各サーバのリソース使用状況テーブルを示す図である。 災害復旧時の仮想サーバ起動先のデータセンタの決定方法の処理フローを示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。

［システム］
図１において、本実施の形態のシステムにおける正常稼働時のシステム全体構成例を示している。本システム全体は、運用基盤システム４０と、複数の各々の拠点のデータセンタ１０とが通信ネットワークで接続される構成である。運用基盤システム４０は、監視サーバ４１と、広域分散リソース管理システム４２と、仮想サーバ構成変更システム４３とを含んで成る。なお図１では、運用基盤システム４０をシングル構成で記載してあるが、冗長化構成とすることが望ましい。

各データセンタ１０（１０Ａ，１０Ｂ，１０Ｃ）は、対応する各システム２０（２０Ａ，２０Ｂ，２０Ｃ）を有する。各システム２０（２０Ａ，２０Ｂ，２０Ｃ）は、対応するサーバ３０（３０Ａ，３０Ｂ，３０Ｃ，３０Ｄ，３０Ｅ）を有する。各システム２０のサーバ３０は仮想サーバ（物理サーバ上に稼働される仮想サーバ）で構成されている。各システム２０はユーザシステム等であり、仮想サーバ（３０）を用いてクラウドコンピューティングサービス等を提供する。例えば「データセンタＡ」１０Ａは、「システムＡ」２０Ａを有し、「システムＡ」２０Ａは、「サーバＡ」３０Ａ，「サーバＢ」３０Ｂで構成（起動、配置等）されている状態を示す。同様に、データセンタＢのシステムＢはサーバＣ，Ｄ、データセンタＣのシステムＣはサーバＥで構成された状態である。

運用基盤システム４０の監視サーバ４１（公知技術）により、各データセンタ１０のサーバ３０等の監視を行う。監視サーバ４１と各データセンタ１０の物理サーバ等の設備は、遠隔で通信接続される。なおデータセンタ１０側に監視エージェントモジュール等を具備してもよい。

また、広域分散リソース管理システム４２では、各拠点（１０）のシステム（２０）のリソース使用状況を参照・表示する機能を有する。広域分散リソース管理システム４２は、監視サーバ４１による各拠点（１０）の監視の処理に基づき、随時、全体的なリソース状況を把握し、テーブル（Ｔ１）の内容を更新する。

なお運用基盤システム４０で、管理者等のユーザは、監視サーバ４１の設定や、広域分散リソース管理システム４２のリソース使用状況（Ｔ１）の表示や、仮想サーバ構成変更システム４３のサーバ移動ポリシーテーブル（Ｔ２）の設定などが、所定のＧＵＩ（例えばＷｅｂインタフェース）で可能である。

仮想サーバ構成変更システム４３は、複数のデータセンタ１０を対象とした、ユーザシステム（２０）の広域分散配置のための仮想サーバ（３０）の構成変更を決定する機能を有する。即ち、仮想サーバ構成変更システム４３は、広域分散リソース管理システム４２の処理を用いて各拠点（１０）のリソース状況をみながら、システム２０を構成するサーバ３０をどの拠点（１０）に配置（移動、起動等）するか決定し、当該構成変更を実行する。また、仮想サーバ構成変更システム４３は、サーバ移動ポリシーテーブル（Ｔ２）を参照しつつ、回線速度を考慮して上記構成変更を決定する。

各構成要素（４１，４２，４３）は、サーバ装置（プロセッサ、メモリ、記憶装置、入力装置、出力装置、通信インタフェース装置、及びバスなどで構成される）によるソフトウェアプログラム処理などの一般的な技術によって実装可能である。

［リソース使用状況テーブル（Ｔ１）］
図２，図３は、広域分散リソース管理システム４２が保持している管理情報の１つである、リソース使用状況テーブル（Ｔ１）のデータ例を示す。図２のＴ１ａは、正常稼働時の各データセンタ１０（拠点）のリソース使用状況を示す。図３のＴ１ｂは、正常稼働時の各サーバ３０のリソース使用状況を示す。広域分散リソース管理システム４２は、本データ（Ｔ１：Ｔ１ａ，Ｔ１ｂ）を用いて、図７の例のように、リソースをグラフ表示（画面表示）することができる。管理者等のユーザは、運用基盤システム４０の提供する当該画面で情報を確認する操作が可能である。

図２のＴ１ａでは、図示のように、拠点（データセンタ１０）、ＣＰＵ使用量、ＣＰＵ空き容量、メモリ使用量、メモリ空き容量、ディスク使用量、ディスク空き容量、回線速度、等の各情報を管理している。

図３のＴ１ｂでは、図示のように、拠点（データセンタ１０）、サーバ（３０）、ＣＰＵ使用量、メモリ使用量、ディスク使用量、システム（２０）、等の各情報を管理している。

［サーバ移動ポリシーテーブル（Ｔ２）］
図４は、仮想サーバ構成変更システム４３が保持する管理情報の１つである、サーバ移動ポリシーテーブル（Ｔ２）を示す。本テーブル（Ｔ２）は、サーバ（３０）の起動先（移動先、配置先）を決定する際に利用するサーバ移動ポリシー情報を管理している。図示のように、サーバ３０ごとに、回線速度優先度｛低／中／高｝が設定されている。

［仮想サーバ構成変更（被災時）］
監視サーバ４１で、あるデータセンタ１０（例えば１０Ａ）での災害を検知した場合（図６）、仮想サーバ構成変更システム４３は、被災していない他のデータセンタ１０（例えば１０Ｂ，１０Ｃ）で、当該被災したデータセンタ１０（１０Ａ）のサーバ３０（例えば３０Ａ，３０Ｂ）を（代わりに）起動する。

図５は、仮想サーバ構成変更システム４３でのサーバ３０の起動先のデータセンタ１０の決定方法を示す処理フローである（Ｓ１等は処理ステップを示す）。

（Ｓ１） まず、被災したデータセンタ１０（例えば１０Ａ）に存在するその時点のシステム２０（例えば２０Ａ）を構成するサーバ３０（例えば３０Ａ，３０Ｂ）のすべてを稼働させることができる（対応するリソースを持つ）他のデータセンタ１０（候補）を検索する（例えば１０Ｂ，１０Ｃがある）。

（Ｓ２） 上記候補が有る場合（Ｓ１−Ｙ）は、Ｓ２で、当該データセンタ１０（候補の１つ）にて、当該被災したシステム２０（２０Ａ）のサーバ３０（３０Ａ，３０Ｂ）を全て集約して起動させることに決定し、対応する起動を実行する（運用基盤システム４０から該当のデータセンタ１０へ起動を指示する）。

（Ｓ３） 上記候補が無い場合（Ｓ１−Ｎ）は、上記被災したシステム２０（２０Ａ）を構成するサーバ３０（３０Ａ，３０Ｂ）を複数の拠点（１０）に分散して起動する。このために、仮想サーバ構成変更システム４３は、Ｓ３で、ポリシーテーブル（Ｔ２）を参照し、サーバ３０の回線速度の優先度が高いものから順に検索する。ポリシーテーブル（Ｔ２）には、各サーバ３０の回線速度の優先度が定義されている。４３は、この回線速度の優先度が高いサーバから、起動先のデータセンタ１０（候補）を決定する。

（Ｓ４） そして、Ｓ４で、仮想サーバ構成変更システム４３は、リソース使用状況テーブル（Ｔ１）を参照しつつ、データセンタ１０のネットワークの回線速度とリソース（ＣＰＵ，メモリ，ディスク）の空き状況から、サーバ３０の起動先（移動先）を決定する。例えばリソースの空き容量がある拠点（１０）のうち回線速度が一番大きい拠点（１０）で当該移動先のサーバ３０を起動することに決定する。

（Ｓ５） Ｓ５で、仮想サーバ構成変更システム４３は、リカバリ（起動）対象の仮想サーバ（３０）が有る場合はＳ３へ戻り同様に繰り返し、無い場合は終了する。

［具体例（１）］
上記処理に関して、以下、図６のようにデータセンタＡ（１０Ａ）にて災害が発生した場合のサーバの例で説明する。本具体例に対応して、図６は、被災に伴い各データセンタ１０でサーバ３０を起動後のシステム構成を示す。図７は、正常稼働時（被災前）の各拠点（１０）のリソース使用状況、図８は、被災後（構成変更後）の各拠点（１０）のリソース使用状況を示している。

データセンタＡでの災害発生を検知した監視サーバ４１は、仮想サーバ構成変更システム４３に災害発生を通知する。仮想サーバ構成変更システム４３は、広域分散リソース管理システム４２のデータセンタのリソース使用状況テーブル（Ｔ１ａ，図２）とサーバのリソース使用状況テーブル（Ｔ１ｂ，図３）から、データセンタＡのシステムＡ（２０Ａ）を構成する全てのサーバ３０（３０Ａ，３０Ｂ）を起動することができるデータセンタ１０を検索する。システムＡのリソース使用量は、例えば図２，図３，図７に示すように、ＣＰＵが４GHz、メモリが５GB、ディスクが400GBである。また、データセンタＢ（１０Ｂ）のリソースの空きは、ＣＰＵが３GHｚ、メモリが４GB、ディスクが300GBであり、データセンタＣ（１０Ｃ）のリソースの空きは、ＣＰＵが３GHｚ、メモリが３GB、ディスクが900GBである。即ち、システムＡ（全サーバ）を起動するのに十分な空きリソースが有る１つのデータセンタは存在しないため、システムＡを構成するサーバ３０（３０Ａ，３０Ｂ）を、データセンタＢとデータセンタＣとに分散配置することになる。

仮想サーバ構成変更システム４３は、システムＡを構成するサーバ３０（３０Ａ，３０Ｂ）で回線速度の優先度が一番大きいサーバＡから、起動先のデータセンタ１０を決定する。先ほどと同様に、広域分散リソース管理システム４２のデータセンタのリソース使用状況テーブル（Ｔ１ａ）とサーバのリソース使用状況テーブル（Ｔ１ｂ）から、空きリソースを検索する。サーバＡのリソース使用量は、ＣＰＵが２GHz、メモリが３GB、ディスクが200GBであり、データセンタＢ、データセンタＣともに、サーバＡを起動するのに十分なリソースが存在する。よって、回線速度が大きいデータセンタＣでサーバＡを起動する。サーバＢのリソース使用量は、ＣＰＵが２GHz、メモリが２GB、ディスクが200GBである。データセンタＣはサーバＡを起動したため、リソースの空きは、ＣＰＵが１GHz、メモリが２GB、ディスクが200GBとなり、サーバＢを起動することはできない。サーバＢを起動するのに十分なリソースが存在するのはデータセンタＢのみであるため、データセンタＢでサーバＢを起動する。

［仮想サーバ構成変更（復旧時）］
また、監視サーバ４１でデータセンタ１０（例えば１０Ａ）の災害復旧を検知した場合、仮想サーバ構成変更システム４３は、前述の分散して配置されているシステム２０（サーバ３０）を検索し、当該システム２０（サーバ３０）を、復旧したデータセンタ（１０Ａ）で起動させる。

図９は、災害復旧直後の各データセンタのリソース使用状況テーブル（Ｔ１ａ）を示す（図２の状態からの変化後）。

図１０は、災害復旧直後の各サーバのリソース使用状況テーブル（Ｔ１ｂ）を示す（図３の状態からの変化後）。

図１１は、仮想サーバ構成変更システム４３での復旧したデータセンタ（１０Ａ）で起動するサーバ３０の決定方法を示す処理フローである。

（Ｓ１１） まず、仮想サーバ構成変更システム４３は、広域分散リソース管理システム４２の処理（Ｔ１）をもとに、複数のデータセンタ１０に分散して配置されているシステム２０のサーバ３０が存在しないかどうかを検索する（例えば３０Ａ，３０Ｂが存在する）。

（Ｓ１２） 上記存在する場合（Ｓ１１−Ｙ）は、４３は、復旧したデータセンタ１０（１０Ａ）で、上記分散配置されているシステム２０を構成する全てのサーバ３０（３０Ａ，３０Ｂ）を起動することができるかどうか確認する。

（Ｓ１３） 上記起動が可能な場合（Ｓ１２−Ｙ）は、対応する起動を実行する（運用基盤システム４０から該当のデータセンタ１０へ起動を指示する）。

［具体例］
上記処理に関して、以下、データセンタＡ（１０Ａ）にて復旧した場合（図６）の例で説明する。データセンタＡの復旧を検知した監視サーバ４１は、仮想サーバ構成変更システム４３に通知する。仮想サーバ構成変更システム４３は、広域分散リソース管理システム４２の図９のデータセンタのリソース使用状況テーブル（Ｔ１ａ）と図１０のサーバのリソース使用状況テーブル（Ｔ１ｂ）から、分散配置されているシステム２０（サーバ３３０）を検索すると、システムＡ（２０Ａ）が合致する。続いて、復旧したデータセンタＡにてシステムＡを起動すること可能か確認する。復旧したデータセンタＡのリソースの空きは、ＣＰＵが８GHz、メモリが８GB、ディスクが800GBであり、システムＡのリソース使用量は、ＣＰＵが４GHｚ、メモリが５GB、ディスクが400GBである。よって、データセンタＡには、システムＡを起動するのに十分なリソースが存在するため、データセンタＣで起動しているサーバＡと、データセンタＢで起動しているサーバＢを停止して、データセンタＡでそれらサーバＡとサーバＢを起動させる。

［効果等］
以上説明したように、本実施の形態のシステムによれば、仮想サーバ（３０）で構成されるシステム２０を含むデータセンタ１０（拠点）に関する仮想サーバ（３０）のリソース使用状況のリモート参照機能やシステム構成変更機能などを持つシステム（運用基盤システム４０）により、システム２０の広域負荷分散、及び適切なリソース配置による構成変更が可能である。これにより例えばあるデータセンタ１０での大規模な災害発生時にも当該データセンタ１０のサービスを他のデータセンタ１０へ移動（集約配置または分散配置）できるので、当該データセンタ１０のサービスの停止時間を少なくすることができる。例えばコンテナ型データセンタを複数の拠点（地域）に分散して配置した場合、状況に応じてリソースを配分することが可能である。特に、本実施の形態では、前記図５のＳ３，Ｓ４のように、回線速度を考慮して移動先（配置）を決定するという特徴を有する。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、データセンタのアウトソーシングサービス、仮想サーバを利用したディザスタリカバリサービスの共通基盤などに利用可能である。

１０…データセンタ、２０…システム、３０…サーバ（仮想サーバ）、４０…運用基盤システム、４１…監視サーバ、４２…広域分散リソース管理システム、４３…仮想サーバ構成変更システム、Ｔ１…リソース使用状況テーブル、Ｔ２…サーバ移動ポリシーテーブル。

Claims (3)

1. 複数のデータセンタ、そのシステム、及びその仮想サーバを対象として管理する運用基盤システムを含んで成る広域分散構成変更システムであって、
   前記システムを構成する１つ以上の仮想サーバは１つ以上のデータセンタに配置され、
   前記運用基盤システムは、
   前記複数の各々のデータセンタのシステムの仮想サーバの状態を監視する処理を行う監視部と、
   前記複数の各々のデータセンタのシステムの仮想サーバのリソース使用状況を第１のテーブルに管理する処理を行う広域分散リソース管理部と、
   前記複数の各々のデータセンタのシステムの仮想サーバに関する構成変更の処理を行う構成変更部と、を有し、
   前記第１のテーブルは、各データセンタのリソースの使用量と空き容量と回線速度と、各システムの各仮想サーバのリソースの使用量とを管理し、
   前記監視部により第１のデータセンタの利用不可の状態を検知した時、
   前記広域分散リソース管理部による前記リソースの使用状況の参照に基づいて、
   前記構成変更部により、前記第１のデータセンタのシステムの仮想サーバについて、移動先とする、１つ以上のデータセンタを検索して決定し、当該移動先のデータセンタで当該第１のデータセンタのシステムの仮想サーバを起動させる処理を行い、
   前記構成変更部は、前記仮想サーバと前記データセンタの回線速度の優先度との対応関係が設定された第２のテーブルを管理し、
   前記構成変更部により、前記仮想サーバの移動先とする１つ以上のデータセンタを検索して決定する際に、前記第２のテーブルを参照し、当該仮想サーバに対応関係が付けられた前記データセンタの回線速度の優先度が高い仮想サーバから順に候補のデータセンタを検索し、当該候補のデータセンタのリソース使用状況で当該仮想サーバを稼動させる空きがあり回線速度が一番大きいデータセンタを移動先として選択すること、を特徴とする広域分散構成変更システム。
2. 請求項１記載の広域分散構成変更システムにおいて、
   前記監視部により第１のデータセンタの災害発生を検知した時、
   前記広域分散リソース管理部による前記リソースの空き容量と回線速度とに基づいて、
   前記構成変更部により、前記第１のデータセンタのシステムの仮想サーバについて、移動先とする、１つ以上のデータセンタを検索して決定し、当該移動先のデータセンタで当該第１のデータセンタのシステムの仮想サーバを起動させる処理を行うこと、を特徴とする広域分散構成変更システム。
3. 請求項１記載の広域分散構成変更システムにおいて、
   前記構成変更部により、前記第１のデータセンタのシステムの仮想サーバについて、移動先とする、１つ以上のデータセンタを検索して決定する際、前記リソース使用状況に基づき、前記システムを構成するすべての仮想サーバが起動可能な１つのデータセンタが有る場合は、当該１つのデータセンタに集約し、無い場合は、複数のデータセンタに分散し、当該複数のデータセンタとしてはリソース空き容量があり回線速度が大きいデータセンタを選択すること、を特徴とする広域分散構成変更システム。

Images