JP2008009622A - 管理サーバ、およびサーバシステム - Google Patents

Abstract

【課題】バッチ処理に対応できる信頼性を有し運用の煩雑さを隠蔽できるサーバシステムを低コストで提供する。
【解決手段】複数のサーバを管理する管理サーバが、バッチ処理対象のジョブネットを実行する第一のサーバの未割り当ての第二のサーバを複数のサーバの中から動的に選択し、選択した第二のサーバに、第一のサーバに関する環境であるサーバ環境を設定させ、第一のサーバと、サーバ環境が設定された第二のサーバに、それぞれ、ジョブネットを構成する各ジョブを実行させ、第一のサーバと第二のサーバからそれぞれジョブネットの実行終了通知を受けた場合に、第二のサーバを解放する。
【選択図】図１

Description

本発明は、サーバシステムに関し、特に、オープン系のサーバシステムに関する。

例えば、低コスト化を目的として、メインフレーム系のサーバシステム（以下、メインフレームサーバシステム）で所定の業務を実行することを、オープン系のサーバシステム（以下、オープンサーバシステム）でその業務を実行することの移行が進んでいる。

オープンサーバシステムは、オープンサーバの台数を増やすことで拡張できるが、オープンサーバシステムの構成要素である各サーバ（以下、オープンサーバ）は、低コストのため、拡張を低コストで行えるという特徴がある。そのため、オープンサーバシステムは、例えば、多数の要求（例えば、多数のトランザクション処理或いは多数のリクエスト）が発生するＷＥＢサーバシステムで適用される。また、ＷＥＢサーバシステムでは、一要求当たりの処理量が少なく、そのため処理時間が短く済み、サーバシステムの障害時の影響範囲が小さいことや、回復処理技術が確立していることもあり、ＷＥＢサーバシステムにおいて、オープンサーバシステムの信頼性は大きな問題にはならない。

しかし、夜間バッチのような、処理時間が何時間にもおよぶバッチ処理の場合には、処理時間が長い上、多量のデータを処理するため、サーバシステムの障害の影響範囲が大きい。また、通常、バッチ処理では、所定時刻（例えば、翌日の午前○時）までに終了しなければならない等の、実行時における制約が厳しい。

そのため、オープンサーバシステムでバッチ処理を実行する場合には、その信頼性（例えば、ハードウェア及び／又はソフトウェアの信頼性）を高める必要がある。オープンサーバシステムの高信頼化のアプローチとしては、以下の２つ、
（１）プロセッサやパスなどのハードウェアを多重化する方法（例えば特許文献１及び２）、
（２）サーバを複数台備え、それら複数台のサーバにリクエストを発行する方法（例えば、特許文献３及び４）、
を挙げることができる。

特開２００６−１１５７６号公報 特開２００２−２４４８７９号公報 特開２００４−８０２４０号公報 特開平８−１６１１８８号公報

上記（１）の方法によれば、多重化のために専用のハードウェアを開発する必要がある。そのため、高いコストがかかってしまう。

一方、上記（２）の方法によれば、コスト高を抑えることができるが、リクエスト発行側に複数台のサーバが見えてしまうので、実際の運用が煩雑になってしまう。

従って、本発明の目的は、バッチ処理に対応できる信頼性を有し運用の煩雑さを隠蔽できるサーバシステムを低コストで提供することにある。

本発明に従う管理サーバは、複数のサーバと前記複数のサーバを管理する管理サーバとを備えるサーバシステムの前記管理サーバであって、第二サーバ選択部、サーバ環境設定部、ジョブネット実行部及びサーバ解放部を備える。第二サーバ選択部は、バッチ処理の対象である一以上のジョブから成るジョブネットを実行させる際に、前記ジョブネットを実行する第一のサーバを含んだ前記複数のサーバの中から、未割り当ての第二のサーバを選択する。サーバ環境設定部は、前記選択した第二のサーバに、前記第一のサーバに関する環境であるサーバ環境を設定させる。ジョブネット実行部は、前記第一のサーバと、前記サーバ環境が設定された第二のサーバに、それぞれ、前記ジョブネットを構成する各ジョブを実行させる。サーバ解放部は、前記第一のサーバと前記第二のサーバからそれぞれ前記ジョブネットの実行終了通知を受けた場合に、前記第二のサーバを解放する。第二のサーバの解放では、例えば、そのサーバから、設定されたサーバ環境を破棄させる。

第一の実施態様では、管理サーバが、各サーバのリソースに関する情報と各サーバの割り当てに関する状態とを含んだサーバ管理情報を記憶するサーバ管理記憶部（例えばメモリ領域）と、前記ジョブネットの実行に必要なリソースに関する情報を含んだジョブ定義情報を記憶するジョブ定義記憶部（例えばメモリ領域）とを更に備える。前記第二サーバ選択部は、前記サーバ管理情報と前記ジョブ定義情報とを参照することにより、前記ジョブネットの実行に必要なリソースを有する未割り当てのサーバを選択する。

第二の実施態様では、前記第一の実施態様において、前記ジョブ定義情報は、前記ジョブネットについての多重度も含んでおり、前記第二選択部は、前記多重度と同数のサーバを第二サーバとして選択する。

第三の実施態様では、前記サーバ環境の設定の際、前記第一のサーバも前記第二のサーバも起動しておらず、前記サーバ環境には、ジョブネットの実行環境が含まれている。前記サーバ環境設定部は、前記第二のサーバを起動した後、前記第二のサーバに設定される、前記第一のサーバと同じ実行環境と異なる実行環境を、該第二のサーバに設定し、その後で、前記第一のサーバを起動する。

第四の実施態様では、前記第三の実施態様において、前記複数のサーバ及び前記管理サーバは、インターネットプロトコルの通信ネットワークに接続され、前記実行環境は、ＩＰアドレスである。

第五の実施態様では、前記第三の実施態様において、前記サーバシステムには、前記複数のサーバ及び前記管理サーバに通信可能に接続されたストレージシステムが含まれている。前記ストレージシステムには、複数の記憶装置とコントローラとが備えられ、前記複数の記憶装置には、前記第一のサーバの前記サーバ環境が記憶された第一の記憶装置が含まれている。前記サーバ環境設定部は、前記コントローラに、前記第一の記憶装置内のサーバ環境を前記複数の記憶装置のうちの他の記憶装置にコピーさせ、且つ、前記第二のサーバに前記他の記憶装置を接続させ、該コピーが完了した後に、前記第二のサーバを起動し、それにより、前記他の記憶装置から前記サーバ環境を前記第二のサーバに読み出されるようにする。

第六の実施態様では、前記ジョブネット実行部は、要求したジョブの実行中に障害が検知された第一のサーバから障害の通知を受けた場合、前記第二のサーバを第一のサーバとして、前記ジョブネットの実行を継続する。

第七の実施態様では、管理サーバは、前記ジョブネットの構成に関する情報を含んだジョブ定義情報を記憶するジョブ定義記憶部を更に備える。前記ジョブネット実行部は、ジョブの要求先のサーバからジョブの正常終了通知を受け、該正常終了通知から、該ジョブが正常に終了したことを把握し、ジョブの要求先のサーバから、ジョブの実行中に障害が検知されたことの障害通知を受けた場合、該ジョブの別の要求先のサーバから正常終了通知を受けたか否かと、前記ジョブ定義情報とに基づき、前記障害通知の通知元のサーバで障害が検知されたことと前記別の要求先のサーバでの該ジョブでの処理状況とを前記ジョブネットの構成と共に示し且つ該ジョブを継続するか中止するかを管理者に問い合わせるＧＵＩを作成して表示し、継続の入力を受けた場合に、該ジョブを継続する。
第八の実施態様では、前記第一のサーバは、オリジナルとするサーバである。前記第二のサーバは、前記オリジナルのサーバのクローンとするサーバである。

各部は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、コンピュータプログラムを読み込んで実行する一又は複数のＣＰＵ）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

本発明によれば、バッチ処理に対応できる信頼性を有し運用の煩雑さを隠蔽できるサーバシステムを低コストで提供することができる。

以下、本発明の実施の形態を説明する。まず、実施の形態の概要を説明する。

バッチ処理対象のジョブネット（複数のジョブから構成されるジョブ群）を構成するジョブを実行することができる複数のサーバと、ジョブをサーバに実行させる管理サーバとが備えられる。管理サーバは、ジョブネットを実行するオリジナルのサーバのクローンとするサーバを複数のサーバから動的に選択し、選択されたクローンのサーバとオリジナルのサーバとをそれぞれ起動する。そして、管理サーバは、ジョブネットを構成するジョブを、それら二以上のサーバ（クローン及びオリジナル）に実行させる。管理サーバは、二以上のサーバからジョブ終了の通知を受けたならば、少なくともクローンサーバを解放する。また、管理サーバは、ジョブを実行しているサーバから障害の通知を受けた場合には、どのジョブについてどのサーバで障害が発生し他のどのサーバでそのジョブについて処理の継続が可能であるかを管理者に見せ且つジョブの実行を継続するか或いは中止するかを管理者に問い合わせるためのＧＵＩを表示する。その問合せに対する回答の結果に応じて、管理サーバは、ジョブを継続するか中止するかを決定する。

以下、本実施形態について詳細に説明する。尚、本実施形態に本発明が限定されるものではない。

図１は、本発明の一実施形態に係る計算機システムの構成例を示した図である。なお、以下の説明では、同種の要素については、親番号（例えば１０５）を用いて説明し、特に区別する場合には、親番号と子符合のセット（例えば１０５ａ）を用いて説明する。

この計算機システムでは、ネットワークスイッチ１０３に、管理サーバ１０１、複数のサーバ１０５及びストレージシステム１０９が接続され、ファイバチャネルスイッチ１０７に、それら複数のサーバ１０５とストレージシステム１０９とが接続されている。ネットワークスイッチ１０３は、例えば、インターネットプロトコルの通信ネットワーク（例えばＬＡＮ（Local Area Network））の一構成要素であり、ファイバチャネルスイッチ１０７は、例えば、ＳＡＮ（Storage Area Network）の一構成要素である。各スイッチ１０３、１０７は、同種のスイッチであっても良い。

図２は、管理サーバ１０１の構成例を示す。

管理サーバ１０１は、一種の計算機であり、ジョブやサーバを管理する。管理サーバ１０１は、ＮＩＣ（Network Interface Card）１３１と、メモリ１１１（他種の記憶資源でも良い）と、プロセッサ（例えばＣＰＵ）１２９とを備える。

ＮＩＣ１３１には、例えば、ＭＡＣ（Media Access Control）アドレスの記憶域１３３や、通信を制御する機構（以下、通信機構）１３５が備えられる。ＮＩＣ１５３を介して、ジョブ実行管理サーバ１０５との通信が行われる。サーバ１０５との通信に利用されるネットワーク種類に応じて、ＮＩＣ１３１に代えて他種の通信インタフェース装置が採用されても良い。

メモリ１１１には、プロセッサ１２９に実行されるコンピュータプログラムや、そのコンピュータプログラムの実行の際に参照される情報が格納される。具体的には、例えば、メモリ１１１には、例えば、ジョブの実行を管理するためのコンピュータプログラム（以下、ジョブ実行管理プログラム）１１３、サーバを動的に多重化するためのプログラム（以下、システム多重化プログラム）１１７、ジョブの実行を命じるためのプログラム（以下、ジョブ実行プログラム）１１９、及びオペレーティングシステム（ＯＳ）１２０が格納される（ＯＳ１２０上で、各プログラム１１３、１１５、１１７及び１１９が動作する）。また、メモリ１１１には、例えば、ジョブの定義を示すテーブル（以下、ジョブ定義テーブル）１２１、サーバを管理するためのテーブル（以下、サーバ管理テーブル）１２３、ジョブを管理するためのテーブル（以下、ジョブ管理テーブル）１２５、及びストレージを管理するためのテーブル（以下、ストレージ管理テーブル）１２７も格納される。各種プログラムや情報については、後に適宜に詳述する。また、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するプロセッサによって処理が行われるものとする。

図３は、サーバ１０５の構成例を示す。

サーバ１０５は、一種の計算機であり、ジョブを実行するサーバとしての一候補である。サーバ１０５は、ＮＩＣ１５３と、ＨＢＡ（Host Bus Adapter）１５１と、メモリ１４１（他種の記憶資源であっても良い）と、プロセッサ（例えばＣＰＵ）１４９とを備える。

ＮＩＣ１５３には、例えば、ＭＡＣアドレスの記憶域２０６や、通信機構２０５が備えられる。ＮＩＣ１５３を介して、管理サーバ１０１との通信が行われる。ジョブ実行管理サーバ１０５との通信に利用されるネットワーク種類に応じて、ＮＩＣ１５３に代えて他種の通信インタフェース装置が採用されても良い。

ＨＢＡ１５１には、例えば、ＷＷＮ（World Wide Name）の記憶域２０４や、通信機構２０３が備えられる。ＨＢＡ１５１を介して、ストレージシステム１０９へのデータの書込みや、ストレージシステム１０９からのデータの読出しが行われる。ストレージシステム１０９との通信に利用されるネットワーク種類に応じて、ＨＢＡ１５１に代えて他種の通信インタフェース装置が採用されても良い。

メモリ１４１には、例えば、プロセッサ１４９に実行されるコンピュータプログラムが格納される。具体的には、例えば、メモリ１４１には、ジョブを実行するコンピュータプログラム（以下、ジョブプログラム）１４５、ジョブの実行の命令を受け付けるコンピュータプログラム（以下、ジョブ実行エージェント）１４３、及び、ＯＳ１４７が格納される（ＯＳ１４７上で、各プログラム１４３、１４５が動作する）。これらのコンピュータプログラムのうちの全部又は一部が、予めメモリ１４１に格納されていても良いが、本実施形態では、それらのコンピュータプログラムの全部が、動的に、ストレージシステム１０９から取得されたり、メモリ１４１から消去されたりする。具体的には、例えば、それらのコンピュータプログラムは、ジョブの実行の必要がある場合に、ストレージシステム１０９から読み出されてメモリ１４１に格納され、必要なくなった場合に（例えば、ジョブの実行が終了した場合に）、メモリ１４１から消去される。

図４は、ストレージシステム１０９の構成例を示す。

ストレージシステム１０９は、複数のディスク装置２２１と、それらディスク装置２２１に接続されたコントローラ２１０とを備える。コントローラ２１０は、例えば、内部バスで接続されたＩ／Ｆ２１１（ネットワークスイッチ１０３のインタフェースや、ファイバチャネルスイッチ１０７のインタフェース）、プロセッサ（例えばＣＰＵ）２１３、キャッシュメモリ２１５及びメモリ２１７を有する。メモリ２１７には、ストレージシステム１０９を制御するためのコンピュータプログラム（以下、制御プログラム）２１９が格納され、プロセッサ２１３によって実行される。尚、ディスク装置２２１は、例えば、ハードディスクドライブであり、ストレージシステム１０９は、複数のディスク装置をＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）構成にしていても良い。また、ディスク装置２２１に代えて、他種の記憶装置（例えばフラッシュメモリ）が採用されても良い。メモリ２１７とキャッシュメモリ２１５は、一体であっても良い。

ストレージシステム１０９がサーバ１０５からライト要求及びデータを受信した場合、制御プログラム２１９は、受信したデータをキャッシュメモリ２１５に一時的に記憶させ、その後、キャッシュメモリ２１５からそのデータを読み出して、ライト要求に従うアクセス先となるディスク装置２２１にそのデータを書込む。ストレージシステム１０９がサーバ１０５からリード要求を受信した場合、制御プログラム２１９は、リード要求に従うアクセス先となるディスク装置２２１からデータを読み出してキャッシュメモリ２１５に一時的に記憶させ、その後、キャッシュメモリ２１５からそのデータを読み出してサーバ１０５に送信する。

ストレージシステム１０９は、複数の仮想ＬＵと、複数の物理ＬＵとを有する。ＬＵとは、論理ボリューム或いは論理ユニットと呼ばれる論理的な記憶デバイスである。仮想ＬＵとは、ストレージシステム１０９の上位装置（本実施形態ではサーバ１０５）に提供され、物理ＬＵに対応付けられる仮想的なＬＵである。物理ＬＵとは、複数のディスク装置２２１により提供される記憶資源を用いて設定されたＬＵである。

このストレージシステム１０９は、本実施形態で「ホストグループ機能」と呼ぶセキュリティ機能を有している。ホストグループ機能とは、ファイバチャネルスイッチ１０３に接続される通信ポートに二以上の物理ＬＵ（及びそれらに対応付けられた二以上に仮想ＬＵ）が対応付けられ、且つ、その通信ポートを介して複数のサーバ１０５と通信が行われるようになっている場合に、各サーバ１０５に、それら二以上の物理ＬＵのうちの、割り当てられた所定の物理ＬＵにしかアクセスできないようにする機能である。ホストグループとは、サーバ１０５と、それに割り当てられた仮想ＬＵ及び物理ＬＵとで構成することができる。

図５は、ホストグループ機能の説明の一例を示す。

例えば、ストレージシステム１０９に、複数の物理ＬＵとして、二以上のシステム物理ＬＵ３０１ａ、３０１ｃ、３０１ｅと、二以上のデータ物理ＬＵ３０１ｂ、３０１ｄ、３０１ｆとがあるとする。システム物理ＬＵとは、サーバ１０５のサーバ環境（例えば、複数のコンピュータプログラムや実行環境（例えばＩＰアドレス））が格納されている物理ＬＵである。データ物理ＬＵとは、そのサーバ環境でジョブが実行されることにより、サーバ１０５にアクセスされるデータ（読み出されるデータ或いは書込まれるデータ）が格納される物理ＬＵである。

図５によれば、ホストグループ機能により、３つのホストグループが設定されている。ホストグループ１では、サーバ１０５ａに、物理ＬＵ３０１ａ及び３０１ｂが割り当てられる。ホストグループ２では、サーバ１０５ｂに、物理ＬＵ３０１ｃ及び３０１ｄが割り当てられる。ホストグループ３では、サーバ１０５ｃに、物理ＬＵ３０１ｅ及び３０１ｆが割り当てられる。これにより、ストレージシステム１０９は、サーバ１０５ａに対して、そのサーバ１０５ａが属するホストグループ１内の物理ＬＵ３０１ａ及び３０１ｂへのアクセスを許可するが、他のホストグループ２或いは３内の物理ＬＵへのアクセスを禁止する。

ホストグループの設定は、例えば、ストレージシステム１０９のコントローラ２１０に接続されている計算機（以下、保守端末）から行うことができる。

図６は、ホストグループの設定の一例を示す。

例えば、システム多重化プログラム１１７が実行されることにより、制御プログラム２１９に対するインタフェース（以下、設定インタフェース）３５１でサポートされているコマンドが利用され、それにより、ホストグループの設定或いは解除が動的に行われる。サポートされているコマンドとしては、ホストグループを新たに追加するためのsetmappingコマンドと、ホストグループを削除するためのremovemappingコマンドの２種類がある。

システム多重化プログラム１１７は、ホストグループを新たに設定する場合、設定するホストグループに関する情報を、setmappingコマンドを使用して入力する。これにより、制御プログラム２１９が、そのsetmappingコマンドに従って、入力された情報を、ディスクマッピングテーブル２２０に格納する。ディスクマッピングテーブル２２０は、制御プログラム２１９に保持される情報であって、ホストグループ名が書かれるカラム２２０ａ、サーバＩＤ（例えばＷＷＮ）が書かれるカラム２２０ｂ、仮想ＬＵＮが書かれるカラム２２０ｃ、及び、物理ＬＵＮが書かれるカラム２２０ｄを有する。一つのホストグループについて、ホストグループ名、サーバＩＤ、仮想ＬＵＮ及び物理ＬＵＮが登録される。すなわち、ホストグループに関する情報としては、ホストグループ名、サーバＩＤ、仮想ＬＵＮ及び物理ＬＵＮがある。ＬＵＮとは、ＬＵを識別するための番号である（番号に代えて他種のコードが採用されても良い）。

一方、システム多重化プログラム１１７は、ホストグループを解除する場合、解除するホストグループに関する情報を、removemappingコマンドを使用して入力する。これにより、制御プログラム２１９が、そのremovemappingコマンドに従って、入力された情報を、ディスクマッピングテーブル２２０から削除する。

さて、この実施形態では、ジョブネットを実行するためのサーバ１０５（以下、オリジナルサーバ）のクローン（以下、クローンサーバ）を動的に生成したり、そのクローンサーバを動的に解除したりすることができる。クローンサーバを生成するとは、オリジナルサーバのサーバ環境を他のサーバ１０５に動的に設定することであり、クローンサーバを解除するとは、その設定されたサーバ環境をクローンサーバ（他のサーバ）１０５から破棄することである。

本実施形態において、サーバ環境は、ジョブネットを実行するためのコンピュータプログラム群と実行環境の両方で表すことができる。実行環境とは、例えばＩＰアドレスである。コンピュータプログラム群は、例えば、特定の計算機或いはストレージシステムからサーバ１０５に送信されても良いが、本実施形態では、クローンとして選出されたサーバ１０５により、システム物理ＬＵ３０１から読み出される。

以下、クローンサーバの生成の流れの概要を、図７及び図８を参照して説明する。

図７は、クローンサーバの生成の流れの一部を示す。図８は、その流れの他の一部を示す。なお、以下の説明では、オリジナルサーバをサーバ１０５ａとし、クローンサーバとなるサーバを１０５ｂとする。

クローンサーバの生成において、オリジナルサーバ１０５ａが稼動中であれば、例えば、システム多重化プログラム１１７は、オリジナルサーバ１０５ａが属するホストグループ１内のデータ物理ＬＵ３０１ｂに対応した仮想ＬＵ（以下、データ仮想ＬＵ）３１３ｂへの書き込みが発生しないような制御を行う。具体的には、例えば、システム多重化プログラム１１７は、オリジナルサーバの静止化する（例えば、データ仮想ＬＵ３１３ｂへの書き込みを禁止させる）。或いは、システム多重化プログラム１１７は、オリジナルサーバ１０５ａを終了する（例えば電源をターンオフさせる）。

図７に示すように、システム多重化プログラム１１７は、オリジナルサーバ１０５ａが属するホストグループ１内のシステム物理ＬＵ３０１ａ及びデータ物理ＬＵ３０１ｂを特定する。そして、システム多重化プログラム１１７は、複数の他の物理ＬＵの中から、未使用の物理ＬＵであって、特定されたシステム物理ＬＵ３０１ａと同じ記憶容量の物理ＬＵ３０１ｃを選択し、制御プログラム２１９に、特定されたシステム物理ＬＵ３０１ａ内のサーバ環境を、選択した物理ＬＵ３０１ｃにコピーさせる。また、システム多重化プログラム１１７は、複数の他の物理ＬＵの中から、未使用の物理ＬＵであって、特定されたデータ物理ＬＵ３０１ｂと同じ記憶容量の物理ＬＵ３０１ｄを選択し、制御プログラム２１９に、特定されたデータ物理ＬＵ３０１ｂ内のデータ群を、選択した物理ＬＵ３０１ｄにコピーさせる。コピーが終了した場合、例えば図５のホストグループ２のようになる。

次に、システム多重化プログラム１１７は、クローンサーバとするサーバ１０５ｂを、オリジナルサーバ１０５ａ以外の未稼働のサーバ１０５の中から選択する。そして、システム多重化プログラム１１７は、選択した未稼働のサーバ１０５ｂのＩＤと、システム物理ＬＵ３０１ｃの物理ＬＵＮと、そのシステム物理ＬＵ３０１ｃに対応付けた仮想ＬＵ（以下、システム仮想ＬＵ）３１３ｃの仮想ＬＵＮ（以下、システム仮想ＬＵＮ）と、データ物理ＬＵ３０１ｄの物理ＬＵＮと、そのデータ仮想ＬＵ３１３ｄの仮想ＬＵＮ（以下、データ仮想ＬＵＮ）とを含んだホストグループ情報を動的に設定する。そして、システム多重化プログラム１１７は、選択した未稼動のサーバ１０５ｂに、起動命令を発行すると共に、設定したシステム仮想ＬＵＮとデータ仮想ＬＵＮとを通知する。これにより、図８に示すように、サーバ１０５ｂが、起動命令に応答して起動し、起動の際に、通知されたシステム仮想ＬＵＮに対するリードコマンドを制御プログラム２１９に発行する。制御プログラム２１９は、リードコマンドで指定されたシステム仮想ＬＵＮに対応するシステム物理ＬＵＮを特定し、特定されたシステム物理ＬＵＮからシステム物理ＬＵ３０１ｃを特定し、そのシステム物理ＬＵ３０１ｃからサーバ環境を読出し、読み出したサーバ環境を、サーバ１０５ｂに送信する。この結果、サーバ１０５ｂに、送信されたサーバ環境が設定される。つまり、サーバ１０５ｂは、オリジナルサーバ１０５ａのクローンとなる。

ここで、サーバ環境が設定された直後のサーバ１０５ｂの実行環境は、オリジナルサーバ１０５ａの実行環境と同一である。このため、オリジナルサーバ１０５ａが起動すると、エラーが生じる可能性がある。それを解消するために、図７に示すように、システム多重化プログラム１１７は、クローンサーバ１０５ｂに対し、一旦設定された実行環境と異なる実行環境（具体的には、オリジナルサーバ１０５ａとは異なるＩＰアドレス）を設定する。

以上の一連の処理により、クローンサーバの生成が完了する。

さて、次に、管理サーバ１０１に保持される種々の情報について説明する。

図９は、ジョブ定義テーブル１２１の概念図である。

ジョブ定義テーブル１２１は、一以上のジョブネットの各々に関する情報を表す。ジョブネットに関する情報としては、例えば、ジョブネットを幾つのクローンサーバで実行させるか（多重度）や、そのジョブネットが幾つのジョブを有しそれらのジョブをどんなタイミングで実行するか等である。多重度は、より高い信頼性が要求されればより大きな値とされる。図９の例では、ジョブネット１を１つのクローンサーバ（換言すれば多重度１であって、オリジナルとクローンの２台のサーバ）でジョブネット１を実行させ、且つ、ジョブネット１では、ジョブ１〜４の４つのジョブがあり、ジョブ１が初めに実行され、その次にジョブ２及び３が並行して実行され、最後に、ジョブ４が実行されることが分かる。

ちなみに、ジョブネットを構成する各ジョブは、図１０に示すように、管理サーバ１０１のジョブ実行プログラム１１９によって、ネットワークスイッチ１０３を経由してサーバ１０５に送られる。サーバ１０５では、ジョブ実行エージェント１４３が、ジョブを受け、そのジョブを、そのジョブを実行するジョブプログラム１４５に割り振る。ジョブプログラム１４５は、割り振られたジョブを実行する。

図１１は、ジョブ定義テーブル１２１の構成例を示す。

ジョブ定義テーブル１２１は、ジョブネット識別子（例えば名称）が書かれるカラム５０１と、多重度（生成するクローンサーバの数）が書かれるカラム５０２と、ジョブネットの実行開始日時が書かれるカラム５０３と、ジョブに関する情報（以下、ジョブ情報）が書かれるカラムとを有する。一つのジョブネットについて、ジョブネットＩＤ、多重度、実行開始日時及びジョブ情報が書かれる。

ジョブ情報が書かれるカラムにおいて、ジョブネットにどんな複数のジョブがあって、それら複数のジョブをどのようなタイミングで実行し、各ジョブをどんな時間内で終了すべきかが定義されている。具体的には、ジョブ情報が書かれるカラムには、ジョブネットを構成する複数のジョブの各々について、ジョブの実行順番が書かれるカラム５０４と、ジョブ名（他種のＩＤでもよい）が書かれるカラム５０５と、ジョブを実行するジョブプログラムの名称が書かれるカラム５０６と、プログラム実行同期が書かれるカラム５０７と、ジョブの処理時間長が書かれるカラム５０８とがある。プログラム実行同期とは、ジョブの実行開始タイミングと言い換えることができる。例えば、ジョブ２のプログラム実行同期として、「ジョブ１」となっているが、これは、ジョブ１の終了に同期してジョブ２の実行が開始されることを意味する。

図１２は、サーバ管理テーブルの構成例を示す。

サーバ管理テーブル１２３は、サーバ識別子（例えば名称）が書かれるカラム５１１と、サーバリソースに関する情報が書かれるカラム５１２及び５１３と、デバイスに関する情報（例えば、通信インタフェース装置に関する種別）が書かれるカラム５１４と、割り当て状態が書かれるカラム５１５と、装置状態が書かれるカラム５１６とを有する。一つのサーバについて、サーバ識別子、サーバリソースに関する情報、割り当て状態及び装置状態が書かれる。なお、サーバリソースに関する情報としては、例えば、プロセッサに関する情報（例えばプロセッサ種別及びクロック数）と、メモリに関する情報（例えばメモリの記憶容量）とがある。割り当て状態とは、例えば、オリジナルサーバ或いはクローンサーバとしてジョブ実行のために既に使用されているかどうかに関する状態であり、割り当て状態としては、例えば、割り当て済みか否かの２種類の状態がある。割り当て状態は、例えば、システム多重化プログラム１１７によるサーバ選択と共に割り当て済みに更新され、クローンサーバの解放と共に未割り当てに更新される。装置状態とは、例えば、サーバの稼動に関する状態であり、装置状態としては、例えば、正常、障害が発生していればどんな障害かなどがある。装置状態が正常の場合、クローンサーバの割り当ての際に選択され得るサーバとなる。

図１３は、ジョブ管理テーブル１２５の構成例を示す。

ジョブ管理テーブル１２１は、ジョブネット識別子（例えば名称）が書かれるカラム５２１と、ジョブネットを実行するサーバに関する情報が書かれるカラムとを有する。一つのジョブネットについて、ジョブネット識別子と、一以上のサーバに関する情報とが書かれる。

サーバに関する情報が書かれるカラムとしては、サーバ種類（オリジナル、クローン）が書かれるカラム５２２と、ジョブネットの実行に必要なリソース（例えば、ＣＰＵ種別、クロック数及びメモリ容量）が書かれるカラム５２３と、割り当てサーバ識別子が書かれるカラム５２４と、ホストグループ識別子が書かれるカラム５２５と、ＩＰアドレスが書かれるカラム５２６とがある。一つのサーバについて、サーバ種類、必要リソース、割り当てサーバ識別子、ホストグループ識別子及びＩＰアドレスが書かれる。なお、サーバ種類とは、オリジナルサーバとしてジョブネットが実行されるか、クローンサーバとしてジョブネットが実行されるかを表す。割り当てサーバ識別子とは、対応するサーバ種類として割り当てられているサーバの識別子である。ホストグループ識別子とは、そのサーバが属するホストグループの識別子である。ＩＰアドレスとは、そのサーバに割り当てられているＩＰアドレスである。

図１４は、ストレージ管理テーブル１２７の構成例を示す。

ストレージ管理テーブル１２７は、ストレージシステムの識別子（例えば名称）が書かれるカラム５３１と、そのストレージシステムが備える物理ＬＵの物理ＬＵＮが書かれるカラム５３２と、その物理ＬＵが属するホストグループの識別子が書かれるカラム５３０と、その物理ＬＵの記憶容量が書かれるカラム５３３と、その物理ＬＵの使用状態（例えば、使用中か未使用か）が書かれるカラム５３４とがある。このストレージ管理テーブル１２７は、ストレージシステム１０９内の空きの物理ＬＵを管理するために使用される。具体的には、例えば、物理ＬＵ間のコピーが完了した場合に、コピー先の物理ＬＵの使用状態は使用中に更新され、そのコピー先の物理ＬＵが割り当てられていたクローンサーバが解放された場合に、その物理ＬＵの使用状態は未使用に更新される。未使用に更新された際、その物理ＬＵ内のデータは、消去される。

以上が、管理サーバ１０１に保持される種々の情報についての説明である。次に、本実施形態で行われる処理の流れの一例を説明する。

図１５は、ジョブ実行管理プログラム１１３が行う処理の流れの一例を示す。

ジョブ実行管理プログラム１１３は、バッチ処理の対象であるジョブネットを選択する（ステップＳ１０）。具体的には、例えば、ジョブ実行管理プログラム１１３は、ジョブ定義テーブル１２１を参照し、実行開始日時になったジョブネットをバッチ処理の対象として選択する。以下、選択されたジョブネットがジョブネット１であるとする。
また、ジョブ実行管理プログラム１１３は、ジョブネット１を選択した場合に、ジョブネット１を実行するオリジナルサーバとして必要なリソースを、ジョブ管理テーブル１２１から特定し、特定された必要リソースを有する、未割り当てのサーバを、サーバ管理テーブル１２３から特定する。ジョブ実行管理プログラム１１３は、特定されたサーバの識別子を、ジョブ管理テーブル１２５の"ジョブネット１"及び"オリジナルサーバ"に対応した欄に書く。なお、必要リソースとして、ハードウェア的なリソースに加えて、ソフトウェア的なリソース、例えば、ジョブネット１の実行に必要なコンピュータプログラムを有するか否かが含まれても良い。ソフトウェア的なリソースを有する場合としては、サーバにソフトウェアがインストール済みである場合であってもよいし、インストールはされていないが、外部の論理ボリュームから取得できる場合であってもよい。
以下、ジョブネット１のオリジナルサーバを、「オリジナルサーバ１」或いは単に「サーバ１」と言い、クローンサーバを、「クローンサーバ２」或いは単に「サーバ２」と言うことにする。

さて、次に、ジョブ実行管理プログラム１１３は、ジョブネット１に対応した多重度をジョブ定義テーブル１２１から特定し、特定された多重度が１以上であれば、ジョブ多重化プログラム１１７を呼び出す（特定された多重度が０であれば、次にＳ５０を行う）（Ｓ２０）。図１１に例示したジョブ定義テーブル１２１によれば、ジョブネット１に対応した多重度は"１"であるので、Ｓ２０は行われる。このＳ２０では、例えば、ジョブ実行管理プログラム１１３は、図１６に例示するように、システム多重化要求と共に、ジョブネット１の識別子"ジョブネット１"を送信する。それにより、システム多重化プログラム１１７によって、システム多重化が行われ、その結果が、図１６に例示するように、システム多重化プログラム１１７からジョブ実行管理プログラム１１３に対して回答される。システム多重化に成功した場合、ジョブ実行管理プログラム１１３は、実行環境設定情報を取得する（Ｓ３０）。実行環境設定情報とは、クローンサーバ２に設定された実行環境を表す情報であり、具体的には、例えば、クローンサーバ２のＩＰアドレスである。

Ｓ２０及びＳ３０が、（多重度−１）回繰り返される。具体的には、ジョブ実行管理プログラム１１３は、ジョブネット１に対応した多重度から１差し引いた分だけＳ２０及びＳ３０を繰り返したか否かを判断し、繰り返していなければ（Ｓ４０でＮＯ）、再度Ｓ２０を行う。ここでは、ジョブネット１に対応した多重度は"１"であり、１−１＝０となるので、Ｓ２０及びＳ３０の繰り返しは行われない。

Ｓ２０及びＳ３０の繰り返しが終わったならば（Ｓ４０でＹＥＳ）、ジョブ実行管理プログラム１１３は、上記選択されたオリジナルサーバ１を起動する（Ｓ５０）。

次に、ジョブ実行管理プログラム１１３は、ジョブ実行プログラム１１９を呼び出す（Ｓ６０）。その際、サーバ１０５の識別子が、ジョブ実行プログラム１１９に通知される。

そして、ジョブ実行管理プログラム１１３は、所定時間待ち（Ｓ７０）、Ｓ６０及びＳ７０を多重度分繰り返したかどうかを判断する（Ｓ８０）。Ｓ６０及びＳ７０が多重度分繰り返されていない場合（Ｓ８０でＮＯ）、ジョブ実行管理プログラム１１３は、再度Ｓ６０を行う。

Ｓ６０及びＳ７０が多重度分繰り返された場合（Ｓ８０でＹＥＳ）、ジョブ実行管理プログラム１１３は、ジョブネット１を実行するサーバ１、２でジョブネット１が終了するまで待つ（Ｓ９０）。

それら全てのサーバ１、２でジョブネット１が終了した場合、ジョブ実行管理プログラム１１３は、後述するクローン用カウンタが１以上であれば、ジョブ管理テーブル１２５を参照し、ジョブネット１についてクローンサーバ２が存在することを検出した場合には、そのクローンサーバ２を解放する（後述するクローン用カウンタが０であれば、終了してよい）（Ｓ１００）。具体的には、例えば、ジョブ実行管理プログラム１１３は、図１３に例示したように、クローンサーバとしてサーバ２が割り当てられている場合、そのサーバ２に関する情報（"サーバ２"、"ホストグループ２"及び"Adr2"）をジョブ管理テーブル１２５から削除し、且つ、そのサーバ２の割り当て状態（図１２に例示した割り当て状態）を"未割り当て"に更新する。

クローンサーバ２を解放した場合、ジョブ実行管理プログラム１１３は、クローン用カウンタを１減算する（Ｓ１１０）。クローン用カウンタとは、クローンサーバの数を表す値であり、図１７に例示する処理流れにおいて、クローンサーバが生成される都度に加算された値である。

ジョブ実行管理プログラム１１３は、クローン用カウンタが０にならなければ（Ｓ１２０でＹｅｓ）、再度Ｓ１００を実行し、クローン用カウンタが０になれば（Ｓ１２０でＮＯ）、終了する。

図１７は、ジョブ実行管理プログラム１１３から呼び出されたシステム多重化プログラム１１７が行う処理の流れの一例を示す。

システム多重化プログラム１１７は、ストレージ管理テーブル１２７を参照し、使用状態が"未使用"の物理ＬＵを選択する（Ｓ２１０）。その際、システム多重化プログラム１１７は、オリジナルサーバ１が属するホストグループ１をジョブ管理テーブル１２５から特定し、特定されたホストグループ１に属する物理ＬＵ及びその記憶容量をストレージ管理テーブル１２７から特定し、特定された記憶容量以上の記憶容量を有する"未使用"の物理ＬＵを選択する。ここでは、一つの物理ＬＵに対して、"未使用"の一つの物理ＬＵが選択される。

システム多重化プログラム１１７は、制御プログラム２１９に、ホストグループ１に属する物理ＬＵから、選択された物理ＬＵにデータをコピーさせる（Ｓ２２０）。これにより、ホストグループ１に属する全物理ＬＵ（システム物理ＬＵ及びデータ物理ＬＵ）から、選択された全物理ＬＵに、それぞれデータコピーされる。

次に、システム多重化プログラム１１７は、ホストグループを選択する（Ｓ２４０）。また、システム多重化プログラム１１７は、サーバ管理テーブル１２３を参照することにより、"未割り当て"のサーバ１０５であって、ジョブネット１の必要リソースを満たすサーバ１０５を選択する（Ｓ２５０）。そして、システム多重化プログラム１１７は、選択したサーバ１０５に、Ｓ２１０で選択した物理ＬＵを接続する（Ｓ２６０）。具体的には、例えば、システム多重化プログラム１１７は、Ｓ２１０で選択した全物理ＬＵのＬＵＮと、それら物理ＬＵに対応付けられる仮想ＬＵのＬＵＮと、Ｓ２５０で選択したサーバ１０５の識別子と、Ｓ２４０で選択したホストグループの識別子とをsetmappingコマンドを用いて入力する。これにより、入力された情報が、制御プログラム２１９が保持するディスクマッピングテーブル２２０に登録される。

システム多重化プログラム１１７は、Ｓ２５０で選択したサーバ１０５（以下、「多重化用サーバ１０５」とも言う）を起動する（Ｓ２７０）。これにより、多重化用サーバ１０５（つまりクローンサーバ２）により、接続された一以上の物理ＬＵのうちのシステム物理ＬＵから、サーバ環境が読み出され、実行環境が設定される。

システム多重化プログラム１１７は、その多重化用サーバ１０５の実行環境を設定する（Ｓ２８０）。具体的には、システム多重化プログラム１１７は、サーバ環境の読み出しにより設定された実行環境と異なる実行環境をその多重化用サーバ１０５に設定する。図１５のＳ５０でオリジナルサーバが起動されるが、そのオリジナルサーバの実行環境（例えばＩＰアドレス）と同じにならないようにするためである。

システム多重化プログラム１１７は、クローン用カウンタを１加算する（２９０）。

また、システム多重化プログラム１１７は、Ｓ２８０で設定した実行環境と、その実行環境が設定された多重化用サーバ１０５の識別子とを、ジョブ実行管理プログラム１１３に通知する（Ｓ３００）。

システム多重化プログラム１１７は、Ｓ２９０で更新したクローン用カウンタが、ジョブ実行管理プログラム１１３により特定された多重度未満か否かを判断し、クローン用カウンタが多重度未満であれば（Ｓ３１０でＹＥＳ）、再度Ｓ２１０を実行し、クローン用カウンタが多重度になっていれば（Ｓ３１０でＮＯ）、終了する。

図１８は、ジョブ実行管理プログラム１１３から呼び出されたジョブ実行プログラム１１９が行う処理の流れの一例を示す。

ジョブ実行プログラム１１９は、ジョブ実行管理プログラム１１３から通知されたサーバ識別子に対応するサーバ１０５を特定し、特定されたサーバ１０５内のジョブ実行エージェント１４３に、ジョブ実行を要求する（Ｓ４１０）。その際、ジョブ実行プログラム１１９は、実行対象のジョブのジョブ名及びプログラム名（ジョブ定義テーブル１２１から特定されるジョブ名及びプログラム名）を、そのジョブ実行エージェント１４３に通知する。

その後、ジョブ実行プログラム１１９は、ジョブの実行結果を受ける（Ｓ４１５）。

その実行結果が、障害を表していない場合（Ｓ４２０でＮＯ）、ジョブ実行プログラム１１９は、ジョブネット１に、実行すべきジョブが存在すれば（Ｓ４３０でＹＥＳ）、そのジョブの実行をさせるためにＳ４１０を行う。なお、そのＳ４１０を実行するタイミングは、ジョブ定義テーブル１２１に基づいて決定される。具体的には、例えば、ジョブネット１におけるジョブ１について、Ｓ４１０が行われた場合、そのジョブ１が終了したことの回答を、ジョブ実行プログラム１１９がジョブ実行エージェント１４３から受けた場合に、ジョブ２及びジョブ３について、Ｓ４１０が行われる。

受けた実行結果が、障害を表している場合（Ｓ４２０でＹＥＳ）、ジョブ実行プログラム１１９は、Ｓ４１０の要求先（サーバ１０５）のサーバ識別子に対応した装置状態（サーバ管理テーブル１２３に記載の装置状態）を更新する（Ｓ４４０）。ここで、更新された装置状態に対応するサーバ種類がオリジナルサーバの場合（Ｓ４５０でＹＥＳ）、ジョブ実行プログラム１１９は、ジョブネット１に対応するクローンサーバのうち装置状態が"正常"のクローンサーバを任意に選択して一時的にオリジナルサーバとする（Ｓ４６０）。

ジョブ実行プログラム１１９は、クローン用カウンタを１減算する（Ｓ４７０）。ジョブネット１を実行するサーバ１０５の台数が１減ったためである。

ジョブ実行プログラム１１９は、そのオリジナルサーバを一時停止して（Ｓ４８０）、ジョブネット１の実行状況を表すＧＵＩ（以下、実行状況ＧＵＩ）を作成し、作成した実行状況ＧＵＩを管理者に対して表示する。実行状況ＧＵＩには、ジョブネット１が幾つのサーバで実行され、それらのサーバのうちのどのサーバにおいて、ジョブネット１のうちのどのジョブの障害が検知され、他のどのサーバでそのジョブの実行が可能であるかに関する情報が表示される。その実行状況ＧＵＩの一例を図２０に示す。この実行状況ＧＵＩは、ジョブ１、ジョブ２及びジョブ３は全サーバ１，２で正常に終了し、ジョブ４について、サーバ１で障害が発生したが故に、サーバ２がクローンサーバからオリジナルサーバに更新された後に表示された実行状況ＧＵＩである（ただし、クローンサーバとオリジナルサーバの表示は、管理者が混乱しないよう、更新前の表示とされる）。ジョブ実行プログラム１１９は、ジョブ実行終了時刻を各ジョブ毎に登録し、その時刻をＧＵＩに展開することができる。その時刻や、正常終了か障害かは、ジョブネット１の構成図と共に表示される。ジョブネット１の構成図は、ジョブ定義テーブル１２１のジョブ情報（特に、例えば、カラム５０４、５０５及び５０７に記述されている情報）を基に作成可能である。また、サーバ１で停止したジョブ４がサーバ２で実行可能（但し現在一時停止）であることが示される。ジョブ４について、サーバ２で一時停止であることは、サーバ２をオリジナルサーバとしＳ４８０で一時停止にしたことと、ジョブ４についての実行結果をサーバ２のジョブ実行エージェント１４３から受けていないこととから特定することができる。また、この実行状況ＧＵＩにおいて、「継続」ボタンと「中止」ボタンが用意されており、「継続」ボタンが押された場合には、サーバ２でジョブ４が継続され（つまりバッチ処理が継続され）、「中止」ボタンが押された場合には、ジョブ４の実行が停止される（つまりバッチ処理が停止される）。管理者は、この実行状況ＧＵＩを見て、ジョブ４の実行を継続するか中止するかを判断する。なお、この例では、サーバ２がオリジナルサーバとなるため、一時停止となったが、サーバ２に加えて、クローンサーバとして他のサーバが存在する場合には、サーバ２のみ一時停止し、他のサーバでは、ジョブ４の実行が継続されてもよい。

中止或いは継続が選択された場合、ジョブ実行プログラム１１９は、一時的なオリジナルサーバを正式にオリジナルサーバとするために、ジョブ管理テーブル１２５を更新する。具体的には、例えば、オリジナルサーバに対応したサーバ識別子を、サーバ１からサーバ２に変更する。

ジョブ中止が選択された場合（Ｓ４９０でＹＥＳ）、ジョブ実行プログラム１１９は、ジョブ終了を、要求元（ジョブ実行管理プログラム１１３）に通知する（Ｓ５００）。ジョブ継続が選択された場合（Ｓ４９０でＹＥＳ）、ジョブ実行プログラム１１９は、ジョブが継続されるサーバについて、Ｓ４３０を実行する。

図１９は、ジョブ実行エージェント１４３が行う処理の流れの一例を示す。

ジョブ実行エージェント１４３は、ジョブ実行要求、ジョブ名及びプログラム名を受け（Ｓ６１０）、そのジョブ実行要求に応答して、通知されたプログラム名に対応するジョブプログラム１４５に、通知されたジョブ名に対応するジョブを実行させる（Ｓ６２０）。

ジョブ実行エージェント１４３は、そのジョブの実行中に障害が発生したか否かを監視する（Ｓ６３０）。その結果、障害を検出した場合（Ｓ６４０でＹＥＳ）、ジョブ実行エージェント１４３は、実行結果として障害をジョブ実行プログラム１１９に通知し、一方、障害を検出することなくジョブ終了を受けた場合（Ｓ６４０でＮＯ、Ｓ６６０）、実行結果として正常終了をジョブ実行プログラム１１９に通知する。

以上、上述した実施形態によれば、バッチ処理対象のジョブネットの実行の際に、その実行に必要なリソースを有するサーバ１０５が動的にクローンサーバとして選択され、オリジナルサーバとクローンサーバらで、それぞれジョブネットが実行される。この実施形態では、多重化のための専用のハードウェアは不要である。これにより、バッチ処理に対応できるほどの高信頼性を有するオープンサーバシステムを低コストで実現することができる。また、この実施形態では、予め存在する全てのサーバがシステム管理者に見えるわけではなく、それらのサーバのうち、動的に多重化されたサーバのみが見えることになるので、運用の煩雑さを抑えることもできる。すなわち、本実施形態によれば、必要なリソース情報さえ定義しておけばクローンサーバが動的に生成されるようになっており、オリジナルサーバに対するクローンサーバを予め定義しておく必要が無い。

以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をその実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。例えば、障害が検出される都度に実行状況ＧＵＩを作成して表示するのではなく（つまり、管理者に問い合わせることなく他のサーバでのジョブ実行を継続させ）、予め管理サーバ１０１に登録された状況（例えば、多重化されたサーバのうちの残り台数がＮ台（Ｎ≧１の整数））になった場合にのみ、実行状況ＧＵＩが作成されてもよい。また、例えば、前述した種々のコンピュータプログラム（例えば、ジョブ実行管理プログラム１１３、システム多重化プログラム１１７など）のうちの少なくとも一つのコンピュータプログラムについて、少なくとも一部を、ハードウェア（例えば、ＡＳＩＣ（Application Specific Integrated Circuit）等の専用ハードウェア）で実現してもよい。

図１は、本発明の一実施形態に係る計算機システムの構成例を示した図である。 図２は、管理サーバ１０１の構成例を示す。 図３は、サーバ１０５の構成例を示す。 図４は、ストレージシステム１０９の構成例を示す。 図５は、ホストグループ機能の説明の一例を示す。 図６は、ホストグループの設定の一例を示す。 図７は、クローンサーバの生成の流れの一部を示す。 図８は、その流れの他の一部を示す。 図９は、ジョブ定義テーブル１２１の概念図である。 図１０は、ジョブネットの発行と実行の概念の説明図である。 図１１は、ジョブ定義テーブル１２１の構成例を示す。 図１２は、サーバ管理テーブルの構成例を示す。 図１３は、ジョブ管理テーブル１２５の構成例を示す。 図１４は、ストレージ管理テーブル１２７の構成例を示す。 図１５は、ジョブ実行管理プログラム１１３が行う処理の流れの一例を示す。 図１６は、ジョブ実行管理プログラム１１３とシステム多重化プログラム１１７のやり取りの様子を示す。 図１７は、システム多重化プログラム１１７が行う処理の流れの一例を示す。 図１８は、ジョブ実行プログラム１１９が行う処理の流れの一例を示す。 図１９は、ジョブ実行エージェント１４３が行う処理の流れの一例を示す。 図２０は、実行状況ＧＵＩの一例を示す。

符号の説明

１０１…管理サーバ、１０５…サーバ、１０９…ストレージシステム、１１３…ジョブ実行管理プログラム、１１７…システム多重化プログラム、１１９…ジョブ実行プログラム、１２１…ジョブ定義テーブル、１２３…サーバ管理テーブル、１２５…ジョブ管理テーブル、１２７…ストレージ管理テーブル

Claims (11)

1. 複数のサーバと前記複数のサーバを管理する管理サーバとを備えるサーバシステムの前記管理サーバであって、
   バッチ処理の対象である一以上のジョブから成るジョブネットを実行させる際に、前記ジョブネットを実行する第一のサーバを含んだ前記複数のサーバの中から、未割り当ての第二のサーバを選択する第二サーバ選択部と、
   前記選択した第二のサーバに、前記第一のサーバに関する環境であるサーバ環境を設定させるサーバ環境設定部と、
   前記第一のサーバと、前記サーバ環境が設定された第二のサーバに、それぞれ、前記ジョブネットを構成する各ジョブを実行させるジョブネット実行部と、
   前記第一のサーバと前記第二のサーバからそれぞれ前記ジョブネットの実行終了通知を受けた場合に、前記第二のサーバを解放するサーバ解放部と
   を備える管理サーバ。
2. 各サーバのリソースに関する情報と各サーバの割り当てに関する状態とを含んだサーバ管理情報を記憶するサーバ管理記憶部と、
   前記ジョブネットの実行に必要なリソースに関する情報を含んだジョブ定義情報を記憶するジョブ定義記憶部と
   を更に備え、
   前記第二サーバ選択部は、前記サーバ管理情報と前記ジョブ定義情報とを参照することにより、前記ジョブネットの実行に必要なリソースを有する未割り当てのサーバを選択する、
   請求項１記載の管理サーバ。
3. 前記ジョブ定義情報は、前記ジョブネットについての多重度も含んでおり、
   前記第二サーバ選択部は、前記多重度と同数のサーバを第二のサーバとして選択する、
   請求項２記載の管理サーバ。
4. 前記サーバ環境の設定の際、前記第一のサーバも前記第二のサーバも起動しておらず、前記サーバ環境には、ジョブネットの実行環境が含まれており、
   前記サーバ環境設定部は、前記第二のサーバを起動した後、前記第二のサーバに設定される、前記第一のサーバと同じ実行環境と異なる実行環境を、該第二のサーバに設定し、その後で、前記第一のサーバを起動する、
   請求項１記載の管理サーバ。
5. 前記複数のサーバ及び前記管理サーバは、インターネットプロトコルの通信ネットワークに接続され、
   前記実行環境は、ＩＰアドレスである、
   請求項４記載の管理サーバ。
6. 前記サーバシステムには、前記複数のサーバ及び前記管理サーバに通信可能に接続されたストレージシステムが含まれており、
   前記ストレージシステムには、複数の記憶装置とコントローラとが備えられ、前記複数の記憶装置には、前記第一のサーバの前記サーバ環境が記憶された第一の記憶装置が含まれており、
   前記サーバ環境設定部は、前記コントローラに、前記第一の記憶装置内のサーバ環境を前記複数の記憶装置のうちの他の記憶装置にコピーさせ、且つ、前記第二のサーバに前記他の記憶装置を接続させ、該コピーが完了した後に、前記第二のサーバを起動し、それにより、前記他の記憶装置から前記サーバ環境を前記第二のサーバに読み出されるようにする、
   請求項４記載の管理サーバ。
7. 前記ジョブネット実行部は、要求したジョブの実行中に障害が検知された第一のサーバから障害の通知を受けた場合、前記第二のサーバを第一のサーバとして、前記ジョブネットの実行を継続する、
   請求項１記載の管理サーバ。
8. 前記ジョブネットの構成に関する情報を含んだジョブ定義情報を記憶するジョブ定義記憶部を更に備え、
   前記ジョブネット実行部は、ジョブの要求先のサーバからジョブの正常終了通知を受け、該正常終了通知から、該ジョブが正常に終了したことを把握し、ジョブの要求先のサーバから、ジョブの実行中に障害が検知されたことの障害通知を受けた場合、該ジョブの別の要求先のサーバから正常終了通知を受けたか否かと、前記ジョブ定義情報とに基づき、前記障害通知の通知元のサーバで障害が検知されたことと前記別の要求先のサーバでの該ジョブの処理状況とを前記ジョブネットの構成と共に示し且つ該ジョブを継続するか中止するかを管理者に問い合わせるＧＵＩを作成して表示し、継続の入力を受けた場合に、該ジョブを継続する、
   請求項１記載の管理サーバ。
9. 前記第一のサーバは、オリジナルとするサーバであり、
   前記第二のサーバは、前記オリジナルのサーバのクローンとするサーバである、
   請求項１記載の管理サーバ。
10. 複数のサーバと、
    前記複数のサーバを管理する管理サーバと
    を備え、
    前記管理サーバが、
    バッチ処理の対象である一以上のジョブから成るジョブネットを実行させる際に、前記ジョブネットを実行する第一のサーバを含んだ前記複数のサーバの中から、未割り当ての第二のサーバを選択する第二サーバ選択部と、
    前記選択した第二のサーバに、前記第一のサーバに関する環境であるサーバ環境を設定させるサーバ環境設定部と、
    前記第一のサーバと、前記サーバ環境が設定された第二のサーバに、それぞれ、前記ジョブネットを構成する各ジョブを実行させるジョブネット実行部と、
    前記第一のサーバと前記第二のサーバからそれぞれ前記ジョブネットの実行終了通知を受けた場合に、前記第二のサーバを解放するサーバ解放部と
    を備える、
    サーバシステム。
11. 複数のサーバを備えるサーバシステムで実現するジョブ実行方法であって、
    バッチ処理の対象である一以上のジョブから成るジョブネットを実行させる際に、前記ジョブネットを実行する第一のサーバを含んだ前記複数のサーバの中から、未割り当ての第二のサーバを選択し、
    前記選択した第二のサーバに、前記第一のサーバに関する環境であるサーバ環境を設定させ、
    前記第一のサーバと、前記サーバ環境が設定された第二のサーバに、それぞれ、前記ジョブネットを構成する各ジョブを実行させ、
    前記第一のサーバと前記第二のサーバからそれぞれ前記ジョブネットの実行終了通知を受けた場合に、前記第二のサーバを解放する、
    ジョブ実行方法。

Images