JP4598248B2 - 記憶サブシステムのセキュリティシステム - Google Patents
記憶サブシステムのセキュリティシステム Download PDFInfo
- Publication number
- JP4598248B2 JP4598248B2 JP2000244020A JP2000244020A JP4598248B2 JP 4598248 B2 JP4598248 B2 JP 4598248B2 JP 2000244020 A JP2000244020 A JP 2000244020A JP 2000244020 A JP2000244020 A JP 2000244020A JP 4598248 B2 JP4598248 B2 JP 4598248B2
- Authority
- JP
- Japan
- Prior art keywords
- logical unit
- storage system
- host
- access
- lun
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
ホストコンピュータからアクセスされる記憶サブシステムに関係し、特にホストコンピュータから該記憶サブシステム内の論理ユニットがアクセスされる記憶サブシステムに関する。
【０００２】
【従来の技術】
これまで、ホストコンピュータから記憶サブシステムへの不正アクセスを防ぐセキュリティ手段として、ホストコンピュータ側のＯＳ（ｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ）の機能やミドルウェアもしくはアプリケーション・ソフトウェアを使用する例がよく知られている。
【０００３】
一方、近年、ファイバチャネル・プロトコルが規格化されたことによって、記憶サブシステムとホストコンピュータとのインタフェースにＳＣＳＩや、ＥＳＣＯＮ、ＴＣＰ／ＩＰなど様々な既存プロトコルの同時使用が可能となり、記憶サブシステム内の記憶資源が一層有効利用可能となってきた。
【０００４】
しかし、このような背景においては、複数のホストが1つの記憶サブシステムに対してアクセスしてくるため、従来通りのホスト側のＯＳやミドルウェア、アプリケーション・ソフトウェアだけでは、記憶サブシステム資源に対するセキュリティ機能として十分ではない、という危惧が発生してきた。このような現状に鑑み、記憶サブシステム資源（論理ユニット）に対するセキュリティ機能の実現手段として、特開平１０−３３３８３９号公報に開示がある。
【０００５】
上記公報による方法では、ホストコンピュータが起動する前に、予め記憶サブシステムにアクセスしてくる可能性があるホストコンピュータを一意に識別するＮ＿Ｐｏｒｔ＿Ｎａｍｅと、アクセスを許可する記憶サブシステム内の論理ユニットの組み合わせを管理したテーブルを記憶サブシステム内に保持する。ホストコンピュータは、起動されると記憶サブシステムに対して、フレームと呼ばれるファイバチャネルプロトコルで規定されたある情報単位によってＳＣＳＩコマンドを送信する。記憶サブシステムは、このＳＣＳＩコマンドを逐一判定して、その中からアクセス元であるホストコンピュータを規定するＮ＿Ｐｏｒｔ＿Ｎａｍｅを抽出する。
【０００６】
抽出されたＮ＿Ｐｏｒｔ＿Ｎａｍｅは、上述のＮ＿Ｐｏｒｔ＿Ｎａｍｅとアクセスを許可した記憶サブシステム内の論理ユニットの組み合わせテーブル上で検索され、そのエントリが存在する場合、当該のホストコンピュータは、当該の論理ユニットへのアクセスを許可され、エントリが存在しない場合、当該ホストコンピュータは、当該の論理ユニットへのアクセスを拒絶される。
【０００７】
【発明が解決しようとする課題】
記憶サブシステム内の記憶資源（論理ユニット）に対するセキュリティを実現する従来技術は、記憶サブシステムにフレームを送信してくるホストコンピュータに対して、逐一、そのアクセス可否を判定するため、データ転送にしめるアクセス可否判定のオーバーヘッドが大きく、高い性能を実現しにくいという課題があった。
【０００８】
また、従来技術は、記憶サブシステムにフレームを送信してくるホストコンピュータが、そのフレーム内に送信元ホストコンピュータを一意に識別するための情報をもたせる点で、ホストコンピュータ側に新たな機能が必要となっていた。
【０００９】
更に、従来技術では、アクセスしてくるホストコンピュータに対して、記憶サブシステム内の論理ユニット番号をそのまま開示するため、記憶サブシステムのポート配下にユーザの運用希望にそった論理ユニットの再配列を行えない。更にまた、多くのホストコンピュータでは、起動時に接続されている記憶サブシステムのＬＵ０にアクセスできない場合、そのＬＵ０以降の同系列のＬＵ（ＳＣＳＩ−２の規格では、この１系列は８つのＬＵで構成されるため、ＬＵ０〜ＬＵ７までが同系列となる。）には全く存在の問い合わせをしない、とするものが多い。
【００１０】
この場合、サブシステム内の論理ユニット番号をそのまま開示する方法では、アクセスが許可されているにもかかわらず、当該ＬＵＮを参照できないという事態が生じる。
【００１１】
本発明の第１の目的は、ホストコンピュータの既存処理を変更せずに、ホストコンピュータ毎にアクセス可能な論理ユニットを制限し、不正アクセスを防止するセキュリティ機能を、記憶資源の高効率利用と高速なアクセス判定ロジックと共に提供することである。
【００１２】
本発明の第２の目的は、ホストコンピュータの既存処理を変更せずに、同一ベンダ毎にアクセス可能な論理ユニットを制限し、不正アクセスを防止するセキュリティ機能を、記憶資源の高効率利用と高速なアクセス判定ロジックと共に提供することである。
【００１３】
また、本発明の第３の目的は、このセキュリティ機能に基づいてアクセスが許可されたベンダのホストコンピュータ群に対して、当該ベンダ向けの記憶資源フォーマットやサービスを提供することである。
【００１４】
【課題を解決するための手段】
上記課題を解決するために、本発明は以下の記憶サブシステムを提供する。
【００１５】
ホストコンピュータを一意に識別する情報（ＷＷＮ）、このホストコンピュータからのアクセスを許可した記憶サブシステム内の論理ユニット番号（ＬＵＮ）、および該論理ユニット番号に対してユーザが任意のリナンバリング方法で任意数再配列して割り当てた仮想的な論理ユニット番号（仮想ＬＵＮ）の対応を記述した管理テーブルと、これを格納する不揮発のメモリと、動的に割り当てられる管理番号（Ｓ＿ＩＤ）（注・「ホスト→ストレージのログイン時に動的に割り当てられる」から変更、以下同じ）、およびホストコンピュータを一意に識別する情報（ＷＷＮ）の対応を記述した管理テーブルと、これを格納する不揮発のメモリと、１つ以上の記憶装置と、これらの記憶装置に対してデータの読み書きを制御する記憶制御装置と、ホストコンピュータと接続を行うための１つ以上のポートと、前記記憶装置の記憶領域に対応した論理ユニットを有する記憶サブシステム。
【００１６】
この記憶サブシステムにおいては、ホスト識別情報ＷＷＮのかわりに、動的に割り当てられるＳ＿ＩＤを識別情報として用いるため、Ｉ／Ｏ処理ごとに、各ＬＵＮにアクセス可否を問い合わせる必要がなくなりアクセス時のオーバヘッドを削減することが可能となる。
【００１７】
また、仮想ＬＵＮを用いることにより、ユーザが任意の方法でＬＵＮの再配列を行なうことが可能となる。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータからのアクセスに応じてマップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記マップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号を含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、アクセス管理マップを有するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセスマネジメントマップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号とを含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされ、前記アクセスマネジメントマップは、前記ホストグループから前記論理ユニットへのアクセスを制御するのに使用されることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記ホストコンピュータからのデータを記憶する複数のディスクドライブと、アクセス管理テーブルを有するコントローラとを有し、前記ディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセス管理テーブルは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号とを含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされ、前記アクセスマ管理テーブルは、前記ホストグループから前記論理ユニットへのアクセスを制御するのに使用されることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じてアクセス管理マップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセス管理マップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号を含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータからのアクセスに応じてマップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループと対応する複数の識別子及び複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号を含むアクセス管理マップを含み、各々のホストグループに割り当てられる前記仮想論理ユニット番号のいくつかはゼロから始まり、他はゼロ以外の番号で始まり、前記コントローラは、前記アクセス管理マップに応じて前記ホストグループから前記論理ユニットへのアクセスを制御することを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループの識別子と複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号をマップするアクセス管理テーブルを含み、前記論理ユニット番号はゼロでない番号で始まり、前記コントローラは、前記アクセス管理テーブルに応じた前記ホストグループから前記論理ユニットへのアクセスを制御すること特徴とする記憶システムである。
【００１８】
【発明の実施の形態】
本発明では、記憶サブシステムとホストコンピュータ間で使用するインタフェース・プロトコルの例にファイバチャネルを、その上で動作するコマンドセットの例にＳＣＳＩコマンドを用いて説明する。しかし本発明の適用は、ファイバチャネルとＳＣＳＩコマンドの組み合わせに限定されるものではなく、これらと同様に、ログイン、問い合わせといった機能、機構を提供可能なプロトコルであれば何でもかまわない。
【００１９】
本発明の第一の実施例を以下に示す。
【００２０】
ここで、ファイバチャネルは比較的新しいインタフェース・プロトコルであるため、はじめに、そのプロトコルの概要を説明する。
【００２１】
ファイバチャネルはシリアル転送方式のプロトコルであり、情報を非同期に送るため伝送媒体の帯域幅を有効に利用できる。また、ファイバチャネルは独自のコマンドセットを持たず、従来のＳＣＳＩ、ＥＳＣＯＮ、ＨＩＰＰＩ、ＩＰＩ−３、ＩＰ等といったコマンドセットのためのインフラとして使用される。これより、従来のプロトコル資産を継承可能であり、かつ、より高速で信頼性の高い多彩なデータ転送を可能とする。
【００２２】
また、ファイバチャネルはチャネルとネットワークの特長を併せ持つインタフェースである。ファイバチャネルでは一度、転送元と転送先が確定すれば、遅延が少ない高速な転送を実現できるが、これはチャネルの最大の特長の１つである。また、通信を希望する機器は、任意の契機でファイバチャネルの通信系に参加し、通信の目的となる相手の機器と相互に通信に関する取り決め情報を交換し、通信を開始することができるが、これはネットワークの特長である。ここで述べた相手機器との通信に関する取り決め情報交換の手続きを、とくにログインと呼ぶ。
【００２３】
ファイバチャネルのインタフェースを持つ機器をノードと呼び、実際のインタフェースにあたる物理的な口をポートと呼ぶ。ノードは１つ以上のポートを持つことが可能である。ファイバチャネルの系全体に同時に参加できるポートの数は、最大で２４ビットのアドレス数、すなわち約１６７７万個である。これらの接続を媒介するハードウェアをファブリックと呼ぶ。実際には、送信元および送信先のポートは、ファブリックを意識せずに互いのポートに関する情報のみを考慮して動作すればよい。
【００２４】
各ノードおよびポートには、標準化団体（ＩＥＥＥ）から一定のルールによって割り当てられる、世界中でユニークな識別子が記憶されている。これは従来からＴＣＰ／ＩＰなどで馴染みのＭＡＣアドレスに相当するものであり、ハードウェア的に固定なアドレスである。このアドレスにはＮ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿Ｎａｍｅの２種類があり、それぞれ８バイトのサイズを持つ。Ｎ＿Ｐｏｒｔ＿Ｎａｍｅはポート毎に固有の値（ハードウェア・アドレス）であり、Ｎｏｄｅ＿Ｎａｍｅはノード毎に固有の値（ハードウェア・アドレス）である。これらは、いずれも世界中でユニークな値であることから、ノードまたは、ポートを一意に識別できるアドレスとして、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）と呼ばれる。本特許の実施例では、ＷＷＮと記述した場合、Ｎ＿Ｐｏｒｔ＿Ｎａｍｅを指すものとする。
【００２５】
ファイバチャネルでは、通信はＯｒｄｅｒｅｄ Ｓｅｔと呼ばれる信号レベルの情報と、フレームと呼ばれる固定のフォーマットを持った論理的な情報とで行われる。図２はフレームの構造を示している。フレーム２０１は、フレームの始まりを示すＳＯＦ（Ｓｔａｒｔ ｏｆ Ｆｒａｍｅ）２０２と呼ばれる４バイトの識別子、リンク動作の制御やフレームの特徴づけを行う２４バイトのフレームヘッダ２０３、実際に転送される目的となるデータ部分であるデータフィールド２０４、４バイトの巡回冗長コード（ＣＲＣ）２０５、フレームの終わりを示すＥＯＦ（Ｅｎｄ ｏｆ Ｆｒａｍｅ）２０６と呼ばれる４バイトの識別子からなる。データフィールド２０４は０〜２１１２バイトの間で可変である。
【００２６】
次に、フレームヘッダの内容について説明する。２０７はフレームヘッダの構造について示している。ここではフレームヘッダ２０３の詳細構造２０７における、１ワード目の０〜２３ビット領域にあたるＳ＿ＩＤ２０８についてのみ説明する。Ｓ＿ＩＤ（Ｓｏｕｒｃｅ ＩＤ）２０８は当該フレームを送信するポートを識別するための３バイトのアドレス識別子であり、送受信されるすべてのフレームで有効な値を持つ。このＳ＿ＩＤは動的に変動する値であり、ファイバチャネルの規格セットの１つであるＦＣ＿ＰＨでは、Ｓ＿ＩＤをファブリックによって、初期化手続き時に割り当てられる、としている。割り当てられる値は、それぞれのポートがもつＮ＿Ｐｏｒｔ＿Ｎａｍｅまたは、Ｎｏｄｅ＿Ｎａｍｅに依存する。
【００２７】
次に、ファイバチャネルプロトコルに基づく、送信元の機器と送信先の機器が通信に関して互いに情報を交換するログイン手続きについて述べる。図３に、ＰＬＯＧＩフレームにおけるデータフィールド３０３の詳細構造について示す。フレーム、およびフレームヘッダの構造は図２と同様である。ＰＬＯＧＩフレームのデータフィールド３０３において、先頭から２１バイト目〜２９バイト目までの８バイトの領域がＮ＿Ｐｏｒｔ＿Ｎａｍｅ３０７を格納する領域であり、先頭から３０バイト目〜３８バイト目までの８バイトの領域がＮｏｄｅ＿Ｎａｍｅ３０８を格納する領域である。
【００２８】
図４は、送信元（ログイン要求元）４０１と送信先（ログイン受信先）４０２との間に取り交わされる情報のやりとりを示したものである。ファイバチャネルのログイン手続きには数種類存在するが、ここではクラス３のログインに関して述べる。
【００２９】
ログイン要求元は、ＰＬＯＧＩフレーム４０３をログイン受信先へ送信する。このフレームには、ログイン要求元のＮ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿Ｎａｍｅ、Ｓ＿ＩＤおよびその他の情報が含まれている。受信先の装置では、このフレームに含まれている情報を取り出し、ログインを承認する場合は、ＡＣＣ４０４と呼ばれるフレームをログイン要求元に対して送信する。一方、ログインを拒絶する場合は、ＬＳ＿ＲＪＴ４０５と呼ばれるフレームをログイン要求元に対して送信する。
【００３０】
ログイン要求元は、自らが送信したＰＬＯＧＩフレームに対してＡＣＣフレームの応答を検出すると、ログインが成功したことを知り、データ転送などのＩ／Ｏプロセスを開始できる状態となる。一方、ログイン要求元が、ＬＳ＿ＲＪＴを受信した場合はログインが成立しなかったこととなり、当該ログイン受信先へのＩ／Ｏプロセスは実行不可となる。ここではクラス３のログインについて述べたが、他のログインプロセスにおいても、ログイン要求元からログイン受信先へ渡すことのできる情報の中に、Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿ＮａｍｅおよびＳ＿ＩＤが含まれることにおいては同様である。
【００３１】
次に、ＳＣＳＩコマンドセットでは必ずサポートされている標準的なコマンドである、Ｉｎｑｕｉｒｙコマンドについて説明する。Ｉｎｑｕｉｒｙコマンドとは、Ｉ／Ｏプロセスを開始するのに先立ち、Ｉ／Ｏプロセスの対象となる論理ユニットに対して、その実装状態、準備状態を問い合わせるコマンドである。
【００３２】
図５は、ＳＣＳＩ規格で定義されたＩｎｑｕｉｒｙコマンドを、ファイバチャネル規格のフレームで送信する場合のデータフィールドの詳細構造を示している。フレーム、およびフレームヘッドの構造は図２と同様であるが、Ｓ＿ＩＤ２０８が含まれている。
【００３３】
データフィールド５０３には５０６のＦＣＰ＿ＣＭＮＤフォーマットに示すように、ＦＣＰ＿ＬＵＮ ５０７、ＦＣＰ＿ＣＮＴＬ５０８、ＦＣＰ＿ＣＤＢ５０９、ＦＣＰ＿ＤＬ５１０と呼ばれる領域がある。ここではＦＣＰ＿ＬＵＮ５０７、およびＦＣＰ＿ＣＤＢ５０９について述べる。ＦＣＰ＿ＬＵＮ５０７の中には、フレーム送信元が状態を問い合わせようとする、フレーム送信先のポートに関連付けられた論理ボリューム（目に見える単体としての記憶装置（物理ボリューム）に対して、便宜上仮想的に分割されナンバリングされた記憶領域）の識別子が格納されている。この識別子をＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）という。ＦＣＰ＿ＣＤＢ５０９の中には、ＳＣＳＩコマンドセットを使用する場合にはＳＣＳＩのコマンド記述ブロック（ＣＤＢ）と呼ばれる命令情報が格納される。このＦＣＰ＿ＣＤＢ５０９の中に、ＳＣＳＩのＩｎｑｕｉｒｙコマンド情報が格納されて、前述のＦＣＰ＿ＬＵＮ ５０７と共に、フレーム受信先へ情報が転送される。
【００３４】
次に、Ｉｎｑｕｉｒｙコマンドを受信したフレーム受信先が、問合せへの応答としてフレーム送信元へ返信する情報について述べる。この情報をＩｎｑｕｉｒｙデータという。図６にＩｎｑｕｉｒｙデータの抜粋を示す。ここでは、Ｉｎｑｕｉｒｙデータ６０１のうちでクオリファイア６０２と、デバイス・タイプ・コード６０３の２つについて述べる。クオリファイア（Ｐｅｒｉｐｈｅｒａｌ Ｑｕａｌｉｆｉｅｒ）６０２は、指定された論理ユニットの現在の状態を設定する３ビットの情報である。論理ユニットの状態６０４は、このクオリファイアのビットパターンによって示される論理ユニットの状態を示したものである。コード０００（２進数）６０５は、論理ユニットとして接続されている装置は、デバイス・タイプ・コード６０３の領域に示される種類の入出力機器であることを示している。本コードが設定されていても、その論理ユニットが使用可能、すなわちレディ状態であることを必ずしも示しているわけではない。
【００３５】
しかし、当該論理ユニットを使用できるのは本コードが設定されている場合に限られる。コード００１（２進数）６０６は、論理ユニットとして接続されている装置は、デバイス・タイプ・コード６０３の領域に示される種類の入出力機器であることを示しているが、そのロジカルユニットには実際の入出力機器が接続されていないことを示している。これは例えばＣＤ−ＲＯＭドライブが実装されているが、ＣＤ−ＲＯＭ媒体がドライブ内に挿入されていないような場合を示す。
【００３６】
コード０１１（２進数）６０７は、指定された論理ユニットがサポートされていないことを示す。従って指定された論理ユニットに装置が割り当てられることはない。本コードが設定されるときは、デバイス・タイプ・コード領域６０３にはかならず１Ｆ（１６進数）が設定される。
【００３７】
デバイス・タイプ・コード（Ｐｅｒｉｐｈｅｒａｌ Ｄｅｖｉｃｅ Ｔｙｐｅ）６０３は、指定された論理ユニットに実際に割り当てられている入出力機器の種別を示す５ビットの情報である。コード６０８は、各デバイスタイプ６０９に対応する１６進数のコードである。６０８に示されている情報のうち、未定義または未接続のデバイスを表す１Ｆ（１６進数）６１０が設定された場合、Ｉｎｑｕｉｒｙコマンド送信元が問い合わせたデバイスは未定義あるいは未接続であり、当該論理ユニットは送信元からは使用できない。
【００３８】
図７に、このＩｎｑｕｉｒｙコマンドを用いた論理ユニット問合せの手順を示す。論理ユニットにアクセスしようとするホストコンピュータ７０１は、アクセスしようとする論理ユニットをもつ記憶サブシステム７０２に対し、Ｉｎｑｕｉｒｙコマンドを格納したフレーム７０３を送信する。
【００３９】
このフレームには、ホストコンピュータのＳ＿ＩＤと、問合せを行う先の論理ユニットの識別子であるＬＵＮが含まれている。ここで、ＬＵＮについては、ＦＣＰ＿ＬＵＮ領域の他に、ＦＣＰ＿ＣＤＢ内のＩｎｑｕｉｒｙコマンド情報のフォーマット中にも設定することができる。どちらの値を使用しても得られる効果は同じであるが、本実施例ではＬＵＮの値はＦＣＰ＿ＬＵＮ ５０７に格納された値を使用するものとする。
【００４０】
Ｉｎｑｕｉｒｙコマンドを含むフレームを受信した記憶サブシステム７０２は、問合せに対して必要なＩｎｑｕｉｒｙデータを準備し、作成したＩｎｑｕｉｒｙデータを含むフレーム７０４をホストコンピュータに送信する。このときＩｎｑｕｉｒｙデータを格納するフレームを、ＦＣＰ＿ＤＡＴＡと呼ぶ。記憶サブシステムが、問合せのあった論理ユニットについて、クオリファイア０００（２進数）、デバイスタイプ００〜０９（１６進数）のいずれかを設定する場合７０４、このＩｎｑｕｉｒｙデータを受信したホストコンピュータは、当該論理ユニットに対して、以降Ｉ／Ｏの発行が可能となる。
【００４１】
一方、７０５に示すように、記憶サブシステムが、クオリファイア００１（２進数）または０１１（２進数）、デバイスタイプ１Ｆ（１６進数）を設定した場合、このＩｎｑｕｉｒｙデータ７０５を受信したホストコンピュータは、当該論理ユニットに対して、以降、Ｉ／Ｏの発行が不可能であることを認識する。
【００４２】
以上のことから、Ｉｎｑｕｉｒｙデータに格納するクオリファイア、およびデバイス・タイプ・コードを記憶サブシステム側でコントロールすれば、ホストコンピュータから記憶サブシステムの論理ユニットへのアクセス許可および不許可を制御できることが分かる。
【００４３】
続いて、本発明の処理の流れについて詳細を述べる。
【００４４】
はじめに図１は、本発明の実施例の装置構成を示したものである。本装置を記憶サブシステム１０１とよぶ。記憶サブシステム１０１は、ファイバチャネル・インタフェース用のポート１０２〜１０４を有し、ファイバチャネル・インタフェースを介して、ホストコンピュータ１０５〜１０７と物理的に接続されている。ホストコンピュータ１０５〜１０７もまた、ファイバチャネルインタフェース用のポート１０８〜１１２を有しており、ホストコンピュータ１０５〜１０７と記憶サブシステム１０１は、ファイバチャネル・プロトコルによる通信が可能である。ホストコンピュータには、１０５や１０６のように複数のファイバチャネル・ポートをもつものもあれば、１０７のように単一のファイバチャネル・ポートしかもたないものもある。
【００４５】
記憶サブシステム１０１とホストコンピュータ１０５〜１０７間のファイバチャネルインタフェースの接続形態（トポロジ）には、Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔや、アービトレーション・ループ接続、ファブリック接続等、いくつかの種類が存在するが、本発明はその接続形態には依存しないため、単にファイバチャネル１１３と記述する。
【００４６】
まず、記憶サブシステム１０１は、種々の演算や処理を行うマイクロプロセッサ１１４を有し、複数の記憶装置群１１５、およびこれらにデータの読み書きを制御して行う記憶制御装置１１６、さらに記憶装置群１１５と記憶制御装置１１６を接続するためのバス１１７を有している。また、記憶サブシステム１０１は、種々の演算や処理のワーク領域として使用するメモリ１１８と、種々の管理情報、管理テーブル等を保存しておく不揮発メモリ１１９を有する。更に、ホストコンピュータへの応答を速くするための工夫として、キャッシュ１２０を有している。また、記憶サブシステム１０１は、通信制御部１２１を有し、通信回線１２２を介して、保守用端末装置１２３と接続されている。
【００４７】
保守用端末装置１２３は、内部にマイクロプロセッサ１２４と、ユーザとのインタフェースとなる入力部１２５と処理の結果を出力する表示部１２６を有している。ユーザは、この入力部１２５を介して、本実施例で定義するいくつかのテーブルの設定を行うことができる。
【００４８】
図８において、本実施例の処理流れ概要を示す。初めに、手順８０１において、ユーザは前述の保守用端末装置１２３の入力部１２５を介して、記憶サブシステム内に存在するＬＵを規定するＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）と、そのＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮ（Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ）と、これにアクセスしてくるホストコンピュータに対してそのＬＵＮをどのように見せるかを決定する仮想ＬＵＮとを結び付けた「ＬＵＮアクセス管理テーブル」を作成する。
【００４９】
本テーブルは、記憶サブシステム内の不揮発メモリ１１９に保持される。各ホストコンピュータには、本テーブルの仮想ＬＵＮが見える。各ホストコンピュータのＷＷＮは既知である。
【００５０】
手順８０２において、各ホストコンピュータが記憶サブシステムに対して、ファイバチャネル・プロトコルに基づいてログインしてくると、記憶サブシステムはＰＬＯＧＩフレームから、当該ホストコンピュータのＷＷＮと、Ｓ＿ＩＤを切り出し、それらの組み合わせを記述した「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を作成し、不揮発メモリ１１９上にこれを保持する。記憶サブシステムはこの作業を全てのＰＬＯＧＩフレームに対して行う。
【００５１】
次に手順８０３において、記憶サブシステムは、各ホストコンピュータが記憶サブシステム内の論理ユニットの状態を知るために送信したＩｎｑｕｉｒｙコマンドを含むフレームを受信する。このフレームを受信した記憶サブシステムは、そのフレームのヘッダからＳ＿ＩＤを、データフィールドからＩｎｑｕｉｒｙコマンドの対象となるＬＵＮを切り出す。続いて、記憶サブシステムは、このＳ＿ＩＤをキーにして上述の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を検索し、このＳ＿ＩＤに相当するＷＷＮを取得する。
【００５２】
続いて、記憶サブシステムは、手順８０４において、得られたＷＷＮをキーにして上述の「ＬＵＮアクセス管理テーブル」を検索し、Ｉｎｑｕｉｒｙコマンドの対象となっているＬＵＮに相当する仮想ＬＵＮを「ＬＵＮアクセス管理テーブル」から取得する。ここでＩｎｑｕｉｒｙ対象となっているＬＵＮを仮想ＬＵＮとして取得する理由は、ホストコンピュータには仮想ＬＵＮが開示されているためである。
【００５３】
続いて手順８０５では、手順８０４の結果、当該ＷＷＮに対応する仮想ＬＵＮを取得できたか否かの判定を行う。取得できた場合、すなわち当該ＷＷＮに対応する仮想ＬＵＮが「ＬＵＮアクセス管理テーブル」上に存在した場合は、当該ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可される。対応する仮想ＬＵＮが該テーブルに存在しない場合は、当該ホストコンピュータにより当該仮想ＬＵＮへのアクセスが拒絶される。
【００５４】
手順８０５の結果、当該ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可される場合、記憶サブシステムは、手順８０６において、ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが実装済みの設定（すなわちアクセス可能である旨の設定）を行った上で、Ｉｎｑｕｉｒｙデータを送信する。
【００５５】
一方、当該仮想ＬＵへのアクセスが拒絶される場合、記憶サブシステムは、手順８０７によって、ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが未実装の設定（すなわちアクセス不可である旨の設定）を行った上で、Ｉｎｑｕｉｒｙデータを送信する。
【００５６】
Ｉｎｑｕｉｒｙデータを受信したホストコンピュータは、そのフレームを解析する。
【００５７】
解析の結果、記憶サブシステムの当該仮想ＬＵＮへのアクセス許可を認識すると、ホストコンピュータは以降、当該仮想ＬＵＮに対して、コマンド（Ｉ／Ｏ要求）を継続して発行することができる。この場合、手順８０８にあるように、記憶サブシステムは当該ホストコンピュータからのログインが有効である間は、当該ＬＵへのアクセス可否をチェックしなおすことなく、コマンド受信を継続することができる。
【００５８】
一方、当該ＬＵＮへのアクセス拒否を認識したホストコンピュータは、記憶サブシステムへのログインが有効である間、当該ＬＵへ再度アクセスすることはない。
【００５９】
以下、上記の記憶サブシステム内の特定ＬＵＮに対するホストコンピュータからのアクセス可否を制御する方式を、便宜的に「ＬＵＮセキュリティ」と呼ぶ。
【００６０】
次に、上記の各手順について詳細を示す。
【００６１】
はじめに、上記手順の「ＬＵＮアクセス管理テーブル」の作成について記述する。本発明におけるＬＵＮセキュリティは、記憶サブシステムのもつポート毎に管理されるものとし、ホストコンピュータは、この記憶サブシステムのポートを通して、記憶サブシステム内のＬＵにアクセスするものとする。この場合、最も簡単な方法として、ホストコンピュータを一意に識別する情報であるＷＷＮと、当該ホストコンピュータにアクセスを許可するＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）の対応を定義した、図９に示すようなテーブル９０１を、記憶サブシステム内に設ければよい。
【００６２】
しかし、ホストコンピュータと記憶サブシステム間に、ファイバチャネル対応のハブや、スイッチなどの機器類が存在するような使用環境では、９０１のテーブルだけでは不十分である。以下それを説明する。
【００６３】
テーブル９０１は、記憶サブシステム内のＬＵをその識別子であるＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）に基づき、そのままホストコンピュータのＷＷＮに対して割り当てている。図９では、ＷＷＮ９０２のホストコンピュータには、ＬＵ０〜２にのみアクセスが許可され、ＷＷＮ９０３のホストコンピュータは、ＬＵ３、４、および７にのみアクセスが許可され、ＷＷＮ９０４のホストコンピュータは、ＬＵ５〜６にのみアクセスが許可されている。
【００６４】
したがって、例えばＬＵ０〜２は、ＷＷＮ９０２のホストコンピュータ以外のホストコンピュータからは、アクセス不可となり、ＬＵＮセキュリティが実現される。しかし、今日多くのホストコンピュータでは、起動時に接続されている記憶サブシステムのＬＵ０にアクセスできない場合、そのＬＵ０以降の同系列のＬＵ（ＳＣＳＩ−２の規格では、この１系列は８つのＬＵで構成されるため、ＬＵ０〜ＬＵ７までが同系列となる。）には全く存在の問い合わせをしない、とするものが多い。
【００６５】
すると、テーブル９０１のような規定方法では、ホストコンピュータ９０３や９０４は、アクセス許可するＬＵＮがそれぞれ規定されていながら、ＬＵ０にアクセスできないために、テーブル９０１で規定したアクセス許可のＬＵＮを参照できない事態が発生してしまう。このような現象は、ディスクアレイ装置のような記憶資源を豊富に提供し得る装置においては、著しくその利用率を下げてしまうことになり無駄である。
【００６６】
そこで、これを防ぐためにホストコンピュータ９０３、９０４にＬＵ０へのアクセスを許可すると、ＬＵ０のセキュリティが保証されない。仮にこれを認めた場合にも、ホストコンピュータ９０３と９０４が異なるＯＳをもつホストコンピュータである場合、ＬＵ０を共有することは、それぞれのＯＳによるフォーマットの違いなどから困難である。
【００６７】
一方、図１０においてホストコンピュータが接続している当該ポート配下にＬＵ０が存在しなくても、全てのＬＵＮに対して存在の問い合わせを行う、ＷＷＮ１００２〜１００４を持つホストコンピュータ群が存在すると仮定する。ここでは、ＷＷＮ１００２のホストコンピュータは、ＬＵ０、１、７にのみアクセスが許可され、ＷＷＮ１００３のホストコンピュータは、ＬＵ３、５、６にのみアクセスが許可され、ＷＷＮ１００４のホストコンピュータは、ＬＵ２、４にのみアクセスが許可されている。
【００６８】
この状態を視覚的に表したのが図１１である。ホストコンピュータ１１０２〜１１０４は、図１０ＷＷＮ１００２〜１００４を持つホストコンピュータに相当する。ホストコンピュータ１１０２〜１１０４は、ファイバチャネル対応のハブや、スイッチ１１０５を経由して記憶サブシステムの同一のポート１１０６に接続している。このような使用環境において、各々のホストコンピュータ１１０２〜１１０４に対し、無計画にアクセス対象ＬＵＮを定義したり、以前割り当てたＬＵＮと異なるＬＵＮをアクセス対象として割り当てた場合、ホストコンピュータに記憶サブシステム内のＬＵＮをそのまま開示している１１０１のような記憶サブシステムではＬＵＮの開示方法に柔軟性がないため、当該ポート配下が、ＬＵ群１１０７のようにＬＵが離散した状態で見え、使用上、著しく管理しにくい状態となってしまう。
【００６９】
一方、最近、記憶サブシステムの１つのポート配下に９個以上のＬＵを定義しても、これを認識するホストコンピュータが存在するが、このようなホストコンピュータと従来のように１つの記憶サブシステムのポート配下にＬＵ０〜７までの８個のＬＵしかサポートしないホストコンピュータ間でＬＵＮセキュリティを実施した場合の問題点を示す。
【００７０】
図１２において、ＷＷＮ１２０２、１２０４を持つホストコンピュータが、接続する記憶サブシステムのポート配下にＬＵ０が存在しなくても、各ＬＵに存在の問い合わせを行う機構をもち、かつ、接続する記憶サブシステムのポート配下にＬＵを１６個まで認識する場合について以下説明する。
【００７１】
ＷＷＮ１２０３を持つホストコンピュータは、接続する記憶サブシステムのポート配下にＬＵ０が存在しなくても、各ＬＵに存在の問い合わせを行えるが、サポート可能なＬＵはＬＵ０〜７の範囲の８個までとする。テーブル１２０１から分かるように、ＷＷＮ１２０２を持つホストコンピュータはＬＵ０〜５の範囲でアクセスが許可されており、ＷＷＮ１２０３を持つホストコンピュータはＬＵ６〜１０の範囲で、またＷＷＮ１２０４を持つホストコンピュータはＬＵ１１〜１５の範囲でアクセスが許されている。この状態を視覚的に表したのが図１３である。
【００７２】
ホストコンピュータ１３０２〜１３０４は、図１２のＷＷＮ１２０２〜１２０４を持つホストコンピュータに相当する。ホストコンピュータ１３０２〜１３０４は、ファイバチャネル対応のハブや、スイッチ１３０５を経由して記憶サブシステムの同一のポート１３０６に接続している。このような使用環境において、各々のホストコンピュータ１３０２〜１３０４に対して、ＬＵ群１３０８のように記憶サブシステム内のＬＵを割り当てたとすると、ホストコンピュータＡ１３０２には、ＬＵ群１３０８中のＬＵ０〜５の範囲のみアクセス許可対象として見え、ホストコンピュータＣ１３０４には、ＬＵ群１３０８中のＬＵ１１〜１５の範囲のみアクセス許可対象として見え、それぞれＬＵＮセキュリティの目的を果たすことができる。しかし、ホストコンピュータＢ１３０３は、元々１ポート配下にＬＵ０〜７までの範囲で、８個までしかＬＵをサポートできないため、ＬＵ群１３０７の範囲内でしか問い合わせを実施することができない。よって、テーブル１２０１において、ＬＵ６〜１０までアクセス許可をしても、実際には、ＬＵ６、７にしかアクセスできないという問題が生じる。これも、記憶サブシステム内のＬＵをそのまま開示しているために起こる弊害である。
【００７３】
以上のような懸念を考慮して、本発明では、図１４に示すような「ＬＵＮアクセス管理テーブル」１４０１を定義する。テーブル１４０１は、図９のテーブル９０１、図１０のテーブル１００１、図１２のテーブル１２０１のように記憶サブシステム内のＬＵＮをＷＷＮに直接割り当てたテーブルとは異なり、記憶サブシステム内のＬＵＮと、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮを組み合わせて記憶サブシステムのポート毎に定義したテーブルである。
【００７４】
このテーブル１４０１において、ユーザは任意個数の任意ＬＵＮに対して、任意のリナンバリング方法で仮想ＬＵＮを対応づけることができる。その結果、この「ＬＵＮアクセス管理テーブル」１４０１を定義した記憶サブシステムでは、各ホストコンピュータに対して、ユーザの任意の使用希望に沿った形でＬＵＮを開示することができる。その際、各ホストコンピュータにアクセスが許可されるＬＵＮは、実際のＬＵＮ１４１７ではなく、仮想ＬＵＮ１４１６であるため、各ホストコンピュータに記憶サブシステム内のＬＵＮのばらつきや、ＬＵ０の有無などを意識させる必要がなく、ユーザの意志によって最適化された柔軟なＬＵＮ状態を提供することができる。
【００７５】
図１４において、ＷＷＮ１４０２を持つホストコンピュータは、仮想ＬＵＮ０〜３を通して、実際のＬＵＮ０〜３へアクセスが許可されている。以下ＷＷＮ１４０３〜１４１４を持つホストコンピュータも同様であり、それぞれ仮想ＬＵＮ１４１６を通して、対応する実際のＬＵＮ１４１７へアクセス許可される。これにより、各ホストコンピュータは、非ＬＵ０に対しても、ＬＵ０に対して行うような処理を実行すること等が可能となる。
【００７６】
この「ＬＵＮアクセス管理テーブル」１４０１において特徴的なことは、ＷＷＮ１４０２〜１４０５を持つホストコンピュータには、それぞれ接続ポート配下のＬＵ０にアクセスしているように見えているものの、実際には、それぞれの間で排他的なセキュリティが実現されながら、実際には異なったＬＵＮにアクセスし、記憶資源を効率的に使用できていることである。
実際のＬＵＮに対する仮想ＬＵＮのリナンバリングに関して詳細を示す。使用者が最もよく行うと思われる仮想ＬＵＮによるリナンバリング方法は、従来のＳＣＳＩ規格との対応を意識して、各ＷＷＮに対して、ＬＵ０を起点に１ずつＬＵＮが増えていくような番号付け、すなわちＷＷＮ１４０２〜１４０４の欄に見られるようなケースである。
【００７７】
しかし、運用面を考えて、ＷＷＮ１４０７，１４０８の欄のように、偶数のみの仮想ＬＵＮ、奇数のみの仮想ＬＵＮを対応させることも可能である。この例では、ＷＷＮ１４０７、１４０８を有するホストコンピュータがアクセス許可されているのは、実際には単に連続するＬＵ３０〜３４、およびＬＵ３５〜３８である。また、ＷＷＮ１４０９の欄のように、ＬＵ０が存在しなくても任意のＬＵＮを検出できるようなホストコンピュータに対しては、アクセス希望するＬＵＮに対応する仮想ＬＵＮにだけアクセス許可すればよい。また、ＷＷＮ１４１０および１４１１の欄のような対応づけは、２つ以上の異なるホストコンピュータを任意にグルーピングする際に便利である。さらにまた、WWN１４１２および１４１３の欄は、これら２つのWWNを有するホストコンピュータに対しては、異なるＬＵＮにアクセス許可しているように見せながら、実際には全く同じＬＵＮにアクセスさせ、同一の情報を開示したい場合に便利な運用である。
【００７８】
さらには、記憶サブシステムがＲＡＩＤを構成するディスクアレイ装置であるような場合に、異なるＲＡＩＤグループに属するＬＵをひとつずつ割り当て、最もＩ／Ｏに貢献する記憶装置（磁気ディスクドライブ）数が多くなるようにすることもできる。図１４の例でいうと、ＷＷＮ１４１４の欄がこれに該当する。
【００７９】
以上、本発明の「ＬＵＮアクセス管理テーブル」による仮想ＬＵＮと実際のＬＵＮ対応づけの効果について具体例に説明してきたが、これを視覚的に表すと図１６のようになる。対応する管理テーブル１５０２は図１５に示した。
【００８０】
テーブル１５０１で、各ホストコンピュータに割り当てた実際のＬＵ群１５０４は、実際には図１６の１６０８のように全く乱雑な配置をとっている。しかし、これをテーブル１５０１の仮想ＬＵ群１５０３で置換することで、各ホストコンピュータに記憶サブシステム１６０１内の実際のＬＵの配置状態１６０８に影響を受けない状態１６０７でＬＵを開示することができる。これにより、記憶サブシステム資源の柔軟な運用が可能となる。
【００８１】
本発明の「ＬＵＮアクセス管理テーブル」１４０１や１５０１は、図１７手順１７０１〜１７０３に示すように、記憶サブシステムの全ポートに対して定義された後、記憶サブシステム内の不揮発メモリに保持される。不揮発メモリに保持されることで、本テーブルは、記憶サブシステムの電源切断によっても消失しない。
【００８２】
続いて、記憶サブシステムがホストコンピュータから、ログインされる際の処理について説明する。本実施例では、一連のログイン処理を通じて、ホストコンピュータを一意に識別するＷＷＮと、ログイン以降に使用されるホストコンピュータを一意に識別するＳ＿ＩＤとを対応させる。ホストコンピュータが起動すると、図１８の手順１８０１において、記憶サブシステムは、ＰＬＯＧＩフレームを受信する。
【００８３】
ＰＬＯＧＩフレームを受信した記憶サブシステムは、手順１８０２において、フレームヘッダからホストコンピュータのＳ＿ＩＤを、手順１８０３において、データフィールドからホストコンピュータのＷＷＮ（Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ）を取得する。続いて、記憶サブシステムは手順１８０４において、このＷＷＮとＳ＿ＩＤの組み合わせを図１９に示す「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１に記録作成し、これを手順１８０５において、記憶サブシステム内の不揮発メモリに保持する。「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１は、記憶サブシステムのポート毎に作成される。
【００８４】
このテーブルに登録されたＷＷＮをもつホストコンピュータから、以後、コマンドが送信されると、記憶サブシステムはそのフレームヘッダからＳ＿ＩＤを取得し、「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１によってそのホストコンピュータのＷＷＮを検索することができる。記憶サブシステムは、この「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を不揮発メモリ上に保存すると、手順１８０６において、当該ホストコンピュータのログインを承認した旨のＡＣＣフレームを送信する。記憶サブシステムからＡＣＣフレームを受信したホストコンピュータは、これ以降、記憶サブシステムに対してＩｎｑｕｉｒｙコマンドを発行することができる。
【００８５】
続いて、ホストコンピュータからのＩｎｑｕｉｒｙコマンド受信と、これに対する記憶サブシステムのセキュリティ応答について説明する。図２０、図２１は、この一連の処理の流れを示したものであり、図２２は、この一連の処理の流れにおいて使用される各テーブルやパラメータの参照関係を示したものである。図２０の手順２００１において、記憶サブシステムは、ホストコンピュータからファイバチャネルに規定されたＦＣＰ＿ＣＭＮＤフレームを受信する。すると記憶サブシステムは、手順２００２において、そのＦＣＰ＿ＣＭＮＤのデータフレームの内容を解析する。
【００８６】
続いて記憶サブシステムは、手順２００３において、当該のＦＣＰ＿ＣＭＮＤの内容がＩｎｑｕｉｒｙコマンドであるか否かをチェックする。Ｉｎｑｕｉｒｙコマンドでない場合、記憶サブシステムは手順２００４において、そのコマンドに対応した処理を実行する。一方、Ｉｎｑｕｉｒｙコマンドであった場合、記憶サブシステムは手順２００５において、当該ＦＣＰ＿ＣＭＮＤフレームのヘッダからホストコンピュータのＳ＿ＩＤを取得し、手順２００６において、当該ＦＣＰ＿ＣＭＮＤフレームのデータフィールドのＦＣＰ＿ＬＵＮから対象とするＬＵＮを取得する。引き続き、記憶サブシステムは手順２００７において、得られたＳ＿ＩＤをキーにして、図１９の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１を検索し、このＳ＿ＩＤに対応するＷＷＮを取得する。ここまでの流れは、図２２の２２０１および手順２２０２、２２０３の参照動作を指す。
【００８７】
続いて、手順２００８において、このＷＷＮに対してアクセス許可されている仮想ＬＵＮ情報を取得する。そして、手順２１０９において、このＷＷＮをもつホストコンピュータのＩｎｑｕｉｒｙコマンドから得られたＬＵＮが、「ＬＵＮアクセス管理テーブル」上でアクセス許可された仮想ＬＵＮとして登録されているか否かを判定する。ここまでの流れは、図２２の手順２２０４および２２０５の参照動作を指す。
【００８８】
「ＬＵＮアクセス管理テーブル」の当該エントリに、手順２００６で得られたＬＵＮが仮想ＬＵＮとして登録されている場合、当該ホストコンピュータからその仮想ＬＵＮへのアクセスが許可されるため、記憶サブシステムは手順２１１０において、ホストコンピュータ応答用Ｉｎｑｕｉｒｙデータのクオリファイアに２進数の'０００'を、デバイスタイプに記憶サブシステムのデバイスタイプコードをセットする。
【００８９】
一方、「ＬＵＮアクセス管理テーブル」の当該エントリに、手順２００６で得られたＬＵＮが仮想ＬＵＮとして登録されていない場合、当該ホストコンピュータからその仮想ＬＵＮへのアクセスは拒絶されるため、記憶サブシステムは手順２１１１において、ホストコンピュータ応答用Ｉｎｑｕｉｒｙデータのクオリファイアに２進数の'００１'または、'０１１'を、デバイスタイプに１６進数の'１Ｆ'をセットする。
【００９０】
次に記憶サブシステムは、手順２１１２において、ＦＣＰ＿ＤＡＴＡフレームに上記の応答用Ｉｎｑｕｉｒｙデータをセットして、ホストコンピュータへ送信する。続いて記憶サブシステムは、手順２１１３において、ホストコンピュータのＩｎｑｕｉｒｙコマンドの応答を完了したことを示すＦＣＰ＿ＲＳＰフレームを送信する。
【００９１】
図２０の手順２１１０、２１１２に引き続いて、Ｉｎｑｕｉｒｙデータを含むＦＣＰ＿ＤＡＴＡを記憶サブシステムから受信したホストコンピュータは、当該ＬＵＮへのアクセスは可能と判断し、以降、当該仮想ＬＵＮへのアクセス可否を再度問い合わせることなく、アクセスを継続することができる。ここで、当該ホストコンピュータがアクセスするＬＵＮは、実際には図２２の手順２２０６の参照動作でポイントされる、仮想ＬＵＮと一意に対応づけられた記憶サブシステム内のＬＵＮとなる。この手順２２０６の参照動作は、記憶サブシステムの内部的な参照作業であり、ホストコンピュータから意識されることはない。一方、手順２１１１、２１１２に引き続いて、Ｉｎｑｕｉｒｙデータを含むＦＣＰ＿ＤＡＴＡを記憶サブシステムから受信したホストコンピュータは、当該ＬＵＮへのアクセスは不可能と判断し、以降、当該ＬＵＮへのアクセス可否を再度問い合わせることはなく、当該仮想ＬＵＮへもアクセスしない。
【００９２】
本実施例では、上記したようにホストコンピュータがアクセス可否を当該ＬＵＮへ問い合わせるのは、Ｉｎｑｕｉｒｙコマンド発行時だけである。つまり、ログインが有効である間は、この問い合わせを繰り返し行う必要がない。これにより、ホストコンピュータと記憶サブシステム間のデータ転送効率を落とすことなく、強固なＬＵＮセキュリティを実現できる。
【００９３】
以上のように、記憶サブシステム内に存在するＬＵと、そのＬＵＮをユーザ任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮとを組み合わせて記憶サブシステムのポート毎に管理することにより、ホストコンピュータ側の処理を変えることなく、記憶サブシステム内の記憶資源を有効に提供でき、当該ホストコンピュータから当該ＬＵＮへのアクセス可否を高速な判定ロジックで行う強固なＬＵＮセキュリティを実現できる。
【００９４】
本実施例では、ファイバチャネルを例に説明したが、実施においては、必ずしもファイバチャネルに限定する必要はなく、同等機能を提供可能なプロトコル環境であれば、その種別は問わない。また、記憶サブシステムに関しても、本実施例では、主にディスクアレイ装置を想定して記述しているが、記憶装置を可換媒体として置き換え、光ディスクライブラリや、テープライブラリなどに適用することも可能である。
【００９５】
本発明に係る第二の実施形態を以下に説明する。
【００９６】
第二の実施例も第一の実施例同様、ホストコンピュータと記憶サブシステムの間のインタフェース・プロトコルにファイバチャネルを例にして説明する。本実施例は、複数のホストコンピュータから構成される特定のグループに対してＬＵＮセキュリティを実現する方法である。
【００９７】
例えば、ホストコンピュータと記憶サブシステム間にファイバチャネル対応のハブや、スイッチなどの機器類が存在する図１、図１１、図１３、図１６のような使用環境では、記憶サブシステムの同一ポートにアクセスするホストコンピュータには様々なベンダ製のものが予想される。このような様々なベンダ製のホストコンピュータが共存するような環境では、しばしば記憶サブシステム内の記憶資源の共有、共用に関して問題が発生する。ベンダが異なれば、多くの場合、当該ホストコンピュータの搭載するＯＳが異なる。この問題は、ホストコンピュータが、ＷＳやメインフレーム等の場合にしばしば発生する。ホストコンピュータがＰＣの場合は、ベンダが異なっても、ＯＳは多くの場合Ｗｉｎｄｏｗｓ系であるためこの限りではない。
【００９８】
ＯＳが異なる場合、記憶資源に対するフォーマット形式や、アクセスのロジック、実行可能なスクリプト、アプリケーション等が異なるため異なるベンダ製ホストコンピュータ間で同一のボリュームを共有することは困難である。
【００９９】
そこで、記憶サブシステムの記憶資源に対して、ベンダ単位でグルーピングしてアクセスの可否を設定できるような、いわゆるベンダ毎のＬＵＮセキュリティ機能を実現することが望ましい。更に、このようなベンダ毎のＬＵＮセキュリティが実現できれば、アクセスを許可したグループ向けの記憶資源上に、当該ベンダ向けのサービスを提供したり、固有の処理を実行させることもできる。
【０１００】
そこで、記憶サブシステム内のＬＵへアクセスを許可する最小単位をホストコンピュータのベンダ単位で規定することを例に、第二の実施例を説明する。第二の実施例が第一の実施例と異なる点は、「ＬＵＮアクセス管理テーブル」の定義方法である。本実施例では、ＷＷＮの性質に注目してホストコンピュータのベンダを識別する。図２３の２３０１は、ＷＷＮのフォーマットの１つを示したものである。この図から分かるように、ＷＷＮ２３０１は、６０〜６３ビットエリア（４ビットエリア）に定義された識別フィールド２３０２と、３６〜５９ビット（２４ビットエリア）に定義されたＣｏｍｐａｎｙ＿ＩＤ２３０３と、０〜３５ビット（３６ビットエリア）に定義されたＶＳＩＤ（Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）２３０４から構成される。
【０１０１】
このＣｏｍｐａｎｙ＿ＩＤ２３０３は、従来からよく知られているＭＡＣアドレスを原則的に流用したもので、ＩＥＥＥが世界中のコンピュータベンダや、通信機器ベンダ等を対象にユニークに割り当てた識別情報である。ＶＳＩＤ２３０４は、ＩＥＥＥからＣｏｍｐａｎｙ＿ＩＤ２３０３の使用を認められたベンダが自社のルールで決定したユニークな識別情報であり、当該ベンダ内でユニークな値となる。各ベンダのＣｏｍｐａｎｙ＿ＩＤ２３０３は、ＩＥＥＥの出版物等を通して誰でも知ることができる情報であることから、このＣｏｍｐａｎｙ＿ＩＤ２３０３を予め調べておけば、記憶サブシステムにログインしてきたホストコンピュータがどのベンダ製のものであるかを識別することができる。
【０１０２】
ＷＷＮには、何種類かのフォーマット形式が規定されているが、Ｃｏｍｐａｎｙ＿ＩＤ２３０３とＶＳＩＤ（Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）２３０４を共通して内包している。
【０１０３】
図２４は、本実施例における「ＬＵＮアクセス管理テーブル」２４０１である。「ＬＵＮアクセス管理テーブル」２４０１は、記憶サブシステム内のＬＵＮ２３０４と、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮ２４０３と、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのベンダを表すＣｏｍｐａｎｙ＿ＩＤ２４０２を組み合わせて記憶サブシステムのポート毎に定義したテーブルである。このテーブル２４０１においてユーザは、任意個数の任意ＬＵＮに対して、任意のリナンバリング方法で仮想ＬＵＮを対応づけることができる。
【０１０４】
その結果、この「ＬＵＮアクセス管理テーブル」２４０１を定義した記憶サブシステムでは、各ベンダ製のホストコンピュータに対して、ユーザの任意の使用希望に沿った形でＬＵＮを開示することができる。その際、各ベンダのホストコンピュータにアクセスが許可されるＬＵＮは、実際のＬＵＮ２４０４ではなく、仮想ＬＵＮ２４０３であるため、各ベンダ製のホストコンピュータに記憶サブシステム内のＬＵＮのばらつきや、ＬＵ０の有無などを意識させる必要がなく、ユーザの意志によって最適化されたＬＵＮ状態を提供することができる。
【０１０５】
一方、「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」に関しては、本発明の第一の実施例図１８に示したものと同様の作成方法で、図１９の１９０１と同様のフォーマットで実現することができる。
【０１０６】
続いて、図２５において、本実施例の全体の処理流れを示し、同時に図２６において、この一連の処理の流れにおいて使用される各テーブルとパラメタの参照関係を示す。初めに、手順２５０１において、ユーザは前述の保守用端末装置１２３の入力部１２５を介して、記憶サブシステム内に存在するＬＵＮと、そのＬＵＮにアクセスする可能性のあるホストコンピュータ群のベンダを表わすＣｏｍｐａｎｙ＿ＩＤと、これにアクセスしてくる各ベンダ製ホストコンピュータに対してそのＬＵＮをどのように見せるかを決定する仮想ＬＵＮとを結び付けた「ＬＵＮアクセス管理テーブル」を作成する。
【０１０７】
本テーブルは、記憶サブシステム内の不揮発メモリ１１９に保持される。各ベンダ製ホストコンピュータには、本テーブルの実際のＬＵＮではなく、仮想ＬＵＮが見える。Ｃｏｍｐａｎｙ＿ＩＤは各ベンダを表す既知の情報である。本実施例の「ＬＵＮアクセス管理テーブル」において、ＷＷＮではなくＷＷＮの構成要素であるＣｏｍｐａｎｙ＿ＩＤを使用するのは、ＬＵへのアクセス可否判定を個々のホストコンピュータ単位ではなく、各ベンダ単位で行うためである。
【０１０８】
手順２５０２において、各ホストコンピュータが記憶サブシステムに対して、ファイバチャネル・プロトコルに基づいてログインしてくると、記憶サブシステムはＰＬＯＧＩフレームから、当該ホストコンピュータのＮ＿Ｐｏｒｔ＿Ｎａｍｅ（以下、これをＷＷＮと記す）と、Ｓ＿ＩＤを切り出し、それらの組み合わせを記述した「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を作成し、不揮発メモリ１１９上にこれを保持する。記憶サブシステムは、この作業を全てのＰＬＯＧＩフレームに対して行う。
【０１０９】
次に手順２５０３において、記憶サブシステムは、各ベンダ製ホストコンピュータが記憶サブシステム内の論理ユニットの状態を知るために送信したＩｎｑｕｉｒｙコマンドを含むフレームを受信する。このフレームを受信した記憶サブシステムは、そのフレームのヘッダからＳ＿ＩＤを、データフィールドからＩｎｑｕｉｒｙコマンドの対象となるＬＵＮを切り出す。続いて、記憶サブシステムは、このＳ＿ＩＤをキーにして上述の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を検索し、このＳ＿ＩＤに相当するＷＷＮを取得する。
【０１１０】
続いて記憶サブシステムは、手順２５０４において、得られたＷＷＮから、図２３の２３０１のフォーマットに基づいて、２４ビットのＣｏｍｐａｎｙ＿ＩＤを切り出す。このＣｏｍｐａｎｙ＿ＩＤの切り出し作業は、第一の実施例の流れにはなかった本実施例に固有のものである。手順２５０３、２５０４は図２６の２６０１〜２６０４に相当する。
【０１１１】
次に記憶サブシステムは、得られたＣｏｍｐａｎｙ＿ＩＤをキーにして上述の「ＬＵＮアクセス管理テーブル」を検索し、Ｉｎｑｕｉｒｙコマンドの対象となっているＬＵＮに相当する仮想ＬＵＮを「ＬＵＮアクセス管理テーブル」から取得する。ここで、Ｉｎｑｕｉｒｙ対象となっているＬＵＮを仮想ＬＵＮとして取得する理由は、仮想ＬＵＮが記憶サブシステムのＬＵＮとして各ベンダ製ホストコンピュータに対して開示されているためである。
【０１１２】
続いて手順２５０６では、手順２５０５の結果、当該ＷＷＮに対応する仮想ＬＵＮを取得できたか否かの判定を行う。取得できた場合、すなわち当該ＷＷＮに対応する仮想ＬＵＮが「ＬＵＮアクセス管理テーブル」上に存在した場合が、当該ベンダ製ホストコンピュータに対して当該仮想ＬＵＮへのアクセスが許可される場合であり、存在しない場合が、当該ベンダ製ホストコンピュータに対して当該仮想ＬＵＮへのアクセスが拒絶される場合である。
【０１１３】
手順２５０６の結果、当該ベンダ製ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可できる場合、記憶サブシステムは、手順２５０７において、当該ベンダ製ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが実装済みの設定、すなわちアクセス可能である旨の設定を行った上で、Ｉｎｑｕｉｒｙデータを送信する。これら手順２５０５、２５０６、２５０７は図２６の２６０５、２６０６、２６０８に相当する。
【０１１４】
一方、手順２５０６の結果、当該ホストコンピュータにより当該仮想ＬＵＮへのアクセスが拒絶される場合、記憶サブシステムは、手順２５０８によって、当該ベンダ製ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが未実装の設定、すなわちアクセス不可である旨の設定を行った上で、Ｉｎｑｕｉｒｙデータを送信する。Ｉｎｑｕｉｒｙデータを受信したホストコンピュータは、そのフレームを解析する。
【０１１５】
解析の結果、記憶サブシステムの当該仮想ＬＵＮへのアクセス許可を認識すると、当該ベンダ製ホストコンピュータは以降、当該仮想ＬＵＮに対して、コマンド（Ｉ／Ｏ要求）を継続して発行することができる。この場合、手順２５０９にあるように、記憶サブシステムは当該ベンダ製ホストコンピュータからのログインが有効である間、当該ＬＵＮへのアクセス可否をチェックしなおすことなく、コマンド受信を継続することができる。ここで、当該ベンダ製ホストコンピュータのアクセスが許可されるＬＵＮは、実際には図２６の手順２６０７の参照動作でポイントされる、仮想ＬＵＮと一意に対応づけられた記憶サブシステム内のＬＵＮとなる。この手順２６０７の参照動作は、記憶サブシステムの内部的な参照作業であり、ホストコンピュータから意識されることはない。
【０１１６】
一方、記憶サブシステムが送信したＩｎｑｕｉｒｙデータフレームから、当該ＬＵへのアクセス拒否を認識した各ベンダ製ホストコンピュータは、記憶サブシステムへのログインが有効である間、当該ＬＵＮへ再度アクセスすることはない。
【０１１７】
本実施例では記憶サブシステムにアクセスしてきたホストコンピュータのＷＷＮを直接セキュリティの管理対象としているのではなく、ＷＷＮを構成する情報であるＣｏｍｐａｎｙ＿ＩＤを切り出して、当該ホストコンピュータが属するグループ、すなわちベンダを規定し、セキュリティの管理対象単位としていることが分かる。
【０１１８】
このことをより詳細に説明しているのが図２７と図２８である。２７０１の「ＬＵＮアクセス管理テーブル」では、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｅ１をもつベンダ製ホストコンピュータ群２７０５に対して、仮想ＬＵＮ０、１、２、３、４を通して、実際のＬＵＮ０、１、６、８、１５へのアクセスを許可している。同様に、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｅ２をもつベンダ製ホストコンピュータ群２７０６に対して、仮想ＬＵＮ０、１、２を通して、実際のＬＵＮ２、７、１０へのアクセスを、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｆ０をもつベンダ製ホストコンピュータ群２７０７に対しては、仮想ＬＵＮ０、１、２、３を通して、実際のＬＵＮ３、４、５、１４へのアクセスを許可している。
【０１１９】
これを図示したのが図２８である。種々のコンピュータ２８０３〜２８１１は、ファイバチャネルのファブリック２８０２を経由して、記憶サブシステム２８０１に単一のポートで接続している。ホストコンピュータ２８０３〜２８１１は、それぞれ世界でユニークなＷＷＮを有しているが、同じベンダ製のホストコンピュータは共通のＣｏｍｐａｎｙ＿ＩＤを有している。ホストコンピュータ２８０３、２８０４、２８０５、２８０８が同一のベンダＡ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｅ１とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１の「ＬＵＮアクセス管理テーブル」のセキュリティ規定から、記憶サブシステム２８０１内のＬＵＡ０〜４にのみアクセスが許可される。
【０１２０】
同様にホストコンピュータ２８０６、２８０７、２８１１が同一のベンダＢ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｅ２とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１のテーブルのセキュリティ規定から、記憶サブシステム２８０１内のＬＵＢ０〜２にのみアクセスが許可される。同様にホストコンピュータ２８０９、２８１０が同一のベンダＣ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｆ０とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１のテーブルのセキュリティ規定から、記憶サブシステム２８０１内のＬＵＣ０〜３にのみアクセスが許可される。これら異なるベンダ間では、２７０１のテーブルのセキュリティ規定に基づいたアクセスの排他論理により、異なるベンダ用にアクセス制限されたＬＵを見ることはできない。
以上のように、ベンダ毎のＬＵＮセキュリティを実現することができるが、これを応用することで、更にベンダ毎のホストコンピュータ群に記憶サブシステム資源を有効に提供することができる。例えば、２８１２のＬＵＡ０〜４、ＬＵＢ０〜２、ＬＵＣ０〜３は、それぞれアクセスしてくるベンダが異なることが自明であるため、それぞれに対して、アクセス許可したベンダ製ホストコンピュータＯＳ向けのフォーマットを実施することができる。また、それぞれに、アクセス許可したベンダ製ホストコンピュータＯＳ向けの固有の実行スクリプトや、アプリケーション・ソフトウェア、サービスを提供することも可能である。更には、それぞれに記憶サブシステム２８０１の制御情報を提供することで、ベンダ毎に当記憶サブシステム２８０１をカスタマイズさせることも可能である。
【０１２１】
以上のように、記憶サブシステム内に存在するＬＵと、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるコンピュータベンダのＣｏｍｐａｎｙ＿ＩＤを組み合わせて記憶サブシステムのポート毎に管理することにより、ホストコンピュータ側の処理を変えることなく、記憶サブシステム内の記憶資源を有効に提供でき、当該ホストコンピュータから当該ＬＵＮへのアクセス可否をベンダ単位で高速な判定ロジックで行う強固なＬＵＮセキュリティを実現することができる。
【０１２２】
本実施例では、ファイバチャネルを例に説明したが、実施においては、必ずしもファイバチャネルに限定する必要はなく、本記述と同等の機能を提供できるプロトコル環境であれば、その種別は問わない。また、記憶サブシステムに関しても、本実施例では、主にディスクアレイを対象に記述したが、記憶装置を可換媒体として置き換え、光ディスクライブラリや、テープライブラリなどに適用することも可能である。更に、ここではホストコンピュータのベンダ単位でグルーピングを行ったが、複数のホストコンピュータ間で共有可能な情報に基づき、任意のグループ分けが可能である。
【０１２３】
以上述べた実施例に基づき、ある記憶サブシステムにおいて本発明が実施されているか否かの確認方法としては、たとえば以下の方法がある。
【０１２４】
▲１▼図１４あるいは図２４に示すような、ホストを一意に識別する識別子と、論理ユニット番号（LUN）、および仮想的な論理ユニット番号（仮想LUN）を対応づけた管理テーブルを作成する必要がある、またはこの表を参照する処理が行われれば、本発明が実施されている可能性が高い。
【０１２５】
▲２▼ファイバモニタを用いて、ホスト−ストレージ間の通信に用いられるコマンドをモニターする。ホストが管理する論理ユニット番号（仮想LUN）と、実際にアクセスした論理ユニットに与えられた、ストレージが管理する論理ユニット番号（LUN）が一致しない場合があれば、本発明が実施されている可能性が高い。
【０１２６】
▲３▼ホストが管理する論理ユニット番号（仮想LUN）の絶対値の最大値と、ストレージが管理する論理ユニット番号（LUN）の絶対値の最大値が一致しない場合があれば、本発明が実施されている可能性が高い。（これは、複数のLUに対して、同一の仮想LUNを対応づけることが可能であることによる。）
【０１２７】
【発明の効果】
以上説明したように、管理テーブルを用いることによって、ホストコンピュータにユーザ運用希望にそった形で、記憶サブシステム内の論理ユニットを開示しながら、各ホストコンピュータに対してＬＵ単位にアクセス可否を制限し、不正アクセスを防止するセキュリティ機能を実現できる。更に、記憶サブシステム内のＬＵに対するアクセス可否判定は、問い合わせコマンド発行時点で判明し、以降この判定を繰り返す必要がないため、記憶サブシステムを高い性能で維持運用しながら、ＬＵに対する強固なセキュリティを確保することができる。
【０１２８】
また、本発明の上記実施例によれば、同一ベンダを示すＣｏｍｐａｎｙ＿ＩＤ等、ホストコンピュータのうちのあるグループに共通な識別情報をＷＷＮから部分的に切り出し、共通の識別情報を持つグループ単位に、記憶サブシステム内のＬＵにアクセス制限を実施することで、当該ホストコンピュータ群にのみ有効な記憶資源フォーマットや、アプリケーション、サービス、固有の処理などを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態におけるハードウェア構成図である。
【図２】本発明の実施形態におけるフレーム・フォーマットおよびそのフレームヘッダの詳細を示す図である。
【図３】本発明の実施形態におけるフレーム・フォーマットおよびそのフレームヘッダおよびデータフィールドの詳細を示す図である。
【図４】本発明の実施形態におけるログインプロセスを示す図である。
【図５】本発明の実施形態におけるＩｎｑｕｉｒｙコマンド送信時のフレーム・フォーマットの詳細を示す図である。
【図６】図５で示したＩｎｑｕｉｒｙコマンドに対して送信するＩｎｑｕｉｒｙデータ・フォーマットの詳細を示す図である。
【図７】本発明の実施形態におけるＩｎｑｕｉｒｙコマンドによる論理ユニットへのアクセス可否問い合わせシーケンスを示す図である。
【図８】本発明の実施形態におけるＬＵＮセキュリティの処理シーケンス概要を示す図である。
【図９】本発明の実施形態における「ＬＵＮアクセス管理テーブル」を示す図である。
【図１０】本発明を利用しないことによる不完全な「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の例を示す図である。
【図１１】図１０の状態を視覚的に表した図である。
【図１２】本発明を利用しないことによる不完全な「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の例を示す図である。
【図１３】図１２で示した状態を視覚的に示した図である。
【図１４】本発明の実施形態における「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の利用例を示す図である。
【図１５】本発明の実施形態における「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の利用例を示す図である。
【図１６】本発明の実施形態におけるＬＵＮセキュリティの効果を視覚的に示す図である。
【図１７】本発明の実施形態における「ＬＵＮアクセス管理テーブル」の作成シーケンスを示す図である。
【図１８】本発明の実施形態における「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の作成シーケンスを示す図である。
【図１９】本発明の実施形態における「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の作成シーケンスを示す図である。
【図２０】本発明の実施形態におけるＬＵＮセキュリティのホストコンピュータ送信のＩｎｑｕｉｒｙコマンドに対するＬＵＮアクセス可否判定シーケンスを示す図である。
【図２１】本発明の実施形態におけるＬＵＮセキュリティのホストコンピュータ送信のＩｎｑｕｉｒｙコマンドに対するＬＵＮアクセス可否判定シーケンスを示す図である。（つづき）
【図２２】本発明の実施形態におけるＬＵＮセキュリティの各テーブル間の参照関係を示す図である。
【図２３】本発明の実施形態におけるＷＷＮのフォーマットの一例を示す図である。
【図２４】本発明の実施形態におけるベンダ別「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の利用例を示す図である。
【図２５】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの処理シーケンス概要を示す図である。
【図２６】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの各テーブル間の参照関係を示す図である。
【図２７】本発明の実施形態におけるベンダ別「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の利用例を示す図である。
【図２８】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの効果を視覚的に示す図である。
【符号の説明】
２０１ フレーム・フォーマット
２０７ フレーム・ヘッダの詳細
２０８ Ｓ＿ＩＤ
３０５ データフィールドの詳細
３０７ Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ
３０８ Ｎｏｄｅ＿Ｎａｍｅ
５０６ データフィールドの詳細
６０１ Ｉｎｑｕｉｒｙコマンドに対して送信するＩｎｑｕｉｒｙデータ・フォーマット
６０４ クオリファイア（３ビット）の詳細
６０５〜６０７ クオリファイア（３ビット）
６０８ デバイス・タイプコード（５ビット）の種別
６０９ デバイス・タイプ
９０１ 不完全な「ＬＵＮアクセス管理テーブル」の第一の例
９０２〜９０４ 記憶サブシステムへアクセス管理されたホストコンピュータ１〜３のＷＷＮ
１００１ 不完全な「ＬＵＮアクセス管理テーブル」の第二の例
１１０１ 記憶サブシステム
１２０１ 不完全な「ＬＵＮアクセス管理テーブル」の第三の例
１３０８ 記憶サブシステムのポート配下に定義されたＬＵ群ＬＵ０〜１５
１４０１ 「ＬＵＮアクセス管理テーブル」の第一の例
１５０１ 「ＬＵＮアクセス管理テーブル」の第二の例
１９０１ 「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の第一の例
２３０１ ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）のフォーマットの一例
２４０１ ベンダ別「ＬＵＮアクセス管理テーブル」の第一の例
２７０１ ベンダ別「ＬＵＮアクセス管理テーブル」の第二の例
【発明の属する技術分野】
ホストコンピュータからアクセスされる記憶サブシステムに関係し、特にホストコンピュータから該記憶サブシステム内の論理ユニットがアクセスされる記憶サブシステムに関する。
【０００２】
【従来の技術】
これまで、ホストコンピュータから記憶サブシステムへの不正アクセスを防ぐセキュリティ手段として、ホストコンピュータ側のＯＳ（ｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ）の機能やミドルウェアもしくはアプリケーション・ソフトウェアを使用する例がよく知られている。
【０００３】
一方、近年、ファイバチャネル・プロトコルが規格化されたことによって、記憶サブシステムとホストコンピュータとのインタフェースにＳＣＳＩや、ＥＳＣＯＮ、ＴＣＰ／ＩＰなど様々な既存プロトコルの同時使用が可能となり、記憶サブシステム内の記憶資源が一層有効利用可能となってきた。
【０００４】
しかし、このような背景においては、複数のホストが1つの記憶サブシステムに対してアクセスしてくるため、従来通りのホスト側のＯＳやミドルウェア、アプリケーション・ソフトウェアだけでは、記憶サブシステム資源に対するセキュリティ機能として十分ではない、という危惧が発生してきた。このような現状に鑑み、記憶サブシステム資源（論理ユニット）に対するセキュリティ機能の実現手段として、特開平１０−３３３８３９号公報に開示がある。
【０００５】
上記公報による方法では、ホストコンピュータが起動する前に、予め記憶サブシステムにアクセスしてくる可能性があるホストコンピュータを一意に識別するＮ＿Ｐｏｒｔ＿Ｎａｍｅと、アクセスを許可する記憶サブシステム内の論理ユニットの組み合わせを管理したテーブルを記憶サブシステム内に保持する。ホストコンピュータは、起動されると記憶サブシステムに対して、フレームと呼ばれるファイバチャネルプロトコルで規定されたある情報単位によってＳＣＳＩコマンドを送信する。記憶サブシステムは、このＳＣＳＩコマンドを逐一判定して、その中からアクセス元であるホストコンピュータを規定するＮ＿Ｐｏｒｔ＿Ｎａｍｅを抽出する。
【０００６】
抽出されたＮ＿Ｐｏｒｔ＿Ｎａｍｅは、上述のＮ＿Ｐｏｒｔ＿Ｎａｍｅとアクセスを許可した記憶サブシステム内の論理ユニットの組み合わせテーブル上で検索され、そのエントリが存在する場合、当該のホストコンピュータは、当該の論理ユニットへのアクセスを許可され、エントリが存在しない場合、当該ホストコンピュータは、当該の論理ユニットへのアクセスを拒絶される。
【０００７】
【発明が解決しようとする課題】
記憶サブシステム内の記憶資源（論理ユニット）に対するセキュリティを実現する従来技術は、記憶サブシステムにフレームを送信してくるホストコンピュータに対して、逐一、そのアクセス可否を判定するため、データ転送にしめるアクセス可否判定のオーバーヘッドが大きく、高い性能を実現しにくいという課題があった。
【０００８】
また、従来技術は、記憶サブシステムにフレームを送信してくるホストコンピュータが、そのフレーム内に送信元ホストコンピュータを一意に識別するための情報をもたせる点で、ホストコンピュータ側に新たな機能が必要となっていた。
【０００９】
更に、従来技術では、アクセスしてくるホストコンピュータに対して、記憶サブシステム内の論理ユニット番号をそのまま開示するため、記憶サブシステムのポート配下にユーザの運用希望にそった論理ユニットの再配列を行えない。更にまた、多くのホストコンピュータでは、起動時に接続されている記憶サブシステムのＬＵ０にアクセスできない場合、そのＬＵ０以降の同系列のＬＵ（ＳＣＳＩ−２の規格では、この１系列は８つのＬＵで構成されるため、ＬＵ０〜ＬＵ７までが同系列となる。）には全く存在の問い合わせをしない、とするものが多い。
【００１０】
この場合、サブシステム内の論理ユニット番号をそのまま開示する方法では、アクセスが許可されているにもかかわらず、当該ＬＵＮを参照できないという事態が生じる。
【００１１】
本発明の第１の目的は、ホストコンピュータの既存処理を変更せずに、ホストコンピュータ毎にアクセス可能な論理ユニットを制限し、不正アクセスを防止するセキュリティ機能を、記憶資源の高効率利用と高速なアクセス判定ロジックと共に提供することである。
【００１２】
本発明の第２の目的は、ホストコンピュータの既存処理を変更せずに、同一ベンダ毎にアクセス可能な論理ユニットを制限し、不正アクセスを防止するセキュリティ機能を、記憶資源の高効率利用と高速なアクセス判定ロジックと共に提供することである。
【００１３】
また、本発明の第３の目的は、このセキュリティ機能に基づいてアクセスが許可されたベンダのホストコンピュータ群に対して、当該ベンダ向けの記憶資源フォーマットやサービスを提供することである。
【００１４】
【課題を解決するための手段】
上記課題を解決するために、本発明は以下の記憶サブシステムを提供する。
【００１５】
ホストコンピュータを一意に識別する情報（ＷＷＮ）、このホストコンピュータからのアクセスを許可した記憶サブシステム内の論理ユニット番号（ＬＵＮ）、および該論理ユニット番号に対してユーザが任意のリナンバリング方法で任意数再配列して割り当てた仮想的な論理ユニット番号（仮想ＬＵＮ）の対応を記述した管理テーブルと、これを格納する不揮発のメモリと、動的に割り当てられる管理番号（Ｓ＿ＩＤ）（注・「ホスト→ストレージのログイン時に動的に割り当てられる」から変更、以下同じ）、およびホストコンピュータを一意に識別する情報（ＷＷＮ）の対応を記述した管理テーブルと、これを格納する不揮発のメモリと、１つ以上の記憶装置と、これらの記憶装置に対してデータの読み書きを制御する記憶制御装置と、ホストコンピュータと接続を行うための１つ以上のポートと、前記記憶装置の記憶領域に対応した論理ユニットを有する記憶サブシステム。
【００１６】
この記憶サブシステムにおいては、ホスト識別情報ＷＷＮのかわりに、動的に割り当てられるＳ＿ＩＤを識別情報として用いるため、Ｉ／Ｏ処理ごとに、各ＬＵＮにアクセス可否を問い合わせる必要がなくなりアクセス時のオーバヘッドを削減することが可能となる。
【００１７】
また、仮想ＬＵＮを用いることにより、ユーザが任意の方法でＬＵＮの再配列を行なうことが可能となる。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータからのアクセスに応じてマップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記マップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号を含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、アクセス管理マップを有するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセスマネジメントマップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号とを含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされ、前記アクセスマネジメントマップは、前記ホストグループから前記論理ユニットへのアクセスを制御するのに使用されることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記ホストコンピュータからのデータを記憶する複数のディスクドライブと、アクセス管理テーブルを有するコントローラとを有し、前記ディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセス管理テーブルは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号とを含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされ、前記アクセスマ管理テーブルは、前記ホストグループから前記論理ユニットへのアクセスを制御するのに使用されることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じてアクセス管理マップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記アクセス管理マップは、前記複数のホストコンピュータの一部のホストグループの識別子と複数の仮想論理ユニット番号を含み、１以上の前記仮想論理ユニット番号は、前記ホストグループの前記識別子と前記論理ユニット番号のうちの１つの識別番号でリナンバーされる前記仮想論理ユニット番号でマップされることを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータからのアクセスに応じてマップを用いて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループと対応する複数の識別子及び複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号を含むアクセス管理マップを含み、各々のホストグループに割り当てられる前記仮想論理ユニット番号のいくつかはゼロから始まり、他はゼロ以外の番号で始まり、前記コントローラは、前記アクセス管理マップに応じて前記ホストグループから前記論理ユニットへのアクセスを制御することを特徴とする記憶システムである。
さらに、本発明は、複数のホストコンピュータとの結合に適応される記憶システムであって、前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じて制御するコントローラとを有し、前記複数のディスクドライブは複数の論理ユニットを形成し、前記論理ユニットは論理ユニット番号を有し、前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループの識別子と複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号をマップするアクセス管理テーブルを含み、前記論理ユニット番号はゼロでない番号で始まり、前記コントローラは、前記アクセス管理テーブルに応じた前記ホストグループから前記論理ユニットへのアクセスを制御すること特徴とする記憶システムである。
【００１８】
【発明の実施の形態】
本発明では、記憶サブシステムとホストコンピュータ間で使用するインタフェース・プロトコルの例にファイバチャネルを、その上で動作するコマンドセットの例にＳＣＳＩコマンドを用いて説明する。しかし本発明の適用は、ファイバチャネルとＳＣＳＩコマンドの組み合わせに限定されるものではなく、これらと同様に、ログイン、問い合わせといった機能、機構を提供可能なプロトコルであれば何でもかまわない。
【００１９】
本発明の第一の実施例を以下に示す。
【００２０】
ここで、ファイバチャネルは比較的新しいインタフェース・プロトコルであるため、はじめに、そのプロトコルの概要を説明する。
【００２１】
ファイバチャネルはシリアル転送方式のプロトコルであり、情報を非同期に送るため伝送媒体の帯域幅を有効に利用できる。また、ファイバチャネルは独自のコマンドセットを持たず、従来のＳＣＳＩ、ＥＳＣＯＮ、ＨＩＰＰＩ、ＩＰＩ−３、ＩＰ等といったコマンドセットのためのインフラとして使用される。これより、従来のプロトコル資産を継承可能であり、かつ、より高速で信頼性の高い多彩なデータ転送を可能とする。
【００２２】
また、ファイバチャネルはチャネルとネットワークの特長を併せ持つインタフェースである。ファイバチャネルでは一度、転送元と転送先が確定すれば、遅延が少ない高速な転送を実現できるが、これはチャネルの最大の特長の１つである。また、通信を希望する機器は、任意の契機でファイバチャネルの通信系に参加し、通信の目的となる相手の機器と相互に通信に関する取り決め情報を交換し、通信を開始することができるが、これはネットワークの特長である。ここで述べた相手機器との通信に関する取り決め情報交換の手続きを、とくにログインと呼ぶ。
【００２３】
ファイバチャネルのインタフェースを持つ機器をノードと呼び、実際のインタフェースにあたる物理的な口をポートと呼ぶ。ノードは１つ以上のポートを持つことが可能である。ファイバチャネルの系全体に同時に参加できるポートの数は、最大で２４ビットのアドレス数、すなわち約１６７７万個である。これらの接続を媒介するハードウェアをファブリックと呼ぶ。実際には、送信元および送信先のポートは、ファブリックを意識せずに互いのポートに関する情報のみを考慮して動作すればよい。
【００２４】
各ノードおよびポートには、標準化団体（ＩＥＥＥ）から一定のルールによって割り当てられる、世界中でユニークな識別子が記憶されている。これは従来からＴＣＰ／ＩＰなどで馴染みのＭＡＣアドレスに相当するものであり、ハードウェア的に固定なアドレスである。このアドレスにはＮ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿Ｎａｍｅの２種類があり、それぞれ８バイトのサイズを持つ。Ｎ＿Ｐｏｒｔ＿Ｎａｍｅはポート毎に固有の値（ハードウェア・アドレス）であり、Ｎｏｄｅ＿Ｎａｍｅはノード毎に固有の値（ハードウェア・アドレス）である。これらは、いずれも世界中でユニークな値であることから、ノードまたは、ポートを一意に識別できるアドレスとして、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）と呼ばれる。本特許の実施例では、ＷＷＮと記述した場合、Ｎ＿Ｐｏｒｔ＿Ｎａｍｅを指すものとする。
【００２５】
ファイバチャネルでは、通信はＯｒｄｅｒｅｄ Ｓｅｔと呼ばれる信号レベルの情報と、フレームと呼ばれる固定のフォーマットを持った論理的な情報とで行われる。図２はフレームの構造を示している。フレーム２０１は、フレームの始まりを示すＳＯＦ（Ｓｔａｒｔ ｏｆ Ｆｒａｍｅ）２０２と呼ばれる４バイトの識別子、リンク動作の制御やフレームの特徴づけを行う２４バイトのフレームヘッダ２０３、実際に転送される目的となるデータ部分であるデータフィールド２０４、４バイトの巡回冗長コード（ＣＲＣ）２０５、フレームの終わりを示すＥＯＦ（Ｅｎｄ ｏｆ Ｆｒａｍｅ）２０６と呼ばれる４バイトの識別子からなる。データフィールド２０４は０〜２１１２バイトの間で可変である。
【００２６】
次に、フレームヘッダの内容について説明する。２０７はフレームヘッダの構造について示している。ここではフレームヘッダ２０３の詳細構造２０７における、１ワード目の０〜２３ビット領域にあたるＳ＿ＩＤ２０８についてのみ説明する。Ｓ＿ＩＤ（Ｓｏｕｒｃｅ ＩＤ）２０８は当該フレームを送信するポートを識別するための３バイトのアドレス識別子であり、送受信されるすべてのフレームで有効な値を持つ。このＳ＿ＩＤは動的に変動する値であり、ファイバチャネルの規格セットの１つであるＦＣ＿ＰＨでは、Ｓ＿ＩＤをファブリックによって、初期化手続き時に割り当てられる、としている。割り当てられる値は、それぞれのポートがもつＮ＿Ｐｏｒｔ＿Ｎａｍｅまたは、Ｎｏｄｅ＿Ｎａｍｅに依存する。
【００２７】
次に、ファイバチャネルプロトコルに基づく、送信元の機器と送信先の機器が通信に関して互いに情報を交換するログイン手続きについて述べる。図３に、ＰＬＯＧＩフレームにおけるデータフィールド３０３の詳細構造について示す。フレーム、およびフレームヘッダの構造は図２と同様である。ＰＬＯＧＩフレームのデータフィールド３０３において、先頭から２１バイト目〜２９バイト目までの８バイトの領域がＮ＿Ｐｏｒｔ＿Ｎａｍｅ３０７を格納する領域であり、先頭から３０バイト目〜３８バイト目までの８バイトの領域がＮｏｄｅ＿Ｎａｍｅ３０８を格納する領域である。
【００２８】
図４は、送信元（ログイン要求元）４０１と送信先（ログイン受信先）４０２との間に取り交わされる情報のやりとりを示したものである。ファイバチャネルのログイン手続きには数種類存在するが、ここではクラス３のログインに関して述べる。
【００２９】
ログイン要求元は、ＰＬＯＧＩフレーム４０３をログイン受信先へ送信する。このフレームには、ログイン要求元のＮ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿Ｎａｍｅ、Ｓ＿ＩＤおよびその他の情報が含まれている。受信先の装置では、このフレームに含まれている情報を取り出し、ログインを承認する場合は、ＡＣＣ４０４と呼ばれるフレームをログイン要求元に対して送信する。一方、ログインを拒絶する場合は、ＬＳ＿ＲＪＴ４０５と呼ばれるフレームをログイン要求元に対して送信する。
【００３０】
ログイン要求元は、自らが送信したＰＬＯＧＩフレームに対してＡＣＣフレームの応答を検出すると、ログインが成功したことを知り、データ転送などのＩ／Ｏプロセスを開始できる状態となる。一方、ログイン要求元が、ＬＳ＿ＲＪＴを受信した場合はログインが成立しなかったこととなり、当該ログイン受信先へのＩ／Ｏプロセスは実行不可となる。ここではクラス３のログインについて述べたが、他のログインプロセスにおいても、ログイン要求元からログイン受信先へ渡すことのできる情報の中に、Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ、Ｎｏｄｅ＿ＮａｍｅおよびＳ＿ＩＤが含まれることにおいては同様である。
【００３１】
次に、ＳＣＳＩコマンドセットでは必ずサポートされている標準的なコマンドである、Ｉｎｑｕｉｒｙコマンドについて説明する。Ｉｎｑｕｉｒｙコマンドとは、Ｉ／Ｏプロセスを開始するのに先立ち、Ｉ／Ｏプロセスの対象となる論理ユニットに対して、その実装状態、準備状態を問い合わせるコマンドである。
【００３２】
図５は、ＳＣＳＩ規格で定義されたＩｎｑｕｉｒｙコマンドを、ファイバチャネル規格のフレームで送信する場合のデータフィールドの詳細構造を示している。フレーム、およびフレームヘッドの構造は図２と同様であるが、Ｓ＿ＩＤ２０８が含まれている。
【００３３】
データフィールド５０３には５０６のＦＣＰ＿ＣＭＮＤフォーマットに示すように、ＦＣＰ＿ＬＵＮ ５０７、ＦＣＰ＿ＣＮＴＬ５０８、ＦＣＰ＿ＣＤＢ５０９、ＦＣＰ＿ＤＬ５１０と呼ばれる領域がある。ここではＦＣＰ＿ＬＵＮ５０７、およびＦＣＰ＿ＣＤＢ５０９について述べる。ＦＣＰ＿ＬＵＮ５０７の中には、フレーム送信元が状態を問い合わせようとする、フレーム送信先のポートに関連付けられた論理ボリューム（目に見える単体としての記憶装置（物理ボリューム）に対して、便宜上仮想的に分割されナンバリングされた記憶領域）の識別子が格納されている。この識別子をＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）という。ＦＣＰ＿ＣＤＢ５０９の中には、ＳＣＳＩコマンドセットを使用する場合にはＳＣＳＩのコマンド記述ブロック（ＣＤＢ）と呼ばれる命令情報が格納される。このＦＣＰ＿ＣＤＢ５０９の中に、ＳＣＳＩのＩｎｑｕｉｒｙコマンド情報が格納されて、前述のＦＣＰ＿ＬＵＮ ５０７と共に、フレーム受信先へ情報が転送される。
【００３４】
次に、Ｉｎｑｕｉｒｙコマンドを受信したフレーム受信先が、問合せへの応答としてフレーム送信元へ返信する情報について述べる。この情報をＩｎｑｕｉｒｙデータという。図６にＩｎｑｕｉｒｙデータの抜粋を示す。ここでは、Ｉｎｑｕｉｒｙデータ６０１のうちでクオリファイア６０２と、デバイス・タイプ・コード６０３の２つについて述べる。クオリファイア（Ｐｅｒｉｐｈｅｒａｌ Ｑｕａｌｉｆｉｅｒ）６０２は、指定された論理ユニットの現在の状態を設定する３ビットの情報である。論理ユニットの状態６０４は、このクオリファイアのビットパターンによって示される論理ユニットの状態を示したものである。コード０００（２進数）６０５は、論理ユニットとして接続されている装置は、デバイス・タイプ・コード６０３の領域に示される種類の入出力機器であることを示している。本コードが設定されていても、その論理ユニットが使用可能、すなわちレディ状態であることを必ずしも示しているわけではない。
【００３５】
しかし、当該論理ユニットを使用できるのは本コードが設定されている場合に限られる。コード００１（２進数）６０６は、論理ユニットとして接続されている装置は、デバイス・タイプ・コード６０３の領域に示される種類の入出力機器であることを示しているが、そのロジカルユニットには実際の入出力機器が接続されていないことを示している。これは例えばＣＤ−ＲＯＭドライブが実装されているが、ＣＤ−ＲＯＭ媒体がドライブ内に挿入されていないような場合を示す。
【００３６】
コード０１１（２進数）６０７は、指定された論理ユニットがサポートされていないことを示す。従って指定された論理ユニットに装置が割り当てられることはない。本コードが設定されるときは、デバイス・タイプ・コード領域６０３にはかならず１Ｆ（１６進数）が設定される。
【００３７】
デバイス・タイプ・コード（Ｐｅｒｉｐｈｅｒａｌ Ｄｅｖｉｃｅ Ｔｙｐｅ）６０３は、指定された論理ユニットに実際に割り当てられている入出力機器の種別を示す５ビットの情報である。コード６０８は、各デバイスタイプ６０９に対応する１６進数のコードである。６０８に示されている情報のうち、未定義または未接続のデバイスを表す１Ｆ（１６進数）６１０が設定された場合、Ｉｎｑｕｉｒｙコマンド送信元が問い合わせたデバイスは未定義あるいは未接続であり、当該論理ユニットは送信元からは使用できない。
【００３８】
図７に、このＩｎｑｕｉｒｙコマンドを用いた論理ユニット問合せの手順を示す。論理ユニットにアクセスしようとするホストコンピュータ７０１は、アクセスしようとする論理ユニットをもつ記憶サブシステム７０２に対し、Ｉｎｑｕｉｒｙコマンドを格納したフレーム７０３を送信する。
【００３９】
このフレームには、ホストコンピュータのＳ＿ＩＤと、問合せを行う先の論理ユニットの識別子であるＬＵＮが含まれている。ここで、ＬＵＮについては、ＦＣＰ＿ＬＵＮ領域の他に、ＦＣＰ＿ＣＤＢ内のＩｎｑｕｉｒｙコマンド情報のフォーマット中にも設定することができる。どちらの値を使用しても得られる効果は同じであるが、本実施例ではＬＵＮの値はＦＣＰ＿ＬＵＮ ５０７に格納された値を使用するものとする。
【００４０】
Ｉｎｑｕｉｒｙコマンドを含むフレームを受信した記憶サブシステム７０２は、問合せに対して必要なＩｎｑｕｉｒｙデータを準備し、作成したＩｎｑｕｉｒｙデータを含むフレーム７０４をホストコンピュータに送信する。このときＩｎｑｕｉｒｙデータを格納するフレームを、ＦＣＰ＿ＤＡＴＡと呼ぶ。記憶サブシステムが、問合せのあった論理ユニットについて、クオリファイア０００（２進数）、デバイスタイプ００〜０９（１６進数）のいずれかを設定する場合７０４、このＩｎｑｕｉｒｙデータを受信したホストコンピュータは、当該論理ユニットに対して、以降Ｉ／Ｏの発行が可能となる。
【００４１】
一方、７０５に示すように、記憶サブシステムが、クオリファイア００１（２進数）または０１１（２進数）、デバイスタイプ１Ｆ（１６進数）を設定した場合、このＩｎｑｕｉｒｙデータ７０５を受信したホストコンピュータは、当該論理ユニットに対して、以降、Ｉ／Ｏの発行が不可能であることを認識する。
【００４２】
以上のことから、Ｉｎｑｕｉｒｙデータに格納するクオリファイア、およびデバイス・タイプ・コードを記憶サブシステム側でコントロールすれば、ホストコンピュータから記憶サブシステムの論理ユニットへのアクセス許可および不許可を制御できることが分かる。
【００４３】
続いて、本発明の処理の流れについて詳細を述べる。
【００４４】
はじめに図１は、本発明の実施例の装置構成を示したものである。本装置を記憶サブシステム１０１とよぶ。記憶サブシステム１０１は、ファイバチャネル・インタフェース用のポート１０２〜１０４を有し、ファイバチャネル・インタフェースを介して、ホストコンピュータ１０５〜１０７と物理的に接続されている。ホストコンピュータ１０５〜１０７もまた、ファイバチャネルインタフェース用のポート１０８〜１１２を有しており、ホストコンピュータ１０５〜１０７と記憶サブシステム１０１は、ファイバチャネル・プロトコルによる通信が可能である。ホストコンピュータには、１０５や１０６のように複数のファイバチャネル・ポートをもつものもあれば、１０７のように単一のファイバチャネル・ポートしかもたないものもある。
【００４５】
記憶サブシステム１０１とホストコンピュータ１０５〜１０７間のファイバチャネルインタフェースの接続形態（トポロジ）には、Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔや、アービトレーション・ループ接続、ファブリック接続等、いくつかの種類が存在するが、本発明はその接続形態には依存しないため、単にファイバチャネル１１３と記述する。
【００４６】
まず、記憶サブシステム１０１は、種々の演算や処理を行うマイクロプロセッサ１１４を有し、複数の記憶装置群１１５、およびこれらにデータの読み書きを制御して行う記憶制御装置１１６、さらに記憶装置群１１５と記憶制御装置１１６を接続するためのバス１１７を有している。また、記憶サブシステム１０１は、種々の演算や処理のワーク領域として使用するメモリ１１８と、種々の管理情報、管理テーブル等を保存しておく不揮発メモリ１１９を有する。更に、ホストコンピュータへの応答を速くするための工夫として、キャッシュ１２０を有している。また、記憶サブシステム１０１は、通信制御部１２１を有し、通信回線１２２を介して、保守用端末装置１２３と接続されている。
【００４７】
保守用端末装置１２３は、内部にマイクロプロセッサ１２４と、ユーザとのインタフェースとなる入力部１２５と処理の結果を出力する表示部１２６を有している。ユーザは、この入力部１２５を介して、本実施例で定義するいくつかのテーブルの設定を行うことができる。
【００４８】
図８において、本実施例の処理流れ概要を示す。初めに、手順８０１において、ユーザは前述の保守用端末装置１２３の入力部１２５を介して、記憶サブシステム内に存在するＬＵを規定するＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）と、そのＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮ（Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ）と、これにアクセスしてくるホストコンピュータに対してそのＬＵＮをどのように見せるかを決定する仮想ＬＵＮとを結び付けた「ＬＵＮアクセス管理テーブル」を作成する。
【００４９】
本テーブルは、記憶サブシステム内の不揮発メモリ１１９に保持される。各ホストコンピュータには、本テーブルの仮想ＬＵＮが見える。各ホストコンピュータのＷＷＮは既知である。
【００５０】
手順８０２において、各ホストコンピュータが記憶サブシステムに対して、ファイバチャネル・プロトコルに基づいてログインしてくると、記憶サブシステムはＰＬＯＧＩフレームから、当該ホストコンピュータのＷＷＮと、Ｓ＿ＩＤを切り出し、それらの組み合わせを記述した「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を作成し、不揮発メモリ１１９上にこれを保持する。記憶サブシステムはこの作業を全てのＰＬＯＧＩフレームに対して行う。
【００５１】
次に手順８０３において、記憶サブシステムは、各ホストコンピュータが記憶サブシステム内の論理ユニットの状態を知るために送信したＩｎｑｕｉｒｙコマンドを含むフレームを受信する。このフレームを受信した記憶サブシステムは、そのフレームのヘッダからＳ＿ＩＤを、データフィールドからＩｎｑｕｉｒｙコマンドの対象となるＬＵＮを切り出す。続いて、記憶サブシステムは、このＳ＿ＩＤをキーにして上述の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を検索し、このＳ＿ＩＤに相当するＷＷＮを取得する。
【００５２】
続いて、記憶サブシステムは、手順８０４において、得られたＷＷＮをキーにして上述の「ＬＵＮアクセス管理テーブル」を検索し、Ｉｎｑｕｉｒｙコマンドの対象となっているＬＵＮに相当する仮想ＬＵＮを「ＬＵＮアクセス管理テーブル」から取得する。ここでＩｎｑｕｉｒｙ対象となっているＬＵＮを仮想ＬＵＮとして取得する理由は、ホストコンピュータには仮想ＬＵＮが開示されているためである。
【００５３】
続いて手順８０５では、手順８０４の結果、当該ＷＷＮに対応する仮想ＬＵＮを取得できたか否かの判定を行う。取得できた場合、すなわち当該ＷＷＮに対応する仮想ＬＵＮが「ＬＵＮアクセス管理テーブル」上に存在した場合は、当該ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可される。対応する仮想ＬＵＮが該テーブルに存在しない場合は、当該ホストコンピュータにより当該仮想ＬＵＮへのアクセスが拒絶される。
【００５４】
手順８０５の結果、当該ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可される場合、記憶サブシステムは、手順８０６において、ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが実装済みの設定（すなわちアクセス可能である旨の設定）を行った上で、Ｉｎｑｕｉｒｙデータを送信する。
【００５５】
一方、当該仮想ＬＵへのアクセスが拒絶される場合、記憶サブシステムは、手順８０７によって、ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが未実装の設定（すなわちアクセス不可である旨の設定）を行った上で、Ｉｎｑｕｉｒｙデータを送信する。
【００５６】
Ｉｎｑｕｉｒｙデータを受信したホストコンピュータは、そのフレームを解析する。
【００５７】
解析の結果、記憶サブシステムの当該仮想ＬＵＮへのアクセス許可を認識すると、ホストコンピュータは以降、当該仮想ＬＵＮに対して、コマンド（Ｉ／Ｏ要求）を継続して発行することができる。この場合、手順８０８にあるように、記憶サブシステムは当該ホストコンピュータからのログインが有効である間は、当該ＬＵへのアクセス可否をチェックしなおすことなく、コマンド受信を継続することができる。
【００５８】
一方、当該ＬＵＮへのアクセス拒否を認識したホストコンピュータは、記憶サブシステムへのログインが有効である間、当該ＬＵへ再度アクセスすることはない。
【００５９】
以下、上記の記憶サブシステム内の特定ＬＵＮに対するホストコンピュータからのアクセス可否を制御する方式を、便宜的に「ＬＵＮセキュリティ」と呼ぶ。
【００６０】
次に、上記の各手順について詳細を示す。
【００６１】
はじめに、上記手順の「ＬＵＮアクセス管理テーブル」の作成について記述する。本発明におけるＬＵＮセキュリティは、記憶サブシステムのもつポート毎に管理されるものとし、ホストコンピュータは、この記憶サブシステムのポートを通して、記憶サブシステム内のＬＵにアクセスするものとする。この場合、最も簡単な方法として、ホストコンピュータを一意に識別する情報であるＷＷＮと、当該ホストコンピュータにアクセスを許可するＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）の対応を定義した、図９に示すようなテーブル９０１を、記憶サブシステム内に設ければよい。
【００６２】
しかし、ホストコンピュータと記憶サブシステム間に、ファイバチャネル対応のハブや、スイッチなどの機器類が存在するような使用環境では、９０１のテーブルだけでは不十分である。以下それを説明する。
【００６３】
テーブル９０１は、記憶サブシステム内のＬＵをその識別子であるＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）に基づき、そのままホストコンピュータのＷＷＮに対して割り当てている。図９では、ＷＷＮ９０２のホストコンピュータには、ＬＵ０〜２にのみアクセスが許可され、ＷＷＮ９０３のホストコンピュータは、ＬＵ３、４、および７にのみアクセスが許可され、ＷＷＮ９０４のホストコンピュータは、ＬＵ５〜６にのみアクセスが許可されている。
【００６４】
したがって、例えばＬＵ０〜２は、ＷＷＮ９０２のホストコンピュータ以外のホストコンピュータからは、アクセス不可となり、ＬＵＮセキュリティが実現される。しかし、今日多くのホストコンピュータでは、起動時に接続されている記憶サブシステムのＬＵ０にアクセスできない場合、そのＬＵ０以降の同系列のＬＵ（ＳＣＳＩ−２の規格では、この１系列は８つのＬＵで構成されるため、ＬＵ０〜ＬＵ７までが同系列となる。）には全く存在の問い合わせをしない、とするものが多い。
【００６５】
すると、テーブル９０１のような規定方法では、ホストコンピュータ９０３や９０４は、アクセス許可するＬＵＮがそれぞれ規定されていながら、ＬＵ０にアクセスできないために、テーブル９０１で規定したアクセス許可のＬＵＮを参照できない事態が発生してしまう。このような現象は、ディスクアレイ装置のような記憶資源を豊富に提供し得る装置においては、著しくその利用率を下げてしまうことになり無駄である。
【００６６】
そこで、これを防ぐためにホストコンピュータ９０３、９０４にＬＵ０へのアクセスを許可すると、ＬＵ０のセキュリティが保証されない。仮にこれを認めた場合にも、ホストコンピュータ９０３と９０４が異なるＯＳをもつホストコンピュータである場合、ＬＵ０を共有することは、それぞれのＯＳによるフォーマットの違いなどから困難である。
【００６７】
一方、図１０においてホストコンピュータが接続している当該ポート配下にＬＵ０が存在しなくても、全てのＬＵＮに対して存在の問い合わせを行う、ＷＷＮ１００２〜１００４を持つホストコンピュータ群が存在すると仮定する。ここでは、ＷＷＮ１００２のホストコンピュータは、ＬＵ０、１、７にのみアクセスが許可され、ＷＷＮ１００３のホストコンピュータは、ＬＵ３、５、６にのみアクセスが許可され、ＷＷＮ１００４のホストコンピュータは、ＬＵ２、４にのみアクセスが許可されている。
【００６８】
この状態を視覚的に表したのが図１１である。ホストコンピュータ１１０２〜１１０４は、図１０ＷＷＮ１００２〜１００４を持つホストコンピュータに相当する。ホストコンピュータ１１０２〜１１０４は、ファイバチャネル対応のハブや、スイッチ１１０５を経由して記憶サブシステムの同一のポート１１０６に接続している。このような使用環境において、各々のホストコンピュータ１１０２〜１１０４に対し、無計画にアクセス対象ＬＵＮを定義したり、以前割り当てたＬＵＮと異なるＬＵＮをアクセス対象として割り当てた場合、ホストコンピュータに記憶サブシステム内のＬＵＮをそのまま開示している１１０１のような記憶サブシステムではＬＵＮの開示方法に柔軟性がないため、当該ポート配下が、ＬＵ群１１０７のようにＬＵが離散した状態で見え、使用上、著しく管理しにくい状態となってしまう。
【００６９】
一方、最近、記憶サブシステムの１つのポート配下に９個以上のＬＵを定義しても、これを認識するホストコンピュータが存在するが、このようなホストコンピュータと従来のように１つの記憶サブシステムのポート配下にＬＵ０〜７までの８個のＬＵしかサポートしないホストコンピュータ間でＬＵＮセキュリティを実施した場合の問題点を示す。
【００７０】
図１２において、ＷＷＮ１２０２、１２０４を持つホストコンピュータが、接続する記憶サブシステムのポート配下にＬＵ０が存在しなくても、各ＬＵに存在の問い合わせを行う機構をもち、かつ、接続する記憶サブシステムのポート配下にＬＵを１６個まで認識する場合について以下説明する。
【００７１】
ＷＷＮ１２０３を持つホストコンピュータは、接続する記憶サブシステムのポート配下にＬＵ０が存在しなくても、各ＬＵに存在の問い合わせを行えるが、サポート可能なＬＵはＬＵ０〜７の範囲の８個までとする。テーブル１２０１から分かるように、ＷＷＮ１２０２を持つホストコンピュータはＬＵ０〜５の範囲でアクセスが許可されており、ＷＷＮ１２０３を持つホストコンピュータはＬＵ６〜１０の範囲で、またＷＷＮ１２０４を持つホストコンピュータはＬＵ１１〜１５の範囲でアクセスが許されている。この状態を視覚的に表したのが図１３である。
【００７２】
ホストコンピュータ１３０２〜１３０４は、図１２のＷＷＮ１２０２〜１２０４を持つホストコンピュータに相当する。ホストコンピュータ１３０２〜１３０４は、ファイバチャネル対応のハブや、スイッチ１３０５を経由して記憶サブシステムの同一のポート１３０６に接続している。このような使用環境において、各々のホストコンピュータ１３０２〜１３０４に対して、ＬＵ群１３０８のように記憶サブシステム内のＬＵを割り当てたとすると、ホストコンピュータＡ１３０２には、ＬＵ群１３０８中のＬＵ０〜５の範囲のみアクセス許可対象として見え、ホストコンピュータＣ１３０４には、ＬＵ群１３０８中のＬＵ１１〜１５の範囲のみアクセス許可対象として見え、それぞれＬＵＮセキュリティの目的を果たすことができる。しかし、ホストコンピュータＢ１３０３は、元々１ポート配下にＬＵ０〜７までの範囲で、８個までしかＬＵをサポートできないため、ＬＵ群１３０７の範囲内でしか問い合わせを実施することができない。よって、テーブル１２０１において、ＬＵ６〜１０までアクセス許可をしても、実際には、ＬＵ６、７にしかアクセスできないという問題が生じる。これも、記憶サブシステム内のＬＵをそのまま開示しているために起こる弊害である。
【００７３】
以上のような懸念を考慮して、本発明では、図１４に示すような「ＬＵＮアクセス管理テーブル」１４０１を定義する。テーブル１４０１は、図９のテーブル９０１、図１０のテーブル１００１、図１２のテーブル１２０１のように記憶サブシステム内のＬＵＮをＷＷＮに直接割り当てたテーブルとは異なり、記憶サブシステム内のＬＵＮと、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮを組み合わせて記憶サブシステムのポート毎に定義したテーブルである。
【００７４】
このテーブル１４０１において、ユーザは任意個数の任意ＬＵＮに対して、任意のリナンバリング方法で仮想ＬＵＮを対応づけることができる。その結果、この「ＬＵＮアクセス管理テーブル」１４０１を定義した記憶サブシステムでは、各ホストコンピュータに対して、ユーザの任意の使用希望に沿った形でＬＵＮを開示することができる。その際、各ホストコンピュータにアクセスが許可されるＬＵＮは、実際のＬＵＮ１４１７ではなく、仮想ＬＵＮ１４１６であるため、各ホストコンピュータに記憶サブシステム内のＬＵＮのばらつきや、ＬＵ０の有無などを意識させる必要がなく、ユーザの意志によって最適化された柔軟なＬＵＮ状態を提供することができる。
【００７５】
図１４において、ＷＷＮ１４０２を持つホストコンピュータは、仮想ＬＵＮ０〜３を通して、実際のＬＵＮ０〜３へアクセスが許可されている。以下ＷＷＮ１４０３〜１４１４を持つホストコンピュータも同様であり、それぞれ仮想ＬＵＮ１４１６を通して、対応する実際のＬＵＮ１４１７へアクセス許可される。これにより、各ホストコンピュータは、非ＬＵ０に対しても、ＬＵ０に対して行うような処理を実行すること等が可能となる。
【００７６】
この「ＬＵＮアクセス管理テーブル」１４０１において特徴的なことは、ＷＷＮ１４０２〜１４０５を持つホストコンピュータには、それぞれ接続ポート配下のＬＵ０にアクセスしているように見えているものの、実際には、それぞれの間で排他的なセキュリティが実現されながら、実際には異なったＬＵＮにアクセスし、記憶資源を効率的に使用できていることである。
実際のＬＵＮに対する仮想ＬＵＮのリナンバリングに関して詳細を示す。使用者が最もよく行うと思われる仮想ＬＵＮによるリナンバリング方法は、従来のＳＣＳＩ規格との対応を意識して、各ＷＷＮに対して、ＬＵ０を起点に１ずつＬＵＮが増えていくような番号付け、すなわちＷＷＮ１４０２〜１４０４の欄に見られるようなケースである。
【００７７】
しかし、運用面を考えて、ＷＷＮ１４０７，１４０８の欄のように、偶数のみの仮想ＬＵＮ、奇数のみの仮想ＬＵＮを対応させることも可能である。この例では、ＷＷＮ１４０７、１４０８を有するホストコンピュータがアクセス許可されているのは、実際には単に連続するＬＵ３０〜３４、およびＬＵ３５〜３８である。また、ＷＷＮ１４０９の欄のように、ＬＵ０が存在しなくても任意のＬＵＮを検出できるようなホストコンピュータに対しては、アクセス希望するＬＵＮに対応する仮想ＬＵＮにだけアクセス許可すればよい。また、ＷＷＮ１４１０および１４１１の欄のような対応づけは、２つ以上の異なるホストコンピュータを任意にグルーピングする際に便利である。さらにまた、WWN１４１２および１４１３の欄は、これら２つのWWNを有するホストコンピュータに対しては、異なるＬＵＮにアクセス許可しているように見せながら、実際には全く同じＬＵＮにアクセスさせ、同一の情報を開示したい場合に便利な運用である。
【００７８】
さらには、記憶サブシステムがＲＡＩＤを構成するディスクアレイ装置であるような場合に、異なるＲＡＩＤグループに属するＬＵをひとつずつ割り当て、最もＩ／Ｏに貢献する記憶装置（磁気ディスクドライブ）数が多くなるようにすることもできる。図１４の例でいうと、ＷＷＮ１４１４の欄がこれに該当する。
【００７９】
以上、本発明の「ＬＵＮアクセス管理テーブル」による仮想ＬＵＮと実際のＬＵＮ対応づけの効果について具体例に説明してきたが、これを視覚的に表すと図１６のようになる。対応する管理テーブル１５０２は図１５に示した。
【００８０】
テーブル１５０１で、各ホストコンピュータに割り当てた実際のＬＵ群１５０４は、実際には図１６の１６０８のように全く乱雑な配置をとっている。しかし、これをテーブル１５０１の仮想ＬＵ群１５０３で置換することで、各ホストコンピュータに記憶サブシステム１６０１内の実際のＬＵの配置状態１６０８に影響を受けない状態１６０７でＬＵを開示することができる。これにより、記憶サブシステム資源の柔軟な運用が可能となる。
【００８１】
本発明の「ＬＵＮアクセス管理テーブル」１４０１や１５０１は、図１７手順１７０１〜１７０３に示すように、記憶サブシステムの全ポートに対して定義された後、記憶サブシステム内の不揮発メモリに保持される。不揮発メモリに保持されることで、本テーブルは、記憶サブシステムの電源切断によっても消失しない。
【００８２】
続いて、記憶サブシステムがホストコンピュータから、ログインされる際の処理について説明する。本実施例では、一連のログイン処理を通じて、ホストコンピュータを一意に識別するＷＷＮと、ログイン以降に使用されるホストコンピュータを一意に識別するＳ＿ＩＤとを対応させる。ホストコンピュータが起動すると、図１８の手順１８０１において、記憶サブシステムは、ＰＬＯＧＩフレームを受信する。
【００８３】
ＰＬＯＧＩフレームを受信した記憶サブシステムは、手順１８０２において、フレームヘッダからホストコンピュータのＳ＿ＩＤを、手順１８０３において、データフィールドからホストコンピュータのＷＷＮ（Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ）を取得する。続いて、記憶サブシステムは手順１８０４において、このＷＷＮとＳ＿ＩＤの組み合わせを図１９に示す「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１に記録作成し、これを手順１８０５において、記憶サブシステム内の不揮発メモリに保持する。「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１は、記憶サブシステムのポート毎に作成される。
【００８４】
このテーブルに登録されたＷＷＮをもつホストコンピュータから、以後、コマンドが送信されると、記憶サブシステムはそのフレームヘッダからＳ＿ＩＤを取得し、「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１によってそのホストコンピュータのＷＷＮを検索することができる。記憶サブシステムは、この「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を不揮発メモリ上に保存すると、手順１８０６において、当該ホストコンピュータのログインを承認した旨のＡＣＣフレームを送信する。記憶サブシステムからＡＣＣフレームを受信したホストコンピュータは、これ以降、記憶サブシステムに対してＩｎｑｕｉｒｙコマンドを発行することができる。
【００８５】
続いて、ホストコンピュータからのＩｎｑｕｉｒｙコマンド受信と、これに対する記憶サブシステムのセキュリティ応答について説明する。図２０、図２１は、この一連の処理の流れを示したものであり、図２２は、この一連の処理の流れにおいて使用される各テーブルやパラメータの参照関係を示したものである。図２０の手順２００１において、記憶サブシステムは、ホストコンピュータからファイバチャネルに規定されたＦＣＰ＿ＣＭＮＤフレームを受信する。すると記憶サブシステムは、手順２００２において、そのＦＣＰ＿ＣＭＮＤのデータフレームの内容を解析する。
【００８６】
続いて記憶サブシステムは、手順２００３において、当該のＦＣＰ＿ＣＭＮＤの内容がＩｎｑｕｉｒｙコマンドであるか否かをチェックする。Ｉｎｑｕｉｒｙコマンドでない場合、記憶サブシステムは手順２００４において、そのコマンドに対応した処理を実行する。一方、Ｉｎｑｕｉｒｙコマンドであった場合、記憶サブシステムは手順２００５において、当該ＦＣＰ＿ＣＭＮＤフレームのヘッダからホストコンピュータのＳ＿ＩＤを取得し、手順２００６において、当該ＦＣＰ＿ＣＭＮＤフレームのデータフィールドのＦＣＰ＿ＬＵＮから対象とするＬＵＮを取得する。引き続き、記憶サブシステムは手順２００７において、得られたＳ＿ＩＤをキーにして、図１９の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」１９０１を検索し、このＳ＿ＩＤに対応するＷＷＮを取得する。ここまでの流れは、図２２の２２０１および手順２２０２、２２０３の参照動作を指す。
【００８７】
続いて、手順２００８において、このＷＷＮに対してアクセス許可されている仮想ＬＵＮ情報を取得する。そして、手順２１０９において、このＷＷＮをもつホストコンピュータのＩｎｑｕｉｒｙコマンドから得られたＬＵＮが、「ＬＵＮアクセス管理テーブル」上でアクセス許可された仮想ＬＵＮとして登録されているか否かを判定する。ここまでの流れは、図２２の手順２２０４および２２０５の参照動作を指す。
【００８８】
「ＬＵＮアクセス管理テーブル」の当該エントリに、手順２００６で得られたＬＵＮが仮想ＬＵＮとして登録されている場合、当該ホストコンピュータからその仮想ＬＵＮへのアクセスが許可されるため、記憶サブシステムは手順２１１０において、ホストコンピュータ応答用Ｉｎｑｕｉｒｙデータのクオリファイアに２進数の'０００'を、デバイスタイプに記憶サブシステムのデバイスタイプコードをセットする。
【００８９】
一方、「ＬＵＮアクセス管理テーブル」の当該エントリに、手順２００６で得られたＬＵＮが仮想ＬＵＮとして登録されていない場合、当該ホストコンピュータからその仮想ＬＵＮへのアクセスは拒絶されるため、記憶サブシステムは手順２１１１において、ホストコンピュータ応答用Ｉｎｑｕｉｒｙデータのクオリファイアに２進数の'００１'または、'０１１'を、デバイスタイプに１６進数の'１Ｆ'をセットする。
【００９０】
次に記憶サブシステムは、手順２１１２において、ＦＣＰ＿ＤＡＴＡフレームに上記の応答用Ｉｎｑｕｉｒｙデータをセットして、ホストコンピュータへ送信する。続いて記憶サブシステムは、手順２１１３において、ホストコンピュータのＩｎｑｕｉｒｙコマンドの応答を完了したことを示すＦＣＰ＿ＲＳＰフレームを送信する。
【００９１】
図２０の手順２１１０、２１１２に引き続いて、Ｉｎｑｕｉｒｙデータを含むＦＣＰ＿ＤＡＴＡを記憶サブシステムから受信したホストコンピュータは、当該ＬＵＮへのアクセスは可能と判断し、以降、当該仮想ＬＵＮへのアクセス可否を再度問い合わせることなく、アクセスを継続することができる。ここで、当該ホストコンピュータがアクセスするＬＵＮは、実際には図２２の手順２２０６の参照動作でポイントされる、仮想ＬＵＮと一意に対応づけられた記憶サブシステム内のＬＵＮとなる。この手順２２０６の参照動作は、記憶サブシステムの内部的な参照作業であり、ホストコンピュータから意識されることはない。一方、手順２１１１、２１１２に引き続いて、Ｉｎｑｕｉｒｙデータを含むＦＣＰ＿ＤＡＴＡを記憶サブシステムから受信したホストコンピュータは、当該ＬＵＮへのアクセスは不可能と判断し、以降、当該ＬＵＮへのアクセス可否を再度問い合わせることはなく、当該仮想ＬＵＮへもアクセスしない。
【００９２】
本実施例では、上記したようにホストコンピュータがアクセス可否を当該ＬＵＮへ問い合わせるのは、Ｉｎｑｕｉｒｙコマンド発行時だけである。つまり、ログインが有効である間は、この問い合わせを繰り返し行う必要がない。これにより、ホストコンピュータと記憶サブシステム間のデータ転送効率を落とすことなく、強固なＬＵＮセキュリティを実現できる。
【００９３】
以上のように、記憶サブシステム内に存在するＬＵと、そのＬＵＮをユーザ任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのＷＷＮとを組み合わせて記憶サブシステムのポート毎に管理することにより、ホストコンピュータ側の処理を変えることなく、記憶サブシステム内の記憶資源を有効に提供でき、当該ホストコンピュータから当該ＬＵＮへのアクセス可否を高速な判定ロジックで行う強固なＬＵＮセキュリティを実現できる。
【００９４】
本実施例では、ファイバチャネルを例に説明したが、実施においては、必ずしもファイバチャネルに限定する必要はなく、同等機能を提供可能なプロトコル環境であれば、その種別は問わない。また、記憶サブシステムに関しても、本実施例では、主にディスクアレイ装置を想定して記述しているが、記憶装置を可換媒体として置き換え、光ディスクライブラリや、テープライブラリなどに適用することも可能である。
【００９５】
本発明に係る第二の実施形態を以下に説明する。
【００９６】
第二の実施例も第一の実施例同様、ホストコンピュータと記憶サブシステムの間のインタフェース・プロトコルにファイバチャネルを例にして説明する。本実施例は、複数のホストコンピュータから構成される特定のグループに対してＬＵＮセキュリティを実現する方法である。
【００９７】
例えば、ホストコンピュータと記憶サブシステム間にファイバチャネル対応のハブや、スイッチなどの機器類が存在する図１、図１１、図１３、図１６のような使用環境では、記憶サブシステムの同一ポートにアクセスするホストコンピュータには様々なベンダ製のものが予想される。このような様々なベンダ製のホストコンピュータが共存するような環境では、しばしば記憶サブシステム内の記憶資源の共有、共用に関して問題が発生する。ベンダが異なれば、多くの場合、当該ホストコンピュータの搭載するＯＳが異なる。この問題は、ホストコンピュータが、ＷＳやメインフレーム等の場合にしばしば発生する。ホストコンピュータがＰＣの場合は、ベンダが異なっても、ＯＳは多くの場合Ｗｉｎｄｏｗｓ系であるためこの限りではない。
【００９８】
ＯＳが異なる場合、記憶資源に対するフォーマット形式や、アクセスのロジック、実行可能なスクリプト、アプリケーション等が異なるため異なるベンダ製ホストコンピュータ間で同一のボリュームを共有することは困難である。
【００９９】
そこで、記憶サブシステムの記憶資源に対して、ベンダ単位でグルーピングしてアクセスの可否を設定できるような、いわゆるベンダ毎のＬＵＮセキュリティ機能を実現することが望ましい。更に、このようなベンダ毎のＬＵＮセキュリティが実現できれば、アクセスを許可したグループ向けの記憶資源上に、当該ベンダ向けのサービスを提供したり、固有の処理を実行させることもできる。
【０１００】
そこで、記憶サブシステム内のＬＵへアクセスを許可する最小単位をホストコンピュータのベンダ単位で規定することを例に、第二の実施例を説明する。第二の実施例が第一の実施例と異なる点は、「ＬＵＮアクセス管理テーブル」の定義方法である。本実施例では、ＷＷＮの性質に注目してホストコンピュータのベンダを識別する。図２３の２３０１は、ＷＷＮのフォーマットの１つを示したものである。この図から分かるように、ＷＷＮ２３０１は、６０〜６３ビットエリア（４ビットエリア）に定義された識別フィールド２３０２と、３６〜５９ビット（２４ビットエリア）に定義されたＣｏｍｐａｎｙ＿ＩＤ２３０３と、０〜３５ビット（３６ビットエリア）に定義されたＶＳＩＤ（Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）２３０４から構成される。
【０１０１】
このＣｏｍｐａｎｙ＿ＩＤ２３０３は、従来からよく知られているＭＡＣアドレスを原則的に流用したもので、ＩＥＥＥが世界中のコンピュータベンダや、通信機器ベンダ等を対象にユニークに割り当てた識別情報である。ＶＳＩＤ２３０４は、ＩＥＥＥからＣｏｍｐａｎｙ＿ＩＤ２３０３の使用を認められたベンダが自社のルールで決定したユニークな識別情報であり、当該ベンダ内でユニークな値となる。各ベンダのＣｏｍｐａｎｙ＿ＩＤ２３０３は、ＩＥＥＥの出版物等を通して誰でも知ることができる情報であることから、このＣｏｍｐａｎｙ＿ＩＤ２３０３を予め調べておけば、記憶サブシステムにログインしてきたホストコンピュータがどのベンダ製のものであるかを識別することができる。
【０１０２】
ＷＷＮには、何種類かのフォーマット形式が規定されているが、Ｃｏｍｐａｎｙ＿ＩＤ２３０３とＶＳＩＤ（Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）２３０４を共通して内包している。
【０１０３】
図２４は、本実施例における「ＬＵＮアクセス管理テーブル」２４０１である。「ＬＵＮアクセス管理テーブル」２４０１は、記憶サブシステム内のＬＵＮ２３０４と、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮ２４０３と、その仮想ＬＵＮにアクセスする可能性のあるホストコンピュータのベンダを表すＣｏｍｐａｎｙ＿ＩＤ２４０２を組み合わせて記憶サブシステムのポート毎に定義したテーブルである。このテーブル２４０１においてユーザは、任意個数の任意ＬＵＮに対して、任意のリナンバリング方法で仮想ＬＵＮを対応づけることができる。
【０１０４】
その結果、この「ＬＵＮアクセス管理テーブル」２４０１を定義した記憶サブシステムでは、各ベンダ製のホストコンピュータに対して、ユーザの任意の使用希望に沿った形でＬＵＮを開示することができる。その際、各ベンダのホストコンピュータにアクセスが許可されるＬＵＮは、実際のＬＵＮ２４０４ではなく、仮想ＬＵＮ２４０３であるため、各ベンダ製のホストコンピュータに記憶サブシステム内のＬＵＮのばらつきや、ＬＵ０の有無などを意識させる必要がなく、ユーザの意志によって最適化されたＬＵＮ状態を提供することができる。
【０１０５】
一方、「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」に関しては、本発明の第一の実施例図１８に示したものと同様の作成方法で、図１９の１９０１と同様のフォーマットで実現することができる。
【０１０６】
続いて、図２５において、本実施例の全体の処理流れを示し、同時に図２６において、この一連の処理の流れにおいて使用される各テーブルとパラメタの参照関係を示す。初めに、手順２５０１において、ユーザは前述の保守用端末装置１２３の入力部１２５を介して、記憶サブシステム内に存在するＬＵＮと、そのＬＵＮにアクセスする可能性のあるホストコンピュータ群のベンダを表わすＣｏｍｐａｎｙ＿ＩＤと、これにアクセスしてくる各ベンダ製ホストコンピュータに対してそのＬＵＮをどのように見せるかを決定する仮想ＬＵＮとを結び付けた「ＬＵＮアクセス管理テーブル」を作成する。
【０１０７】
本テーブルは、記憶サブシステム内の不揮発メモリ１１９に保持される。各ベンダ製ホストコンピュータには、本テーブルの実際のＬＵＮではなく、仮想ＬＵＮが見える。Ｃｏｍｐａｎｙ＿ＩＤは各ベンダを表す既知の情報である。本実施例の「ＬＵＮアクセス管理テーブル」において、ＷＷＮではなくＷＷＮの構成要素であるＣｏｍｐａｎｙ＿ＩＤを使用するのは、ＬＵへのアクセス可否判定を個々のホストコンピュータ単位ではなく、各ベンダ単位で行うためである。
【０１０８】
手順２５０２において、各ホストコンピュータが記憶サブシステムに対して、ファイバチャネル・プロトコルに基づいてログインしてくると、記憶サブシステムはＰＬＯＧＩフレームから、当該ホストコンピュータのＮ＿Ｐｏｒｔ＿Ｎａｍｅ（以下、これをＷＷＮと記す）と、Ｓ＿ＩＤを切り出し、それらの組み合わせを記述した「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を作成し、不揮発メモリ１１９上にこれを保持する。記憶サブシステムは、この作業を全てのＰＬＯＧＩフレームに対して行う。
【０１０９】
次に手順２５０３において、記憶サブシステムは、各ベンダ製ホストコンピュータが記憶サブシステム内の論理ユニットの状態を知るために送信したＩｎｑｕｉｒｙコマンドを含むフレームを受信する。このフレームを受信した記憶サブシステムは、そのフレームのヘッダからＳ＿ＩＤを、データフィールドからＩｎｑｕｉｒｙコマンドの対象となるＬＵＮを切り出す。続いて、記憶サブシステムは、このＳ＿ＩＤをキーにして上述の「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」を検索し、このＳ＿ＩＤに相当するＷＷＮを取得する。
【０１１０】
続いて記憶サブシステムは、手順２５０４において、得られたＷＷＮから、図２３の２３０１のフォーマットに基づいて、２４ビットのＣｏｍｐａｎｙ＿ＩＤを切り出す。このＣｏｍｐａｎｙ＿ＩＤの切り出し作業は、第一の実施例の流れにはなかった本実施例に固有のものである。手順２５０３、２５０４は図２６の２６０１〜２６０４に相当する。
【０１１１】
次に記憶サブシステムは、得られたＣｏｍｐａｎｙ＿ＩＤをキーにして上述の「ＬＵＮアクセス管理テーブル」を検索し、Ｉｎｑｕｉｒｙコマンドの対象となっているＬＵＮに相当する仮想ＬＵＮを「ＬＵＮアクセス管理テーブル」から取得する。ここで、Ｉｎｑｕｉｒｙ対象となっているＬＵＮを仮想ＬＵＮとして取得する理由は、仮想ＬＵＮが記憶サブシステムのＬＵＮとして各ベンダ製ホストコンピュータに対して開示されているためである。
【０１１２】
続いて手順２５０６では、手順２５０５の結果、当該ＷＷＮに対応する仮想ＬＵＮを取得できたか否かの判定を行う。取得できた場合、すなわち当該ＷＷＮに対応する仮想ＬＵＮが「ＬＵＮアクセス管理テーブル」上に存在した場合が、当該ベンダ製ホストコンピュータに対して当該仮想ＬＵＮへのアクセスが許可される場合であり、存在しない場合が、当該ベンダ製ホストコンピュータに対して当該仮想ＬＵＮへのアクセスが拒絶される場合である。
【０１１３】
手順２５０６の結果、当該ベンダ製ホストコンピュータによる当該仮想ＬＵＮへのアクセスが許可できる場合、記憶サブシステムは、手順２５０７において、当該ベンダ製ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが実装済みの設定、すなわちアクセス可能である旨の設定を行った上で、Ｉｎｑｕｉｒｙデータを送信する。これら手順２５０５、２５０６、２５０７は図２６の２６０５、２６０６、２６０８に相当する。
【０１１４】
一方、手順２５０６の結果、当該ホストコンピュータにより当該仮想ＬＵＮへのアクセスが拒絶される場合、記憶サブシステムは、手順２５０８によって、当該ベンダ製ホストコンピュータの発行したＩｎｑｕｉｒｙコマンドに対して、対象ＬＵが未実装の設定、すなわちアクセス不可である旨の設定を行った上で、Ｉｎｑｕｉｒｙデータを送信する。Ｉｎｑｕｉｒｙデータを受信したホストコンピュータは、そのフレームを解析する。
【０１１５】
解析の結果、記憶サブシステムの当該仮想ＬＵＮへのアクセス許可を認識すると、当該ベンダ製ホストコンピュータは以降、当該仮想ＬＵＮに対して、コマンド（Ｉ／Ｏ要求）を継続して発行することができる。この場合、手順２５０９にあるように、記憶サブシステムは当該ベンダ製ホストコンピュータからのログインが有効である間、当該ＬＵＮへのアクセス可否をチェックしなおすことなく、コマンド受信を継続することができる。ここで、当該ベンダ製ホストコンピュータのアクセスが許可されるＬＵＮは、実際には図２６の手順２６０７の参照動作でポイントされる、仮想ＬＵＮと一意に対応づけられた記憶サブシステム内のＬＵＮとなる。この手順２６０７の参照動作は、記憶サブシステムの内部的な参照作業であり、ホストコンピュータから意識されることはない。
【０１１６】
一方、記憶サブシステムが送信したＩｎｑｕｉｒｙデータフレームから、当該ＬＵへのアクセス拒否を認識した各ベンダ製ホストコンピュータは、記憶サブシステムへのログインが有効である間、当該ＬＵＮへ再度アクセスすることはない。
【０１１７】
本実施例では記憶サブシステムにアクセスしてきたホストコンピュータのＷＷＮを直接セキュリティの管理対象としているのではなく、ＷＷＮを構成する情報であるＣｏｍｐａｎｙ＿ＩＤを切り出して、当該ホストコンピュータが属するグループ、すなわちベンダを規定し、セキュリティの管理対象単位としていることが分かる。
【０１１８】
このことをより詳細に説明しているのが図２７と図２８である。２７０１の「ＬＵＮアクセス管理テーブル」では、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｅ１をもつベンダ製ホストコンピュータ群２７０５に対して、仮想ＬＵＮ０、１、２、３、４を通して、実際のＬＵＮ０、１、６、８、１５へのアクセスを許可している。同様に、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｅ２をもつベンダ製ホストコンピュータ群２７０６に対して、仮想ＬＵＮ０、１、２を通して、実際のＬＵＮ２、７、１０へのアクセスを、Ｃｏｍｐａｎｙ＿ＩＤ００００Ｆ０をもつベンダ製ホストコンピュータ群２７０７に対しては、仮想ＬＵＮ０、１、２、３を通して、実際のＬＵＮ３、４、５、１４へのアクセスを許可している。
【０１１９】
これを図示したのが図２８である。種々のコンピュータ２８０３〜２８１１は、ファイバチャネルのファブリック２８０２を経由して、記憶サブシステム２８０１に単一のポートで接続している。ホストコンピュータ２８０３〜２８１１は、それぞれ世界でユニークなＷＷＮを有しているが、同じベンダ製のホストコンピュータは共通のＣｏｍｐａｎｙ＿ＩＤを有している。ホストコンピュータ２８０３、２８０４、２８０５、２８０８が同一のベンダＡ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｅ１とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１の「ＬＵＮアクセス管理テーブル」のセキュリティ規定から、記憶サブシステム２８０１内のＬＵＡ０〜４にのみアクセスが許可される。
【０１２０】
同様にホストコンピュータ２８０６、２８０７、２８１１が同一のベンダＢ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｅ２とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１のテーブルのセキュリティ規定から、記憶サブシステム２８０１内のＬＵＢ０〜２にのみアクセスが許可される。同様にホストコンピュータ２８０９、２８１０が同一のベンダＣ製であり、そのＣｏｍｐａｎｙ＿ＩＤは、００００Ｆ０とすると、これらのホストコンピュータは、所属するファイバチャネルのドメインが異なっても、２７０１のテーブルのセキュリティ規定から、記憶サブシステム２８０１内のＬＵＣ０〜３にのみアクセスが許可される。これら異なるベンダ間では、２７０１のテーブルのセキュリティ規定に基づいたアクセスの排他論理により、異なるベンダ用にアクセス制限されたＬＵを見ることはできない。
以上のように、ベンダ毎のＬＵＮセキュリティを実現することができるが、これを応用することで、更にベンダ毎のホストコンピュータ群に記憶サブシステム資源を有効に提供することができる。例えば、２８１２のＬＵＡ０〜４、ＬＵＢ０〜２、ＬＵＣ０〜３は、それぞれアクセスしてくるベンダが異なることが自明であるため、それぞれに対して、アクセス許可したベンダ製ホストコンピュータＯＳ向けのフォーマットを実施することができる。また、それぞれに、アクセス許可したベンダ製ホストコンピュータＯＳ向けの固有の実行スクリプトや、アプリケーション・ソフトウェア、サービスを提供することも可能である。更には、それぞれに記憶サブシステム２８０１の制御情報を提供することで、ベンダ毎に当記憶サブシステム２８０１をカスタマイズさせることも可能である。
【０１２１】
以上のように、記憶サブシステム内に存在するＬＵと、そのＬＵＮをユーザの任意のリナンバリング方法で定義しなおした仮想ＬＵＮと、その仮想ＬＵＮにアクセスする可能性のあるコンピュータベンダのＣｏｍｐａｎｙ＿ＩＤを組み合わせて記憶サブシステムのポート毎に管理することにより、ホストコンピュータ側の処理を変えることなく、記憶サブシステム内の記憶資源を有効に提供でき、当該ホストコンピュータから当該ＬＵＮへのアクセス可否をベンダ単位で高速な判定ロジックで行う強固なＬＵＮセキュリティを実現することができる。
【０１２２】
本実施例では、ファイバチャネルを例に説明したが、実施においては、必ずしもファイバチャネルに限定する必要はなく、本記述と同等の機能を提供できるプロトコル環境であれば、その種別は問わない。また、記憶サブシステムに関しても、本実施例では、主にディスクアレイを対象に記述したが、記憶装置を可換媒体として置き換え、光ディスクライブラリや、テープライブラリなどに適用することも可能である。更に、ここではホストコンピュータのベンダ単位でグルーピングを行ったが、複数のホストコンピュータ間で共有可能な情報に基づき、任意のグループ分けが可能である。
【０１２３】
以上述べた実施例に基づき、ある記憶サブシステムにおいて本発明が実施されているか否かの確認方法としては、たとえば以下の方法がある。
【０１２４】
▲１▼図１４あるいは図２４に示すような、ホストを一意に識別する識別子と、論理ユニット番号（LUN）、および仮想的な論理ユニット番号（仮想LUN）を対応づけた管理テーブルを作成する必要がある、またはこの表を参照する処理が行われれば、本発明が実施されている可能性が高い。
【０１２５】
▲２▼ファイバモニタを用いて、ホスト−ストレージ間の通信に用いられるコマンドをモニターする。ホストが管理する論理ユニット番号（仮想LUN）と、実際にアクセスした論理ユニットに与えられた、ストレージが管理する論理ユニット番号（LUN）が一致しない場合があれば、本発明が実施されている可能性が高い。
【０１２６】
▲３▼ホストが管理する論理ユニット番号（仮想LUN）の絶対値の最大値と、ストレージが管理する論理ユニット番号（LUN）の絶対値の最大値が一致しない場合があれば、本発明が実施されている可能性が高い。（これは、複数のLUに対して、同一の仮想LUNを対応づけることが可能であることによる。）
【０１２７】
【発明の効果】
以上説明したように、管理テーブルを用いることによって、ホストコンピュータにユーザ運用希望にそった形で、記憶サブシステム内の論理ユニットを開示しながら、各ホストコンピュータに対してＬＵ単位にアクセス可否を制限し、不正アクセスを防止するセキュリティ機能を実現できる。更に、記憶サブシステム内のＬＵに対するアクセス可否判定は、問い合わせコマンド発行時点で判明し、以降この判定を繰り返す必要がないため、記憶サブシステムを高い性能で維持運用しながら、ＬＵに対する強固なセキュリティを確保することができる。
【０１２８】
また、本発明の上記実施例によれば、同一ベンダを示すＣｏｍｐａｎｙ＿ＩＤ等、ホストコンピュータのうちのあるグループに共通な識別情報をＷＷＮから部分的に切り出し、共通の識別情報を持つグループ単位に、記憶サブシステム内のＬＵにアクセス制限を実施することで、当該ホストコンピュータ群にのみ有効な記憶資源フォーマットや、アプリケーション、サービス、固有の処理などを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態におけるハードウェア構成図である。
【図２】本発明の実施形態におけるフレーム・フォーマットおよびそのフレームヘッダの詳細を示す図である。
【図３】本発明の実施形態におけるフレーム・フォーマットおよびそのフレームヘッダおよびデータフィールドの詳細を示す図である。
【図４】本発明の実施形態におけるログインプロセスを示す図である。
【図５】本発明の実施形態におけるＩｎｑｕｉｒｙコマンド送信時のフレーム・フォーマットの詳細を示す図である。
【図６】図５で示したＩｎｑｕｉｒｙコマンドに対して送信するＩｎｑｕｉｒｙデータ・フォーマットの詳細を示す図である。
【図７】本発明の実施形態におけるＩｎｑｕｉｒｙコマンドによる論理ユニットへのアクセス可否問い合わせシーケンスを示す図である。
【図８】本発明の実施形態におけるＬＵＮセキュリティの処理シーケンス概要を示す図である。
【図９】本発明の実施形態における「ＬＵＮアクセス管理テーブル」を示す図である。
【図１０】本発明を利用しないことによる不完全な「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の例を示す図である。
【図１１】図１０の状態を視覚的に表した図である。
【図１２】本発明を利用しないことによる不完全な「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の例を示す図である。
【図１３】図１２で示した状態を視覚的に示した図である。
【図１４】本発明の実施形態における「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の利用例を示す図である。
【図１５】本発明の実施形態における「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の利用例を示す図である。
【図１６】本発明の実施形態におけるＬＵＮセキュリティの効果を視覚的に示す図である。
【図１７】本発明の実施形態における「ＬＵＮアクセス管理テーブル」の作成シーケンスを示す図である。
【図１８】本発明の実施形態における「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の作成シーケンスを示す図である。
【図１９】本発明の実施形態における「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の作成シーケンスを示す図である。
【図２０】本発明の実施形態におけるＬＵＮセキュリティのホストコンピュータ送信のＩｎｑｕｉｒｙコマンドに対するＬＵＮアクセス可否判定シーケンスを示す図である。
【図２１】本発明の実施形態におけるＬＵＮセキュリティのホストコンピュータ送信のＩｎｑｕｉｒｙコマンドに対するＬＵＮアクセス可否判定シーケンスを示す図である。（つづき）
【図２２】本発明の実施形態におけるＬＵＮセキュリティの各テーブル間の参照関係を示す図である。
【図２３】本発明の実施形態におけるＷＷＮのフォーマットの一例を示す図である。
【図２４】本発明の実施形態におけるベンダ別「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第一の利用例を示す図である。
【図２５】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの処理シーケンス概要を示す図である。
【図２６】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの各テーブル間の参照関係を示す図である。
【図２７】本発明の実施形態におけるベンダ別「ＬＵＮアクセス管理テーブル」のフォーマットおよび、その第二の利用例を示す図である。
【図２８】本発明の実施形態におけるベンダ別ＬＵＮセキュリティの効果を視覚的に示す図である。
【符号の説明】
２０１ フレーム・フォーマット
２０７ フレーム・ヘッダの詳細
２０８ Ｓ＿ＩＤ
３０５ データフィールドの詳細
３０７ Ｎ＿Ｐｏｒｔ＿Ｎａｍｅ
３０８ Ｎｏｄｅ＿Ｎａｍｅ
５０６ データフィールドの詳細
６０１ Ｉｎｑｕｉｒｙコマンドに対して送信するＩｎｑｕｉｒｙデータ・フォーマット
６０４ クオリファイア（３ビット）の詳細
６０５〜６０７ クオリファイア（３ビット）
６０８ デバイス・タイプコード（５ビット）の種別
６０９ デバイス・タイプ
９０１ 不完全な「ＬＵＮアクセス管理テーブル」の第一の例
９０２〜９０４ 記憶サブシステムへアクセス管理されたホストコンピュータ１〜３のＷＷＮ
１００１ 不完全な「ＬＵＮアクセス管理テーブル」の第二の例
１１０１ 記憶サブシステム
１２０１ 不完全な「ＬＵＮアクセス管理テーブル」の第三の例
１３０８ 記憶サブシステムのポート配下に定義されたＬＵ群ＬＵ０〜１５
１４０１ 「ＬＵＮアクセス管理テーブル」の第一の例
１５０１ 「ＬＵＮアクセス管理テーブル」の第二の例
１９０１ 「ＷＷＮ−Ｓ＿ＩＤ変換テーブル」の第一の例
２３０１ ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）のフォーマットの一例
２４０１ ベンダ別「ＬＵＮアクセス管理テーブル」の第一の例
２７０１ ベンダ別「ＬＵＮアクセス管理テーブル」の第二の例
Claims (24)
- 複数のホストコンピュータとの結合に適応される記憶システムであって、
前記ホストコンピュータからのデータを記憶する複数のディスクドライブと、
アクセス管理テーブルを有するコントローラとを有し、
前記ディスクドライブは複数の論理ユニットを形成し、
前記論理ユニットは論理ユニット番号を有し、
前記アクセス管理テーブルは、
前記複数のホストコンピュータのうちの一部の複数のホストコンピュータからなるホストグループを識別するホストグループ識別子と、各々が前記論理ユニット番号のうちの１つでリナンバーされる複数の仮想論理ユニット番号とを含み、
前記ホストグループの前記識別子と、前記複数の仮想論理ユニット番号のうちの少なくとも1つと、を対応付け、
前記ホストグループから前記論理ユニットへのアクセスを制御するのに使用されることを特徴とする記憶システム。 - 前記アクセステーブルは、
前記ホストグループの前記識別子と、前記複数の仮想論理ユニット番号のうちの少なくとも1つと、当該複数の仮想論理ユニット番号のうちの少なくとも1つがリナンバーされる前記論理ユニット番号のうちの１つと、を対応付けていることを特徴とする請求項1に記載の記憶システム。 - 前記アクセス管理テーブルは、異なるホストグループにそれぞれ割当てられた同一の仮想論理ユニット番号に、それぞれ異なる論理ユニット番号を対応付けられることを特徴とする請求項２に記載の記憶システム。
- 前記アクセス管理テーブルは、同じ仮想論理ユニット番号で1つのホストグループに異なる論理ユニット番号を対応付けないことを特徴とする請求項２に記載の記憶システム。
- 複数のホストコンピュータとの結合に適応される記憶システムであって、
前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、
前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じてアクセス管理マップを用いて制御するコントローラとを有し、
前記複数のディスクドライブは複数の論理ユニットを形成し、
前記論理ユニットは論理ユニット番号を有し、
前記アクセス管理マップは、
前記複数のホストコンピュータのうちの一部の複数のホストコンピュータからなるホストグループを識別するホストグループ識別子と、各々が前記論理ユニット番号のうちの１つでリナンバーされる複数の仮想論理ユニット番号を含み、
前記ホストグループの前記識別子と、前記仮想論理ユニット番号のうちの少なくとも１つと、を対応付けられることを特徴とする記憶システム。 - 前記アクセス管理マップは、
前記ホストグループの前記識別子と、前記複数の仮想論理ユニット番号のうちの少なくとも1つと、当該複数の仮想論理ユニット番号のうちの少なくとも1つがリナンバーされる前記論理ユニット番号のうちの１つと、を対応付けていることを特徴とする請求項５に記載の記憶システム。 - 前記アクセス管理マップは、異なるホストグループにそれぞれ割当てられた同一の仮想論理ユニット番号に、それぞれ異なる論理ユニット番号を対応付けられることを特徴とする請求項６に記載の記憶システム。
- 前記アクセス管理マップは、同じ仮想論理ユニット番号で1つのホストグループに異なる論理ユニット番号を対応付けないことを特徴とする請求項６に記載の記憶システム。
- 各々のホストグループに割り当てられる仮想論理ユニット番号は、ゼロから始まり、
前記各々の仮想論理ユニット番号は、前記論理ユニット番号のうちの１つの識別子でリナンバーされることを特徴とする請求項２又は請求項６に記載の記憶システム。 - 各々のホストグループに割り当てられる仮想論理ユニット番号は、ゼロから始まるとともに１ずつ増加し、
前記各々の仮想論理ユニット番号は、前記論理ユニット番号のうちの１つの識別子でリナンバーされることを特徴とする請求項２又は請求項６に記載の記憶システム。 - 各々の前記仮想論理ユニット番号は、ユーザによって指定されることを特徴とする請求項２又は請求項６に記載の記憶システム。
- 前記ホストコンピュータは、互いに関連付けられた前記ホストグループを含むことを特徴とする請求項２又は請求項６に記載の記憶システム。
- 複数のホストコンピュータとの結合に適応される記憶システムであって、
前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、
前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータからのアクセスに応じてマップを用いて制御するコントローラとを有し、
前記複数のディスクドライブは複数の論理ユニットを形成し、
前記論理ユニットは論理ユニット番号を有し、
前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループと対応する複数の識別子及び複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号を含むアクセス管理マップを含み、
各々のホストグループに割り当てられる前記仮想論理ユニット番号のいくつかはゼロから始まり、他はゼロ以外の番号で始まり、
前記コントローラは、前記アクセス管理マップに応じて前記ホストグループから前記論理ユニットへのアクセスを制御することを特徴とする記憶システム。 - 前記アクセス管理マップは、
前記ホストグループの前記識別子と、前記複数の仮想論理ユニット番号のうちの少なくとも1つと、当該複数の仮想論理ユニット番号のうちの少なくとも1つがリナンバーされる前記論理ユニット番号のうちの１つと、を対応付けていることを特徴とする請求項１３に記載の記憶システム。 - 前記アクセス管理マップは、異なるホストグループにそれぞれ割当てられた同一の仮想論理ユニット番号に、それぞれ異なる論理ユニット番号を対応付けられることを特徴とする請求項１４記載の記憶システム。
- 前記アクセス管理マップは、同じ仮想論理ユニット番号で1つのホストグループに異なる論理ユニット番号を対応付けないことを特徴とする請求項１４記載の記憶システム。
- 前記ホストグループに対応する仮想論理ユニット番号のいつくかは、１ずつ増加することを特徴とする請求項１４記載の記憶システム。
- 各々の前記仮想論理ユニット番号は、ユーザによって指定されることを特徴とする請求項１４記載の記憶システム。
- 複数のホストコンピュータとの結合に適応される記憶システムであって、
前記複数のホストコンピュータからのデータを記憶する複数のディスクドライブと、
前記複数のディスクドライブからのデータの読み取り又は前記複数のディスクドライブへのデータの書き込みを前記複数のホストコンピュータから前記論理ユニットへのアクセスに応じて制御するコントローラとを有し、
前記複数のディスクドライブは複数の論理ユニットを形成し、
前記論理ユニットは論理ユニット番号を有し、
前記コントローラは、前記ホストコンピュータのいくつかを有するホストグループの識別子と複数の前記論理ユニット番号のうちの１つでリナンバーされた仮想論理ユニット番号を対応付けるアクセス管理テーブルを含み、
前記論理ユニット番号はゼロでない番号で始まり、
前記コントローラは、前記アクセス管理テーブルに応じた前記ホストグループから前記論理ユニットへのアクセスを制御すること特徴とする記憶システム。 - 前記アクセス管理テーブルは、
前記ホストグループの前記識別子と、前記複数の仮想論理ユニット番号のうちの少なくとも1つと、当該複数の仮想論理ユニット番号のうちの少なくとも1つがリナンバーされる前記論理ユニット番号のうちの１つと、を対応付けていることを特徴とする請求項１９に記載の記憶システム。 - 前記アクセス管理テーブルは、異なるホストグループにそれぞれ割当てられた同一の仮想論理ユニット番号に、それぞれ異なる論理ユニット番号を対応付けられることを特徴とする請求項２０記載の記憶システム。
- 前記アクセス管理テーブルは、同じ仮想論理ユニット番号で1つのホストグループに異なる論理ユニット番号を対応付けないことを特徴とする請求項２０記載の記憶システム。
- 前記ホストグループと対応する仮想論理ユニット番号は、前記ゼロでない番号で始まるとともに１ずつ増加することを特徴とする請求項２０記載の記憶システム。
- 各々の前記仮想論理ユニット番号は、ユーザによって指定されることを特徴とする請求項２０記載の記憶システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000244020A JP4598248B2 (ja) | 2000-01-14 | 2000-08-07 | 記憶サブシステムのセキュリティシステム |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-10115 | 2000-01-14 | ||
| JP2000010115 | 2000-01-14 | ||
| JP2000244020A JP4598248B2 (ja) | 2000-01-14 | 2000-08-07 | 記憶サブシステムのセキュリティシステム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2001265655A JP2001265655A (ja) | 2001-09-28 |
| JP2001265655A5 JP2001265655A5 (ja) | 2007-08-16 |
| JP4598248B2 true JP4598248B2 (ja) | 2010-12-15 |
Family
ID=26583761
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000244020A Expired - Fee Related JP4598248B2 (ja) | 2000-01-14 | 2000-08-07 | 記憶サブシステムのセキュリティシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4598248B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3993773B2 (ja) | 2002-02-20 | 2007-10-17 | 株式会社日立製作所 | ストレージサブシステム、記憶制御装置及びデータコピー方法 |
| JP4379860B2 (ja) | 2003-04-08 | 2009-12-09 | 株式会社日立製作所 | 記憶制御装置及びその制御方法 |
| JP4429634B2 (ja) | 2003-06-02 | 2010-03-10 | 株式会社日立製作所 | ストレージシステム、及びストレージシステムの制御方法 |
| JP4152866B2 (ja) | 2003-11-19 | 2008-09-17 | 株式会社日立製作所 | 記憶装置、記憶装置システム、および、通信制御方法 |
| US7137031B2 (en) * | 2004-02-25 | 2006-11-14 | Hitachi, Ltd. | Logical unit security for clustered storage area networks |
| JP3976324B2 (ja) | 2004-02-27 | 2007-09-19 | 株式会社日立製作所 | セキュリティレベルに応じて記憶領域を計算機に割り当てるシステム |
| US7574529B2 (en) * | 2004-06-22 | 2009-08-11 | International Business Machines Corporation | Addressing logical subsystems in a data storage system |
| JP4484597B2 (ja) * | 2004-06-28 | 2010-06-16 | 株式会社日立製作所 | ストレージ装置及びストレージ装置の排他制御方法 |
| JP4612373B2 (ja) | 2004-09-13 | 2011-01-12 | 株式会社日立製作所 | 記憶装置及び記憶装置を用いた情報システム |
| JP2007018401A (ja) | 2005-07-11 | 2007-01-25 | Hitachi Ltd | 記憶制御装置、記憶制御装置の上位インターフェース制御部及び記憶制御装置の情報保護方法 |
| JP2007087059A (ja) | 2005-09-21 | 2007-04-05 | Hitachi Ltd | 記憶制御システム |
| JP4671353B2 (ja) | 2005-12-14 | 2011-04-13 | 株式会社日立製作所 | ストレージ装置及びその制御方法 |
| WO2016103416A1 (ja) * | 2014-12-25 | 2016-06-30 | 株式会社日立製作所 | ストレージシステム、ストレージ装置およびアクセス制御方法 |
| JP6343716B2 (ja) * | 2015-06-24 | 2018-06-13 | 株式会社日立製作所 | 計算機システム及び記憶制御方法 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000000881A1 (en) * | 1998-06-30 | 2000-01-06 | Emc Corporation | Method and apparatus for authenticating connections to a storage system coupled to a network |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3228182B2 (ja) * | 1997-05-29 | 2001-11-12 | 株式会社日立製作所 | 記憶システム及び記憶システムへのアクセス方法 |
| US6061753A (en) * | 1998-01-27 | 2000-05-09 | Emc Corporation | Apparatus and method of accessing target devices across a bus utilizing initiator identifiers |
-
2000
- 2000-08-07 JP JP2000244020A patent/JP4598248B2/ja not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000000881A1 (en) * | 1998-06-30 | 2000-01-06 | Emc Corporation | Method and apparatus for authenticating connections to a storage system coupled to a network |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001265655A (ja) | 2001-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4651230B2 (ja) | 記憶システム及び論理ユニットへのアクセス制御方法 | |
| US8700587B2 (en) | Security method and system for storage subsystem | |
| US7657727B2 (en) | Security for logical unit in storage subsystem | |
| JP4719957B2 (ja) | 記憶制御装置及び記憶システム並びに記憶システムのセキュリティ設定方法 | |
| US7454795B2 (en) | Disk control unit | |
| JP3993773B2 (ja) | ストレージサブシステム、記憶制御装置及びデータコピー方法 | |
| US6260120B1 (en) | Storage mapping and partitioning among multiple host processors in the presence of login state changes and host controller replacement | |
| US6295575B1 (en) | Configuring vectors of logical storage units for data storage partitioning and sharing | |
| US6421711B1 (en) | Virtual ports for data transferring of a data storage system | |
| US20040025166A1 (en) | Server computer and a method for accessing resources from virtual machines of a server computer via a fibre channel | |
| US20020099914A1 (en) | Method of creating a storage area & storage device | |
| JP4598248B2 (ja) | 記憶サブシステムのセキュリティシステム | |
| JP4512179B2 (ja) | ストレージ装置及びそのアクセス管理方法 | |
| JP3744248B2 (ja) | ファイバチャネル接続ストレージサブシステム及びそのアクセス方法 | |
| JP4315142B2 (ja) | ストレージシステム及びストレージシステムのアクセス方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070702 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070702 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20070702 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20070718 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100422 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100617 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100826 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100924 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131001 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |