(57)【要約】【課題】サーバの再起動のためにそのサーバを含むシステム全体の処理が停止する時間を低減する。【解決手段】管理システム１００は、第１管理サーバ１０２と、第２管理サーバ１０４と、を含む。２つの管理サーバ１０２、１０４は、一方が他方のバックアップに設定される。２つの管理サーバ１０２、１０４は、定期的にそのバックアップ関係が入れ替えられる。この際、２つの管理サーバ１０２、１０４のバックアップ関係が入れ替えられた後、新たにバックアップする側に設定された管理サーバが再起動される。管理システム１００は運用テーブル１２０に規定される運用のスケジュールにしたがって運用される。２つの管理サーバ１０２、１０４のバックアップ関係の入替がこのスケジュール通りに行われたか否かが判別される。【選択図】図１
2011138455.tif 000002
【特許請求の範囲】
【請求項１】
一方が他方のバックアップに設定される２つのサーバと、
前記２つのサーバの関係を入れ替える際、前記２つのサーバのうちバックアップに設定されている一方のサーバをバックアップされるサーバに設定し、その設定の後他方のサーバを再起動する制御部と、を備えることを特徴とするクラスタシステム。
【請求項２】
前記他方のサーバは、少なくとも前記制御部によって再起動された後、前記一方のサーバのバックアップに設定された状態となることを特徴とする請求項１に記載のクラスタシステム。
【請求項３】
前記制御部は、定期的に前記２つのサーバの関係を入れ替えることを特徴とする請求項１または２に記載のクラスタシステム。
【請求項４】
前記制御部は、サーバの再起動に必要な時間とバックアップされるサーバをバックアップするサーバに切り替えるために必要な時間との和よりも長い周期で定期的に前記２つのサーバの関係を入れ替えることを特徴とする請求項３に記載のクラスタシステム。
【請求項５】
前記制御部は、前記一方のサーバに含まれる第１制御部と前記他方のサーバに含まれる第２制御部とを含み、
前記第２制御部は前記一方のサーバをバックアップされるサーバに設定し、
前記第１制御部は、前記第２制御部によって前記一方のサーバがバックアップされるサーバに設定された後、前記他方のサーバを再起動することを特徴とする請求項１から４のいずれかに記載のクラスタシステム。
【請求項６】
運用のスケジュールを記憶する運用テーブルと、
前記２つのサーバによって共用される記憶装置と、をさらに備え、
前記第２制御部は、前記一方のサーバをバックアップされるサーバに設定した日時を示す情報を前記記憶装置に記憶させ、
前記第１制御部は、前記記憶装置に前記情報を検出すると、その情報に示される日時および前記運用テーブルを参照して、運用のスケジュールに沿って前記一方のサーバがバックアップされるサーバに設定されたか否かを判別することを特徴とする請求項５に記載のクラスタシステム。
【請求項７】
一方が他方のバックアップに設定される２つのサーバを管理するクラスタ管理方法であって、
前記２つのサーバの関係を入れ替える際、前記２つのサーバのうちバックアップに設定されている一方のサーバをバックアップされるサーバに設定するステップと、
前記一方のサーバをバックアップされるサーバに設定した後他方のサーバを再起動するステップと、を含むことを特徴とするクラスタ管理方法。
【請求項８】
一方が他方のバックアップに設定される２つのサーバに、
前記２つのサーバの関係を入れ替える際、前記２つのサーバのうちバックアップに設定されている一方のサーバをバックアップされるサーバに設定する機能と、
前記一方のサーバをバックアップされるサーバに設定した後他方のサーバを再起動する機能と、を実現させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタシステムおよびクラスタ管理方法に関する。
【背景技術】
【０００２】
多くの企業は会計処理などのバッチ処理を行うために、サーバを多数備えたデータセンタを保有し運用している。またはその運用を別の運用管理会社に任せている。
このようなデータセンタには、万が一サーバに障害が発生した場合に備えていわゆるクラスタ方式を採用しているものがある。このクラスタ方式では、サーバを冗長化することでことで可用性を高めている（例えば、特許文献１参照）。
【０００３】
また、サーバを再起動すると再起動前と比べてフリーズの可能性を低減でき、また処理速度を高く保つことができることが経験的に知られている。したがって、データセンタのサーバも再起動することが好ましい。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２３０１７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながらサーバの再起動には一般的に時間がかかる。近年のサーバの性能向上に伴い、それを初期化したりシャットダウンしたりするために必要な時間、つまり再起動にかかる時間もまた長くなっている。
データセンタのサーバを再起動すると再起動が完了するまでそこで処理が停止しうる。サーバの数が増え、またサーバ間の関係が複雑になるほど、この処理が停止する時間も長くなりうる。これはデータ処理の観点から非効率的である。
【０００６】
本発明はこうした課題に鑑みてなされたものであり、その目的は、サーバの再起動のために処理が停止する時間を低減したクラスタシステムの提供にある。
【課題を解決するための手段】
【０００７】
本発明のある態様はクラスタシステムに関する。このクラスタシステムは、一方が他方のバックアップに設定される２つのサーバと、２つのサーバの関係を入れ替える際、２つのサーバのうちバックアップに設定されている一方のサーバをバックアップされるサーバに設定し、その設定の後他方のサーバを再起動する制御部と、を備える。
【０００８】
「再起動する」とは、サーバをシャットダウンした直後に初期化することであってもよい。また、リセットすることであってもよい。また、単に初期化することであってもよい。
この態様によると、他方のサーバの再起動中は一方のサーバによって処理を遂行できる。
【０００９】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、サーバの再起動のためにそのサーバを含むシステムの処理が停止する時間を低減できる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態に係る管理システムを含むバッチ処理システムを示す概略図である。
【図２】図１の管理システムの機能および構成を示すブロック図である。
【図３】図２の運用テーブルを示すデータ構造図である。
【図４】図２の入替ファイルを示すデータ構造図である。
【図５】入替異常警告画面の代表画面図である。
【図６】再起動異常警告画面の代表画面図である。
【図７】図２の第１管理サーバおよび第２管理サーバにおける一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１３】
実施の形態に係る管理システムは同等な機能、構成を有する２つの管理サーバを備える。通常では一方の管理サーバは他方の管理サーバをバックアップする。ここで、管理サーバを再起動すべき頻度に合わせて２つの管理サーバのバックアップ関係が入れ替えられ、その直後に新たにバックアップとなった側の管理サーバが再起動される。これにより、管理システム全体で見たときは、常にバックアップする側の管理サーバが再起動されることとなり、再起動によって管理システム全体の処理が停止する時間を低減できる。このように実施の形態では、クラスタシステムを障害発生時以外にも再起動のために有効に使用している。
【００１４】
図１は、実施の形態に係る管理システム１００を含むバッチ処理システム１０を示す概略図である。バッチ処理システム１０は、ユーザ企業の日々の活動において発生する会計処理などの業務をバッチ処理する。
バッチ処理システム１０は、実施の形態に係る管理システム１００と、４つの管理対象サーバ２０ａ〜２０ｄと、を備える。管理システム１００は、第１管理サーバ１０２と、第２管理サーバ１０４と、ＮＡＳ（Network Attached Storage）１０６と、を含む。
管理システム１００は、４つの管理対象サーバ２０ａ〜２０ｄのそれぞれにジョブを振り分けたり４つの管理対象サーバ２０ａ〜２０ｄの状態を監視・設定するなどして、４つの管理対象サーバ２０ａ〜２０ｄを管理する。個々の管理対象サーバ２０ａ〜２０ｄはバッチ処理においてジョブを実際に処理するサーバである。
【００１５】
第１管理サーバ１０２、第２管理サーバ１０４、ＮＡＳ（Network Attached Storage）１０６、および４つの管理対象サーバ２０ａ〜２０ｄは、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットなどのネットワークを通じて互いに接続されている。
【００１６】
管理システム１００はいわゆるアクティブ−スタンバイ型のクラスタ方式を採用している。つまり第１管理サーバ１０２および第２管理サーバ１０４は同等の機能、構成を有し、一方が実際に４つの管理対象サーバ２０ａ〜２０ｄを管理し、他方が一方のバックアップに設定され待機する。以下、実際に４つの管理対象サーバ２０ａ〜２０ｄを管理する方の管理サーバを正系の管理サーバと呼び、そのバックアップに設定され待機するサーバを副系の管理サーバと呼ぶ。この管理システム１００では、通常運用中は正系のサーバが４つの管理対象サーバ２０ａ〜２０ｄを管理し副系のサーバは正系のサーバをバックアップしつつ待機する。そして運用中に正系のサーバに障害が生じた場合、副系を起動してサーバ管理を引き継がせる。これによりサーバ障害によるバッチ処理システム１０の停止時間を最小限にとどめて可用性を高めている。
【００１７】
ここで管理サーバをバックアップに設定する、とは実際にその管理サーバがバックアップとして機能していることを必要としない。例えば、管理サーバのレジストリにその管理サーバがバックアップであることを示す情報が記憶されることをもってその管理サーバがバックアップに設定されるとしてもよい。
【００１８】
管理システム１００は、運用のスケジュールにしたがって自身と４つの管理対象サーバ２０ａ〜２０ｄとを管理する。この運用のスケジュールは、例えば各サーバをいつどのような状態に設定するかという情報やジョブの順番、ジョブの優先順位などであり、運用テーブル１２０（後述する）に記憶される。
ＮＡＳ１０６は、ネットワークに接続されたファイルサーバであり、第１管理サーバ１０２および第２管理サーバ１０４によって共用される。ＮＡＳ１０６は運用テーブル１２０を記憶する。
【００１９】
管理システム１００では、定期的に２つの管理サーバ１０２、１０４の正副が入れ替えられる。管理システム１００はこの入れ替えの後、新たに副系に設定されるべき管理サーバを再起動する。つまり、管理システム１００は少なくとも、２つの管理サーバ１０２、１０４の関係を入れ替える際、２つの管理サーバ１０２、１０４のうちバックアップに設定されている一方の管理サーバをバックアップされる管理サーバに設定し、その設定の後他方の管理サーバを再起動する。
【００２０】
なお、バックアップ関係の入替と管理サーバの再起動とを一連の処理（以下、入替・再起動処理と呼ぶ）として行うことを可能とするため、管理システム１００におけるバックアップ関係の入替の周期Ｔは、管理サーバの再起動に必要な時間と正系の管理サーバを副系の管理サーバに切り替えるために必要な時間との和よりも長く設定される。特にこの周期Ｔは管理サーバの機種毎に推奨される再起動の周期の２分の１程度に設定される。
【００２１】
図２は、管理システム１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００２２】
第１管理サーバ１０２は、正系制御部１０８ａと、副系制御部１１０ａと、を含む。第２管理サーバ１０４は、正系制御部１０８ａと同等の正系制御部１０８ｂと、副系制御部１１０ａと同等の副系制御部１１０ｂと、を含む。
ＮＡＳ１０６は、運用テーブル１２０を含み、場合によっては入替ファイル１２２を含む。以下、第１管理サーバ１０２が正系、第２管理サーバ１０４が副系という状態から、第１管理サーバ１０２が副系、第２管理サーバ１０４が正系という状態に切り替える場合の各部の処理について説明する。その逆の場合における各部の処理は、以下の説明を読んだ当業者には自明であるので省略する。
【００２３】
正系制御部１０８ａは、処理開始部１１２と、状態確認部１１４と、正副入替部１１６と、入替情報生成部１１８と、を含む。
処理開始部１１２は、運用テーブル１２０を参照し、入替・再起動処理を行うべき日時が到来したか否かを判別する。運用テーブル１２０は、上述の周期Ｔで現れる入替・再起動処理を指示するエントリを有する。処理開始部１１２はこのエントリに含まれる、入替・再起動処理を行うべき日時と現在の日時とを比較し、一致すると状態確認部１１４に処理の開始を通知する。
【００２４】
状態確認部１１４は、処理開始部１１２によって処理の開始が通知されると、第２管理サーバ１０４の状態を確認する。状態確認部１１４は第２管理サーバ１０４が副系の管理サーバとして正常に動作していれば、正副入替部１１６に入替を行うよう通知する。そうでなければ状態確認部１１４は入替・再起動処理を異常終了させる。
【００２５】
正副入替部１１６は、状態確認部１１４から入替を行うよう通知を受けると、２つの管理サーバ１０２、１０４の正副を入れ替える。正副入替部１１６は、自己が属する第１管理サーバ１０２を副系に設定すると共に、第２管理サーバ１０４を正系に設定する。正副入替部１１６は自己が属する第１管理サーバ１０２が正常に副系に切り替わると、入替の正常終了を入替情報生成部１１８に通知する。
入替情報生成部１１８は、正副入替部１１６から入替の正常終了が通知されると、その入替が行われた入替日時を含む入替ファイル１２２をＮＡＳ１０６に生成する。
【００２６】
副系制御部１１０ｂは、入替情報検出部１２４と、運用判別部１２６と、再起動部１２８と、開始指示部１３２と、警告部１３４と、を含む。
入替情報検出部１２４は、自己が属する第２管理サーバ１０４が第１管理サーバ１０２の正副入替部１１６によって正系に設定されると、ＮＡＳ１０６にアクセスし入替ファイル１２２の存否を調べる。入替情報検出部１２４は、ＮＡＳ１０６に入替ファイル１２２を検出すると、入替ファイル１２２に含まれる入替日時を読み出し、その後入替ファイル１２２を削除する。入替情報検出部１２４は読み出された入替日時を運用判別部１２６に渡す。
【００２７】
入替情報検出部１２４は、自己が属する第２管理サーバ１０４が第１管理サーバ１０２の正副入替部１１６によって正系に設定されてから所定の第１検出時間内にＮＡＳ１０６に入替ファイル１２２を検出しない場合、入替・再起動処理を異常終了し、その旨を警告部１３４に通知する。この第１検出時間は、正系制御部１０８ａにおいて第１管理サーバ１０２を正系から副系に切り替えるために必要な時間よりも長く設定される。
【００２８】
運用判別部１２６は、入替情報検出部１２４から渡された入替日時と運用テーブル１２０とを参照して、運用のスケジュールに沿って入替が行われたか否かを判別する。つまり運用判別部１２６は、運用テーブル１２０に含まれる入替・再起動処理を指示するエントリのなかに、渡された入替日時に対応するエントリがあるかどうかを調べる。そのようなエントリがあれば、運用判別部１２６は再起動部１２８および開始指示部１３２に後続の処理を行うよう指示を出す。そのようなエントリが見つからない場合は、運用判別部１２６は入替・再起動処理を異常終了し、その旨を警告部１３４に通知する。
【００２９】
再起動部１２８は、運用判別部１２６から指示を受けると、第１管理サーバ１０２を再起動させる。再起動部１２８は第１管理サーバ１０２の再起動の成否を監視する。再起動の開始後所定の第２検出時間内に第１管理サーバ１０２から再起動の完了を知らせる信号を受信しないなど、第１管理サーバ１０２の再起動が失敗したと考えられる状態を検出すると、再起動部１２８は再起動が失敗した可能性が有ることを示す情報を警告部１３４に通知する。この第２検出時間は、管理サーバの再起動のために必要な時間よりも長く設定される。
【００３０】
警告部１３４は、入替情報検出部１２４または運用判別部１２６から入替・再起動処理の異常終了が通知されると、正副入替処理の過程で何らかの異常があった可能性があることを示す入替異常警告画面１４６（図５で後述）を、図示しない表示制御部を介してディスプレイ１３０に表示させる。また、警告部１３４は、再起動部１２８から再起動が失敗した可能性が有ることを示す情報が通知されると、再起動処理の過程で何らかの異常があった可能性があることを示す再起動異常警告画面１４８（図６で後述）を、図示しない表示制御部を介してディスプレイ１３０に表示させる。
【００３１】
開始指示部１３２は、運用判別部１２６から指示を受けると、第２管理サーバ１０４に４つの管理対象サーバ２０ａ〜２０ｄの管理を開始させる。
【００３２】
図３は、運用テーブル１２０を示すデータ構造図である。運用テーブル１２０は、日時１４０と、その日時１４０に実行されるべきジョブ１４２とを対応付けて記憶する。ジョブ１４２のうち入替・再起動処理は周期Ｔ、ここでは５日間隔、で現れる。日時１４０の代わりに先行するジョブの正常終了をキーとしてもよい。あるいはまた両者の組み合わせであってもよい。
【００３３】
図４は、入替ファイル１２２を示すデータ構造図である。入替ファイル１２２は、正副の入替が行われた入替日時１４４を含む。
【００３４】
図５は、入替異常警告画面１４６の代表画面図である。入替異常警告画面１４６は、入替情報検出部１２４で入替・再起動処理が異常終了された場合に対応するタイムアウト領域１５０と、運用判別部１２６で入替・再起動処理が異常終了された場合に対応するスケジュールエラー領域１５２と、を有する。図５では、タイムアウトエラー、つまり入替情報検出部１２４が第１検出時間内に入替ファイル１２２を検出しなかった場合が示される。
【００３５】
図６は、再起動異常警告画面１４８の代表画面図である。再起動異常警告画面１４８は、対応選択領域１５４と、実行ボタン１５６と、を有する。対応選択領域１５４には、再起動が第２検出時間以上かかっていることに対して管理者側が取り得る対応の選択肢が示される。この選択肢は、入替・再起動処理を異常終了することと、もう少し待つことと、再度再起動を試みることと、を含む。実行ボタン１５６は、押し下げられると、対応選択領域１５４で選択された対応を開始させる。
【００３６】
図７は、第１管理サーバ１０２および第２管理サーバ１０４における一連の処理を示すフローチャートである。ここでは第１管理サーバ１０２が正系、第２管理サーバ１０４が副系という状態から、第１管理サーバ１０２が副系、第２管理サーバ１０４が正系という状態に切り替える場合について説明する。
【００３７】
第１管理サーバ１０２の処理開始部１１２は、運用テーブル１２０を参照する（Ｓ２０２）。現在の日時が入替・再起動処理を行うべき日時でない場合（Ｓ２０４のＮ）、しばらく置いて再度運用テーブル１２０を参照する。入替・再起動処理を行うべき日時が到来すると（Ｓ２０４のＹ）、状態確認部１１４は副系の管理サーバ（第２管理サーバ１０４）の状態を確認する（Ｓ２０６）。正副入替部１１６は、２つの管理サーバ１０２、１０４の正副を入れ替える（Ｓ２０８）。第１管理サーバ１０２が正常に副系に切り替えられた後、入替情報生成部１１８はＮＡＳ１０６に入替ファイル１２２を生成する（Ｓ２１０）。一方第２管理サーバ１０４では、第２管理サーバ１０４が正系に切り替えられた後、入替情報検出部１２４はＮＡＳ１０６にアクセスし入替ファイル１２２の存否を調べる（Ｓ２１２）。ＮＡＳ１０６に入替ファイル１２２が検出されなかった場合（Ｓ２１４のＮ）、入替情報検出部１２４はしばらく置いて再度ＮＡＳ１０６にアクセスする。ＮＡＳ１０６に入替ファイル１２２が検出された場合（Ｓ２１４のＹ）、つまり第１管理サーバ１０２が正常に副系に切り替わった後、運用判別部１２６は正副入替が運用のスケジュール通りに行われたか否かを判別する（Ｓ２１６）。それがスケジュール通りである場合、再起動部１２８は第１管理サーバ１０２を再起動する（Ｓ２１８）。なお、再起動後の第１管理サーバ１０２は、次の入替・再起動処理まで副系の管理サーバとなる。
【００３８】
以上の構成によるバッチ処理システム１０の動作を説明する。ユーザ企業の日々の活動により会計処理などの業務が発生する。バッチ処理システム１０は例えば夜間などにこの業務をバッチ処理する。ここで、バッチ処理システム１０の管理システム１００は２つのクラスタリングされた管理サーバ１０２、１０４でこのバッチ処理を管理する。管理システム１００では定期的に正副が入れ替えられ、また入替の際それまで正系であった管理サーバを再起動する。したがって管理を継続しつつ各管理サーバを定期的に再起動できる。
【００３９】
上述の実施の形態において、ＮＡＳ１０６の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００４０】
本実施の形態に係る管理システム１００によると、正副入替の際、それまで副系であった管理サーバを正系に設定した後に正系であった管理サーバを再起動する。したがって、再起動中も新しく正系に設定された管理サーバで管理を継続できる。これにより管理サーバを再起動する際に再起動にかかる時間だけバッチ処理システム１０の管理を止めなくてもよいので、再起動に伴うバッチ処理システム１０の停止時間を低減することができる。
【００４１】
サーバに使用されるハードディスクドライブ、メモリなどのハードウエアコンポーネントは近年その耐久性が向上しているとはいえ、やはり経年劣化や突発的な事故による寿命がある。そこで、本実施の形態に係る管理システム１００では、入替後新たに副系に設定された管理サーバはその再起動後も副系の管理サーバとして機能する。したがって、入替の周期Ｔよりも長いタイムスパンで見ると、第１管理サーバ１０２が正系である期間と第２管理サーバ１０４が正系である期間とはほぼ等しくなる。その結果、第１管理サーバ１０２および第２管理サーバ１０４で使用されているハードウエアコンポーネントの寿命を均等にできる。
【００４２】
一般的なアクティブ−スタンバイ方式のクラスタシステムにおいては、正系に設定されたサーバは障害が起こるまでは正系のままである。したがって、そのサーバにおけるハードウエアコンポーネントはバックアップ側のサーバのそれよりも早く寿命がくる可能性がある。すると結果的に正系のサーバに障害が発生する頻度が高くなり、その分システム全体が停止する時間も長くなりえる。これに対して本実施の形態に係る管理システム１００では２つの管理サーバ１０２、１０４におけるハードウエアコンポーネントの寿命を均等にできるので、管理システム１００を停止しなければならない頻度は相対的に低くなる。
【００４３】
また、本実施の形態に係る管理システム１００では、定期的に入替・再起動処理を行う。したがって、個々の管理サーバは定期的に再起動されるので高いパフォーマンスを維持できる。また、各管理サーバが正系として動作するか否かを定期的に確認できる。
【００４４】
また、本実施の形態に係る管理システム１００では、正副入替の際、正系であった第１管理サーバ１０２が副系に正常に切り替わった後、それを知らせる入替ファイル１２２をＮＡＳ１０６に置く。また、新たに正系に切り替わった第２管理サーバ１０４がその入替ファイル１２２の検出を契機として、第１管理サーバ１０２を再起動する。したがって、新たに正系に切り替わった第２管理サーバ１０４は入替ファイル１２２の存否によって正系であった第１管理サーバ１０２が正常に副系に切り替わったか否かを知ることができる。また第１管理サーバ１０２が副系に切り替わっている途中に再起動される状況を防ぎ、第１管理サーバ１０２の再起動が副系への切替後に行われることを確実にすることができる。
【００４５】
また、本実施の形態に係る管理システム１００では、正副入替の入替日時と運用テーブル１２０とを参照して、運用のスケジュールに沿って入替が行われたか否かを判別する。したがって、運用のスケジュールに沿ったバッチ処理システム１０の運用が可能となり、また、意図せず行われた入替を検出することができる。
【００４６】
以上、実施の形態に係る管理システム１００の構成と動作について説明した。これらの実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００４７】
実施の形態では、第１管理サーバ１０２が正系、第２管理サーバ１０４が副系という状態から、第１管理サーバ１０２が副系、第２管理サーバ１０４が正系という状態に切り替える場合の各部の処理について説明された。この場合、第１管理サーバ１０２の正系制御部１０８ａおよび第２管理サーバ１０４の副系制御部１１０ｂを合わせて管理システム１００に含まれるひとつの制御部と見なせる。
【００４８】
実施の形態では、第１管理サーバ１０２が正系の場合は第２管理サーバ１０４がそれをバックアップする副系となるいわゆるアクティブ−スタンバイ方式を採用する場合について説明したが、これに限られない。例えば実施の形態に係る技術思想は、管理システムの２つの管理サーバが両方とも４つの管理対象サーバ２０ａ〜２０ｄの管理に関与するいわゆるアクティブ−アクティブ方式のクラスタシステムに適用されてもよい。
【００４９】
実施の形態では、管理システム１００が４つの管理対象サーバ２０ａ〜２０ｄを管理する場合について説明したが、管理対象サーバの数に制限はない。
【００５０】
実施の形態では、管理サーバをクラスタリングする場合について説明したが、これに限られない。例えば、管理対象サーバをクラスタリングし、それに実施の形態に係る技術思想を適用してもよい。この場合、管理対象サーバの入替・再起動を行う制御部は管理サーバに含まれてもよい。
なお一般に管理対象サーバに障害が起こってもバッチ処理システム１０全体の処理は止まらないが管理サーバに障害が起こるとバッチ処理システム１０全体の処理が停止しうるので、実施の形態のように管理サーバ側で入替・再起動処理ができると好ましい。
【００５１】
実施の形態では、正副入替して新たに副系となった管理サーバを再起動した後、その管理サーバを副系のままとする場合について説明したが、これに限られない。新たに正系となった管理サーバの性能が不十分である場合などは、副系制御部は再起動の後再度正副入替を行ってもよい。この場合、より性能の高い管理サーバを正系として使い続けることができる。
【００５２】
実施の形態では、正副入替を行った後に再起動する場合について説明したが、これに限られない。例えば、入替の際、副系であった管理サーバを正系に設定した後にもう一方の管理サーバを再起動すればよい。言い換えると、正系であったサーバは再起動前に副系に設定されなくてもよい。
【００５３】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【符号の説明】
【００５４】
１０  バッチ処理システム、  １００  管理システム、  １０２  第１管理サーバ、  １０４  第２管理サーバ、  １０６  ＮＡＳ、  １０８  正系制御部、  １１０  副系制御部、  １１２  処理開始部、  １１４  状態確認部、  １１６  正副入替部、  １１８  入替情報生成部、  １２０  運用テーブル、  １２２  入替ファイル、  １２４  入替情報検出部、  １２６  運用判別部、  １２８  再起動部、  １３２  開始指示部、  １３４  警告部。
【図１】
2011138455.tif 000003
【図２】
2011138455.tif 000004
【図３】
2011138455.tif 000005
【図４】
2011138455.tif 000006
【図５】
2011138455.tif 000007
【図６】
2011138455.tif 000008
【図７】
2011138455.tif 000009