JP5577404B2 - ストレージ・クラスタにおける適応的な電力節約の方法 - Google Patents

Description

本発明は、一般的には電力節約に関する。より具体的には、本発明は、ストレージ・クラスタにおける電力節約に関する。

現在、いわゆる「環境保全」技術を推進し、地球の気象変化に対応する目的で、コンピュータによる電力消費を抑制する取り組みが進められている。このような長期目標に加えて、消費電力を抑制することは、事業主にとって即座の節約につながる。コンピュータシステムで使用される電力の削減は、コンピュータシステムの電気料金が減少することを意味するだけではなく、コンピュータシステムの冷却コストの削減にもつながる。巨大データセンターを管理する企業にとって、コンピュータ群を冷却するのに必要な電力の削減は非常に重要である。このような企業にとって、冷却容量の削減は、必要な冷却用インフラの削減とデータセンターに必要な不動産の削減につながる。

したがって、コストを削減し、冷却の必要性を削減するために、一般的には、コンピュータのストレージ・クラスタで電力を節約することが望ましい。ただし、ストレージ・クラスタ内では、クライアント・アプリケーションが常時クラスタへの書き込みやクラスタからの読み出しを行なっており、また、ストレージ・クラスタ自身も自己のデジタルオブジェクトの整合性を評価し、必要に応じてデジタルオブジェクトのコピーを作成しているため、電力節約スキームの策定は容易ではない。

このため、クライアント・アプリケーションが必要とするアクセスが可能なままで、コンピュータのストレージ・クラスタにおいて電力消費を抑制し、クラスタ内でのオブジェクト整合性を維持する方法及びシステムが求められている。

前記を達成するために、本発明の目的に従い、電力節約方法を開示する。ボリュームが使用されていない場合にディスクドライブをスピンダウンし、また、ノードが使用されていない場合にＣＰＵ使用率を低下させることにより、ストレージ・クラスタの電力を節約することが望まれている。
（１）本発明の第１の形態は、ＣＰＵと少なくとも１個のディスクドライブとを備え、自己のオペレーティングシステムを実行するよう各コンピュータノードが相互に接続された複数のコンピュータノードからなるストレージ・クラスタにおいて、前記コンピュータノードと前記ディスクドライブとをアイドル状態にする方法であって、
前記ストレージ・クラスタ内の各コンピュータノードに関して、第１の所定期間に、前記各コンピュータノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の各コンピュータノードに関して、第２の所定期間に、前記各コンピュータノードで、前記ストレージ・クラスタ内の他のコンピュータノードから書き込み要求又は読み出し要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の各コンピュータノードに関して、前記第１の所定期間及び前記第２の所定期間に、前記クライアント要求も前記書き込み要求も生じなかったことを判定した場合に、前記各コンピュータノードを独立にアイドル状態に移行させる工程と、
アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、を備える方法である。
（２）本発明の第２の形態は、複数の相互に接続されるコンピュータノードを有するストレージ・クラスタ内でコンピュータノードをアイドル状態にする方法であって、
前記コンピュータノードがアクティブ状態のときに、前記コンピュータノードにより、前記ストレージ・クラスタ外部のクライアント・アプリケーションからのクライアント要求を処理する工程と、
第１の所定期間に、前記コンピュータノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
第２の所定期間に、前記コンピュータノードで、前記ストレージ・クラスタ内の他のコンピュータノードからの読み出し要求又は書き込み要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の前記他のコンピュータノードとは独立に、前記コンピュータノードをアイドル状態に移行させる工程と、
前記アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、
を備える方法である。

本発明は、十分に利用されていないクラスタが、ディスクのスピンダウンを開始し、ノードのＣＰＵ使用率を低下させることが可能な機構を提供する。電力を節約するために利用可能なスループットを意図的に低下させるが目的なのではなく、スループット要求が低いことを認識して、電力を節約する措置を講じることが目的である。夜間や週末にドーマント（休眠）状態になるクラスタや、書き込み／読み出し／削除動作にまれにしか利用されていないクラスタでは、ドーマント（休眠）期間に使用電力をかなり、たとえば、８０〜９０％も、抑制することができる。クラスタへの以降のアクセスにより、自動的に１つ又は複数のノードが休止状態から復帰して要求を実行し、最終的には、クラスタ全体が復帰する。スリープ状態のノードに対する最初のアクセス時に、追加の待ち時間が生じるが、最大利用可能なスループットは影響を受けない。

このアプローチの利点としては、本発明がクライアント・アプリケーションにより大きく変わる使用パターンに適応できること、各ノード及びボリュームが、いつスリープ状態に入りいつ復帰するかに関する決定を分散的に自分で下すことができること、及び、クラスタ全体を完全にドーマント（休眠）状態にすることが可能であること、が挙げられる。本発明では、電力節約を実施するために管理者が複雑なサブクラスタ構成を設計する必要がなく、管理費は基本的にゼロである。

本発明の第１の実施形態は、ストレージ・クラスタの各コンピュータノード及びそのハードディスクを独立にアイドル状態にすることができ、これによって電力を節約する。第２の実施形態は、ストレージ・クラスタ全体をアイドル状態で保持し、休止状態から復帰させることなく、ストレージ・クラスタ内の関係ノードに対する読み出し又は書き込みアクセスを可能にする。第３の実施形態は、アーカイブ・アプリケーションに対して、アーカイブ・モードを用いて、特定のノードが必要になるまでアイドル状態で空のまま保持する。第４の実施形態は、クラスタがアイドル状態になってから所定時間後にクラスタ全体のヘルス処理を実行可能にする。第５の実施形態は、ソリッドステート・ドライブ（ＳＳＤ）を用いて、スピンアップ遅延によるアイドル・クラスタの初期待ち時間をなくす。

本発明は、以下の適用例としても実現可能である。
［適用例１］
ＣＰＵと少なくとも０個のディスクドライブとを備え、自己のオペレーティングシステムを実行するよ各コンピュータノードが相互に接続された複数のコンピュータノードからなるストレージ・クラスタにおいて、前記コンピュータノードと前記ディスクドライブとをアイドル状態にする方法であって、
前記ストレージ・クラスタ内の各コンピュータノードに関して、第１の所定期間に、前記各ノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の各コンピュータノードに関して、第２の所定期間に、前記各ノードで、前記ストレージ・クラスタ内の他のノードから書き込み要求又は読み出し要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の各コンピュータノードに関して、前記第１の所定期間及び前記第２の所定期間に、前記クライアント要求も前記書き込み要求も生じなかったことを判定した場合に、前記各コンピュータノードを独立にアイドル状態に移行させる工程と、
アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、を備える方法。
［適用例２］
適用例１に記載の方法であって、
前記第１の所定期間、前記第２の所定期間、及び前記第３の所定期間が同じ値である、方法。
［適用例３］
適用例１に記載の方法であって、さらに、
アイドル状態に移行させた各ディスクボリュームの回転を停止させる工程を備える、方法。
［適用例４］
適用例１に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例５］
適用例１に記載の方法であって、さらに、
各コンピュータノードのディスクボリューム上で実行されるすべてのファイル整合性チェックを停止することにより、前記各コンピュータノードをアイドル状態にする工程と、
前記各コンピュータノードの前記オペレーティング・システムにより、前記各コンピュータノードの前記ＣＰＵのクロックレートを低下させる工程と、
を備える方法。
［適用例６］
適用例１に記載の方法であって、さらに、
アイドル状態のコンピュータノードの各ディスクボリュームのスピンダウンを指示することにより、前記ディスクボリュームをアイドル状態にする工程を備える、方法。
［適用例７］
適用例１に記載の方法であって、さらに、
各コンピュータノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させるようにビッド値を計算することにより、前記コンピュータノードをアイドル状態にする工程を備える、方法。
［適用例８］
複数の相互に接続されるコンピュータノードを有するストレージ・クラスタ内でコンピュータノードをアイドル状態にする方法であって、
前記コンピュータノードがアクティブ状態のときに、前記コンピュータノードにより、前記ストレージ・クラスタ外部のクライアント・アプリケーションからのクライアント要求を処理する工程と、
第１の所定期間に、前記コンピュータノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
第２の所定期間に、前記コンピュータノードで、前記ストレージ・クラスタ内の他のコンピュータノードからの読み出し要求又は書き込み要求が生じなかったことを判定する工程と、
前記ストレージ・クラスタ内の前記他のコンピュータノードとは独立に、前記コンピュータノードをアイドル状態に移行させる工程と、
前記アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、
を備える方法。
［適用例９］
適用例８に記載の方法であって、さらに、
前記第１の所定期間に、前記他のコンピュータノードの各々で、外部クライアント・アプリケーションからのクライアント要求が生じなかったことが判定され、かつ、前記第２の所定期間に、前記他のコンピュータノードの各々で、前記ストレージ・クラスタ内の他のコンピュータノードから読み出し要求又は書き込み要求が生じなかったことを判定した場合に、前記ストレージ・クラスタ内の前記他のコンピュータノードの各々に対して、前記移行工程を実施する工程を備える、方法。
［適用例１０］
複数のコンピュータノードを有するストレージ・クラスタからコンピュータファイルを読み出す方法であって、
前記ストレージ・クラスタの前記コンピュータノードの各々がアイドル状態のときに、前記ストレージ・クラスタの第１のコンピュータノードで、前記ストレージ・クラスタから前記コンピュータファイルを検索する要求を外部クライアント・アプリケーションから受信する工程と、
前記第１のコンピュータノードから前記ストレージ・クラスタ内の前記コンピュータノードに、前記コンピュータファイルを読み出すためのビッドを要求するマルチキャスト・メッセージを送信する工程と、
前記マルチキャスト・メッセージに対する応答に基づいて、前記複数のコンピュータノードのうちの１つを選択する工程と、
前記選択されたコンピュータノードと前記コンピュータファイルを含む前記選択されたコンピュータノードのディスクボリュームとをアクティブ状態に移行させる工程と、
前記ストレージ・クラスタ内の選択されていないコンピュータノードをアイドル状態に維持する工程と、
前記選択されたコンピュータノードの前記ディスクボリュームから前記外部クライアント・アプリケーションに前記コンピュータファイルを返送する工程と、を備える方法。
［適用例１１］
適用例１０に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例１２］
適用例１０に記載の方法であって、
前記アイドル状態の各コンピュータノードでは、ＣＰＵのクロックレートが低下している、方法。
［適用例１３］
適用例１０に記載の方法であって、
前記アイドル状態のコンピュータノードの各ディスクボリュームは、スピンダウン中である、方法。
［適用例１４］
複数のコンピュータノードを有するストレージ・クラスタにコンピュータファイルを書き込む方法であって、
前記ストレージ・クラスタの前記コンピュータノードの各々がアイドル状態のときに、前記ストレージ・クラスタの第１のコンピュータノードで、前記コンピュータファイルを前記ストレージ・クラスタに書き込む要求を外部クライアント・アプリケーションから受信する工程と、
前記第１のコンピュータノードから前記ストレージ・クラスタ内の前記コンピュータノードに、前記コンピュータファイルを書き込むためのビッドを要求するマルチキャスト・メッセージを送信する工程と、
前記マルチキャスト・メッセージに対する応答に基づいて、前記複数のコンピュータノードのうちの１つを選択する工程と、
前記選択されたコンピュータノードと前記選択されたコンピュータノードのディスクボリュームとをアクティブ状態に移行させる工程と、
前記ストレージ・クラスタ内の選択されていないコンピュータノードをアイドル状態に維持する工程と、
前記外部クライアント・アプリケーションから前記選択されたコンピュータノードの前記ディスクボリュームに前記コンピュータファイルを書き込む工程と、を備える方法。
［適用例１５］
適用例１４に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例１６］
適用例１４に記載の方法であって、
前記アイドル状態の各コンピュータノードでは、ＣＰＵのクロックレートが低下している、方法。
［適用例１７］
適用例１４に記載の方法であって、
前記アイドル状態のコンピュータノードの各ディスクボリュームは、スピンダウン中である、方法。
［適用例１８］
複数のコンピュータノードを有するストレージ・クラスタにコンピュータファイルを書き込む方法であって、
前記ストレージ・クラスタの第１のコンピュータノードで、前記コンピュータファイルを前記ストレージ・クラスタに書き込む要求を外部アーカイブ・アプリケーションから受信する工程と、
前記第１のコンピュータノードから前記ストレージ・クラスタ内の前記コンピュータノードに、前記コンピュータファイルを書き込むためのビッドを要求するマルチキャスト・メッセージを送信する工程と、
前記コンピュータノードの各々が、前記コンピュータファイルを書き込む機会に関するビッド値を計算する工程であって、より大きな容量を有するコンピュータノードからのビッド値が、より小さな容量を有するコンピュータノードからのビッド値よりも大きい、工程と、
前記複数のコンピュータノードから最小ビッド値を有するコンピュータノードを選択する工程と、
前記外部クライアント・アプリケーションから前記選択されたコンピュータノードのディスクボリュームに前記コンピュータファイルを書き込む工程と、を備える方法。
［適用例１９］
適用例１８に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例２０］
適用例１８に記載の方法であって、さらに、
前記選択されたコンピュータノードのうちで最小容量を有するディスクボリュームに、前記コンピュータファイルを書き込む工程を備える、方法。
［適用例２１］
適用例１８に記載の方法であって、
前記ストレージ・クラスタの前記コンピュータノードの各々がアーカイブモードであり、前記コンピュータノードの各々がアーカイブモードでない場合には、より大きな容量を有するコンピュータノードからの計算ビッド値が、より小さな容量を有するコンピュータノードからの計算ビッド値よりも小さい、方法。
［適用例２２］
複数のコンピュータノードを有するストレージ・クラスタにコンピュータファイルを格納する方法であって、
前記ストレージ・クラスタ内の第１のコンピュータノードから、外部アーカイブ・アプリケーション由来の前記コンピュータファイルを書き込むためのビッドを要求するマルチキャスト・メッセージを受信する工程と、
前記ストレージ・クラスタ内の第２のコンピュータノードがアーカイブモードにあるか否かを判定する工程と、
前記第２のコンピュータノードがアーカイブモードにあると判定された場合に、前記コンピュータファイルを書き込む機会に関するビッド値を計算する工程であって、前記コンピュータノードの容量が大きいほど前記ビッド値が大きくなる、工程と、
前記計算したビッド値に基づいて、前記コンピュータノード間でのビッド競争に勝つ工程と、
前記外部クライアント・アプリケーションから前記第２のコンピュータノードのディスクボリュームに前記コンピュータファイルを書き込む工程と、を備える方法。
［適用例２３］
適用例２２に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例２４］
適用例２２に記載の方法であって、さらに、
最小容量を有する選択されたコンピュータノードのディスクボリュームに前記コンピュータファイルを書き込む工程を備える、方法。
［適用例２５］
適用例２２に記載の方法であって、さらに、
前記第２のコンピュータノードのディスクボリュームをほぼ容量いっぱいまで満杯にする工程と、
所定の期間が経過する間、前記外部アーカイブ・アプリケーションからの要求が処理されていないと判定された場合に、前記第２のコンピュータノードをアイドル状態にする工程と、を備える方法。
［適用例２６］
複数のコンピュータノードを有するストレージ・クラスタにおいて外部要求を処理する方法であって、
前記ストレージ・クラスタのアイドル・コンピュータノードで、外部クライアント・アプリケーション由来の前記外部要求を処理するビッドを要求するマルチキャスト・メッセージを受信する工程と、
前記外部要求を処理する機会に関するビッド値を計算する工程と、
前記ストレージ・クラスタ内の前記アイドル・コンピュータノードがアイドル状態であるか否かを判定する工程であって、前記アイドル・コンピュータノードがアイドル状態であると判定された場合に、前記ビッド値にプレミアム値を加算して、最終ビッド値を求める工程と、
前記最終ビッド値を提示する工程と、
前記最終ビッド値は他のビッド値よりも大きいため、前記最終ビッド値が前記外部要求を処理することを認めない、という通知を受け取る工程と、
前記アイドル・コンピュータノードにより前記外部要求を処理しない工程と、を備える方法。
［適用例２７］
適用例２６に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
［適用例２８］
適用例２６に記載の方法であって、さらに、
前記提示された最終ビッド値に対する応答を受信しないことに基づいて、通知を受け取る工程を備える、方法。
［適用例２９］
適用例２６に記載の方法であって、さらに、
前記アイドル・コンピュータノードをアイドル状態に維持する工程であって、前記アイドル状態は、前記アイドル・コンピュータノードのＣＰＵのクロックレートの低下を特徴とする、工程を備える方法。
［適用例３０］
適用例１に記載の方法であって、さらに、
前記ノードのうちハードディスクドライブを備える第１のノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させるように、前記ノードのうちの前記第１のノードに関するビッド値を計算する工程と、
前記ノードのうちソリッドステート・ドライブを備える第２のノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を増大させるように、前記ノードのうちの前記第２のノードに関するビッド値を計算する工程と、を備える方法。
［適用例３１］
適用例８に記載の方法であって、さらに、
ディスクドライブを備える各ディスク・ボリュームに対して、書き込み又は読み出しビッド値を調整して、前記ディスクドライブを備えるボリュームが、外部書き込み又は読み出しのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させる工程と、
ソリッドステート・ドライブを備える各ディスク・ボリュームに対して、書き込み又は読み出しビッド値を調整して、前記ソリッドステート・ドライブを備えるボリュームが、外部書き込み又は読み出しのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を増大させる工程と、を備える方法。
［適用例３２］
複数のコンピュータノードを備えるアイドル状態のストレージ・クラスタにコンピュータファイルを書き込む方法であって、
前記ストレージ・クラスタは、少なくとも１つのソリッドステート・ドライブと少なくとも１つのハードディスクドライブとを含む複数のドライブを備え、
前記方法が、
前記アイドル状態のストレージ・クラスタの前記複数のドライブのすべてがアイドル状態にあるときに、前記ストレージ・クラスタの第１のコンピュータノードにおいて、外部アプリケーションから前記ストレージ・クラスタに前記コンピュータファイルを書き込む要求を受信する工程と、
前記第１のコンピュータノードから前記ストレージ・クラスタ内の前記コンピュータノードに、前記コンピュータファイルを書き込むためのビッドを要求するマルチキャスト・メッセージを送信する工程と、
前記コンピュータノードの各々が、前記コンピュータファイルを書き込む機会に関するビッド値を計算する工程であって、前記少なくとも１つのソリッドステート・ドライブを備える第１のコンピュータノードからの第１のビッド値が前記少なくとも１つのハードディスクドライブを備える任意の他のコンピュータノードからの第２のビッド値よりも小さい、工程と、
最小ビッド値を持つ前記第１のコンピュータノードを選択する工程と、
前記外部クライアント・アプリケーションから前記選択された第１のコンピュータノードの前記少なくとも１つのソリッドステート・ドライブに前記コンピュータファイルを書き込む工程と、を備える方法。
［適用例３３］
適用例３２に記載の方法であって、
前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
添付の図面と共に、以下の説明を参照することにより、本発明及びその効果を最もよく理解することができるであろう。

本発明の動作環境を示す図。 通常動作時に、クライアント・アプリケーションがストレージ・クラスタにファイルを書き込む工程を説明するフロー図。 アクティブ状態からアイドル状態へのノードの移行工程を説明するフロー図。 アイドル・クラスタが読み出し要求を処理する工程を説明するフロー図。 アイドル・クラスタが書き込み要求を処理する工程を説明するフロー図。 本発明の実施例を実施するのに適したコンピュータシステムを示す図。 本発明の実施例を実施するのに適したコンピュータシステムを示す図。

任意の適当なコンピュータハードウェア及びソフトウェアを用いて、本発明を実施可能である。ストレージ・クラスタは、任意の数のコンピュータノードを含むものでよい。各ノードが、ＣＰＵ（又は複数のＣＰＵ）と、オペレーティング・システムと、他のノードに接続される（又は少なくとも中央ルータに接続される）通信リンクと、任意の数（すなわち、ゼロからＮ個）の内部ハードディスクドライブ又はソリッドステート・ドライブと、を備えることが望ましい。通常、各ノードは、少なくとも１つのドライブを備え、ソリッドステート・ドライブとハードディスクドライブとを任意に組み合わせたものでもよい。クラスタは、一般的に、バックアップや長期間の保存、アーカイブ保管等に用いられ、コンピュータファイルへの日常的なアクセスには通常用いられない固定コンテンツストレージ・クラスタである。これは、ＷＯＲＭ（ライトワンス・リードメニー）記憶装置とも称され、いったんクラスタに書き込まれたコンピュータファイルやデジタルオブジェクトは変更できない。（当然のことながら、コンピュータファイルの修正版もクラスタ内に格納可能である。）クラスタは、独立ノードの冗長アレイ（redundant array of independent node：ＲＡＩＮ）として実現されるものでもよく、この場合、各ノードは、自己のオペレーティング・システムを実行し、クラスタ内の記憶に関して独立に決定を下す。ストレージ・クラスタは、ブレード、タワー、パーソナルコンピュータ及びサーバ上に構築可能である。あるいは、単一のコンピュータボックス内部のマルチコア・プロセッサが、各コア上で実行される仮想記憶ノードをサポートするものでもよい。すなわち、単一のコンピュータボックス内に、複数のノードを有するストレージ・クラスタが配置されるものでもよい。さらに、単一の物理ボックス（フィジカルボックス）内部のコンピュータシステムが、複数のＣＰＵを備え、各ＣＰＵがノードとなって、単一の物理ボックス内部にストレージ・クラスタを実現するものでもよい。

図１に、本発明の動作環境１０を示す。ストレージ・クラスタ２０と、クライアント・アプリケーション３０と、管理コンソール４０と、任意の数のコンピュータノード５１〜５４と、中央ルータ７０と、を備える。前述したように、コンピュータノードは物理ファイルサーバであり、少なくとも１つのＣＰＵと、任意の数のディスクドライブ、ソリッドステート・ドライブ又は両方の種類が混在するハイブリッドドライブと、を備えることが望ましい。各ノードは、Debian Linux（デビアン・リナックス）等のオペレーティング・システムを実行し、また、処理を実行することによって、ノード間のピアツーピア通信を管理し、ヘルス処理を実施し、ノードとそのボリュームに対して独立に決定を下す。各ノードは、さらに、管理ソフトウェアを備え、インターネットを通じてウェブブラウザによりその状態を監視することができる。

ある特定のＲＡＩＮ実施形態において、各ノードは、１テラバイト以上のシリアルＡＴＡディスク記憶容量を有し、標準的なイーサネット（登録商標）ネットワーク構築を行なう１Ｕサーバ（たとえば、ｘ８６コンピュータ）である。各ノードは、ＩＰアドレスを有し、ＩＰベースのＬＡＮ、ＭＡＮ又はＷＡＮを用いて物理的に相互に接続される。したがって、各ノードは、１つのノードと通信を行なうことも可能であるし、ルータ７０又はその他の同様なネットワークスイッチを用いて、ストレージ・クラスタ内のすべてのノードに対してメッセージをブロードキャストすることも可能である（マルチキャスト）。

各ノードは、クライアント・アプリケーションからの外部要求（たとえば、SCSP要求）、ノード間の複製要求（たとえば、interSCSP要求）及びその他のインターノードプロトコル通信（ビッディング、情報要求等）を処理する管理モジュールを備える。（後述する）ヘルス処理モジュールは、各ノードのデジタルコンテントを管理する。管理コンソール４０は、望ましくは、ストレージ・クラスタに接続されるウェブ・サーバであり、任意の適当なインターネット接続を介して各ノードにアクセス可能である。各ノードは、クラスタ全体の監視及び管理に利用可能な冗長管理コンソールを実装する。

一実施形態において、ストレージ・クラスタは、テキサス州オースチンのCaringo社から市販されているCAStorコンテンツストレージ・ソフトウェアと、任意の適当なコンピュータ・ハードウェアと、を用いて実現される。この実施形態において、ストレージ・クラスタは、固定コンテンツを記憶させるものであり、各デジタルオブジェクトは、真性乱数発生器を用いてそのデジタルオブジェクトのために発生させた乱数により、一意的にクラスタ内でアドレスが指定されている（汎用一意識別子（universally unique identifier）又はＵＵＩＤ）。各デジタルオブジェクトのコンテンツは、ハッシュ関数を用いて検証される。クライアント・ソフトウェア・アプリケーションは、クラスタ内にデジタルオブジェクトを格納する際にＵＵＩＤを受け取り、ＵＵＩＤをクラスタに出力することによりそのデジタルオブジェクトの検索を行なう。ソフトウェア・アプリケーションは、HTTP1.1規格を用いて、より具体的には、その規格のＳＣＳＰ（Simple Content Storage Protocol）と称される簡易サブセットを用いて、CAStorクラスタと通信を行なう。この標準インターフェースを用いて、電子メール、企業コンテンツ管理、ヘルスケアアプリケーション、ウェブブラウザ、Web2.0サイト、写真共有、ソーシャル・メディアサイト、セキュリティビデオ、ビデオ編集等のクライアント・アプリケーションがCAStorストレージ・クラスタにアクセス可能である。さらに、ブラウザ、ＪＡＶＡ（登録商標）、Ｐｙｔｈｏｎ、Ｃ＋＋及びその他のソフトウェア環境で直接ＨＴＰＰアクセスが可能である。

概要
本発明は、設定可能期間にわたって実際に処理を行なった外部クライアント・アプリケーションからの要求の頻度及びノード間の複製要求の頻度に基づいて、クラスタ内の各ノード及びボリュームが、電力消費を抑制するか否かを独立に決定することを可能にする。sleepAfterとwakeAfterと称する２つのノード設定パラメータを用いるが、たとえば、これらのパラメータは、整数の秒数で表わされる（クラスタ内のすべてのノードが同じ値でなくてもよい）。

直近のsleepAfter秒の期間、あるノードがクライアント・アプリケーションからの要求（読み出し又は書き込み）を処理しておらず、また、他のノードからの同様の要求も処理しなかった場合、そのノードは休止を開始する。（たとえば、夜間や週末に予想されるように）読み出しや書き込みに対する外部要求が存在しない状態が継続すると、そのノード及びそのノードのすべてのボリュームは、完全にドーマント（休眠）状態になる。クライアント・アプリケーションが再び要求を送信し始めると、クラスタ内のノードの１つ又は複数のノードが休止状態から復帰して、その要求を処理する。長期間にわたって外部動作が検出されなくても、各ノードは、wakeAfter秒の期間アイドル状態にあった後、アイドル状態から復帰する。これにより、定期的にヘルス処理及びハウスキーピング処理（クラスタ内にデジタルオブジェクトの少なくとも最小数の特定コピーが存在することを保証する処理）を実施することができる。

ビッディング（入札）処理により、各ノードは、そのノードがデジタルオブジェクトを書き込む、デジタルオブジェクトを読み出す、又は、デジタルオブジェクトを複製する（そのノード上にコピーを保持する）際にかかるコストを示すビッド値を計算する。一般に、ノードは、すべての利用可能なノードからのビッド（入札）を要求するプライマリ・アクセスノードにビッド値を提示することにより、書き込み、読み出し及び複製要求に対するビッドを行なう。ビッドは数値で表わされ、ビッド値が小さいほど、そのノードが要求を処理するビッドに勝つ可能性が高くなる。書き込みは、クライアント・アプリケーションからデジタルオブジェクトを取得し、クラスタのノード内のディスク上に取得したデジタルオブジェクトを格納する工程である。読み出しは、クライアント・アプリケーションからデジタルオブジェクトに関する一意識別子を受け取り、そのデジタルオブジェクトをクラスタ内のディスク上で検索し、検索したオブジェクトをクライアント・アプリケーションに返送する工程である。複製要求は、クラスタ内のノード上にデジタルオブジェクトのコピーを格納するのにかかるコストを決定する（replication factorが２であると仮定した場合、クラスタ内で２つのコピーが必要となる）。複製要求後のビッドの結果に、オブジェクトのコピーをさらに複製して格納する処理が含まれるものでもよい。クラスタにおける電力を節約するために、ノードがアイドル状態であるか否か、ノードの容量、ノードが直近数分間にどの程度ビジーであったか、いずれの種類のディスクドライブが利用可能か、及びそれらの現在の状態を考慮して、ビッディングを行なう。

最小ビッド値を持つノードが書き込み、読み出し又は複製のビッドに勝つ。複製ビッド値は、デジタルオブジェクトのコピーを現在の位置に保持するのにかかるコストを示す。ヘルス処理では、この複製ビッド値を用いて、コピーを別のノードに移動するべきか否かを判定する。基本的に、ヘルス処理では、各ノードに、「このデジタルオブジェクトのコピーを保有しているか」及び「その位置でコピーを保持するのにかかるコストはどのくらいか」を問い合わせる。各ノードは、問い合わせに応じて、複製ビッド値を計算して、ヘルス処理モジュールに計算した複製ビッド値を提示する。

アイドル・ノードは、自己のヘルス処理を中断し、また、（後述するように）自己のビッディング（入札）を変更して、ストリームの読み出し、書き込み、又は複製を実行する可能性が他のノードに勝ることがないようにすることにより、電力消費を抑制する。アイドル・ノードのオペレーティング・システムは、使用率の低下を認識し、ＣＰＵのクロックレート、さらには、電力消費を徐々に低下させる。プロセッサを高速のクロックレートで動かせば、高い性能が得られる。一方、同じプロセッサをより低い周波数（速度）で動かすと、発生される熱は小さく、電力消費も小さくなる。多くの場合、コア電圧も抑制することができ、これが、さらに、消費電力と熱発生の抑制につながる。これにより、ストレージ・サーバのバッテリー残量を節約し、プロセッサの寿命を延ばし、変速ファンにより発生するノイズを減少させることができる。多くのIntelチップ群では、SpeedStep（登録商標）手法を採用し、プロセッサの稼働率の低下にあわせて、ＣＰＵのクロックレートを自動的に低下させている。PowerNow!（登録商標）と称されるＡＭＤ社による同様の手法でも、同社のチップ群に対して同様の目的を達成している。

アイドル・ボリュームは、主に、ディスクＩ／Ｏを削除し、ディスクをスピンダウンすることにより、消費電力を抑制する。ノードがアイドル状態になっても、そのボリュームの一部又は全部はアクティブなままで、そのノードの未処理分のタスクに従事している場合がある。あるボリュームが直近のsleepAfter秒内に何のＩ／Ｏ動作も実施しなかった場合に限り、そのボリュームはアイドル状態に移行して、自己のディスクをスピンダウンさせる。

詳細な設計
以下の４つのクラスタ全体にわたる設定パラメータを用いる。sleepAfterは、アクティブ・ノード又はボリュームがアイドル状態になるまでの非活動時間の秒数である（デフォルトは２時間）。wakeAfterは、アイドル・ノードが再びアクティブ状態になるまでの非活動時間の秒数である（デフォルトは８時間）。idleCostは、アイドル・ノードの場合に読み出しビッド値及び書き込みビッド値に加算されるビッドプレミアムである（デフォルトは１０）。replication factor（複製係数）は、ストレージ・クラスタ内で維持されるべき各デジタルオブジェクトのコピーの数である（デフォルトは２。ただし、各オブジェクトがこのパラメータに勝るメタデータを含有するものでもよい）。これらのパラメータは、ブートタイムに各ノードに送信されるクラスタ設定ファイルに格納される。

アーカイブを実行するアプリケーションでは、各ノードをarchive mode（アーカイブモード）設定にする。この設定（通常はバイナリ値）では、ノード上のすべてのボリュームに関して、１００から読み出しビッド値を引くことにより、通常の書き込みビッド値を逆転させて、新しい書き込みビッド値を取得する。この設定を採用する場合には、１つのノードを可能な限り長くスリープ状態のままにしておくことができるように、そのノードの書き込み要求に対するビッドを変更する。実際のアーカイブ・アプリケーションは、非常に大きなクラスタの総計スループット容量と比較したら、書き込み及び読み出しのスループットに対して特に高い要求を持つわけではない。書き込みビッド及び複製ビッドを計算する通常のビッディング・アルゴリズムでは、スループットを最大にするように、クラスタ内のすべてのノードの負荷バランスを均一にするように試みるが、このようにバランスを取ることにより、ノードがスリープ状態になるのを妨げるという副次的な悪影響が生じる。クラスタ管理者が、一部又はすべてのノードをアーカイブモードに指定することを選択する可能性もある。一般に、スループット要求のピークに対処するのに十分な大きさのノードコア群はアーカイブモードには設定されない。単に容量を増大させるために追加された新しいノードをアーカイブノードに指定して、必要となるまでスリープ状態にしておくことができる。

このようなアプリケーションにおいて、archive mode（アーカイブモード）設定では、書き込み要求に対するノード上のすべてのボリュームの通常のビッディング（入札）パターンが基本的に逆転する。空又はほぼ空のボリュームでは、ストリームの書き込みを実行する可能性が減る一方で、容量いっぱいにより近いボリュームでは、容量いっぱいになるまで、どんどんデータを格納するように努める。１つのノードにおいては、他のもっと空に近いボリュームをアクティブにするように求める前に、容量いっぱいに近いボリュームを満杯にしようと試みる。この結果、新しい、比較的空に近いノードは、どの書き込みビッドにも負けて、クライアント・アプリケーションの書き込み要求を実施することなく、スリープ状態を続けることが、アーカイブ・アプリケーションでは望ましい。本明細書に記載する電力節約機構を前提に、このようなアーカイブの逆転ビッディングを考えると、クラスタに追加された新しいノード又はボリュームを、その容量が実際に必要になるまで、低電力モードでアイドル状態のままにしておくことができる。古いノード及びボリュームを、ほぼ満杯になるまで使い続け、ほぼ満杯になった時点で、これらのノード及びボリュームを休止させる。

電力を節約するために、各ノードはアイドル状態に移行可能である。クライアント・アプリケーションからの読み出し又は書き込み要求や他のノードからの同様の要求が直近のsleepAfter秒の期間にわたって無かったことをノードが検出すると、ノードはアイドル状態に入り、ノードのＣＰＵ使用率を低下させ、また、ノードのビッディング手法を変更して、電力を節約する。前者は、単に、アイドル状態の間、ノードのヘルス処理モジュールを休止させることにより実施される。ＣＰＵ使用率を低下させることにより、ＣＰＵ及びＲＡＭのクロックレートを自動的に徐々に減少させて、使用電力を減らし、熱の発生を減らし、さらに、冷却ファンの運転速度を落として電力使用を減らすことが可能になるため、オペレーティング・システムとＣＰＵ自体の電力節約が可能になる。

前述したように、各ノードは、他のノードとビッドで競争する。後述するようにビッディングを変化させることは、アイドル・ノードが、アイドル・ノードからのファイルの移動を必要とする読み出し、書き込み、消去及び複製（すなわち、ディスクへのアクセスを必要とする動作）に関する将来のビッドに勝つ可能性を低下させることを目的としている。クラスタ内の他のノードが休止状態から復帰していれば、これらのノードが要求を処理する可能性が高いため、アイドル・ノードをスリープ状態のままにしておける。ただし、アイドル・ノードは、ノード間プロトコルメッセージに応答し、また、既にキューに入っている複製要求や自分自身のヘルス・プロセッサからのオブジェクトを読み出して整合性を検査する要求等の未処理分の作業を継続可能であることに留意されたい。

アイドル・ノードは、ヘルス処理が中断されており、ビッディングが「レイジー（lazy）」であるという意味でアイドル状態である。アイドル・ノードは、要求に応じて、プライマリ・アクセスノード（ＰＡＮ）としての動作を継続し、他のノードからのノード間プロトコル・クエリーへの応答を継続する。アイドル・ノードは、これらのクエリーすべてに対して、（ディスクにアクセスするのではなく）メモリ内構造のみを用いて、応答する。ＰＡＮとして外部要求を処理しても、ビッドに実際に勝たない限り、スリープ状態のノードが休止状態から復帰するわけではない（アクティブ状態に移行するわけではない）。ノードがアイドル状態の間は、書き込み、読み出し（消去を含む）及び複製要求に通常のノード間ビッディングは、以下のように変更される。writeBidで通常通りに計算を行ない、idleCostを加算する。readBidで通常通りに計算を行ない、idleCostを加算する。RepBidで通常通りに計算を行ない、idleCostを減算する。すなわち、既存の複製をアイドル・ノードから移すよりもアイドル・ノード上に保持する方がコストが少なくてすむ。

要するに、アイドル・ノードに対する読み書きはコストがかかるが、既存の複製をアイドル・ノードに保持するのにはコストがかからない。ここで留意するべきは、ヘルス処理は、writeBidを用いて、複製をアイドル・ノードに移すべきか否かを判定し、また、repBidを用いてアイドル・ノードから複製を移すべきか否かを判定するということである。（読み出し及び書き込みに対するビッドを単純に行なわないのではなく）ビッドを変更する理由は、一部のノードがスリープ状態の一方で、他のノードが休止状態から復帰していて、要求を処理することにより生じる渋滞（ネック）を避けるためである。このような状態がしばらく続くと、アイドル状態に対するプレミアム係数を加えても、活動中のノードから返信されてきたビッドがスリープ状態のノードから返信されてきたビッドよりも大きくなってしまう場合がある。

アイドル・ノードでも、ノード間プロトコル通信は継続され、そのボリュームはビジー状態の場合もある。外部クライアント・アプリケーションからの要求や内部の複製動作及びヘルス処理の反復がない場合には、アイドル・ノードは、他のノードからの所定の要求の処理を継続する。他のノードの一部がアクティブなままであれば、応答のためにディスク・ボリュームへのアクセスを要求するいくつかのノード間メッセージが出力される。このようなメッセージには以下のものが含まれる：
・余分な複製が存在する場合に他のノードにより送信されるtrimRequest
・動的消去に応じて他のノードがストリームを消去した後に送信されるdeleteQuery
・アンカーストリームのバージョン番号に関する問い合わせを行なうために他のノードにより送信されるversionQuery
・ステイル（stale）可変オブジェクトが存在することを判定した場合に他のノードにより送信されるversionNotice。
これらのノード間要求に対する処理が必要となるため、一般的には、アイドル・ノードは、自己のすべてのボリュームを直ちにスピンダウンさせることはできない。そのうち、クラスタ内の大部分又はすべての他のノードもアイドル状態になり、ノード間の動作も減少して最終的には終了する。このようになれば、アイドル・ノードのボリューム自体もアイドル状態にすることができる。

ノードの各ボリュームもアイドル状態になり得る。個々のボリュームは、独立に、ディスクをいつスピンダウンさせるべきかを判定する。この場合、ノードが全体として用いたものと同じ基準やパラメータを用いて判定を行なうことができる。sleepAfter秒の期間にわたって順序キュー上で何のディスク動作も実行されなかったことをあるボリュームが認識すると、そのボリュームはアイドル状態に移行して、ディスクをスピンダウンさせる。ノードの場合とは異なり、ボリュームの場合には、wakeAfter秒毎に休止状態から復帰させる必要はない。これは、ノード自体が休止状態から復帰し、そのボリュームに対して反復処理を開始し、自動的にディスクを再スピンアップさせるからである。ソリッドステート・ドライブは、物理的にはスピンダウンもスピンアップもしないが、アイドル状態への移行又はアイドル状態からの移行の一部として、「スピンダウン」コマンド及び「スピンアップ」コマンドを受け取り処理することが可能である（たとえば、ドライブが、単にコマンドを認識するものでもよい）。

ノードのうちの１つと接続される管理コンソールは、クラスターの状態を表示する。管理コンソールは、また、アイドル・ノードとアイドル・ボリュームの状態を表示する。他のノードの状態が基本的に、そのボリュームの状態の組み合わせから得られるのに対して、アイドル状態では、ノードとボリュームとは独立である。すなわち、あるノードがアイドルである一方で、そのすべてのボリュームがアクティブであるということもあり得る。また、短期間の間であれば、アクティブ・ノードのボリュームがアイドル状態ということもあり得る。アイドル状態を示すのに加えて、管理コンソールは、ランタイムにおけるクラスタ・ステータスページ上の設定ウィンドウからのsleepAfter及びwakeAfterパラメータに関するクラスター全体に及ぶ設定変更をサポートする。ストレージ・クラスタが完全にアイドル状態になると、最初の読み出し又は書き込み要求を処理するまでに異常に長い待ち時間が生じるが、その間に、１つ又は複数のボリュームが休止状態から復帰し、ハードディスクをスピンアップさせる。以降の処理では、上述したように、現在回転中のボリュームに復帰するため、追加の待ち時間は最初の要求でのみ生じる。

ソリッドステート・ドライブ（ＳＳＤ）の場合には、回転媒体と比べて電力効率が高く、待ち時間は基本的にはアイドル状態でもアクティブ状態でも同じ、すなわち、物理的にはスピンダウンしないため、ＳＳＤを用いて、この追加の待ち時間を減少させる又はなくすことができる。ただし、ＳＳＤは、従来のディスクドライブと比較して、高価で、かつ、容量が小さい。このように特性が異なることに合わせて、ＳＳＤは、通常のドライブとは異なる方法でビッド値を計算するようにしてもよい。ＳＳＤは、一般に、writeBid及びreadBid値が小さく、これは、スループット率が高いことを示している。また、repBid値が大きく、これは、容量が小さくコストが高いことを示している。すなわち、ＳＳＤは、新しいデータを最初に格納するのには適しているが、できるだけ早く、データを他の低コストの媒体に複製することが望ましい。（ノードの他のドライブからのビッドと共に）ＳＳＤからのビッドも考慮して、ノード全体のビッド値が算出される。

さらに、ＳＳＤは、従来のボリュームのように、アイドルモードの場合にビッドを調整するということがない。この挙動のために、アイドル・クラスタ内のＳＳＤボリュームは、ＳＳＤボリュームが格納しているデータの書き込み又は読み出しに関するビッドに勝つ可能性が最も高い。全体的な効果として、ＳＳＤを含有するアイドル・クラスタは、電力節約特性に悪影響を与えることなく、ＳＳＤを持たないアイドル・クラスタと比べて、非常に短い待ち時間で要求に応答することができる。

ヘルス処理
上述したように、各ノードのヘルス処理モジュールは、ノードのデジタルオブジェクトに対して反復処理を行なって、すべてのデジタルコンテンツの整合性を確認し、ストレージ・クラスタ内に各デジタルオブジェクトの適正な数のコピーが存在することを保証し、スループットを維持するためにオブジェクトを低コストのノードに移動させる。デジタルオブジェクトをクライアント・アプリケーションにより最初にストレージ・クラスタに書き込む際に、このオブジェクトに対するハッシュ値が算出され、ストレージ・クラスタを管理するソフトウェアにアクセス可能な、たとえば、ヘルス処理モジュールにアクセス可能な、記憶場所に格納される。任意の適当なハッシュ関数を用いることができるが、たとえば、ＭＤ５アルゴリズムはこの目的に適している。このような一意のハッシュ値を用いて、各デジタルオブジェクトの整合性を確認することができるが、このハッシュ値は、デジタルオブジェクトの検索に用いられる汎用一意識別子と必ずしも同じものでなくてもよいことに留意されたい。好適な実施形態において、整合性確認の目的で用いられるＭＤ５は、汎用一意識別子とは異なる。クラスタ内の各ノードは、デフォルト状態で、書き込みも読み出しも進行中（「Posts」又は「Gets」）ではないと仮定して、整合性チェックを実施する。各ノードのヘルス処理モジュールは、ノードのすべてのデジタルコンテンツに対してウォークスルー（検証）を行ない、各デジタルオブジェクトの最初に格納されたＭＤ５がそのデジタルオブジェクトに関して新たに算出されたＭＤ５に等しいことを検証する。

各デジタルオブジェクトの適正な数のコピーがストレージ・クラスタ内に存在することを保証するために、ヘルス処理モジュールはマルチキャストを用いる。一実施形態において、整合性チェックの際にファイルにアクセスする毎に、ヘルス処理モジュールは、すべての他のノードに「デジタルオブジェクトを保有しているか？」及び「そのデジタルオブジェクトを格納し続けるコストはどのくらいか」を問い合わせるメッセージを送信する。このマルチキャスト・メッセージに対して、ストレージ・クラスタ内で特定ファイルのコピーがさらに必要か否かを知らせ、また、各ノード上にこのようなコピーを格納し続けるコストを知らせる応答を行なう（複製ビッド）。

ストレージ・クラスタ内にデジタルオブジェクトの十分な数のコピーが存在する場合には（デジタルオブジェクト自身の任意のメタデータにより変更されるクラスタパラメータのreplication factor（複製係数）により判断される）、ヘルス処理モジュールは、オブジェクトをより低コストのノードに移動させることを決定するようにしてもよい。このような移動は、高スループットを可能にする（データが分散され、より多くのノードがアクティブになる）一方で、アーカイブ・アプリケーションにとっては必ずしも最適とは限らない。アーカイブ・アプリケーションでは、ほんの数個のノードがアクティブでデータを格納するほうが電力をより節約できる。これら数個のノードが満杯になると、ドーマント（休眠）状態になり、電力を節約できる。上述したアーカイブモードのパラメータは、状況により用いることができる。

詳細なフロー図
図２は、通常動作時に、クライアント・アプリケーションがストレージ・クラスタにファイルを書き込む工程を説明するフロー図である。ステップ２０４で、任意の適当なクライアント・アプリケーション３０が、ストレージ・クラスタ２９内へのデジタルオブジェクト（たとえば、コンピュータファイル、デジタル画像、デジタル動画、ヘルスレコード等）の格納を要求する。クライアント・アプリケーションは、クラスタ内のノード５１のうち１つのＩＰアドレスを発見又は取得して、格納処理を開始するプライマリ・アクセスノード（ＰＡＮ）として、そのノードを選択する。一般的に、クライアント・アプリケーションは、次の書き込み要求に対して、直近に用いたノードにアクセスする。ステップ２０８で、クライアント・アプリケーションは、デジタルオブジェクトを格納する要求をＰＡＮに送信する（２０１）。一実施形態において、この要求は、ヘッダとデジタルオブジェクトのバイト数で示す長さを有するHTTP POST要求である。この要求に対するＰＡＮからクライアントへの応答は、
・Ｙｅｓ，ＰＡＮはオブジェクトを格納可能
・Ｎｏ，オブジェクトを格納するのにより適したノードが存在
・Ｎｏ，クラスタ内のいずれのノードもオブジェクトを格納不可能、
のいずれか１つである。

ステップ２１２で、ＰＡＮは、この要求を受信し、それに対する応答として、クラスタ内のすべてのノードに対して、格納対象のデジタルオブジェクトとそのバイトの大きさとを示し、オブジェクトの格納に用いられるノードを決定するために、マルチキャスト・メッセージを送信する。ステップ２１６で、（ＰＡＮを含む）各ノードは、このデジタルオブジェクトに関する書き込みビッド（入札）値を算出して、ＰＡＮに対して算出したビッド値を返信する。書き込みビッド値は、各ノード上にデジタルオブジェクトを格納するのにかかるコストを示すものであり、ここでは０〜１００の値で示される。ビッド値が小さければ小さいほど、そのノード上へのオブジェクトの格納コストが安いことを示し、そのノードがビッドに勝つ可能性がより高いことを示す。各ノードにおける書き込みビッド値を算出するのに用いられる要因としては、そのノードがどの程度までいっぱいになっているか、デジタルオブジェクトの大きさ、ノードがアクティブかアイドルか、そのノードが直近にどの程度ビジーであったか、いずれの種類のボリュームが使用可能か（ソリッドステート・ドライブ、ディスクドライブ等）及びそれら個々のビッド値、並びにボリュームの状態（リタイア、アイドル等）が挙げられる。すなわち、ノードのビッド値は、ノードの各ボリュームの個々のビッド値から得られる。ノードは、各ボリュームに関して格納コストを計算し、最小値（最良値）を選択して、これを用いて、上述したような自身のノードレベルのビッド値を計算する。１つのノードが多くのドライブを備える場合には、各ドライブの容量が異なる、各ドライブが異なる状態にある等の理由により、各ドライブが異なるビッド値を持つものでもよい。

ＰＡＮが最小ビッド値を持つノードを選択すると、制御フローはステップ２２０又はステップ２３２に進む。ステップ２２０で、ＰＡＮが最小ビッド値を持つ場合には、ＰＡＮは、クライアント・アプリケーションに対して「continue」メッセージを返信して応答する。これに応じて、ステップ２２４で、クライアントがＰＡＮにデジタルオブジェクトを送信し、ステップ２２８で、ＰＡＮは、デジタルオブジェクトを格納し、ＵＵＩＤ（汎用一意識別子）を計算し、クライアント・アプリケーションに計算したＵＵＩＤ識別子を返信する。

一方、ＰＡＮがビッド（入札）に負けた場合には、ステップ２３２で、ＰＡＮは、最小ビッド値を持つノード５３に、クライアント・アプリケーションをリダイレクト（出力先変更）する（２０２）。これ以降は、リダイレクトされたノード５３が要求を処理する。このノードをセカンダリ・アクセスノード（ＳＡＮ）と称する。ステップ２３６でクライアント・アプリケーションが（ステップ２０８で送信したものと）同じ要求をＳＡＮに送信すると、ステップ２４０でノードＳＡＮがクライアント・アプリケーションに「continue」メッセージを返信して応答する。これに応じて、ステップ２４４で、クライアントがＳＡＮにデジタルオブジェクトを送信し、ステップ２４８で、ＳＡＮは、デジタルオブジェクトを格納し、ＵＵＩＤ（汎用一意識別子）を計算し、クライアント・アプリケーションに計算したＵＵＩＤ識別子を返信する。

同様に、クライアント・アプリケーションは、ＵＵＩＤ識別子により識別された特定のデジタルオブジェクトを返送するようにストレージ・クラスタに要求することも可能である。これは、SCSP GET要求を用いて、実施可能である。クライアント・アプリケーションが、識別子をストレージ・クラスタのＰＡＮに提供する。ＰＡＮは、クラスタ内のすべてのノードに対して、識別子と共にマルチキャスト・メッセージを送信する。各ノードは、読み出しビッド（デジタルオブジェクトを読み出してクライアント・アプリケーションに返送するコスト）を計算する。ＰＡＮは最小値の読み出しビッドを有するノードを選択する。選択されたノードは、クライアント・アプリケーションにデジタルオブジェクトを返送する。当然のことながら、デジタルオブジェクトを格納していないノード（ノードのメモリ内のオブジェクトの一意識別子の存在により判定される）は、ビッドに参加しない。いずれのノードもPOST要求を実行してデジタルオブジェクトを自身のドライブの１つに書き込むことができるが、実際にそのデジタルオブジェクトを格納しているノードだけが、クライアント・アプリケーションからのGET要求に応答可能である。上述したのと同様な方法で、ノードが、（ヘルス処理の際に複製を目的として）ノード間書き込み及び読み出し要求を実施するようにしてもよい。

したがって、特定の動作によりノードが「ビジー」になり、アクティブ状態に移行する。ファイルの書き込みやファイルの検索等の外部クライアント要求に応答する、又は、（たとえば、ヘルス処理の一部として）ファイルを書き込む若しくは読み出すという他のノードからの要求に応答することにより、ノードはビジーになる（したがって、アイドル状態ではなくなる）。電力を節約するために、以下に記載する工程で、ノードが、アクティブ状態からアイドル状態に移行する。

図３は、アクティブ状態からアイドル状態へのノードの移行工程を説明するフロー図である。このフローは、ストレージ・クラスタ内の各ノードにより独立に実行される。最初に、ノードがビジー、すなわち、アクティブであると仮定する。すなわち、書き込み、読み出し及びヘルス処理動作（ノードに格納されている各ファイルの整合性をチェックする、クラスタ内にファイルの適正な数のコピーが存在するか否かを判定する、および、より低コストのノードにファイルを移す）を実行中であると仮定する。当然のことながら、壊れているファイルがあれば、それを削除して、追加のコピーをクラスタ内に格納する。同様に、ヘルス処理において、クラスタ内に適正な数のコピーが存在しないと判定されれば、この場合にも、追加のコピーを格納する必要がある。また、ヘルス処理で、より低コストのノードが見つかれば、（たとえ、十分な数のコピーが存在する場合でも）ファイルを他のノードに書き込むことも可能である。このような動作はすべてＣＰＵを利用するものであり、ディスクへのアクセスを伴う。アクティブ・ノードは、クライアント・アプリケーションからの、又は、他のノードからの読み出し及び書き込み要求に対処する。

したがって、ステップ３０４で、このような動作のうちのいずれかにより、ノードは現在アクティブな状態である。ステップ３０８及びステップ３１２を並列に実施して、所定期間内に、読み出し若しくは書き込み動作又はディスクへの書き込みを伴うヘルス処理が行なわれたかを検証することが望ましい。ヘルス処理動作に関しては、ディスクへのファイルの書き込みを伴わない動作もあることに留意する必要がある。たとえば、整合性チェックの結果、壊れたオブジェクトが見つからなければ、追加のコピーを書き込む必要がない。同様に、クラスタ内に適正な数のコピーが存在する場合にも、追加のコピーを書き込む必要がない。また、ヘルス処理でより低コストのノードが見つからない場合には、ファイルのコピーを移す必要がない。ディスクへの書き込みを伴うヘルス処理動作の場合にはノードはアイドル状態に移行しないが、書き込みを伴わない動作の場合には移行が行なわれる。

上述したように、パラメータsleepAfterは、所望の時間に設定可能である。何らかの動作がなされれば、ノードはアクティブなまま維持される。しかし、所定期間にわたって、読み出し又は書き込み動作も書き込みを伴わないヘルス処理動作も実施されなければ、ステップ３１６で、ノードはアイドル状態に移行する。

ノードのアイドル状態への移行はさまざまな方法で実施可能である。移行によりすべてのヘルス処理動作を停止し、ごくわずかな実行中の処理だけが残ることが望ましい。オペレーティング・システムは、ＣＰＵが活動していない（又はほとんど活動していない）ことを認識すると、ＣＰＵ及びＲＡＭ状のクロックレートを低下させる。ストレージ・クラスタ内における電力節約の利点の１つは、外部クライアント・アプリケーション要求、ヘルス処理動作及びクラスタ内でのマルチキャスト・メッセージの処理を除けば、他の実行中の処理が、たとえあったとしてもごく少数しかないということである。ノードがアイドル状態に移行して、すべてのヘルス処理が中断されると、ごくわずかな処理しか残らないため、オペレーティング・システムはクロックレートを低下させる可能性が高い。通常のコンピュータでは、常に多数の処理が実行されるため、オペレーティング・システムがクロックレートを低下させる可能性は低い。アイドル状態になれば、ノードは、「レイジー」にビッドを行なうため、読み出し、書き込み又は複製の実施をそのノードが要求される可能性は低い。この時点で、ノードはアイドルであるが、ノードの個々のボリュームは、自己のワークキューに応じて、未処理の仕事の処理を続ける。ボリュームは、個々に自己のワークキューを保持している。

ステップ３２０で、sleepAfter秒の間、所定ボリュームに関するワークキューが空であった（すなわち、ディスクの仕事がない）と判定されると、ステップ３２８で、このボリュームを同様にアイドル状態に移行させる。そのボリュームに関するワークキューが空でなければ、ノードはアイドルのまま、ステップ３２４でボリュームをビジー状態に維持する。任意の適当なコマンドを用いてディスクをスピンダウンさせることにより、ボリュームがアイドル状態に移行する。たとえば、ディスクのスピンダウンを制御する１つの方法は、内蔵Linuxオペレーティング・システムにインストールされるhdparmユーティリティを用いる方法である。対象となるコマンドラインオプションは、Ｓ、ｙ、Ｃ、Ｙ及びＺである。オプション「Ｓ」は、ドライブの待機（スピンダウン）タイムアウトを設定する。ドライブはこの値を用いて、スピンドルモータをオフにして電力を節約するまでの（ディスク活動なしの）待機時間を決定する。ステップ３２０における判定を、オペレーティングシステムを用いて実行するようにしてもよいし、ハードウェア内で実行するようにしてもよい。ディスクがスピンダウンされて、ステップ３３２でディスクが停止し、さらに電力消費が抑制される。

図４は、アイドル・クラスタが読み出し要求を処理する工程を説明するフロー図である。ステップ４０４で、ストレージ・クラスタ全体がアイドルである、すなわち、クラスタの各コンピュータノードがアイドル状態である、と仮定する。さらに、すべてのヘルス処理動作が中断されている。

ステップ４０８で、一意識別子で識別された特定のデジタルオブジェクトを要求する外部読み出し要求を、プライマリ・アクセスノード（ＰＡＮ）がクライアント・アプリケーションから受信する。ステップ４１２で、ＰＡＮは、マルチキャスト・ビッディング処理を開始する。資格のある各ノードが、自分の読み出しビッドを計算して、この値をＰＡＮに返信する。ビッド値の計算には、各ノードのＣＰＵ及びＲＡＭが用いられ、ディスクへのアクセスは必要としないため、電力が節約できる。ノードは、そのノードのボリュームの１つが実際に該当するデジタルオブジェクトを格納している場合に限り、ビッドを行なう。ノードは、この判定をノードのメモリ内に一意識別子が格納されているか否かにより行なう。ノードの読み出しビッド値の計算に用いられる要因としては、ノードがアクティブかアイドルか、そのノードが直近にどの程度ビジーであったか、いずれの種類のボリュームがオブジェクトを格納しているか及びそれら個々のビッド値、並びに、ボリュームの状態（リタイア、アイドル等）が挙げられる。前述したように、ノードがアイドルである場合には、IdleCost値がビッドに加算される。この加算値により、アイドル状態のノードがアイドル状態で保持される。すべてのノードがアイドルである場合には、１つのノードが休止状態から復帰して要求を実行する必要がある。

ステップ４１６で、ＰＡＮは、最小ビッド値に基づいて、応答してきたノードのうち１つを選択する。この時点で、選択されたノード（及びすべての他のノード）は、まだアイドル状態である。ステップ４２０で、選択されたノードがアイドル状態からアクティブ状態に移行し、該当するデジタルオブジェクトを格納しているそのノードのボリュームもアクティブ状態に移行する。ノード及びボリュームがアクティブ状態に移行する際には、まず、デジタルオブジェクトを含むボリュームをスピンアップさせる。読み出しが完了するまで、新たにアクティブになったノードのヘルスプロセッサは起動しない。

ステップ４２４で、アクティブ・ノードが、GET要求を実行し、クライアント・アプリケーションに識別されたデジタルオブジェクトを返送する。この際、ステップ４２８で、選択されたノード及びボリュームはアクティブ状態を維持し、再びヘルス処理を実行するようにしてもよい。次に、ノードは、図３のフロー図の処理を開始して、ノードは最終的にはアイドル状態に戻る。

図５は、アイドル・クラスタが書き込み要求を処理する工程を説明するフロー図である。ステップ５０４で、ストレージ・クラスタ全体がアイドルである、すなわち、クラスタの各コンピュータノードがアイドル状態である、と仮定する。さらに、すべてのヘルス処理動作が中断されている。

ステップ５０８で、特定のデジタルオブジェクトをストレージ・クラスタに書き込むことを要求する外部書き込み要求を、プライマリ・アクセスノード（ＰＡＮ）がクライアント・アプリケーションから受信する。ステップ５１２で、ＰＡＮはマルチキャスト・ビッディング処理を開始する。クラスタの各ノードは、（たとえば、上述したように）自身の書き込みビッドを計算して、計算した値をＰＡＮに返信する。ビッド値の計算には、各ノードのＣＰＵ及びＲＡＭが用いられ、ディスクへのアクセスは必要としないため、電力が節約できる。前述したように、ノードがアイドルである場合には、IdleCost値がビッドに加算される。この加算値により、アイドル状態のノードがアイドル状態で保持される。上述したように、主に、ノードとそのボリュームの使用率により、勝利するビッドが決まる。利用可能な記憶容量が大きいボリュームほど、未使用のメモリを多く残しているため、ビッドに勝つ可能性が高い。

ステップ５１６で、ＰＡＮは、最小値の書き込みビッドに基づいて、ノードの１つを選択する。この時点で、選択されたノード（及びすべての他のノード）は、まだアイドル状態である。ステップ５２０で、選択されたノードがアイドル状態からアクティブ状態に移行し、選択されたノードの中で最も空に近いボリュームもアクティブ状態に移行する。選択されたボリュームは、そのボリュームのディスクをスピンアップさせる。

ステップ５２４で、アクティブ・ノードがPOST要求を実行して、デジタルオブジェクトを最も空に近いボリュームに書き込み、そのデジタルオブジェクトに対する一意識別子を算出し、算出した識別子をクライアント・アプリケーションに返信する。この際、ステップ５２８で、選択されたノード及びボリュームはアクティブ状態を維持し、再びヘルス処理を実行するようにしてもよい。ストレージ・クラスタ内でデジタルオブジェクトのコピーが通常は少なくとも２つ必要とされるため、ステップ５３２で、セカンダリ・アクセスノード（ＳＡＮ）が、再びマルチキャスト・メッセージを送信して、デジタルオブジェクトのコピーを書き込む機会に関して、ビッディング処理を開始する。ステップ５３６で、あるノード（複製ピア）がこのビッドに勝つと、そのノード及びそのノードの中で最も空に近いボリュームがアクティブ状態に移行する。ステップ５４０で、他のノードへのオブジェクトの第２のコピーの書き込みを実行する。当然のことながら、ストレージ・クラスタのreplication factor（複製係数）が２よりも大きな値である場合には、この時点で、デジタルオブジェクトのコピーがさらに書き込まれる。次に、両方のノードが、図３のフロー図の処理を開始して、各ノードが最終的にはアイドル状態に戻る。

このように、図４及び図５は、クラスタ内のすべてのノードを休止状態から復帰させることなく、スリープ状態のクラスタが、クライアント・アプリケーションからの書き込み及び読み出し要求を実行する工程を示すものである。

実施例
sleepAfterが３０分でwakeAfterが８時間であると仮定する。金曜日の午後５時半にすべての人が週末を過ごすために帰宅し、常にビジー状態であったストレージ・クラスタは、新しく実施するべき仕事がないことを認識する。すべてのノードが、自身のコンテンツに対して反復処理を続け、ヘルス処理チェックを実行して、クラスタ内のすべてのストリームが正常で、かつ、完全に複製されるまで、必要な複製を継続する。このような状態に到達すると、すべての複製動作が中止されるが、ノードは、反復処理とチェック、ＣＰＵサイクルの使用、及びハードディスクへのアクセスで未だビジー状態である。ある時点で、ノードの中の１つが、直近の３０分間何の新しい仕事もしなかったことを認識すると、アイドル状態に移行して、自己のヘルス処理を中断し、「レイジー」にビッドを行なう（すなわち、デジタルオブジェクトの読み出し、書き込み又は複製を行なう可能性が下がるようにビッドを調整する）。このアイドル・ノードは、他のノードからの（コピーの数に関する要求を含む）ノード間プロトコル要求には応答し続けるが、このような要求は完全にメモリ内構造で実施され、ディスクへのアクセスを必要としない。新たにアイドル状態になったノードは、自己のヘルス処理を反復しないため、コピーの数に関するクエリーを他のノードに送信しない。ノードがアイドルになっても、通常、そのノードのボリュームは、自分のワークキューが空になるまで、しばらくの間アクティブなままである。最終的に、各ボリュームは、３０分間にわたって自己のワークキューが空であったことを認識すると、アイドル状態になり、自己のディスクをスピンダウンさせる。

他のノードも、３０分間にわたって何の新しい仕事もしなかったことを認識すると、アイドル状態になる。最終的に、クラスタ内のすべてのノードがアイドル状態になり、ノード間プロトコルメッセージの送信を中止する。スリープ状態のクラスタ内における唯一の動作は、まれに生じる「town crier」メッセージの送受信である。これにより、クラスタは、スリープ状態のノードの異常を検出することができる。

ここで、低頻度メンテナンス・アプリケーションが、クラスタに１つの新しいストリーム（デジタルオブジェクト）を毎時書き込む必要がある、と仮定する。クラスタ内のすべてのノードはアイドル状態でレイジーにビッドを行なっているため、これらのノードの中の１つが書き込みビッドに勝って、要求を処理するために、強制的に休止状態から復帰させられる。ここで、プライマリ・アクセスノード（ＰＡＮ、クラスタからの読み書きを要求するクライアント・アプリケーションが最初にアクセスしたノード）が適当なＳＡＮ（セカンダリ・アクセスノード、プライマリ・ノードがクライアント要求に対処できない場合にクライアント要求を実際に処理するノード）を見つけるために、自己のディスクにアクセスして要求をリダイレクトする必要がないため、ＰＡＮを休止状態から復帰させる必要はない、ことに留意するべきである。これは、ノードがアイドル状態でもＰＡＮの動作を実行可能なためである。replication factor（複製係数）＝２（クラスタ内における各デジタルオブジェクトの要求コピー数）である場合、ＳＡＮは、第２のノードを休止状態から復帰させて、複製ピアとして機能させる必要がある。両方のノードは、次の３０分間、復帰した状態を維持し、３０分後に、再びアイドル状態になる。

２つの活動中のノードがスリープ状態に戻る前に他の書き込み要求が（クライアント・アプリケーションから）届くと、他のノードはすべてスリープ状態のままなので、この２つのノードのうちの１つが、ほぼ確実にビッドに勝つ。したがって、（たとえば）１０分毎に１回書き込みを行なうクライアント・アプリケーションは、毎回、同じ２つのノードと通信を行ない、クラスタの残りのノードは電力の節約を続ける。アプリケーションがこれら２つのノードのいずれにも格納されていないデジタルオブジェクトを読み出そうとした場合、クラスタは、そのデジタルオブジェクトの複製を見つけ、複製を保有しているノードを休止状態から復帰させて、そのデータを読み出す。アプリケーションがもっと頻繁な動作を開始する、又は、より高いスループットを必要とする場合には、より多くのノードが休止状態から復帰して、増大する要求の処理を行なう。

週末の間、別のアプリケーション動作がなければ、各ノードは、８時間毎に休止状態から復帰して、ヘルス処理を開始し、自己のストリームを検査して、必要があれば是正措置を実行する。これにより、各ノードは、スリープ状態の間に操作不能になったボリュームがあれば、これを検出することができる。何の是正措置も次の３０分間必要なければ、ノードはアイドル状態に戻る。

コンピュータシステムの実施例
図６及び図６Ｂに、本発明の実施形態を実現するのに適したコンピュータシステム９００を示す。図６Ａに、コンピュータシステムの物理的形態の例を示す。当然のことながら、コンピュータシステムは、さまざまな物理的形態をとることができ、例としては、集積回路、プリント基板、（携帯電話やＰＤＡ等の）小型携帯用デバイス、パーソナルコンピュータやスーパーコンピュータが挙げられる。コンピュータシステム９００は、モニタ９０２と、ディスプレイ９０４と、筺体９０６と、ディスクドライブ９０８と、キーボード９１０と、マウス９１２と、を備える。ディスク９１４は、コンピュータシステム９００との間のデータ転送に用いられるコンピュータ読み取り可能な媒体である。

図６Ｂに、コンピュータシステム９００のブロック図の例を示す。さまざまな種類のサブシステムがシステムバス９２０に連結される。プロセッサ９２２（中央処理装置すなわちＣＰＵとも称する）は、メモリ９２４を含む記憶装置に接続される。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）とリードオンリメモリ（ＲＯＭ）とを備える。当技術分野で周知のように、ＲＯＭは、ＣＰＵに対して一方向にデータと命令とを転送するように働き、一方、ＲＡＭは、通常、双方向にデータと命令を転送するのに用いられる。これら２種類のメモルは、いずれも、後述する任意の適当なコンピュータ読み取り可能な媒体を備えるものでもよい。固定ディスク９２６も、ＣＰＵ９２２に双方向で結合され、付加的なデータ記憶容量を提供し、後述するコンピュータ読み取り可能な媒体のいずれかを備えるものでもよい。固定ディスク９２６は、プログラムやデータ等の格納に利用可能であり、通常、主記憶装置よりも低速の二次記憶媒体（たとえば、ハードディスク）である。固定ディスク９２６内に保持されている情報は、適切と思われる場合には、標準的な方法で仮想メモリとしてメモリ９２４内に組み込むことができる。リムーバブル・ディスク９１４は、後述するコンピュータ読み取り可能な媒体いずれの形態でもよい。

ＣＰＵ９２２は、ディスプレイ９０４、キーボード９１０、マウス９１２及びスピーカー９３０等のさまざまな入出力装置にも接続されている。一般に、入出力装置として、ビデオディスプレイ、トラックボール、マウス、キーボード、マイク、タッチセンサ式ディスプレイ、トランスデューサ・カードリーダ、磁気又は紙テープ読み取り装置、タブレット、スタイラス、音声又は手書き認識装置、生体認証読み取り装置や他のコンピュータのいずれかを用いることができる。ＣＰＵ９２２が、さらに、ネットワーク・インターフェース９４０を用いて、他のコンピュータネットワークや電気通信網に接続されるものでもよい。上述した処理工程を実行する際に、このようなネットワーク・インターフェースを用いて、ＣＰＵがネットワークから情報を受信したり、ネットワークに情報を出力したりすることができる。さらに、本発明の方法の実施形態は、ＣＰＵ９２２が単独で実行することもできるし、あるいは、インターネット等のネットワークを介して、リモートＣＰＵに処理の一部を分担させるようにしてもよい。

さらに、本発明の実施形態は、さまざまなコンピュータが実現する動作を実行するためのコンピュータコードを有するコンピュータ読み取り可能な媒体を備えるコンピュータ・ストレージ製品に関する。媒体及びコンピュータコードは、本発明の目的のために特別に設計及び構成されたものでもよいし、コンピュータソフトウェア分野の当業者に周知で利用可能な種類のものでもよい。コンピュータ読み取り可能な媒体の例としては、以下に限定されるものではないが、ハードディスク、フレキシブルディスク及び磁気テープ等の磁気媒体、ＣＤ−ＲＯＭ及びホログラフィック装置等の光学媒体、フロプティカルディスク等の光磁気媒体、並びに、特定用途向け修正回路（ＡＳＩＣ）、プログラム可能な論理装置（ＰＬＤ）並びにＲＯＭ及びＲＡＭ装置等のプログラムコードを格納して実行するように特別に構成されたハードウェア装置が挙げられる。コンピュータコードの例としては、コンパイラにより生成されるもの等のマシンコードや、インタープリタを用いるコンピュータにより実行される上位コードを含むファイルが挙げられる。

以上、理解を助ける目的で、本発明を詳細に説明してきたが、添付の特許請求の範囲内で変形や変更が可能である。したがって、上述の実施形態は例示に過ぎず本発明を限定するものではない。本発明は、上述の詳細に何ら限定されるものではなく、以下の特許請求の範囲及びそれと等価の要旨の全範囲内で規定されるものである。

Claims (11)

1. ＣＰＵと少なくとも１個のディスクドライブとを備え、自己のオペレーティングシステムを実行するよう各コンピュータノードが相互に接続された複数のコンピュータノードからなるストレージ・クラスタにおいて、前記コンピュータノードと前記ディスクドライブとをアイドル状態にする方法であって、
   前記ストレージ・クラスタ内の各コンピュータノードに関して、第１の所定期間に、前記各コンピュータノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
   前記ストレージ・クラスタ内の各コンピュータノードに関して、第２の所定期間に、前記各コンピュータノードで、前記ストレージ・クラスタ内の他のコンピュータノードから書き込み要求又は読み出し要求が生じなかったことを判定する工程と、
   前記ストレージ・クラスタ内の各コンピュータノードに関して、前記第１の所定期間及び前記第２の所定期間に、前記クライアント要求も前記書き込み要求も生じなかったことを判定した場合に、前記各コンピュータノードを独立にアイドル状態に移行させる工程と、
   アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、を備える方法。
2. 請求項１に記載の方法であって、
   前記第１の所定期間、前記第２の所定期間、及び前記第３の所定期間が同じ値である、方法。
3. 請求項１に記載の方法であって、さらに、
   アイドル状態に移行させた各ディスクボリュームの回転を停止させる工程を備える、方法。
4. 請求項１に記載の方法であって、
   前記ストレージ・クラスタは、ライトワンス・リードメニー（ＷＯＲＭ）型の固定コンテンツ保存クラスタである、方法。
5. 請求項１に記載の方法であって、さらに、
   各コンピュータノードのディスクボリューム上で実行されるすべてのファイル整合性チェックを停止することにより、前記各コンピュータノードをアイドル状態にする工程と、
   前記各コンピュータノードの前記オペレーティング・システムにより、前記各コンピュータノードの前記ＣＰＵのクロックレートを低下させる工程と、
   を備える方法。
6. 請求項１に記載の方法であって、さらに、
   アイドル状態のコンピュータノードの各ディスクボリュームのスピンダウンを指示することにより、前記ディスクボリュームをアイドル状態にする工程を備える、方法。
7. 請求項１に記載の方法であって、さらに、
   各コンピュータノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させるようにビッド値を計算することにより、前記コンピュータノードをアイドル状態にする工程を備える、方法。
8. 複数の相互に接続されるコンピュータノードを有するストレージ・クラスタ内でコンピュータノードをアイドル状態にする方法であって、
   前記コンピュータノードがアクティブ状態のときに、前記コンピュータノードにより、前記ストレージ・クラスタ外部のクライアント・アプリケーションからのクライアント要求を処理する工程と、
   第１の所定期間に、前記コンピュータノードで、外部クライアント・アプリケーションからのクライアント要求が生じなかったことを判定する工程と、
   第２の所定期間に、前記コンピュータノードで、前記ストレージ・クラスタ内の他のコンピュータノードからの読み出し要求又は書き込み要求が生じなかったことを判定する工程と、
   前記ストレージ・クラスタ内の前記他のコンピュータノードとは独立に、前記コンピュータノードをアイドル状態に移行させる工程と、
   前記アイドル状態のコンピュータノードの各ディスクボリュームに対するワークキューが、第３の所定期間にわたって空であったことを判定した場合に、前記各ディスクボリュームをアイドル状態に移行させる工程と、
   を備える方法。
9. 請求項８に記載の方法であって、さらに、
   前記第１の所定期間に、前記他のコンピュータノードの各々で、外部クライアント・アプリケーションからのクライアント要求が生じなかったことが判定され、かつ、前記第２の所定期間に、前記他のコンピュータノードの各々で、前記ストレージ・クラスタ内の他のコンピュータノードから読み出し要求又は書き込み要求が生じなかったことを判定した場合に、前記ストレージ・クラスタ内の前記他のコンピュータノードの各々に対して、前記移行工程を実施する工程を備える、方法。
10. 請求項１に記載の方法であって、さらに、
    前記コンピュータノードのうちハードディスクドライブを備える第１のコンピュータノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させるように、前記コンピュータノードのうちの前記第１のコンピュータノードに関するビッド値を計算する工程と、
    前記コンピュータノードのうちソリッドステート・ドライブを備える第２のコンピュータノードが外部読み出し又は書き込みのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を増大させるように、前記コンピュータノードのうちの前記第２のコンピュータノードに関するビッド値を計算する工程と、を備える方法。
11. 請求項８に記載の方法であって、さらに、
    ディスクドライブを備える各ディスク・ボリュームに対して、書き込み又は読み出しビッド値を調整して、前記ディスクドライブを備えるボリュームが、外部書き込み又は読み出しのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を減少させる工程と、
    ソリッドステート・ドライブを備える各ディスク・ボリュームに対して、書き込み又は読み出しビッド値を調整して、前記ソリッドステート・ドライブを備えるボリュームが、外部書き込み又は読み出しのビッドに関して、アクティブ・コンピュータノードとの競争に勝つ可能性を増大させる工程と、を備える方法。

Images