(57)【要約】【課題】コンピュータ・システムのクラスタに対し、ストレージエリアネットワーク内のデータ記憶装置へのリアルタイム・アクセスを保証する。【解決手段】プロセスが帯域幅予約のリクエストを発信し、これが当初は要求元プロセスと同一ノード上のデーモンにより扱われる。ローカル・デーモンは、帯域幅が利用可能か否かを判定し、利用可能な場合はローカル・ノード上の共通ハードウェアに帯域幅を予約し、次いで、共有リソースに対するリクエストをクラスタのマスター・デーモンへ転送する。マスター・デーモンは、ストレージエリアネットワーク内のデータ記憶要素を含む、クラスタにより共有されるリソースに対して同様の判定および予約を行ない、利用可能帯域幅の総量を超えないリクエストを承認する。【特許請求の範囲】
【請求項１】
リアルタイム・アプリケーションによりストレージエリアネットワークにアクセスする方法であって、
前記ストレージエリアネットワーク内のノードで実行されている前記リアルタイム・アプリケーションによるマスター・デーモンから、前記ストレージエリアネットワーク内のリソースへアクセスすべく帯域幅の予約を要求するステップと、
前記マスター・デーモンにより、各リアルタイム・アプリケーションによる前記ストレージエリアネットワーク内のリソースへのアクセスをスケジューリングするステップとを含む方法。
【請求項２】
前記マスター・デーモンによるスケジューリングの間に決定された少なくとも１個のスケジュールを各要求元ノードへ配信するステップと、
前記少なくとも１個のスケジュールに含まれる対応スケジュールに従い、各要求元ノード上の各リアルタイム・アプリケーションによる前記ストレージエリアネットワーク内のリソースへのアクセスを制限するステップとを更に含む、請求項１に記載の方法。
【請求項３】
前記ストレージエリアネットワーク内のノードにより、前記リアルタイム・アプリケーションのどの１個からも要求されていない、追加分の帯域幅を予約するステップを更に含む、請求項２に記載の方法。
【請求項４】
前記ストレージエリアネットワーク内のノードの１個にあるローカル・デーモンにより、前記ストレージエリアネットワークへのアクセス用に予約された追加分の帯域幅を、前記ノードの１個で実行されていて、かつ帯域幅リクエストを前記ローカル・デーモンへ発信していないアプリケーションに割り当てるステップを更に含む、請求項３に記載の方法。
【請求項５】
前記追加分の帯域幅を割り当てるステップが、ローカル・デーモンにより帯域幅に対するリクエストが承認されたリアルタイム・アプリケーションの少なくとも１個に対し、帯域幅を割り当てるステップを更に含み、その際に前記ノードの１個のために前記ローカル・デーモンが前記マスター・デーモンから追加分の帯域幅を要求する必要がない、請求項４に記載の方法。
【請求項６】
前記スケジューリングするステップが、
ある経路に沿って各リクエストが要求した利用可能な帯域幅を決定するステップと、
全ての承認されたリクエストの予約済み帯域幅の総量が利用可能帯域幅の総量よりも小さい場合のみ前記ストレージエリアネットワークのリソースを承認するステップとを含む、請求項１に記載の方法。
【請求項７】
各々に関連付けられた経路が、リクエストを発信している前記ストレージエリアネットワーク内のノードから、前記ストレージエリアネットワーク内の少なくとも１個のデータ記憶要素までである、請求項６に記載の方法。
【請求項８】
各リクエストが前記少なくとも１個の記憶要素、必要とされる周期的帯域幅、開始時刻および前記少なくとも１個の記憶要素へのアクセスするための予約持続期間を識別する、請求項７に記載の方法。
【請求項９】
前記決定するステップが、
リクエストを発信している前記ストレージエリアネットワーク内のノードにおける入出力インターフェースから、少なくとも１個の記憶要素の各々への経路を決定するステップと、
前記経路に沿って、少なくとも１個のコンポーネント用に利用可能な帯域幅を決定するステップとを含む、請求項８に記載の方法。
【請求項１０】
前記承認するステップが、前記少なくとも１個のコンポーネントの各々が前記リクエストにより識別される要求された周期的帯域幅を超える利用可能帯域幅を有する場合に実行され、かつ前記少なくとも１個のコンポーネントの各々における予約済み帯域幅を、前記リクエストにより識別される要求された周期的帯域幅分だけ増大させるステップを含む、請求項９に記載の方法。
【請求項１１】
前記マスター・デーモンにより、前記ストレージエリアネットワーク内のノードにより共有可能なコンポーネントの予約済み帯域幅および利用可能帯域幅の総量のマスター・データベースを管理するステップを更に含む、請求項１０に記載の方法。
【請求項１２】
帯域幅予約のリクエストが発信された、前記ストレージエリアネットワーク内の各ノードのローカル・デーモンにより、ローカルに発信されたリクエスト用の予約済み帯域幅および当該ノードで実行されるプロセスにより共有されるローカル・ノード・コンポーネント用の利用可能帯域幅の総量のローカル・データベースを管理するステップを更に含む、請求項１１に記載の方法。
【請求項１３】
前記少なくとも１個のコンポーネントが前記ストレージエリアネットワーク内のディスク記憶装置の一部を含む、請求項１１に記載の方法。
【請求項１４】
前記少なくとも１個のコンポーネントが、システム・メモリからファイバー・チャネル・アダプタへのホスト・バスを更に含む、請求項１３に記載の方法。
【請求項１５】
リアルタイム・アプリケーションによりストレージエリアネットワークにアクセスする方法を実行するコンピュータ・システムを制御するコンピュータ可読な記憶装置であって、前記方法が、
前記ストレージエリアネットワーク内のノードで実行されている前記リアルタイム・アプリケーションによるマスター・デーモンから、前記ストレージエリアネットワーク内のリソースへアクセスすべく帯域幅の予約を要求するステップと、
前記マスター・デーモンにより、各リアルタイム・アプリケーションによる前記ストレージエリアネットワーク内のリソースへのアクセスをスケジューリングするステップとを含む記憶装置。
【請求項１６】
コンピュータ・システムのクラスタであって、
共有可能なリソースを有するストレージエリアネットワークと、
前記ストレージエリアネットワークに接続されたコンピュータ・システム・ノードであって、前記ストレージエリアネットワーク内の共有可能なリソースにアクセスすべく、前記コンピュータ・システム・ノードの１個で動作しているマスター・デーモンに対し、帯域幅の予約のリクエストを発信するリアルタイム・アプリケーションを実行するコンピュータ・システム・ノードとを含み、前記マスター・デーモンが前記リクエストに応答して、各リアルタイム・アプリケーションによる前記ストレージエリアネットワーク内の共有可能なリソースへのアクセスをスケジューリングするクラスタ。
【請求項１７】
データ構造を保存する少なくとも１個のコンピュータ可読な媒体であって、前記データ構造が、
ストレージエリアネットワーク内のノードで実行されているリアルタイム・アプリケーションにより共有可能なコンポーネントの予約済みネットワーク帯域幅および利用可能なネットワーク帯域幅の総量のマスター・データベースと、
各々が、ローカル・ノードで実行されるリアルタイム・アプリケーションにより共有されるローカル・ノード・コンポーネントの予約済みローカル帯域幅およびローカル利用可能な帯域幅の総量を保存しているクライアントノード・データベースとを含む媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイム・コンピュータ処理、より具体的にはリアルタイム・コンピュータ・システムによるストレージエリアネットワーク（ＳＡＮ）へのアクセスに関している。
【背景技術】
【０００２】
デジタル媒体ファイルの放送、マルチキャストおよび編集、並びにセンサー・データの収集や処理等、多くのアプリケーションでリアルタイムに記憶領域へアクセスする必要がある。カリフォルニア州マウンテンビュー（Ｍｏｕｎｔａｉｎ  Ｖｉｅｗ，Ｃａｌｉｆｏｒｎｉａ）のシリコングラフィックス社（Ｓｉｌｌｉｃｏｎ  Ｇｒａｐｈｉｃｓ，Ｉｎｃ．）（ＳＧＩ）から販売されている帯域保証Ｉ／Ｏ（Guaranteed Rate I/O:ＧＲＩＯ）ディスク帯域幅スケジューラを含むリアルタイムのデータ・アクセスを提供する多くの方法が提案および実装されてきた。同様にＳＧＩ社から販売されているＸＬＶディスク・ボリューム・マネージャと合わせて、ＧＲＩＯにより保証されたディスク帯域幅予約がローカル・クライアント側で行なえるようにする。帯域幅予約は、個々のファイルまたはファイルシステム全体に付与され、プロセス間で共有可能である。ＧＲＩＯに対応すべく、ローカル記憶装置を適切に設定する必要がある。アプリケーションが必要とするデータ量が単一のディスクにより提供可能な量より多い場合、ディスクをボリューム構成にして、データを数個のディスクにストライピング（１つのデータを２つ以上の記憶装置に分けて同時に書き込むこと）するか、多数のディスクにスタガー(stagger)させることにより、異なるプロセスが異なるディスクに個別にアクセスできるようにする必要がある。
【０００３】
ＧＲＩＯは、ＩＲＩＸ（登録商標）（ＳＧＩ社版ＵＮＩＸ（登録商標））の入出力システムと一体の部分であり、確実にリアルタイム・アクセスを保証する。ＧＲＩＯは、リクエストの再配置をしないフレーム・ベースのディスク・ブロック・スケジューラを用いて、システム内のハードウェアの異なる部分およびそれらの帯域幅特性のデータベースを管理する。ローカル・クライアントノードで実行されているプロセスから帯域幅予約を受信したならば、複数プロセッサがアクセスする入出力アダプタから始めて、ローカル・データ記憶装置に至るまで、物理入出力経路全体に存在するコンポーネント用に利用可能な帯域幅が決定される。当該経路に存在する各コンポーネントにおける全プロセスの予約帯域の総量が、当該コンポーネントで利用可能な帯域幅の総量を下回るように維持されている。このレベルを超えるならば、ＧＲＩＯデーモンはリクエストの承認を拒否する。デーモンは、ＵＮＩＸ（登録商標）系ＯＳにおいて、メモリに常駐して様々なサービスを提供するソフトウェアである。超過帯域を求めるリクエストを処理している間に残りの予約が悪影響を受けない限り、予備の容量を使用してプロセスが超過帯域を消費してもよい。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＧＲＩＯは個々のクライアントノードで利用可能であるが、ストレージエリアネットワーク（ＳＡＮ）を介してノードのクラスタにより共有されるデータ収納部へのリアルタイム・アクセスを保証する公知のクライアントソフトウェア・ソリューションは存在しない。これに最も近い公知のソリューションは、ＳＡＮに保存されているファイルをローカル記憶装置にコピーして、ＧＲＩＯを用いてローカル記憶装置内のファイルへのアクセスの同期化を制御するものである。この技術は、非線型編集等、ある種の用途に適しているが、例えばビデオファイルの大規模なオンデマンド・マルチキャスティングには望ましくない。その理由は、ＳＡＮのリソースへのリアルタイム・アクセスが保証されていれば必要がない筈の、大量のローカル記憶装置が余計に必要になるためである。
【０００５】
上述のソリューションでは得られない、いくつかの利点がＳＡＮにはある。データへのアクセスが耐障害性を有する点がＳＡＮの主な利点の一つである。更に、同一の物理記憶装置の負荷バランス調整や異なるクライアントからのアクセスを行なえる点も、ＳＡＮを用いたクラスタ型ファイルシステムにより得られる利点である。
【０００６】
これらの利点のいくつかを得る別の方法として、ネーグル（Ｎａｇｌｅ）による「アクティブ・ストレージ・ネットワーク（Ａｃｔｉｖｅ  Ｓｔｏｒａｇｅ  Ｎｅｔｓ）」（ＤＡＲＰＡ／ＩＴＯアクティブ・ネットワーク会議、１９９８年７月）に提案されているように、ディスク・コントローラ・ファームウェアを変更してデータ・リクエストのスケジューリングと再配置を行ない、知的ディスク・ネットワークを用いる方法がある。ネーグルは、サービス品質保証に適合するために要に応じてストライピング構成を再配置可能な知的ディスクドライブのネットワークを提案した。これは、ディスクドライブに知能を与えて、知的ディスクドライブを接続する能動的に再構成可能なネットワークの提供を必要とする。ＳＡＮへのアクセスを提供するクラスタ型ファイルシステムに加える変更が少なくて済む、より簡単なソリューションが費用対効果の観点から好ましい。
【課題を解決するための手段】
【０００７】
本発明の一態様は、共有クラスタ型記憶装置へのデータ・アクセス速度を保証することである。
【０００８】
本発明の別の態様は、記憶装置または相互接続に対するハードウェアの変更を必要とせずに共有クラスタ型記憶装置へのデータ・アクセス速度を保証することである。
【０００９】
本発明の更なる態様は、放送またはマルチキャスティング用にファイルへのリアルタイム・アクセスを提供するとともに、同時に、現在放送またはマルチキャストされていないファイルの編集を可能にすることである。
【００１０】
本発明の更に別の態様は、クラスタ内の１個のノードにおけるプロセスが、共有リソースへのアクセスのリクエストが承認可能か否かを、クラスタ内の他のノードとの通信を必要とせずに決定できるようにすることである。
【００１１】
上述の態様は、リアルタイム・アプリケーションによりストレージエリアネットワークにアクセスする方法により実現可能であり、当該方法は、ストレージエリアネットワーク内のノードで実行されているリアルタイム・アプリケーションによるマスター・デーモンから、ストレージエリアネットワーク内のリソースへアクセスすべく帯域幅の予約を要求するステップと、マスター・デーモンにより、各リアルタイム・アプリケーションによるストレージエリアネットワーク内のリソースへのアクセスをスケジューリングするステップとを含む。スケジューリングは、経路に沿って各リクエストが必要とする利用可能な帯域幅を決定し、全ての承認されたリクエストの予約済み帯域幅の総量が利用可能帯域幅の総量よりも少ない場合にのみ、ストレージエリアネットワークのリソースの使用許可を承認することにより実行可能である。
【００１２】
利用可能な帯域幅は好適には、リクエストを発信しているストレージエリアネットワーク内のノードにおける入出力インターフェースから、ストレージエリアネットワーク内の少なくとも１個の記憶要素の各々までの経路を決定し、当該経路に存在する少なくとも１個のコンポーネントが利用可能帯域幅を決定することにより決定される。これらの決定は、ストレージエリアネットワーク内のノードにより共有可能なコンポーネントの予約済み帯域幅および利用可能帯域幅の総量のマスター・データベースと、ローカルに発信されたリクエスト用の予約済み帯域幅および帯域幅予約のリクエストを発信する各ノードで実行されるプロセスにより共有されるローカル・ノード・コンポーネントが利用可能な帯域幅の総量のローカル・データベースとを用いて行なわれる。
【００１３】
好適には、本方法はまた、マスター・デーモンによるスケジューリングの過程で決定される少なくとも１個のスケジュールを各要求元ノードへ配信するステップと、当該少なくとも１個のスケジュールに含まれる対応スケジュールに従い、各要求元ノード上の各リアルタイム・アプリケーションによるストレージエリアネットワーク内のリソースへのアクセスを制限するステップとを含む。
【００１４】
本方法はオプションとして、ストレージエリアネットワークのノードにより、どのリアルタイム・アプリケーションからも要求されていない追加分の帯域幅を予約するステップを含んでいてよい。この場合、本方法は好適には、ストレージエリアネットワーク内のノードの１個にあるローカル・デーモンにより、ストレージエリアネットワークへのアクセス用の追加分の帯域幅を、ノードの１個で実行されていて、マスター・デーモンに対し帯域幅のリクエストを発信していないアプリケーションに割り当てるステップを含む。更に、追加分の帯域幅を割り当てるステップは好適には、ローカル・デーモンがノードの１個のためにマスター・デーモンから追加分の帯域幅をリクエストする必要なしに、ローカル・デーモンにより帯域幅のリクエストが承認されたリアルタイム・アプリケーションの少なくとも一つに帯域幅を割り当てるステップを含む。オプションとして、追加分の帯域幅はまた、帯域幅予約リクエストを発信していないアプリケーションでも利用可能である。
【００１５】
これらおよび以下に明らかになるこれらおよび他の態様は、本明細書により完全に記載および特許請求する構成と動作の詳細事項に存在する。本明細書の一部をなす添付図面を参照するが、全体を通じて同一の番号は同一部材を指示する。
【発明を実施するための最良の形態】
【００１６】
本発明は、各々ＵＮＩＸ（登録商標）またはＩＲＩＸ（登録商標）を実行しているコンピュータ・システムのクラスタ、およびＣＸＦＳやボリューム・マネージャＸＶＭ（共にＳＧＩ社の製品）等のクラスタ型ファイルシステムがアクセスするＳＡＮに実装可能である。そのような動作環境の更なる詳細は、２００２年６月５日に出願されたコステロ（Ｃｏｓｔｅｌｌｏ）他による米国特許出願第１０／１６２，２５８号明細書「クラスタ型ファイルシステム（Ｃｌｕｓｔｅｒｅｄ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）」、およびクルシアニ（Ｃｒｕｃｉａｎｉ）他による「ストレージエリアネットワークの異種クライアント（Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｃｌｉｅｎｔｓ  Ｏｆ  Ａ  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）」およびムーア（Ｍｏｏｒｅ）他による「クラスタ化ファイルシステムにおけるマルチクラスの異種クライアント（Ｍｕｌｔｉ−Ｃｌａｓｓ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｃｌｉｅｎｔｓ  Ｉｎ  Ａ  Ｃｌｕｓｔｅｒｅｄ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）」（共に２００３年４月１６日出願）に記載されており、その全文を本明細書に引用するものとする。
【００１７】
このようなクラスタの例を図１に示す。図１に示す例において、ノード２２はＳＧＩ社製のＩＲＩＸ（登録商標）オペレーティングシステムを実行させる一方、ノード２４はカリフォルニア州サンタクララ（Ｓａｎｔａ  Ｃｌａｒａ，Ｃａｌｆｏｒｎｉａ）のサン・マイクロシステムズ社（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ）製のＳｏｌａｒｉｓ（商標）オペレーティングシステムを実行させ、ノード２６はワシントン州レッドモンド（Ｒｅｄｍｏｎｄ  Ｗａｓｈｉｎｇｔｏｎ）のマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）製のＷｉｎｄｏｗｓ（登録商標）ＮＴ（登録商標）を実行させている。これらのノードの各々は少なくとも１個、多くの場合数個プロセッサ、一部がディスク・キャッシュとして使われるローカルまたは一次メモリ、入力／出力（Ｉ／Ｏ）インターフェース、および１個以上のディスプレイまたはプリンタ等の入出力装置を含む従来のコンピュータ・システムである。本発明によれば、クラスタは、ディスクドライブ２８等の大容量または二次記憶装置がファイバー・チャネル・スイッチ３０およびファイバー・チャネル接続３２を介してノードの２２、２４、２６に接続されているストレージエリアネットワークを含む。ノード２２、２４、２６はまた、イーサネット（登録商標）等、ＴＣＰ／ＩＰを用いるローカル・エリア・ネットワーク（ＬＡＮ）３４を介して接続されていて、メッセージ送信およびハートビート信号を提供する。シリアルポート・マルチプレクサ３６もまた、ＬＡＮおよび各ノードのシリアルポートに接続されていて、ノードのハードウェア・リセットを可能にする。図１に示す例において、ＩＲＩＸ（登録商標）ノード２２だけがシリアルポート・マルチプレクサ３６に接続されている。
【００１８】
ファイバ・チャネル接続３２を介してディスクドライブ２８以外の他の記憶装置をファイバ・チャネル・スイッチ３０に接続することができる。図１にテープドライブ３８を示すが、他の従来の記憶装置も接続されていてよい。あるいは、ディスクドライブ２８またはテープドライブ３８（または他の記憶装置）が１個以上のノード２２、２４、２６へ、例えばＳＣＳＩ接続（図示せず）に接続されていてよい。
【００１９】
図１に示すようなクラスタの一用途として、ビデオ・クリップがディスクドライブ２８（またはテープドライブ３８）のファイルに保存されているビデオ放送スタジオがある。異種ノード２２、２４、２６上で動作している非線型ビデオエディタがビデオファイルを修正する一方で、テレビ放送用にファイルへアクセス可能である。本発明による、クラスタを認識しているリアルタイム・スケジューラにより、タイミング要求と再生サーバの帯域幅の総量が合致する。
【００２０】
ＣＸＦＳにより、全ての接続されたクライアント２２、２４、２６からＳＡＮ２８、３０、３２への直接アクセスが可能になり、各種のアクション用にトークンを発行することにより整合性を維持する。例えば、個々のファイルへのアクセス用に読込み／書出しトークンが存在し、新規ディスクのブロック・エクステントの割り当て用のトークンが存在する。ノード２２の１個は、各ファイルシステムのメタデータ・サーバとして機能し、トークンの承認および複製を制御する。メタデータ・サーバの再配置復旧もＣＸＦＳが対応している。
【００２１】
異なるクライアント間の帯域幅利用時の衝突を効率的に解決できるように、好適な実施形態において、各クライアントノード２２、２４または２６は、任意のデータへのアクセス保証を求めるリクエストに応じる、ｇｇｄと名付けられたデーモンを実行する。デーモンとは、ＵＮＩＸ（登録商標）系ＯＳにおいて、メモリに常駐して様々なサービスを提供するソフトウェアである。各帯域幅予約リクエストは好適には、少なくとも１個の記憶要素、例えば毎秒１ＭＢである必要な周期的帯域幅、スタート時刻および少なくとも１個の記憶要素へのアクセス用の予約の持続期間を含んでいる。
【００２２】
図２に示すように、ノードの１個はマスターノード４０として機能する。残りのノードをクライアントノード４２で表わす。マスターノード４０のｇｇｄ４４ｍにより実行される機能は、クライアントノード４２内のｇｇｄ４４ｃの機能と基本的に同様である。実際、ｇｇｄ４４ｍは、他のノード４２から受信するのと同様に、共有リソースに対する帯域幅リクエストを管理すべく、マスターノード４０で実行されているプロセスからリクエストを受信する。ｇｇｄ４４ｃとｇｇｄ４４ｍの両方が実行する処理を参照する場合、ｇｇｄ４４を参照する。
【００２３】
ｇｇｄ４４は各ノード４２、４４において、利用可能な総量すなわち最大の帯域幅および要求された帯域幅の総量と共にハードウェアのデータベースを管理する。更に、メモリ・コンポーネントへのハードウェア経路がデータベースに保存されているため、当該経路に存在するコンポーネントの利用可能帯域幅を決定することができる。要求された帯域幅の総量とは、帯域幅の予約を発信したプロセス用に取り置かれた帯域幅である。他のプロセスが帯域幅予約のリクエストを行なわずに共有ハードウェアを使用する場合、利用可能帯域幅の総量は特定のハードウェアの容量より少ない恐れがある。しかし、ＳＡＮ２８、３０、３２内でアクセスを行なう全てのアプリケーションおよびノードがローカル・デーモンｇｇｄ４４ｃ（および共有リソースをリクエストする場合にはｇｇｄ４４ｃからｇｇｄ４４ｍまで）にリクエストを発信することが好適である。好適には、要求された帯域幅の総量は、データベースに保存されている各リクエストからの情報に基づき決定される。開始時刻および持続期間により決定された予約時間が過ぎたならば、予約リクエストはデータベースから除去され、要求された帯域幅の総量が当該リクエストに含まれる帯域幅の分だけ減らされる。
【００２４】
帯域幅予約は、複数のプロセスにより共有されるハードウェア・コンポーネント用にネスティングされたトランザクションとして生成される。ＳＧＩ社製品等のキャッシュ・コヒーレント型マルチプロセッサ・システムにおいて、ｇｇｄ４４はノード４０または４２内の全てのプロセッサがメモリ・インターフェース４６で入出力ハードウェアに対応している共通ポイントから処理を開始する。ｇｇｄ４４は、リクエストを受信したならば、要求された記憶要素へのハードウェア経路をカーネルに問い合わせる。ｇｇｄ４４はこの情報により、当該経路を下りながら各部分がリクエストを承認するのに十分な未予約帯域幅を有するか否かを判定する。クライアントノードの場合についてこの様子を、メモリ・インターフェース４６、ＰＣＩ  Ｂｕｓ４８およびファイバー・チャネル・アダプタ５０の間の矢線により示す。クライアントノード４２内のｇｇｄ４４ｃが、自身のノードの全てのハードウェアが十分な未予約帯域幅を有すると判定した場合、ノード４０のマスター・デーモンにリクエストが発信されて、クラスタ全体にわたり共有されているハードウェアの利用可能帯域幅を調べる。
【００２５】
図２に示す実施形態において、破線で示すように、クライアントノード４２からのリクエストに応答してｇｇｄ４４ｍから未予約帯域幅の問い合わせが来ているものとして共有ディスク２８のみ示している。これは、リクエスト内の少なくとも１個のコンポーネントがストレージエリアネットワーク内のディスク記憶装置の一部を含み、ストレージエリアネットワーク内の他のコンポーネントは十分な容量を有するため、唯一のボトルネックが共有ディスクに生じる可能性がある場合である。好適には、ｇｇｄ４４ｍが管理するデータベースは、ファイバー・チャネル・アダプタ、ファイバー・チャネル・スイッチ、ディスク・コントローラ等、ボトルネックが生じる恐れのある、ＳＡＮ２８、３０、３２内の任意のハードウェアを含む。共有ディスク２８上で帯域幅予約のリクエスト対象となっている少なくとも１個のコンポーネントのすなわち記憶要素の各々が、当該リクエストで必要とされる周期的帯域幅を超える利用可能帯域幅を備えているとｇｇｄ４４ｍが判定した場合、ｇｇｄ４４ｍはｇｇｄ４４ｃに対し、リクエストを承認して、共有クラスタ・コンポーネントで管理されているデータベース内のリクエスト済み帯域幅の総量を増やすようメッセージを送信する。同様に、ｇｇｄ４４ｃは複数プロセスに共有されているノード４２内のコンポーネントについて自身のデータベースを更新する。
【００２６】
ＳＡＮ２８、３０、３２の共有リソースへのリクエストのマスター・データベースを管理しているマスター・デーモンを代替するものとして、ＳＡＮ２８、３０、３２の共有リソースの帯域幅の総量に対するパーセンテージを、マスター・デーモンにより、または各ノード４２内のローカルｇｇｄ４４ｃ間で送信されたメッセージにより、各ノード４２に割り当ててもよい。この代替方式において、各ノード４２内のローカルｇｇｄ４４ｃは、ノード４２自身に含まれる共有リソースに加えて自分に割り当てられたＳＡＮ２８、３０、３２の共有リソースに関する情報を管理する。
【００２７】
ＳＧＩ社から販売されているＧＲＩＯ製品とは異なり、ｇｇｄ４４ｃは共有リソースの超過帯域の利用を許さない。これは通常、プロセスを実行中のノード間で更に通信を必要とする。このようなアクセスを承認するために必要な時間、および必要な通信を行なうために複雑さが増すことを考えれば、概して帯域幅が未利用であるシステムにおいて、超過帯域状態を回避するのに十分多くの帯域幅予約を行なうことが好適である。あるいは、クライアントノード４２がｇｇｄ４４ｍに対し、クライアントノード４２で実行中のプロセス用に、それらのプロセスのいずれからも特段のリクエストが無くても、追加分の帯域幅予約リクエストを発信してもよい。ｇｇｄ４４ｍにより承認されたならば、帯域幅予約を一切発信していないリクエストクライアントノード４２に対して追加分の帯域幅予約をｇｇｄ４４ｃにより割り当てたり、あるいはリクエストを発信したもののｇｇｄ４４ｍにより承認された帯域幅を超える必要があるプロセスに対して追加分の帯域幅を提供することができる。
【００２８】
本発明は、ＳＧＩ社製のハードウェアおよびソフトウェアを用いる実施形態に関して述べてきた。しかし、本発明はＳＧＩ社製のハードウェアやソフトウェア、またはビデオ編集や放送用途に限定されるものではない。
【００２９】
本発明の多くの特徴および利点は詳述された明細書から明らかであり、従って本発明の真の概念および範囲に含まれる本発明のあらゆる特徴および利点が添付の請求項に包含されることを意図している。更に、当業者により各種の変更や改造が容易に想起されるため、ここに図解および記載した構造や動作自体により本発明を限定することは本意でなく、従ってあらゆる適切な変更および等価物が本発明の範囲に含まれるものとする。
【図面の簡単な説明】
【００３０】
【図１】ＳＡＮに接続しているコンピュータ・システムの一群のブロック図である。
【図２】帯域幅予約リクエストを承認すべきか否かを決定するプロセスを示すべく、２個のノード内のコンポーネントおよびＳＡＮ内の共有コンポーネントを示すブロック図である。
【図１】
2005525638.tif 000002
【図２】
2005525638.tif 000003
【国際調査報告】
2005525638.tif 000004
2005525638.tif 000005
2005525638.tif 000006