JP2019057213A - 調整プログラム、調整装置および調整方法 - Google Patents

Abstract

【課題】適切な移動スケジュールを作成すること。【解決手段】記憶部１ａは、物理マシン２，３，４，・・・および各物理マシンで動作する仮想マシン２ａ，２ｂ，３ａ，３ｂ，４ａ，４ｂ，・・・に関する構成情報Ｄ１と物理マシンから他の物理マシンへの仮想マシンの移動の所要時間を示す時間情報Ｄ２とを記憶する。処理部１ｂは、物理マシン２，３，４，・・・に関するメンテナンスの実施期間を取得すると、記憶部１ａに記憶された構成情報Ｄ１および時間情報Ｄ２から移動のスケジュールを決定するための制約条件を仮想マシンに対して作成する。処理部１ｂは、作成した制約条件およびメンテナンスの実施期間に基づいて仮想マシン２ａ，２ｂ，３ａ，３ｂ，４ａ，４ｂ，・・・の移動のスケジュール情報を作成する。処理部１ｂは、仮想マシン２ａ，２ｂ，３ａ，３ｂ，４ａ，４ｂ，・・・のユーザＵ１が使用する端末装置５にスケジュール情報を出力する。【選択図】図１

Description

本発明は調整プログラム、調整装置および調整方法に関する。

情報処理の分野では、物理的なコンピュータ（物理マシンや物理ホストと呼ぶことがある）上で、複数の仮想的なコンピュータ（仮想マシンや仮想ホストと呼ぶことがある）を動作させる仮想化技術が利用されている。各仮想マシン上では、ＯＳ（Operating System）などのソフトウェアを実行できる。仮想化技術を利用する物理マシンは、複数の仮想マシンを管理するためのソフトウェアを実行する。例えば、ハイパーバイザと呼ばれるソフトウェアが、ＣＰＵ（Central Processing Unit）の処理能力やＲＡＭ（Random Access Memory）の記憶領域を、演算のリソースとして複数の仮想マシンに割り振ることがある。

複数の物理マシンを含むシステムには、仮想マシンを実行する物理マシンを変更できるものがある。例えば、仮想マシンを終了させてから、あるいは、終了させずに、ハイパーバイザ間で仮想マシンに関するデータの移動を可能とする技術が用いられている。

例えば、ユーザにより入力された仮想ホストの移動予定日がサーバ機器のメンテナンス予定日よりも後の場合、移動予定日を修正するよう要請し、当該移動予定日に当該仮想ホストを移動先サーバ機器へ移動予約するメンテナンス管理装置の提案がある。

また、仮想マシンに関する情報およびネットワークでのトラフィックに関する情報の少なくとも一方に基づいて、複数の仮想マシンのライブマイグレーションの実行順を定める提案もある。

なお、ＳＡＴ（SATisfiability problem、充足可能性問題）ソルバを用いて病院の特定病棟に勤務する看護師（スタッフ）の勤務スケジュールを求める提案もある。

特開２０１５−１６１９５６号公報 特開２０１４−１５３９９７号公報 特開２０１５−２２２４６４号公報 特開２０１５−１７２７９４号公報

利用者に仮想マシンの利用環境を提供する運用者は、物理マシンのメンテナンスを行うために、事前に、メンテナンスを行う物理マシン上の仮想マシンを別の物理マシンに移動させることがある。この場合、移動処理により該当の仮想マシンの性能が低下したり、該当の仮想マシンを一時的に利用できなくなったりすることがある。このため、運用者は、メンテナンス日程やそれに伴う仮想マシンの移動スケジュールを利用者に事前に通知することが多い。ところが、運用者による仮想マシンの移動スケジュールの決定には利用者の仮想マシンの利用予定が考慮されないことが多く、利用者に影響を与える可能性がある。

そこで、利用者により業務都合を入力させて、運用者側で仮想マシンの移動スケジュールを決定することも考えられる。しかし、利用者が必ずしも仮想マシンの負荷の高い時間帯を把握しているとは限らない。このため、利用者の業務都合に任せて仮想マシンの移動スケジュールを決定すると、仮想マシンの負荷の高い時間帯に移動処理が実行され、利用者の仮想マシンの利用に対する影響が却って大きくなる可能性がある。

１つの側面では、本発明は、適切な移動スケジュールを作成することを目的とする。

１つの態様では、調整プログラムが提供される。調整プログラムは、物理マシンに関するメンテナンスの実施期間を取得すると、物理マシンおよび物理マシンで動作する仮想マシンに関する構成情報および物理マシンから他の物理マシンへの仮想マシンの移動の所要時間を示す時間情報から移動のスケジュールを決定するための制約条件を仮想マシンに対して作成し、制約条件および実施期間に基づいて移動のスケジュール情報を作成し、仮想マシンのユーザが使用する装置にスケジュール情報を出力する、処理をコンピュータに実行させる。

１つの側面では、適切な移動スケジュールを作成できる。

第１の実施の形態の情報処理システムを示す図である。 仮想マシン移動スケジュールの作成例を示す図である。 第２の実施の形態の情報処理システムの例を示す図である。 管理サーバのハードウェア例を示す図である。 ライブマイグレーションの例を示す図である。 管理サーバの機能例を示す図である。 メンテナンス実施期間情報の例を示す図である。 メンテナンス対象マシン情報の例を示す図である。 物理マシン構成テーブルの例を示す図である。 仮想マシン構成テーブルの例を示す図である。 仮想マシン稼働テーブルの例を示す図である。 依存関係テーブルの例を示す図である。 ＬＭ所要時間テーブルの例を示す図である。 メンテナンススケジュールテーブルの例を示す図である。 ＬＭスケジュールテーブルの例を示す図である。 ＬＭ実施拒否日時情報の例を示す図である。 制約充足問題における変数の例を示す図である。 変数によるＬＭの表現の例を示す図である。 管理サーバの処理例を示すフローチャートである。 日程調整例を示すフローチャートである。 制約充足問題の生成例を示すフローチャートである。 日程再調整例を示すフローチャートである。 制約充足問題の再生成例を示すフローチャートである。 ソルバ部に対する入力データの例（その１）を示す図である。 ソルバ部に対する入力データの例（その２）を示す図である。 ソルバ部に対する入力データの例（その３）を示す図である。 ソルバ部に対する入力データの例（その４）を示す図である。 ソルバ部に対する入力データの例（その５）を示す図である。 ソルバ部による出力データの例（その１）を示す図である。 ソルバ部による出力データの例（その２）を示す図である。 利用者に対するＬＭスケジュール画面の例（その１）を示す図である。 利用者に対するＬＭスケジュール画面の例（その２）を示す図である。 利用者に対するＬＭスケジュール画面の例（その３）を示す図である。 運用者に対するメンテナンススケジュール画面の例を示す図である。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムを示す図である。第１の実施の形態の情報処理システムは、調整装置１および物理マシン２，３，４，・・・を有する。調整装置１および物理マシン２，３，４，・・・はネットワークＮ１に接続されている。調整装置１は、物理マシン２，３，４，・・・における仮想マシンの移動スケジュールを調整する。物理マシン２，３，４，・・・それぞれは、ＣＰＵやメモリなどの演算リソースを有し、演算リソースを用いて仮想マシンを実行する。例えば、物理マシン２，３，４，・・・それぞれは、ハイパーバイザを実行し、ハイパーバイザの機能により、仮想マシンに対する演算リソースの割り当てを行う。ここで、物理マシンをＰＭ（Physical Machine）と略記することがある。仮想マシンをＶＭ（Virtual Machine）と略記することがある。

ネットワークＮ１には、端末装置５も接続されている。端末装置５は、仮想マシンを利用するユーザＵ１によって利用されるクライアントである。端末装置５は、インターネットなどの他のネットワークを介してネットワークＮ１に接続されてもよい。

物理マシン２，３，４，・・・は、自物理マシンで動作する仮想マシンを他の物理マシンに移動させる機能を有する。例えば、物理マシン２，３，４，・・・はライブマイグレーションと呼ばれる技術を用いて仮想マシンの移動を行う。ライブマイグレーションでは、移動対象の仮想マシンに割り当てられた移動元の物理マシンのＣＰＵリソースやメモリリソースの情報を移動先の物理マシンにコピーすることで、仮想マシンの起動状態を保ったまま仮想マシンを移動させる。あるいは、仮想マシンを移動させる技術として、仮想マシンを停止してから該当の仮想マシンの情報を移動先の物理マシンにコピーするコールドマイグレーションを用いることもできる。

システムの運用では、仮想マシンを実現するための基盤（インフラ（infrastructure））である物理マシンに対するセキュリティパッチの適用やＯＳのアップグレードなどのメンテナンスが行われることがある。物理マシンのメンテナンスには、物理マシンの停止を伴うことが多い。物理マシンを停止させる場合、当該物理マシン上の仮想マシンも停止させることになり、仮想マシンを利用できなくなってしまう。

そこで、物理マシンのメンテナンスの前に、メンテナンス対象の物理マシン上の仮想マシンを別の物理マシンに移動させることで、メンテナンスによる仮想マシン利用への影響を軽減しながら、メンテナンス対象の物理マシンのメンテナンスを行うことがある。調整装置１は、そのための仮想マシンの移動スケジュールの作成を支援する。調整装置１は、記憶部１ａおよび処理部１ｂを有する。

記憶部１ａは、ＲＡＭなどの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１ｂは、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１ｂはプログラムを実行するプロセッサでもよい。プロセッサは、複数のプロセッサの集合（マルチプロセッサ）も含み得る。

記憶部１ａは、物理マシンおよび物理マシンで動作する仮想マシンに関する構成情報Ｄ１を記憶する。構成情報Ｄ１は、インフラに関する情報を含む。例えば、構成情報Ｄ１は、物理マシンの構成を示す物理マシン構成情報ｄ１、仮想マシンの構成を示す仮想マシン構成情報ｄ２および仮想マシン間の依存関係を示す依存関係情報ｄ３を含む。

ここで、一例として、物理マシン２，３，４および仮想マシン２ａ，２ｂ，３ａ，３ｂ，４ａ，４ｂの識別情報を次の通りとする。物理マシン２の識別情報は“ＰＭ１”である。物理マシン３の識別情報は“ＰＭ２”である。物理マシン４の識別情報は“ＰＭ３”である。仮想マシン２ａの識別情報は“ＶＭ１”である。仮想マシン２ｂの識別情報は“ＶＭ２”である。仮想マシン３ａの識別情報は“ＶＭ３”である。仮想マシン３ｂの識別情報は“ＶＭ４”である。仮想マシン４ａの識別情報は“ＶＭ５”である。仮想マシン４ｂの識別情報は“ＶＭ６”である。

物理マシン構成情報ｄ１は、各物理マシンが備えるＣＰＵコア数、メモリ容量およびディスク容量の情報を含む。具体的には、物理マシン構成情報ｄ１には、物理マシン２（識別情報“ＰＭ１”）に対して、ＣＰＵコア数“６４”個、メモリ容量“２５６ＧＢ（Giga Bytes）”、ディスク容量“３２ＴＢ（Tera Bytes）”というレコードが登録されている。物理マシン構成情報ｄ１には、他の物理マシンに対しても同様のレコードが登録される。

仮想マシン構成情報ｄ２は、各仮想マシンに割り当てるＣＰＵコア数、メモリ容量、ディスク容量および当該仮想マシンの現配置（現在の配置先の物理マシン）の情報を含む。具体的には、仮想マシン構成情報ｄ２には、仮想マシン２ａ（識別情報“ＶＭ１”）に対して、ＣＰＵコア数“２”個、メモリ容量“３２ＧＢ”、ディスク容量“２ＴＢ”、現配置“ＰＭ１”（物理マシン２）というレコードが登録されている。仮想マシン構成情報ｄ２には、他の仮想マシンに対しても同様のレコードが登録される。

依存関係情報ｄ３は、仮想マシンの組合せと、当該組合せに属する各仮想マシンを同じ物理マシン上で動作させてもよいか否かを示す情報を含む。具体的には、依存関係情報ｄ３には、仮想マシン２ａ，２ｂの組合せ（識別情報“ＶＭ１”、“ＶＭ２”の組合せ）に対して、同物理マシンで動作可（同ＰＭ“可”）というレコードが登録されている。また、依存関係情報ｄ３には、仮想マシン２ａ，３ａの組合せ（識別情報“ＶＭ１”、“ＶＭ３”の組合せ）に対して、同物理マシンで動作不可（同ＰＭ“不可”）というレコードが登録されている。例えば、ある仮想マシンの組を共通の物理マシン上で動作させた方が、性能の向上を見込めることもあるし、冗長化を考慮して共通の物理マシン上で動作させないこともある。仮想マシン間のこのような関係性を依存関係情報ｄ３として予め設定することが考えられる。

記憶部１ａは、物理マシンから他の物理マシンへの仮想マシンの移動の所要時間を示す時間情報Ｄ２を記憶する。時間情報Ｄ２は、メンテナンスの実施期間に属する各時刻における仮想マシンの移動の所要時間（予測される所要時間）を示す情報である。所要時間は仮想マシン毎に与えられる。

例えば、時間情報Ｄ２は、仮想マシン、時刻および移動所要時間の情報を含む。具体的には、時間情報Ｄ２には、仮想マシン２ａの識別情報“ＶＭ１”、時刻“ｔ１”、移動所要時間“Δｘ”を含むレコードが登録されている。このレコードは、物理マシン２から他の物理マシンへの仮想マシン２ａの移動を時刻“ｔ１”に完了させるための移動の所要時間が“Δｘ”であることを示す。

また、時間情報Ｄ２には、仮想マシン２ａの識別情報“ＶＭ１”、時刻“ｔ２”、移動所要時間“Δｙ”を含むレコードが登録されている。このレコードは、物理マシン２から他の物理マシンへの仮想マシン２ａの移動を時刻“ｔ２”に完了させるための移動の所要時間が“Δｙ”であることを示す。時間情報Ｄ２には、他の時刻についても、仮想マシン２ａの移動所要時間が登録される。時間情報Ｄ２には、他の仮想マシンについても、時刻毎の移動所要時間が登録される。

時間情報Ｄ２は、記憶部１ａに予め格納されていてもよい。時間情報Ｄ２は、各仮想マシンの過去の各時刻における負荷の履歴や過去の各時刻における移動時の所要時間の履歴などに基づいて予測された結果でもよい（例えば、処理部１ｂが当該予測結果を記憶部１ａに格納してもよい）。

図２は、仮想マシン移動スケジュールの作成例を示す図である。処理部１ｂは、物理マシンに関するメンテナンスの実施期間を取得すると、記憶部１ａに記憶された構成情報Ｄ１および時間情報Ｄ２から仮想マシンの移動のスケジュールを決定するための制約条件Ｄ３を当該仮想マシンに対して作成する。制約条件Ｄ３は、仮想マシンの移動のスケジュールの決定に対する制約を示す。ここで、移動対象となる仮想マシンは、メンテナンス対象の物理マシン上の仮想マシンである。

制約条件Ｄ３は、構成情報Ｄ１および時間情報Ｄ２から作成される。制約条件Ｄ３は、構成情報Ｄ１に基づく仮想マシンの移動先に対する制約条件を含む。構成情報Ｄ１に基づく制約条件には、例えば、ある物理マシン上の仮想マシンの所要リソースの合計が、当該物理マシンのリソースを上回らないようにする、仮想マシンの組を同一物理マシン上で稼働する（または稼働させない）などの条件が考えられる。

また、制約条件Ｄ３は、時間情報Ｄ２に基づく仮想マシンの移動タイミングや移動時間に対する制約条件を含む。時間情報Ｄ２に基づく制約条件には、メンテナンス中の物理マシンでは仮想マシンの移動を行わない、などの条件が考えられる。また、時間情報Ｄ２に基づく制約条件は、時間情報Ｄ２に基づく仮想マシンの移動所要時間の総和（移動対象が複数の仮想マシンの場合は複数の仮想マシンの移動所要時間の総和）を最小にするという条件（目的関数）を含む。

制約条件Ｄ３の一例として、依存関係情報ｄ３における仮想マシン２ａ，３ａに対する制約（仮想マシン２ａ，３ａを同一物理マシン上で稼働させない）の作成方法を示すと次のようになる。

（１）処理部１ｂは、仮想マシン２ａ，３ａが所属するグループＧを生成する。
（２）処理部１ｂは、式（１）で示される制約条件を生成する。

ここで、ｖは仮想マシンを示す。ｐは物理マシンを示す。Ｐは物理マシンの集合を示す。ａ_ｐｖ（ｔ）は、時刻ｔに仮想マシンｖが物理マシンｐ上で稼働している場合は１であり、それ以外の場合は０である。

処理部１ｂは、制約条件Ｄ３およびメンテナンスの実施期間に基づいて仮想マシンの移動のスケジュール情報を作成する。例えば、処理部１ｂは、作成した制約条件Ｄ３およびメンテナンスの実施期間の情報を制約充足判定ソルバに入力し、制約充足判定ソルバの機能により、制約条件Ｄ３を満足するスケジュールを作成する。例えば、処理部１ｂは、制約充足判定ソルバとして、ＭＩＬＰ（Mixed Integer Linear Programming、混合整数線形計画法）ソルバやＳＡＴソルバを用いることができる。ここで、以下では、制約充足判定ソルバを、単にソルバと称することがある。

物理マシンに関するメンテナンスの実施期間は、メンテナンス対象の物理マシンに対してメンテナンスを行う候補の期間ということもできる。例えば、処理部１ｂは、物理マシン毎のメンテナンスの所要時間の情報（記憶部１ａに予め格納される）に基づいて、物理マシン毎のメンテナンス実施期間に関する制約条件を更に作成してもよい。処理部１ｂは、当該制約条件に基づいて、仮想マシンの移動のスケジュールと共に、当該候補期間のうち物理マシン毎のメンテナンスを行う期間を、ソルバにより決定してもよい。処理部１ｂは、メンテナンス対象の物理マシン上の仮想マシンを、当該物理マシンのメンテナンスを行う期間よりも前に、他の物理マシンに移動させるように、スケジュール情報を作成する。

例えば、物理マシン２（識別情報“ＰＭ１”）がメンテナンス対象に含まれるとする。このとき、一例として、処理部１ｂは、仮想マシン２ａを時刻ｔａから時刻ｔｂの間に物理マシン２から物理マシン４に移動させ、仮想マシン２ｂを時刻ｔｂから時刻ｔｃの間に物理マシン２から物理マシン４に移動させるというスケジュール情報を作成する。なお、時刻ｔｂは、時刻ｔａよりも後の時刻である。時刻ｔｃは、時刻ｔｂよりも後の時刻である。

処理部１ｂは、移動対象の仮想マシンのユーザが使用する装置に、作成したスケジュール情報を出力する。例えば、ユーザＵ１は、仮想マシン２ａ，２ｂ，３ａ，３ｂを利用する。記憶部１ａは、ユーザの端末装置の識別情報と当該ユーザが使用する仮想マシンの識別情報との対応関係を予め記憶してもよい。そうすれば、処理部１ｂは、記憶部１ａを参照することで、仮想マシンに対応するユーザの端末装置を特定できる。

例えば、処理部１ｂは、仮想マシン２ａ（識別情報“ＶＭ１”）を時刻ｔａから時刻ｔｂの間に移動させ、仮想マシン２ｂ（識別情報“ＶＭ２”）を時刻ｔｂから時刻ｔｃの間に移動させるスケジュール情報を、端末装置５に送信する。なお、処理部１ｂは、ユーザＵ１に対して、移動元および移動先の物理マシンの情報を提供しなくてよい。端末装置５は、スケジュール情報を受信し、当該スケジュール情報で示されるスケジュールを表す画面６を、端末装置５に接続されたディスプレイに表示させる。ユーザＵ１は、画面６を閲覧することで、自身が利用する仮想マシン２ａ，２ｂの移動スケジュールを確認することができる。

このようにして、調整装置１は、仮想マシンの適切な移動スケジュールを作成できる。
例えば、処理部１ｂは、制約条件Ｄ３として、仮想マシンの移動所要時間の総和（移動対象が複数の仮想マシンの場合は複数の仮想マシンの移動時間の総和）を最小にするという制約条件を作成する。そして、処理部１ｂは、時間情報Ｄ２に基づいて、当該条件を満たすスケジュール情報を作成する。このため、ユーザＵ１の仮想マシンの利用に対する影響を抑えて仮想マシンの移動スケジュールを作成することができる。

なお、処理部１ｂは、時間情報Ｄ２を含む制約条件を作成してソルバにより解いてもよい。あるいは、処理部１ｂは、時間情報Ｄ２を含まない制約条件（移動所要時間の入力部分を変数とする）を作成し、当該制約条件に時間情報Ｄ２の移動所要時間を入力してソルバにより解いてもよい（構成情報Ｄ１に基づく制約条件についても同様である）。

また、処理部１ｂは、制約条件Ｄ３として、構成情報Ｄ１に基づく仮想マシンの移動先に関する制約条件を作成する。このため、物理マシンおよび仮想マシンの運用の要件を逸脱しないように、仮想マシンの移動スケジュールを決定できる。ここで、例えば、ユーザＵ１の仮想マシンの利用への影響時間の最小化のみを目的として移動スケジュールを作成すると、運用上の意図がある仮想マシンの依存関係を満たせなくなる可能性がある。一例としては、性能向上のために同一の物理マシンに配備すべきアプリケーションを実行する仮想マシンとＤＢ（DataBase）を実行する仮想マシンとを、別個の物理マシンに移動させてしまうことが考えられる。これに対して、当該依存関係も制約条件として用いることで、このような運用上意図しない仮想マシンの配置を抑制できる。

なお、画面６は、ユーザＵ１により当該スケジュールを確定させるためのボタン（例えば、“ＯＫ”ボタン）を含んでもよい。また、画面６は、ユーザＵ１による当該スケジュールの拒否を受け付けるためのボタン（例えば、“移動拒否期間設定”ボタン）を含んでもよい。処理部１ｂは、後者のボタンの入力に応じて、仮想マシン毎の移動拒否期間（移動の禁止時間帯）を設定するための設定画面の情報を更に端末装置５に送信し、当該設定画面に対するユーザＵ１の移動拒否期間の入力を受け付けてもよい。

そして、処理部１ｂは、移動拒否期間の入力に応じて、該当の仮想マシンに対する移動拒否期間に対応する制約条件を更に作成し、該当の仮想マシンの移動スケジュールに関するスケジュール情報を再作成してもよい。この場合、処理部１ｂは、再作成したスケジュール情報を端末装置５に再度送信し、端末装置５によりユーザＵ１に提示する。ここで、処理部１ｂは、ユーザＵ１による移動拒否期間に代えて、ユーザＵ１による移動の許容時間帯を取得して、制約条件を再作成し、スケジュール情報を再作成してもよい。

すなわち、処理部１ｂは、出力したスケジュール情報に対してユーザにより入力された移動の禁止時間帯または移動の許容時間帯を取得する。処理部１ｂは、禁止時間帯または許容時間帯に基づいて制約条件を再作成し、再作成した制約条件に基づいてスケジュール情報を再作成し、再作成したスケジュール情報を端末装置５に出力する。

このように、ユーザＵ１により、仮想マシンの移動予定を確認させ、当該移動予定がユーザＵ１の業務都合と競合している場合に、移動拒否期間を指定させることで、ユーザＵ１の仮想マシンの利用への影響を更に抑えた移動スケジュールの作成が可能となる。

以下では、より具体的な情報処理システムを例示して、調整装置１の機能を詳細に説明する。
［第２の実施の形態］
図３は、第２の実施の形態の情報処理システムの例を示す図である。第２の実施の形態の情報処理システムは、管理サーバ１００、物理マシン２００，３００，４００，・・・を有する。管理サーバ１００および物理マシン２００，３００，４００，・・・は、ネットワーク１０に接続されている。ネットワーク１０は、例えば、ＬＡＮ（Local Area Network）である。ネットワーク１０は、ネットワーク２０に接続されている。ネットワーク２０は、ネットワーク１０の外部のネットワークであり、例えば、インターネットやＷＡＮ（Wide Area Network）などである。ネットワーク２０には、利用者端末５００，６００が接続されている。また、ネットワーク１０には運用者端末７００が接続されている。

ここで、第２の実施の形態の情報処理システムは、パブリッククラウドサービスと呼ばれるサービスを提供する。パブリッククラウドサービスでは、システムの運用者は、システム上のハードウェア資源をネットワーク経由で複数の利用者（テナント）に提供する。システムの利用者は、提供されるハードウェア資源を用いて、仮想マシンを構築し、当該仮想マシン上で種々の業務アプリケーションを利用する。

第２の実施の形態の情報処理システムでは、サービスの品質を維持するために、インフラ側のメンテナンス（例えば、物理マシン２００，３００，４００，・・・に対するセキュリティパッチの適用やＯＳのアップグレードなど）が行われる。そこで、物理マシンに対してメンテナンスを行う前に、該当の物理マシン上で動作中の仮想マシンを別の物理マシンに移動する処理が行われる。第２の実施の形態の例では、仮想マシンの移動に、ライブマイグレーションの技術が利用される（ただし、仮想マシンの移動に、コールドマイグレーションを用いてもよい）。

管理サーバ１００は、物理マシン２００，３００，４００，・・・における仮想マシンのライブマイグレーションのスケジュールを管理するサーバコンピュータである。管理サーバ１００は、メンテナンス対象の物理マシンおよびメンテナンスの実施期間が入力されると、メンテナンス対象の物理マシン上で動作する仮想マシンのライブマイグレーションのスケジュールを作成する。管理サーバ１００は、作成したスケジュールを、利用者端末５００，６００や運用者端末７００に送信する。また、管理サーバ１００は、作成したスケジュールが確定されると、確定されたスケジュールに従って、メンテナンス対象の物理マシンに仮想マシンのライブマイグレーションを指示する。管理サーバ１００は、第１の実施の形態の調整装置１の一例である。

物理マシン２００，３００，４００，・・・は、それぞれがＣＰＵやメモリなどの演算リソースを有し、演算リソースを用いて仮想マシンを実行するサーバコンピュータである。例えば、物理マシン２００，３００，４００，・・・それぞれは、ハイパーバイザを実行し、ハイパーバイザの機能により、仮想マシンに対する演算リソースの割り当てを行う。物理マシン２００，３００，４００，・・・は、第１の実施の形態の物理マシン２，３，４，・・・の一例である。

利用者端末５００，６００は、利用者によって利用されるクライアントコンピュータである。利用者端末５００，６００は、異なる利用者によって利用される。各利用者は、利用者端末５００，６００を操作して、物理マシン２００，３００，４００，・・・上の仮想マシンを利用する。利用者端末５００の利用者は、利用者端末５００を用いて、管理サーバ１００により提供されるライブマイグレーション（自身が利用する仮想マシンについてのライブマイグレーション）のスケジュールを確認することもある。利用者端末６００の利用者も同様に、利用者端末６００を用いて、管理サーバ１００により提供されるライブマイグレーションのスケジュールを確認することもある。利用者端末５００，６００は、第１の実施の形態の端末装置５の一例である。

運用者端末７００は、第２の実施の形態の情報処理システムの運用者（システム管理者）によって利用されるクライアントコンピュータである。運用者は、運用者端末７００を用いて、管理サーバ１００により提供される物理マシンのメンテナンスのスケジュールやメンテナンスに伴うライブマイグレーションのスケジュールを確認する。

図４は、管理サーバのハードウェア例を示す図である。管理サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。各ハードウェアは管理サーバ１００のバスに接続されている。

プロセッサ１０１は、管理サーバ１００の情報処理を制御するハードウェアである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組合せであってもよい。

ＲＡＭ１０２は、管理サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。

ＨＤＤ１０３は、管理サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

画像信号処理部１０４は、プロセッサ１０１からの命令に従って、管理サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１として、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０５は、管理サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２として、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

媒体リーダ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

ＮＩＣ１０７は、ネットワーク１０を介して他の装置と通信を行う。ＮＩＣ１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
物理マシン２００，３００，４００，・・・、利用者端末５００，６００および運用者端末７００も管理サーバ１００と同様のハードウェアを用いて実現できる。

図５は、ライブマイグレーションの例を示す図である。物理マシン２００，３００，４００，・・・は、ライブマイグレーションにより、物理マシン間で仮想マシンを移動させる。例えば、物理マシン２００は、ハイパーバイザ２１０および仮想マシン２１１，２１２を有する。物理マシン３００は、ハイパーバイザ３１０および仮想マシン３１１を有する。ハイパーバイザ２１０は、物理マシン２００が備えるＣＰＵやメモリといったハードウェアのリソースを仮想マシン２１１，２１２に割り当てる。ハイパーバイザ３１０も同様に、物理マシン３００が備えるハードウェアのリソースを仮想マシン３１１に割り当てる。例えば、物理マシン２００から物理マシン３００に仮想マシン２１２を移動する場合を想定すると、ライブマイグレーションにより次のような手順を採ることが考えられる。

（１）物理マシン３００上で移動対象の仮想マシン２１２用のＣＰＵ／メモリリソースを予約する。（２）物理マシン２００で移動対象の仮想マシン２１２に割り当てられているメモリリソースのデータを、物理マシン３００で当該仮想マシン２１２用に新たに割り当てたメモリリソースにコピーする。（３）物理マシン２００から物理マシン３００へ仮想マシン２１２に割り当てていたＣＰＵリソースの状態をコピーし、物理マシン２００で仮想マシン２１２を停止させる。（４）物理マシン３００で仮想マシン２１２を再開し、物理マシン２００で仮想マシン２１２に割り当てていたリソースを解放する。これにより、物理マシン２００上で稼働している仮想マシン２１２を、物理マシン３００に移動させることができる。上記の手順はＰｒｅ−Ｃｏｐｙと呼ばれることもある。ただし、ライブマイグレーションにはＰｏｓｔ−Ｃｏｐｙなどの他の手順を用いてもよい。

ここで、以下の説明では、ライブマイグレーションを、ＬＭ（Live Migration）と略記することがある。
図６は、管理サーバの機能例を示す図である。管理サーバ１００は、インフラ管理部１１１およびスケジューラ１１２を有する。インフラ管理部１１１およびスケジューラ１１２の機能は、プロセッサ１０１により実現される。例えば、プロセッサ１０１は、ＲＡＭ１０２に記憶された所定のプログラムを実行することで、インフラ管理部１１１およびスケジューラ１１２の機能を発揮する。あるいは、インフラ管理部１１１およびスケジューラ１１２は、ＦＰＧＡやＡＳＩＣなどのハードワイヤードロジックにより実現されてもよい。

インフラ管理部１１１は、各物理マシンのハードウェアの構成や各仮想マシンに割り当てられるリソースの構成を管理する。例えば、物理マシン２００は、仮想マシン２１１，２１２を有する。物理マシン３００は、仮想マシン３１１，３１２を有する。

インフラ管理部１１１は、インフラ構成情報記憶部１２０、ＶＭ性能情報記憶部１３０およびインフラ管理制御部１４０を有する。インフラ構成情報記憶部１２０およびＶＭ性能情報記憶部１３０は、例えば、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。

インフラ構成情報記憶部１２０は、インフラ構成情報を記憶する。インフラ構成情報は、各物理マシンのハードウェアの構成や各仮想マシンに割り当てられるリソースの構成に関する情報である。

ＶＭ性能情報記憶部１３０は、ＶＭ性能情報を記憶する。ＶＭ性能情報は、仮想マシンの性能に関する情報であり、各仮想マシンのＬＭの所要時間（各時刻においてＬＭのために予測される所要時間）に関する情報を含む。また、ＶＭ性能情報は、ＬＭの所要時間の予測結果を得るために用いられた各仮想マシンの負荷の履歴（過去の各時刻における各仮想マシンの負荷の履歴）を含む。なお、各仮想マシンの負荷の履歴に基づくＬＭの所要時間の予測は、管理サーバ１００により行われてもよい。

インフラ管理制御部１４０は、スケジューラ１１２により決定されたＬＭのスケジュールに従って、各物理マシンに対する仮想マシンのＬＭを指示する。
スケジューラ１１２は、物理マシンのメンテナンスを行う際に、メンテナンス対象の物理マシンで動作する仮想マシンのＬＭのスケジュールを決定する。スケジューラ１１２は、メンテナンス実施期間やメンテナンス対象の物理マシンの情報を運用者端末７００から受け付けると、インフラ構成情報記憶部１２０およびＶＭ性能情報記憶部１３０に記憶された情報に基づいて、ＬＭのスケジュールを決定する。

スケジューラ１１２は、制約条件記憶部１５０、イベント情報記憶部１６０、制約条件生成部１７０およびソルバ部１８０を有する。制約条件記憶部１５０およびイベント情報記憶部１６０は、例えば、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。

制約条件記憶部１５０は、制約条件生成部１７０により生成された制約条件を記憶する。
イベント情報記憶部１６０は、ソルバ部１８０により作成された各仮想マシンのＬＭのスケジュールの情報や各物理マシンのメンテナンスのスケジュールの情報を記憶する。

制約条件生成部１７０は、インフラ構成情報記憶部１２０に記憶されたインフラ構成情報およびＶＭ性能情報記憶部１３０に記憶されたＶＭ性能情報に基づいて、ＬＭのスケジュールの決定に対する制約条件を生成する。制約条件生成部１７０は、生成した制約条件を制約条件記憶部１５０に格納する。

ソルバ部１８０は、制約条件生成部１７０により生成された制約条件を満足するようにスケジューリングできるかを判定することで、ＬＭのスケジュールの作成を試行する。ソルバ部１８０は、生成された制約条件を最も良く満足するＬＭのスケジュールを、イベント情報記憶部１６０に格納する。

ソルバ部１８０として、例えば、ＭＩＬＰソルバやＳＡＴソルバなどを利用することができる。ＭＩＬＰソルバには、次の文献が参考になる。
（文献１）J.P.Vielma, “Mixed Integer Linear Programming Formulation Techniques,” SIAM Review, vol.57, No.1, pp.3-57, 2015.
（文献２）Free Software Foundation,Inc., “GLPK (GNU Linear Programming Kit),” URL:http://www.gnu.org/software/glpk/glpk.html.
（文献３）Zuse Institute Berlin, “SCIP (Solving Constraint Integer Programs),”URL:http://scip.zib.de/.
（文献４）IBM Corporation, “IBM ILOG CPLEX Optimizer,”URL:http://www-01.ibm.com/software/commerce/optimization/cplex-optimizer/index.html.
また、ＳＡＴソルバには、次の文献が参考になる。

（文献５）C.P.Gomes, H.Kautz, A.Sabharwal, and B.Selman, “Satisfiability Solvers,” in Handbook of Knowledge Representation (F. van Harmelen, V. Lifschitz, and B.Porter, eds.), pp.89-134, Foundations of Artificial Intelligence, 2008.
（文献６）N.Een and N.Sorensson, “MiniSat,” URL:http://minisat.se/Main.html.
（文献７）G.Audemard and L.Simon, “Glucose,”URL:http://www.labri.fr/perso/lsimon/glucose/.
ただし、ソルバ部１８０として、上記のＭＩＬＰソルバやＳＡＴソルバ以外のソルバを利用することもできる。

図７は、メンテナンス実施期間情報の例を示す図である。メンテナンス実施期間情報Ｍ１は、運用者端末７００により、スケジューラ１１２に入力される。メンテナンス実施期間情報Ｍ１は、システムに含まれる複数の物理マシンに関するメンテナンスの実施期間の情報である。メンテナンス実施期間情報Ｍ１は、開始日時および終了日時の項目を含む。

開始日時の項目には、メンテナンスの実施期間の開始日時が登録される。終了日時の項目には、メンテナンスの実施期間の終了日時が登録される。例えば、メンテナンス実施期間情報Ｍ１は、開始日時“２０１７−０６−０１Ｔ１２：００：００．０００Ｚ”および終了日時“２０１７−０６−３０Ｔ１１：５９：００．０００Ｚ”という情報を含む。これは、メンテナンス実施期間が２０１７年６月１日１２時００分から２０１７年６月３０日１１時５９分までであることを示す。

ここで、１つの物理マシンに対するメンテナンス作業は、メンテナンス実施期間のうちの一部の時間範囲を用いて行われる。管理サーバ１００は、各物理マシンのメンテナンス作業が、入力されたメンテナンス実施期間中に完了するようにスケジューリングする。

例えば、管理サーバ１００は、第１の物理マシンに対するメンテナンス作業を行う前に、第１の物理マシン上の全ての仮想マシンを第２の物理マシン（移動先の物理マシンは複数でもよい）に移動させて、第１の物理マシンのメンテナンス作業を行えるようにする。

また、その後、第２の物理マシンのメンテナンス作業を行う場合も考えられる。その場合、管理サーバ１００、第２の物理マシン上の全ての仮想マシンを第１の物理マシンまたは第３の物理マシン（移動先の物理マシンは複数でもよい）に移動させて、第２の物理マシンのメンテナンス作業を行えるようにする。

図８は、メンテナンス対象マシン情報の例を示す図である。メンテナンス対象マシン情報Ｍ２は、運用者端末７００により、スケジューラ１１２に入力される。メンテナンス対象マシン情報Ｍ２は、物理マシン名およびメンテナンス所要時間の項目を含む。

物理マシン名の項目には、物理マシンの名称が登録される。メンテナンス所要時間の項目には、当該物理マシンのメンテナンスの所要時間が登録される。例えば、メンテナンス対象マシン情報Ｍ２は、物理マシン名“ＰＭ０１”、メンテナンス所要時間“０１：００：００．０００”という情報を含む。これは、物理マシン名“ＰＭ０１”で示される物理マシンのメンテナンス作業の所要時間が１時間であることを示す。

メンテナンス対象マシン情報Ｍ２には、メンテナンス対象の他の物理マシンに対しても、同様に物理マシン名とメンテナンス所要時間が登録される。
図９は、物理マシン構成テーブルの例を示す図である。物理マシン構成テーブル１２１は、インフラ構成情報記憶部１２０に予め格納されている。物理マシン構成テーブル１２１は、物理マシン名、ＣＰＵコア数、メモリ容量およびディスク容量の項目を含む。

物理マシン名の項目には、物理マシンの名称が登録される。ＣＰＵコア数の項目には、当該物理マシンが備えるＣＰＵコアの数が登録される。メモリ容量の項目には、当該物理マシンが備えるメモリ（ＲＡＭ）の容量が登録される。ディスク容量の項目には、当該物理マシンが備えるＨＤＤ（あるいは、当該物理マシンに対して外部ストレージに割り当てられた補助記憶領域）の容量が登録される。

例えば、物理マシン構成テーブル１２１には、物理マシン名が“ＰＭ０１”、ＣＰＵコア数が“６４”、メモリ容量が“２５６ＧＢ”、ディスク容量が“３２ＴＢ”というレコードが登録されている。このレコードは、物理マシン名“ＰＭ０１”で示される物理マシンが備えるＣＰＵコア数が６４個、メモリ容量が２５６ＧＢ、ディスク容量が３２ＴＢであることを示す。

物理マシン構成テーブル１２１には、他の物理マシンに対しても同様に、物理マシン名とＣＰＵコア数とメモリ容量とディスク容量とが登録される。
図１０は、仮想マシン構成テーブルの例を示す図である。仮想マシン構成テーブル１２２は、インフラ構成情報記憶部１２０に予め格納されている。仮想マシン構成テーブル１２２は、仮想マシン名、ＣＰＵコア数、メモリ容量、ディスク容量およびユーザＩＤ（IDentifier）の項目を含む。

仮想マシン名の項目には、仮想マシンの名称が登録される。ＣＰＵコア数の項目には、当該仮想マシンに割り当てられるＣＰＵコア数が登録される。メモリ容量の項目には、当該仮想マシンに割り当てられるメモリの容量が登録される。ディスク容量の項目には、当該仮想マシンに割り当てられるＨＤＤ（あるいは、物理マシンの外部ストレージの補助記憶装置）の容量が登録される。

例えば、仮想マシン構成テーブル１２２には、仮想マシン名が“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”、ＣＰＵコア数が“２”、メモリ容量が“３２ＧＢ”、ディスク容量が“２ＴＢ”、ユーザＩＤが“ｕｓｅｒ１”というレコードが登録されている。このレコードは、仮想マシン名“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”で示される仮想マシンに対して所要されるＣＰＵコア数が２個、メモリ容量が３２ＧＢ、ディスク容量が２ＴＢであり、ユーザＩＤ“ｕｓｅｒ１”のユーザが当該仮想マシンを利用していることを示す。

仮想マシン構成テーブル１２２には、他の仮想マシンに対しても同様に、仮想マシン名とＣＰＵコア数とメモリ容量とディスク容量とユーザＩＤとが登録される。
図１１は、仮想マシン稼働テーブルの例を示す図である。仮想マシン稼働テーブル１２３は、インフラ構成情報記憶部１２０に予め格納されている。仮想マシン稼働テーブル１２３は、各仮想マシンの初期配置先の物理マシンを示す情報である。仮想マシン稼働テーブル１２３は、物理マシン名、仮想マシン名およびユーザＩＤの項目を含む。

物理マシン名の項目には、物理マシンの名称が登録される。仮想マシン名の項目には、当該物理マシン上で稼働する仮想マシンの名称が登録される。ユーザＩＤの項目には、当該仮想マシンを利用するユーザのユーザＩＤが登録される。

例えば、仮想マシン稼働テーブル１２３には、物理マシン名が“ＰＭ０１”、仮想マシン名が“ｓｅｒｖｅｒ−９０”、ユーザＩＤが“ｕｓｅｒ３”というレコードが登録されている。このレコードは、物理マシン名“ＰＭ０１”で示される物理マシン上で、仮想マシン名“ｓｅｒｖｅｒ−９０”で示される仮想マシンが稼働しており、ユーザＩＤ“ｕｓｅｒ３”のユーザが当該仮想マシンを利用していることを示す。

仮想マシン稼働テーブル１２３には、他の仮想マシンに対しても同様に、配置先の物理マシン名と仮想マシン名とユーザＩＤとが登録される。
図１２は、依存関係テーブルの例を示す図である。依存関係テーブル１２４は、インフラ構成情報記憶部１２０に予め格納されている。依存関係テーブル１２４は、仮想マシンのグループに対する依存関係を示す情報である。依存関係テーブル１２４は、グループ名、仮想マシン名およびルールの項目を含む。

グループ名の項目には、仮想マシンのグループの名称が登録される。仮想マシン名の項目には、該当のグループに属する仮想マシンの名称の組が登録される。ルールの項目には、該当のグループに属する仮想マシンを同一の物理マシン上で稼働させるか否かを示す情報が登録される。例えば、ルール“ａｆｆｉｎｉｔｙ”は、同一の物理マシン上で稼働させること（ａｆｆｉｎｉｔｙルールと呼ぶ）を示す。また、ルール“ａｎｔｉ−ａｆｆｉｎｉｔｙ”は、同一の物理マシン上で稼働させないこと（ａｎｔｉ−ａｆｆｉｎｉｔｙルールと呼ぶ）を示す。

例えば、依存関係テーブル１２４には、グループ名が“Ｇ０１”、仮想マシン名が“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”および“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”、ルールが“ａｎｔｉ−ａｆｆｉｎｉｔｙ”というレコードが登録されている。このレコードは、グループ名“Ｇ０１”で示されるグループに、仮想マシン名“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”および“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”の２つの仮想マシンが所属し、これら仮想マシンを同一物理マシン上で稼働させないことを示す。

また、例えば、依存関係テーブル１２４には、グループ名が“Ｇ０２”、仮想マシン名が“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”および“ａｃｃｏｕｎｔｉｎｇ−ｗｅｂ−０３”、ルールが“ａｆｆｉｎｉｔｙ”というレコードが登録されている。このレコードは、グループ名“Ｇ０２”で示されるグループに、仮想マシン名“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”および“ａｃｃｏｕｎｔｉｎｇ−ｗｅｂ−０３”の２つの仮想マシンが所属し、これら仮想マシンを同一物理マシン上で稼働させることを示す。

依存関係テーブル１２４には、仮想マシンの他のグループに対しても同様に、グループ名と仮想マシン名とルールとが登録される。
図１３は、ＬＭ所要時間テーブルの例を示す図である。ＬＭ所要時間テーブル１３１は、ＶＭ性能情報記憶部１３０に予め格納されている。ＬＭ所要時間テーブル１３１は、時刻、仮想マシン名およびＬＭ所要時間の項目を含む。

時刻の項目には、時刻が登録される。仮想マシン名の項目には、仮想マシンの名称が登録される。ＬＭ所要時間の項目には、該当の時刻において該当の仮想マシンに対して予測されるライブマイグレーション（ＬＭ）の所要時間が登録される。

例えば、ＬＭ所要時間テーブル１３１には、時刻が“２０１７−０６−２０Ｔ０９：００：００．０００Ｚ”、仮想マシン名が“ｓｅｒｖｅｒ−９０”、ＬＭ所要時間が“００：１５：００．０００”というレコードが登録されている。このレコードは、２０１７年６月２０日９時００分〜９時５９分の間に仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンのＬＭを完了する場合の当該ＬＭの所要時間が１５分であることを示す。

また、ＬＭ所要時間テーブル１３１には、時刻が“２０１７−０６−２０Ｔ０９：００：００．０００Ｚ”、仮想マシン名が“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”、ＬＭ所要時間が“００：３０：００．０００”というレコードが登録されている。このレコードは、２０１７年６月２０日９時００分〜９時５９分の間に仮想マシン名“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”の仮想マシンのＬＭを完了する場合の当該ＬＭの所要時間が３０分であることを示す。

また、ＬＭ所要時間テーブル１３１には、時刻が“２０１７−０６−２０Ｔ１０：００：００．０００Ｚ”、仮想マシン名が“ｓｅｒｖｅｒ−９０”、ＬＭ所要時間が“００：１５：００．０００”というレコードが登録されている。このレコードは、２０１７年６月２０日１０時００分〜１０時５９分の間に仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンのＬＭを完了する場合の当該ＬＭの所要時間が１５分であることを示す。

また、ＬＭ所要時間テーブル１３１には、時刻が“２０１７−０６−２０Ｔ１０：００：００．０００Ｚ”、仮想マシン名が“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”、ＬＭ所要時間が“００：２０：００．０００”というレコードが登録されている。このレコードは、２０１７年６月２０日１０時００分〜１０時５９分の間に仮想マシン名“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”の仮想マシンのＬＭを完了する場合の当該ＬＭの所要時間が２０分であることを示す。

ＬＭ所要時間テーブル１３１には、他の時刻、他の仮想マシンに対しても同様に、時刻と仮想マシン名とＬＭ所要時間とが登録される。
図１４は、メンテナンススケジュールテーブルの例を示す図である。メンテナンススケジュールテーブル１６１は、ソルバ部１８０により生成され、イベント情報記憶部１６０に格納される。メンテナンススケジュールテーブル１６１は、物理マシン名、開始日時および終了日時の項目を含む。

物理マシン名の項目には、メンテナンス対象の物理マシンの名称が登録される。開始日時の項目には、当該物理マシンのメンテナンスの開始日時が登録される。終了日時の項目には、当該物理マシンのメンテナンスの終了日時が登録される。

例えば、メンテナンススケジュールテーブル１６１には、物理マシン名が“ＰＭ０１”、開始日時が“２０１７−０６−２０Ｔ１０：３０：００．０００Ｚ”、終了日時が“２０１７−０６−２０Ｔ１１：２９：００．０００Ｚ”というレコードが登録されている。このレコードは、物理マシン名“ＰＭ０１”の物理マシンのメンテナンスを２０１７年６月２０日１０時３０分〜２０１７年６月２０日１１時２９分まで行う予定であることを示す。

メンテナンススケジュールテーブル１６１には、メンテナンス対象の他の物理マシンに対しても同様に、物理マシン名と開始日時と終了日時とが登録される。
図１５は、ＬＭスケジュールテーブルの例を示す図である。ＬＭスケジュールテーブル１６２は、ソルバ部１８０により生成され、イベント情報記憶部１６０に格納される。ＬＭスケジュールテーブル１６２は、仮想マシン名、開始日時、終了日時、移動元、移動先および状態の項目を含む。

仮想マシン名の項目には、ＬＭ対象の仮想マシンの名称が登録される。開始日時の項目には、該当の仮想マシンのＬＭの開始日時が登録される。終了日時の項目には、該当の仮想マシンのＬＭの終了日時が登録される。移動元の項目には、ＬＭの移動元の物理マシンの名称（物理マシン名）が登録される。移動先の項目には、ＬＭの移動先の物理マシンの名称（物理マシン名）が登録される。状態の項目には、当該ＬＭの開始日時および終了日時で示されるスケジュールの“確定”または“未確定”を示す情報が登録される。状態の項目の初期値は“未確定”である。

例えば、ＬＭスケジュールテーブル１６２には、仮想マシン名が“ｓｅｒｖｅｒ−９０”、開始日時が“２０１７−０６−２０Ｔ０９：４５：００．０００Ｚ”、終了日時が“２０１７−０６−２０Ｔ０９：５９：００．０００Ｚ”、移動元が“ＰＭ０１”、移動先が“ＰＭ０２”、状態が“確定”というレコードが登録されている。

このレコードは、仮想マシン名“ｓｅｒｖｅｒ−９０”のＬＭを２０１７年６月２０日９時４５分に開始し、２０１７年６月２０日９時５９分に終了することを示す。また、当該ＬＭの移動元が物理マシン名“ＰＭ０１”の物理マシンであり、移動先が物理マシン“ＰＭ０２”の物理マシンであること、当該ＬＭのスケジュールが利用者によって確定済であることを示す。

ＬＭスケジュールテーブル１６２には、他の仮想マシンに対しても、仮想マシン名と開始日時と終了日時と移動元と移動先と状態とが登録される。
なお、ＬＭスケジュールテーブル１６２のうち、仮想マシン名、開始日時および終了日時の項目の内容が利用者に提示される内容である。また、ＬＭスケジュールテーブル１６２のうち、仮想マシン名、開始日時、終了日時、移動元および移動先の項目が運用者に提示される内容である。

図１６は、ＬＭ実施拒否日時情報の例を示す図である。ＬＭ実施拒否日時情報Ｍ３は、利用者端末５００，６００により、スケジューラ１１２に入力される。ＬＭ実施拒否日時情報Ｍ３は、仮想マシン名、開始日時および終了日時の項目を含む。

仮想マシン名の項目には、仮想マシンの名称が登録される。開始日時の項目には、ＬＭの実施を拒否する期間（ＬＭ実施拒否期間）の開始日時が登録される。終了日時の項目には、ＬＭの実施拒否期間の終了日時が登録される。例えば、ＬＭ実施拒否日時情報Ｍ３は、仮想マシン名“ｍｙｓｑｌ−６７”、開始日時“２０１７−０６−２０Ｔ１１：００：００．０００Ｚ”、終了日時“２０１７−０６−２０Ｔ１３：５９：００．０００Ｚ”という情報を含む。これは、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンのＬＭ実施拒否期間が２０１７年６月２０日１１時００分から２０１７年６月２０日１３時５９分であることを示す。

ＬＭ実施拒否日時情報Ｍ３には、他の仮想マシンについても同様に、仮想マシン名と開始日時と終了日時とが含まれ得る。
図１７は、制約充足問題における変数の例を示す図である。制約条件生成部１７０は、図７〜図１３で例示した各情報（場合によっては、図１６の情報も含む）に含まれる値を制約充足問題の入力とする。ソルバ部１８０は、制約充足問題を解くことで、図１４で例示したメンテナンススケジュールテーブル１６１および図１５で例示したＬＭスケジュールテーブル１６２を出力し、イベント情報記憶部１６０に格納する。

例えば、入力変数には次のものがある。
ｔ_ｓは、メンテナンス実施期間の開始日時である。ｔ_ｅは、メンテナンス実施期間の終了日時である。Ｔ＝｛ｔ_ｓ，・・・，ｔ_ｅ｝は、メンテナンス実施期間を分単位に離散化した時刻の集合である。Ｔにおけるある時刻から、その次の時刻（１分後の時刻）の直前までの期間を１つのタイムスロットと呼ぶ。時刻ｔ_ｓおよびｔ_ｅの値は、メンテナンス実施期間情報Ｍ１から得られる。

Ｐは、メンテナンス対象の物理マシン（ＰＭ）の集合である。ｍａｉｎｔＤｕｒａｔｉｏｎ_ｐは、物理マシンｐ（ＰＭｐ）のメンテナンス所要時間である。ここで、ｐは、メンテナンス対象の物理マシンを示す添え字である。ＰおよびｍａｉｎｔＤｕｒａｔｉｏｎ_ｐの値は、メンテナンス対象マシン情報Ｍ２から得られる。

ｃｐｕＣａｐ_ｐは、ＰＭｐのＣＰＵコア数である。ｒａｍＣａｐ_ｐは、ＰＭｐのメモリ容量である。ｄｉｓｋＣａｐ_ｐは、ＰＭｐのディスク容量である。ｃｐｕＣａｐ_ｐ、ｒａｍＣａｐ_ｐおよびｄｉｓｋＣａｐ_ｐの値は、物理マシン構成テーブル１２１から得られる。

Ｖは、ＬＭの日程調整対象の仮想マシン（ＶＭ）の集合である。ｉｎｉｔＡｃｃｏｍｍｏ_ｐｖは、仮想マシンｖ（ＶＭｖ）の初期配置を示し、ＶＭｖの初期配置先がＰＭｐの場合は１、それ以外の場合は０を示す。ここで、ｖは、ＬＭ対象の仮想マシンを示す添え字である。Ｖは、仮想マシン稼働テーブル１２３に登録された仮想マシンのうち、メンテナンス対象マシン情報Ｍ２で指定された物理マシンに対応付けられた仮想マシンの集合となる。ｉｎｉｔＡｃｃｏｍｍｏ_ｐｖの値は、仮想マシン稼働テーブル１２３から得られる。

ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）は、時刻ｔにおけるＶＭｖのＬＭ所要時間である。ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）の値は、ＬＭ所要時間テーブル１３１から得られる。

ｃｐｕＲｅｑ_ｖは、ＶＭｖのＣＰＵコア数である。ｒａｍＲｅｑ_ｖは、ＶＭｖのメモリ容量である。ｄｉｓｋＲｅｑ_ｖは、ＶＭｖのディスク容量である。ｃｐｕＲｅｑ_ｖ、ｒａｍＲｅｑ_ｖおよびｄｉｓｋＲｅｑ_ｖの値は、仮想マシン構成テーブル１２２から得られる。

ａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）は、ＬＭ実施許可日時（あるいは、ＬＭ実施拒否日時）を示し、時刻ｔにＶＭｖのＬＭを実施してよい場合は１、それ以外の場合は０を示す。ａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）の値は、ＬＭ実施拒否日時情報Ｍ３から得られる（ＬＭ実施拒否日時に属する時刻では０であり、それ以外で１となる）。

ｎｕｍＧ_ａｆは、ａｆｆｉｎｉｔｙルールが適用されているグループの数である。Ｇ_ａｆ＝｛Ｇ_ａｆ＿１，・・・，Ｇ_{ａｆ＿ｎｕｍＧａｆ}｝は、ａｆｆｉｎｉｔｙルールが適用されているグループの集合である。ｎｕｍＧ_ａａは、ａｎｔｉ−ａｆｆｉｎｉｔｙルールが適用されているグループの数である。Ｇ_ａａ＝｛Ｇ_ａａ＿１，・・・，Ｇ_{ａａ＿ｎｕｍＧａａ}｝は、ａｎｔｉ−ａｆｆｉｎｉｔｙルールが適用されているグループの集合である。ｎｕｍＧ_ａｆ、Ｇ_ａｆ、ｎｕｍＧ_ａａ、Ｇ_ａａの値は、依存関係テーブル１２４から得られる。

また、例えば、出力変数には次のものがある。
ｍ_ｐ（ｔ）は、ＰＭ単位のメンテナンス実施期間を示し、時刻ｔにＰＭｐがメンテナンス中の場合は１、それ以外の場合は０を示す。ｍ_ｐ（ｔ）は、メンテナンススケジュールテーブル１６１の作成に用いられる。

ａ_ｐｖ（ｔ）は、ＶＭの配置先の物理マシンを示し、時刻ｔにＶＭｖがＰＭｐ上で稼働している場合は１、それ以外の場合は０を示す。ｌ_ｐｖ（ｔ）は、ＬＭによるＶＭの配置先の切り替わりを示し、ＶＭｖについて時刻ｔにＰＭｐへのＬＭが完了した場合は１、それ以外の場合は０を示す。ａ_ｐｖ（ｔ）およびｌ_ｐｖ（ｔ）は、ＬＭスケジュールテーブル１６２の作成に用いられる。

ここで、上記の変数ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）、ｌ_ｐｖ（ｔ）およびａ_ｐｖ（ｔ）によるＬＭの表現を例示する。
図１８は、変数によるＬＭの表現の例を示す図である。図１８（Ａ）は、時刻ｔ_ｉ，ｔ_ｉ＋１，・・・，ｔ_ｉ＋５における、仮想マシンｖ１，ｖ２に対するｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖを例示する。

例えば、ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ１（ｔ_ｉ＋２）＝２である。これは、時刻ｔ_ｉ＋２に仮想マシンｖ１のＬＭを完了させるためにタイムスロットを２つ要することを示す。

また、ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ２（ｔ_ｉ＋４）＝３である。これは、時刻ｔ_ｉ＋４に仮想マシンｖ２のＬＭを完了させるためにタイムスロットを３つ要することを示す。

図１８（Ｂ）は、時刻ｔ_ｉ，ｔ_ｉ＋１，・・・，ｔ_ｉ＋５における、仮想マシンｖ１，ｖ２に対するｌ_ｐｖ（ただし、ｐ＝Ｃとする）を例示する。
例えば、ｌ_ｐｖ１（ｔ_ｉ＋２）＝１であり、それ以外の時刻ではｌ_ｐｖ１（ｔ）＝０である。これは、時刻ｔ_ｉ＋２に、仮想マシンｖ１の物理マシンＣへのＬＭが完了したことを示す。ここで、図１８（Ａ）によれば、時刻ｔ_ｉ＋２で仮想マシンｖ１のＬＭが完了するには、タイムスロットを２つ要する。したがって、仮想マシンｖ１のＬＭの実施期間は、時刻ｔ_ｉ＋１，ｔ_ｉ＋２で示される２つのタイムスロットの期間である。

また、ｌ_ｐｖ２（ｔ_ｉ＋４）＝１であり、それ以外の時刻ではｌ_ｐｖ２（ｔ）＝０である。これは、時刻ｔ_ｉ＋４に、仮想マシンｖ２の物理マシンＣへのＬＭが完了したことを示す。ここで、図１８（Ａ）によれば、時刻ｔ_ｉ＋４で仮想マシンｖ２のＬＭが完了するには、タイムスロットを３つ要する。したがって、仮想マシンｖ２のＬＭの実施期間は、時刻ｔ_ｉ＋２，ｔ_ｉ＋３，ｔ_ｉ＋４で示される３つのタイムスロットの期間である。

図１８（Ｃ）は、時刻ｔ_ｉ，ｔ_ｉ＋１，・・・，ｔ_ｉ＋５において、仮想マシンｖ１，ｖ２に対し、ａ_ｐｖ（ｔ）＝＝１となるｐ（物理マシン）を例示する。
例えば、時刻ｔ_ｉ，ｔ_ｉ＋１，ｔ_ｉ＋２では、ａ_ｐｖ１（ｔ）＝＝１となるｐは、物理マシンＡ（仮想マシンｖ１のＬＭの移動元）である。そして、図１８（Ｂ）で例示されるように、仮想マシンｖ１は、時刻ｔ_ｉ＋２で物理マシンＣへのＬＭが完了する。このため、時刻ｔ_ｉ＋３以降では、ａ_ｐｖ１（ｔ）＝＝１となるｐは、物理マシンＣである。

また、時刻ｔ_ｉ，ｔ_ｉ＋１，・・・，ｔ_ｉ＋４では、ａ_ｐｖ２（ｔ）＝＝１となるｐは、物理マシンＢ（仮想マシンｖ２のＬＭの移動元）である。そして、図１８（Ｂ）で例示されるように、仮想マシンｖ２は、時刻ｔ_ｉ＋４で物理マシンＣへのＬＭが完了する。このため、時刻ｔ_ｉ＋５以降では、ａ_ｐｖ２（ｔ）＝＝１となるｐは、物理マシンＣである。

以上のように、変数ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）、ｌ_ｐｖ（ｔ）およびａ_ｐｖ（ｔ）により、仮想マシンｖ１，ｖ２のＬＭについて、次の内容が表される。
仮想マシンｖ１について、ＬＭ実施期間は時刻［ｔ_ｉ＋１，ｔ_ｉ＋２］（時刻ｔ_ｉ＋１から時刻ｔ_ｉ＋２まで）であり、移動元が物理マシンＡ、移動先が物理マシンＣである。

仮想マシンｖ２について、ＬＭ実施期間は時刻［ｔ_ｉ＋２，ｔ_ｉ＋４］（時刻ｔ_ｉ＋２から時刻ｔ_ｉ＋４まで）であり、移動元が物理マシンＡ、移動先が物理マシンＣである。
制約条件生成部１７０は、上記に例示した各変数を用いた制約条件を生成する。ソルバ部１８０は、生成された制約条件に関する制約充足問題を解くことで、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を作成する。

ここで、制約条件生成部１７０により生成される制約条件の例を示す。
第１の制約条件は、ＶＭｖが初期配置先のＰＭｐ上で起動することである。第１の制約条件は、式（２）で表される。

第２の制約条件は、ＰＭｐに対してメンテナンスを一度実施することである。第２の制約条件は、式（３）（４）で表される。特に、式（３）は、ＰＭｐに対してｍａｉｎｔＤｕｒａｔｉｏｎ_ｐ以上の連続したメンテナンス期間が確保されることを示す。式（４）は、当該メンテナンス期間の合計がｍａｉｎｔＤｕｒａｔｉｏｎ_ｐに等しいことを示す。

第３の制約条件は、一度にメンテナンスを実施できるＰＭ数をＣ_ｍ台以下とすることである。ここで、Ｃ_ｍは、システムに応じて予め定められる定数である。第３の制約条件は、式（５）で表される。

第４の制約条件は、ＶＭｖが何れかのＰＭｐ上で常に稼働することである。第４の制約条件は、式（６）で表される。

第５の制約条件は、ＰＭｐ上で稼働するＶＭの要求資源量の合計がＰＭｐの提供資源量以下であり、かつ、ＰＭｐのメンテナンス中はＰＭｐ上でＶＭを稼働させないことである。第５の制約条件は、式（７）（８）（９）で表される。特に、式（７）は、ＣＰＵコア数に関する制約条件を表す。式（８）は、メモリ容量に関する制約条件を示す。式（９）は、ディスク容量に関する制約条件を表す。

第６の制約条件は、ＶＭｖがＰＭｐ上で稼働する時間がｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）＋１以上であることである。第６の制約条件は、式（１０）で表される。ここで、第６の制約条件は、ＶＭｖがＬＭのためにｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）＋１以上の期間、連続して稼働状態となることを反映している。ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）に“＋１”（１を加算）する理由は、ＬＭが完了した直後に別のＬＭを実施することは考えにくいためである。

第７の制約条件は、ライブマイグレーションの検出を示す。第７の制約条件は、式（１１）で表される。ここで、ｌ_ｐｖ（ｔ）は、ＶＭｖについて時刻ｔにＰＭｐへのライブマイグレーションが完了した場合は１であり、それ以外の場合は０である。

第８の制約条件は、ＶＭｖのＬＭを実施できるのは許可された期間のみであることである。第８の制約条件は、式（１２）で表される。

第９の制約条件は、ＰＭｐについてメンテナンス中のライブマイグレーションが禁止されることである。第９の制約条件は、式（１３）で表される。

第１０の制約条件は、一度にＬＭを行えるＶＭをＣ_ｌ台以下とすることである。ここで、Ｃ_ｌは、システムに応じて予め定められる定数である。第１０の制約条件は、式（１４）で表される。

第１１の制約条件は、ａｎｔｉ−ａｆｆｉｎｉｔｙルールが適用されているグループに属する各ＶＭを同じＰＭ上で稼働させることを禁止することである。第１１の制約条件は、式（１５）で表される。

第１２の制約条件は、ａｆｆｉｎｉｔｙルールが適用されているグループに属する各ＶＭを同じＰＭ上で稼働させることである。第１２の制約条件は、式（１６）で表される。

第１３の制約条件は、制約充足問題の目的関数であり、各ＶＭのＬＭの所要時間（すなわち、利用者の業務に対する影響時間）を最小化することである。第１３の制約条件は、式（１７）で表される。

次に、管理サーバ１００による処理手順を説明する。
図１９は、管理サーバの処理例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。

（Ｓ１）スケジューラ１１２は、メンテナンスおよびＬＭの日程調整実施のメッセージを運用者端末７００から受信する。当該メッセージは、メンテナンス実施期間情報Ｍ１およびメンテナンス対象マシン情報Ｍ２を含む。

（Ｓ２）スケジューラ１１２は、メンテナンスの日程調整の処理を実行する。日程調整の処理の詳細は後述される。スケジューラ１１２は、日程調整の結果、各物理マシンのメンテナンススケジュールテーブル１６１および各仮想マシンのＬＭスケジュールテーブル１６２を作成する。

（Ｓ３）スケジューラ１１２は、作成したＬＭスケジュールに基づいて、ＬＭ実施予定日時を利用者に提示する。具体的には、スケジューラ１１２は、利用者が利用する仮想マシンのＬＭ実施予定日時を示す画面情報を、利用者毎に作成し、該当の利用者の利用者端末に、作成した画面情報を送信する。このとき、スケジューラ１１２は、ＬＭ実施予定日時と共にＬＭ実施予定日時に含まれる各時刻に対して予測される仮想マシンの負荷（予測負荷）を示す情報も該当の利用者端末に送信する。スケジューラ１１２により送信された画面情報は、利用者端末により受信される。利用者端末は、当該画面情報に基づいて仮想マシンのＬＭ実施予定日時を示す画面（各時刻の仮想マシンの予測負荷を含む）を表示する。なお、スケジューラ１１２は、仮想マシン構成テーブル１２２や仮想マシン稼働テーブル１２３のユーザＩＤの項目により、各仮想マシンを利用する利用者を識別することができる。

（Ｓ４）スケジューラ１１２は、各利用者によるＬＭ実施日時確定または拒否日時のメッセージを受信する。拒否日時のメッセージは、ＬＭ実施拒否日時情報Ｍ３を含む。
（Ｓ５）スケジューラ１１２は、メンテナンスおよびＬＭの日程再調整の処理を実行する。日程再調整の処理の詳細は後述される。スケジューラ１１２は、日程再調整に応じて、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を更新する。

（Ｓ６）スケジューラ１１２は、メンテナンス日程を運用者に提示する。具体的には、スケジューラ１１２は、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２に基づいて、各仮想マシンのＬＭのスケジュールや各物理マシンのメンテナンスのスケジュールを示す画面情報を作成する。スケジューラ１１２は、作成した画面情報を運用者端末７００に送信する。

（Ｓ７）スケジューラ１１２は、ＬＭ実施確定日時を利用者に提示する。具体的には、スケジューラ１１２は、ＬＭスケジュールテーブル１６２に基づいて、利用者が利用する仮想マシンのＬＭのスケジュールを示す画面情報を、利用者毎に作成する。スケジューラ１１２は、該当の利用者の利用者端末に、作成した画面情報を送信する。なお、スケジューラ１１２は、ステップＳ６，Ｓ７を、任意の順序で実行することができる。

（Ｓ８）スケジューラ１１２は、作成したメンテナンス日程をインフラ管理部１１１に登録する。具体的には、スケジューラ１１２は、ＬＭスケジュールテーブル１６２で示されるスケジュールで各仮想マシンのＬＭを行うようにインフラ管理部１１１を設定する。

インフラ管理部１１１は、当該スケジュールに応じて、各仮想マシンのＬＭを物理マシン２００，３００，４００，・・・に指示する。すなわち、管理サーバ１００は、作成されたＬＭスケジュールテーブル１６２（スケジュール情報）に基づいて、該当の仮想マシンのＬＭ（移動）をメンテナンス対象の物理マシンに指示する。これにより、運用者による物理マシンのメンテナンス作業を効率化できる。

図２０は、日程調整例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１９のステップＳ２に相当する。
（Ｓ１１）制約条件生成部１７０は、制約充足問題の生成処理を実行する。制約充足問題の生成処理の詳細は後述される。制約条件生成部１７０は、制約充足問題の生成処理の結果、複数の制約条件を含む制約充足問題を出力する。

（Ｓ１２）ソルバ部１８０は、ステップＳ１１で出力された制約充足問題の求解を実行し、メンテナンス実施期間の各時刻における出力変数の各値を求める。
（Ｓ１３）ソルバ部１８０は、メンテナンス実施期間の各時刻における出力変数の値から、スケジューリング結果として、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を作成する。ソルバ部１８０は、当該スケジューリング結果をイベント情報記憶部１６０に格納する。なお、この段階では、ＬＭスケジュールテーブル１６２の状態の項目は、全て“未確定”である。

ここで、ソルバ部１８０は、メンテナンス実施期間のうち、メンテナンス対象の物理マシン上で稼働する全ての仮想マシンを他の物理マシンに移動させた後の期間から、当該物理マシンに対してメンテナンスを行う日程を決定する。例えば、ソルバ部１８０は、メンテナンス対象の物理マシン上で稼働する全ての仮想マシンを、他の物理マシンに移動させた直後の期間（メンテナンスの所要時間に相当する長さの期間）を、当該物理マシンに対してメンテナンスを行う期間としてもよい。

図２１は、制約充足問題の生成例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。以下に示す手順は、図２０のステップＳ１１に相当する。

（Ｓ２１）制約条件生成部１７０は、インフラ構成情報記憶部１２０に記憶されたインフラ構成情報をソルバ部１８０への入力形式に変換する。前述のように、インフラ構成情報は、物理マシン構成テーブル１２１、仮想マシン構成テーブル１２２、仮想マシン稼働テーブル１２３および依存関係テーブル１２４を含む。制約条件生成部１７０は、これらの各テーブルの情報をソルバ部１８０に対する入力データの形式に変換する。

（Ｓ２２）制約条件生成部１７０は、仮想マシン（ＶＭ）の依存関係に関する制約条件を生成する。ＶＭの依存関係に関する制約条件は、例えば、前述の第１、第４、第５、第１１および第１２の制約条件である。制約条件生成部１７０は、生成した制約条件を制約条件記憶部１５０に格納する。

（Ｓ２３）制約条件生成部１７０は、ＬＭの日程調整対象の全仮想マシン（ＶＭ）をスケジューリング候補に設定する。日程調整対象の仮想マシンは、メンテナンス対象マシン情報Ｍ２で指定された物理マシン上で稼働する仮想マシンである。それ以外の物理マシン上で稼働する仮想マシンはＬＭの日程調整の対象外である。

（Ｓ２４）制約条件生成部１７０は、メンテナンス実施期間の全日時をＬＭ実施の候補日時に設定する。例えば、制約条件生成部１７０は、メンテナンス実施期間情報Ｍ１に基づいて、Ｔ＝｛ｔ_ｓ，・・・，ｔ_ｅ｝を設定する。また、制約条件生成部１７０は、Ｔに属する全てのｔについてａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）＝１とする。

（Ｓ２５）制約条件生成部１７０は、ＶＭ性能情報記憶部１３０に記憶された仮想マシンの負荷予測を、ソルバ部１８０への入力形式に変換する。ここで、仮想マシンの負荷予測とは、ＶＭ性能情報記憶部１３０に記憶されたＬＭ所要時間テーブル１３１である。ＬＭ所要時間テーブル１３１は、メンテナンス実施期間（Ｔ）の各時刻に対応する仮想マシン毎のＬＭの所要時間を含む。制約条件生成部１７０は、ＬＭ所要時間テーブル１３１の情報をソルバ部１８０に対する入力データの形式（変換後の仮想マシンの負荷予測）に変換する。なお、ＬＭの所要時間は、仮想マシンの負荷が大きいときには長くなり、仮想マシンの負荷が小さいときには短くなる傾向にある。このため、ＬＭの所要時間は、仮想マシンの負荷予測の結果を反映した情報であるといえる。

（Ｓ２６）制約条件生成部１７０は、変換後の仮想マシンの負荷予測に基づいて、仮想マシン（ＶＭ）負荷が小さいとき（すなわち、各仮想マシンのＬＭ所要時間が小さいとき）にＬＭを実施するように制約条件（ＬＭ実施時間に関する制約条件）を生成する。ＬＭ実施時間に関する制約条件は、例えば、前述の第２、第３、第６〜第１０および第１３の制約条件である。ここで、この段階では、第８の制約条件については、各仮想マシンについてメンテナンス実施期間における全ての期間でＬＭを実施可（全てのｔについてａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）＝１）である。制約条件生成部１７０は、生成した制約条件を制約条件記憶部１５０に格納する。

（Ｓ２７）制約条件生成部１７０は、ステップＳ２２，Ｓ２６で生成した制約条件を基に制約充足問題を設定する。
図２２は、日程再調整例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１９のステップＳ５に相当する。

（Ｓ３１）制約条件生成部１７０は、集合Ｖ_ａを初期化する。具体的には、制約条件生成部１７０は、集合Ｖ_ａを空集合φとする。ここで、集合Ｖ_ａは、ＬＭ実施の日程が確定した仮想マシンの集合である。

（Ｓ３２）制約条件生成部１７０は、仮想マシン毎のＬＭの日程の確認を行う。制約条件生成部１７０は、ステップＳ３２〜Ｓ３７の手順を、Ｖに属する全ての仮想マシンに対して繰り返し実行する。

（Ｓ３３）制約条件生成部１７０は、仮想マシンｖのＬＭ実施予定日時は利用者により受け入れられたか否かを判定する。受け入れられた場合、制約条件生成部１７０は、ステップＳ３４に処理を進める。受け入れられなかった場合、制約条件生成部１７０は、ステップＳ３６に処理を進める。制約条件生成部１７０は、利用者に提示した仮想マシンｖのＬＭのＬＭ実施予定日時に対する確定または実施拒否日時のメッセージを受け付けることで、ステップＳ３３の判定を行う。確定のメッセージを受け付けた場合、制約条件生成部１７０は、ＬＭ実施予定日時が利用者により受け入れられたと判定する。実施拒否日時のメッセージを受け付けた場合、制約条件生成部１７０は、ＬＭ実施予定日時が利用者により受け入れられなかったと判定する。

（Ｓ３４）制約条件生成部１７０は、集合Ｖ_ａに仮想マシンｖを追加する。
（Ｓ３５）制約条件生成部１７０は、仮想マシンｖのＬＭ実施日時を確定する。具体的には、制約条件生成部１７０は、イベント情報記憶部１６０に記憶されたＬＭスケジュールテーブル１６２における仮想マシンｖのレコードの状態の項目を、“未確定”から“確定”に変更する。そして、制約条件生成部１７０は、ステップＳ３７に処理を進める。

（Ｓ３６）制約条件生成部１７０は、実施拒否日時のメッセージに含まれるＬＭ実施拒否日時情報Ｍ３から、仮想マシンｖのＬＭ実施拒否日時を取得し、制約条件記憶部１５０に格納する。そして、制約条件生成部１７０は、ステップＳ３７に処理を進める。

（Ｓ３７）制約条件生成部１７０は、Ｖに属する全ての仮想マシンｖに対して、利用者による確定または実施拒否日時のメッセージを処理するまでステップＳ３２〜Ｓ３７を繰り返し実行し、全ての仮想マシンｖに対して処理済になると、ステップＳ３８に処理を進める。

（Ｓ３８）制約条件生成部１７０は、Ｖ_ａ＝Ｖであるか（すなわち、集合Ｖ_ａの全要素が集合Ｖの全要素に一致するか）否かを判定する。Ｖ_ａ＝Ｖの場合、制約条件生成部１７０は、ステップＳ４１に処理を進める。Ｖ_ａ＝Ｖでない場合、制約条件生成部１７０は、ステップＳ３９に処理を進める。

（Ｓ３９）制約条件生成部１７０は、制約充足問題の再生成処理を実行する。制約充足問題の再生成処理の詳細は後述される。制約条件生成部１７０は、制約充足問題の再生成処理の結果、複数の制約条件を含む制約充足問題を出力する。

（Ｓ４０）ソルバ部１８０は、ステップＳ３９で出力された制約充足問題の求解を実行し、メンテナンス実施期間の各時刻における出力変数の各値を求める。
（Ｓ４１）ソルバ部１８０は、メンテナンス実施期間の各時刻における出力変数の値から、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を更新する。ソルバ部１８０は、ＬＭスケジュールテーブル１６２においてＬＭスケジュールを更新した仮想マシンの状態の項目を“未確定”から“確定”に変更する。ソルバ部１８０は、再スケジューリング結果として、更新後のメンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を出力する。ソルバ部１８０は、当該再スケジューリング結果をイベント情報記憶部１６０に格納する。

なお、ステップＳ３８でＶ＝Ｖ_ａの場合、利用者によって全ての仮想マシンのＬＭ実施予定日時が受け入れられたことになるため、ステップＳ４１の再スケジューリング結果はステップＳ１３のスケジューリング結果に等しくなる。

また、ステップＳ３６では、制約条件生成部１７０は、仮想マシンｖのＬＭ実施拒否日時を受け付けるものとしたが、ＬＭ実施拒否日時に代えて、ＬＭ実施を許容する日時（ＬＭ実施許容日時）を受け付けてもよい。そして、制約条件生成部１７０は、当該ＬＭ実施許容日時に基づいて制約条件を作成し、ソルバ部１８０による再スケジューリングを行ってもよい。

図２３は、制約充足問題の再生成例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。以下に示す手順は、図２２のステップＳ３９に相当する。

（Ｓ５１）制約条件生成部１７０は、集合Ｖ−Ｖ_ａに属する全ての仮想マシンｖ_ｒをスケジューリング候補に設定する。集合Ｖ−Ｖ_ａは、ＬＭ実施日程が確定していないＶＭの集合である。制約条件生成部１７０は、最初のスケジューリングの結果、利用者によってＬＭの実施予定日時が受け入れられた仮想マシンについては最初のスケジューリングの結果として得られたＬＭの実施予定日時を固定する。そして、制約条件生成部１７０は、ＬＭ実施予定日時が受け入れられなかった仮想マシンｖ_ｒを再スケジューリングの候補とする。

（Ｓ５２）制約条件生成部１７０は、仮想マシンｖ_ｒのＬＭ実施拒否日時、および、仮想マシンｖ_ａ（仮想マシンｖ_ａは、集合Ｖ_ａの全要素）のＬＭ実施日時をＬＭ実施の候補日時から除外する。具体的には、制約条件生成部１７０は、仮想マシンｖ_ｒのＬＭ実施拒否日時については対象の仮想マシンｖ_ｒについてのみ、候補日時から除外する（仮想マシンｖ_ｒ以外の仮想マシンについては仮想マシンｖ_ｒのＬＭ実施拒否日時を候補日時から除外しない）。また、制約条件生成部１７０は、仮想マシンｖ_ａのＬＭ実施日時を、全仮想マシンについて候補日から除外する。制約条件生成部１７０は、これらの除外内容を、ａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）の値に反映させる。

ここで、仮想マシンｖ_ｒのＬＭ実施拒否日時は、ＬＭ実施拒否日時情報Ｍ３から取得された情報（制約条件記憶部１５０に格納されている）である。また、仮想マシンｖ_ａのＬＭ実施日時は、ＬＭスケジュールテーブル１６２に登録されている情報である。

（Ｓ５３）制約条件生成部１７０は、変換後の仮想マシンの負荷予測に基づいて、仮想マシン（ＶＭ）負荷が小さいとき（すなわち、各仮想マシンのＬＭ所要時間が小さいとき）にＬＭを実施するように制約条件（ＬＭ実施時間に関する制約条件）を生成する。ＬＭ実施時間に関する制約条件は、例えば、前述の第２、第３、第６〜第１０および第１３の制約条件である。ただし、ＬＭ実施予定日時が確定済の仮想マシンに関しては決定済の各種変数の値は固定である。制約条件生成部１７０は、生成した制約条件を制約条件記憶部１５０に格納する。

（Ｓ５４）制約条件生成部１７０は、ステップＳ２２で生成したＶＭの依存関係に関する制約条件とステップＳ５３で生成したＬＭ実施時間に関する制約条件を基に制約充足問題を設定する。

なお、ステップＳ５２では、ＬＭスケジュールを確定済の仮想マシンｖ_ａのＬＭ実施日時を候補日時から除外するものとした。その理由は、ＬＭを並列に行う多重度が増加し過ぎて、システム負荷の増大を抑えるためである。一方、システム負荷の増大が懸念されないのであれば、仮想マシンｖ_ａのＬＭ実施日時を候補日時から除外しなくてもよい。

以下では、ソルバ部１８０に対する入力データ、および、当該入力データに対してソルバ部１８０の出力データを例示する。
図２４は、ソルバ部に対する入力データの例（その１）を示す図である。例えば、入力データは、変数ｔ_ｓ、ｔ_ｅ、Ｐ、ｍａｉｎｔＤｕｒａｔｉｏｎ_ｐ、ｃｐｕＣａｐ_ｐ、ｒａｍＣａｐ_ｐおよびｄｉｓｋＣａｐ_ｐを含む。

ｔ_ｓ：＝０；およびｔ_ｅ：＝４１７５９；はメンテナンス実施期間を示す（ここで、“：＝”は代入を表し、“；”は当該変数への代入終了を表す）。ｔ_ｓ：＝０は、メンテナンス実施期間の開始日時である２０１７年６月１日１２時００分を示す。ｔ_ｅ：＝４１７５９は、メンテナンス実施期間の終了日時である２０１７年６月３０日１１時５９分を示す。Ｔは、ｔ_ｓを基準にｔ_ｅまでの時刻を分単位に離散化した値の集合となる。

Ｐ：＝“ＰＭ０１”、“ＰＭ０２”、・・・；は、物理マシン名（ＰＭ名）の集合である（図中では各行が物理マシン名となる）。
ｍａｉｎｔＤｕｒａｔｉｏｎ_ｐ：＝（“ＰＭ０１” ６０）、（“ＰＭ０２” １２０）、・・・；は、物理マシン毎のメンテナンスの所要時間（単位は分）である。１つのレコードは、（物理マシン名（ＰＭ名） メンテナンスの所要時間）の組となる。なお、図中では１行が１つのレコードとなる（入力データに含まれる以降の他の変数についても同様である）。

ｃｐｕＣａｐ_ｐ：＝（“ＰＭ０１” ６４）、（“ＰＭ０２” ３２）、・・・；は、物理マシン毎のＣＰＵコア数である。１つのレコードは、（ＰＭ名 ＣＰＵコア数）の組となる。

ｒａｍＣａｐ_ｐ：＝（“ＰＭ０１” ２５６）、（“ＰＭ０２” １２８）、・・・；は、物理マシン毎のメモリ容量である。１つのレコードは、（ＰＭ名 メモリ容量）の組となる。

ｄｉｓｋＣａｐ_ｐ：＝（“ＰＭ０１” ３２０００）、（“ＰＭ０２” １２８０００）、・・・；は、物理マシン毎のディスク容量である。１つのレコードは、（ＰＭ名 ディスク容量）の組となる。

図２５は、ソルバ部に対する入力データの例（その２）を示す図である。入力データは、更に、変数ＶおよびｉｎｉｔＡｃｃｏｍｍｏ_ｐｖを含む。
Ｖ：＝“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”、“ｖｍ−６７”、・・・；は、仮想マシン名（ＶＭ名）の集合である。

ｉｎｉｔＡｃｃｏｍｍｏ_ｐｖ：＝（・・・、“ＰＭ０１” “ｍｙｓｑｌ−６７” １）、（“ＰＭ０２” “ｍｙｓｑｌ−６７” ０）、（“ＰＭ０１” “ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３” １）、（“ＰＭ０２” “ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３” ０）、・・・；は、各仮想マシンの初期配置先の物理マシンを示す。１つのレコードは、（ＰＭ名 仮想マシン名（ＶＭ名） ０ｏｒ１）の組となる（最後の値は、該当の物理マシンが該当の仮想マシンの初期配置先であれば“１”、初期配置先でなければ“０”である）。

図２６は、ソルバ部に対する入力データの例（その３）を示す図である。入力データは、更に、変数ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）を含む。
ｍｉｇｒａｔｉｏｎＤｕｒａｔｉｏｎ_ｖ（ｔ）：＝・・・、（“ｓｅｒｖｅｒ−９０” ２７１８０ １５）、（“ｍｙｓｑｌ−６７” ２７１８０ １５）、・・・、（“ｓｅｒｖｅｒ−９０” ２７２３９ １５）、（“ｍｙｓｑｌ−６７” ２７２３９ １５）、・・・；は、仮想マシン毎のＬＭの所要時間である。１つのレコードは、（ＶＭ名 時刻 ＬＭの所要時間（分））の組となる。

ここで、図中の時刻“２７１８０”は、２０１７年６月２０日９時００分を示す。時刻“２７２３９”は、２０１７年６月２０日９時５９分を示す。時刻“２７２４０”は、２０１７年６月２０日１０時００分を示す。時刻“２７２４１”は、２０１７年６月２０日１０時０１分を示す。

図２７は、ソルバ部に対する入力データの例（その４）を示す図である。入力データは、更に、変数ｃｐｕＲｅｑ_ｖ、ｒａｍＲｅｑ_ｖおよびｄｉｓｋＲｅｑ_ｖを含む。
ｃｐｕＲｅｑ_ｖ：＝（“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３” ２）、（“ｖｍ−６７” ２）、・・・；は、仮想マシン毎に割り当てるＣＰＵコア数である。１つのレコードは、（ＶＭ名 ＣＰＵコア数）の組となる。

ｒａｍＲｅｑ_ｖ：＝（“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３” ３２）、（“ｖｍ−６７” ２）、・・・；は、仮想マシン毎に割り当てるメモリ容量である。１つのレコードは、（ＶＭ名 メモリ容量）となる。

ｄｉｓｋＲｅｑ_ｖ：＝（“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３” ２０００）、（“ｖｍ−６７” ３２）、・・・；は、仮想マシン毎に割り当てるディスク容量である。１つのレコードは、（ＶＭ名 ディスク容量）となる。

図２８は、ソルバ部に対する入力データの例（その５）を示す図である。入力データは、更に、変数ａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）、Ｇ_ａａ＿１およびＧ_ａｆ＿１を含む。

ａｖａｉｌＭｉｇｒａｔｉｏｎＴｉｍｅＳｌｏｔ_ｖ（ｔ）：＝・・・、（“ｍｙｓｑｌ−６７” ２７２９８ １）、（“ｍｙｓｑｌ−６７” ２７２９９ １）、（“ｍｙｓｑｌ−６７” ２７３００ ０）、（“ｍｙｓｑｌ−６７” ２７３０１ ０）、・・・；は、仮想マシン後のＬＭの実施許可期間または実施拒否期間を示す。実施許可は“１”であり、実施拒否は“０”である。１つのレコードは、（ＶＭ名 時刻 ０ｏｒ１）となる。

ここで、図中の時刻“２７２９８”は、２０１７年６月２０日１０時５８分を示す。時刻“２７２９９”は、２０１７年６月２０日１０時５９分を示す。時刻“２７３００”は、２０１７年６月２０日１１時００分を示す。時刻“２７３０１”は、２０１７年６月２０日１１時０１分を示す。

Ｇ_ａａ＿１：＝“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−１３”、“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”；は、ａｎｔｉ−ａｆｆｉｎｉｔｙルールの適用対象の１つ目のグループおよび当該グループに属する仮想マシンを示す。ａｎｔｉ−ａｆｆｉｎｉｔｙルールの適用対象の２つ目以降のグループも同様に設定される。

Ｇ_ａｆ＿１：＝“ａｃｃｏｕｎｔｉｎｇ−ｄｂ−０３”、“ａｃｃｏｕｎｔｉｎｇ−ｗｅｂ−０３”；は、ａｆｆｉｎｉｔｙルールの適用対象の１つ目のグループおよび当該グループに属する仮想マシンを示す。ａｆｆｉｎｉｔｙルールの適用対象の２つ目以降のグループも同様に設定される。

図２９は、ソルバ部による出力データの例（その１）を示す図である。例えば、ソルバ部１８０は、制約条件生成部１７０により設定された制約充足問題を解くことで、次の出力データを出力する。出力データは、変数ｍ_ｐ（ｔ）およびａ_ｐｖ（ｔ）を含む。

ｍ_ｐ（ｔ）＝・・・、（“ＰＭ０１” ２７２６８ ０）、（“ＰＭ０１” ２７２６９ ０）、（“ＰＭ０１” ２７２７０ １）、（“ＰＭ０１ ” ２７２７１ １）、・・・；は、物理マシン毎のメンテナンス実施期間を示す。１つのレコードは、（ＰＭ名 時刻 ０ｏｒ１）の組である（最後の値は、該当ＰＭが該当時刻にメンテナンス中であれば“１”、メンテナンス中でなければ“０”である）。

ここで、図中の時刻“２７２６８”は、２０１７年６月２０日１０時２８分を示す。時刻“２７２６９”は、２０１７年６月２０日１０時２９分を示す。時刻“２７２７０”は、２０１７年６月２０日１０時３０分を示す。時刻“２７２７１”は、２０１７年６月２０日１０時３１分を示す。

ａ_ｐｖ（ｔ）＝・・・、（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２３８ １）、（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２３９ １）、（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２４０ ０）、（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２４１ ０）、・・・；は、各ＰＭで稼働するＶＭを示す。１つのレコードは、（ＰＭ名 ＶＭ名 時刻 ０ｏｒ１）の組である（最後の値は、該当のＰＭ上で該当のＶＭが稼働している場合は“１”、稼働していない場合は“０”である）。

ここで、図中の時刻“２７２３８”は、２０１７年６月２０日９時５８分を示す。時刻“２７２３９”は、２０１７年６月２０日９時５９分を示す。時刻“２７２４０”は、２０１７年６月２０日１０時００分を示す。時刻“２７２４１”は、２０１７年６月２０日１０時０１分を示す。

図３０は、ソルバ部による出力データの例（その２）を示す図である。出力データは、更に、変数ｌ_ｐｖ（ｔ）を含む。
ｌ_ｐｖ（ｔ）＝（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２３８ ０）、（“ＰＭ０１” “ｓｅｒｖｅｒ−９０” ２７２３９ ０）、・・・、（“ＰＭ０２” “ｓｅｒｖｅｒ−９０” ２７２３８ ０）、（“ＰＭ０２” “ｓｅｒｖｅｒ−９０” ２７２３９ １）、（“ＰＭ０２” “ｓｅｒｖｅｒ−９０” ２７２４０ ０）、・・・；は、各仮想マシンの移動先物理マシンへのＬＭ完了時刻を示す。１つのレコードは、（ＰＭ名 ＶＭ名 時刻 ０ｏｒ１）の組である（最後の値は、該当のＰＭ上への該当のＶＭのＬＭが完了した時刻の場合は“１”、それ以外の場合は“０”である）。

ここで、図中の時刻“２７２３８”は、２０１７年６月２０日９時５８分を示す。時刻“２７２３９”は、２０１７年６月２０日９時５９分を示す。時刻“２７２４０”は、２０１７年６月２０日１０時００分を示す。時刻“２７２４１”は、２０１７年６月２０日１０時０１分を示す。時刻“２７２４８”は、２０１７年６月２０日１０時０８分を示す。時刻“２７２４９”は、２０１７年６月２０日１０時０９分を示す。時刻“２７２５０”は、２０１７年６月２０日１０時１０分を示す。時刻“２７２５１”は、２０１７年６月２０日１０時１１分を示す。

ソルバ部１８０は、出力データの内容から各仮想マシンに対するＬＭスケジュールを得る。例えば、ｌ_ｐｖ（ｔ）の出力結果によれば、“ｓｅｒｖｅｒ−９０”について“ＰＭ０２”へのＬＭ終了時刻は“２７２３９”である。また、ＬＭ所要時間テーブル１３１によれば、時刻“２７２３９”（２０１７年６月２０日９時５９分）に仮想マシン名“ｓｅｖｅｒ−９０”の仮想マシンのＬＭを完了させるときのＬＭの所要時間は１５分である。したがって、ソルバ部１８０は、“ｓｅｒｖｅｒ−９０”に対するＬＭスケジュールを、時刻“２７２２５”〜“２７２３９”の１５タイムスロットの期間と決定する。

ソルバ部１８０は、出力データで示される期間を年月日時分秒の形式に変換し、メンテナンススケジュールテーブル１６１およびＬＭスケジュールテーブル１６２を作成する。
スケジューラ１１２は、ソルバ部１８０により作成したＬＭスケジュールを利用者に提示し、利用者による確認を促す。次に、管理サーバ１００により利用者端末５００に提供される画面の例を説明する。

図３１は、利用者に対するＬＭスケジュール画面の例（その１）を示す図である。画面８００は、管理サーバ１００から利用者端末５００に対して提供される画面の例である。利用者端末５００は、画面８００に対応する画面情報を管理サーバ１００から受信し、当該画面情報に基づいて、利用者端末５００に内蔵または接続されたディスプレイ（表示装置）により、画面８００を表示する。ここで、利用者端末５００は、ユーザＩＤ“ｕｓｅｒ３”の利用者によって利用されるものとし、当該利用者のユーザ名を“ＡＡＡ”とする。

スケジューラ１１２は、仮想マシン構成テーブル１２２（または、仮想マシン稼働テーブル１２３）に基づいて、ＬＭスケジュールテーブル１６２に登録された各仮想マシンの利用者のユーザＩＤを特定する。また、ユーザＩＤに対応する利用者のユーザ名や端末のアドレスの情報は、ＲＡＭ１０２またはＨＤＤ１０３に予め格納されている。スケジューラ１１２は、当該情報を参照することで、ユーザ名や画面情報の送信先を特定する。

画面８００は、ＶＭシンボル８０１，８０２、ＬＭシンボル８１１，８１２、予測負荷シンボル群８２１，８２２およびボタン８３１，８３２を有する。
ＶＭシンボル８０１，８０２は、該当の利用者が利用する、ＬＭ対象の仮想マシンを示す。例えば、ＶＭシンボル８０１は、仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンを示す。また、ＶＭシンボル８０２は、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンを示す。画面８００の例では、ＶＭシンボル８０１，８０２それぞれの行の左側から右側へ向かう方向を時系列の正方向として、各仮想マシンのＬＭスケジュールを示す。

ＬＭシンボル８１１，８１２は、各仮想マシンのＬＭの実施予定の日時を示す。例えば、ＬＭシンボル８１１は、仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンに対して、２０１７年６月２０日９時４５分〜同日９時５９分にＬＭを実施することを示す。また、例えば、ＬＭシンボル８１２は、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンに対して、２０１７年６月２０日１１時００分〜同日１１時０９分にＬＭを実施することを示す。

予測負荷シンボル群８２１，８２２は、各時刻における各仮想マシンの予測負荷を示す。例えば、予測負荷シンボル群８２１，８２２に属するシンボルは円状の図形であり、円の大きさにより負荷の大きさを表す（円の直径が大きいほど予測負荷が大きく、円の直径が小さいほど予測負荷が小さい）。仮想マシンの予測負荷は、ＬＭスケジュールの決定の根拠となる情報であり、利用者は、予測負荷シンボル群８２１，８２２を確認することで、各仮想マシンの負荷と、ＬＭスケジュールとの整合（負荷の小さいときにＬＭを行う）を確認することができる。

ボタン８３１は、画面８００のＬＭスケジュールの確定を入力するためのボタンである。利用者端末５００は、利用者によるボタン８３１の入力を受け付けると、画面８００に表示された各仮想マシンについて、ＬＭスケジュールの確定メッセージを管理サーバ１００に送信する。

ボタン８３２は、画面８００のＬＭスケジュールを変更するための画面へ遷移するためのボタンである。
図３２は、利用者に対するＬＭスケジュール画面の例（その２）を示す図である。画面８００ａは、画面８００のＬＭスケジュールに対する変更内容（ＬＭ実施拒否日時）を入力するための画面である。画面８００ａは、利用者によるボタン８３２への入力に応じて、管理サーバ１００から利用者端末５００に提供される画面である。画面８００ａは、ＶＭシンボル８０１，８０２、ＬＭシンボル８１１，８１２、予測負荷シンボル群８２１，８２２、ボタン８３３，８３４およびＬＭ実施拒否日時シンボル８４１を有する。

ボタン８３３は、ＬＭ実施拒否日時シンボル８４１によるＬＭ実施拒否日時の選択を解除するためのボタンである。
ボタン８３４は、ＬＭ実施拒否日時シンボル８４１を用いて選択されたＬＭ実施拒否日時を設定するためのボタンである。利用者端末５００は、ボタン８３４に対する入力を受け付けると、選択された仮想マシンのＬＭ実施拒否日時を示すＬＭ実施拒否日時情報Ｍ３を含む拒否日時メッセージを管理サーバ１００に送信する。なお、画面８００ａにおいて、ＬＭ実施拒否日時が選択されていない仮想マシンについては、利用者端末５００は、確定メッセージを管理サーバ１００に送信する。

ＬＭ実施拒否日時シンボル８４１は、利用者によるＬＭ実施拒否日時の選択を受け付けるためのシンボルである。例えば、利用者は、利用者端末５００に接続されたポインティングデバイスを用いて、所望の仮想マシンの行にＬＭ実施拒否日時シンボル８４１を配置する。そして、利用者は、当該ポインティングデバイスを用いて、ＬＭ実施拒否日時シンボル８４１の横方向の幅を変えることで、当該仮想マシンに対するＬＭ実施拒否日時を選択する。利用者は、ＬＭ実施拒否日時シンボル８４１をＬＭシンボル８１２に重ねて配置することができる。ＬＭ実施拒否日時シンボル８４１の例では、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンに対するＬＭ実施拒否日時として、２０１７年６月２０日１１時００分〜同日１３時５９分が選択されている。

管理サーバ１００は、画面８００ａによりＬＭ実施拒否日時情報Ｍ３を受け付けると、ＬＭ実施時間に関する制約条件を再作成し、ＬＭ実施拒否日時が入力された仮想マシンについてＬＭスケジュールを更新する。管理サーバ１００は、更新したＬＭスケジュールを利用者に再度提示する。

図３３は、利用者に対するＬＭスケジュール画面の例（その３）を示す図である。画面８００ｂは、管理サーバ１００から利用者端末５００に対して提供される画面の例である。画面８００ｂは、画面８００ａによるＬＭ実施拒否日時の選択に応じて更新されたＬＭスケジュールを示す。画面８００ｂは、ＶＭシンボル８０１，８０２、ＬＭシンボル８１１，８１３、予測負荷シンボル群８２１，８２２、ボタン８３５およびＬＭ実施拒否日時シンボル８４１を有する。

ＬＭシンボル８１３は、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンに対し、利用者により入力されたＬＭ実施拒否日時（ＬＭ実施拒否日時シンボル８４１で示されるＬＭ実施拒否日時）に基づいて再作成されたＬＭスケジュールを示す。具体的には、ＬＭシンボル８１３は、仮想マシン名“ｍｙｓｑｌ−６７”の仮想マシンに対して、２０１７年６月２０日１０時００分〜同日１０時０９分にＬＭを実施することを示す。

なお、画面８００ａでは、仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンに対しては、ＬＭ実施拒否日時が選択されなかったので、仮想マシン名“ｓｅｒｖｅｒ−９０”の仮想マシンについては最初に決定されたＬＭスケジュールから更新されていない。

ボタン８３５は、仮想マシンのＬＭスケジュールの確認を終了するためのボタンである。利用者端末５００は、ボタン８３５の入力を受け付けると、画面８００ｂを閉じる。
上記の例では、利用者端末５００に提供される画面８００，８００ａ，８００ｂを例示したが、利用者端末６００にも当該利用者端末６００の利用者が利用する仮想マシンに関してＬＭスケジュールを確認するための画面が提供される。

図３４は、運用者に対するメンテナンススケジュール画面の例を示す図である。画面９００は、管理サーバ１００から運用者端末７００に対して提供される画面の例である。画面９００は、画面８００ｂで示される更新後のＬＭスケジュールに対応する物理マシンのメンテナンススケジュールを示す。運用者端末７００は、画面９００を描画するための画面情報を管理サーバ１００から受信し、当該画面情報に基づいて、運用者端末７００に内蔵または接続されたディスプレイ（表示装置）により、画面９００を表示する。ここで、利用者のユーザ名を“ａａａ”とする。

画面９００は、ＰＭシンボル９０１，９０２、ＶＭスケジュールシンボル９１１，９１２およびメンテナンスシンボル９１３を有する。
ＰＭシンボル９０１，９０２は、メンテナンス対象の物理マシンを示す。例えば、ＰＭシンボル９０１は、物理マシン名“ＰＭ０１”の物理マシンを示す。また、ＰＭシンボル９０２は、物理マシン名“ＰＭ０２”の物理マシンを示す。画面９００の例では、ＰＭシンボル９０１，９０２それぞれの行の左側から右側へ向かう方向を時系列の正方向として、各物理マシン上の仮想マシンの稼働予定、ＬＭ予定およびメンテナンススケジュールを示す。

ＶＭスケジュールシンボル９１１，９１２は、各仮想マシンの稼働予定およびＬＭ予定を示す。ＶＭスケジュールシンボル９１１，９１２は、ＬＭスケジュールテーブル１６２の内容（各仮想マシンに対してＬＭスケジュールが“確定”された結果）を反映している。例えば、ＶＭスケジュールシンボル９１１は、物理マシン名“ＰＭ０１”上の複数の仮想マシンの稼働予定と、当該複数の仮想マシンのＬＭ予定とを示す。また、ＶＭスケジュールシンボル９１２は、物理マシン名“ＰＭ０２”上の複数の仮想マシンの稼働予定と、当該複数の仮想マシンのＬＭ予定とを示す。ＶＭスケジュールシンボル９１１，９１２によれば、運用者は、各仮想マシンがＬＭ実施前には物理マシン名“ＰＭ０１”の物理マシンで稼働し、ＬＭ実施後には物理マシン名“ＰＭ０２”の物理マシンで稼働することを把握できる。

メンテナンスシンボル９１３は、物理マシンのメンテナンススケジュールを示すシンボルである。メンテナンスシンボル９１３は、メンテナンススケジュールテーブル１６１の内容を反映しており、物理マシン名“ＰＭ０１”の物理マシンに対するメンテナンススケジュールを示す。メンテナンスシンボル９１３の例では、物理マシン名“ＰＭ０１”の物理マシンに対して、２０１７年６月２０日１０時３０分〜同日１１時２９分の期間に、メンテナンスを行うことを示す。

このように、管理サーバ１００は、インフラ構成情報に基づくＶＭの依存関係に関する制約条件や、ＬＭ所要時間テーブル１３１に基づくＬＭ実施時間に関する制約条件を作成することで、当該制約条件により、仮想マシンの適切なＬＭスケジュールを作成できる。

例えば、管理サーバ１００は、ＶＭの依存関係に関する制約条件に基づいて、物理マシンおよび仮想マシンの運用上の構成要件を逸脱しないように、仮想マシンのＬＭスケジュールを決定することができる。

特に、ＶＭの依存関係に関する制約条件は、依存関係テーブル１２４に基づく制約条件を含む。ここで、例えば、利用者の仮想マシンの利用への影響時間の最小化のみを目的として移動スケジュールを作成すると、運用上の意図がある仮想マシンの依存関係を満たせなくなる可能性がある。

一例としては、性能向上のために同一の物理マシンに配備すべきアプリケーションを実行する仮想マシンとＤＢを実行する仮想マシンとを、別個の物理マシンに移動させてしまうことが考えられる。そこで、管理サーバ１００は、例えば、インフラ構成情報に含まれる仮想マシンの第１のグループを同一の物理マシンで動作させる第１の制約条件を作成し、第１の制約条件に基づいて、第１のグループに属する各仮想マシンの移動先を同一の物理マシンとする。

あるいは、冗長化のために別個の物理マシンに配備すべきソフトウェアを実行する仮想マシン同士を、共通の物理マシンに移動させてしまうことも考えられる。そこで、管理サーバ１００は、例えば、インフラ構成情報に含まれる仮想マシンの第２のグループに属する各仮想マシンをそれぞれ別個の物理マシンで動作させる第２の制約条件を作成する。そして、管理サーバ１００は、第２の制約条件に基づいて、第２のグループに属する各仮想マシンの移動先をそれぞれ別個の物理マシンとする。

このように、インフラ構成情報（特に、依存関係テーブル１２４）で示される依存関係も制約条件として用いることで、運用上意図しない仮想マシンの配置を抑制でき、仮想マシンの性能が低下することを抑えられる。

また、ＬＭのタイミングの決定について、例えば、利用者に業務都合を予め入力させ、入力された業務都合を基にＬＭスケジュールを決定することも考えられる。しかし、利用者が考える業務の繁忙と仮想マシンの負荷の大きさとが乖離していることもある。例えば、主に昼間に利用する人事業務のアプリケーションを実行する仮想マシンであるため、利用者がＬＭスケジュールを夜間としたが、夜間は当該仮想マシンで高負荷のバッチ処理を行っており、ＬＭによる性能低下で当該バッチ処理を完了できないこともある。このように、利用者の感覚だけでは、利用者の業務への影響を最小にするＬＭスケジュールを作成できるとは限らない。

そこで、管理サーバ１００は、ＬＭ実施時間に関する制約条件に基づいて、仮想マシンのＬＭの所要時間の総和（移動対象が複数の仮想マシンの場合は複数の仮想マシンの移動時間の総和）を最小にするように、仮想マシンのＬＭスケジュールを決定する。すなわち、管理サーバ１００は、仮想マシン毎のＬＭの所要時間を示す時間情報（例えば、ＬＭ所要時間テーブル１３１）に基づいて複数の仮想マシンのＬＭの所要時間の和を最小にする第３の制約条件を作成する。そして、管理サーバ１００は、第３の制約条件に基づいて複数の仮想マシンのＬＭの所要時間の和を最小にするスケジュールを決定する。これにより、各利用者による仮想マシンの利用に対する影響を抑えて仮想マシンのＬＭスケジュールを決定できる。

更に、管理サーバ１００は、最初に作成した仮想マシンのＬＭスケジュールに対し、利用者の確認を促し、利用者によるＬＭ実施拒否期間の入力を許容する。これにより、利用者の業務都合に整合しないスケジュールでＬＭが実施されることを抑制でき、利用者による仮想マシンの利用への影響を一層抑えた、より適切なＬＭスケジュールを決定できる。

なお、第１の実施の形態の情報処理は、処理部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。

例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１ 調整装置
１ａ 記憶部
１ｂ 処理部
２，３，４，・・・ 物理マシン
２ａ，２ｂ，３ａ，３ｂ，４ａ，４ｂ，・・・ 仮想マシン
５ 端末装置
Ｄ１ 構成情報
ｄ１ 物理マシン構成情報
ｄ２ 仮想マシン構成情報
ｄ３ 依存関係情報
Ｄ２ 時間情報
Ｎ１ ネットワーク
Ｕ１ ユーザ

Claims (12)

1. 物理マシンに関するメンテナンスの実施期間を取得すると、前記物理マシンおよび前記物理マシンで動作する仮想マシンに関する構成情報および前記物理マシンから他の物理マシンへの前記仮想マシンの移動の所要時間を示す時間情報から前記移動のスケジュールを決定するための制約条件を前記仮想マシンに対して作成し、
   前記制約条件および前記実施期間に基づいて前記移動のスケジュール情報を作成し、
   前記仮想マシンのユーザが使用する装置に前記スケジュール情報を出力する、
   処理をコンピュータに実行させる調整プログラム。
2. 出力した前記スケジュール情報に対して前記ユーザにより入力された前記移動の禁止時間帯または前記移動の許容時間帯を取得し、前記禁止時間帯または前記許容時間帯に基づいて前記制約条件を再作成し、再作成した前記制約条件に基づいて前記スケジュール情報を再作成し、再作成した前記スケジュール情報を前記装置に出力する、請求項１記載の調整プログラム。
3. 前記スケジュール情報と共に前記スケジュール情報に含まれる各時刻に対して予測される前記仮想マシンの負荷を示す情報を前記装置に出力する、請求項１または２記載の調整プログラム。
4. 前記時間情報は、前記実施期間に属する各時刻における仮想マシン毎の前記移動の所要時間を示す情報である、請求項１乃至３の何れか１項に記載の調整プログラム。
5. 前記スケジュール情報の作成では、更に、前記物理マシンのメンテナンスの所要時間に基づいて、前記実施期間のうち、前記物理マシンに対してメンテナンスを行う期間を決定する、請求項１乃至４の何れか１項に記載の調整プログラム。
6. 前記制約条件の作成では、前記構成情報に含まれる前記仮想マシンの第１のグループに属する各仮想マシンを同一の物理マシンで動作させる第１の制約条件を作成し、
   前記スケジュール情報の作成では、前記第１の制約条件に基づいて、前記第１のグループに属する各仮想マシンの移動先を同一の物理マシンとする、
   請求項１乃至５の何れか１項に記載の調整プログラム。
7. 前記制約条件の作成では、前記構成情報に含まれる前記仮想マシンの第２のグループに属する各仮想マシンをそれぞれ別個の物理マシンで動作させる第２の制約条件を作成し、
   前記スケジュール情報の作成では、前記第２の制約条件に基づいて、前記第２のグループに属する各仮想マシンの移動先をそれぞれ別個の物理マシンとする、
   請求項１乃至６の何れか１項に記載の調整プログラム。
8. 前記制約条件の作成では、前記時間情報に基づいて複数の前記仮想マシンの前記移動の所要時間の和を最小にする第３の制約条件を作成し、
   前記スケジュール情報の作成では、前記第３の制約条件に基づいて前記和を最小にするスケジュールを決定する、
   請求項１乃至７の何れか１項に記載の調整プログラム。
9. 作成した前記スケジュール情報に基づいて、前記仮想マシンの前記移動を前記物理マシンに指示する、請求項１乃至８の何れか１項に記載の調整プログラム。
10. 前記移動の所要時間は、ライブマイグレーションの所要時間である、請求項１乃至９の何れか１項に記載の調整プログラム。
11. 物理マシンおよび前記物理マシンで動作する仮想マシンに関する構成情報と前記物理マシンから他の物理マシンへの前記仮想マシンの移動の所要時間を示す時間情報とを記憶する記憶部と、
    前記物理マシンに関するメンテナンスの実施期間を取得すると、前記記憶部に記憶された前記構成情報および前記時間情報から前記移動のスケジュールを決定するための制約条件を前記仮想マシンに対して作成し、前記制約条件および前記実施期間に基づいて前記移動のスケジュール情報を作成し、前記仮想マシンのユーザが使用する装置に前記スケジュール情報を出力する処理部と、
    を有する調整装置。
12. コンピュータが、
    物理マシンに関するメンテナンスの実施期間を取得すると、前記物理マシンおよび前記物理マシンで動作する仮想マシンに関する構成情報および前記物理マシンから他の物理マシンへの前記仮想マシンの移動の所要時間を示す時間情報から前記移動のスケジュールを決定するための制約条件を前記仮想マシンに対して作成し、
    前記制約条件および前記実施期間に基づいて前記移動のスケジュール情報を作成し、
    前記仮想マシンのユーザが使用する装置に前記スケジュール情報を出力する、
    調整方法。

Images