(57)【要約】【課題】ストリーム提供に影響を与えずディスク故障に対する修復時間を短縮できる実時間ストリームサーバを提供する。【解決手段】蓄積部３はデータをブロック（複数セグメントとパリティ）単位に分散格納する複数ディスク３２を持ち、バッファ４はディスク３２へ読書きするデータを一時記憶し、転送部５は、通常ストリームでデータをブロック単位に要求元へ転送し、修復部７は修復ストリームで対象ブロックのセグメントのうち故障ディスク上のものを代替ディスク上に修復する。ストリーム資源は、まず通常ストリームに、残りがあれば修復ストリームに割り当てる。両ストリームによる該資源の利用を一元管理し、転送部の１ブロックのデータ読み出し／転送と修復部の１ブロックのデータ読み出し／セグメント修復を同様のタイミングで行い、修復部はその後修復セグメントを代替ディスクに書込むように、転送部と修復部の動作タイミングをスケジューリングする。【選択図】      図１
2004342135.tif 000002
【特許請求の範囲】
【請求項１】
クライアントから要求されたデータを、所定個数のデータセグメントとパリティセグメントからなるブロックに分散して格納するための複数のディスク装置を持つデータ蓄積部と、
修復すべきデータセグメントの属するブロックの情報を管理する手段と、
前記ディスク装置から読み出されたデータおよび前記ディスク装置へ書き込むデータを一時的に記憶するバッファメモリと、
前記ディスク装置へアクセスするためのタイムスロットと前記バッファメモリ上の割り当て領域とを含むストリーム資源を、前記クライアントへのデータ転送に用いる通常のストリームに優先的に割り当てるとともに、残りのストリーム資源の全部又は一部を、データを修復して代替ディスク装置へ書き戻す修復ストリームに割り当てる割り当て手段と、
前記通常のストリームを用いて、前記データ蓄積部からデータをブロック単位に読み出して前記割り当て領域に一時的に保持し、ネットワークを介して前記クライアントに転送する転送手段と、
前記修復ストリームを用いて、前記情報により特定されるブロックに属するデータセグメントのうち、故障が検出されたディスク装置に格納されていたデータセグメントを代替ディスク装置上に修復する修復手段と、
前記通常のストリームと前記修復ストリームとによる前記ストリーム資源の利用を一元的に管理し、前記転送手段が１ブロックのデータの読み出しおよびクライアントへのデータ転送を行うのと同様のタイミングで前記修復手段が１ブロックのデータの読み出しおよび前記割り当て領域上でのセグメント修復を行い、前記修復手段はその後修復されたセグメントを代替ディスク装置に書き込むように、前記転送手段と前記修復手段との動作タイミングをスケジューリングする制御手段と、
を備える実時間ストリームサーバ。
【請求項２】
新たな通常のストリームの接続要求時に全部または一部の修復ストリームによる修復を中断する手段を備え、
前記割り当て手段は、解放されたストリーム資源を新たな通常のストリームに割り当てる、
請求項１に記載の実時間ストリームサーバ。
【請求項３】
前記割り当て手段は、前記転送手段によるクライアントへのデータ転送が終了した場合、その転送に用いられた通常のストリームのストリーム資源を修復ストリームに割り当てる、
請求項１に記載の実時間ストリームサーバ。
【請求項４】
前記転送手段は、前記情報により特定されるブロックに属するデータセグメントを前記ディスク装置から読み出す場合は、そのデータセグメントを前記割り当て領域内に修復し、修復されたデータセグメントを含むブロックをネットワークを介して前記クライアントに転送する、
請求項１に記載の実時間ストリームサーバ。
【請求項５】
前記転送手段は、修復されたデータセグメントを前記代替ディスク装置に書き込む、
請求項４に記載の実時間ストリームサーバ。
【請求項６】
前記転送手段は、各ブロックの転送に先だって、次に転送すべきブロックがまだ修復されておらず、かつ、ストリーム資源が確保可能であるか否かを調べ、両条件が成立する場合は、修復されたデータセグメントを前記代替ディスク装置に書き込む、
請求項４に記載の実時間ストリームサーバ。
【請求項７】
前記修復手段は、前記情報から参照した選択優先度に基づいて次に修復すべきブロックを選択する手段を備え、
前記転送手段は、前記クライアントに供給中のデータに対応するすべてのブロックの前記選択優先度を、前記クライアントに供給中のデータに対応しないブロックの前記選択優先度より低くなるように調整する手段を備える、
請求項４に記載の実時間ストリームサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、実時間ストリームサーバからクライアントへのストリームの供給に影響を与えずにディスク装置の故障により失われたデータを修復する実時間ストリームサーバに関する。
【背景技術】
【０００２】
動画像や音声に代表される、実時間で順次転送されるデータを「実時間ストリームデータ」と呼ぶ。これらのデータを扱う「実時間ストリームサーバ」においては、ディスク装置に蓄積された実時間ストリームデータを、実時間での連続性を保証して各クライアントに送出できることが必要条件である。その条件を満たすために、従来技術では実時間ストリームデータをある一定時間に転送すべき大きさのブロックに分割してデータ蓄積部に格納しておき、各ストリーム毎にサーバが周期的にデータ蓄積部にアクセスする。読み出されたブロックは一旦バッファメモリ上に置かれ、対応するクライアントに通信網を介して周期的に送出される。制御装置では、この動作のタイミングの管理を行ない、また、クライアントからの接続要求を受け付けて、新しいストリームチャネルを確立する。
【０００３】
データ蓄積部には大量のデータを格納し、かつ高速にデータを転送する必要があるので、複数のディスク装置を組み合わせたディスクアレイ装置を用意して、データを小さなブロックに分割して全てのディスク装置に順に格納するストライピング技術が一般に用いられる。
【０００４】
ディスクアレイにおけるデータ修復を可能にする技術としては、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ ｄｉｓｋｓ）がよく知られている。例えば、ある数のデータディスク毎に１台のパリティディスクを設けて論理的なディスクグループを作り、格納するデータを何らかの基準で小さなブロックに分割し、さらにそのブロックをデータディスクの数のデータセグメントに分割して格納する。各ブロックについて、データセグメントの排他的論理和を持つパリティデータを計算してパリティディスクに格納しておく。すると、ディスクグループ内のどれか１台のディスク装置が故障した場合でも、他のデータディスクとパリティディスクからデータの修復が可能となる。
【０００５】
さらに実時間ストリームサーバにおいては、ディスク装置が故障した場合でも接続されているストリームによるクライアントへのデータ供給を継続し、かつサーバの運用を停止せずにデータの修復を行なうことが求められる。そこで、実時間ストリームサーバのデータ蓄積部にはディスク装置の故障検出手段とサーバの動作中にディスク装置を交換する手段が用意されている。
【０００６】
ところで、実際にデータの修復を行なう場合には、クライアントへのデータ供給を行うストリーム以外にも、修復のためのディスクアクセス、バッファメモリ等のストリーム資源が必要となる。
【０００７】
従来は、あるストリーム資源を修復ストリーム専用に確保しておき、データの修復の際に、確保しておいたストリーム資源を修復ストリームに割り当てデータの修復を実行させていた。このため、修復中の最大ストリーム供給数が低く制限される不具合があった。また、どのストリーム資源を確保するかは固定的に設定されるので、実際のストリーム供給数が少ない場合、割り当てられずに余っているストリーム資源が多く存在しても、これら資源を有効に利用して修復時間を短縮することができなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従来は、故障ディスク装置のデータの修復を行なう場合、あるストリーム資源を修復ストリーム専用に割り当てていたので、その後の最大ストリーム供給数が低く制限されるという不具合があった。また、ストリーム資源を有効に利用して修復時間を短縮することができなかった。
【０００９】
本発明は、上記事情を考慮してなされたものであり、実時間ストリームサーバにおけるディスク装置の故障によって失われたデータをスペアディスク上に修復中であっても、新しいストリームの接続要求には制限を付けずに通常時と全く同様のサービスを提供しつつ、余ったストリーム資源を最大限に利用して修復時間を短縮することを可能とする実時間ストリームサーバを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る実時間ストリームサーバは、クライアントから要求されたデータを、所定個数のデータセグメントとパリティセグメントからなるブロックに分散して格納するための複数のディスク装置を持つデータ蓄積部と、修復すべきデータセグメントの属するブロックの情報を管理する手段と、前記ディスク装置から読み出されたデータおよび前記ディスク装置へ書き込むデータを一時的に記憶するバッファメモリと、前記ディスク装置へアクセスするためのタイムスロットと前記バッファメモリ上の割り当て領域とを含むストリーム資源を、前記クライアントへのデータ転送に用いる通常のストリームに優先的に割り当てるとともに、残りのストリーム資源の全部又は一部を、データを修復して代替ディスク装置へ書き戻す修復ストリームに割り当てる割り当て手段と、前記通常のストリームを用いて、前記データ蓄積部からデータをブロック単位に読み出して前記割り当て領域に一時的に保持し、ネットワークを介して前記クライアントに転送する転送手段と、前記修復ストリームを用いて、前記情報により特定されるブロックに属するデータセグメントのうち、故障が検出されたディスク装置に格納されていたデータセグメントを代替ディスク装置上に修復する修復手段と、前記通常のストリームと前記修復ストリームとによる前記ストリーム資源の利用を一元的に管理し、前記転送手段が１ブロックのデータの読み出しおよびクライアントへのデータ転送を行うのと同様のタイミングで前記修復手段が１ブロックのデータの読み出しおよび前記割り当て領域上でのセグメント修復を行い、前記修復手段はその後修復されたセグメントを代替ディスク装置に書き込むように、前記転送手段と前記修復手段との動作タイミングをスケジューリングする制御手段とを備えることを特徴とする。
【００１１】
本発明では、ディスク装置の故障が検出され通知されると、修復すべきデータセグメントが属するブロックを調べ管理する。例えばそのブロックを表す識別子のリストを作成すれば、このリストを参照することにより、各ブロックが未修復であるか修復中であるかを知ることができる。そして、使用されていないストリーム資源の全部あるいは一部を、そのストリーム資源に対応する数の修復ストリームに割り当てる。ここで、ストリーム資源とは、例えば、ディスクアクセスを割り付けるタイムスロット、ディスクから読み出したデータを一時保持しておくためのバッファメモリ、制御装置内でストリームを管理・スケジュールするために必要となる情報を格納しておく領域である。
【００１２】
修復ストリームでは、リストを参照するなどして次に修復すべきブロックの識別子を得る。そして、通常のストリームと同様のスケジューリング方法で、そのブロックのディスクアクセス、バッファメモリ上でのデータセグメントの修復が行なわれ、スペアディスクに修復されたデータセグメントが書き込まれる。
【００１３】
新しいストリームの接続要求が到着したときには、優先的に新ストリームにストリーム資源を割り当てるのが好ましい。そこで、新ストリームで必要となるストリーム資源を確保するために、一部の修復ストリームによる修復を中断させてそのストリーム資源を解放するのが好ましい。
【００１４】
一方、クライアントへのデータ供給を行う通常のストリームが終了し、そのストリーム資源が解放された場合には、解放されたストリーム資源を修復ストリームに割り当てることができる。
【００１５】
以上により、通常のストリームで使用されていない余ったストリーム資源をディスクの修復のために最大限に利用しつつ、かつ新しいストリームの接続要求に対応して通常のストリームと修復ストリームの割合を変化させることが可能になる。
【００１６】
従って、本発明によれば、修復ストリームによるデータ上の修復中であっても、既接続のストリームによるクライアントへのデータ供給に影響を及ぼさず、かつ新しいストリームの接続に制限を設けずに、ストリーム資源を無駄なく有効に利用してディスク装置の故障により失われたデータの修復時間を短縮することが可能である。
【００１７】
また、本発明では、修復ストリームだけでなく、通常のストリームによるクライアントへのデータ供給の際に修復されたデータをスペアディスクに書き込むようにすると好ましい。まず、ディスクアクセスの前にそのブロックが未修復がどうかリストを参照するなどして調べる。そのブロックが未修復の場合には、バッファメモリ上に修復されたデータセグメントをスペアディスクに書き込む。なお、同時に複数の書き込みが同一スペアディスクに集中しないようにスケジュールしておけば良い。
【００１８】
これにより、修復完了時間をさらに短縮することができる。
【００１９】
また、本発明では、現在クライアントへ供給中のストリームデータに関しては、その後引き続いてそのストリームで供給と修復が同時に行なわれると予想されるので（あるいは同時に行なわれるとみなし）、現在クライアントへ供給中のストリームデータを格納しているブロック番号の選択優先度を低く設定して、現在供給されていないストリームデータを格納しているブロック識別子を優先的に選択するようにするとより効果的である。
【００２０】
これにより、現在供給されていないデータを修復ストリームで修復し、通常ストリームで供給しているデータをそのまま修復に利用できる確率が上がり、修復完了時間をさらに短縮することができる。
【発明の効果】
【００２１】
本発明によれば、修復すべきブロックについてリストを作成するなどして管理し、通常ストリームには必要に応じて修復ストリームを中断してストリーム資源を優先的に割り当て、修復ストリームには未使用のストリーム資源をできるかぎり割り当てられるようにし、修復ストリームは上記リストを参照するなどして修復を行なうようにしたので、修復ストリームによるデータの修復中であっても、既接続のストリームによるクライアントへのデータ供給に影響を及ぼさず、かつ新しいストリームの接続に制限を設けずに、ストリーム資源を無駄なく有効に利用することができ、ディスク装置の故障により失われたデータの修復時間を短縮することが可能である。
【００２２】
また、現在供給されていないデータを修復ストリームで修復し、通常ストリームで供給しているデータをそのまま修復に利用すれば、修復完了時間をさらに短縮することができる。
【発明を実施するための最良の形態】
【００２３】
以下、図面を参照しながら、本発明の実施の形態について説明する。
【００２４】
本発明の第１の実施形態では、ディスク装置の故障が検出され制御装置に通知されると、ブロック修復リスト管理部は、修復すべきデータセグメントが属するブロックを調べて、ブロック修復予約リストを作成する。このリストは各ブロックが未修復であるか修復中であるかを示す情報を持つ。また、ブロック修復リスト管理部では、スケジューリング部の問い合わせに対して次に修復すべきブロックを選択する機能と、指定されたブロックが未修復であるかどうかを判断する機能を持つ。その後、使用されていないストリーム資源の全てあるいは一部を、そのストリーム資源に対応する数の修復ストリームに割り当てる。
【００２５】
ここで、ストリーム資源とは、ディスクアクセスを割り付けるタイムスロットと、ディスクから読み出したデータを一時保持しておくためのバッファメモリと、制御装置内でストリームを管理、スケジュールするために必要となる情報を格納しておく領域である。
【００２６】
修復ストリームでは、次にアクセスすべきディスクグループに対応するブロック修復予約リストからブロック識別子を得る。そして、通常のストリームと同様のスケジューリング方法で、そのブロックのディスクアクセス、バッファメモリ上でのデータセグメントの修復が行なわれ、その後スペアディスクにそのデータセグメントが書き込まれる。
【００２７】
新しいストリームの接続要求が到着したときには、新ストリームで必要となるストリーム資源を確保するために、一部の修復ストリームによる修復を中断させてそのストリーム資源を解放する。
【００２８】
また、クライアントへのデータ供給を行う通常のストリームが終了し、そのストリーム資源が解放された場合には、解放されたストリーム資源を修復ストリームに割り当てる。以上により、通常のストリームによるクライアントへのデータの供給で使用されていない余ったストリーム資源をディスクの修復のために最大限に利用しつつ、かつ新しいストリームの接続要求に対応して通常のストリームと修復ストリームの割合を変化させることが可能になる。
【００２９】
さらに、第２の実施形態では、修復ストリームだけでなく、通常のストリームによるクライアントへのデータ供給の際に修復されたデータをスペアディスクに書き込む。スケジューリング部は、ディスクアクセスの前にそのブロックが未修復がどうかをブロック修復リスト管理部に問い合わせる。ブロック修復リスト管理部は、そのブロックが格納されているディスクグループのブロック修復予約リストを調べて、未修復かどうかを返す。スケジューリング部は、そのブロックが未修復の場合に、バッファメモリ上に修復されたデータセグメントをスペアディスクに書き込む。このとき、バッファメモリ上にそのデータが残っている間、すなわちブロックのクライアントへの転送が終了するまでにスペアディスクへの書き込みが実行されなければならない。また、同時に複数の書き込みが同一スペアディスクに集中しないようにスケジュールしなければならない。
【００３０】
なお、現在クライアントへ供給中のストリームデータに関しては、その後引き続いてそのストリームで供給と修復が同時に行なわれると予想されるので、修復ストリームで次に修復されるブロックをブロック修復リスト管理部が選択する際に、現在クライアントへ供給中のストリームデータを格納しているブロック番号の選択優先度を低くして、現在供給されていないストリームデータを格納しているブロック識別子を優先的に選択するようにするとより効果的である。
【００３１】
以上により、通常ストリームで供給しているデータをそのまま修復に利用できる確率が上がり、修復完了時間をさらに短縮することができる。
【００３２】
また、第３の実施形態では、バッファメモリ上での修復を行うハードウェアの制限により、クライアントへのデータ供給とバッファメモリ上でのデータ修復が同時に行われるために、データ転送が終了するまでの時間内には修復データをスペアディスクに書き込めない場合であっても、第２の実施形態と同様に、通常ストリームによるクライアントへのデータ供給の際にバッファメモリ上で修復されたセグメントをスペアディスクに書き込む。
【００３３】
この場合には、通常ストリームと修復を行うストリームとでデータのバッファ滞在時間が異なり、その結果バッファメモリの使用量が異なる。そこで、新ストリームの接続時には、そのストリームに必要となるストリーム資源を確保できるように、必要ならば複数の修復ストリームを中断して資源を解放し、新ストリームに割り当てる。
【００３４】
逆に通常ストリームによるデータ供給の終了時には、終了した通常ストリームのストリーム資源を解放する。その後で未使用のストリーム資源量が修復ストリームで必要なストリーム資源量に達している場合には、新しい修復ストリームにストリーム資源を割り当てる。
【００３５】
以下では、クライアントへのストリームデータの供給のみを行う通常ストリームをＳストリームと呼ぶ。すなわち、Ｓストリームでは、転送対象のブロックを格納したディスクが故障している場合は、該ブロックを修復しながらクライアントへストリームデータ供給を行うが、修復した故障ディスクの内容を代替ディスクに書き込むことはしない。
【００３６】
一方、ストリームデータの供給／故障ディスクの修復を併せて行う通常ストリームをＲＳストリームと呼ぶ。すなわち、ＲＳストリームでは、転送対象のブロックを格納したディスクが故障している場合は、該ブロックを修復しながらストリームデータの供給を行うとともに、修復した故障ディスクの内容を代替ディスクに書き込む。
【００３７】
また、故障ディスクの修復のみを行うストリームをＲストリームと呼ぶ。
【００３８】
以下、各実施形態をさらに詳しく説明する。
【００３９】
（第１の実施形態）
まず、第１の実施形態について説明する。
【００４０】
本実施形態は、故障ディスクのデータを修復しながら送出するＳストリームと、故障ディスクのデータを修復して代替ディスクに書き込むＲストリームを用いる実施形態である。
【００４１】
図１に本実施形態に係る実時間ストリームサーバの構成を、図２に本実施形態の動作のフローチャートを示す。
【００４２】
なお、図１のバッファメモリ４内のストリームstream iに対する矢印は、故障ディスクのデータを修復して該故障ディスクに書き込む様子（Ｒストリームに対応）を示しており、ストリームstream jに対する矢印は、故障ディスクのデータを修復しながらクライアントに送出する様子（Ｓストリームに対応）を示している。
【００４３】
図１のように本実施形態の実時間ストリームサーバは、実時間ストリームデータを格納するための複数台のディスク装置３２を有するデータ蓄積部３、ディスク装置３２から読み出したデータを一時保持しておくためのバッファメモリ４、バッファメモリ４から読み出したデータをネットワーク（図示せず）を介して要求元のクライアントへ転送するデータ転送部５、ディスク装置３２の故障を検出する故障検出部６、故障したディスク装置のデータを修復するデータ修復部７、データ蓄積部３やデータ転送部５に対して必要な動作の指示を行なうなどシステム全体を制御する制御装置２を備えている。
【００４４】
制御装置２は、要求元クライアントからネットワークを介して送られてくるストリーム接続要求を受け付ける接続要求処理部２１、各ストリームの連続性を保証するのに必要な動作のスケジュールを管理するスケジューリング部２２、修復ストリームにストリーム資源を割り当てる修復ストリーム割り付け部２３、修復ストリームによる修復を中断させてそのストリーム資源を解放する修復ストリーム解放部２４、修復状況・順序等を管理するブロック修復リスト管理部２５を備えている。
【００４５】
データ蓄積部３は、Ｎ組のディスクグループ３１からなる。１組のディスクグループには、ｍ＋１台のディスク装置３２が含まれる。ｍ＋１台のディスク装置３２のうち、ｍ台はデータ格納用として使われ、１台はパリティ格納用に使われる。１つのディスクグループに格納されるブロックは、等長のｍ個のデータセグメントに分割されて、それぞれ異なるデータ格納用ディスクに格納される。パリティディスクには、ｍ個のデータセグメントのパリティデータが格納される。
【００４６】
以下、本実施形態の動作について図２を参照しながら説明する。ディスク装置の故障の通知のない通常動作では、接続要求処理部２１によりネットワークを介して転送されてきた要求元クライアントのストリーム接続要求が受理されると、制御装置２は、通常ストリームにストリーム資源、すなわちスケジューリング部２２のストリーム管理表２２１のエントリ、ディスクアクセスを割り付けるタイムスロットとディスクから読み出したデータを一時保持しておくためのバッファメモリ４の領域を割り当てる。
【００４７】
そして、制御装置２は、要求元クライアントに要求されたストリームデータを供給するために、割り当てたストリーム資源を使用して、該当するディスクグループ内のｍ個のデータセグメントとそれらに対応する１個のパリティデータを同時にバッファメモリ４に呼び出させ、その後、バッファメモリ４から転送装置５によりネットワーク（図示せず）を介してクライアントへ順次転送させる。制御装置２は、データセグメントを周期的に転送し、要求されたストリームデータの供給が完了したら、割り当てたストリーム資源を解放する。
【００４８】
以上が、通常動作である（ステップＳ１１）。
【００４９】
さて、通常動作中において、ディスク装置３２に故障が生じたものとする。すると、故障検出部６によりディスク装置３２の故障が検出され、制御装置２に故障発生通知と故障したディスク装置のディスク番号が送られてくる（ステップＳ１２）。
【００５０】
通知を受けた制御装置２は、データ修復装置７に命令を送り、故障したディスク装置（図中の３３）が属するディスクグループ（例えば図１中のＧｒｏｕｐ Ｎ−１）からバッファメモリ４に読み出されたデータをクライアントへ転送する前に、故障したディスク装置３３から読み出されるべきデータセグメントを他のデータセグメントとパリティデータから修復させ（ステップＳ１９）、その後に転送させる（ステップＳ２０）。
【００５１】
一方、故障したディスク装置３３は新しいディスク装置と交換する（ステップＳ１２）。なお、通常動作中にスペアディスク装置を接続しておいて、故障発生時に故障したディスク装置３３とスペアディスク装置のディスク番号を論理的に交換してもよい。
【００５２】
さて、故障が検出されるとブロック修復リスト管理部２５は、各ディスクグループ毎にブロック修復予約リスト２５１を作成する（ステップＳ１３）。ブロック修復予約リスト２５１には、そのディスクグループ３１に格納されているブロックを表すブロック識別子を登録する。故障ディスク３３が存在しないディスクグループ３１のブロック修復予約リスト２５１は空とする。ブロック識別子には、そのブロックがディスク装置３２に格納されるときの位置情報が含まれる。その位置情報は、論理ブロック番号でもよいし、あるいは物理的なトラック番号やセグメント番号でもよい。あるブロックのｍ個のデータセグメントが各ディスク装置で同一の論理ブロック番号で表されるならば、ブロック識別子はその論理ブロック番号の情報を保持すればよい。そうでない場合には、ブロック識別子はｍ個のデータセグメントの各ディスク装置上での位置情報を全て保持する必要がある。
【００５３】
修復ストリーム割り付け部２３は、現在クライアントへのデータの供給に使用されていないストリーム資源の一部または全部を修復ストリームに割り当てる（ステップＳ１４）。具体的には、通常のストリームと同様にバッファメモリ４の領域（図中のstream iの部分）、スケジューリング部２２のストリーム管理表２２１の領域（図中のstream iの部分）、ディスクアクセスを割り付けるタイムスロットを確保して、ストリーム管理表２２１にその修復ストリームの管理情報書き込み、タイムスロットにディスクアクセスを割り付ける。
【００５４】
修復ストリームでは、次にアクセスするディスクグループ（例えば図１中のＧｒｏｕｐ Ｎ−１）のブロック修復予約リスト２５１からブロック識別子を取り出す（ステップＳ２１）。通常のストリームと同様にそのブロック識別子に対応するデータセグメントとパリティデータを同時にバッファメモリ４に読み出して、データ修復装置７により故障したディスク３３から読み出されるべきデータセグメントを修復する（ステップＳ２２〜Ｓ２４）。修復されたデータセグメントは、バッファメモリ４から交換されたスペアディスク３２に書き込まれる。
【００５５】
ここで、書き込みを通常のストリームのブロック転送終了までのタイムスロットで行なうようにすれば、１ブロックがバッファメモリ４の１領域を占有する期間が通常のストリームと同じになるので、１本の修復ストリームで全てのディスクグループの修復を１ブロックづつ順番に行なうことが可能となる。
【００５６】
ブロック修復予約リストが空である場合には（ステップＳ２２）、ディスク装置３２が故障していないか、あるいは修復が終了したものとみなして、そのディスクグループに対するディスクアクセスの順番がまわってきても読み出し、修復、書き込みを行なわなければよい。
【００５７】
ここで、修復中に新しいストリームの接続要求があった場合、修復タイムスロットが存在しないものとみなして新ストリームのディスクアクセスを割り付けるタイムスロットを選択する。選択したタイムスロットに修復ストリームのディスクアクセスが既に割り付けられていた場合には、その修復ストリームによる修復を中断して、そのストリーム資源を解放する（ステップＳ１５）。このとき、その修復ストリームにおいて書き込みが終了していないブロックを表す識別子全てを、それぞれが対応するディスクグループのブロック修復予約リスト２５１に登録し直す。その後、解放されたストリーム資源を新ストリームに割り当てる。空いたタイムスロットに新ストリームのディスクアクセスを割り付ける（ステップＳ１６）。
【００５８】
一方、既に接続されている通常ストリームによるデータ供給が終了した場合、解放されたストリーム資源を修復ストリームに割り当てて、修復ストリームを増加させる（ステップＳ１７，Ｓ１８）。
【００５９】
ここで、ディスク装置１台分のデータの修復に必要となる時間は、  
（修復時間）＝（ディスク１台分の修復ブロック数）×（ブロック転送周期）×（ディスクグループ数）／（修復ストリーム数）となる。
【００６０】
全てのブロックにおいて、（ブロック転送時間）＝（ブロック転送周期）であるならば、  
（修復時間）＝（全データの転送時間）／（修復ストリーム数）となる。修復ストリームは全てのディスクグループの修復で共用できるので、故障ディスクを含むディスクグループ数が増加しても修復時間は変化しない。
【００６１】
以上のようにして、全ての修復ストリームで修復が完了したら（ステップＳ２４）、全ての修復ストリームを解放し（ステップＳ２５）、通常動作へ戻る（ステップＳ２６）。
【００６２】
以上のように本実施形態によれば、通常のストリームによるクライアントへのデータの供給で使用されていない余ったストリーム資源をディスクの修復のために最大限に利用しつつ、かつ新しいストリームの接続要求に対応して通常のストリームと修復ストリームの割合を変化させることが可能になる。
【００６３】
従って、修復ストリームによるデータの修復中であっても、既接続の通常ストリームによるクライアントへのデータ供給に影響を及ぼさず、かつ新しいストリームの接続に制限を設けずに、故障ディスク装置を含むディスクグループの転送能力を無駄なく有効に利用してディスク装置の故障により失われたデータの修復時間を短縮することが可能である。
【００６４】
（第２の実施形態）
次に、第２の実施形態について説明する。本実施形態では、第１の実施形態のように修復ストリームにより故障ディスクのデータを修復して故障ディスクに書き込むだけでなく、通常のストリームによりクライアントへのデータの供給とデータの修復を同時に行う。すなわち、ＲＳストリームとＲストリームを用いる実施形態である。
【００６５】
本実施形態に係る実時間ストリームサーバの構成は図１と同様であり、詳細な説明は省略する。ただし、制御装置２に上記のようなＲＳストリームによる新たな修復操作の制御機能が加わっている点が異なる。また、図３に本実施形態の動作のフローチャートを示す。なお、図３中、第１の実施形態の動作を示す図２のフローチャートと同様の部分は同一の符号を付した。以下では、第１の実施形態と相違する点を中心に説明する。
【００６６】
第１の実施形態では、通常ストリームにおいて、クライアントへのデータの供給のためにバッファメモリ４上でのデータの修復が行なわれ（ステップＳ１９）、そして、データを修復されたブロックはクライアントへ転送された（ステップＳ２０）。
【００６７】
ここで、データを修復されたブロックは、そのブロックが全てクライアントへ転送されるまではバッファメモリ４上に保持されており、本実施形態では、その転送が終了するまでにスペアディスクに書き込むようにする。
【００６８】
本実施形態では、通常ストリームにおいて、既にスペアディスク上に修復されているデータセグメントをスペアディスクに書き込む必要はないので、ディスクアクセスの前にそのブロックが未修復かどうかをブロック修復リスト管理部２５に問い合わせる。その結果、未修復であればブロック修復リストからそのデータのブロック識別子を除いておく（ステップＳ１０３）。
【００６９】
次に、ステップＳ１９のデータの修復が行なわれ、Ｓ２０の転送が行なわれる。
【００７０】
ここで、先の問い合わせの結果、修復済みであればスペアディスクに書き込まず、未修復であれば転送が終了するまでにスペアディスクに書き込む（ステップＳ１０４，Ｓ１０５）。
【００７１】
スペアディスクに書き込むタイミングは、バッファメモリ４上にデータが保持されている間であり、且つ、１台のスペアディスクへ複数の書き込みが重ならないようにスケジュールしなければならない。これは、図４のようにディスクアクセス、データセグメントの修復、書き込み、クライアントへの転送をスケジュールすることで可能となる。すなわち、ディスクアクセスの直後のタイムスロットから一定時間内にデータセグメントの修復を完了し、さらにその直後にスペアディスクに書き込みを行なう。データセグメントの修復とクライアントへの転送が重なることは許されないが、スペアディスクへの書き込みとクライアントへの転送が重なることは許される。図４は、１ストリーム当り４個のバッファメモリを割り付けて、クライアントへの転送時間が４スロット、データ修復時間が２スロットの場合を示している。この場合、ディスクアクセスを割り付けることが可能なタイムスロットの範囲である許容ジッター範囲は、クライアントへの転送開始より１２スロット前から２スロット前までの１０スロット分である。この例では、全てのブロックについて対応するディスクグループのスペアディスクに書き込みを行なっているが、そのディスクグループに故障ディスクが存在しない場合には、バッファメモリ上での修復とスペアディスクへの書き込みの必要はない。
【００７２】
ところで、上記のように通常ストリームを供給と修復の両方に使用する場合、修復されるブロックは供給しているストリームデータを格納しているブロックに限られる。そのブロックが修復ストリームで既に修復されている場合であっても、その通常のストリームでは他のブロックを修復することはできない。そこで、本実施形態では、修復ストリームで次に修復するブロックを選択するときに、通常のストリームで供給中のストリームデータを格納しているブロックの優先度を低くし（ステップＳ１０１）、供給していないストリームデータを格納しているブロックを優先してブロック識別子を選択する。
【００７３】
より具体的には、ブロック修復予約リスト作成時にディスクグループ毎に二種類のブロック修復予約リストを作る。一方のリストには、供給中のストリームデータを格納するブロックを表すブロック識別子を登録する（ステップＳ１０１）。もう一方には、それ以外のブロックを表すブロック識別子を登録する（ステップＳ１０２）。
【００７４】
スケジューリング部２２は、ある修復ストリームで次にアクセスするディスクグループの番号をブロック修復リスト管理部２５に渡して、次に修復すべきブロックを問い合わせる。それに対してブロック修復リスト管理部２５は、そのディスクグループの供給中でないブロックのブロック修復予約リストの先頭に登録されているブロック識別子を取り出してスケジューリング部２２に返す。このリストが空の場合には、供給中のブロックのブロック修復予約リストの最後に登録されているブロック識別子を選択する（ステップＳ１０６）。両方のリストが空の場合には、空を表すブロック識別子を返す。この場合には、修復ストリームはディスクアクセス、修復、書き込みの動作を行なわない。
【００７５】
通常のストリームでの供給が終了した場合、そのストリームデータの中で実際に修復の行なわれなかったブロックを表すブロック識別子が供給中のブロックのブロック修復予約リストに登録されているので、そのブロック識別子を全て供給中でないブロックのブロック修復予約リストに移動する（ステップＳ１０２）。逆に、新しいストリームの供給が開始された場合には、そのストリームデータのブロックを表すブロック識別子を供給中でないブロックのブロック修復予約リストから供給中のブロック修復予約リストに移動する（ステップＳ１０１）。
【００７６】
なお、ブロック修復予約リストの形態としては、各ブロック識別子の選択優先度が判別できる形態であれば良い。例えば、各ブロック識別子自体に優先度の情報を記録し、ブロック修復リスト管理部２５がその優先度情報を参照できるのであれば、ディスクグループ毎に二種類のリストを持たずに済ませることも可能である。
【００７７】
以上のように本実施形態によれば、通常のストリームで使用されていない余ったストリーム資源をディスクの修復のために最大限に利用しつつ、かつ新しいストリームの接続要求に対応して通常のストリームと修復ストリームの割合を変化させることが可能になる。
【００７８】
従って、修復ストリームによるデータの修復中であっても、既接続のストリームによるクライアントへのデータ供給に影響を及ぼさず、かつ新しいストリームの接続に制限を設けずに、故障ディスク装置を含むディスクグループの転送能力を無駄なく有効に利用してディスク装置の故障により失われたデータの修復時間を短縮することが可能である。
【００７９】
また、本実施形態によれば、現在供給されていないデータを修復ストリームで修復し、通常ストリームで供給しているデータをそのまま修復に利用することにより、修復完了時間をより短縮することができる。
【００８０】
（第３の実施形態）
次に、第３の実施形態について説明する。
【００８１】
前述した第１、第２の実施形態では、バッファメモリ上での修復とスペアディスクへの書き込みのタイミングについては、図４に示すように、クライアントへの転送時間が開始されるまでにデータを修復し、転送時間が終了するまでにスペアディスクへの書き込みを行うものとして説明した。
【００８２】
このタイミングで上記の修復処理を実行することにより、Ｒストリーム、ＲＳストリームにおいて、バッファメモリ上にデータが滞在する時間が、Ｓストリームにおけるデータ滞在時間と同じまたはそれ以下になる。つまり、ストリーム１本当たりのバッファメモリの使用量に関しては、Ｓストリーム、Ｒストリーム、ＲＳストリームの３種類のストリームで等しいと考えて良い。
【００８３】
しかし、ハードウェアの構成によっては、この修復と書き込みのタイミングが異なる場合がある。例えば、データの格納方式としてＲＡＩＤ３を用いて、データの先頭からバッファメモリへの転送を行うようなハードウェア構成を採用した場合には、クライアントへの転送時間が終了した後でスペアディスクへの書き込みを実行する。
【００８４】
以下では、上記のような場合に本発明を適用した実施形態について説明する。
【００８５】
図５に、本実施形態におけるタイミングチャートの例を示す。
【００８６】
図５（ａ）はＳストリームのバッファメモリ利用に関するタイムチャートであり、図５（ｂ）はＲＳストリームのバッファメモリ利用に関するタイムチャートである。ここでは、Ｓストリーム１本当たりブロック２個分のバッファメモリを割り当てる例を示している。
【００８７】
図５（ｂ）のようなタイミングで修復が行われる場合、ＳストリームよりもＲＳストリームおよびＲストリームの方がスペアディスクへの書き込みを行う時間だけデータのバッファメモリ滞在期間が長くなる。つまり、ストリーム１本当たりのバッファメモリの使用量に関しては、Ｓストリームよりも、ＲＳストリームおよびＲストリームの方が、より多くの資源を必要とするということになる。
【００８８】
図５（ｂ）の例では、ＲＳストリーム１本当たりブロック３個分のバッファメモリを使用する例を示している。
【００８９】
Ｓストリーム、ＲＳストリーム、Ｒストリームの使用資源量に  
Ｂｒ＝Ｂｒｓ＝ｎ×Ｂｓ  
（ＢｓはＳストリーム１本で使用する資源量、ＢｒはＲストリーム１本で使用する資源量、ＢｒｓはＲＳストリーム１本で使用する資源量）  
の関係があるとすると、各ストリームの本数の構成を動的に変化させる際には、各ストリームの数は、次式で示す条件を満たす必要がある。  
Ｎｍａｘ≧Ｎｓ＋ｎ×（Ｎｒｓ＋Ｎｒ）  
（Ｎｍａｘは最大ストリーム数、ＮｓはＳストリームの本数、ＮｒはＲストリームの本数、ＮｒｓはＲＳストリームの本数）
第１、第２の実施形態において、例えば図４で示したタイミングで動作する場合、ｎ＝１であるので、ＳストリームまたはＲＳストリーム１本が終了すれば、解放された資源でＲストリーム１本を実行できる。逆に、新ストリームの接続要求が到着した場合には、Ｒストリーム１本を解放することにより、ＳストリームまたはＲＳストリームを１本供給できる。
【００９０】
これに対して、この第３の実施形態において、例えば図５で示したタイミングで動作するでは、バッファメモリ領域をブロック２個分から３個分に増やせば修復が可能となるので、ｎ＝１．５として、Ｎｓ＋Ｎｒｓがデータを供給するストリームの本数となり、かつ、上記の条件を満たす範囲内でＮｓ，Ｎｒｓ，Ｎｒを動的に決定すれば良い。
【００９１】
本実施形態に係る実時間ストリームサーバの構成は図１と同様であり、詳細な説明は省略する。また、図６に本実施形態の動作のフローチャートの一例を示す。なお、図６中、第１、第２の実施形態の動作を示す図２、図３のフローチャートと同様の部分は同一の符号を付した。以下では、第１、第２の実施形態と相違する点を中心に説明する。
【００９２】
本実施形態は、Ｓストリームを用いる点は、第１の実施形態と同様であり、ＲＳストリームを用いる点は、第２の実施形態と同様であるが、ＲＳストリームにおいて、ステップＳ２１０で、データ修復とクライアントへの転送を行った後に、ステップＳ１０５で、スペアディスクへの書き込みを実行する点が、第２の実施形態におけるＲＳストリームと相違する。
【００９３】
また、本実施形態では、１つの通常ストリームを、動的にＳストリームとＲＳストリームの間で遷移させる制御を行う点が、第１、第２の実施形態と相違する。
【００９４】
より具体的には、以下で説明するステップＳ２０１〜Ｓ２０２の処理（１）〜処理（４）の部分が、第１、第２の実施形態と異なる。
【００９５】
（ステップＳ２０１の処理（１））
新しいストリームの接続要求があった場合、まず、各ストリームの本数に応じて、新ストリームをＳストリームとして供給を行うか、ＲＳストリームとして供給／（故障ディスクの）修復を同時に行うかを選択する。
【００９６】
もし、要求されたストリームデータの最初に転送すべきブロックの修復が完了しておらず、かつ、未使用のストリーム資源からＢｒｓの資源が確保できる場合または幾つかのＲストリームを中断すればＢｒｓの資源が確保できる場合には、新ストリームをＲＳストリームとし、（後者の場合、幾つかのＲストリームを中断した後、）新ストリームに資源を割り当てる。
【００９７】
一方、上記以外の場合には、新ストリームは、Ｓストリームとする。ただし、他のＲＳストリームが存在し、幾つかのＲストリームを中断するだけではＢｒの資源が確保できない場合には、さらに、既存のＲＳストリームをＳストリームに変更して、不要になったストリーム資源（Ｂｒｓ−Ｂｓ）を解放する。
【００９８】
なお、既存のＲストリームとＲＳストリームを全て中断してもＢｒの資源が確保できない場合には、新ストリームの接続要求を受理することはできない。
【００９９】
（ステップＳ２０２の処理（２））
ＳストリームまたはＲＳストリームによるデータの供給が終了した場合、割り当てられていたストリーム資源を解放する。そして、解放されたストリーム資源を含めて、未使用の資源を新Ｒストリームに割り当てる。
【０１００】
（ステップＳ２０３の処理（３））
Ｓストリームでのデータの供給中において、次のブロックが未修復であり、かつ、幾つかのＲストリームを中断することによってＢｒｓの資源が確保できる場合には、幾つかのＲストリームを中断して、そのＳストリームをＲＳストリームに変更する。
【０１０１】
（ステップＳ２０４の処理（４））
ＲＳストリームでのデータ供給中において、そのＲＳストリームでスペアディスクへ書き込むべきブロックがバッファメモリ上になく、かつ、次のブロックが修復済みである場合には、そのＲＳストリームをＳストリームに変更して、不要になったストリーム資源（Ｂｒｓ−Ｂｓ）を解放する。そして、解放されたストリーム資源を含めて、未使用の資源を新Ｒストリームに割り当てる。
【０１０２】
以上のように本実施形態によれば、通常のストリームで使用されていない余ったストリーム資源をディスクの修復のために最大限に利用しつつ、かつ新しいストリームの接続要求に対応して通常のストリームと修復ストリームの割合を変化させることが可能になる。
【０１０３】
従って、修復ストリームによるデータの修復中であっても、既接続のストリームによるクライアントへのデータ供給に影響を及ぼさず、かつ新しいストリームの接続に制限を設けずに、故障ディスク装置を含むディスクグループの転送能力を無駄なく有効に利用してディスク装置の故障により失われたデータの修復時間を短縮することが可能である。
【０１０４】
また、本実施形態によれば、現在供給されていないデータを修復ストリームで修復し、可能な限り通常ストリームで供給しているデータをそのまま修復に利用することにより、修復完了時間をより短縮することができる。
【０１０５】
なお、ストリーム資源が必要になり、Ｒストリームを中断すると、中断のタイミングによっては、そのＲストリームにおいて読み出したデータをバッファメモリ上で修復する以前あるいは修復したデータをスペアディスクへ書き込む以前に資源を解放することになる場合がある。そこで、Ｒストリームを解放する必要がある場合には、バッファメモリへのデータの読み出しは完了したが未だ修復／書き込みを行っていないブロックが少ないＲストリームから順に中断して資源を解放すると良い。
【０１０６】
ところで、未修復のブロックと修復済みのブロックが複雑に入り混じったストリームデータが生じる可能性がある。このようなストリームデータをＲＳストリームで修復する場合には、ＲＳストリームとＳストリームの切替が頻繁に生じる。すると、切替えの度に中断されるＲストリームが生じて、修復途中のブロックが無駄になるばかりか、ＲＳ／Ｓストリームの切替のオーバーヘッドが大きくなる可能性がある。
【０１０７】
このような問題が生じるときには、上記のステップＳ２０４の処理（４）におけるＲＳストリームをＳストリームに変更する条件を、例えば次のように変更すると良い。
【０１０８】
（ステップＳ２０４の処理（４））
ＲＳストリームでのデータ供給中において、そのＲＳストリームで、Ｌ個連続して既に修復済みのブロックをクライアントに供給した場合には、そのＲＳストリームをＳストリームに変更する。
【０１０９】
不要になったストリーム資源（Ｂｒｓ−Ｂｓ）は解放し、解放されたストリーム資源を含めて、未使用の資源を新Ｒストリームに割り当てる。
【０１１０】
これにより、ＲＳストリームとＳストリームの間の切替の回数を抑えることができる。
【０１１１】
なお、図６は、修復すべきブロックの選択優先度を用いない場合の手順であるが、第２の実施形態と同様に修復すべきブロックの選択優先度を用いても良い。本実施形態では、通常ストリームとしてスペアディスクへの書き込みを行わないＳストリームとスペアディスクへの書き込みを行うＲＳストリームが存在するが、ここでは、各々の通常ストリームで供給されているストリームデータの選択優先度を画一的に下げる。この場合の手順の一例を図７に示す。
【０１１２】
また、本実施形態において、第２の実施形態のように、Ｓストリームは用いず、ＲＳストリームを固定的に用いるようにしても良い。この場合、図６や図７で説明した手順から、Ｓストリームに関する部分を削除すれば良い。
【０１１３】
また、前述したようにクライアントへの転送時間が開始されるまでにデータを修復し、転送時間が終了するまでにスペアディスクへの書き込みを行う第２の実施形態において、ＲＳストリームに必要な資源が、Ｓストリームに必要な資源を上回るような場合には、第３の実施形態のように、ＳストリームとＲＳストリームを動的に変更するようにしても良い。
【０１１４】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【図面の簡単な説明】
【０１１５】
【図１】本発明の第１、第２および第３の実施形態に係る実時間ストリームサーバのディスク修復装置を示す図
【図２】本発明の第１の実施形態の動作を示すフローチャート
【図３】本発明の第２の実施形態の動作を示すフローチャート
【図４】スケジューリングされた通常ストリームのバッファメモリ利用状況と動作のタイミングを説明するための図
【図５】本発明の第３の実施形態において、スケジューリングされた通常ストリームのバッファメモリ利用状況と動作のタイミングを説明するための図
【図６】本発明の第３の実施形態の動作を示すフローチャート
【図７】本発明の第３の実施形態の他の動作を示すフローチャート
【符号の説明】
【０１１６】
２…制御装置、２１…接続要求処理部、２２…スケジューリング部、２３…修復ストリーム割り付け部、２４…修復ストリーム解放部、２５…ブロック修復リスト管理部、３…データ蓄積部、３２…ディスク装置、４…バッファメモリ、５…データ転送部、６…故障検出部
【図１】
2004342135.tif 000003
【図２】
2004342135.tif 000004
【図３】
2004342135.tif 000005
【図４】
2004342135.tif 000006
【図５】
2004342135.tif 000007
【図６】
2004342135.tif 000008
【図７】
2004342135.tif 000009