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

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

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

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

特開2010−244181号公報

特開2010−205200号公報

WO2012/120664号公報

近年、コンテナ型仮想化によるアプリケーション実行環境が普及しはじめている。コンテナ型仮想化は、VMのようなサーバのハードウェアを仮想化したものとは異なり、OSのプロセス空間を複数のグループに区切って別のサーバのように利用する技術である。そのため、コンテナ型仮想化は、「OSの仮想化」とも呼ばれる。コンテナ型仮想化技術の例としては、Docker社が提供するコンテナ型仮想化環境であるDocker(登録商標)や、Solaris(登録商標)コンテナ、BSDのJailなどが知られている。

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

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

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

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

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

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

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

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

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

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

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

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

図1は、実施例における情報処理システムのシステム構成を示す図である。

図2は、ホストコンピュータ100のハードウェア構成の一例を示す図である。

図3は、ホストコンピュータ100におけるアプリケーション実行環境を説明する図である。

図4は、管理サーバ130のハードウェア構成の一例を示す図である。

図5は、情報処理システム10におけるアプリケーション実行環境の一例を説明する図である。

図6は、情報処理システム10における業務アプリケーションの運用例を説明する図である。

図7は、図6の運用例における各VMゲスト320で実行されるエージェント340の処理を説明する図である。

図8は、各コンテナの通信状況に応じたコンテナの優先順位付けの例を記載した表を示す図である。

図9は、図7の運用例における各コンテナの通信状況の例と優先順位付けの例を記載した表を示す図である。

図10は、コンテナの優先順位付けを行う全体フローチャートである。

図11は、コンテナの優先順位付けを行うフローチャート(1)である。

図12は、コンテナの優先順位付けを行うフローチャート(2)である。

図13は、図7の運用例において管理マネージャが各ホストコンピュータ100から取得する、ハードウェアリソースの使用状況に関する情報の例を示す図である。

図14は、図13の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーションを説明する1つ目の図である。

図15は、図13の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーションを説明する2つ目の図である。

図16は、図13の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーション結果のリストを示す図である。

図17は、図13の運用例においてホスト1上の仮想マシン又はコンテナのマイグレーションが必要になった場合の処理の例を示す図である。

図18は、実施例に係るマイグレーションの可否判定処理の全体フローの前半を示すフローチャートである。

図19は、実施例に係るマイグレーションの可否判定処理の全体フローの後半を示すフローチャートである。

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

図21は、ホストコンピュータ内で、コンテナを稼働させている全てのVMについてのVM単位でのマイグレーション可否判定を行うサブルーチンの処理を示すフローチャートである。

図22は、ホストコンピュータ内で稼働している優先度の高いコンテナのマイグレーションの可否判定を行うサブルーチンの処理を示すフローチャートの前半を示す図である。

図23は、ホストコンピュータ内で稼働している優先度の高いコンテナのマイグレーションの可否判定を行うサブルーチンの処理を示すフローチャートの後半を示す図である。

図24は、ホストコンピュータ内で稼働している優先度が中又は低のコンテナのマイグレーションの可否判定を行う処理のサブルーチンを示すフローチャートである。

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

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

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

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

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

図2は、ホストコンピュータ100のハードウェア構成の一例を示す図である。ホストコンピュータ100は、CPU101(101A〜101D)と、入出力装置インタフェース回路102と、メモリ103と、ネットワークインタフェース回路104と、ストレージインタフェース回路105と、ローカルバスインタフェース回路106とを備える。各CPU101は、内部バス107を介して、メモリ103や入出力装置インタフェース回路102等の各インタフェース回路(104〜106)にアクセスする。

CPU101(101A〜101D)は、Central Processing Unit(CPU)、Micro-Processing Unit(MPU)等のプロセッサの電子部品である。図2の例では、ホストコンピュータ100が、CPU101A、CPU101B、CPU101C、CPU101Dの4つのCPUを備える例を示しているが、CPUの数は4つに限られず、より多くのCPUを備えてもよい。また、CPUの中に複数のCPUコアや、ハードウェアスレッドを備え、1つのCPUによって、複数のアプリケーションプログラムのプロセスの処理を行えるCPUをCPU101として用いてもよい。さらに、CPUは、ホストコンピュータによってその搭載数が異なっていてもよい。

入出力装置インタフェース回路102は、不図示のマウスやキーボード等のデバイスを含む周辺デバイスへの入出力を制御するための回路である。メモリ103は、RAM(Random Access Memory)等の記憶デバイスである。図2では、1つのメモリ103を図示しているが、メモリ103は複数のRAMを含んでもよく、また、CPU101A〜101Dごとに対応する別々のメモリ103(103A、103B、103C、103D)を備えるようにしてもよい。

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

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

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

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

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

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

図3の例では、仮想マシン202Aと202Bのそれぞれにおいて、コンテナ型仮想化環境210が提供される。コンテナ型仮想化環境では、仮想マシン202上で例えばLinux(登録商標) OSが起動され、Linux OS上でDocker(登録商標)等のコンテナ仮想化ソフトウェアがインストールされる。図3の例では、コンテナ仮想化ソフトウェアがインストールされたLinux OS等のゲストOSを「コンテナOS」と記載する。図3において、各コンテナOS211A、211B上でそれぞれ2つのコンテナが稼働する例を示しているが、コンテナOS211上で稼働するコンテナの数は2個に限られず、ユーザからの要求に応じた数のコンテナを稼働させることができる。

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

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

コンテナ212Aとコンテナ212Bとの間のコンテナ間通信は、コンテナOS211A上でのコンテナ起動時のフラグ設定、又はリンク機能による設定を行うことで設定できる。しかし、コンテナ212C及びコンテナ212Dは、コンテナOS211B上で稼働するため、異なるコンテナOS211上で稼働するコンテナ212Aとコンテナ212Cとの間のコンテナ間通信は行うことができない。この場合、コンテナ212Aとコンテナ212C間の通信はネットワークスイッチ120を介したパケット通信により行う。

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

図4は、管理サーバ130のハードウェア構成の一例を示す図である。管理サーバ130は、CPU131と、入出力装置インタフェース回路132と、メモリ133と、ネットワークインタフェース回路134と、ストレージインタフェース回路135、とを有する。CPU131は、内部バス137を介して、メモリ133や入出力装置インタフェース回路132等の各インタフェース回路(134〜136)にアクセスする。

入出力装置インタフェース回路132は、不図示のマウスやキーボード等のデバイスを含む周辺デバイスへの入出力を制御するための回路である。ネットワークインタフェース回路134は、ネットワーク20を介して他の装置と通信を行うためのインタフェース回路であり、ストレージインタフェース回路135は、ストレージ装置110へのアクセスを行うためのインタフェース回路である。ローカルバスインタフェース回路136は、ローカルバス140を介して各ホストコンピュータ100A〜100C、ストレージ装置110、ネットワークスイッチ120と通信を行うためのインタフェース回路である。

CPU131は、ストレージ装置110やメモリ133に格納されたプログラムを実行することにより、各ホストコンピュータ100の管理を行う。CPU131は、情報処理システム10内の各ホストコンピュータ100A〜100C上で稼働する仮想化されたアプリケーション実行環境(200、210)の管理を行う管理マネージャによる各種処理を行うためのプログラムを実行する。管理マネージャによる処理の詳細については後述する。

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

図5において、各ホストコンピュータ100A〜100Cに含まれるホスト310A、310B、310Cは、それぞれ図3におけるハードウェア100H及びハイパーバイザ201を含む機能ブロックを模式的に表したものである。また、VMゲスト320A〜320Gは、それぞれホスト310A、310B、310C上で起動してユーザに提供される仮想マシンの実行環境である。図5において、VMゲスト320A、320B、320C、320Eでは、コンテナ330が稼働し、コンテナ上でユーザの業務に関するアプリケーションプログラムが実行されているものとする。以下、ホスト310A〜310Cは、それらを区別不要の場合、ホスト310と記述する。また、VMゲスト320A〜320Gは、それらを区別不要の場合、VMゲスト320と記述する。

各VMゲスト320またはコンテナ330上で実行されるユーザのアプリケーションプログラムと、そのアプリケーションプログラムが使用するデータは、ストレージ装置110に格納される。ストレージ装置110に格納されたアプリケーションプログラム又はデータは、各ホスト310に含まれるCPU101によって読み出されて、アプリケーションの実行時に使用される。

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

図6において、VMゲスト320A上で稼働する2つのコンテナ330では、アプリケーション「Web A」、「DB A」が実行されているものとする。同様に、VMゲスト320B上のコンテナ330では、アプリケーション「App B1」、「App B2」が実行され、VMゲスト320C上のコンテナ330では、アプリケーション「Web C」、「App C」が実行されているものとする。また、VMゲスト320E上のコンテナ330では、アプリケーション「Web E」、「App E」が実行されているものとする。なお、例えば、「Web」はWebサーバ・プログラムを示し、「DB」はDatabase(DB)サーバ・プログラムを示す。

各VMゲスト320上で稼働するコンテナOS211上では、各VMゲスト320に関する情報を収集するプログラムであるエージェント340A〜340G(図6では「a」と表示)が実行される。以下、エージェント340A〜340Gは、それらを区別不要の場合、エージェント340と記述する。エージェント340は、例えば、コンテナOS211上で実行されるデーモンプログラムとして実装され、各VMゲスト320上で実行されるアプリケーションプログラムとは独立して実行される。

図7は、図6の運用例における各VMゲスト320のコンテナ330で実行されるエージェント340の処理を説明する図である。図7において、アプリケーション「Web A」、「App B1」、「Web C」、「Web E」が実行されているコンテナから下方向に出ている矢印は、各アプリケーションがコンテナ330によって提供される通信機能によってVMゲスト320外部と通信することを示す。また、アプリケーション「Web A」と「DB A」間の双方向矢印は、これらのアプリケーション間での通信、言い換えれば、これらのアプリケーションが実行されるコンテナ間での通信が行われることを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一方、VMゲスト320B上で稼働する各コンテナ上で実行される「App B1」、「App B2」はそれぞれコンテナ間通信ができる設定がされておらず、外部通信のみ行っている。そのため、「App B1」、「App B2」を実行するコンテナについては、図8の表を参照して、結合優先度は「中」とする。

VMゲスト320C上で実行されている「Web C」と「App C」を実行する2つのコンテナは、コンテナ間通信ができる設定がされておらず、かつ一方のコンテナのみが外部通信を行っている。そのため、これら2つのコンテナ間の結合優先度はいずれも「低」とする。VMゲスト320E上で実行されている2つのコンテナについても同様の通信状況であるため、それぞれのコンテナの結合優先度は「低」とする。

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

図10は、コンテナの優先順位付けを行う全体フローチャートである。ホストコンピュータ100上で稼働するVMゲスト320やコンテナ330の数が変更された場合や、一定期間ごとに、各コンテナの結合優先度の判定を行う。コンテナの結合優先度の判定を行う際、図10に示すように、コンテナの分類を行う処理(S102)を、VMの数(M、Mは自然数)の分だけ行う。コンテナの分類を行う処理(S102)の詳細については、図11、図12を用いて説明する。

図11、図12は、コンテナの優先順位付けを行うフローチャートである。まず、図10のS101で選択されたVM上で稼働するコンテナのうち、接続状態が「外+内」のコンテナの情報を取得する(S111)。取得したコンテナの数(K、Kは自然数)が0であればS117に進み、取得したコンテナの数(K)が1以上であれば、S113〜S116の処理を行う。

S113〜S116では、変数k(kは自然数)が1からKになるまで、S113〜S116の処理を繰り返す。S113〜S116の処理では、取得した接続状態が「外+内」のコンテナの数(K)の分だけ、取得したコンテナと内部通信(コンテナ間通信)ができる設定がされているコンテナを取得する(S114)。そして、取得したコンテナと、内部通信(コンテナ間通信)先のコンテナのペアの結合優先度を「高」に設定する(S115)。

次に、接続状態の「外」のみのコンテナの情報を取得する(S117)。取得した接続状態が「外」のみのコンテナの数が0の場合(S118で「0」)、S121へ進む。接続状態が「外」のみのコンテナの数が1の場合(S118で「1」)、取得したコンテナの結合優先度を「低」に設定する(S120)。取得した接続状態が「外」のみのコンテナの数が2以上の場合(S118で「2以上」)、取得したコンテナのそれぞれの結合優先度を「中」に設定する(S119)。

次に、接続状態が「無」のコンテナの情報を取得する(S121)。取得した接続状態が「無」のコンテナの数が1以上である場合(S122で「1以上」)、取得した接続状態が「無」のコンテナの結合優先度を「低」に設定する(S123)。一方、取得した接続状態が「無」のコンテナの数が0である場合、S124に進む。

S124では、接続状態が「内」のみで、結合優先度が設定されていないコンテナの情報を取得する。S124で取得したコンテナの数が1以上である場合(S125で「1以上」)、S124で取得したコンテナの結合優先度を「中」に設定する(S126)。S124で取得したコンテナの数が0である場合(S125で「0」)、処理を終了する。

図13は、図7の運用例において管理マネージャが各ホストコンピュータ100から取得する、ハードウェアリソースの使用状況に関する情報の例を示す図である。図13の例では、各ホストコンピュータ100のCPUリソースとして、ホスト1は9.0GHz、ホスト2は7.5GHz、ホスト3は11.5GHzであるものとする。ここで、CPUリソースの単位としている「GHz」は、各ホストにおいてCPU101を用いて処理を行うことができるプログラムの単位時間当たりの処理ステップ数をいうものとする。また、図13中のCPU使用量の単位として記載している「GHz」は、各CPU上で実行されているアプリケーションプログラムが単位時間あたりに使用するCPU101の処理ステップ数をいうものとする。

図13から、ホスト1の各コンテナ上で実行されている各アプリケーションプログラムのCPU使用量の合計は7.0GHzであり、ホスト1のCPU空きリソースは2.0GHzである。ホスト2のVM又はコンテナ上で実行されている各アプリケーションプログラムのCPU使用量の合計は4.0GHzであり、ホスト2のCPU空きリソースは3.5GHzである。また、ホスト3のVM上で実行されている各アプリケーションプログラムのCPU使用量の合計は8.0GHzであり、ホスト3のCPU空きリソースは3.5GHzである。図13において、「VM D」、「VM F」、「VM G」の各VM上では、アプリケーションプログラムの名称は記載されていないものの、何らかのアプリケーションプログラムが実行されているものとする。

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

例えば、図14(A)において、ライブマイグレーションで「VM B」をホスト3に移動させ、「VM C」をホスト2に移動させる。そうすると、図14(B)に示されるように、ホスト2のCPU空きリソースが0.5GHz、ホスト3のCPU空きリソースが1.3GHzとなる。この場合、ホスト1に残った「VM A」の移動先となるホストコンピュータのCPU空きリソースが「VM A」のCPU使用量の1.8GHzを満たさず、ライブマイグレーションを行うことができない。

従って、図14で示されるような場合には、ホスト1上の各VMをライブマイグレーションによって他のホスト(ホスト2又はホスト3)に移動できないので、図15に示すようにVM上で稼働するコンテナを分割してマイグレーションできないかを判定する必要がある。

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

まず、図15(A)で、ホスト1の各VM上で稼働しているコンテナのうち、図9に示される結合優先度の低い「VM C」上で稼働する2つのコンテナを、ホスト2とホスト3に分割することを考える。例えば、「VM C」上で稼働するコンテナのうち、「Web C」を実行するコンテナを、ホスト3に新たに作成した「VM H」に移動させ、「App C」のみを実行することになった「VM C」をライブマイグレーションでホスト2に移動させる。すると、図15(B)に示されるように、ホスト2のCPU空きリソースの残りは1.7GHzとなり、ホスト3のCPU空きリソースの残りは2.3GHzとなる。

図15(B)において、さらに結合優先度が「中」で分割可能な「VM B」上で稼働する2つのコンテナを分割することを考える。例えば、「VM B」で稼働するコンテナのうち、「App B1」をホスト3に新たに作成した「VM I」に移動させ、「App B2」のみを実行することになった「VM B」をライブマイグレーションでホスト2に移動させる。すると、図15(C)に示されるように、ホスト2のCPU空きリソースの残りは0GHzとなり、ホスト3のCPU空きリソースの残りは1.8GHzとなる。

ここで、「VM A」上で稼働する2つのコンテナは、互いにコンテナ間通信ができる設定がされており、結合優先度が「高」となっているため、コンテナを分割して移動できない。しかし、図15(A)、(B)のように「VM B」、「VM C」のコンテナを分割して移動させることでCPU使用量が1.8GHzの「VM A」をライブマイグレーションによりホスト3に移動できることになる。

図15の(A)〜(C)に示すシミュレーションによって、ホスト1上で稼働するVM又はコンテナを他のホストコンピュータにマイグレーションできることが分かる。図15のシミュレーションにおいてコンテナを分割して移動させるための新たなVMである「VM H」と「VM I」を作成したので、移動元のホスト1についての、移動時に必要となるVM数は2となる。

図15のようなシミュレーションをホスト2、ホスト3に対しても同様に行う。すなわちホストコンピュータ100Bや100Cの保守作業等を行うと仮定した場合に、ホスト2やホスト3上で実行されているVM又はコンテナを他のホストコンピュータに移動できるかどうかをシミュレーションする。ホスト2についてのシミュレーションでは、ライブマイグレーションによって「VM D」をホスト3に移動させ、「VM E」をホスト1に移動させることができる。従って、コンテナを分割して移動させる必要はなく、移動時に必要となるVM数は0となる。

また、ホスト3についてのシミュレーションについては、CPU使用量が3.5GHzの「VM G」を、ライブマイグレーションによって空きリソースが3.5GHzあるホスト2に移動させることができる。しかし、残った「VM F」のCPU使用量の4.5GHz分のCPU空きリソースがホスト1に残っていないことからホスト3の全てのVMをマイグレーションすることはできない。この場合、ホスト3についてはマイグレーションできる空きリソースがないことを、情報処理システム10の運用管理者に通知し、運用管理者によってホストコンピュータの追加や、既存のホストコンピュータにおけるハードウェアリソースの追加が行われる。

図16は、図13の運用例における仮想マシン又はコンテナのマイグレーションのシミュレーション結果のリスト400を示す図である。図15のようなシミュレーションを各ホストに対して行った結果、ホスト上で稼働しているVMまたはコンテナの全てをマイグレーション可能な場合、対応するホストの移動可能フラグを“true”とする。例えば、ホスト3のように全てのVM(「VM F」及び「VM G」)を他のホストにマイグレーションできない場合、移動可能フラグを“false”とする。図15のシミュレーションでは、ホスト1のシミュレーションに関して、ホスト3に新規に「VM H」、「VM I」を作成する必要があることから、図16のリスト400においてホスト1の「VM新規作成数」を2とし、「VM新規作成先ホスト」を「ホスト3」とする。

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

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

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

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

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

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

図18、図19は、実施例に係るマイグレーションの可否判定処理の全体フローを示すフローチャートである。まず、情報処理システム10に含まれるホストコンピュータ100(以下、単に「ホスト」と記載する)について、各ホスト上で稼働しているVM又はコンテナのマイグレーションを行うことが可能かどうかを判定する(S201〜S214)。

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

図18の処理では、ホストの数をN(Nは自然数)とし、変数n(nは自然数)が1からNになるまで、S201〜S214の処理を繰り返す。まず、マイグレーションの可否判定対象となる最初のホスト(n=1)を特定し(S201)、特定したホスト以外のマイグレーションの移動先となるホストの全体のリソースの空き容量を計算する(S202)。移動先となるホストの全体のリソースの空き容量が足りない場合には(S203でNO)、移動可能フラグを“false”にするとともに、必要なVM数、すなわち、コンテナ等の移動に必要となる新規に作成すべきVM数を0とする(S205)。そして、S214に進む。

移動先となるホストの全体のリソースの空き容量が足りる場合(S203でYES)、コンテナを稼働していないVMについて移動可能であるかどうかをS204のサブルーチンで判定する。S204のサブルーチンの処理の詳細について、図20を用いて説明する。

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

まず対象ホスト上で稼働しているVMのうち、コンテナが稼働されていないVMを抽出する(S221)。S221で抽出したコンテナが稼働されていないVMをリソース使用量の多い順にソートする(S222)。次に、移動先の候補となるホストを、リソースの空き容量の多い順にソートする(S223)。

S221で抽出したコンテナが稼働されていないVMの数をM(Mは自然数、以下同じ)として、変数m(mは自然数、以下同じ)が1からMになるまで、S222でソートした順にS221で抽出したVMを選択し、S224〜S232の処理を行う。S224で選択されたVMの移動可否を判定する前に、判定対象ホスト(S201で選択されたホスト)の移動可能フラグを“false”にする(S225)。そして、VMの移動先の候補となるホストの数をH(Hは自然数、以下同じ)として、変数h(hは自然数、以下同じ)が1からHになるまで、S223でソートした順に移動先候補のホストを選択し、S226〜S230の処理を行う。

S224で選択されたVMについて、S226で選択された移動先ホストの候補にVM単位で移動できる場合(S227でYES)、選択した移動先ホストのリソース空き容量からS224で選択されたVMのリソース使用量を引く(S228)。次に、判定対象ホストの移動可能フラグを“true”にし(S229)、S226〜S230のループを抜ける。

S224で選択されたVMについて、S226で選択された移動先ホストの候補にVM単位で移動できない場合(S227でNO)、移動先ホストの候補を変更して(S230)、再度、S224で選択されたVMをVM単位で移動できるかどうかを判定する(S227)。いずれかの移動先ホストの候補にVMを移動できる場合には、S228、S229の処理を経て移動可能フラグが“true”の状態でS226〜S230のループを抜ける。一方、いずれの移動先ホストの候補にもVMを移動できない場合には、移動可能フラグが“false”の状態でS226〜S230のループを抜ける。

S226〜S230のループを抜けた後、移動可能フラグの状態を判定する(S231)。S224で選択されたVMについての移動可否判定の結果、移動可能フラグが“true”であれば(S231で“true”)、mの値を更新し(S232)、次のVMについてS225〜S231の処理を繰り返す。コンテナが稼働されていないVMのうち、1つでも移動先ホストの候補に移動できないVMがあれば、他のVMについてVMの移動可否を判定する意味がないので、S231の判定で“false”の場合には、S224〜S232のループを抜ける。

そして、再度移動可能フラグを判定し(S233)、S233の判定において移動可能フラグが“true”であれば、S204のサブルーチンの戻り値として、コンテナが稼働されていないVMの移動が可能と返す(S235)。一方、S233の判定において移動可能フラグが“false”であれば、S204のサブルーチンの戻り値として、コンテナが稼働されていないVMの移動が不可と返す(S234)。なお、図18のフローチャートの処理において、S234とS235によって返すサブルーチンS204の戻り値を使わない場合には、S233〜S235を省略しても良い。

ここで、図18のS206に戻って説明する。S204のコンテナが稼働されていないVMのマイグレーションの可否判定を行った後の移動先候補のリソースの空き容量の値で、図18の判定処理における移動先候補となるホストのリソース空き容量の値を更新する(S206)。なお、S204のサブルーチンのS229で更新する移動先ホストのリソース空き容量の変数と、図18のS202、S203、S206で扱う移動先ホストのリソース空き容量の変数とが同じ場合、S206の処理を省略しても良い。

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

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

判定対象のホストにおいて、コンテナを稼働させているVMの数をMとして、変数mが1からMになるまで、S241でソートした順に、コンテナを稼働させているVMを選択し、S243〜S251の処理を行う。S243で選択されたVMの移動可否を判定する前に、判定対象ホストの移動可能フラグを“false”に設定する(S244)。そして、VMの移動先の候補となるホストの数をHとして、変数hが1からHになるまで、S242でソートした順に移動先候補のホストを選択し、S245〜S249の処理を行う。

S243で選択されたVMについて、S245で選択された移動先ホストの候補にVM単位で移動できる場合(S246でYES)、選択した移動先ホストのリソース空き容量からS243で選択されたVMのリソース使用量を引く(S247)。次に、判定対象ホストの移動可能フラグを“true”にし(S248)、S245〜S249のループを抜ける。

S243で選択されたVMについて、S245で選択された移動先ホストの候補にVM単位で移動できない場合(S246でNO)、移動先ホストの候補を変更して(S249)、再度S243で選択されたVMをVM単位で移動できるかどうかを判定する(S246)。いずれかの移動先ホストの候補にVMを移動できる場合には、S247、S248の処理を経て移動可能フラグが“true”の状態でS245〜S249のループを抜ける。一方、いずれの移動先ホストの候補にもVMを移動できない場合には、移動可能フラグが“false”の状態でS245〜S249のループを抜ける。

S245〜S249のループを抜けた後、移動可能フラグの状態を判定する(S250)。S243で選択されたVMの移動可否判定の結果、移動可能フラグが“true”であれば(S250で“true”)、mの値を更新し(S251)、次のVMについてS244〜S250の処理を繰り返す。コンテナが稼働されているVMのうち、1つでも移動先ホストの候補に移動できないVMがあれば、他のVMについてVMの移動可否を判定する意味がないので、S250の判定で“false”の場合には、S243〜S251のループを抜ける。

S243〜S251のループを抜けた後、再度移動可能フラグを判定し(S252)、S252の判定において移動可能フラグが“true”であれば、S207のサブルーチンの戻り値として、コンテナが稼働されているVMについてVM単位での移動が可能と返す(S254)。一方、S252の判定において移動可能フラグが“false”であれば、S207のサブルーチンの戻り値として、コンテナが稼働されているVMのVM単位での移動が不可と返す(S253)。なお、図18のフローチャートの処理において、S253、S254によって返すサブルーチンS207の戻り値を使わない場合には、S252〜S254を省略してもよい。

ここで、図18のS208に戻って説明する。S207のサブルーチンによって、コンテナを稼働させているVMの全てについて、VM単位で移動可能である場合(S208でYES)、移動可能フラグを“true”にする。そして、必要なVM数、すなわち、コンテナの移動に必要となる新規に作成すべきVM数を0とし(S210)、S214に進む。一方、コンテナを稼働させているVMの全てについて、VM単位で移動できない場合(S208でNO)、S209のサブルーチンにおいてコンテナ単位で移動可能かどうかを判定する。S209のサブルーチンの処理の詳細については、図22を用いて説明する。

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

S261で優先度の高い順にソートしたコンテナを参照して、優先度の高いコンテナを含む親VMを抽出する。ここで、「親VM」とは、着目するコンテナを稼働させているVMをいうものとする。抽出した親VMの数をP(Pは自然数)とすると、変数p(pは自然数)が1からPになるまで、親VMを1つずつ選択してS263〜S274の処理を行う。S263で選択されたVMに含まれる優先度が高いコンテナの移動可否を判定する前に、判定対象ホストの移動可能フラグを“false”に設定する(S264)。

そして、VMの移動先の候補となるホストの数をHとして、変数hが1からHになるまで、S262でソートした順に移動先候補のホストを選択し、S265〜S272の処理を行う。

S263で選択された親VMに含まれる優先度が「高」の全てのコンテナと、優先度が「中」の全てのコンテナとを一緒にS265で選択された移動先ホストの候補に移動できる場合(S266でYES)、これらの優先度が「高」、「中」のコンテナを移動するコンテナに設定する(S267)。一方、S266の判定において、優先度が「高」、「中」のコンテナをS265で選択された移動先ホストの候補に移動できない場合(S266でNO)、S268に進む。

S268では、優先度が「高」の全てのコンテナについて、S265で選択された移動先ホストの候補に一緒に移動可能かどうかを判定する。優先度が「高」の全てのコンテナについて移動先ホストの候補に一緒に移動可能な場合(S268でYES)、優先度が「高」のコンテナを移動するコンテナに設定する(S269)。一方、優先度が「高」の全てのコンテナについて移動先ホストの候補に一緒に移動できない場合(S268でNO)、コネクタCを介してS272に進み、変数hを更新して、再度、次の移動先ホストをS265で選択して、S265〜S272の処理を行う。

S267又はS269において移動するコンテナが設定された場合、S265で選択された移動先ホストのリソースの空き容量から、移動するコンテナのリソース使用量を引く(S270)。次に、判定対象ホストの移動可能フラグを“true”にし(S271)、コネクタDを介してS265〜S272のループを抜ける。

S263で選択された親VMに含まれる優先度「高」の全てのコンテナが、S265で選択されたいずれの移動先のホストへも一緒に移動できない場合には、移動可能フラグが“false”の状態でS265〜S272のループを抜ける。

S265〜S272のループを抜けた後、移動可能フラグの状態を判定する(S273)。S273において、移動可能フラグが“true”であれば、pの値を更新し(S274)、次の親VMについてS264〜S273の処理を繰り返す。移動可能フラグが“false”であれば、他の親VMについてS264〜S273の判定をする意味がないので、S263〜S274のループを抜ける。

S263〜S274のループを抜けた後、再度、移動可能フラグを判定する(S275)。S275の判定において、移動可能フラグが“false”の場合、移動に必要なVM数、すなわち、コンテナの移動に必要となる新規に作成すべきVM数を0とする(S276)。そして、S209のサブルーチンの戻り値として、移動可能フラグと新規に作成すべきVM数(この場合0)を返す(S278)。

S275の判定において、移動可能フラグが“true”である場合、S277のサブルーチンにおいて、S267又はS269で移動するコンテナとして設定されていない残りのコンテナの移動可否を判定する。S277のサブルーチンの処理の詳細については、図24を用いて説明する。

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

S281でソートしたコンテナの数をK(Kは自然数)、変数k(kは自然数)が1からKになるまで、S281でソートした順に残りのコンテナを選択し、S283〜S292の処理を行う。S283で選択されたコンテナの移動可否を判定する前に、移動可能フラグを“false”に設定する(S284)。そして、コンテナの移動先の候補となるホストの数をHとして、変数hが1からHになるまで、S282でソートした順に移動先候補のホストを選択し、S285〜S290の処理を行う。

S283で選択されたコンテナには優先度「高」のコンテナが含まれていないため、選択されたコンテナ単体でいずれかの移動先ホストの候補に移動できるかどうかを判定する(S286)。選択されたコンテナが移動先ホストの候補に移動できる場合(S286でYES)、選択した移動先ホストのリソース空き容量からS283で選択されたコンテナのリソース使用量を引く(S287)。

次にS283で選択されたコンテナの情報と、移動先ホストの情報とを、メモリ133又はストレージ110内の不図示のテーブルに格納する(S288)。S288でテーブルに格納したコンテナの移動先の情報は、後述するS295の移動に必要なVM数の計算に用いられる。また、S288でテーブルに格納したコンテナの移動先の情報を、将来、仮にマイグレーションをする必要が生じた際に参照するようにしてもよい。そして、移動可能フラグを“true”に設定して(S289)、S285〜S290のループを抜ける。

S283で選択されたコンテナについて、S285で選択された移動先ホストの候補に移動できない場合(S286でNO)、変数hを更新して移動先ホストの候補を変更する(S290)。そして、再度S283で選択したコンテナを変更した移動先ホストの候補に移動できるかどうかを判定する(S286)。

いずれかの移動先ホストにコンテナを移動できる場合には、S287〜S289の処理を経て移動可能フラグが“true”の状態でS285〜S290のループを抜ける。一方、いずれの移動先ホストの候補にもコンテナを移動できない場合には、移動可能フラグが“false”の状態でS285〜S290のループを抜ける。

S285〜S290のループを抜けた後、移動可能フラグの状態を判定する(S291)。S283で選択したコンテナの移動可否の判定の結果、移動可能フラグが“true”であれば(S291で“true”)、kの値を更新し(S292)、次のコンテナについてS284〜S292の処理を繰り返す。残っているコンテナのうち、1つでも移動先ホストの候補に移動できないコンテナがあれば、他のコンテナについて移動可否を判定する意味がないので、S291の判定結果が“false”であれば、S283〜S292のループを抜ける。

S283〜S292のループを抜けた後、再度移動可能フラグを判定し(S293)、S293の判定において移動可能フラグが“true”であれば、S288で格納したテーブルの情報を参照して、移動に必要なVM数、すなわち、コンテナの移動に必要となる新規に作成すべきVM数を計算する(S295)。一方、S293の判定において移動可能フラグが“false”であれば、移動に必要なVM数を0にする(S294)。そして、S277のサブルーチンの戻り値として、S295で計算した移動に必要なVM数と移動可能フラグを返す(S296)。

S277のサブルーチンを抜けると、図23のS278に進み、S277の戻り値を、S209のサブルーチンの戻り値として返す(S278)。S209のサブルーチンを抜けると、図18のS211の処理に移る。

図18に戻って、図18のフローチャートのS211の続きを説明する。S209のサブルーチンによって、全てのコンテナについて、コンテナ単位であれば移動可能であると判定された場合(S211でYES)、移動可能フラグを“true”にする(S213)。また、この場合、分割したコンテナを移動させる際に必要となる新たに作成すべきVMの数を、図16に示すリスト400に追加する(S213)。一方、S209の判定においてコンテナ単位で全てのコンテナを移動できないと判定した場合には(S211でNO)、移動可能フラグを“false”にする(S212)。そして、必要なVM数、すなわち、コンテナの移動に必要となる新規に作成すべきVM数を0とする(S212)。

そして、S214でnの値を更新し、次のホストについて、ホスト上で稼働しているVM又はコンテナのマイグレーションを行うことができるか否かを判定する。S201〜S214で全てのホストについてのマイグレーションの可否判定が終了すると、コネクタBを介して図19のS215に移る。

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

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

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

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

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

10 :情報処理システム 20 :ネットワーク 30 :クライアント装置 100:ホストコンピュータ 101:CPU 102:入出力装置インタフェース回路 103:メモリ 104:ネットワークインタフェース回路 105:ストレージインタフェース回路 106:ローカルバスインタフェース回路 110:ストレージ装置 120:ネットワークスイッチ 130:管理サーバ 131:CPU 132:入出力装置インタフェース回路 133:メモリ 134:ネットワークインタフェース回路 135:ストレージインタフェース回路 136:ローカルバスインタフェース回路 140:ローカルバス 200:ハイパーバイザ型仮想化環境 201:ハイパーバイザ 202:仮想マシン 210:コンテナ型仮想化環境 211:コンテナOS 212:コンテナ 300:管理マネージャ 310:ホスト 320:VMゲスト 330:コンテナ 340:エージェント 400:シミュレーション結果のリスト