(57)【要約】【課題】機能制御のインタフェースが異なる複数の外部記憶装置が混在する環境において、記憶装置の機能をコンピュータから制御する場合に、制御の対象となる記憶装置の種類を識別し種類に応じた処理を実行する必要があるため、制御が複雑化する問題がある。【解決手段】記憶装置の機能を制御するための共通インタフェースを設ける。共通インタフェースを提供する装置は、ホストコンピュータが認識する記憶領域と、記憶装置が提供する記憶領域の対応関係を管理し、機能制御指示の対象となる記憶領域と、それを提供している記憶装置を対応付ける。機能制御指示の対象となる記憶領域を提供する記憶装置の種類を識別し、その装置に固有の機能制御インタフェースを介して機能制御を指示する。【選択図】  図１
2004192105.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のホストコンピュータおよび１つ以上の外部記憶装置とネットワークで接続された記憶装置の接続装置であり、
前記ホストコンピュータから前記外部記憶に関する機能を制御する指示を受信する第１の手段と、
受信した指示から、制御対象となる外部記憶装置を識別する第２の手段と、
受信した指示から、外部記憶装置に指示する内容を選択する第３の手段と、
識別した制御対象および選択した指示内容に応じて、外部記憶装置に指示を送る方法を選択する第４の手段と、
選択した方法により、外部記憶装置に指示を送る第５の手段と、
を備えることを特徴とする記憶装置の接続装置。
【請求項２】
前記第２の手段から参照され、ホストコンピュータが認識する記憶領域と外部記憶装置が提供する記憶領域の対応関係を記憶する第６の手段と、
前記第３の手段に応じて受信した指示から、ホストコンピュータが指定した制御対象に対応する、外部記憶装置が提供する１つ以上の記憶領域を識別する第７の手段と、
を更に備えることを特徴とする請求項１記載の記憶装置の接続装置。
【請求項３】
外部記憶装置から状態情報を取得する第８の手段と、
外部記憶装置から取得した複数の状態情報から、ホストコンピュータが指定した制御対象の状態を作成する第９の手段と、
前記ホストコンピュータに前記状態情報を送信する第１０の手段と、
を更に備えることを特徴とする請求項１記載の記憶装置の接続装置。
【請求項４】
互いにプロトコルの異なる複数の前記第１の手段
を備えることを特徴とする請求項１記載の記憶装置の接続装置。
【請求項５】
ホストコンピュータから指定された制御対象および制御内容に応じた、外部記憶装置に指示を送る複数の方法を記憶する第１１の手段と、
外部記憶装置への指示の失敗を識別する第１２の手段と、
外部記憶装置への指示が失敗した場合に、指示を送る別の手段を選択する第１３の手段と、
を更に備えることを特徴とする請求項１記載の記憶装置の接続装置。
【請求項６】
外部記憶装置への指示が失敗した場合に、その指示に対応する、エラー処理内容を記憶する第１４の手段と、
外部記憶装置への指示が失敗した場合に、エラー処理が必要な制御対象を識別する第１５の手段と、
エラー処理が必要であると識別した制御対象に対するエラー処理を実行する第１６の手段と、
を更に備えることを特徴とする請求項５記載の記憶装置の接続装置。
【請求項７】
制御対象ごとに、制御を許可する対象を記憶する第１７の手段と、
受信した指示の、通信プロトコルの送信元に関する情報に基づいて、制御が許可されているか判別する第１８の手段と、
受信した指示が、許可された制御か判別する第１９の手段と、
を更に備えることを特徴とする請求項１記載の記憶装置の接続装置。
【請求項８】
受信した指示の、指示内容に含まれる送信元の識別子に基づいて、制御が許可されているか判別する第２０の手段と、
を備えることを特徴とする請求項７記載の記憶装置の接続装置。
【請求項９】
１つ以上のホストコンピュータおよび１つ以上の外部記憶装置と接続されたネットワークスイッチであり、
ホストコンピュータから外部記憶に関する機能を制御する指示を受信する手段と、
受信した指示から、制御対象となる外部記憶装置を識別する手段と、
受信した指示から、外部記憶装置に指示する内容を選択する手段と、
識別した制御対象および選択した指示内容に応じて、外部記憶装置に指示を送る方法を選択する手段と、
選択した手段により、外部記憶装置に指示を送る手段と、
を備えることを特徴とするネットワークスイッチ。
【請求項１０】
インテリジェント機能を持ちプロトコルの異なる２以上の記憶装置と、前記記憶装置に共通インタフェースで前記記憶装置の機能を制御する指示を出力する１以上のホストコンピュータとに接続され、前記ホストコンピュータからの仮想ボリューム識別子を含む前記指示を共通インタフェースとして受信する第１の手段と、前記指示を受け、前記仮想ボリュームを構成するディスクボリュームを求め前記ディスクボリュームに固有なプロトコルに変換して各記憶装置に対し機能を制御する指示を発行する第２の手段とを備えたことを特徴とする記憶装置の接続装置。
【請求項１１】
インテリジェント機能を持ちプロトコルの異なる２以上の記憶装置と、前記記憶装置に共通インタフェースで前記記憶装置の機能を制御する指示を出力する１以上のホストコンピュータと、前記記憶装置とホストコンピュータに接続され、前記ホストコンピュータからの前記指示を共通インタフェースとして受信する第１の手段と、前記指示を前記記憶装置の指示を受けるプロトコルに変換して各記憶装置に対し発行する第２の手段とを有する記憶装置の接続装置とを備えたことを特徴とするコンピュータシステム。
【請求項１２】
前記記憶装置の接続装置は前記記憶装置の機種ごとに制御される機能の制御のためのＡＰＩを記憶するテーブルを持ち、前記第２の手段は前記テーブルを参照することを特徴とする請求項１１記載のコンピュータシステム。
【請求項１３】
１以上のホストコンピュータとインタフェースの異なる２以上の記憶装置を含む記憶装置群に接続された記憶装置の接続装置における接続制御方法であって、
前記ホストコンピュータから共通インタフェースに対し前記記憶装置の機能の制御を指示するものであり制御機能と制御対象である仮想ボリュームの情報を含む制御ブロックを受信し、
特定の機能制御であることを判別し、
制御対象となる仮想ボリュームを特定し、
仮想ボリュームを構成するディスクボリュームを特定し、
前記記憶装置のディスクボリュームに固有な制御ＡＰＩを呼び出す際に引数となるＡＰＩを含む制御ブロックを作成し、
前記記憶装置に固有なインタフェースと前記制御ブロックから機能を制御するＡＰＩを呼び出して機能制御を指示することを特徴とする接続制御方法。
【請求項１４】
１以上のホストコンピュータとインタフェースの異なる２以上の記憶装置を含む記憶装置群に接続された記憶装置の接続装置における接続制御のため前記接続装置を、
前記ホストコンピュータから共通インタフェースに対し前記記憶装置の機能の制御を指示するものであり制御機能と制御対象である仮想ボリュームの情報を含む制御ブロックを受信する手段、
特定の機能制御であることを判別する手段、
制御対象となる仮想ボリュームを特定する手段、
仮想ボリュームを構成するディスクボリュームを特定する手段、
前記記憶装置のディスクボリュームに固有な制御ＡＰＩを呼び出す際に引数となるＡＰＩを含む制御ブロックを作成する手段、および
前記記憶装置に固有なインタフェースと前記制御ブロックから機能を制御するＡＰＩを呼び出して機能制御を指示する手段、
として機能させるための接続制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ホストコンピュータと複数の記憶装置と接続する技術に関し、特に、ディスクアレイなどの記憶装置がユーザに提供する様々な機能の制御に関する。
【０００２】
【従来の技術】
近年、ディスクアレイに代表されるコンピュータの記憶装置のインテリジェント化が進んでいる。例えば、ディスクアレイ装置が提供するミラー機能は、ホストコンピュータがディスクアレイ装置内の記憶領域のデータを更新すると、あらかじめ決められた別の記憶領域にもその更新データを自動的に書き込む。ミラーの停止を指示することにより、その時点での記憶データを保存し、バックアップ等の用途に使用することができる。更新データの別領域への書き込みはディスクアレイ装置内のコントローラによって実行されるため、ホストコンピュータに負荷がかからず、高速な入出力処理が可能となる（例えば、特許文献１参照）。
【０００３】
一方、システム内の記憶装置の数が増え、種類の異なる記憶装置が混在するということが起こっている。即ち、異なるプロトコルを持った記憶装置が混在することになる。ここで、機能とは記憶装置をミラーすることやスナップショットを取ることなどを言い、機能制御とはホストコンピュータが記憶装置にこれらの機能を実現させるよう制御することである。
【０００４】
ホストコンピュータは、ディスクアレイが提供する機能制御インタフェースにアクセスし、あらかじめ定義された記憶装置に固有のプロトコルで指示を送ることにより、機能を制御する。機能制御インタフェースは、Ｉｎ−ｂａｎｄのＳＣＳＩコマンドや、ＬＡＮ経由のＴＣＰ／ＩＰ通信など、さまざまな形態で実現できる（例えば、特許文献２参照）。
【０００５】
また、複数のホストコンピュータと記憶装置をネットワークで接続するストレージエリアネットワーク（ＳＡＮ：  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）の普及が進んでいる。ＳＡＮはファイバチャネルに代表されるようなデータ入出力専用の高速ネットワークであり、コンピュータの入出力性能を向上することができる。さらに、ＳＡＮで接続されたコンピュータ群が１つの記憶装置を共用したり、逆に１つのコンピュータが複数の記憶装置にアクセスしたりできるなど、多様な記憶領域の利用が可能となる。最近では、記憶装置／記憶領域の共有を実現するだけでなく、記憶装置が提供する記憶領域（ディスクボリューム）を結合、あるいは分割して仮想的な記憶領域（仮想ボリューム）をホストコンピュータに提供するストレージバーチャライゼーション（Ｓｔｏｒａｇｅ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）の技術も導入されはじめ、より柔軟な記憶領域の管理が可能となっている。
【０００６】
【特許文献１】
米国特許第５，８４５，２９５号明細書
【特許文献２】
米国特許第５，８６７，７３６号明細書
【０００７】
【発明が解決しようとする課題】
ＳＡＮ環境など、複数の異なる種類の記憶装置が混在するコンピュータシステムにおいて、記憶装置が提供するインテリジェントな機能を利用する場合、ホストコンピュータは制御対象となるディスクアレイの種類を識別し、各記憶装置に固有のインタフェースで機能制御の指示を送る必要がある。同じ機能の制御でも装置毎に異なる制御プログラムをホストコンピュータ内に用意して使い分けなければならず、制御が複雑化する。
【０００８】
また、ストレージバーチャライゼーションにおいては、記憶装置が提供する機能を利用して仮想ボリューム単位でインテリジェントな機能を実現することが考えられるが、その際、仮想ボリュームが複数のディスクボリュームから構成されていると、ディスクボリューム毎に機能の制御を指示する必要がある。そのため、ホストコンピュータは仮想ボリュームの実際の記憶領域を提供する装置を識別し、各装置固有の制御インタフェースを使用する必要があるため制御が複雑化する。
【０００９】
本発明の目的は、異なる種類の記憶装置のさまざまな機能を制御するために、装置の種類に依存しない共通の制御インタフェースを提供し、制御の簡単化を実現することである。
【００１０】
【課題を解決するための手段】
本発明は、記憶装置の機能を制御するための共通インタフェースをコンピュータシステム内のバーチャライゼーションサーバやスイッチに設け、記憶装置の種類に依存しない機能制御方法を提供する。ホストコンピュータは、制御の対象となる記憶装置の種類にかかわらず、あらかじめ定義されたプロトコルで共通インタフェースに機能制御の指示を送る。共通インタフェースを提供する装置は、ホストコンピュータが認識する記憶領域と、記憶装置が提供する記憶領域の対応関係を管理する。また、共通インタフェースのプロトコルを各装置に固有のプロトコルに変換する手段を備え、各記憶装置に固有のインタフェースを介して機能制御を実現する手段をもつ。
【００１１】
共通インタフェースを提供する装置が機能制御の指示を受け取ると、指示の対象となる記憶領域と、それを提供している記憶装置を解釈する。例えば、指示が、ある仮想ボリュームに対するものである場合は、仮想ボリュームを構成するディスクボリュームが指示の対象となる。指示の対象となる記憶領域を提供する記憶装置の種類を識別し、その装置に固有の機能制御インタフェースを介して機能制御を指示する。各装置に固有のインタフェースはインタフェースサーバで隠蔽され、ホストコンピュータは制御対象の装置の種類を意識することなく、共通のインタフェースを利用して機能を制御することが可能となる。ホストコンピュータは、複数のインタフェースに対応し、それぞれを使い分ける必要がなくなるため、制御の簡単化が実現できる。
【００１２】
【発明の実施の形態】
第一の実施の形態
本実施形態は、ファイバチャネルで接続され、異なる機能制御インタフェースを持つ２つのディスクアレイ装置が提供する記憶領域をバーチャライゼーションサーバで仮想化するストレージバーチャライゼーション環境において、ディスクアレイ装置のミラー機能を用いて実現された仮想ボリュームのミラー機能を、バーチャライゼーションサーバが提供する共通インタフェースを利用して制御する例である。
【００１３】
（１）  システムの構成
図１に本実施形態の全体構成を示す。
【００１４】
２台のホストコンピュータ１１０１、１２０１および２台のディスクアレイ１４０１、１５０１があり、それぞれのファイバチャネルインタフェース１１０２、１２０２、１４０２、１５０２とファイバチャネルケーブル１３１４〜１３１７によりバーチャライゼーションサーバ１３０１のファイバチャネルインタフェース１３０２、１３０３、１３０７、１３０８に接続されている。ホストコンピュータから記憶装置へのデータ入出力は、これらのファイバチャネルケーブル上の標準的なＳＣＳＩプロトコルで実現される。以下の説明では、ホストコンピュータやディスクアレイ装置がバーチャライゼーションサーバと直接接続されているが、本発明は通信媒体や接続形態に依存しないため、スイッチを経由した接続やファイバチャネル以外のＳＣＳＩやＩＰネットワークなど、他の通信媒体やプロトコルを用いた構成にも適用可能である。
【００１５】
ホストコンピュータ１１０１のメモリ１１０４内には、仮想ボリュームの機能制御を指示するための仮想ボリューム機能制御プログラム１１０６があり、ＣＰＵ１１０３により実行される。仮想ボリューム機能制御プログラム１１０６は、ディスクアレイの機能制御指示を送出するホストコンピュータにあらかじめインストールされている。仮想ボリューム機能制御プログラム１１０６は、後述するように、制御する機能や制御対象となる仮想ボリュームなどの必要な情報をバーチャライゼーションサーバ１３０１が提供する共通インタフェース（ホストコンピュータから見て共通インタフェースとして供給される仮想ボリューム）に送り、機能制御を指示する。ホストコンピュータ１２０１も同様の構成を持つ。
【００１６】
ディスクアレイ１４０１では、コントローラ１４０４内の制御プログラム１４０７が全体の動作を統括する。制御プログラム１４０７は、ディスクボリューム１４０５および１４０６をホストコンピュータの記憶領域として提供する通常のディスクアレイ機能に加え、ミラー機能やスナップショット機能などのさまざまなインテリジェント機能を提供する。ディスクアレイ１５０１も１４０１と同様の構成を持ち、ミラー機能を含むインテリジェント機能を提供する。
【００１７】
バーチャライゼーションサーバ１３０１は、全体の動作をボリューム仮想化プログラム１３０９が制御し、ストレージバーチャライゼーション機能を提供する。記憶領域仮想化の実現方法の詳細は本発明の主眼ではないので、簡単に説明する。ディスクアレイが提供する複数のディスクボリュームから１つの仮想ボリュームを作成する場合、各ディスクボリュームの記憶領域を結合し、１つの仮想ボリュームに見せる。各ディスクボリュームのアドレス空間が仮想ボリュームのアドレス空間の一部にマッピングされ、１つの連続したアドレス空間を実現する。バーチャライゼーションサーバ１３０１内の制御プログラムが、仮想ボリュームとそれを構成する実際のディスクボリュームの対応関係、および仮想ボリュームのアドレス空間と実際のディスクボリュームのアドレス空間の対応関係を管理する。仮想ボリュームは、ホストコンピュータにはＳＣＳＩのＬＵ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ）、すなわち通常のディスクボリュームとして認識される。ホストコンピュータがＲｅａｄまたはＷｒｉｔｅコマンドを発行して仮想ボリュームにアクセスすると、バーチャライゼーションサーバ１３０１が宛て先のディスクボリュームおよびアドレスを解釈し、実際のディスクボリュームにコマンドを発行する。アクセス先が複数のディスクボリュームにまたがる領域である場合は、複数のコマンドを発行する。これにより、複数のディスクボリュームを結合した１つの仮想ボリュームが実現できる。
【００１８】
また、バーチャライゼーションサーバ１３０１は、ディスクアレイの機能を制御するための共通インタフェースを実現するために、仮想ボリューム管理表１３１３、ディスクボリューム管理表１３１２、インタフェース対応表１３１０、機能制御プログラムライブラリ１３１１、共通インタフェース管理表１３１４を持つ。これらの詳細については、後述する。
【００１９】
（２）ディスクアレイ装置の機能制御の説明
ミラー機能を例にディスクアレイの機能制御について説明する。ミラー機能は２つのディスクボリュームの一方を主ボリューム、他方を副ボリュームとして扱いデータの二重化を行う機能で、初期化、中断、再同期、解消、状態取得の５つの制御が可能である。
【００２０】
例えば、ディスクアレイ１４０１のボリューム１４０５を主ボリューム、１４０６を副ボリュームとするペアとすると、まずミラーの初期化が指示されると、主ボリューム１４０５の内容を全て１４０６にコピーする。初期化終了後、主ボリュームの内容が更新されると、コントローラ１４０４は対応する副ボリューム１４０６の内容も自動的に更新する。ミラーの中断が指示されると、１４０５のデータを更新しても１４０６は自動更新されず、１４０６には中断指示時のデータが保存される。再同期を指示すると、２つのボリュームが同一の内容をもつように中断中に主副間で差異が生じた部分をコピーする。解消を指示すると、主副のペアが解消され、再び初期化を指示されない限りミラー機能が無効化される。状態取得を指示すると、コントローラ１４０４は、初期化処理中、中断中、エラー状態などの現在の状態を返す。状態は、制御指示と同様にあらかじめ定義されたデータ型で制御インタフェースを通して返される。
【００２１】
ディスクアレイ１４０１では、ＬＡＮインタフェース１４０３が各機能の制御インタフェースとして提供され、外部からあらかじめ決められたプロトコルで指示を受け、それに基づいてコントローラ１４０４が機能制御を行う。ＬＡＮインタフェースのあらかじめ決められたポートに、例えば図５で示されるような制御ブロックを受け取ると、コントローラの制御プログラム１４０７が１バイト目５１０１に格納されているコマンドを解釈し、指示の操作内容を判別する。コマンドに続くパラメータフィールド５１０２〜５１０４は、操作対象のディスクボリューム等、指示を実行するために必要なパラメータを記録するフィールドとして、あらかじめコマンド毎にデータの意味が定義されている。これにより、ＬＡＮインタフェース１４０３に図５で示される制御ブロックを送ることで、外部からディスクアレイ１４０１の機能を制御することが可能となる。
【００２２】
ディスクアレイ１５０１ではＬＡＮインタフェースがなく、機能制御の指示はファイバチャネルインタフェース１５０２を介して、制御対象のディスクボリュームへのＳＣＳＩ  Ｍｏｄｅ  Ｓｅｌｅｃｔコマンドとして送られる。状態取得は対象ボリュームへのＭｏｄｅ  Ｓｅｎｓｅコマンドで指示され、状態はＳｅｎｓｅデータとして返送される。
【００２３】
（３）共通インタフェースの説明
バーチャライゼーションサーバが提供する共通インタフェースは、ディスクアレイ装置が提供する機能制御インタフェースと同様にさまざまな方法で実現可能であるが、本実施形態ではホストコンピュータからはファイバチャネルで接続されたディスクボリュームとして認識される仮想ボリュームとして実現する例を説明する。
【００２４】
ホストコンピュータは、共通インタフェースを他の仮想ボリュームと同様に読み書き可能な記憶領域として認識し、ＲｅａｄおよびＷｒｉｔｅコマンドを発行することにより制御情報をやりとりする。ただし、実際の記憶領域となるディスクボリュームは割り当てられず、ボリューム仮想化プログラム１３０９によりアドレス空間のみ提供される。ホストコンピュータから図８のようなデータ構造をもつ制御ブロックを、共通インタフェースである仮想ボリュームの、例えば先頭５１２バイトに書くことで機能制御を指示する。図８のコマンド８１０１はミラー機能、スナップショット機能など、制御する機能を表し、サブコマンド８１０２は、例えばミラー機能の場合初期化、中断などの指示を表す。コマンドおよびサブコマンドは、各機能および指示に対してあらかじめ番号を定義しておくことにより、番号で指定する。また、仮想ボリューム識別子８１０３および８１０４は、機能を適用する仮想ボリュームの識別子の指定に利用する。例えばミラーの初期化の場合、仮想ボリューム識別子８１０３は主ボリューム、仮想ボリューム識別子８１０４は副ボリュームを指定する。対象となる仮想ボリュームの指定方法は、識別子に限らず、仮想ボリュームを一意に識別できる情報であればよく、例えば、仮想ボリュームに割り当てられたバーチャライゼーションサーバのファイバチャネルインタフェースのＷＷＮとＬＵＮで指定する形態も可能である。その他のパラメータ８１０５〜８１０６はそれ以外に必要な情報を指定するための領域として使用される。
【００２５】
ボリューム仮想化プログラム１３０９は、共通インタフェースの先頭５１２バイトへのＷｒｉｔｅコマンドを受け取ると、機能制御の指示とみなし、先頭５１２バイトを図８のデータ構造に従って解釈する。先頭５１２バイト以外へのＷｒｉｔｅは、エラーとなる。また、バーチャライゼーションサーバからホストコンピュータへ仮想ボリュームの状態等の情報を受け渡す場合は、ホストコンピュータから共通インタフェースにＲｅａｄコマンドを発行する。その場合、情報はＲｅａｄコマンドに対するデータとして返され、特に図には示さないが、Ｗｒｉｔｅコマンドで書かれる制御ブロックと同様に、あらかじめ定義されたデータ構造が用いられる。
【００２６】
管理者は、共通インタフェースに割り当てるファイバチャネルインタフェースのＷＷＮおよびＬＵＮを、ホストコンピュータの仮想ボリューム機能制御プログラムのパラメータとして設定する。あるいは、ホストコンピュータ上の仮想ボリューム機能制御プログラムがファイバチャネルインタフェースに接続された各ＬＵにＩｎｑｕｉｒｙコマンドを発行し、あらかじめ定義された共通インタフェースに固有なベンダＩＤやプロダクトＩＤを返すＬＵを探すことにより、共通インタフェースを自動で特定することもできる。
【００２７】
共通インタフェースを実現するために、バーチャライゼーションサーバは仮想ボリューム管理表１３１３、ディスクボリューム管理表１３１２、インタフェース対応表１３１０、機能制御プログラムライブラリ１３１１、共通インタフェース管理表１３１４を持つ。共通インタフェース管理表１３１４は、図１２に示す構成を持ち、共通インタフェースに割り当てられたファイバチャネルインタフェースのＷＷＮとＬＵＮを管理する。ここで記録されたＷＷＮ（ファイバチャネルインタフェースに割り当てられたもの）とＬＵＮの組み合わせは、他の仮想ボリュームでは使用できない。複数の共通インタフェースを定義することにより、例えば、ホストコンピュータ毎に異なる共通インタフェースを割り当てることもできる。
【００２８】
仮想ボリューム管理表１３１３は図２に示すような構成を持ち、各仮想ボリュームと、それを構成する実際のディスクボリュームの対応関係を管理する。各仮想ボリュームには、識別子として一意な通し番号が振られる（２１０１）。また、ホストコンピュータがその仮想ボリュームにアクセスするために割り当てられるバーチャライゼーションサーバのファイバチャネルポートのＷＷＮ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ）と（２１０２）、仮想ボリュームのＬＵＮ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ）が記録される（２１０３）。さらに、表の２１０４〜２１０７には仮想ボリュームを構成する実際のディスクボリュームの識別子（通し番号）が記録される。図２の仮想ボリューム１の例では、仮想ボリューム１はＷＷＮがｗｗｎ３のポートからｌｕｎ１のＬＵＮでアクセスされ、識別子が１および３の２つのディスクボリュームから構成される。Ｖｏｌ．１は一つ目のディスクボリュームを、Ｖｏｌ．２は２つ目のディスクボリュームを示す。制御処理の項目（２１０８）は、その仮想ボリュームがなんらかの機能制御を処理中であるかどうかのフラグである。処理中であれば「処理中」が記録される。
【００２９】
ディスクボリュームは、仮想ボリュームとは別に図３のような構成を持つディスクボリューム管理表１３１２で管理される。各ディスクボリュームは識別子として一意な通し番号を持ち（３１０１）、そのディスクボリュームに割り当てられたディスクアレイ装置のファイバチャネルポートのＷＷＮ（３１０２）と、そのディスクボリュームのＬＵＮ（３１０３）および容量（３１０４）が記録される。また、そのディスクボリュームを提供するディスクアレイ装置の機種（３１０５）と装置識別子が記録される（３１０６）。機種情報は、例えば、Ｉｎｑｕｉｒｙコマンドに対して返されるベンダＩＤやプロダクトＩＤのような、装置の種別に固有な情報である。一般に機種が変わるとプロトコルも変わる。装置識別子は、ディスクアレイ装置毎に割り当てられる一意な通し番号である。３１０７〜３１１２には、各ボリュームを対象としてさまざまな機能を制御する場合に使用するＡＰＩとディスクアレイ装置が提供する機能制御インタフェースが記録される。３１０８、３１１０、３１１２のインタフェースは、例えばディスクアレイのＬＡＮポートに制御パケットを送るインタフェースである場合はＩＰアドレスとポート番号を、制御対象のディスクボリュームにＭｏｄｅ  ＳｅｌｅｃｔやＭｏｄｅ  Ｓｅｎｓｅで指示を送る場合はそのディスクボリュームに割り当てられているＷＷＮやＬＵＮを記録する。
【００３０】
各ＡＰＩは、機能制御プログラムライブラリ１３１１で提供され、例えば、図９の構造体を引数とし、制御プログラム１３０９に動的にリンクされる関数として実現される。関数を機能制御ライブラリ１３１１から読み出す。その関数がＡＰＩとして表される。各ＡＰＩは、目的の機能を実現するために、対象となるディスクボリュームを提供しているディスクアレイ装置固有のプロトコルでディスクアレイに指示を送る。制御指示として送られるデータの構造は、装置毎に定義されているため、各ＡＰＩは図９の共通インタフェースのデータ構造から図５のような装置固有のパラメータに変換する論理を含む。また、特に図では示さないが、ＡＰＩ呼び出しからの戻り値が必要な場合も、呼び出し引数と同様に共通のデータ構造で値が返される。
【００３１】
図３のディスクボリューム管理表の各エントリは、バーチャライゼーションサーバが新しいディスクボリュームを認識する際にバーチャライゼーションサーバの管理者が作成する。ただし、項目のいくつかは、管理者の操作に頼らずボリューム仮想化プログラムがボリューム管理表へ自動的に登録することもできる。例えば、ファイバチャネルインタフェースに接続されたＬＵを走査し、そのＷＷＮ、ＬＵＮを検出したり、各ディスクボリュームにＳＣＳＩ  Ｒｅａｄ  Ｃａｐａｃｉｔｙコマンドを発行することで容量を得たりすることができる。機種情報はＳＣＳＩ  Ｉｎｑｕｉｒｙコマンドをディスクボリュームに発行し、ベンダＩＤやプロダクトＩＤを取得して記録することができる。また、各ＡＰＩは、あらかじめ機種情報と使用するＡＰＩの対応関係を図４のようなインタフェース対応表１３１０としてインストールしておくことにより、装置識別子に応じて必要なＡＰＩをディスクボリューム管理表に記録することができる。
【００３２】
（４）  共通インタフェースを利用したミラー初期化
共通インタフェースを利用してディスクアレイ装置の機能を制御する例を、仮想ボリュームのミラー初期化を例に説明する。
【００３３】
共通インタフェースを用いた機能制御について説明する前に、その前段階として、本実施形態における仮想ボリュームの作成手順をボリューム仮想化プログラム１３０９の一部をなす図６のフローチャートを用いて説明する。バーチャライゼーションサーバに新しいディスクボリュームが接続されると、まずボリューム仮想化プログラムがそれをファイバチャネルインタフェースに接続されたデバイスとして認識する（ステップ６００１）。次に、そのディスクボリュームのＷＷＮ、ＬＵＮ、装置識別子、機能制御のＡＰＩを、前述のように管理者もしくはボリューム仮想化プログラムがディスクボリューム管理表に登録する（ステップ６００２）。登録したディスクボリュームから仮想ボリュームを作成すると、そのＷＷＮ、ＬＵＮおよび使用されるディスクボリュームを仮想ボリューム管理表に登録する（ステップ６００３）。最後に、ホストコンピュータから仮想ボリュームを認識することにより、仮想ボリュームがホストコンピュータの記憶領域として使用可能になる。
【００３４】
図１において、上記のような手順により、仮想ボリューム１がホストコンピュータ１１０１に提供され、仮想ボリューム２がホストコンピュータ１２０１に提供されている場合に、仮想ボリューム１および２をペアとするミラーを初期化する例を、同じくボリューム仮想化プログラムの一部である図７のフローチャートを用いて説明する。
【００３５】
まず、ステップ７００１でホストコンピュータから共通インタフェースにＷｒｉｔｅコマンドを発行し、先頭５１２バイトに図８の制御ブロックを書く。制御ブロックのコマンド８１０１にはミラー機能を指定し、サブコマンド８１０２には初期化を指定する。仮想ボリューム識別子１、２（８１０３、８１０４）には仮想ボリューム１および２の識別子を指定する。この制御ブロックを、図１２の共通インタフェース管理表に記録されたファイバチャネルポートのＬＵに受信すると、バーチャライゼーションサーバのボリューム仮想化プログラムはミラー機能の初期化指示であることを判別し（ステップ７００２）、ボリューム仮想化プログラム内のミラーの初期化用の処理ルーチンを実行する。定義されていないコマンドを含む制御ブロックのＷｒｉｔｅはエラーとなる。ミラー初期化用の処理ルーチンは、制御ブロックの仮想ボリューム識別子８１０３および８１０４を参照して、制御対象となる仮想ボリュームを特定する（ステップ７００３）。
【００３６】
ここで、仮想ボリューム管理表を参照し、対象の仮想ボリュームが他の機能制御を処理中であるか調べる（ステップ７０１２）。既に他の処理中であれば、ステップ７０１０に進む。処理中でなければ、仮想ボリューム管理表の制御処理の項目に「処理中」を記録する（ステップ７０１３）。さらに、仮想ボリューム管理表を参照し、それぞれの仮想ボリュームを構成するディスクボリュームを特定する（ステップ７００４）。図２の仮想ボリューム管理表の例では、仮想ボリューム１はディスクボリューム１と３、仮想ボリューム２はディスクボリューム２と４から構成されていることがわかる。
【００３７】
次に、ステップ７００５において、ディスクボリュームをミラーのペアとして組み合わせる。ディスクボリュームがミラーのペアとなるためには主ボリュームと副ボリュームが同じディスクアレイ装置内に存在し、さらにボリュームの容量が等しくなければならない。各ボリュームの容量および提供しているディスクアレイ装置は、ディスクボリューム管理表の容量および装置識別子から確認できる。主ボリュームとなるディスクボリューム群と、副ボリュームとなるディスクボリューム群の中から、それぞれ前記の条件を満たすものをミラーのペアとして組み合わせる。もし、容量が一致しないペアや同じ装置内に存在しないペアがあった場合は、ミラーの初期化失敗として終了する（ステップ７００６）。条件を満たす組み合わせが複数ある場合、例えば、主ボリュームおよび副ボリュームとなる仮想ボリュームがそれぞれ、ディスクボリューム１と３および２と４で構成され、ディスクボリューム１と２および３と４でペアを組むことが可能で、一方、ディスクボリューム１と４および３と２でもペア形成が可能であるような場合も考えられる。そのような場合、ディスクボリュームの識別子が最も小さいもの同士を組み合わせる。前記の例の場合、主ボリュームとなるディスクボリュームは識別子の小さい順に１、３であり、副ボリュームについては同様に２、４となる。従って、識別子が小さい順に１と２、３と４がペアとなる。このようにすることで、別の機能指示の際にディスクボリューム同士のペア関係を知る必要がある場合にも、同じ仮想ボリュームペアについては必ず初期化処理と同じディスクボリュームのペアが得られる。
【００３８】
ミラーが組めることを確認したら、全ての組み合わせについて、ディスクアレイ装置にミラー初期化の指示を送る。各ペアについて、制御ＡＰＩを呼び出す際に引数となる図９の構造を持つ制御データを作成する（ステップ７００７）。ディスクボリューム管理表から、各ディスクボリュームに対する制御指示に使用されるＡＰＩおよびインタフェースを調べ、前述の制御データとインタフェースを引数としてＡＰＩを呼び出す（ステップ７００８）。例えば、ディスクボリューム１、２のペアについては、ディスクボリューム管理表を参照して、登録されたＩＰアドレスとポート番号を制御インタフェースとするｆｕｎｃ１のＡＰＩにより初期化を指示する。これを全てのペアについて繰り返す（ステップ７００９）。全てのペアに指示したら、仮想ボリューム管理表の「処理中」の記録を削除する（ステップ７０１４）。最後に、制御の指示が完了したことをホストコンピュータに伝える。これは、共通インタフェースへのＷｒｉｔｅコマンドに対するステータス返送として実現する（ステップ７０１０）。
【００３９】
このように、ステップ７００２においてホストコンピュータから共通インタフェースで受信した制御ブロックを、ステップ７００７とステップ７００８においてディスクボリューム固有のプロトコルに変換してミラー初期化指示を出している。上記の手順により、複数のディスクボリュームから構成されている仮想ボリュームのミラー機能を、ディスクアレイ装置の種類にかかわらず共通のインタフェースから制御することが可能となる。
【００４０】
（５）  共通インタフェースを利用したミラーの状態取得
ある仮想ボリュームのミラーの状態を取得する場合も、前述のミラーの初期化と同様の手順で、ホストコンピュータから共通インタフェースに指示を送り、バーチャライゼーションサーバがディスクアレイ装置からミラーの状態を取得するためのＡＰＩを呼び出す。ただし、状態取得の場合は、バーチャライゼーションサーバが各ディスクアレイ装置から取得したディスクボリュームのミラーの状態を仮想ボリュームのミラーの状態に変換し、ホストコンピュータに伝える必要がある点が異なる。
【００４１】
ミラーの状態取得の手順を、図１０のフローチャートを用いて説明する。図１０もボリューム仮想化プログラム１３０９の一部である。ステップ１０００１〜１０００６までは図７のステップ７００１〜７００５と同様である。ステップ１０００８〜１００１０で、各ディスクボリュームのミラーペアの状態を取得する。次に、これらの状態から仮想ボリュームのミラーペアの状態を作成する（ステップ１００１１）。例えば、ディスクボリュームのミラーペアの状態が初期化前の「無効」、初期化処理中である「初期化」、初期化が完了し主副が同じデータを持つ「同期」、ミラーを中断している「中断」、中断から再び同期状態に戻す処理中である「再同期」、障害が起きている「エラー」の６つの状態であるとすると、仮想ボリュームのミラーペアの状態は図１１のように作成することができる。全てのディスクボリュームのミラーペアが一致した場合は、仮想ボリュームのミラーペアの状態もその状態になる。もし一致しない状態があれば、ディスクボリュームのミラーペアの状態の整合性が取れていないため、仮想ボリュームのミラーペアの状態は「エラー」となる。ただし、初期化処理および再同期処理では、全てのディスクボリュームのミラーペアが同時に処理を終えるとは限らないため、早く処理が終わったミラーペアの状態は「同期」となる可能性がある。その場合は不一致があっても仮想ボリュームのミラーペアの状態をエラーではなく、それぞれ「初期化」および「再同期」とする。
【００４２】
仮想ボリュームのミラーペアの状態を作成したら、仮想ボリューム管理表の「処理中」の記録を削除し（ステップ１００１２）、ホストコンピュータにステータスを返す（ステップ１００１３）。このステータスとはＳＣＳＩプロトコルの一部として規格で定義されたもので、通常エラーがなければＧｏｏｄ（バイトコード＝０００００）が返される。これにより、ホストコンピュータの仮想ボリューム機能制御プログラムは状態取得処理の完了を認識し、状態を読み出すために共通インタフェースにＲｅａｄコマンドを送る。バーチャライゼーションサーバのボリューム仮想化プログラムは、ステップ１００１１で作成した仮想ボリュームのミラーペアの状態をＲｅａｄコマンドに対するデータとして返送し（ステップ１００１５）、最後にステータスを返す（ステップ１００１６）。
【００４３】
上述のように、図１１は仮想ボリュームのミラー状態と、仮想ボリュームを構成する実際のディスクボリューム群のミラー状態の対応表である。図１０のステップ１０００８〜１００１０で取得した実際のディスクボリューム群のミラー状態を図１１に照らし合わせて仮想ボリュームのミラー状態を作成する（ステップ１００１１）。図１１の対応表による変換がプロトコルの変換にあたる。
【００４４】
上記の手順により、バーチャライゼーションサーバからホストコンピュータへ情報を渡す必要がある機能制御も実現することができる。
【００４５】
（６）  効果
本実施形態により、異なる機能制御インタフェースを持つ複数のディスクアレイ装置が存在するストレージバーチャライゼーション環境において、仮想ボリューム単位でミラー機能などのストレージ機能を適用することができる。その際、構成する記憶領域が、どの装置に存在するかを意識することなく、共通の方法で機能制御を指示することができる。
【００４６】
なお、本実施形態ではストレージバーチャライゼーションの基本機能と、機能制御の共通インタフェースが同じバーチャライゼーションサーバで提供されているが、それぞれの機能を個別の装置内で実現することも可能である。また、サーバに限らず、同様のストレージバーチャライゼーション機能を持つスイッチ装置等に適用することもできる。ここでは、これらを記憶装置の接続装置と呼ぶ。さらに、ディスクボリューム単位の制御に限らず、例えば、ディスクアレイをファイルサーバ、ファイバチャネルとＳＣＳＩプロトコルをＬＡＮとＮＦＳプロトコル、バーチャライゼーションサーバ内の管理単位をファイルシステム、共通インタフェースをＬＡＮインタフェースとすることにより、ファイルシステム単位での機能制御にも適用することができる。
【００４７】
第二の実施形態
本実施形態の構成は、図１の第一の実施形態とほぼ同様であるが、バーチャライゼーションサーバで複数の共通インタフェースを提供する。また、バーチャライゼーションサーバがディスクアレイ装置に制御を指示するときに、一部のディスクボリュームに対する指示が失敗した場合に、エラー処理を実行する手段を備える。以下、第一の実施形態と異なる点のみを説明する。
【００４８】
（１）  複数の機能制御インタフェース
本実施形態では、バーチャライゼーションサーバが２つの共通インタフェースをホストコンピュータに提供する。第一の実施形態で説明した仮想ボリュームによるインタフェースに加え、図１のＬＡＮインタフェース１３０６を利用したＬＡＮ経由のインタフェースを提供する。共通インタフェース管理表１３１４は、図１２の構成の表に加えて、図１３の構成の表も持つ。図１３の表に記録されたＬＡＮインタフェース（ＩＰアドレス）とポート番号の組み合わせをあて先とする入力データは、機能制御ブロックとして解釈される。ＬＡＮインタフェースで共通インタフェースを実現する場合、第一の実施形態でファイバチャネル上のＳＣＳＩコマンドおよびデータの送受信で実現したように、イーサネット（ゼロックス社の登録商標）上のデータ送受信で実現する。ＳＣＳＩのステータスの代わりに、処理の終了を示すために確認のパケット（ａｃｋｎｏｗｌｅｄｇｅ）を返す。この第二の共通インタフェースを利用することにより、例えばファイルシステムを介さないところのファイバチャネルインタフェースへの入出力が不可能なホストコンピュータでは、ＬＡＮインタフェースを利用した機能制御指示が可能となる。即ち、ファイバチャネルインタフェースの入出力がファイルシステム経由でのみ可能なホストコンピュータでは全ての入出力はファイル操作となるため、ユーザが入出力のアドレスやパケットのデータ構造を指定することが出来ず、共通インタフェースに制御パケットを送ることが出来ない。そのようなホストコンピュータでは、ＬＡＮインタフェースを利用することで共通インタフェースに制御パケットを送ることが出来る。
【００４９】
図１のホストコンピュータ１２０１上の仮想ボリューム機能制御プログラム１２０６は、ＬＡＮ通信の機能を持ち、仮想ボリュームとして提供される第一の実施形態の共通インタフェースではなく、ＬＡＮインタフェースを利用して実現された共通インタフェースにアクセスする機能を持つ。共通インタフェースのＩＰアドレスおよびポート番号は、第一の実施形態における共通インタフェースのＷＷＮとＬＵＮと同様に、管理者が仮想ボリューム機能制御プログラムに設定する。
【００５０】
ディスクアレイ１４０１は、第一の実施形態で説明したＬＡＮインタフェースによる機能制御に加え、ディスクアレイ１５０１と同様にファイバチャネルインタフェース経由でのＭｏｄｅ  Ｓｅｌｅｃｔ／Ｍｏｄｅ  Ｓｅｎｓｅコマンドによる機能制御方法を提供する。すなわち、バーチャライゼーションサーバ上のボリューム仮想化プログラムは、ＬＡＮ経由もしくはファイバチャネル経由のどちらでもディスクアレイ１４０１に機能制御の指示を送ることが可能である。
【００５１】
バーチャライゼーションサーバ内のボリューム管理表は、ディスクアレイ１４０１の複数の制御インタフェースに対応するために変更される。また、機能制御を指示したときにエラーが発生した場合の回復処理を定義するための項目が追加される。変更したディスクボリューム管理表を図１４に示す。図１４で１４１０１から１４１０６までの項目は、図３のボリューム識別子３１０１から装置識別子３１０６までの項目に対応し、変更はないので説明を省略する。１４１０７は機能制御を指示する際に呼び出すＡＰＩであるが、ディスクアレイ１４０１のように複数の制御インタフェースを持つ装置のディスクボリュームについては、それぞれのインタフェースに対応する複数のＡＰＩを登録する。図１４の例では、ディスクボリューム１を提供し、装置識別子Ａで表されるディスクアレイは２つの制御インタフェースを持ち、ミラー初期化のＡＰＩとしてそれぞれｆｕｎｃ１とｆｕｎｃ５を登録する。一方、装置識別子Ｂで表されるディスクアレイは制御インタフェースを１つしか持たないため、ＡＰＩも１つ（ｆｕｎｃ５のみ）を登録する。また、それぞれのＡＰＩで利用する制御インタフェースを１４１０８に記録する。
【００５２】
１４１０９のＲｅｃｏｖｅｒｙ  ＡＰＩは、エラー処理を行う際に呼び出すＡＰＩである。例えば、２つのディスクボリュームからなる仮想ボリュームを対象とする機能制御を指示し、一方のディスクボリュームに対する制御が成功し他方の制御が失敗した場合に、仮想ボリュームの状態を指示前の状態に戻すために、成功した方の指示を取り消すときに使用する。Ｒｅｃｏｖｅｒｙ  ＡＰＩはＡＰＩと同じ引数で呼び出され、ＡＰＩと同様の方法で登録する。
（２）  エラー処理
本実施形態における機能制御の指示の手順は、第一の実施形態とほぼ同様であるが、ディスクアレイが提供する複数の制御インタフェースと、あらかじめボリューム管理表に登録したＲｅｃｏｖｅｒｙ  ＡＰＩを利用したエラー処理を行う点が異なる。以下、ミラー初期化指示の手順について第一の実施形態からの変更部分のみ説明する。ボリューム管理表のミラー初期化のＲｅｃｏｖｅｒｙ  ＡＰＩには、ミラーの解消を指示するＡＰＩがあらかじめ登録されているとする。
【００５３】
図１５は、図７のミラーの初期化処理の、ステップ７００６とステップ７０１４の間の変更部分を示したものである。ステップ１５００１で制御指示を送る、ディスクボリュームのミラーペアを１つ選び、ボリューム管理表からそのディスクボリュームのミラー初期化指示に使用するＡＰＩを１つ選ぶ（ステップ１５００２）。そのＡＰＩを呼び出し（ステップ１５００２）、呼び出しが成功であれば全てのディスクボリュームのミラーペアについて同様の処理を繰り返す（ステップ１５００３、１５００４）。もしＬＡＮやファイバチャネルケーブルの切断などの理由でディスクアレイへの制御が指示できず、ＡＰＩの呼び出しが失敗したら、別のＡＰＩをボリューム管理表から選択し、リトライする（ステップ１５００５）。これはＡＰＩが１つのディスクボリュームに対していくつかあるので、試していないＡＰＩがあるかを判定するものである。失敗は、タイムアウトやディスクアレイからのエラーステータスの受信で認識できる。ボリューム管理表に登録されている全てのＡＰＩで呼び出しが失敗したら、これまでにＡＰＩ呼び出しが成功したディスクボリュームのミラーペアについてＲｅｃｏｖｅｒｙ  ＡＰＩを呼び出し、ミラーの解消を指示する（ステップ１５００６、１５００７）。このＲｅｃｏｖｅｒｙ  ＡＰＩの呼び出しを、ＡＰＩ呼び出しが成功した全てのディスクボリュームのミラーペアについて繰り返す（ステップ１５００８）。全てのＡＰＩ呼び出しが成功、もしくはエラー処理がすべて完了したら、ステップ７０１４以降の終了処理に進む。
【００５４】
（３）  効果
本実施形態では、バーチャライゼーションサーバが複数の共通インタフェースを提供することにより、ホストコンピュータが使用する通信手段を選択することができる。そのため、各ホストコンピュータが制御指示を送るために利用できる通信手段が異なる場合にも、第一の実施形態と同様の効果が得られる。また、複数のディスクボリュームから構成される仮想ボリュームを対象とする機能を制御する場合、ディスクアレイに複数の制御指示を送り、その一部が失敗したときに、既に成功した指示を取り消し、仮想ボリュームを一貫性の取れた状態に戻すことができる。なお、本実施形態では各ＡＰＩに対して単一のＲｅｃｏｖｅｒｙ  ＡＰＩを定義したが、エラー状態毎に使用するＲｅｃｏｖｅｒｙ  ＡＰＩを定義することもできる。言い換えれば、第三の実施形態では図１４に示すように、ある１つのＡＰＩによる処理を取り消すＡＰＩとして１つのＲｅｃｏｖｅｒｙ  ＡＰＩを定義している。しかし、１つのＡＰＩに対して複数のＲｅｃｏｖｅｒｙ  ＡＰＩを定義するような実装も考えられる。例えば、通信路障害によるエラー状態と、ストレージ装置のコントローラ障害によるエラー状態では別のＲｅｃｏｖｅｒｙ  ＡＰＩを用いることが考えられる。このように複数のＲｅｃｏｖｅｒｙ  ＡＰＩをエラーの種類によって使い分けることも出来る。また、本実施形態では、ＡＰＩの呼び出しが成功した制御対象にはＲｅｃｏｖｅｒｙ  ＡＰＩを使用しないが、必要に応じて、ＡＰＩ呼び出しが成功した場合に使用するＲｅｃｏｖｅｒｙ  ＡＰＩを定義することもできる。
【００５５】
第三の実施形態
本実施形態は、本発明をファイバチャネルネットワークによるＳＡＮ環境に適用し、ディスクボリュームの機能制御に共通インタフェースを利用する例である。バーチャライゼーションサーバではなく、ファイバチャネルスイッチで共通インタフェースを提供する。さらに、機能制御のログを管理コンソールで記録し、ホストコンピュータから指示できる制御を制限するセキュリティ機能を提供する。本実施形態では、共通インタフェースとして、制御の対象となるボリュームへのＭｏｄｅ  ＳｅｌｅｃｔおよびＭｏｄｅ  Ｓｅｎｓｅコマンドの送信により機能制御を指示する。
【００５６】
（１）  システムの構成
図１６に本実施形態の全体構成を示す。
【００５７】
ホストコンピュータ１６１０１、１６２０１およびディスクアレイ１６４０１、１６５０１の構成、動作は、第一の実施形態と同様であり、ファイバチャネルスイッチ１６３０１に接続されている。ただし、ホストコンピュータ上の仮想ボリューム機能制御プログラムは、第一実施形態とは異なり、Ｒｅａｄ、Ｗｒｉｔｅコマンドではなく、Ｍｏｄｅ  Ｓｅｌｅｃｔ、Ｍｏｄｅ  Ｓｅｎｓｅコマンドを送信する。それぞれのページコードには、あらかじめ機能制御用に定義したベンダユニークな番号を使用する。パラメータリストには、図１７のような構造のデータを用いる。Ｍｏｄｅ  ＳｅｌｅｃｔやＭｏｄｅ  Ｓｅｎｓｅコマンドは、制御対象となるボリュームに送るため、制御対象をパラメータリスト内で指定する必要はない。ミラーペアの初期化のように、２つのボリュームを指定する必要がある制御では、パラメータリスト内で２つ目のボリュームを指定する。そのようなボリュームは、例えば、制御対象ボリュームに割り当てられているディスクアレイのポートのＷＷＮとＬＵＮをパラメータリストの一部として指定する。
【００５８】
ファイバチャネルスイッチ１６３０１について、通常のファイバチャネルスイッチと異なる点を説明する。ホストコンピュータやディスクアレイと接続するためのファイバチャネルポートを提供するポートモジュール１６３０２は、ファイバチャネルインタフェース１６３１０とインタフェース制御プロセッサ１６３１１から構成される。インタフェース制御プロセッサ１６３１１は、共通インタフェースへの制御指示を受け取ると、ＣＰＵ１６３０７に通知する。具体的には、ファイバチャネルインタフェースで受信されたＳＣＳＩコマンドのＣＤＢ（Ｃｏｍｍａｎｄ  Ｄｅｓｃｒｉｐｔｏｒ  Ｂｌｏｃｋ）を解釈し、受信したコマンドが機能制御用として定義されたページコードを持つＭｏｄｅ  Ｓｅｌｅｃｔ、Ｍｏｄｅ  Ｓｅｎｓｅコマンドであれば、共通インタフェースへのアクセスであると判断して、送信元ホストコンピュータのＷＷＮと、送信先ボリュームのＷＷＮおよびＬＵＮ、コマンドの内容をＣＰＵ１６３０７に通知する。
【００５９】
ＣＰＵ１６３０７はメモリ１６３０８内のスイッチ制御プログラム１６３１２を実行し、スイッチの動作を制御する。インタフェース対応表１６３１３、ボリューム制御プログラムライブラリ１６３１４、ボリューム管理表１６３１５は第一の実施形態と同様の構成である。これらを用いてスイッチ制御プログラム１６３１２がプロトコル変換を行う。詳細は第一、第二の実施形態と同じであるため省略する。本実施形態では、ストレージバーチャライゼーション機能はないため、仮想ボリューム管理表は持たない。また、制御対象となるディスクボリューム自体がホストコンピュータからの制御コマンドのあて先、すなわち共通インタフェースとなるため、共通インタフェース管理表も持たない。
【００６０】
制御権限管理表１６３１６は、図１８のように構成され、各ディスクボリュームを対象とする機能制御について、制御を指示することのできるホストコンピュータをファイバチャネルインタフェースのＷＷＮで指定する。図１８の例では、ディスクボリューム１に対するミラー初期化および中断の制御は、ｗｗｎ１およびｗｗｎ２のＷＷＮを持つホストコンピュータが指示することができる。また、スナップショットの取得については、ｗｗｎ２のホストコンピュータのみ指示できることを表している。これらの情報は、管理者が登録・変更する。
【００６１】
スイッチ制御プログラム１６３１２は、共通インタフェースを介した制御指示を受け取ると、ＬＡＮインタフェース１６３０９から、あらかじめ管理者により設定されたＩＰアドレスとポート番号で指定される管理コンソール１６６０１に制御記録を通知する。通知内容には、時刻、制御の指示元、制御の許可および不許可、制御対象、制御内容、ディスクアレイへの指示に用いられたインタフェース、および制御の成功／失敗を識別する情報が含まれる。
【００６２】
管理コンソール１６６０１では、制御記録を蓄積するためのログ記録プログラム１６６０５がＣＰＵ１６６０２により実行されている。ログ記録プログラムは、ファイバチャネルスイッチからの制御記録がＬＡＮインタフェース１６６０３に到着するのを待ち、それをログファイル１６６０６に記録する。また、ログ記録プログラムは、管理者が記録された情報を閲覧するために、ログを表示する機能を持つ。
【００６３】
（２）  共通インタフェースへの制御指示の制限とログの記録
本実施形態において、Ｍｏｄｅ  Ｓｅｌｅｃｔコマンドによりディスクボリュームの機能制御を指示するスイッチ制御プログラム１６３１２の処理の流れを図１９のフローチャートを用いて説明する。
【００６４】
まず、ホストコンピュータ上の仮想ボリューム制御プログラムが、制御対象となるディスクボリュームにＭｏｄｅ  Ｓｅｌｅｃｔコマンドを送る（ステップ１９００１）。Ｍｏｄｅ  Ｓｅｌｅｃｔのページコードには、機能制御用としてあらかじめ割り当てたコードを用い、図１７に示す制御ブロックをパラメータリストとして送る。ファイバチャネルスイッチのポートモジュールは、通常はスイッチモジュールを介して他のポートモジュールにコマンドをフォワードするが、コマンドが機能制御用ページコードを持つＭｏｄｅ  Ｓｅｌｅｃｔであることを検出すると、コマンドの内容とその送信元のＷＷＮおよび送信先のＷＷＮとＬＵＮをＣＰＵに通知する（ステップ１９００２）。スイッチのＣＰＵは、ステップ１９００３で、機能制御が、指示の送信元に対して、許可されていることを確認する。まずディスクボリューム管理表を参照し、送信先ボリュームのＷＷＮおよびＬＵＮから制御対象のボリュームの識別子を求める。次に、制御権限管理表を参照し、そのボリュームを対象とする、制御ブロックで指定された制御機能が送信元のＷＷＮに対して許可されていることを確認する。
【００６５】
もし、制御を許可するＷＷＮの一覧に、指示の送信元ＷＷＮが記録されていなければ制御が許可されていないので、ＬＡＮインタフェースから管理コンソールのログ記録プログラムに指示を拒否したという記録を送信し（ステップ１９００４）、ステップ１９０１０に進む。一方、制御が許可されていれば、第一の実施形態と同様に、ディスクボリューム管理表に登録されているＡＰＩおよび制御インタフェースを用いて、ディスクアレイに対して機能制御を指示する（ステップ１９００６）。ＡＰＩの呼び出し、すなわちディスクアレイの機能制御の成否を確認し（ステップ１９００７）、ＡＰＩ呼び出しの成功あるいは失敗をそれぞれステップ１９００８、１９００９でログに記録する。最後に、指示の送信元ホストコンピュータにＳＣＳＩステータスを返して（ステップ１９０１０）、処理を終了する。
【００６６】
（３）  効果
本実施形態により、ストレージバーチャライゼーションを用いない通常のＳＡＮ環境において、共通インタフェースを用いたディスクボリュームの機能制御が可能となる。また、各ディスクボリュームの機能毎に制御を許可するホストコンピュータを指定し、制御権限を管理することができる。さらに、制御の履歴をログに記録することができる。なお、本実施形態では、制御権限をホストコンピュータ単位で管理したが、他の管理単位にも適用可能である。例えば、制御権限管理表の制御許可対象をユーザＩＤで管理し、ホストコンピュータからの制御指示にユーザＩＤを含めることにより、ユーザ単位での権限管理ができる。また、本実施形態では、ログ情報を直ちに外部の管理コンソールに送信するが、スイッチ内部の記憶領域に蓄積し、定期的に管理コンソールに送信、あるいは管理コンソールから取得することも可能である。
【００６７】
以上述べたように、本発明の実施例によれば、各装置に固有のインタフェースは隠蔽され、ホストコンピュータは制御対象の装置の種類を意識することなく、共通のインタフェースを利用して機能を制御することが可能となる。これにより、制御指示を発行するプログラムの構成が簡単化される。
【００６８】
複数の共通インタフェースを提供することにより、ホストコンピュータが使用する通信手段を選択することができる。そのため、制御指示を送るために利用できる通信手段が異なる装置が混在する環境にも対応することができる。また、複数のディスクボリュームを対象とする一連の機能制御を指示する場合、その一部が失敗したときのために、エラー処理の機能制御を定義できる。
【００６９】
さらに、機能制御の種別および制御の対象毎に、制御を許可するコンピュータを管理することができる。また、制御の履歴をログに記録することができる。
【００７０】
【発明の効果】
以上述べたように、本発明によれば、各装置に固有のインタフェースは隠蔽され、ホストコンピュータは制御対象の装置の種類を意識することなく、共通のインタフェースを利用して機能を制御することが可能となる。これにより、制御指示を発行するプログラムの構成が簡単化される。
【図面の簡単な説明】
【図１】本発明の第一実施形態の全体構成図。
【図２】本発明の第一実施形態における仮想ボリューム管理表の構成を示す図。
【図３】本発明の第一実施形態におけるディスクボリューム管理表の構成を示す図。
【図４】本発明の第一実施形態におけるインタフェース対応表の構成を示す図。
【図５】本発明の第一実施形態におけるディスクアレイの制御ブロックの構成を示す図。
【図６】本発明の第一実施形態における仮想ボリューム作成のフローチャート。
【図７】本発明の第一実施形態におけるミラーペア初期化のフローチャート。
【図８】本発明の第一実施形態における共通インタフェースの制御ブロックの構成を示す図。
【図９】本発明の第一実施形態における制御ＡＰＩの引数データの構成を示す図。
【図１０】本発明の第一実施形態における仮想ボリュームの情報取得のフローチャート。
【図１１】本発明の第一実施形態におけるディスクボリュームと仮想ボリュームの状態の対応表。
【図１２】本発明の第一実施形態における共通インタフェース管理表の構成を示す図。
【図１３】本発明の第二実施形態における共通インタフェース管理表の追加部分の構成を示す図。
【図１４】本発明の第二実施形態におけるボリューム管理表の構成を示す図。
【図１５】本発明の第二実施形態におけるミラーペア初期化のフローチャート。
【図１６】本発明の第三実施形態の全体構成図。
【図１７】本発明の第三実施形態における共通インタフェースの制御ブロックの構成を示す図。
【図１８】本発明の第三実施形態における制御権限管理表の構成を示す図。
【図１９】本発明の第三実施形態におけるディスクボリュームの機能制御指示のフローチャート。
【符号の説明】
１１０１，１２０１  ホストコンピュータ
１３０１  バーチャライゼーションサーバ
１４０１，１５０１  ディスクアレイ
１１０６，１２０６  仮想ボリューム機能制御プログラム
１３０９  ボリューム仮想化プログラム
１３１０  インタフェース対応表
１３１１  機能制御プログラムライブラリ
１３１２ディスクボリューム管理表
１３１３  仮想ボリューム管理表
１３１４  共通インタフェース管理表
１４０４，１５０４  コントローラ
１４０５，１４０６，１５０５，１５０６  ディスクボリューム。
【図１】
2004192105.tif 000003
【図２】
2004192105.tif 000004
【図３】
2004192105.tif 000005
【図４】
2004192105.tif 000006
【図５】
2004192105.tif 000007
【図６】
2004192105.tif 000008
【図７】
2004192105.tif 000009
【図８】
2004192105.tif 000010
【図９】
2004192105.tif 000011
【図１０】
2004192105.tif 000012
【図１１】
2004192105.tif 000013
【図１２】
2004192105.tif 000014
【図１３】
2004192105.tif 000015
【図１４】
2004192105.tif 000016
【図１５】
2004192105.tif 000017
【図１６】
2004192105.tif 000018
【図１７】
2004192105.tif 000019
【図１８】
2004192105.tif 000020
【図１９】
2004192105.tif 000021