JP4245588B2 - クラスタノードを動作させるクラスタシステムおよび方法 - Google Patents

Description

本発明は、クラスタノードを動作させるクラスタシステムおよび方法に関する。

近年のアプリケーションアーキテクチャは往々にして、アプリケーションのクラスタ実行をサポートしている。クラスタ実行は、作業負荷が分散し、場合によってはシステムにわたって平衡されるように、システムのセット上のインスタンス（大半の場合では同一インスタンス）の集まりとしてアプリケーションを実行することを指す。任意の特定のシステムが故障した場合、その作業負荷は、通常通り、またはパフォーマンスがいくらか低下した状態で、残りのシステムで続けられる。

クラスタ実行には多くの利点がある。たとえば、クラスタ実行は、クラスタノードが故障しても全体のアプリケーション故障に繋がらないため、より高い可用性を提供する。さらに、クラスタ実行は通常、コストの削減に繋がる。これは、一体式のサーバをより大きなサーバで置き換えるのではなく、より小さなサーバを使用して増分ベースで拡張を行うことができるためである。同じ理由により、分散したアプリケーションをより迅速にスケーリングすることができる。また、サーバを地理的に分散させることで、負荷平衡化および耐災害性を取り入れることができる。

一実施形態では、クラスタシステムは、複数のアプリケーションを実行する複数のクラスタノードと、複数のクラスタノードを制御する管理プロセスとを備え、管理プロセスは、サービスレベル目標（ＳＬＯ）を満たしていない第１のアプリケーションを特定し、現在、第１のアプリケーションを実行していないクラスタノードを選択し、選択されたクラスタノードへの第２のアプリケーションのトランザクションのルーティングを徐々に低減し、選択されたクラスタノードへの第１のアプリケーションのトランザクションのルーティングを徐々に増大するように動作可能である。

別の実施形態では、複数のクラスタノードを動作させる方法は、第１のアプリケーションがサービスレベル目標を満たしていないことを検出すること、第２のアプリケーションを実行しているノードを再分配するものとして選択すること、第２のアプリケーションに関連するトランザクションの選択されたノードへのルーティングを徐々に低減すること、第１のアプリケーションに関連するトランザクションの選択されたノードへのルーティングを徐々に増大することとを含む。

別の実施形態では、システムは、クラスタアーキテクチャの複数のコンピュータアプリケーションを実行する複数の手段と、第１のコンピュータアプリケーションがサービスレベル目標を満たしていないことを検出する手段と、複数の実行する手段の中から、第２のコンピュータアプリケーションを実行しているものを選択する手段と、選択された実行する手段への第２のコンピュータアプリケーションのトランザクションのルーティングを徐々に低減する手段と、選択された実行する手段への第１のコンピュータアプリケーションのトランザクションのルーティングを徐々に増大する手段とを備え、徐々に増大する手段および徐々に低減する手段は同時に動作する。

典型的な分散アプリケーションは、各アプリケーションにそれぞれ専用のクラスタを使用して実装される。しかし、専用クラスタは、突然の需要の上昇に対処する際に問題が多い。クラスタのすべてのシステムは飽和し、それによって資源の枯渇が発生する可能性がある。資源が枯渇する可能性は、多くの組織によってサポートされるイントラネットおよびエクストラネットのオープン接続によって高くなる。具体的には、接続が突然急増すると、資源枯渇によってクラスタが動作不能になる場合がある。この状況を検出する管理ツールが存在するが、リカバリは通常、手動での作業である。

これより図面を参照すると、図１は、代表的な一実施形態による、サーバ資源を動的に分配するシステム１００を示す。システム１００は、単一システムイメージング（ＳＳＩ：Single System Imaging）クラスタ（Hewlett-Packard社からのTruCluster等）を使用して実装することができる。ＳＳＩクラスタは、システム管理者およびアプリケーションに対して単一ノードの「イメージ」を呈する、ハードウェアおよびソフトウェアの接続性を有するシステムの集まりを指す。具体的には、複数のノードを単一のプラットフォームとして管理することが可能である。さらに、インターネットプロトコル（ＩＰ）アドレスエイリアシングを利用して、所与のアプリケーションをクラスタの複数のノードで実行することができ、その間、アプリケーションのクライアントからはアプリケーションが単一のシステムで実行されているように見える。ＳＳＩクラスタは通常、コンフィグレーションファイル（図示せず）のルート単一コピーを含むすべてのファイルシステムへのアクセスをコヒーレントにするファイルシステム１１０を備える。ファイルシステム１１０およびクラスタボリューム管理に対するトランスペアレントで高度な可用性が通常、提供される。ＳＳＩクラスタに関するさらなる詳細については、Hewlett-Packard社が２００２年９月に発行した出版物「Cluster Hardware Configuration: TruCluster Server Version 5.1B」から得られ、これを参照により本明細書に援用する。

図１に示すように、クラスタは、制御システム１０８上で実行される管理プロセス１０１によって管理される。別法として、管理プロセス１０１は、クラスタのノード１１１ａ〜１１１ｉの中の１つで実行してもよい。クラスタ相互接続１１４を、専用高性能ノード間通信に使用することができる。クラスタ相互接続１１４は、転送をノード１１１のメモリに直接マッピングすることによって実装することができる。アプリケーション（ＡＰＰ_１、ＡＰＰ_２、およびＡＰＰ_３）は、サービスを各クライアント１０９に提供することができる。アプリケーションは、各ノード１１１上で、各ソフトウェアコードのインスタンスを提供することによって実装される。たとえば、ソフトウェアインスタンス１０５ａ〜１０５ｃがＡＰＰ_１に提供され、ソフトウェアインスタンス１０６ａ〜１０６ｄがＡＰＰ_２に提供され、ソフトウェアインスタンス１０７ａおよび１０７ｂがＡＰＰ_３に提供される。図１は例として与えられることを理解すべきである。任意の適したクラスタアーキテクチャおよびアプリケーションを代表的な実施形態に採用することが可能である。

各ノード１１１は、適したコンピュータプラットフォームおよび関連するサーバソフトウェアを使用して実装することができる。ノード１１１が展開されると、アプリケーションの実行可能ソフトウェアをノード１１１に記憶することができる。管理プロセス１０１は、アプリケーション管理（ＡＡ）モジュール１１３との通信により、どの特定のソフトウェアプロセスが各ノードで実行されるかを制御することができる。たとえば、一実施形態では、「アプリケーション定義ファイル」（ＡＤＦ）が使用されて、ノード１１１上で実行可能なアプリケーション、各アプリケーションをノード１１１上で開始する方法を特定したスクリプト、ノード１１１上での各アプリケーションの実行を停止する方法に関連する情報、および／または他の同様のものが特定される。管理プロセス１０１は、ノード１１１が特定のアプリケーションを実行すべきであると判断した場合、適した信号またはメッセージを各ＡＡモジュール１１３に送る。ＡＤＦを使用して、実行のためのアプリケーションのインスタンスが作成される。管理プロセス１０１は、特定のノード１１１上でのアプリケーションインスタンスの実行を、同様にして停止させることもできる。

図１に示すように、クラスタは、クラスタエイリアス１０２、１０３、および１０４を使用してサブクラスタに分割される。各クラスタエイリアスには、クライアント１０９が各サブクラスタにアクセスできるようにするＩＰアドレスが関連付けられる。クラスタエイリアス１０２には、アプリケーションインスタンス１０５ａ〜１０５ｃを実行している３つのノード（１１１ａ〜１１１ｃ）が関連付けられ、クラスタエイリアス１０３には、アプリケーションインスタンス１０６ａ〜１０６ｄを実行している４つのノード（１１１ｄ〜１１１ｇ）が関連付けられ、クラスタエイリアス１０４には、アプリケーションインスタンス１０７ａおよび１０７ｂを実行している２つのノード（１１１ｈ〜１１１ｉ）が関連付けられる。

各アプリケーションには相対優先度を割り当てることができる。相対優先度は、サブクラスタ上で実行されるアプリケーションの相対的な重要度を規定する。この例では、アプリケーションＡＰＰ_１およびＡＰＰ_２はオンラインデータベーストランザクション処理を実行することができ、ＡＰＰ_３はバッチサービスを実行することができる。したがって、アプリケーションＡＰＰ_１およびＡＰＰ_２には、クラスタエイリアスＡＰＰ_３の優先度よりも高い相対優先度が割り当てられる。

各サブクラスタ、アプリケーション、またはノードには、サービスレベル目標（ＳＬＯ）を割り当てることができる。ＳＬＯは、規定の資源利用測度またはパフォーマンス目標測度である。たとえば、クラスタエイリアス１０３のＳＬＯは、アプリケーションＡＰＰ_２が規定のクエリタイプに対して平均応答時間１０ミリ秒を提供することであり得る。別法として、特定のノード１１１のＣＰＵ／メモリ／Ｉ／Ｏ資源の利用率が８０パーセント未満、または他の任意の適したレベル未満のままの状態であるべきである。各パフォーマンスモニタ１１２が、各ノード１１１に関連する動作を調べ、適した測度を管理プロセス１０１に通信する。管理プロセス１０１はこの測度を用いて、ＳＬＯ解析を実行し、ノード１１１を適宜再分配する。

さらに、各クラスタエイリアスは、ノード１１１がクラスタインフラストラクチャを使用してデフォルトの「重み」を有するように構成することが可能である。重みとは、特定のノード１１１にルーティングされるサブクラスタトランザクションの相対量を示す。各サブクラスタは、各サブクラスタ内のすべてのノード１１１に対して所定の重み（サブクラスタデフォルト重み（ＳＤＷ））を有することができる。別法として、サブクラスタをインスタンス化した後、各サブクラスタの様々なノード１１１に非均等な重みを割り当てることができる。

図２は、クラスタアーキテクチャでの、サーバ資源の分配に関するフローチャートを示す。図２のフローチャートは、例として、管理プロセス１０１内の実行可能コードまたはソフトウェア命令として実装することができる。

本例では、クラスタエイリアス１０３に関連するＡＰＰ_２はそのＳＬＯを達成していないと仮定する。したがって、ＡＰＰ_２は、現在分配されている資源よりも多くの資源から恩恵を受け得る。また、クラスタエイリアス１０４に関連するＡＰＰ_３は、そのＳＬＯを常に達成しているものと仮定する。クラスタエイリアス１０２に関連するＡＰＰ_１は、殆どの時間においてそのＳＬＯを達成しているものと仮定する。

ステップ２０１において、第１のサブクラスタ（クラスタエイリアス１０３に関連するサブクラスタ）すなわち第１のアプリケーション（ＡＰＰ_２）がそのＳＬＯを満たしていないと判断される。たとえば、第１のアプリケーションの、規定のトランザクションに対する応答時間は、所定のしきい値を下回り得る。別法として、メモリ利用率、プロセッサ利用率、またはＩ／Ｏ資源利用率が所定のしきい値を超えており、それによってアプリケーションのパフォーマンスの低下が示され得る。

ステップ２０２において、第２のアプリケーション（ＡＰＰ_３）を実行している、別のサブクラスタの（サブクラスタ１０４に関連する）各ノード１１１（たとえば、ノード１１１ｈ）が選択される。たとえば、ノード１１１ｈの選択は、サブクラスタまたはアプリケーションの相対優先度を用いて行うことができる。ステップ２０３において、プロセスが、選択されたノード１１１ｈ上で開始され、選択されたノード１１１ｈ上に第１のアプリケーション（ＡＰＰ_２）のインスタンスが作成される。プロセスは、適したメッセージを管理プロセス１０１から各ＡＡモジュール１１３に通信することによって開始することができる。

ステップ２０４において、選択されたノード１１１ｈが第１のアプリケーション（ＡＰＰ_２）のサブクラスタ（クラスタエイリアス１０３に関連する）に追加され、サブクラスタについての重み０が割り当てられる。重み０は、第１のアプリケーションに関連するトラフィックが最初に、選択されたノード１１１ｈに送られないようにする。

ステップ２０５において、タイマが初期化される。たとえば、特定の時間期間をタイマに設定することができる。時間期間は、各アプリケーションに使用されるプロトコルおよび平均トランザクション時間を考慮することによって選択することができる。たとえば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）永続接続が、比較的長いアプリケーションセッションをサポートするために使用される場合、時間期間は、クライアント１０９との過度の数のＴＣＰ／ＩＰ接続が切断しないように、比較的大量であり得る（たとえば、秒単位）。別法として、トランザクションが比較的短い場合（たとえば、複雑性の低いデータベース検索の場合）、時間期間は比較的小量であり得る。また、時間期間は、調整可能パラメータとして実装することができる。

ステップ２０６において、論理比較が行われ、その時間が経過したか否かが判断される。経過していない場合、プロセスの流れは、タイマが経過するまで繰り返される。その時間が経過すると、プロセスの流れはステップ２０７に進む。

ステップ２０７において、第２のアプリケーション（ＡＰＰ_３）に関連するサブクラスタ内の選択されたノード１１１ｈの重みが、０よりも大きい場合に限り、所定量だけ低減される。

ステップ２０８において、第１のアプリケーション（ＡＰＰ_２）に関連するサブクラスタについて選択されたノード１１１ｈの重みが、サブクラスタデフォルト重み（ＳＤＷ）または他の適した重みに達するまで、所定量だけ増大される。

ステップ２０９において、論理比較が行われ、これらのサブクラスタについて選択されたノード１１１ｈの重みがゼロおよびＳＤＷに達したか否かが判断される。達していない場合、プロセスの流れはステップ２０５に戻る。重みが所望の重みに達している場合、プロセスの流れはステップ２１０に進む。

ノード１１１ｈの再分配に関連して、選択されたノード１１１ｈの重みを管理することにより、アプリケーションの動作を有利に行うことができる。具体的には、ノード１１１ｈの再分配は、第２のアプリケーションに関連するクライアント１０９が、通常、かなりのパフォーマンス低下を認めずにすむ十分な時間量にわたって行うことができる。たとえば、過度の量の永続ＴＣＰ／ＩＰセッションが切断されない。さらに、第２のアプリケーションに関連するトランザクションが終了したときに、第１のアプリケーションに関連する重みが増分的に増大される。したがって、資源は、過度の待ち時間なしで第１のアプリケーションに効率的に移行されている。

ステップ２１０において、低優先度を、第２のアプリケーションに関連するバイナリファイル処理トランザクションに割り当てることができ、または別法として、バイナリファイルの実行を停止することができる。

ステップ２１１において、選択されたノード１１１ｈは、第２のアプリケーション（アプリケーション１０７）に関連するサブクラスタから除去される。

一実施形態について、より低い優先度を有するアプリケーションから資源を再分配するものとして説明したが、本発明はこのように限定されるものではない。たとえば、複数の優先度のより高いアプリケーションが、単一の優先度のより低いアプリケーションから同じノードを同時に取得しようとすることもできる。「DYNAMIC MANAGEMENT OF COMPUTER WORKLOADS THROUGH SERVICE LEVEL OPTIMIZATION」という名称の米国特許出願第０９／４９３，７５３号（これを参照により本明細書に援用する）に開示されるアルゴリズム等、アービトレーションアルゴリズムを採用して、ノードを２つの優先度のより高いアプリケーション間で分配することができる。さらに、追加の基準を使用して、再分配するノードを選択することもできる。たとえば、ＳＬＯを満たしていない、優先度のより低いアプリケーションからノードを再分配するのではなく、十分にＳＬＯの範囲内にある優先度が等しいか、またはより高いアプリケーションからノードを再分配することが有利な場合もある。

図３は、代表的な一実施形態による、再分配するノードの選択に関するフローチャートである。図３のフローチャートは、例として、管理プロセス１０１内の実行可能コードまたはソフトウェア命令として実装することができる。ステップ３０１において、現在、ＳＬＯを満たしていないアプリケーションよりも低い相対優先度を有するアプリケーション（複数可）に関連する測度が調べられる。ステップ３０２において、論理比較が行われ、優先度のより低いアプリケーションがＳＬＯ範囲内で動作しているか否かが判断される。真の場合、プロセスの流れはステップ３０３に進み、相対優先度のより低いアプリケーションを実行しているノード１１１が再分配されるものとして選択される。ステップ３０２の論理判断が偽の場合、プロセスの流れはステップ３０４に進む。

ステップ３０４において、等しい優先度を有するアプリケーション（複数可）に関連する測度が調べられる。ステップ３０５において、論理比較が行われ、優先度の等しいアプリケーションが十分にＳＬＯ範囲内で動作しているか否かが判断される。たとえば、優先度の等しいアプリケーションが３つのノード１１１上で実行されている場合、このアプリケーションは資源利用率８０％というＳＬＯを有し、利用率測度は、利用率が２０％であることを示し、各サブクラスタから１つのノード１１１を再分配しても、パフォーマンスの低下に繋がらない可能性が最も高い。

ステップ３０５の論理比較が真の場合、プロセスの流れはステップ３０６に進む。ステップ３０６において、等しい優先度を有するアプリケーションに関連するノード１１１が、再分配されるものとして選択される。ステップ３０５の論理比較が偽の場合、プロセスの流れはステップ３０３に進む。ステップ３０３において、優先度のより低いアプリケーションを実行しているノード１１１が、再分配されるものとして選択される。

このようにして再分配するノード１１１を選択することにより、アプリケーションのパフォーマンスに対する影響を最低限に抑えることができる。具体的には、可能であれば、選択されたノードでそれまで実行されていたアプリケーションのパフォーマンスに生じる影響がごくわずかなノードが選択される。そうすることができない場合、再分配の影響が、優先度のより低いアプリケーションのパフォーマンスにおいて観察される。図３のプロセスの流れは例としてのものである。他の適した再分配基準を解析してもよい。さらに、優先度のより高いアプリケーションも同様に調べて、ノードの再分配が優先度のより高いアプリケーションにおよぼす影響がごくわずかであるか否かを判断することもできる。

ソフトウェアに実装される場合、本発明の諸要素は本質的に、必要なタスクを実行するコードセグメントである。プログラムまたはコードセグメントは、プロセッサ可読媒体に記憶することもでき、または伝送媒体を介して、搬送波、または搬送波で変調された信号で具現されるコンピュータデータ信号で伝送することもできる。「プロセッサ可読媒体」は、情報を記憶する、または転送することができるあらゆる媒体を包含し得る。プロセッサ可読媒体の例としては、電子回路、半導体メモリデバイス、ＲＯＭ、フラッシュメモリ、消去可能ＲＯＭ（ＥＲＯＭ）、フロッピー(登録商標)ディスク、コンパクトディスクＣＤ―ＲＯＭ、光ディスク、ハードディスク、光ファイバ媒体、無線周波（ＲＦ）リンク等が挙げられる。コードセグメントは、インターネット、イントラネット等のコンピュータネットワークを介してダウンロードすることができる。

図４は、代表的な一実施形態に従って適合されたコンピュータシステム４００を示す。中央演算処理装置（ＣＰＵ）４０１がシステムバス４０２に結合される。ＣＰＵ４０１は任意の汎用ＣＰＵであることができる。しかし、本発明は、ＣＰＵ４０１が本明細書において説明する本発明の動作をサポートする限り、ＣＰＵ４０１の構造によって制限されない。バス４０２はランダムアクセスメモリ（ＲＡＭ）４０３に結合され、ＲＡＭ４０３は、ＳＲＡＭ、ＤＲＡＭ、またはＳＤＲＡＭであることができる。ＲＯＭ４０４もバス４０２に結合され、ＲＯＭ４０４は、ＰＲＯＭ、ＥＰＲＯＭ、またはＥＥＰＲＯＭであることができる。ＲＡＭ４０３およびＲＯＭ４０４は、当分野において既知のようにユーザデータ、システムデータ、およびプログラムを保持する。

バス４０２は、入出力（Ｉ／Ｏ）コントローラカード４０５、通信アダプタカード４１１、ユーザインタフェースカード４０８、およびディスプレイカード４０９にも結合される。Ｉ／Ｏカード４０５は、ハードドライブ、ＣＤドライブ、フロッピー(登録商標)ディスクドライブ、テープドライブ等のうちの１つまたは複数の記憶装置４０６をコンピュータシステムに接続する。記憶装置４０６は、クラスタアーキテクチャのノードへのトランザクションのルーティングを制御し、どのアプリケーションがノードで実行されるかを制御するソフトウェアまたは実行可能コードを記憶することができる。たとえば、記憶装置４０６は、代表的な一実施形態による管理プロセス１０１を実装する実行可能コードを記憶することができる。

通信カード４１１は、コンピュータシステム４００をネットワーク４１２に結合するように適合され、ネットワーク４１２は、ローカル（ＬＡＮ）、広域（ＷＡＮ）、イーサネット(登録商標)、またはインターネットネットワークのうちの１つまたは複数であることができる。ユーザインタフェースカード４０８は、キーボード４１３およびポインティングデバイス４０７等のユーザ入力装置をコンピュータシステム４００に結合する。ディスプレイカード４０９は、ＣＰＵ４０１によって駆動され、表示装置４１０上の表示を制御する。

いくつかの代表的な実施形態は、クラスタアプリケーションの効率的な動作を可能にする。クラスタのノードは、観察された需要に応答して、特定のアプリケーションに動的に分配される。より少数のノードを使用して、資源枯渇という危険を冒すことなくアプリケーションをサポートすることができる。したがって、資源の過剰提供を回避することができる。さらに、再分配するノードを選択する間にアプリケーションのパフォーマンスを調べることにより、クライアントにとって大抵はトランスペアレントにノードの再分配を行うことができる。また、相対優先度を使用することにより、再分配によってアプリケーションパフォーマンスが認め得るほどに変化し得る場合に、「極めて重要」または重要なアプリケーションが適正なパフォーマンス基準を維持することができる。

代表的な一実施形態によるクラスタシステムを示す。 代表的な一実施形態によるクラスタノードへの分配に関するフローチャートを示す。 代表的な一実施形態による再分配するノードの選択に関するフローチャートを示す。 代表的な一実施形態に従って適合されたコンピュータシステムを示す。

符号の説明

１００・・・クラスタシステム
１０１・・・管理プロセス
１０２〜１０４・・・クラスタエイリアス
１０５〜１０７・・・アプリケーション
１０８・・・制御システム
１０９・・・クライアント
１１０・・・記憶装置
１１１・・・ノード
１１２・・・パフォーマンスモニタ
１１３・・・アプリケーション管理モジュール
１１４・・・クラスタ相互接続
４００・・・コンピュータシステム
４０１・・・ＣＰＵ
４０２・・・システムバス
４０３・・・ＲＡＭ
４０４・・・ＲＯＭ
４０５・・・Ｉ／Ｏアダプタ
４０６・・・記憶装置
４０７・・・ポインティングデバイス
４０８・・・ユーザインタフェースアダプタ
４０９・・・ディスプレイアダプタ
４１０・・・表示装置
４１１・・・通信アダプタ
４１２・・・ネットワーク

Claims (8)

1. 複数のアプリケーション（１０５、１０６、１０７）を実行する複数のクラスタノード（１１１）と、
   該複数のクラスタノードを制御する管理プロセス（１０１）と
   を備え、
   前記管理プロセスは、サービスレベル目標（ＳＬＯ）を満たしていない第１のアプリケーションを特定し、現在、該第１のアプリケーションを実行していないクラスタノードを選択し、該選択されたクラスタノードへの第２のアプリケーションのトランザクションのルーティングを徐々に低減し、前記選択されたクラスタノードへの前記第１のアプリケーションのトランザクションのルーティングを徐々に増大し、前記クラスタノードの再分配により、前記第２のアプリケーションが該第２のアプリケーションのサービスレベル目標を満たさなくなるか否かを判断するように動作可能である、クラスタシステム。
2. 前記管理プロセスは、優先度のより低いアプリケーションに関連するクラスタノードを調べることによって前記クラスタノードを選択するように動作可能である、請求項１記載のクラスタシステム。
3. 前記管理プロセスは、優先度の等しい、またはより高いアプリケーションに関連するクラスタノードを調べることによって前記クラスタノードを選択するように動作可能である、請求項１記載のクラスタシステム。
4. 前記複数のクラスタノード上の各パフォーマンス監視プロセスが、パフォーマンス測度情報を前記管理プロセスに通信する、請求項１記載のクラスタシステム。
5. 複数のクラスタノード（１１１）を動作させる方法であって、
   第１のアプリケーションがサービスレベル目標を満たしていないことを検出すること（２０１）、
   第２のアプリケーションを実行しているノードを再分配するものとして選択すること（２０２）、
   前記選択されたノードの再分配により、別のアプリケーションがサービスレベル目標を満たさなくなるか否かを判断すること、
   前記第２のアプリケーションに関連するトランザクションの前記選択されたノードへのルーティングを徐々に低減すること（２０７）、
   前記第１のアプリケーションに関連するトランザクションの前記選択されたノードへのルーティングを徐々に増大すること（２０８）
   とを含む、複数のクラスタノードを動作させる方法。
6. 前記徐々に低減すること、および徐々に増大することは同時に行われる、請求項５記載の複数のクラスタノードを動作させる方法。
7. 前記選択することは、前記判断することに応答して、優先度のより低いアプリケーションに関連するクラスタノード、および優先度が少なくとも等しいアプリケーションに関連するクラスタノードの中から選択する、請求項５記載の複数のクラスタノードを動作させる方法。
8. 前記徐々に低減すること、および徐々に増大することは、
   前記第１のアプリケーションについて前記選択されたクラスタノードのサブクラスタ重みを増大すること、
   前記第２のアプリケーションについて前記選択されたクラスタノードのサブクラスタ重みを低減すること
   とを含む、請求項５記載の複数のクラスタノードを動作させる方法。

Images