JP2002222110A - ストレージシステム及び仮想プライベートボリューム制御方法 - Google Patents
ストレージシステム及び仮想プライベートボリューム制御方法Info
- Publication number
- JP2002222110A JP2002222110A JP2001016503A JP2001016503A JP2002222110A JP 2002222110 A JP2002222110 A JP 2002222110A JP 2001016503 A JP2001016503 A JP 2001016503A JP 2001016503 A JP2001016503 A JP 2001016503A JP 2002222110 A JP2002222110 A JP 2002222110A
- Authority
- JP
- Japan
- Prior art keywords
- identification number
- access
- command
- server
- response
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/062—Securing storage systems
- G06F3/0622—Securing storage systems in relation to access
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0637—Permissions
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 サーバ内に複数のＯＳが存在し、ディスク
装置へのパスを共有していると、ディスク装置側ではこ
れら複数のＯＳ、アプリケーションを区別することがで
きない。そこで、複数のＯＳ、アプリケーションを区別
して、排他制御、優先制御方法を代えることでセキュリ
ティ能力を向上させ、システムの性能最適化を図る。 【解決手段】 ＯＳが発行するコマンドの内部にＯＳ
を識別する識別番号を付与し、ディスク装置内でその識
別番号を元にアクセスの排他、優先処理を制御すること
で、サーバ及びディスク装置全体のトランザクション性
能を高めることを特徴とする仮想プライベートボリュー
ム制御装置とする。
装置へのパスを共有していると、ディスク装置側ではこ
れら複数のＯＳ、アプリケーションを区別することがで
きない。そこで、複数のＯＳ、アプリケーションを区別
して、排他制御、優先制御方法を代えることでセキュリ
ティ能力を向上させ、システムの性能最適化を図る。 【解決手段】 ＯＳが発行するコマンドの内部にＯＳ
を識別する識別番号を付与し、ディスク装置内でその識
別番号を元にアクセスの排他、優先処理を制御すること
で、サーバ及びディスク装置全体のトランザクション性
能を高めることを特徴とする仮想プライベートボリュー
ム制御装置とする。
Description
【０００１】
【発明の属する技術分野】本発明は、サーバおよび記憶
装置技術に関し、特に複数の記憶装置、ＣＰＵなどの構
成要素を接続し、高いセキュリティ能力、高い応答性
能、トランザクション数が要求される情報処理装置、記
憶装置に有効な技術に関する。
装置技術に関し、特に複数の記憶装置、ＣＰＵなどの構
成要素を接続し、高いセキュリティ能力、高い応答性
能、トランザクション数が要求される情報処理装置、記
憶装置に有効な技術に関する。
【０００２】
【従来の技術】複数のＣＰＵ、メモリとＩ／Ｏアダプタ
を持つサーバと大容量のディスク装置を組み合わせ、複
数のユーザでそれら資源を共用する環境が現実になって
くるに従って、各ユーザのセキュリティを守り、効率的
に資源を使うことが要求されてきている。従来のサーバ
及びディスク装置においては、論理ボリュームの排他制
御を行うためにサーバに内蔵しているＩ／Ｏアダプタ毎
に識別番号を持ちそれをストレージ側で区別する方式が
採用されている。図２に従来のサーバ、ディスク装置構
成例を示す。ここでサーバ＃０（１１０）とサーバ＃１
（１２０）はそれぞれ複数のＯＳ＃０（１５５）〜ＯＳ
＃２（１２０）を内蔵している。またＩ／Ｏアダプタ１
１８、１２８を持ちストレージ１７０に接続している。
ストレージ１７０にアクセスする場合データフレーム１
３０、１３５、１４０をＩ／Ｏアダプタ１１８、１２８
より発行する。データフレーム１３０、１３５、１４０
の記述内容の中にはＷｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ
（ＷＷＮ）（２０５、２１５、２２５）がありＩ／Ｏア
ダプタ１１８、１２８毎に固有の認識番号をそこに書き
こむ。一方ディスク装置１７０ではＩ／Ｏアダプタ１７
３、１７４を持ち上記データフレーム１３０、１３５、
１４０を受信する。ディスク装置１７０で内部制御を行
うチャネルコントローラ１７５、１７６は受信したデー
タフレーム１３０、１３５、１４０から識別番号である
ＷＷＮ２０５、２１５、２２５を抽出する。そしてチャ
ネルコントローラ１７５、１７６はＷＷＮ２０５、２１
５、２２５とローカルメモリ１８０、１８１にあらかじ
め登録されている排他／優先制御テーブル１８２、１８
３を比較することで論理ボリューム１９５、１９６に対
するアクセスの排他／優先制御を行う。例えばサーバ＃
０（１１０）のＯＳ＃２（１５０）が論理ボリューム＃
０（１９５）を所有し、サーバ＃１（１２０）のＯＳ＃
１（１６０）が論理ボリューム＃１（１９６）を所有し
ていることを仮定する。ここで誤ってＯＳ＃１（１６
０）が論理ボリューム＃０（１９５）をアクセスした場
合、このアクセスのデータフレーム１４０のＷＷＮ２２
５には識別番号００１があるので、チャネルコントロー
ラ１７６は排他／優先制御テーブル１８３を参照し、識
別番号０００しかアクセスが許可されていないことがわ
かる。そこでチャネルコントローラ１７６はＯＳ＃１
（１６０）に対してアクセスが拒否されたことを伝え
る。このような論理ボリュームの排他／優先制御を備え
たディスク装置の技術については、特開２０００-２０
４４７号に開示された「記憶サブシステム」等がある。
を持つサーバと大容量のディスク装置を組み合わせ、複
数のユーザでそれら資源を共用する環境が現実になって
くるに従って、各ユーザのセキュリティを守り、効率的
に資源を使うことが要求されてきている。従来のサーバ
及びディスク装置においては、論理ボリュームの排他制
御を行うためにサーバに内蔵しているＩ／Ｏアダプタ毎
に識別番号を持ちそれをストレージ側で区別する方式が
採用されている。図２に従来のサーバ、ディスク装置構
成例を示す。ここでサーバ＃０（１１０）とサーバ＃１
（１２０）はそれぞれ複数のＯＳ＃０（１５５）〜ＯＳ
＃２（１２０）を内蔵している。またＩ／Ｏアダプタ１
１８、１２８を持ちストレージ１７０に接続している。
ストレージ１７０にアクセスする場合データフレーム１
３０、１３５、１４０をＩ／Ｏアダプタ１１８、１２８
より発行する。データフレーム１３０、１３５、１４０
の記述内容の中にはＷｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ
（ＷＷＮ）（２０５、２１５、２２５）がありＩ／Ｏア
ダプタ１１８、１２８毎に固有の認識番号をそこに書き
こむ。一方ディスク装置１７０ではＩ／Ｏアダプタ１７
３、１７４を持ち上記データフレーム１３０、１３５、
１４０を受信する。ディスク装置１７０で内部制御を行
うチャネルコントローラ１７５、１７６は受信したデー
タフレーム１３０、１３５、１４０から識別番号である
ＷＷＮ２０５、２１５、２２５を抽出する。そしてチャ
ネルコントローラ１７５、１７６はＷＷＮ２０５、２１
５、２２５とローカルメモリ１８０、１８１にあらかじ
め登録されている排他／優先制御テーブル１８２、１８
３を比較することで論理ボリューム１９５、１９６に対
するアクセスの排他／優先制御を行う。例えばサーバ＃
０（１１０）のＯＳ＃２（１５０）が論理ボリューム＃
０（１９５）を所有し、サーバ＃１（１２０）のＯＳ＃
１（１６０）が論理ボリューム＃１（１９６）を所有し
ていることを仮定する。ここで誤ってＯＳ＃１（１６
０）が論理ボリューム＃０（１９５）をアクセスした場
合、このアクセスのデータフレーム１４０のＷＷＮ２２
５には識別番号００１があるので、チャネルコントロー
ラ１７６は排他／優先制御テーブル１８３を参照し、識
別番号０００しかアクセスが許可されていないことがわ
かる。そこでチャネルコントローラ１７６はＯＳ＃１
（１６０）に対してアクセスが拒否されたことを伝え
る。このような論理ボリュームの排他／優先制御を備え
たディスク装置の技術については、特開２０００-２０
４４７号に開示された「記憶サブシステム」等がある。
【０００３】一方サーバ内に複数の資源が存在する場合
それらを複数のＯＳで分割して使う技術が存在する。こ
の技術を用いることで、サーバのＣＰＵ、メモリ等を効
率よく利用することが可能になってきている。これらの
技術の一例としてＬＰＡＲ（Ｌｏｇｉｃａｌ ＰＡＲＴ
ｉｏｎｉｎｇ）がある。これを用いた場合、複数のＯＳ
を管理するソフトウエアプログラムとしてハイパバイザ
４３０が存在することにより、動的にＯＳに，ＣＰＵ、
メモリ、Ｉ／Ｏデバイスを割り当てることが可能とな
る。例えば図２のサーバ＃１（１２０）では、ＣＰＵ＃
１０〜＃１３と４個あるので、ＬＰＡＲを用いることで
ＯＳ＃０（１５５）にはＣＰＵ＃１０を割り当て、ＯＳ
＃１（１６０）にはＣＰＵ＃１１、＃１２、＃１３（１
２２、１２３、１２４）を割り当てることができる。メ
インメモリ１２５についても容量を適当な割合でＯＳ＃
０（１５５）、ＯＳ＃１（１６０）に割り当てることが
できる。Ｉ／Ｏアダプタが複数ある場合はＯＳ＃０（１
５５）、ＯＳ＃１（１６０）に割り当てることができる
がこの例では１個しかないので、Ｉ／Ｏアダプタ１２８
は両ＯＳで共有することになる。このような技術につい
ては、特開平１０-３０１７９５号に開示された「仮想
計算機システム」等がある。また、特開２０００−１１
２８０４号には、複数のＯＳがファイルを共用して動作
する仮想計算機システムにおいて、１つのＯＳが他のＯ
Ｓのデータファイルをアクセスすることを防止するた
め、ＯＳ番号が付されたＩ／Ｏ命令をディスク装置に対
して発行することが記載されている。また、特開平４−
１４０８４４号には、ＯＳが発行したＩ／Ｏ命令を解析
するＩ／Ｏ解析手段を有し、Ｉ／Ｏ解析手段では引き取
ったＩ／Ｏ命令にＯＳ識別子を付加し、複数ＯＳを同時
動作させたときに排他制御することが記載されている。
それらを複数のＯＳで分割して使う技術が存在する。こ
の技術を用いることで、サーバのＣＰＵ、メモリ等を効
率よく利用することが可能になってきている。これらの
技術の一例としてＬＰＡＲ（Ｌｏｇｉｃａｌ ＰＡＲＴ
ｉｏｎｉｎｇ）がある。これを用いた場合、複数のＯＳ
を管理するソフトウエアプログラムとしてハイパバイザ
４３０が存在することにより、動的にＯＳに，ＣＰＵ、
メモリ、Ｉ／Ｏデバイスを割り当てることが可能とな
る。例えば図２のサーバ＃１（１２０）では、ＣＰＵ＃
１０〜＃１３と４個あるので、ＬＰＡＲを用いることで
ＯＳ＃０（１５５）にはＣＰＵ＃１０を割り当て、ＯＳ
＃１（１６０）にはＣＰＵ＃１１、＃１２、＃１３（１
２２、１２３、１２４）を割り当てることができる。メ
インメモリ１２５についても容量を適当な割合でＯＳ＃
０（１５５）、ＯＳ＃１（１６０）に割り当てることが
できる。Ｉ／Ｏアダプタが複数ある場合はＯＳ＃０（１
５５）、ＯＳ＃１（１６０）に割り当てることができる
がこの例では１個しかないので、Ｉ／Ｏアダプタ１２８
は両ＯＳで共有することになる。このような技術につい
ては、特開平１０-３０１７９５号に開示された「仮想
計算機システム」等がある。また、特開２０００−１１
２８０４号には、複数のＯＳがファイルを共用して動作
する仮想計算機システムにおいて、１つのＯＳが他のＯ
Ｓのデータファイルをアクセスすることを防止するた
め、ＯＳ番号が付されたＩ／Ｏ命令をディスク装置に対
して発行することが記載されている。また、特開平４−
１４０８４４号には、ＯＳが発行したＩ／Ｏ命令を解析
するＩ／Ｏ解析手段を有し、Ｉ／Ｏ解析手段では引き取
ったＩ／Ｏ命令にＯＳ識別子を付加し、複数ＯＳを同時
動作させたときに排他制御することが記載されている。
【０００４】
【発明が解決しようとする課題】以上に述べたように，
ＷＷＮ２０５、２１５、２２５をディスク装置１７０で
識別することによって論理ボリューム１９５、１９６の
排他／優先制御を行うことが可能となる。またＬＰＡＲ
を用いることでサーバ内複数のＯＳに対して，ＣＰＵ、
メモリ、Ｉ／Ｏデバイスを効率よく割り当てることが可
能になる。しかし一般にサーバ内ＣＰＵ数の増加の割合
に対して、Ｉ／Ｏデバイスの数はそれほど多く増加せ
ず、ＣＰＵ間で共有する場合が多い。これはコストを削
減とＩ／Ｏデバイスが外部へのＩ／Ｆを持つことによる
物理的な大きさのためである。このような状況で論理ボ
リュームの排他／優先制御を行う場合、以下のように排
他／優先制御が出来なくなる問題がある。例えば、図２
のサーバ＃１（１２０）ではＯＳ＃０（１５５）とＯＳ
＃１（１６０）が同じサーバ内に存在し、Ｉ／Ｏアダプ
タ１２８を共有して使うことになる。しかし両ＯＳから
発行するデータフレーム１３５、１４０のＷＷＮ２１
５、２２５はＩ／Ｏアダプタ１２８を共有するため同じ
識別番号“００１”が付けられる。よってディスク装置
１７０ではこの２個のデータフレームについて排他／優
先制御は行うことができない。よってＯＳ＃０（１５
５）が論理ボリューム＃０（１９５）を所有、他のＯＳ
にアクセスすることを許可しない場合でも、上記理由に
よりＯＳ＃１（１６０）は論理ボリューム＃０（１９
５）にアクセスすることが可能となってしまう。本発明
の主たる目的は、サーバ内の複数ＯＳがＩ／Ｏデバイス
とストレージシステムを共有する場合に、各ＯＳに固有
な識別情報をサーバ側で付加、ディスク装置側で抽出す
る手段をつけることにより各ＯＳ毎に所有する論理ボリ
ュームの排他／優先制御を行う技術を改良することにあ
る。本発明のさらに別の目的は、ディスク装置に排他／
優先制御方法を記述したテーブルを設置し、複数の排他
／優先制御方法から選択し実行する技術を提供すること
にある。本発明のさらに別の目的は、サーバからディス
ク装置に対して、各ＯＳ毎に複数の排他／優先制御方式
をディスク装置に対して命令する技術を提供することに
ある。
ＷＷＮ２０５、２１５、２２５をディスク装置１７０で
識別することによって論理ボリューム１９５、１９６の
排他／優先制御を行うことが可能となる。またＬＰＡＲ
を用いることでサーバ内複数のＯＳに対して，ＣＰＵ、
メモリ、Ｉ／Ｏデバイスを効率よく割り当てることが可
能になる。しかし一般にサーバ内ＣＰＵ数の増加の割合
に対して、Ｉ／Ｏデバイスの数はそれほど多く増加せ
ず、ＣＰＵ間で共有する場合が多い。これはコストを削
減とＩ／Ｏデバイスが外部へのＩ／Ｆを持つことによる
物理的な大きさのためである。このような状況で論理ボ
リュームの排他／優先制御を行う場合、以下のように排
他／優先制御が出来なくなる問題がある。例えば、図２
のサーバ＃１（１２０）ではＯＳ＃０（１５５）とＯＳ
＃１（１６０）が同じサーバ内に存在し、Ｉ／Ｏアダプ
タ１２８を共有して使うことになる。しかし両ＯＳから
発行するデータフレーム１３５、１４０のＷＷＮ２１
５、２２５はＩ／Ｏアダプタ１２８を共有するため同じ
識別番号“００１”が付けられる。よってディスク装置
１７０ではこの２個のデータフレームについて排他／優
先制御は行うことができない。よってＯＳ＃０（１５
５）が論理ボリューム＃０（１９５）を所有、他のＯＳ
にアクセスすることを許可しない場合でも、上記理由に
よりＯＳ＃１（１６０）は論理ボリューム＃０（１９
５）にアクセスすることが可能となってしまう。本発明
の主たる目的は、サーバ内の複数ＯＳがＩ／Ｏデバイス
とストレージシステムを共有する場合に、各ＯＳに固有
な識別情報をサーバ側で付加、ディスク装置側で抽出す
る手段をつけることにより各ＯＳ毎に所有する論理ボリ
ュームの排他／優先制御を行う技術を改良することにあ
る。本発明のさらに別の目的は、ディスク装置に排他／
優先制御方法を記述したテーブルを設置し、複数の排他
／優先制御方法から選択し実行する技術を提供すること
にある。本発明のさらに別の目的は、サーバからディス
ク装置に対して、各ＯＳ毎に複数の排他／優先制御方式
をディスク装置に対して命令する技術を提供することに
ある。
【０００５】
【課題を解決するための手段】上記問題を解決するため
に、複数のＯＳを有し、前記ＯＳからのアクセス要求が
あると当該ＯＳを識別する識別番号を付与し、前記付与
された識別番号を有するコマンドを送信するサーバと、
当該送信されたコマンドを受信するディスク装置とを備
え、前記ディスク装置は前記識別番号を抽出し、前記抽
出した識別番号に対応した論理ボリュームへのアクセス
を処理するかまたはアクセスを拒否するかに相当するレ
スポンスを前記識別番号を付与して返信し、前記サーバ
は前記レスポンスを受信する仮想プライベートボリュー
ム制御方法とする。また、サーバにＯＳ毎の識別番号を
ディスク装置アクセス時に発行するデータフレーム内に
書き込む手段をおく。また、ディスク装置の中で上記Ｏ
Ｓ毎の識別番号を抽出し、それを元にアクセスの排他／
優先制御を行う手段をおく。さらにサーバからディスク
装置にＯＳ毎にアクセス可能な論理ボリュームまたは排
他／優先制御情報を送る手段をおく。さらにディスク装
置に上記ＯＳ毎にアクセス可能な論理ボリュームまたは
排他／優先制御情報を格納するテーブルをおく。ここ
で、複数のＯＳとは、ＯＳユーザーが異なる場合など
の、仮想的に異なる複数のＯＳであればよく、同種のＯ
Ｓ（例えばＯＳ＃０がWindowsＮＴ［米国およびその他
の国における米国Microsoft Corp.の登録商標；以下同
じ］でＯＳ＃１がWindowsＮＴの場合、ＯＳ＃１がＵＮ
ＩＸ［X/Open Company Limited が独占的にライセンス
している米国ならびに他の国における登録商標；以下同
じ］でＯＳ＃２がＵＮＩＸなど）であってもよい。
に、複数のＯＳを有し、前記ＯＳからのアクセス要求が
あると当該ＯＳを識別する識別番号を付与し、前記付与
された識別番号を有するコマンドを送信するサーバと、
当該送信されたコマンドを受信するディスク装置とを備
え、前記ディスク装置は前記識別番号を抽出し、前記抽
出した識別番号に対応した論理ボリュームへのアクセス
を処理するかまたはアクセスを拒否するかに相当するレ
スポンスを前記識別番号を付与して返信し、前記サーバ
は前記レスポンスを受信する仮想プライベートボリュー
ム制御方法とする。また、サーバにＯＳ毎の識別番号を
ディスク装置アクセス時に発行するデータフレーム内に
書き込む手段をおく。また、ディスク装置の中で上記Ｏ
Ｓ毎の識別番号を抽出し、それを元にアクセスの排他／
優先制御を行う手段をおく。さらにサーバからディスク
装置にＯＳ毎にアクセス可能な論理ボリュームまたは排
他／優先制御情報を送る手段をおく。さらにディスク装
置に上記ＯＳ毎にアクセス可能な論理ボリュームまたは
排他／優先制御情報を格納するテーブルをおく。ここ
で、複数のＯＳとは、ＯＳユーザーが異なる場合など
の、仮想的に異なる複数のＯＳであればよく、同種のＯ
Ｓ（例えばＯＳ＃０がWindowsＮＴ［米国およびその他
の国における米国Microsoft Corp.の登録商標；以下同
じ］でＯＳ＃１がWindowsＮＴの場合、ＯＳ＃１がＵＮ
ＩＸ［X/Open Company Limited が独占的にライセンス
している米国ならびに他の国における登録商標；以下同
じ］でＯＳ＃２がＵＮＩＸなど）であってもよい。
【０００６】
【発明の実施の形態】（実施例１）以下、本発明に係る
の実施例１を図面に示しさらに詳細に説明する。図１は
本発明の実施例１における仮想プライベートボリューム
制御装置の全体構成図である。１１０、１２０はサーバ
であり、ＯＳ、アプリケーションを動かし、ディスク装
置１７０に対してデータの読み出し、書き込み等の命令
を発行する。１１１、１１２、１１３、１１４、１２
１、１２２、１２３、１２４はCPUであり、サーバ＃
０、＃１（１１０、１２０）に複数格納され、OS,アプ
リケーションの処理を並列に行う。１１５、１２５はメ
インメモリであり、CPUが直接使うデータを格納してあ
る。１１６、１２６はノードコントローラであり、CPU
とI/OアダプタまたはLANアダプタ等の下位アダプタ間の
転送を制御する。１１７、１２７はLANコントローラで
あり、CPU（１１１、１１２、１１３、１１４、１２
１、１２２、１２３、１２４）とLAN１４５に接続して
いる外部装置間の転送を制御する。１１８、１２８、１
７３、１７４はI／Oアダプタであり、CPU（１１１、１
１２、１１３、１１４、１２１、１２２、１２３、１２
４）とディスク装置１７０間の転送を制御する。図１の
例では複数のCPUでメインメモリ、LANアダプタ、I/Oア
ダプタを共用することになる。１４５はLAN（Local Ar
ea Network）でありサーバとディスク装置間のデータ
を通す通信路である。このLAN１４５を使ってディスク
装置１７０はサーバ１１０、１２０からの排他／優先制
御に関する情報を入手する。１７０はディスク装置であ
り、サーバ＃０、＃１（１１０、１２０）の命令に従っ
てデータの読み出し、書き込みを行う。１７１、１７２
はSVP（Service Processor）であり、LAN１４５を経由
してサーバ＃０、＃１（１１０、１２０）より送られる
ディスク装置１７０の制御情報を受信し、ディスク装置
１７０の必要な制御情報を変更する。１７５、１７６は
チャネルコントローラであり、サーバ＃０、＃１（１１
０、１２０）からくるコマンドを解析し、必要なデータ
の検索、送受信を行う。１８０、１８１はローカルメモ
リであり、チャネルコントローラ１７５、１７６を制御
する際に必要な制御情報を格納する。１８４は共有メモ
リであり、チャネルコントローラ１７５、１７６間の通
信、制御を行う際に必要な制御情報を格納する。１８
２、１８３、１８５は排他／優先制御テーブルであり、
論理ボリューム等の排他／優先制御を行う際に必要な制
御情報を格納する。詳しくは図６にて説明する。１８６
はキャッシュメモリであり、サーバ＃０、＃１（１１
０、１２０）が必要としているデータを格納するメモリ
である。ただしすべてのデータは格納されておらず、使
用頻度の高いデータのみ格納されている。１８７、１８
８はキャッシュメモリ１８６内に格納されたデータであ
る。１９０はディスクコントローラであり、磁気ディス
ク１９１、１９２、１９３，１９４とキャッシュメモリ
１８６間データの送受信制御を行う。１９１、１９２、
１９３，１９４は磁気ディスクであり、データが最終的
に格納されている記憶装置である。１５０、１５５、１
６０はOSであり、アプリケーションからのアクセスの制
御等を行う。１９５、１９６は論理ボリュームであり、
OS＃０（１５０）、OS＃１（１５５）、OS＃２（１６
０）に割り当てられる記憶領域である。OS＃０（１５
０）、OS＃１（１５５）、OS＃２（１６０）から論理ボ
リューム＃０（１９５）、＃１（１９６）に対するアク
セス命令はI／Oアダプタ１１８、１２８でコマンドおよ
び制御情報に変換され、データフレーム１３０、１３
５、１４０内に書き込まれ、ディスク装置１７０へ転送
される。データフレーム内の詳細については図３にて説
明する。１９７、１９８はI/Oパスであり、サーバ＃
０、＃１（１１０、１２０）とディスク装置１７０を接
続しているデータの通信路である。この例ではファイバ
ーチャネル（FC）を示しているが他の規格でも本発明の
範囲内である。ここで、複数のＯＳとは、ＯＳユーザー
が異なる場合などの、仮想的に異なる複数のＯＳであれ
ばよく、同種のＯＳ（例えばＯＳ＃０がＮＴでＯＳ＃１
がＮＴの場合、ＯＳ＃１がＵＮＩＸでＯＳ＃２がＵＮＩ
Ｘなど）であってもよい。
の実施例１を図面に示しさらに詳細に説明する。図１は
本発明の実施例１における仮想プライベートボリューム
制御装置の全体構成図である。１１０、１２０はサーバ
であり、ＯＳ、アプリケーションを動かし、ディスク装
置１７０に対してデータの読み出し、書き込み等の命令
を発行する。１１１、１１２、１１３、１１４、１２
１、１２２、１２３、１２４はCPUであり、サーバ＃
０、＃１（１１０、１２０）に複数格納され、OS,アプ
リケーションの処理を並列に行う。１１５、１２５はメ
インメモリであり、CPUが直接使うデータを格納してあ
る。１１６、１２６はノードコントローラであり、CPU
とI/OアダプタまたはLANアダプタ等の下位アダプタ間の
転送を制御する。１１７、１２７はLANコントローラで
あり、CPU（１１１、１１２、１１３、１１４、１２
１、１２２、１２３、１２４）とLAN１４５に接続して
いる外部装置間の転送を制御する。１１８、１２８、１
７３、１７４はI／Oアダプタであり、CPU（１１１、１
１２、１１３、１１４、１２１、１２２、１２３、１２
４）とディスク装置１７０間の転送を制御する。図１の
例では複数のCPUでメインメモリ、LANアダプタ、I/Oア
ダプタを共用することになる。１４５はLAN（Local Ar
ea Network）でありサーバとディスク装置間のデータ
を通す通信路である。このLAN１４５を使ってディスク
装置１７０はサーバ１１０、１２０からの排他／優先制
御に関する情報を入手する。１７０はディスク装置であ
り、サーバ＃０、＃１（１１０、１２０）の命令に従っ
てデータの読み出し、書き込みを行う。１７１、１７２
はSVP（Service Processor）であり、LAN１４５を経由
してサーバ＃０、＃１（１１０、１２０）より送られる
ディスク装置１７０の制御情報を受信し、ディスク装置
１７０の必要な制御情報を変更する。１７５、１７６は
チャネルコントローラであり、サーバ＃０、＃１（１１
０、１２０）からくるコマンドを解析し、必要なデータ
の検索、送受信を行う。１８０、１８１はローカルメモ
リであり、チャネルコントローラ１７５、１７６を制御
する際に必要な制御情報を格納する。１８４は共有メモ
リであり、チャネルコントローラ１７５、１７６間の通
信、制御を行う際に必要な制御情報を格納する。１８
２、１８３、１８５は排他／優先制御テーブルであり、
論理ボリューム等の排他／優先制御を行う際に必要な制
御情報を格納する。詳しくは図６にて説明する。１８６
はキャッシュメモリであり、サーバ＃０、＃１（１１
０、１２０）が必要としているデータを格納するメモリ
である。ただしすべてのデータは格納されておらず、使
用頻度の高いデータのみ格納されている。１８７、１８
８はキャッシュメモリ１８６内に格納されたデータであ
る。１９０はディスクコントローラであり、磁気ディス
ク１９１、１９２、１９３，１９４とキャッシュメモリ
１８６間データの送受信制御を行う。１９１、１９２、
１９３，１９４は磁気ディスクであり、データが最終的
に格納されている記憶装置である。１５０、１５５、１
６０はOSであり、アプリケーションからのアクセスの制
御等を行う。１９５、１９６は論理ボリュームであり、
OS＃０（１５０）、OS＃１（１５５）、OS＃２（１６
０）に割り当てられる記憶領域である。OS＃０（１５
０）、OS＃１（１５５）、OS＃２（１６０）から論理ボ
リューム＃０（１９５）、＃１（１９６）に対するアク
セス命令はI／Oアダプタ１１８、１２８でコマンドおよ
び制御情報に変換され、データフレーム１３０、１３
５、１４０内に書き込まれ、ディスク装置１７０へ転送
される。データフレーム内の詳細については図３にて説
明する。１９７、１９８はI/Oパスであり、サーバ＃
０、＃１（１１０、１２０）とディスク装置１７０を接
続しているデータの通信路である。この例ではファイバ
ーチャネル（FC）を示しているが他の規格でも本発明の
範囲内である。ここで、複数のＯＳとは、ＯＳユーザー
が異なる場合などの、仮想的に異なる複数のＯＳであれ
ばよく、同種のＯＳ（例えばＯＳ＃０がＮＴでＯＳ＃１
がＮＴの場合、ＯＳ＃１がＵＮＩＸでＯＳ＃２がＵＮＩ
Ｘなど）であってもよい。
【０００７】図３に本発明の実施例１におけるデータフ
レーム構造例を示す。この構造例はファイバーチャネル
の標準規格のフォーマットを参考にしたものである。３
００はデータフレームの例であり、幾つかの部分から成
り立つデータである。３０５はStart Of Frame識別子で
あり、データフレームの先頭をI／Oアダプタ１１８、１
２８、１７３、１７４に伝える。３１０はフレームヘッ
ダであり、データフレームのアドレス等を記述してい
る。詳細は後で述べる。３１５は、ペイロードであり上
位プロトコルのデータ、コマンド等が格納されている。
詳細は後で述べる。３２０はCRC（Cyclic Redundancy C
heck）であり、データフレーム３００内のデータの誤り
を発見し訂正を行う。３２５はEnd Of Frame識別子であ
り、データフレームの終わりをI／Oアダプタ１１８、１
２８、１７３、１７４に伝える。次にフレームヘッダ３
１０の構造例を示す。３３０は送信先ポートIDでありデ
ータフレーム３００が次に進みたい装置のポートIDを示
す。３３５は送信元ポートIDでありデータフレームをデ
ィスク装置１７０に送信してきた装置のポートIDを示
す。具体的にはＷＷＮの情報がここに格納され、異なる
Ｉ／Ｏアダプタからのデータフレームの排他／優先制御
に用いられる。３４０は上位レイヤプロトコルであり、
送信元と送信先がデータのやり取りを行う際に使うプロ
トコルの種類を示しており、たとえばSCSI等があげられ
る。３４５は上位レイヤシーケンスIDであり、上位プロ
トコルに従った通信におけるシーケンスの順番を示す。
３５０はシーケンス内フレーム番号であり、シーケンス
内にある複数のデータフレームの順番を示す。３５５は
上位レイヤプロトコル送信先IDであり、最終的にデータ
フレーム３００が到着する装置のポートIDを示す。次に
ペイロード内容としてＳＣＳＩを上位プロトコルに使っ
た場合のリードコマンド構造例を示す。３６０はグルー
プコードであり、コマンドの長さまたは標準のコマンド
かベンダユニークなコマンドかの区別をする。３６５は
コマンドコードでありこの例の場合はリードコマンドに
対応するコードが入る。３７０は論理ボリューム番号
（ＬＵＮ）であり例えば磁気ディスク１９１〜１９４に
設定された 論理ボリューム＃０（１９５）、＃１（１
９６）を示している。３７５はデータ等が存在する場所
のアドレスであり、例えば論理ボリューム＃０（１９
５）、＃１（１９６）内のアドレスを示している。３８
０はＬＰＡＲ−ＩＤを示しており、具体的にはハイパバ
イザ４３０の指定した各ＯＳの識別番号が入る。３８５
は転送データ長であり、リードする範囲を示す。３９０
はコントロールバイトであり、データフレーム３００ま
たはペイロード３１５が扱える容量に合わせるために付
け加える空白なデータである。なお上記例以外のフォー
マットを使ってＷＷＮ、ＬＰＡＲ−ＩＤをフレームに内
蔵させた場合でも、本発明の範囲であることは自明であ
る。図４に本発明の実施例１におけるソフトウエア構造
例とデータ転送成功例を示す。ここでサーバ＃０（１１
０）のみ説明する。４１０、４１１、４１２、４１３は
ミドル／アプリであり、ユーザの処理を直接受けるプロ
グラムである。４２０、４２１、４２２、４２３はＯＳ
であり、ミドル／アプリ４１０、４１１、４１２、４１
３からの要求を調整、処理を行う。４３０はハイババイ
ザであり、サーバ＃０（１１０）内のＣＰＵ、メインメ
モリ、Ｉ／Ｏデバイスを複数のＯＳ４２０、４２１、４
２２、４２３に分割して利用させる。また各ＯＳ４２
０、４２１、４２２、４２３の識別番号となるＬＰＡＲ
−ＩＤ４５０、４５１、４５２を管理、設定する。４４
０、４４１、４４２はデバイスドライバであり、ディス
ク装置１７０へのアクセスが必要な場合、コマンド、デ
ータ、ＷＷＮ、ＬＰＡＲ−ＩＤ等をデータフレーム１３
０に設定してディスク装置１７０に送信する。４５５は
制御フレームであり、サーバ＃０（１１０）からディス
ク装置１７０の制御方式等を変更したい場合にこの中に
設定してディスク装置１７０にあるテーブルセットプロ
グラム４７０に送信する。制御フレームの詳細について
は図７にて説明する。４６０、４６５はディスク装置１
７０のμプログラム（μＰ）であり、ディスク装置１７
０のＩ／Ｏアダプタ１７３、１７４、チャネルコントロ
ーラ１７５、１７６、キャッシュメモリ１８６を制御す
る。ディスク装置１７０のμプログラム４６０は、Ｉ／
Ｏアダプタでフレームの受信、解析を制御するＩ／Ｏア
ダプタμＰと、チャネルコントローラでコマンドの解
析、排他／優先制御、コマンド実行を制御するチャネル
コントローラμＰ（４６２）に分かれている。さらにチ
ャネルコントローラμＰ（４６２）ではデータフレーム
１３０内に書きこまれている、ＷＷＮ、ＬＰＡＲ−ＩＤ
を抽出して、排他／優先制御テーブル１８２、１８５の
内容と比較することにより、Ｉ／Ｏアクセスの排他／優
先制御を実行する。排他／優先制御の詳細は図１２、１
２、１３、１４で説明する。４７０はテーブルセットプ
ログラムであり、サーバ＃０（１１０）から来た制御フ
レーム４５５を受信し、内容をローカルメモリ１８０ま
たは共有メモリ１８４内の排他／優先制御テーブル１８
２、１８５に格納する。図４のようにデータフレーム１
３０のＬＰＡＲ−ＩＤがローカルメモリ１８０、または
共有メモリ１８４にある排他／制御テーブル１８２、１
８５内で論理ボリューム＃０（１９５）へのアクセスを
許可されている場合、アクセスの結果は以下のようにな
る。アクセスが許可されているので、論理ボリューム＃
０（１９５）内の必要なデータをリードし、フレーム１
３６にＬＰＡＲ−ＩＤといっしょに載せてサーバ＃０
（１１０）に送る。さらにデータ転送が正しく処理した
ことをステータスとして、フレーム１３７にＬＰＡＲ−
ＩＤ等といっしょに載せてサーバ＃０（１１０）に送
る。これらのフレーム１３６、１３７を受け取ることに
よりサーバはデータアクセスを完了する。図４の様なソ
フトウエア構造においてハイパバイザ４３０がデバイス
ドライバ４４０、４４１、４４２にＬＰＡＲ−ＩＤを設
定する方式は２通りある。一つは初期設定時にデバイス
ドライバ４４０、４４１に設定する方式である。ＯＳ４
２０、４２１とデバイスドライバ＃０（４４０）、＃１
（４４１）が一対一に対応している場合はＯＳにＬＰＡ
Ｒ−ＩＤが割り当てられた時に各デバイスドライバに来
るＩ／ＯのＬＰＡＲ−ＩＤも決まっているので、初期設
定時にハイパバイザ４３０よりＯＳ４２０、４２１、デ
バイスドライバ＃０（４４０）、＃１（４４１）がそれ
ぞれＬＰＡＲ−ＩＤ＃０、＃１（４５０、４５１）を受
け取り設定する。Ｉ／Ｏアクセス発生時にはデバイスド
ライバ＃０、＃１（４４０，４４１）は設定されたＬＰ
ＡＲ−ＩＤ＃０、＃１（４５０，４５１）をデータフレ
ーム１３０に設定する。２種類目はＩ／Ｏアクセス毎に
デバイスドライバ＃２（４４２）にＬＰＡＲ−ＩＤ＃２
／３（４５２）を連絡する方式である。ＯＳ４２２、４
２３はデバイスドライバ＃２（４４２）を共有している
ので実際にＩ／Ｏアクセスが発生するまでどちらのＯＳ
のＩ／Ｏアクセスなのか不明である。そのためＯＳがＩ
／Ｏアクセスをデバイスドライバ＃２（４４２）に発行
する際に、前もってハイパバイザより設定されたＬＰＡ
Ｒ−ＩＤ＃２／３（４５２）を同時にデバイスドライバ
４４２に送信する。受信したデバイスドライバ＃２（４
４２）はそのＬＰＡＲ−ＩＤ＃２／３（４５２）をデー
タフレーム１３０に設定する。以上のようにしてデータ
フレーム１３０にＬＰＡＲ−ＩＤ＃０、＃１、＃２、＃
３（４５０、４５１，４５２）が設定されると、同じＩ
／Ｏアダプタ１１８を共有している複数のＯＳ（４２
０、４２１、４２２、４２３）からＩ／Ｏアクセスが発
生した場合でも、ＬＰＡＲ−ＩＤ＃０、＃１、＃２、＃
３（４５０、４５１，４５２）が異なるため、上で述べ
た様にストレージ側でこれを識別することで排他／優先
制御を行うことが可能になる。図５に本発明の実施例１
におけるソフトウエア構造例とデータ転送失敗例を示
す。図５のようにデータフレーム１３０のＬＰＡＲ−Ｉ
Ｄがローカルメモリ１８０、または共有メモリ１８４に
ある排他／制御テーブル１８２、１８５内で論理ボリュ
ーム＃０（１９５）へのアクセスを許可されていない場
合、アクセスの結果は以下のようになる。アクセスが許
可されていないので、データ転送が正しく処理できずエ
ラーとなる。エラーが発生したことをステータスとし
て、フレーム１３８にＬＰＡＲ−ＩＤ等といっしょに載
せてサーバ＃０（１１０）に送る。このフレーム１３８
を受け取ることによりサーバは次に行うべきエラー処理
を判断することが可能になる。一般的にはこの後サーバ
側がディスク装置のエラー情報にアクセスして次の処理
を決定する。図４，５で示したサーバへのフレーム１３
７、１３８の返信は本発明のひとつの例であり、排他／
優先制御に関する他の情報を返信することが可能なこと
は明白である。図６に本発明の実施例１における排他/
優先制御テーブル例を示す。５００は例として論理ボリ
ューム＃０（１９５）の排他／優先制御テーブルを示し
ている。５０５、５１０、５１５、５２０は論理ボリュ
ーム＃０（１９５）アクセスする可能性があるWWNを示
す。５２５、５３０、５３５、５４０は各WWNを持つI／
Oアダプタからアクセスする可能性のあるＯＳのＬＰＡ
Ｒ−ＩＤを示す。この表で“○”で示されているＷＷ
Ｎ、ＬＰＡＲ−ＩＤは論理ボリューム＃０（１９５）に
アクセスが可能である。逆に“×”の場合論理ボリュー
ム＃０（１９５）にアクセスは排他される。この制御方
式は図１３に詳細を説明する。また排他制御＃２と書い
てあった場合は図１４で詳細を説明する排他制御方式に
従う。また優先制御と書いてあった場合は図１５で示す
優先制御方式に従う。ここで他の排他／優先制御を用い
る場合でもこの排他／優先制御テーブル５００に登録し
ておけば実現可能であることは自明である。排他／優先
制御テーブルは論理ボリューム毎に存在し、それらの集
合はローカルメモリ１８０、１８１、共有メモリ１８４
内に存在する（排他／優先制御テーブル１８２、１８
３、１８５）。そしてチャネルコントローラ１７５、１
７６はこれらの表を参照して排他／優先制御を行う。こ
れらの排他／優先制御テーブルはＬＡＮ１４５を通し
て、サーバ＃０、＃１（１１０、１２０）から送られる
制御フレーム４５５をテーブルセットプログラム４７０
が受信し、生成、変更することによってできる。制御フ
レーム４５５の詳細については図７で説明する。図７に
本発明の実施例１における制御フレーム構造例を示す。
制御フレーム構造例についてはＩＰ、ＵＤＰのプロトコ
ルを参考にしたものである。またメッセージ構造例につ
いてはＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａ
ｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を参考にしたも
のである。ローカルネットワークヘッダ６０５には、Ｌ
ＡＮ通信に必要なアドレス、データ長等の制御情報が格
納されている。ＩＰヘッダ６１０にはＩＰを使った通信
に必要なアドレス、データ長等の制御情報が格納されて
いる。ＵＤＰヘッダ６１５にはＵＤＰを使った通信に必
要なアドレス、データ長等の制御情報が格納されてい
る。ここで取り上げた以外のプロトコルを使っても本発
明の範囲であることは自明である。６２０はメッセージ
であり詳細については後で説明する。６２５はローカル
ネットワークトレイラであり、データのエラーチェック
のコード、データの終端のコード等が記述されている。
次にメッセージ６２０の構造例を示す。６３０はコマン
ドフィールドでありこのメッセージを使ってディスク装
置が行うべきことを示している。この例ではパラメータ
を排他／優先制御テーブルにセットする命令が入ってい
る。６３５はデータ長フィールドであり、以下のデータ
フィールドが何個続くかを示している。この例では６個
続くことを示している。６４０〜６６５まではデータフ
ィールドであり、排他／優先制御テーブルに設定すべき
パラメータが記述されている。この例では、論理ボリュ
ーム＃２（６４０）のＬＡＰＲ−ＩＤ＃２（６４５）か
つＷＷＮ＃１（６５０）のアクセスに関しては排他制御
＃２（６５５）を行い、その制約条件は最大排他処理時
間（６６０）と最大排他処理Ｉ／Ｏ数（６６５）である
ことを示している。データフィールドにはこのほかに優
先制御を行う際の優先順位等が入ることも考えられる。
図８に本発明の実施例１におけるサーバVPV制御初期化
のフロー示す。ここではサーバ＃０（１１０）側仮想プ
ライベートボリューム（ＶＰＶ）制御の初期化を行う。
ステップ７００からサーバＶＰＶ制御初期化が始まる。
ステップ７０５ではハイパバイザ４３０の初期化をまず
行う。ステップ７１０ではＬＰＡＲ−ＩＤ＃０（４５
０）、＃１（４５１）、＃２／３（４５２）を各ＬＰＡ
Ｒ（ＯＳ）に割り当てる。ステップ７１５では各ＬＰＡ
Ｒ内の特定エリアにＩＤを格納する。ステップ７２０で
はＯＳ４２０、４２１、４２２、４２３とデバイスドラ
イバ４４０、４４１、４４２を初期化して立ち上げる。
ステップ７２５ではＯＳ４２０、４２１、４２２、４２
３間でデバイスドライバ４４０、４４１、４４２を共用
しているかを調べる。もし共有していなければ（ＯＳ４
２０、４２１の場合）デバイスドライバ４４０、４４１
が各ＬＰＡＲが格納しているＬＰＡＲ−ＩＤ＃０（４５
０）、＃１（４５１）を取得する。デバイス４４０、４
４１、４４２を共有していれば（ＯＳ４２２、４２３の
場合）、ＯＳ４２２、４２３がＬＰＡＲ−ＩＤ＃２／３
（４５２）を取得する。ステップ７４０ではＬＰＡＲ−
ＩＤ＃０（４５０）、＃１（４５１）、＃２／３（４５
２）、論理ボリューム＃０、＃１（１９５，１９６）排
他／優先制御情報をディスク装置１７０に対して制御フ
レーム４５５を使って送信する。そしてステップ７４５
でサーバＶＰＶ制御初期化が終了する。図９に本発明の
実施例１におけるサーバ側I／O処理（デバイスドライバ
非共有）のフローチャート示す。ここでは初期化終了後
通常のＩ／Ｏ処理のフローを示す。またデバイスドライ
バはＯＳ間で共有しない。ステップ８００からサーバ側
Ｉ／Ｏ処理が開始される。ステップ８０５ではＯＳ４２
０、４２１にＩ／Ｏ処理が来ているかどうかを調べる。
もし来ていなければ、そのままステップ８０５に戻る。
Ｉ／Ｏ処理が来ていればステップ８１０に進み、ＯＳ４
２０、４２１がデバイスドライバ４４０、４４１用のシ
ステムコールを起動する。ステップ８１５ではデバイス
ドライバ４４０、４４１が起動する。ステップ８２０で
はデバイスドライバ４４０、４４１がデータフレーム１
３０に自分のＬＰＡＲ−ＩＤ＃０（４５０）、＃１（４
５１）を埋め込む。ステップ８３０ではディスク装置１
７０からデータフレームに対するステータスが返送され
たかどうかを調査する。返送していなければ、そのまま
ステップ８３０に戻る。ステータスが返送された場合、
ステップ８３５に進み、Ｉ／Ｏステータスが正常終了し
たかどうかを調べる。もし正常終了した場合はステップ
８０５に戻る。異常終了した場合、ステップ８４０に進
みエラー原因をディスク装置１７０に問い合わせる。ス
テップ８４５では問い合わせた結果を見て、サーバ＃０
（１１０）のエラー処理を行う。ステップ８５０ではＩ
／Ｏ処理の回復は不可能かどうか調べる。もし回復が可
能ならばステップ８０５に進む。不可能ならばステップ
８５５に進みサーバ側Ｉ／Ｏ処理を終了する。図１０に
本発明の実施例１におけるサーバ側I／O処理（デバイス
ドライバ共有）のフローチャートを示す。ここでは初期
化終了後通常のＩ／Ｏ処理のフローを示す。またデバイ
スドライバはＯＳ間で共有する。ステップ９００からサ
ーバ側Ｉ／Ｏ処理が開始される。ステップ９０５ではＯ
Ｓ４２２、４２３にＩ／Ｏ処理が来ているかどうかを調
べる。もし来ていなければ、そのままステップ９０５に
戻る。Ｉ／Ｏ処理が来ていればステップ９１０に進み、
ＯＳ４２２、４２３がデバイスドライバ４４２用のシス
テムコールを起動する。ステップ９１５ではＯＳ４２
２、４２３がデバイスドライバ４４２に対して自分のＬ
ＰＡＲ−ＩＤ＃２／３（４５２）を連絡する。ステップ
９２０ではデバイスドライバ４４２がデータフレーム１
３０に連絡されたのＬＰＡＲ−ＩＤ＃２／３（４５２）
を埋め込む。ステップ９３０以降は図９のステップ８３
０以降と同じなので以下説明を省略する。図１１に本発
明の実施例１におけるディスク装置VPV制御初期化のフ
ローチャートを示す。ここではディスク装置１７０側仮
想プライベートボリューム（ＶＰＶ）制御の初期化を行
う。ステップ１０００からディスク装置ＶＰＶ制御初期
化を開始する。ステップ１００５ではディスク装置１７
０の初期化を行う。ステップ１０１０ではＶＰＶ制御μ
プログラム立ち上げ、排他／優先制御テーブル１８２、
１８３、１８５の初期化を行う。ステップ１０１５では
サーバ＃０（１１０）より制御フレーム４５５を通し
て、ＬＰＡＲ−ＩＤ、論理ボリューム、排他／優先制御
に関する情報を受信する。受信なければ、ステップ１０
１５に戻る。受信した後、ステップ１０２０では排他／
優先制御テーブル１８２、１８３、１８５の設定を行
う。そしてステップ１０２５でディスク装置ＶＰＶ制御
初期化が終了する。図１２に本発明の実施例１における
ディスク装置側I／O処理フローチャートを示す。ここで
は初期化終了後ディスク装置１７０における通常のＩ／
Ｏ処理のフローを示す。ステップ１１００よりディスク
装置側Ｉ／Ｏ処理が開始される。ステップ１１０５では
Ｉ／Ｏアダプタ１７３、１７４にＩ／Ｏ処理が来ている
かどうかを調べる。もし来ていなければ、そのままステ
ップ１１０５に戻る。Ｉ／Ｏ処理が来ていればステップ
１１１０に進み、Ｉ／Ｏアダプタμプログラム４６１を
起動する。ステップ１１１５ではチャネルコントローラ
μプログラム４６２を起動する。ステップ１１２０では
コマンドに埋め込まれたＬＰＡＲ−ＩＤ３８０を抽出す
る。ステップ１１２５ではＩ／Ｏ処理対象の論理ボリュ
ーム３７０の排他／優先制御テーブル５００を参照す
る。ステップ１１３０ではＩ／ＯのＬＰＡＲ−ＩＤ３８
０、ＷＷＮ３３５を参照してそれが排他制御対象かどう
か調べる。排他制御対象でなければ、ステップ１１５０
の優先制御処理に進む。ステップ１１５０については図
１５で詳細を説明する。排他制御対象ならばステップ１
１３５に進む。ステップ１１３５については図１３、１
３で詳細を説明する。ステップ１１５０の優先制御処理
の後、ステップ１１３５で通常処理と判定された場合は
ステップ１１５５にてＩ／Ｏアクセス処理のキューに入
ってキャッシュメモリ１８６または磁気ディスク１９
１、１９２、１９３、１９４のＩ／Ｏ処理を待つ。ステ
ップ１１３５で排他処理と判定された場合はステップ１
１４０に進む。ステップ１１６０ではキューに入れたＩ
／Ｏの処理が正常に終わったかどうかを調べる。正常終
了した場合はステップ１１４５へ進む。異常終了した場
合はステップ１１４０へ進む。ステップ１１４０ではエ
ラーメッセージを作成してディスク装置１７０内に保存
する。ステップ１１４５はデータまたはステータスメッ
セージを作成して、サーバに返答する。その後ステップ
１１０５に戻る図１３に本発明の実施例１における第一
の排他制御処理例のフローチャートを示す。ここでは、
図１２のステップ１１３５の具体的な制御方式として、
一番単純な排他制御のフローを示す。ステップ１２００
より排他制御処理＃１が始まる。ステップ１２０５では
アクセスが排他されるべきかどうかを調べる。排他なら
ばステップ１２１５の排他処理へ進む。排他でなければ
ステップ１２０５の通常処理へ進む。図１４に本発明の
実施例１における第二の排他制御処理例のフローチャー
トを示す。ここでは、図１２のステップ１１３５の具体
的な制御方式として、処理時間、処理Ｉ／Ｏ数を条件と
した、制限付き排他制御のフローを示す。ステップ１３
００より排他制御処理＃２が始まる。ステップ１３０５
ではそれまでに排他処理を行った時間が、あらかじめ設
定してある最大排他処理時間（６６０）より少ないかど
うか調べる。少なければステップ１３１０へ進む。同じ
か、大きければステップ１３３５の通常処理へ進む。ス
テップ１３１０では排他処理時間を加算する。ステップ
１３１５ではそれまでに排他処理を行ったＩ／Ｏ数が、
あらかじめ設定してある最大排他処理Ｉ／Ｏ数（６６
５）より少ないかどうか調べる。少なければステップ１
３２０に進む。同じか、大きければステップ１３３５の
通常処理へ進む。ステップ１３２０では排他処理Ｉ／Ｏ
数の加算を行う。ステップ１３２５ではではアクセスが
排他されるべきかどうかを調べる。排他ならばステップ
１３３０の排他処理へ進む。排他でなければステップ１
３３５の通常処理へ進む。図１５に本発明の実施例１に
おける優先制御処理例のフローチャートを示す。ここで
は排他制御を行わず、処理の順番を変更するフローを示
す。この例はＳＣＳＩの標準規格のタグキューイングを
参考にしたものである。ステップ１４００から優先制御
処理が行われる。ステップ１４０５では処理するＩ／Ｏ
の処理順番を決めるためのポインタをキューの先頭にセ
ットする。ステップ１４１０では処理するＩ／Ｏの優先
順位を読み出す。ステップ１４１５ではキュー内のポイ
ンタの位置にＩ／Ｏがあるかどうかを調べる。なければ
ステップ１４３０へ進む。Ｉ／Ｏがあればステップ１４
２０に進みポインタ位置にあるキュー内Ｉ／Ｏの優先順
位を読み出す。ステップ１４２５ではキュウ内Ｉ／Ｏの
優先順位が処理するＩ／Ｏの優先順位より高いかどうか
を調べる。優先順位高ければステップ１４３５に進み、
ポインタを１加算して、ステップ１４１５に戻る。優先
順位が低ければステップ１４３０へ進む。ステップ１４
３０では処理するＩ／Ｏの順番を現時点でセットされた
ポインタの位置に決定する。ステップ１４４０では通常
処理へ進む。なお以上のフロー例以外の方式を使った排
他／優先制御処理も本発明の範囲であることは自明であ
る。以上図１から図１５までに示した実施例１によれ
ば、ＬＰＡＲ−ＩＤをデータフレームに入れてディスク
装置に送信し、受信したディスク装置側で排他制御を行
うことにより、Ｉ／Ｏアダプタを共有する複数のＯＳに
関しても排他制御を行うことが可能となる。またディス
ク装置側でＬＰＡＲ−ＩＤ、ＷＷＮを考慮した排他／優
先制御テーブルを持つことにより、サーバ間をまたがっ
たＯＳ等に関してもディスク装置側で統一的に排他／優
先制御を行うことが可能となる。また排他／優先制御方
式も複数の方式を選択できるようにしているので、柔軟
な排他制御、性能の最適化が可能となる。 （実施例２）以下、本発明に係るの実施例２を図面に示
しさらに詳細に説明する。
レーム構造例を示す。この構造例はファイバーチャネル
の標準規格のフォーマットを参考にしたものである。３
００はデータフレームの例であり、幾つかの部分から成
り立つデータである。３０５はStart Of Frame識別子で
あり、データフレームの先頭をI／Oアダプタ１１８、１
２８、１７３、１７４に伝える。３１０はフレームヘッ
ダであり、データフレームのアドレス等を記述してい
る。詳細は後で述べる。３１５は、ペイロードであり上
位プロトコルのデータ、コマンド等が格納されている。
詳細は後で述べる。３２０はCRC（Cyclic Redundancy C
heck）であり、データフレーム３００内のデータの誤り
を発見し訂正を行う。３２５はEnd Of Frame識別子であ
り、データフレームの終わりをI／Oアダプタ１１８、１
２８、１７３、１７４に伝える。次にフレームヘッダ３
１０の構造例を示す。３３０は送信先ポートIDでありデ
ータフレーム３００が次に進みたい装置のポートIDを示
す。３３５は送信元ポートIDでありデータフレームをデ
ィスク装置１７０に送信してきた装置のポートIDを示
す。具体的にはＷＷＮの情報がここに格納され、異なる
Ｉ／Ｏアダプタからのデータフレームの排他／優先制御
に用いられる。３４０は上位レイヤプロトコルであり、
送信元と送信先がデータのやり取りを行う際に使うプロ
トコルの種類を示しており、たとえばSCSI等があげられ
る。３４５は上位レイヤシーケンスIDであり、上位プロ
トコルに従った通信におけるシーケンスの順番を示す。
３５０はシーケンス内フレーム番号であり、シーケンス
内にある複数のデータフレームの順番を示す。３５５は
上位レイヤプロトコル送信先IDであり、最終的にデータ
フレーム３００が到着する装置のポートIDを示す。次に
ペイロード内容としてＳＣＳＩを上位プロトコルに使っ
た場合のリードコマンド構造例を示す。３６０はグルー
プコードであり、コマンドの長さまたは標準のコマンド
かベンダユニークなコマンドかの区別をする。３６５は
コマンドコードでありこの例の場合はリードコマンドに
対応するコードが入る。３７０は論理ボリューム番号
（ＬＵＮ）であり例えば磁気ディスク１９１〜１９４に
設定された 論理ボリューム＃０（１９５）、＃１（１
９６）を示している。３７５はデータ等が存在する場所
のアドレスであり、例えば論理ボリューム＃０（１９
５）、＃１（１９６）内のアドレスを示している。３８
０はＬＰＡＲ−ＩＤを示しており、具体的にはハイパバ
イザ４３０の指定した各ＯＳの識別番号が入る。３８５
は転送データ長であり、リードする範囲を示す。３９０
はコントロールバイトであり、データフレーム３００ま
たはペイロード３１５が扱える容量に合わせるために付
け加える空白なデータである。なお上記例以外のフォー
マットを使ってＷＷＮ、ＬＰＡＲ−ＩＤをフレームに内
蔵させた場合でも、本発明の範囲であることは自明であ
る。図４に本発明の実施例１におけるソフトウエア構造
例とデータ転送成功例を示す。ここでサーバ＃０（１１
０）のみ説明する。４１０、４１１、４１２、４１３は
ミドル／アプリであり、ユーザの処理を直接受けるプロ
グラムである。４２０、４２１、４２２、４２３はＯＳ
であり、ミドル／アプリ４１０、４１１、４１２、４１
３からの要求を調整、処理を行う。４３０はハイババイ
ザであり、サーバ＃０（１１０）内のＣＰＵ、メインメ
モリ、Ｉ／Ｏデバイスを複数のＯＳ４２０、４２１、４
２２、４２３に分割して利用させる。また各ＯＳ４２
０、４２１、４２２、４２３の識別番号となるＬＰＡＲ
−ＩＤ４５０、４５１、４５２を管理、設定する。４４
０、４４１、４４２はデバイスドライバであり、ディス
ク装置１７０へのアクセスが必要な場合、コマンド、デ
ータ、ＷＷＮ、ＬＰＡＲ−ＩＤ等をデータフレーム１３
０に設定してディスク装置１７０に送信する。４５５は
制御フレームであり、サーバ＃０（１１０）からディス
ク装置１７０の制御方式等を変更したい場合にこの中に
設定してディスク装置１７０にあるテーブルセットプロ
グラム４７０に送信する。制御フレームの詳細について
は図７にて説明する。４６０、４６５はディスク装置１
７０のμプログラム（μＰ）であり、ディスク装置１７
０のＩ／Ｏアダプタ１７３、１７４、チャネルコントロ
ーラ１７５、１７６、キャッシュメモリ１８６を制御す
る。ディスク装置１７０のμプログラム４６０は、Ｉ／
Ｏアダプタでフレームの受信、解析を制御するＩ／Ｏア
ダプタμＰと、チャネルコントローラでコマンドの解
析、排他／優先制御、コマンド実行を制御するチャネル
コントローラμＰ（４６２）に分かれている。さらにチ
ャネルコントローラμＰ（４６２）ではデータフレーム
１３０内に書きこまれている、ＷＷＮ、ＬＰＡＲ−ＩＤ
を抽出して、排他／優先制御テーブル１８２、１８５の
内容と比較することにより、Ｉ／Ｏアクセスの排他／優
先制御を実行する。排他／優先制御の詳細は図１２、１
２、１３、１４で説明する。４７０はテーブルセットプ
ログラムであり、サーバ＃０（１１０）から来た制御フ
レーム４５５を受信し、内容をローカルメモリ１８０ま
たは共有メモリ１８４内の排他／優先制御テーブル１８
２、１８５に格納する。図４のようにデータフレーム１
３０のＬＰＡＲ−ＩＤがローカルメモリ１８０、または
共有メモリ１８４にある排他／制御テーブル１８２、１
８５内で論理ボリューム＃０（１９５）へのアクセスを
許可されている場合、アクセスの結果は以下のようにな
る。アクセスが許可されているので、論理ボリューム＃
０（１９５）内の必要なデータをリードし、フレーム１
３６にＬＰＡＲ−ＩＤといっしょに載せてサーバ＃０
（１１０）に送る。さらにデータ転送が正しく処理した
ことをステータスとして、フレーム１３７にＬＰＡＲ−
ＩＤ等といっしょに載せてサーバ＃０（１１０）に送
る。これらのフレーム１３６、１３７を受け取ることに
よりサーバはデータアクセスを完了する。図４の様なソ
フトウエア構造においてハイパバイザ４３０がデバイス
ドライバ４４０、４４１、４４２にＬＰＡＲ−ＩＤを設
定する方式は２通りある。一つは初期設定時にデバイス
ドライバ４４０、４４１に設定する方式である。ＯＳ４
２０、４２１とデバイスドライバ＃０（４４０）、＃１
（４４１）が一対一に対応している場合はＯＳにＬＰＡ
Ｒ−ＩＤが割り当てられた時に各デバイスドライバに来
るＩ／ＯのＬＰＡＲ−ＩＤも決まっているので、初期設
定時にハイパバイザ４３０よりＯＳ４２０、４２１、デ
バイスドライバ＃０（４４０）、＃１（４４１）がそれ
ぞれＬＰＡＲ−ＩＤ＃０、＃１（４５０、４５１）を受
け取り設定する。Ｉ／Ｏアクセス発生時にはデバイスド
ライバ＃０、＃１（４４０，４４１）は設定されたＬＰ
ＡＲ−ＩＤ＃０、＃１（４５０，４５１）をデータフレ
ーム１３０に設定する。２種類目はＩ／Ｏアクセス毎に
デバイスドライバ＃２（４４２）にＬＰＡＲ−ＩＤ＃２
／３（４５２）を連絡する方式である。ＯＳ４２２、４
２３はデバイスドライバ＃２（４４２）を共有している
ので実際にＩ／Ｏアクセスが発生するまでどちらのＯＳ
のＩ／Ｏアクセスなのか不明である。そのためＯＳがＩ
／Ｏアクセスをデバイスドライバ＃２（４４２）に発行
する際に、前もってハイパバイザより設定されたＬＰＡ
Ｒ−ＩＤ＃２／３（４５２）を同時にデバイスドライバ
４４２に送信する。受信したデバイスドライバ＃２（４
４２）はそのＬＰＡＲ−ＩＤ＃２／３（４５２）をデー
タフレーム１３０に設定する。以上のようにしてデータ
フレーム１３０にＬＰＡＲ−ＩＤ＃０、＃１、＃２、＃
３（４５０、４５１，４５２）が設定されると、同じＩ
／Ｏアダプタ１１８を共有している複数のＯＳ（４２
０、４２１、４２２、４２３）からＩ／Ｏアクセスが発
生した場合でも、ＬＰＡＲ−ＩＤ＃０、＃１、＃２、＃
３（４５０、４５１，４５２）が異なるため、上で述べ
た様にストレージ側でこれを識別することで排他／優先
制御を行うことが可能になる。図５に本発明の実施例１
におけるソフトウエア構造例とデータ転送失敗例を示
す。図５のようにデータフレーム１３０のＬＰＡＲ−Ｉ
Ｄがローカルメモリ１８０、または共有メモリ１８４に
ある排他／制御テーブル１８２、１８５内で論理ボリュ
ーム＃０（１９５）へのアクセスを許可されていない場
合、アクセスの結果は以下のようになる。アクセスが許
可されていないので、データ転送が正しく処理できずエ
ラーとなる。エラーが発生したことをステータスとし
て、フレーム１３８にＬＰＡＲ−ＩＤ等といっしょに載
せてサーバ＃０（１１０）に送る。このフレーム１３８
を受け取ることによりサーバは次に行うべきエラー処理
を判断することが可能になる。一般的にはこの後サーバ
側がディスク装置のエラー情報にアクセスして次の処理
を決定する。図４，５で示したサーバへのフレーム１３
７、１３８の返信は本発明のひとつの例であり、排他／
優先制御に関する他の情報を返信することが可能なこと
は明白である。図６に本発明の実施例１における排他/
優先制御テーブル例を示す。５００は例として論理ボリ
ューム＃０（１９５）の排他／優先制御テーブルを示し
ている。５０５、５１０、５１５、５２０は論理ボリュ
ーム＃０（１９５）アクセスする可能性があるWWNを示
す。５２５、５３０、５３５、５４０は各WWNを持つI／
Oアダプタからアクセスする可能性のあるＯＳのＬＰＡ
Ｒ−ＩＤを示す。この表で“○”で示されているＷＷ
Ｎ、ＬＰＡＲ−ＩＤは論理ボリューム＃０（１９５）に
アクセスが可能である。逆に“×”の場合論理ボリュー
ム＃０（１９５）にアクセスは排他される。この制御方
式は図１３に詳細を説明する。また排他制御＃２と書い
てあった場合は図１４で詳細を説明する排他制御方式に
従う。また優先制御と書いてあった場合は図１５で示す
優先制御方式に従う。ここで他の排他／優先制御を用い
る場合でもこの排他／優先制御テーブル５００に登録し
ておけば実現可能であることは自明である。排他／優先
制御テーブルは論理ボリューム毎に存在し、それらの集
合はローカルメモリ１８０、１８１、共有メモリ１８４
内に存在する（排他／優先制御テーブル１８２、１８
３、１８５）。そしてチャネルコントローラ１７５、１
７６はこれらの表を参照して排他／優先制御を行う。こ
れらの排他／優先制御テーブルはＬＡＮ１４５を通し
て、サーバ＃０、＃１（１１０、１２０）から送られる
制御フレーム４５５をテーブルセットプログラム４７０
が受信し、生成、変更することによってできる。制御フ
レーム４５５の詳細については図７で説明する。図７に
本発明の実施例１における制御フレーム構造例を示す。
制御フレーム構造例についてはＩＰ、ＵＤＰのプロトコ
ルを参考にしたものである。またメッセージ構造例につ
いてはＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａ
ｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を参考にしたも
のである。ローカルネットワークヘッダ６０５には、Ｌ
ＡＮ通信に必要なアドレス、データ長等の制御情報が格
納されている。ＩＰヘッダ６１０にはＩＰを使った通信
に必要なアドレス、データ長等の制御情報が格納されて
いる。ＵＤＰヘッダ６１５にはＵＤＰを使った通信に必
要なアドレス、データ長等の制御情報が格納されてい
る。ここで取り上げた以外のプロトコルを使っても本発
明の範囲であることは自明である。６２０はメッセージ
であり詳細については後で説明する。６２５はローカル
ネットワークトレイラであり、データのエラーチェック
のコード、データの終端のコード等が記述されている。
次にメッセージ６２０の構造例を示す。６３０はコマン
ドフィールドでありこのメッセージを使ってディスク装
置が行うべきことを示している。この例ではパラメータ
を排他／優先制御テーブルにセットする命令が入ってい
る。６３５はデータ長フィールドであり、以下のデータ
フィールドが何個続くかを示している。この例では６個
続くことを示している。６４０〜６６５まではデータフ
ィールドであり、排他／優先制御テーブルに設定すべき
パラメータが記述されている。この例では、論理ボリュ
ーム＃２（６４０）のＬＡＰＲ−ＩＤ＃２（６４５）か
つＷＷＮ＃１（６５０）のアクセスに関しては排他制御
＃２（６５５）を行い、その制約条件は最大排他処理時
間（６６０）と最大排他処理Ｉ／Ｏ数（６６５）である
ことを示している。データフィールドにはこのほかに優
先制御を行う際の優先順位等が入ることも考えられる。
図８に本発明の実施例１におけるサーバVPV制御初期化
のフロー示す。ここではサーバ＃０（１１０）側仮想プ
ライベートボリューム（ＶＰＶ）制御の初期化を行う。
ステップ７００からサーバＶＰＶ制御初期化が始まる。
ステップ７０５ではハイパバイザ４３０の初期化をまず
行う。ステップ７１０ではＬＰＡＲ−ＩＤ＃０（４５
０）、＃１（４５１）、＃２／３（４５２）を各ＬＰＡ
Ｒ（ＯＳ）に割り当てる。ステップ７１５では各ＬＰＡ
Ｒ内の特定エリアにＩＤを格納する。ステップ７２０で
はＯＳ４２０、４２１、４２２、４２３とデバイスドラ
イバ４４０、４４１、４４２を初期化して立ち上げる。
ステップ７２５ではＯＳ４２０、４２１、４２２、４２
３間でデバイスドライバ４４０、４４１、４４２を共用
しているかを調べる。もし共有していなければ（ＯＳ４
２０、４２１の場合）デバイスドライバ４４０、４４１
が各ＬＰＡＲが格納しているＬＰＡＲ−ＩＤ＃０（４５
０）、＃１（４５１）を取得する。デバイス４４０、４
４１、４４２を共有していれば（ＯＳ４２２、４２３の
場合）、ＯＳ４２２、４２３がＬＰＡＲ−ＩＤ＃２／３
（４５２）を取得する。ステップ７４０ではＬＰＡＲ−
ＩＤ＃０（４５０）、＃１（４５１）、＃２／３（４５
２）、論理ボリューム＃０、＃１（１９５，１９６）排
他／優先制御情報をディスク装置１７０に対して制御フ
レーム４５５を使って送信する。そしてステップ７４５
でサーバＶＰＶ制御初期化が終了する。図９に本発明の
実施例１におけるサーバ側I／O処理（デバイスドライバ
非共有）のフローチャート示す。ここでは初期化終了後
通常のＩ／Ｏ処理のフローを示す。またデバイスドライ
バはＯＳ間で共有しない。ステップ８００からサーバ側
Ｉ／Ｏ処理が開始される。ステップ８０５ではＯＳ４２
０、４２１にＩ／Ｏ処理が来ているかどうかを調べる。
もし来ていなければ、そのままステップ８０５に戻る。
Ｉ／Ｏ処理が来ていればステップ８１０に進み、ＯＳ４
２０、４２１がデバイスドライバ４４０、４４１用のシ
ステムコールを起動する。ステップ８１５ではデバイス
ドライバ４４０、４４１が起動する。ステップ８２０で
はデバイスドライバ４４０、４４１がデータフレーム１
３０に自分のＬＰＡＲ−ＩＤ＃０（４５０）、＃１（４
５１）を埋め込む。ステップ８３０ではディスク装置１
７０からデータフレームに対するステータスが返送され
たかどうかを調査する。返送していなければ、そのまま
ステップ８３０に戻る。ステータスが返送された場合、
ステップ８３５に進み、Ｉ／Ｏステータスが正常終了し
たかどうかを調べる。もし正常終了した場合はステップ
８０５に戻る。異常終了した場合、ステップ８４０に進
みエラー原因をディスク装置１７０に問い合わせる。ス
テップ８４５では問い合わせた結果を見て、サーバ＃０
（１１０）のエラー処理を行う。ステップ８５０ではＩ
／Ｏ処理の回復は不可能かどうか調べる。もし回復が可
能ならばステップ８０５に進む。不可能ならばステップ
８５５に進みサーバ側Ｉ／Ｏ処理を終了する。図１０に
本発明の実施例１におけるサーバ側I／O処理（デバイス
ドライバ共有）のフローチャートを示す。ここでは初期
化終了後通常のＩ／Ｏ処理のフローを示す。またデバイ
スドライバはＯＳ間で共有する。ステップ９００からサ
ーバ側Ｉ／Ｏ処理が開始される。ステップ９０５ではＯ
Ｓ４２２、４２３にＩ／Ｏ処理が来ているかどうかを調
べる。もし来ていなければ、そのままステップ９０５に
戻る。Ｉ／Ｏ処理が来ていればステップ９１０に進み、
ＯＳ４２２、４２３がデバイスドライバ４４２用のシス
テムコールを起動する。ステップ９１５ではＯＳ４２
２、４２３がデバイスドライバ４４２に対して自分のＬ
ＰＡＲ−ＩＤ＃２／３（４５２）を連絡する。ステップ
９２０ではデバイスドライバ４４２がデータフレーム１
３０に連絡されたのＬＰＡＲ−ＩＤ＃２／３（４５２）
を埋め込む。ステップ９３０以降は図９のステップ８３
０以降と同じなので以下説明を省略する。図１１に本発
明の実施例１におけるディスク装置VPV制御初期化のフ
ローチャートを示す。ここではディスク装置１７０側仮
想プライベートボリューム（ＶＰＶ）制御の初期化を行
う。ステップ１０００からディスク装置ＶＰＶ制御初期
化を開始する。ステップ１００５ではディスク装置１７
０の初期化を行う。ステップ１０１０ではＶＰＶ制御μ
プログラム立ち上げ、排他／優先制御テーブル１８２、
１８３、１８５の初期化を行う。ステップ１０１５では
サーバ＃０（１１０）より制御フレーム４５５を通し
て、ＬＰＡＲ−ＩＤ、論理ボリューム、排他／優先制御
に関する情報を受信する。受信なければ、ステップ１０
１５に戻る。受信した後、ステップ１０２０では排他／
優先制御テーブル１８２、１８３、１８５の設定を行
う。そしてステップ１０２５でディスク装置ＶＰＶ制御
初期化が終了する。図１２に本発明の実施例１における
ディスク装置側I／O処理フローチャートを示す。ここで
は初期化終了後ディスク装置１７０における通常のＩ／
Ｏ処理のフローを示す。ステップ１１００よりディスク
装置側Ｉ／Ｏ処理が開始される。ステップ１１０５では
Ｉ／Ｏアダプタ１７３、１７４にＩ／Ｏ処理が来ている
かどうかを調べる。もし来ていなければ、そのままステ
ップ１１０５に戻る。Ｉ／Ｏ処理が来ていればステップ
１１１０に進み、Ｉ／Ｏアダプタμプログラム４６１を
起動する。ステップ１１１５ではチャネルコントローラ
μプログラム４６２を起動する。ステップ１１２０では
コマンドに埋め込まれたＬＰＡＲ−ＩＤ３８０を抽出す
る。ステップ１１２５ではＩ／Ｏ処理対象の論理ボリュ
ーム３７０の排他／優先制御テーブル５００を参照す
る。ステップ１１３０ではＩ／ＯのＬＰＡＲ−ＩＤ３８
０、ＷＷＮ３３５を参照してそれが排他制御対象かどう
か調べる。排他制御対象でなければ、ステップ１１５０
の優先制御処理に進む。ステップ１１５０については図
１５で詳細を説明する。排他制御対象ならばステップ１
１３５に進む。ステップ１１３５については図１３、１
３で詳細を説明する。ステップ１１５０の優先制御処理
の後、ステップ１１３５で通常処理と判定された場合は
ステップ１１５５にてＩ／Ｏアクセス処理のキューに入
ってキャッシュメモリ１８６または磁気ディスク１９
１、１９２、１９３、１９４のＩ／Ｏ処理を待つ。ステ
ップ１１３５で排他処理と判定された場合はステップ１
１４０に進む。ステップ１１６０ではキューに入れたＩ
／Ｏの処理が正常に終わったかどうかを調べる。正常終
了した場合はステップ１１４５へ進む。異常終了した場
合はステップ１１４０へ進む。ステップ１１４０ではエ
ラーメッセージを作成してディスク装置１７０内に保存
する。ステップ１１４５はデータまたはステータスメッ
セージを作成して、サーバに返答する。その後ステップ
１１０５に戻る図１３に本発明の実施例１における第一
の排他制御処理例のフローチャートを示す。ここでは、
図１２のステップ１１３５の具体的な制御方式として、
一番単純な排他制御のフローを示す。ステップ１２００
より排他制御処理＃１が始まる。ステップ１２０５では
アクセスが排他されるべきかどうかを調べる。排他なら
ばステップ１２１５の排他処理へ進む。排他でなければ
ステップ１２０５の通常処理へ進む。図１４に本発明の
実施例１における第二の排他制御処理例のフローチャー
トを示す。ここでは、図１２のステップ１１３５の具体
的な制御方式として、処理時間、処理Ｉ／Ｏ数を条件と
した、制限付き排他制御のフローを示す。ステップ１３
００より排他制御処理＃２が始まる。ステップ１３０５
ではそれまでに排他処理を行った時間が、あらかじめ設
定してある最大排他処理時間（６６０）より少ないかど
うか調べる。少なければステップ１３１０へ進む。同じ
か、大きければステップ１３３５の通常処理へ進む。ス
テップ１３１０では排他処理時間を加算する。ステップ
１３１５ではそれまでに排他処理を行ったＩ／Ｏ数が、
あらかじめ設定してある最大排他処理Ｉ／Ｏ数（６６
５）より少ないかどうか調べる。少なければステップ１
３２０に進む。同じか、大きければステップ１３３５の
通常処理へ進む。ステップ１３２０では排他処理Ｉ／Ｏ
数の加算を行う。ステップ１３２５ではではアクセスが
排他されるべきかどうかを調べる。排他ならばステップ
１３３０の排他処理へ進む。排他でなければステップ１
３３５の通常処理へ進む。図１５に本発明の実施例１に
おける優先制御処理例のフローチャートを示す。ここで
は排他制御を行わず、処理の順番を変更するフローを示
す。この例はＳＣＳＩの標準規格のタグキューイングを
参考にしたものである。ステップ１４００から優先制御
処理が行われる。ステップ１４０５では処理するＩ／Ｏ
の処理順番を決めるためのポインタをキューの先頭にセ
ットする。ステップ１４１０では処理するＩ／Ｏの優先
順位を読み出す。ステップ１４１５ではキュー内のポイ
ンタの位置にＩ／Ｏがあるかどうかを調べる。なければ
ステップ１４３０へ進む。Ｉ／Ｏがあればステップ１４
２０に進みポインタ位置にあるキュー内Ｉ／Ｏの優先順
位を読み出す。ステップ１４２５ではキュウ内Ｉ／Ｏの
優先順位が処理するＩ／Ｏの優先順位より高いかどうか
を調べる。優先順位高ければステップ１４３５に進み、
ポインタを１加算して、ステップ１４１５に戻る。優先
順位が低ければステップ１４３０へ進む。ステップ１４
３０では処理するＩ／Ｏの順番を現時点でセットされた
ポインタの位置に決定する。ステップ１４４０では通常
処理へ進む。なお以上のフロー例以外の方式を使った排
他／優先制御処理も本発明の範囲であることは自明であ
る。以上図１から図１５までに示した実施例１によれ
ば、ＬＰＡＲ−ＩＤをデータフレームに入れてディスク
装置に送信し、受信したディスク装置側で排他制御を行
うことにより、Ｉ／Ｏアダプタを共有する複数のＯＳに
関しても排他制御を行うことが可能となる。またディス
ク装置側でＬＰＡＲ−ＩＤ、ＷＷＮを考慮した排他／優
先制御テーブルを持つことにより、サーバ間をまたがっ
たＯＳ等に関してもディスク装置側で統一的に排他／優
先制御を行うことが可能となる。また排他／優先制御方
式も複数の方式を選択できるようにしているので、柔軟
な排他制御、性能の最適化が可能となる。 （実施例２）以下、本発明に係るの実施例２を図面に示
しさらに詳細に説明する。
【０００８】図１６に本発明の実施例２におけるソフト
ウエア構造例を示す。実施例１では排他／優先制御はデ
ィスク装置１７０で行ったが、単体サーバ＃０（１１
０）の内部だけに制御を限定し、サーバ＃０（１１
０）、ハイパバイザ１５００の処理能力が高い場合は、
その他にハイパバイザ１５００行うことも可能である。
この場合、すべてのＩ／Ｏアクセスはハイパバイザ１５
００で受け取り、ハイパバイザ内に格納されているＬＰ
ＡＲ−ＩＤ１５１０とその優先／排他制御テーブル１５
５０を用いることで、排他／優先制御を行う。アクセス
が許可された場合Ｉ／Ｏアクセスはそのままディスク装
置１７０に送信され、アクセスが許可されない場合はそ
のままエラーでＯＳ（４２０）に返される。以上図１６
に示した実施例によればディスク装置１７０、データフ
レーム１４０に変更を加えることなく、ＯＳ間の排他／
優先制御を行うことが可能になる。 （実施例３）以下、本発明に係るの実施例３を図面に示
しさらに詳細に説明する。
ウエア構造例を示す。実施例１では排他／優先制御はデ
ィスク装置１７０で行ったが、単体サーバ＃０（１１
０）の内部だけに制御を限定し、サーバ＃０（１１
０）、ハイパバイザ１５００の処理能力が高い場合は、
その他にハイパバイザ１５００行うことも可能である。
この場合、すべてのＩ／Ｏアクセスはハイパバイザ１５
００で受け取り、ハイパバイザ内に格納されているＬＰ
ＡＲ−ＩＤ１５１０とその優先／排他制御テーブル１５
５０を用いることで、排他／優先制御を行う。アクセス
が許可された場合Ｉ／Ｏアクセスはそのままディスク装
置１７０に送信され、アクセスが許可されない場合はそ
のままエラーでＯＳ（４２０）に返される。以上図１６
に示した実施例によればディスク装置１７０、データフ
レーム１４０に変更を加えることなく、ＯＳ間の排他／
優先制御を行うことが可能になる。 （実施例３）以下、本発明に係るの実施例３を図面に示
しさらに詳細に説明する。
【０００９】図１７に本発明の実施例３におけるソフト
ウエア構造例を示す。実施例１、２では排他／優先制御
を行う単位は、ＬＰＡＲ−ＩＤを持つOS単位で行ってい
た。しかしユーザによっては、アプリケーション単位で
排他を行う必要がでてくる。同一OS内のアプリケーショ
ンならば、OSが排他／優先制御を行うことになるが、複
数OSにあるアプリケーション間で行うためには実施例
１、２と同様にディスク装置４６０またはハイパバイザ
４３０で排他／優先制御を行うことになる。たとえばア
プリケーション＃１（１６０５、１６１５ 以下アプリ
＃１と呼ぶ）のデータアクセスは優先したい場合、アプ
リ＃１（１６０５、１６１５）のアクセスが発生時にア
プリケーション毎にあるＩＤ（ＡＰＬ−ＩＤ）をＬＰＡ
Ｒ−ＩＤと同様にデータフレーム１６３５につけ、ディ
スク装置４６０に送信する。ディスク装置４６０側で
は、前もって受信した制御フレーム１６２０で伝えられ
排他／優先制御テーブル１６２５、１６３０に登録され
た、アプリケーション毎の排他／制御情報を元に排他／
優先制御を行う。アクセス結果はデータ１６４０、ステ
ータス１６４５によってサーバ＃０（１１０）に報告さ
れる。この結果として、ＬＰＡＲ−ＩＤ＃０（４５
０）、ＬＰＡＲ−ＩＤ＃２（４５２）によってアクセス
が排他されていない限り、アプリ＃１のデータアクセス
はＯＳにかかわらず優先される。
ウエア構造例を示す。実施例１、２では排他／優先制御
を行う単位は、ＬＰＡＲ−ＩＤを持つOS単位で行ってい
た。しかしユーザによっては、アプリケーション単位で
排他を行う必要がでてくる。同一OS内のアプリケーショ
ンならば、OSが排他／優先制御を行うことになるが、複
数OSにあるアプリケーション間で行うためには実施例
１、２と同様にディスク装置４６０またはハイパバイザ
４３０で排他／優先制御を行うことになる。たとえばア
プリケーション＃１（１６０５、１６１５ 以下アプリ
＃１と呼ぶ）のデータアクセスは優先したい場合、アプ
リ＃１（１６０５、１６１５）のアクセスが発生時にア
プリケーション毎にあるＩＤ（ＡＰＬ−ＩＤ）をＬＰＡ
Ｒ−ＩＤと同様にデータフレーム１６３５につけ、ディ
スク装置４６０に送信する。ディスク装置４６０側で
は、前もって受信した制御フレーム１６２０で伝えられ
排他／優先制御テーブル１６２５、１６３０に登録され
た、アプリケーション毎の排他／制御情報を元に排他／
優先制御を行う。アクセス結果はデータ１６４０、ステ
ータス１６４５によってサーバ＃０（１１０）に報告さ
れる。この結果として、ＬＰＡＲ−ＩＤ＃０（４５
０）、ＬＰＡＲ−ＩＤ＃２（４５２）によってアクセス
が排他されていない限り、アプリ＃１のデータアクセス
はＯＳにかかわらず優先される。
【００１０】図１８に本発明の実施例３における排他/
優先制御テーブル例を示す。実施例３ではアプリ毎に排
他／優先制御を判定するために、図６に比較してテーブ
ルが一種類増えることになる。１６２５−ａは排他／優
先制御テーブル例（ＷＷＮ−ＬＰＡＲ関係）で図６の排
他／優先制御テーブル５００と同様な形式である。１６
２５−ｂは排他／優先制御テーブル例（ＷＷＮ−ＡＰＬ
関係）であり、各ＷＷＮ（１７００〜１７１５）に対す
るＡＰＬ（１７２０〜１７３５）の排他／優先制御の有
無を示してある。
優先制御テーブル例を示す。実施例３ではアプリ毎に排
他／優先制御を判定するために、図６に比較してテーブ
ルが一種類増えることになる。１６２５−ａは排他／優
先制御テーブル例（ＷＷＮ−ＬＰＡＲ関係）で図６の排
他／優先制御テーブル５００と同様な形式である。１６
２５−ｂは排他／優先制御テーブル例（ＷＷＮ−ＡＰＬ
関係）であり、各ＷＷＮ（１７００〜１７１５）に対す
るＡＰＬ（１７２０〜１７３５）の排他／優先制御の有
無を示してある。
【００１１】図１９に本発明の実施例３におけるデータ
フレーム構造例を示す。基本的には図３のデータフレー
ム構造と同じであるが、ペイロード３１５内にアプリケ
ーションに関するＩＤとして、ＡＰＬ−ＩＤ（３９５）
が付け加えられている。
フレーム構造例を示す。基本的には図３のデータフレー
ム構造と同じであるが、ペイロード３１５内にアプリケ
ーションに関するＩＤとして、ＡＰＬ−ＩＤ（３９５）
が付け加えられている。
【００１２】図２０に本発明の実施例３における制御フ
レーム例を示す。基本的には図７の制御フレーム構造と
同じであるが、メッセージ６２０内のデータフィールド
にアプリケーションに関するＩＤとして、ＡＰＬ−ＩＤ
（６７０）が付け加えられている。以上図１７に示した
実施例によれば、図１３〜１４で示した排他／優先制御
処理のフローチャートと同様な方式で、異なるOSに存在
するアプリケーション間の排他／優先制御を行うことが
可能になる。
レーム例を示す。基本的には図７の制御フレーム構造と
同じであるが、メッセージ６２０内のデータフィールド
にアプリケーションに関するＩＤとして、ＡＰＬ−ＩＤ
（６７０）が付け加えられている。以上図１７に示した
実施例によれば、図１３〜１４で示した排他／優先制御
処理のフローチャートと同様な方式で、異なるOSに存在
するアプリケーション間の排他／優先制御を行うことが
可能になる。
【００１３】
【発明の効果】本発明によれば、複数OSがI／Oデバイス
を共有してディスク装置をアクセスするとき、OS、アプ
リケーション毎に付与された認識番号をディスク装置が
認識できるようになる。そのため、ディスク装置側での
OS、アプリケーション間のデータの排他制御が可能とな
りセキュリティを高めることができる。さらに、アクセ
スの優先制御も行うことが可能になり仮想プライベート
ボリュームシステム性能の最適化が図れる。
を共有してディスク装置をアクセスするとき、OS、アプ
リケーション毎に付与された認識番号をディスク装置が
認識できるようになる。そのため、ディスク装置側での
OS、アプリケーション間のデータの排他制御が可能とな
りセキュリティを高めることができる。さらに、アクセ
スの優先制御も行うことが可能になり仮想プライベート
ボリュームシステム性能の最適化が図れる。
【図面の簡単な説明】
【図１】本発明の実施例１における全体構成図を示す。
【図２】従来の排他制御方式内臓記憶装置の構成図を示
す。
す。
【図３】本発明の実施例１におけるデータフレーム構造
例を示す。
例を示す。
【図４】本発明の実施例１におけるソフトウエア構造例
とデータ転送成功例を示す。
とデータ転送成功例を示す。
【図５】本発明の実施例１におけるソフトウエア構造例
とデータ転送失敗例を示す。
とデータ転送失敗例を示す。
【図６】本発明の実施例１における排他/優先制御テー
ブル例を示す。
ブル例を示す。
【図７】本発明の実施例１における制御フレーム例を示
す。
す。
【図８】本発明の実施例１におけるサーバVPV制御初期
化のフロー示す。
化のフロー示す。
【図９】本発明の実施例１におけるサーバ側I／O処理
（デバイスドライバ非共有）のフローチャート示す。
（デバイスドライバ非共有）のフローチャート示す。
【図１０】本発明の実施例１におけるサーバ側I／O処理
（デバイスドライバ共有）のフローチャートを示す。
（デバイスドライバ共有）のフローチャートを示す。
【図１１】本発明の実施例１におけるディスク装置VPV
制御初期化のフローチャートを示す。
制御初期化のフローチャートを示す。
【図１２】本発明の実施例１におけるディスク装置側I
／O処理フローチャートを示す。
／O処理フローチャートを示す。
【図１３】本発明の実施例１における第一の排他制御処
理のフローチャートを示す。
理のフローチャートを示す。
【図１４】本発明の実施例１における第二の排他制御処
理のフローチャートを示す。
理のフローチャートを示す。
【図１５】本発明の実施例１における優先制御処理のフ
ローチャートを示す。
ローチャートを示す。
【図１６】本発明の実施例２におけるソフトウエア構造
例を示す。
例を示す。
【図１７】本発明の実施例３におけるソフトウエア構造
例を示す。
例を示す。
【図１８】本発明の実施例３における排他/優先制御テ
ーブル例を示す。
ーブル例を示す。
【図１９】本発明の実施例３におけるデータフレーム構
造例を示す。
造例を示す。
【図２０】本発明の実施例３における制御フレーム例を
示す。
示す。
１１０、１２０・・サーバ、１１１、１１２、１１３、
１１４、１２１、１２２、１２３、１２４・・ＣＰＵ、
１１５、１２５・・メインメモリ、１１６、１２６・・
ノードコントローラ、１１７、１２７・・ＬＡＮアダプ
タ、１１８、１２８、１７３、１７４・・Ｉ／Ｏアダプ
タ、１３０、１３５、１４０・・フレーム、１４５・・
ＬＡＮ、１５０、１５５、１６０・・ＯＳ、１７０・・
ディスク装置、１７１、１７２・・ＳＶＰ、１７５、１
７６・・チャネルコントローラ、１８０、１８１・・ロ
ーカルメモリ、１８２、１８３、１８５・・排他／優先
制御テーブル、１８４・・共有メモリ、１８６・・キャ
ッシュメモリ、１８７、１８８・・Ｄａｔａ、１９０・
・ディスクコントローラ、１９１、１９２、１９３、１
９４・・磁気ディスク、１９５、１９６・・論理ボリュ
ーム、１９７、１９８・・Ｉ／Ｏパス。
１１４、１２１、１２２、１２３、１２４・・ＣＰＵ、
１１５、１２５・・メインメモリ、１１６、１２６・・
ノードコントローラ、１１７、１２７・・ＬＡＮアダプ
タ、１１８、１２８、１７３、１７４・・Ｉ／Ｏアダプ
タ、１３０、１３５、１４０・・フレーム、１４５・・
ＬＡＮ、１５０、１５５、１６０・・ＯＳ、１７０・・
ディスク装置、１７１、１７２・・ＳＶＰ、１７５、１
７６・・チャネルコントローラ、１８０、１８１・・ロ
ーカルメモリ、１８２、１８３、１８５・・排他／優先
制御テーブル、１８４・・共有メモリ、１８６・・キャ
ッシュメモリ、１８７、１８８・・Ｄａｔａ、１９０・
・ディスクコントローラ、１９１、１９２、１９３、１
９４・・磁気ディスク、１９５、１９６・・論理ボリュ
ーム、１９７、１９８・・Ｉ／Ｏパス。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 小田原 宏明 東京都国分寺市東恋ケ窪一丁目280番地 株式会社日立製作所中央研究所内 Ｆターム(参考） 5B045 EE06 EE08 EE11 5B082 EA11 JA03
Claims (24)
- 【請求項１】複数のＯＳを識別する識別番号を付与され
たコマンドを受信し、前記識別番号を抽出し、前記コマ
ンドに対応した論理ボリュームへのアクセスを処理する
かまたはアクセスを拒否するかに相当するレスポンスを
前記識別番号に付与して返信することを特徴とするスト
レージシステム。 - 【請求項２】前記論理ボリュームは複数の磁気ディスク
装置から構成されることを特徴とする請求項１記載のス
トレージシステム。 - 【請求項３】前記受信したコマンドの識別番号に対応し
てアクセス処理の優先順位を変えることを特徴とする請
求項１または２記載のストレージシステム。 - 【請求項４】前記受信したコマンドのアクセスを処理す
るかまたはアクセスを拒否するかをあらかじめ設定した
条件に基づき判断し、前記レスポンスを返信することを
特徴とする請求項１乃至３記載のストレージシステム。 - 【請求項５】前記識別番号と前記コマンドのアクセスの
処理または拒否との関係を記憶したテーブルを有するこ
とを特徴とする請求項項１乃至４記載のストレージシス
テム。 - 【請求項６】前記受信したコマンドの複数の識別番号の
組み合わせに対応してレスポンスを返信することを特徴
とする請求項１乃至５記載のストレージシステム。 - 【請求項７】複数のＯＳを有し、前記ＯＳからのアクセ
ス要求があると当該ＯＳを識別する識別番号を付与し、
前記付与された識別番号を有するコマンドを送信するサ
ーバと、当該送信されたコマンドを受信するディスク装
置とを備え、前記ディスク装置は前記識別番号を抽出
し、前記抽出した識別番号に対応した論理ボリュームへ
のアクセスを処理するかまたはアクセスを拒否するかに
相当するレスポンスを前記識別番号を付与して返信し、
前記サーバは前記レスポンスを受信することを特徴とす
る仮想プライベートボリューム制御方法。 - 【請求項８】前記サーバは前記ＯＳを識別する識別番号
をデータフレームに書き込み、当該データフレームをコ
マンドとして送信し、前記ディスク装置は当該データフ
レームを受信して前記識別番号を抽出することを特徴と
する請求項７記載の仮想プライベートボリューム制御方
法。 - 【請求項９】前記受信したコマンドの識別番号に対応し
てアクセス処理の優先順位を変えることを特徴とする請
求項７または８記載の仮想プライベートボリューム制御
方法。 - 【請求項１０】前記受信したコマンドのアクセスを処理
するかまたはアクセスを拒否するかをあらかじめ設定し
た条件に基づき判断し、前記レスポンスを返信すること
を特徴とする請求項７乃至８記載の仮想プライベートボ
リューム制御方法。 - 【請求項１１】前記識別番号と前記コマンドのアクセス
の処理または拒否との関係を記憶したテーブルを有する
ことを特徴とする請求項７乃至１０記載の仮想プライベ
ートボリューム制御方法。 - 【請求項１２】複数ＯＳの少なくとも一つからアクセス
要求があると当該ＯＳを識別する識別番号を付与し、前
記付与された識別番号をサーバ内に記憶し、前記識別番
号に対応するレスポンスを受信し、当該レスポンスを前
記ＯＳへ返信することを特徴とするＯＳ管理ソフトプロ
グラム。 - 【請求項１３】複数のＯＳおよびアプリケーションを識
別する識別番号を付与されたコマンドを受信し、前記識
別番号を抽出し、前記コマンドに対応した論理ボリュー
ムへのアクセスを処理するかまたはアクセスを拒否する
かに相当するレスポンスを前記識別番号に付与して返信
することを特徴とするストレージシステム。 - 【請求項１４】前記論理ボリュームは複数の磁気ディス
ク装置から構成されることを特徴とする請求項１３記載
のストレージシステム。 - 【請求項１５】前記受信したコマンドの識別番号に対応
してアクセス処理の優先順位を変えることを特徴とする
請求項１３または１４記載のストレージシステム。 - 【請求項１６】前記受信したコマンドのアクセスを処理
するかまたはアクセスを拒否するかをあらかじめ設定し
た条件に基づき判断し、前記レスポンスを返信すること
を特徴とする請求項１３乃至１５記載のストレージシス
テム。 - 【請求項１７】前記識別番号と前記コマンドのアクセス
の処理または拒否との関係を記憶したテーブルを有する
ことを特徴とする請求項項１３乃至１６記載のストレー
ジシステム。 - 【請求項１８】前記受信したコマンドの複数の識別番号
の組み合わせに対応してレスポンスを返信することを特
徴とする請求項１乃至１７記載のストレージシステム。 - 【請求項１９】複数のアプリケーションおよびＯＳを有
し、前記アプリケーションおよびＯＳからのアクセス要
求があると当該アプリケーションおよびＯＳを識別する
識別番号を付与し、前記付与された識別番号を有するコ
マンドを送信するサーバと、当該送信されたコマンドを
受信するディスク装置とを備え、前記ディスク装置は前
記識別番号を抽出し、前記抽出した識別番号に対応した
論理ボリュームへのアクセスを処理するかまたはアクセ
スを拒否するかに相当するレスポンスを前記識別番号を
付与して返信し、前記サーバは前記レスポンスを受信す
ることを特徴とする仮想プライベートボリューム制御方
法。 - 【請求項２０】前記サーバは前記アプリケーションおよ
びＯＳを識別する識別番号をデータフレームに書き込
み、当該データフレームをコマンドとして送信し、前記
ディスク装置は当該データフレームを受信して前記識別
番号を抽出することを特徴とする請求項１９記載の仮想
プライベートボリューム制御方法。 - 【請求項２１】前記受信したコマンドの識別番号に対応
してアクセス処理の優先順位を変えることを特徴とする
請求項１９または２０記載の仮想プライベートボリュー
ム制御方法。 - 【請求項２２】前記受信したコマンドのアクセスを処理
するかまたはアクセスを拒否するかをあらかじめ設定し
た条件に基づき判断し、前記レスポンスを返信すること
を特徴とする請求項１９乃至２１記載の仮想プライベー
トボリューム制御方法。 - 【請求項２３】前記識別番号と前記コマンドのアクセス
の処理または拒否との関係を記憶したテーブルを有する
ことを特徴とする請求項１９乃至２２記載の仮想プライ
ベートボリューム制御方法。 - 【請求項２４】複数アプリケーションの少なくとも一つ
からアクセス要求があると当該アプリケーションおよび
ＯＳを識別する識別番号を付与し、前記付与された識別
番号をサーバ内に記憶し、前記識別番号に対応するレス
ポンスを受信し、当該レスポンスを前記アプリケーショ
ンおよびＯＳへ返信することを特徴とするアプリケーシ
ョンおよびＯＳ管理ソフトプログラム。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001016503A JP4087072B2 (ja) | 2001-01-25 | 2001-01-25 | ストレージシステム及び仮想プライベートボリューム制御方法 |
| EP01116444A EP1227389A3 (en) | 2001-01-25 | 2001-07-06 | Storage system and virtual private volume control method |
| US09/918,796 US6820168B2 (en) | 2001-01-25 | 2001-08-01 | Storage system and virtual private volume control method |
| US10/962,396 US7293147B2 (en) | 2001-01-25 | 2004-10-13 | Storage system controlling exclusion/priority for I/O access |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001016503A JP4087072B2 (ja) | 2001-01-25 | 2001-01-25 | ストレージシステム及び仮想プライベートボリューム制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002222110A true JP2002222110A (ja) | 2002-08-09 |
| JP4087072B2 JP4087072B2 (ja) | 2008-05-14 |
Family
ID=18882863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001016503A Expired - Fee Related JP4087072B2 (ja) | 2001-01-25 | 2001-01-25 | ストレージシステム及び仮想プライベートボリューム制御方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (2) | US6820168B2 (ja) |
| EP (1) | EP1227389A3 (ja) |
| JP (1) | JP4087072B2 (ja) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006209487A (ja) * | 2005-01-28 | 2006-08-10 | Hitachi Ltd | 計算機システム、計算機、ストレージ装置及び管理端末 |
| JP2008033449A (ja) * | 2006-07-26 | 2008-02-14 | Nec Corp | 入出力転送装置の共有方式、入出力転送装置の共有方法、及びプログラム |
| JP2008522279A (ja) * | 2004-11-25 | 2008-06-26 | ソフトキャンプ カンパニー リミテッド | アクセスが制御される仮想ディスク間のオンラインによるデータのセキュリティ伝送システムおよび、これを通じたセキュリティ伝送方法 |
| JP2008262566A (ja) * | 2008-04-14 | 2008-10-30 | Hitachi Ltd | データ処理システム |
| US7464188B2 (en) | 2003-03-31 | 2008-12-09 | Hitachi, Ltd. | Computer system controlling accesses to storage apparatus |
| US7519745B2 (en) | 2004-02-03 | 2009-04-14 | Hitachi, Ltd. | Computer system, control apparatus, storage system and computer device |
| US7610581B2 (en) | 2004-01-08 | 2009-10-27 | Hitachi, Ltd. | Data processing system |
| US7672863B2 (en) | 2003-03-31 | 2010-03-02 | Hitachi, Ltd. | System and method for load balancing based on service level objectives and information on the contents of start and finish processes of business services |
| JP2011108246A (ja) * | 2002-08-23 | 2011-06-02 | Finite State Machine Labs Inc | 管理オペレーティングシステムからネットワーク接続を監視及び制御するシステム、方法、及びコンピュータプログラム製品 |
| JP2011181080A (ja) * | 2011-04-01 | 2011-09-15 | Hitachi Ltd | データ処理システム |
| JP2013511104A (ja) * | 2009-11-16 | 2013-03-28 | マイクロソフト コーポレーション | ブロブとしての仮想ハードドライブ管理 |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7783727B1 (en) * | 2001-08-30 | 2010-08-24 | Emc Corporation | Dynamic host configuration protocol in a storage environment |
| JP4335516B2 (ja) * | 2001-12-04 | 2009-09-30 | パナソニック株式会社 | 複数のプロセッサを用いた動画像符号化装置およびその方法 |
| JP2004054721A (ja) * | 2002-07-23 | 2004-02-19 | Hitachi Ltd | ネットワークストレージ仮想化方法 |
| US6804753B1 (en) * | 2002-10-04 | 2004-10-12 | Crossroads Systems, Inc. | Partitioned library |
| JP2004164072A (ja) * | 2002-11-11 | 2004-06-10 | Hitachi Ltd | ディスク制御装置およびディスク制御装置の制御方法 |
| JP4567293B2 (ja) * | 2003-01-21 | 2010-10-20 | 株式会社日立製作所 | ファイルサーバ |
| US7512717B2 (en) * | 2003-01-21 | 2009-03-31 | Nextio Inc. | Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture |
| US7836211B2 (en) | 2003-01-21 | 2010-11-16 | Emulex Design And Manufacturing Corporation | Shared input/output load-store architecture |
| US7617333B2 (en) | 2003-01-21 | 2009-11-10 | Nextio Inc. | Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture |
| US8032659B2 (en) * | 2003-01-21 | 2011-10-04 | Nextio Inc. | Method and apparatus for a shared I/O network interface controller |
| US8102843B2 (en) * | 2003-01-21 | 2012-01-24 | Emulex Design And Manufacturing Corporation | Switching apparatus and method for providing shared I/O within a load-store fabric |
| US7457906B2 (en) * | 2003-01-21 | 2008-11-25 | Nextio, Inc. | Method and apparatus for shared I/O in a load/store fabric |
| US7188209B2 (en) * | 2003-04-18 | 2007-03-06 | Nextio, Inc. | Apparatus and method for sharing I/O endpoints within a load store fabric by encapsulation of domain information in transaction layer packets |
| US7664909B2 (en) * | 2003-04-18 | 2010-02-16 | Nextio, Inc. | Method and apparatus for a shared I/O serial ATA controller |
| US7493416B2 (en) * | 2003-01-21 | 2009-02-17 | Nextio Inc. | Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture |
| US7502370B2 (en) | 2003-01-21 | 2009-03-10 | Nextio Inc. | Network controller for obtaining a plurality of network port identifiers in response to load-store transactions from a corresponding plurality of operating system domains within a load-store architecture |
| US7698483B2 (en) | 2003-01-21 | 2010-04-13 | Nextio, Inc. | Switching apparatus and method for link initialization in a shared I/O environment |
| US7917658B2 (en) | 2003-01-21 | 2011-03-29 | Emulex Design And Manufacturing Corporation | Switching apparatus and method for link initialization in a shared I/O environment |
| US7219183B2 (en) * | 2003-01-21 | 2007-05-15 | Nextio, Inc. | Switching apparatus and method for providing shared I/O within a load-store fabric |
| US8346884B2 (en) | 2003-01-21 | 2013-01-01 | Nextio Inc. | Method and apparatus for a shared I/O network interface controller |
| US7174413B2 (en) * | 2003-01-21 | 2007-02-06 | Nextio Inc. | Switching apparatus and method for providing shared I/O within a load-store fabric |
| US7046668B2 (en) * | 2003-01-21 | 2006-05-16 | Pettey Christopher J | Method and apparatus for shared I/O in a load/store fabric |
| US7953074B2 (en) | 2003-01-21 | 2011-05-31 | Emulex Design And Manufacturing Corporation | Apparatus and method for port polarity initialization in a shared I/O device |
| US7103064B2 (en) | 2003-01-21 | 2006-09-05 | Nextio Inc. | Method and apparatus for shared I/O in a load/store fabric |
| US7523139B1 (en) | 2003-05-02 | 2009-04-21 | Symantec Operating Corporation | Volume server and volume owner communication protocol in a distributed storage management system |
| US7484043B2 (en) * | 2003-06-25 | 2009-01-27 | International Business Machines Corporation | Multiprocessor system with dynamic cache coherency regions |
| JP2005128781A (ja) * | 2003-10-23 | 2005-05-19 | Hitachi Ltd | 系切り替え方法及び情報処理システム |
| JP4391200B2 (ja) * | 2003-11-05 | 2009-12-24 | 株式会社日立製作所 | ディスクアレイ装置及びディスクアレイ装置の制御方法 |
| US7421519B2 (en) * | 2003-11-20 | 2008-09-02 | International Business Machines Corporation | Method for the detection of misdirected data |
| JP2005301708A (ja) | 2004-04-13 | 2005-10-27 | Hitachi Ltd | 記憶装置システムにおけるソフトウェア管理方法及び記憶装置システム |
| JP4230410B2 (ja) * | 2004-05-11 | 2009-02-25 | 株式会社日立製作所 | 仮想ストレージの通信品質制御装置 |
| JP2006011541A (ja) * | 2004-06-22 | 2006-01-12 | Hitachi Ltd | 計算機および共用記憶装置を含む計算機システムにおける情報記録方法 |
| JP4532237B2 (ja) * | 2004-10-29 | 2010-08-25 | 株式会社日立製作所 | 計算機および計算機におけるアクセス制御方法 |
| US20060136473A1 (en) * | 2004-12-20 | 2006-06-22 | Lamb James A | Service data organization |
| JP2006260075A (ja) * | 2005-03-16 | 2006-09-28 | Fujitsu Ltd | 識別情報設定装置、識別情報設定方法および識別情報設定プログラム |
| JP4987307B2 (ja) * | 2005-03-25 | 2012-07-25 | 株式会社日立製作所 | ストレージシステム |
| JP4831599B2 (ja) * | 2005-06-28 | 2011-12-07 | ルネサスエレクトロニクス株式会社 | 処理装置 |
| JP4725955B2 (ja) * | 2005-06-30 | 2011-07-13 | 株式会社リコー | 情報処理装置、メッセージ管理方法、プログラムおよび記憶媒体 |
| US20070180210A1 (en) * | 2006-01-31 | 2007-08-02 | Seagate Technology Llc | Storage device for providing flexible protected access for security applications |
| JP4731420B2 (ja) * | 2006-07-24 | 2011-07-27 | 株式会社日立製作所 | 複数の仮想計算機からのテープ媒体へのアクセスを制御する方法及びシステム |
| JP2008108227A (ja) * | 2006-09-25 | 2008-05-08 | Hitachi Ltd | ストレージシステム及び監査ログ管理方法 |
| JP2009266119A (ja) * | 2008-04-28 | 2009-11-12 | Hitachi Ltd | ストレージ装置及びデータ転送方法 |
| JP2010102458A (ja) * | 2008-10-22 | 2010-05-06 | Hitachi Ltd | コマンドの起動を制御するストレージシステム及び方法 |
| US8046460B1 (en) * | 2009-01-23 | 2011-10-25 | Hewlett-Packard Development Company, L.P. | Automatic server deployment using a pre-provisioned logical volume |
| US9229850B1 (en) * | 2009-06-30 | 2016-01-05 | Emc Corporation | Mapping data storage and virtual machines |
| US8667207B2 (en) * | 2009-09-30 | 2014-03-04 | Citrix Systems, Inc. | Dynamic reallocation of physical memory responsive to virtual machine events |
| US8826271B2 (en) * | 2010-04-28 | 2014-09-02 | Cavium, Inc. | Method and apparatus for a virtual system on chip |
| US9021472B2 (en) * | 2010-12-10 | 2015-04-28 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Virtualizing baseboard management controller operation |
| US8909896B2 (en) | 2011-03-01 | 2014-12-09 | Hitachi, Ltd. | Network efficiency for continuous remote copy |
| US9081507B2 (en) * | 2012-03-14 | 2015-07-14 | Symantec Corporation | Shared storage access management systems and methods |
| US20140317372A1 (en) * | 2013-04-23 | 2014-10-23 | Broadcom Corporation | Data frame security |
| US9898198B2 (en) * | 2015-06-12 | 2018-02-20 | International Business Machines Corporation | Available frame queue processing |
| US10037329B2 (en) | 2015-11-18 | 2018-07-31 | American Express Travel Related Services Company, Inc. | System and method for automatically capturing and recording lineage data for big data records |
| US10169601B2 (en) | 2015-11-18 | 2019-01-01 | American Express Travel Related Services Company, Inc. | System and method for reading and writing to big data storage formats |
| US10055471B2 (en) | 2015-11-18 | 2018-08-21 | American Express Travel Related Services Company, Inc. | Integrated big data interface for multiple storage types |
| US10445324B2 (en) | 2015-11-18 | 2019-10-15 | American Express Travel Related Services Company, Inc. | Systems and methods for tracking sensitive data in a big data environment |
| US10055426B2 (en) | 2015-11-18 | 2018-08-21 | American Express Travel Related Services Company, Inc. | System and method transforming source data into output data in big data environments |
| US10360394B2 (en) * | 2015-11-18 | 2019-07-23 | American Express Travel Related Services Company, Inc. | System and method for creating, tracking, and maintaining big data use cases |
| US10055444B2 (en) | 2015-12-16 | 2018-08-21 | American Express Travel Related Services Company, Inc. | Systems and methods for access control over changing big data structures |
| US10235211B2 (en) | 2016-04-22 | 2019-03-19 | Cavium, Llc | Method and apparatus for dynamic virtual system on chip |
| US11295326B2 (en) | 2017-01-31 | 2022-04-05 | American Express Travel Related Services Company, Inc. | Insights on a data platform |
| US11182086B2 (en) * | 2019-07-19 | 2021-11-23 | Cignet Technology, Inc. | Method and system for application-based management of user data storage rights |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5136582A (en) * | 1990-05-29 | 1992-08-04 | Advanced Micro Devices, Inc. | Memory management system and method for network controller |
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| JPH05120194A (ja) | 1991-10-29 | 1993-05-18 | Nec Eng Ltd | フアイル保護方式 |
| US5553305A (en) * | 1992-04-14 | 1996-09-03 | International Business Machines Corporation | System for synchronizing execution by a processing element of threads within a process using a state indicator |
| US5414851A (en) * | 1992-06-15 | 1995-05-09 | International Business Machines Corporation | Method and means for sharing I/O resources by a plurality of operating systems |
| DE69409445D1 (de) * | 1993-07-27 | 1998-05-14 | Ibm | Prozessüberwachung in einem Mehrfachverarbeitungsanbieter |
| US5483654A (en) * | 1993-09-15 | 1996-01-09 | Allen-Bradley Company, Inc. | Apparatus to select computer program for execution |
| US6192389B1 (en) * | 1997-03-28 | 2001-02-20 | International Business Machines Corporation | Method and apparatus for transferring file descriptors in a multiprocess, multithreaded client/server system |
| US6061753A (en) * | 1998-01-27 | 2000-05-09 | Emc Corporation | Apparatus and method of accessing target devices across a bus utilizing initiator identifiers |
| JP2000020367A (ja) | 1998-06-30 | 2000-01-21 | Toshiba Corp | 情報記憶方法および情報記憶装置および記録媒体 |
| JP2000020447A (ja) | 1998-07-07 | 2000-01-21 | Hitachi Ltd | 記憶サブシステム |
| JP3189894B2 (ja) | 1998-10-01 | 2001-07-16 | 日本電気株式会社 | 仮想計算機システム |
| US6453392B1 (en) * | 1998-11-10 | 2002-09-17 | International Business Machines Corporation | Method of and apparatus for sharing dedicated devices between virtual machine guests |
| JP3853540B2 (ja) * | 1999-06-30 | 2006-12-06 | 日本電気株式会社 | ファイバチャネル接続磁気ディスク装置およびファイバチャネル接続磁気ディスク制御装置 |
| US6343324B1 (en) * | 1999-09-13 | 2002-01-29 | International Business Machines Corporation | Method and system for controlling access share storage devices in a network environment by configuring host-to-volume mapping data structures in the controller memory for granting and denying access to the devices |
-
2001
- 2001-01-25 JP JP2001016503A patent/JP4087072B2/ja not_active Expired - Fee Related
- 2001-07-06 EP EP01116444A patent/EP1227389A3/en not_active Withdrawn
- 2001-08-01 US US09/918,796 patent/US6820168B2/en not_active Expired - Fee Related
-
2004
- 2004-10-13 US US10/962,396 patent/US7293147B2/en not_active Expired - Fee Related
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8805994B2 (en) | 2002-08-23 | 2014-08-12 | Intellectual Ventures Fund 73 Llc | System, method and computer program product for monitoring and controlling network connections from a supervisory operating system |
| US8713158B2 (en) | 2002-08-23 | 2014-04-29 | Intellectual Ventures Fund 73 Llc | System, method and computer program product for monitoring and controlling network connections from a supervisory operating system |
| JP2011108246A (ja) * | 2002-08-23 | 2011-06-02 | Finite State Machine Labs Inc | 管理オペレーティングシステムからネットワーク接続を監視及び制御するシステム、方法、及びコンピュータプログラム製品 |
| US7672863B2 (en) | 2003-03-31 | 2010-03-02 | Hitachi, Ltd. | System and method for load balancing based on service level objectives and information on the contents of start and finish processes of business services |
| US7464188B2 (en) | 2003-03-31 | 2008-12-09 | Hitachi, Ltd. | Computer system controlling accesses to storage apparatus |
| US8607214B2 (en) | 2004-01-08 | 2013-12-10 | Hitachi Ltd. | Data processing system running on a plurality of operating systems (OS) and enabling a channel device to simultaneously perform processing associated with the plurality of operating systems |
| US7610581B2 (en) | 2004-01-08 | 2009-10-27 | Hitachi, Ltd. | Data processing system |
| US8176211B2 (en) | 2004-02-03 | 2012-05-08 | Hitachi, Ltd. | Computer system, control apparatus, storage system and computer device |
| US7519745B2 (en) | 2004-02-03 | 2009-04-14 | Hitachi, Ltd. | Computer system, control apparatus, storage system and computer device |
| US8495254B2 (en) | 2004-02-03 | 2013-07-23 | Hitachi, Ltd. | Computer system having virtual storage apparatuses accessible by virtual machines |
| JP2008522279A (ja) * | 2004-11-25 | 2008-06-26 | ソフトキャンプ カンパニー リミテッド | アクセスが制御される仮想ディスク間のオンラインによるデータのセキュリティ伝送システムおよび、これを通じたセキュリティ伝送方法 |
| US7930511B2 (en) | 2005-01-28 | 2011-04-19 | Hitachi, Ltd. | Method and apparatus for management between virtualized machines and virtualized storage systems |
| JP2006209487A (ja) * | 2005-01-28 | 2006-08-10 | Hitachi Ltd | 計算機システム、計算機、ストレージ装置及び管理端末 |
| US8683172B2 (en) | 2005-01-28 | 2014-03-25 | Hitachi, Ltd. | Method and apparatus for management between virtualized machines and virtualized storage systems |
| US7783856B2 (en) | 2005-01-28 | 2010-08-24 | Hitachi, Ltd. | Method and apparatus for management between virtualized machines and virtualized storage systems |
| JP2008033449A (ja) * | 2006-07-26 | 2008-02-14 | Nec Corp | 入出力転送装置の共有方式、入出力転送装置の共有方法、及びプログラム |
| JP2008262566A (ja) * | 2008-04-14 | 2008-10-30 | Hitachi Ltd | データ処理システム |
| JP2013511104A (ja) * | 2009-11-16 | 2013-03-28 | マイクロソフト コーポレーション | ブロブとしての仮想ハードドライブ管理 |
| US10628086B2 (en) | 2009-11-16 | 2020-04-21 | Microsoft Technology Licensing, Llc | Methods and systems for facilitating communications with storage |
| JP2011181080A (ja) * | 2011-04-01 | 2011-09-15 | Hitachi Ltd | データ処理システム |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1227389A2 (en) | 2002-07-31 |
| EP1227389A3 (en) | 2007-01-03 |
| US20020099901A1 (en) | 2002-07-25 |
| US7293147B2 (en) | 2007-11-06 |
| JP4087072B2 (ja) | 2008-05-14 |
| US20050066125A1 (en) | 2005-03-24 |
| US6820168B2 (en) | 2004-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4087072B2 (ja) | ストレージシステム及び仮想プライベートボリューム制御方法 | |
| US6594698B1 (en) | Protocol for dynamic binding of shared resources | |
| US7313636B2 (en) | Methods and structure for supporting persistent reservations in a multiple-path storage environment | |
| JP4457185B2 (ja) | シリコンベースのストレージ仮想化サーバ | |
| US6044415A (en) | System for transferring I/O data between an I/O device and an application program's memory in accordance with a request directly over a virtual connection | |
| US6112263A (en) | Method for multiple independent processes controlling access to I/O devices in a computer system | |
| US6078990A (en) | Volume set configuration using a single operational view | |
| US10055264B2 (en) | Reception according to a data transfer protocol of data directed to any of a plurality of destination entities | |
| US6976083B1 (en) | Apparatus for providing direct data processing access using a queued direct input-output device | |
| US7543084B2 (en) | Method for destroying virtual resources in a logically partitioned data processing system | |
| JP4576398B2 (ja) | マルチパーティションコンピュータシステムのｉ／ｏデバイスを制御するためのシステム | |
| US20090089460A1 (en) | Storage device and storage device access control method | |
| JP4620776B2 (ja) | ネットワークに付属する物理的なポートの仮想インスタンスを管理するための方法およびシステム | |
| US20060195848A1 (en) | System and method of virtual resource modification on a physical adapter that supports virtual resources | |
| US20090043886A1 (en) | OPTIMIZING VIRTUAL INTERFACE ARCHITECTURE (VIA) ON MULTIPROCESSOR SERVERS AND PHYSICALLY INDEPENDENT CONSOLIDATED VICs | |
| US9298658B2 (en) | Using PCI-E extended configuration space to send IOCTLS to a PCI-E adapter | |
| JP2004506980A (ja) | コンピュータネットワークを介してブロックレベルストレージアクセスを提供するためのアーキテクチャ | |
| CN101124541A (zh) | 修改逻辑分区数据处理系统中的虚拟适配器资源 | |
| TW200522583A (en) | IP-based method and apparatus for booting computers remotely in wide-area-network environment | |
| US6397350B1 (en) | Method of providing direct data processing access using a queued direct input-output device | |
| US7761529B2 (en) | Method, system, and program for managing memory requests by devices | |
| US6401145B1 (en) | Method of transferring data using an interface element and a queued direct input-output device | |
| CN117834561A (zh) | 基于spdk的网络i/o处理方法以及装置 | |
| US20050165938A1 (en) | Method, system, and program for managing shared resources | |
| CN101310262B (zh) | 能使多个通信信道独立工作的集成电路 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040825 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070803 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20070803 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070823 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20071001 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071011 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071101 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071227 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080116 |
|
| 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: 20080213 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080220 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| 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: 20110228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140228 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |