JP5282569B2 - 管理装置、管理システム、管理方法及び管理プログラム - Google Patents

Description

本発明は、複数のサーバを管理するサーバ管理装置及びサーバ管理プログラムに関し、特に、複数のサーバの内、待機中のサーバに対して動作確認を行うためのサーバ管理装置及びサーバ管理プログラムに関する。

サーバを用いたサービスの提供においては、実際にサービスを提供するために稼働しているサーバ（以下稼働サーバという。）に種々の要因による異常が発生した場合、そのサービスが停止してしまうおそれがある。そのような異常発生時に、稼働サーバは異常信号を発信することで待機中のサーバ（以下待機サーバという。）を稼働サーバと置換し、サービスの停止を避ける運用が一般的である。

（発明が解決しようとする課題）
従来技術では、予備サーバは常に起動している必要があった。異常発生時に素早いサーバの置換を可能とすることでサービスの停止時間を短縮するためである。

しかし、近年のサーバシステムの大規模化に伴い、稼動サーバ数は増加し、それに伴い待機サーバの数も増加している。すなわち、複数のサービスが存在するシステムにおいては、複数の稼動サーバが存在し、当該稼動サーバに対応する待機サーバが存在することとなる。

したがって、複数の待機サーバは、サービスの提供等を行っていないにも関わらずサーバ自身で電力を消費し、また、サーバを冷却するため電力も消費しており、無駄であった。

一方、消費電力の低減のために待機サーバの電源をオフにしている場合では、稼動サーバに異常が発生した場合に、サーバ置換に多大な時間を要することとなり、サービスの低下となっていた。また、待機サーバの電源をオフにした状態では、待機サーバに異常が発生していても不明であり、稼動サーバの異常発生時にサーバ置換をなしえない問題もあった。
（課題を解決するための手段）
本発明は、サーバが電源断か否かの状態を管理するテーブル、前記テーブルに電源断状態のサーバがある場合に該サーバに対して電源Ｏｎを指示する指示手段、前記サーバから電源Ｏｎステータス信号を確認した場合に、電源Ｏｆｆを指示する指示手段、として機能させる。

また、電源Ｏｆｆの指示は前記サーバに対して行う。

また、前記テーブルは更に、稼動中のサーバか否かの状態を管理し、電源Ｏｆｆの指示は他のサーバで、稼動中状態ではなく、かつ、電源断状態でもないサーバに対して行う。

また、前記サーバから異常状態のステータス信号を受信した場合は、異常状態の旨を出力する出力手段を更に有する。

また、電源Ｏｎの指示は一定時間毎に行う。
（発明の効果）
以上により、電源断状態のサーバに対して電源投入が可能であり、かつ、待機中のサーバの数も保つことが出来るため、消費電力の低減、かつ、システムの安全性の確保をすることが可能となる。

図１は、システム構成図である。 図２は、実施例１におけるサーバ管理ＤＢ３０のデータ構成図である。 図３は、実施例１における待機サーバ特定のフローチャートである。 図４は、実施例１における待機サーバの移行指示のフローチャートである。 図５は、実施例１におけるサーバの待機サーバ移行処理のフローチャートである。 図６は、実施例１における電源断サーバ特定のフローチャートである。 図７は、実施例１における電源断サーバの移行指示のフローチャートである。 図８は、実施例１におけるサーバの電源断サーバ移行処理のフローチャートである。 図９は、実施例２におけるサーバ管理ＤＢ３０のデータ構成を示した図である。 図１０は、実施例２における確認フラグ３６を用いた場合の電源断サーバの確認方式のフローチャートである。 図１１は、実施例３におけるサーバ管理ＤＢ３０のデータ構成を示した図である。 図１２は、実施例３による各サーバの電源確認方式のフローチャートである。 図１３は、実施例４における時間管理ＤＢ４０のデータ構成図である。 図１４は、実施例４における時間によるサーバ状態遷移のフローチャートである。 図１５は、ハードウェア構成図である。

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

図１は、本発明のサーバ管理システムのシステム構成図を示した図である。

サーバ０１乃至サーバｘｘは、サーバ管理システムで管理する対象となるサーバであり、それぞれ、リカバリ機能、故障検知機能を有する。また、各サーバは、電源が落ちている状態であるサーバ（以下、電源断サーバという）、待機中の状態である待機サーバ、稼動中の状態である稼動サーバとする状態を有する。

サーバ０１乃至サーバｘｘは、管理サーバ１０からの指示により、電源断サーバ、待機サーバ、稼動サーバとして機能が遷移する。

電源断サーバは、電源Ｏｎの受信、ハードウェア確認、ネットワーク接続確認を経て待機サーバの状態となる。

待機サーバは、サービスを実行するためのプログラム、データをコピーされることにより稼動サーバの状態となる。

電源断サーバは、電源Ｏｎの受信、ハードウェア確認、ネットワーク接続確認、サービスのためのプログラム、データをコピーという作業を行い稼動サーバの状態となる。

稼動サーバは、待機サーバとして機能するプログラム、データをコピーされることにより待機サーバの状態となる。

稼動サーバおよび待機サーバは、電源断の指示を受信すると電源をＯｆｆにし、電源断サーバの状態となる。

待機サーバは、サービスを実行するする情報を有する必要はないが、稼動サーバとしての動作が可能である保証をする必要がある。

電源断サーバは動作保証を得るため、ホコリ混入による故障回避のためなどを理由に定期的に動かすことも必要である。

管理サーバ１０は、サーバ０１乃至サーバｘｘを管理するサーバである。

管理クライアント２０は、管理者が管理サーバ１０を操作したい場合に使用するクライアント端末である。

サーバ管理ＤＢ（データベース）３０は、サーバ０１乃至サーバｘｘの状態を管理するデータベースである。

時間管理ＤＢ４０は、稼動させるサーバ台数を予め設定する時間に応じて変化させる場合に使用するデータベースである。

管理サーバ１０は、管理クライアント２０、サーバ０１乃至サーバｘｘ、サーバ管理ＤＢ３０および時間管理ＤＢ（データベース）４０とネットワークを介して接続している。

管理サーバ１０が各サーバの状態を確認する方法は、管理サーバ１０が各サーバに対しステータス取得依頼を指示する方法で可能である。また、各サーバがサーバが有する状態情報を管理サーバ１０に出力する方法によっても可能である。状態の確認は、例えば一定時間毎に行う。

ここで、待機サーバと稼動サーバとの切替について簡単に説明する。

管理サーバ１０は、管理対象の各サーバ０１乃至ｘｘの状態を取得する。稼動サーバの異常状態を検知すると、稼動サーバを待機サーバに変更すると共に待機サーバを稼動サーバとする指示を出力する。この場合、システムを構成する他の機器が、ネットワーク情報に基づき判別した場合に、異常を検出した稼動サーバと稼動サーバに変更する待機サーバとが同じサーバとなるように設定を切り替える。以上の処理を行うことで、サービスの停止期間を最小限にとどめることが出来る。

また、稼動サーバの故障を修正後、稼動サーバとして元に戻すことも可能であるし、稼動サーバと待機サーバは代わったままでも可能である。
（実施例１）
次に、実施例１におけるサーバ管理ＤＢ３０のデータ構成について説明する。

図２は、実施例１におけるサーバ管理ＤＢ３０のデータ構成を示した図である。

実施例１におけるサーバ管理ＤＢ３０は、サーバＩＤ３１、ステータス３２、サービス３３、電源断時刻３４、動作開始時刻３５から構成される。サーバＩＤ３１は、サーバ０１乃至サーバｘｘに付された識別子である。本実施例におけるシステムでは、サーバの識別子を０１から順にｘｘまで設定してあるものとしている。ステータス３２はサーバの状態を記憶したものである。管理サーバ１０は定期的、あるいは特定のイベント毎にサーバのステータスを取得しステータス３２に記憶する。サービス３３は、稼動サーバが行っているサービスの種類を記憶したものである。本実施例は、サービスＡとサービスＢの２種類のサービスが存在するシステムである。電源断時刻３４は、電源断サーバが電源断の状態となった時刻を記憶したものである。動作開始時刻３５は、待機サーバとなった時刻を記憶したものである。

以降、管理サーバ１０が電源断サーバを待機サーバに状態遷移させる処理、待機サーバを電源断サーバに状態遷移させる処理について説明する。

図３は、待機サーバ特定のフローチャートである。

管理サーバ１０は、サーバ管理ＤＢ３０を参照し、ステータス３２が「電源断」であるサーバ３１のリストを抽出する（Ｓ３０１）。 次に、Ｓ３０１で抽出したサーバ３１のリストに対応する電源断時刻３４が最古のデータレコードを選択し、選択したサーバを待機サーバに変更するサーバとして特定する（Ｓ３０２）。

管理サーバ１０は、電源断サーバ群の中から待機サーバにする電源断サーバを特定すると、当該電源断サーバを待機サーバにする処理を行う。

図４は、管理サーバ１０が、電源断サーバから待機サーバへの移行指示を行った際の処理についてのフローチャートである。

管理サーバ１０は、Ｓ３０２で特定したサーバ（特定サーバ）に対して電源Ｏｎの指示を送信する（Ｓ４０１）。

管理サーバ１０は、特定サーバから起動完了の情報を受信したか否かを判断する（Ｓ４０２）。

特定サーバから起動完了の情報を受信していない場合（Ｓ４０２：Ｎｏ）、予め設定した一定時間経過したか否かを判断する（Ｓ４０３）。一定時間を経過していない場合（Ｓ４０３：Ｎｏ）、引き続き特定サーバからの起動完了情報を待つ。一方、一定時間経過した場合（Ｓ４０３：Ｙｅｓ）、特定サーバのハードの故障、管理サーバ１０と特定サーバまでのネットワークの故障の可能性があるため、エラー情報を出力する（Ｓ４０６）。

特定サーバから起動完了の情報を受信した場合（Ｓ４０２：Ｙｅｓ）、管理サーバ１０は、特定サーバに対し現在の状態を取得するための情報取得指示を送信する（Ｓ４０４）。

サーバの状態には、正常、警告、エラーおよび無反応の種類があるものとする。正常とは、異常なく起動していることを示す。警告とは、特定サーバ内において何れかのポートが壊れている等、特定サーバの故障箇所を特定サーバ自身で検知できる場合である。エラーとは、ハード的な故障が発生している状態であり、特定サーバの故障箇所を特定サーバ自身で検知できない状態である。また、無反応とは、起動完了を受信したが、ステータスの取得依頼に対しては応答が無い状態であり、ネットワークを介しての通信が確立していない状態である。

管理サーバ１０は、特定サーバからの状態を取得（Ｓ４０５）し、状態が「正常」であった場合（Ｓ４０５：Ｙｅｓ）は、電源断サーバから待機サーバへの以降が正常に完了したこととなり、サーバ管理ＤＢ３０の情報を更新する（Ｓ４０７）。具体的には、サーバ管理ＤＢ３０の特定サーバに該当するサーバＩＤ３１のデータレコードを検索し、ステータス３２を「電源断」から「待機」に更新し、電源断時刻３４の情報を削除し、動作開始時刻３５に現在の時刻を記憶する。

一方、状態が「正常」以外の状態であった場合（Ｓ４０５：Ｎｏ）、特定サーバに何らかの問題があるとして、エラー情報の出力を行う（Ｓ４０６）。

次に、特定サーバが行う、電源断サーバから待機サーバへの移行処理について説明する。

図５は、特定サーバの待機サーバ移行処理のフローチャートである。管理サーバ１０から起動指示を受信する（Ｓ５０１）と、特定サーバは起動処理を開始する。特定サーバは起動処理を行い（Ｓ５０２）、起動した場合は（Ｓ５０２：Ｙｅｓ）、起動完了情報を管理サーバ１０に送信する（Ｓ５０３）。

次に、特定サーバは、管理サーバ１０からステータス取得依頼を受信する（Ｓ５０４）と、ステータス情報を返信する（Ｓ５０５）。

なお、この特定サーバが正常に動作したか否かを確認するためには、予め定めた所定時間待つこととしてもよい。例えば、起動直後は動作したが、しばらくすると異常が発生する場合が考えられる。したがって、例えば１５分間程度待機させ、当該特定サーバが正常に動作している場合にのみ、正常に動作していると判定することも可能である。この判断は、Ｓ４０５において、管理サーバ１０が行うことで可能である。

特定サーバが正常に動作したことを確認すると、管理サーバ１０は、現在の待機サーバの内の何れかについて電源を落とす処理を行う。

図６は、電源断サーバ特定のフローチャートである。

管理サーバ１０は、サーバ管理ＤＢ３０を参照し、ステータス３２が「待機」であるサーバ３１のリストを抽出する（Ｓ６０１）。 次に、Ｓ６０１で抽出したサーバ３１のリストに対応する動作開始時刻３５が最古のデータレコードを選択し、選択したサーバを待機サーバに変更するサーバとして特定する（Ｓ６０２）。なお、ここで特定されたサーバを第二特定サーバとする。

図７は、管理サーバ１０が、第二特定サーバに対し、待機サーバから電源断サーバへの移行指示の処理についてのフローチャートである。

管理サーバ１０は、Ｓ６０２で第二特定サーバに対して電源断の指示を送信する（Ｓ７０１）。

管理サーバ１０は、第二特定サーバから電源断完了の情報を受信したか否かを判断する（Ｓ７０２）。

第二特定サーバから電源断完了の情報を受信していない場合（Ｓ７０２：Ｎｏ）、予め設定した一定時間経過したか否かを判断する（Ｓ７０３）。一定時間を経過していない場合（Ｓ７０３：Ｎｏ）、引き続き第二特定サーバからの電源断完了情報を待つ。一方、一定時間経過した場合（Ｓ７０３：Ｙｅｓ）、第二特定サーバのハードの故障、管理サーバ１０と特定サーバまでのネットワークの故障の可能性があるため、エラー情報を出力する（Ｓ７０４）。

第二特定サーバから電源断完了の情報を受信した場合（Ｓ７０２：Ｙｅｓ）、サーバ管理ＤＢ３０の情報を更新する（Ｓ７０５）。具体的には、サーバ管理ＤＢ３０の第二特定サーバに該当するサーバＩＤ３１のデータレコードを検索し、ステータス３２を「待機」から「電源断」に更新し、電源断時刻３４に現在の時刻を記憶し、動作開始時刻３５の情報を削除する。

次に、第二特定サーバが行う、待機サーバから電源断サーバへの移行処理について説明する。

図８は、第二特定サーバの電源断サーバ移行処理のフローチャートである。管理サーバ１０から電源断指示を受信する（Ｓ９０１）と、第二特定サーバは電源断処理を開始する。第二特定サーバは電源断処理を行い（Ｓ９０２）、電源断が完了した場合は（Ｓ９０２：Ｙｅｓ）、電源断完了情報を管理サーバ１０に送信する（Ｓ９０３）。
（実施例２）
次に、電源断サーバの動作確認をする別の実施例について説明する。

本実施例は、テーブルを用いて、特定時刻になった場合に、電源断サーバを順次電源Ｏｎと電源Ｏｆｆの処理を行うことで、電源断サーバの動作確認を行う方式である。

図９は、実施例２におけるサーバ管理ＤＢ３０のデータ構成を示した図である。

実施例２のサーバ管理ＤＢ３０は、サーバＩＤ３１、ステータス３２、確認フラグ３６からなる構成となっている。

サーバＩＤ３１とステータス３２は、実施例１と同内容であるので、説明を省略する。

確認フラグ３６は、ステータス３２が電源断の状態であるサーバに対して付される情報である。電源断サーバに対して、初期値として「０」が付されており、電源Ｏｎの確認が行われた場合には「１」が付さる。

図１０は、確認フラグ３６を用いた場合の電源断サーバの確認方式のフローチャートである。

管理サーバ１０は、予め設定した時間に毎に本フローチャートを実行する。

管理サーバ１０はサーバ管理ＤＢ３０の確認フラグ３６を初期化する（ｓ１００１）。この初期化は、サーバＩＤ３１に対応するステータス３２に基づき、ステータス３２が「稼動」又は「待機」の状態である場合には、動作チェック対象から外すべく確認フラグ３６には値を入力せず、一方、ステータス３２が「電源断」の状態である場合は、フラグの初期値として「０」を設定する。

管理サーバ１０は、確認フラグ３６で設定された全てのフラグが「０」以外になるまで、（ｓ１００２：Ｙｅｓ）、Ｓ１００３以降の処理を行う（Ｓ１００２：Ｎｏ）。

管理サーバ１０は、確認フラグ３６が「０」であるサーバＩＤ３１に対して以下の処理を行う。

管理サーバ１０は、サーバＩＤ３１に対応する電源断サーバに電源Ｏｎの指示を発行する（ｓ１００３）。

電源Ｏｎの処理は実施例１の図４と同様の処理を行う。なお、図４の特定サーバは、本実施例では、ｓ１００３の電源断サーバを意味する。ただし、Ｓ４０７におけるサーバＤＢの更新にあっては、確認フラグ３６を「１」に設定する処理を行い、Ｓ４０６におけるエラー情報の送信にあっては、確認フラグ３６を「０」、「１」以外の値に設定する処理を行う。

エラーが発生した場合（ｓ１００４：Ｙｅｓ）管理サーバ１０は、対象となる次のサーバを抽出する。

一方、エラーが発生しなかった場合（ｓ１００４：Ｎｏ）、すなわち電源Ｏｎの確認が出来たサーバに対しては、電源断の処理を行う（ｓ１００５）。電源断の処理は実施例１における図７と同様の処理によって可能である。なお、図７における特定したサーバは、電源Ｏｎを確認したサーバとなる。

電源断を確認した場合には、確認フラグ３６が「０」である次のサーバについて同様の処理を行う。

上記処理により、全ての確認フラグ３６が「０」以外になった場合に今回の動作確認は終了となる。

上記処理により、一定期間毎の動作チェック時にサーバの電源を同時に起動させることなく、また、各サーバの動作状況を正確に把握可能となる。
（実施例３）
次に、電源断サーバの動作確認をする別の実施例について説明する。

例えば、管理サーバ１０によるサーバの動作確認処理が独立した処理として動作するシステムにおいては、管理サーバ１０のアクセスがあってから対象のサーバについて電源Ｏｎの指示がなされたとしても、当該サーバは起動のための時間を必要とする。その結果、管理サーバ１０の動作確認の待ち時間に間に合わない不具合が生じる。このようなシステムの場合には、各電源断サーバの電源を管理サーバ１０による動作確認処理の直前に電源をＯｎとし、管理サーバ１０による動作確認後に電源をＯｆｆとすれば上記の問題を解決することができる。

本実施例においても、サーバ管理ＤＢ３０の構成を変更する。

図１１は、実施例３におけるサーバ管理ＤＢ３０のデータ構成を示した図である。

実施例３のサーバ管理ＤＢ３０は、サーバＩＤ３１、ステータス３２、起動フラグ３７、起動時間３８からなる構成となっている。

サーバＩＤ３１とステータス３２は、実施例１と同内容であるので、説明を省略する。

起動フラグ３７は、電源断の状態のサーバに対して、電源Ｏｎの指示を行うか否かを示す情報であり、「０」の場合は、サーバ管理ＤＢ３０のステータス３２が電源断の状態で、かつ、管理サーバ１０が電源Ｏｎの指示も与えていない状態を示し、「１」の場合は、サーバ管理ＤＢ３０のステータス３２が電源断の状態で、かつ管理サーバ１０が電源Ｏｎの指示を与えている状態、すなわちサーバが起動中である状態を示す。起動が完了した場合には「２」とする。また、その他の値は、故障中、あるいは、稼動中、待機中等の状態を示す。

起動時間３８は、サーバＩＤ３１に対応する各サーバのそれぞれについて、電源断から正常に起動が完了するまでに要する時間を予め記憶した値である。

管理サーバ１０は、動作確認を行う時刻を予め入手する。

また、管理サーバ１０は、起動フラグ３７の値について、ステータス３２が「電源断」のサーバについて「０」と設定し、他の状態のサーバについては「０」以外の値を設定する。

以降の処理は管理サーバ１０が行う処理であり、管理サーバ１０による各サーバに対しての動作確認処理前に繰り返し行われる処理である。

図１２は、実施例３による各サーバの電源確認方式のフローチャートである。

管理サーバ１０は、現在時刻を取得する（ｓ１２０１）。

管理サーバ１０は、動作確認時刻と現在時刻との差分から、動作確認時間までの残時間を算出する（ｓ１２０２）。

管理サーバ１０は起動フラグ３７を確認し、起動フラグ３７が「０」であるレコードを抽出する（ｓ１２０３）。

ここで、データレコードが存在しない場合（ｓ１２０４：ｎｏ）、すなわち、全てのサーバが電源断サーバではない場合は以降の処理は不要であるため、処理を終了する。

一方、抽出したデータレコードが存在する場合（ｓ１２０４：ｙｅｓ）は、以下の処理を行う。

管理サーバ１０は、データレコードが抽出できた場合は、管理サーバ１０は、残時間と抽出したレコードに対応する起動時間３８とを比較する（ｓ１２０５）。

ここで、全てのデータレコードの起動時間３８が残時間よりも短い場合（ｓ１２０６：Ｙｅｓ）には、以降の処理は不要であるため、処理は終了する。

一方、起動時間３８が残時間以上の場合（ｓ１２０６：Ｎｏ）には、電源Ｏｎの指示と共に起動フラグ３７を起動中である「１」にする（ｓ１２０７）。これにより、次回の起動前確認においては、フラグ値が「０」ではないため、チェック対象から排除されることとなる。

そして、当該起動時間３８に対応するサーバに対して電源Ｏｎの処理（ｓ１２０８）を実行する。

サーバの電源Ｏｎについての処理は、実施例１における図４の処理と同様である。なお、図４の特定サーバは、本実施例では、ｓ１２０８の電源断サーバを意味する。

ただし、Ｓ４０７のサーバ管理ＤＢ３０の更新時には、起動フラグ３７を起動中を示す「１」から起動完了を示す「２」の値にする。

上記、起動時間３８の方が、残時間よりも短いデータレコードを有する全てのサーバについて電源Ｏｎの指示が完了した場合（ｓ１２０９：Ｙｅｓ）には、本処理は終了する。

上記図１２に係る処理を動作確認開始直前まで行う。

管理サーバ１０は、動作確認を行う時刻が経過すると、管理対象のサーバについて動作確認を行う。その後、起動フラグ３７が「２」である全てのサーバに対して、電源断の処理を行う。

以上の処理により、本来、電源を継続して入れておく必要がないサーバについては、短い時間の電源Ｏｎで動作確認が可能となる。

また、上記例では特定の時間にまとめてサーバの動作確認を行う方式について記載したが、各サーバ個別に動作確認の時刻を定めておいた場合にも応用は可能である。この場合には、各サーバについて動作確認の時刻を設定しておき、当該時刻と現在時刻との差分から残時間を算出し、各データレコードの起動時間３８との比較を行うことにより実現可能である。
（実施例４）
図１３は、時間管理ＤＢ４０のデータ構成を示した図である。

時間管理ＤＢ４０は、時間４１、待機サーバ数４２、稼動サーバ数サービスＡ４３、稼動サーバ数サービスＢ４４とから構成される。時間４１は、２４時間を３時間毎に区切り表示したものである。３時間毎に区切るのは、単なる例示であり、日単位、週単位、分単位、等、適宜設定可能である。待機サーバ数４２は、時間４１に対応して設定する待機サーバの数である。待機サーバ数についても管理者が予め任意に設定可能である。稼動サーバ数サービスＡ４３および稼動サーバ数サービスＢ４４は、サービスＡとサービスＢについて時間４１に対応して稼動させる稼動サーバの数である。

なお、稼動サーバ数サービスＡ４３及び稼動サーバ数サービスＢ４４は２つの項目となっているが、本実施例がサービスＡとサービスＢの２種類のサービスが存在するシステムであるためであり、サービス数が増加すれば項目数も増加する。

図１４は、時間によるサーバ状態遷移のフローチャートである。

まず、管理サーバ１０は、現在時刻に対応する時間管理ＤＢ４０の時間４１を抽出する（Ｓ１４０１）。

管理サーバ１０は、時間４１に対応する待機サーバ数４２、サービスＡに対応する稼動サーバ数４３、サービスＢに対応する稼動サーバ数４４を読込む（Ｓ１４０２）。

管理サーバ１０は、システム上で現在稼動中の各サービスＡ，Ｂに対応するサービスをするサーバ数をサーバ管理ＤＢ２０のサービス３３、およびステータス３２から読込む（Ｓ１４０３）。

Ｓ１４０２で読み込んだ台数とＳ１４０３で読み込んだの台数が異なるか否かを判定する（Ｓ１４０４）。

異なる場合は（Ｓ１４０４：Ｙｅｓ）、サーバ台数の調整を行う（Ｓ１４０５）。サーバ台数の調整は、例えば稼働時間の長い稼動サーバを電源断とする方法、あるいは、サーバ処理能力が低いサーバを電源断とする方法などがある。電源断サーバを待機サーバ、稼動サーバに設定する。待機サーバを優先して稼動サーバに切り替える。などの種々の判断が可能である。これらの判断定義については、予め定義しておく。

管理サーバ１０は、サービス毎の混雑度を監視し、上記のような稼動サーバ、待機サーバ、電源断サーバの状態遷移を動的に行うことも可能である。

次に時間に応じて、稼動サーバの数、及び待機サーバの数を動的に変化させるシステムの場合について説明する。

一般にサーバシステムは、処理するサーバ台数が多ければ処理速度が早くなる。したがって、負荷の状況に応じて待機サーバを稼動サーバに変更することが可能である。また、複数のサービスが並行して行われるサーバシステムでは、サービスＡの負荷は軽く、サービスＢの負荷が重い場合、処理が流れているサービスＡについては、稼動サーバの台数を減らし、待機サーバとなったサーバをサービスＢを処理する稼動サーバとして切り替えて処理することで、効率的なサーバの運用が可能となる。

上記の状態に対応するため、管理者は時間管理ＤＢ４０を予め設定し、時間毎の稼動サーバの数、待機サーバの数を定義する。当該時間に対応して稼動サーバ及び待機サーバを起動することも可能である。

図１５は、ハードウェア構成図である。

図１５は、上記のサーバ管理システム、管理サーバ１０、管理クライアント２０、サーバ０１乃至サーバｘｘのハードウェア構成の一例を示す図である。

同図に示すサーバ及びクライアントは、ＣＰＵ１１、メモリ１２、入力手段１３、出力手段１４、記憶手段１５、ネットワーク接続手段１６等を有し、これらがバス１７に接続された構成となっている。なお、同図に示した構成は一例であり、これに限るものではない。

ＣＰＵ１１は、当該サーバ及びクライアントコンピュータ全体を制御する中央処理装置である。

メモリ１２は、プログラム実行、データ更新等の際に、記憶手段１５に記憶されているプログラムやデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１１は、メモリ１２に読み出したプログラムやデータを用いて、上述の図３乃至図１２等を用いて説明したサーバ管理動作に係る処理を含む各種処理を実行する。

入力手段１３は、例えばキーボード、マウス、タッチパネル等である。

出力手段１４は、例えばディスプレイ（表示装置）等である。

記憶手段１５は、例えばハードディスク装置等であり、プログラム（上述のサーバ管理動作に係る処理をコンピュータに実行させるプログラムを含む）やデータ（上述のサーバ管理ＤＢ３０、時間管理ＤＢ４０を含む）が格納される。

ネットワーク接続装置１７は、ネットワーク（インターネット等）に接続して、外部の情報処理装置とプログラムやデータの送受信を可能にする構成である。

また、上記プログラムを記録した記録媒体又はプログラムのダウンロードのも可能である。

上記の各種処理を実行させるプログラムやデータ読み出してメモリ１２に格納し実行するものであってもよいし、また、上記プログラムやデータは、ネットワーク接続装置１７により接続されているネットワーク（インターネット等）を介して、外部のプログラムやサーバに記憶されているプログラムやデータをダウンロードするものであってもよい。

なお、本サーバ管理システムで管理するサーバは、ネットワーク経由での電源投入、及び電源断が可能であるサーバである。さらに、当該サーバに節電機能がある場合には待機サーバから電源断サーバへの状態遷移については、節電機能による電源断によっても実現可能である。ここで節電機能とは、メモリの状態等、運用状態を保持したまま電源を停止できる機能であり、電源を投入すると、サーバが節電機能により電源断となった時の状態を即時に再現可能となる機能である。

以上、本発明について詳細に説明したが、本発明は上記実施形態に限定されず、本発明の要旨を逸脱しない範囲において、各種の改良及び変更を行っても良いのはもちろんである。

発明は、消費電力の低減、かつ、システムの安全性の確保が出来るサーバ管理を提供できる。

符号の説明

１０ 管理サーバ１０
２０ 管理クライアント
３０ サーバ管理ＤＢ３０
４０ 時間管理ＤＢ

Claims (6)

1. 第１の期間に第１のコンピュータの状態情報を返信させる指示を前記第１のコンピュータに行ない、前記第１の期間と重複しない第２の期間に第２のコンピュータの状態情報を返信させる指示を前記第２のコンピュータに対して行なう指示手段と、
   前記第１の期間を除く期間すべてにおいて前記第１のコンピュータを電源断にさせる制御と、前記第２の期間を除く期間すべてにおいて前記第２のコンピュータを電源断にさせる制御と、を行なう制御手段と、
   を含むことを特徴とする管理装置。
2. 前記制御手段が、さらに、
   前記第１のコンピュータ及び前記第２のコンピュータを含むコンピュータ群に含まれる各コンピュータについて、前記各コンピュータを電源断にさせる制御を行なうとともに、前記コンピュータ群に含まれるコンピュータのうち、同時に電源断にされない状態のコンピュータを所定数以下に制限する、
   ことを特徴とする請求項１に記載の管理装置。
3. 前記第１のコンピュータの状態情報に基づいて、前記第１のコンピュータの状態を監視し、前記第２のコンピュータの状態情報に基づいて、前記第２のコンピュータの状態を監視する監視手段、
   をさらに含むことを特徴とする請求項１または請求項２に記載の管理装置。
4. 第１のコンピュータと、
   第２のコンピュータと、
   管理装置と、を含む管理システムであって、
   前記管理装置は、
   第１の期間に第１のコンピュータの状態情報を返信させる指示を前記第１のコンピュータに行ない、前記第１の期間と重複しない第２の期間に第２のコンピュータの状態情報を返信させる指示を前記第２のコンピュータに対して行なう指示手段と、
   前記第１の期間を除く期間すべてにおいて前記第１のコンピュータを電源断にさせる制御と、前記第２の期間を除く期間すべてにおいて前記第２のコンピュータを電源断にさせる制御と、を行なう制御手段と、
   を含むことを特徴とする管理システム。
5. 少なくとも第１のコンピュータおよび第２のコンピュータを管理するコンピュータに、
   第１の期間に前記第１のコンピュータの状態情報を返信させる指示を前記第１のコンピュータに行ない、前記第１の期間と重複しない第２の期間に前記第２のコンピュータの状態情報を返信させる指示を前記第２のコンピュータに対して行ない、
   前記第１の期間を除く期間すべてにおいて前記第１のコンピュータを電源断にさせる制御と、前記第２の期間を除く期間すべてにおいて前記第２のコンピュータを電源断にさせる制御と、を行なう、
   ことを実行させることを特徴とする管理方法。
6. 少なくとも第１のコンピュータおよび第２のコンピュータを管理するコンピュータに、
   第１の期間に第１のコンピュータの状態情報を返信させる指示を前記第１のコンピュータに行ない、前記第１の期間と重複しない第２の期間に第２のコンピュータの状態情報を返信させる指示を前記第２のコンピュータに対して行ない、
   前記第１の期間を除く期間すべてにおいて前記第１のコンピュータを電源断にさせる制御と、前記第２の期間を除く期間すべてにおいて前記第２のコンピュータを電源断にさせる制御と、を行なう、
   ことを実行させることを特徴とする管理プログラム。