JP2010256942A - ストレージの操作権限管理を含む計算機システム - Google Patents

Abstract

【課題】
ストレージに対する設定・操作の安全性を高め、計算機システム内で実行される業務の運用状態の多様な変化に対応する、より最適化されたアクセス制御方式を提供する。
【解決手段】
ストレージに対する操作指示の発行が必要となった時に、業務の運用状態および業務の運用状態別の操作権限定義に基づきストレージに対する操作可否を決定する。
【選択図】 図１

Description

本発明は、計算機およびストレージで構成される計算機システムにおける、前記ストレージに対する操作権限管理に関する。

大型のストレージはストレージサブシステムとも呼ばれ、高速・大容量なデータ保管を可能とするだけでなく、高度なデータ管理機能を有する。ストレージ内にはハードディスクドライブなどの物理的なストレージ部品が複数搭載され、それらのストレージ部品内の記憶領域を適宜再配分することで、論理的な記憶領域である論理ボリュームを構成する。ホスト計算機から利用できるのはこの論理ボリューム単位が基本となっており、同論理ボリュームに対して業務処理で使用するデータなどを保管できる。また、ストレージが提供する付加価値機能、たとえばホスト計算機を介在しないデータのコピー処理も、主にこの論理ボリュームを単位として行われる。

論理ボリュームを割り当て、運用していくためには、ストレージの管理者がストレージに対して様々な設定を行ったり、動作状態の変更などの操作をしたりすることが必要となる。ところが、それらの設定・操作は状況に応じて適宜制限を加えなければ、ホストから論理ボリュームに対してアクセスできなくなったり、必要なデータが失われたりするなどの不具合が発生する。

本発明はこのような不具合を防ぐための、ストレージに対する設定・操作時のアクセス制御方法に関する。同制御方法についての公知技術として、特許文献１記載の技術がある。

特開２００６−７９１９４号公報

本発明が解決しようとする課題は、ストレージに対する設定・操作の安全性を高めるため、より良い設定・操作制限手段を提供することである。特許文献１には、ストレージを管理するための計算機である管理サーバ内に、ストレージの運用スケジュールを登録しておき、その運用スケジュールに応じてストレージに対するアクセス権限情報をストレージとストレージを利用する計算機であるサーバに配布することで、アクセス制限を行う技術が開示されている。

しかし、運用スケジュールに登録される内容はストレージの運用に関するものであるため、ストレージ側の状況に応じたアクセス制限しか行えないという課題がある。

また、事前に登録済みの運用スケジュールに沿った形でしかアクセス制限をかけられないという課題がある。たとえば障害発生など事前に予測できない事象が発生した場合に適切なアクセス制限をかけられない。また、事前に予測できる事象であっても、状況に応じて運用内容が変化（分岐）する場合にも対応できない。

本発明では、上記課題の少なくとも1つを解決するため、ストレージを利用する側であるサーバ上の業務プログラムの運用状態に応じてストレージに対する操作権限を決定する手段を提供する。

また、本発明では、上記課題の少なくとも1つを解決するため、業務プログラムの運用状態毎の権限情報を保持し、いずれの運用状態になったとしても対応できる手段を提供する。

本発明によれば、業務プログラムの状態変化に合わせてストレージに対する操作をより適切に制限することができ、より安全にストレージ操作が実施できるようになる。

実施例１および実施例２のシステム構成図 実施例１および実施例２のシステム構成要素間の関係および構成要素の状態を示す図 実施例１および実施例２のコピーペア情報２１２のデータ構造およびデータ例を示す図 実施例１および実施例２の操作可否情報２１３のデータ構造およびデータ例を示す図である。 実施例１および実施例２の管理者別役割情報２１４のデータ構造およびデータ例を示す図 実施例１の業務情報２１５のデータ構造およびデータ例を示す図 実施例１および実施例２の業務構成情報４４２のデータ構造およびデータ例を示す図 実施例１の管理サーバプログラム２１１の操作指示９２２受領時の処理フロー 実施例１の管理エージェントプログラム４４１の、業務状態の照会要求９２５受領時の処理フロー 実施例２の業務情報２１５のデータ構造およびデータ例を示す図 実施例２の管理エージェントプログラム４４１の業務プログラム４４３の状態を管理サーバプログラム２１１に伝える処理フロー 実施例２の管理サーバプログラム２１１の業務プログラム４４３の状態受領時の処理フロー 実施例２の管理エージェントプログラム４４１の業務プログラム４４３の状態を管理サーバプログラム２１１に伝える処理フロー 実施例２の管理サーバプログラム２１１の操作指示９２２受領時の処理フロー 実施例３のシステム構成図 実施例３のシステム構成要素間の関係および構成要素の状態を示す図 実施例３のボリューム情報２１６のデータ構造およびデータ例を示す図 実施例３の操作可否情報２１７のデータ構造およびデータ例を示す図 実施例３の管理サーバプログラム２１１の操作指示９２２受領時の処理フロー

実施例１および実施例２はストレージが提供する論理ボリュームのコピー機能の管理操作に対するアクセス制御に関する例である。実施例３は同論理ボリュームに対する管理操作に対するアクセス制御に関する例である。以下、図面に従い発明を実施するための形態について述べる。

図１は実施例１と実施例２に関する計算機システムの構成図である。計算機システムは、管理端末１０、管理計算機２０、ストレージ３０、ホスト計算機４０、管理用ネットワーク５１、ストレージネットワーク５２を含む。管理端末１０、管理計算機２０、ストレージ３０、ホスト計算機４０は管理用ネットワーク５１によって結ばれている。また、管理計算機２０、ストレージ３０、ホスト計算機４０はストレージネットワーク５２によって結ばれている。

管理用ネットワーク５１およびストレージネットワーク５２は通信回線であり、情報処理システム間でデータを送受信するための経路である。なお図１では管理用ネットワーク５１とストレージネットワーク５２を別の通信回線としているが、両者は共通の通信回線であっても良い。

管理端末１０は情報処理装置であり、データやプログラムを記憶するためのメモリ１１、プログラムを実行するためのプロセサ１２、データ等を表示する表示装置１３、ユーザからの文字による入力受け付けるキーボード１４、表示画面上の任意の地点を指し示すためのマウス１５、管理用ネットワーク５１を接続して他の情報処理装置とデータ送受信するためのＨｏｓｔ Ｉ／Ｆ１６で構成される。

コンソールプログラム１１１はメモリ１１に格納され、プロセサ１２によって実行されるプログラムであり、Ｈｏｓｔ Ｉ／Ｆ１６および管理用ネットワーク５１を介して管理計算機２０にアクセスし、表示装置１３に情報を表示し、またキーボード１４およびマウス１５を介して管理端末１０の利用者からの入力を受け付ける。本発明では管理端末１０を、ストレージの運用・管理に携わるストレージ管理者が、ストレージ３０を運用・管理するための窓口として用いる。

管理計算機２０は情報処理装置であり、データやプログラムを記憶するためのメモリ２１、プログラムを実行するためのプロセサ２２、ストレージネットワーク５２を経由してストレージ３０に対して操作指示や情報の照会を行なうためのＳＡＮ Ｉ／Ｆ２３、管理用ネットワーク５１を接続して他の情報処理装置とデータ送受信するためのＨｏｓｔ Ｉ／Ｆ２４を含む。

管理サーバプログラム２１１はストレージ３０を管理するためのプログラムであり、メモリ２１に格納され、プロセサ２２によって実行される。コピーペア情報２１２はストレージ３０内で実施されるデータのコピー処理に関する情報である。操作可否情報２１３はストレージ３０に対する各種操作指示の実行可否を示す情報である。管理者別役割情報２１４はストレージ３０を管理または利用する利用者の役割を示す情報である。業務情報２１５はホスト計算機４０上で実行される業務プログラム４３３に関する情報である。コピーペア情報２１２、操作可否情報２１３、管理者別役割情報２１４、業務情報２１５はメモリ２１に格納される。各情報の詳細については後述する。

ストレージ３０は情報を記憶するための装置であり、記憶制御ユニット３１、ディスクユニット３２によって構成される。記憶制御ユニット３１はさらに、管理用ネットワーク５１に接続するためのＨｏｓｔ Ｉ／Ｆ３１１、ストレージネットワーク５２に接続するためのＳＡＮ Ｉ／Ｆ３１２、入出力処理プログラム３１４１やコピー処理プログラム３１４２を実行するプロセサ３１３、情報やプログラムを記憶するためのメモリ３１４、ディスク装置に対する情報の書き込み・読み込みを行うためのディスク制御部３１５を備える。ディスクユニット３２は一つ以上のディスクドライブ３２１をまとめたものであり、まとめた記憶領域をさらに論理的な記憶領域として再区分する。この論理的な記憶領域を論理ボリューム３２２と呼ぶ。

入出力処理プログラム３１４１は、管理計算機２０からの要求に応じて論理ボリュームの定義やホスト計算機４０からの求めに応じて論理ボリュームに対するデータの読み書きを行う。コピー処理プログラム３１４２は、管理計算機２０からの指示に応じて特定の論理ボリューム３２２から他の論理ボリューム３２２に対してデータのコピーを行う。
ホスト計算機４０は情報処理装置であり、ストレージネットワーク５２を経由してストレージ３０に対してデータの読み書きを行うためのＳＡＮ Ｉ／Ｆ４１、管理用ネットワーク５１を接続して他の情報処理装置とデータ送受信するためのＨｏｓｔ Ｉ／Ｆ４２、ＯＳや業務プログラム４４３などのプログラムを実行するためのプロセサ４３、データやプログラムを記憶するためのメモリ４４を含む。

管理エージェントプログラム４４１は管理サーバプログラム２１１と連携して動作するプログラムである。業務構成情報４４２は業務プログラム４４３と、業務プログラム４４３が使用する論理ボリューム３２２の関係を示す情報である。業務プログラム４４３はホスト計算機４０で実行される業務処理のためのプログラムである。なお業務プログラム４４３は単体のプログラムではなく、複数のプログラム（サービスやプロセスを含む）から構成されていても良い。ＯＳ４４４は管理エージェントプログラム４４１および業務プログラム４４３の実行基盤となる基本ソフトウェアである。

図２は本願の技術を用いたシステムの構成および状態の例である。図２においてストレージ３０ａとストレージ３０ｂはそれぞれ異なるストレージ３０を指す。他にも数字の末尾に英字が付与されている事物があるが、それは英字を省いたものの異なる個体を示す。

管理者９１はコンソールプログラム１１１に対して操作指示９２１を発行している。コンソールプログラムをその操作指示を管理サーバプログラム２１１に転送している（９２２）。さらに管理サーバプログラム２１１は管理エージェントプログラム４４１に対して業務プログラム４４３の状態を問い合わせ（９２３）、管理エージェントプログラム４４１はその問い合わせに回答する（９２４）。管理サーバプログラム２１１は回答（９２４）と要求９２２の内容に応じて操作可否を判断し、操作可であればコピー処理プログラム３１４２に対して操作指示を発行する。

ホスト計算機４０上では、業務プログラム４４３ａと業務プログラム４４３ｂ、管理エージェントプログラム４４１が稼動しており、それぞれ「PROG1」、「PROG2」、「AG1」という識別名を持つとする。業務プログラム４４３ａは論理ボリューム３２２ａを使用し、業務プログラム４４３ｂは論理ボリューム３２２ｂを使用している。なお「PROG1」の動作状態は「BACKUP」であり、「PROG2」の動作状態は「障害停止」となっている。「ST1」という識別名を持つストレージ３０ａ内には、コピー処理プログラム３１４２と「VOL11」という識別名を持つ論理ボリューム３２２ａ、「VOL12」という識別名を持つ論理ボリューム３２２ｂがある。また、論理ボリューム３２２ａがコピー元で論理ボリューム３２２ｃがコピー先であるコピーペア９３ａが存在する。

本願では以下、ある一つの論理ボリューム３２２から別の一つの論理ボリューム３２２に対するコピー処理の組のことをコピーペア９３と称する。コピーペア９３ａの識別名は「PAIR11」であり、状態は「分割（正常）」である。同様に論理ボリューム３２２ｂから論理ボリューム３２２ｄへのコピーペア９３ｂが存在するが、その識別名は「PAIR12」で、その状態は「分割（障害）」である。

「ST2」という識別名を持つストレージ３０ｂ内には識別名が「VOL21」である論理ボリューム３２２ｃ、同「VOL22」である論理ボリューム３２２ｄ、同「VOL23」である論理ボリューム３２２ｅ、同「VOL24」である論理ボリューム３２２ｆがある。そして論理ボリューム３２２ｃから論理ボリューム３２２ｅに対するコピーペア９３ｃと、論理ボリューム３２２ｄから論理ボリューム３２２ｆへのコピーペア９３ｄとがあるが、それぞれ識別名が「PAIR21」と「PAIR22」であり、その状態はそれぞれ「コピー中」、「ペア」となっている。

図３はコピーペア情報２１２のデータ構造および、図２の状況における内容の具体例を示した図である。

コピーペア情報２１２は、ストレージ３０の識別名を保持するストレージＩＤ２１２１と、コピーペア９３の識別名を保持するコピーペアＩＤ２１２２と、コピーペアＩＤ２１２２で特定されるコピーペア９３の状態を示すペア状態２１２３と、同コピーペア９３に対する操作権限の雛形の識別名である権限パターンＩＤ２１２４と、同コピーペア９３に関係する業務プログラム４４３を特定するための業務ＩＤ２１２５から構成される。

なお、ストレージＩＤ２１２１には、当該コピーペア９３を制御するために管理サーバプログラム２１１から発行される操作指示の、発行先となるストレージ３０の識別名を登録するが、すなわち、コピー元の論理ボリューム３２２が格納されているストレージ３０の識別名を指すことになる。たとえば図２でコピーペア９３ａのストレージＩＤ２１２１は、同コピーペアのコピー元が論理ボリューム３２２ａであり、かつ同論理ボリュームはストレージ３０ａに含まれるため同ストレージの識別名である「ST1」を用いる。また、コピーペア情報２１２は存在するコピーペア９３の数に比例した情報量となる。図２の例では、「PAIR11」、「PAIR12」、「PAIR21」、「PAIR22」という識別名を持つ四つのコピーペア９３が存在しているため、図３では各コピーペア９３に対応する情報が一行一コピーペア９３の形で計四行登録されている。

ペア状態２１２３はコピーペアＩＤ２１２２で特定されるペアのコピー状態を保持する。図３の例で「分割(正常)」は管理者９１の操作によってコピー処理を中断させている状態を示す。また、「分割(障害)」とあるのはコピーペア９３の障害によってコピー処理が中断している状態を示し、「コピー中」はコピーが進行中であることを示し、「ペア」はコピーが完了してコピー元論理ボリューム３２２とコピー先論理ボリューム３２２の内容が一致している状態を示す。また、図２の権限パターンＩＤ２１２４欄には、「PAIR11」と「PAIR12」に対して「REMOTE_MIRROR1」、「PAIR21」と「PAIR22」には「LOCAL_BACKUP1」という内容が登録されているが、この内容については管理者が個別に指定する形でも良いし、異なるストレージ３０間のコピーペアか同一ストレージ３０内のコピーペアかによって所定の値が使われるようにしても良い。

図４は操作可否情報２１３のデータ構造および、図２の状況における内容の具体例を示した図である。操作可否情報２１３は、権限パターンＩＤ２１３１、業務状態２１３２、役割２１３３、ペア操作可否２１３４で構成される。

権限パターンＩＤ２１３１は、特定のコピーペアに対するペア操作可否２１３４の主キーとなる情報であり、コピーペア９３の用途別に定義する。たとえば異なるストレージ３０間のコピーペア９３の場合、同一のストレージ３０間のコピーペア９３でデータバックアップ用に使用する場合などがある。コピーペア情報２１２内の権限パターンＩＤ２１２４で指定する内容は、操作可否情報２１３の権限パターンＩＤ２１３１に対応させた形で参照される。たとえば図３でPAIR11の権限パターンＩＤ２１２４の内容は「REMOTE_MIRROR1」であることから、PAIR11に関する操作可否は操作可否情報２１３内の情報の内、権限パターンＩＤ２１３１が「REMOTE_MIRROR1」になっているものが使われる。

業務状態２１３２には業務プログラム４４３の状態の種類が含まれる。さらに、役割２１３３には管理者９１の役割が登録される。本実施の形態では、ストレージ管理者と業務管理者の二種類の役割を想定しており、図４の役割２１３３で「スト」とあるのは前者、「業務」とあるのは後者を指す。操作可否情報２１３内の情報は、権限パターンＩＤ２１３１、業務状態２１３２、役割２１３３の三つがキー情報となり一つのペア操作可否２１３４が特定される。ペア操作可否情報２１３は操作の種類別の操作可否を示したものである。「不可」とあるのは操作不可であることを、「可」は操作可であることを、それぞれ示す。

なお、ペア操作可否２１３４の内容は、特定の種類の操作が許可されるか・されないかが判別できるものであれば形式は問わない。たとえば可能な操作のみ列挙するという形でも良い。

図５は管理者別役割情報２１４のデータ構造および、図２の状況における内容の具体例を示した図である。管理者別役割情報２１４は、ユーザ名２１４１、リソース種別２１４２、リソースＩＤ２１４３で構成される。

ユーザ名２１４１は任意の管理者９１を特定するための識別名である。リソース種別２１４２は当該管理者が権限を与えられている対象の種類を示す情報である。本実施の形態では、「ストレージ」と「業務」の二種類を想定しているが、その他に「コピーペア」などを加えても良い。

リソースＩＤ２１４３は当該管理者が権限を与えられている対象の識別名の情報である。図５の例で管理者「USER_STO1」は、「ST1」および「ST2」という識別名を持つ「ストレージ（ストレージ３０）」に対する権限を持つことを示している。同様に「USER_PRO1」は「PROG1」という識別名を持つ「業務（業務プログラム４４３）」に対する権限を持っている。

図６は業務情報２１５のデータ構造および、図２の状況における内容の具体例を示した図である。業務情報２１５は業務ＩＤ２１５１、エージェントＩＤ２１５２で構成される。業務ＩＤ２１５１には業務プログラム４４３の識別名を入れる。

一方、エージェントＩＤ２１５２には業務プログラム４４３に関する情報を収集する管理エージェントプログラム４４１の識別名が入る。たとえば図２の構成において業務プログラム４４３ａの情報を管理エージェントプログラム４４１で取得する場合、業務プログラム４４３ａの識別名「PROG1」と管理エージェントプログラム４４１の識別名「AG1」の組が業務情報２１５に入る。

図７は業務構成情報４４２のデータ構造および、図２の状況における内容の具体例を示した図である。業務構成情報４４２は業務ＩＤ４４２１、ボリューム４４２２で構成される。

業務ＩＤ４４２１には業務プログラム４４３の識別名を入れる。ボリューム４４２２には業務プログラム４４３で使用する論理ボリューム３２２の識別名を入れる。図２の例では、業務プログラム４４３ａは論理ボリューム３２２ａを使用していることを想定しているが、その場合業務ＩＤ４４２１には前者の識別名である「PROG1」を、ボリューム４４２２には後者の識別名である「VOL11」が入る。

図８は、管理者９１から管理端末１０経由で操作指示９２２を受領した時の管理サーバプログラム２１１の処理フローを示したものである。
第一のステップはコピーペア操作指示を受領する（８１０１）ことである。この処理は、典型的には管理サーバプログラム２１１が管理端末１０からの操作指示９２２の受領を常に待っている状態にしておき操作指示９２２を受け取ったら図８の８１０２以降の処理を実行する形である。

第二のステップは、操作対象となるコピーペアに関連する業務プログラム４４３を特定する（８１０２）ことである。具体的には、操作指示９２２に含まれている操作対象のコピーペア３２２の識別名を、コピーペア情報２１２のコピーペアＩＤ２１２２から検索する。図２の例では、操作指示９２２（操作指示９２１）に含まれるコピーペア９３の識別名が「PAIR12」であり、図３のコピーペア情報２１２内の二行目にその識別名が見つかる。その二行目の業務ＩＤ２１２５欄の「PROG2」という識別名が業務プログラム４４３を特定するための情報となる。

第三のステップは、特定した業務プログラム４４３を担当している管理エージェントプログラムを特定する（８１０３）ことである。この処理は前のステップで特定した業務プログラム４４３の識別名を、業務情報２１５から探すことによって行える。図６の例では、業務ＩＤ２１５１欄の内容が前のステップで特定した「PROG2」になっている行を探すと、二行目がそれに相当する。その二行目のエージェントＩＤ２１５２欄の内容「AG1」が業務エージェントプログラム４４１の識別名である。

第四のステップは、第三のステップで特定した管理エージェントプログラム４４１に対して、第二のステップ（８１０２）で特定した業務プログラム４４３の状態を問い合わせる（８１０４）ことである。図２では、この処理は９２３の矢印に相当し、管理エージェントプログラム４４１（識別名＝「AG1」）に対して業務プログラム４４３ｂ（識別名＝「PROG2」）の状態を問い合わせる形になる。

第五のステップは、管理エージェントプログラム４４１から業務プログラム４４３の状態を受領する（８１０５）ことである。図２においてこの処理は、９２４の矢印に相当し、受領される情報は業務プログラム４４３ｂの状態である「障害停止」となる。
第六のステップは、操作対象となるコピーペア９３の所属ストレージ３０を特定する（８１０６）ことである。同所属ストレージ３０はコピーペア情報２１２を参照することで特定できる。図２の例では操作対象コピーペア９３は「PAIR12」であり、その識別名はコピーペア情報２１２の二行目のコピーペアＩＤ２１２２にある。その二行目のストレージＩＤ２１２１欄の内容が当該コピーペア９３が所属するストレージ３０の識別名、すなわち「ST1」である。

第七のステップは、操作対象コピーペア９３に対する権限パターンを特定することである。この処理も、コピーペア情報２１２を参照することで特定できる。前のステップで二行目が今回の操作対象ペアに関する情報であることが判明している。その二行目の権限パターンＩＤ２１２４欄の内容である「REMOTE_MIRROR1」が権限パターンの識別名である。

第八のステップは、操作要求発行者である管理者９１が当該ストレージ３０に対する権限を持つか否かを判断する（８１０８）ことである。この処理は、管理者別役割情報２１４の内容を参照することで判断できる。

図２の例では同管理者９１の識別名は「USER_STO1」で、第六のステップ（８１０６）で特定したストレージ３０の識別名が「ST1」であるため、管理者別役割表２１４の中からユーザ名２１４１欄が「USER_STO1」で、リソース種別２１４２欄の内容がストレージ３０に相当する種別名「ストレージ」であり、かつリソースＩＤ２１４３欄の内容が「ST1」である行を検索する。

検索の結果、該当する情報が見つかった場合は権限を持つものと判断し、見つからなかった場合は権限を持たないものと判断する。図５の例では一行目にその情報が存在するため、権限があると見なす。

第九のステップは、第八のステップ（８１０８）で権限を持つと判断された場合の処理である。その内容は、第五のステップ（８１０５）で受領した業務プログラム４４３ｂの状態において、第一のステップ（８１０１）で受領した操作指示９２２に含まれる操作が許可されるか否かを判断する（８１０９）ことである。

この処理は操作可否情報２１３を参照することで行える。すなわち、権限パターンＩＤ２１３１欄の内容が第七のステップ（８１０７）で特定した権限パターンの識別名（「REMOTE_MIRROR1」）になっており、かつ業務状態２１３２欄の内容が第五のステップ（８１０５）で受領した業務プログラム４４３ｂの状態（「障害停止」）と一致しており、かつ役割２１３３欄の内容がストレージ３０を指す「スト」になっている行を検索する。

図２の例では上から五行目がその条件に該当する。さらに第一のステップ（８１０１）で受領した操作の種類と、コピーペア９３の状態に基づいて操作の種類を特定する。この例では、操作指示９２１（９２２）の内容が「PAIR12」に対する「再同期」であり、またコピーペア情報２１２から「PAIR12」の状態が「分割(障害)」であることが分かる。この操作は、「分割(障害)」状態に対する「再同期」であり、操作可否情報２１２のペア操作可否２１３４欄の項目である再同期(障害)２１３４３に相当する。

図４の例では、同項目の内容が「不可」となっているため要求された操作を不許可と判定する。なお図４の例では、「再同期」操作の場合のみコピーペア９３の状態を加味して操作の種類を細分化しており、「初期コピー」２１３４１など「再同期」操作以外の操作はコピーペア９３の状態を加味していないが、この細分化を施す・施さないについてはシステムの要件に合わせて選択すれば良い。

第十のステップは、第八のステップ（８１０８）で権限を持たないと判定されたか第九のステップ（８１０９）で操作が不許可と判定された場合の処理である。その内容は、操作要求発行者である管理者９１が当該業務プログラム４４３に対する権限を持つか否かを判断する（８１１０）ことである。この処理は、管理者別役割情報２１４の内容を参照することで判断できる。

図２の例では同管理者９１の識別名は「USER_STO1」で、第二のステップ（８１０２）で特定した業務プログラム４４３の識別名が「PROG1」であるため、管理者別役割表２１４の中からユーザ名２１４１欄が「USER_STO1」で、リソース種別２１４２欄の内容がストレージ３０に相当する種別名「業務」であり、かつリソースＩＤ２１４３欄の内容が「PROG1」である行を検索する。検索の結果、該当する情報が見つかった場合は権限を持つものと判断し、見つからなかった場合は権限を持たないものと判断する。図５の例ではそのような情報は存在しないため、権限が無いと見なす。

第十一のステップ（８１１１）は、第十のステップ（８１１０）で権限を持つと判定された場合に実行する処理で、その内容は第九のステップ（８１０９）とほぼ同じである。異なる点は、操作可否情報２１３の役割２１３３欄で検索対象となるキーワードのみ。第九のステップ（８１０９）では「スト」が検索対象となるのに対して、第十一のステップ（８１１１）では「業務」が検索対象となる。

第十二のステップは、コピーペア９３を対象とした操作指示をストレージ３０内のコピー処理プログラム３１４２に発行する（８１１２）ことである。この時、操作指示発行先のストレージ３０は、コピーペア情報２１２を参照して決定する。
図２の例では、操作対象となるコピーペア９３が「PAIR12」あるため、図３を参照して識別名が「ST1」のストレージ３０が発行先であることが分かる。

第十三のステップ（８１１３）は、第十のステップ（８１１０）で権限を持たないと判定されたか第十一のステップ（８１１１）で操作が不許可と判定された場合の処理である。その内容は、管理端末１０の表示装置１３上に権限が無い旨のメッセージを表示する処理（８１１３）であり、これはたとえば管理サーバプログラム２１１がコンソールプログラム１１１に操作指示９２２の結果を返す際にその旨通知して、コンソールプログラム１１１に画面表示させれば良い。

図９は、管理サーバプログラム２１１から業務プログラム４４３の状態に関する問い合わせを受けた時の管理エージェントプログラム４４１の処理フローである。

第一のステップは、管理サーバプログラム２１１から業務プログラム４４３の状態に関する照会要求９２３を受信する（８２０１）ことである。管理エージェントプログラム４４１は常駐プログラムとし、常に管理サーバプログラム２１１からの照会要求９２３を待っている状態にしておいても良い。

第二のステップは、照会要求９２３に含まれる識別名を取り出し、同識別名で特定される業務プログラム４４３の状態を調査すること（８２０２）である。本実施例では照会要求９２３に照会したい業務プログラム４４３の識別名が含まれていることを想定しているが、同識別名を含めないで、管理エージェントプログラム４４１が状態確認できるすべての業務プログラム４４３の状態を調査する方式を取っても良い。

業務プログラム４４３の状態の種類は業務プログラム４４３の種類によって異なるが、たとえば「通常運用」、「バッチ」、「BACKUP」、「障害停止」、「正常停止」、「テスト」、「未使用」に分けることが考えられる。

ここで「通常運用」は業務プログラム４４３が、オンライン処理など当該業務プログラム４４３の主たる処理を行っている状態を示す。「バッチ」は業務プログラム４４３が、データの集計作業等のバッチ処理を行っている状態を示す。「BACKUP」は当該業務のデータのバックアップが取られている最中である場合を示す。「障害停止」は業務プログラム４４３が停止中で、かつ障害等によって停止した場合を、「正常停止」は管理者等が操作して業務プログラム４４３を停止させた場合を、それぞれ示す。また、「テスト」は当該業務プログラム４４３がテスト動作中であることを、「未使用」は操作対象のコピーペア９３のコピー元となる論理ボリューム３２２が当該業務プログラム４４３によって使用されていない状態を示す。

業務プログラム４４３が稼動しているか否かの識別は、たとえばＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）４４４の実行中のプロセス／サービス一覧の内容を参照することで特定できる。通常処理中であるか否かは、通常処理を行うプロセス名またはサービス名を事前に設定しておき、前記プロセス／サービス一覧を参照して、前記プロセス名またはサービス名のプログラムの稼動状態を調べることで確認できる。バッチ処理中であるか否かの判断も通常処理の確認と同様である。また、データバックアップ中であるか否かは、業務プログラム４４３自身がバックアップ状態であるか否かの属性値を持っている場合はその属性値を参照するなどの手段で特定する。テスト状態であるか否かは、テスト状態であることを示す属性情報を業務プログラム４４３内に持たせ、前記属性情報をユーザが任意に設定し、管理エージェントプログラム４４１が読み取るなどの手段を用いて特定すれば良い。また、未使用状態であるか否かは、業務プログラム４４３の構成情報を参照するなどして論理ボリューム３２２の使用状況を確認すれば良い。

第三のステップは、業務プログラム４４３が現在の状態になった経緯を特定する処理（８２０３）である。第二のステップ（８２０２）で業務プログラム４４３が停止中と判断された時に、停止にいたった原因を調べる。

この処理は業務プログラム４４３が正常に停止したのか何らかの障害が発生して停止したのかによって、操作権限の与え方を変えたい場合に実施する。正常か障害かの判定は、業務プログラム４４３の起動や正常終了、異常の発生時にその旨をイベントログ（事象を記録するファイル）に出力する仕組みが業務プログラム４４３やＯＳ４４４に備わっていれば、そのイベントログの内容を参照することによって判断できる。

たとえば、業務プログラム４４３が停止中の場合で、イベントログの最新の記録が正常終了を示す内容の時は「正常停止」と判断し、そうでない時は「障害停止」と判断すれば良い。

第四のステップは、状態または経緯を含む状態を管理サーバプログラム２１１に送信する（８２０４）ことである。このステップは図２では照会結果９２４に相当する。

なお本実施例では、操作指示９２１を管理者９１の役割に基づいて分類したが、管理者個別に権限を付与しても良い。その場合、以下の変更を施せば良い。操作可否情報２１３は役割２１３３欄の代わりに、管理者を特定するための識別名、すなわち管理者別役割情報２１４のユーザ名２１４１に相当する情報を入れる。管理者別役割情報２１４は必要なくなる。これにより、図８に示した処理フローの第八のステップ（８１０８）から第十一のステップ（８１１１）の処理は、第七のステップ（８１０７）までに特定した情報と上記変更された管理者別役割情報２１４に基づいて操作可否を判断する一つのステップに集約することができる。

また、操作指示９２１を管理者９１が所属するグループ別に分類しても良い。すなわち操作可否情報２１３の役割２１３３欄の代わりに、管理者が所属するグループ名を定義する。そして、管理者別役割情報２１４においてリソース種別２１４２とリソースＩＤ２１４３をグループ名に置き換える。図８に示した処理フローについても、前記管理者個別に権限を付与する場合と同様な変更を加えれば良い。

また、上記実施例１ではユーザ別役割情報２１４のリソース種別として、「ストレージ」と「業務」の二つを使用したが、「ホスト」を使用しても良い。「ホスト」とは業務処理プログラム４４３が稼動するホスト計算機４０を指し、リソースＩＤ２１４３欄にはホスト計算機４０の識別名が格納される。また、ホスト計算機４０が複数存在し、業務処理プログラム４４３が稼動しているホスト計算機４０とストレージ３０の間に中継役となる別のホスト計算機４０が存在する場合、その中継役ホスト計算機４０の識別名をリソースＩＤ２１４３欄に格納しても良い。

また、実施例１では操作可否情報２１３を情報としているが、プログラムの処理ロジックとして実装しても良い。

前述した図８・図９の処理フローを、管理サーバプログラム２１１および管理エージェントプログラム４４１が実行することによって、本発明が意図するストレージ３０に対する操作制限が行えるが、業務プログラム４４３の状態の受け渡しについては実施例１の方法に限定されない。その一例を実施例２として、実施例１と異なる点を以下で説明する。
実施例２では、データ構造の一部と処理フローが異なる。データ構造で異なるのは業務情報２１５である。図１０に実施例２のための業務情報２１５を示した。図６に示した実施例１向けのそれに業務の状態２１５３欄を追加した形である。業務の状態２１５３欄には管理エージェントプログラム４４１から受け取った業務プログラム４４３の状態を格納する。

実施例２の処理フローは大きく分けて二系統ある。また、第一の系統は管理エージェントプログラム４４１のパートと管理サーバプログラム２１１のパートに分かれる。第一の系統の管理エージェントプログラム４４１のパートは図１１に示す通りである。

第一のステップは、業務プログラム４４３の状態を特定する（８３０１）ことであるが、その内容は第一の実施例の項で述べた図８の第一のステップ（８１０２）と同様である。また、第二のステップ（８３０２）は、図８の第四のステップ（８１０４）と同じである。図１１では図８の第三のステップ（８１０３）を省略しているが、取り入れても差し支えない。図１１の第三のステップ（８３０３）は、管理エージェントプログラム４４１に対する終了判定である。

実施例２では、管理エージェントプログラム４４１は業務プログラム４４３の状態変化を監視し続けるため、何らかのプログラム終了手段が必要となる。第三のステップ（８３０３）はその手段を提供するもので、管理エージェントプログラム４４１のユーザなどから何らかの指示を受け取った場合に終了する。

第四のステップは、業務プログラム４４３の状態を特定するもので、第一のステップ（８３０１）と同じである。

第五のステップ（８３０５）は、業務プログラム４４３の状態が変化したか否かを判定するもので、第二のステップまたは第六のステップで最後に管理サーバプログラム２１１に通知した業務プログラム４４３の状態と、現在の業務プログラム４４３の状態とを比較し、同じであれば状態変化なしとして第三のステップに戻り、異なるのであれば状態変化ありと判断する。

第六のステップ（８３０６）は、第五のステップ（８３０５）で「異なる」と判断された場合の処理で、第四のステップ（８３０４）で特定した現在の業務プログラム４４３の状態を管理サーバプログラム２１１に送信する。

第一の系統の管理サーバプログラム２１１のパートの処理フローを図１２に示す。第一のステップ（８４０１）は、図１２に示した処理フローの第二のステップ（８３０２）または第六のステップ（８３０６）で送信された業務プログラム４４３の状態を受け取る処理である。

第二のステップ（８４０２）の処理は、第一のステップ（８４０１）で受け取った業務プログラム４４３の状態を業務情報２１５に格納する処理である。上記第一の系統の管理エージェントプログラム４４１の処理フロー（図１１）の別の方式として、状態変更のイベント発生を待つ形にしても良い。図１３にその処理フローを示す。

第一のステップ（８５０１）から第三のステップ（８５０３）までは図１１の第一のステップ（８３０１）から第三のステップ（８３０３）と同じである。

第四のステップ（８５０４）は、イベントの発生を待つ処理である。ここで言うイベントとは図９の説明で述べたイベントと同じものである。イベントの発生を常時待ち、発生したら第五のステップ（８５０５）に進む。

第五のステップ（８５０５）は、発生したイベントの内容を調べる処理で、当該業務プログラム４４３の状態変更に関係する内容か否かを判断する。当該業務プログラム４４３に関するイベントの場合で、かつプログラムの起動や停止、障害の発生などを示す内容であれば関係がある（図１３では「YES」）と判定し、そうでない場合は関係なし（図１３の「NO」）と判定する。

第六のステップ（８５０６）から第八のステップ（８５０８）の処理は、図１１の第四のステップ（８３０４）から第六のステップ（８３０６）と同じである。

第二の系統は管理サーバプログラム２１１向けで、その処理フローを図１４に示す。第一のステップ（８６０１）と第二のステップ（８６０２）は、それぞれ図８の第一のステップ（８１０１）と第二のステップ（８１０２）と同じである。

第三のステップ（８６０３）は、業務プログラム４４３の状態を特定する処理で、図８では管理エージェントプログラム４４１に問い合わせていたところを、図１４の処理フローでは図１０の業務情報２１５を参照することによって実施している点が異なる。

第四のステップ（８６０４）から第十一のステップ（８６１１）までの処理は、図８の第六のステップ（８１０６）から第十三のステップ（８１１３）までと同じである。

なお、業務プログラム４４３の運用状態に合わせて権限情報を更新する形にしても良い。たとえば、操作可否情報２１３に含まれるペア操作可否２１３４欄と役割２１３３欄をコピーペア情報２１２にも追加する。

この場合、コピーペア９３一つあたり役割２１３３別に二行の情報量となる。そして、管理サーバプログラム２１１は管理エージェントプログラム４４１から業務プログラム４４３の運用状態を取得したら、コピーペア情報２１２の中で、業務ＩＤ２１２５欄の内容が、同業務プログラム４４３の識別名と一致する行に関して、操作可否情報２１３の中から権限パターンおよび業務の状態が一致する行の役割２１３３とペア操作可否２１３４の内容を設定（上書き）する。そして、管理サーバプログラム２１１は管理者からコピーペア操作指示９２２を受けた時に、コピーペア情報２１２に含まれる操作可否２１３４の内容を参照し操作可否を判定する。

また、管理エージェントプログラム４４１側で業務プログラム４４３の運用状態変化を検出するのではなく、業務プログラム４４１の運用状態を管理サーバプログラム２１１から定期的に取得する形でも良い。この場合、管理エージェントプログラム４４１側の処理は実施例１と同じになる。

本発明が開示する処理方式はコピー操作に関するアクセス制限に限定されない。たとえば論理ボリューム３２２に対する操作制御にも適用できる。その一例を実施例3として、実施例１と異なる点を以下で説明する。

図１５はボリュームの設定変更に対するアクセス制御に本発明の方式を適用した場合のシステム構成例を示す図である。管理計算機２０内にボリューム情報２１６を持つ点、およびストレージ内３０内にボリュームパス管理プログラム３１４４、ボリューム構成管理プログラム３１４５、ボリューム属性管理プログラム３１４６を持つ点が、図１と異なる。

ボリュームパス管理プログラム３１４４は、ホスト計算機４０から論理ボリューム３２２に至る経路設定を管理するためのプログラムであり、特定の論理ボリューム３２２を特定のホスト計算機４０からのみ利用できるようアクセス制限をかけたり、および経路の設定変更したりする機能を持つ。

ボリューム構成管理プログラム３１４５は論理ボリューム３２２の構成管理機能を提供するプログラムである。たとえば、論理ボリューム３２２を作成・削除する機能、複数の論理ボリューム３２２を一つの論理ボリューム３２２に見立ててホスト計算機４０側からアクセスさせる機能、他のストレージ３０内に存在する論理ボリューム３２２を自ストレージ３０内の論理ボリューム３２２としてホスト計算機４０からアクセスさせる機能、論理ボリューム３２２のデータが記憶されている領域を他の記憶領域に移す機能などを提供する。ボリューム属性管理プログラム３１４６は論理ボリューム３２２の属性、たとえば読書き可否などを管理するプログラムである。

図１６は実施例３を説明するためのモデル図である。ストレージ３０ａ内にボリュームパス管理プログラム３１４４、ボリューム構成管理プログラム３１４５、ボリューム属性管理プログラム３１４６が存在する点が図２と異なる。

図１７はボリューム情報２１６のデータ構造およびデータの例を示す図である。ストレージＩＤ２１６１は、特定の論理ボリューム３２２が配置されているストレージ３０の識別名を保持する。ボリューム２１６２は、論理ボリューム３２２の識別名を保持する。権限パターンＩＤ２１６３は当該論理ボリューム３２２向けの権限パターンの識別名を保持する。業務ＩＤ２１６４は当該論理ボリューム３２２を使用する業務プログラム４４３の識別名を保持する。

図１８は操作可否情報２１７のデータ構造およびデータ例を示す図である。データ構造は図４に示した操作可否情報２１３と同様で、ペア操作可否２１３４の代わりにボリューム操作可否２１７４が含まれている点のみ異なる。

ボリューム操作可否２１７４に含まれるパス追加２１７４１およびパス削除２１７４２は、それぞれボリュームパス管理プログラム３１４４による経路設定の追加および削除を示す。構成追加２１７４３および構成削除２１７４４、解体(削除)２１７４５は、それぞれボリューム構成管理プログラム３１４５による論理ボリューム３２２内の構成要素を追加および削除する操作、論理ボリューム３２２自体を削除する操作である。属性変更２１７４６は論理ボリューム３２２の属性を変更する操作である。

なお本実施例では、様々な属性変更の種類をひとまとめにしているが、ボリューム読書き可や読み込みのみ可など操作可否を細分化して定義しても良い。パス追加２１７４１などボリューム操作可否２１７４内の他の項目についても同様に細分化しても良い。

図１９は、図２において管理サーバプログラム２１１が操作指示９２２を受け取った時の処理フローである。第一のステップ（８１０１１）、第二のステップ（８１０２１）、第六のステップ（８１０６１）、第七のステップ（８１０７１）、第十二のステップ（８１１２１）の処理対象が「コピーペア」ではなく「ボリューム」である点が図8と異なる。

実施例３の動作例を、図１６を用いて以下説明する。図１６では、管理者９１が「VOL11を書込み禁止に」する旨の操作指示９２１１を発行している。管理サーバプログラム２１１は、その操作指示９２１１をコンソールプログラム１１１経由で受け取り、ボリューム情報２１６を参照し操作対象である論理ボリューム３２２ａ「VOL11」を使用している業務プログラム４４３ａ「PROG1」を特定する。

さらに業務情報２１５を参照することで同業務プログラム４４３ａを担当する管理エージェントプログラム４４１「AG1」を特定し、同プログラムから業務プログラム４４３ａの状態「通常運用」を取得する。さらにボリューム情報２１６を参照することにより、論理ボリューム３２２ａに対応する権限パターン「DATABASE_TYPE1」を特定する。次に管理者別役割情報２１４を参照することで、管理者９１「USER_STO1」がストレージ３０ａの「ストレージ管理者」であり、「業務管理者」ではないことを特定する。

以上の情報を元にボリューム操作可否情報２１７４内を参照することで、属性変更２１７４６に相当する操作指示９２１１「書込み禁止」は、不可と判定される。

１０・・・管理端末 ２０・・・管理計算機 ３０・・・ストレージ ４０・・・ホスト計算機

Claims (13)

1. 記憶装置を操作対象とし、前記記憶装置とホスト計算機に接続された管理計算機であって、
   メモリと、
   制御部とを備え、
   前記メモリは、
   前記ホスト計算機上で動作するアプリケーションの状態を示す情報と、前記アプリケーションの状態を示す情報に応じた前記記憶装置に対する操作命令の可否を示す情報を含む操作可否情報とを有し、
   前記制御部は、
   前記操作命令を受信し、
   前記ホスト計算機から前記操作命令を送信した前記アプリケーションの状態を問い合わせ、
   前記操作命令、前記問い合わせの結果及び前記操作可否情報を参照して、前記操作命令の可否を判断することを特徴とする管理計算機。
2. 請求項1記載の管理計算機であって、
   前記操作可否情報は、さらに、前記操作命令を送信する送信者を識別する情報)を含むことを特徴とする管理計算機。
3. 請求項2記載の管理計算機であって、
   前記メモリは、さらに、
   前記アプリケーションを識別する識別子と、前記アプリケーションの状態を示す情報を含む業務情報を有し、
   前記制御部は、
   前記ホスト計算機から前記操作命令を送信した前記アプリケーションの状態を問い合わせる代わりに、前記業務情報をさらに参照して、前記操作命令の可否を判断することを特徴とする管理計算機。
4. 請求項3記載の管理計算機であって、
   前記制御部は、
   前記業務情報を、前記アプリケーションのイベント発生を契機にして更新することを特徴とする管理計算機。
5. 請求項3記載の管理計算機であって、
   前記制御部は、
   前記業務情報を、予め定められた時間ごとに更新することを特徴とする管理計算機。
6. 請求項4又は5記載の管理計算機であって、
   前記記憶装置の状態を示す情報は、前記操作が実行中か否かの情報、前記操作が中断しているか否かの情報及び前記操作が完了したか否かの情報を含むことを特徴とする管理計算機。
7. 請求項6記載の管理計算機であって、
   前記アプリケーションの状態を示す情報は、前記アプリケーションが動作しているか否かの情報を含むことを特徴とする管理計算機。
8. 請求項記載の管理計算機であって、
   前記アプリケーションの状態を示す情報は、前記アプリケーションが動作していない場合、その原因である情報を含むことを特徴とする管理計算機。
9. 請求項8記載の管理計算機であって、
   前記制御部は、
   前記操作命令の可否の判断が可であった場合、前記操作を実行し、
   前記操作命令の可否の判断が否であった場合、前記送信命令を送信した送信者に前記操作命令の権限が無い旨の通知を送信することを特徴とする管理計算機。
10. 請求項9記載の管理計算機であって、
    前記操作命令は、
    前記記憶装置におけるボリュームのコピーであり、
    前記操作可否情報は、さらに、
    前記操作命令を識別する識別子を有し、
    前記メモリは、さらに、
    前記記憶装置の識別子、前記コピーのペアを特定する情報、前記コピーのペアの状態を示す情報及び前記操作命令を識別する識別子を含む状態情報とを有し、
    前記制御部は、
    前記操作命令及び前記状態情報を参照し、前記操作命令の対象となる前記記憶装置の領域を特定し、
    さらに、前記状態情報を参照して、前記操作命令の可否を判断することを特徴とする管理計算機。
11. 請求項10記載の管理計算機であって、
    前記記憶装置の状態を示す情報は、さらに、前記操作が中断している場合、その原因である情報を含むことを特徴とする管理計算機。
12. 請求項11記載の管理計算機であって、
    前記送信者を識別する情報は、前記送信者が、前記記憶装置の操作権限を有するか否か及び前記アプリケーションの動作権限を有するか否かの情報を含むことを特徴とする管理計算機。
13. 請求項12記載の管理計算機であって、
    前記送信者を識別する情報は、前記送信者を一意に特定する情報、又は前記送信者を分類するグループを一意に特定する情報を含むことを特徴とする管理計算機。

Images