JP6558037B2 - 運用管理プログラム、運用管理方法、および運用管理装置 - Google Patents

Description

本発明は、運用管理プログラム、運用管理方法、および運用管理装置に関する。

コンピュータシステムの運用では、コンピュータシステム内のサーバに対して、様々な操作が行われる。例えば、サーバ内のデータのバックアップや、サーバに実装されているプログラムのアップデートなどの操作である。システムが大規模になると、運用中に発生するすべての操作（以下、運用操作と呼ぶ）を管理者が手作業で実行するのは困難である。

運用操作を自動で実行するために、例えば運用シナリオが作成される。運用シナリオは、運用操作の実行順を定義した情報である。予め運用シナリオを作成しておくことで、運用シナリオに従って、運用操作を自動で実施することができる。例えば、既知インシデントに対する対応を自動的に行うインシデント管理システムが考えられている。

なお操作対象のサーバに不具合があると、運用シナリオ通りに操作を実行できない場合がある。このような場合に備え、例えば、運用シナリオの実行を中断する中断シナリオを生成する技術が考えられている。

特開２０１３−８１７８号公報 特開２００５−３３２０２５号公報

複数のサーバに適用する運用シナリオを生成する方法としては、例えば個々のサーバに関する運用操作についての運用シナリオを個別に生成する方法が考えられる。この方法では、サーバの増減があるたびに、運用シナリオを個別に生成することになり、仮想マシンを用いることによりサーバの増減が容易となった現在では、管理者への運用シナリオ生成負担が過大となる。

そこで、運用シナリオの生成負担の軽減のために、複数のサーバに関する運用操作を一括して実施する運用シナリオを生成することができる。これにより、生成する運用シナリオ数を削減し、管理者の運用シナリオ生成の負担を軽減できる。

しかし、従来は、複数のサーバに対する運用操作を一括して実施する運用シナリオの実行時に一部のサーバで異常が発生した場合、その異常の影響範囲を判断することができない。そのため、一部のサーバの異常であっても、運用シナリオ全体の実行が停止され、異常に関連しないサーバに対しても運用操作を実行することができなくなる。このように、複数のサーバに対する運用操作を一括して実施する運用シナリオを用いると、一部のサーバの異常で運用シナリオ中のすべての運用操作が中止され、運用操作の実施効率が低下してしまう。

１つの側面では、一部のサーバの異常により運用シナリオ中のすべての運用操作の実行が中止されることを抑止することを目的とする。

１つの案では、以下の処理をコンピュータに実行させる運用管理プログラムが提供される。
運用管理プログラムに基づいて、コンピュータは、複数のサーバに対する複数の運用操作の実行手順を示す運用シナリオと、複数の運用操作それぞれが並列実行するものか否かを示す並列実行情報とを含む運用シナリオ実行情報を取得する。次にコンピュータは、複数のサーバそれぞれが利用可能か否かを示す利用可能情報を取得する。そしてコンピュータは、利用が不可能な利用不可サーバが存在することが利用可能情報に示されているとき、運用シナリオ実行情報に基づいて、並列実行するものとされている運用操作それぞれを運用シナリオの実行時に実行するか否かを示す実行判断情報を生成する。

１態様によれば、一部のサーバの異常により運用シナリオ中のすべての運用操作の実行が中止されることを抑止できる。

第１の実施の形態に係るシステムの構成例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 本実施の形態に用いる管理サーバのハードウェアの一構成例を示す図である。 運用操作機能を示すブロック図である。 サーバ構成情報の一例を示す図である。 プロセス定義の一例を示す図である。 プロセス定義情報の一例を示す図である。 スケジュール情報の一例を示す図である。 プロセス定義の実行制御処理の手順の一例を示すフローチャートである。 代替のプロセス定義の生成処理の手順の一例を示すフローチャートである。 代替のプロセス定義の一例を示す図である。 再実行用のプロセス定義の生成処理の手順の一例を示すフローチャートである。 再実行用のプロセス定義の一例を示す図である。 プロセス定義実行処理の手順の一例を示すフローチャートである。 プロセス定義の一例を示す図である。 異常検知時に実行中のプロセス定義情報の一例を示す図である。 代替のプロセス定義の一例を示す図である。 代替のプロセス定義を示すプロセス定義情報の一例を示す図である。 再実行用のプロセス定義の一例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るシステムの構成例を示す図である。運用管理装置１０は、運用シナリオ２に基づいて、複数のサーバ１ａ〜１ｄに対する運用操作を行う。運用シナリオ２は、サーバ１ａ〜１ｄに対する運用操作の実行手順を定義したものである。なおサーバ１ａ〜１ｄの名称は、それぞれ「サーバＡ」、「サーバＢ」、「サーバＣ」、「サーバＤ」である。運用操作は、複数のサーバ１ａ〜１ｄのデータのバックアップ、ソフトウェアのアップデート、ソフトウェアの動作環境設定などである。運用シナリオ２では、例えば各運用操作がノード２ａ〜２ｈで表される。ノード２ａ〜２ｈには、開始のノード２ａと終了のノード２ｈとが含まれる。実行順の先後関係が、ノード２ａ〜２ｈ間の接続線で表されている。各ノード２ａ〜２ｈには、ノードＩＤが付与されている。図１では、各ノード２ａ〜２ｈの下に、ノードＩＤが示されている。

監視装置３は、サーバ１ａ〜１ｄの状態を監視する。例えば監視装置３は、定期的にサーバ１ａ〜１ｄに所定のコマンドを送信し、その応答の有無に応じて、サーバ１ａが正常に動作しているか否かを確認する。

運用管理装置１０は、記憶部１１と演算部１２とを有する。記憶部１１は、運用シナリオ実行情報１１ａを記憶する。運用シナリオ実行情報１１ａは、運用シナリオ２と、運用シナリオ２内の複数の運用操作それぞれが並列実行するものか否かを示す並列実行情報とを含んでいる。運用シナリオ実行情報１１ａでは、運用シナリオ２が、例えばノード名、対象サーバ、ノードＩＤ、前方ノードＩＤリスト、後方ノードＩＤリストで定義されている。ノード名は、ノードの名称である。対象サーバは、運用操作の対象のサーバの名称である。ノードＩＤは、ノードの識別番号である。前方ノードＩＤリストは、該当ノードの直前に実行する運用操作に対応するノードＩＤのリストである。後方ノードＩＤリストは、該当ノードの直後に実行する運用操作に対応するノードＩＤのリストである。前方ノードＩＤリストと後方ノードＩＤリストとにより、運用操作の実行順が定義されている。並列に実行する運用操作のノードに対しては、並列実行情報が「並列」と設定される。並列に実行しない運用操作のノードに対しては、並列実行情報が「非並列」と設定される。

演算部１２は、運用シナリオ実行情報１１ａに基づいて運用シナリオ２を解釈し、運用シナリオ２に示された手順で、サーバ１ａ〜１ｄに対する運用操作を行う。演算部１２は、運用操作を実行する場合、記憶部１１から運用シナリオ実行情報１１ａを取得する（ステップＳ１）。また演算部１２は、複数のサーバそれぞれが利用可能か否かを示す利用可能情報４を、監視装置３から取得する。

演算部１２は、取得した利用可能情報４に基づいて、利用が不可能なサーバが存在するか否かを判断する。利用が不可能なサーバがある場合、演算部１２は、運用シナリオ実行情報１１ａに基づいて、並列実行するものとされている運用操作それぞれを運用シナリオの実行時に実行するか否かを示す実行判断情報５を生成する（ステップＳ３）。例えば利用が不可能なサーバを操作対象とする第１の運用操作が並列に実行するものである場合がある。この場合、演算部１２は、並列に実行する運用操作のうち第１の運用操作との間に実行順の先後関係を有する第２の運用操作、および第１の運用操作の実行を抑止することを示す実行判断情報５を生成する。

実行判断情報５を生成した演算部１２は、利用が可能な利用可能サーバに対して、実行判断情報５において実行抑止対象とされている運用操作を除外して、運用シナリオ２を実行する（ステップＳ４）。例えば演算部１２は、運用シナリオ２を実行する場合、開始のノード２ａから接続線を終了のノード２ｈ方向へ辿りながら、出現するノードに対応する運用操作を順次実行する。この際、演算部１２は、実行判断情報５において実行を抑止することが示された運用操作については実行しない。

このようなシステムにおいて、運用シナリオ２を実行するときに、サーバ１ｄに障害が発生した場合を考える。サーバ１ｄで障害が発生したことは、監視装置３によって検知される。運用管理装置１０の演算部１２は、運用シナリオ２の実行開始タイミングになると、記憶部１１から運用シナリオ実行情報１１ａを取得すると共に、監視装置３から利用可能情報４を取得する。利用可能情報４には、名称「サーバＤ」のサーバ１ｄが利用不可であることが示されている。

演算部１２は、サーバ１ｄが利用できないため、運用シナリオ実行情報１１ａに基づいて、まずサーバ１ｄを操作対象とするノードを特定する。図１の例では、ノードＩＤ「６」のノード２ｆが、サーバ１ｄに対する運用操作に対応する。演算部１２は、該当するノード２ｆの並列実行情報を確認する。すると、そのノード２ｆが、並列に実行する運用操作に対応することが分かる。そこで、演算部１２は、ノードＩＤ「６」のノード２ｆに対応する運用操作の実行を抑止することを決定する。

また演算部１２は、並列に実行する運用操作に対応するノード２ｃ〜２ｆ（ノードＩＤ「３」〜「６」）のうち、利用不可のサーバ１ｄに対する運用操作との間に実行順の先後関係を有する運用操作に対応するノードを特定する。図１の例では、ノードＩＤ「５」のノード２ｅは、ノード２ｆの前に実行する運用操作に対応する。そこで演算部１２は、ノード２ｅに対応する運用操作の実行を抑止することを決定する。

演算部１２は、最終的に、並列に実行する区間の運用操作のうち、ノードＩＤ「３」，「４」のノード２ｃ，２ｄの運用操作を実行し、ノードＩＤ「５」，「６」のノード２ｅ，２ｆの運用操作の実行を抑止することを示す実行判断情報５を生成する。そして演算部１２は、運用シナリオ２に基づいて、ノード２ｅ，２ｆ以外のノード２ａ〜２ｄ，２ｇ，２ｈに示された運用操作を、利用可能なサーバ１ａ，１ｂに対して実行する。

このようにして、運用シナリオ２において操作対象となっている複数のサーバ１ａ〜１ｄのうち、一部のサーバが利用できない場合であっても、そのサーバの停止が影響しない範囲で、運用シナリオ２を実行できる。その結果、複数のサーバ１ａ〜１ｄに一括して運用操作を行う運用シナリオ２を作成した場合において、一部のサーバに異常が発生しても、運用シナリオ中のすべての運用操作の実行が中止されることを抑止できる。

例えばサーバ１ａ，１ｃのメモリ内のデータを、サーバ１ａ，１ｃそれぞれに対応するサーバ１ｂ，１ｄ内のデータベース（ＤＢ）に格納した後、サーバ１ｂ，１ｄそれぞれのデータのバックアップを取る場合を考える。この場合、サーバ１ｄが故障していても、サーバ１ａ内のデータのサーバ１ｂ内のＤＢへの書き込み、およびサーバ１ｂ内のデータのバックアップは可能である。データのバックアップは、できるかぎり予め指定した日時に実施されることが望ましい。第１の実施の形態のシステムによれば、サーバ１ｄが故障した場合でも、サーバ１ａからサーバ１ｂ内のＤＢへのデータの書き込み、およびサーバ１ｂのデータのバックアップ操作については、定時に実行することができる。

なお、サーバ１ｄが利用できないにも拘わらず、サーバ１ｃへの運用操作を実行してしまうと、その運用操作が正常に終了できないか、誤った処理となる。そのような運用操作を実行してしまうと、誤って実行された処理の修正といった、余分な作業が発生する可能性がある。第１の実施の形態では、運用シナリオ２中でサーバ１ｄに対する運用操作の前に実行することになっている、ノード２ｅの運用操作の実行は抑止される。そのため、不完全な運用操作が実行されることが抑止され、運用操作の信頼性が向上する。

なお、演算部１２は、例えば、並列実行するものとされている運用操作それぞれを運用シナリオの実行時に実行するか否かの判断結果を反映させた代替の運用シナリオを生成してもよい。代替の運用シナリオは、実行判断情報５において実行抑止対象とされている運用操作を、運用シナリオ２から除外したものである。代替の運用シナリオを生成することで、運用シナリオの実行時に、運用操作ごとに実行の要否を判断せずにすみ、使用可能なサーバに対する適切な運用シナリオの実行が容易となる。

また演算部１２は、実行判断情報５において実行対象とされている運用操作を運用シナリオ２から除外した、再実行用の運用シナリオを生成することもできる。図１の例では、運用シナリオ２からノード２ｃ，２ｄの運用操作を除外した再実行用の運用シナリオが生成される。再実行用の運用シナリオを生成することで、例えばサーバ１ｄが障害から復旧した場合に、運用シナリオ２の実行時に実施されなかった運用操作を、最小限のサーバに対して正しく実行することができる。その結果、少ないサーバ資源の利用で、未実行の運用操作を確実に実行することができる。

運用シナリオ２の実行開始時には全サーバ１ａ〜１ｄが利用可能であっても、運用シナリオ２の実行開始後に一部のサーバに障害が発生する場合もあり得る。この場合、演算部１２は、例えば、並列に実行する運用操作の実行が開始されていなければ、代替の運用シナリオを生成する。既に並列に実行する運用操作の実行が開始されていた場合に代替の運用シナリオを生成しないのは、この場合に代替の運用シナリオを生成して実行すると、同じ運用操作を重複して実行することになってしまうためである。すなわち、並列に実行する運用操作の実行が開始されていないことを条件に代替の運用シナリオを生成することで、同じ運用操作が重複して実行されることが抑止される。

なお、演算部１２は、例えば運用管理装置１０が有するプロセッサにより実現することができる。また、記憶部１１は、例えば運用管理装置１０が有するメモリにより実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態では、運用操作の手順がプロセス定義に示される。このプロセス定義は、第１の実施の形態における運用シナリオの一例である。

図２は、第２の実施の形態のシステム構成例を示す図である。ネットワーク２０を介して、複数のサーバ３１〜３３、端末装置４０、監視装置５０、および管理サーバ１００が接続されている。サーバ３１〜３３は、ネットワーク２０を介した情報処理サービスを提供するコンピュータである。端末装置４０は、システムの管理者が使用するコンピュータである。監視装置５０は、サーバ３１〜３３の動作状況を監視するコンピュータである。管理サーバ１００は、サーバ３１〜３３に対する運用操作を実行するコンピュータである。なお、管理サーバ１００は、図１に示した第１の実施の形態における運用管理装置１０の一例である。

図３は、本実施の形態に用いる管理サーバのハードウェアの一構成例を示す図である。管理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、管理サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、管理サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置（ＳＳＤ：Solid State Drive）を使用することもできる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、管理サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。サーバ３１〜３３、端末装置４０、および監視装置５０も、管理サーバ１００と同様のハードウェアで実現できる。また、第１の実施の形態に示した運用管理装置１０も、管理サーバ１００と同様のハードウェアにより実現できる。

管理サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。管理サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、管理サーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また管理サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

図４は、運用操作機能を示すブロック図である。端末装置４０は、プロセス定義生成部４１を有する。プロセス定義生成部４１は、管理者からの操作に応じて、プロセス定義を示すプロセス定義情報を生成する。プロセス定義情報は、複数のサーバに対して運用操作を行う場合の、運用操作の実行順（シナリオ）の定義（プロセス定義）を示す情報である。プロセス定義には、並列に実行する運用操作を含めることができる。そこでプロセス定義情報には、各運用操作が並列に実行するものか否かを識別するための情報が含まれる。なおプロセス定義情報は、図１に示す運用シナリオ実行情報の一例である。プロセス定義生成部４１は、生成したプロセス定義情報を、管理サーバ１００に送信する。

監視装置５０は、監視部５１を有する。監視部５１は、サーバ３１〜３３が正常に動作しているかどうかを監視する。例えば監視部５１は、サーバ３１〜３３に定期的に所定のコマンドを送信し、応答の有無により、サーバ３１〜３３が動作しているかどうかを判断する。監視部５１が、いずれかのサーバが正常に動作していない場合、そのサーバが動作していないことを管理サーバ１００に通知する。

管理サーバ１００は、ＣＭＤＢ（Configuration Management Database）１１０、運用操作情報記憶部１２０、構成情報管理部１３１、プロセス定義制御部１３２、プロセス定義実行部１３３、スケジュール管理部１３４、スケジュール実行部１３５、および運用操作実行部１３６を有する。

ＣＭＤＢ１１０は、サーバ３１〜３３などのネットワーク構成を示す情報を記憶するデータベースである。ＣＭＤＢ１１０には、サーバ構成情報１１１が含まれる。サーバ構成情報１１１は、各サーバ３１〜３３の構成や状態に関する情報である。

運用操作情報記憶部１２０は、運用操作の自動実行に用いられる情報を記憶する。運用操作情報記憶部１２０には、例えば複数のプロセス定義情報１２１、スケジュール情報１２２、および複数の運用操作スクリプト１２３が格納されている。プロセス定義情報１２１としては、プロセス定義生成部４１で生成されたものや、プロセス定義制御部１３２によって自動生成されたものがある。スケジュール情報１２２は、プロセス定義情報１２１の実行スケジュールを示す情報である。運用操作スクリプト１２３は、サーバ３１〜３３に対する運用操作手順が記述されたスクリプトである。

構成情報管理部１３１は、ＣＭＤＢ１１０内のネットワークの構成情報を管理する。例えば構成情報管理部１３１は、監視装置５０から、サーバが正常に動作していないことが通知されると、サーバ構成情報１１１内の該当サーバの状態に関する情報を更新する。

プロセス定義制御部１３２は、プロセス定義情報１２１の生成や登録を制御する。例えばプロセス定義制御部１３２は、端末装置４０から、プロセス定義生成部４１が生成したプロセス定義情報を取得し、運用操作情報記憶部１２０に格納する。またプロセス定義制御部１３２は、スケジュール実行部１３５から、実行時期となったプロセス定義の通知を受け取ると、そのプロセス定義の実行をプロセス定義実行部１３３に指示する。

なお実行時期となったプロセス定義の通知を受け取ったとき、プロセス定義制御部１３２は、そのプロセス定義における運用操作対象のサーバの中に正常に動作していないサーバがあれば、代替のプロセス定義をプロセス定義実行部１３３に実行させることができる。例えばプロセス定義制御部１３２は、ＣＭＤＢ１１０内のサーバ構成情報１１１を参照し、プロセス定義実行部１３３に実行させるプロセス定義において操作対象となるサーバが、正常に動作しているかどうかを判断する。正常に動作していないサーバがある場合、プロセス定義制御部１３２は、該当サーバへの運用操作を含む一部の運用操作を除外した、現在実行可能な代替のプロセス定義が生成可能かどうかを判断する。生成可能であれば、プロセス定義制御部１３２は、代替のプロセス定義を示すプロセス定義情報１２１を生成し、運用操作情報記憶部１２０に格納する。代替のプロセス定義を示すプロセス定義情報１２１を生成した場合、プロセス定義制御部１３２は、プロセス定義実行部１３３に対して、新たに生成したプロセス定義情報１２１に基づく代替のプロセス定義の実行を指示する。

またプロセス定義制御部１３２は、実行しようとしたプロセス定義における運用操作のうち、代替のプロセス定義から除外された運用操作を実行するための、再実行用のプロセス定義を示すプロセス定義情報１２１を生成することもできる。プロセス定義制御部１３２は、再実行用のプロセス定義を示すプロセス定義情報１２１を生成した場合、そのプロセス定義情報１２１を運用操作情報記憶部１２０に格納する。再実行用のプロセス定義は、例えば、管理者からの実行指示が入力されたときに実行される。

プロセス定義実行部１３３は、プロセス定義制御部１３２からの指示に応じ、運用操作情報記憶部１２０に格納されているプロセス定義情報１２１に基づいてプロセス定義を実行する。例えばプロセス定義実行部１３３は、実行対象のプロセス定義に基づいて、運用操作の実行順を判断する。そしてプロセス定義実行部１３３は、プロセス定義に示された順番での運用操作の実行を、運用操作実行部１３６に指示する。

スケジュール管理部１３４は、プロセス定義の実行スケジュールを管理する。例えばスケジュール管理部１３４は、管理者からの入力に応じ、プロセス定義生成部４１で生成されたプロセス定義の実行時期を示すスケジュール情報１２２を生成する。スケジュール管理部１３４は、生成したスケジュール情報１２２を、運用操作情報記憶部１２０に格納する。

スケジュール実行部１３５は、スケジュール情報１２２に従って、プロセス定義の実行時期を管理する。例えばスケジュール実行部１３５は、定期的にスケジュール情報１２２を参照し、実行時期となったプロセス定義がある場合、そのプロセス定義の実行時期であることを、プロセス定義制御部１３２に通知する。

運用操作実行部１３６は、運用操作情報記憶部１２０に格納された運用操作スクリプト１２３に基づいて、サーバ３１〜３３に対する運用操作を実行する。例えば運用操作実行部１３６は、プロセス定義実行部１３３から指定されたサーバに対して、指定された運用操作を実行する。なお実行する運用操作の中には、サーバ３１〜３３に対する運用操作の準備処理も含まれる。例えば運用操作実行部１３６が実行する運用操作には、運用操作対象のサーバが一時的に停止することを示すメッセージの配信も含まれる。

以上のような構成のシステムにより、適切な運用プロセスの実行が可能となる。なお、図４に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図４に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

次に、管理サーバ１００が保持する各種情報について詳細に説明する。
図５は、サーバ構成情報の一例を示す図である。サーバ構成情報１１１には、サーバごとの、サーバ名、ホスト名、およびavailable＿flagが含まれている。サーバ名は、システム上でのサーバの名称である。ホスト名は、サーバのネットワーク上での名称である。Available＿flagは、サーバが正常に動作しているかどうかを示すフラグである。例えば正常に動作しているサーバのavailable＿flagは「ＴＲＵＥ」である。また正常に動作していないサーバのavailable＿flagは、「ＦＡＬＳＥ」である。

Available＿flagは、例えば、監視装置５０の監視部５１によって設定される。また管理サーバ１００の管理者の入力によって、available＿flagを設定することもできる。例えば、管理者は、予定していたスケジュールでサーバのメンテナンスを行うときに、そのサーバのavailable＿flagを「ＦＡＬＳＥ」に設定する。

図６は、プロセス定義の一例を示す図である。プロセス定義６１には、複数のノード６１ａ〜６１ｍ間の関係が定義されている。ノード６１ａ〜６１ｍのうち、開始のノード６１ａは、運用シナリオの開始位置を示している。終了のノード６１ｍは、運用シナリオの終了位置を示している。ノード６１ｂは、並列実行開始を示している。ノード６１ｊは、並列実行終了を示している。ノード６１ｃ〜６１ｋは、サーバに対する運用操作を示している。図６では、各ノード６１ａ〜６１ｍの関係が、ノード間の接続線で示されている。開始のノード６１ａから終了のノード６１ｍに向かって、ノード間の関係を辿ったときに出現する運用操作のノードが、出現した順番に実行される。

図６の例では、複数のサーバ３１〜３３それぞれのデータのバックアップの運用シナリオが、プロセス定義６１に示されている。各サーバのバックアップは並列実行可能であるため、サーバごとの運用操作が並列処理として定義されている。サーバ名「サーバＡ」のサーバ３１に対する運用操作は、ノード６１ｃ〜６１ｅに示されている。サーバ名「サーバＢ」のサーバ３２に対する運用操作は、ノード６１ｆ〜６１ｈに示されている。サーバ名「サーバＣ」のサーバ３３に対する運用操作は、ノード６１ｉ〜６１ｋに示されている。

このようなプロセス定義６１は、運用操作情報記憶部１２０内では、例えばプロセス定義情報１２１として記憶される。
図７は、プロセス定義情報の一例を示す図である。プロセス定義情報１２１ａは、データテーブルで管理できる。プロセス定義情報１２１ａには、プロセス定義を一意に識別するプロセス定義ＩＤが付与されている。プロセス定義情報１２１ａには、ノードごとに、ノード名、対象サーバ、ノードＩＤ、前方ノードＩＤリスト、後方ノードＩＤリスト、並列実行開始ノードＩＤ、並列実行終了ノードＩＤ、および状態の情報が登録されている。

ノード名は、ノードの名称である。対象サーバは、ノードに示される運用操作の対象となるサーバのサーバ名である。なお操作対象のサーバがない場合、対象サーバは「ＮＵＬＬ」となる。ノードＩＤは、プロセス定義情報１２１ａ内でのノードの識別番号である。前方ノードＩＤリストは、対応するノードの運用操作の直前に実行される運用操作を示すノードのノードＩＤである。後方ノードＩＤリストは、対応するノードの運用操作の直後に実行される運用操作を示すノードのノードＩＤである。並列実行開始ノードＩＤは、対応するノードが並列実行区間内にある場合に、その並列実行区間の並列実行開始を示すノードのノードＩＤである。並列実行終了ノードＩＤは、対応するノードが並列実行区間内にある場合に、その並列実行区間の並列実行終了を示すノードのノードＩＤである。状態は、ノードに対応する運用操作の実行状態を示す情報である。ノードの状態には、「実行待ち」、「実行中」、「実行終了」がある。

図８は、スケジュール情報の一例を示す図である。スケジュール情報１２２は、例えばテーブル形式のデータ構造で記憶される。スケジュール情報１２２には、例えばプロセス定義ＩＤに対応付けて、実行開始日時、実行結果が登録される。プロセス定義ＩＤは、実行するプロセス定義の識別情報である。実行開始日時は、対応するプロセス定義を実行する日時である。実行開始日時には、例えば、毎日の実行開始時刻のように、定期的な繰り返し実行日時を設定することもできる。実行開始日時が設定されていないプロセス定義は、管理者から指示があったとき、または生成直後に実行される。例えば代替のプロセス定義であれば、生成直後に実行される。また再実行用のプロセス定義であれば、管理者の指示があったときに実行される。実行されていないプロセス定義には、実行結果として「未実行」が設定される。実行されたプロセス定義には、実行結果として「実行済」が設定される。

以上のような情報を用いて、実行開始時となったプロセス定義を実行することができる。
次に、第２の実施の形態におけるプロセス定義を用いた運用操作について詳細に説明する。

第２の実施の形態では、前提条件として、プロセス定義内の各運用操作に対応するノードの実行の順番に関する依存関係については、各プロセス定義におけるノードの直列／並列関係で解決されているものとする。すなわちノードが直列に接続されている場合、接続順に応じた実行順の制約が存在する。またノードが並列に接続されている場合、実行順の先後関係はない。

また事前準備として、管理者は、プロセス定義生成部４１を用いて、プロセス定義を作成する。このとき管理者は、プロセス定義情報に並列実行開始のノードと並列実行終了のノードとを設定する。さらに管理者は、並列で実行する運用操作に対応するノードに対して並列実行区間の情報（並列実行開始ノードＩＤ、並列実行終了ノードＩＤ）を設定する。並列実行区間の情報が設定されていることで、そのノードに対応する運用操作が、並列に実行するものであることが分かる。また管理者は、プロセス定義情報に、各ノードの前方ノードＩＤリストと後方ノードＩＤリストを設定する。前方ノードＩＤリストと後方ノードＩＤリストとにより、ノード間の依存関係が定義される。

以上の前提条件と事前準備により、利用できないサーバが存在する場合、プロセス定義から除外可能なノードを適切に識別可能となる。そして、除外可能なノードを除外した代替のプロセス定義を実行することで、利用不可サーバへの操作を避けて運用操作を実行することができる。

また、管理サーバ１００は、ノード情報に保存した並列実行区間の情報と、代替のプロセス定義生成時に除外したノード情報に基づき、冗長性を排除した再実行用のプロセス定義を生成し、実行待ち状態とすることもできる。生成した再実行用のプロセス定義を実行することで、システム復旧時、最低限のサーバのみを操作する運用操作が可能となる。

以下、プロセス定義を用いた運用操作処理手順を、フローチャートを参照して説明する。
図９は、プロセス定義の実行制御処理の手順の一例を示すフローチャートである。

［ステップＳ１０１］プロセス定義制御部１３２は、プロセス定義の実行開始時になると、そのプロセス定義における操作対象サーバのサーバ名を取得する。例えばプロセス定義制御部１３２は、スケジュール実行部１３５からプロセス定義ＩＤを指定した、プロセス定義の実行時期になったことの通知を受けると、指定されたプロセス定義ＩＤに対応するプロセス定義を、運用操作情報記憶部１２０から取得する。そしてプロセス定義制御部１３２は、取得したプロセス定義から、各ノードの対象サーバのサーバ名を抽出する。

［ステップＳ１０２］プロセス定義制御部１３２は、操作対象サーバの利用状況情報を取得する。例えばプロセス定義制御部１３２は、ＣＭＤＢ１１０内のサーバ構成情報１１１を参照し、実行開始するプロセス定義の操作対象サーバの利用状況情報として、available＿flagを抽出する。

［ステップＳ１０３］プロセス定義制御部１３２は、操作対象サーバが、すべて利用可能か否かを判断する。例えばプロセス定義制御部１３２は、すべてのサーバのavailable＿flagが「ＴＲＵＥ」であれば、すべてのサーバが利用可能であると判断する。またプロセス定義制御部１３２は、available＿flagが「ＦＡＬＳＥ」のサーバが少なくとも１つでもあれば、利用不可能なサーバがあると判断する。

このようにして、並列実行する運用操作を含むプロセス定義を実行する前に、操作対象のサーバ３１〜３３のうち、利用不可能なサーバが存在するか否かが確認される。すべてのサーバが利用可能な場合、処理がステップＳ１０４に進められる。利用不可能なサーバがある場合、処理がステップＳ１０５に進められる。

［ステップＳ１０４］プロセス定義制御部１３２は、実行開始時になったプロセス定義の実行を、プロセス定義実行部１３３に指示する。すると、プロセス定義実行部１３３は、実行するプロセス定義を運用操作情報記憶部１２０から取得し、開始のノードから順にノードの接続関係を辿り、出現したノードから順に、そのノードに対応する運用操作の実行を、運用操作実行部１３６に指示する。運用操作実行部１３６は、実行を指示された運用操作の運用操作スクリプトを運用操作情報記憶部１２０から取得する。そして運用操作実行部１３６は、取得した運用操作スクリプトに従って、操作対象のサーバに対する運用操作を実行する。その後、プロセス定義の実行処理が終了する。

なおプロセス定義の実行を指示した後、プロセス定義に応じた運用操作の完了前に、サーバの異常が検知された場合、プロセス定義制御部１３２は、プロセス定義の実行を中止させ、代替のプロセス定義を生成する。そして代替のプロセス定義による運用操作の実行を指示する。このような、プロセス定義の実行指示後のサーバ異常検知に応じた対処を含む処理については、後述する（図１４参照）。

［ステップＳ１０５］実行不可能な操作対象のサーバがある場合、プロセス定義制御部１３２は、代替のプロセス定義を生成する。代替のプロセス定義の生成処理の詳細は後述する（図１０参照）。なお、並列実行区間以外のノードの操作対象サーバが使用不可能な場合、代替のプロセス定義は生成されない。

［ステップＳ１０６］プロセス定義制御部１３２は、再実行用のプロセス定義を生成する。再実行用のプロセス定義の生成処理の詳細は後述する（図１２参照）。
［ステップＳ１０７］プロセス定義制御部１３２は、代替のプロセス定義が生成されたか否かを判断する。代替のプロセス定義が生成された場合、処理がステップＳ１０８に進められる。代替のプロセス定義が生成されていなければ、処理が終了する。

［ステップＳ１０８］プロセス定義制御部１３２は、代替のプロセス定義の実行指示を、プロセス定義実行部１３３に出す。するとプロセス定義実行部１３３が、運用操作実行部１３６と連携し、代替のプロセス定義を実行する。

このようにして、実行時期となったプロセス定義、またはそのプロセス定義から生成された代替のプロセス定義が実行される。
次に、代替のプロセス定義の生成処理について詳細に説明する。

図１０は、代替のプロセス定義の生成処理の手順の一例を示すフローチャートである。
［ステップＳ１１１］プロセス定義制御部１３２は、実施開始時となったプロセス定義内のノードのうち、利用不可能なサーバへ運用操作を行うノードを、除外候補ノードに設定する。

［ステップＳ１１２］プロセス定義制御部１３２は、すべての除外候補ノードが、並列実行区間内にあるか否かを判断する。例えばプロセス定義制御部１３２は、プロセス定義情報１２１ａ（図７参照）を参照し、各除外候補ノードに対して、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されているか否かを判断する。並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されている除外候補ノードは、並列実行区間内のノードと判断される。すべての除外候補ノードが並列実行区間内の場合、処理がステップＳ１１３に進められる。少なくとも１つの除外候補ノードが並列実行区間外の場合、代替のプロセス定義は生成できないものと判断され、代替のプロセス定義生成処理が終了する。

［ステップＳ１１３］プロセス定義制御部１３２は、未選択の除外候補ノードから、除外候補ノードを１つ選択する。
［ステップＳ１１４］プロセス定義制御部１３２は、選択した除外候補ノードを通る並列実行区間内のすべてのノードを、除外ノードとして登録する。例えばプロセス定義制御部１３２は、選択した除外候補ノードを、除外ノードとする。次に、プロセス定義制御部１３２は、プロセス定義情報１２１ａ（図７参照）において、選択した除外候補ノードから順に、前方ノードＩＤリストで示されているノードを、並列実行開始ノードに達するまで辿る。そしてプロセス定義制御部１３２は、選択した除外候補ノードと並列実行開始ノードとの間にある各ノードを、除外ノードとする。同様にプロセス定義制御部１３２は、プロセス定義情報１２１ａ（図７参照）において、選択した除外候補ノードから順に、後方ノードＩＤリストで示されているノードを、並列実行終了ノードに達するまで辿る。そしてプロセス定義制御部１３２は、選択した除外候補ノードと並列実行終了ノードとの間にある各ノードを、除外ノードとする。

［ステップＳ１１５］プロセス定義制御部１３２は、すべての除外候補ノードを選択したか否かを判断する。すべての除外候補ノードが選択済みであれば、処理がステップＳ１１６に進められる。未選択の除外候補ノードが存在すれば、処理がステップＳ１１３に進められる。

［ステップＳ１１６］プロセス定義制御部１３２は、実行開始時となったプロセス定義から除外ノードを削除した代替のプロセス定義を生成する。プロセス定義制御部１３２は、生成した代替のプロセス定義を、運用操作情報記憶部１２０に格納する。

このようにして代替のプロセス定義が生成される。図１０に示すように、すべての除外候補ノードについて並列実行区間内に存在するかが確認され、少なくとも一部の除外候補ノードが、並列実行区間以外（直列区間）に存在する場合は、除外不可能と判断され、代替のプロセス定義は生成されない。すると、元のプロセス定義も代替のプロセス定義も実行されずに処理が終了する。すべての除外候補ノードが、並列実行区間内に存在する場合、その除外候補ノードを除外可能と判断され、利用不可のサーバへの運用操作ノードを含む並列実行区間内の全ノードを除外した、代替のプロセス定義が生成され、実行される。

図１１は、代替のプロセス定義の一例を示す図である。図１１の例は、図６に示したプロセス定義６１を実行しようとしたときに、サーバ名「サーバＣ」のサーバ３３が利用不可能であることにより生成された代替のプロセス定義６１−１である。代替のプロセス定義６１−１では、元のプロセス定義６１から、３つのノード６１ｉ〜６１ｋが削除されている。

このように、利用不可能なサーバの運用操作に関するノードを含む並列実行区間内のノードをすべて削除することで、利用可能なサーバに対する運用操作を適切に実行することができる。すなわち、図１１の例では、サーバ名「サーバＣ」のサーバ３３が利用できなくても、他のサーバ３１，３２に対しては、バックアップの運用操作を実行できる。

次に、再実行用のプロセス定義の生成処理について詳細に説明する。
図１２は、再実行用のプロセス定義の生成処理の手順の一例を示すフローチャートである。

［ステップＳ１２１］プロセス定義制御部１３２は、実施開始時となったプロセス定義内のノードのうち、利用可能なサーバへの運用操作を行うノードを、除外候補ノードに設定する。

［ステップＳ１２２］プロセス定義制御部１３２は、未選択の除外候補ノードから、除外候補ノードを１つ選択する。
［ステップＳ１２３］プロセス定義制御部１３２は、選択した除外候補ノードが、並列実行区間内にあるか否かを判断する。並列実行区間内か否かは、例えばプロセス定義情報１２１ａ（図７参照）において、除外候補ノードに対して、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されているか否かで判断できる。並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されていれば、除外候補ノードは並列実行区間内にある。選択した除外候補ノードが並列実行区間内にある場合、処理がステップＳ１２４に進められる。選択した除外候補ノードが並列実行区間外にある場合、処理がステップＳ１２５に進められる。

［ステップＳ１２４］プロセス定義制御部１３２は、選択した除外候補ノードを除外ノードとして登録する。
［ステップＳ１２５］プロセス定義制御部１３２は、すべての除外候補ノードを選択したか否かを判断する。すべての除外候補ノードが選択済みであれば、処理がステップＳ１２６に進められる。未選択の除外候補ノードが存在すれば、処理がステップＳ１２２に進められる。

［ステップＳ１２６］プロセス定義制御部１３２は、選択した除外候補ノードを通る並列実行区間内の他のすべてのノードを、除外ノードとして登録する。
［ステップＳ１２７］プロセス定義制御部１３２は、実行開始時となったプロセス定義から除外ノードを削除した再実行用のプロセス定義を生成する。プロセス定義制御部１３２は、生成した代替のプロセス定義を、運用操作情報記憶部１２０に格納する。

このようにして再実行用のプロセス定義が生成される。
図１３は、再実行用のプロセス定義の一例を示す図である。図１１の例は、図６に示したプロセス定義６１を実行しようとしたときに、サーバ名「サーバＣ」のサーバ３３が利用不可能であることにより生成された再実行用のプロセス定義６１−２である。再実行用のプロセス定義６１−２では、元のプロセス定義６１から、６つのノード６１ｃ〜６１ｈが削除されている。

このように、プロセス定義６１から代替のプロセス定義６１−１により運用操作が実行された並列実行区間内のノードを削除することで、現在は利用不可能なサーバに対して、後で運用操作を適切に実行する再実行用のプロセス定義６１−２を生成できる。図１３の例では、代替のプロセス定義６１−１により既に運用操作が実行されたサーバ３１，３２を除外して、サーバ３３に対してのみバックアップの運用操作を実行できる。

ところで、プロセス定義に応じた運用操作の実行途中で、サーバの異常が検知される場合もある。そのような場合、現在実行しているプロセス定義の実行を中止して、代替のプロセス定義が実行される。

図１４は、プロセス定義実行処理の手順の一例を示すフローチャートである。
［ステップＳ１３１］プロセス定義制御部１３２は、プロセス定義実行部１３３に対してプロセス定義の実行を指示する。この指示に応じて、プロセス定義実行部１３３と運用操作実行部１３６が連携して、プロセス定義に従った運用操作を実行する。

［ステップＳ１３２］プロセス定義制御部１３２は、サーバの異常が検知されたか否かを判断する。例えば、プロセス定義制御部１３２は、サーバ構成情報１１１を参照し、実行中のプロセス定義の対象サーバに含まれるサーバのavailable＿flagを確認する。Available＿flagが「ＦＡＬＳＥ」となっているサーバがある場合、サーバの異常が検知されたと判断される。サーバの異常が検知された場合、処理がステップＳ１３３に進められる。サーバの異常が検知されていなければ、処理がステップＳ１３８に進められる。

［ステップＳ１３３］プロセス定義制御部１３２は、並列実行区間内のノードを実行中、または次に実行するノードが並列実行区間内に存在するか否かを判断する。例えばプロセス定義制御部１３２は、現在実行中のプロセス定義を参照し、各ノードの状態を確認する。状態が「実行中」のノードが、現在実行中のノードである。実行中のノードに対して、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されていれば、並列実行区間内のノードを実行中であることが分かる。また実行中のノードの後方ノードＩＤリストを参照することで、次に実行するノードが特定できる。次に実行するノードに対して、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されていれば、そのノードは、並列実行区間内に存在することが分かる。

実行中のノードが並列実行区間内のノードであるか、もしくは次に実行するノードが並列実行区間内にある場合、代替プロセスの生成などをせずに、現在実行中のプロセス定義をそのまま実行させ、処理が終了する。実行中のノードが並列実行区間内の場合は、異常が発生したサーバを操作対象とするノードを含む並列実行区間に対しても既に運用操作が実行されている。そのため、実行中のプロセス定義を、その並列実行区間を除外した代替のプロセス定義に置き換える意義がない。そのため、代替のプロセス定義の生成は行わずに、現行のプロセス定義が継続実行される。また、次に実行するノードが並列実行区間内にある場合、すでに並列分岐が完了済みである可能性がある。そのため、プロセス定義制御部１３２は、次に実行するノードが並列実行区間内にある場合も、並列実行区間内のノードを実行中の場合と同様に、代替のプロセス定義の生成を行わない。すなわち、実行しているプロセス定義が継続実行され、使用不可のノードに対する運用操作のノードにおいて、操作が失敗する。

実行中のノードが並列実行区間内のノードではなく、次に実行するノードも並列実行区間内ではない場合、使用不可のサーバへの運用操作実行を回避できる可能性があるため、処理がステップＳ１３４に進められ、代替のプロセス定義が生成される。

［ステップＳ１３４］プロセス定義制御部１３２は、現在実行しているプロセス定義の実行の中止を、プロセス定義実行部１３３に指示する。指示を受けたプロセス定義実行部１３３は、現在の運用操作を実行中のノードより後のノードの運用操作の実行の指示を抑止する。

［ステップＳ１３５］プロセス定義制御部１３２は、代替のプロセス定義を生成する。代替のプロセス定義の生成処理の詳細は、図１０に示した通りである。なお、生成される代替のプロセス定義では、生成元となったプロセス定義における状態（実行待ちか否か）の情報も引き継がれる。なお代替のプロセス定義の生成処理における除外候補ノードの設定（図１０のステップＳ１１１）では、「実行中」および「実行済み」のノードについては、除外候補の対象外と判断され、「実行待ち」のノードから除外候補ノードが選択される。

［ステップＳ１３６］プロセス定義制御部１３２は、再実行用のプロセス定義を生成する。再実行用のプロセス定義の生成処理の詳細は、図１２に示した通りである。
［ステップＳ１３７］プロセス定義制御部１３２は、代替のプロセス定義の実行待ちの最も実施順が早いノードからの実行を、プロセス定義実行部１３３に指示する。指示に応じて、プロセス定義実行部１３３により、代替のプロセス定義のうち、実行待ちの最も実施順が早いノードがからプロセス定義の実行が開始される。その後、プロセス定義実行処理が終了する。

［ステップＳ１３８］プロセス定義制御部１３２は、プロセス定義の実行が完了したか否かを判断する。プロセス定義の実行が完了した場合、プロセス定義実行処理が終了する。完了していなければ、処理がステップＳ１３２に進められる。

このようにして、プロセス定義の実行開始後にサーバの異常が検出された場合でも、代替のプロセス定義を生成することができる。すなわち、複数のサーバに対し運用操作を並列実行するプロセス定義を実行開始後に、利用不可なサーバが検知されると、そのサーバを操作するノードのうち、「実行待ち」のノードが除外候補ノードとされる。そして、除外候補ノードが並列実行区間内にあれば、その除外候補ノードを実行しない代替のプロセス定義が生成され、実行される。なお、除外候補ノードの除外が並列実行区間外の場合、実行中のノード終了後、プロセス定義の実行を中止される。

以下、プロセス定義実行中にサーバの異常が検知された場合の、代替のプロセス定義の生成例について説明する。
図１５は、プロセス定義の一例を示す図である。図１５に示すプロセス定義６２は、図６に示すプロセス定義６１内のノード６１ａ〜６１ｍと同様のノード６２ａ〜６２ｍを有しており、開始を示すノード６２ａと並列実行開始を示すノード６２ｂとの間にノード６２ｎが設けられている。ノード６２ｎは、サーバ３１〜３３のデータのバックアップを実行する前に、管理者へ、バックアップの実行を通知する電子メールを送信する運用操作を示している。

このようなプロセス定義６２の実行が開始され、ノード６２ｎに対応する運用操作の実行中に、サーバ名「サーバＣ」のサーバ３３に異常が発生したものとする。この場合、監視装置５０の監視部５１により異常が検知され、異常の発生が管理サーバ１００に通知される。すると管理サーバ１００の構成情報管理部１３１により、サーバ構成情報１１１が更新される。例えば図５に示したサーバ構成情報１１１と同様に、「サーバＣ」のavailable＿flagが「ＦＡＬＳＥ」に変更される。

プロセス定義制御部１３２は、サーバ構成情報１１１を参照し、「サーバＣ」が利用不可になったことを認識する。そしてプロセス定義制御部１３２は、現在実行中のプロセス定義６２に基づいて、代替のプロセス定義を生成する。

図１６は、異常検知時に実行中のプロセス定義情報の一例を示す図である。プロセス定義情報１２１ｂは、例えばテーブル形式のデータ構造を有している。図１６の例では、ノードＩＤ「１」のノードの状態は「実行済み」であり、ノードＩＤ「２」のノードの状態は「実行中」であり、ノードＩＤ「３」〜「１４」の各ノードの状態は「実行待ち」である。

このような状態で、「サーバＣ」の異常が検知されると、まず、現在実行中のノードが並列実行区間内のノードではなく、次に実行するノードも並列実行区間内のノードではないことが確認される。図１６の例では、実行中のノード（ノードＩＤ「２」）には、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されておらず、実行中のノードは並列実行区間内のノードではない。また実行中のノードの後方ノードＩＤリストには、ノードＩＤ「３」が設定されており、ノードＩＤ「３」のノードが次に実行するノードである。次に実行するノードにも、並列実行開始ノードＩＤと並列実行終了ノードＩＤとが設定されていない。従って、次に実行するノードも、並列実行区間内のノードではない。従って、代替のプロセス定義が生成される。

代替のプロセス定義の生成では、プロセス定義情報１２１ｂに示されるノードのうち、使用不可のサーバを対象サーバとするノード、およびそのノードと同じ並列実行区間内のノードが、除外候補ノードに設定される。除外候補ノードの状態が「実行待ち」であれば、その除外候補ノードが削除される。図１６の例では、ノードＩＤ「１０」〜「１２」の各ノードが削除される。この際、各ノードの前方ノードＩＤリストおよび後方ノードＩＤリストから、削除したノードのノードＩＤが削除される。

このようにして、代替のプロセス定義が生成される。
図１７は、代替のプロセス定義の一例を示す図である。代替のプロセス定義６２−１では、図１５に示したプロセス定義６２から、ノード６２ｉ〜６２ｋが削除されている。

図１８は、代替のプロセス定義を示すプロセス定義情報の一例を示す図である。図１８に示すように、代替のプロセス定義を示すプロセス定義情報１２１ｃでは、生成元のプロセス定義情報１２１ｂに設定されていた状態が引き継がれる。プロセス定義情報１２１ｃに基づいて代替のプロセス定義６２−１を実行する際には、実行中のノードの状態が「実行済み」となった後、そのノードの次のノード（後方ノードＩＤリストに登録されたノード）から順に、運用操作が実行される。図１８の例では、ノードＩＤ「２」のノードの状態が「実行済み」になると、ノードＩＤ「３」のノードの運用操作が行われる。以後、代替のプロセス定義６２−１に示された順番で、実行待ちの各ノードの運用操作が実行される。

代替のプロセス定義６２−１が生成された場合、再実行用のプロセス定義も生成される。
図１９は、再実行用のプロセス定義の一例を示す図である。再実行用のプロセス定義６２−２では、図１５に示したプロセス定義６２から、ノード６２ｃ〜６２ｈが削除されている。

このようにして、プロセス定義の実行中であっても、サーバの異常が検知された場合、そのサーバを操作対象とするノードを含む並列実行区間を除外した代替のプロセス定義６２−１が生成される。そして、代替のプロセス定義６２−１を用いて運用操作を続行することができる。しかも代替のプロセス定義６２−１において除外された並列実行区間については、異常が検知されたサーバが利用可能となった後に、再実行用のプロセス定義６２−２を用いて、運用操作を実行することができる。

以上説明したように、第２の実施の形態によれば、複数のサーバに対し運用操作を並列実行する運用において、操作対象の一部のサーバが利用不可である際、利用不可サーバへの操作を避け、運用操作を行うことが可能となる。その結果、一部のサーバに異常があっても、複数のサーバを操作対処とするプロセス定義全体の実行を停止せずにすみ、運用操作の実行効率が向上する。しかも、異常時運用に備えて単体サーバ向けの多数のプロセス定義を準備することをせずにすみ、管理者の負担が減る。また、サーバ台数が増加しても、生成するプロセス定義の数を抑止できるため、利用するシステムの資源量が削減され、保守性が向上する。

さらに、運用操作の再実行時に、最低限のマシンへのみ運用操作を自動実行できることで、再実行時に占有するマシン数が減る。その結果、使用するマシンリソースが減り、運用操作を効率的に実行できる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ａ〜１ｄ サーバ
２ 運用シナリオ
３ 監視装置
４ 利用可能情報
５ 実行判断情報
１０ 運用管理装置
１１ 記憶部
１１ａ 運用シナリオ実行情報
１２ 演算部

Claims (6)

1. コンピュータに、
   複数のサーバに対する複数の運用操作の実行手順を示す運用シナリオと、前記複数の運用操作それぞれが並列実行するものか否かを示す並列実行情報とを含む運用シナリオ実行情報を取得し、
   前記複数のサーバそれぞれが利用可能か否かを示す利用可能情報を取得し、
   利用が不可能な利用不可サーバが存在することが前記利用可能情報に示されており、前記利用不可サーバを操作対象とする第１の運用操作が並列に実行するものであることが前記並列実行情報に示されているとき、前記運用シナリオ実行情報に基づいて、並列実行するものとされている運用操作のうちの前記第１の運用操作および前記第１の運用操作との間に実行順の先後関係を有する第２の運用操作を前記運用シナリオから除外した代替の運用シナリオを生成する、
   処理を実行させる運用管理プログラム。
2. 前記コンピュータに、さらに、
   前記代替の運用シナリオに従った運用操作を実行する、
   処理を実行させる請求項１記載の運用管理プログラム。
3. 前記コンピュータに、さらに、
   並列実行するものとされている運用操作のうちの前記代替の運用シナリオに含まれる運用操作を前記運用シナリオから除外した再実行用の運用シナリオを生成する、
   処理を実行させる請求項１または２記載の運用管理プログラム。
4. 前記代替の運用シナリオの生成では、前記運用シナリオに従った運用操作の実行が開始された後に前記利用可能情報が更新され、前記利用不可サーバが存在することを検知した場合、並列に実行する運用操作の実行が開始されていなければ、前記代替の運用シナリオを生成する、
   請求項１ないし３のいずれか１つに記載の運用管理プログラム。
5. コンピュータが、
   複数のサーバに対する複数の運用操作の実行手順を示す運用シナリオと、前記複数の運用操作それぞれが並列実行するものか否かを示す並列実行情報とを含む運用シナリオ実行情報を取得し、
   前記複数のサーバそれぞれが利用可能か否かを示す利用可能情報を取得し、
   利用が不可能な利用不可サーバが存在することが前記利用可能情報に示されており、前記利用不可サーバを操作対象とする第１の運用操作が並列に実行するものであることが前記並列実行情報に示されているとき、前記運用シナリオ実行情報に基づいて、並列実行するものとされている運用操作のうちの前記第１の運用操作および前記第１の運用操作との間に実行順の先後関係を有する第２の運用操作を前記運用シナリオから除外した代替の運用シナリオを生成する、
   運用管理方法。
6. 複数のサーバに対する複数の運用操作の実行手順を示す運用シナリオと、前記複数の運用操作それぞれが並列実行するものか否かを示す並列実行情報とを含む運用シナリオ実行情報を記憶する記憶部と、
   前記複数のサーバそれぞれが利用可能か否かを示す利用可能情報を取得し、利用が不可能な利用不可サーバが存在することが前記利用可能情報に示されており、前記利用不可サーバを操作対象とする第１の運用操作が並列に実行するものであることが前記並列実行情報に示されているとき、前記運用シナリオ実行情報に基づいて、並列実行するものとされている運用操作のうちの前記第１の運用操作および前記第１の運用操作との間に実行順の先後関係を有する第２の運用操作を前記運用シナリオから除外した代替の運用シナリオを生成する演算部と、
   を有する運用管理装置。

Images