JP6394455B2 - 情報処理システム、管理装置およびプログラム - Google Patents

Description

本発明は、情報処理システム、管理装置およびプログラムに関する。

いわゆるクラウドコンピューティング環境では、仮想化されたアプリケーション実行環境が利用者に提供される。仮想化されたアプリケーション実行環境としては、例えばハイパーバイザ型仮想化環境がある。ハイパーバイザ型仮想化では、利用者に対して仮想マシン（以下、「ＶＭ」と記す）の実行環境であるＶＭゲスト環境が提供される。ＶＭは、ＶＭのホストとなるホストコンピュータ（又は「サーバ」とも記す）のハードウェアを仮想化したものであり、ＶＭ上でオペレーティング・システム（ＯＳ）が起動され、ＶＭ上で動作するＯＳ上でアプリケーションプログラムが実行される。

ハイパーバイザ型仮想化環境では、ホストコンピュータの保守作業やホストコンピュータの障害が発生した場合に、ＶＭを停止せずに保守対象のホストコンピュータから他のホストコンピュータにＶＭを動的に移動させるライブマイグレーションを行うことで業務を継続できる。以下、ＶＭの移動又はＶＭ上で実行されるアプリケーションプログラムのプロセス等の移動を「マイグレーション」と記す。

ここで、サーバの仮想化に関する従来技術には次のようなものがある。まず、各仮想マシンの負荷の相関関係から各仮想マシンの相対的な最大負荷量を予測し、予測された各仮想マシンの最大負荷量に基づいて仮想マシンを各仮想マシンサーバ（物理マシン）へ配置する技術が知られている（例えば、特許文献１参照）。また、仮想マシンを実行するプロセッサが、ソフトウェア処理を実行する際に使用するリソース量に基づいて消費電力を算出し、算出結果に応じて複数のプロセッサ間でソフトウェア処理を移行する技術が知られている（例えば、特許文献２参照）。さらに、仮想計算機を移動させる際に、移動先の物理計算機の負荷が過大になるのを防ぐため、移動先の物理計算機の負荷を見積もり、移動先の物理計算機の負荷が許容範囲内であれば仮想計算機の移動を実施する技術も知られている（例えば、特許文献３参照）。

特開２０１０−２４４１８１号公報 特開２０１０−２０５２００号公報 ＷＯ２０１２／１２０６６４号公報

近年、コンテナ型仮想化によるアプリケーション実行環境が普及しはじめている。コンテナ型仮想化は、ＶＭのようなサーバのハードウェアを仮想化したものとは異なり、ＯＳのプロセス空間を複数のグループに区切って別のサーバのように利用する技術である。そのため、コンテナ型仮想化は、「ＯＳの仮想化」とも呼ばれる。コンテナ型仮想化技術の例としては、Ｄｏｃｋｅｒ社が提供するコンテナ型仮想化環境であるＤｏｃｋｅｒ（登録商標）や、Ｓｏｌａｒｉｓ（登録商標）コンテナ、ＢＳＤのＪａｉｌなどが知られている。

コンテナ型仮想化環境では、ホストＯＳに仮想化機能を組み込み、複数の仮想的なアプリケーション実行環境（仮想ＯＳ）が作成される。コンテナ型仮想化環境において作成される、仮想的なアプリケーション実行環境である仮想ＯＳを、以下、「コンテナ」と記載して説明する。

コンテナ型仮想化では、単一のＯＳ環境の内部を分割し、ＯＳのアプリケーションの実行に関する部分だけを個別に作成する。ＯＳ環境の基本的な部分（カーネル等）はコンテナ間で共有され、コンテナごとに設定を変えたい部分など、コンテナごとに固有のＯＳの部分だけを個別に作成する。各コンテナにおいては、独立したアプリケーション実行環境が提供される。そのため、複数の利用者による仮想化環境を用いた業務処理の運用管理がより容易となる。

コンテナ型仮想化では、ハイパーバイザを介した処理は行われないため、サーバ装置の物理資源を使用する際のオーバーヘッドが小さく、仮想化環境の動作が高速である。また、複数のコンテナ間でＯＳの基本的な部分を共有することからメモリ資源の使用を抑えることができ、多くのアプリケーションを起動できる。さらに、コンテナを新たに作成する度に新しくＯＳ全体を起動する必要がないため、コンテナの起動が早く、コンテナの環境構築も容易であるといった利点もある。

ここで、ハイパーバイザ型仮想化とコンテナ型仮想化とを比較して説明すると、ハイパーバイザ型仮想化では、ＶＭごとにゲストＯＳを起動させるので、ＶＭごとに異なるＯＳを実行することができる。一方、コンテナ型仮想化では、ベースとなるＯＳは一つしか存在しないため、異なるＯＳ用のアプリケーションを同時に実行できない。また、コンテナ型仮想化では、ハイパーバイザ型仮想化と異なり、ライブマイグレーションができない。

そこで、ハイパーバイザ型仮想化とコンテナ型仮想化とを組み合わせて実行するハイブリッド型仮想化も適用され始めてきている。ハイブリッド型仮想化では、ＶＭによるライブマイグレーションの利点と、コンテナによる業務プロセス管理が容易になるという利点が得られる。

ハイブリッド型仮想化では、ホストコンピュータの障害等が発生した場合、複数のコンテナを動作させているＶＭを他のホストコンピュータにライブマイグレーションすることで、業務を継続できる。ライブマイグレーションでは、保守対象となったホストコンピュータのメモリ上に展開されているＶＭの情報を、移動先のホストコンピュータのメモリへ送信する。また、移動元と移動先のホストコンピュータで共有するストレージ装置に格納されているデータの参照先を、移動先のホストコンピュータに切り替える。このようにすることで、ＶＭ上で実行されている業務プロセスに支障をきたさないような僅かな時間内にＶＭを稼働させるホストコンピュータを切り替えることができる。

ところで、複数のコンテナが稼働するＶＭのライブマイグレーションをするための、ＶＭの移動先のホストコンピュータのリソースが足りない場合、ＶＭのライブマイグレーションを行うことができない。この場合、ＶＭ上で実行されている複数のコンテナを分割して、分割したコンテナを別々のホストコンピュータ上で稼働するＶＭに移動させることが考えられる。

しかし、ユーザデータのセキュリティ管理上の制約によってコンテナ間の通信を把握していない場合、互いに通信を行う複数のコンテナを分割して別々のＶＭに移動させるとコンテナ上で実行している業務プロセスを続行できなくなる場合がある。従って、同じＶＭ上で実行される複数のコンテナのうち、互いに通信を行うコンテナについてマイグレーションを行う際に、同じＶＭに移動させることで業務を継続できる形でマイグレーションを行う必要がある。

また、ＶＭ上で実行されている複数のコンテナを分割し、分割したコンテナを別々のＶＭに移動させる場合、複数のコンテナの全てを稼働させた状態でＶＭのライブマイグレーションを行うことはできない。この場合、他のＶＭに移動させる分割した一部のコンテナを一旦停止させる。そして、停止させたコンテナの移動先となるホストコンピュータ上で新たなＶＭを起動させ、起動したＶＭ上でゲストＯＳの起動及びコンテナ環境の作成を行った後で、停止させたコンテナを移動させる。ここで、ゲストＯＳの起動を行う際には、通常のＯＳの起動と同様の起動時間がかかる。また、起動したＶＭ上でコンテナ環境を構築し、構築されたコンテナ環境に、分割されたコンテナを移動させる必要がある。従って、ゲストＯＳ上で実行されていたコンテナを分割して別々のＶＭに移動させる場合には、停止させたコンテナの移動先となるコンテナ環境の作成と移動処理を行う間、停止させたコンテナ上で実行される業務プロセスは停止し、業務に支障をきたす場合がある。

本発明の１つの側面では、仮想化環境で実行される業務プロセスのうち、互いに通信をおこなう関連する複数のプロセスのマイグレーションを行う際に、業務を継続できる状態でマイグレーションすることを目的とする。

発明の一観点によれば、情報処理システムは、仮想マシンを生成するプログラムを実行するとともに、前記仮想マシン上で動作するオペレーティング・システム（ＯＳ）により提供されるアプリケーションプログラムの実行環境であって、前記ＯＳの一部を共有しつつ前記実行環境ごとに異なる設定を有することで、前記ＯＳ上で互いに独立して稼働される複数の仮想ＯＳを生成するプログラムを実行するプロセッサをそれぞれ備える複数のコンピュータと、前記複数のコンピュータに含まれる一のコンピュータ上で稼働する前記仮想ＯＳを、前記複数のコンピュータに含まれる他のコンピュータ上で稼働する仮想マシン上に移動させるマイグレーションを行う管理装置と、を備える。管理装置は、同じ仮想マシン上で稼働する複数の仮想ＯＳのうち、異なる仮想ＯＳ上で実行されるアプリケーションプログラムどうしで通信を行う複数の仮想ＯＳを検出することにより、前記マイグレーションを行う際に同じ仮想マシン上で稼働させるべき複数の仮想ＯＳを特定し、特定した複数の仮想ＯＳに対してマイグレーションを実行すべき状況が発生する前に、前記特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させる。

一実施態様によれば、仮想化環境で実行される業務プロセスのうち、互いに通信をおこなう関連する複数のプロセスのマイグレーションを行う際に、業務を継続できる状態でマイグレーションすることができる。

図１は、実施例における情報処理システムのシステム構成を示す図である。 図２は、ホストコンピュータ１００のハードウェア構成の一例を示す図である。 図３は、ホストコンピュータ１００におけるアプリケーション実行環境を説明する図である。 図４は、管理サーバ１３０のハードウェア構成の一例を示す図である。 図５は、情報処理システム１０におけるアプリケーション実行環境の一例を説明する図である。 図６は、情報処理システム１０における業務アプリケーションの運用例を説明する図である。 図７は、図６の運用例における各ＶＭゲスト３２０で実行されるエージェント３４０の処理を説明する図である。 図８は、各コンテナの通信状況に応じたコンテナの優先順位付けの例を記載した表を示す図である。 図９は、図７の運用例における各コンテナの通信状況の例と優先順位付けの例を記載した表を示す図である。 図１０は、コンテナの優先順位付けを行う全体フローチャートである。 図１１は、コンテナの優先順位付けを行うフローチャート（１）である。 図１２は、コンテナの優先順位付けを行うフローチャート（２）である。 図１３は、図７の運用例において管理マネージャが各ホストコンピュータ１００から取得する、ハードウェアリソースの使用状況に関する情報の例を示す図である。 図１４は、図１３の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーションを説明する１つ目の図である。 図１５は、図１３の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーションを説明する２つ目の図である。 図１６は、図１３の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーション結果のリストを示す図である。 図１７は、図１３の運用例においてホスト１上の仮想マシン又はコンテナのマイグレーションが必要になった場合の処理の例を示す図である。 図１８は、実施例に係るマイグレーションの可否判定処理の全体フローの前半を示すフローチャートである。 図１９は、実施例に係るマイグレーションの可否判定処理の全体フローの後半を示すフローチャートである。 図２０は、コンテナが稼働されていないＶＭのマイグレーションの可否判定を行うサブルーチンの処理を示すフローチャートである。 図２１は、ホストコンピュータ内で、コンテナを稼働させている全てのＶＭについてのＶＭ単位でのマイグレーション可否判定を行うサブルーチンの処理を示すフローチャートである。 図２２は、ホストコンピュータ内で稼働している優先度の高いコンテナのマイグレーションの可否判定を行うサブルーチンの処理を示すフローチャートの前半を示す図である。 図２３は、ホストコンピュータ内で稼働している優先度の高いコンテナのマイグレーションの可否判定を行うサブルーチンの処理を示すフローチャートの後半を示す図である。 図２４は、ホストコンピュータ内で稼働している優先度が中又は低のコンテナのマイグレーションの可否判定を行う処理のサブルーチンを示すフローチャートである。

以下、図面を参照して、一実施形態について説明する。

図１は、実施例における情報処理システム１０のシステム構成を示す図である。図１に示すように、本実施形態に係る情報処理システム１０は、ホストコンピュータ１００Ａ、１００Ｂ、１００Ｃと、ストレージ装置１１０と、ネットワークスイッチ１２０と、管理サーバ１３０とを備える。情報処理システム１０は、インターネット等の外部通信回線のネットワーク２０を介してクライアント装置３０と接続される。情報処理システム１０は、例えばクライアント装置３０を介して受信したユーザからのリクエストに応じて、ユーザの業務に係るアプリケーションプログラムを実行し、ユーザからのリクエストに応じたサービスを提供する。

ホストコンピュータ１００Ａ、１００Ｂ、１００Ｃのそれぞれは、ユーザの業務に係るアプリケーションプログラムを実行するサーバ装置である。以下、ホストコンピュータ１００Ａ、１００Ｂ、１００Ｃは、それらを区別不要の場合、ホストコンピュータ１００と記述する。ホストコンピュータ１００は、例えば、前述のハイパーバイザ型仮想化、コンテナ型仮想化、及びこれらを組み合わせたハイブリッド型仮想化を行って、ユーザへ仮想化されたアプリケーション実行環境を提供する。図１では、３つのホストコンピュータ１００Ａ、１００Ｂ、１００Ｃを備える例としているが、ホストコンピュータ１００の数は３つに限られない。ホストコンピュータ１００は、一部のホストコンピュータに故障等が発生した場合でも保守作業によって増設や交換が行われ、ユーザへのサービスが継続される。

ストレージ装置１１０は、データを記憶する装置であり、ホストコンピュータ１００上で実行されるＯＳやアプリケーションのプログラムデータ、ユーザのアプリケーションが用いるデータ等を記憶する。

ネットワークスイッチ１２０は、ネットワーク２０に接続され、ホストコンピュータ１００や管理サーバ１３０と、ネットワークに接続された装置との通信を制御する。管理サーバ１３０は、情報処理システム１０内の通信回線であるローカルバス１４０を介して、情報処理システム１０内のホストコンピュータ１００Ａ〜１００Ｃ、ストレージ装置１１０、ネットワークスイッチ１２０等と通信を行って、各装置の管理を行う。管理サーバ１３０は、管理装置の一例である。

図２は、ホストコンピュータ１００のハードウェア構成の一例を示す図である。ホストコンピュータ１００は、ＣＰＵ１０１（１０１Ａ〜１０１Ｄ）と、入出力装置インタフェース回路１０２と、メモリ１０３と、ネットワークインタフェース回路１０４と、ストレージインタフェース回路１０５と、ローカルバスインタフェース回路１０６とを備える。各ＣＰＵ１０１は、内部バス１０７を介して、メモリ１０３や入出力装置インタフェース回路１０２等の各インタフェース回路（１０４〜１０６）にアクセスする。

ＣＰＵ１０１（１０１Ａ〜１０１Ｄ）は、Central Processing Unit（ＣＰＵ）、Micro-Processing Unit（ＭＰＵ）等のプロセッサの電子部品である。図２の例では、ホストコンピュータ１００が、ＣＰＵ１０１Ａ、ＣＰＵ１０１Ｂ、ＣＰＵ１０１Ｃ、ＣＰＵ１０１Ｄの４つのＣＰＵを備える例を示しているが、ＣＰＵの数は４つに限られず、より多くのＣＰＵを備えてもよい。また、ＣＰＵの中に複数のＣＰＵコアや、ハードウェアスレッドを備え、１つのＣＰＵによって、複数のアプリケーションプログラムのプロセスの処理を行えるＣＰＵをＣＰＵ１０１として用いてもよい。さらに、ＣＰＵは、ホストコンピュータによってその搭載数が異なっていてもよい。

入出力装置インタフェース回路１０２は、不図示のマウスやキーボード等のデバイスを含む周辺デバイスへの入出力を制御するための回路である。メモリ１０３は、ＲＡＭ（Random Access Memory）等の記憶デバイスである。図２では、１つのメモリ１０３を図示しているが、メモリ１０３は複数のＲＡＭを含んでもよく、また、ＣＰＵ１０１Ａ〜１０１Ｄごとに対応する別々のメモリ１０３（１０３Ａ、１０３Ｂ、１０３Ｃ、１０３Ｄ）を備えるようにしてもよい。

ネットワークインタフェース回路１０４は、ネットワーク２０を介して他の装置と通信を行うためのインタフェース回路であり、図２の例では、ネットワークスイッチ１２０を介してネットワーク２０と接続される。ストレージインタフェース回路１０５は、ストレージ装置１１０へのアクセスを行うためのインタフェース回路である。ローカルバスインタフェース回路１０６は、ローカルバス１４０を介して情報処理システム内の管理サーバ１３０や他のホストコンピュータ１００等と通信を行うためのインタフェース回路である。

以下に説明する、ホストコンピュータ１００で実行される仮想化環境２００、２１０を生成するプログラム、ＶＭやコンテナ上で実行されるアプリケーションの業務処理を行うためのプログラムやデータはメモリ１０３やストレージ装置１１０に格納される。ＣＰＵ１０１は、メモリ１０３やストレージ装置１１０に格納されたプログラムやデータを読み出して、仮想化環境２００、２１０に関連するプログラム処理、及び、ＶＭやコンテナ上で実行されるアプリケーションの業務処理に関するプログラムを実行する。

図３は、ホストコンピュータ１００におけるアプリケーション実行環境を説明する図である。図３では、ホストコンピュータ１００におけるハードウェア構成とソフトウェア実行環境の構成とが模式的に示されている。ホストコンピュータ１００のハードウェアブロック１００Ｈに含まれるＣＰＵ１０１やメモリ１０３等を用いて、ハイパーバイザ型仮想化環境２００と、仮想マシン２０２上で稼働するコンテナ型仮想化環境２１０とが動作するハイブリッド型仮想化環境が提供される。

ハイパーバイザ型仮想化環境２００は、ハイパーバイザ２０１と、ハイパーバイザ２０１によって生成された仮想マシン２０２とを含む。ハイパーバイザ２０１は、仮想マシン２０２の起動や削除、仮想マシン２０２上で実行されるプログラムからのハードウェア資源１００Ｈへのアクセス要求の制御等を行う。また、ハイパーバイザ２０１は、図１におけるネットワークスイッチ１２０のハードウェア資源を仮想化した仮想スイッチ２０４の制御も行う。

ハイパーバイザ２０１は、ホストコンピュータ１００のハードウェア故障が発生した場合やメンテナンスを行う場合等において、仮想マシンのライブマイグレーションをするための処理も行う。他のホストコンピュータ１００へのライブマイグレーションを行う際には、他のホストコンピュータ１００上で稼働しているハイパーバイザ２０１と連携してライブマイグレーションの処理を行う。

仮想マシン２０２Ａ、２０２Ｂは、ホストコンピュータ１００のハードウェア資源１００Ｈを仮想化したものであり、仮想マシン２０２Ａ、２０２Ｂ毎に独立したソフトウェア実行環境が提供される。そのため、例えば、仮想マシン２０２Ａと仮想マシン２０２Ｂとで異なるＯＳを実行することができる。以下、仮想マシン２０２Ａ、２０２Ｂは、それらを区別不要の場合、仮想マシン２０２と記述する。

図３の例では、仮想マシン２０２Ａと２０２Ｂのそれぞれにおいて、コンテナ型仮想化環境２１０が提供される。コンテナ型仮想化環境では、仮想マシン２０２上で例えばＬｉｎｕｘ（登録商標） ＯＳが起動され、Ｌｉｎｕｘ ＯＳ上でＤｏｃｋｅｒ（登録商標）等のコンテナ仮想化ソフトウェアがインストールされる。図３の例では、コンテナ仮想化ソフトウェアがインストールされたＬｉｎｕｘ ＯＳ等のゲストＯＳを「コンテナＯＳ」と記載する。図３において、各コンテナＯＳ２１１Ａ、２１１Ｂ上でそれぞれ２つのコンテナが稼働する例を示しているが、コンテナＯＳ２１１上で稼働するコンテナの数は２個に限られず、ユーザからの要求に応じた数のコンテナを稼働させることができる。

コンテナ型仮想化環境２１０では、コンテナＯＳ２１１によって、独立したアプリケーション実行環境であるコンテナ２１２が提供される。コンテナ型仮想化では過去に作成したアプリケーション実行環境を共通ファイルのイメージとして保存する。そして、保存したイメージをコピーし、アプリケーション実行環境ごとの設定を追加することで、新たなコンテナを容易に作成できる。そのため、コンテナ型仮想化環境は、ＰａａＳ（Platform as a Service）等の構築に適している。

ここで、ＰａａＳ等の環境において、他のユーザのコンテナ上で実行されているアプリケーションプログラムを参照できてしまうとセキュリティ上の問題が生じる。一方、同じユーザによって複数の関連する業務アプリケーションを別々のコンテナで実行する場合等においては、コンテナ間で通信する必要が生じる場合もある。そのため、Ｄｏｃｋｅｒ等のコンテナ型仮想化環境においては、コンテナの起動時にコンテナ間の通信を許可するかどうかを指定できる機能が提供されている。例えば、Ｄｏｃｋｅｒでは、コンテナ間通信を許可するか否かをコンテナ起動コマンドの引数である“−−ｉｃｃ”フラグ（Inter Container Communication）で切り替えることができる。また、Ｌｉｎｋ機能によって、特定のコンテナとの通信を許可するといった制御も行うことができる。これらのコンテナ間通信を行うための機能は、コンテナＯＳ２１１の機能として提供される。

コンテナ２１２Ａとコンテナ２１２Ｂとの間のコンテナ間通信は、コンテナＯＳ２１１Ａ上でのコンテナ起動時のフラグ設定、又はリンク機能による設定を行うことで設定できる。しかし、コンテナ２１２Ｃ及びコンテナ２１２Ｄは、コンテナＯＳ２１１Ｂ上で稼働するため、異なるコンテナＯＳ２１１上で稼働するコンテナ２１２Ａとコンテナ２１２Ｃとの間のコンテナ間通信は行うことができない。この場合、コンテナ２１２Ａとコンテナ２１２Ｃ間の通信はネットワークスイッチ１２０を介したパケット通信により行う。

図３の例では、仮想スイッチ２０４がネットワークスイッチ１２０の機能を仮想化しており、コンテナ２１２Ａ及びコンテナ２１２Ｃが同じホストコンピュータ１００上に存在する。そのため、コンテナ２１２Ａからコンテナ２１２Ｃ宛てに送付された通信パケットは、実際にネットワークスイッチ１２０に送信されることなく、仮想スイッチ２０４を介して受け渡され、ホストコンピュータ１００内部で通信パケットが受け渡されることになる。

図４は、管理サーバ１３０のハードウェア構成の一例を示す図である。管理サーバ１３０は、ＣＰＵ１３１と、入出力装置インタフェース回路１３２と、メモリ１３３と、ネットワークインタフェース回路１３４と、ストレージインタフェース回路１３５、とを有する。ＣＰＵ１３１は、内部バス１３７を介して、メモリ１３３や入出力装置インタフェース回路１３２等の各インタフェース回路（１３４〜１３６）にアクセスする。

入出力装置インタフェース回路１３２は、不図示のマウスやキーボード等のデバイスを含む周辺デバイスへの入出力を制御するための回路である。ネットワークインタフェース回路１３４は、ネットワーク２０を介して他の装置と通信を行うためのインタフェース回路であり、ストレージインタフェース回路１３５は、ストレージ装置１１０へのアクセスを行うためのインタフェース回路である。ローカルバスインタフェース回路１３６は、ローカルバス１４０を介して各ホストコンピュータ１００Ａ〜１００Ｃ、ストレージ装置１１０、ネットワークスイッチ１２０と通信を行うためのインタフェース回路である。

ＣＰＵ１３１は、ストレージ装置１１０やメモリ１３３に格納されたプログラムを実行することにより、各ホストコンピュータ１００の管理を行う。ＣＰＵ１３１は、情報処理システム１０内の各ホストコンピュータ１００Ａ〜１００Ｃ上で稼働する仮想化されたアプリケーション実行環境（２００、２１０）の管理を行う管理マネージャによる各種処理を行うためのプログラムを実行する。管理マネージャによる処理の詳細については後述する。

図５は、情報処理システム１０におけるアプリケーション実行環境の一例を説明する図である。図５では、情報処理システム１０における各ホストコンピュータ１００Ａ〜１００Ｃの処理と、管理サーバ１３０における処理とが模式的に表されている。管理サーバ１３０のＣＰＵ１３１上で実行されるシステムの運用管理プログラムである管理マネージャ３００は、各ホストコンピュータ１００Ａ〜１００Ｃ上で稼働する仮想化環境の管理を行う。

図５において、各ホストコンピュータ１００Ａ〜１００Ｃに含まれるホスト３１０Ａ、３１０Ｂ、３１０Ｃは、それぞれ図３におけるハードウェア１００Ｈ及びハイパーバイザ２０１を含む機能ブロックを模式的に表したものである。また、ＶＭゲスト３２０Ａ〜３２０Ｇは、それぞれホスト３１０Ａ、３１０Ｂ、３１０Ｃ上で起動してユーザに提供される仮想マシンの実行環境である。図５において、ＶＭゲスト３２０Ａ、３２０Ｂ、３２０Ｃ、３２０Ｅでは、コンテナ３３０が稼働し、コンテナ上でユーザの業務に関するアプリケーションプログラムが実行されているものとする。以下、ホスト３１０Ａ〜３１０Ｃは、それらを区別不要の場合、ホスト３１０と記述する。また、ＶＭゲスト３２０Ａ〜３２０Ｇは、それらを区別不要の場合、ＶＭゲスト３２０と記述する。

各ＶＭゲスト３２０またはコンテナ３３０上で実行されるユーザのアプリケーションプログラムと、そのアプリケーションプログラムが使用するデータは、ストレージ装置１１０に格納される。ストレージ装置１１０に格納されたアプリケーションプログラム又はデータは、各ホスト３１０に含まれるＣＰＵ１０１によって読み出されて、アプリケーションの実行時に使用される。

図６は、情報処理システム１０における業務アプリケーションの運用例を説明する図である。図６では、図５におけるアプリケーション実行環境の例で示される各コンテナ３３０において、それぞれ異なるアプリケーションプログラムが実行されている例を示す。

図６において、ＶＭゲスト３２０Ａ上で稼働する２つのコンテナ３３０では、アプリケーション「Ｗｅｂ Ａ」、「ＤＢ Ａ」が実行されているものとする。同様に、ＶＭゲスト３２０Ｂ上のコンテナ３３０では、アプリケーション「Ａｐｐ Ｂ１」、「Ａｐｐ Ｂ２」が実行され、ＶＭゲスト３２０Ｃ上のコンテナ３３０では、アプリケーション「Ｗｅｂ Ｃ」、「Ａｐｐ Ｃ」が実行されているものとする。また、ＶＭゲスト３２０Ｅ上のコンテナ３３０では、アプリケーション「Ｗｅｂ Ｅ」、「Ａｐｐ Ｅ」が実行されているものとする。なお、例えば、「Ｗｅｂ」はＷｅｂサーバ・プログラムを示し、「ＤＢ」はＤａｔａｂａｓｅ（ＤＢ）サーバ・プログラムを示す。

各ＶＭゲスト３２０上で稼働するコンテナＯＳ２１１上では、各ＶＭゲスト３２０に関する情報を収集するプログラムであるエージェント３４０Ａ〜３４０Ｇ（図６では「ａ」と表示）が実行される。以下、エージェント３４０Ａ〜３４０Ｇは、それらを区別不要の場合、エージェント３４０と記述する。エージェント３４０は、例えば、コンテナＯＳ２１１上で実行されるデーモンプログラムとして実装され、各ＶＭゲスト３２０上で実行されるアプリケーションプログラムとは独立して実行される。

図７は、図６の運用例における各ＶＭゲスト３２０のコンテナ３３０で実行されるエージェント３４０の処理を説明する図である。図７において、アプリケーション「Ｗｅｂ Ａ」、「Ａｐｐ Ｂ１」、「Ｗｅｂ Ｃ」、「Ｗｅｂ Ｅ」が実行されているコンテナから下方向に出ている矢印は、各アプリケーションがコンテナ３３０によって提供される通信機能によってＶＭゲスト３２０外部と通信することを示す。また、アプリケーション「Ｗｅｂ Ａ」と「ＤＢ Ａ」間の双方向矢印は、これらのアプリケーション間での通信、言い換えれば、これらのアプリケーションが実行されるコンテナ間での通信が行われることを示す。

情報処理システム１０に含まれるホストコンピュータ１００等の装置は、ハードウェア障害等による保守交換や定期的な保守作業が行われる場合がある。このような場合、保守対象となるホストコンピュータ１００上で実行されているユーザの業務に関するアプリケーションプログラムの処理を、動作を継続した状態で、他のホストコンピュータ１００上の仮想マシンにマイグレーションを行うことが望まれる。マイグレーションを行う際、仮想マシンの移動先となるホストコンピュータ１００のハードウェアリソース（ＣＰＵ処理能力や、使用可能なメモリ容量等）に空きがなければ、マイグレーションを適切に行うことができない。

そのため、管理マネージャ３００は、特定のタイミングで、各ホストコンピュータ１００上の仮想化環境で実行されているアプリケーションプログラムの処理を他のホストコンピュータ上の仮想化環境にマイグレーションできるか否かを調査する。具体的には、管理マネージャ３００は、各ホストコンピュータ１００のハードウェアリソースの情報や、ＶＭゲスト３２０やコンテナ３３０上で実行されるアプリケーションプログラムのリソース使用量を含むモニタ情報を各ホストコンピュータ１００から収集する。ＶＭゲスト３２０のマイグレーションを行う際には、ハードウェアリソースに空き（余裕）のあるホストコンピュータ１００を移動先としてマイグレーションを行うこととなる。

各ホストコンピュータ１００のハードウェアリソースの使用量等については、各ホストコンピュータ１００におけるハードウェアリソースの管理を行うハイパーバイザ２０１や、各ＶＭゲスト３２０で稼働するＯＳ上で実行されるエージェント３４０等から収集する。なお、ハードウェアリソースの使用量等の情報の取得は、ハイパーバイザ２０１やエージェント３４０に限らず、各ホストコンピュータ上で実行されるファームウェアやＯＳ等のプログラムによって行うようにしてもよい。

本実施形態において、エージェント３４０は、例えば、同じＶＭゲスト３２０上で稼働するコンテナ間で通信が行われることがあるか否かの検出に用いられる。すなわち、同じＶＭゲスト３２０上で稼働する複数のコンテナ３３０のそれぞれで動作するアプリケーションどうしが通信を行えるようになっているか否かをモニタする。

前述の通り、情報処理システム１０の管理マネージャ３００が、ユーザがコンテナ３３０上で実行するアプリケーションの処理の内容に関する情報を取得してしまうとセキュリティ上問題がある。しかし、ホストコンピュータ１００の保守管理等に起因するマイグレーションを行う際に、同じＶＭ上で稼働するコンテナ間の通信の有無を把握できなければ適切にマイグレーションを行えない場合がある。すなわち、ＶＭのマイグレーションを行う際のＶＭの移動先となるホストコンピュータのハードウェアリソースに十分な空きがない場合、ＶＭ上で稼働する複数のコンテナを分割して移動させる必要が生じるが、コンテナ間通信の有無を把握しないと適切に分割できない。

本実施例では、セキュリティの観点からコンテナ３３０上で実行されるユーザのアプリケーションプログラムの処理に関する情報を参照せずに、同じＶＭゲスト３２０上で稼働する複数のコンテナ間の通信が行えるように設定されているかどうかをモニタする。具体的には、ユーザのリクエストに応じてＶＭゲスト３２０上にコンテナ３３０を生成する際のコンテナ生成コマンドの引数（例えば、前述の“−−ｉｃｃ”フラグ）をエージェント３４０がモニタすることによって、コンテナ間通信ができる状態かどうかを把握する。他の方法としては、エージェント３４０が、前述のＬｉｎｋ機能によるコンテナ間通信の設定を行うためのコマンドをモニタすることによって、コンテナ間通信ができる状態に設定されているかどうかをモニタする。

エージェント３４０がモニタするコンテナ間の通信に関する設定の有無の情報は、実際のコンテナ間の通信の有無を検出する訳ではないが、同じＶＭゲスト３２０上で稼働させるべき複数のコンテナの有無を判断するための情報としては十分である。そのため、本実施例では、ホストコンピュータ１００の保守作業等に起因するマイグレーションを行う際にコンテナを分割する必要がある場合には、エージェント３４０が収集したコンテナ間通信の設定に関する情報を参照して、コンテナの分割の可否判断を行う。同じＶＭゲスト３２０上で稼働させるべき複数のコンテナを把握し、同じ移動先のＶＭゲスト３２０にマイグレーションできるため、コンテナ上で動作しているアプリケーションプログラムによる業務プロセスに支障を来たすことなくマイグレーションを実施できる。

ところで、コンテナ３３０上で実行されるアプリケーションからＶＭゲスト３２０外部にアクセスする通信に関してはコンテナＯＳ２１１のコンテナ間通信を行う機能を利用するものではない。この場合、ＶＭゲスト３２０又はコンテナ３３０のマイグレーションを行う際に、基本的にはコンテナを分割して別々のＶＭゲスト３２０又は別々のホストコンピュータ１００に移動させても業務に支障は生じない。

しかし、図３に示すような仮想化環境においては、仮想スイッチ２０４によってネットワークスイッチ１２０も仮想化されている。そのため、ＶＭゲスト３２０やコンテナ３３０のリソースの割り当て状況によっては、ＶＭゲスト３２０外部への通信であっても、同じＶＭゲスト３２０上の他のコンテナ３３０と通信を行う場合が発生し得る。このような状況でコンテナ３３０を分割してマイグレーションを行う場合、必須ではないものの、可能であれば互いに外部通信を行うコンテナどうしを同じＶＭゲスト３２０上に移動させることが望ましい。

このような観点から、エージェント３４０は、ＶＭゲスト３２０上で稼働しているコンテナ３３０から外部へ通信を行うことがあるか否かもモニタする。その際、ＶＭゲスト３２０外部への通信パケットの中身は参照せずに、コンテナ３３０からそのコンテナ３３０が実行されているＶＭゲスト３２０の外部へ通信を行うパケットが存在するかどうかのみをモニタすることでユーザ情報のセキュリティを確保しつつ、コンテナ３３０のマイグレーション処理に必要な情報のみを収集する。

エージェント３４０は、ＶＭゲスト３２０上で稼働しているコンテナ３３０ごとに、コンテナ間通信の有無（コンテナ間通信を行える設定になっているかどうか）と、ＶＭゲスト３２０外部への通信の有無をモニタする。そして、管理マネージャ３００は、エージェント３４０から収集したモニタ情報から各コンテナ３３０の通信状況を把握する。管理マネージャ３００は、各コンテナ３３０の通信状況から、各コンテナ３３０についてマイグレーションを行う際に他のコンテナ３３０と一緒に同じ移動先のＶＭゲスト３２０に移動させるべきかどうかの指標となる優先度を決定する。

図８は、各コンテナの通信状況に応じたコンテナの優先順位付けの例を記載した表を示す図である。図８の例では、同じＶＭゲスト上でコンテナ１とコンテナ２が稼働している場合の優先度の設定例が示されている。

項目１の場合、コンテナ１とコンテナ２とが互いにコンテナ間通信を行う設定がされているとともに、各コンテナが外部通信を行う状況を示しており、この場合、コンテナ１とコンテナ２との通信関係による優先度は「高」である。コンテナが外部通信を行っているということは、コンテナ上で実行されているアプリケーションによる業務の処理が実行されていると考えられる。業務実行中のコンテナどうしでコンテナ間通信を行う設定となっているので、これらのコンテナについてマイグレーションを行う際には、同じ移動先のＶＭゲストに移動させるべきであるため、優先度は「高」となる。

項目２の場合も各コンテナ間で内部通信を行う設定となっており、コンテナ１については外部通信も行う状況となっている。コンテナ２についてはコンテナ１との内部通信のみであるが、コンテナ１が業務実行中の状況であり、コンテナ２と内部通信を行う設定となっていることから、これら２つのコンテナについても優先度は「高」となる。

項目３の場合、各コンテナが外部通信を行うものの、コンテナ間通信の設定はされていないため、コンテナのマイグレーションを行う際に必ず同じ移動先のＶＭゲストに移動させる必要はない。しかし、前述の通り、仮想スイッチ２０４を介して互いに通信を行う可能性もあることから、可能であれば、同じ移動先のＶＭゲストにマイグレーションさせることが望ましい。そのため、優先度は「中」とする。

項目４の場合、コンテナ１は外部通信するものの、コンテナ１とコンテナ２の間のコンテナ間通信はなく、コンテナ２は外部通信もない。そのため、コンテナ１とコンテナ２とを関連付けて同じ移動先にマイグレーションさせる必要性がないため、優先度は「低」となる。

項目５の場合、コンテナ１、コンテナ２ともに外部通信を行っていないので業務を実行していないが、コンテナ間通信が可能な設定となっており、業務を今後実行する可能性があるため優先度を「中」とする。本実施例で想定しているマイグレーションは、例えばホストコンピュータの障害や保守対応のために一時的にＶＭ又はコンテナを移動させるものである。そのため、コンテナ間通信が可能な設定になっていたとしても、業務を実行していないコンテナについては優先度を「中」としておき、業務の実行を確認できた段階で優先度を「高」にすることが考えられる。

例えば、実施例に係る情報処理システム１０をクラウド環境におけるサービス提供に使用する場合、コンテナ上で業務アプリケーションを実行すれば、必然的に外部通信が発生することになる。前述のエージェント３４０によってコンテナの外部通信をモニタした段階で、モニタ対象のコンテナの通信状況に関する情報を更新することで、項目５の優先度を「中」から「高」に変更するようにできる。

項目６の場合、各コンテナが外部通信をしておらず、コンテナ間通信ができる設定にもなっていない。そのため、コンテナ１とコンテナ２とを関連付けて同じ移動先にマイグレーションさせる必要性がないため、優先度は「低」とする。

図９は、図７の運用例における各コンテナの通信状況の例と優先順位付けの例を記載した表を示す図である。図７の例におけるコンテナから出ている矢印で示される通信状況から、ＶＭゲスト３２０Ａ上の「Ｗｅｂ Ａ」と「ＤＢ Ａ」を実行するコンテナどうしはコンテナ間通信ができる設定になっているとともに、「Ｗｅｂ Ａ」を実行するコンテナは外部通信も行う。そのため、図９の表の「コンテナ」の列と「コンテナ間通信先」の列に記載されている互いに通信を行う「Ｗｅｂ Ａ」のコンテナと「ＤＢ Ａ」のコンテナのペアについては、これらのコンテナの結合優先度を「高」とする。ここで、「結合優先度」とは、マイグレーションを行う際に同じ仮想マシン上で稼働させるべきコンテナのペアであるかどうかを示す指標をいうものとする。

一方、ＶＭゲスト３２０Ｂ上で稼働する各コンテナ上で実行される「Ａｐｐ Ｂ１」、「Ａｐｐ Ｂ２」はそれぞれコンテナ間通信ができる設定がされておらず、外部通信のみ行っている。そのため、「Ａｐｐ Ｂ１」、「Ａｐｐ Ｂ２」を実行するコンテナについては、図８の表を参照して、結合優先度は「中」とする。

ＶＭゲスト３２０Ｃ上で実行されている「Ｗｅｂ Ｃ」と「Ａｐｐ Ｃ」を実行する２つのコンテナは、コンテナ間通信ができる設定がされておらず、かつ一方のコンテナのみが外部通信を行っている。そのため、これら２つのコンテナ間の結合優先度はいずれも「低」とする。ＶＭゲスト３２０Ｅ上で実行されている２つのコンテナについても同様の通信状況であるため、それぞれのコンテナの結合優先度は「低」とする。

先にも述べたように、結合優先度が「高」の設定がなされたコンテナのペアは、互いにコンテナ間通信を行う可能性があることから、マイグレーションを行う際に同じ移動先のＶＭ上で稼働させる必要がある。一方、結合優先度が「中」又は「低」のコンテナについては、コンテナを分割して別々のＶＭに移動させても業務を継続できることから、コンテナを分割しても良い対象のコンテナと判断する。

図１０は、コンテナの優先順位付けを行う全体フローチャートである。ホストコンピュータ１００上で稼働するＶＭゲスト３２０やコンテナ３３０の数が変更された場合や、一定期間ごとに、各コンテナの結合優先度の判定を行う。コンテナの結合優先度の判定を行う際、図１０に示すように、コンテナの分類を行う処理（Ｓ１０２）を、ＶＭの数（Ｍ、Ｍは自然数）の分だけ行う。コンテナの分類を行う処理（Ｓ１０２）の詳細については、図１１、図１２を用いて説明する。

図１１、図１２は、コンテナの優先順位付けを行うフローチャートである。まず、図１０のＳ１０１で選択されたＶＭ上で稼働するコンテナのうち、接続状態が「外＋内」のコンテナの情報を取得する（Ｓ１１１）。取得したコンテナの数（Ｋ、Ｋは自然数）が０であればＳ１１７に進み、取得したコンテナの数（Ｋ）が１以上であれば、Ｓ１１３〜Ｓ１１６の処理を行う。

Ｓ１１３〜Ｓ１１６では、変数ｋ（ｋは自然数）が１からＫになるまで、Ｓ１１３〜Ｓ１１６の処理を繰り返す。Ｓ１１３〜Ｓ１１６の処理では、取得した接続状態が「外＋内」のコンテナの数（Ｋ）の分だけ、取得したコンテナと内部通信（コンテナ間通信）ができる設定がされているコンテナを取得する（Ｓ１１４）。そして、取得したコンテナと、内部通信（コンテナ間通信）先のコンテナのペアの結合優先度を「高」に設定する（Ｓ１１５）。

次に、接続状態の「外」のみのコンテナの情報を取得する（Ｓ１１７）。取得した接続状態が「外」のみのコンテナの数が０の場合（Ｓ１１８で「０」）、Ｓ１２１へ進む。接続状態が「外」のみのコンテナの数が１の場合（Ｓ１１８で「１」）、取得したコンテナの結合優先度を「低」に設定する（Ｓ１２０）。取得した接続状態が「外」のみのコンテナの数が２以上の場合（Ｓ１１８で「２以上」）、取得したコンテナのそれぞれの結合優先度を「中」に設定する（Ｓ１１９）。

次に、接続状態が「無」のコンテナの情報を取得する（Ｓ１２１）。取得した接続状態が「無」のコンテナの数が１以上である場合（Ｓ１２２で「１以上」）、取得した接続状態が「無」のコンテナの結合優先度を「低」に設定する（Ｓ１２３）。一方、取得した接続状態が「無」のコンテナの数が０である場合、Ｓ１２４に進む。

Ｓ１２４では、接続状態が「内」のみで、結合優先度が設定されていないコンテナの情報を取得する。Ｓ１２４で取得したコンテナの数が１以上である場合（Ｓ１２５で「１以上」）、Ｓ１２４で取得したコンテナの結合優先度を「中」に設定する（Ｓ１２６）。Ｓ１２４で取得したコンテナの数が０である場合（Ｓ１２５で「０」）、処理を終了する。

図１３は、図７の運用例において管理マネージャが各ホストコンピュータ１００から取得する、ハードウェアリソースの使用状況に関する情報の例を示す図である。図１３の例では、各ホストコンピュータ１００のＣＰＵリソースとして、ホスト１は９．０ＧＨｚ、ホスト２は７．５ＧＨｚ、ホスト３は１１．５ＧＨｚであるものとする。ここで、ＣＰＵリソースの単位としている「ＧＨｚ」は、各ホストにおいてＣＰＵ１０１を用いて処理を行うことができるプログラムの単位時間当たりの処理ステップ数をいうものとする。また、図１３中のＣＰＵ使用量の単位として記載している「ＧＨｚ」は、各ＣＰＵ上で実行されているアプリケーションプログラムが単位時間あたりに使用するＣＰＵ１０１の処理ステップ数をいうものとする。

図１３から、ホスト１の各コンテナ上で実行されている各アプリケーションプログラムのＣＰＵ使用量の合計は７．０ＧＨｚであり、ホスト１のＣＰＵ空きリソースは２．０ＧＨｚである。ホスト２のＶＭ又はコンテナ上で実行されている各アプリケーションプログラムのＣＰＵ使用量の合計は４．０ＧＨｚであり、ホスト２のＣＰＵ空きリソースは３．５ＧＨｚである。また、ホスト３のＶＭ上で実行されている各アプリケーションプログラムのＣＰＵ使用量の合計は８．０ＧＨｚであり、ホスト３のＣＰＵ空きリソースは３．５ＧＨｚである。図１３において、「ＶＭ Ｄ」、「ＶＭ Ｆ」、「ＶＭ Ｇ」の各ＶＭ上では、アプリケーションプログラムの名称は記載されていないものの、何らかのアプリケーションプログラムが実行されているものとする。

図１４は、図１３の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーション例を説明する１つ目の図である。図１４（Ａ）において、例えばホストコンピュータ１００Ａ（ホスト１）上で実行されているＶＭ又はコンテナを他のホストコンピュータにマイグレーションさせる必要が生じた場合を想定する。ここで、前述のライブマイグレーションができれば、ＶＭを稼働させた状態で他のホストコンピュータに移動できるので、まずＶＭ単位で移動できるかどうかを判定する。

例えば、図１４（Ａ）において、ライブマイグレーションで「ＶＭ Ｂ」をホスト３に移動させ、「ＶＭ Ｃ」をホスト２に移動させる。そうすると、図１４（Ｂ）に示されるように、ホスト２のＣＰＵ空きリソースが０．５ＧＨｚ、ホスト３のＣＰＵ空きリソースが１．３ＧＨｚとなる。この場合、ホスト１に残った「ＶＭ Ａ」の移動先となるホストコンピュータのＣＰＵ空きリソースが「ＶＭ Ａ」のＣＰＵ使用量の１．８ＧＨｚを満たさず、ライブマイグレーションを行うことができない。

従って、図１４で示されるような場合には、ホスト１上の各ＶＭをライブマイグレーションによって他のホスト（ホスト２又はホスト３）に移動できないので、図１５に示すようにＶＭ上で稼働するコンテナを分割してマイグレーションできないかを判定する必要がある。

図１５は、図１３の運用例における仮想マシン又はコンテナのマイグレーションができるかどうかを判定するためのシミュレーションを説明する２つ目の図である。図１４で示されるように、ホスト１上の各ＶＭについてＶＭ単位でライブマイグレーションを行うことができなかったので、次に、各ＶＭ上で稼働するコンテナを分割して移動先のホストコンピュータの空き容量を確保できないか判定する。

まず、図１５（Ａ）で、ホスト１の各ＶＭ上で稼働しているコンテナのうち、図９に示される結合優先度の低い「ＶＭ Ｃ」上で稼働する２つのコンテナを、ホスト２とホスト３に分割することを考える。例えば、「ＶＭ Ｃ」上で稼働するコンテナのうち、「Ｗｅｂ Ｃ」を実行するコンテナを、ホスト３に新たに作成した「ＶＭ Ｈ」に移動させ、「Ａｐｐ Ｃ」のみを実行することになった「ＶＭ Ｃ」をライブマイグレーションでホスト２に移動させる。すると、図１５（Ｂ）に示されるように、ホスト２のＣＰＵ空きリソースの残りは１．７ＧＨｚとなり、ホスト３のＣＰＵ空きリソースの残りは２．３ＧＨｚとなる。

図１５（Ｂ）において、さらに結合優先度が「中」で分割可能な「ＶＭ Ｂ」上で稼働する２つのコンテナを分割することを考える。例えば、「ＶＭ Ｂ」で稼働するコンテナのうち、「Ａｐｐ Ｂ１」をホスト３に新たに作成した「ＶＭ Ｉ」に移動させ、「Ａｐｐ Ｂ２」のみを実行することになった「ＶＭ Ｂ」をライブマイグレーションでホスト２に移動させる。すると、図１５（Ｃ）に示されるように、ホスト２のＣＰＵ空きリソースの残りは０ＧＨｚとなり、ホスト３のＣＰＵ空きリソースの残りは１．８ＧＨｚとなる。

ここで、「ＶＭ Ａ」上で稼働する２つのコンテナは、互いにコンテナ間通信ができる設定がされており、結合優先度が「高」となっているため、コンテナを分割して移動できない。しかし、図１５（Ａ）、（Ｂ）のように「ＶＭ Ｂ」、「ＶＭ Ｃ」のコンテナを分割して移動させることでＣＰＵ使用量が１．８ＧＨｚの「ＶＭ Ａ」をライブマイグレーションによりホスト３に移動できることになる。

図１５の（Ａ）〜（Ｃ）に示すシミュレーションによって、ホスト１上で稼働するＶＭ又はコンテナを他のホストコンピュータにマイグレーションできることが分かる。図１５のシミュレーションにおいてコンテナを分割して移動させるための新たなＶＭである「ＶＭ Ｈ」と「ＶＭ Ｉ」を作成したので、移動元のホスト１についての、移動時に必要となるＶＭ数は２となる。

図１５のようなシミュレーションをホスト２、ホスト３に対しても同様に行う。すなわちホストコンピュータ１００Ｂや１００Ｃの保守作業等を行うと仮定した場合に、ホスト２やホスト３上で実行されているＶＭ又はコンテナを他のホストコンピュータに移動できるかどうかをシミュレーションする。ホスト２についてのシミュレーションでは、ライブマイグレーションによって「ＶＭ Ｄ」をホスト３に移動させ、「ＶＭ Ｅ」をホスト１に移動させることができる。従って、コンテナを分割して移動させる必要はなく、移動時に必要となるＶＭ数は０となる。

また、ホスト３についてのシミュレーションについては、ＣＰＵ使用量が３．５ＧＨｚの「ＶＭ Ｇ」を、ライブマイグレーションによって空きリソースが３．５ＧＨｚあるホスト２に移動させることができる。しかし、残った「ＶＭ Ｆ」のＣＰＵ使用量の４．５ＧＨｚ分のＣＰＵ空きリソースがホスト１に残っていないことからホスト３の全てのＶＭをマイグレーションすることはできない。この場合、ホスト３についてはマイグレーションできる空きリソースがないことを、情報処理システム１０の運用管理者に通知し、運用管理者によってホストコンピュータの追加や、既存のホストコンピュータにおけるハードウェアリソースの追加が行われる。

図１６は、図１３の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーション結果のリスト４００を示す図である。図１５のようなシミュレーションを各ホストに対して行った結果、ホスト上で稼働しているＶＭまたはコンテナの全てをマイグレーション可能な場合、対応するホストの移動可能フラグを“ｔｒｕｅ”とする。例えば、ホスト３のように全てのＶＭ（「ＶＭ Ｆ」及び「ＶＭ Ｇ」）を他のホストにマイグレーションできない場合、移動可能フラグを“ｆａｌｓｅ”とする。図１５のシミュレーションでは、ホスト１のシミュレーションに関して、ホスト３に新規に「ＶＭ Ｈ」、「ＶＭ Ｉ」を作成する必要があることから、図１６のリスト４００においてホスト１の「ＶＭ新規作成数」を２とし、「ＶＭ新規作成先ホスト」を「ホスト３」とする。

先にも述べたように、コンテナを分割してマイグレーションを実行する場合、分割したコンテナの一部は、そのコンテナを稼働させるＶＭとともにライブマイグレーションによって移動できるが、残りのコンテナはライブマイグレーションによっては移動できない。この場合、分割した残りのコンテナの移動先となるＶＭを他のホスト上で新たに作成し、作成したＶＭ上でコンテナＯＳを起動させてから初めて移動可能となる。

ここで、複数のホストが同時に故障等して、複数のホスト上で稼働しているＶＭ又はコンテナを移動させなければならない状況は非常に稀であると考えられる。そのため、シミュレーション結果のリスト４００の「ＶＭ新規作成数」の列に記録されている数の最大値の数（図１６の例では、２つ）のＶＭを作成し、各ホスト３１０で共有するストレージ装置１１０に作成したＶＭのデータを保存しておく。その際、作成したＶＭ上にコンテナＯＳを稼働させた状態で、保存しておいてもよい。いずれかのホスト３１０上で稼働するコンテナを分割して移動させる必要が生じたときに、ストレージ装置１１０に保持しておいたＶＭを利用することで、業務プロセスに支障をきたさない程度の短い時間内にコンテナの移動を行うことができる。なお、作成したＶＭの保存方法としては、いわゆるホットスタンバイ方式で保存しても良いし、いわゆるコールドスタンバイ方式で保存しても良い。図１６に示すリスト４００の情報は、管理サーバ１３０のメモリ１３３上の記憶領域に保持してもよいし、ストレージ装置１１０上の記憶領域に保持してもよい。

図１６のリスト４００において、ホスト３の移動可能フラグは“ｆａｌｓｅ”となっており、仮にホスト３でハードウェア故障等が発生した場合には、適切にマイグレーションを行うことができない。そのため、シミュレーション結果のリスト４００で移動可能フラグが“ｆａｌｓｅ”のホストがある場合には、管理マネージャ３００は、システムの運用管理者にマイグレーションを実行できないホストがあることを通知する。運用管理者は、管理マネージャ３００からの通知に基づいて、不足しているハードウェアリソースの追加等を行う。

図１７は、図１３の運用例においてホスト１上の仮想マシン又はコンテナのマイグレーションが必要になった場合の処理の例を示す図である。図１７に示すホスト３では、図１６のシミュレーション結果のリスト４００に沿って、予めホスト３上にコンテナＯＳが起動された「ＶＭ Ｈ」、「ＶＭ Ｉ」を準備してある状態となっている。そのため、仮に、ホスト１のハードウェア故障や保守点検によるマイグレーションが急に必要になったとしても、ホスト１上のコンテナ上で実行されているアプリケーションによる業務プロセスを停止させることなく、短い時間内にマイグレーションを行うことができる。

図１４〜図１６を用いて説明した各ホストコンピュータ上で稼働するＶＭ又はコンテナのマイグレーションの可否判断のシミュレーションを管理マネージャ３００行う際のフローチャートを図１８〜図２４を用いて説明する。管理マネージャ３００は、情報処理システム１０に含まれるホストコンピュータ１００上で稼働するＶＭゲスト３２０やコンテナ３３０の数が変更された場合や、一定期間を経過するごとに、以下の図１８〜図２４に示すマイグレーションの可否判定を行う。そして、シミュレーションによる判定の結果、新たにＶＭを起動させておくべきホストがあれば、そのホスト上でＶＭを起動させる。また、シミュレーションによる判定の結果、ハードウェアリソース不足によってマイグレーションできないホストがある場合には、不足しているハードウェアリソースを追加するよう、管理マネージャ３００がシステムの運用管理者に通知する。

図１８〜図２４に示される管理マネージャ３００によるマイグレーションの可否判定の処理は、管理サーバ１３０のＣＰＵ１３１が、メモリ１３３に格納されたプログラムやデータ、並びに、各ホストコンピュータから収集したモニタ情報を用いて実行する。

図１８、図１９は、実施例に係るマイグレーションの可否判定処理の全体フローを示すフローチャートである。まず、情報処理システム１０に含まれるホストコンピュータ１００（以下、単に「ホスト」と記載する）について、各ホスト上で稼働しているＶＭ又はコンテナのマイグレーションを行うことが可能かどうかを判定する（Ｓ２０１〜Ｓ２１４）。

図１４〜図１６を用いた説明では、説明を簡単にするために、ホストコンピュータ１００のハードウェアとしてＣＰＵ１０１のリソースに着目して説明した。しかし、実際には、ＣＰＵリソースだけでなく、各アプリケーションプログラムが使用するメモリのリソースも問題となるので、ＣＰＵ１０１のリソースだけでなく、メモリ１０３のリソースも考慮してマイグレーションの可否判断を行うことが望ましい。以下、ＣＰＵリソースやメモリリソース等のハードウェアリソースを単に「リソース」と記載して説明する。

図１８の処理では、ホストの数をＮ（Ｎは自然数）とし、変数ｎ（ｎは自然数）が１からＮになるまで、Ｓ２０１〜Ｓ２１４の処理を繰り返す。まず、マイグレーションの可否判定対象となる最初のホスト（ｎ＝１）を特定し（Ｓ２０１）、特定したホスト以外のマイグレーションの移動先となるホストの全体のリソースの空き容量を計算する（Ｓ２０２）。移動先となるホストの全体のリソースの空き容量が足りない場合には（Ｓ２０３でＮＯ）、移動可能フラグを“ｆａｌｓｅ”にするとともに、必要なＶＭ数、すなわち、コンテナ等の移動に必要となる新規に作成すべきＶＭ数を０とする（Ｓ２０５）。そして、Ｓ２１４に進む。

移動先となるホストの全体のリソースの空き容量が足りる場合（Ｓ２０３でＹＥＳ）、コンテナを稼働していないＶＭについて移動可能であるかどうかをＳ２０４のサブルーチンで判定する。Ｓ２０４のサブルーチンの処理の詳細について、図２０を用いて説明する。

図２０は、コンテナが稼働されていないＶＭのマイグレーションの可否判定を行うサブルーチンＳ２０４の処理を示すフローチャートである。

まず対象ホスト上で稼働しているＶＭのうち、コンテナが稼働されていないＶＭを抽出する（Ｓ２２１）。Ｓ２２１で抽出したコンテナが稼働されていないＶＭをリソース使用量の多い順にソートする（Ｓ２２２）。次に、移動先の候補となるホストを、リソースの空き容量の多い順にソートする（Ｓ２２３）。

Ｓ２２１で抽出したコンテナが稼働されていないＶＭの数をＭ（Ｍは自然数、以下同じ）として、変数ｍ（ｍは自然数、以下同じ）が１からＭになるまで、Ｓ２２２でソートした順にＳ２２１で抽出したＶＭを選択し、Ｓ２２４〜Ｓ２３２の処理を行う。Ｓ２２４で選択されたＶＭの移動可否を判定する前に、判定対象ホスト（Ｓ２０１で選択されたホスト）の移動可能フラグを“ｆａｌｓｅ”にする（Ｓ２２５）。そして、ＶＭの移動先の候補となるホストの数をＨ（Ｈは自然数、以下同じ）として、変数ｈ（ｈは自然数、以下同じ）が１からＨになるまで、Ｓ２２３でソートした順に移動先候補のホストを選択し、Ｓ２２６〜Ｓ２３０の処理を行う。

Ｓ２２４で選択されたＶＭについて、Ｓ２２６で選択された移動先ホストの候補にＶＭ単位で移動できる場合（Ｓ２２７でＹＥＳ）、選択した移動先ホストのリソース空き容量からＳ２２４で選択されたＶＭのリソース使用量を引く（Ｓ２２８）。次に、判定対象ホストの移動可能フラグを“ｔｒｕｅ”にし（Ｓ２２９）、Ｓ２２６〜Ｓ２３０のループを抜ける。

Ｓ２２４で選択されたＶＭについて、Ｓ２２６で選択された移動先ホストの候補にＶＭ単位で移動できない場合（Ｓ２２７でＮＯ）、移動先ホストの候補を変更して（Ｓ２３０）、再度、Ｓ２２４で選択されたＶＭをＶＭ単位で移動できるかどうかを判定する（Ｓ２２７）。いずれかの移動先ホストの候補にＶＭを移動できる場合には、Ｓ２２８、Ｓ２２９の処理を経て移動可能フラグが“ｔｒｕｅ”の状態でＳ２２６〜Ｓ２３０のループを抜ける。一方、いずれの移動先ホストの候補にもＶＭを移動できない場合には、移動可能フラグが“ｆａｌｓｅ”の状態でＳ２２６〜Ｓ２３０のループを抜ける。

Ｓ２２６〜Ｓ２３０のループを抜けた後、移動可能フラグの状態を判定する（Ｓ２３１）。Ｓ２２４で選択されたＶＭについての移動可否判定の結果、移動可能フラグが“ｔｒｕｅ”であれば（Ｓ２３１で“ｔｒｕｅ”）、ｍの値を更新し（Ｓ２３２）、次のＶＭについてＳ２２５〜Ｓ２３１の処理を繰り返す。コンテナが稼働されていないＶＭのうち、１つでも移動先ホストの候補に移動できないＶＭがあれば、他のＶＭについてＶＭの移動可否を判定する意味がないので、Ｓ２３１の判定で“ｆａｌｓｅ”の場合には、Ｓ２２４〜Ｓ２３２のループを抜ける。

そして、再度移動可能フラグを判定し（Ｓ２３３）、Ｓ２３３の判定において移動可能フラグが“ｔｒｕｅ”であれば、Ｓ２０４のサブルーチンの戻り値として、コンテナが稼働されていないＶＭの移動が可能と返す（Ｓ２３５）。一方、Ｓ２３３の判定において移動可能フラグが“ｆａｌｓｅ”であれば、Ｓ２０４のサブルーチンの戻り値として、コンテナが稼働されていないＶＭの移動が不可と返す（Ｓ２３４）。なお、図１８のフローチャートの処理において、Ｓ２３４とＳ２３５によって返すサブルーチンＳ２０４の戻り値を使わない場合には、Ｓ２３３〜Ｓ２３５を省略しても良い。

ここで、図１８のＳ２０６に戻って説明する。Ｓ２０４のコンテナが稼働されていないＶＭのマイグレーションの可否判定を行った後の移動先候補のリソースの空き容量の値で、図１８の判定処理における移動先候補となるホストのリソース空き容量の値を更新する（Ｓ２０６）。なお、Ｓ２０４のサブルーチンのＳ２２９で更新する移動先ホストのリソース空き容量の変数と、図１８のＳ２０２、Ｓ２０３、Ｓ２０６で扱う移動先ホストのリソース空き容量の変数とが同じ場合、Ｓ２０６の処理を省略しても良い。

次に、コンテナを稼働させているＶＭについて、ＶＭ単位で移動可能であるかどうかを、Ｓ２０７のサブルーチンで判定する。Ｓ２０７のサブルーチンの処理の詳細については、図２１を用いて説明する。

図２１は、ホストコンピュータ内で、コンテナを稼働させている全てのＶＭについてＶＭ単位でのマイグレーション可否判定を行うサブルーチンＳ２０７の処理を示すフローチャートである。まず、判定対象ホスト内で、コンテナを稼働させている全てのＶＭをリソース使用量の多い順にソートする（Ｓ２４１）。次に、移動先の候補となるホストを、リソースの空き容量の多い順にソートする（Ｓ２４２）。

判定対象のホストにおいて、コンテナを稼働させているＶＭの数をＭとして、変数ｍが１からＭになるまで、Ｓ２４１でソートした順に、コンテナを稼働させているＶＭを選択し、Ｓ２４３〜Ｓ２５１の処理を行う。Ｓ２４３で選択されたＶＭの移動可否を判定する前に、判定対象ホストの移動可能フラグを“ｆａｌｓｅ”に設定する（Ｓ２４４）。そして、ＶＭの移動先の候補となるホストの数をＨとして、変数ｈが１からＨになるまで、Ｓ２４２でソートした順に移動先候補のホストを選択し、Ｓ２４５〜Ｓ２４９の処理を行う。

Ｓ２４３で選択されたＶＭについて、Ｓ２４５で選択された移動先ホストの候補にＶＭ単位で移動できる場合（Ｓ２４６でＹＥＳ）、選択した移動先ホストのリソース空き容量からＳ２４３で選択されたＶＭのリソース使用量を引く（Ｓ２４７）。次に、判定対象ホストの移動可能フラグを“ｔｒｕｅ”にし（Ｓ２４８）、Ｓ２４５〜Ｓ２４９のループを抜ける。

Ｓ２４３で選択されたＶＭについて、Ｓ２４５で選択された移動先ホストの候補にＶＭ単位で移動できない場合（Ｓ２４６でＮＯ）、移動先ホストの候補を変更して（Ｓ２４９）、再度Ｓ２４３で選択されたＶＭをＶＭ単位で移動できるかどうかを判定する（Ｓ２４６）。いずれかの移動先ホストの候補にＶＭを移動できる場合には、Ｓ２４７、Ｓ２４８の処理を経て移動可能フラグが“ｔｒｕｅ”の状態でＳ２４５〜Ｓ２４９のループを抜ける。一方、いずれの移動先ホストの候補にもＶＭを移動できない場合には、移動可能フラグが“ｆａｌｓｅ”の状態でＳ２４５〜Ｓ２４９のループを抜ける。

Ｓ２４５〜Ｓ２４９のループを抜けた後、移動可能フラグの状態を判定する（Ｓ２５０）。Ｓ２４３で選択されたＶＭの移動可否判定の結果、移動可能フラグが“ｔｒｕｅ”であれば（Ｓ２５０で“ｔｒｕｅ”）、ｍの値を更新し（Ｓ２５１）、次のＶＭについてＳ２４４〜Ｓ２５０の処理を繰り返す。コンテナが稼働されているＶＭのうち、１つでも移動先ホストの候補に移動できないＶＭがあれば、他のＶＭについてＶＭの移動可否を判定する意味がないので、Ｓ２５０の判定で“ｆａｌｓｅ”の場合には、Ｓ２４３〜Ｓ２５１のループを抜ける。

Ｓ２４３〜Ｓ２５１のループを抜けた後、再度移動可能フラグを判定し（Ｓ２５２）、Ｓ２５２の判定において移動可能フラグが“ｔｒｕｅ”であれば、Ｓ２０７のサブルーチンの戻り値として、コンテナが稼働されているＶＭについてＶＭ単位での移動が可能と返す（Ｓ２５４）。一方、Ｓ２５２の判定において移動可能フラグが“ｆａｌｓｅ”であれば、Ｓ２０７のサブルーチンの戻り値として、コンテナが稼働されているＶＭのＶＭ単位での移動が不可と返す（Ｓ２５３）。なお、図１８のフローチャートの処理において、Ｓ２５３、Ｓ２５４によって返すサブルーチンＳ２０７の戻り値を使わない場合には、Ｓ２５２〜Ｓ２５４を省略してもよい。

ここで、図１８のＳ２０８に戻って説明する。Ｓ２０７のサブルーチンによって、コンテナを稼働させているＶＭの全てについて、ＶＭ単位で移動可能である場合（Ｓ２０８でＹＥＳ）、移動可能フラグを“ｔｒｕｅ”にする。そして、必要なＶＭ数、すなわち、コンテナの移動に必要となる新規に作成すべきＶＭ数を０とし（Ｓ２１０）、Ｓ２１４に進む。一方、コンテナを稼働させているＶＭの全てについて、ＶＭ単位で移動できない場合（Ｓ２０８でＮＯ）、Ｓ２０９のサブルーチンにおいてコンテナ単位で移動可能かどうかを判定する。Ｓ２０９のサブルーチンの処理の詳細については、図２２を用いて説明する。

図２２、図２３は、ホストコンピュータ内で稼働している結合優先度の高いコンテナのマイグレーションの可否判定を行うサブルーチンＳ２０９の処理を示すフローチャートである。図２２、図２３の説明において、「結合優先度」を単に「優先度」と記載して説明する。まず、判定対象ホスト内のＶＭ上で稼働しているコンテナを優先度の高い順にソートする（Ｓ２６１）次に、移動先の候補となるホストを、リソースの空き容量の多い順にソートする（Ｓ２６２）。

Ｓ２６１で優先度の高い順にソートしたコンテナを参照して、優先度の高いコンテナを含む親ＶＭを抽出する。ここで、「親ＶＭ」とは、着目するコンテナを稼働させているＶＭをいうものとする。抽出した親ＶＭの数をＰ（Ｐは自然数）とすると、変数ｐ（ｐは自然数）が１からＰになるまで、親ＶＭを１つずつ選択してＳ２６３〜Ｓ２７４の処理を行う。Ｓ２６３で選択されたＶＭに含まれる優先度が高いコンテナの移動可否を判定する前に、判定対象ホストの移動可能フラグを“ｆａｌｓｅ”に設定する（Ｓ２６４）。

そして、ＶＭの移動先の候補となるホストの数をＨとして、変数ｈが１からＨになるまで、Ｓ２６２でソートした順に移動先候補のホストを選択し、Ｓ２６５〜Ｓ２７２の処理を行う。

Ｓ２６３で選択された親ＶＭに含まれる優先度が「高」の全てのコンテナと、優先度が「中」の全てのコンテナとを一緒にＳ２６５で選択された移動先ホストの候補に移動できる場合（Ｓ２６６でＹＥＳ）、これらの優先度が「高」、「中」のコンテナを移動するコンテナに設定する（Ｓ２６７）。一方、Ｓ２６６の判定において、優先度が「高」、「中」のコンテナをＳ２６５で選択された移動先ホストの候補に移動できない場合（Ｓ２６６でＮＯ）、Ｓ２６８に進む。

Ｓ２６８では、優先度が「高」の全てのコンテナについて、Ｓ２６５で選択された移動先ホストの候補に一緒に移動可能かどうかを判定する。優先度が「高」の全てのコンテナについて移動先ホストの候補に一緒に移動可能な場合（Ｓ２６８でＹＥＳ）、優先度が「高」のコンテナを移動するコンテナに設定する（Ｓ２６９）。一方、優先度が「高」の全てのコンテナについて移動先ホストの候補に一緒に移動できない場合（Ｓ２６８でＮＯ）、コネクタＣを介してＳ２７２に進み、変数ｈを更新して、再度、次の移動先ホストをＳ２６５で選択して、Ｓ２６５〜Ｓ２７２の処理を行う。

Ｓ２６７又はＳ２６９において移動するコンテナが設定された場合、Ｓ２６５で選択された移動先ホストのリソースの空き容量から、移動するコンテナのリソース使用量を引く（Ｓ２７０）。次に、判定対象ホストの移動可能フラグを“ｔｒｕｅ”にし（Ｓ２７１）、コネクタＤを介してＳ２６５〜Ｓ２７２のループを抜ける。

Ｓ２６３で選択された親ＶＭに含まれる優先度「高」の全てのコンテナが、Ｓ２６５で選択されたいずれの移動先のホストへも一緒に移動できない場合には、移動可能フラグが“ｆａｌｓｅ”の状態でＳ２６５〜Ｓ２７２のループを抜ける。

Ｓ２６５〜Ｓ２７２のループを抜けた後、移動可能フラグの状態を判定する（Ｓ２７３）。Ｓ２７３において、移動可能フラグが“ｔｒｕｅ”であれば、ｐの値を更新し（Ｓ２７４）、次の親ＶＭについてＳ２６４〜Ｓ２７３の処理を繰り返す。移動可能フラグが“ｆａｌｓｅ”であれば、他の親ＶＭについてＳ２６４〜Ｓ２７３の判定をする意味がないので、Ｓ２６３〜Ｓ２７４のループを抜ける。

Ｓ２６３〜Ｓ２７４のループを抜けた後、再度、移動可能フラグを判定する（Ｓ２７５）。Ｓ２７５の判定において、移動可能フラグが“ｆａｌｓｅ”の場合、移動に必要なＶＭ数、すなわち、コンテナの移動に必要となる新規に作成すべきＶＭ数を０とする（Ｓ２７６）。そして、Ｓ２０９のサブルーチンの戻り値として、移動可能フラグと新規に作成すべきＶＭ数（この場合０）を返す（Ｓ２７８）。

Ｓ２７５の判定において、移動可能フラグが“ｔｒｕｅ”である場合、Ｓ２７７のサブルーチンにおいて、Ｓ２６７又はＳ２６９で移動するコンテナとして設定されていない残りのコンテナの移動可否を判定する。Ｓ２７７のサブルーチンの処理の詳細については、図２４を用いて説明する。

図２４は、ホストコンピュータ内で稼働している優先度が中又は低のコンテナのマイグレーションの可否判定を行うサブルーチンＳ２７７の処理を示すフローチャートである。まず、図２３のＳ２６７又はＳ２６９で移動するコンテナとして設定されていない残りのコンテナについて、リソース使用量の多い順にソートする（Ｓ２８１）。次に、コンテナの移動先の候補となるホストを、リソースの空き容量の多い順にソートする（Ｓ２８２）。

Ｓ２８１でソートしたコンテナの数をＫ（Ｋは自然数）、変数ｋ（ｋは自然数）が１からＫになるまで、Ｓ２８１でソートした順に残りのコンテナを選択し、Ｓ２８３〜Ｓ２９２の処理を行う。Ｓ２８３で選択されたコンテナの移動可否を判定する前に、移動可能フラグを“ｆａｌｓｅ”に設定する（Ｓ２８４）。そして、コンテナの移動先の候補となるホストの数をＨとして、変数ｈが１からＨになるまで、Ｓ２８２でソートした順に移動先候補のホストを選択し、Ｓ２８５〜Ｓ２９０の処理を行う。

Ｓ２８３で選択されたコンテナには優先度「高」のコンテナが含まれていないため、選択されたコンテナ単体でいずれかの移動先ホストの候補に移動できるかどうかを判定する（Ｓ２８６）。選択されたコンテナが移動先ホストの候補に移動できる場合（Ｓ２８６でＹＥＳ）、選択した移動先ホストのリソース空き容量からＳ２８３で選択されたコンテナのリソース使用量を引く（Ｓ２８７）。

次にＳ２８３で選択されたコンテナの情報と、移動先ホストの情報とを、メモリ１３３又はストレージ１１０内の不図示のテーブルに格納する（Ｓ２８８）。Ｓ２８８でテーブルに格納したコンテナの移動先の情報は、後述するＳ２９５の移動に必要なＶＭ数の計算に用いられる。また、Ｓ２８８でテーブルに格納したコンテナの移動先の情報を、将来、仮にマイグレーションをする必要が生じた際に参照するようにしてもよい。そして、移動可能フラグを“ｔｒｕｅ”に設定して（Ｓ２８９）、Ｓ２８５〜Ｓ２９０のループを抜ける。

Ｓ２８３で選択されたコンテナについて、Ｓ２８５で選択された移動先ホストの候補に移動できない場合（Ｓ２８６でＮＯ）、変数ｈを更新して移動先ホストの候補を変更する（Ｓ２９０）。そして、再度Ｓ２８３で選択したコンテナを変更した移動先ホストの候補に移動できるかどうかを判定する（Ｓ２８６）。

いずれかの移動先ホストにコンテナを移動できる場合には、Ｓ２８７〜Ｓ２８９の処理を経て移動可能フラグが“ｔｒｕｅ”の状態でＳ２８５〜Ｓ２９０のループを抜ける。一方、いずれの移動先ホストの候補にもコンテナを移動できない場合には、移動可能フラグが“ｆａｌｓｅ”の状態でＳ２８５〜Ｓ２９０のループを抜ける。

Ｓ２８５〜Ｓ２９０のループを抜けた後、移動可能フラグの状態を判定する（Ｓ２９１）。Ｓ２８３で選択したコンテナの移動可否の判定の結果、移動可能フラグが“ｔｒｕｅ”であれば（Ｓ２９１で“ｔｒｕｅ”）、ｋの値を更新し（Ｓ２９２）、次のコンテナについてＳ２８４〜Ｓ２９２の処理を繰り返す。残っているコンテナのうち、１つでも移動先ホストの候補に移動できないコンテナがあれば、他のコンテナについて移動可否を判定する意味がないので、Ｓ２９１の判定結果が“ｆａｌｓｅ”であれば、Ｓ２８３〜Ｓ２９２のループを抜ける。

Ｓ２８３〜Ｓ２９２のループを抜けた後、再度移動可能フラグを判定し（Ｓ２９３）、Ｓ２９３の判定において移動可能フラグが“ｔｒｕｅ”であれば、Ｓ２８８で格納したテーブルの情報を参照して、移動に必要なＶＭ数、すなわち、コンテナの移動に必要となる新規に作成すべきＶＭ数を計算する（Ｓ２９５）。一方、Ｓ２９３の判定において移動可能フラグが“ｆａｌｓｅ”であれば、移動に必要なＶＭ数を０にする（Ｓ２９４）。そして、Ｓ２７７のサブルーチンの戻り値として、Ｓ２９５で計算した移動に必要なＶＭ数と移動可能フラグを返す（Ｓ２９６）。

Ｓ２７７のサブルーチンを抜けると、図２３のＳ２７８に進み、Ｓ２７７の戻り値を、Ｓ２０９のサブルーチンの戻り値として返す（Ｓ２７８）。Ｓ２０９のサブルーチンを抜けると、図１８のＳ２１１の処理に移る。

図１８に戻って、図１８のフローチャートのＳ２１１の続きを説明する。Ｓ２０９のサブルーチンによって、全てのコンテナについて、コンテナ単位であれば移動可能であると判定された場合（Ｓ２１１でＹＥＳ）、移動可能フラグを“ｔｒｕｅ”にする（Ｓ２１３）。また、この場合、分割したコンテナを移動させる際に必要となる新たに作成すべきＶＭの数を、図１６に示すリスト４００に追加する（Ｓ２１３）。一方、Ｓ２０９の判定においてコンテナ単位で全てのコンテナを移動できないと判定した場合には（Ｓ２１１でＮＯ）、移動可能フラグを“ｆａｌｓｅ”にする（Ｓ２１２）。そして、必要なＶＭ数、すなわち、コンテナの移動に必要となる新規に作成すべきＶＭ数を０とする（Ｓ２１２）。

そして、Ｓ２１４でｎの値を更新し、次のホストについて、ホスト上で稼働しているＶＭ又はコンテナのマイグレーションを行うことができるか否かを判定する。Ｓ２０１〜Ｓ２１４で全てのホストについてのマイグレーションの可否判定が終了すると、コネクタＢを介して図１９のＳ２１５に移る。

図１９は、全てのホストについてマイグレーションの可否判定が終了した後の処理についてのフローチャートである。Ｓ２１５では、図１６に示すようなシミュレーション結果のリスト４００を参照して、「ＶＭ新規作成数」の列に記憶されている数の最大値を求める。そして、Ｓ２１５で求めた作成すべきＶＭの数（「ＶＭ新規作成数」の最大値）に応じて、新たなＶＭを作成し、各ホスト３１０で共有するストレージ装置１１０に作成したＶＭのデータを保存しておく（Ｓ２１６）。その際、作成したＶＭ上にコンテナＯＳを稼働させた状態のデータとして保存しておいてもよい。また、過去に作成して使われていないＶＭ等があれば削除する（Ｓ２１６）。

その後、図１６に示すシミュレーション結果のリスト４００を参照して、移動可能フラグが“ｆａｌｓｅ”となっているホストがある場合、移動可能フラグが“ｆａｌｓｅ”のホストに関する情報を情報処理システム１０の運用管理者に通知する。運用管理者は、移動可能フラグが“ｆａｌｓｅ”のホストがある場合には、マイグレーションを行う際に足りないハードウェア資源のリソースを追加や、ホストコンピュータの追加を行う。

以上の説明のように、本実施形態では、管理サーバ１３０上で動作する管理マネージャ３００が、各ホストコンピュータ１００上の仮想環境で稼働しているＶＭやコンテナのリソース使用量、各コンテナの通信状況等のモニタ情報を収集する。管理マネージャ３００は、収集したモニタ情報に基づいて、各コンテナの結合優先度を決定する。そして、ホストコンピュータ１００の故障や保守管理に備えて、管理マネージャ３００は、予めＶＭやコンテナのマイグレーションを行うことが可能であるかどうかをシミュレーションする。シミュレーションの結果、コンテナを分割して移動する必要がある場合には、コンテナの移動先に予めＶＭを作成しておく。このようにすることで、ホストコンピュータ１００の故障等が発生した場合でも、ＶＭやコンテナ上で実行されているアプリケーションプログラムによる業務プロセスを停止させることなく、マイグレーションを行うことが可能となる。

以上、本発明の好ましい実施例について説明したが、本発明は特定の実施例に限定されるものではなく、種々の変形や変更が可能である。例えば、各コンテナの通信状況のモニタをエージェント３４０で行うのではなく、ハイパーバイザ２０１等で行っても良い。また、各ホストコンピュータにおけるＶＭやハードウェアのリソース使用量の指標として、ＣＰＵリソースやメモリリソースに限らず、ネットワーク通信回線の使用量等、他のハードウェアリソースの使用量を指標としてもよい。

なお、前述した情報処理システムが提供する仮想環境の提供および管理マネージャの処理をコンピュータに実行させるコンピュータプログラム、およびそのプログラムを記録した、非一時的なコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで、非一時的なコンピュータ読み取り可能な記録媒体は、例えばＳＤメモリカードなどのメモリカードである。なお、前記コンピュータプログラムは、前記記録媒体に記録されたものに限られず、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送されるものであってもよい。

１０ ：情報処理システム
２０ ：ネットワーク
３０ ：クライアント装置
１００：ホストコンピュータ
１０１：ＣＰＵ
１０２：入出力装置インタフェース回路
１０３：メモリ
１０４：ネットワークインタフェース回路
１０５：ストレージインタフェース回路
１０６：ローカルバスインタフェース回路
１１０：ストレージ装置
１２０：ネットワークスイッチ
１３０：管理サーバ
１３１：ＣＰＵ
１３２：入出力装置インタフェース回路
１３３：メモリ
１３４：ネットワークインタフェース回路
１３５：ストレージインタフェース回路
１３６：ローカルバスインタフェース回路
１４０：ローカルバス
２００：ハイパーバイザ型仮想化環境
２０１：ハイパーバイザ
２０２：仮想マシン
２１０：コンテナ型仮想化環境
２１１：コンテナＯＳ
２１２：コンテナ
３００：管理マネージャ
３１０：ホスト
３２０：ＶＭゲスト
３３０：コンテナ
３４０：エージェント
４００：シミュレーション結果のリスト

Claims (10)

1. 仮想マシンを生成するプログラムを実行するとともに、前記仮想マシン上で動作するオペレーティング・システム（ＯＳ）により提供されるアプリケーションプログラムの実行環境であって、前記ＯＳの一部を共有しつつ前記実行環境ごとに異なる設定を有することで、前記ＯＳ上で互いに独立して稼働される複数の仮想ＯＳを生成するプログラムを実行するプロセッサをそれぞれ備える複数のコンピュータと、
   前記複数のコンピュータに含まれる一のコンピュータ上で稼働する前記仮想ＯＳを、前記複数のコンピュータに含まれる他のコンピュータ上で稼働する仮想マシン上に移動させるマイグレーションを行う管理装置と、を備え、
   前記管理装置は、
   同じ仮想マシン上で稼働する複数の仮想ＯＳのうち、異なる仮想ＯＳ上で実行されるアプリケーションプログラムどうしで通信を行う複数の仮想ＯＳを検出することにより、前記マイグレーションを行う際に同じ仮想マシン上で稼働させるべき複数の仮想ＯＳを特定し、
   特定した複数の仮想ＯＳに対してマイグレーションを実行すべき状況が発生する前に、前記特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させる
   ことを特徴とする情報処理システム。
2. 前記管理装置は、
   前記複数のコンピュータのそれぞれが備えるプロセッサの使用状況を示すモニタ情報を前記複数のコンピュータから取得し、
   取得した前記モニタ情報を参照し、前記複数のコンピュータのそれぞれのプロセッサの使用状況と、前記特定した複数の仮想ＯＳを稼働させるＶＭに係るプロセッサの使用状況とに基づいて、前記特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを稼働する前記他のコンピュータを決定する
   ことを特徴とする請求項１記載の情報処理システム。
3. 前記管理装置は、
   取得した前記モニタ情報を参照し、前記複数のコンピュータ上で稼働している仮想マシンのそれぞれに対して、各仮想マシンのリソース使用量と、移動先候補となるコンピュータの空きリソース量とを比較して、仮想マシンの単位でライブマイグレーションを行うことができるかどうかを判定し、
   仮想マシンの単位でライブマイグレーションを行うことができない仮想マシンがある場合、当該仮想マシン上で実行されている複数の仮想ＯＳのうち、同じ仮想マシン上で稼働する複数の仮想ＯＳのうち、異なる仮想ＯＳ上で実行されるアプリケーションプログラムどうしで通信を行う複数の仮想ＯＳを検出することにより、前記マイグレーションを行う際に同じ仮想マシン上で稼働させるべき複数の仮想ＯＳの特定し、特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させる
   ことを特徴とする請求項２記載の情報処理システム。
4. 前記仮想マシンの各々は、
   各仮想マシン上で稼働されている仮想ＯＳが、自仮想マシンの外部との通信を行うか否かをモニタし、モニタして得られた前記仮想ＯＳの外部との通信の有無に関する情報を前記前記管理装置に送信し、
   前記管理装置は、
   各仮想マシンから取得した前記仮想ＯＳの外部との通信の有無に関する情報を参照して、前記マイグレーションを行う際に同じ仮想マシン上で稼働させるべき複数の仮想ＯＳを特定した場合には、特定した当該複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させ、
   取得した前記モニタ情報を参照して、同じ仮想マシン上の他の仮想ＯＳとは通信を行わず、かつ、当該仮想マシン外部と通信を行う仮想ＯＳが特定された場合には、特定された当該仮想ＯＳの移動先候補となるコンピュータの空きリソースに応じて当該仮想ＯＳの移動先となる仮想マシンを、移動先候補となるコンピュータ上に生成させる
   ことを特徴とする請求項２又は３のいずれか１項に記載の情報処理システム。
5. 前記管理装置は、
   前記複数のコンピュータのそれぞれのプロセッサの使用状況と、前記特定した複数の仮想ＯＳを実行中のプロセッサの使用状況とに基づいて、前記他のコンピュータ上で予め起動させる仮想マシンの数を決定する
   ことを特徴とする請求項２記載の情報処理システム。
6. 前記管理装置は、
   前記複数のコンピュータ上で稼働された各仮想マシン上で稼働する仮想ＯＳの通信設定に関する情報を各仮想マシンから取得し、
   取得した各仮想ＯＳの通信設定に関する情報に基づいて、同じ仮想マシン上で互いに通信を行う複数の仮想ＯＳを検出する
   ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理システム。
7. 前記仮想マシンの各々は、
   前記仮想ＯＳを起動させる際の前記仮想ＯＳの通信設定を行うコマンドをモニタし、モニタして得られた前記仮想ＯＳの通信設定についての情報を前記管理装置に送信し、
   前記管理装置は、
   各仮想マシンから取得した前記仮想ＯＳの通信設定についての情報を参照して互いに通信を行う前記複数の仮想ＯＳを検出する
   ことを特徴とする請求項６に記載の情報処理システム。
8. 前記管理装置は、
   前記他のコンピュータ上に生成させた仮想マシンについて、前記特定した複数の仮想ＯＳに対してマイグレーションを実行すべき情報が発生するまで、該仮想マシンを停止状態にさせる
   ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理システム。
9. 仮想マシンを生成するプログラムを実行するとともに、前記仮想マシン上で動作するオペレーティング・システム（ＯＳ）により提供されるアプリケーションプログラムの実行環境であって、前記ＯＳの一部を共有しつつ前記実行環境ごとに異なる設定を有することで、前記ＯＳ上で互いに独立して稼働される複数の仮想ＯＳを生成するプログラムを実行するプロセッサをそれぞれ備える複数のコンピュータを管理する管理装置において、
   メモリと、
   前記メモリに格納されたプログラムを実行し、前記複数のコンピュータに含まれる一のコンピュータ上で稼働する前記仮想ＯＳを、前記複数のコンピュータに含まれる他のコンピュータ上で稼働する仮想マシン上に移動させるマイグレーションを行う処理装置とを備え、
   前記処理装置は、
   同じ仮想マシン上で稼働する複数の仮想ＯＳのうち、異なる仮想ＯＳ上で実行されるアプリケーションプログラムどうしで通信を行う複数の仮想ＯＳを検出することにより、前記マイグレーションを行う際に同じ仮想マシン上で稼働させるべき複数の仮想ＯＳを特定し、
   特定した複数の仮想ＯＳに対してマイグレーションを実行すべき状況が発生する前に、前記特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させる
   ことを特徴とする管理装置。
10. 仮想マシンを生成するプログラムを実行するとともに、前記仮想マシン上で動作するオペレーティング・システム（ＯＳ）により提供されるアプリケーションプログラムの実行環境であって、前記ＯＳの一部を共有しつつ前記実行環境ごとに異なる設定を有することで、前記ＯＳ上で互いに独立して稼働される複数の仮想ＯＳを生成するプログラムを実行するプロセッサをそれぞれ備える複数のコンピュータを管理する管理装置に、
    同じ仮想マシン上で稼働する複数の仮想ＯＳのうち、異なる仮想ＯＳ上で実行されるアプリケーションプログラムどうしで通信を行う複数の仮想ＯＳを検出することにより、前記複数のコンピュータに含まれる一のコンピュータ上で稼働する前記仮想ＯＳを、前記複数のコンピュータに含まれる他のコンピュータ上で稼働する仮想マシン上に移動させるマイグレーションを行う際に、同じ仮想マシン上で稼働させるべき複数の仮想ＯＳを特定し、
    特定した複数の仮想ＯＳに対してマイグレーションを実行すべき状況が発生する前に、前記特定した複数の仮想ＯＳについてマイグレーションを行う際の移動先となる仮想マシンを、前記他のコンピュータ上に生成させる
    処理を行わせる、プログラム。

Images