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

Abstract

【課題】メンテナンス作業にかかる時間を短縮することを課題とする。【解決手段】管理装置は、複数の情報処理装置によって構成されるクラスタのリソース情報と、クラスタ内で稼働する各仮想マシンのリソース情報の合計値とを取得する。管理装置は、クラスタのリソース情報が各仮想マシンのリソース情報の合計値よりも多くなるように、複数の情報処理装置の中から、クラスタの冗長ポリシーに基づき設定される設定台数の情報処理装置を選択してクラスタから切り離す。管理装置は、クラスタから切り離された情報処理装置上で稼働する仮想マシンを、クラスタ内の他の情報処理装置に移動させ、クラスタから切り離された情報処理装置に対してメンテナンス作業を実行する。【選択図】図２

Description

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

複数台のサーバを１つのシステムとみせるクラスタリング技術が普及している。クラスタリング技術を用いたシステムは、リソースの活用や冗長化等を行うために、数十台から数百台以上の規模のデータセンター事業者から、数台規模の中小企業まで、幅広く導入されている。

近年では、クラスタリング技術を用いたサーバ群のシステムに対して、システムを構成する個々のサーバのBIOS（Basic Input／Output System）／BMC（Baseboard Management Controller）等のファームウェアのアップデートなどを行うメンテナンス技術として、システムの全サーバの完全停止をしないローリングアップデートが知られている。

特開平１１−３５３１９６号公報 特開２０１１−８１５８８号公報

しかしながら、上記技術では、ローリングアップデートによってシステムを起動しながらメンテナンスを行う際でも、クラスタを構成しているサーバ１台ずつの起動と停止を繰り返すことになるので、数十台を超えるサーバ群のシステムでは、メンテナンスが完了するまでに時間がかかり過ぎる。また、サーバ１台を保守するためには、メンテナンス対象のサーバ上で起動しているサービスや仮想マシン等をクラスタ上の別のサーバへ移動する煩雑な作業が発生するので、メンテナンス時間がさらに長くなる。

一つの側面では、メンテナンス作業にかかる時間を短縮することができる管理装置、管理プログラムおよび情報処理システムを提供することを目的とする。

第１の案では、管理装置は、複数の情報処理装置によって構成されるクラスタのリソース情報と、前記クラスタ内で稼働する各仮想マシンのリソース情報の合計値とを取得する取得部を有する。管理装置は、前記クラスタのリソース情報が前記各仮想マシンのリソース情報の合計値よりも多くなるように、前記複数の情報処理装置の中から、前記クラスタの冗長ポリシーに基づき設定される設定台数の情報処理装置を選択して前記クラスタから切り離すクラスタ制御部を有する。管理装置は、前記クラスタから切り離された情報処理装置上で稼働する仮想マシンを、前記クラスタ内の他の情報処理装置に移動させ、前記クラスタから切り離された情報処理装置に対してメンテナンス作業を実行する実行部を有する。

一実施形態によれば、メンテナンス作業にかかる時間を短縮することができる。

図１は、実施例１にかかるクラスタシステムの全体構成例を示す図である。 図２は、実施例１にかかる管理装置の機能構成を示す機能ブロック図である。 図３は、固定ＶＭリストＤＢに記憶される情報の例を示す図である。 図４は、ＶＭ位置情報ＤＢに記憶される情報の例を示す図である。 図５は、サーバリストＤＢに記憶される情報の例を示す図である。 図６は、サーバリソース情報ＤＢに記憶される情報の例を示す図である。 図７は、ＶＭリソース情報ＤＢに記憶される情報の例を示す図である。 図８は、具体例におけるメンテナンス開始時の初期状態を説明する図である。 図９は、具体例における１回目のメンテナンス処理を説明する図である。 図１０は、具体例における１回目のメンテナンス完了時を説明する図である。 図１１は、具体例における２回目のメンテナンス処理を説明する図である。 図１２は、具体例における２回目のメンテナンス完了時を説明する図である。 図１３は、具体例における３回目のメンテナンス処理を説明する図である。 図１４は、具体例における３回目のメンテナンス完了時を説明する図である。 図１５は、事前処理の流れを示すシーケンス図である。 図１６は、メンテナンス処理の流れを示すシーケンス図である。 図１７は、メンテナンス処理におけるリソース不足を説明する図である。 図１８は、メンテナンス処理におけるリソース不足時の処理を説明する図である。 図１９は、ハードウェア構成例を説明する図である。

以下に、本願の開示する管理装置、管理プログラムおよび情報処理システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１にかかるクラスタシステムの全体構成例を示す図である。図１に示すように、クラスタシステムは、保守端末２０、クラスタ３０、管理装置５０を有し、各装置がインターネットなどのネットワークを介して相互に通信可能に接続されるシステムである。

保守端末２０は、クラスタシステムを管理およびメンテナンスを行う保守者が利用するコンピュータ装置であり、例えばサーバ、パーソナルコンピュータ、スマートフォンなどである。保守端末２０は、ディスプレイなどの表示部に各種情報を表示する。また、保守端末２０は、保守者から各種指示の入力を受け付けて管理装置５０に出力する。

クラスタ３０は、サーバ１からサーバＮ（Ｎは自然数）の複数のサーバをホストサーバとしてクラスタリング技術で統合し、システム全体として処理性能を向上させたクラスタサービスを提供する。クラスタ３０を構成する各サーバ上では、各サーバの物理リソースを利用して複数のＶＭ（Virtual Machine：仮想マシン）が稼働している。

管理装置５０は、保守端末２０からの指示に応じて、クラスタ３０のメンテナンスを実行するコンピュータ装置であり、例えばサーバ、パーソナルコンピュータ、スマートフォンなどである。

このようなシステムにおいてクラスタ３０の各サーバのメンテナンスを実行する場合、管理装置５０は、複数のサーバによって構成されるクラスタ３０のリソース情報と、クラスタ３０内で稼働する各ＶＭのリソース情報の合計値とを取得する。続いて、管理装置５０は、クラスタ３０のリソース情報が各ＶＭのリソース情報の合計値よりも多くなるように、複数のサーバの中から、クラスタ３０の冗長ポリシーによって設定される台数のサーバを、クラスタ３０から切り離す。そして、管理装置５０は、クラスタ３０から切り離されたサーバ上で稼働するＶＭを、クラスタ３０内の他のサーバに移動させ、クラスタ３０から切り離されたサーバに対してメンテナンス作業を実行する。

例えば、管理装置５０は、冗長ポリシーで制限される２台のサーバが停止しても、全ＶＭをクラスタ３０内で稼働可能か否かを判定する。そして、管理装置５０は、稼働可能と判定した場合、サーバ１上で稼働するＶＭとサーバ２で稼働するＶＭとを、リソースに余裕があるサーバ５などの移動させた後、サーバ１とサーバ２のシャットダウンを行う。その後、管理装置５０は、サーバ１とサーバ２のソフトウェアのバージョンアップなどを実行し、完了した場合に、サーバ１とサーバ２を起動する。そして、管理装置５０は、メンテナンス未完了の他のサーバについても同様に実行する。

このようにして、管理装置５０は、起動停止含むメンテナンス対象のサーバを自動で複数選択してメンテナンスを実施し、自動で再起動を含めたメンテナンスを実施することで、作業期間および作業工数を短縮し、メンテナンス作業にかかる時間を短縮する。

［機能構成］
図２は、実施例１にかかる管理装置５０の機能構成を示す機能ブロック図である。図２に示すように、管理装置５０は、通信部５１、記憶部５２、制御部６０を有する。

通信部５１は、クラスタシステムの他の装置の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部５１は、メンテナンス開始の指示を保守端末２０から受信する。通信部５１は、クラスタ３０内の各サーバに起動停止などの指示を送信し、クラスタ３０内の各ＶＭに移動（マイグレーション）などの指示を送信する。また、通信部５１は、各サーバや各ＶＭから処理完了の通知などを受信する。

記憶部５２は、データやプログラムなどを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。記憶部５２は、固定ＶＭリストＤＢ５３、ＶＭ位置情報ＤＢ５４、冗長ポリシーＤＢ５５、サーバリストＤＢ５６、サーバリソース情報ＤＢ５７、ＶＭリソース情報ＤＢ５８を記憶する。

固定ＶＭリストＤＢ５３は、使用ライセンス上他のサーバへ移動することが許可されていないなどの理由により、別のサーバへ移動することができない固定されたＶＭ（以下では、固定ＶＭと記載する場合がある）に関する情報を記憶するデータベースである。ここで記憶される情報は、保守者により設定登録することもでき、後述するように管理装置５０が自動で生成することもできる。

図３は、固定ＶＭリストＤＢ５３に記憶される情報の例を示す図である。図３に示すように、固定ＶＭリストＤＢ５３は、「固定ＶＭ、サーバ」を対応付けて記憶する。ここで記憶される「固定ＶＭ」は、移動できないＶＭを識別する識別子であり、「サーバ」は、固定ＶＭが稼働するサーバを識別する識別子である。図３の例では、サーバ１上で固定ＶＭである管理ＶＭ＃１が稼働し、サーバ２上で固定ＶＭである管理ＶＭ＃２が稼働していることを示す。なお、ＶＭが稼働することの具体的な一例は、サーバの物理リソースであるプロセッサやメモリなどの一部が割当てられた仮想プロセッサや仮想メモリなどを利用して、ＶＭが各種サービスを提供することなどを示す。

ＶＭ位置情報ＤＢ５４は、クラスタ３０内で稼働するＶＭの初期位置情報を記憶するデータベースである。具体的には、ＶＭ位置情報ＤＢ５４は、クラスタ３０が構成されて各ＶＭが実行された初期状態のＶＭの位置情報を記憶する。ここで記憶される情報は、保守者により設定登録することもでき、管理装置５０がクラスタ３０内の各サーバのメモリ等を参照して自動で生成することもできる。

図４は、ＶＭ位置情報ＤＢ５４に記憶される情報の例を示す図である。図４に示すように、ＶＭ位置情報ＤＢ５４は、ＶＭが稼働するサーバを識別する識別子が設定される「サーバ」と、サーバ上で稼働するＶＭを識別する識別子が設定される「ＶＭ」とを対応付けて記憶する。図４の例では、ＶＭ１とＶＭ２がサーバ１上で稼働し、ＶＭ３とＶＭ４とＶＭ５とがサーバ２上で稼働することを示す。なお、ＶＭ位置情報ＤＢ５４は、初期位置情報に限らず、ＶＭの移動（マイグレーション）に追従して、ＶＭの現在位置すなわちＶＭが現時点で稼働するサーバの識別子を記憶することもできる。

冗長ポリシーＤＢ５５は、クラスタの冗長ポリシー、言い換えると仮想ストレージの冗長ポリシーによって設定される、同時に再起動が可能なサーバの台数を記憶するデータベースである。例えば、冗長ポリシーＤＢ５５は、「台数」として「２」などを記憶する。この例の場合、クラスタ内のサーバのうち２台までは同時に再起動、すなわちメンテナンスが可能であることを示す。なお、ここで設定される情報は、クラスタ内の冗長性が担保される範囲で設定され、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成等により管理装置５０が自動で設定することもできる。例えば、クラスタ３０がＲＡＩＤ５で構成されている場合には、２台が設定され、クラスタ３０がＲＡＩＤ１で構成されている場合には、１台が設定される。

サーバリストＤＢ５６は、メンテナンス対象のサーバの一覧を記憶するデータベースである。ここで記憶される情報は、保守者により設定登録することもでき、管理装置５０がクラスタ３０内のクラスタリングを実現するアプリケーションなどに問い合わせることにより自動で生成することもできる。

図５は、サーバリストＤＢ５６に記憶される情報の例を示す図である。図５に示すように、サーバリストＤＢ５６は、サーバを識別する識別子が設定される「サーバ」として、「サーバ１、サーバ２、サーバ３、・・・」などを記憶する。ここで記憶される情報は、クラスタ３０を構成するサーバのうちサーバ１、サーバ２、サーバ３などがメンテナンス対象であることを示す。

サーバリソース情報ＤＢ５７は、クラスタ３０を構成する各サーバの物理リソースおよび使用リソースに関する情報を記憶するデータベースである。ここで記憶される情報は、保守者により設定登録することもでき、管理装置５０がクラスタ３０内の各サーバから自動で生成することもできる。

図６は、サーバリソース情報ＤＢ５７に記憶される情報の例を示す図である。図６に示すように、サーバリソース情報ＤＢ５７は、「サーバ、物理リソース（ＣＰＵ（Central Processing Unit）、メモリ）、使用率（ＣＰＵ、メモリ）」を対応付けて記憶する。ここで記憶される「サーバ」は、サーバを識別する識別子であり、「物理リソース」は、サーバが有する物理リソースを示し、「使用率」は、サーバが有する物理リソースのうち使用されているリソースの割合を示す。

図６の例では、サーバリソース情報ＤＢ５７は、「サーバ、物理リソース（ＣＰＵ、メモリ）、使用率（ＣＰＵ、メモリ）」の一例として、「サーバ＝サーバ１、物理リソース（ＣＰＵ＝４ＧＨｚ、メモリ＝８ＧＢ）、使用率（ＣＰＵ＝２／４、メモリ＝６／８）」を記憶する。これは、サーバ１が物理リソースとして、４ＧＨｚのＣＰＵと８ＧＢのメモリとを有し、４ＧＨｚのうち１ＧＨｚと８ＧＢのうち６ＧＢとが使用中であることを示す。

また、サーバリソース情報ＤＢ５７は、「サーバ、物理リソース（ＣＰＵ、メモリ）、使用率（ＣＰＵ、メモリ）」の一例として、「サーバ＝クラスタ、物理リソース（ＣＰＵ＝２０、メモリ＝４０）、使用率（ＣＰＵ＝８／２０、メモリ＝３２／４０）」を記憶する。これは、クラスタ３０のシステムリソースを示す情報である。具体的には、クラスタ３０は、物理リソースとして、合計２０ＧＨｚのＣＰＵと合計４０ＧＢのメモリとを有し、そのうち８ＧＨｚと３２ＧＢが使用中であることを示す。なお、システムリソースの物理リソースのＣＰＵの数は、各サーバのＣＰＵ数の合計であり、システムリソースの物理リソースのメモリの数は、各サーバのメモリ数の合計である。なお、メモリのことをＭＥＭと記載する場合がある。

ＶＭリソース情報ＤＢ５８は、クラスタ３０内で稼働する各ＶＭが使用するリソースに関する情報を記憶するデータベースである。ここで記憶される情報は、管理装置５０がクラスタ３０内の各サーバから自動で生成することもできる。図７は、ＶＭリソース情報ＤＢ５８に記憶される情報の例を示す図である。図７に示すように、ＶＭリソース情報ＤＢ５８は、「ＶＭ、リソース（ＣＰＵ、メモリ）」を対応付けて記憶する。

ここで記憶される「ＶＭ」は、ＶＭを識別する識別子である。「リソース（ＣＰＵ）」は、ＶＭが使用しているＣＰＵの情報であり、「リソース（メモリ）」は、ＶＭが使用しているメモリの情報である。図７の例では、ＶＭ１が、１ＧＨｚのＣＰＵ（プロセッサ）と４ＧＢのメモリを使用していることを示す。

制御部６０は、入出力部６１とメイン処理部６２とを有し、管理装置５０全体を司る処理部であり、例えばプロセッサなどである。なお、入出力部６１とメイン処理部６２は、例えばプロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。

入出力部６１は、保守端末２０から各種情報を受け付けて管理装置５０に設定する処理部である。具体的には、入出力部６１は、対象システム内の固定ＶＭの登録、メンテナンスの実行指示や後述する処理部によって特定されたメンテナンスを可能とする方法の提案などを出力する。

例えば、入出力部６１は、固定ＶＭに関する情報を受け付けて固定ＶＭリストＤＢ５３に登録し、クラスタ３０内の各ＶＭの初期位置情報を受け付けてＶＭ位置情報ＤＢ５４に登録する。また、入出力部６１は、同時再起動可能なサーバ台数を受け付けて冗長ポリシーＤＢ５５に登録し、クラスタ３０を構成するサーバに関する情報を受け付けてサーバリストＤＢ５６に登録する。また、入出力部６１は、ＶＭのシャットダウンの指示や各サーバのメンテナンス完了の通知を保守端末２０に送信する。

メイン処理部６２は、事前処理部６３とメンテナンス実行部６４を有し、サーバのメンテナンスに関する事前作業や各種作業などを実行する処理部である。

事前処理部６３は、保守端末２０からメンテナンス開始の指示を受け付けた場合に、メンテナンスを行うための事前処理を実行し、メンテナンスの実行可否を判定する処理部である。具体的には、事前処理部６３は、メンテナンスの開始に先立って、事前に固定ＶＭの確認、ストレージの冗長ポリシーの確認、クラスタ３０を構成している全サーバの物理リソースの確認、全ＶＭのリソースの確認を行い、メンテナンスが可能か算出する。そして、事前処理部６３は、システムのリソース使用状態からメンテナンスが可能かを判断し、実行可能な場合は、メンテナンス実行部６４に処理開始を出力し、メンテナンスできない要因がある場合は、入出力部６１を介してユーザに対処方法を提案する。

例えば、事前処理部６３は、固定ＶＭリストＤＢ５３を参照して固定ＶＭを特定し、クラスタ３０にアクセスして、固定ＶＭが稼働中か否かを判定する。そして、事前処理部６３は、固定ＶＭが稼働中である場合、入出力部６１を介して、固定ＶＭの停止（シャットダウン）を保守者に要求する。なお、事前処理部６３は、固定ＶＭを利用するユーザ等によって許可されている場合には、保守者を介することなく、固定ＶＭを停止することもできる。

また、事前処理部６３は、冗長ポリシーＤＢ５５を参照して、同時再起動可能な台数「２」を取得し、サーバリソース情報ＤＢ５７を参照して、全サーバの物理リソース（Ｂ）を取得し、ＶＭリソース情報ＤＢ５８を参照して、各ＶＭの使用リソース（Ｃ）を取得する。そして、事前処理部６３は、２台のサーバをシャットダウンさせたときのクラスタ３０内の物理リソース（Ｄ）を算出し、物理リソース（Ｄ）の範囲で各ＶＭの使用リソース（Ｃ）が確保できるか否かを判定する。

より詳細には、事前処理部６３は、サーバリソース情報ＤＢ５７からシステムリソースとして、ＣＰＵ使用率（８／２０）とメモリ使用率（３２／４０）を取得する。そして、事前処理部６３は、クラスタ３０内のサーバ１からサーバＮのうちいずれかのサーバ２台を停止したとしても、ＶＭに割り当てるための８個のＣＰＵと３２個目のメモリとが確保可能か否かを判定する。ここで、事前処理部６３は、取得したシステムリソースに固定ＶＭのリソースが含まれている場合は、固定ＶＭのリソースを除外したシステムリソースを算出して上記判定を行うことができる。

そして、事前処理部６３は、ＶＭのリソースが確保可能な場合は、メンテナンス実行部６４に処理開始を指示する。一方、事前処理部６３は、ＶＭのリソースの確保が不可能な場合は、メンテナンス不可能である旨とＶＭのシャットダウンを要求する旨を含むメッセージを保守端末２０に出力する。その後、保守者によるリソース確保のためのＶＭ停止が実行された後、事前処理部６３は、サーバリソース情報ＤＢ５７やＶＭリソース情報ＤＢ５８から、停止されたＶＭのリソースを削除して、使用リソース等を更新する。そして、事前処理部６３は、上記判定を再度実行する。

メンテナンス実行部６４は、メンテナンスに伴うＶＭの自動停止、ＶＭの移動、サーバの再起動などを実行する処理部である。具体的には、メンテナンス実行部６４は、サーバリソース情報ＤＢ５７を参照して、各サーバの使用率（使用リソース）を確認し、使用率が少ないサーバの順番を特定する。その後、メンテナンス実行部６４は、決定したサーバを同時メンテナンス可能な台数分並行してメンテナンスを実施し、メンテナンス実施後、対象のサーバをサーバリストＤＢ５６のサーバリストから削除する。メンテナンス実行部６４は、このような処理をサーバリストがゼロになるまで繰り返す。なお、メンテナンス実行部６４は、サーバリストＤＢ５６を参照して、リストに登録される各サーバへアクセスを行い、リソース使用率を確認することもできる。

例えば、メンテナンス実行部６４は、サーバリストにあるサーバ３とサーバ４をメンテナンス対象に決定すると、サーバ３やサーバ４にアクセスして、サーバ３上で稼働するＶＭ６とサーバ４上で稼働するＶＭ７を特定する。また、メンテナンス実行部６４は、サーバリソース情報ＤＢ５７を参照して、リソースに空きがあるサーバ１とサーバ５を特定する。そして、メンテナンス実行部６４は、サーバ３上のＶＭ６をサーバ５に移動させ、サーバ４上のＶＭ７をサーバ１に移動させる。移動完了後、メンテナンス実行部６４は、サーバ３とサーバ４をクラスタ３０から切り離す。

そして、メンテナンス実行部６４は、サーバ３とサーバ４に予め指定されたメンテナンスを実行したり、保守者によるメンテナンス作業の完了を待ったりする。なお、メンテナンス実行部６４は、必要に応じて、サーバ３とサーバ４をシャットダウンや再起動させることもできる。

その後、メンテナンス実行部６４は、メンテナンスが完了すると、サーバ３とサーバ４をクラスタ３０に接続してクラスタ３０を再構成する。そして、メンテナンス実行部６４は、サーバリストに登録されている他のサーバについても同様の手法で、メンテナンスを実行する。

なお、クラスタ３０からの切り離しや再構成は、一般的なクラスタリング技術を採用することができるので、詳細な説明は省略する。また、ＶＭの移動は、一般的なライブマイグレーション技術を採用することができる。例えば、メンテナンス実行部６４は、該当ＶＭが使用するメモリのプレコピーやストップアンドコピーなどを実行して、ＶＭのマイグレーションを実行する。

［具体例］
次に、図８から図１４を用いて、メンテナンスの自動実行の具体例を説明する。ここでは、固定ＶＭはすでに停止しており、各サーバの物理リソースの使用リソースは、固定ＶＭを除くリソースが管理されているものとする。また、メンテナンスが可能であると判定済みとする。

（初期状態）
図８は、具体例におけるメンテナンス開始時の初期状態を説明する図である。図８の（ａ）に示すように、サーバリストＤＢ５６が記憶するサーバリストには、メンテナンス対象として、サーバ１からサーバ５が登録されている。また、冗長ポリシーＤＢ５５には、「２」台が登録されている。また、ＶＭ位置情報ＤＢ５４には、ＶＭの初期の位置情報「サーバ、ＶＭ」として、「サーバ１、ＶＭ１，ＶＭ２」、「サーバ２、ＶＭ３，ＶＭ４，ＶＭ５」、「サーバ３、ＶＭ６」、「サーバ４、ＶＭ７」、「サーバ５、ＶＭ８」が登録されている。

クラスタ３０内のサーバ、ＶＭ、リソースの初期状態は、図８の（ｂ）に示される。具体的には、サーバ１は、物理リソースとして４ＧＨｚのプロセッサと８ＧＢのメモリとを有し、１ＧＨｚのＣＰＵと２ＧＢのメモリを使用するＶＭ１と、１ＧＨｚのＣＰＵと１ＧＢのメモリを使用するＶＭ２とを稼働させており、４ＧＨｚのプロセッサのうちの２ＧＨｚと８ＧＢのメモリのうちの３ＧＢが使用中である。

サーバ２は、物理リソースとして４ＧＨｚのプロセッサと８ＧＢのメモリとを有し、それぞれ１ＧＨｚのＣＰＵと１ＧＢのメモリを使用するＶＭ３とＶＭ４とＶＭ５とを稼働させており、４ＧＨｚのプロセッサのうちの３ＧＨｚと８ＧＢのメモリのうちの３ＧＢが使用中である。サーバ３は、物理リソースとして４ＧＨｚのプロセッサと８ＧＢのメモリとを有し、１ＧＨｚのＣＰＵと２ＧＢのメモリを使用するＶＭ６を稼働させており、４ＧＨｚのプロセッサのうちの１ＧＨｚと８ＧＢのメモリのうちの２ＧＢが使用中である。

サーバ４は、物理リソースとして４ＧＨｚのプロセッサと８ＧＢのメモリとを有し、１ＧＨｚのＣＰＵと４ＧＢのメモリを使用するＶＭ７を稼働させており、４ＧＨｚのプロセッサのうちの１ＧＨｚと８ＧＢのメモリのうちの４ＧＢが使用中である。サーバ５は、物理リソースとして４ＧＨｚのプロセッサと８ＧＢのメモリとを有し、１ＧＨｚのＣＰＵと４ＧＢのメモリを使用するＶＭ８を稼働させており、４ＧＨｚのプロセッサのうちの１ＧＨｚと８ＧＢのメモリのうちの４ＧＢが使用中である。

したがって、クラスタ３０全体のシステムリソースとしては、２０ＧＨｚのＣＰＵと４０ＧＢのメモリとを有し、そのうちの８ＧＨｚと１６ＧＢとが使用中となる。

（１回目のメンテナンス）
図８に示した初期状態において、管理装置５０は、メンテナンス対象のサーバを特定し、自動でメンテナンスを実行する。図９は、具体例における１回目のメンテナンス処理を説明する図である。

図９に示すように、管理装置５０のメイン処理部６２は、サーバ１からサーバ５のうち、冗長ポリシーに設定される２台のメンテナンス対象のサーバを特定する。ここでは、メイン処理部６２は、サーバリストの中からＣＰＵ使用率が少ないサーバ３、４、５を特定し、サーバ３、４、５のうちメモリ使用率が少ないサーバ３を選択する。また、メイン処理部６２は、残りのサーバ４とサーバ５のうち、サーバリストの上位であるサーバ４を選択する。この結果、メイン処理部６２は、メンテナンス対象としてサーバ３とサーバ４を特定する。

続いて、メイン処理部６２は、メンテナンス対象のサーバ上で稼働するＶＭをリソースに空きがある任意のサーバに移動させる。例えば、メイン処理部６２は、メンテナンス対象のサーバ３上で稼働するＶＭ６をサーバ５に移動させ、メンテナンス対象のサーバ４上で稼働するＶＭ７をサーバ１に移動させる。その後、サーバ３とサーバ４に対してメンテナンスが実行される。なお、２台のサーバが停止中であることから、クラスタ３０全体のシステムリソースとしては、１２ＧＨｚのＣＰＵと２４ＧＢのメモリとを有し、そのうちの８ＧＨｚと１６ＧＢとが使用中となる。

メンテナンスの実行完了後の状態を図１０に示す。図１０は、具体例における１回目のメンテナンス完了時を説明する図である。図１０の（ａ）に示すように、メイン処理部６２は、メンテナンスが完了したサーバ３とサーバ４をサーバリストから削除する。また、図１０の（ｂ）に示すように、サーバ３とサーバ４は、メンテナンス完了後であることから、物理リソースの使用率は０である。サーバ１は、サーバ４から移動したＶＭ７を新たに稼働させているので、４ＧＨｚのプロセッサのうちの３ＧＨｚと８ＧＢのメモリのうちの７ＧＢが使用中である。同様に、サーバ５は、サーバ３から移動したＶＭ６を新たに稼働させているので、４ＧＨｚのプロセッサのうちの２ＧＨｚと８ＧＢのメモリのうちの６ＧＢが使用中である。

なお、サーバ２には変化がなく、システムリソースとしても、ＶＭが移動しただけで全体としては変化がないので、初期状態と同様、２０ＧＨｚのＣＰＵのうちの８ＧＨｚと４０ＧＢのメモリのうちの１６ＧＢとが使用中である。また、サーバ３とサーバ４は、メンテナンス完了後に、クラスタ３０に再度組み込まれる。

（２回目のメンテナンス）
図１０に示した初期状態において、管理装置５０は、次のメンテナンス対象のサーバを特定し、自動でメンテナンスを実行する。図１１は、具体例における２回目のメンテナンス処理を説明する図である。

図１１に示すように、管理装置５０のメイン処理部６２は、サーバリストの中から冗長ポリシーに設定される２台のメンテナンス対象のサーバを特定する。ここでは、メイン処理部６２は、サーバリストに登録されるサーバ１、２、５のうちＣＰＵ使用率が少ないサーバ５を選択する。また、メイン処理部６２は、残りのサーバ１とサーバ２についてはＣＰＵ使用率が同じであることから、メモリ使用率が少ないサーバ２を選択する。この結果、メイン処理部６２は、メンテナンス対象としてサーバ２とサーバ５を特定する。

続いて、メイン処理部６２は、メンテナンス対象のサーバ上で稼働するＶＭをリソースに空きがある任意のサーバに移動させる。例えば、メイン処理部６２は、メンテナンス対象のサーバ２上で稼働するＶＭ３、ＶＭ４、ＶＭ５をサーバ３に移動させ、メンテナンス対象のサーバ５上で稼働するＶＭ５、ＶＭ６をサーバ４に移動させる。その後、サーバ２とサーバ５に対してメンテナンスが実行される。なお、２台のサーバが停止中であることから、クラスタ３０全体のシステムリソースとしては、１２ＧＨｚのＣＰＵと２４ＧＢのメモリとを有し、そのうちの８ＧＨｚと１６ＧＢとが使用中となる。

メンテナンスの実行完了後の状態を図１２に示す。図１２は、具体例における２回目のメンテナンス完了時を説明する図である。図１２の（ａ）に示すように、メイン処理部６２は、メンテナンスが完了したサーバ２とサーバ５をサーバリストから削除する。また、図１２の（ｂ）に示すように、サーバ２とサーバ５は、メンテナンス完了後であることから、物理リソースの使用率は０である。サーバ３は、サーバ２から移動したＶＭ３、ＶＭ４、ＶＭ５を新たに稼働させているので、４ＧＨｚのプロセッサのうちの３ＧＨｚと８ＧＢのメモリのうちの３ＧＢが使用中である。同様に、サーバ４は、サーバ５から移動したＶＭ６とＶＭ８を新たに稼働させているので、４ＧＨｚのプロセッサのうちの２ＧＨｚと８ＧＢのメモリのうちの６ＧＢが使用中である。

なお、サーバ１には変化がなく、システムリソースとしても、ＶＭが移動しただけで全体としては変化がないので、初期状態と同様、２０ＧＨｚのＣＰＵのうちの８ＧＨｚと４０ＧＢのメモリのうちの１６ＧＢとが使用中である。また、サーバ２とサーバ５は、メンテナンス完了後に、クラスタ３０に再度組み込まれる。

（３回目のメンテナンス）
図１１に示した初期状態において、管理装置５０は、次のメンテナンス対象のサーバを特定し、自動でメンテナンスを実行する。図１３は、具体例における３回目のメンテナンス処理を説明する図である。

図１３に示すように、管理装置５０のメイン処理部６２は、サーバリストの中から冗長ポリシーに設定される２台のメンテナンス対象のサーバを特定する。ここでは、メイン処理部６２は、サーバリストにサーバが登録されていないので、メンテナンス対象としてサーバ１のみを特定する。

続いて、メイン処理部６２は、メンテナンス対象のサーバ上で稼働するＶＭをリソースに空きがある任意のサーバに移動させる。例えば、メイン処理部６２は、メンテナンス対象のサーバ１上で稼働するＶＭ１、ＶＭ２、ＶＭ７をサーバ２に移動させる。その後、サーバ２とサーバ５に対してメンテナンスが実行される。なお、１台のサーバが停止中であることから、クラスタ３０全体のシステムリソースとしては、１６ＧＨｚのＣＰＵと３２ＧＢのメモリとを有し、そのうちの８ＧＨｚと１６ＧＢとが使用中となる。

メンテナンスの実行完了後の状態を図１２に示す。図１４は、具体例における３回目のメンテナンス完了時を説明する図である。図１４の（ａ）に示すように、メイン処理部６２は、メンテナンスが完了したサーバ１をサーバリストから削除する。また、図１４の（ｂ）に示すように、サーバ１は、メンテナンス完了後であることから、物理リソースの使用率は０である。サーバ２は、サーバ１から移動したＶＭ１、ＶＭ２、ＶＭ７を新たに稼働させているので、４ＧＨｚのプロセッサのうちの３ＧＨｚと８ＧＢのメモリのうちの７ＧＢが使用中である。

なお、サーバ３、４、５には変化がなく、システムリソースとしても、ＶＭが移動しただけで全体としては変化がないので、初期状態と同様、２０ＧＨｚのＣＰＵのうちの８ＧＨｚと４０ＧＢのメモリのうちの１６ＧＢとが使用中である。また、サーバ１は、メンテナンス完了後に、クラスタ３０に再度組み込まれる。

その後、メイン処理部６２は、サーバリストにサーバが登録されていないことから、メンテナンスが完了したと判定する。また、メイン処理部６２は、ＶＭの初期位置情報に基づいて、メンテナンス完了後の図１４の状態から図８の状態になるように、ＶＭを移動させることもできる。具体的には、メイン処理部６２は、サーバ２で稼働するＶＭ１、ＶＭ２をサーバ１に移動させ、サーバ２で稼働するＶＭ７をサーバ４に移動させ、サーバ３で稼働するＶＭ３、ＶＭ４、ＶＭ５をサーバ２に移動させ、サーバ４で稼働するＶＭ６とＶＭ８それぞれをサーバ３とサーバ５に移動させる。

［事前処理の流れ］
図１５は、事前処理の流れを示すシーケンス図である。図１５に示すように、管理装置５０の入出力部６１は、保守端末２０から固定ＶＭの入力を受け付けると（Ｓ１０１とＳ１０２）、固定ＶＭを固定ＶＭリストＤＢ５３に設定（登録）する（Ｓ１０３とＳ１０４）。

続いて、管理装置５０の事前処理部６３は、メンテナンス開始が指示されると、固定ＶＭのリストを固定ＶＭリストＤＢ５３から取得し（Ｓ１０５とＳ１０６）、クラスタ３０内の各サーバにアクセスし、各固定ＶＭの起動状態を取得する（Ｓ１０７とＳ１０８）。

ここで、事前処理部６３は、起動状態の固定ＶＭが存在する場合（Ｓ１０９：Ｙｅｓ）、入出力部６１を介して、固定ＶＭの停止を保守端末２０に要求する（Ｓ１１０とＳ１１１）。そして、保守端末２０は、クラスタ３０内の該当サーバにアクセスして、固定ＶＭの停止を実行する（Ｓ１１２とＳ１１３）。この指示を受信した該当サーバは、固定ＶＭを停止し（Ｓ１１４）、停止が完了したことを示す停止完了通知を保守端末２０に送信する（Ｓ１１５とＳ１１６）。そして、保守端末２０は、入出力部６１を介して、固定ＶＭの停止完了通知を事前処理部６３に通知する（Ｓ１１７とＳ１１８）。

この停止完了通知を受信した事前処理部６３は、冗長ポリシーである同時再起動可能なサーバ数を冗長ポリシーＤＢ５５から取得する（Ｓ１１９とＳ１２０）。続いて、事前処理部６３は、サーバの物理リソースおよび使用リソースを含むシステムリソースの情報をサーバリソース情報ＤＢ５７から取得し（Ｓ１２１とＳ１２２）、各ＶＭのリソース情報をＶＭリソース情報ＤＢ５８から取得する（Ｓ１２３とＳ１２４）。

その後、事前処理部６３は、クラスタ３０内のサーバのうち同時再起動可能なサーバ数を除いた残りのサーバの物理リソース量から、各ＶＭのリソース量を減算した未使用リソース量を算出する（Ｓ１２５）。そして、事前処理部６３は、未使用リソース量が０以上か否かによって、メンテナンスが可能か否かを判定する（Ｓ１２６）。つまり、事前処理部６３は、クラスタ３０内のサーバのうち同時再起動可能なサーバ数を除いた残りのサーバの物理リソースで、ＶＭのリソースが確保できるか否かによって、メンテナンスが可能か否かを判定する。

ここで、事前処理部６３は、メンテナンスが可能ではないと判定した場合（Ｓ１２６：Ｎｏ）、入出力部６１を介して、保守端末２０にリソース解放を要求する（Ｓ１２７とＳ１２８）。続いて、保守端末２０は、クラスタ３０に対して、使用していなアプリ等を終了させたり、不要なＶＭを停止させたりするリソース解放を実行する（Ｓ１２９とＳ１３０）。

そして、クラスタ３０内では、保守端末２０からの指示に応じて、該当ＶＭの停止などが実行されてリソースを解放し（Ｓ１３１）、完了通知を保守端末２０に送信する（Ｓ１３２とＳ１３３）。

この完了通知を受信した保守端末２０は、入出力部６１を介して、事前処理部６３にリソース解放完了通知を送信する（Ｓ１３４とＳ１３５）。その後、事前処理部６３は、メンテナンス実行部６４に、メンテナンス処理の実行開始を指示する（Ｓ１３６）。

なお、Ｓ１０９において、事前処理部６３は、起動状態の固定ＶＭが存在しない場合（Ｓ１０９：Ｎｏ）、Ｓ１１０からＳ１１８を実行することなく、Ｓ１１９を実行する。また、Ｓ１２７において、事前処理部６３は、メンテナンスが可能であると判定した場合（Ｓ１２６：Ｙｅｓ）、Ｓ１２７からＳ１３５を実行することなく、Ｓ１３６を実行する。

［メンテナンス処理の流れ］
図１６は、メンテナンス処理の流れを示すシーケンス図である。なお、ここでは、一例として、メンテナンス時にサーバを停止させる例を用いて説明するが、これに限定されるものではない。

図１６に示すように、管理装置５０のメンテナンス実行部６４は、メンテナンス実行が指示されると、サーバリストをサーバリストＤＢ５６から取得する（Ｓ２０１とＳ２０２）。続いて、メンテナンス実行部６４は、冗長ポリシーである同時再起動可能なサーバ数を冗長ポリシーＤＢ５５から取得する（Ｓ２０３とＳ２０４）。

そして、メンテナンス実行部６４は、メンテナンス対象のサーバを決定する（Ｓ２０５）。例えば、メンテナンス実行部６４は、サーバリストから、ＣＰＵ使用率およびメモリ使用率の少ない順に同時再起動可能台数分のサーバを選択する。

続いて、メンテナンス実行部６４は、メンテナンス対象に選択されたサーバに、メンテナンス対象であることを通知する（Ｓ２０６とＳ２０７）。すると、該当サーバは、メンテナンスモードに変換し、変換が完了したことをメンテナンス実行部６４に通知する（Ｓ２０８とＳ２０９）。このとき、メンテナンス実行部６４は、メンテナンス対象のサーバ上で稼働するＶＭの移動指示を送信し、該当サーバのＶＭの移動を実行する。なお、メンテナンスモードの一例としては、稼働中のＶＭを停止または移動させて、サーバの停止等が実行可能な状態を示す。

そして、メンテナンス実行部６４は、メンテナンスモードに変更対象に選択されたサーバに、サーバ停止を指示する（Ｓ２１０とＳ２１１）。すると、該当サーバは、シャットダウンして停止する（Ｓ２１２）。その後、保守者等によるメンテナンスが実行され（Ｓ２１３）、メンテナンスが完了すると、メンテナンス完了通知がメンテナンス実行部６４に送信される（Ｓ２１４とＳ２１５）。なお、メンテナンス完了通知は、クラスタ３０内のいずれかのサーバから送信することもでき、クラスタ内の管理ＶＭなどから送信することもでき、保守端末２０が送信することもできる。

そして、メンテナンス実行部６４は、メンテナンス完了を確認すると（Ｓ２１６）、停止させたサーバに起動指示を送信する（Ｓ２１７とＳ２１８）。すると、該当サーバは、Ｗａｋｅ−ＯＮ−Ｌａｎなどを用いた遠隔操作によりサーバを起動し、起動が完了すると、起動完了を通知する（Ｓ２１９とＳ２２０）。

その後、メンテナンス実行部６４は、サーバの起動を確認すると（Ｓ２２１）、サーバリストを更新する（Ｓ２２２）。すなわち、メンテナンス実行部６４は、メンテナンスが完了したサーバをサーバリストから削除する。

そして、メンテナンス実行部６４は、サーバリストにサーバが残っており、メンテナンス未完了のサーバが存在する場合（Ｓ２２３：Ｙｅｓ）、Ｓ２０５以降を繰り返す。一方、メンテナンス実行部６４は、サーバリストにサーバが残っておらず、メンテナンス未完了のサーバが存在しない場合（Ｓ２２３：Ｎｏ）、入出力部６１にメンテナンス完了通知を送信する（Ｓ２２４とＳ２２５）。そして、入出力部６１は、メンテナンス完了通知を保守端末２０に送信する（Ｓ２２６とＳ２２７）。

［効果］
上述したように、管理装置５０は、クラスタリング技術を用いたサーバ群であるシステムのファームウェアのアップデートなどのメンテナンス時に、事前確認において高度なスキルやノウハウを用いずに、メンテナンス作業を開始することができる。また、管理装置５０は、事前に空のサーバを用意する必要がなくなり、複数台のサーバを同時に保守・メンテナンスを可能となるため、メンテナンス作業時間の短期化を実現し、結果として保守作業のコスト削減を実現できる。

一般的に、クラスタリング技術を用いたシステムを構成しているサーバの台数、種類が多いほど、工数や人為的ミスの発生する可能性が高くなる。これに対して、管理装置５０は、起動停止含む保守を行うサーバを自動で複数選択し、自動で再起動を含めたメンテナンスを同時に実施することで、コストダウンと短納期化を実現するとともに、人為的なミスも削減できる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［冗長ポリシーの変更］
例えば、管理装置５０は、メンテナンス処理時にリソース不足が発生した場合、冗長ポリシーを動的に変更して、メンテナンス処理を継続することができる。図１７は、メンテナンス処理におけるリソース不足を説明する図である。図１８は、メンテナンス処理におけるリソース不足時の処理を説明する図である。

図１７に示すように、使用可能なシステム全体の物理リソースが、ＣＰＵが２０ＧＨｚでメモリが４０ＧＢであり、ＶＭが使用している使用リソースが、ＣＰＵが８ＧＨｚでメモリが３２ＧＢの状態で、冗長ポリシー２台であったとする。

そして、管理装置５０は、サーバ１からサーバ５はいずれも同じ物理リソース（４ＧＨｚ、８ＧＢ）であることから、任意の２台をメンテナンス対象とする。ところが、管理装置５０は、２台のサーバをクラスタ３０から切り離したときの物理リソースがＣＰＵ１２ＧＨｚ、メモリ２４ＧＢとなり、ＶＭが使用している使用リソース（ＣＰＵ８ＧＨｚ、メモリ３２ＧＢ）より少なくなるので、メンテナンスが実行できないと判定する。

このとき、図１８に示すように、管理装置５０は、冗長ポリシーを設定値「２」よりも小さい「１」に変更する。この結果、管理装置５０は、１台のサーバをクラスタ３０から切り離したときの物理リソースがＣＰＵ１６ＧＨｚでメモリ３２ＧＢとなり、ＶＭが使用している使用リソース（ＣＰＵ８ＧＨｚ、メモリ３２ＧＢ）より多くなるので、メンテナンスが実行可能と判定し、実施例１によるメンテナンスを実行することができる。このように、管理装置５０は、冗長化が担保できる範囲内で、クラスタ３０から切り離すサーバ台数を動的に制御することができるので、冗長化を維持しつつ、安全にメンテナンスを実行することができる。

［固定ＶＭの検出］
管理装置５０は、固定ＶＭを自動で検出することができる。例えば、各サーバはクラスタ３０に属している共有ストレージと、クラスタ３０に属していないローカルストレージを保有している。一般的にローカルストレージにはオペレーティングシステム等が格納され、共有ストレージには仮想マシン等のデータが格納される。ただし、仮想マシンを移動させないために、ローカルストレージ上に仮想マシンを配置する場合がある。このため、管理装置５０の事前処理部６３は、各サーバ上の各仮想マシンのデータが保有されているストレージを確認し、ローカルストレージにある仮想マシンを固定ＶＭと自動で判定することができる。

［メンテナンス］
上記実施例で説明したメンテナンスの一例としては、保守者が手動で行うハードディスク交換などに限らず、管理装置５０が主導で実行できるファームウェア等へのパッチ適用、ファームウェア等のアップデート、サーバリブートなどを含む。また、管理装置は、サーバに限らずルータなどのネットワーク機器に対しても上記自動メンテナンスを実行することもできる。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値などは、あくまで一例であり、任意に変更することができる。なお、リソースの数字等、実施例で説明した各数値例は一例であり、任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［ハードウェア］
図１９は、ハードウェア構成例を説明する図である。図１９に示すように、管理装置５０は、通信装置５０ａ、ＨＤＤ（Hard Disk Drive）５０ｂ、メモリ５０ｃ、プロセッサ５０ｄを有する。また、図１９に示した各部は、バス等で相互に接続される。

通信装置５０ａは、ネットワークインタフェースカードなどであり、他のサーバや他の端末との通信を行う。ＨＤＤ５０ｂは、図２に示した機能を動作させるプログラムやＤＢを記憶する。

プロセッサ５０ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ５０ｂ等から読み出してメモリ５０ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、管理装置５０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ５０ｄは、入出力部６１とメイン処理部６２等と同様の機能を有するプログラムをＨＤＤ５０ｂ等から読み出す。そして、プロセッサ５０ｄは、入出力部６１とメイン処理部６２等と同様の処理を実行するプロセスを実行する。

このように管理装置５０は、プログラムを読み出して実行することで管理方法を実行する情報処理装置として動作する。また、管理装置５０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、管理装置５０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ（Magneto−Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

２０ 保守端末
３０ クラスタ
５０ 管理装置
５１ 通信部
５２ 記憶部
５３ 固定ＶＭリストＤＢ
５４ ＶＭ位置情報ＤＢ
５５ 冗長ポリシーＤＢ
５６ サーバリストＤＢ
５７ サーバリソース情報ＤＢ
５８ ＶＭリソース情報ＤＢ
６０ 制御部
６１ 入出力部
６２ メイン処理部
６３ 事前処理部
６４ メンテナンス実行部

Claims (8)

1. 複数の情報処理装置によって構成されるクラスタのリソース情報と、前記クラスタ内で稼働する各仮想マシンのリソース情報の合計値とを取得する取得部と、
   前記クラスタのリソース情報が前記各仮想マシンのリソース情報の合計値よりも多くなるように、前記複数の情報処理装置の中から、前記クラスタの冗長ポリシーに基づき設定される設定台数の情報処理装置を選択して前記クラスタから切り離すクラスタ制御部と、
   前記クラスタから切り離された情報処理装置上で稼働する仮想マシンを、前記クラスタ内の他の情報処理装置に移動させ、前記クラスタから切り離された情報処理装置に対してメンテナンス作業を実行する実行部と
   を有することを特徴とする管理装置。
2. 前記クラスタ制御部は、メンテナンス作業が完了した作業済みの情報処理装置を前記クラスタに組み込んで前記クラスタを再構成し、前記クラスタのリソース情報が前記各仮想マシンのリソース情報の合計値よりも多くなるように、前記クラスタを構成する前記複数の情報処理装置のうち前記作業済みの情報処理装置を除く情報処理装置の中から、前記設定台数以下の情報処理装置を選択して、前記クラスタから切り離し、
   前記実行部は、前記クラスタから切り離された情報処理装置上で稼働する仮想マシンを、前記クラスタ内の他の情報処理装置に移動させ、前記クラスタから切り離された情報処理装置に対してメンテナンス作業を実行することを特徴とする請求項１に記載の管理装置。
3. 前記クラスタ制御部は、前記クラスタを構成する複数の情報処理装置それぞれに対するメンテナンス作業が完了するまで、前記クラスタから切り離す情報処理装置の選択と、メンテナンス作業が完了した情報処理装置を組み込む前記クラスタの再構成とを順次繰り返すことを特徴とする請求項２に記載の管理装置。
4. 前記実行部は、前記クラスタを構成する複数の情報処理装置それぞれに対するメンテナンス完了後の各仮想マシンの稼働位置を、初期状態の位置に戻すように、前記各仮想マシンの移動を実行することを特徴とする請求項３に記載の管理装置。
5. 前記各仮想マシンのうち他の情報処理装置に移動できない固定仮想マシンを、前記メンテナンス作業の開始前に停止させる停止部をさらに有することを特徴とする請求項１に記載の管理装置。
6. 前記停止部は、前記各仮想マシンのうち、前記クラスタに属していない情報処理装置のローカルストレージを利用する仮想マシンを前記固定仮想マシンとして検出することを特徴とする請求項５に記載の管理装置。
7. コンピュータに、
   複数の情報処理装置によって構成されるクラスタのリソース情報と、前記クラスタ内で稼働する各仮想マシンのリソース情報の合計値とを取得し、
   前記クラスタのリソース情報が前記各仮想マシンのリソース情報の合計値よりも多くなるように、前記複数の情報処理装置の中から、前記クラスタの冗長ポリシーに基づき設定される設定台数の情報処理装置を選択して前記クラスタから切り離し、
   前記クラスタから切り離された情報処理装置上で稼働する仮想マシンを、前記クラスタ内の他の情報処理装置に移動させ、前記クラスタから切り離された情報処理装置に対してメンテナンス作業を実行する
   を実行させることを特徴とする管理プログラム。
8. クラスタシステムと管理装置とを含む情報処理システムにおいて、
   前記クラスタシステムは、
   前記クラスタシステムを構成する複数の情報処理装置と、前記複数の情報処理装置それぞれのリソースを用いて稼働する各仮想マシンとを有し、
   前記管理装置は、
   前記クラスタシステムのリソース情報と、前記各仮想マシンのリソース情報の合計値とを取得する取得部と、
   前記クラスタシステムのリソース情報が前記各仮想マシンのリソース情報の合計値よりも多くなるように、前記複数の情報処理装置の中から、前記クラスタシステムの冗長ポリシーに基づき設定される設定台数の情報処理装置を選択して前記クラスタシステムから切り離すクラスタ制御部と、
   前記クラスタシステムから切り離された情報処理装置上で稼働する仮想マシンを、前記クラスタシステム内の他の情報処理装置に移動させ、前記クラスタシステムから切り離された情報処理装置に対してメンテナンス作業を実行する実行部と、を有する
   ことを特徴とする情報処理システム。

Images