(57)【要約】メディア・エリア・ネットワーク（１０）は、ディジタル化された情報を記憶するための少なくとも１個の記憶デバイス（１８）を有する記憶システム（１６）を具える。ホスト・バス・アダプタ（１４）は、記憶システムとホスト・システム（１２）の間のリンクとなる。ホスト・システム（１２）はメディア・エリア・ネットワークを全体的に制御する。ホスト・バス・アダプタの内部で、下位レベルのポート・ドライバ（２４）は記憶システムとホスト・バス・アダプタの間の通信をモニタする。通信の故障の際、下位レベルのポート・ドライバは、故障したポートから代りのポートに切り替えて、フェイル‐オーバ・リカバリを達成する。フェイル‐オーバ・リカバリの責任を下位レベルのポート・ドライバに割り当てることにより、ポートの故障が適時に処理され、それにより、待ち時間による潜在的遅延が短縮される。
2005535034.tif 000002
【特許請求の範囲】
【請求項１】
ディジタル化された情報を記憶する少なくとも１個の記憶デバイスを含む記憶システムと、
メディア・エリア・ネットワークを全体的に制御するホスト・システムと、
前記ホスト・システムと前記記憶システム間のリンクを供給するホスト・バス・アダプタと、からなる、前記メディア・エリア・ネットワークにおいて、
前記ホスト・バス・アダプタは下位レベルのポート・ドライバを具え、該下位レベルのポート・ドライバは、動作中のポートを介して前記記憶システムとホスト・バス・アダプタ間の通信をモニタするモニタ手段と、リアルタイムで代替ポートに切り替えることにより通信の故障の際に故障からの回復を達成する切替え手段と、を含んでいる、前記メディア・エリア・ネットワーク。
【請求項２】
前記モニタ手段は更に、前記記憶システムが少なくとも１つのコマンドの完了に成功したかどうかを確認する手段を含む、請求項１記載のメディア・エリア・ネットワーク。
【請求項３】
前記モニタ手段は更に、前記少なくとも１つのコマンドの完了の不成功を故障からの回復により変更できるかどうかを確認する手段を含む、請求項２記載のメディア・エリア・ネットワーク。
【請求項４】
前記切替え手段は更に、前記少なくとも１つのコマンドの完了の不成功が故障からの回復により変更できることが確認されると、故障からの回復を計る手段を含む、請求項３記載のメディア・エリア・ネットワーク。
【請求項５】
故障からの回復を計る前記手段が更に、故障した最初のポートから代替ポートにリクエストをキューする手段と、
最初のポート上で未処理のリクエストをすべてキャンセルする手段と、
前記代替ポートを介して少なくとも１つのコマンドを発する手段と、からなる、
請求項４記載のメディア・エリア・ネットワーク。
【請求項６】
ディジタル化された情報を記憶する少なくとも１個の記憶デバイスを有する記憶システム、メディア・エリア・ネットワークを全体的に制御するホスト・システム、およびホスト・システムと記憶システム間のリンクとなるホスト・バス・アダプタを具えるメディア・エリア・ネットワークで、故障からの回復を達成する方法であって、
前記ホスト・バス・アダプタ内の下位レベルのポート・ドライバにおいて前記記憶システムとホスト・バス・アダプタ間の通信状態をモニタするステップと、
故障発生時に、前記下位レベル・ポート・ドライバにおいて切替えを開始し、代替ポートを起動することにより、故障からの回復を達成するステップと、からなる前記方法。
【請求項７】
前記記憶システムとホスト・バス・アダプタ間の通信状態をモニタするステップは更に、前記記憶システムが少なくとも１つのコマンドの完了に成功したかどうかを確認するステップを含む、請求項６記載の方法。
【請求項８】
前記少なくとも１つのコマンドの完了の不成功を故障からの回復によって変更できるかどうかを確認するステップを更に含む、請求項７記載の方法。
【請求項９】
前記少なくとも１つのコマンドの完了の不成功を故障からの回復によって変更できることが確認されると、故障からの回復を計るステップを更に含む、請求項８記載の方法。
【請求項１０】
故障した最初のポートから代替ポートにリクエストをキューするステップと、
前記最初のポート上で未処理のリクエストをすべてキャンセルするステップと、
前記代替ポートを介して少なくとも１つのコマンドを発するステップと、を更に含む、請求項９記載の方法。
【請求項１１】
前記未処理のコマンドのキャンセルが生じたかどうか検査し、生じていなければ、故障した記憶システム・コントローラの故障からの回復を開始するステップを更に含む、請求項１０記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディア・エリア・ネットワーク（ｍｅｄｉａ  ａｒｅａ  ｎｅｔｗｏｒｋ）内の記憶デバイスが故障からの回復を達成するための技術に関する。
【背景技術】
【０００２】
放送事業においては、メディア・エリア・ネットワーク（Ｍｅｄｉａ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：ＭＡＮ）が存在し、メディア・エリア・ネットワークは、非リアルタイムのオペレーティング・システムを実行する中央処理装置の形式でホスト・システムを備えている。外部のストレージ機能からのデータをホストバスに渡すためのインターフェースとバスを提供するホスト・バス・アダプタ（ｈｏｓｔ  ｂｕｓ  ａｄａｐｔｅｒ）が、ホスト・システムを１つ以上の記憶デバイスを含む記憶システムにリンクさせる。各デバイスは、独立型のディスクあるいはＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｅｘｐｅｎｓｉｖｅ  Ｄｉｓｋｓ：複数の小型ハードディスク装置を使って、単独のＨＤＤよりも高い信頼性や性能を実現する方式）の形式を取ることができる。実際、各記憶デバイスは、編集および／または放送用に利用できるディジタル化されたビデオを保持する。信頼性を確保するために、メディア・エリア・ネットワーク内部のすべての構成部品は、故障に耐えられるもので、冗長性を有し、故障が生じた場合にリアルタイムの回復が得られるように努めている。このようなリアルタイムの回復は、記憶システムの記憶デバイスに記憶されたビデオがライブで送信されるときに特に重要となる。
【０００３】
メディア・エリア・ネットワークに故障が生じると、故障の箇所は回復に要する時間に影響を及ぼす。例えば、或る記憶デバイスに割り当てられたポートに関する故障を考える。このような故障が発生すると、エラー信号がファイバ・チャンネル構造の中に伝播して、そのエラー信号をホスト・バス・アダプタに送信する。一般にホスト・バス・アダプタは、故障から回復するため、故障したポートから代替ポートに切り替える機能を有する。あいにく、現在のホスト・バス・アダプタは始めから、メディア・エリア・ネットワークに要求されるリアルタイム性能をサポートしていない。現行のホスト・バス・アダプタでは通常、相当の待ち時間を生じる。エラーの受信からポートの切替えまでに１０秒もの遅延を生じ得る。このような遅延は重大な支障をもたらす。現在、ポートの故障を管理する故障からの回復のソフトウェアを提供しているホスト・バス・アダプタの製造者もいるが、そうしたソフトウェアは、トランスペアレント（透明）またはシームレス（継目なし）であるとは言えない。実験的テストによれば、こうしたソフトウェアは１５秒もの待ち時間の遅延を被ることが明らかにされている。従って、メディア・エリア・ネットワークにおける故障をほぼリアルタイムで回復させる技術が必要である。
【発明の開示】
【０００４】
（発明の概要）
簡単に言うと、本発明の原理により、メディア・エリア・ネットワーク（ＭＡＮ）には、ホスト・システム（ｈｏｓｔ  ｓｙｓｔｅｍ）と、少なくとも１個の記憶デバイスを有する記憶システムと、ホスト・システムを記憶システムにリンクさせるホスト・バス・アダプタ（ｈｏｓｔ  ｂｕｓ  ａｄａｐｔｅｒ）と、が含まれる。エラーが発生するとホスト・バス・アダプタの内部で、記憶システムより発生される信号の存在をポート・ドライバ（ｐｏｒｔ  ｄｒｉｖｅｒ）がモニタする。エラー信号に応答してポート・ドライバは、故障したポートと代替ポート間の切替えを自動的に開始し、故障からの回復を達成する。故障からの回復の役割をポート・ドライバに割り当てることにより、ポートの故障が適時に処理され、待ち時間による遅延を短縮することができる。
【発明を実施するための最良の形態】
【０００５】
図１は、ホスト・バス・アダプタ１４によって記憶システム１６にリンクされるホスト・システム１２を含む、メディア・エリア・ネットワーク（ＭＡＮ）１０の実施例の概略ブロック図を示す。記憶システム１６には１つ以上の記憶デバイス（デバイス１８で例示する）が含まれる。各記憶デバイス１８は個別のデバイスまたはＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｅｘｐｅｓｉｖｅ  Ｄｉｓｋｓ：ディスクの冗長アレイ）の形態を取る。各記憶デバイス１８は、ディジタル化されたビデオのようなディジタル化情報を圧縮／または非圧縮形式で多量に記憶する容量を有する。記憶システム１６内でファイバ・チャンネル構造（ｆｉｂｅｒ  ｃｈａｎｎｅｌ  ｆａｂｒｉｃ）２０が各記憶デバイス１８をホスト・バス・アダプタ１４に結合させる。一般に、ファイバ・チャンネル構造２０は、１つ以上の従来のファイバ・チャンネル・スイッチおよび対応するリンク（図示せず）の形式を取る。
【０００６】
ホスト・バス・アダプタ１４は、ホスト・システム１２と記憶システム１６との間で切替え可能な経路を供給する。リアルタイムのオペレーティング・システムはほかにも存在しており簡易に使用できるが、ホスト・バス・アダプタ１４は、ＶｘＷｏｒｋｓ（商標）オペレーティング・システム（Ｗｉｎｄ  Ｒｉｖｅｒ  Ｓｙｓｔｅｍ，Ｉｎｃ．、カリフォルニア州アラメダ市、から入手できる）のようなリアルタイムのオペレーティング・システムを実行するプロセッサの形式でリアルタイムのカーネル（ｋｅｒｎｅｌ：核心部）２２を具える。リアルタイムのカーネル２２は、下位レベルのＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ：小型コンピュータ・システム・インタフェース）ポート・ドライバ２４を制御する。インタフェース・ポート・ドライバ２４は、本発明の原理に従い、リアルタイムの故障からの回復機能を提供する。特に、下位レベルのポート・ドライバ２４は論理回路を（専用の回路またはプログラム可能なプロセッサの形式で）具え、情報を記憶システム１６に配信し／記憶システム１６から搬出する個々のポートおよび対応するリンク（何れも図示せず）の状態をモニタする。冗長性を確保するために各記憶デバイス１８は、デュアル・リンクおよびデュアル・ポートを介してホスト・バス・アダプタ１４への接続を維持する。一方のポートおよびそれに対応するリンクが動作している間、他方のポートおよびそれに対応するリンクは代替ポート／リンクを提供する。故障（例えば、以前から動作しているポートおよび／またはそれに対応するリンクの故障）が生じると、下位レベルのポート・ドライバ（ｐｏｒｔ  ｄｒｉｖｅｒ）２４は代替ポート（およびその対応するリンク）に切り替えて故障からの回復を達成する。図２および図３に関して詳細に説明するが、下位レベルのポート・ドライバ２４は、ポートの切替えに関する決定（並びに、冗長記憶デバイスおよび／またはデバイス・コントローラを起動させることに関する決定）を行う。従って、下位レベルのポート・コントローラ２４はホスト・システム１２をこの役割から解放し、待ち時間による遅延を短縮することができる。また、下位レベルのポート・ドライバ２４は、ファイバ・チャンネル構造２０を通るＳＣＳＩのＩ／Ｏトラフィックの通信を容易にする。
【０００７】
図１のＭＡＮ１０の実施例で、ホスト・バス・アダプタ１４は、デュアル接続（すなわち、各チャンネルごとに２つのリンクと２つのポート）を経由してファイバ・チャンネル構造２０に接続する。同様にして、記憶システム１６／１８も各ＲＡＩＤシャーシごとに２つの接続を経由してファイバ・チャンネル構造２０に接続する。このようにして、２つのホスト・ポートのうちどちらかが、各ＲＡＩＤシャーシにつき２個のコントローラ（図示せず）のどちらかと通信できるので、これらのポートと２つのＲＡＩＤコントローラの間で独立した故障からの回復が許される。各ホスト・ポートは、ＲＡＩＤシャーシ内でどちらか一方のＲＡＩＤコントローラを使用できる。従って、故障発生の際、ＲＡＩＤコントローラを切り替えることなくホスト・ポートの切替えが行われ、ホスト・ポートを切り替えることなくＲＡＩＤコントローラの切替えが行われる。
【０００８】
ホスト・システム１２は、非リアルタイムのカーネル２６を介して、ＭＡＮ１０を全体的に制御する。カーネル２６は、Ｍｉｃｒｏｓｏｆｔ社（ワシントン州レドモンド市）のＷｉｎｄｏｗｓ（登録商標）オペレーティング・システム、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ社（カリフォルニア州サンタクララ市）のＳｏｌａｒｉｓ（Ｒ）（米国における登録商標）オペレーティング・システム、あるいはＬｉｎｕｘオペレーティング・システムのような、非リアルタイムのＯＳを実行するプロセッサの形式を取る。非リアルタイムのカーネル２６は、各記憶デバイス１８と直接接続せずに、メッセージング技術によってホスト・バス・アダプタ１４と通信して、記憶システム１６とホスト・システム１２間の情報伝達（通信）を管理する。
【０００９】
図２に示すフローチャートは、記憶システム１６（図１）内の記憶デバイス１８より発生されるインタラプト（ｉｎｔｅｒｒｕｐｔ：割込み）を補助するタスクを実現するために、下位レベルのポート・ドライバ２４（図１）により実行される方法のステップを示す。インタラプトを補助するタスクはステップ１００を実行すると開始され、このステップ１００の間、下位レベル・ポート・ドライバ２４は、記憶デバイス１８が正常にコマンドを完了したかどうか検査する。正常に完了していれば、下位レベル・ポート・ドライバ２４は、ステップ１１０（図２）の間、そのコマンドの完了に成功したことをホスト・システム１２に通知する。ステップ１００で記憶システムのコマンドの実行に成功しないと、ステップ１２０の間、そのエラーが訂正可能かどうか検査される。換言すれば、下位レベルのポート・ドライバ２４は、代替ポートまたはコントローラに切り替えることにより、発生したエラーが訂正可能かどうか判定する。訂正不可能と判定されると、ステップ１３０の間、ホスト・システム１２はその旨の通知を受け取る。訂正可能なエラーの場合、ステップ１４０の間、下位レベル・ポート・ドライバ２４は、そのエラーを発生した記憶デバイスに関連するポート（図示せず）を非動作状態にあるとしてマークする。従って、ステップ１５０の間、下位レベルのポート・ドライバ２４は故障からの回復のタスク（すなわち、代替ポートを選択するタスク）を計る。
【００１０】
図３に示すフローチャートは、下位レベルのポート・ドライバ２４（図１）で実行される故障からの回復のタスクのステップを示す。故障からの回復のタスクは、図３のステップ２００を実行すると開始される。ステップ２００の間、下位レベル・ポート・ドライバ２４は、故障からの回復のタスクを行うべきであることを伝える信号（図２のインタラプト・タスクからの）を待つ。故障からの回復のタスクが作動することを知ると、ステップ２１０の間、下位レベルのポート・ドライバ２４は、非動作状態にある（故障している）ポートからのすべてのリクエストをキュー（ｑｕｅｕｅ：待ち行列）に入れる。その後、ステップ２１５の間、下位レベルのポート・ドライバ２４は典型的にはＴＰＰＬＯ（Ｔｈｉｒｄ  Ｐａｒｔｙ  Ｐｒｏｃｅｓｓ  Ｌｏｇ  Ｏｕｔ：第三者プロセス・ログ・アウト）コマンドにより、最初の（今は非動作状態にある）ポートからの未処理のリクエストをすべてキャンセルする。次に、ステップ２２０の間、ＴＰＰＬＯコマンドが履行されなかったか検査がなされる。ステップ２２０の間に、ＴＰＰＬＯコマンドの不履行を検出すると、下位レベルのポート・ドライバ２４は、ステップ２２５の間、記憶デバイス１８に関連するコントローラ、一般にＲＡＩＤコントローラ（図示せず）、が故障したかまたはそのコントローラに関連する経路が故障したと推側する。このような状況下で、下位レベルのポート・ドライバ２４は、冗長ＲＡＩＤコントローラを作動させることにより、回復を開始する。
【００１１】
ステップ２２５（ＴＰＰＬＯコマンドが不履行とならなかったとき、ステップ２２０）に続き、ステップ２３０の間、下位レベルのポート・コントローラ２４は、記憶デバイス１８からの応答であるＴＵＲ（Ｔｅｓｔ  Ｕｎｉｔ  Ｒｅａｄｙ：テスト装置の準備が整う）を完了（「クリーン・アップ」）する。最後に、ステップ２４０の間に、下位レベルのポート・コントローラ２４は、新しく起動された代替ポートを介してコマンド（ステップ２１０の間、再試行するために以前キューに入れられたコマンドを含む）を発する。その後、プログラムの実行がステップ２００に戻り、回復タスクを待つ。
【００１２】
上述したのは、メディア・エリア・ネットワークにおいて記憶デバイスの故障からの回復を達成するための技術であって、これにより下位レベルのポート・ドライバ２４が、故障した（動作していない）ポートをモニタし、それから、代替ポートに切り替えて回復を達成することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の原理による、リアルタイムの故障からの回復を達成するメディア・エリア・ネットワークの概略ブロック図を示す。
【図２】図１のメディア・エリア・ネットワークで、記憶デバイスより発生されるインタラプト（割り込み）を補助するタスクを実行するためのステップをフローチャートで示す。
【図３】図２に示すインタラプト（割り込み）を補助するタスクの間、或る種のエラーを検出した後に、リアルタイムの故障からの回復を実行するためのステップをフローチャートで示す。
【図１】
2005535034.tif 000003
【図２】
2005535034.tif 000004
【図３】
2005535034.tif 000005
【国際調査報告】
2005535034.tif 000006
2005535034.tif 000007