JP2014178912A - サーバ移動計画策定支援方法 - Google Patents

Abstract

【課題】
本発明は仮想サーバ１９１、１９２の移動に伴うシステム運用への影響を考慮した、仮想サーバの移動計画の策定支援を行う。
【解決手段】
管理サーバ１２０において、システム運用中に行われる各構成要素間での通信に関する情報と、通信を行う際に通信対象を識別するための識別方法が移動先に引き継がれるかを示す引き継ぎ情報とを持ち、サーバ移動の後の通信継続可否に基づきシステム運用への影響を判定する。
また、管理サーバ１２０において、システムに含まれるサーバの構成情報を持ち、引継ぎ情報において、移動先のサーバが特定の条件を満たす場合に識別情報が引き継がれる場合において、移動先のサーバが前記条件を満たすかをサーバの構成情報を用いて判定し、識別情報の引き継ぎ有無を判定する。
【選択図】 図１

Description

本発明は、サーバを含む情報処理システムの運用方法に関するものであり、特にその移動先の決定を支援する技術に関するものである。

近年の情報システムにおいて、サーバ仮想化技術の普及が進んでいる。サーバ仮想化とは、１つの物理サーバを仮想的に複数のサーバに見せる技術である。サーバ仮想化により提供される仮想的なサーバを仮想サーバと呼ぶ。

サーバ仮想化技術を利用することで、従来に比べサーバの移動を容易に実施することができるようになり、高度なサーバ運用が可能となる。例えば、仮想サーバのライブマイグレーション機能を用いることで、業務無停止でのサーバ保守が実現できる。ライブマイグレーションとは、ある物理サーバ上で稼働する仮想サーバを、OSやアプリケーションを停止することなく、他の物理サーバに移動させる機能である。ファームウェアのアップデートや部品交換といったサーバの保守作業を行う場合、物理サーバの電源を切断する必要があることが多い。そのため、従来は物理サーバ上で稼働するOSやアプリケーションを停止させた後にサーバ保守を実施していた。ライブマイグレーションを利用して、保守対象の物理サーバ上で稼働する仮想サーバを他の物理サーバに移動させた後にサーバ保守を実施することで、業務を停止することなくサーバの保守を行うことができる。

無停止保守などの目的で仮想サーバを移動させる場合、事前に移動計画を立て、どの仮想サーバをどこに移動させるかを決める必要がある。しかし、移動計画の策定は、様々な条件を考慮する必要があるため煩雑な作業である。そのため、移動計画の策定を支援するための技術が求められている。例えば、特許文献１では、移動に要する処理時間の情報を用いて、適切な移動先のサーバを選択する方法が開示されている。なお、本明細書での移動とは、あるサーバで行っている機能を他のサーバで実行可能とするもので、その一例として、保守の際のいわゆる退避も含まれる。

特開2008-217302号公報

仮想サーバの移動計画の策定においては、仮想サーバの移動がシステム運用へ与える影響を考慮する必要がある。システムの内部には多くの構成要素が存在し、システム運用中には各構成要素の間で様々な通信が行われる。システム運用中に実施していた構成要素間の通信が、仮想サーバの移動に伴い継続不可能となり、システム運用に支障をきたすことがある。特に、ブレードサーバを用いたシステムでは構成要素の数が多く、構成要素間の通信の種類も多いため、システム運用への影響の判定は困難な作業となる。

例えば、ブレードサーバを用いたシステムでは、ブレードシャーシ内に管理モジュールが存在する。システム運用において、ある仮想サーバが、同じブレードシャーシ内に存在する管理モジュールと通信を行うことがある。この場合、仮想サーバが他のブレードシャーシに移動すると、通信すべき管理モジュールも変わるため、適切な通信が継続できなくなる可能性がある。

特許文献１では、移動に要する処理時間を用いた移動先サーバの選択方法が開示されている。しかし、移動先サーバを選択する際、移動がシステム運用に与える影響、特にシステム運用において実施されている各種通信が移動後にも継続できるかどうかについては考慮されていない。そのため、特許文献１では、仮想サーバの移動に伴いシステム運用に問題が発生する可能性を排除することができなかった。

そこで、本発明は仮想サーバの移動に伴うシステム運用への影響を考慮した、仮想サーバの移動計画の策定支援を行うことを目的とする。

上記の目的を達成するために、本発明では、サーバ移動における引継情報を用いて、移動先を決定するものである。より詳細には、移動対象のサーバを管理する管理サーバにおいて、システム運用中に行われる各構成要素間での通信に関する情報と、通信を行う際に通信対象を識別するための識別方法が移動先に引き継がれるかを示す引き継ぎ情報とを持ち、サーバ移動の後の通信継続可否に基づきシステム運用への影響を判定する。

また、管理サーバにおいて、システムに含まれるサーバの構成情報を持ち、引継ぎ情報において、移動先のサーバが特定の条件を満たす場合に識別情報が引き継がれる場合において、移動先のサーバが前記条件を満たすかをサーバの構成情報を用いて判定し、識別情報の引き継ぎ有無を判定する。

本発明を実施することで、サーバの移動がシステム運用に与える影響を事前に判定することができる。これにより、運用管理者はシステム運用への影響を考慮した移動計画を容易に策定することができる。

本発明の第１実施形態に関わるシステムの構成 本発明の実施形態で用いられるブレードサーバ、管理サーバの構成 本発明の実施形態における処理の流れ 保守内容入力画面の例 保守メニューの例 サーバ構成の例 保守内容の例 移動計画の例 移動先候補評価部の内部構造 移動先候補情報の例 移動先候補情報の例 移動先候補情報の例 移動先候補情報の例 通信情報の例 引継ぎ情報の例 運用への影響判定処理の詳細 通信毎の運用への影響判定処理の詳細 移動先選択画面の例 本発明の第２実施形態に関わるシステムの構成 本発明の実施形態における通信情報作成処理の流れ 通信モデルの例 構成モデルの例 運用情報の例

以下、図面を参照しながら本発明を実施するための第１の実施形態について説明する。 本実施形態に関わるシステムの構成例を図１に示す。本システムは、２つのブレードシャーシ１００及び１１０、管理サーバ１２０、外部スイッチ１４０から構成される。管理サーバ１２０と各ブレードシャーシ（１００及び１１０）は、外部スイッチ１４０を介して接続されている。ブレードシャーシの内部には、ブレードサーバ、管理モジュール、内部スイッチモジュールなどが含まれる。例えば、ブレードシャーシ１００は、複数のブレードサーバ（図を簡単化するため、図１には１８１と１８２の２つのみ記載）、管理モジュール１０１、内部スイッチモジュール１０２を含んでいる。同様に、ブレードシャーシ１１０は、複数のブレードサーバ（図１には１８３、１８４のみ記載）、管理モジュール１１１、内部スイッチモジュール１１２を含んでいる。ブレードサーバ上では０個以上の仮想サーバが稼働している。例えば、ブレードサーバ１０１上では、２つの仮想サーバ（１９１と１９２）が稼働している。図１では省略しているが、他のブレードサーバ上でも同様に０個以上に仮想サーバが稼働している。管理サーバ１２０は、保守内容特定部１２１、移動サーバ特定部１２２、移動先候補評価部１２３のプログラムを備え、保守メニュー１３１、サーバ構成１３２、保守内容１３３、移動計画１３４、移動先候補情報１３５、通信情報１３６、引継ぎ情報１３７のデータを備える。各プログラムとデータの詳細については後述する。

本実施形態では、ブレードサーバ１８１の保守を実施する場合を例にとり説明を行う。ブレードサーバ１８１の保守を実施する際、ブレードサーバ１８１の電源を切断する必要があるため、業務無停止で保守を実行するにはブレードサーバ１８１上で稼働している仮想サーバ１９１及び１９２を、システム内の他のブレードサーバに移動させる必要がある。
ブレードサーバ１８１、１８２、１８３、１８４、管理サーバ１２０は、図２に示すような一般的な構成を持つ計算機２０１を用いて実現することができる。計算機２０１は、CPU２０２、メモリ２０３、ネットワークに接続するネットワークアダプタ２０４、ハードディスクなどの記憶媒体に接続するディスクアダプタ２０５、キーボードやマウスなどの入力装置２０６、ディスプレイなどの出力装置２０７によって構成される。計算機２０１では、CPU２０２が、メモリ２０３上に読み込まれたプログラム２０８を実行することで各機能が実現される。

以下では、図３に示す処理フローに従い本実施形態における処理の詳細を説明する。
まず、ステップ３０１において、管理サーバ１２０の保守内容特定部１２１は、保守内容入力画面を作成し、管理サーバ１２０の出力装置２０７に表示する。保守内容入力画面の例を図４に示す。保守内容入力画面４０１は、保守作業入力欄４０２、作業対象入力欄４０３、決定ボタン４０４から構成される。保守内容特定部１２１は、予め保存されている保守メニュー１３１、サーバ構成１３２を用いて、保守内容入力画面４０１に入力支援機能を挿入してもよい。保守メニュー１３１は、本システムにおいて想定される保守作業の内容を予め登録したデータである。保守メニュー１３１の例を図５に示す。保守メニュー１３１はテーブル形式で表現されており、保守メニュー１３１の各レコードは、保守の具体的な作業内容を示す保守作業フィールド５０１と、当該保守作業の対象となるシステムの構成要素を示す作業対象フィールド５０２とを持つ。例えば、代表的な保守作業であるサーバのファームウェアアップデートの場合は、保守作業５０１は「サーバのファームウェアアップデート」、作業対象５０２は「ブレードサーバ」となる。

サーバ構成１３２は、本システムにおけるブレードシャーシ、ブレードサーバ、仮想サーバの構成を登録したデータである。サーバ構成１３２の例を図６に示す。
サーバ構成１３２では、ブレードシャーシ識別子フィールド６０１、ブレードサーバ識別子フィールド６０２、仮想サーバ識別子６０４により、各ブレードシャーシ、ブレードサーバ、仮想サーバの包含関係を表現している。サーバ構成１３２の#01行目から#04行目において、ブレードシャーシ１００に対してブレードサーバ１８１、１８２、１８３が登録されている。このことはこれら３つのブレードサーバがブレードシャーシ１００内に含まれることを示す。また、サーバ構成１３２の#01行目から#02行目において、ブレードサーバ１８１に対して、仮想サーバ１９１、１９２が登録されている。このことは、これら２つの仮想サーバがブレードサーバ１８１上で稼働していることを示す。サーバ構成１３２の#06行目において、ブレードサーバ１８５に対して、仮想サーバが「−」印となっているのは、ブレードサーバ１８５上では仮想サーバが稼働していないことを表す。また、ブレードサーバ構成フィールド６０３は、各ブレードサーバの構成情報を表す。ここでは、構成情報の例として各ブレードサーバが持つCPU数を格納している。
保守内容特定部１２１において、保守メニュー１３１とサーバ構成１３２を用いて、保守内容入力画面４０１に入力支援機能を挿入する方法を説明する。保守内容特定部１２１は、保守内容入力画面４０１を作成する際、保守メニュー１３１に含まれる各レコードの保守作業フィールド５０１の内容を、保守作業入力欄４０２の入力候補として、リストボックス等により表示してもよい。また、保守内容入力画面４０１の保守作業欄４０２に入力された値に応じて、作業対象入力欄４０３の入力候補を表示してもよい。例えば、保守作業欄４０２に「サーバのファームウェアアップデート」が入力された場合、保守メニュー１３１を参照することで、「サーバのファームウェアアップデート」の作業対象が「ブレードサーバ」であることが特定できる。そこで、サーバ構成１３２を参照して本システムに含まれるブレードサーバの識別子を取得し、作業対象欄４０３の入力候補として、リストボックス等により表示してもよい。また、保守作業欄４０２に「バックプレーンの交換」が入力された場合、保守メニュー１３１を参照することで、「バックプレーンの交換」の作業対象が「ブレードシャーシ」であることが特定できる。そこで、サーバ構成１３２を参照して本システムに含まれるブレードシャーシの識別子を取得し、作業対象欄４０３の入力候補として、リストボックス等により表示してもよい。

次にステップ３０２において、保守作業を実施する運用管理者は、出力装置２０７に表示された保守内容入力画面４０１を確認し、入力装置２０６を用いて、これから実施する保守内容を入力する。すなわち、保守内容入力画面４０１の保守作業欄４０２及び作業対象欄４０３に適切な値を入力し、決定ボタン４０４を押下する。保守内容特定部１２１は、入力された内容を保守内容１３３として保存する。保守内容１３３の例を図７に示す。保守内容特定部１２１は、保守内容入力画面４０１の作業対象欄４０３に入力された値を保守内容１３３の保守対象フィールド７０１に、保守作業欄４０２に入力された値を作業内容フィールド７０２に格納する。

次にステップ３０３において、移動サーバ特定部１２２は、保守内容１３３とサーバ構成１３２を用いて移動が必要となる仮想サーバを特定し、移動計画１３４を生成する。移動計画１３４の例を図８に示す。移動計画１３４はテーブル形式で表現されており、移動計画１３４に含まれる各レコードは移動仮想サーバフィールド８０１と移動先ブレードサーバフィールド８０２とを持つ。移動仮想サーバフィールド８０１は、保守作業に伴い移動が必要となる仮想サーバを表す。移動先サーバブレード８０２は、当該仮想サーバの移動先のブレードサーバを表す。移動先サーバ特定部１２２は、保守対象となる構成要素の情報を、保守内容１３３の保守対象フィールド７０１から取得する。そして、保守対象に含まれるブレードサーバ上で稼働するそれぞれの仮想サーバを移動対象とする。例えば、図７に示した保守内容１３３では、保守対象フィールド７０１の値が「ブレードサーバ１８１」であることから、ブレードサーバ１８１以上で稼働するそれぞれの仮想サーバを移動対象とする。ブレードサーバ１８１上で動作する仮想サーバは、サーバ構成１３２を参照することで、仮想サーバ１９１と１９２の２つであることが特定できる。

移動先サーバ特定部１２２は、移動対象の仮想サーバの数だけ移動計画１３４にレコードを追加し、移動仮想サーバフィールド８０１に移動対象の仮想サーバの情報を格納する。ここで格納する情報は、当該仮想サーバが稼働するブレードサーバの識別子と、当該仮想サーバの識別子を「/」で区切った文字列を使用する。ここでは、移動対象の仮想サーバが１９１と１９２の２つであるため、移動計画１３４には２レコードを追加し、移動仮想サーバフィールド８０１には、それぞれ「ブレードサーバ１８１/仮想サーバ１９１」と「ブレードサーバ１８１/仮想サーバ１９２」を格納する。ステップ３０３の時点では、まだ移動先のブレードサーバは決定していないため、移動計画１３４のそれぞれのレコードにおいて、移動先ブレードサーバフィールド８０２は空欄とする。

次に、移動計画１３４に含まれる各レコードについて、ステップ３０５からステップ３１２で説明する処理を順に実行する。以下では、移動計画１３４の第１レコード（#01行目）の処理を例に取り詳細を説明する。
ステップ３０５からステップ３１２の処理は、主に移動先候補評価部１２３によって実行される。移動先候補評価部１２３の内部構造を図９に示す。移動先候補評価部１２３は、移動先候補情報管理部９０１、保守実施可否判定部９０２、移動可否判定部９０３、運用影響判定部９０３のプログラムを備える。

ステップ３０５では、移動先候補評価部１２３の移動先候補情報管理部９０１が、サーバ構成１３２を用いて移動先候補情報１３５を作成する。
移動先候補情報１３５は、移動先の候補となるブレードサーバや、当該ブレードサーバに対する評価の結果を持つデータである。移動先候補情報１３５の例を図１０に示す。移動先候補情報１３５はテーブル形式で表現され、各レコードが１つの移動先候補を表す。ブレードサーバフィールド１００１は、移動先の候補となるブレードサーバの識別子を表す。保守可否フィールド１００２、移動可否フィールド１００３、運用影響フィールド１００４、コメントフィールド１００５は、ステップ１００６以降で実施する候補先サーバの評価の結果を格納するためのフィールドである。

移動先候補情報管理部９０１は、サーバ構成１３２を参照し、本システムに含まれるブレードサーバの識別子を取得する。そして、本システムに含まれるブレードサーバの数だけ、移動先候補情報１３５にレコードを追加し、ブレードサーバフィールド１００１に各移動先候補のブレードサーバの識別子を登録する。図６に示したサーバ構成１３２より、本システムに含まれるブレードサーバは１８１、１８２、１８３、１８４、１８５、１８６の６つであることが特定できる。そのため、移動先候補情報１３５には６レコードを追加し、ブレードサーバフィールド１００１には、それぞれ「１８１」、「１８２」、「１８３」、「１８４」、「１８５」、「１８６」を格納する。ステップ３０５の時点ではまだ移動先の候補となるブレードサーバの評価を実施していないため、保守可否フィールド１００２、移動可否フィールド１００３、運用影響フィールド１００４、コメントフィールド１００５は空欄とする。

次に、ステップ３０６では、移動先候補評価部１２３の保守実施可否判定部９０２が、移動先候補の各ブレードサーバに対して移動後の保守の実施可否を判定する。すなわち、保守実施可否判定部９０２は、移動先候補情報１３５に含まれる各レコードに対して保守の実施可否を判定し、その結果を移動先候補情報１３５の保守可否フィールド１００２に格納する。移動後の保守の実施可否の判定は、保守内容１３３の保守対象フィールド７０１の値を用いて実施する。保守を実施するには、移動対象の仮想サーバを、保守対象構成要素の外部に移動させる必要がある。

そのため、移動先候補情報１３５のブレードサーバフィールド１００１で示される移動先候補のブレードサーバが、保守内容１３３の保守対象フィールド７０１で示される保守対象構成要素と一致するもしくは含まれる場合、移動先ブレードサーバが保守対象構成要素の外部ではないと判定し、保守可否フィールド１００２に「NG」を格納する。保守可否がNGの場合には、コメントフィールド１００５にNGと判定した理由を格納する。移動先候補のブレードサーバが、保守対象構成要素に含まれない場合は、移動先ブレードサーバが保守対象の外部であると判定し、保守可否フィールド１００２に「OK」を格納する。ステップ３０６における保守実施可否の判定を行った後の移動先候補情報１３５を図１１に示す。本実施形態では、保守対象のブレードサーバが１８１であるため、移動先ブレードサーバが１８１であるレコード判定のみがNGとなり（図１１の#01行目）、その他のレコードは判定がOKとなる（図１１の#02行目〜#06行目）。

次に、ステップ３０７では、移動先候補評価部１２３の移動可否判定部９０３が、移動先候補の各ブレードサーバに対して移動の可否判定を行う。
すなわち、移動可否判定部９０３は、移動先候補情報１３５に含まれる各レコードに対して移動可否を判定し、その結果を移動先候補情報１３５の移動可否フィールド１００３に格納する。

移動可否の判定は、移動の前後のブレードサーバの構成を比較することで行う。仮想サーバの移動を行う場合、移動の前後のブレードサーバの構成に関して、様々な制約条件が存在することがある。例えば、仮想サーバを移動するには、移動の前後のブレードサーバにおいて、CPU数が一致していなくてはならないという制約条件が存在することがある。この場合、移動の前後のブレードサーバのCPU数を比較することで、移動の可否を判定する。移動元のブレードサーバは、処理中の移動計画１３４のレコードにおける、移動仮想サーバフィールド８０１を参照することで取得できる。移動先のブレードサーバは、処理中の移動先候補情報１３５のレコードにおける、ブレードサーバフィールド１００１を参照することで取得できる。各ブレードサーバの構成情報は、サーバ構成１３２のブレードサーバ構成フィールド６０３を参照することで取得できる。ここでは、ブレードサーバの構成情報の例として、サーバ構成１３２はCPU数の情報を保持している。この他にも、例えばCPU種別、仮想化機構種別、ネットワークアダプタ数、ネットワークアダプタ種別など、仮想サーバを移動する際の制約条件となる構成情報を保持してもよい。以上の情報を用いて、移動前後のブレードサーバの構成（ここではCPU数）を比較し、条件を満たす場合（ここではCPU数が一致する場合）は移動可能であると判定し、移動可否フィールド１００３に「OK」を格納する。条件を満たさない場合（ここではCPU数が不一致の場合）は移動不可であると判定し、移動可否フィールド１００３に「NG」を格納する。移動可否がNGの場合は、コメントフィールド１００５にNGと判定した理由を格納する。ステップ３０７における移動可否の判定を行った後の移動先候補情報１３５を図１２に示す。

次に、ステップ３０８では、移動先候補評価部１２３の運用影響判定部９０４が、移動先候補の各ブレードサーバに対して、移動を実施した場合のシステム運用への影響判定を行う。ステップ３０８における運用影響判定の処理の詳細を図１６に示す。以下では、図１６に示すフローチャートに従い、運用影響判定処理の詳細を説明する。

運用影響判定部９０４は、移動先候補方法１３５に含まれる各レコードに対してステップ１６０２からステップ１６０７の処理を実行する。ステップ１６０２では、運用影響判定処理の省略可否を判定する。例えば、処理対象の移動先候補のブレードサーバに対し、ステップ３０６において既に保守不可と判定されている場合、移動先として当該ブレードサーバが選択される可能性が低いため、運用影響判定処理を省略してもよい。ステップ３０６の判定結果は、移動先情報１３５の保守可否フィード１００２を参照することで確認できる。保守可否フィールド１００２の値が「NG」の場合、既に保守不可と判定されているため運用影響判定処理の省略が可能である。同様に、処理対象の移動先候補のブレードサーバに対し、ステップ３０７において既に移動不可と判定されている場合、運用影響判定処理を省略してもよい。ステップ３０７の判定結果は、移動先情報１３５の移動可否フィールド１００３を参照することで確認できる。移動可否フィールド１００３の値が「NG」の場合、既に移動不可と判定されているため運用影響判定処理の省略が可能である。

ステップ１６０２において、省略が可能と判定された場合、運用影響判定処理を省略しステップ１６０３に進む。ステップ１６０３では、移動先候補情報１３５の処理対象レコードの運用影響フィールド１００４に、判定処理を省略したことを表す「−」を格納する。その後、ステップ１６０１に戻り、移動先候補情報１３５に含まれる次のレコードの処理を行う。

ステップ１６０２において、省略が不可と判定された場合、ステップ１６０４に進む。ステップ１６０４以降の処理では、通信情報１３６及び引継ぎ情報１３７を用いて運用への影響判定を行う。

通信情報１３６は、システム運用において、各構成要素間でどのような通信が行われているかを表すデータである。通信情報１３６の例を図１４に示す。通信情報１３６はテーブル形式で表現されており、各レコードが１つの通信に関する情報を表す。通信情報１３６の各レコードは、運用対象フィールド１４０１、アクセス先フィールド１４０２、アクセス元フィールド１４０３、コメントフィールド１４０４を持つ。運用対象フィールド１４０１は、当該通信がどの仮想サーバの運用のために実行されているかを示す情報である。アクセス先フィールド１４０２は、当該通信において、どの構成要素に対して、どのような方法でアクセスしているかを表す情報である。ここでは、アクセス対象であるシステム構成要素を一意に特定する情報とアクセス方法の情報を「＠」で区切って表現している。例えば、#01行目のアクセス先フィールドの値「管理モジュール１０３＠IPアドレス」は、管理モジュール１０３に対してIPアドレスを用いてアクセスしていることを表す。アクセス元フィールド１４０３は、当該通信のアクセス元であるシステム構成要素を一意に特定する情報である。例えば、#01行目のアクセス元フィールドの値「ブレードサーバ１８４/仮想サーバ１９５」は、アクセス元がブレードサーバ１８４上で稼働する仮想サーバ１９５であることを表す。コメントフィールド１４０４には、アクセス先が変更になった場合の影響内容や対策方法を登録する。
引継ぎ情報１３７は、アクセス方法として使われる各種情報が、移動の前後で引継がれるかどうかを表すデータである。引継ぎ情報１３７の例を図１５に示す。

引継ぎ情報１３７はテーブル形式により表現され、各レコードが１つのアクセス先に対する引継ぎ有無に関する情報を表す。引継ぎ情報１３７の各レコードは、アクセス先フィールド１５０１、引継ぎ有無フィールド１５０２、条件フィールド１５０３を持つ。アクセス先フィールド１５０１は、アクセス対象の構成要素の種別を表す情報と、アクセス方法の情報とを「＠」で区切って表現している。例えば、#01行目のアクセス先フィールドの値「仮想サーバ＠IPアドレス」は、仮想サーバに対してIPアドレスでアクセスすることを表す。引継ぎ有無フィールド１５０２は、当該アクセス先が移動先に引継がれるかを表す情報である。引継ぎ有無フィールド１５０２が「有」となっている場合、当該アクセス先の情報は、移動後も引継がれることを表す。例えば、図１５の#01行目では、アクセス先フィールド１５０１の値が「仮想サーバ＠IPアドレス」であり、引継ぎ有無フィールド１５０２の値が「有」である。このことは、仮想サーバのIPアドレスは移動先にも引継がれることを示す。そのため、システム運用において、あるシステム構成要素が仮想サーバにIPアドレスを用いてアクセスしている場合、アクセス元は仮想サーバが移動したことを意識する必要がなく、システム運用に影響は与えない。また、引継ぎ有無フィールド１５０２の値が「無」となっている場合、当該アクセス先の情報は、移動先に引継がれないことを表す。この場合は、アクセス元が移動を意識する必要がある。すなわち、移動に合わせてアクセス先の情報を変更するなどの対応が必要となる。条件に応じて引継ぎ有無が決まる場合には、引継ぎ有無フィールド１５０２の値を「条件付有」とし、条件フィールド１５０３に当該条件を記述する。例えば、図１５の#02行目では、アクセス先フィールド１５０１の値が「管理モジュール＠IPアドレス」であり、引継ぎ有無フィールド１５０２の値が「条件付有」であり、条件フィールド１５０３の値が「ブレードシャーシ内での移動」であることから、管理モジュールのIPアドレスが、ブレードシャーシ内の移動であれば引継がれ、ブレードシャーシ外への移動であれば引継がれないことを表す。

ステップ１６０４では、通信情報１３６に含まれるレコードのうち、処理対象である移動仮想サーバの運用に関するレコードを抽出する。すなわち、通信情報１３６に含まれるレコードのうち、運用対象フィールド１４０１の値が、処理対処の移動仮想サーバと一致するレコードを抽出する。例えば、処理対象の移動仮想サーバが１９１の場合、通信情報１３６の#01行目と#02行目のレコードを処理対象レコードとして抽出する。
ステップ１６０４にて処理対象として抽出した通信情報１３６の各レコードに対し、ステップ１６０６に示す通信情報毎の影響判定を実施する。ステップ１６０６における通信情報毎の影響判定処理の詳細を図１７に示す。以下では、図１７に従って通信情報毎の影響判定処理の詳細を説明する。

まず、ステップ１７０１では、処理対処の通信におけるアクセス先情報の引継ぎ有無を判定する。すなわち、通信情報１３６の処理対象のレコードのアクセス先フィールド１４０２の値について、当該アクセス先が移動先に引継がれるかどうかを、引継ぎ情報１３７の引継ぎ有無フィールド１５０２を参照することで判定する。
ステップ１７０１の判定結果が「有」の場合、ステップ１７０２に進み、移動先候補情報１３５の運用影響フィールド１００４に「影響あり」を格納し、コメントフィールド１００５に影響内容や対策方法の情報を格納する。影響内容や対策方法の情報は、通信情報１３６のコメントフィールド１４０４に記載されている情報をコピーする。
ステップ１７０１の判定結果が「無」の場合、ステップ１７０３に進む。ステップ１７０３では、移動先候補情報１３５の運用影響フィールド１００４を参照し、すでに当該フィールドに値が格納されているかを確認する。運用影響フィールド１００４に、すでに値が格納されている場合、ステップ１７０４に進み、何もせずに処理を終了する。運用影響フィールド１００４に、まだ値が格納されておらず空欄の場合、ステップ１７０５に進み、当該フィールドに「影響なし」を格納する。ステップ１７０１の判定結果が「条件付有」の場合、ステップ１７０６に進み、引継ぎ情報１３７の条件フィールド１５０４に記載されている条件を参照し、処理対象の移動先ブレードサーバが当該条件を満たしているかを判定する。ステップ１７０６において条件を満たす場合、アクセス先情報が引継がれ、システム運用に影響がないため、ステップ１７０３に進む。ステップ１７０６において条件を満たさない場合、アクセス先情報が引継がれず、システム運用に影響があるため、ステップ１７０２に進む。

以上、ステップ１７０１〜ステップ１７０６で説明した通信情報毎の運用への影響判定が終了すると、ステップ１６０５に戻り、通信情報１３６の未処理のレコードに対して通信情報毎の運用への影響判定を行う。処理対象として抽出した通信情報１３６の各レコードの処理が終了すると、ステップ１６０１に戻り、移動先候補方法１３５の未処理のレコードに対して移動先候補に対する運用への影響判定を行う。移動先候補１３５の各レコードの処理が完了すると、ステップ３０９に進む。

ステップ３０９では、管理サーバ１２０の移動先候補情報管理部９０１が、ブレードサーバ選択画面１８０１を作成し、管理サーバ１２０の出力装置に２０７に表示する。移動先選択画面１８０１の例を図１８に示す。移動先選択画面は、移動元表示欄１８０２、移動先候補表示欄１８０３、決定ボタン１８０５、再評価ボタン１８０６を持つ。移動先候補情報管理部９０１は、移動先選択画面１８０１の移動元表示欄１８０２に、処理対象の移動仮想サーバを表示する。移動先候補表示欄１８０３には、ステップ３０５〜ステップ３０８にて作成した移動先候補情報１３５に登録された情報を表示し、さらに移動先を選択するためのラジオボタン１８０４を表示する。ラジオボタン１８０４を表示する際、保守可否フィールドもしくは移動可否フィールドの値がNGであるブレードサーバについては、移動先として選択されることを防ぐため、ラジオボタンを入力不可状態として表示してもよい。図１８に示した移動先選択画面１８０１では、ブレードサーバ１８１は保守可否フィールドの値がNGであることから、ラジオボタンを入力不可状態として表示している。また、ブレードサーバ１８３は移動可否フィールドの値がNGであることから、ラジオボタンを入力不可状態として表示している。

ステップ３１０では、運用管理者は移動先選択画面１８０１の内容を確認し、移動先とするブレードサーバを選択する。ここで、表示された移動先候補の中に適切な移動先ブレードサーバが存在する場合、当該ブレードサーバに対応する選択欄１８０４を選択し、決定ボタン１８０５を押下する。適切な移動先ブレードサーバが存在しない場合には、必要に応じてシステム構成の設定や各種設定の変更などを行った後に、再評価ボタン１８０６を押下する。

ステップ３１１では、移動先候補情報管理部９０１が、ステップ３１０にて入力された内容の種別を判定する。すわなち、ステップ３１０における入力が再評価ボタン１８０６の押下だった場合、ステップ３０５に戻り、再度移動先候補の評価を実施する。ステップ３１０における入力が、移動先の選択と決定ボタン１８０５の押下だった場合、ステップ３１２に進む。

ステップ３１２では、移動先候補情報管理部９０１が、ステップ３１０にて入力された内容に基づき移動計画１３４を更新する。すなわち、移動計画１３４の移動先ブレードサーバフィールド８０２に、ステップ３１０にて選択されたブレードサーバの識別子を格納する。

ステップ３１２が終了すると、移動計画１３４に未処理のレコードが存在する場合には、ステップ３０４に戻り未処理のレコードに対する処理を実行する。移動計画１３４に未処理のレコードが存在しない場合には処理を終了させる。

本実施形態では、移動先サーバの候補を評価する際、保守実施可否の判定（ステップ３０６）、移動可否の判定（ステップ３０７）、運用への影響判定（ステップ３０８）を実行しているが、他の方法を用いて評価を実施してもよい。例えば、仮想サーバを移動した後、現状と同等の性能を確保できるか判定することで評価を行ってもよい。また、これらの評価は任意の順番で実行してもよい。

また、本実施形態では、移動対象の各仮想サーバに対して個別に移動先の候補を表示しているが、移動対象の仮想サーバが複数存在する場合には、移動先の候補をまとめて表示してもよい。

また、本実施形態では、移動先サーバの評価を実施した後、移動先サーバの候補を表示しているが（ステップ３０９）、移動先サーバの候補を表示するのではなく、保守実施可能であり、移動可能であり、運用への影響もない移動先ブレードが存在する場合には、当該ブレードに自動的に仮想サーバを移動してもよい。

以下、図面を参照しながら本発明を実施するための第２の実施形態について説明する。
本発明の第１実施形態では、通信情報１３６を用いてサーバ移動が運用に与える影響を判定する方法を説明した。本実施形態では、通信モデル１９０２、構成モデル１９０３、運用情報１９０４を用いて通信情報１３６を作成する方法を説明する。本実施形態で説明する通信情報１３６の作成は、システムの構築時、システムの構成変更時、サーバの移動計画の策定時などに実行する。

本実施形態に関わるシステムの構成例を図１９に示す。本システムにおけるブレードシャーシ１００、ブレードシャーシ１１０、外部スイッチ１４０は、第１実施形態と同様である。管理サーバ１２０は、第１実施形態にて説明した保守内容特定部１２１、移動サーバ特定部１２２、移動先候補評価部１２３のプログラムを備える（図１９では、これらをまとめてプログラム群１９０５と記載する）。本実施形態の管理サーバ１２０は、さらに通信情報作成部１９０１のプログラムを備える。また、管理サーバ１２０は、第１実施形態にて説明した保守メニュー１３１、サーバ構成１３２、保守内容１３３、移動計画１３４、移動先候補情報１３５、通信情報１３６、引継ぎ情報１３７のデータを備える（図１９では、これらをまとめてデータ群１９０６と記載する）。本実施形態の管理サーバ１２０は、さらに通信モデル１９０２、構成モデル１９０３、運用情報１９０４のデータを備える。
通信モデル１９０２は、システム運用において、各種運用項目を実現するために行われる通信内容を表すデータである。通信モデル１９０２の例を図２１に示す。通信モデル１９０２はテーブル形式で表現され、各レコードが一つの通信内容を表す。運用項目フィールド２１０１は、実施する運用項目を表す。アクセス元フィールド２１０２は、当該運用項目を実施する際に必要となる通信における当該通信のアクセス元の構成要素を表す。アクセス先フィールド２１０３は、当該運用項目を実施する際に必要となる通信における当該通信のアクセス先の構成用とアクセス方法を表す。アクセス元フィールド２１０２およびアクセス先フィールド２１０３は、構成要素の相対的な位置情報を用いて記述する（記述方法の詳細は後述する）。通信モデル１９０２は、システム運用で使用するハードウェアやソフトウェアの仕様により決まる情報である。そのため、同様のハードウェアやソフトウェアを用いるシステムであれば、共通の通信モデルを利用することができる。

構成モデル１９０３は、システムを構成する各要素の関係を表したデータである。構成モデル１９０３の例を図２２に示す。図２２では構成モデル１９０３をツリー形式で表現しているが、他の形式で表現してもよい。構成モデルの各ノード（２２０１〜２２０７）は、それぞれシステムの構成要素を表し、各ノードを結ぶ線は各構成要素間の包含関係を表す。例えば、構成モデル１９０２において、ブレードシャーシ１００の子ノードとして、ブレードサーバ１８１、１８２、管理モジュール１０１、内部スイッチモジュール１０２が存在する。このことは、ブレードシャーシ１００がこれらの構成要素を含むことを示す。
運用情報１９０４は、対象とするシステムにおいてどのような運用が実施されているかを表す情報である。運用情報１９０４の例を図２３に示す。運用情報１９０４はテーブル形式で表現され、各レコードが一つの運用項目を表す。運用対象フィールド２３０１は、運用の対象である仮想サーバを表す。運用項目フィールド２３０２は、対象とする仮想サーバに対して実施する運用項目を表す。パラメータフィールド２３０３は、運用項目に対する補足情報をパラメータとして記述する。パラメータフィールド２３０３では、「、」で区切ることで複数パラメータを記述することができる。各パラメータは、キーと値を「=」で区切ることで記述する。運用情報１９０４は、個々のシステムにおける具体的な運用内容を含むデータであり、システム毎に異なる。

以下では、図２０に示す処理フローに従い、通信情報作成部１９０１が通信情報１３６の作成処理の詳細を説明する。本処理では、運用情報１９０４に含まれる各レコードに対して、ステップ２００２から２００４の処理を順に実行する。

ステップ２００２において、通信情報作成部１９０１は通信モデル１９０２を参照し、各運用項目において実施する通信内容を取得する。すなわち、通信情報作成部１９０１は処理対象の運用情報１９０４のレコードにおける運用項目フィールド２３０２の値を取得し、通信モデル１９０２のレコードの中から、取得した値が運用項目フィールド２１０１と一致するものを抽出する。例えば、処理対象の運用情報１９０４のレコードの運用項目フィールド２３０２が「クラスタ管理」の場合、通信モデル１９０２のレコードの中から運用項目フィールド２１０１が「クラスタ管理」であるレコード、すなわち#01行目〜#04行目の４レコードが抽出される。

通信モデル１９０２を取得する際、抽出した通信モデル１９０２のレコード内においてパラメータが使用されている場合、パラメータの置換を行う。通信モデル１９０２のアクセス元フィールドおよびアクセス先フィールド２１０３では、パラメータを用いて構成要素を記述することができる。本実施形態では、文字列を「{」と「}」で囲むことで、当該文字列がパラメータであることを表現する。通信モデル１９０２の#01行目のレコードでは、アクセス元フィールド２１０２の「{ACTIVE}」およびアクセス先フィールド２１０３の「{STANDBY}」がパラメータである。前述したように、運用情報１９０４のパラメータフィールド２３０３では、パラメータのキーと値を記述することができる。そこで、処理対象の運用情報１９０４のレコードにおけるパラメータフィールド２３０３を参照してパラメータのキーと値を取得し、抽出した通信モデル１９０２のレコード内のパラメータに対して置換を行う。例えば、運用情報１９０４の#01行目では、パラメータとして「ACTIVE=仮想サーバ１９１」と「STANDBY=仮想サーバ１９５」が記述されているため、通信モデル１９０２の#01行目の「{ACTIVE}」を「仮想サーバ１９１」に、「{STANDBY}」を「仮想サーバ１９５」にそれぞれ置換する。

ステップ２００３において、通信情報作成部１９０１は構成モデル１９０３を参照し、位置情報の解決を行う。すなわち、通信情報作成部１９０１は、ステップ２００２で抽出した通信モデル１９０２のレコード内において、相対的な位置情報が記述されている場合、構成モデル１９０３を参照することで具体的な構成要素を特定する。通信モデル１９０２のアクセス元フィールドおよびアクセス先フィールド２１０３では、相対的な位置情報を用いて構成要素を記述することができる。例えば、通信モデル１９０２の#01行目のアクセス先フィールドで用いられている「..」は、当該構成要素を含む上位の構成要素を表す。また、「/」は構成要素の区切り文字として使用する。以下では、通信モデル１９０２の#01行目のアクセス先フィールドに記載された構成要素である「{STANDBY}/../../管理モジュール」を例に取り、位置情報の解決の詳細を説明する。前述したように、ステップ２００２において「{STANDBY}」は「仮想サーバ１９５」に置換される。そのため、「{STANDBY}/..」は、仮想サーバ１９５を含む上位の構成要素を表す。構成モデル１９０３を参照することで、仮想サーバ１９５を含む上位の構成要素はブレードサーバ１８１であることが特定できる。そのため、位置情報の解決により、「{STANDBY}/..」はブレードサーバ１８１を示すことになる。同様にして、「{STANDBY}/../..」は、ブレードサーバ１８１を含む上位の構成要素であることから、ブレードシャーシ１００１を示す。さらに「{STANDBY}/../../管理モジュール」は、ブレードシャーシ１００１に含まれる管理モジュールであることから、構成モデル１９０３を参照することで管理モジュール１０１であることが特定できる。このようにして、位置情報の解決の結果「{STANDBY}/../../管理モジュール」は「管理モジュール１０１」に置き換えられる。

ステップ２００４では、ステップ２００２およびステップ２００３の結果を用いて、通信情報１３６を作成する。すなわち、通信情報１３６の運用対象フィールド１４０１に、処理対象の運用情報１９０４のレコードにおける運用対象フィールド２３０１の値を格納する。また、通信情報１３６のアクセス先フィールド１４０２に、ステップ２００２にて抽出した通信モデル１９０２のレコードにおけるアクセス先フィールド２１０３の値を格納する。さらに、通信情報１３６のアクセス元フィールド１４０３に、ステップ２００２にて抽出した通信モデル１９０２のレコードにおけるアクセス元フィールド２１０２の値を格納する。アクセス先フィールド１４０２およびアクセス元フィールド１４０３に値を格納する際には、上述したパラメータの置換および相対位置情報の解決を行った後の値を格納する。ステップ２００２において、複数のレコードを抽出した場合は、通信情報１３６に抽出した数と同数のレコードを追加する。

以上、説明した処理により、通信モデル１９０２、構成モデル１９０３、運用情報１９０４を用いて通信情報１３６を作成することができる。

Claims (8)

1. 仮想化されたシステムを構成する複数のサーバに含まれるいずれかのサーバを他のサーバに移動させるためのサーバ移動計画策定支援方法において、
   前記システム運用中に当該システムの構成要素間の通信情報および通信を行う際に通信対象を識別するための識別情報が移動先に引き継がれるかを示す引き継ぎ情報を記憶しておき、
   前記記憶された内容に基づいて、移動前サーバから移動後サーバに移動された場合に、当該移動後サーバへ前記移動前サーバの引継情報が引き継がれるかを判定し、
   当該判定結果により、前記移動後サーバでの通信可否を判断し、
   前記通信可否に基づいて、前記移動に起因する前記システム運用への影響を判定することで、前記移動の可否を判断可能とすることを特徴とするサーバ移動計画策定支援方法。
2. 請求項１に記載のサーバ移動計画策定支援方法において、
   さらに、前記複数のサーバそれぞれにおける構成情報を記憶しておき、
   前記引継情報が引き継がれるかの判定は、前記構成情報が所定の条件を満たすかにより判定することを特徴とするサーバ移動計画策定支援方法。
3. 請求項１または２のいずれかに記載のサーバ移動計画策定支援方法において、
   前記システム運用への影響を出力することを特徴とするサーバ移動計画策定支援方法。
4. 請求項３に記載のサーバ移動計画策定支援方法において、
   前記出力は、前記影響についての判定の結果、前記移動が前記システム運用に影響を与える場合に、前記影響の内容を出力することを特徴とするサーバ移動計画策定支援方法。
5. 仮想化されたシステムを構成する複数のサーバに含まれるいずれかのサーバを他のサーバに移動させるためのサーバ移動計画策定支援方法を実行する管理サーバにおいて、
   前記システム運用中に当該システムの構成要素間の通信情報および通信を行う際に通信対象を識別するための識別情報が移動先に引き継がれるかを示す引き継ぎ情報を記憶する記憶手段と、
   前記記憶された内容に基づいて、移動前サーバから移動後サーバに移動された場合に、当該移動後サーバへ前記移動前サーバの引継情報が引き継がれるかを判定する第１の判定手段と、
   当該判定結果により、前記移動後サーバでの通信可否を判断する判断手段と、
   前記通信可否に基づいて、前記移動に起因する前記システム運用への影響を判定する第２の判定手段とを有し、前記移動の可否を判断可能とすることを特徴とする管理サーバ。
6. 請求項５に記載のサーバ移動計画策定支援方法において、
   前記記憶手段は、さらに、前記複数のサーバそれぞれにおける構成情報を記憶しておき、
   前記第１の判定手段は、前記構成情報が所定の条件を満たすかにより判定することを特徴とする管理サーバ。
7. 請求項５または６のいずれかに記載の管理サーバにおいて、
   前記システム運用への影響を出力する出力手段を更に有することを特徴とする管理サーバ。
8. 請求項４に記載の管理サーバにおいて、
   前記出力手段は、前記判定の結果、前記移動が前記システム運用に影響を与える場合に、前記影響の内容を出力することを特徴とする管理サーバ。

Images