JP2005202919A - ストレージシステムへのアクセスを制限する方法と装置 - Google Patents

Abstract

【課題】
ストレージネットワークデバイスは、他のストレージネットワークデバイスからの接続要求に対して、ベンダ又は製造業者関連情報に基づいて、肯定又は否定の様式で応答する。
この方法により、引き続く交信を阻止することができる。
【解決手段】
これによりデバイス毎のアクセス要求の実行を、適正に検証され又は十分にテストされたデバイスのみに制限でき、信頼性と性能を向上するのに有益である。
【選択図】 図１Ａ

Description

本発明はコンピュータストレージに関連し、具体的にはコンピュータストレージシステムでのアクセスを制限することに関連する。

ＦＣＰ(Fiber Channel Protocol)、ＳＣＳＩ(Small Computer Systems Interface)、やＦＩＣＯＮのようなストレージアクセスプロトコルはオープンなプロトコルで、これらのプロトコルの仕様は公開されている。これにより、ストレージシステムベンダのＳＡＮ(Storage Area Network)市場への参入が大いに促されてきた。

競争の拡大はユーザーにとって、一般的には有益であるものの、製品の増殖は有益な事ばかりではない事が判明してきた。ＮＡＳ(Network Attached Storage)システムやＳＡＮ用のデバイス数が増大するに従って、各装置と他のデバイス間の互換性をテストすることが重荷になってきた。各装置の様々な組み合わせに対してテストし、保証し、更にサポートをする為に、より多くの時間が必要になってきた。例えば、スイッチ装置の製造業者は他のスイッチ、ＨＢＡ(Host Bus Adapter)、ストレージサブシステム等と、自装置との接続性を保証する必要が生じてきた。あるベンダはテストを短縮するか又は単純に省略してしまい、エンドユーザーはいつの間にか未保証又は未テスト装置を掴んでしまうリスクを背負い込む事になる。この為に、デバイス間の非互換な動作、不適切なハードウェアやソフトウェアバージョンなどの原因で接続上の問題が発生する可能性がある。

この問題を回避する為に、多くのベンダはサポート済ベンダとファームウェアバージョンのリストを公表している。例えば、ストレージシステムのベンダは、自社がサポートするＨＢＡとファイバーチャネルスイッチをそのファームウェアバージョンと共に公表している。ユーザー又はシステムエンジニアは、所定の装置がサポート済か否かを判定する為に、リストを単純にチェックしている。これは管理者から見ると時間消費の仕事である。

更に、急速に変動するビジネス環境に於いては、会社は時において、お互いに製品を補完する為に他社と提携するようになって来た。会社が、戦略的なパートナーのみに自らのネットワークに接続することを認めることが、非常に一般的なビジネス戦略になってきた。そのような戦略では、戦略的なパートナーのみにネットワーク接続を限定する為のテクノロジーが必要となる。ネットワークをこのような観点で再構成することは、多大な時間を消費し又エラーが起こり易い仕事でもある。更に悪い事に、不適切な装置が誤って接続されれば、システム全体が停止し又は最悪の場合にはデータが破損する可能性がある。

本発明の一態様では、ストレージネットワークデバイスは、別のストレージネットワークデバイスからの接続要求に、ベンダ又は製造業者関連の情報に基づいて、肯定又は否定の様式で応答する。

この方法により、ストレージネットワークデバイスとの引き続く交信は、適切に検証されたか又は十分にテストされたデバイスに制限することが可能になる。

本発明の態様、利点、及び新規な機能は、付随図面と共になされる以下の記述により明らかになる。
ワークステーションやサーバをストレージネットワークのストレージデバイスに接続するハードウェアは、“ファブリック”又は“スイッチファブリック”と一般に呼ばれている。このファブリックは、ファイバーチャネルスイッチテクノロジーを使用して如何なるサーバと如何なるストレージデバイスとの接続でも可能にする。ここで開示する本発明の実施例の説明では、ファイバーチャネルテクノロジーによる実装を対象とする。しかしながら、他のストレージネットワークテクノロジーも本発明の態様に適応できることは容易に理解できるであろう。

図１Ａでは、本発明の一実施例でのストレージネットワークデバイスの典型的な構成をハイレベルブロック図により示す。ディスクシステム１００はプロセッサ１０１ａ、１０１ｂを装備する。メモリ要素１０２は、ディスクシステムを操作する為の制御プログラムを格納する。このメモリ要素は更に、ディスクシステムのストレージ要素である複数ディスク１０５のキャッシュデータの保存にも使用される。プロセッサ１０１ａは通信ポート１０３ａを経由して外部デバイスと交信し、同様に、プロセッサ１０１ｂはポート１０３ｂを経由して交信する。

図1Ａは又複数のスイッチ１２０ａ、１２０ｂを示す。２台を示しているが、ホスト１１０ａとディスクシステム１００との間には多くのスイッチを置くことができる。スイッチはホスト１１０ａとディスクシステム１００間のデータ又は情報経路を定める。多くの種類のスイッチが知られている。例えば、ファイバーチャネルスイッチ、ＩｎｆｉｎｉＢａｎｄ(Ｒ)スイッチ、及びネットワーク又はファイバチャネルのハブ又はルータ、はスイッチの例の一部である。

ユーザーのアプリケーションが動作するホスト１１０ａは慣用的に処理要素、メモリ等(図示されていない)を装備する。ホストは更にＨＢＡ(Host Bus Adapter)を有する。図１Ａの説明例では、ホスト１１０ａ内にＨＢＡ１１５ａ、１１５ｂを、ホスト１１０ｂ内にはＨＢＡ１１５ｃ、１１５ｄを装備する。ＨＢＡはホストをスイッチなどの外部デバイスに接続する。ＨＢＡはホストをディスクシステム又は別のホストに直接接続することもできる。ＨＢＡの例としては、ファイバチャネルＨＢＡやネットワークカードがある。ディスクシステム１００に格納されているアプリケーションデータは、ＨＢＡとネットワーク１３０経由でアクセス可能である。ネットワーク１３０の実例としては、ファイバチャネル、ＥＳＣＯＮ、ＦＩＣＯＮ、ＴＣＰ／ＩＰ、及びＳＣＳＩがある。

図1Ｂは、本発明の別の実施例のハイレベルブロック図である。この構成は二式のディスクシステム１００ａ、１００ｂを示し、ディスクシステム１００ａと１００ｂはデータ交信の為に接続されている。ホスト１１０ａは、ディスクシステム１００ａとデータ交信中である。図１Ｂに示す例に於いては、ホスト１１０ａはＨＢＡ１１５ａを経由してディスクシステムと直接接続されている。ホスト１１０ｂはスイッチ１２０’と接続されている。このスイッチは第二のスイッチ１２０に接続され、この第二のスイッチがディスクシステム１００ｂに結合している。図1Ｂは、複数のスイッチを、例えばホストやストレージ等の末端ノード間に配置できることを示す。

慣用的構成としては、ディスクシステム１００ｂはディスクシステム１００ａにアクセス可能である。ホスト１１０ｂの観点からは、このホストはディスクシステム１００ｂのみが“見える”。ディスクシステム１００ｂは、ホスト１１０ｂがアクセス可能な論理ドライブをディスクシステム１００ａ内の物理ドライブに内部的にマップすることができ、この結果、ホスト１１０ｂはディスクシステム１００ａの存在を知る必要はない。従って、ホスト１１０ｂがこの論理ドライブにアクセスするコマンドを発行すれば、ディスクシステム１００ｂはこのコマンドを受け取り、要求を果たす為にディスクシステム１００ａに転送する。

ここで、アクセスコントロールテーブル(以降ＡＣＴと呼ぶ)２００を議論する為に図２を参照する。ＡＣＴは、対象デバイスへのアクセス権限を与えられたデバイスのベンダとバージョン番号を示す情報を有する。図１Ａで示す事例では、対象デバイスはディスクシステム１００である。従って、ＡＣＴ２００は図示される様に、メモリ要素１０２に保存される。プロセッサ１０１ａ、１０１ｂはこのテーブルにアクセスし或いは更新することができる。図１Ｂに示す例では、対象デバイスはディスクシステム１００ａである。

このテーブルはベンダフィールド２１０、デバイスタイプフィールド２２０、及びバージョンフィールド２３０により構成される。ベンダフィールド２１０はベンダ又は各装置を識別する。ベンダフィールドの情報は、当該装置ベンダの会社名などの英数字で表される。この情報は、例えばＯＵＩ(Organizationally Unique Identifier)のように、特定のベンダに対応してコード化されたものであり得る。

デバイスタイプフィールド２２０は、装置タイプを識別する情報を含む。図２では、例として、テーブルの第一のエントリは会社ＡＡＡから供給されたＨＢＡデバイスを示し、第二のエントリは会社ＢＢＢから供給されたスイッチを示す。必要なら、デバイスタイプフィールドは、ベンダから供給された対象デバイスをモデル別に、より具体的に判別できるように拡張できることを理解願いたい。例えば、ベンダＡＡＡは多数のＨＢＡモデルを持っていることもあり得る。デバイスタイプフィールドは、異なったＨＢＡを収容するように拡張しても良いし、このＡＣＴ２００に追加のフィールドを与えても良い。

バージョンフィールド２３０は、当該デバイスに対応するバージョン情報を表示する。必要ならば、このフィールドは、当該デバイスの構成要素のバージョン情報を含むように拡張できることを理解願いたい。例えば、スイッチはスイッチ全体を示す単一のバージョン番号を持つことも出来るが、ベンダによっては、当該スイッチのソフトウェアバージョンとハードウェアバージョンを別々に用意することもあり得る。このＡＣＴ２００は、このような製造業者関連の情報の何れをも収容するように拡張する事ができる。

図３は、図１Ａに関連して本発明に従うデバイスの処理を示すフローチャートである。説明目的の為に、図１Ａに示す具体的構成例では、スイッチ１２０ａはディスクシステム１００では未サポートである(例えば、このスイッチはディスクシステム１００と連動して動作できる保証がなされていない)と仮定する。このフローチャートはディスクシステム１００で行われる処理を示す。然しながら、図３のフローチャートで示すプロセスは、ストレージネットワークのどのデバイス、例えばＨＢＡ、スイッチ、他のディスクシステムにも適用できる事を、図１Ａ及び図１Ｂから理解願いたい。図１Ａ及び図１Ｂはこのことを示す。これらの図は、ストレージネットワーク内の他のデバイスも本発明に従って構成できることを示す。かくして、図１Ａのスイッチ１２０ｂもＡＣＴ(点線で示す)を持つことが出来、図１Ｂのスイッチ１２０も同様である。

かくして、この手続は接続要求をデバイスが受信した時に開始する。例えば、図１Ａでは、スイッチ１２０ａはＨＢＡ１１５ａから接続要求を受信することができる。又は、スイッチ１２０ｂはディスクシステム１００に接続要求を行うことができる。本発明の実施例に於いては、ストレージネットワーク内の二つのノード間の接続要求は、一般的にＦＬＯＧＩ(Fabric Login)と呼ばれる。この二つのノードが末端(例えば、ディスクシステムへのＨＢＡ)の場合には、接続要求はＰＬＯＧＩ(Port Login)と呼ばれる。

ステップ３００に於いて、接続要求を受信したデバイスはこの要求に関連した情報を取得する。例えば、スイッチ１２０ａ又は１２０ｂが、接続要求をディスクシステム１００に送信するときには、この要求はこのスイッチに関するベンダ、デバイスタイプ及びバージョン情報を含むことができる。ファイバチャネルの場合には、送信デバイス（例えば、スイッチ１２０ａ、又は１２０ｂ）がディスクシステム１００に接続要求（即ちＦＬＯＧＩ）を送る時には、ディスクシステムはこのＦＬＯＧＩ要求からログインパラメーターを取得できる。典型的な情報は、デバイスのベンダ名（例えば、ＯＵＩ）を表示するＷＷＮ（World Wide Name）、ログインのタイプ（ＦＬＯＧＩ、ＰＬＯＧＩ）、ベンダバージョンレベル情報などを含む。例えば、要求スイッチのベンダ情報は接続要求から取得できる。

ステップ３１０にて、ステップ３００に於いて得られた製造業者関連の情報を、ＡＣＴ２００に含まれる該当情報と比較する。この接続要求を受信し処理するデバイス（例えば、ディスクシステム１００）が、送信デバイス（例えば、スイッチ１２０ｂ）に対するテーブルで十分な適合が確認できたら、その内部状態を、送信デバイスを承認しアクセスを許可する状態にセットする（ステップ３２０）。例えば、このプロセスでは、デバイスのベンダ識別表示が一致するエントリを検出すべくＡＣＴを検索する。このバージョン（例えば、ソフトウェアリリース、ハードウェアバージョンなど）が受信デバイスのバージョンと互換であることをチェックする為に、比較が行われる。

受信デバイスは、接続要求が受理された事を送信デバイスに表示する為に、接続要求のプロトコルの仕様に対応して、適切な肯定応答を返す必要があり得る。例えば、ＦＬＯＧｌコマンドシーケンスに対しては、ディスクシステムがログイン要求を受理したら、送信デバイスに承認(ＡＣＣ)フレームを返信する。

送信デバイス（例えば、スイッチ１２０ａ）がＡＣＴに登録されていないと判断されたら、この接続要求を処理する受信デバイス（例えば、ディスクシステム１００）は、送信デバイスからの要求は受理できなかったことを示す内部状態をセットする（ステップ３３０）。接続要求のプロトコルの詳細に対応した適切な否定応答が必要になる。送信デバイス（例えば、スイッチ１２０ａ）は否定応答を検出し、以降この受信デバイス（例えば、ディスクシステム１００）へのアクセスを行わない。

ＡＣＴ２００に於いては、“関係なし”状態を表示する為にある表記を用いる事が出来る。例えば、図２は会社ＡＡＡからのＨＢＡデバイスにアスタリスク‘＊’を表示している。約束事によってこの場合はバージョン番号は無関係であると判断され、このフィールドの照合は行われない。この機能は、当該フィールドの情報が接続要求で取得不可能な場合に有効である。その様なフィールドを“関係なし”と指定することによって、接続要求から得られる他の全ての情報に対して照合を継続する事が可能になる。

判定ステップ３１０では、送信デバイスがＡＣＴにリストされているか否かでアクセス可能性の判定を行う。このＡＣＴは、送信デバイスが、接続要求を受信するデバイスにアクセスするか否かを具体的に表示する情報を含んでも良いことを、理解願いたい。

前述の処理は如何なる二式のデバイス間でも実行できることを理解願いたい。かくして、ＨＢＡはディスクシステムに直接又はスイッチ経由で接続要求を発行しても良い。一つのスイッチは他のスイッチに接続要求を発行でき、又スイッチはディスクシステムに接続要求を発行できる。図１Ｂで分かるように、適切に構成されたストレージアーキテクチュアに於いては、ディスクシステムは他のディスクシステムに接続要求を送信できる。例えば、要求されたディスク（例えば、ディスクシステム１００ａ）にとって、要求ディスク（例えば、ディスクシステム１００ｂ）は、接続要求を発行しているスイッチデバイスの様にも見える。

図１Ｂの議論を完成させると、図は、ディスクシステム１００ｂがディスクシステム１００ａに接続要求を送信した事を示している。ディスクシステム１００ａは接続要求から情報を取得する（ステップ３００）。ディスクシステム１００ａがＡＣＴをチェックする（ステップ３１０）と、ディスクシステム１００ｂはこのテーブルにリストされていないことが分かる。従って、ディスクシステム１００ａはこの接続要求に否定応答を返送する（ステップ３３０）。この結果は、ディスクシステム１００ｂはディスクシステム１００ａに対して見えないと言う事になる。同様に、ディスクシステム１００ｂからはディスクシステム１００ａにはアクセス不能に見え、結果として、ディスクシステム１００ｂはディスクシステム１００ａにアクセスしようとすることはない。

本発明の他の態様では、デバイスアクセスへの制限が、デバイスへのアクセスの完全な拒絶に代わる別案として提供される。デバイスに対する“タスクセット”と言う新規なアイデアをここで議論する。各デバイスは多様なサービスと機能を備えている。例えば、ディスクシステムは以下の機能を実行する。
・ディスクに対する読み書き
・スナップショット
・遠隔ミラーリング
・ＬＵ構成の変更(例えば、サイズの変更、アクセスパスとＬＵ数の決定、など）
・内部性能と構成データの取得
・サブシステム動作モードの変更
デバイスに対するサービス又は機能は、ベンダ毎にも又ベンダのモデル毎にも変わるものである。典型的には、これらのサービスにアクセスするインタフェースはＡＰＩ（Application Programmer's Interface）、ＣＬＩ（Command Line Interface）或いは、ＧＵＩ（Graphical User Interface）の形で使用できる。これらのコマンドは、パス１３０を経由して伝えられる（例えば図１Ａを参照）。これらのコマンドのデバイスに於ける内部実装はデバイス及びベンダに固有である。例えば、コマンドは特殊ＳＣＳＩコマンド（ＳＣＳｌ標準の規定外のベンダ固有コマンド）にマップしてもよい。

本発明のこの態様の一実施例では、“タスクセット”は、デバイスが実行できるサービスと機能の全集合として定義される。例えば、下記のテーブルは、典型的ディスクシステム（例えば、図１Ａのディスクシステム１００）が実行可能なサービスと機能を一覧にしたものである。

一つのタスクセットは、自分（例えば、ディスクシステム１００）にアクセスするデバイスに許可するタスクのセットを指定する。例えば、図１Ａに関して、スイッチ１２０ｂのタスクセットは、スイッチがディスクシステムでタスク１とタスク３を実行することを許可するように定義される。図１Ｂに関連して、ディスクシステム１００ａに含まれるタスクセットは、ＨＢＡ１１５ａがこのディスクシステムに於いてタスク３を実行することを許可するように定義される。一つのタスクセットは一つ以上のタスクを含むことができるということが分かる。

図４Ａは、本発明のこの態様の実施例を説明するタスクセットテーブル４００を示す。ＡＣＴ２００と同様に、タスクセットテーブルはストレージネットワークデバイスの何れにも適用できる。このタスクセットテーブルは、ソースアドレスフィールド４１０、ＡＣＴエントリフィールド４２０、及びタスクセットフィールド４３０で構成される。ソースアドレスフィールド４１０は、対象デバイスのソースアドレスに対応する。この情報は、典型的には、デバイスが最初にネットワークに接続されるときに、名前サーバによって与えられる。接続要求が成功裏に実行された後、引き続く交信にはサービス要求の送信デバイスのアドレスが典型的な場合には含まれるようになる。例えば、スイッチがディスクシステムにサービス要求を送信するときには、この要求にはこのスイッチを特定しこれに関連するソースアドレスが含まれる。かくして、ソースアドレスフィールドによりサービス要求の送信デバイスを特定する事ができる。

ＡＣＴエントリフィールド４２０は、ＡＣＴ２００のインデックス又はこれへのポインタである。このフィールドは、単なる数値であるソースアドレスをＡＣＴのエントリに関係づけ、このソースアドレスに関連するデバイスを識別する役割を果たす。このフィールドは、管理者が実行するこれらのテーブルのメンテナンス活動を容易にする為に使用される。

タスクセットフィールド４３０は、要求受信デバイス（例えば、ディスクシステム）が、送信デバイス（例えば、スイッチ、ＨＢＡ）が実行することを許可する一つ以上のタスクを識別する。例えば、０ｘ００２４１Ｆのソースアドレスを持つデバイスは、タスク１、２、及び４を実行することが許可され、０ｘ１２０３００のソースアドレスを持つデバイスは、タスク１及び２を実行することが許可される。

図４Ｂは、タスクセットテーブル４００に関して行われる処理を説明するハイレベルのフローチャートである。説明目的の為に、ディスクシステム１００（図１Ａ）が、タスクセットテーブルを有し、このテーブルに基づいて送信デバイスのアクセスを制限する、と仮定する。然しながら、図４Ｂのフローチャートで説明したプロセスは他のデバイス（例えば、ＨＢＡ、スイッチ）にも適用できることは、理解できるであろう。

ディスクシステム１００がデバイス（例えば、スイッチ１２０ｂ）からサービス要求を受け取ることによりこのプロセスが起動され、ステップ４０１にて、このサービスを実行すべきか否かを判定する。この為には、要求からソースアドレスを取得し、タスクセットテーブル内で、このソースアドレスにマッチするエントリを検出する。このアドレスが見つからなければ、この要求は拒絶される（ステップ４０２）。要求を“拒絶する”為の具体的レスポンスは、使われている個別の通信プロトコルに依存する。

ソースアドレスに対応するエントリが見つかれば、見つかったエントリのタスクセットフィールド４３０を調べる。このサービス要求は、タスクセットフィールド４３０に登録されている許可済みタスクのリストと比較される。このフィールドに当該要求がリストされていなければ、否定応答が生成される（ステップ４０２）。このフィールドに当該要求が見つかれば、このサービス要求は実行される（ステップ４０３）。この時、実際上、サービスとプロトコルに対応して応答を生成するか否かが決まる。

デバイスはテストされ検証されるので、ＡＣＴ２００は定期的に更新される必要がある。この為の一方法は、管理者がテーブルに対して必要な処理を実行できるように、デバイス上にインタフェースを用意することである。インタフェースは、ＡＰＩの形かＣＬＩやＧＵＩ等のユーザインターフェースである。例えば、ＡＣＴがディスクシステムに置かれている場合を考える。ホストデバイス内でＡＰＩにアクセス可能なＧＵＩを書けるようにすることができる。このＡＰｌによって、ＡＣＴにアクセスし保守することが可能になる。以下のテーブルは、いくつかの典型的な管理機能を一覧にしたものである。

ＡＣＴを手動で更新するのは、手間がかかり又誤り易い仕事である。スイッチ、ＨＢＡ、及びディスクシステムを含む多数のデバイスが本発明に関係する場合には、特に退屈な仕事になる。従って、本発明のもう一つの態様として、Ｗｅｂサイトのようなセントラルロケーションが使用される。このセントラルロケーションでは、全ての必要なデバイスに対して全てのＡＣＴを用意する。本発明に従って構成されたデバイスは、このセントラルロケーションを定期的にチェックし、更新されていたら、この更新済ＡＣＴにアクセスする。

このセントラルロケーションは、ＡＣＴの更新を容易にする為に、下記の情報を含んでいる。
・ＡＣＴ２００のバージョン
・このバージョンは、ディスクシステム１００が、Ｗｅｂサイトで更新されたＡＣＴ２００と比較するのに使用される。勿論、ディスクシステム１００は、ＡＣＴ２００と共にＡＣＴ２００のバージョンをメモリ１０２に保存する。
・ＡＣＴ２００に適用されるデバイス
・ベンダが複数タイプのデバイス（例えば、ディスクシステム１００とＨＢＡ１１５等)を供給するなら、デバイス毎に異なったＡＣＴ２００が必要であろう。

図５は、ＡＣＴを更新するフローチャートを示す。セントラルロケーションに接続がなされる（ステップ５００）。本発明の一実施例では、Ｗｅｂサイトが使用され、その場合はＷｅｂサイトにアクセスすることが接続することになる。ＡＣＴが更新されるべきデバイス（例えば、ディスクシステム１００）は、Ｗｅｂサイトが更新済みテーブルを持っているかをチェックする（ステップ５１０）。このことは、例えば、このテーブルをダウンロードして、これをディスクシステムが持つバージョンと比較する事によりなされる。もしこのテーブルが更新要と判断されたら、ステップ５２０で旧テーブルは新たにダウンロードされたテーブルと置き換えられる。

本発明の一実施例を示すストレージネットワークのハイレベルの一般化ブロック図。 は、本発明のもう一つの実施例であるもう一つのストレージネットワークに対するハイレベルの一般化ブロック図。 は、アクセスコントロールテーブル(ＡＣＴ)の一例を示す。 は、本発明の一実施例に従う接続要求の処理を説明するフロー図。 は、タスクセットテーブルの一例を示す。 は、本発明の一実施例に従うサービス要求の処理を説明するフロー図。 は、アクセスコントロールテーブル(ＡＣＴ)を更新するプロセスを説明するフロー図。

符号の説明

１００・・・ディスクシステム、１００ａ・・・ディスクシステム、１００ｂ・・・(未サポート)ディスクシステム、１０１ａ,１０１ｂ・・・プロセッサ、１０２・・・メモリ、１１０ａ，１１０ｂ・・・ホスト、１２０ａ・・・(未サポート)スイッチ、１２０ｂ・・・(サポート済)スイッチ、
１２０，１２０’・・・スイッチ

Claims (33)

1. ストレージネットワークの第一のデバイスに於いて、
   送信デバイスから接続要求を受信するステップと、
   前記送信デバイスに関する製造業者関連の情報を取得するステップと、
   前記製造業者関連の情報とアクセスコントロールテーブルに含まれる製造業者関連の情報との比較結果によって、前記送信デバイスに肯定又は否定の様式で応答するステップと、
   を含み、
   肯定の様式で応答する場合は、前記第一のデバイスと前記送信デバイスとの間の引き続くデータ交信を許可し、
   否定の様式で応答する場合は、前記第一のデバイスと前記送信デバイスとの間の引き続くデータ交信を拒絶する、
   ことを特徴とするサービス要求を処理する為の方法。
2. 前記接続要求はファブリックログインであり、前記製造業者関連の情報は前記送信デバイスの製造業者を表示する情報を含むことを特徴とする請求項１の方法。
3. 前記送信デバイスに応答するステップは、前記製造業者名が前記アクセスコントロールテーブルにリストされているか否かを判定するステップを含むことを特徴とする請求項２の方法。
4. 前記製造業者関連の情報は更にバージョン情報を含み、前記送信デバイスに応答するステップは更に該バージョン情報を前記アクセスコントロールテーブルに登録されているバージョン情報と比較して判定するステップを含むことを特徴とする請求項３の方法。
5. 前記アクセスコントロールテーブルは前記製造業者に関するアクセス許可情報を含み、前記送信デバイスに肯定又は否定の様式で応答するステップは該アクセス許可情報に基づくことを特徴とする請求項２の方法。
6. 前記第一のデバイスはディスクシステムであることを特徴とする請求項１の方法。
7. 前記送信デバイスはホストバスアダプタ(ＨＢＡ)であることを特徴とする請求項６の方法。
8. 前記送信デバイスはスイッチであることを特徴とする請求項６の方法。
9. 前記送信デバイスは第二のディスクシステムであることを特徴とする請求項６の方法。
10. 前記第一のデバイスはスイッチであり、前記送信デバイスはＨＢＡであることを特徴とする請求項１の方法。
11. 前記第一のデバイスは第一のスイッチであり、前記送信デバイスは第二のスイッチであることを特徴とする請求項１の方法。
12. 前記第一のデバイスはＨＢＡであることを特徴とする請求項１の方法。
13. 複数のサービスを実行可能な第一のストレージネットワークデバイスに於いて、第二のストレージネットワークデバイスから送信されたサービス要求を受信するステップと、
    前記サービス要求から前記第二のストレージネットワークデバイスを特定する識別情報を取得するステップと、
    前記識別情報に基づいて前記第二のストレージネットワークデバイスに関するサービスを決定するステップと、
    前記サービス要求が前記第二のストレージネットワークデバイスに関するサービスに対してであれば、該サービス要求を実行するステップと、
    前記サービス要求が前記第二のストレージネットワークデバイスに関するサービスに対してでなければ、対応する否定応答を生成し、該第二のストレージネットワークデバイスに対して、該サービスは前記第一のストレージネットワークデバイスでは実行されない旨を表示するステップと、
    を含むことを特徴とするストレージネットワークにおけるアクセス方法。
14. 前記第一のストレージネットワークデバイスはディスクシステムであることを特徴とする請求項１３の方法。
15. 前記識別情報は前記サービス要求に含まれるソースアドレスであることを特徴とする請求項１４の方法。
16. 前記第一のストレージネットワークデバイスはスイッチであることを特徴とする請求項１３の方法。
17. 前記第一のストレージネットワークデバイスはＨＢＡであることを特徴とする請求項１３の方法。
18. 前記請求項１３の方法のステップを実行するように構成されることを特徴とするストレージネットワークデバイス。
19. 前記ストレージネットワークデバイスはディスクシステムであることを特徴とする請求項１８のストレージネットワークデバイス。
20. 前記ストレージネットワークデバイスはスイッチであることを特徴とする請求項１８のストレージネットワークデバイス。
21. 前記ストレージネットワークデバイスはＨＢＡであることを特徴とする請求項１８のストレージネットワークデバイス。
22. 第一の複数のストレージネットワークデバイスに対する製造業者関連の情報を記録するアクセスコントロールテーブルを格納するメモリ要素を有するデータ処理要素と、
    前記データ処理要素とデータ交信を行い、第二のストレージネットワークデバイスと交信が可能な通信ポートと、
    を有するストレージネットワークデバイスにおいて、
    前記データ処理要素は、
    前記第二のストレージネットワークデバイスから送信された接続要求の受信を含めて、前記通信ポートを経由してデータを交換するステップと、
    前記接続要求に含まれる情報に基づいて前記第二のストレージネットワークデバイスに関する製造業者関連の情報を取得するステップと、
    前記第二のストレージネットワークデバイスに関する前記製造業者関連の情報と前記アクセスコントロールテーブル内の製造業者関連の情報を比較して、肯定又は否定の応答を生成するステップと、
    前記第二のストレージネットワークデバイスに前記応答を送信するために前記通信ポートを経由してデータを交換するステップと、
    を実行するように構成されることを特徴とするストレージネットワークデバイス。
23. 前記接続要求は、ファブリックログインかポートログインの何れかであることを特徴とする請求項２２のストレージネットワークデバイス。
24. 前記比較は、前記第二のストレージネットワークデバイスに関するベンダ識別情報と前記アクセスコントロールテーブル内のベンダ識別リストとの間の比較を含むことを特徴とする請求項２２のストレージネットワークデバイス。
25. 前記比較は更に、前記第二のストレージネットワークデバイスに関するバージョン情報と前記アクセスコントロールテーブル内のバージョン情報との間の比較を含むことを特徴とする請求項２４のストレージネットワークデバイス。
26. 前記ストレージネットワークデバイスはディスクシステムであることを特徴とする請求項２２のストレージネットワークデバイス。
27. 前記第二のストレージネットワークデバイスはＨＢＡ、スイッチ、及び第二のディスクシステムの何れか一つであることを特徴とする請求項２６のストレージネットワークデバイス。
28. 前記接続要求はファブリックログインかポートログインの何れかであることを特徴とする請求項２７のストレージネットワークデバイス。
29. 前記比較は、前記第二のストレージネットワークデバイスに関するベンダ識別情報と前記アクセスコントロールテーブル内のベンダ識別リストとの間の比較を含むことを特徴とする請求項２７のストレージネットワークデバイス。
30. 前記ストレージネットワークデバイスはスイッチであることを特徴とする請求項２２のストレージネットワークデバイス。
31. 前記ストレージネットワークデバイスはＨＢＡであることを特徴とする請求項２２のストレージネットワークデバイス。
32. データ処理要素と、
    前記データ処理要素と結合して稼動するデータストレージ要素と、
    第二のストレージネットワークデバイスと交信する為の通信ポートと、
    を有するストレージネットワークデバイスにおいて、
    前記データストレージ要素は、
    ファブリックログイン要求かポートログイン要求の何れかの接続要求を前記第二のストレージネットワークデバイスから受信するステップと、
    前記接続要求からベンダ識別情報を取得するステップと、
    前記ベンダ識別情報に基づいて応答を生成するステップと、
    前記第二のストレージネットワークデバイスに前記応答を送信するステップと、
    から成る方法のステップを実行可能であり、
    前記応答が肯定応答なら、前記ストレージネットワークデバイスと前記第二のストレージネットワークデバイスとの間の引き続く交信が可能であり、
    前記応答が否定応答なら、前記ストレージネットワークデバイスと前記第二のストレージネットワークデバイスとの間の引き続く交信は不能で、
    前記引き続く交信は、前記データストレージ要素にアクセスする為のストレージアクセス要求を含む、
    ことを特徴とするストレージネットワークデバイス。
33. 前記第二のストレージネットワークデバイスはＨＢＡ、スイッチ、及びディスクシステムの何れか一つであることを特徴とする請求項３２のストレージネットワークデバイス。
    

Images