JP4087072B2 - ストレージシステム及び仮想プライベートボリューム制御方法 - Google Patents
ストレージシステム及び仮想プライベートボリューム制御方法 Download PDFInfo
- Publication number
- JP4087072B2 JP4087072B2 JP2001016503A JP2001016503A JP4087072B2 JP 4087072 B2 JP4087072 B2 JP 4087072B2 JP 2001016503 A JP2001016503 A JP 2001016503A JP 2001016503 A JP2001016503 A JP 2001016503A JP 4087072 B2 JP4087072 B2 JP 4087072B2
- Authority
- JP
- Japan
- Prior art keywords
- identifying
- identification number
- control
- exclusive
- oss
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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)
Description
【０００１】
【発明の属する技術分野】
本発明は、サーバおよび記憶装置技術に関し、特に複数の記憶装置、ＣＰＵなどの構成要素を接続し、高いセキュリティ能力、高い応答性能、トランザクション数が要求される情報処理装置、記憶装置に有効な技術に関する。
【０００２】
【従来の技術】
複数のＣＰＵ、メモリとＩ／Ｏアダプタを持つサーバと大容量のディスク装置を組み合わせ、複数のユーザでそれら資源を共用する環境が現実になってくるに従って、各ユーザのセキュリティを守り、効率的に資源を使うことが要求されてきている。従来のサーバ及びディスク装置においては、論理ボリュームの排他制御を行うためにサーバに内蔵しているＩ／Ｏアダプタ毎に識別番号を持ちそれをストレージ側で区別する方式が採用されている。図２に従来のサーバ、ディスク装置構成例を示す。ここでサーバ＃０（１１０）とサーバ＃１（１２０）はそれぞれ複数のＯＳ＃０（１５５）〜ＯＳ＃２（１２０）を内蔵している。またＩ／Ｏアダプタ１１８、１２８を持ちストレージ１７０に接続している。ストレージ１７０にアクセスする場合データフレーム１３０、１３５、１４０をＩ／Ｏアダプタ１１８、１２８より発行する。データフレーム１３０、１３５、１４０の記述内容の中にはＷｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ（ＷＷＮ）（２０５、２１５、２２５）がありＩ／Ｏアダプタ１１８、１２８毎に固有の認識番号をそこに書きこむ。一方ディスク装置１７０ではＩ／Ｏアダプタ１７３、１７４を持ち上記データフレーム１３０、１３５、１４０を受信する。ディスク装置１７０で内部制御を行うチャネルコントローラ１７５、１７６は受信したデータフレーム１３０、１３５、１４０から識別番号であるＷＷＮ２０５、２１５、２２５を抽出する。そしてチャネルコントローラ１７５、１７６はＷＷＮ２０５、２１５、２２５とローカルメモリ１８０、１８１にあらかじめ登録されている排他／優先制御テーブル１８２、１８３を比較することで論理ボリューム１９５、１９６に対するアクセスの排他／優先制御を行う。例えばサーバ＃０（１１０）のＯＳ＃２（１５０）が論理ボリューム＃０（１９５）を所有し、サーバ＃１（１２０）のＯＳ＃１（１６０）が論理ボリューム＃１（１９６）を所有していることを仮定する。ここで誤ってＯＳ＃１（１６０）が論理ボリューム＃０（１９５）をアクセスした場合、このアクセスのデータフレーム１４０のＷＷＮ２２５には識別番号００１があるので、チャネルコントローラ１７６は排他／優先制御テーブル１８３を参照し、識別番号０００しかアクセスが許可されていないことがわかる。そこでチャネルコントローラ１７６はＯＳ＃１（１６０）に対してアクセスが拒否されたことを伝える。このような論理ボリュームの排他／優先制御を備えたディスク装置の技術については、特開２０００-２０４４７号に開示された「記憶サブシステム」等がある。
【０００３】
一方サーバ内に複数の資源が存在する場合それらを複数のＯＳで分割して使う技術が存在する。この技術を用いることで、サーバのＣＰＵ、メモリ等を効率よく利用することが可能になってきている。これらの技術の一例としてＬＰＡＲ（Ｌｏｇｉｃａｌ ＰＡＲＴｉｏｎｉｎｇ）がある。これを用いた場合、複数のＯＳを管理するソフトウエアプログラムとしてハイパバイザ４３０が存在することにより、動的にＯＳに，ＣＰＵ、メモリ、Ｉ／Ｏデバイスを割り当てることが可能となる。例えば図２のサーバ＃１（１２０）では、ＣＰＵ＃１０〜＃１３と４個あるので、ＬＰＡＲを用いることでＯＳ＃０（１５５）にはＣＰＵ＃１０を割り当て、ＯＳ＃１（１６０）にはＣＰＵ＃１１、＃１２、＃１３（１２２、１２３、１２４）を割り当てることができる。メインメモリ１２５についても容量を適当な割合でＯＳ＃０（１５５）、ＯＳ＃１（１６０）に割り当てることができる。Ｉ／Ｏアダプタが複数ある場合はＯＳ＃０（１５５）、ＯＳ＃１（１６０）に割り当てることができるがこの例では１個しかないので、Ｉ／Ｏアダプタ１２８は両ＯＳで共有することになる。このような技術については、特開平１０-３０１７９５号に開示された「仮想計算機システム」等がある。
また、特開２０００−１１２８０４号には、複数のＯＳがファイルを共用して動作する仮想計算機システムにおいて、１つのＯＳが他のＯＳのデータファイルをアクセスすることを防止するため、ＯＳ番号が付されたＩ／Ｏ命令をディスク装置に対して発行することが記載されている。また、特開平４−１４０８４４号には、ＯＳが発行したＩ／Ｏ命令を解析するＩ／Ｏ解析手段を有し、Ｉ／Ｏ解析手段では引き取ったＩ／Ｏ命令にＯＳ識別子を付加し、複数ＯＳを同時動作させたときに排他制御することが記載されている。
【０００４】
【発明が解決しようとする課題】
以上に述べたように，ＷＷＮ２０５、２１５、２２５をディスク装置１７０で識別することによって論理ボリューム１９５、１９６の排他／優先制御を行うことが可能となる。またＬＰＡＲを用いることでサーバ内複数のＯＳに対して，ＣＰＵ、メモリ、Ｉ／Ｏデバイスを効率よく割り当てることが可能になる。しかし一般にサーバ内ＣＰＵ数の増加の割合に対して、Ｉ／Ｏデバイスの数はそれほど多く増加せず、ＣＰＵ間で共有する場合が多い。これはコストを削減とＩ／Ｏデバイスが外部へのＩ／Ｆを持つことによる物理的な大きさのためである。このような状況で論理ボリュームの排他／優先制御を行う場合、以下のように排他／優先制御が出来なくなる問題がある。例えば、図２のサーバ＃１（１２０）ではＯＳ＃０（１５５）とＯＳ＃１（１６０）が同じサーバ内に存在し、Ｉ／Ｏアダプタ１２８を共有して使うことになる。しかし両ＯＳから発行するデータフレーム１３５、１４０のＷＷＮ２１５、２２５はＩ／Ｏアダプタ１２８を共有するため同じ識別番号“００１”が付けられる。よってディスク装置１７０ではこの２個のデータフレームについて排他／優先制御は行うことができない。よってＯＳ＃０（１５５）が論理ボリューム＃０（１９５）を所有、他のＯＳにアクセスすることを許可しない場合でも、上記理由によりＯＳ＃１（１６０）は論理ボリューム＃０（１９５）にアクセスすることが可能となってしまう。
本発明の主たる目的は、サーバ内の複数ＯＳがＩ／Ｏデバイスとストレージシステムを共有する場合に、各ＯＳに固有な識別情報をサーバ側で付加、ディスク装置側で抽出する手段をつけることにより各ＯＳ毎に所有する論理ボリュームの排他／優先制御を行う技術を改良することにある。
本発明のさらに別の目的は、ディスク装置に排他／優先制御方法を記述したテーブルを設置し、複数の排他／優先制御方法から選択し実行する技術を提供することにある。
本発明のさらに別の目的は、サーバからディスク装置に対して、各ＯＳ毎に複数の排他／優先制御方式をディスク装置に対して命令する技術を提供することにある。
【０００５】
【課題を解決するための手段】
上記問題を解決するために、複数のＯＳを有し、前記ＯＳからのアクセス要求があると当該ＯＳを識別する識別番号を付与し、前記付与された識別番号を有するコマンドを送信するサーバと、当該送信されたコマンドを受信するディスク装置とを備え、前記ディスク装置は前記識別番号を抽出し、前記抽出した識別番号に対応した論理ボリュームへのアクセスを処理するかまたはアクセスを拒否するかに相当するレスポンスを前記識別番号を付与して返信し、前記サーバは前記レスポンスを受信する仮想プライベートボリューム制御方法とする。また、サーバにＯＳ毎の識別番号をディスク装置アクセス時に発行するデータフレーム内に書き込む手段をおく。また、ディスク装置の中で上記ＯＳ毎の識別番号を抽出し、それを元にアクセスの排他／優先制御を行う手段をおく。さらにサーバからディスク装置にＯＳ毎にアクセス可能な論理ボリュームまたは排他／優先制御情報を送る手段をおく。さらにディスク装置に上記ＯＳ毎にアクセス可能な論理ボリュームまたは排他／優先制御情報を格納するテーブルをおく。
ここで、複数のＯＳとは、ＯＳユーザーが異なる場合などの、仮想的に異なる複数のＯＳであればよく、同種のＯＳ（例えばＯＳ＃０が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 Area 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 Check）であり、データフレーム３００内のデータの誤りを発見し訂正を行う。３２５は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がI／Oデバイスを共有してディスク装置をアクセスするとき、OS、アプリケーション毎に付与された認識番号をディスク装置が認識できるようになる。そのため、ディスク装置側でのOS、アプリケーション間のデータの排他制御が可能となりセキュリティを高めることができる。さらに、アクセスの優先制御も行うことが可能になり仮想プライベートボリュームシステム性能の最適化が図れる。
【図面の簡単な説明】
【図１】本発明の実施例１における全体構成図を示す。
【図２】従来の排他制御方式内臓記憶装置の構成図を示す。
【図３】本発明の実施例１におけるデータフレーム構造例を示す。
【図４】本発明の実施例１におけるソフトウエア構造例とデータ転送成功例を示す。
【図５】本発明の実施例１におけるソフトウエア構造例とデータ転送失敗例を示す。
【図６】本発明の実施例１における排他/優先制御テーブル例を示す。
【図７】本発明の実施例１における制御フレーム例を示す。
【図８】本発明の実施例１におけるサーバVPV制御初期化のフロー示す。
【図９】本発明の実施例１におけるサーバ側I／O処理（デバイスドライバ非共有）のフローチャート示す。
【図１０】本発明の実施例１におけるサーバ側I／O処理（デバイスドライバ共有）のフローチャートを示す。
【図１１】本発明の実施例１におけるディスク装置VPV制御初期化のフローチャートを示す。
【図１２】本発明の実施例１におけるディスク装置側I／O処理フローチャートを示す。
【図１３】本発明の実施例１における第一の排他制御処理のフローチャートを示す。
【図１４】本発明の実施例１における第二の排他制御処理のフローチャートを示す。
【図１５】本発明の実施例１における優先制御処理のフローチャートを示す。
【図１６】本発明の実施例２におけるソフトウエア構造例を示す。
【図１７】本発明の実施例３におけるソフトウエア構造例を示す。
【図１８】本発明の実施例３における排他/優先制御テーブル例を示す。
【図１９】本発明の実施例３におけるデータフレーム構造例を示す。
【図２０】本発明の実施例３における制御フレーム例を示す。
【符号の説明】
１１０、１２０・・サーバ、１１１、１１２、１１３、１１４、１２１、１２２、１２３、１２４・・ＣＰＵ、１１５、１２５・・メインメモリ、１１６、１２６・・ノードコントローラ、１１７、１２７・・ＬＡＮアダプタ、１１８、１２８、１７３、１７４・・Ｉ／Ｏアダプタ、１３０、１３５、１４０・・フレーム、１４５・・ＬＡＮ、１５０、１５５、１６０・・ＯＳ、１７０・・ディスク装置、１７１、１７２・・ＳＶＰ、１７５、１７６・・チャネルコントローラ、１８０、１８１・・ローカルメモリ、１８２、１８３、１８５・・排他／優先制御テーブル、１８４・・共有メモリ、１８６・・キャッシュメモリ、１８７、１８８・・Ｄａｔａ、１９０・・ディスクコントローラ、１９１、１９２、１９３、１９４・・磁気ディスク、１９５、１９６・・論理ボリューム、１９７、１９８・・Ｉ／Ｏパス。
【発明の属する技術分野】
本発明は、サーバおよび記憶装置技術に関し、特に複数の記憶装置、ＣＰＵなどの構成要素を接続し、高いセキュリティ能力、高い応答性能、トランザクション数が要求される情報処理装置、記憶装置に有効な技術に関する。
【０００２】
【従来の技術】
複数のＣＰＵ、メモリとＩ／Ｏアダプタを持つサーバと大容量のディスク装置を組み合わせ、複数のユーザでそれら資源を共用する環境が現実になってくるに従って、各ユーザのセキュリティを守り、効率的に資源を使うことが要求されてきている。従来のサーバ及びディスク装置においては、論理ボリュームの排他制御を行うためにサーバに内蔵しているＩ／Ｏアダプタ毎に識別番号を持ちそれをストレージ側で区別する方式が採用されている。図２に従来のサーバ、ディスク装置構成例を示す。ここでサーバ＃０（１１０）とサーバ＃１（１２０）はそれぞれ複数のＯＳ＃０（１５５）〜ＯＳ＃２（１２０）を内蔵している。またＩ／Ｏアダプタ１１８、１２８を持ちストレージ１７０に接続している。ストレージ１７０にアクセスする場合データフレーム１３０、１３５、１４０をＩ／Ｏアダプタ１１８、１２８より発行する。データフレーム１３０、１３５、１４０の記述内容の中にはＷｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ（ＷＷＮ）（２０５、２１５、２２５）がありＩ／Ｏアダプタ１１８、１２８毎に固有の認識番号をそこに書きこむ。一方ディスク装置１７０ではＩ／Ｏアダプタ１７３、１７４を持ち上記データフレーム１３０、１３５、１４０を受信する。ディスク装置１７０で内部制御を行うチャネルコントローラ１７５、１７６は受信したデータフレーム１３０、１３５、１４０から識別番号であるＷＷＮ２０５、２１５、２２５を抽出する。そしてチャネルコントローラ１７５、１７６はＷＷＮ２０５、２１５、２２５とローカルメモリ１８０、１８１にあらかじめ登録されている排他／優先制御テーブル１８２、１８３を比較することで論理ボリューム１９５、１９６に対するアクセスの排他／優先制御を行う。例えばサーバ＃０（１１０）のＯＳ＃２（１５０）が論理ボリューム＃０（１９５）を所有し、サーバ＃１（１２０）のＯＳ＃１（１６０）が論理ボリューム＃１（１９６）を所有していることを仮定する。ここで誤ってＯＳ＃１（１６０）が論理ボリューム＃０（１９５）をアクセスした場合、このアクセスのデータフレーム１４０のＷＷＮ２２５には識別番号００１があるので、チャネルコントローラ１７６は排他／優先制御テーブル１８３を参照し、識別番号０００しかアクセスが許可されていないことがわかる。そこでチャネルコントローラ１７６はＯＳ＃１（１６０）に対してアクセスが拒否されたことを伝える。このような論理ボリュームの排他／優先制御を備えたディスク装置の技術については、特開２０００-２０４４７号に開示された「記憶サブシステム」等がある。
【０００３】
一方サーバ内に複数の資源が存在する場合それらを複数のＯＳで分割して使う技術が存在する。この技術を用いることで、サーバのＣＰＵ、メモリ等を効率よく利用することが可能になってきている。これらの技術の一例としてＬＰＡＲ（Ｌｏｇｉｃａｌ ＰＡＲＴｉｏｎｉｎｇ）がある。これを用いた場合、複数のＯＳを管理するソフトウエアプログラムとしてハイパバイザ４３０が存在することにより、動的にＯＳに，ＣＰＵ、メモリ、Ｉ／Ｏデバイスを割り当てることが可能となる。例えば図２のサーバ＃１（１２０）では、ＣＰＵ＃１０〜＃１３と４個あるので、ＬＰＡＲを用いることでＯＳ＃０（１５５）にはＣＰＵ＃１０を割り当て、ＯＳ＃１（１６０）にはＣＰＵ＃１１、＃１２、＃１３（１２２、１２３、１２４）を割り当てることができる。メインメモリ１２５についても容量を適当な割合でＯＳ＃０（１５５）、ＯＳ＃１（１６０）に割り当てることができる。Ｉ／Ｏアダプタが複数ある場合はＯＳ＃０（１５５）、ＯＳ＃１（１６０）に割り当てることができるがこの例では１個しかないので、Ｉ／Ｏアダプタ１２８は両ＯＳで共有することになる。このような技術については、特開平１０-３０１７９５号に開示された「仮想計算機システム」等がある。
また、特開２０００−１１２８０４号には、複数のＯＳがファイルを共用して動作する仮想計算機システムにおいて、１つのＯＳが他のＯＳのデータファイルをアクセスすることを防止するため、ＯＳ番号が付されたＩ／Ｏ命令をディスク装置に対して発行することが記載されている。また、特開平４−１４０８４４号には、ＯＳが発行したＩ／Ｏ命令を解析するＩ／Ｏ解析手段を有し、Ｉ／Ｏ解析手段では引き取ったＩ／Ｏ命令にＯＳ識別子を付加し、複数ＯＳを同時動作させたときに排他制御することが記載されている。
【０００４】
【発明が解決しようとする課題】
以上に述べたように，ＷＷＮ２０５、２１５、２２５をディスク装置１７０で識別することによって論理ボリューム１９５、１９６の排他／優先制御を行うことが可能となる。またＬＰＡＲを用いることでサーバ内複数のＯＳに対して，ＣＰＵ、メモリ、Ｉ／Ｏデバイスを効率よく割り当てることが可能になる。しかし一般にサーバ内ＣＰＵ数の増加の割合に対して、Ｉ／Ｏデバイスの数はそれほど多く増加せず、ＣＰＵ間で共有する場合が多い。これはコストを削減とＩ／Ｏデバイスが外部へのＩ／Ｆを持つことによる物理的な大きさのためである。このような状況で論理ボリュームの排他／優先制御を行う場合、以下のように排他／優先制御が出来なくなる問題がある。例えば、図２のサーバ＃１（１２０）ではＯＳ＃０（１５５）とＯＳ＃１（１６０）が同じサーバ内に存在し、Ｉ／Ｏアダプタ１２８を共有して使うことになる。しかし両ＯＳから発行するデータフレーム１３５、１４０のＷＷＮ２１５、２２５はＩ／Ｏアダプタ１２８を共有するため同じ識別番号“００１”が付けられる。よってディスク装置１７０ではこの２個のデータフレームについて排他／優先制御は行うことができない。よってＯＳ＃０（１５５）が論理ボリューム＃０（１９５）を所有、他のＯＳにアクセスすることを許可しない場合でも、上記理由によりＯＳ＃１（１６０）は論理ボリューム＃０（１９５）にアクセスすることが可能となってしまう。
本発明の主たる目的は、サーバ内の複数ＯＳがＩ／Ｏデバイスとストレージシステムを共有する場合に、各ＯＳに固有な識別情報をサーバ側で付加、ディスク装置側で抽出する手段をつけることにより各ＯＳ毎に所有する論理ボリュームの排他／優先制御を行う技術を改良することにある。
本発明のさらに別の目的は、ディスク装置に排他／優先制御方法を記述したテーブルを設置し、複数の排他／優先制御方法から選択し実行する技術を提供することにある。
本発明のさらに別の目的は、サーバからディスク装置に対して、各ＯＳ毎に複数の排他／優先制御方式をディスク装置に対して命令する技術を提供することにある。
【０００５】
【課題を解決するための手段】
上記問題を解決するために、複数のＯＳを有し、前記ＯＳからのアクセス要求があると当該ＯＳを識別する識別番号を付与し、前記付与された識別番号を有するコマンドを送信するサーバと、当該送信されたコマンドを受信するディスク装置とを備え、前記ディスク装置は前記識別番号を抽出し、前記抽出した識別番号に対応した論理ボリュームへのアクセスを処理するかまたはアクセスを拒否するかに相当するレスポンスを前記識別番号を付与して返信し、前記サーバは前記レスポンスを受信する仮想プライベートボリューム制御方法とする。また、サーバにＯＳ毎の識別番号をディスク装置アクセス時に発行するデータフレーム内に書き込む手段をおく。また、ディスク装置の中で上記ＯＳ毎の識別番号を抽出し、それを元にアクセスの排他／優先制御を行う手段をおく。さらにサーバからディスク装置にＯＳ毎にアクセス可能な論理ボリュームまたは排他／優先制御情報を送る手段をおく。さらにディスク装置に上記ＯＳ毎にアクセス可能な論理ボリュームまたは排他／優先制御情報を格納するテーブルをおく。
ここで、複数のＯＳとは、ＯＳユーザーが異なる場合などの、仮想的に異なる複数のＯＳであればよく、同種のＯＳ（例えばＯＳ＃０が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 Area 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 Check）であり、データフレーム３００内のデータの誤りを発見し訂正を行う。３２５は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がI／Oデバイスを共有してディスク装置をアクセスするとき、OS、アプリケーション毎に付与された認識番号をディスク装置が認識できるようになる。そのため、ディスク装置側でのOS、アプリケーション間のデータの排他制御が可能となりセキュリティを高めることができる。さらに、アクセスの優先制御も行うことが可能になり仮想プライベートボリュームシステム性能の最適化が図れる。
【図面の簡単な説明】
【図１】本発明の実施例１における全体構成図を示す。
【図２】従来の排他制御方式内臓記憶装置の構成図を示す。
【図３】本発明の実施例１におけるデータフレーム構造例を示す。
【図４】本発明の実施例１におけるソフトウエア構造例とデータ転送成功例を示す。
【図５】本発明の実施例１におけるソフトウエア構造例とデータ転送失敗例を示す。
【図６】本発明の実施例１における排他/優先制御テーブル例を示す。
【図７】本発明の実施例１における制御フレーム例を示す。
【図８】本発明の実施例１におけるサーバVPV制御初期化のフロー示す。
【図９】本発明の実施例１におけるサーバ側I／O処理（デバイスドライバ非共有）のフローチャート示す。
【図１０】本発明の実施例１におけるサーバ側I／O処理（デバイスドライバ共有）のフローチャートを示す。
【図１１】本発明の実施例１におけるディスク装置VPV制御初期化のフローチャートを示す。
【図１２】本発明の実施例１におけるディスク装置側I／O処理フローチャートを示す。
【図１３】本発明の実施例１における第一の排他制御処理のフローチャートを示す。
【図１４】本発明の実施例１における第二の排他制御処理のフローチャートを示す。
【図１５】本発明の実施例１における優先制御処理のフローチャートを示す。
【図１６】本発明の実施例２におけるソフトウエア構造例を示す。
【図１７】本発明の実施例３におけるソフトウエア構造例を示す。
【図１８】本発明の実施例３における排他/優先制御テーブル例を示す。
【図１９】本発明の実施例３におけるデータフレーム構造例を示す。
【図２０】本発明の実施例３における制御フレーム例を示す。
【符号の説明】
１１０、１２０・・サーバ、１１１、１１２、１１３、１１４、１２１、１２２、１２３、１２４・・ＣＰＵ、１１５、１２５・・メインメモリ、１１６、１２６・・ノードコントローラ、１１７、１２７・・ＬＡＮアダプタ、１１８、１２８、１７３、１７４・・Ｉ／Ｏアダプタ、１３０、１３５、１４０・・フレーム、１４５・・ＬＡＮ、１５０、１５５、１６０・・ＯＳ、１７０・・ディスク装置、１７１、１７２・・ＳＶＰ、１７５、１７６・・チャネルコントローラ、１８０、１８１・・ローカルメモリ、１８２、１８３、１８５・・排他／優先制御テーブル、１８４・・共有メモリ、１８６・・キャッシュメモリ、１８７、１８８・・Ｄａｔａ、１９０・・ディスクコントローラ、１９１、１９２、１９３、１９４・・磁気ディスク、１９５、１９６・・論理ボリューム、１９７、１９８・・Ｉ／Ｏパス。
Claims (16)
- 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムであって、
前記ディスク装置は、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出し、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較し、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断する
ことを特徴とするストレージシステム。 - 前記優先制御では、前記ディスク装置のキュー内に前記サーバからのＩ／Ｏを処理する処理順番を決定するためのポインタの位置にＩ／Ｏがある場合に、前記ポインタの位置にある前記キュー内のＩ／Ｏの優先順位と、現時点で処理対象のＩ／Ｏの優先順位とを比較して、前記キュー内のＩ／Ｏの優先順位が前記現時点で処理対象のＩ／Ｏの優先順位より低い場合には前記現時点で設定されたポインタの位置を処理対象の順番として変更することで、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する
ことを特徴とする請求項１に記載のストレージシステム。 - 前記排他制御では、排他制御を行った時間が予め設定する最大排他処理時間より少ない場合であり、かつ、排他制御を行ったＩ／Ｏ数が最大排他処理Ｉ／Ｏ数より少ない場合に、抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を前記排他／優先制御情報と比較することで前記論理ボリュームへのアクセス拒否を行うか否かを判断する
ことを特徴とする請求項１又は２に記載のストレージシステム。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムであって、
前記サーバは、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出し、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較し、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断する
ことを特徴とするストレージシステム。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置であって、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出し、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較し、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断する
ことを特徴とするディスク装置。 - 前記優先制御では、前記ディスク装置のキュー内に前記サーバからのＩ／Ｏを処理する処理順番を決定するためのポインタの位置にある前記キュー内のＩ／Ｏの優先順位と、現時点で処理対象のＩ／Ｏの優先順位とを比較して、前記キュー内のＩ／Ｏの優先順位が前記便時点で処理対象のＩ／Ｏの優先順位より低い場合には前記現時点で設定されたポインタの位置を処理対象の順番として変更することで、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する
ことを特徴とする請求項５に記載のディスク装置。 - 前記排他制御では、排他制御を行った時間が予め設定する最大排他処理時間より少ない場合であり、かつ、排他制御を行ったＩ／Ｏ数が最大排他処理Ｉ／Ｏ数より少ない場合に、抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を前記排他／優先制御情報と比較することで前記論理ボリュームへのアクセス拒否を行うか否かを判断する
ことを特徴とする請求項５又は６に記載のディスク装置。 - 複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と接続し、複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバであって、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出し、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較し、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断する
ことを特徴とするサーバ。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムの制御方法であって、
前記ディスク装置では、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出するステップと、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較するステップと、
一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断するステップと、を有する
ことを特徴とするストレージシステムの制御方法。 - 前記優先制御では、前記ディスク装置のキュー内に前記サーバからのＩ／Ｏを処理する処理順番を決定するためのポインタの位置にＩ／Ｏがある場合に、前記ポインタの位置にある前記キュー内のＩ／Ｏの優先順位と、現時点で処理対象のＩ／Ｏの優先順位とを比較して、前記キュー内のＩ／Ｏの優先順位が前記現時点で処理対象のＩ／Ｏの優先順位より低い場合には前記現時点で設定されたポインタの位置を処理対象の順番として変更することで、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定するステップである
ことを特徴とする請求項９に記載のストレージシステムの制御方法。 - 前記排他制御では、排他制御を行った時間が予め設定する最大排他処理時間より少ない場合であり、かつ、排他制御を行ったＩ／Ｏ数が最大排他処理Ｉ／Ｏ数より少ない場合に、抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を前記排他／優先制御情報と比較することで前記論理ボリュームへのアクセス拒否を行うか否かを判断するステップである
ことを特徴とする請求項９又は１０に記載のストレージシステムの制御方法。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムであって、
前記サーバでは、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出するステップと、
抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較するステップと、
一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行するように判断するステップと、を有する
ことを特徴とするストレージシステムの制御方法。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムのプログラムであって、
前記ディスク装置に、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出させ、
抽出させた前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較させ、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行させるように判断させる
ことを特徴とするストレージシステムのプログラム。 - 前記ディスク装置に、前記優先制御として、前記ディスク装置のキュー内に前記サーバからのＩ／Ｏを処理する処理順番を決定するためのポインタの位置にＩ／Ｏがある場合に、前記ポインタの位置にある前記キュー内のＩ／Ｏの優先順位と、現時点で処理対象のＩ／Ｏの優先順位とを比較させて、前記キュー内のＩ／Ｏの優先順位が前記現時点で処理対象のＩ／Ｏの優先順位より低い場合には前記現時点で設定されたポインタの位置を処理対象の順番として変更させることで、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定させる
ことを特徴とする請求項１３に記載のストレージシステムのプログラム。 - 前記ディスク装置に、前記排他制御として、排他制御を行った時間が予め設定する最大排他処理時間より少ない場合であり、かつ、排他制御を行ったＩ／Ｏ数が最大排他処理Ｉ／Ｏ数より少ない場合に、抽出した前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を前記排他／優先制御情報と比較させることで前記論理ボリュームへのアクセス拒否を行うか否かを判断させる
ことを特徴とする請求項１３又は１４に記載のストレージシステムのプログラム。 - 複数のＯＳ又は複数のアプリケーションと、データの転送を制御する複数のＩ／Ｏアダプタと、を有する複数のサーバと、
前記複数のサーバと接続し、複数の記憶装置上に形成される複数の論理ボリュームを有するディスク装置と、を備えたストレージシステムのプログラムであって、
前記サーバに、
前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号が設定されたデータフレームから、前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号を抽出させ、
抽出させた前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、各論理ボリュームに対して設定され、かつ、前記論理ボリュームへのアクセス拒否を行う排他制御、前記論理ボリュームに対してデータの読み書きを行うための優先順位を決定する優先制御、又は、前記論理ボリュームに対してデータの読み書きを行う通常制御、のいずれかを実行するための制御情報が格納される排他／優先制御情報内に予め設定される前記複数のＯＳ又は複数のアプリケーションを識別するための識別番号及び前記複数のＩ／Ｏアダプタを識別するための識別番号と、が一致するか否かを比較させ、一致する場合に前記制御情報に従って排他制御、優先制御、又は通常制御を実行させるように判断させる
ことを特徴とするストレージシステムのプログラム。
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 JP2002222110A (ja) | 2002-08-09 |
| JP4087072B2 true 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) |
Families Citing this family (73)
| 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 | ネットワークストレージ仮想化方法 |
| US6782424B2 (en) * | 2002-08-23 | 2004-08-24 | Finite State Machine Labs, Inc. | System, method and computer program product for monitoring and controlling network connections from a supervisory operating system |
| US6804753B1 (en) * | 2002-10-04 | 2004-10-12 | Crossroads Systems, Inc. | Partitioned library |
| JP2004164072A (ja) * | 2002-11-11 | 2004-06-10 | Hitachi Ltd | ディスク制御装置およびディスク制御装置の制御方法 |
| 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 |
| 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 |
| US8032659B2 (en) * | 2003-01-21 | 2011-10-04 | Nextio Inc. | Method and apparatus for a shared I/O network interface controller |
| US7219183B2 (en) * | 2003-01-21 | 2007-05-15 | Nextio, Inc. | Switching apparatus and method for providing shared I/O within a load-store fabric |
| 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 |
| 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 |
| JP4567293B2 (ja) * | 2003-01-21 | 2010-10-20 | 株式会社日立製作所 | ファイルサーバ |
| 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 |
| 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 |
| US8346884B2 (en) * | 2003-01-21 | 2013-01-01 | Nextio Inc. | Method and apparatus for a shared I/O network interface controller |
| US7103064B2 (en) * | 2003-01-21 | 2006-09-05 | Nextio Inc. | 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 |
| US7457906B2 (en) * | 2003-01-21 | 2008-11-25 | Nextio, Inc. | Method and apparatus for shared I/O in a load/store fabric |
| US7836211B2 (en) * | 2003-01-21 | 2010-11-16 | Emulex Design And Manufacturing Corporation | Shared input/output load-store architecture |
| US7664909B2 (en) * | 2003-04-18 | 2010-02-16 | Nextio, Inc. | Method and apparatus for a shared I/O serial ATA controller |
| US7698483B2 (en) * | 2003-01-21 | 2010-04-13 | Nextio, Inc. | Switching apparatus and method for link initialization in a shared I/O environment |
| 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 |
| 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 |
| JP4077352B2 (ja) | 2003-03-31 | 2008-04-16 | 株式会社日立製作所 | 負荷分散方法及びその実施システム並びにその処理プログラム |
| JP4380198B2 (ja) | 2003-03-31 | 2009-12-09 | 株式会社日立製作所 | ストレージ装置でアクセス制御を行う計算機システム |
| US7389394B1 (en) | 2003-05-02 | 2008-06-17 | Symantec Operating Corporation | System and method for performing snapshots in a storage environment employing distributed block virtualization |
| 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 |
| JP4333370B2 (ja) | 2004-01-08 | 2009-09-16 | 株式会社日立製作所 | データ処理システム |
| JP4227035B2 (ja) | 2004-02-03 | 2009-02-18 | 株式会社日立製作所 | 計算機システム、管理装置、ストレージ装置及びコンピュータ装置 |
| 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 | 株式会社日立製作所 | 計算機および計算機におけるアクセス制御方法 |
| KR100589541B1 (ko) * | 2004-11-25 | 2006-06-14 | 소프트캠프(주) | 접근이 통제되는 가상디스크들 간의 온라인을 통한데이터의 보안전송시스템과 이를 통한 보안전송방법 |
| US20060136473A1 (en) * | 2004-12-20 | 2006-06-22 | Lamb James A | Service data organization |
| JP4733399B2 (ja) * | 2005-01-28 | 2011-07-27 | 株式会社日立製作所 | 計算機システム、計算機、ストレージ装置及び管理端末 |
| 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 | 株式会社日立製作所 | 複数の仮想計算機からのテープ媒体へのアクセスを制御する方法及びシステム |
| JP4983133B2 (ja) * | 2006-07-26 | 2012-07-25 | 日本電気株式会社 | 入出力制御装置およびその制御方法、並びにプログラム |
| JP2008108227A (ja) * | 2006-09-25 | 2008-05-08 | Hitachi Ltd | ストレージシステム及び監査ログ管理方法 |
| JP4623126B2 (ja) * | 2008-04-14 | 2011-02-02 | 株式会社日立製作所 | データ処理システム |
| 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 |
| WO2011041615A1 (en) * | 2009-09-30 | 2011-04-07 | Citrix Systems, Inc. | Dynamic reallocation of physical memory responsive to virtual machine events |
| US8516137B2 (en) * | 2009-11-16 | 2013-08-20 | Microsoft Corporation | Managing virtual hard drives as blobs |
| 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 |
| JP4894963B2 (ja) * | 2011-04-01 | 2012-03-14 | 株式会社日立製作所 | データ処理システム |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| US10055471B2 (en) | 2015-11-18 | 2018-08-21 | American Express Travel Related Services Company, Inc. | Integrated big data interface for multiple storage types |
| 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
Also Published As
| Publication number | Publication date |
|---|---|
| US6820168B2 (en) | 2004-11-16 |
| EP1227389A3 (en) | 2007-01-03 |
| US7293147B2 (en) | 2007-11-06 |
| JP2002222110A (ja) | 2002-08-09 |
| US20050066125A1 (en) | 2005-03-24 |
| EP1227389A2 (en) | 2002-07-31 |
| US20020099901A1 (en) | 2002-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4087072B2 (ja) | ストレージシステム及び仮想プライベートボリューム制御方法 | |
| JP4457185B2 (ja) | シリコンベースのストレージ仮想化サーバ | |
| US6594698B1 (en) | Protocol for dynamic binding of shared resources | |
| US7428581B2 (en) | Architecture for providing block-level storage access over a computer network | |
| US7313636B2 (en) | Methods and structure for supporting persistent reservations in a multiple-path storage environment | |
| US7865588B2 (en) | System for providing multi-path input/output in a clustered data storage network | |
| US8719817B2 (en) | Virtualization intermediary/virtual machine guest operating system collaborative SCSI path management | |
| US6907457B2 (en) | Architecture for access to embedded files using a SAN intermediate device | |
| 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 | |
| US8677034B2 (en) | System for controlling I/O devices in a multi-partition computer system | |
| US8904050B1 (en) | Techniques for automated data storage system port initialization | |
| US7953878B1 (en) | Multi-threaded internet small computer system interface (iSCSI) socket layer | |
| TW200925878A (en) | System and method for management of an IOV adapter through a virtual intermediary in an IOV management partition | |
| GB2366048A (en) | Selecting a preferred path to a storage device | |
| US9298658B2 (en) | Using PCI-E extended configuration space to send IOCTLS to a PCI-E adapter | |
| TW200522583A (en) | IP-based method and apparatus for booting computers remotely in wide-area-network environment | |
| US10872036B1 (en) | Methods for facilitating efficient storage operations using host-managed solid-state disks and devices thereof | |
| US8677094B2 (en) | Storage system, release method, and secondary storage apparatus | |
| JP2008083788A (ja) | ネットワーク通信装置、ネットワークシステム及びフレーム転送方法 | |
| JP4948938B2 (ja) | クロスパーティションコマンドを認定する為の方法と装置 | |
| JP2008186211A (ja) | 計算機システム | |
| US9065740B2 (en) | Prioritising data processing operations | |
| US8417858B2 (en) | System and method for enabling multiple processors to share multiple SAS wide ports | |
| US11100027B1 (en) | Storage device protocol dual personality | |
| US20190361824A1 (en) | I/o control method and i/o control system |
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 |