JP4318914B2 - ストレージシステム及びその動的負荷管理方法 - Google Patents
ストレージシステム及びその動的負荷管理方法 Download PDFInfo
- Publication number
- JP4318914B2 JP4318914B2 JP2002377977A JP2002377977A JP4318914B2 JP 4318914 B2 JP4318914 B2 JP 4318914B2 JP 2002377977 A JP2002377977 A JP 2002377977A JP 2002377977 A JP2002377977 A JP 2002377977A JP 4318914 B2 JP4318914 B2 JP 4318914B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- load
- host
- command
- storage device
- 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/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
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
- G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
-
- 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/061—Improving I/O performance
- G06F3/0611—Improving I/O performance in relation to response time
-
- 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/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
- G06F3/0689—Disk arrays, e.g. RAID, JBOD
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2206/00—Indexing scheme related to dedicated interfaces for computers
- G06F2206/10—Indexing scheme related to storage interfaces for computers, indexing schema related to group G06F3/06
- G06F2206/1012—Load balancing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、磁気デイスク等のストレージ装置を使用してデータの入出力を行うストレージシステム及びその動的負荷管理方法に関し、特に、入出力コマンドの処理量を管理して、コマンド処理の滞留を防止するためのストレージシステム及びその動的負荷管理方法に関する。
【０００２】
【従来の技術】
磁気デイスク、光磁気デイスク、光デイスク等の記憶媒体を利用したストレージ装置では、データ処理装置の要求で、記憶媒体を実アクセスする。データ処理装置が、大容量のデータを使用する場合には、複数のストレージ機器と制御装置とを備えたストレージシステムを利用する。
【０００３】
このようなストレージシステムでは、大量のアクセスに対し、システム内でリソース配分をダイナミックに最適化し、上位装置からのアクセスに対し、安定な性能を実現するＤＴＣ（Dynamic Traffic Control）機能を備えている。図１９は、従来技術の構成図、図２０は、従来技術の説明図である。
【０００４】
図１９に示すように、ストレージコントローラ１００は、ホストＩ／Ｏコマンドに応じて、複数のストレージ装置（磁気デイスク装置）１１０をアクセス制御する。このストレージコントローラ１００は、コマンド処理機能１０２、ＤＴＣ機能１０４、デイスクドライバ１０６、デバイスアダプタ１０８を有する。コマンド処理機能１０２は、ホストＩ／Ｏコマンドと内部Ｉ／Ｏコマンドを受ける。
【０００５】
内部Ｉ／Ｏコマンドは、ホストＩ／Ｏのバックグラウンドで実行するＩ／Ｏ制御であり、例えば、ホストからの連続ブロック群のコピー指示に応じて、ホストＩ／Ｏのバックグラウンドで、順次コピーを行うＯＰＣ（One Point Copy）や、ＲＡＩＤ再構築のリビルドや、データバックアップのためのコピーバック等がある。
【０００６】
ＤＴＣ機能１０４は、ドライバ１０６、デバイスアダプタ１０８を介しストレージ装置１１０に発行するコマンド数を制御する。図２０に示すように、従来技術では、ＤＴＣ機能１０４は、各コマンドの応答時間（ストレージ装置１１０へのコマンド発行からストレージ装置１１０から応答を受けるまでの時間）を測定し、応答時間の平均を計算し、この平均応答時間が、所定時間より早い場合には、単位時間の発行コマンド数を増加し、所定時間より遅い場合には、単位時間の発行コマンド数を減少する。決定された発行コマンド数を越えたコマンドは、キュー待ちする。
【０００７】
コマンド処理機能１０２は、ホストＩ／Ｏ(ランダム、シーケンシャル）の受け入れ制限を付けず、優先して処理し、ＤＴＣ１０４に渡す。内部Ｉ／Ｏは、ホストＩ／Ｏのバックグラウンドで処理し、ＤＴＣ１０４に渡す。ＤＴＣ１０４は、ドライバ１０６、デバイスアダプタ１０８を介し、ストレージ装置１１０に発行コマンド数を越えない数のコマンドを発行する。
【０００８】
このように、ＤＴＣ１０４は、ストレージ装置１１０のレスポンス時間に応じて、起動数（コマンド数）を動的に変更し、Ｉ／Ｏコマンドの実行の最適化を行っていた。
【０００９】
【発明が解決しようとする課題】
従来技術では、ホストＩ／Ｏを全て受け入れているため、システム性能以上のホストＩ／Ｏを受け付けた場合には、内部のタイムアウト時間（例えば、２５秒）内に、ホストＩ／Ｏを実行できず、ホストにタイムアウトで返答していた。このため、ホストは、このＩ／Ｏ要求の実行待ちの状態が長くなり、且つタイムアウトに応じて、その時点で再度、ホストＩ／Ｏを発する必要があった。
【００１０】
又、ＯＰＣ等の内部Ｉ／Ｏが、コマンド処理部１０２で、内部バッファ領域の排他権（Extent排他という）を獲得したまま、ＤＴＣ１０４で待たされることがあり、後発のホストＩ／Ｏコマンドが、Extent排他を獲得できず、スリープし、最悪の場合には、内部のタイムアウトが同様に発生してしまうという問題もあった。
【００１１】
更に、従来のＤＴＣが、過去のストレージ装置（デイスク装置）からのレスポンス時間のみで新たな起動数を決定しているため、一時的にデイスク装置からのレスポンスの遅延が発生した場合には、デイスク装置への新たなコマンド発行を必要以上に絞ってしまうという問題もあり、ストレージ装置の性能をフルに使用することが困難であった。
【００１２】
従って、本発明の目的は、ホストＩ／Ｏの受け付けを調整して、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１３】
又、本発明の他の目的は、システム性能以上のホストＩ／Ｏのコマンド処理の受け付けを抑止し、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１４】
更に、本発明の他の目的は、Ｅｘｔｅｎｔ排他前に負荷管理を行い、ホストＩ／Ｏ処理を妨げずに、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１５】
更に、本発明の他の目的は、ストレージ装置に着目した流量管理を行い、ハード性能以上のストレージ装置へのコマンド発行を抑止し、ストレージ装置の性能をフルに使用するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１６】
【課題を解決するための手段】
この目的の達成のため、本発明のストレージシステムは、複数のストレージ装置と、前記複数のストレージ装置をアクセスするためのデバイスアダプターと、前記ストレージ装置のデータの一部を保持するキャッシュメモリと、ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求に応じたコマンド処理を実行し、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行処理を実行するコントローラとを有し、前記コントローラは、前記ホストＩ／Ｏ要求を解読し、解読結果により、前記キャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理を実行し、前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行処理を実行し、前記コントローラは、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止する。
【００１７】
本発明の動的システム負荷管理方法は、コントローラが、ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求を解読し、解読結果により、複数の前記ストレージ装置のデータの一部を保持するキャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理ステップと、前記コントローラが、前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行ステップと、前記コントローラが、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算するシステム負荷計算ステップと、前記コントローラが、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップとを有する。
【００１８】
本発明では、従来、ホストＩ／Ｏ要求を管理していないかったが、ストレージシステムのシステム負荷を越えるホストＩ／Ｏ要求に対しては、ホストＩ／Ｏ要求を処理せず、エラー応答し、ホストにコマンドのリトライを行わせるようにした。これにより、システム内でのコマンド処理の停滞を抑止する。又、システム負荷を、アクセス実行前と後との両方の負荷から計算するため、正確にシステム自体の負荷を管理できる。
【００１９】
又、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整し、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行部を起動する。これにより、内部資源獲得前に、Ｉ／Ｏ要求の調整を行うことができ、ホストＩ／Ｏの処理を妨げずに、より早く、タイムアウトエラーの発生を防止できる。
【００２０】
又、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御モジュールと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御モジュールとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせる。
【００２１】
これにより、ホストＩ／Ｏの調整と、内部Ｉ／Ｏの調整を別に分けたので、ホストＩ／Ｏ要求を妨げることなく、内部Ｉ／Ｏ要求を早期に実行できる。
【００２２】
更に、本発明では、好ましくは、前記コマンド処理部は、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得る。
【００２３】
これにより、アクセス実行部でのハード使用量が不確定な段階で、予測負荷を予測できる。
【００２４】
更に、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御する。これにより、内部Ｉ／Ｏ要求を、早期に処理できる。
【００２５】
更に、本発明では、好ましくは、前記コマンド処理部は、前記実際の負荷に応じて、前記アクセス実行部のコマンド処理量を制御する。これにより、アクセス実行部のハード性能以上のコマンド発行を抑止でき、ストレージ装置のタイムアウトを防止できる。
【００２６】
更に、本発明では、前記コマンド処理部は、ハードウェアで規定される前記アクセス実行部の単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測する。これにより、負荷予測が可能となり、且つ精度も高い。
【００２７】
更に、本発明では、前記ストレージ装置のデータの一部を保持するキャッシュメモリを更に設け、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止する。
【００２８】
キャッシュヒットのＩ／Ｏ要求を除外することにより、より正確な、ホストＩ／Ｏ要求の管理が可能となる。
【００２９】
更に、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロントモジュールと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御モジュールと、前記ＩＯ制御モジュールで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドモジュールとを有する。
【００３０】
これにより、コマンド処理の流れの中で、容易に、ホストＩ／Ｏ要求の管理が可能となる。
【００３１】
更に、本発明では、好ましくは、前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測する流量予測モジュールと、前記アクセス実行部の実際の負荷を管理する実負荷管理モジュールと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計モジュールとを有する。これにより、システム負荷の計算を高速且つ容易に実行できる。
【００３２】
【発明の実施の形態】
以下、本発明の実施の形態を、ストレージシステム、動的システム負荷管理構成、システム負荷管理、動的システム負荷制御、閾値調整処理、他の実施の形態の順で説明する。
【００３３】
［ストレージシステム］
図１は、本発明の一実施の形態のストレージシステムの構成図であり、磁気デイスクを使用したＲＡＩＤ（Redundant Arrays of Inexpensive Disk)システムを示す。図１に示すように、ストレージシステムは、一対の磁気デイスクコントローラ（以下、コントローラという）１、２と、この一対のコントローラ１、２にＦＣ＿ＡＬ（Fiber Channel Arbitrated Loop）４−１，４−２で接続された多数のデバイスエンクロージャー５−１〜５−８とからなる。
【００３４】
このデバイスエンクロージャー５−１〜５−８の各々は、１５台の磁気デイスク装置（ストレージ装置）５０を内蔵する。各磁気デイスク装置５０は、一対のＦＣ＿ＡＬ４−１、４−２に接続される。
【００３５】
コントローラ１、２は、直接又はネットワーク機器を介し、クライアントやサーバー等のホスト３に接続され、ホスト３の大量のデータを、ＲＡＩＤデイスクドライブ（磁気デイスク装置）へ高速かつ、ランダムに読み書きが出来るシステムである。
【００３６】
一対のコントローラ１、２は、同一の構成を有する。従って、コントローラ１の構成を説明し、コントローラ２の構成の説明は省略する。コントローラ１は、ＣＡ（Channel Adapter)１１、１２と、ＣＭ（Centralized Module)１０、１５〜１９と、ＤＡ（Device Adapter)１３、１４のファンクションモジュールによって構成されている。
【００３７】
ＣＡ（Channel Adapter）１１、１２は、ホストを結ぶホスト・インタフェースの制御をつかさどる回路であり、例えば、ファイバーチャネル回路（ＦＣ）やＤＭＡ（Direct Memory Access）回路等で構成される。ＤＡ（Device Adapter）１３、１４は、デイスクデバイス（磁気デイスク装置）５０を制御するため、デイスクデバイスとコマンド、データのやり取りを行う回路であり、例えば、ファイバーチャネル回路（ＦＣ）やＤＭＡ回路等で構成される。
【００３８】
ＣＭ（Centralized Module）は、ＣＰＵ１０と、メモリー（ＲＡＭ）１５と、フラッシュメモリ（プログラムメモリ）１７と、ＩＯブリッジ回路１８とを有する。メモリー１５は、バッテリーでバックアップされ、その一部が、キャッシュメモリ１６として使用される。
【００３９】
ＣＰＵ１０は、内部バス１９を介し、メモリー１５、フラッシュメモリ１７、ＩＯブリッジ回路１８に接続される。このメモリー１５は、ＣＰＵ１０のワーク領域に使用され、フラッシュメモリ１７は、ＣＰＵ１０が実行するプログラムを格納する。このプログラムとして、カーネル、ＢＩＯＳ（Basic Input/Output System），ファイルアクセスプログラム（リード／ライトプログラム）、ＲＡＩＤ管理プログラム等を格納する。ＣＰＵ１０は、このプログラムを実行し、リード／ライト処理、ＲＡＩＤ管理処理等を実行する。
【００４０】
一対のＰＣＩ（Personal Computer Interface）バス２０、２１は、ＣＡ１１，１２と、ＤＡ１３，１４とを接続するとともに、ＩＯブリッジ回路１８を介し、ＣＰＵ１０、メモリー１５を接続する。更に、ＰＣＩバス２０、２１には、ＰＣＩ−ノードリンクブリッジ回路３０が接続される。
【００４１】
コントローラ１のＰＣＩ−ノードリンクブリッジ回路３０は、コントローラ２のＰＣＩ−ノードリンクブリッジ回路と接続され、コントローラ１，２間のコマンド、データの交信を行う。
【００４２】
例えば、コントローラ１は、デバイスエンクロージャー５−１〜５−４のデイスク装置５０を担当し、コントローラ２は、デバイスエンクロージャー５−５〜５−８のデイスク装置５０を担当する。図１では、デバイスエンクロージャー５−１〜５−４のデイスク装置５０と、デバイスエンクロージャー５−５〜５−８のデイスク装置５０とが、ＲＡＩＤ５の構成を有する。
【００４３】
キャッシュメモリ１６は、各々、担当するデイスク装置のデータの一部を格納し、ホストからのライトデータを格納する。ＣＰＵ１０は、ＣＡ１１，１２を介しホストからのリード要求を受けて、キャッシュメモリ１６を参照し、物理デイスクへのアクセスが必要かを判定し、必要であれば、デイスクアクセス要求をＤＡ１３，１４に要求する。
【００４４】
又、ＣＰＵ１０は、ホストからのライト要求を受けて、ライトデータをキャッシュメモリ１６に書込み、且つ内部でスケジュールされるライトバック等をＤＡ１３，１４に要求する。
【００４５】
［動的システム負荷管理構成］
図２は、図１のＣＰＵ１０が実行するＩＯコマンド処理モジュールと負荷の関係図、図３は、図２のＩＯコマンド処理モジュールの構成図である。
【００４６】
図２に示すように、ＩＯコマンド処理は、大きく分けて、ストレージ装置へのアクセスが必要かを判定するフロントエンド処理モジュール４０、ストレージ装置へのアクセスの処理を行うバックエンド処理モジュール４４と、バックエンド処理モジュール４４へのＩＯコマンドの受け付け量を制御するＩ／Ｏ制御モジュール４２とからなる。フロントエンド処理モジュール４０は、キャッシュメモリ１６（図１参照）の参照、リード、ライトを行うキャッシュ制御モジュール４８を有する。
【００４７】
このバックエンド処理モジュール４４に対する負荷は、ホストＩ／Ｏによるものと、内部（ローカル）Ｉ／Ｏによるものである。ホスト３からのＩ／Ｏコマンドによるものとしては、ライトコマンド実行後のライトバック８１（キャッシュからのライトバック）のコマンド、プリフェッチ８２（リードされたデータの近辺のデータを前もってステージングする）のコマンド、ホストＩ／Ｏコマンド８３である。
【００４８】
内部コマンド（ローカルコマンド）としては、ホストからのコピー指示に応じて、順次コピーするワンポイントコピー８０によるコマンド、外部指示に応じて、ＲＡＩＤレベルを変更するマイグレーション８４によるコマンド、デイスクデバイスの増設による容量拡張のためのＬＤＥ（Logical Device Expansion）８５によるコマンド、物理デイスクのフォーマットをバックグラウンドで行うクイックフォーマット８６によるコマンド、再構築やコピーバック８７によるコマンドがある。
【００４９】
本発明では、Ｉ／Ｏ制御モジュール４２からの情報と、バックエンドモジュール４４からの情報に基づき、システム負荷を計算し、Ｉ／Ｏ制御モジュール４２を制御するシステム負荷管理モジュール４６を設けている。図３により、詳細に説明する。
【００５０】
図３に示すように、Ｉ／Ｏ制御モジュール４２は、ホスト−ＩＯ（Ｈ−ＩＯ）制御モジュール６０と、ローカルＩＯ（Ｌ−ＩＯ）制御モジュール６１とからなる。
【００５１】
ホスト−ＩＯ制御モジュール６０は、ホストＩ／Ｏの受付量を調節するモジュールである。フロントエンドモジュール４０のキャッシュ制御モジュール４８で、ミスヒット（対象データがキャッシュメモリ１６に存在しない）と判断した後にコールされ、システム負荷管理モジュール４６のシステム負荷状態を判断し、ホストＩ／Ｏの受付量を調節する。受付量の調節は、ホスト３へのBusy/Q-Full応答にて行う。
【００５２】
又、ローカルＩＯ制御モジュール６１は、ローカルＩ／Ｏの起動量を調節するモジュールである。ローカルＩ／Ｏを受け付けた時点で、システム負荷管理モジュール４６の負荷状態を判断し、起動量を調節する。起動量の調節は、待ち合わせ（キューイング）にて行う。
【００５３】
Ｉ／Ｏ制御モジュール４２で、起動許可されたＩ／Ｏコマンドに対し、ＢＥ（ＢａｃｋＥｎｄ）−ＡＣＢ(Access Control Block)の獲得処理６２で、ＢＥ−ＡＣＢが獲得され、バックエンドモジュール４４へのアクセスが可能となる。バックエンドモジュール４４では、Ｉ／Ｏコマンドの要求内容の解釈処理７０を行い、この解釈（デイスクへのコマンド分割）に従い、制御用の各資源の獲得処理７２が行われる。資源獲得処理７２は、内部バッファ領域（Extent）、ローカルバッファ、ワークメモリ等を獲得し、排他権を設定する。
【００５４】
この資源獲得後、Ｄｉｓｋ（デイスク）／ＦＣ（ファイバーチャネル）ドライバ７３にデイスクコマンドを発行する。ドライバ７３からＰＣＩバス２０（２１）より、ＤＡ１３（１４）に、デイスクコマンドが送信され、更に、ＦＣ＿ＡＬ４−１（４−２）を通して、磁気デイスク装置５０にデイスクコマンドが伝達される。これにより、磁気デイスク装置５０は、このデイスクコマンドを実行する。
【００５５】
一方、システム負荷管理モジュール４６は、流量予測モジュール７４と、実負荷管理モジュール７６と、負荷統計モジュール７８とからなる。流量予測モジュール７４は、ハード使用量の不確定な段階で、ハード使用量の予測を行う。即ち。流量予測モジュール７４は、バックエンドモジュール４４へＩ／Ｏを要求した時点で、Ｉ／Ｏ要求の各パラメータ(転送数／Read／Write／RAIDレベルなど)により一意な点数（ハード使用量の予測値）を計算し、負荷統計モジュール７８に情報（予測値）を反映する。
【００５６】
実負荷管理モジュール７６は、ハード使用量が確定した段階で、ハード使用量（実負荷）を計算する。即ち、実負荷管理モジュール７６は、デイスク装置５０／ＦＣ＿ＡＬ４−１(ハード)へ起動している転送量を管理し、ハードのタイムアウトが発生しないように起動調整する。またハードの実負荷情報を計算し、負荷統計モジュール７８に反映する。
【００５７】
負荷統計モジュール７８は、ＲＬＵ（Raid Logical Unit）単位で、負荷の統計を行い、過負荷状態に遷移したときに、Ｈ−ＩＯ/Ｌ−ＩＯ制御モジュール６０，６１に抑止通知を行う。
【００５８】
図４乃至図６は、システム負荷管理の動作説明図である。
【００５９】
図４に示すように、システム負荷管理モジュール４６のバックエンドの流量管理によって、バックエンドモジュール４４に発行できるコマンドサイズ上限が決定される。この上限以上のデータをバックエンドモジュール４４に発行しないために、ＩＯ制御モジュール４２により発行コマンドの制限を行う。ＩＯ制御モジュール４２は、前述のように、ホストＩ／Ｏを制限するＨ−ＩＯ制御モジュール６０と、ローカルＩ／Ｏを制限するＬ−ＩＯ制御モジュール６１で構成されている。
【００６０】
Ｉ／Ｏ要求を受け付けたＩＯ制御モジュール４２は、発行可能コマンドサイズ上限(閾値)をチェックし、閾値以下の場合には、即座にバックエンドモジュール４４にコマンドを発行するが、閾値以上の場合には、前に出したコマンドが完了し、バックエンドモジュール４４で実行中のコマンドサイズが閾値以下になるまで、コマンドの発行を抑止する。
【００６１】
抑止方法としては、ホストＩ／Ｏの場合には、コマンド発行元に対し、エラー復帰する。エラーを受けたフロントエンドモジュール４０は、ホスト３に対しQfull/BUSY等(設定による)を返す。ローカルＩ／Ｏの場合には、Ｌ−ＩＯ制御モジュール６１内で、コマンドはキューにつながれ、待ちあわせを行う。この場合、コマンド再実行のタイミングは、前のコマンドの実行完了時(バックエンドモジュール４４からの復帰時)に、再度閾値チェックを行った時となる。
【００６２】
図５に示すように、ホストＩ／Ｏについては、ホストＩ／Ｏの受け付け時に、キャッシュヒットデータについては制限を行わず、即時実行する。キャッシュミスヒットデータや、ライトバックデータついては、最終的にライトバックデータとしてＨ−ＩＯ制御モジュール６０を呼び出し、バックエンドモジュール４４へのコマンド投入可否を問い合わせる。プリフェッチ、リードデータについても、同様にＨ−ＩＯ制御モジュール６０を呼び出す。
【００６３】
一方、図６に示すように、システム負荷が１００％を超えた場合には、キャッシュシュ制御モジュール４８からＨ−ＩＯ制御モジュール６０への問い合わせに対し、BUSYエラー復帰する。キャッシュ制御モジュール４８は、BUSYエラーによって、上位へのエラー復帰、ライトバックの待ち合わせなどの異常処理を行う。
【００６４】
このように、システム負荷に従い、ホストＩ／Ｏについても管理を行うことで、システム性能以上のコマンド処理を受け付けない。又、Extent排他前に負荷管理を実施することで、ホストＩ／Ｏ処理を妨げない。
【００６５】
更に、デイスク装置に着目した流量管理を実施し、ハード性能以上のデイスクコマンド発行を抑止する。内部のタイマ監視と連携し、システム負荷を管理することで、内部タイムアウト多発(パス切れ)を防止する。
【００６６】
即ち、個々のホストＩ／Ｏ，ローカルＩ／Ｏ毎に負荷の重みを予測算出する管理と、ハード実負荷を、総合的に管理することで、システム全体の抱える負荷をリアルタイムに把握でき、システム性能をフルに引き出し，正確な負荷管理を実現できる。
【００６７】
又、これらの問題以外のＤＴＣの利点に関しては，そのまま継承する。即ち、ローカルＩ／Ｏを、より制限し、ホストＩ／Ｏ処理を極力妨げないようにする。システム負荷状態により、動的に内部Ｉ／Ｏ(デイスク装置へのコマンド)の発行数を制限する。更に、ＯＰＣとRebuild/Copybackについて、制御の違いを考慮し、別管理として負荷管理を実施する。
【００６８】
［システム負荷管理］
次に、前述のシステム負荷管理機構を使用した動的システム負荷管理を具体的に説明する。図７は、図２及び図３のシステム負荷管理モジュール４６の詳細構成図、図８は、図７の実負荷管理モジュール７６のテーブル構成図、図９は、図７の総合（システム）負荷の説明図、図１０は、図８の実負荷の説明図である。
【００６９】
先ず、図３及び図７に示すように、流量予測モジュール７４は、前述のように、ハード使用量の不確定の段階で、負荷予測を行う。この予測において、個々のＩ／Ｏ要求は、要求転送長、ＲＡＩＤの種類、コマンド種別等により、使用するデイスク装置の位置やＦＣ＿ＡＬループなどが異なり、また，ハードを占有する時間も異なる。
【００７０】
そのため、ホストのアクセス単位であるＲＬＵ（Ｒａｉｄ Ｌｏｇｉｃａｌ Ｕｎｉｔ）単位の負荷を正確にもとめるには、個々のＩ／Ｏ要求が持つ、これら各ハードを、それぞれどのくらい使用するかという情報を、ハード資源単位(個々のデイスク装置／ファィバーチャネル単位)に統計を行い、各ＲＬＵを構成するハード資源の統計値を元に、ＲＬＵ単位の負荷率を求める必要がある。
【００７１】
しかし、Ｉ／Ｏ要求が、各ハードをそれぞれどのくらい使用するかという情報は、要求受け付け時点では確定せず、要求内容を解釈し、制御用の各資源を獲得し、ハード(デイスク装置)毎に、コマンドを分割して始めて判断できる。即ち、図３のデイスクドライバへ起動する直前に判明する。
【００７２】
予測負荷は、Ｉ／Ｏ要求受け付け時点〜デイスクドライバ７３へコマンド起動するまでの、ハード使用量が不確定なフェーズ（図３参照）で予測するため、要求転送長、ＲＡＩＤの種類、コマンド種別などのパラメータから、ハード使用量を予測する方法にて統計を行う。
【００７３】
なお、この予測値は、デイスクドライバ７３へのコマンド起動前の実際のハード使用量が確定した時点で、実負荷管理モジュール７６による実際のハード使用量へと変わり、統計に反映される。
【００７４】
この流量予測モジュール７４の予測値の統計は、ＲＬＵ単位である。即ち、図９に示すように、あるＲＬＵに起動された１つのコマンドだけを考えると、ＲＬＵを構成する一部のデイスク装置のみの起動であり、ＲＬＵとしてはアクセスの偏りが生じている。しかし、本来ＲＡＩＤは，ストライピング手法を採用しており、特定デイスク装置へのアクセスの集中を防止し、負荷を分散させ、性能を向上させている。このため、フロントエンドモジュール４０から複数のコマンドが起動され、バックエンドの負荷が上がる程、構成する各デイスク装置の負荷は分散し、均等化される。
【００７５】
これを利用し、流量予測モジュール７４は、個々のデイスク装置単位で統計を行うのではなく、低負荷時には多少の誤差が生じるが、煩雑な処理を行う必要がないＲＬＵ単位による統計を行い、処理の高速化を図る。そして、ＲＬＵ単位に統計を行った場合、個々のデイスク装置の負荷は、ＲＡＩＤ（ＲＬＵ）を構成するデイスク装置の台数分の1という値で求める。
【００７６】
流量予測モジュール７４は、ＲＬＵ単位の加点制を採用し、フロントエンドモジュール４０から起動されたパラメータをもとに、負荷要素であるデイスクコマンド数とデータ転送数の予測値を求め、それを時間換算し、最終的に１μｓ当たり１点として統計を行う。具体的に、説明する。
【００７７】
先ず、デイスクコマンド数によるハード使用量の予測値は、デイスク装置の平均アクセス時間×デイスク装置へのコマンド数から計算する。例えば、デイスク装置への１コマンドに対する平均アクセス時間を、５ｍｓとすると、デイスク装置への１コマンドは、５ｍｓ＝５，０００点に換算する。又、デイスク装置のコマンド数は、フロントエンドモジュール４０から起動されたデータ数を元に求める。
【００７８】
データ転送数によるハード使用量の予測値は、デイスク装置とＦＣ＿ＡＬの転送能力から、１Blockの点数を予め求めておき、この点数に、転送ブロック数を掛けて、計算する。そして、Ｉ／Ｏ要求の予測負荷（予測点数）は、ＲＬＵ単位で、以下のようにして計算する。
【００７９】
予測点数＝（デイスクコマンド数による予測点数＋データ転送数による予測点数）／（ＲＬＵ構成デイスク装置台数）
図１の実施の形態の構成での例により、更に、具体的に、説明する。先ず、転送能力を説明する。図１のＣＰＵ１０からデイスク装置５０へのルートは、ＰＣＩバス２０，２１、ＦＣ＿ＡＬ４−１，デイスク装置５０のルートである。各ルート要素の転送能力が、転送能力となる。
【００８０】
先ず、図１のＰＣＩバス能力の論理値は５２８MB/ｓであるが、実測では、約２００MB/ｓである。図１の構成では、コントローラ当り２本のＰＣＩバス２０，２１が実装されており、各ＰＣＩバスには５個のＰＣＩデバイス１１，１２，１３，１４，３０が接続されている。これを元に，１個のデバイス（ＤＡ１３，１４）が使用できる能力を計算すると、２００ＭＢ/s÷５＝４０ＭＢ／ｓとなる。
【００８１】
次に、バックエンドのＦＣ＿ＡＬ能力は２００ＭＢ/sであるが、両コントローラから同時にアクセスした場合、2分の１の性能となるため、ＦＣ１ポート当り１００MB/ｓとなる。ただし、ＰＣＩ転送能力が性能ネックとなるため、ＦＣ能力は、ＰＣＩ能力と同じ４０ＭＢ／ｓとなる。
【００８２】
更に、図１のデイスク装置単体のデータ転送能力は、約５０ＭＢ/s〜８０MB/ｓであるが、ＦＣ１ポートには１〜６０台のデイスク装置５０が接続されるため、デイスク装置１台当りのデータ転送能力は、ＦＣ能力を，接続(担当する)デイスク装置の台数で分割した能力と考える。
【００８３】
そのため、デイスク装置１台当りのデータ転送能力は、４０ＭＢ／ｓ÷接続（担当する）デイスク装置の台数となる。例えば、２つのコントローラ１，２で、８つのデバイスエンクロージャー５−１〜５−８(デイスク装置１２０台)の構成時、ＦＣ１ポート当り担当するデイスク装置は通常３０台のため、デイスク装置１台のデータ転送能力は、１．３３ＭＢ／ｓ（＝４０÷３０）となる。
【００８４】
又、デイスク装置５０の１コマンド当りの処理時間は、前述の平均アクセス時間の５ｍｓとする。同様に、デイスク装置５０のコマンド処理能力を考えると、デイスク装置５０に、アクセス速度を向上するためのコマンド並び替え機能があるため、デイスク装置へ多数のコマンドを起動した方が、性能が向上する。
【００８５】
ただし、あまり多くのコマンドを起動しすぎると、デイスク装置内のファームオーバヘッドが増加し、性能がダウンしてしまう。図１のデイスク装置の測定では、約８０個のコマンドを、デイスク装置へ起動したときに最大性能がでていることが判明したため、デイスク装置５０のコマンド能力は、８０個とする。
【００８６】
例えば、２ＣＭ（コントローラ）−８ＤＥ（デバイスエンクロージャー）モデルの場合、ＦＣポート当たり３０台のデイスク装置５０を担当したとすると、ＦＣ能力４０ＭＢ／ｓを、３０台で割った１．３３ＭＢ／ｓが、デイスク装置単体のデータ転送能力であり、１Ｂｌｏｃｋ（＝５１２Ｂｙｔｅ）当り，３７６点(３７６μｓ)となる。
【００８７】
起動時のパラメータ（要求転送量、ＲＡＩＤ構成、コマンド種別）により、デイスクコマンド点数、データ転送点数は、実際の処理同様に計算される。例えば、ＲＡＩＤ５(3+1, Normal)、４０ＫＢのＲｅａｄコマンドの場合には、予測点数は、以下のように計算される。
【００８８】
デイスクコマンド点数：80Block(40KB)÷2×5ms×1＝200ms(200,000点)
データ転送点数 ：80Block(40KB)×376×1＝30,080点
予測点数合計230,080点 (１デイスク当り57,520点)
次に、実負荷管理モジュール７６を説明する。フロントモジュール４０からのＲＬＵに対する１つの要求は、複数(または１つ)のデイスク(ＦＣ)コマンドへ変換されデイスクドライバ７３（図３参照）へ起動される。この時点になると、ハード使用量は、予測によるものではなく、実際のハード使用量が確定する。実負荷管理モジュール７６は、各ハード資源の性能限界時(ハード能力限界点)の調節用の情報としても使用するため、予測時に行うＲＬＵ単位の統計ではなく、各ハード資源単位（デイスク装置単位）での統計を実施する。
【００８９】
実負荷管理モジュール７６の統計は、図７に示すように、デイスク装置単位の加点制で、デイスクドライバ７３−１へ起動されたデータ転送数を時間換算し、点数は、流量予測モジュール７４と同じく、１μｓ当り１点として統計を行う。
【００９０】
具体的には、デイスク装置５０への１コマンドは、５ｍｓ(平均アクセスTime)と考え，５，０００点とする。又、流量予測モジュール７４と同様に、デイスク／ＦＣの転送能力から１Blockの点数を予め求めておき、それを元に加点する。この１Blockの点数は、前述と同様に、３７６点である。そして、前述の予測と同様に、デイスク装置単位で、デイスクコマンド点数と、データ転送点数を求め、これを加算して、実負荷点数を計算する。
【００９１】
更に、ハード能力限界点を超えるＩ／Ｏ要求をハードへ依頼すると、デイスク装置のタイムアウトが発生してしまうため、実負荷管理モジュール７６は、バックエンドモジュール４４から起動されたつぶつぶのＩ／Ｏ要求毎に、対象のデイスク装置負荷が、ハード能力を超えないよう管理を行う。
【００９２】
図１０に示すように、実負荷管理モジュール７６は、ハード能力超えをチェックした結果、ハード能力以下の場合は、ハードに起動をかけ、ハード能力を超えている場合は、デイスクドライバ７３−１で負荷が下がるのを待つ待ち合わせ（キューイング）を行う。その後、デイスク装置５０からの終了割込みの延長で、負荷がハード能力以下となった場合に、待ち合わせ中のＩ／Ｏ要求をハード能力限界まで起動する。
【００９３】
実負荷管理モジュール７６のハード能力限界の判断は、図８に示すように、デイスク装置単位に、以下の２つの要素毎に量を管理し、それぞれの閾値をチェックすることで、ハード能力限界を超えたかどうか判断する。
【００９４】
図８に示すように、各デイスク装置単位のテーブル７６−１は、実負荷ポイントとして、ハード限界能力ポイント（＝ＦＣ性能(４０ＭＢ/S)÷デイスク装置台数×４秒）、実負荷のトータルポイント、実行中ポイント（図１０のＦＣドライバ７３−２起動後の負荷ポイント）、待ちポイント（図１０のデイスクドライバ７３−１起動後、ＦＣドライバ７３−２起動前の待ち負荷ポイント）とで、デイスクドライバを管理し、デイスク装置のコマンド数として、限界コマンド数（８０コマンド）、トータルコマンド数、実行中コマンド数（図１０のＦＣドライバ７３−２起動後のコマンド数ポイント）、待ちコマンド数（図１０のデイスクドライバ７３−１起動後、ＦＣドライバ７３−２起動前の待ちコマンド数ポイント）を管理する。
【００９５】
即ち、実負荷管理モジュール７６は、バックエンドモジュール４４からデイスクドライバ７３−１に、デイスクコマンドが発行されると、前述のコマンド数ポイントと、データ転送数ポイントを計算し、更に、実負荷ポイントを計算する。そして、実負荷管理モジュール７６は、テーブル７６−１の待ちポイント、トータルポイントを更新する。図１０に示すように、デイスクドライバ７３−１からＦＣドライバ７３−２に、デイスクコマンドが起動されると、テーブル７６−１の待ちポイント、実行中ポイントに移す。
【００９６】
次に、図７に戻り、予測負荷と実負荷との統合を行う負荷統計モジュール７８を説明する。負荷統計モジュール７８は、予測負荷と実負荷の統合を、負荷チェックがＲＬＵ単位であり負荷チェック時の処理を軽くするため、ＲＬＵ単位で管理する。
【００９７】
ただし、図７及び図９に示すように、負荷統計モジュール７８の統計は、ＲＬＵに属するデイスク装置の中で一番負荷が高いものを代表として管理する。ＲＬＵに属するデイスク装置内の負荷が変動し、負荷が一番高いデイスク装置番号が変わった場合は、代表のデイスク装置も入れ換え処理を実施し、常に一番負荷の高いデイスク装置を代表とする。
【００９８】
負荷統計モジュール７８が、図７に示すように、予想負荷点と実負荷点を合算して、総合負荷点を計算する。総合負荷点を計算するタイミングは、予測負荷、または、実負荷が更新されるたび(即ち、内部Ｉ／Ｏが処理されるたび)に行うことができる。又、更新毎に行うと処理が重くなるため、以下のタイミング時にのみ実施すると良い。
【００９９】
（１）ＲＬＵ単位の予測負荷点が、毎500,000ポイント境界を跨ぎ変動した場合。
【０１００】
（２）実負荷の代表デイスク装置(一番高負荷なデイスク装置)が入換わった場合(尚、代表デイスク装置の入換えは、各デイスク装置の値が100,000ポイント境界を跨いだときに、代表デイスク装置のポイントと比較し、代表を超えていた場合に実施する)。
【０１０１】
（３）実負荷の代表デイスク装置の値が、100,000ポイント境界を跨ぎ変動した場合。
【０１０２】
図７の負荷統計モジュール７８の閾点は、システム能力限界点を設定する。例えば、コントローラ間通信のタイマ値である20秒(20,000,000μｓ)から求めた値、20,000,000点とする。
【０１０３】
又、負荷統計モジュール７８は、負荷の割合(％)を求めることができる。負荷の割合は、（総合負荷点÷閾点×１００）の式で計算する。
【０１０４】
［動的システム負荷制御］
図１１は、図３のＨ−ＩＯ制御モジュール６０のホストＩ／Ｏ処理フロー図、図１２は、図７及び図８で説明したハード能力限界点とシステム能力限界点の説明図、図１３は、図１１のＨ−ＩＯ制御モジュール６０とシステム負荷管理モジュール４６の処理の流れ図、図１４は、ＩＯ制御モジュール４２とシステム負荷管理モジュール４６の処理の流れ図である。
【０１０５】
図１２に示すように、システムの負荷が高くなると、次の２つの限界点が現れる。第１は、ハード能力限界点である。即ち、これ以上ハードに処理を要求しても、ハードの処理能力をオーバしてしまい、特定時間以内に処理が完了しなくなる境界点である。例えば、デイスク装置の能力が、１０ＭＢ／ｓの能力であり、ハード処理の時間監視を５秒とした場合、５０ＭＢの要求を超えると、ハードのタイムアウトが発生してしまう。ハード能力限界点に達した場合、オーバした要求は、前述のドライバ７３で待たせる。
【０１０６】
例えば、デイスク装置の時間監視が７秒であり、そのうち３秒をデイスク装置内のコマンド並び替え、ポジショニング等の時間として、残り４秒をデータ転送分と考えた場合、ハード能力限界点は、４秒(4,000,000μｓ)から求め、４，０００，０００点とする。
【０１０７】
第２に、システム能力限界点である。ハード能力の限界を超えてもさらに要求がき続けた場合、ドライバ７３で待ちが出始め、システムの監視時間(ＣＡ１１，１２のコマンドタイムアウト検出(２５秒)、または、コントローラ間のタイムアウト(２０秒))以内に、処理が完了しなくなる境界点を、システム能力限界点という。システム能力限界点に達した場合、オーバしたホスト要求は、前述のBusy/Q-Fullで、ホスト応答させる。また、ローカルＩ／Ｏの場合は、負荷が限界点を下回るまで要求を待たせる。
【０１０８】
例えば、フロントモジュール４０で行っているホストコマンド処理の時間監視が２５秒、コントローラ間を跨いだクロスアクセス時のコントローラ間通信の時間監視が２０秒である場合には、システム能力限界点は、短い方の２０秒(20,000,000μｓ)から求め、２０，０００，０００点となる。
【０１０９】
次に、システム負荷制御を、図１１のＩ／Ｏ制御モジュール４２の処理フロー図及び図１３のＩ／Ｏ制御モジュール４２とシステム負荷管理モジュール４６の処理フロー図で説明する。
【０１１０】
（Ｓ１０）Ｉ／Ｏ制御モジュール４２は、Ｉ／Ｏ要求を受け付けると、システム負荷管理モジュール４６から負荷統計モジュール７８の総合負荷点と閾点（図７参照）を問い合わせる。
【０１１１】
（Ｓ１２）Ｉ／Ｏ制御モジュール４２は、総合負荷点が、閾点（システム能力限界点）を超えているかを判定する。
【０１１２】
（Ｓ１４）総合負荷点が、閾点を越えている場合には、図４、図６、図１２で説明したように、システム負荷が高負荷のため、ホストに、Ｂｕｓｙ／Ｑｆｕｌｌを返答し、バックエンドへの起動を行わず、終了する。
【０１１３】
（Ｓ１６）総合負荷点が、閾点を越えていない場合には、図５で説明したように、システム負荷が高負荷でないため、バックエンドモジュール４４へＩ／Ｏ要求を発行し、終了する。
【０１１４】
図１３で具体的に説明する。過負荷でない通常負荷の場合には、ホスト３からのリード要求が、フロントエンドモジュール４０でキャッシュヒットと判定されると、キャッシュメモリ１６のデータがホスト３に転送され、流量管理の対象とならない。
【０１１５】
リード要求でも、キャッシュミスヒットの場合には、バックエンドモジュール４４へリード要求が発行されるとともに、流量予測モジュール７４で負荷予測値を計算され、負荷統計モジュール７８の予測値に加算される。更に、実負荷モジュール７６は、予測値を減点し、これを実負荷点に加点する（減点した予測値を実負荷値に移す）。Ｉ／ＯでのＩ／Ｏ処理が終了すると、実負荷点を減点する。これとともに、デイスク装置からホストへリードデータが転送される。
【０１１６】
同様に、過負荷でない通常負荷の場合には、ホスト３からのライト要求が到来すると、フロントエンドモジュール４０でキャッシュメモリ１６に、ライトデータが書き込まれ、流量管理の対象とならない。
【０１１７】
ライトバック等のローカルＩ／Ｏ要求は、バックエンドモジュール４４へ伝達されるとともに、流量予測モジュール７４で負荷予測値を計算され、負荷統計モジュール７８の予測値に加算される。更に、実負荷モジュール７６は、予測値を減点し、これを実負荷点に加点する（減点した予測値を実負荷値に移す）。Ｉ／ＯでのＩ／Ｏ処理が終了すると、実負荷点を減点する。これとともに、デイスク装置からホストへライト完了が転送される。
【０１１８】
一方、過負荷の場合には、ホスト３からのリード要求が、フロントエンドモジュール４０でキャッシュヒットと判定されると、キャッシュメモリ１６のデータがホスト３に転送され、流量管理の対象とならないが、リード要求でも、キャッシュミスヒットの場合には、バックエンドモジュール４４へリード要求が発行されず、ホスト３へＢｕｓｙ／Ｑｆｕｌｌが返答される。ライトバックを含むローカルＩ／Ｏも、Ｌ−ＩＯ制御モジュール６１で、待ちキューに待ち合わせされる。
【０１１９】
次に、図１４により、ハード能力限界制御を説明する。バックエンドモジュール４４で、デイスクコマンドが作成されると、前述のように、実負荷管理モジュール７６で、各デイスク装置毎のテーブル７６−１を参照し、ハード能力点をチエックする。即ち、実負荷管理モジュール７６は、トータルポイント又はトータルコマンド数のいずれかが、限界値を越えているかを判定し、越えていないと、テーブル７６−１の実行中ポイント、実行中コマンド数に加点し、Ｉ／Ｏを起動する。
【０１２０】
一方、限界値を越えていると、テーブル７６−１の待ちポイント、待ちコマンド数に加点し、待ちキューに待ち合わせする。これを、デイスクコマンド分繰り返し、終了する。
【０１２１】
又、起動Ｉ／Ｏから終結割り込みが、デイスク／ＦＣドライバ７３に到来すると、実負荷管理モジュール７６は、実行中ポイント、実行中コマンド数を減点する。デイスク／ＦＣドライバ７３は、待ちキューに待ちコマンドがあるかを判定し、無ければ、終了する。
【０１２２】
待ちキューに待ちコマンドがあると、待ちキューの先頭を参照し、実負荷管理モジュール７６で、各デイスク装置毎のテーブル７６−１を参照し、ハード能力点をチエックする。即ち、実負荷管理モジュール７６は、トータルポイント又はトータルコマンド数のいずれかが、限界値を越えているかを判定し、越えていないと、テーブル７６−１の待ちポイント、待ちコマンド数を減点し、且つ実行中ポイント、実行中コマンド数に加点し、待ちキューの先頭をデキューし、Ｉ／Ｏを起動する。
【０１２３】
一方、限界値を越えていると、このルーチンを脱出する。
【０１２４】
［閾値調整処理］
次に、ローカルＩ／Ｏの割合を制御する閾値調整処理を説明する。図１５は、Ｌ−ＩＯ制御モジュール６１とシステム負荷管理モジュール４６との関係図、図１６は、システム負荷とローカルＩ／Ｏの閾値の説明図である。ここでは、ローカルＩ／Ｏの閾値を可変に制御する。
【０１２５】
図１５に示すように、負荷統計(RLU)モジュール７８で負荷割合（＝（総合負荷数÷閾点）×１００）からローカルＩ／Ｏの閾値（割合）を計算する。Ｌ−ＩＯ制御モジュール６１は、このローカルＩ／Ｏの閾値を取得し、（アクセス対象ＲＬＵに関する現在のコマンドサイズ＋これから発行しようとするコマンドサイズ）が，この閾値を超えているかどうかを判断する。
【０１２６】
このローカルＩ／Ｏの制御アルゴリズムとして、ホストＩ／Ｏを最優先とするため、ホストＩ／ＯとローカルＩ／Ｏとで閾値に違いを持たせ、ローカルＩ／Ｏを早期に制限する。即ち、ホストＩ／Ｏがあるときには、極力ローカルＩ／Ｏの割合を下げるが、ホストＩ／Ｏがないときには，ローカルＩ／Ｏをできるだけ実行する。
【０１２７】
このために、Ｌ−ＩＯ制御モジュール６１は、図１６に示すように、ローカルＩ／Ｏの負荷全体に占める割合を制限し、最大でも閾値の７０％(Webから設定可能な値)とし、ホストＩ／Ｏがある場合には、システム負荷が閾値の６０％を超えた時点で、ローカルＩ／Ｏの割合を制限する。
【０１２８】
又、ホストＩ／Ｏの負荷割合が非常に高くなった場合でも、最低限のローカルＩ／Ｏを実行するために、ローカルＩ／Ｏの最低閾値を１０％と制御する。全体負荷が低くなるに応じて、ローカルＩ／Ｏの割合の制限をやめ、最終的には，閾値の最大の７０％に戻す。
【０１２９】
更に、ＯＰＣなど完了時間保証しなければならないローカルＩ／Ｏについては、時間保証に必要な転送性能を確保するために、最低限、一定時間毎にコマンドを実行するように制御する。ローカルＩ／Ｏの閾値を変動させるタイミングは、ローカルＩ／Ｏコマンド発行時と完了時とする。
【０１３０】
図１６で説明すると、記号「▼」は、ホストＩ／Ｏがあり、システム負荷が６０％を超えたため、ローカルＩ／Ｏの割合を下げる。記号「△」は、システム負荷が５０％以下となったため、ローカルＩ／Ｏの割合を上げる(但し、６０％までとする)。記号「△2」は、ホストＩ／Ｏ負荷がないため、ローカルＩ／Ｏの割合を７０％まで戻す。
【０１３１】
又、図３及び図１５のＬ−ＩＯ制御モジュール６１は、キューの優先度制御を行う。即ち、待ち合わせキューには、優先度を持ったものを３種類持ち、どのキューにも、待ち合わせコマンドが存在する場合には、優先度の高いコマンドから実行する。
【０１３２】
キューの種別としては、以下の３種類のものがある。
【０１３３】
優先度高(時間保証あり)のキューは、ＣＧＩから設定可能な２種類のモード(時間優先設定、ホストI/O優先)を持ち、時間優先の場合には、さらにコマンド完了通知をまたずに一定時間毎にバックエンドモジュールにコマンド発行する。この結果、システム負荷の上昇が懸念されるが、その場合には、ホストＩ／Ｏを制限することで、時間保証を行う。対象Ｉ／Ｏは、ＯＰＣである。
【０１３４】
次に、優先度高(時間保証無し)のキューは、優先度低のキューに優先し実行するが、時間保証は行わず、ホストＩ／Ｏをより優先させる。対象Ｉ／Ｏは、Rebuild/Copyback、LDE、Migrationである。
【０１３５】
更に、優先度低のキューは、優先度高のキューがある場合には実行しないキューであり、対象Ｉ／Ｏは、Quick Formatである。
【０１３６】
次に、Ｌ−ＩＯ制御モジュール６１が、自己で閾値管理を行う場合のローカルＩ／Ｏ処理を説明する。図１７及び図１８は、Ｌ−ＩＯ制御モジュール６１の処理フロー図である。前述のように、Ｌ−ＩＯ制御モジュール６１は、ローカルＩ／Ｏの起動量を調節するモジュールであり、ローカルＩ／Ｏを受け付けた時点で、システム負荷管理モジュール４６の負荷状態を判断し、起動量を調節する。起動量の調節は、待ち合わせ（キューイング）にて行う。
【０１３７】
図１７は、ローカルＩ／Ｏとして、Rebuildで説明する。ローカルＩ／Ｏ実行時には、Extent排他前に，Ｌ−ＩＯ制御モジュール６１を呼び出し、コマンド発行可能かどうかをチエックする。
【０１３８】
図１７に示すように、Rebuild８７で、ローカルＩ／Ｏのコマンドを作成すると、Ｌ−ＩＯ制御モジュール６１に問い合わせる。Ｌ−ＩＯ制御モジュール６１は、システム負荷管理モジュール４６の流量予測モジュール７４で、予測値を計算させ、負荷統計モジュール７８の予測値に加点する。
【０１３９】
Ｌ−ＩＯ制御モジュール６１は、前述の図１５のローカルＩ／Ｏ実行の閾値を超えているかを判定し、越えている場合には、Ｌ−ＩＯ制御モジュール６１に対し発行したコマンドは、Ｌ−ＩＯ制御モジュール６１内でキューされる。一方、ローカルＩ／Ｏ実行の閾値を越えていない場合には、Rebuild８７にコマンド実行を指示し、Rebuild８７が、バックエンドモジュール４４に、Ｉ／Ｏ起動を行う。
【０１４０】
又、図１８に示すように、バックエンドモジュール４４へのコマンドにより、Ｉ／Ｏが完了すると、Rebuild８７に通知される。これにより、システム負荷管理モジュール４６は、これにより、実負荷値を減算する。
【０１４１】
そして、Ｌ−ＩＯ制御モジュール６１は、次のコマンドを待ちキューから外し、前述の図１５のローカルＩ／Ｏ実行の閾値を超えているかを判定し、越えている場合には、Ｌ−ＩＯ制御モジュール６１に対し発行したコマンドは、Ｌ−ＩＯ制御モジュール６１内でキューされる。一方、ローカルＩ／Ｏ実行の閾値を越えていない場合には、Rebuild８７にコマンド実行を指示し、Rebuild８７が、バックエンドモジュール４４に、Ｉ／Ｏ起動を行う。
【０１４２】
このように、Ｌ−ＩＯ制御モジュール６１は、自己の閾値内で、ローカルＩ／Ｏの発行の調整を行い、バックエンドの負荷が閾値以下になり、ローカルＩ／Ｏが実行できる状態になると、次のステージ（コマンド）が呼び出される。これにより、ローカルＩ／Ｏについても、図３に示した、Extent排他獲得処理７２、及びバックエンド４４へのコマンド発行処理が継続される。
【０１４３】
尚、ホストＩ／Ｏを実行するために必要なローカルＩ／Ｏについては、ホストＩ／Ｏと同様に，Ｈ−ＩＯ制御モジュール６０を使用する。この時、ホストＩ／Ｏを実行するために必要なコマンドが，すでにＬ−ＩＯ制御モジュール６１内にキューイングされている場合には、即時実行させることができる。
【０１４４】
［他の実施の形態］
前述の実施の形態では、図１のような冗長構成のＲＡＩＤで説明したが、これ以外の冗長構成のストレージシステムに適用できる。又、物理デイスクは、磁気デイスク、光デイスク、光磁気デイスク、各種のストレージデバイスを適用できる。
【０１４５】
又、システム負荷として、コマンドの処理量を、予測値と実負荷値の両方で管理しているが、予測値を使用しても良い。
【０１４６】
以上、本発明を実施の形態により説明したが、本発明の趣旨の範囲内において、本発明は、種々の変形が可能であり、本発明の範囲からこれらを排除するものではない。
【０１４７】
（付記１）ホストから依頼されたＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムにおいて、前記Ｉ／Ｏ要求に応じたコマンド処理を実行するコマンド処理部と、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行部とを有し、前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測するととともに、前記アクセス実行部の実際の負荷を管理し、前記予測負荷と前記実際の負荷とからシステム負荷を計算し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止することを特徴とするストレージシステム。
【０１４８】
（付記２）前記コマンド処理部は、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整し、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行部を起動することを特徴とする付記１のストレージシステム。
【０１４９】
（付記３）前記コマンド処理部は、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御モジュールと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御モジュールとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせることを特徴とする付記２のストレージシステム。
【０１５０】
（付記４）前記コマンド処理部は、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得ることを特徴とする付記１のストレージシステム。
【０１５１】
（付記５）前記コマンド処理部は、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御することを特徴とする付記１のストレージシステム。
【０１５２】
（付記６）前記コマンド処理部は、前記実際の負荷に応じて、前記アクセス実行部のコマンド処理量を制御することを特徴とする付記１のストレージシステム。
【０１５３】
（付記７）前記コマンド処理部は、ハードウェアで規定される前記アクセス実行部の単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測することを特徴とする付記１のストレージシステム。
【０１５４】
（付記８）前記ストレージ装置のデータの一部を保持するキャッシュメモリを更に設け、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止することを特徴とする付記１のストレージシステム。
【０１５５】
（付記９）前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロントモジュールと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御モジュールと、前記ＩＯ制御モジュールで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドモジュールとを有することを特徴とする付記８のストレージシステム。
【０１５６】
（付記１０）前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測する流量予測モジュールと、前記アクセス実行部の実際の負荷を管理する実負荷管理モジュールと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計モジュールとを有することを特徴とする付記１のストレージシステム。
【０１５７】
（付記１１）ホストから依頼されたＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムの動的システム負荷管理方法において、前記Ｉ／Ｏ要求に応じたコマンド処理を実行するコマンド処理ステップと、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行ステップと、前記依頼されたＩ／Ｏ要求の前記アクセス実行ステップの負荷を予測するととともに、前記アクセス実行ステップの実際の負荷を管理し、前記予測負荷と前記実際の負荷とからシステム負荷を計算するシステム負荷計算ステップと、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップとを有することを特徴とする動的システム負荷管理方法。
【０１５８】
（付記１２）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整するステップと、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行ステップを起動するステップとを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１５９】
（付記１３）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御ステップと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御ステップとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせることを特徴とする付記１２の動的システム負荷管理方法。
【０１６０】
（付記１４）前記システム負荷計算ステップは、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得るステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６１】
（付記１５）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御するステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６２】
（付記１６）前記コマンド処理ステップは、前記実際の負荷に応じて、前記アクセス実行ステップのコマンド処理量を制御するステップを更に有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６３】
（付記１７）前記システム負荷計算ステップは、ハードウェアで実行される前記アクセス実行ステップの単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測するステップを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６４】
（付記１８）前記コマンド処理ステップは、前記Ｉ／Ｏ要求に対し、前記ストレージ装置のデータの一部を保持するキャッシュメモリを参照するステップを有し、前記抑止ステップは、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６５】
（付記１９）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロント処理ステップと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御ステップと、前記ＩＯ制御ステップで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドステップとを有することを特徴とする付記１８の動的システム管理方法。
【０１６６】
（付記２０）前記システム負荷計算ステップは、前記依頼されたＩ／Ｏ要求の前記アクセス実行ステップの負荷を予測する流量予測ステップと、前記アクセス実行ステップの実際の負荷を管理する実負荷管理ステップと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計ステップとを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６７】
【発明の効果】
このように、本発明では、従来、ストレージシステムで管理していなかったホストＩ／Ｏ要求を、ストレージシステムのシステム負荷に応じて管理し、システム負荷を越えるホストＩ／Ｏ要求に対しては、ホストＩ／Ｏ要求を処理せず、エラー応答し、ホストにコマンドのリトライを行わせるようにした。これにより、システム内でのコマンド処理の停滞を抑止できる。
【０１６８】
又、システム負荷を、アクセス実行前と後との両方の負荷から計算するため、正確にシステム自体の負荷を管理できる。
【図面の簡単な説明】
【図１】本発明の一実施の形態のストレージシステムの構成図である。
【図２】本発明の一実施の形態のコマンド処理部の構成図である。
【図３】図２の本発明の一実施の形態のコマンド処理部の詳細構成図である。
【図４】図２のＩＯ制御部の動作説明図である。
【図５】図４のＨ−ＩＯ制御部の低負荷時の動作説明図である。
【図６】図４のＨ−ＩＯ制御部の高負荷時の動作説明図である。
【図７】図３のシステム負荷管理部の構成図である。
【図８】図７の実負荷管理部のテーブルの説明図である。
【図９】図７のＲＬＵ負荷の説明図である。
【図１０】図７の実負荷管理部の実負荷の説明図である。
【図１１】図４のＨ−ＩＯ制御部の処理フロー図である。
【図１２】図７の能力限界点の説明図である。
【図１３】図３のＩＯ制御部とシステム負荷管理部との処理の流れ図である。
【図１４】図３のシステム負荷管理部とバックエンドモジュールの処理の流れ図である。
【図１５】図３のＬ−ＩＯ制御部の説明図である。
【図１６】図１５のローカルＩ／Ｏ要求の閾値制御の動作説明図である。
【図１７】図３のＬ−ＩＯ制御部とシステム負荷管理部との処理の流れ図である。
【図１８】図３のＬ−ＩＯ制御部とシステム負荷管理部とバックエンドの処理の流れ図である。
【図１９】従来技術の構成図である。
【図２０】従来技術のＤＴＣ処理の流れ図である。
【符号の説明】
１、２ ストレージコントローラ
１１、１２ チャネルアダプター
１３、１４ デバイスアダプター
１０、２０ ＣＰＵ
１５，２５ メモリ
１６、２６ キャッシュメモリ
４−１，４−２ ＦＣ＿ＡＬ
５−１〜５−８ デバイスエンクロージャー
３０、４０ ＰＣＩ−ノードブリッジ回路
２０、２１ ＰＣＩバス
５０ 物理デイスク装置（ストレージ装置）
４０ フロントエンドモジュール
４２ Ｉ／Ｏ制御モジュール
４４ バックエンドモジュール
４６ システム負荷管理モジュール
【発明の属する技術分野】
本発明は、磁気デイスク等のストレージ装置を使用してデータの入出力を行うストレージシステム及びその動的負荷管理方法に関し、特に、入出力コマンドの処理量を管理して、コマンド処理の滞留を防止するためのストレージシステム及びその動的負荷管理方法に関する。
【０００２】
【従来の技術】
磁気デイスク、光磁気デイスク、光デイスク等の記憶媒体を利用したストレージ装置では、データ処理装置の要求で、記憶媒体を実アクセスする。データ処理装置が、大容量のデータを使用する場合には、複数のストレージ機器と制御装置とを備えたストレージシステムを利用する。
【０００３】
このようなストレージシステムでは、大量のアクセスに対し、システム内でリソース配分をダイナミックに最適化し、上位装置からのアクセスに対し、安定な性能を実現するＤＴＣ（Dynamic Traffic Control）機能を備えている。図１９は、従来技術の構成図、図２０は、従来技術の説明図である。
【０００４】
図１９に示すように、ストレージコントローラ１００は、ホストＩ／Ｏコマンドに応じて、複数のストレージ装置（磁気デイスク装置）１１０をアクセス制御する。このストレージコントローラ１００は、コマンド処理機能１０２、ＤＴＣ機能１０４、デイスクドライバ１０６、デバイスアダプタ１０８を有する。コマンド処理機能１０２は、ホストＩ／Ｏコマンドと内部Ｉ／Ｏコマンドを受ける。
【０００５】
内部Ｉ／Ｏコマンドは、ホストＩ／Ｏのバックグラウンドで実行するＩ／Ｏ制御であり、例えば、ホストからの連続ブロック群のコピー指示に応じて、ホストＩ／Ｏのバックグラウンドで、順次コピーを行うＯＰＣ（One Point Copy）や、ＲＡＩＤ再構築のリビルドや、データバックアップのためのコピーバック等がある。
【０００６】
ＤＴＣ機能１０４は、ドライバ１０６、デバイスアダプタ１０８を介しストレージ装置１１０に発行するコマンド数を制御する。図２０に示すように、従来技術では、ＤＴＣ機能１０４は、各コマンドの応答時間（ストレージ装置１１０へのコマンド発行からストレージ装置１１０から応答を受けるまでの時間）を測定し、応答時間の平均を計算し、この平均応答時間が、所定時間より早い場合には、単位時間の発行コマンド数を増加し、所定時間より遅い場合には、単位時間の発行コマンド数を減少する。決定された発行コマンド数を越えたコマンドは、キュー待ちする。
【０００７】
コマンド処理機能１０２は、ホストＩ／Ｏ(ランダム、シーケンシャル）の受け入れ制限を付けず、優先して処理し、ＤＴＣ１０４に渡す。内部Ｉ／Ｏは、ホストＩ／Ｏのバックグラウンドで処理し、ＤＴＣ１０４に渡す。ＤＴＣ１０４は、ドライバ１０６、デバイスアダプタ１０８を介し、ストレージ装置１１０に発行コマンド数を越えない数のコマンドを発行する。
【０００８】
このように、ＤＴＣ１０４は、ストレージ装置１１０のレスポンス時間に応じて、起動数（コマンド数）を動的に変更し、Ｉ／Ｏコマンドの実行の最適化を行っていた。
【０００９】
【発明が解決しようとする課題】
従来技術では、ホストＩ／Ｏを全て受け入れているため、システム性能以上のホストＩ／Ｏを受け付けた場合には、内部のタイムアウト時間（例えば、２５秒）内に、ホストＩ／Ｏを実行できず、ホストにタイムアウトで返答していた。このため、ホストは、このＩ／Ｏ要求の実行待ちの状態が長くなり、且つタイムアウトに応じて、その時点で再度、ホストＩ／Ｏを発する必要があった。
【００１０】
又、ＯＰＣ等の内部Ｉ／Ｏが、コマンド処理部１０２で、内部バッファ領域の排他権（Extent排他という）を獲得したまま、ＤＴＣ１０４で待たされることがあり、後発のホストＩ／Ｏコマンドが、Extent排他を獲得できず、スリープし、最悪の場合には、内部のタイムアウトが同様に発生してしまうという問題もあった。
【００１１】
更に、従来のＤＴＣが、過去のストレージ装置（デイスク装置）からのレスポンス時間のみで新たな起動数を決定しているため、一時的にデイスク装置からのレスポンスの遅延が発生した場合には、デイスク装置への新たなコマンド発行を必要以上に絞ってしまうという問題もあり、ストレージ装置の性能をフルに使用することが困難であった。
【００１２】
従って、本発明の目的は、ホストＩ／Ｏの受け付けを調整して、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１３】
又、本発明の他の目的は、システム性能以上のホストＩ／Ｏのコマンド処理の受け付けを抑止し、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１４】
更に、本発明の他の目的は、Ｅｘｔｅｎｔ排他前に負荷管理を行い、ホストＩ／Ｏ処理を妨げずに、受け付けたホストＩ／Ｏの処理遅延によるタイムアウトを防止するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１５】
更に、本発明の他の目的は、ストレージ装置に着目した流量管理を行い、ハード性能以上のストレージ装置へのコマンド発行を抑止し、ストレージ装置の性能をフルに使用するためのストレージシステム及びその動的負荷管理方法を提供することにある。
【００１６】
【課題を解決するための手段】
この目的の達成のため、本発明のストレージシステムは、複数のストレージ装置と、前記複数のストレージ装置をアクセスするためのデバイスアダプターと、前記ストレージ装置のデータの一部を保持するキャッシュメモリと、ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求に応じたコマンド処理を実行し、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行処理を実行するコントローラとを有し、前記コントローラは、前記ホストＩ／Ｏ要求を解読し、解読結果により、前記キャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理を実行し、前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行処理を実行し、前記コントローラは、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止する。
【００１７】
本発明の動的システム負荷管理方法は、コントローラが、ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求を解読し、解読結果により、複数の前記ストレージ装置のデータの一部を保持するキャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理ステップと、前記コントローラが、前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行ステップと、前記コントローラが、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算するシステム負荷計算ステップと、前記コントローラが、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップとを有する。
【００１８】
本発明では、従来、ホストＩ／Ｏ要求を管理していないかったが、ストレージシステムのシステム負荷を越えるホストＩ／Ｏ要求に対しては、ホストＩ／Ｏ要求を処理せず、エラー応答し、ホストにコマンドのリトライを行わせるようにした。これにより、システム内でのコマンド処理の停滞を抑止する。又、システム負荷を、アクセス実行前と後との両方の負荷から計算するため、正確にシステム自体の負荷を管理できる。
【００１９】
又、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整し、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行部を起動する。これにより、内部資源獲得前に、Ｉ／Ｏ要求の調整を行うことができ、ホストＩ／Ｏの処理を妨げずに、より早く、タイムアウトエラーの発生を防止できる。
【００２０】
又、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御モジュールと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御モジュールとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせる。
【００２１】
これにより、ホストＩ／Ｏの調整と、内部Ｉ／Ｏの調整を別に分けたので、ホストＩ／Ｏ要求を妨げることなく、内部Ｉ／Ｏ要求を早期に実行できる。
【００２２】
更に、本発明では、好ましくは、前記コマンド処理部は、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得る。
【００２３】
これにより、アクセス実行部でのハード使用量が不確定な段階で、予測負荷を予測できる。
【００２４】
更に、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御する。これにより、内部Ｉ／Ｏ要求を、早期に処理できる。
【００２５】
更に、本発明では、好ましくは、前記コマンド処理部は、前記実際の負荷に応じて、前記アクセス実行部のコマンド処理量を制御する。これにより、アクセス実行部のハード性能以上のコマンド発行を抑止でき、ストレージ装置のタイムアウトを防止できる。
【００２６】
更に、本発明では、前記コマンド処理部は、ハードウェアで規定される前記アクセス実行部の単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測する。これにより、負荷予測が可能となり、且つ精度も高い。
【００２７】
更に、本発明では、前記ストレージ装置のデータの一部を保持するキャッシュメモリを更に設け、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止する。
【００２８】
キャッシュヒットのＩ／Ｏ要求を除外することにより、より正確な、ホストＩ／Ｏ要求の管理が可能となる。
【００２９】
更に、本発明では、好ましくは、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロントモジュールと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御モジュールと、前記ＩＯ制御モジュールで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドモジュールとを有する。
【００３０】
これにより、コマンド処理の流れの中で、容易に、ホストＩ／Ｏ要求の管理が可能となる。
【００３１】
更に、本発明では、好ましくは、前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測する流量予測モジュールと、前記アクセス実行部の実際の負荷を管理する実負荷管理モジュールと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計モジュールとを有する。これにより、システム負荷の計算を高速且つ容易に実行できる。
【００３２】
【発明の実施の形態】
以下、本発明の実施の形態を、ストレージシステム、動的システム負荷管理構成、システム負荷管理、動的システム負荷制御、閾値調整処理、他の実施の形態の順で説明する。
【００３３】
［ストレージシステム］
図１は、本発明の一実施の形態のストレージシステムの構成図であり、磁気デイスクを使用したＲＡＩＤ（Redundant Arrays of Inexpensive Disk)システムを示す。図１に示すように、ストレージシステムは、一対の磁気デイスクコントローラ（以下、コントローラという）１、２と、この一対のコントローラ１、２にＦＣ＿ＡＬ（Fiber Channel Arbitrated Loop）４−１，４−２で接続された多数のデバイスエンクロージャー５−１〜５−８とからなる。
【００３４】
このデバイスエンクロージャー５−１〜５−８の各々は、１５台の磁気デイスク装置（ストレージ装置）５０を内蔵する。各磁気デイスク装置５０は、一対のＦＣ＿ＡＬ４−１、４−２に接続される。
【００３５】
コントローラ１、２は、直接又はネットワーク機器を介し、クライアントやサーバー等のホスト３に接続され、ホスト３の大量のデータを、ＲＡＩＤデイスクドライブ（磁気デイスク装置）へ高速かつ、ランダムに読み書きが出来るシステムである。
【００３６】
一対のコントローラ１、２は、同一の構成を有する。従って、コントローラ１の構成を説明し、コントローラ２の構成の説明は省略する。コントローラ１は、ＣＡ（Channel Adapter)１１、１２と、ＣＭ（Centralized Module)１０、１５〜１９と、ＤＡ（Device Adapter)１３、１４のファンクションモジュールによって構成されている。
【００３７】
ＣＡ（Channel Adapter）１１、１２は、ホストを結ぶホスト・インタフェースの制御をつかさどる回路であり、例えば、ファイバーチャネル回路（ＦＣ）やＤＭＡ（Direct Memory Access）回路等で構成される。ＤＡ（Device Adapter）１３、１４は、デイスクデバイス（磁気デイスク装置）５０を制御するため、デイスクデバイスとコマンド、データのやり取りを行う回路であり、例えば、ファイバーチャネル回路（ＦＣ）やＤＭＡ回路等で構成される。
【００３８】
ＣＭ（Centralized Module）は、ＣＰＵ１０と、メモリー（ＲＡＭ）１５と、フラッシュメモリ（プログラムメモリ）１７と、ＩＯブリッジ回路１８とを有する。メモリー１５は、バッテリーでバックアップされ、その一部が、キャッシュメモリ１６として使用される。
【００３９】
ＣＰＵ１０は、内部バス１９を介し、メモリー１５、フラッシュメモリ１７、ＩＯブリッジ回路１８に接続される。このメモリー１５は、ＣＰＵ１０のワーク領域に使用され、フラッシュメモリ１７は、ＣＰＵ１０が実行するプログラムを格納する。このプログラムとして、カーネル、ＢＩＯＳ（Basic Input/Output System），ファイルアクセスプログラム（リード／ライトプログラム）、ＲＡＩＤ管理プログラム等を格納する。ＣＰＵ１０は、このプログラムを実行し、リード／ライト処理、ＲＡＩＤ管理処理等を実行する。
【００４０】
一対のＰＣＩ（Personal Computer Interface）バス２０、２１は、ＣＡ１１，１２と、ＤＡ１３，１４とを接続するとともに、ＩＯブリッジ回路１８を介し、ＣＰＵ１０、メモリー１５を接続する。更に、ＰＣＩバス２０、２１には、ＰＣＩ−ノードリンクブリッジ回路３０が接続される。
【００４１】
コントローラ１のＰＣＩ−ノードリンクブリッジ回路３０は、コントローラ２のＰＣＩ−ノードリンクブリッジ回路と接続され、コントローラ１，２間のコマンド、データの交信を行う。
【００４２】
例えば、コントローラ１は、デバイスエンクロージャー５−１〜５−４のデイスク装置５０を担当し、コントローラ２は、デバイスエンクロージャー５−５〜５−８のデイスク装置５０を担当する。図１では、デバイスエンクロージャー５−１〜５−４のデイスク装置５０と、デバイスエンクロージャー５−５〜５−８のデイスク装置５０とが、ＲＡＩＤ５の構成を有する。
【００４３】
キャッシュメモリ１６は、各々、担当するデイスク装置のデータの一部を格納し、ホストからのライトデータを格納する。ＣＰＵ１０は、ＣＡ１１，１２を介しホストからのリード要求を受けて、キャッシュメモリ１６を参照し、物理デイスクへのアクセスが必要かを判定し、必要であれば、デイスクアクセス要求をＤＡ１３，１４に要求する。
【００４４】
又、ＣＰＵ１０は、ホストからのライト要求を受けて、ライトデータをキャッシュメモリ１６に書込み、且つ内部でスケジュールされるライトバック等をＤＡ１３，１４に要求する。
【００４５】
［動的システム負荷管理構成］
図２は、図１のＣＰＵ１０が実行するＩＯコマンド処理モジュールと負荷の関係図、図３は、図２のＩＯコマンド処理モジュールの構成図である。
【００４６】
図２に示すように、ＩＯコマンド処理は、大きく分けて、ストレージ装置へのアクセスが必要かを判定するフロントエンド処理モジュール４０、ストレージ装置へのアクセスの処理を行うバックエンド処理モジュール４４と、バックエンド処理モジュール４４へのＩＯコマンドの受け付け量を制御するＩ／Ｏ制御モジュール４２とからなる。フロントエンド処理モジュール４０は、キャッシュメモリ１６（図１参照）の参照、リード、ライトを行うキャッシュ制御モジュール４８を有する。
【００４７】
このバックエンド処理モジュール４４に対する負荷は、ホストＩ／Ｏによるものと、内部（ローカル）Ｉ／Ｏによるものである。ホスト３からのＩ／Ｏコマンドによるものとしては、ライトコマンド実行後のライトバック８１（キャッシュからのライトバック）のコマンド、プリフェッチ８２（リードされたデータの近辺のデータを前もってステージングする）のコマンド、ホストＩ／Ｏコマンド８３である。
【００４８】
内部コマンド（ローカルコマンド）としては、ホストからのコピー指示に応じて、順次コピーするワンポイントコピー８０によるコマンド、外部指示に応じて、ＲＡＩＤレベルを変更するマイグレーション８４によるコマンド、デイスクデバイスの増設による容量拡張のためのＬＤＥ（Logical Device Expansion）８５によるコマンド、物理デイスクのフォーマットをバックグラウンドで行うクイックフォーマット８６によるコマンド、再構築やコピーバック８７によるコマンドがある。
【００４９】
本発明では、Ｉ／Ｏ制御モジュール４２からの情報と、バックエンドモジュール４４からの情報に基づき、システム負荷を計算し、Ｉ／Ｏ制御モジュール４２を制御するシステム負荷管理モジュール４６を設けている。図３により、詳細に説明する。
【００５０】
図３に示すように、Ｉ／Ｏ制御モジュール４２は、ホスト−ＩＯ（Ｈ−ＩＯ）制御モジュール６０と、ローカルＩＯ（Ｌ−ＩＯ）制御モジュール６１とからなる。
【００５１】
ホスト−ＩＯ制御モジュール６０は、ホストＩ／Ｏの受付量を調節するモジュールである。フロントエンドモジュール４０のキャッシュ制御モジュール４８で、ミスヒット（対象データがキャッシュメモリ１６に存在しない）と判断した後にコールされ、システム負荷管理モジュール４６のシステム負荷状態を判断し、ホストＩ／Ｏの受付量を調節する。受付量の調節は、ホスト３へのBusy/Q-Full応答にて行う。
【００５２】
又、ローカルＩＯ制御モジュール６１は、ローカルＩ／Ｏの起動量を調節するモジュールである。ローカルＩ／Ｏを受け付けた時点で、システム負荷管理モジュール４６の負荷状態を判断し、起動量を調節する。起動量の調節は、待ち合わせ（キューイング）にて行う。
【００５３】
Ｉ／Ｏ制御モジュール４２で、起動許可されたＩ／Ｏコマンドに対し、ＢＥ（ＢａｃｋＥｎｄ）−ＡＣＢ(Access Control Block)の獲得処理６２で、ＢＥ−ＡＣＢが獲得され、バックエンドモジュール４４へのアクセスが可能となる。バックエンドモジュール４４では、Ｉ／Ｏコマンドの要求内容の解釈処理７０を行い、この解釈（デイスクへのコマンド分割）に従い、制御用の各資源の獲得処理７２が行われる。資源獲得処理７２は、内部バッファ領域（Extent）、ローカルバッファ、ワークメモリ等を獲得し、排他権を設定する。
【００５４】
この資源獲得後、Ｄｉｓｋ（デイスク）／ＦＣ（ファイバーチャネル）ドライバ７３にデイスクコマンドを発行する。ドライバ７３からＰＣＩバス２０（２１）より、ＤＡ１３（１４）に、デイスクコマンドが送信され、更に、ＦＣ＿ＡＬ４−１（４−２）を通して、磁気デイスク装置５０にデイスクコマンドが伝達される。これにより、磁気デイスク装置５０は、このデイスクコマンドを実行する。
【００５５】
一方、システム負荷管理モジュール４６は、流量予測モジュール７４と、実負荷管理モジュール７６と、負荷統計モジュール７８とからなる。流量予測モジュール７４は、ハード使用量の不確定な段階で、ハード使用量の予測を行う。即ち。流量予測モジュール７４は、バックエンドモジュール４４へＩ／Ｏを要求した時点で、Ｉ／Ｏ要求の各パラメータ(転送数／Read／Write／RAIDレベルなど)により一意な点数（ハード使用量の予測値）を計算し、負荷統計モジュール７８に情報（予測値）を反映する。
【００５６】
実負荷管理モジュール７６は、ハード使用量が確定した段階で、ハード使用量（実負荷）を計算する。即ち、実負荷管理モジュール７６は、デイスク装置５０／ＦＣ＿ＡＬ４−１(ハード)へ起動している転送量を管理し、ハードのタイムアウトが発生しないように起動調整する。またハードの実負荷情報を計算し、負荷統計モジュール７８に反映する。
【００５７】
負荷統計モジュール７８は、ＲＬＵ（Raid Logical Unit）単位で、負荷の統計を行い、過負荷状態に遷移したときに、Ｈ−ＩＯ/Ｌ−ＩＯ制御モジュール６０，６１に抑止通知を行う。
【００５８】
図４乃至図６は、システム負荷管理の動作説明図である。
【００５９】
図４に示すように、システム負荷管理モジュール４６のバックエンドの流量管理によって、バックエンドモジュール４４に発行できるコマンドサイズ上限が決定される。この上限以上のデータをバックエンドモジュール４４に発行しないために、ＩＯ制御モジュール４２により発行コマンドの制限を行う。ＩＯ制御モジュール４２は、前述のように、ホストＩ／Ｏを制限するＨ−ＩＯ制御モジュール６０と、ローカルＩ／Ｏを制限するＬ−ＩＯ制御モジュール６１で構成されている。
【００６０】
Ｉ／Ｏ要求を受け付けたＩＯ制御モジュール４２は、発行可能コマンドサイズ上限(閾値)をチェックし、閾値以下の場合には、即座にバックエンドモジュール４４にコマンドを発行するが、閾値以上の場合には、前に出したコマンドが完了し、バックエンドモジュール４４で実行中のコマンドサイズが閾値以下になるまで、コマンドの発行を抑止する。
【００６１】
抑止方法としては、ホストＩ／Ｏの場合には、コマンド発行元に対し、エラー復帰する。エラーを受けたフロントエンドモジュール４０は、ホスト３に対しQfull/BUSY等(設定による)を返す。ローカルＩ／Ｏの場合には、Ｌ−ＩＯ制御モジュール６１内で、コマンドはキューにつながれ、待ちあわせを行う。この場合、コマンド再実行のタイミングは、前のコマンドの実行完了時(バックエンドモジュール４４からの復帰時)に、再度閾値チェックを行った時となる。
【００６２】
図５に示すように、ホストＩ／Ｏについては、ホストＩ／Ｏの受け付け時に、キャッシュヒットデータについては制限を行わず、即時実行する。キャッシュミスヒットデータや、ライトバックデータついては、最終的にライトバックデータとしてＨ−ＩＯ制御モジュール６０を呼び出し、バックエンドモジュール４４へのコマンド投入可否を問い合わせる。プリフェッチ、リードデータについても、同様にＨ−ＩＯ制御モジュール６０を呼び出す。
【００６３】
一方、図６に示すように、システム負荷が１００％を超えた場合には、キャッシュシュ制御モジュール４８からＨ−ＩＯ制御モジュール６０への問い合わせに対し、BUSYエラー復帰する。キャッシュ制御モジュール４８は、BUSYエラーによって、上位へのエラー復帰、ライトバックの待ち合わせなどの異常処理を行う。
【００６４】
このように、システム負荷に従い、ホストＩ／Ｏについても管理を行うことで、システム性能以上のコマンド処理を受け付けない。又、Extent排他前に負荷管理を実施することで、ホストＩ／Ｏ処理を妨げない。
【００６５】
更に、デイスク装置に着目した流量管理を実施し、ハード性能以上のデイスクコマンド発行を抑止する。内部のタイマ監視と連携し、システム負荷を管理することで、内部タイムアウト多発(パス切れ)を防止する。
【００６６】
即ち、個々のホストＩ／Ｏ，ローカルＩ／Ｏ毎に負荷の重みを予測算出する管理と、ハード実負荷を、総合的に管理することで、システム全体の抱える負荷をリアルタイムに把握でき、システム性能をフルに引き出し，正確な負荷管理を実現できる。
【００６７】
又、これらの問題以外のＤＴＣの利点に関しては，そのまま継承する。即ち、ローカルＩ／Ｏを、より制限し、ホストＩ／Ｏ処理を極力妨げないようにする。システム負荷状態により、動的に内部Ｉ／Ｏ(デイスク装置へのコマンド)の発行数を制限する。更に、ＯＰＣとRebuild/Copybackについて、制御の違いを考慮し、別管理として負荷管理を実施する。
【００６８】
［システム負荷管理］
次に、前述のシステム負荷管理機構を使用した動的システム負荷管理を具体的に説明する。図７は、図２及び図３のシステム負荷管理モジュール４６の詳細構成図、図８は、図７の実負荷管理モジュール７６のテーブル構成図、図９は、図７の総合（システム）負荷の説明図、図１０は、図８の実負荷の説明図である。
【００６９】
先ず、図３及び図７に示すように、流量予測モジュール７４は、前述のように、ハード使用量の不確定の段階で、負荷予測を行う。この予測において、個々のＩ／Ｏ要求は、要求転送長、ＲＡＩＤの種類、コマンド種別等により、使用するデイスク装置の位置やＦＣ＿ＡＬループなどが異なり、また，ハードを占有する時間も異なる。
【００７０】
そのため、ホストのアクセス単位であるＲＬＵ（Ｒａｉｄ Ｌｏｇｉｃａｌ Ｕｎｉｔ）単位の負荷を正確にもとめるには、個々のＩ／Ｏ要求が持つ、これら各ハードを、それぞれどのくらい使用するかという情報を、ハード資源単位(個々のデイスク装置／ファィバーチャネル単位)に統計を行い、各ＲＬＵを構成するハード資源の統計値を元に、ＲＬＵ単位の負荷率を求める必要がある。
【００７１】
しかし、Ｉ／Ｏ要求が、各ハードをそれぞれどのくらい使用するかという情報は、要求受け付け時点では確定せず、要求内容を解釈し、制御用の各資源を獲得し、ハード(デイスク装置)毎に、コマンドを分割して始めて判断できる。即ち、図３のデイスクドライバへ起動する直前に判明する。
【００７２】
予測負荷は、Ｉ／Ｏ要求受け付け時点〜デイスクドライバ７３へコマンド起動するまでの、ハード使用量が不確定なフェーズ（図３参照）で予測するため、要求転送長、ＲＡＩＤの種類、コマンド種別などのパラメータから、ハード使用量を予測する方法にて統計を行う。
【００７３】
なお、この予測値は、デイスクドライバ７３へのコマンド起動前の実際のハード使用量が確定した時点で、実負荷管理モジュール７６による実際のハード使用量へと変わり、統計に反映される。
【００７４】
この流量予測モジュール７４の予測値の統計は、ＲＬＵ単位である。即ち、図９に示すように、あるＲＬＵに起動された１つのコマンドだけを考えると、ＲＬＵを構成する一部のデイスク装置のみの起動であり、ＲＬＵとしてはアクセスの偏りが生じている。しかし、本来ＲＡＩＤは，ストライピング手法を採用しており、特定デイスク装置へのアクセスの集中を防止し、負荷を分散させ、性能を向上させている。このため、フロントエンドモジュール４０から複数のコマンドが起動され、バックエンドの負荷が上がる程、構成する各デイスク装置の負荷は分散し、均等化される。
【００７５】
これを利用し、流量予測モジュール７４は、個々のデイスク装置単位で統計を行うのではなく、低負荷時には多少の誤差が生じるが、煩雑な処理を行う必要がないＲＬＵ単位による統計を行い、処理の高速化を図る。そして、ＲＬＵ単位に統計を行った場合、個々のデイスク装置の負荷は、ＲＡＩＤ（ＲＬＵ）を構成するデイスク装置の台数分の1という値で求める。
【００７６】
流量予測モジュール７４は、ＲＬＵ単位の加点制を採用し、フロントエンドモジュール４０から起動されたパラメータをもとに、負荷要素であるデイスクコマンド数とデータ転送数の予測値を求め、それを時間換算し、最終的に１μｓ当たり１点として統計を行う。具体的に、説明する。
【００７７】
先ず、デイスクコマンド数によるハード使用量の予測値は、デイスク装置の平均アクセス時間×デイスク装置へのコマンド数から計算する。例えば、デイスク装置への１コマンドに対する平均アクセス時間を、５ｍｓとすると、デイスク装置への１コマンドは、５ｍｓ＝５，０００点に換算する。又、デイスク装置のコマンド数は、フロントエンドモジュール４０から起動されたデータ数を元に求める。
【００７８】
データ転送数によるハード使用量の予測値は、デイスク装置とＦＣ＿ＡＬの転送能力から、１Blockの点数を予め求めておき、この点数に、転送ブロック数を掛けて、計算する。そして、Ｉ／Ｏ要求の予測負荷（予測点数）は、ＲＬＵ単位で、以下のようにして計算する。
【００７９】
予測点数＝（デイスクコマンド数による予測点数＋データ転送数による予測点数）／（ＲＬＵ構成デイスク装置台数）
図１の実施の形態の構成での例により、更に、具体的に、説明する。先ず、転送能力を説明する。図１のＣＰＵ１０からデイスク装置５０へのルートは、ＰＣＩバス２０，２１、ＦＣ＿ＡＬ４−１，デイスク装置５０のルートである。各ルート要素の転送能力が、転送能力となる。
【００８０】
先ず、図１のＰＣＩバス能力の論理値は５２８MB/ｓであるが、実測では、約２００MB/ｓである。図１の構成では、コントローラ当り２本のＰＣＩバス２０，２１が実装されており、各ＰＣＩバスには５個のＰＣＩデバイス１１，１２，１３，１４，３０が接続されている。これを元に，１個のデバイス（ＤＡ１３，１４）が使用できる能力を計算すると、２００ＭＢ/s÷５＝４０ＭＢ／ｓとなる。
【００８１】
次に、バックエンドのＦＣ＿ＡＬ能力は２００ＭＢ/sであるが、両コントローラから同時にアクセスした場合、2分の１の性能となるため、ＦＣ１ポート当り１００MB/ｓとなる。ただし、ＰＣＩ転送能力が性能ネックとなるため、ＦＣ能力は、ＰＣＩ能力と同じ４０ＭＢ／ｓとなる。
【００８２】
更に、図１のデイスク装置単体のデータ転送能力は、約５０ＭＢ/s〜８０MB/ｓであるが、ＦＣ１ポートには１〜６０台のデイスク装置５０が接続されるため、デイスク装置１台当りのデータ転送能力は、ＦＣ能力を，接続(担当する)デイスク装置の台数で分割した能力と考える。
【００８３】
そのため、デイスク装置１台当りのデータ転送能力は、４０ＭＢ／ｓ÷接続（担当する）デイスク装置の台数となる。例えば、２つのコントローラ１，２で、８つのデバイスエンクロージャー５−１〜５−８(デイスク装置１２０台)の構成時、ＦＣ１ポート当り担当するデイスク装置は通常３０台のため、デイスク装置１台のデータ転送能力は、１．３３ＭＢ／ｓ（＝４０÷３０）となる。
【００８４】
又、デイスク装置５０の１コマンド当りの処理時間は、前述の平均アクセス時間の５ｍｓとする。同様に、デイスク装置５０のコマンド処理能力を考えると、デイスク装置５０に、アクセス速度を向上するためのコマンド並び替え機能があるため、デイスク装置へ多数のコマンドを起動した方が、性能が向上する。
【００８５】
ただし、あまり多くのコマンドを起動しすぎると、デイスク装置内のファームオーバヘッドが増加し、性能がダウンしてしまう。図１のデイスク装置の測定では、約８０個のコマンドを、デイスク装置へ起動したときに最大性能がでていることが判明したため、デイスク装置５０のコマンド能力は、８０個とする。
【００８６】
例えば、２ＣＭ（コントローラ）−８ＤＥ（デバイスエンクロージャー）モデルの場合、ＦＣポート当たり３０台のデイスク装置５０を担当したとすると、ＦＣ能力４０ＭＢ／ｓを、３０台で割った１．３３ＭＢ／ｓが、デイスク装置単体のデータ転送能力であり、１Ｂｌｏｃｋ（＝５１２Ｂｙｔｅ）当り，３７６点(３７６μｓ)となる。
【００８７】
起動時のパラメータ（要求転送量、ＲＡＩＤ構成、コマンド種別）により、デイスクコマンド点数、データ転送点数は、実際の処理同様に計算される。例えば、ＲＡＩＤ５(3+1, Normal)、４０ＫＢのＲｅａｄコマンドの場合には、予測点数は、以下のように計算される。
【００８８】
デイスクコマンド点数：80Block(40KB)÷2×5ms×1＝200ms(200,000点)
データ転送点数 ：80Block(40KB)×376×1＝30,080点
予測点数合計230,080点 (１デイスク当り57,520点)
次に、実負荷管理モジュール７６を説明する。フロントモジュール４０からのＲＬＵに対する１つの要求は、複数(または１つ)のデイスク(ＦＣ)コマンドへ変換されデイスクドライバ７３（図３参照）へ起動される。この時点になると、ハード使用量は、予測によるものではなく、実際のハード使用量が確定する。実負荷管理モジュール７６は、各ハード資源の性能限界時(ハード能力限界点)の調節用の情報としても使用するため、予測時に行うＲＬＵ単位の統計ではなく、各ハード資源単位（デイスク装置単位）での統計を実施する。
【００８９】
実負荷管理モジュール７６の統計は、図７に示すように、デイスク装置単位の加点制で、デイスクドライバ７３−１へ起動されたデータ転送数を時間換算し、点数は、流量予測モジュール７４と同じく、１μｓ当り１点として統計を行う。
【００９０】
具体的には、デイスク装置５０への１コマンドは、５ｍｓ(平均アクセスTime)と考え，５，０００点とする。又、流量予測モジュール７４と同様に、デイスク／ＦＣの転送能力から１Blockの点数を予め求めておき、それを元に加点する。この１Blockの点数は、前述と同様に、３７６点である。そして、前述の予測と同様に、デイスク装置単位で、デイスクコマンド点数と、データ転送点数を求め、これを加算して、実負荷点数を計算する。
【００９１】
更に、ハード能力限界点を超えるＩ／Ｏ要求をハードへ依頼すると、デイスク装置のタイムアウトが発生してしまうため、実負荷管理モジュール７６は、バックエンドモジュール４４から起動されたつぶつぶのＩ／Ｏ要求毎に、対象のデイスク装置負荷が、ハード能力を超えないよう管理を行う。
【００９２】
図１０に示すように、実負荷管理モジュール７６は、ハード能力超えをチェックした結果、ハード能力以下の場合は、ハードに起動をかけ、ハード能力を超えている場合は、デイスクドライバ７３−１で負荷が下がるのを待つ待ち合わせ（キューイング）を行う。その後、デイスク装置５０からの終了割込みの延長で、負荷がハード能力以下となった場合に、待ち合わせ中のＩ／Ｏ要求をハード能力限界まで起動する。
【００９３】
実負荷管理モジュール７６のハード能力限界の判断は、図８に示すように、デイスク装置単位に、以下の２つの要素毎に量を管理し、それぞれの閾値をチェックすることで、ハード能力限界を超えたかどうか判断する。
【００９４】
図８に示すように、各デイスク装置単位のテーブル７６−１は、実負荷ポイントとして、ハード限界能力ポイント（＝ＦＣ性能(４０ＭＢ/S)÷デイスク装置台数×４秒）、実負荷のトータルポイント、実行中ポイント（図１０のＦＣドライバ７３−２起動後の負荷ポイント）、待ちポイント（図１０のデイスクドライバ７３−１起動後、ＦＣドライバ７３−２起動前の待ち負荷ポイント）とで、デイスクドライバを管理し、デイスク装置のコマンド数として、限界コマンド数（８０コマンド）、トータルコマンド数、実行中コマンド数（図１０のＦＣドライバ７３−２起動後のコマンド数ポイント）、待ちコマンド数（図１０のデイスクドライバ７３−１起動後、ＦＣドライバ７３−２起動前の待ちコマンド数ポイント）を管理する。
【００９５】
即ち、実負荷管理モジュール７６は、バックエンドモジュール４４からデイスクドライバ７３−１に、デイスクコマンドが発行されると、前述のコマンド数ポイントと、データ転送数ポイントを計算し、更に、実負荷ポイントを計算する。そして、実負荷管理モジュール７６は、テーブル７６−１の待ちポイント、トータルポイントを更新する。図１０に示すように、デイスクドライバ７３−１からＦＣドライバ７３−２に、デイスクコマンドが起動されると、テーブル７６−１の待ちポイント、実行中ポイントに移す。
【００９６】
次に、図７に戻り、予測負荷と実負荷との統合を行う負荷統計モジュール７８を説明する。負荷統計モジュール７８は、予測負荷と実負荷の統合を、負荷チェックがＲＬＵ単位であり負荷チェック時の処理を軽くするため、ＲＬＵ単位で管理する。
【００９７】
ただし、図７及び図９に示すように、負荷統計モジュール７８の統計は、ＲＬＵに属するデイスク装置の中で一番負荷が高いものを代表として管理する。ＲＬＵに属するデイスク装置内の負荷が変動し、負荷が一番高いデイスク装置番号が変わった場合は、代表のデイスク装置も入れ換え処理を実施し、常に一番負荷の高いデイスク装置を代表とする。
【００９８】
負荷統計モジュール７８が、図７に示すように、予想負荷点と実負荷点を合算して、総合負荷点を計算する。総合負荷点を計算するタイミングは、予測負荷、または、実負荷が更新されるたび(即ち、内部Ｉ／Ｏが処理されるたび)に行うことができる。又、更新毎に行うと処理が重くなるため、以下のタイミング時にのみ実施すると良い。
【００９９】
（１）ＲＬＵ単位の予測負荷点が、毎500,000ポイント境界を跨ぎ変動した場合。
【０１００】
（２）実負荷の代表デイスク装置(一番高負荷なデイスク装置)が入換わった場合(尚、代表デイスク装置の入換えは、各デイスク装置の値が100,000ポイント境界を跨いだときに、代表デイスク装置のポイントと比較し、代表を超えていた場合に実施する)。
【０１０１】
（３）実負荷の代表デイスク装置の値が、100,000ポイント境界を跨ぎ変動した場合。
【０１０２】
図７の負荷統計モジュール７８の閾点は、システム能力限界点を設定する。例えば、コントローラ間通信のタイマ値である20秒(20,000,000μｓ)から求めた値、20,000,000点とする。
【０１０３】
又、負荷統計モジュール７８は、負荷の割合(％)を求めることができる。負荷の割合は、（総合負荷点÷閾点×１００）の式で計算する。
【０１０４】
［動的システム負荷制御］
図１１は、図３のＨ−ＩＯ制御モジュール６０のホストＩ／Ｏ処理フロー図、図１２は、図７及び図８で説明したハード能力限界点とシステム能力限界点の説明図、図１３は、図１１のＨ−ＩＯ制御モジュール６０とシステム負荷管理モジュール４６の処理の流れ図、図１４は、ＩＯ制御モジュール４２とシステム負荷管理モジュール４６の処理の流れ図である。
【０１０５】
図１２に示すように、システムの負荷が高くなると、次の２つの限界点が現れる。第１は、ハード能力限界点である。即ち、これ以上ハードに処理を要求しても、ハードの処理能力をオーバしてしまい、特定時間以内に処理が完了しなくなる境界点である。例えば、デイスク装置の能力が、１０ＭＢ／ｓの能力であり、ハード処理の時間監視を５秒とした場合、５０ＭＢの要求を超えると、ハードのタイムアウトが発生してしまう。ハード能力限界点に達した場合、オーバした要求は、前述のドライバ７３で待たせる。
【０１０６】
例えば、デイスク装置の時間監視が７秒であり、そのうち３秒をデイスク装置内のコマンド並び替え、ポジショニング等の時間として、残り４秒をデータ転送分と考えた場合、ハード能力限界点は、４秒(4,000,000μｓ)から求め、４，０００，０００点とする。
【０１０７】
第２に、システム能力限界点である。ハード能力の限界を超えてもさらに要求がき続けた場合、ドライバ７３で待ちが出始め、システムの監視時間(ＣＡ１１，１２のコマンドタイムアウト検出(２５秒)、または、コントローラ間のタイムアウト(２０秒))以内に、処理が完了しなくなる境界点を、システム能力限界点という。システム能力限界点に達した場合、オーバしたホスト要求は、前述のBusy/Q-Fullで、ホスト応答させる。また、ローカルＩ／Ｏの場合は、負荷が限界点を下回るまで要求を待たせる。
【０１０８】
例えば、フロントモジュール４０で行っているホストコマンド処理の時間監視が２５秒、コントローラ間を跨いだクロスアクセス時のコントローラ間通信の時間監視が２０秒である場合には、システム能力限界点は、短い方の２０秒(20,000,000μｓ)から求め、２０，０００，０００点となる。
【０１０９】
次に、システム負荷制御を、図１１のＩ／Ｏ制御モジュール４２の処理フロー図及び図１３のＩ／Ｏ制御モジュール４２とシステム負荷管理モジュール４６の処理フロー図で説明する。
【０１１０】
（Ｓ１０）Ｉ／Ｏ制御モジュール４２は、Ｉ／Ｏ要求を受け付けると、システム負荷管理モジュール４６から負荷統計モジュール７８の総合負荷点と閾点（図７参照）を問い合わせる。
【０１１１】
（Ｓ１２）Ｉ／Ｏ制御モジュール４２は、総合負荷点が、閾点（システム能力限界点）を超えているかを判定する。
【０１１２】
（Ｓ１４）総合負荷点が、閾点を越えている場合には、図４、図６、図１２で説明したように、システム負荷が高負荷のため、ホストに、Ｂｕｓｙ／Ｑｆｕｌｌを返答し、バックエンドへの起動を行わず、終了する。
【０１１３】
（Ｓ１６）総合負荷点が、閾点を越えていない場合には、図５で説明したように、システム負荷が高負荷でないため、バックエンドモジュール４４へＩ／Ｏ要求を発行し、終了する。
【０１１４】
図１３で具体的に説明する。過負荷でない通常負荷の場合には、ホスト３からのリード要求が、フロントエンドモジュール４０でキャッシュヒットと判定されると、キャッシュメモリ１６のデータがホスト３に転送され、流量管理の対象とならない。
【０１１５】
リード要求でも、キャッシュミスヒットの場合には、バックエンドモジュール４４へリード要求が発行されるとともに、流量予測モジュール７４で負荷予測値を計算され、負荷統計モジュール７８の予測値に加算される。更に、実負荷モジュール７６は、予測値を減点し、これを実負荷点に加点する（減点した予測値を実負荷値に移す）。Ｉ／ＯでのＩ／Ｏ処理が終了すると、実負荷点を減点する。これとともに、デイスク装置からホストへリードデータが転送される。
【０１１６】
同様に、過負荷でない通常負荷の場合には、ホスト３からのライト要求が到来すると、フロントエンドモジュール４０でキャッシュメモリ１６に、ライトデータが書き込まれ、流量管理の対象とならない。
【０１１７】
ライトバック等のローカルＩ／Ｏ要求は、バックエンドモジュール４４へ伝達されるとともに、流量予測モジュール７４で負荷予測値を計算され、負荷統計モジュール７８の予測値に加算される。更に、実負荷モジュール７６は、予測値を減点し、これを実負荷点に加点する（減点した予測値を実負荷値に移す）。Ｉ／ＯでのＩ／Ｏ処理が終了すると、実負荷点を減点する。これとともに、デイスク装置からホストへライト完了が転送される。
【０１１８】
一方、過負荷の場合には、ホスト３からのリード要求が、フロントエンドモジュール４０でキャッシュヒットと判定されると、キャッシュメモリ１６のデータがホスト３に転送され、流量管理の対象とならないが、リード要求でも、キャッシュミスヒットの場合には、バックエンドモジュール４４へリード要求が発行されず、ホスト３へＢｕｓｙ／Ｑｆｕｌｌが返答される。ライトバックを含むローカルＩ／Ｏも、Ｌ−ＩＯ制御モジュール６１で、待ちキューに待ち合わせされる。
【０１１９】
次に、図１４により、ハード能力限界制御を説明する。バックエンドモジュール４４で、デイスクコマンドが作成されると、前述のように、実負荷管理モジュール７６で、各デイスク装置毎のテーブル７６−１を参照し、ハード能力点をチエックする。即ち、実負荷管理モジュール７６は、トータルポイント又はトータルコマンド数のいずれかが、限界値を越えているかを判定し、越えていないと、テーブル７６−１の実行中ポイント、実行中コマンド数に加点し、Ｉ／Ｏを起動する。
【０１２０】
一方、限界値を越えていると、テーブル７６−１の待ちポイント、待ちコマンド数に加点し、待ちキューに待ち合わせする。これを、デイスクコマンド分繰り返し、終了する。
【０１２１】
又、起動Ｉ／Ｏから終結割り込みが、デイスク／ＦＣドライバ７３に到来すると、実負荷管理モジュール７６は、実行中ポイント、実行中コマンド数を減点する。デイスク／ＦＣドライバ７３は、待ちキューに待ちコマンドがあるかを判定し、無ければ、終了する。
【０１２２】
待ちキューに待ちコマンドがあると、待ちキューの先頭を参照し、実負荷管理モジュール７６で、各デイスク装置毎のテーブル７６−１を参照し、ハード能力点をチエックする。即ち、実負荷管理モジュール７６は、トータルポイント又はトータルコマンド数のいずれかが、限界値を越えているかを判定し、越えていないと、テーブル７６−１の待ちポイント、待ちコマンド数を減点し、且つ実行中ポイント、実行中コマンド数に加点し、待ちキューの先頭をデキューし、Ｉ／Ｏを起動する。
【０１２３】
一方、限界値を越えていると、このルーチンを脱出する。
【０１２４】
［閾値調整処理］
次に、ローカルＩ／Ｏの割合を制御する閾値調整処理を説明する。図１５は、Ｌ−ＩＯ制御モジュール６１とシステム負荷管理モジュール４６との関係図、図１６は、システム負荷とローカルＩ／Ｏの閾値の説明図である。ここでは、ローカルＩ／Ｏの閾値を可変に制御する。
【０１２５】
図１５に示すように、負荷統計(RLU)モジュール７８で負荷割合（＝（総合負荷数÷閾点）×１００）からローカルＩ／Ｏの閾値（割合）を計算する。Ｌ−ＩＯ制御モジュール６１は、このローカルＩ／Ｏの閾値を取得し、（アクセス対象ＲＬＵに関する現在のコマンドサイズ＋これから発行しようとするコマンドサイズ）が，この閾値を超えているかどうかを判断する。
【０１２６】
このローカルＩ／Ｏの制御アルゴリズムとして、ホストＩ／Ｏを最優先とするため、ホストＩ／ＯとローカルＩ／Ｏとで閾値に違いを持たせ、ローカルＩ／Ｏを早期に制限する。即ち、ホストＩ／Ｏがあるときには、極力ローカルＩ／Ｏの割合を下げるが、ホストＩ／Ｏがないときには，ローカルＩ／Ｏをできるだけ実行する。
【０１２７】
このために、Ｌ−ＩＯ制御モジュール６１は、図１６に示すように、ローカルＩ／Ｏの負荷全体に占める割合を制限し、最大でも閾値の７０％(Webから設定可能な値)とし、ホストＩ／Ｏがある場合には、システム負荷が閾値の６０％を超えた時点で、ローカルＩ／Ｏの割合を制限する。
【０１２８】
又、ホストＩ／Ｏの負荷割合が非常に高くなった場合でも、最低限のローカルＩ／Ｏを実行するために、ローカルＩ／Ｏの最低閾値を１０％と制御する。全体負荷が低くなるに応じて、ローカルＩ／Ｏの割合の制限をやめ、最終的には，閾値の最大の７０％に戻す。
【０１２９】
更に、ＯＰＣなど完了時間保証しなければならないローカルＩ／Ｏについては、時間保証に必要な転送性能を確保するために、最低限、一定時間毎にコマンドを実行するように制御する。ローカルＩ／Ｏの閾値を変動させるタイミングは、ローカルＩ／Ｏコマンド発行時と完了時とする。
【０１３０】
図１６で説明すると、記号「▼」は、ホストＩ／Ｏがあり、システム負荷が６０％を超えたため、ローカルＩ／Ｏの割合を下げる。記号「△」は、システム負荷が５０％以下となったため、ローカルＩ／Ｏの割合を上げる(但し、６０％までとする)。記号「△2」は、ホストＩ／Ｏ負荷がないため、ローカルＩ／Ｏの割合を７０％まで戻す。
【０１３１】
又、図３及び図１５のＬ−ＩＯ制御モジュール６１は、キューの優先度制御を行う。即ち、待ち合わせキューには、優先度を持ったものを３種類持ち、どのキューにも、待ち合わせコマンドが存在する場合には、優先度の高いコマンドから実行する。
【０１３２】
キューの種別としては、以下の３種類のものがある。
【０１３３】
優先度高(時間保証あり)のキューは、ＣＧＩから設定可能な２種類のモード(時間優先設定、ホストI/O優先)を持ち、時間優先の場合には、さらにコマンド完了通知をまたずに一定時間毎にバックエンドモジュールにコマンド発行する。この結果、システム負荷の上昇が懸念されるが、その場合には、ホストＩ／Ｏを制限することで、時間保証を行う。対象Ｉ／Ｏは、ＯＰＣである。
【０１３４】
次に、優先度高(時間保証無し)のキューは、優先度低のキューに優先し実行するが、時間保証は行わず、ホストＩ／Ｏをより優先させる。対象Ｉ／Ｏは、Rebuild/Copyback、LDE、Migrationである。
【０１３５】
更に、優先度低のキューは、優先度高のキューがある場合には実行しないキューであり、対象Ｉ／Ｏは、Quick Formatである。
【０１３６】
次に、Ｌ−ＩＯ制御モジュール６１が、自己で閾値管理を行う場合のローカルＩ／Ｏ処理を説明する。図１７及び図１８は、Ｌ−ＩＯ制御モジュール６１の処理フロー図である。前述のように、Ｌ−ＩＯ制御モジュール６１は、ローカルＩ／Ｏの起動量を調節するモジュールであり、ローカルＩ／Ｏを受け付けた時点で、システム負荷管理モジュール４６の負荷状態を判断し、起動量を調節する。起動量の調節は、待ち合わせ（キューイング）にて行う。
【０１３７】
図１７は、ローカルＩ／Ｏとして、Rebuildで説明する。ローカルＩ／Ｏ実行時には、Extent排他前に，Ｌ−ＩＯ制御モジュール６１を呼び出し、コマンド発行可能かどうかをチエックする。
【０１３８】
図１７に示すように、Rebuild８７で、ローカルＩ／Ｏのコマンドを作成すると、Ｌ−ＩＯ制御モジュール６１に問い合わせる。Ｌ−ＩＯ制御モジュール６１は、システム負荷管理モジュール４６の流量予測モジュール７４で、予測値を計算させ、負荷統計モジュール７８の予測値に加点する。
【０１３９】
Ｌ−ＩＯ制御モジュール６１は、前述の図１５のローカルＩ／Ｏ実行の閾値を超えているかを判定し、越えている場合には、Ｌ−ＩＯ制御モジュール６１に対し発行したコマンドは、Ｌ−ＩＯ制御モジュール６１内でキューされる。一方、ローカルＩ／Ｏ実行の閾値を越えていない場合には、Rebuild８７にコマンド実行を指示し、Rebuild８７が、バックエンドモジュール４４に、Ｉ／Ｏ起動を行う。
【０１４０】
又、図１８に示すように、バックエンドモジュール４４へのコマンドにより、Ｉ／Ｏが完了すると、Rebuild８７に通知される。これにより、システム負荷管理モジュール４６は、これにより、実負荷値を減算する。
【０１４１】
そして、Ｌ−ＩＯ制御モジュール６１は、次のコマンドを待ちキューから外し、前述の図１５のローカルＩ／Ｏ実行の閾値を超えているかを判定し、越えている場合には、Ｌ−ＩＯ制御モジュール６１に対し発行したコマンドは、Ｌ−ＩＯ制御モジュール６１内でキューされる。一方、ローカルＩ／Ｏ実行の閾値を越えていない場合には、Rebuild８７にコマンド実行を指示し、Rebuild８７が、バックエンドモジュール４４に、Ｉ／Ｏ起動を行う。
【０１４２】
このように、Ｌ−ＩＯ制御モジュール６１は、自己の閾値内で、ローカルＩ／Ｏの発行の調整を行い、バックエンドの負荷が閾値以下になり、ローカルＩ／Ｏが実行できる状態になると、次のステージ（コマンド）が呼び出される。これにより、ローカルＩ／Ｏについても、図３に示した、Extent排他獲得処理７２、及びバックエンド４４へのコマンド発行処理が継続される。
【０１４３】
尚、ホストＩ／Ｏを実行するために必要なローカルＩ／Ｏについては、ホストＩ／Ｏと同様に，Ｈ−ＩＯ制御モジュール６０を使用する。この時、ホストＩ／Ｏを実行するために必要なコマンドが，すでにＬ−ＩＯ制御モジュール６１内にキューイングされている場合には、即時実行させることができる。
【０１４４】
［他の実施の形態］
前述の実施の形態では、図１のような冗長構成のＲＡＩＤで説明したが、これ以外の冗長構成のストレージシステムに適用できる。又、物理デイスクは、磁気デイスク、光デイスク、光磁気デイスク、各種のストレージデバイスを適用できる。
【０１４５】
又、システム負荷として、コマンドの処理量を、予測値と実負荷値の両方で管理しているが、予測値を使用しても良い。
【０１４６】
以上、本発明を実施の形態により説明したが、本発明の趣旨の範囲内において、本発明は、種々の変形が可能であり、本発明の範囲からこれらを排除するものではない。
【０１４７】
（付記１）ホストから依頼されたＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムにおいて、前記Ｉ／Ｏ要求に応じたコマンド処理を実行するコマンド処理部と、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行部とを有し、前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測するととともに、前記アクセス実行部の実際の負荷を管理し、前記予測負荷と前記実際の負荷とからシステム負荷を計算し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止することを特徴とするストレージシステム。
【０１４８】
（付記２）前記コマンド処理部は、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整し、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行部を起動することを特徴とする付記１のストレージシステム。
【０１４９】
（付記３）前記コマンド処理部は、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御モジュールと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御モジュールとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせることを特徴とする付記２のストレージシステム。
【０１５０】
（付記４）前記コマンド処理部は、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得ることを特徴とする付記１のストレージシステム。
【０１５１】
（付記５）前記コマンド処理部は、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御することを特徴とする付記１のストレージシステム。
【０１５２】
（付記６）前記コマンド処理部は、前記実際の負荷に応じて、前記アクセス実行部のコマンド処理量を制御することを特徴とする付記１のストレージシステム。
【０１５３】
（付記７）前記コマンド処理部は、ハードウェアで規定される前記アクセス実行部の単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測することを特徴とする付記１のストレージシステム。
【０１５４】
（付記８）前記ストレージ装置のデータの一部を保持するキャッシュメモリを更に設け、前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止することを特徴とする付記１のストレージシステム。
【０１５５】
（付記９）前記コマンド処理部は、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロントモジュールと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御モジュールと、前記ＩＯ制御モジュールで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドモジュールとを有することを特徴とする付記８のストレージシステム。
【０１５６】
（付記１０）前記コマンド処理部は、前記依頼されたＩ／Ｏ要求の前記アクセス実行部の負荷を予測する流量予測モジュールと、前記アクセス実行部の実際の負荷を管理する実負荷管理モジュールと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計モジュールとを有することを特徴とする付記１のストレージシステム。
【０１５７】
（付記１１）ホストから依頼されたＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムの動的システム負荷管理方法において、前記Ｉ／Ｏ要求に応じたコマンド処理を実行するコマンド処理ステップと、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行ステップと、前記依頼されたＩ／Ｏ要求の前記アクセス実行ステップの負荷を予測するととともに、前記アクセス実行ステップの実際の負荷を管理し、前記予測負荷と前記実際の負荷とからシステム負荷を計算するシステム負荷計算ステップと、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップとを有することを特徴とする動的システム負荷管理方法。
【０１５８】
（付記１２）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求と内部Ｉ／Ｏ要求とを、前記システム負荷に従い、調整するステップと、調整されたＩ／Ｏ要求の解析、資源獲得処理を行い、前記アクセス実行ステップを起動するステップとを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１５９】
（付記１３）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求を調整する第１のＩ／Ｏ制御ステップと、前記内部Ｉ／Ｏ要求を調整する第２のＩ／Ｏ制御ステップとを有し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するとともに、前記内部Ｉ／Ｏ要求を待ち合わせることを特徴とする付記１２の動的システム負荷管理方法。
【０１６０】
（付記１４）前記システム負荷計算ステップは、前記Ｉ／Ｏ要求のパラメータから前記ストレージ装置を含むアクセス実行部の処理時間を予測し、前記予測負荷を得るとともに、前記コマンド処理結果から前記ストレージ装置を含むアクセス実行部の処理時間を計算し、前記実際の負荷を得るステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６１】
（付記１５）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求を優先するとともに、前記システム負荷から、前記内部Ｉ／Ｏ処理の前記システム負荷に対する割合を制御するステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６２】
（付記１６）前記コマンド処理ステップは、前記実際の負荷に応じて、前記アクセス実行ステップのコマンド処理量を制御するステップを更に有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６３】
（付記１７）前記システム負荷計算ステップは、ハードウェアで実行される前記アクセス実行ステップの単位処理時間と、前記Ｉ／Ｏ要求の処理数とから前記負荷を予測するステップを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６４】
（付記１８）前記コマンド処理ステップは、前記Ｉ／Ｏ要求に対し、前記ストレージ装置のデータの一部を保持するキャッシュメモリを参照するステップを有し、前記抑止ステップは、前記キャッシュメモリで処理できないホストＩ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップからなることを特徴とする付記１１の動的システム負荷管理方法。
【０１６５】
（付記１９）前記コマンド処理ステップは、前記ホストＩ／Ｏ要求に対し、キャッシュメモリを参照して、前記キャッシュメモリで処理するフロント処理ステップと、前記キャッシュメモリで処理できないホストＩ／Ｏと内部Ｉ／Ｏに対し、前記システム負荷が所定の閾値を越えた場合に、前記ホストＩ／Ｏ要求の受け付けを抑止するＩＯ制御ステップと、前記ＩＯ制御ステップで調整されたＩ／Ｏ要求の解析及び資源獲得を行うバックエンドステップとを有することを特徴とする付記１８の動的システム管理方法。
【０１６６】
（付記２０）前記システム負荷計算ステップは、前記依頼されたＩ／Ｏ要求の前記アクセス実行ステップの負荷を予測する流量予測ステップと、前記アクセス実行ステップの実際の負荷を管理する実負荷管理ステップと、前記予測負荷と前記実際の負荷とからシステム負荷を計算する負荷統計ステップとを有することを特徴とする付記１１の動的システム負荷管理方法。
【０１６７】
【発明の効果】
このように、本発明では、従来、ストレージシステムで管理していなかったホストＩ／Ｏ要求を、ストレージシステムのシステム負荷に応じて管理し、システム負荷を越えるホストＩ／Ｏ要求に対しては、ホストＩ／Ｏ要求を処理せず、エラー応答し、ホストにコマンドのリトライを行わせるようにした。これにより、システム内でのコマンド処理の停滞を抑止できる。
【０１６８】
又、システム負荷を、アクセス実行前と後との両方の負荷から計算するため、正確にシステム自体の負荷を管理できる。
【図面の簡単な説明】
【図１】本発明の一実施の形態のストレージシステムの構成図である。
【図２】本発明の一実施の形態のコマンド処理部の構成図である。
【図３】図２の本発明の一実施の形態のコマンド処理部の詳細構成図である。
【図４】図２のＩＯ制御部の動作説明図である。
【図５】図４のＨ−ＩＯ制御部の低負荷時の動作説明図である。
【図６】図４のＨ−ＩＯ制御部の高負荷時の動作説明図である。
【図７】図３のシステム負荷管理部の構成図である。
【図８】図７の実負荷管理部のテーブルの説明図である。
【図９】図７のＲＬＵ負荷の説明図である。
【図１０】図７の実負荷管理部の実負荷の説明図である。
【図１１】図４のＨ−ＩＯ制御部の処理フロー図である。
【図１２】図７の能力限界点の説明図である。
【図１３】図３のＩＯ制御部とシステム負荷管理部との処理の流れ図である。
【図１４】図３のシステム負荷管理部とバックエンドモジュールの処理の流れ図である。
【図１５】図３のＬ−ＩＯ制御部の説明図である。
【図１６】図１５のローカルＩ／Ｏ要求の閾値制御の動作説明図である。
【図１７】図３のＬ−ＩＯ制御部とシステム負荷管理部との処理の流れ図である。
【図１８】図３のＬ−ＩＯ制御部とシステム負荷管理部とバックエンドの処理の流れ図である。
【図１９】従来技術の構成図である。
【図２０】従来技術のＤＴＣ処理の流れ図である。
【符号の説明】
１、２ ストレージコントローラ
１１、１２ チャネルアダプター
１３、１４ デバイスアダプター
１０、２０ ＣＰＵ
１５，２５ メモリ
１６、２６ キャッシュメモリ
４−１，４−２ ＦＣ＿ＡＬ
５−１〜５−８ デバイスエンクロージャー
３０、４０ ＰＣＩ−ノードブリッジ回路
２０、２１ ＰＣＩバス
５０ 物理デイスク装置（ストレージ装置）
４０ フロントエンドモジュール
４２ Ｉ／Ｏ制御モジュール
４４ バックエンドモジュール
４６ システム負荷管理モジュール
Claims (4)
- ホストから依頼されたホストＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムにおいて、
複数の前記ストレージ装置と、
前記複数のストレージ装置をアクセスするためのデバイスアダプターと、
前記ストレージ装置のデータの一部を保持するキャッシュメモリと、
ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求に応じたコマンド処理を実行し、前記処理結果に応じて、前記ストレージ装置をアクセスするアクセス実行処理を実行するコントローラとを有し、
前記コントローラは、
前記ホストＩ／Ｏ要求を解読し、解読結果により、前記キャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理を実行し、
前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行処理を実行し、
前記コントローラは、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算し、
前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止する
ことを特徴とするストレージシステム。 - 前記コントローラは、前記システム負荷に従い、前記ホストＩ／Ｏ要求の受け付けの制御を行うとともに、前記ホストＩ／Ｏ以外の内部Ｉ／Ｏ要求の起動量を調整する
ことを特徴とする請求項１のストレージシステム。 - 前記コントローラは、前記実際の負荷に応じて、前記アクセス実行処理のコマンド処理量を制御する
ことを特徴とする請求項１のストレージシステム。 - ホストから依頼されたホストＩ／Ｏ要求に応じて、接続されたストレージ装置をアクセスし、Ｉ／Ｏ要求を実行するストレージシステムの動的システム負荷管理方法において、
コントローラが、ＲＡＩＤ構成のＲａｉｄ論理ユニット単位でアクセスする前記ホストＩ／Ｏ要求を解読し、解読結果により、複数の前記ストレージ装置のデータの一部を保持するキャッシュメモリを参照して、前記ホストＩ／Ｏ要求に対する応答を行うとともに、前記キャッシュメモリで処理できない前記ホストＩ／Ｏ要求に対し、指定された前記ストレージ装置へのアクセス依頼を行うコマンド処理ステップと、
前記コントローラが、前記アクセス依頼されたＩ／Ｏ要求の要求内容を解釈し、前記Ｒａｉｄ論理ユニットのストレージ装置を特定し、アクセスコマンドを発行するアクセス実行ステップと、
前記コントローラが、前記アクセス依頼された前記ホストＩ／Ｏ要求の要求パラメータから、要求転送長とコマンド種別とを用いて、前記Ｒａｉｄ論理ユニットの負荷を予測するとともに、前記ストレージ装置の実行中のコマンド数と実行中のデータ転送数とから、前記ストレージ装置の実際の負荷を、前記ストレージ装置毎に計算し、前記予測負荷と前記実際の負荷とから前記Ｒａｉｄ論理ユニット毎のシステム負荷を計算するシステム負荷計算ステップと、
前記コントローラが、前記システム負荷が所定の閾値を越えた場合に、前記ホストから依頼されたＩ／Ｏ要求の受け付けを抑止するステップとを有する
ことを特徴とする動的システム負荷管理方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002377977A JP4318914B2 (ja) | 2002-12-26 | 2002-12-26 | ストレージシステム及びその動的負荷管理方法 |
| US10/740,443 US7136970B2 (en) | 2002-12-26 | 2003-12-22 | Storage system and dynamic load management method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002377977A JP4318914B2 (ja) | 2002-12-26 | 2002-12-26 | ストレージシステム及びその動的負荷管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004206623A JP2004206623A (ja) | 2004-07-22 |
| JP4318914B2 true JP4318914B2 (ja) | 2009-08-26 |
Family
ID=32677411
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002377977A Expired - Fee Related JP4318914B2 (ja) | 2002-12-26 | 2002-12-26 | ストレージシステム及びその動的負荷管理方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7136970B2 (ja) |
| JP (1) | JP4318914B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10628083B2 (en) | 2016-09-27 | 2020-04-21 | Hitachi, Ltd. | Storage system and storage system management method |
Families Citing this family (59)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4322068B2 (ja) * | 2003-03-07 | 2009-08-26 | 富士通株式会社 | ストレージシステム及びそのデイスク負荷バランス制御方法 |
| JP2005338893A (ja) * | 2004-05-24 | 2005-12-08 | Hitachi Ltd | データ処理システムおよびディスクアクセス制御方法並びにその処理プログラム |
| US20060037018A1 (en) * | 2004-08-16 | 2006-02-16 | Dell Products L.P. | System, method and software providing an adaptive job dispatch algorithm for large distributed jobs |
| US7263583B2 (en) * | 2004-10-05 | 2007-08-28 | International Business Machines Corporation | On demand, non-capacity based process, apparatus and computer program to determine maintenance fees for disk data storage system |
| JP4568078B2 (ja) * | 2004-10-20 | 2010-10-27 | 三洋電機株式会社 | サーバ |
| US7451259B2 (en) * | 2004-12-06 | 2008-11-11 | Nvidia Corporation | Method and apparatus for providing peer-to-peer data transfer within a computing environment |
| JP4856983B2 (ja) * | 2006-03-02 | 2012-01-18 | 株式会社日立製作所 | ストレージシステム及びスケジューリング方法 |
| JP2006318012A (ja) * | 2005-05-10 | 2006-11-24 | Hitachi Ltd | ディスク制御システム |
| JP4842593B2 (ja) | 2005-09-05 | 2011-12-21 | 株式会社日立製作所 | ストレージ仮想化装置のデバイス制御引継ぎ方法 |
| JP4472617B2 (ja) * | 2005-10-28 | 2010-06-02 | 富士通株式会社 | Ｒａｉｄシステム、ｒａｉｄコントローラ及びそのリビルド／コピーバック処理方法 |
| US7469309B1 (en) * | 2005-12-12 | 2008-12-23 | Nvidia Corporation | Peer-to-peer data transfer method and apparatus with request limits |
| JP4901310B2 (ja) * | 2006-05-31 | 2012-03-21 | 株式会社日立製作所 | 記憶制御装置及び記憶制御装置のコマンド実行数制御方法 |
| JP4331742B2 (ja) | 2006-10-25 | 2009-09-16 | 株式会社日立製作所 | Ｉ／ｏの割り振り比率に基づいて性能を管理する計算機システム、計算機及び方法 |
| JP4679494B2 (ja) * | 2006-11-22 | 2011-04-27 | Ｎｅｃシステムテクノロジー株式会社 | ディスクアレイ装置システム、ディスクアレイ装置制御方法、および、プログラム |
| US8892780B2 (en) * | 2007-03-08 | 2014-11-18 | Oracle International Corporation | Management of shared storage I/O resources |
| US8099564B1 (en) * | 2007-08-10 | 2012-01-17 | Xilinx, Inc. | Programmable memory controller |
| JP5026212B2 (ja) * | 2007-09-28 | 2012-09-12 | 株式会社日立製作所 | 計算機システム並びに管理装置及び管理方法 |
| US7886110B2 (en) * | 2007-12-27 | 2011-02-08 | Intel Corporation | Dynamically adjusting cache policy based on device load in a mass storage system |
| US7962690B2 (en) * | 2008-01-04 | 2011-06-14 | International Business Machines Corporation | Apparatus and method to access data in a raid array |
| JP2009217475A (ja) * | 2008-03-10 | 2009-09-24 | Fujitsu Ltd | ストレージシステム，ストレージ装置，ストレージシステムの制御方法および制御プログラム |
| JP4542173B2 (ja) | 2008-05-21 | 2010-09-08 | 富士通株式会社 | ストレージ装置、ディスクコントローラ、及びコマンド発行制御方法 |
| JP2009294949A (ja) | 2008-06-05 | 2009-12-17 | Hitachi Ltd | ストレージ装置及びその性能測定方法 |
| WO2010033877A1 (en) | 2008-09-19 | 2010-03-25 | Oracle International Corporation | Storage-side storage request management |
| US9772798B2 (en) * | 2008-09-19 | 2017-09-26 | Oracle International Corporation | Method and system for implementing workload management by monitoring disk utilizations |
| US8868831B2 (en) | 2009-09-14 | 2014-10-21 | Oracle International Corporation | Caching data between a database server and a storage system |
| US9325583B2 (en) * | 2009-01-27 | 2016-04-26 | Hewlett Packard Enterprise Development Lp | Method and system for optimizing network input/output performance |
| JP2010211428A (ja) * | 2009-03-10 | 2010-09-24 | Fujitsu Ltd | ストレージ装置、中継装置、及びコマンド発行制御方法 |
| JP5347648B2 (ja) * | 2009-03-30 | 2013-11-20 | 富士通株式会社 | プログラム、情報処理装置及び状態出力方法 |
| JP4814982B2 (ja) | 2009-06-25 | 2011-11-16 | 富士通株式会社 | ストレージ制御装置及びストレージ装置の動作制御方法 |
| WO2011079467A1 (zh) * | 2009-12-31 | 2011-07-07 | 华为技术有限公司 | 分布式缓存资源调度的方法、装置及系统 |
| WO2011132224A1 (en) * | 2010-04-21 | 2011-10-27 | Hitachi,Ltd. | Disk array system and traffic control method |
| US8863139B2 (en) | 2011-04-12 | 2014-10-14 | Hitachi, Ltd. | Management system and management method for managing a plurality of storage subsystems |
| US9015411B2 (en) * | 2011-12-02 | 2015-04-21 | Compellent Technologies | System and method for unbalanced raid management |
| JP5825359B2 (ja) * | 2011-12-19 | 2015-12-02 | 富士通株式会社 | 負荷分散システム |
| JP6051617B2 (ja) * | 2012-06-28 | 2016-12-27 | 富士通株式会社 | 制御装置、ストレージ装置、制御方法及び制御プログラム |
| US10152500B2 (en) | 2013-03-14 | 2018-12-11 | Oracle International Corporation | Read mostly instances |
| US20150081400A1 (en) * | 2013-09-19 | 2015-03-19 | Infosys Limited | Watching ARM |
| US9767178B2 (en) | 2013-10-30 | 2017-09-19 | Oracle International Corporation | Multi-instance redo apply |
| JP2015184895A (ja) * | 2014-03-24 | 2015-10-22 | 富士通株式会社 | ストレージ制御装置、ストレージ装置、及びストレージ制御プログラム |
| US9983831B2 (en) | 2014-07-22 | 2018-05-29 | Ngd Systems, Inc. | System and method for consistent performance in a storage device |
| WO2016132428A1 (ja) * | 2015-02-16 | 2016-08-25 | 株式会社日立製作所 | ストレージ装置 |
| US10481805B1 (en) * | 2015-06-30 | 2019-11-19 | EMC IP Holding Company LLC | Preventing I/O request timeouts for cloud-based storage systems |
| US10678788B2 (en) | 2015-10-22 | 2020-06-09 | Oracle International Corporation | Columnar caching in tiered storage |
| US10747752B2 (en) | 2015-10-23 | 2020-08-18 | Oracle International Corporation | Space management for transactional consistency of in-memory objects on a standby database |
| US11657037B2 (en) | 2015-10-23 | 2023-05-23 | Oracle International Corporation | Query execution against an in-memory standby database |
| US9792051B2 (en) * | 2016-02-24 | 2017-10-17 | Samsung Electronics Co., Ltd. | System and method of application aware efficient IO scheduler |
| US10698771B2 (en) | 2016-09-15 | 2020-06-30 | Oracle International Corporation | Zero-data-loss with asynchronous redo shipping to a standby database |
| US10891291B2 (en) | 2016-10-31 | 2021-01-12 | Oracle International Corporation | Facilitating operations on pluggable databases using separate logical timestamp services |
| US11475006B2 (en) | 2016-12-02 | 2022-10-18 | Oracle International Corporation | Query and change propagation scheduling for heterogeneous database systems |
| JP6822274B2 (ja) * | 2017-03-30 | 2021-01-27 | 富士通株式会社 | 情報処理システム、方法、及びプログラム |
| US10691722B2 (en) | 2017-05-31 | 2020-06-23 | Oracle International Corporation | Consistent query execution for big data analytics in a hybrid database |
| CN109725829B (zh) * | 2017-10-27 | 2021-11-05 | 伊姆西Ip控股有限责任公司 | 用于数据存储系统的端到端QoS解决方案的系统和方法 |
| US11170002B2 (en) | 2018-10-19 | 2021-11-09 | Oracle International Corporation | Integrating Kafka data-in-motion with data-at-rest tables |
| US11687363B2 (en) * | 2019-07-15 | 2023-06-27 | Micron Technology, Inc. | Internal management traffic regulation for memory sub-systems |
| CN112231252B (zh) * | 2019-07-15 | 2024-04-30 | 美光科技公司 | 用于存储器子系统的内部管理业务调节 |
| US11507321B1 (en) | 2021-06-04 | 2022-11-22 | Western Digital Technologies, Inc. | Managing queue limit overflow for data storage device arrays |
| US11567883B2 (en) * | 2021-06-04 | 2023-01-31 | Western Digital Technologies, Inc. | Connection virtualization for data storage device arrays |
| JP2023015488A (ja) | 2021-07-20 | 2023-02-01 | 富士通株式会社 | データ中継装置、中継制御方法およびストレージシステム |
| CN113778347B (zh) * | 2021-11-15 | 2022-04-15 | 广东睿江云计算股份有限公司 | 一种ceph系统读写质量优化方法及服务端 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09258907A (ja) | 1996-03-25 | 1997-10-03 | Mitsubishi Electric Corp | 複数の記憶ディスク部を有した高可用性の外部記憶装置 |
| US6493811B1 (en) * | 1998-01-26 | 2002-12-10 | Computer Associated Think, Inc. | Intelligent controller accessed through addressable virtual space |
| US6456850B1 (en) * | 1999-08-17 | 2002-09-24 | Lucent Technologies Inc. | Method for preventing overload conditions in communication systems |
| US6947985B2 (en) * | 2001-12-05 | 2005-09-20 | Websense, Inc. | Filtering techniques for managing access to internet sites or other software applications |
-
2002
- 2002-12-26 JP JP2002377977A patent/JP4318914B2/ja not_active Expired - Fee Related
-
2003
- 2003-12-22 US US10/740,443 patent/US7136970B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10628083B2 (en) | 2016-09-27 | 2020-04-21 | Hitachi, Ltd. | Storage system and storage system management method |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040133707A1 (en) | 2004-07-08 |
| US7136970B2 (en) | 2006-11-14 |
| JP2004206623A (ja) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4318914B2 (ja) | ストレージシステム及びその動的負荷管理方法 | |
| US9747044B2 (en) | Interleaving read and write requests to reduce latency and maximize throughput in a flash storage device | |
| JP4322068B2 (ja) | ストレージシステム及びそのデイスク負荷バランス制御方法 | |
| JP4922496B2 (ja) | Ｉ／ｏ要求に優先順位を与える方法 | |
| US5426736A (en) | Method and apparatus for processing input/output commands in a storage system having a command queue | |
| US8312121B2 (en) | Storage system comprising function for alleviating performance bottleneck | |
| US7185168B2 (en) | System and method for quality of service management in a partitioned storage device or subsystem | |
| US8429667B2 (en) | Storage system and method for controlling the same | |
| US6324620B1 (en) | Dynamic DASD data management and partitioning based on access frequency utilization and capacity | |
| US7730257B2 (en) | Method and computer program product to increase I/O write performance in a redundant array | |
| US6665740B1 (en) | Logical volume selection in a probability-based job scheduler | |
| US20030212865A1 (en) | Method and apparatus for flushing write cache data | |
| JP3137554B2 (ja) | データ転送／管理システム及び方法 | |
| JP2009015844A (ja) | 要求優先順位シーク・マネージャ | |
| JPH09258907A (ja) | 複数の記憶ディスク部を有した高可用性の外部記憶装置 | |
| US6799228B2 (en) | Input/output control apparatus, input/output control method and information storage system | |
| JP5246872B2 (ja) | ストレージシステムおよびストレージ管理方法 | |
| JP2003131814A (ja) | ディスクアレイシステム | |
| JP6848278B2 (ja) | ストレージ管理装置、性能調整方法及び性能調整プログラム | |
| JP3793682B2 (ja) | コマンドキューイングの機能を持つ記憶装置 | |
| US20090063769A1 (en) | Raid apparatus, controller of raid apparatus and write-back control method of the raid apparatus | |
| JP6379841B2 (ja) | 情報処理装置、試験方法および試験制御プログラム | |
| US20240201869A1 (en) | Efficient Execution Of I/O Operations In A Storage Environment | |
| JP2018045282A (ja) | ストレージ制御装置、ストレージシステムおよびストレージ制御プログラム | |
| JPH1040218A (ja) | バス制御装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051202 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080827 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080902 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081104 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090120 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090323 |
|
| 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: 20090526 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090527 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120605 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: 20120605 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130605 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130605 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |