JP2006031350A - 計算機システム、管理装置及びそのプログラム - Google Patents

Abstract

【課題】複数の管理プログラムの情報を統合して、構成の変更によって生じる影響を提供する。
【解決手段】複数のディスク及びディスクアレイ制御部を有するストレージサブシステムと、前記ストレージサブシステムを管理する制御部が設けられた管理装置と、を備える計算機システムであって、前記制御部は、計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、当該イベントに対する管理業務を取得し、当該イベントに対する複数の管理業務の影響範囲を重ね合わせて登録する。
【選択図】 図１

Description

本発明は、複数の管理プログラムが管理業務を自動的に実行する方法に関し、特に構成変更を伴う管理業務の実行に関する。

情報処理装置を利用した業務には、種々の業務が含まれる。例えば、ＳＡＮを利用したストレージ機器を管理するにあたって、それらのストレージ機器に関して、どのような判定対象が、どのような条件を満たしたとき、どのようなアクション（管理業務）を実行するかを規定したポリシーを設定する。そして、ストレージ機器の使用状況に関する情報を収集し、収集した情報に基づいて前記ポリシーの判定対象の値を求め、前記判定対象の値が前記ポリシーの条件を満足するか否かを判定する。この判定で、前記ポリシーの条件を満足するとき、前記ポリシーのアクションを実行する。これによって、ＳＡＮを利用したストレージ機器に対して、その使用状況などを予測し、その予測結果などに基づいて自動的な管理を行う技術が提案されている（例えば、特許文献１参照。）。
特開２００３−３４５６３２号公報

このような管理業務に関し、目的が異なる複数の管理プログラムを組み合わせてシステムの自動運用を行うためには、お互いの管理業務（ジョブ）によって矛盾を生じないように運用することが必要である。しかし、各プログラムが自分の管理範囲しか管理しないため、あるプログラムが持つ管理機能によって他のプログラムが持っている情報に不整合が生じたり、管理対象を正しく管理できなくなる場合がある。

本発明は、同じ構成を管理、参照する複数の管理プログラムが構成変更を含む管理業務を自動実行する際に、複数の管理業務が同時に実行されることによって、構成に矛盾が生じることの抑止を目的とする。

また、ある管理プログラムによって管理される範囲の構成が、他の管理業務によって変更されるなど、管理プログラムの自動実行が継続できなくなった場合、その管理プログラムの実行を停止することによって、管理プログラムとその管理範囲の構成とが矛盾したままの運用の継続を抑制することを目的とする。

本発明は、複数のディスク及びディスクアレイ制御部を有するストレージサブシステムと、前記ストレージサブシステムを管理する制御部が設けられた管理装置と、を備える計算機システムであって、前記制御部は、管理対象の構成を管理マップとして持ち、管理マップによって複数の管理プログラムが同時に一つの構成を参照しないこと、又は変更しないことを保証する。

本発明によると、同一の構成を参照し、又は変更しうる複数の管理プログラムが同時実行されることによって構成に矛盾を生じることを抑止することができる。

また、ある管理プログラムによって管理される範囲の構成が、他の管理業務によって変更されるなど、管理プログラムの自動実行が継続できなくなった場合、その管理プログラムの実行を停止することによって、管理プログラムとその管理範囲の構成とが矛盾したままで運用が続けられることを抑止することができる。

以下、本発明の実施の形態を図面を参照して説明する。

図１は、本発明の実施の形態の計算機システムの構成を示すブロック図である。

本発明の実施の形態の計算機システムは、業務サーバ１、管理サーバ２、バックアップ装置３、ストレージサブシステム５及びこれらを接続するネットワーク４、６によって構成されている。

業務サーバ１は、ＣＰＵ１１、メモリ１２、記憶装置（ディスク）１３、ネットワークインターフェース（ＮＩＣ）１４、ホストバスアダプタ（ＨＢＡ）１５及び入出力装置が備わるコンピュータ装置であり、記憶装置１３に記憶された管理プログラム１〜３がメモリ１２にロードされ、ＣＰＵ１１が管理プログラムを実行して、計算機システムを管理する。

この管理プログラムには、ディスクの使用量を管理し、アプリケーションにディスクを動的に割り当てる容量管理プログラム、アプリケーションが使用しているデータのバックアップやリストアを行うデータ保護プログラム、ストレージサブシステムやＳＡＮ６に設けられたスイッチの動作を管理するデバイス管理プログラムがある。これらの管理プログラムは、それぞれ、管理者によってオンデマンドで実行されたり、管理者が定めたポリシーによって自動実行される。

管理サーバ２は、ＣＰＵ２１、メモリ２２、記憶装置（ディスク）２３、ネットワークインターフェース（ＮＩＣ）２４、ホストバスアダプタ（ＨＢＡ）２５及び入出力装置が備わるコンピュータ装置であり、記憶装置２３に記憶された管理プログラムがメモリ２２にロードされ、ＣＰＵ２１が管理プログラムを実行することによって、計算機システムを管理する。また、管理サーバ２では、ＣＰＵ２１が記憶装置２３に記憶された管理マップ２０２、影響範囲マップ２０３、イベント管理テーブル２０４をメモリに展開し、同じくメモリにロードされたモニタ制御プログラムをＣＰＵが実行することによって、影響範囲マップ２０２の内容が作成される。

これらの業務サーバ１と管理サーバ２とは、同一のハードウェアに配置されてもよいし、別個のハードウェアに配置されてもよい。

バックアップ装置３は、ＣＰＵ３１、メモリ３２、ホストバスアダプタ（ＨＢＡ）３５、テープ装置３７及び入出力装置が備わるコンピュータ装置であり、テープバックアップサーバとして機能する。

バックアップ装置３では、ＣＰＵ３１がプログラムを実行することによって、管理サーバからのバックアップ要求に対応して、ストレージサブシステム５に記憶されたデータをテープにバックアップする。

なお、バックアップ装置３にはテープ装置３７ではなく、光磁気ディスク装置など他のバックアップメディアにバックアップを行う装置を備えていてもよい。

業務サーバ１及び管理サーバ２は、ＬＡＮ４を介して接続されている。ＬＡＮ４は、例えば、ＴＣＰ／ＩＰプロトコルによって、コンピュータ間でデータや制御情報を通信可能であり、例えばイーサネット（登録商標、以下同じ）が用いられる。

ストレージサブシステム５は、ディスクアレイコントローラ及びディスクアレイ５６によって構成されている。ディスクアレイコントローラは、ＣＰＵ５１、メモリ５２及びホストバスアダプタ（ＨＢＡ）５５によって構成されている。ＣＰＵ５１では制御プログラムが動作しており、業務サーバ１からの要求に基づいてディスクアレイ５６に対するデータの入出力を制御する。

また、ディスクアレイ５６にはＲＡＩＤ（Redundant Array of Independent Disks）が構成されており、冗長性を持たせてデータを記憶している。このため、ディスクアレイ５６を構成するディスクドライブの一部に障害が生じても、記憶されたデータが消失しないようになっている。

ストレージサブシステム５は、ＳＡＮ６によって業務サーバ１、管理サーバ２及びバックアップ装置３と接続されている。ＳＡＮ６は、例えばファイバチャネルプロトコルのような、データの転送に適するプロトコルで通信可能なネットワークである。

図２は、本発明の実施の形態のコンピュータシステムのリソースの構成を示すブロック図である。

ストレージサブシステム５は、ＳＡＮ６を介してホストＡ及びホストＢに接続されており、ホストＡ及びホストＢからストレージサブシステム５のディスクドライブにアクセスすることができる。

ホストＡでは、アプリケーション（データベースプログラム）が動作しており、複数のデータベースインスタンスが取り扱われている。また、データベースインスタンスには、各々複数（又は単数でもよい）のファイルシステムがマウントされている。各ファイルシステムは、一つ又は複数の論理ボリュームに関連づけられている。この論理ボリュームはホスト側で認識できるディスクの単位である。各論理ボリュームは、複数（又は単数でもよい）の論理デバイスファイルによって構成されている。また、各論理デバイスは複数又は単数の物理的なディスクドライブによって構成されている。

計算機システムでは、多くのサーバが一つのストレージサブシステムを共有し、アプリケーションに対してはストレージサブシステムの構成を見せたくないことから、通常のＰＣと異なり、このような階層によって計算機システムを管理する。これにより、ＯＳやアプリケーションからは自分が使用するデータがどのように配置されているかを意識する必要がない利点が生じる一方、複数のレイヤを管理しなければストレージが管理できない欠点もある。

図３は、本発明の実施の形態の概念図である。

本発明では、管理プログラムが管理業務を実施する前に、モニタ制御プログラムに対してイベントを発行する。管理プログラムがモニタに発行するイベントは下記の３種類がある。

一つ目は実行要求イベントである。この実行要求イベントは、管理プログラムが管理業務を行おうとする際に発行するイベントである。なお、管理プログラムは、管理業務実行命令を受信するまでは、行おうとしている管理業務を実行できない。モニタ制御プログラムは、実行要求イベントを受信すると、後述するモニタ制御プログラム（図５）によって処理を行う。

二つ目は構成変更イベントである。この構成変更イベントは、管理業務を実行している管理プログラムが構成変更を行う際に発行するイベントである。基本的には、管理業務実行命令を受信した管理プログラムが、構成変更イベントを発行するが、それ以外の管理プログラムが、障害発生時などに発行する場合もある。モニタ制御プログラムは本イベントを受信すると、管理マップ及び影響範囲マップを書き換える。

三つ目は実行終了イベントである。この実行終了イベントは、管理業務を実行している管理プログラムが、その終了を通知する際に発行するイベントである。

管理プログラムは、モニタ制御プログラムから管理業務実行命令を受信した場合のみ、その管理業務を実行することができる。実行許可が返ってこない場合には管理業務を実行できない。

モニタ制御プログラムは、イベントを受信すると、そのイベントに対応するイベント管理テーブルから影響範囲マップを特定し、その影響範囲を管理マップにマッピングする。その後、イベント管理テーブルに基づき、各管理プログラムに管理業務命令を順次送信する。

このように、構成の参照や変更を伴う管理業務を行う場合には、イベント管理テーブルに定義されたイベントを、対象となる管理プログラムに順次配信し、各管理プログラムが処理実行時にモニタ制御プログラムに問い合わせる。そして、自分のオペレーション範囲が他の管理プログラムによるオペレーション中かを確認してからオペレーションを行うことによって、矛盾の少ない自動運用を実現する。

モニタ制御プログラムは、各管理プログラムによって登録された影響範囲を重ね合わせて管理マップに登録する。

図４は、本発明の実施の形態で用いられる管理マップ、影響範囲マップの説明図である。

管理マップ（図４（ａ））には、前述したホストからストレージサブシステム５までの階層のリソース（ＤＢインスタンス、ファイルシステム、論理ボリューム、論理デバイス）が登録されている。

各階層のリソース情報は、コマンドなどを使用して取得する。取得した各階層のリソース情報は、リポジトリに各階層間の関連を維持したまま保持しておく。管理マップ２０２は、リポジトリに蓄積された情報に基づいて作成される。なお、リポジトリは、取得した各階層のリソース情報を格納する領域であり、管理サーバ２の記憶装置２３に配置することも、メモリ２２に配置することも可能である。

モニタ制御プログラムは、管理マップに対し、特定の影響範囲マップのマップ範囲をマッピングしたり、またマッピングした範囲を解除することができる。また、モニタ制御プログラムは管理マップのマッピング範囲を参照して、受信したイベントを実行するか否かを決定する。

影響範囲マップ（図４（ｂ））は、管理マップ上に、イベントによって影響が生じるリソースの範囲をマッピングしたものである。影響範囲マップは、各管理プログラムが、時プログラムのそれぞれの管理業務を行ったときに、どの階層まで影響が及ぶかをパラメータとして保有し、このパラメータを管理マップにマッピングすることによって作成される。あるイベントが発生した際に、その範囲で他の無関係なオペレーションを行うと、お互いの状態に不整合が発生する可能性があるが、影響範囲マップによると、システム構成上、影響が及ぶ範囲を知ることができる。

図５は、本発明の実施の形態のモニタ制御プログラムのフローチャートであり、ＣＰＵ２１によって実行される。

モニタ制御プログラムが動作するＣＰＵ２１は、管理プログラムからイベントを受信すると（Ｓ１０１）、イベント種別に応じた処理を行う。

そのイベントが構成変更イベントであった場合には、その構成変更を管理マップおよび影響範囲マップに反映し（Ｓ１１４）、再び次のイベントの到着を待つ（Ｓ１０１）。

また、そのイベントが実行要求イベントであった場合には、イベント管理テーブルを参照して、当該イベントに対する管理業務を抽出して、当該イベントへの対応方法を決定する（Ｓ１０２）。

そして、抽出された当該イベントに対する管理業務の管理マップへの登録が必要か否かを判定する（Ｓ１０３）。この判定は実行される管理業務によってリソースの構成に影響があるか否かによって判定される。例えば、論理デバイスが追加される場合は管理マップへの登録が必要であり、単に、管理サーバの画面に表示するだけであれば管理マップへの登録は不要である。

この判定の結果、管理マップへの登録が不要であれば、ステップＳ１０６に移行する。一方、管理マップへの登録が必要であれば、影響範囲が重なる他管理業務を実行中か否かを判定する（Ｓ１０４）。そして、影響範囲が重なる他管理業務を実行中であれば、抽出された当該イベントに対する管理業務を実行イベントキューに格納するキューイングを行う（Ｓ１１２）。

その後、影響範囲に構成変更がなければ、実行イベントキューに格納され管理業務を実行し、影響範囲に構成変更があれば、管理プログラムに構成変更があった旨を通知する。イベントキューに格納されたイベントは、実行中のイベント処理が終了した時点で取り出され、その時点で再びステップＳ１０４の判定を実行する。影響範囲に構成変更があれば管理プログラムに構成変更があった旨を通知する。

一方、影響範囲が重なる他管理業務を実行中でなければ、管理マップ２０２の影響範囲を「参照／更新中」にして、管理マップ２０２に影響範囲を登録する（Ｓ１０５）。

以上の処理で管理マップ２０２の更新が終了したので、管理プログラムに対して管理業務実行命令を送信して、イベント管理テーブルに定義された管理業務の実行を開始する（Ｓ１０６）。

また、そのイベントが実行終了イベントであった場合には、イベント管理テーブルに定義された管理業務がまだあるか否かを判定する（Ｓ１０８）。その結果、実行されていない管理業務がイベント管理テーブルに残っていれば、ステップＳ１０６に戻り、管理プログラムに対して管理業務実行命令を発行して、管理業務を継続して実行する。

一方、イベント管理テーブルに定義された全ての管理業務が実行されていれば、管理マップ２０２に「参照／更新中」の登録があるかを確認し（Ｓ１０９）、この登録があれば、「参照／更新中」の登録を管理マップ２０２から削除して、管理マップ２０２から影響範囲の登録を解除する（Ｓ１１０）。

その後、イベントキューが空か否かを確認する（Ｓ１１６）。空であれば、そのまま処理を終了する。空でなければ、本イベントの処理中に構成変更イベントが発生したか否かを確認する（Ｓ１１１）。その結果、構成変更イベントが発生していれば、イベントキューに格納されているイベントを通知した管理プログラムに対し、管理業務の停止を通知し（Ｓ１１３）、処理を終了する。一方、構成変更イベントが発生していなければ、イベントキューからイベントを取り出して実行する（Ｓ１１５）。なお、イベントキューからのイベントの取り出しは、最先にイベントキューに格納されたイベントを取り出す。また、イベントに優先度属性を付し、格納されているイベントの中で最も優先度の高いイベントを取り出してもよい。

図６は、本発明の実施の形態の管理プログラムによる処理のフローチャートであり、ＣＰＵ１１、２１によって実行される。

管理プログラムは、管理業務を開始する前に、モニタ制御プログラム２０１に対して実行要求イベントを発行する（Ｓ１２１）。この結果、管理プログラムはモニタ制御プログラムから発行される管理業務実行命令又は管理業務停止命令のいずれかを受信する。

管理業務停止命令を受信した場合、管理業務停止をユーザに通知する（Ｓ１２４）。

一方、管理業務実行命令を受信した場合、管理プログラムは管理業務を実行する（Ｓ１２２）。管理業務の実行に伴って構成変更が発生するか否かを確認する（Ｓ１２５）。

その結果、構成変更が発生する場合は、モニタ制御プログラムに対して構成変更イベントを送信する（Ｓ１２６）。その後、管理業務が終了したか否かを判定し（Ｓ１２７）、終了していなければステップＳ１２２に戻る。

管理業務が終了した場合、モニタ制御プログラムに対して実行終了イベントを送信する（Ｓ１２３）。

図７は、本発明の実施の形態のイベント管理テーブルの説明図である。

イベント管理テーブルには、実行の契機となる実行要求イベント及びイベント発生元のプログラムと、そのイベントが発生したときに実行される管理業務及び管理業務を実行するプログラムが規定されている。すなわち、イベント管理テーブルは、各管理プログラムが発行する実行要求イベント毎に規定され、ある管理プログラムが実行する管理業務をイベントとして規定し、他管理ソフトウェアも含めて何をどのような順序で行うかを規定したものである。

図７（ａ）には、正副構成を採用するストレージサブシステムの正側（primary側）に論理デバイス（ＬＤＥＶ）が追加されたときに実行される管理業務が規定されている。このイベントが生じると、副側（Secondary側）にも同様の論理デバイスを追加する管理業務１がデバイス管理プログラムによって実行され、正側のＲＡＩＤのペアを組み直す管理業務２が正側のデータ保護プログラムによって実行され、テープバックアップカタログを修正する管理業務３が副側のデータ保護プログラムによって実行される。従って、このイベントによって、正側に追加された論理デバイスだけでなく、当該論理デバイスを使用する論理ボリューム、ファイルシステム及びＤＢインスタンス、さらに正側の組み直されたＲＡＩＤを構成する論理デバイスや、副側の論理デバイスにも影響が生じる。

図７（ｂ）には、正副構成を採用するストレージサブシステムの正側（primary側）の論理デバイス（ＬＤＥＶ）内にディスクドライブが追加されたときに実行される管理業務が規定されている。このイベントが生じると、副側（Secondary側）の論理デバイスにも同様のディスクドライブを追加する管理業務１がデバイス管理プログラムによって実行され、正側のＲＡＩＤのペアを組み直す管理業務２が正側のデータ保護プログラムによって実行される。従って、このイベントによって、正側に追加されたディスクだけでなく、当該ディスクを使用する論理デバイス、論理ボリューム、ファイルシステム及びＤＢインスタンス、さらに正側の組み直されたＲＡＩＤを構成する論理デバイスや、副側の論理デバイスにも影響が生じる。

図７（ｃ）には、正副構成を採用するストレージサブシステムの正側（primary側）の動作が停止したときに副側でフェールオーバするために実行される管理業務が定義されている。このとき、ホストとの間のパスを副側（Secondary側）に切り替える管理業務１がデバイス管理プログラムによって実行され、副側のアプリケーションを起動する管理業務２が副側のデータ保護プログラムで実行される。よって、このイベントによって、正副のストレージサブシステムだけでなく、ホスト（ホストへのパス）にも影響が生じる。

以上、図７（ａ）〜（ｃ）のイベント管理テーブルは、いずれもイベントの発生によって管理マップへの登録が必要な管理業務が規定されているが、イベントの発生によって管理マップへの登録が必要ない管理業務のみが規定される場合もある。

図７（ｄ）には、ストレージサブシステムに新たに論理デバイスが追加されたときに実行される管理業務が定義されている。このとき、新たに追加された論理デバイスはストレージプールに追加され、直ちに使用されない。よって、ストレージサブシステムの運用に影響するリソースの変更は生じず、管理マップへの登録は必要ない。

なお、図７（ｄ）のように直ちに使用されない場合の他、管理サーバの画面に表示するだけの場合にも、管理マップへの登録は必要ない。

ここまで、一つのイベント管理テーブルについて説明したが、一つのイベント管理テーブルで実行される管理業務が他のイベント管理テーブルのイベントとなる場合には、さらに階層的にイベント管理テーブルをたどって、イベントによって影響が生じる範囲を特定する。

なお、本発明の第１の実施の形態では、各管理業務における構成変更の有無を構成変更イベントによって通知するが、モニタ制御プログラムに実行終了イベントを通知する際に、その付帯属性として構成変更があった旨を通知してもよい。

次に本発明の第２の実施の形態について説明する。第２の実施の形態では、前述した第１の実施の形態と異なり、イベント管理テーブルにルールが追加されている（図８）。また、管理マップ２０２にはリソース間の関連が追加されている（図９）。これに伴い影響範囲マップ２０３は使用されない。なお、第１の実施の形態と同じ構成は同じ符号を付し、その説明は省略する。

図８は、本発明の第２の実施の形態のイベント管理テーブルの説明図である。

図８（ａ）は、イベント管理テーブルを示す。前述したように、イベント管理テーブルにはルールの定義が追加されている。。ルールは、イベントが発生した場合に適用されるルールを示す。その他の項目は第１の実施の形態（図７）と同じである。

図８（ｂ）は、ルールテーブルを示す。ルールテーブルは、イベント管理テーブルに定義されているイベント元にイベントが発生した場合に参照され、定義されているルールに従って影響範囲が特定される。例えば、ルール（１）は、関連するもの全てを再帰的にたどり、それをチェックの範囲とするルールが規定されている。すなわち、ルール（１）によると、イベント発生元のリソースに関連する全てのリソースの全てが影響が生じる範囲となる（図９（ｂ））。

一方、ルール（２）は、関連するものをたどるが再帰的には辿らないルールが規定されている。すなわち、ルール（２）によると、イベント発生元のリソースを上方向へたどっていき最上位階層に行き着いたらそこで終了する、また、下方向へたどっていき最下位階層に行き着いたらそこで終了して影響が生じる範囲とする（図９（ｃ））。

図９は、本発明の第２の実施の形態の管理マップ２０２の説明図である。

第２の実施の形態の管理マップ２０２（図９（ａ））には、前述した第１の実施の形態の管理マップ（図４（ａ））と同様に階層化されたリソースが登録されている。また、第２の実施の形態の管理マップ２０２には、各階層のリソース間の関連が登録されている。例えば、管理マップ２０２において、論理ボリュームＡは論理デバイスｄ１、ｄ２及びｄ３によって構成されているので、論理ボリュームＡと論理デバイスｄ１、ｄ２及びｄ３が関連付けられている。

図９（ｂ）には、論理ボリュームＡにイベントが生じたときにルール（１）を適用した場合の管理マップ２０２を示す。論理ボリュームＡ（lvolA）から階層を上下方向に関連をたどっていくと、論理デバイスｄ１〜ｄ３、ファイルシステムＦＳ１〜ＦＳ２及びＤＢインスタンスＡＰ１〜ＡＰ２が論理ボリュームＡの影響範囲であることが分かる。さらに、ＤＢインスタンスＡＰ２が影響範囲に含まれるので、ＡＰ２から下の階層に影響が及ぶ範囲をたどっていくと、ファイルシステムＦＳ３、論理ボリュームlvolB、論理デバイスｄ４〜ｄ５も影響範囲であることが分かる。

図９（ｂ）には、論理ボリュームＡにイベントが生じたときにルール（２）を適用した場合の管理マップ２０２を示す。論理ボリュームＡ（lvolA）から階層を上下方向に関連をたどっていくと、論理デバイスｄ１〜ｄ３、ファイルシステムＦＳ１〜ＦＳ２及びＤＢインスタンスＡＰ１〜ＡＰ２が論理ボリュームＡの影響範囲であることが分かる。ルール（２）の場合は影響が生じるリソースがされに影響を生じるリソースまでは影響範囲に含めないので、ここで、影響範囲の特定は終了する。

本実施例によれば、例えば、lvolAから図８（ａ）に記されている実行要求イベントが発行された場合、モニタ制御プログラムは、ルール（１）を適用する。適用されるルールの種類は、イベントの種類によって一意に定まり、イベントを発行した場所には依存しない。したがって、図８（ａ）に記されている「ＬＤＥＶを追加」というイベントに対しては、常にルール（１）が適用される。

このように第２の実施の形態は、管理マップとイベント種別によってルール化することができるので、イベントが発生する可能性がある箇所ごとにテーブルを定義する必要がない。

本発明の実施の形態の計算機システムのブロック図である。 本発明の実施の形態で対象となるストレージサブシステムの構成の説明図である。 本発明の実施の形態のモニタ制御プログラムの構成の説明図である。 本発明の実施の形態のモニタ制御プログラムが使用するマップの説明図である。 本発明の実施の形態のモニタ制御プログラムのイベント受信時の処理のフローチャートである。 本発明の第１の実施の形態の管理プログラムの管理業務実行時のフローチャートである。 本発明の第１の実施の形態のモニタ制御プログラムが使用するイベント管理テーブルの説明図である。 本発明の第２の実施の形態のモニタ制御プログラムが使用するイベント管理テーブルの説明図である。 本発明の第２の実施の形態のモニタ制御プログラムが使用するマップの説明図である。

符号の説明

１ 業務サーバ
２ 管理サーバ
３ バックアップ装置
４ ＬＡＮ
５ ストレージサブシステム
６ ＳＡＮ
２０２ 管理マップ
２０３ 影響範囲マップ
２０４ イベント管理テーブル

Claims (13)

1. 複数のディスク及びディスクアレイ制御部を有するストレージサブシステムと、前記ストレージサブシステムを管理する制御部が設けられた管理装置と、を備える計算機システムであって、
   前記計算機システムに備わるリソースが登録される管理マップ、前記計算機システムに生じうるイベントに対する管理業務が登録されるイベント管理テーブル、及び、処理待ちのイベントが格納されるイベントキューを有し、
   前記制御部は、
   計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、前記イベント管理テーブルを参照して当該イベントに対する管理業務を取得して、当該イベントへの対応方法を決定し、
   前記取得したイベントの影響範囲の前記管理マップへの登録の要否を判定し、
   当該イベントを前記管理マップへ登録する必要があれば、影響範囲が重なる他のイベントを実行中か否かを判定し、
   影響範囲が重なる他のイベントを実行中であれば、当該イベントを前記実行イベントキューに格納し、
   影響範囲が重なる他のイベントを実行中でなければ、当該イベントに対する影響範囲を重ね合わせて登録した後、管理業務実行命令を発行して当該イベントに対する管理業務を実行させ、
   当該イベントに対する管理業務の実行が終了すると、前記影響範囲の登録を解除する管理装置を備える計算機システム。
2. 複数のディスク及びディスクアレイ制御部を有するストレージサブシステムと、前記ストレージサブシステムを管理する制御部が設けられた管理装置と、を備える計算機システムであって、
   前記制御部は、計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、当該イベントに対する管理業務を取得し、当該イベントに対する影響範囲を重ね合わせて登録する計算機システム。
3. 前記計算機システムに生じうるイベントに対する管理業務が登録されるイベント管理情報を有し、
   前記制御部は、
   計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、前記イベント管理情報を参照して当該イベントに対する管理業務を取得して、当該イベントへの対応方法を決定し、
   当該イベントに対する影響範囲を重ね合わせて登録する請求項２に記載の計算機システム。
4. 実行処理待ちのイベントが格納されるイベントキューを有し、
   前記制御部は、
   前記イベントに対応した管理業務の実行が終了すると、前記影響範囲の登録を解除し、
   前記登録の解除後に、前記イベントキューに格納されている実行待ちの管理業務の要求元に、当該管理業務の実行停止を通知する請求項２に記載の計算機システム。
5. 前記イベント管理情報には、前記イベントに対する影響範囲を特定する方法が登録されており、
   前記制御部は、前記イベント管理情報に登録された影響範囲の特定方法に従って、当該イベントに対する影響範囲を重ね合わせて登録する請求項２に記載の計算機システム。
6. 複数のディスク及びディスクアレイ制御部を有するストレージサブシステムを管理する制御部が設けられた管理装置であって、
   前記制御部は、前記ストレージサブシステムを管理する管理プログラムに生じた実行要求イベントを受信すると、当該イベントに対する管理業務を取得し、当該イベントに対するの影響範囲を重ね合わせて登録する管理装置。
7. 前記計算機システムに生じうるイベントに対する管理業務が登録されるイベント管理情報を有し、
   前記制御部は、
   前記ストレージサブシステムを管理する管理プログラムに生じた実行要求イベントイベントを受信すると、前記イベント管理情報を参照して当該イベントに対する管理業務を取得して、当該イベントへの対応方法を決定し、
   当該イベントに対する影響範囲を重ね合わせて登録する請求項６に記載の管理装置。
8. 前記制御部は、
   実行処理待ちのイベントが格納されるイベントキューを有し、
   前記イベントに対応した管理業務の実行が終了すると、前記影響範囲の登録を解除し、
   前記登録の解除後に、前記イベントキューに格納されている実行待ちの管理業務の要求元に、当該管理業務の実行停止を通知する請求項６に記載の管理装置。
9. 前記イベント管理情報には、前記イベントに対する影響範囲を特定する方法が登録されており、
   前記制御部は、前記イベント管理情報に登録された影響範囲の特定方法に従って、当該イベントに対する影響範囲を重ね合わせて登録する請求項６に記載の管理装置。
10. 複数のディスク及びディスクアレイ制御部を有するストレージサブシステムと、ジョブネットによって前記ストレージサブシステムを管理する制御部が設けられた管理装置と、を備える計算機システム以下の手順を実行させるプログラムであって、
    前記計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、当該イベントに対する管理業務を取得する手順と、
    当該イベントに対する影響範囲を重ね合わせて登録する手順と、を含むプログラム。
11. さらに、前記計算機システムに生じうるイベントに対する管理業務が登録されるイベント管理情報を有する計算機システムに以下の手順を実行させる請求項１０に記載のプログラムであって、
    前記計算機システムを管理する管理プログラムに生じた実行要求イベントを受信すると、前記イベント管理情報を参照して当該イベントに対する管理業務を取得して、当該イベントへの対応方法を決定する手順と、
    当該イベントに対する影響範囲を重ね合わせて登録する手順と、を含むプログラム。
12. さらに、実行待ちの管理業務が格納される実行イベントキューを有する計算機システムに以下の手順を実行させる請求項１０に記載のプログラムであって、
    前記イベントに対応した管理業務の実行が終了すると、前記影響範囲の登録を解除する手順と、
    前記登録の解除後に、前記実行イベントキューに格納されている実行待ちの管理業務の要求元に、当該管理業務の実行停止を通知する手順と、を含むプログラム。
13. さらに、前記イベント管理情報には前記イベントに対する影響範囲を特定する方法が登録されている計算機システムに以下の手順を実行させる請求項１０に記載のプログラムであって、
    前記イベント管理情報に登録された影響範囲の特定方法に従って、当該イベントに対する影響範囲を重ね合わせて登録する手順を含むプログラム。

Images