JP2006113828A

JP2006113828A - 作業負荷管理可能なクラスタシステム

Info

Publication number: JP2006113828A
Application number: JP2004300884A
Authority: JP
Inventors: Katsuharu Nakagawa; 勝晴中川; Junko Sasaki; 淳子佐々木
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-10-15
Filing date: 2004-10-15
Publication date: 2006-04-27

Abstract

【課題】本発明はクラスタ環境のノード間で自動的に負荷分散を行う方法に関し、従来はサービスを提供するサーバとは別に管理サーバが必要だった。そのため不経済であり、また、管理サーバの障害の際にはクラスタ機能を維持できない。さらに、従来の負荷分散方法では複数のサーバで同じアプリケーションの起動が必要な場合があり、その分多くリソースを消費する。
【解決手段】各ノード上のクラスタ制御部の中で中心的な役割を果たすコーディネータにより、管理サーバが不要となる。また、たとえコーディネータが存在するノードに障害が発生しても、生き残るノードのクラスタ制御部の中から新たなコーディネータが選ばれることにより、クラスタ機能を維持できる。さらに、フェイルオーバする方法でノード間の負荷分散を実現することにより、同じアプリケーションを複数のノードで起動する必要が無くなる。
【選択図】図１

Description

本発明は、クラスタシステム内の複数のノード間で負荷分散する方法に関するものである。

従来は、特許文献１に記載のように、一台の管理サーバを中心にノード間の負荷分散を行っていた。また、特許文献１では、アプリケーションをフェイルオーバさせる方法ではなく、各ノードがサービスを提供する対象とする端末の組み合わせを変更することにより、負荷分散を行っている。

特開２００３−３４５７７０号公報

上記背景技術は、サービスを提供している構成サーバとは別に専用の管理サーバを必要としているため不経済であるという欠点や、管理サーバに障害が発生するとクラスタ機能を維持できなくなるという欠点があった。また、同じサービスを受けたい複数の端末が別の構成サーバに割り当てられた場合には、同じアプリケーションを複数の構成サーバで起動する必要があった。このため、各ノードのCPU、メモリ、ディスクバンド幅などのリソースを有効活用し、ノード間で作業負荷を管理可能な高可用性クラスタを実現するためには不十分であった。

上記目的を達成するために、各ノード上のクラスタ制御部の中で中心的な役割を果たすコーディネータが存在する。たとえコーディネータが存在するノードに障害が発生しても、再編成後のクラスタに含まれるノードのクラスタ制御部の中から、新たなコーディネータとなるものを選ぶ。

また、アプリケーションをフェイルオーバすることでノード間の負荷分散を実現する。

本発明によれば、管理用の専用サーバが不要となる経済的な利点や、たとえコーディネータをもつノードに障害が発生しても、ほかのノードにコーディネータが移るため、引き続きクラスタの制御や作業負荷の管理が可能となる利点がある。

また、同じサービスを受ける複数の端末がある場合でも、複数のノードで同じアプリケーションを起動することなく負荷分散が行えるため、CPU、メモリ、ディスクバンド幅などのリソースを有効活用できる利点がある。

以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。

図１は本発明における一実施例である作業負荷管理可能なクラスタシステムの構成を示すものである。

本実施例ではクラスタシステムが３つのノード101,102,103から成っており、各ノード上にはクラスタ制御部104,105,106および作業負荷管理部107,108,109が存在する。本実施例では、クラスタ制御部104がコーディネータの役割を担っているものとする。ノード102の負荷が大きく、ノード102上で起動しているパッケージ(アプリケーションを扱う単位)110のフェイルオーバが必要な時に、各ノードの負荷状態を比較して負荷の低いノード103にフェイルオーバするまでの流れを順に説明する。

ノード102上の作業負荷管理部108が、図４のフェイルオーバ必要性判断の手順により、フェイルオーバが必要だと判断してクラスタ制御部105に図１３で示す負荷情報を通知する。クラスタ制御部105は受け取った負荷情報をコーディネータ104に通知する。コーディネータ104は、負荷情報を既に通知してきたノード102以外のノード101,103のクラスタ制御部104,106に負荷情報を問い合わせる要求を通知する。クラスタ制御部104は作業負荷管理部107に、また、クラスタ制御部106は作業負荷管理部109に、それぞれ負荷情報を問い合わせる。作業負荷管理部107はクラスタ制御部104に、また、作業負荷管理部109はクラスタ制御部106に、それぞれのノードの負荷情報を図１３で示す形式で通知する。クラスタ制御部104,109がそれぞれ自分のノードの負荷情報をコーディネータ104に通知する。コーディネータ104は収集した各ノードの負荷情報を元に、図１０の利用率テーブル1001または図１１のSLO達成状態テーブル1101を更新し、その内容をどのノードからもアクセス可能な共有ディスク上の負荷情報記録ファイル111に記録する。その内容を元に、図６のフェイルオーバ先決定処理に従って最も負荷の低いと判断されるノード2にパッケージ110をフェイルオーバさせる。

図８のフェイルオーバポリシーテーブル801は、フェイルオーバポリシー803の優先度802の設定情報を持ち、共有ディスク113またはローカルディスク上のパッケージ構成ファイル112の中で定義される。なお、パッケージ構成ファイルの内容は、全ノードのクラスタ制御部104,105,106が共通の内容として持っているものとする。また、図８〜図１２のテーブルの情報はメモリ上に存在するものとする。

図２のステップ221、ステップ217、図３のステップ309において、フェイルオーバポリシー803に合わせた処理の選択が行われる際には、優先度802の高いフェイルオーバポリシーから順に適用が試みられるが、適用できない場合には次に優先度の高いポリシーの適用を試みる。あるフェイルオーバポリシーが適用できずに次の優先度のものを採用する例としては、例えばステップ217において、他ノードの負荷情報がタイムアウトにより収集できず、現在の負荷情報によるフェイルオーバ先の決定ができない場合や、ステップ206,308において、共有ディスク113上に負荷情報ファイルが存在していない場合が考えられる。

また、フェイルオーバポリシーテーブル801には、フェイルバックさせるかどうかを設定するフラグ808がある。

図９は起動ノードの優先順位を示すテーブルであり、パッケージ構成ファイル112の中で定義される。フェイルオーバポリシー803が「優先順」807の場合、現在クラスタに参加しているノードの中で、最も優先順位の高いノードをフェイルオーバ先に決める。なお、すべてのテーブルに記載されているノード1、ノード2、ノード3は、それぞれ、図１のノード101、ノード102、ノード103に対応するものとする。

図１５のノード間共通情報テーブル1501は、クラスタ内の全ノードに共通する内容のものが置かれている。クラスタの設定変更やクラスタの再編成、パッケージの起動または停止の際に、クラスタ制御部間でこれらの情報が通知されてテーブルが更新され、常に全ノードのテーブルの内容が一致している。ノード間共通情報テーブル1501には、現在のコーディネータ1502、フェイルオーバポリシーを決める材料1503、各ノードで起動中のパッケージ数1504、フェイルバック先のノード1505、コーディネータ決定ポリシー1506、コーディネータとなるノードの優先順位1507に関する情報が含まれている。

フェイルバック先のノード1505は、既にフェイルオーバしたパッケージが、フェイルオーバする前に起動していたノードである。フェイルオーバ後に利用率またはSLOの目標値を満たしていなかった場合に、フェイルバックする設定であれば元のノードにパッケージを移動させる(ステップ703)。

なお、フェイルオーバポリシーテーブル801、起動ノード優先順位テーブル901も、ノード間共通情報テーブル1501と同様に全ノードで共通の情報であり、クラスタの設定が変更された際にクラスタ制御部間で更新情報を通知する。

図１０の利用率テーブル1001は、コーディネータ104に各ノードのクラスタ制御部から集められたリソースの利用率に関するメモリ上の情報であり、負荷情報記録ファイル111にも記録される。ここでの利用率とは、各ノードの持つリソース(CPU、メモリ、ディスクバンド幅)が利用されている割合を意味する。図１３の負荷情報が届くたびに、利用率テーブル1001と負荷情報記録ファイル111は更新される。なお、負荷情報記録ファイル111の更新時点で、もし共有ディスク113に負荷情報記録ファイルが無ければ、メモリ上の利用率テーブル1001を元に新たに生成される。

図１１のSLO達成状態テーブル1101は、コーディネータ104に各ノードのクラスタ制御部から集められたSLOの達成状態に関するメモリ上の情報であり、負荷情報記録ファイル111にも記録される。SLOとはアプリケーショングループごとのサービスレベルに関する目標値のことであり、たとえばリソース(CPU、メモリ、ディスクバンド幅)の利用率やレスポンスタイムなどの目標値が考えられる。図１１中グループとは、アプリケーションのグループである。ただし、アプリケーショングループの利用率1103とは、CPUまたはメモリまたはディスクバンド幅のいずれかのリソースのうち、そのアプリケーショングループに利用されている割合を意味する。優先順1102は、フェイルオーバ対象のアプリケーショングループを決めるための優先順であり、必ずしも重要な業務のアプリケーショングループの優先度を高くしたほうがよいとは限らない。わずかなダウンタイムも許されない重要な業務にリソースを確保するために、あまり重要でないアプリケーショングループをフェイルオーバさせたほうがよい場合もあることを考えて設定する。図１３の負荷情報が届くたびに、SLO達成状態テーブル1101と負荷情報記録ファイル111は更新される。なお、負荷情報記録ファイル111の更新時点で、もし共有ディスク113に負荷情報記録ファイルが無ければ、メモリ上のSLO達成状態テーブル1101を元に新たに生成される。

図１２の作業負荷管理テーブル1201は各ノードの作業負荷管理部が持つ情報であり、各ノードのリソース利用率またはSLOの目標値1203および測定値1204、未達成回数1205、未達成許容回数1206などが含まれる。これをもとに、図４のフェイルオーバ必要性判断処理が行われる。また、各リソースの利用率やSLOを、フェイルオーバ先を決める材料とするかどうか設定する。ただし、利用率とSLO達成状態のうち、いずれか片方しかフェイルオーバ先を決める材料として選択できないものとする。

図１３は作業負荷管理部とクラスタ制御部の間、またはクラスタ制御部間でやりとりされる負荷情報である。図１２の作業負荷管理テーブル1201の「材料とするか」という項目1202でフェイルオーバ先を決める材料として決めた必要最小限のデータのみ送ることが可能である。図１３中の斜線欄は、図１２中で材料と決めていない不要なデータであり、これを送らない例を示している。

図２は図１で示したクラスタ制御部104,105,106に対し、各種の情報が通知されたときに、その情報の種類に応じた処理の流れを示したものである。

クラスタ制御部104,105,106は起動している間、作業負荷管理部107,108,109または他ノードのクラスタ制御部からの各種情報の通知を待っている(ステップ201)。

クラスタ制御部105に、同じノードの作業負荷管理部108より図１３で示した負荷情報が届いたとき(ステップ202)、クラスタ制御部105はコーディネータ104に負荷情報を通知する(ステップ203)。

コーディネータ104が他ノードのクラスタ制御部105より負荷情報の通知を受けたとき(ステップ204)、フェイルオーバポリシー803に応じた処理が行われる。ただし、ここでの負荷情報の通知は、問合せに対する返信情報の通知ではなく、フェイルオーバが必要なノード102のクラスタ制御部105から自主的に行われた通知とする。ここで、図１３の送信種別フラグ1301により、自主的な通知なのか、それとも問い合わせに対する返信通知なのか見分けられる。なお、フェイルオーバポリシーの優先度については、図８のフェイルオーバポリシーテーブル801で設定されている。

図８の優先度802に基づいて、フェイルオーバポリシー803として「現在の負荷状況を問い合わせる」(804)が採用される場合、コーディネータ104は既に負荷情報を通知してきたノード102を除く、ノード101,103のクラスタ制御部104,106に負荷情報を問い合わせる(ステップ205)。

フェイルオーバポリシー803として「負荷情報の記録を元にする」(805)が採用される場合、コーディネータ104の共有ディスク113上に負荷情報記録ファイル111が存在していれば、その情報を参照して(ステップ206)、図６のフェイルオーバ先決定処理を行う(ステップ207)。

フェイルオーバポリシー803として「パッケージ数が最小のノード」(806)が採用される場合、コーディネータ104は、起動中のパッケージ数1504が最も少ないノードを、フェイルオーバ先に決定する(ステップ208)。

フェイルオーバポリシー803として「優先順」(807)が採用される場合、フェイルオーバ対象のパッケージがそれまで起動していたノードを除いて、図９の優先順に従いフェイルオーバ先を決める(ステップ209)。

クラスタ制御部104,106が、コーディネータ104より負荷情報の問い合わせを受けたとき(ステップ210)、それぞれの作業負荷管理部107,109に負荷情報を問い合わせ(ステップ211)、受信した結果をコーディネータ104に通知する(ステップ213)。

コーディネータ104が各ノードのクラスタ制御部104,106より負荷情報に関する問い合わせ結果の通知を受けたとき(ステップ214)、図１０の利用率テーブル1001または図１１のSLO状態テーブル1101を更新し(ステップ215)、その内容を負荷情報記録ファイル111にも記録する。現在クラスタに参加している全てのノードの負荷情報が届くまで待つものとするが、タイムアウトを過ぎた場合には「現在の負荷情報を問い合わせる」(804)以外のフェイルオーバポリシーを優先度802に従って適用する(ステップ217)。タイムアウトまでに全ノードの負荷情報が届いた場合は、図６のフェイルオーバ先決定処理を行う(ステップ216)。

既にクラスタが起動している状態で、ユーザのコマンドやアプリケーションにより、追加のサービス起動要求が、あるノードのクラスタ制御部105に通知されたとき(ステップ218、図１４)、図３のサービス起動ノード決定処理を行った(ステップ219)後に、サービスを起動する(ステップ220)。

図４は各ノード101,102,103の負荷状態に応じて、フェイルオーバが必要かどうか判断する手順を示す。各ノードの作業負荷管理部107,108,109は、図１２の作業負荷管理テーブル1201の利用率またはSLOの測定値1204が、目標値(許容限界値)1203を満たしているかどうか、定期的に確認している(ステップ401)。また、確認のたびに作業負荷管理テーブル1201の測定値1204および連続未達成回数1205を更新する(ステップ401)。

確認の結果、満たしていれば連続未達成回数1205のカウンタを0に戻し(ステップ402)、次の確認までの間待つ(ステップ405)。

満たしていなければ、連続未達成回数1205のカウンタを1増やす(ステップ403)。ここで、連続未達成回数1205が非許容回数1206に達していれば、フェイルオーバが必要だと判断し、同じノードのクラスタ制御部に図１３の負荷情報を通知する(ステップ404)。ここで送られる負荷情報は、フェイルオーバ先を決める材料とするかどうかを設定したフラグ1202がyesであるもののみとし、また、図１３の目標値や必要なリソース量1302など、一度のみの通知で十分であるものは、作業負荷管理部のこれらの設定が変わった時点で一度のみの通知とする。

以上のステップ402〜404を、一定時間待った(ステップ405)後に、定期的に繰り返す。図１の例では、作業負荷管理部108がステップ404によりフェイルオーバが必要だと判断し、クラスタ制御部105に負荷情報を通知する。

図５はクラスタ制御部から作業負荷管理部に負荷情報の問い合わせ(ステップ211)があった時に、作業負荷管理部が図１３の負荷情報をクラスタ制御部に通知する(ステップ501)ことを示す。図１の例では、クラスタ制御部104から作業負荷管理部107に、また、クラスタ制御部106から作業負荷管理部109に、それぞれ問合せがあったときに、負荷情報を返信通知している(ステップ212,501)。

図６は図２のフェイルオーバ先決定処理(ステップ207,216)の詳細な流れを示す。

フェイルオーバ先を決める材料1503が利用率の場合、目標値を達成しているノードが無ければ、フェイルオーバさせない(ステップ605)。目標値を達成しているノードがあれば、その中で利用率が最も低いノードをフェイルオーバ先に決める(ステップ601)。ただし、図10の利用率テーブル1001において、CPU1002、メモリ1003、ディスクバンド幅1004の中で、優先度1005の高いリソースを元にフェイルオーバ先のノードを決める。例えば、最も優先度の高いCPU1002の利用率をまず比較し、もしもノード間でこの値が等しい場合には、メモリ1003の利用率の比較結果をもとにフェイルオーバ先のノードを決めるというように、優先度に従う。

起動ノードを決める材料がSLO達成状態である場合、未達成SLO数の最も少ないノードをフェイルオーバ先に決める(ステップ602)。

フェイルオーバ先を決めた後、フェイルオーバさせるアプリケーションを決める(ステップ604)。フェイルオーバが必要なノードで動いている複数のアプリケーション中で、フェイルオーバ候補の優先順(1102,1303)に、フェイルオーバ先のノードに必要なリソース量1302があるか順次確認する(ステップ603)。ここで、必要なリソース量1302は、ユーザが実験などを通して見積もった値をあらかじめ設定しておく。リソース確保可能なアプリケーションのうち、最も優先順1102の高いものをフェイルオーバ対象としてフェイルオーバを行う(ステップ604)。もしもリソース確保可能なアプリケーションがなければ、フェイルオーバさせない(ステップ605)。

図７はフェイルオーバ後の処理の流れを示す。フェイルオーバ完了後、作業負荷管理部の負荷状況の確認(ステップ401)の結果、フェイルオーバ先のノードで利用率とSLOの測定値1204が目標値1203を満たすことができた場合、そのノードでサービスを続行する(ステップ701)。フェイルオーバ先のノードで利用率またはSLOの目標値を満たしていなかった場合、作業負荷管理部109はクラスタ制御部106に満足していないことを通知する(ステップ702)。その後、クラスタ制御部106は、フェイルバックするかどうかを決めるフラグ808がYesであれば、フェイルバック先のノード1505にフェイルバックし(ステップ703)、そうでなければ設定した待ち時間の後に、図２の各種情報の通知に対する対応処理を再開する(ステップ704)。

図３は図２で示したサービス起動ノード決定処理(ステップ219)について、処理の流れを詳細に示したものである。

このサービス起動ノード決定処理は、クラスタが既に起動している状態で、追加のサービスを起動する場合の処理であり、クラスタ起動時やフェイルオーバ時には適用されない。なお、クラスタ起動に伴いサービスを起動するときには、図９の優先順位が最も高いノードで起動される。

この処理が行われた時の一実施例を、図１４に示す。

ノード102のクラスタ制御部105に、サービス起動要求が通知された時(ステップ218,301)、クラスタ制御部105はサービス起動要求をコーディネータ104に通知する(ステップ302)。サービス開始要求を受けたコーディネータ104は、フェイルオーバポリシー803の設定に応じて起動ノードを決定する。

フェイルオーバポリシー803として「現在の負荷状態を問い合わせる」(804)が採用される場合、コーディネータ104は各ノードのクラスタ制御部104，105，106に負荷情報を問い合わせる(ステップ303)。問合せを受けたクラスタ制御部104，105，106は、それぞれ作業負荷管理部107，108，109に負荷情報を問合せ、その返信情報をコーディネータ104に通知する(ステップ304)。コーディネータ104は利用率テーブル1001またはSLO達成状態テーブル1101を更新し(ステップ305)、負荷情報記録ファイル111も更新する。起動先ノードを決める材料が利用率の場合、利用率の最も低いノードを起動先のノードとする(ステップ306)。起動ノードを決める材料がSLO達成状態の場合、未達成SLO数の最も少ないノードを起動先のノードとする(ステップ307)。

フェイルオーバポリシー803として「最新の負荷情報記録を元にする」(805)が採用される場合、負荷情報記録ファイル111があるかどうか確認し(ステップ308)、ある場合は起動ノードを決める材料に応じてフェイルオーバ先を決める。すなわち、起動先ノードを決める材料が利用率の場合、利用率の最も低いノードを起動先のノードとし(ステップ306)、起動ノードを決める材料がSLO達成状態の場合、未達成SLO数の最も少ないノードを起動先のノードとする(ステップ307)。負荷情報記録ファイル111がない場合は、優先度802に応じた他のフェイルオーバポリシー803を採用する。

フェイルオーバポリシー803として「パッケージ数が最小のノード」(806)が採用される場合、コーディネータ104は、起動しているパッケージ数1504が最も少ないノードを、起動先に決定する(ステップ309)。

フェイルオーバポリシー803として「優先順」(807)が採用される場合、現在クラスタに参入しているノードの中で、図９の優先順位が最も高いノードで起動される。

図１６はコーディネータを決定する処理の流れを示す。コーディネータの決定が必要なタイミングとしては、クラスタの起動時（ステップ1601）とコーディネータのノードに障害発生した時（ステップ1602）が挙げられる。

クラスタの起動が開始すると（ステップ1601）、コーディネータとなるノードの優先順位1507に従ってコーディネータが決定される（ステップ1603）。

コーディネータのノードに障害が発生した時（ステップ1602）、コーディネータ決定ポリシー1506が優先順であれば、コーディネータとなるノードの優先順位1507に従ってコーディネータを決定する（ステップ1603）。コーディネータ決定ポリシー1506がパッケージ数であれば、起動中のパッケージ数1504が最小のノードの中で、さらに優先順位1507に従ってコーディネータを決定する（ステップ1604）。

本発明の実施方法の全体構成を示した説明図である。クラスタ制御部の、通知された情報に応じた処理の流れを示した図である。サービス起動ノード決定処理の流れを詳細に示した図である。負荷状態に応じてフェイルオーバが必要かどうか判断する手順を示した図である。作業負荷管理部がクラスタ制御部に返信通知することを示した図である。フェイルオーバ先決定処理の詳細な流れを示した図である。フェイルオーバ後の処理の流れを示した図である。フェイルオーバポリシーの優先度の設定情報を持つテーブルである。起動ノードの優先順位を示すテーブルである。各ノードのリソースの利用率に関する情報を持つテーブルである。各ノードのSLO達成状態に関する情報を持つテーブルである。各ノードの負荷状態や目標達成状況に関する情報を持つテーブルである。作業負荷管理部またはクラスタ制御部の間でやりとりされる負荷情報を示すテーブルである。サービス起動ノード決定処理の全体構成を示した図である。クラスタ内の全ノードに共通する内容のテーブルである。コーディネータを決定する処理の流れを示した図である。

符号の説明

101…ノード1、102…ノード2、103…ノード3、104…クラスタ制御部（現在のコーディネータ）、105…クラスタ制御部、106…クラスタ制御部、107…作業負荷管理部、108…作業負荷管理部、109…作業負荷管理部、110…フェイルオーバ対象のパッケージ、111…負荷情報記録ファイル、112…パッケージ構成ファイル、113…共有ディスク。

Claims

クラスタを制御するクラスタ制御部、各ノード上の負荷を管理する作業負荷管理部、を備える複数のノード間で、各ノードの負荷状態に応じて、サービスの起動ノードを決めることを特徴とするクラスタシステム。
請求項１のクラスタシステムにおいて、クラスタ制御部が作業負荷管理部からの負荷状態の通知を待つことを特徴とするクラスタシステム。
コーディネータの存在するノードの障害に対しても、コーディネータを他のノードに切り替えることによって、作業負荷管理可能なクラスタの機能を維持できるようにすることを特徴とするクラスタシステム。
障害発生時のみならず、ノード間で負荷に偏りが発生した時にも自発的にアプリケーションをフェイルオーバさせることを特徴とするクラスタシステム。