JP2015032219A - 管理装置および管理方法 - Google Patents

Abstract

【課題】サービスを安定して提供できるようにする。
【解決手段】管理装置５０は、収集部５１と、判定部５４とを備える。収集部５１は、現用系のマスタサーバに障害が発生し、待機系のマスタサーバがフェイルオーバして新たな現用系のマスタサーバとなった場合に、当該新たな現用系のマスタサーバの負荷を示す計測情報を収集する。判定部５４は、収集部５１によって収集された計測情報が所定の閾値を下回った場合に、新たな現用系のマスタサーバに、予備サーバとの間でのデータの同期処理の開始を指示して、当該予備サーバを新たな待機系のマスタサーバに移行させる。
【選択図】図２

Description

本発明は、管理装置および管理方法に関する。

下記の非特許文献１には、大量のデータを多数のサーバで並列処理するための大規模分散処理システムについて開示されている。この大規模分散処理システムを構成する各サブシステムにおけるマスタ系サーバは、設計上、現用系マスタと１台以上の待機系マスタとで構成される。現用系マスタが故障した場合には、待機系マスタが新たに現用系マスタに昇格（フェイルオーバ）することで、システム全体としての可用性を向上させている。

このように、２４時間３６５日安定したサービスを提供する必要のある商用システムでは、通常、サーバは冗長化されており、１台のサーバが故障しても、システム全体としては停止しないように構成されている。

鷲坂光一 他、「大量データ分析のための大規模分散処理基盤の開発」、ＮＴＴ技術ジャーナル、2011 Vol.23 No.10、p.22-25

ところで、上記した大規模分散処理システムでは、現用系サーバに障害が発生し、ホットスタンバイ状態にある待機系サーバがフェイルオーバした場合、次の障害発生に備えて、別の待機系サーバを新たに準備する必要がある。待機系サーバを新たに準備する処理には、（フェイルオーバにより待機系サーバから昇格した）現用系サーバとの間で、データの同期をとる処理を実行する必要がある。データの同期をとる処理には、ある程度高い処理負荷がかかる。

また、待機系サーバがフェイルオーバにより現用系サーバに昇格してサービスを再開した直後は、旧現用系サーバが機能していなかった期間に溜まったリクエストが一気に押し寄せるため、一時的に処理負荷が高くなる。

そのため、待機系サーバを新たに準備する場合には、フェイルオーバにより昇格した現用系サーバの負荷状況を確認しながら、当該現用系サーバによって提供されるサービスへの影響が極力少なくなるように、フェイルオーバにより昇格した現用系サーバと、新たな待機系サーバとの間でデータの同期をとる処理を開始するタイミングを見計らう必要がある。

従来は、システムの保守者がこのような作業を行っていたため、保守者が不在の場合には、フェイルオーバにより昇格した現用系サーバ１台でサービスを継続する状況が続くことになる。そのため、保守者が不在の間に、フェイルオーバにより昇格した現用系サーバも故障してしまうと、システム全体のサービスが停止してしまうことになる。

また、複数の処理サーバで処理を分担する分散処理システムにおいて、１つの処理サーバが故障すると、その処理サーバの処理を他の処理サーバが引き継ぐことで、全体としてのサービスを継続することができる。その場合、故障した処理サーバに代えて、リソースプールにある予備サーバが、新たに処理サーバとしてシステムに組み入られることで、システム全体の計算機リソースが元の状態に戻される。

ここで、故障した処理サーバの処理を他の処理サーバが引き継ぐ場合、１台の処理サーバに負荷が集中しないように、故障した処理サーバの処理を他の処理サーバのそれぞれに分散させるリカバリ処理が行われる。このリカバリ処理では、各処理サーバには、ある程度高い処理負荷がかかる。そのため、処理サーバが故障すると、故障していない他の処理サーバの負荷が一時的に高くなる。

また、リソースプールにある予備サーバを、新たな処理サーバとしてシステムに組み入れる場合、複数の処理サーバで負荷を均等に配分するためのリバランス処理が実行される。この処理でも、各処理サーバには、ある程度高い処理負荷がかかる。

そのため、処理サーバが故障した場合に、リソースプールにある予備サーバを、新たな処理サーバとして即座にシステムに組み入れると、リカバリ処理とリバランス処理とが平行して実行されるため、各処理サーバの負荷がさらに高くなり、分散処理システム全体として提供するサービスの品質が悪化する場合がある。

そのため、処理サーバが故障した場合には、各処理サーバの負荷状況を確認しながら、サービスの品質への影響が極力少なくなるように、リバランス処理を開始するタイミングを見計らう必要がある。従来は、システムの保守者がこのような作業を行っていたため、保守者が不在の間に処理サーバが故障した場合には、システム全体の計算機リソースが少ない状態での運用を余儀なくされていた。

そこで、本発明は、上述した従来技術の課題を解決するためになされたものであり、サービスを安定して提供できるようにすることを目的とする。

上記課題を解決するための本発明の第一の態様は、例えば、現用系サーバと、待機系サーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置であって、前記現用系サーバに障害が発生し、前記待機系サーバがフェイルオーバして新たな現用系サーバとなった場合に、当該新たな現用系サーバの負荷を示す計測値を収集する収集部と、前記収集部によって収集された前記計測値が、所定の閾値を下回った場合に、前記新たな現用系サーバに、前記予備サーバとの間でのデータの同期処理の開始を指示して、当該予備サーバを新たな待機系サーバに移行させる判定部と、を備える。

また、本発明の第二の態様は、例えば、複数のスレーブサーバと、それぞれのスレーブサーバが保持するデータを管理するマスタサーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置であって、前記複数のスレーブサーバのいずれかに障害が発生した後に、当該障害が発生した前記スレーブサーバが保持しているデータと同一のデータを、当該スレーブサーバ以外の他のスレーブサーバに分散配置させるリカバリ処理が完了したか否かを判定し、当該リカバリ処理が完了した後に、前記予備サーバを新たなスレーブサーバとして、障害が発生していない複数のスレーブサーバのそれぞれが保持しているデータの量を調整するリバランス処理の開始を前記マスタサーバに指示する判定部を備える。

また、本発明の第三の態様は、例えば、現用系サーバと、待機系サーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置によって実行される管理方法であって、前記現用系サーバに障害が発生し、前記待機系サーバがフェイルオーバして新たな現用系サーバとなった場合に、当該新たな現用系サーバの負荷を示す計測値を収集する収集工程と、前記収集工程において収集した前記計測値が所定の閾値を下回ったか否かを判定する工程と、前記収集工程において収集した前記計測値が前記所定の閾値を下回ったと判定した場合に、前記新たな現用系サーバに、前記予備サーバとの間でのデータの同期処理の開始を指示して、当該予備サーバを新たな待機系サーバに移行させる工程と、を含む。

また、本発明の第四の態様は、例えば、複数のスレーブサーバと、それぞれのスレーブサーバが保持するデータを管理するマスタサーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置によって実行される管理方法であって、前記複数のスレーブサーバのいずれかに障害が発生した後に、当該障害が発生した前記スレーブサーバが保持しているデータと同一のデータを、当該スレーブサーバ以外の他のスレーブサーバに分散配置させるリカバリ処理が完了したか否かを判定する工程と、前記リカバリ処理が完了したと判定した後に、前記予備サーバを新たなスレーブサーバとして、障害が発生していない複数のスレーブサーバのそれぞれが保持しているデータの量を調整するリバランス処理の開始を前記マスタサーバに指示する工程と、を含む。

本発明の管理装置によれば、サービスを安定して提供することができる。

図１は、本発明の一実施形態におけるサーバシステムの構成の一例を示すシステム構成図である。 図２は、管理装置の機能構成の一例を示すブロック図である。 図３は、計測情報格納部に格納されるデータの構造の一例を示す図である。 図４は、閾値格納部に格納されるデータの構造の一例を示す図である。 図５は、管理装置の動作の一例を示すフローチャートである。 図６は、管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下、本発明の実施の形態について、図面を参照しながら説明する。

［サーバシステム１０の全体構成］
図１は、本発明の一実施形態におけるサーバシステム１０の構成の一例を示すシステム構成図である。本実施形態におけるサーバシステム１０は、現用系のマスタサーバ２０−１と、待機系のマスタサーバ２０−２と、複数の予備サーバ３１−１〜ｎと、複数のスレーブサーバ４０−１〜ｎと、管理装置５０と、死活監視装置６０とを備える。

それぞれのマスタサーバ２０、それぞれの予備サーバ３１、それぞれのスレーブサーバ４０、管理装置５０、および死活監視装置６０は、相互に通信可能に通信回線１１に接続されている。

実施形態では、サーバシステム１０として、ユーザのデータを管理するデータベースシステムを例に説明する。当該データベースシステムでは、データを複数のスレーブサーバ４０−１〜ｎに分散配置し、マスタサーバ２０がユーザの端末からのデータの要求に応じて、当該データを保持しているスレーブサーバ４０の情報を提供する。ユーザは、端末を操作して、マスタサーバ２０から提供された情報に基づいてスレーブサーバ４０にアクセスし、目的のデータを取得する。

複数の予備サーバ３１−１〜ｎは、リソースプール３０として管理されており、通信回線１１を介した管理装置５０からの制御により、必要なソフトウェアのインストールやパラメータの設定を経て、待機系のマスタサーバ２０−２またはスレーブサーバ４０として機能する。

死活監視装置６０は、通信回線１１を介して、それぞれのスレーブサーバ４０の障害発生の有無を監視する。死活監視装置６０は、例えば、それぞれのスレーブサーバ４０から通信回線１１を介して定期的に送信されるハートビート信号を監視し、一定期間以上ハートビート信号を受信しなかったスレーブサーバ４０を検出した場合に、当該スレーブサーバ４０の障害発生を検出する。障害発生を検出した場合、死活監視装置６０は、障害が発生した旨よび障害が発生したスレーブサーバ４０の識別情報等を、通信回線１１を介して現用系のマスタサーバ２０−１および管理装置５０に通知する。

待機系のマスタサーバ２０−２は、現用系のマスタサーバ２０−１との間でデータの同期をとりながら、ホットスタンバイ状態で待機している。そして、待機系のマスタサーバ２０−２は、現用系のマスタサーバ２０−１に障害が発生した場合に、当該現用系のマスタサーバ２０−１に代って現用系のマスタサーバ２０−１に昇格（フェイルオーバ）する。

待機系のマスタサーバ２０−２は、例えば、現用系のマスタサーバ２０−１から通信回線１１を介して定期的に送信されるハートビート信号を監視しており、一定期間以上ハートビート信号を受信しなかった場合に、現用系のマスタサーバ２０−１の障害発生を検出し、フェイルオーバを実行する。フェイルオーバを実行して新たに現用系となったマスタサーバ２０−１は、その旨を通信回線１１を介して管理装置５０に通知する。

複数のスレーブサーバ４０−１〜ｎのそれぞれは、所定の処理を実行する処理サーバである。本実施形態において、それぞれのスレーブサーバ４０は、データベースサーバであり、データ毎に、同一のデータを所定台数（例えば３台）の異なるスレーブサーバ４０に分散配置することで、スレーブサーバ４０の障害に対するデータ保持の信頼性を高めている。

それぞれのスレーブサーバ４０は、現在の負荷を計測し、負荷の計測値を、スレーブサーバ４０を識別するサーバＩＤ、スレーブサーバであることを示すサーバ種別、および計測時刻に対応付けて計測情報として保持する。本実施形態において、それぞれのスレーブサーバ４０は、例えば、ＣＰＵ利用率、メモリ利用率、単位時間当たりのリクエスト処理件数などを、現在の負荷として計測する。そして、通信回線１１を介して管理装置５０から計測情報を要求された場合、それぞれのスレーブサーバ４０は、保持している計測情報を、通信回線１１を介して管理装置５０へ送信する。

また、本実施形態において、現用系のマスタサーバ２０−１は、データ毎に、当該データを保持しているスレーブサーバ４０の情報を格納する分散テーブルを保持している。そして、現用系のマスタサーバ２０−１は、通信回線１１を介して、ユーザの端末からデータを要求された場合に、分散テーブルを参照して、当該データを保持しているスレーブサーバ４０の情報を特定し、特定した情報をユーザの端末に返す。ユーザは、端末を操作して、受け取った情報に対応するスレーブサーバ４０にアクセスし、当該スレーブサーバ４０から目的のデータを取得する。

また、現用系のマスタサーバ２０−１は、現在の負荷を計測し、負荷の計測値を、マスタサーバ２０−１を識別するサーバＩＤ、マスタサーバであることを示すサーバ種別、および計測時刻に対応付けて計測情報として保持する。本実施形態において、現用系のマスタサーバ２０−１は、例えば、ＣＰＵ利用率、メモリ利用率、単位時間当たりのリクエスト処理件数などを、処理負荷として計測する。そして、通信回線１１を介して管理装置５０から計測情報を要求された場合、現用系のマスタサーバ２０−１は、保持している計測情報を、通信回線１１を介して管理装置５０へ送信する。

また、現用系のマスタサーバ２０−１は、新たな待機系のマスタサーバ２０−２の識別情報と共に、同期処理の開始を管理装置５０から指示された場合に、通信回線１１を介して、当該新たな待機系のマスタサーバ２０−２との間で、内部データを同期させる同期処理を開始し、当該新たな待機系のマスタサーバ２０−２をホットスタンバイ状態に移行させる。

また、現用系のマスタサーバ２０−１は、スレーブサーバ４０に障害が発生した旨を死活監視装置６０から通知された場合に、当該スレーブサーバ４０の稼働を停止させる。そして、現用系のマスタサーバ２０−１は、分散テーブルを参照し、障害が発生したスレーブサーバ４０が保持しているデータと同一のデータを保持している他のスレーブサーバ４０を特定する。

そして、現用系のマスタサーバ２０−１は、障害が発生したスレーブサーバ４０が保持しているデータと同一のデータを、特定した他のスレーブサーバ４０から抽出して、障害が発生していないスレーブサーバ４０に分散配置させるリカバリ処理を実行する。これにより、障害が発生したスレーブサーバ４０が保持しているデータと同一のデータが、障害が発生したスレーブサーバ４０を除いた、所定台数の異なるスレーブサーバ４０に分散配置される。リカバリ処理が完了した場合、現用系のマスタサーバ２０−１は、その旨を通信回線１１を介して管理装置５０に通知する。

また、現用系のマスタサーバ２０−１は、新たなスレーブサーバ４０の情報と共に、リバランス処理の開始を管理装置５０から指示された場合に、分散テーブルに当該新たなスレーブサーバ４０の情報を登録する。そして、現用系のマスタサーバ２０−１は、各スレーブサーバ４０が保持するデータの容量の差が、全てのスレーブサーバ４０間で小さくなるように、各スレーブサーバ４０が保持するデータを調整するリバランス処理を実行する。

管理装置５０は、（フェイルオーバ実行直前までは待機系のマスタサーバ２０−２であった）現用系のマスタサーバ２０−１からフェイルオーバが実行された旨の通知を受けた場合に、リソースプール３０として管理されている予備サーバ３１の中の１台に対して、待機系のマスタサーバ２０−２として機能するのに必要なソフトウェアのインストールおよび設定等を、通信回線１１を介して行う。そして、管理装置５０は、現用系のマスタサーバ２０−１から負荷の計測値を取得する。

次に、管理装置５０は、現用系のマスタサーバ２０−１の負荷の計測値が所定の閾値を下回った場合に、現用系のマスタサーバ２０−１に、必要なソフトウェアのインストール等が行われた新たな待機系のマスタサーバ２０−２との間で同期処理の開始を指示する。現用系のマスタサーバ２０−１との間で同期処理が行われた新たな待機系のマスタサーバ２０−２は、ホットスタンバイ状態に移行する。

また、死活監視装置６０からスレーブサーバ４０の障害発生を通知された場合、管理装置５０は、リソースプール３０とした管理されている予備サーバ３１の中の１台に対して、スレーブサーバ４０として機能するのに必要なソフトウェアのインストールおよび設定等を通信回線１１を介して行う。

そして、リカバリ処理の完了を現用系のマスタサーバ２０−１から通知された場合、管理装置５０は、障害が発生していない各スレーブサーバ４０から負荷の計測値を取得する。そして、各スレーブサーバ４０の負荷の計測値が所定の閾値を下回った場合、管理装置５０は、必要なソフトウェアのインストール等が行われた新たなスレーブサーバ４０の情報と共に、現用系のマスタサーバ２０−１にリバランス処理の開始を指示する。

なお、本実施形態において、現用系のマスタサーバ２０−１と、死活監視装置６０とは、別々の装置として説明するが、本発明はこれに限られず、現用系のマスタサーバ２０−１が死活監視装置６０の機能を有していてもよく、管理装置５０が死活監視装置６０の機能を有していてもよい。

［管理装置５０の構成］
図２は、管理装置５０の機能構成の一例を示すブロック図である。管理装置５０は、収集部５１、計測情報格納部５２、通信部５３、判定部５４、設定部５５、および閾値格納部５６を有する。

図３は、計測情報格納部５２に格納されるデータの構造の一例を示す。計測情報格納部５２には、例えば図３に示すように、複数のレコード５２４が格納される。それぞれのレコード５２４には、サーバＩＤ５２０、サーバ種別５２１、計測値５２２、および計測時刻５２３が含まれる。

サーバＩＤ５２０は、現用系のマスタサーバ２０−１および複数のスレーブサーバ４０−１〜ｎのそれぞれを識別する情報である。サーバ種別５２１は、サーバＩＤ５２０に対応するサーバが、マスタサーバ２０か、スレーブサーバ４０かを識別する情報である。計測値５２２は、サーバＩＤ５２０に対応するサーバの負荷を示す情報であり、例えば、ＣＰＵ使用率、メモリ使用率、および単位時間当たりのリクエスト処理件数等が含まれる。計測時刻５２３は、サーバＩＤ５２０に対応するサーバにおいて、計測値５２２が計測された時刻を示す。

図３には、「Ｓ００１」のサーバＩＤ５２０と、「マスタ」のサーバ種別５２１と、「９１％」のＣＰＵ利用率、「７２％」のメモリ使用率、および「１６件／秒」のリクエスト処理件数等を含む計測値５２２と、「１３：５６：１６」の計測時刻５２３とを含むレコード５２４が格納されている計測情報格納部５２が例示されている。

図４は、閾値格納部５６に格納されるデータの構造の一例を示す。閾値格納部５６には、例えば図４に示すように、計測値の種別を示す計測種別５６０に対応付けて、当該計測値が計測されるサーバの種別を示すサーバ種別５６１、および、当該計測値の閾値５６２が格納される。

図４には、「リクエスト処理件数」の計測種別５６０に対応付けて、「マスタ」のサーバ種別５６１、および、「１０件／秒」の閾値５６２が格納されている閾値格納部５６が例示されている。

図２に戻って説明を続ける。通信部５３は、現用系のマスタサーバ２０−１、待機系のマスタサーバ２０−２、それぞれの予備サーバ３１−１〜ｎ、それぞれのスレーブサーバ４０−１〜ｎ、および死活監視装置６０と、通信回線１１を介して通信する。

収集部５１は、判定部５４から現用系のマスタサーバ２０−１の計測情報の収集を指示された場合に、通信部５３に、現用系のマスタサーバ２０−１への計測情報の要求を送る。通信部５３は、通信回線１１を介して、現用系のマスタサーバ２０−１へ計測情報の要求を送信し、当該現用系のマスタサーバ２０−１から計測情報を受信して収集部５１へ送る。通信部５３から計測情報を受け取った場合、収集部５１は、受け取った計測情報に含まれている計測時刻毎にレコードを作成し、作成したレコードを計測情報格納部５２に格納する。

また、判定部５４からそれぞれのスレーブサーバ４０の計測情報の収集を指示された場合、収集部５１は、それぞれのスレーブサーバ４０への計測情報の要求を通信部５３へ送る。通信部５３は、通信回線１１を介して、それぞれのスレーブサーバ４０へ計測情報の要求を送信し、それぞれのスレーブサーバ４０から計測情報を受信して収集部５１へ送る。通信部５３から計測情報を受け取った場合、収集部５１は、受け取った計測情報に含まれている計測時刻毎にレコードを作成し、作成したレコードを計測情報格納部５２に格納する。

判定部５４は、通信部５３を介して、（フェイルオーバ実行直前までは待機系のマスタサーバ２０−２であった）現用系のマスタサーバ２０−１からフェイルオーバを実行した旨の通知を受けた場合に、予備サーバ３１を待機系のマスタサーバ２０−２として機能させるための設定を行う旨を設定部５５に指示する。そして、判定部５４は、所定の設定が行われた新たな待機系のマスタサーバ２０−２の情報を設定部５５から受け取る。また、判定部５４は、現用系のマスタサーバ２０−１の計測情報の収集を収集部５１に指示する。

次に、判定部５４は、閾値格納部５６を参照し、「マスタ」のサーバ種別に対応付けられている計測種別および閾値の情報を抽出する。図４の例では、判定部５４は、計測種別として「リクエスト処理件数」を、閾値として「１０件／秒」を、それぞれ抽出する。

次に、判定部５４は、計測情報格納部５２を参照して、「マスタ」のサーバ種別が含まれているレコードの中で、フェイルオーバを実行した旨の通知を受けた時点以降の計測時刻が含まれているレコードを特定する。そして、判定部５４は、閾値格納部５６から抽出した計測種別に該当する種別の負荷の計測値（図３の例では、「リクエスト処理件数」の「１６件／秒」）を、特定したレコードから抽出する。

次に、判定部５４は、抽出した負荷の計測値が、閾値格納部５６から抽出した閾値未満か否かを判定する。ここで、フェイルオーバ直後は、負荷が低く計測される可能性があるため、判定部５４は、フェイルオーバを実行した旨の通知を受けた時点から所定時間（例えば１秒）経過後の計測時刻が含まれるレコードから抽出した負荷の計測値を用いることが好ましい。

また、フェイルオーバ直後は、負荷が安定せず、計測される値も大きく変動する場合が多いため、判定部５４は、現在時刻から所定時間前（例えば数秒前）までの計測値を統計処理した値（例えば平均値）を、閾値格納部５６から抽出した閾値と比較することが好ましい。

そして、現用系のマスタサーバ２０−１の負荷の計測値が、閾値格納部５６から抽出した閾値未満となった場合、判定部５４は、通信部５３を介して、現用系のマスタサーバ２０−１に、新たな待機系のマスタサーバ２０−２の情報と共に、同期処理の開始を指示する。

また、通信部５３を介して死活監視装置６０から、いずれかのスレーブサーバ４０に障害が発生した旨の通知を受けた場合、判定部５４は、予備サーバ３１をスレーブサーバ４０として機能させるための設定を行う旨を設定部５５に指示する。そして、判定部５４は、所定の設定が行われた新たなスレーブサーバ４０の情報を設定部５５から受け取る。また、判定部５４は、通信部５３を介して、現用系のマスタサーバ２０−１からリカバリ処理の完了を通知されたか否かを判定する。

リカバリ処理の完了を通知された場合、判定部５４は、障害が発生していないそれぞれのスレーブサーバ４０の計測情報の収集を収集部５１に指示する。そして、判定部５４は、閾値格納部５６を参照し、「スレーブ」のサーバ種別に対応付けられている計測種別および閾値の情報を抽出する。図４の例では、判定部５４は、計測種別として「ＣＰＵ使用率」を、閾値として「６０％」を、それぞれ抽出する。

次に、判定部５４は、計測情報格納部５２を参照して、「スレーブ」のサーバ種別が含まれているレコードの中で、スレーブサーバ４０の障害発生の通知を受けた時点以降の計測時刻が含まれているレコードを特定する。そして、判定部５４は、閾値格納部５６から抽出した計測種別に該当する種別の負荷の計測値（図３の例では、「ＣＰＵ使用率」の「８６％」）を、サーバＩＤと共に、特定したレコードから抽出する。

次に、判定部５４は、サーバＩＤ毎に抽出した負荷の計測値に基づく値が、閾値格納部５６から抽出した閾値未満か否かを判定する。判定部５４は、例えば、サーバＩＤ毎に抽出した計測値を、障害が発生していない複数のスレーブサーバ４０について統計処理した値（例えば平均値）を算出し、算出した値が、閾値格納部５６から抽出した閾値未満か否かを判定する。また、他の例として、判定部５４は、例えば、サーバＩＤ毎に抽出した計測値の中の最大値が、閾値格納部５６から抽出した閾値未満か否かを判定するようにしてもよい。

なお、それぞれのスレーブサーバ４０の負荷の計測値は、瞬間的に大きく変動する場合があるため、判定部５４は、障害が発生していないそれぞれのスレーブサーバ４０について、所定時間（例えば１秒）毎の計測値の平均を算出し、算出した平均を、これらのスレーブサーバ４０についてさらに統計処理して閾値と比較したり、算出した平均の中の最大値と閾値とを比較するようにしてもよい。

そして、サーバＩＤ毎に抽出した計測値に基づく値が、閾値格納部５６から抽出した閾値未満となった場合、判定部５４は、通信部５３を介して、現用系のマスタサーバ２０−１に、新たなスレーブサーバ４０の情報と共に、リバランス処理の開始を指示する。

設定部５５は、予備サーバ３１を待機系のマスタサーバ２０−２として機能させるための設定を行う旨を判定部５４から指示された場合に、リソースプール３０として管理されている複数の予備サーバ３１の中の１台を選択する。

そして、設定部５５は、選択した予備サーバ３１に、待機系のマスタサーバ２０−２として機能するのに必要なソフトウェアのインストールやパラメータの設定等を、通信部５３を介して行う。そして、設定部５５は、所定の設定が行われた新たな待機系のマスタサーバ２０−２の情報を判定部５４に通知する。

また、予備サーバ３１をスレーブサーバ４０として機能させるための設定を行う旨を判定部５４から指示された場合、設定部５５は、リソースプール３０として管理されている複数の予備サーバ３１の中の１台を選択する。

そして、設定部５５は、選択した予備サーバ３１に、スレーブサーバ４０として機能するのに必要なソフトウェアのインストールやパラメータの設定等を、通信部５３を介して行う。そして、設定部５５は、所定の設定が行われた新たなスレーブサーバ４０の情報を判定部５４に通知する。

［管理装置５０の動作］
図５は、管理装置５０の動作の一例を示すフローチャートである。例えば、本フローチャートに示す処理の開始を入力装置を介して管理者から指示される等の所定のタイミングで、管理装置５０は、本フローチャートに示す動作を開始する。

まず、判定部５４は、通信回線１１および通信部５３を介して、（フェイルオーバ実行直前までは待機系のマスタサーバ２０−２であった）現用系のマスタサーバ２０−１からフェイルオーバを実行した旨の通知を受信したか否かを判定することにより、フェイルオーバが実行されたか否かを判定する（Ｓ１００）。

フェイルオーバが実行された場合（Ｓ１００：Ｙｅｓ）、判定部５４は、予備サーバ３１を待機系のマスタサーバ２０−２として機能させるための設定を行う旨を設定部５５に指示する。設定部５５は、リソースプール３０として管理されている複数の予備サーバ３１の中の１台を選択する。

そして、設定部５５は、通信回線１１および通信部５３を介して、選択した予備サーバ３１に、待機系のマスタサーバ２０−２として機能するのに必要なソフトウェアのインストールやパラメータの設定等の所定の設定を行う（Ｓ１０２）。そして、設定部５５は、所定の設定が行われた新たな待機系のマスタサーバ２０−２の情報を判定部５４に通知する。

次に、判定部５４は、閾値格納部５６を参照し、「マスタ」のサーバ種別に対応付けられている計測種別および閾値の情報を取得する（Ｓ１０４）。そして、判定部５４は、現用系のマスタサーバ２０−１の計測情報の収集を収集部５１に指示する。

収集部５１は、現用系となったマスタサーバ２０−１から計測情報を取得する（Ｓ１０６）。具体的には、収集部５１は、現用系のマスタサーバ２０−１への計測情報の要求を通信部５３へ送る。通信部５３は、通信回線１１を介して、現用系のマスタサーバ２０−１へ計測情報の要求を送信し、当該マスタサーバ２０−１から計測情報を受信して収集部５１へ送る。通信部５３から計測情報を受信した場合、収集部５１は、受信した計測情報に含まれている計測時刻毎にレコードを作成し、作成したレコードを計測情報格納部５２に格納する。

次に、判定部５４は、計測情報格納部５２を参照して、「マスタ」のサーバ種別が含まれているレコードの中で、フェイルオーバを実行した旨の通知を受けた時点以降の計測時刻が含まれているレコードを特定する。そして、判定部５４は、ステップＳ１０４で取得した計測種別に該当する種別の負荷の計測値を、特定したレコードから抽出する。

次に、判定部５４は、抽出した負荷の計測値が、閾値格納部５６から抽出した閾値未満か否かを判定する（Ｓ１０８）。ここで、判定部５４は、例えば、フェイルオーバを実行した旨の通知を受けた時点から所定時間経過後の計測時刻が含まれるレコードから抽出した計測値を、例えば所定時間分平均した値を負荷の計測値として、閾値格納部５６から抽出した閾値未満か否かを判定する。

負荷の計測値が、閾値格納部５６から抽出した閾値未満となった場合（Ｓ１０８：Ｙｅｓ）、判定部５４は、通信部５３に、新たな待機系のマスタサーバ２０−２の情報と共に、同期処理の開始指示を送る。通信部５３は、通信回線１１を介して、現用系のマスタサーバ２０−１に、新たな待機系のマスタサーバ２０−２の情報と共に、同期処理の開始を指示し（Ｓ１１０）、判定部５４は、再びステップＳ１００に示した処理を実行する。

負荷の計測値が、閾値格納部５６から抽出した閾値以上である場合（Ｓ１０８：Ｎｏ）、判定部５４は、フェイルオーバを実行した旨の通知を受けた時点から所定時間（例えば数分）が経過したか否かを判定する（Ｓ１１２）。所定時間が経過していない場合（Ｓ１１２：Ｎｏ）、収集部５１は、所定時間（例えば数秒）経過してから再びステップＳ１０６に示した処理を実行する。一方、所定時間が経過した場合（Ｓ１１２：Ｙｅｓ）、判定部５４は、管理装置５０に接続された表示装置等の出力装置を介して、サーバシステム１０の管理者にエラーを通知し（Ｓ１１４）、再びステップＳ１００に示した処理を実行する。

フェイルオーバが実行されていない場合（Ｓ１００：Ｎｏ）、判定部５４は、通信回線１１および通信部５３を介して死活監視装置６０から、いずれかのスレーブサーバ４０に障害が発生した旨の通知を受けたか否かを判定することにより、いずれかのスレーブサーバ４０に障害が発生したか否かを判定する（Ｓ１１６）。いずれのスレーブサーバ４０にも障害が発生していない場合（Ｓ１１６：Ｎｏ）、判定部５４は、再びステップＳ１００に示した処理を実行する。

いずれかのスレーブサーバ４０に障害が発生した場合（Ｓ１１６：Ｙｅｓ）、判定部５４は、予備サーバ３１をスレーブサーバ４０として機能させるための設定を行う旨を設定部５５に指示する。設定部５５は、リソースプール３０として管理されている複数の予備サーバ３１の中の１台を選択する。

そして、設定部５５は、通信回線１１および通信部５３を介して、選択した予備サーバ３１に、スレーブサーバ４０として機能するのに必要なソフトウェアのインストールやパラメータの設定等の所定の設定を行う（Ｓ１１８）。そして、設定部５５は、所定の設定が行われた新たなスレーブサーバ４０の情報を判定部５４に通知する。

次に、判定部５４は、通信部５３を介して、現用系のマスタサーバ２０−１からリカバリ処理の完了を通知されたか否かを判定することにより、リカバリ処理が完了したか否かを判定する（Ｓ１２０）。リカバリ処理が完了した場合（Ｓ１２０：Ｙｅｓ）、判定部５４は、閾値格納部５６を参照し、「スレーブ」のサーバ種別に対応付けられている計測種別および閾値の情報を取得する（Ｓ１２２）。

次に、判定部５４は、それぞれのスレーブサーバ４０の計測情報の収集を収集部５１に指示する。収集部５１は、それぞれのスレーブサーバ４０から計測情報を取得する（Ｓ１２４）。具体的には、収集部５１は、それぞれのスレーブサーバ４０への計測情報の要求を通信部５３へ送る。通信部５３は、通信回線１１を介して、それぞれのスレーブサーバ４０へ計測情報の要求を送信し、それぞれのスレーブサーバ４０から計測情報を受信して収集部５１へ送る。通信部５３から計測情報を受信した場合、収集部５１は、受信した計測情報に含まれている計測時刻毎にレコードを作成し、作成したレコードを計測情報格納部５２に格納する。

次に、判定部５４は、計測情報格納部５２を参照して、「スレーブ」のサーバ種別が含まれているレコードの中で、スレーブサーバ４０の障害発生の通知を受けた時点以降の計測時刻が含まれているレコードを特定する。そして、判定部５４は、閾値格納部５６から抽出した計測種別に該当する種別の負荷の計測値を、サーバＩＤと共に、特定したレコードから抽出する。

次に、判定部５４は、サーバＩＤ毎に抽出した負荷の計測値に基づく値が、閾値格納部５６から抽出した閾値未満か否かを判定する（Ｓ１２６）。ここで、判定部５４は、例えば、サーバＩＤ毎に抽出した計測値を、障害が発生していない複数のスレーブサーバ４０について統計処理した値を算出し、算出した値が、閾値格納部５６から抽出した閾値未満か否かを判定する。

負荷の計測値に基づく値が、閾値格納部５６から抽出した閾値未満となった場合（Ｓ１２６：Ｙｅｓ）、判定部５４は、新たなスレーブサーバ４０の情報と共に、通信部５３にリバランス処理の開始指示を送る。通信部５３は、通信回線１１を介して、現用系のマスタサーバ２０−１に、新たなスレーブサーバ４０の情報と共に、リバランス処理の開始を指示し（Ｓ１２８）、再びステップＳ１００に示した処理を実行する。

負荷の計測値に基づく値が、閾値格納部５６から抽出した閾値以上である場合（Ｓ１２６：Ｎｏ）、判定部５４は、リカバリ処理の完了が通知された時点から所定時間（例えば数分）が経過したか否かを判定する（Ｓ１３０）。所定時間が経過していない場合（Ｓ１３０：Ｎｏ）、収集部５１は、所定時間（例えば数秒）経過してから再びステップＳ１２４に示した処理を実行する。一方、所定時間が経過した場合（Ｓ１３０：Ｙｅｓ）、判定部５４は、管理装置５０に接続された表示装置等の出力装置を介して、サーバシステム１０の管理者にエラーを通知し（Ｓ１３２）、再びステップＳ１００に示した処理を実行する。

［管理装置５０のハードウェア構成］
図６は、管理装置５０の機能を実現するコンピュータ７０の構成の一例を示すハードウェア構成図である。コンピュータ７０は、ＣＰＵ（Central Processing Unit）７１、ＲＡＭ（Random Access Memory）７２、ＲＯＭ（Read Only Memory）７３、ＨＤＤ（Hard Disk Drive）７４、通信インターフェイス（Ｉ／Ｆ）７５、入出力インターフェイス（Ｉ／Ｆ）７６、およびメディアインターフェイス（Ｉ／Ｆ）７７を備える。

ＣＰＵ７１は、ＲＯＭ７３またはＨＤＤ７４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ７３は、コンピュータ７０の起動時にＣＰＵ７１によって実行されるブートプログラムや、コンピュータ７０のハードウェアに依存するプログラム等を格納する。

ＨＤＤ７４は、ＣＰＵ７１によって実行されるプログラムおよび当該プログラムによって使用されるデータ等を格納する。通信インターフェイス７５は、通信回線１１を介して他の機器からデータを受信してＣＰＵ７１へ送り、ＣＰＵ７１が生成したデータを、通信回線１１を介して他の機器へ送信する。

ＣＰＵ７１は、入出力インターフェイス７６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ７１は、入出力インターフェイス７６を介して、入力装置からデータを取得する。また、ＣＰＵ７１は、生成したデータを、入出力インターフェイス７６を介して出力装置へ出力する。

メディアインターフェイス７７は、記録媒体７８に格納されたプログラムまたはデータを読み取り、ＲＡＭ７２を介してＣＰＵ７１に提供する。ＣＰＵ７１は、当該プログラムを、メディアインターフェイス７７を介して記録媒体７８からＲＡＭ７２上にロードし、ロードしたプログラムを実行する。記録媒体７８は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

コンピュータ７０のＣＰＵ７１は、ＲＡＭ７２上にロードされたプログラムを実行することにより、収集部５１、計測情報格納部５２、通信部５３、判定部５４、設定部５５、および閾値格納部５６の各機能を実現する。また、ＨＤＤ７４には、計測情報格納部５２および閾値格納部５６内のデータが格納される。なお、計測情報格納部５２および閾値格納部５６内のデータは、通信回線１１に接続された他の装置に格納されていてもよい。

コンピュータ７０のＣＰＵ７１は、これらのプログラムを、記録媒体７８から読み取って実行するが、他の例として、他の装置から、通信回線１１を介してこれらのプログラムを取得してもよい。

以上、本発明の実施の形態について説明した。

上記説明から明らかなように、本実施形態のサーバシステム１０によれば、サービスを安定して提供することができる。

なお、上記した実施形態において、現用系および待機系のマスタサーバ２０を、それぞれ１つの装置として説明したが、本発明はこれに限られず、各マスタサーバ２０に含まれるそれぞれの機能を、２つ以上の装置にそれぞれ分散配置させ、これらの装置が、通信回線１１を介して互いに通信データをやり取りすることにより協調動作して、全体として各マスタサーバ２０の機能を実現するように構成してもよい。各スレーブサーバ４０についても同様である。

また、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に多様な変更または改良を加えることが可能であることが当業者には明らかである。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

２０ マスタサーバ
３１ 予備サーバ
４０ スレーブサーバ
５０ 管理装置
５１ 収集部
５４ 判定部

Claims (7)

1. 現用系サーバと、待機系サーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置であって、
   前記現用系サーバに障害が発生し、前記待機系サーバがフェイルオーバして新たな現用系サーバとなった場合に、当該新たな現用系サーバの負荷を示す計測値を収集する収集部と、
   前記収集部によって収集された前記計測値が所定の閾値を下回った場合に、前記新たな現用系サーバに、前記予備サーバとの間でのデータの同期処理の開始を指示して、当該予備サーバを新たな待機系サーバに移行させる判定部と、
   を備えることを特徴とする管理装置。
2. 複数のスレーブサーバと、それぞれのスレーブサーバが保持するデータを管理するマスタサーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置であって、
   前記複数のスレーブサーバのいずれかに障害が発生した後に、当該障害が発生した前記スレーブサーバが保持しているデータと同一のデータを、当該スレーブサーバ以外の他のスレーブサーバに分散配置させるリカバリ処理が完了したか否かを判定し、当該リカバリ処理が完了した後に、前記予備サーバを新たなスレーブサーバとして、障害が発生していない複数のスレーブサーバのそれぞれが保持しているデータの量を調整するリバランス処理の開始を前記マスタサーバに指示する判定部
   を備えることを特徴とする管理装置。
3. 前記複数のスレーブサーバのいずれかに障害が発生した後に、当該スレーブサーバ以外の他のスレーブサーバの負荷を示す計測値を収集する収集部
   をさらに備え、
   前記判定部は、
   前記リカバリ処理が完了した後に、障害が発生したスレーブサーバ以外の他のスレーブサーバの前記計測値が所定の閾値を下回った場合に、前記リバランス処理の開始を前記マスタサーバに指示することを特徴とする請求項２に記載の管理装置。
4. 前記判定部は、
   前記リカバリ処理が完了した後に、障害が発生したスレーブサーバ以外の他のスレーブサーバの前記計測値の平均が、前記所定の閾値を下回った場合に、前記リバランス処理の開始を前記マスタサーバに指示することを特徴とする請求項３に記載の管理装置。
5. 前記判定部は、
   前記リカバリ処理が完了した後に、障害が発生したスレーブサーバ以外の他のスレーブサーバの前記計測値の中で、最大の前記計測値が、前記所定の閾値を下回った場合に、前記リバランス処理の開始を前記マスタサーバに指示することを特徴とする請求項３に記載の管理装置。
6. 現用系サーバと、待機系サーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置によって実行される管理方法であって、
   前記現用系サーバに障害が発生し、前記待機系サーバがフェイルオーバして新たな現用系サーバとなった場合に、当該新たな現用系サーバの負荷を示す計測値を収集する収集工程と、
   前記収集工程において収集した前記計測値が所定の閾値を下回ったか否かを判定する工程と、
   前記収集工程において収集した前記計測値が前記所定の閾値を下回ったと判定した場合に、前記新たな現用系サーバに、前記予備サーバとの間でのデータの同期処理の開始を指示して、当該予備サーバを新たな待機系サーバに移行させる工程と、
   を含むことを特徴とする管理方法。
7. 複数のスレーブサーバと、それぞれのスレーブサーバが保持するデータを管理するマスタサーバと、リソースプール内の予備サーバとを備えるサーバシステムを管理する管理装置によって実行される管理方法であって、
   前記複数のスレーブサーバのいずれかに障害が発生した後に、当該障害が発生した前記スレーブサーバが保持しているデータと同一のデータを、当該スレーブサーバ以外の他のスレーブサーバに分散配置させるリカバリ処理が完了したか否かを判定する工程と、
   前記リカバリ処理が完了したと判定した後に、前記予備サーバを新たなスレーブサーバとして、障害が発生していない複数のスレーブサーバのそれぞれが保持しているデータの量を調整するリバランス処理の開始を前記マスタサーバに指示する工程と、
   を含むことを特徴とする管理方法。

Images