JP6318031B2 - バッチサーバメンテナンス方法 - Google Patents

バッチサーバメンテナンス方法 Download PDF

Info

Publication number
JP6318031B2
JP6318031B2 JP2014140112A JP2014140112A JP6318031B2 JP 6318031 B2 JP6318031 B2 JP 6318031B2 JP 2014140112 A JP2014140112 A JP 2014140112A JP 2014140112 A JP2014140112 A JP 2014140112A JP 6318031 B2 JP6318031 B2 JP 6318031B2
Authority
JP
Japan
Prior art keywords
batch
server
maintenance
business
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014140112A
Other languages
English (en)
Other versions
JP2016018350A (ja
Inventor
崇司 三田村
崇司 三田村
和行 中村
和行 中村
史泰 山地
史泰 山地
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2014140112A priority Critical patent/JP6318031B2/ja
Publication of JP2016018350A publication Critical patent/JP2016018350A/ja
Application granted granted Critical
Publication of JP6318031B2 publication Critical patent/JP6318031B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Stored Programmes (AREA)

Description

本発明は、サーバ機器の運用管理技術に関し、特に、長時間のバッチ処理を行うサーバ機器のメンテナンス方法に適用して有効な技術に関するものである。
サーバ機器を含んで構成される情報処理システムにおいて、システムの正常稼働を維持するには、サーバ機器に対するパッチやバグフィクス等の修正プログラムの適用やソフトウェアのバージョンアップ、定期的なリブートなどのメンテナンス処理が必要である。メンテナンス中のサーバは、基本的に業務処理を行うことができないため、全体的な業務の継続に影響を与えないようにするために種々の対策が講じられる。
例えば、特開2012−174220号公報(特許文献1)には、複数のサーバを備えるシステムにおいて、各サーバのリブートを管理するサーバ管理装置と、第1のサーバグループについてリブートを実行した後に第2のサーバグループについてリブートを実行するリブート順序の計画を立てるリブート計画部と、リブートを指示したサーバグループを構成するサーバについてリブートが完了しない場合、リブートが完了しないサーバを切り離してサーバグループの縮退運用が可能か否かを判定する縮退運用判定部と、第1のサーバグループを構成するサーバにリブートエラーがあっても、縮退運用判定部による第1のサーバグループの縮退運用が可能の判定をリブート完了とみなして、第2のサーバグループにリブート指示を行うリブート制御部とを有することで、保守担当者の負担を軽減しつつ、保守時間内のサーバのリブートを実行可能とする技術が記載されている。
また、特開2003−15894号公報(特許文献2)には、複数のコンピュータから構成されるクラスタを少なくとも一つ含むコンピュータシステムにおいて、総合監視装置が複数のコンピュータの構成情報等を管理し、その構成情報等に基づいて、パッチの適用スケジュールを決定することで、前記コンピュータシステム全体を停止することなく、前記コンピュータシステムを構成するそれぞれのコンピュータで動作するオペレーティングシステムに対してパッチの適用処理を行う技術が記載されている。
特開2012−174220号公報 特開2003−15894号公報
従来技術では、サーバのメンテナンスにおいて、同一の処理を行うことができるサーバが複数系統存在するサーバグループやクラスタの構成が前提とされ、一部のサーバ毎に順に保守のための停止時間を設けてその間に効率的にメンテナンス処理を行うものとされている。
上記のような手法は、オンライン業務を行うサーバ(以下では「業務サーバ」と記載する場合がある)については適用が可能であるが、バッチ業務を行うサーバ(以下では「バッチサーバ」と記載する場合がある)については適用が困難である。オンライン業務は、通常、処理が短時間で終了するトランザクションが多量に発生する特性を有することから、複数系統の業務サーバを起動して負荷分散による処理能力向上と可用性向上を図る構成がとられ、業務中にメンテナンス対象のサーバを切り離して停止させることは比較的容易である。
一方で、バッチ業務は、通常、即時性の要求が高くないことから、複数系統のバッチサーバを用意して処理能力と可用性を向上させるという対応がとられずにシングルサーバとして構成される場合が多く、また、大量のデータに対して一括して処理することから処理時間が長時間になる場合があり、処理中の業務バッチプログラムをメンテナンスのために所望のタイミングで停止させることは困難である。
そこで本発明の目的は、バッチ業務や関連するオンライン業務への影響を最小限に抑えつつ、業務バッチプログラムが長時間稼働するバッチサーバに対するメンテナンスを行うバッチサーバメンテナンス方法を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
本発明の代表的な実施の形態によるバッチサーバメンテナンス方法は、1つ以上のバッチプログラムが実行中であるバッチサーバに対してメンテナンスを行うバッチサーバメンテナンス方法であって、(a)前記バッチサーバに対するメンテナンスを行うために起動されたメンテナンスプログラムが、前記バッチサーバに停止依頼フラグを立てさせる工程と、(b)前記各バッチプログラムが、前記バッチサーバに、実行中に所定の間隔で到来するチェックポイントのタイミング毎に、前記停止依頼フラグが立っているか否かを判定させ、前記停止依頼フラグが立っていない場合には実行を継続させ、前記停止依頼フラグが立っている場合にはそれぞれ停止完了フラグを立てて実行を停止させる工程と、(c)前記メンテナンスプログラムが、前記バッチサーバに、前記各バッチプログラムに係る前記停止完了フラグが立っているか否かを判定させ、前記各停止完了フラグが全て立っている場合に、前記バッチサーバに対するメンテナンスを行わせる工程と、を有するものである。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
すなわち、本発明の代表的な実施の形態によれば、バッチ業務や関連するオンライン業務への影響を最小限に抑えつつ、業務バッチプログラムが長時間稼働するバッチサーバに対するメンテナンスを行うことが可能となる。
本発明の一実施の形態であるバッチサーバメンテナンス方法の例について概要を示した図である。 本発明の一実施の形態のバッチサーバメンテナンス方法が適用される情報処理システムの構成例について概要を示した図である。 本発明の一実施の形態における業務バッチプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるメンテナンスプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における業務サーバプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるバッチ管理テーブルのデータ構成の例について概要を示した図である。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
上述したように、業務バッチプログラムが長時間稼働するバッチサーバは、処理中の業務バッチプログラムを停止させるのが困難であることから、メンテナンスのための停止時間を所望のタイミングで設けることが難しい。
また、業務バッチプログラムが稼働するバッチサーバの中には、他の業務サーバ等から、例えば、15分毎に1回や、1000件処理毎に1回などのタイミングでファイル転送によりデータが送信されるなど、所定の間隔でアクセスがされる場合がある。このような構成の場合に、例えば、業務サーバが、24時間365日もしくはこれに類する程度の常時稼働のシステムである場合は特に、バッチサーバについても常に稼働可能とされている必要があり、メンテナンスのための停止時間を設けることは困難である。また、バッチサーバについてメンテナンスを行うにしても、その間は、他の業務サーバがファイル転送等を停止してバッチサーバにアクセスしてこないよう制御するなどの対応が必要となる。
そこで、本発明の一実施の形態であるバッチサーバメンテナンス方法は、業務バッチプログラムに一時停止可能なチェックポイントを所定の間隔で設けておき、業務バッチプログラムから参照可能な記憶領域において、メンテナンスジョブ等により停止依頼フラグが立てられている場合に、業務バッチプログラムが次のチェックポイントで自発的に一旦終了することで、その後、バッチサーバに対してメンテナンス処理(メンテナンスジョブの実行等)を行うことを可能とするものである。また、メンテナンスの完了後は、フラグを解除した上で一旦終了されていた業務バッチプログラムをチェックポイントから再開する。
これにより、業務バッチプログラムを通常通り稼働させつつ、メンテナンス処理が必要なタイミングで停止依頼フラグを立てることで、業務バッチプログラムを一旦終了させ、メンテナンスのための停止時間を確保することが可能となる。
図1は、本発明の一実施の形態であるバッチサーバメンテナンス方法の例について概要を示した図である。バッチサーバ上で稼働する業務バッチプログラム11には、所定の間隔でチェックポイントCPが設けられており、業務バッチプログラム11は、チェックポイントCPが到来する毎に、停止依頼フラグ14が立っているか否かをチェックする。一方、メンテナンスプログラム12は、例えば、メンテナンス処理の実行が必要となったタイミングで起動され、停止依頼フラグ14を立てる(ONに設定する)。
停止依頼フラグ14がONに設定されると、業務バッチプログラム11は、次のチェックポイントCPのタイミングでこれを検知し、その後、停止完了フラグ16を立てる(ONに設定する)とともに異常終了する。メンテナンスプログラム12は、停止完了フラグ16がONに設定されていること、すなわち、業務バッチプログラム11が終了したことを確認した後、所望のメンテナンス処理を実行する。メンテナンス処理が完了すると、メンテナンスプログラム12は、停止依頼フラグ14および停止完了フラグ16を解除する。その後、業務バッチプログラム11は、前回異常終了したチェックポイントCPから処理を再開することができる。
<システム構成>
図2は、本発明の一実施の形態のバッチサーバメンテナンス方法が適用される情報処理システムの構成例について概要を示した図である。対象となる情報処理システムは、例えば、バッチサーバ10と、1つ以上の業務サーバ20とが、LAN(Local Area Network)等のネットワーク30を介して相互に通信可能なように接続された構成を有する。
バッチサーバ10は、バッチ業務を行うサーバ機器であり、例えば、図示しないOS(Operating System)やDBMS(DataBase Management System)などのミドルウェア上で稼働するソフトウェアにより実装される1つ以上の業務バッチプログラム11、およびメンテナンスプログラム12などの各プログラムを有し、これらを手動もしくは自動により実行することができる。また、データベースやファイル、メモリテーブル等により実装されるバッチ管理テーブル13、停止依頼フラグ14、およびサーバリスト15などの各データを有する。
業務バッチプログラム11は、業務サーバ20において実行されるオンライン業務と関連した業務処理を実行するバッチプログラムである。例えば、各業務サーバ20における一定期間の業務処理により発生した複数件の処理依頼データやログファイル等をネットワーク30を介して取得し、業務サーバ20におけるオンライン業務とは非同期で、一括して登録等の処理を行うようなプログラムが想定される。
業務バッチプログラム11は、上述したように、所定の間隔(例えば、15分毎に1回や、1000件処理毎に1回などのタイミング)で、自発的に一時停止可能なチェックポイントが実装されており、各チェックポイントにおいて後述する停止依頼フラグ14がONとなっている場合は、当該チェックポイントから再開可能なように必要な情報を記録した上で、一旦処理を異常終了するよう実装されているものとする。
メンテナンスプログラム12は、バッチサーバ10に対するメンテナンス処理を行うプログラムであり、メンテナンスを実行するタイミングで自動もしくは手動により起動される。メンテナンス処理としては、例えば、バッチサーバ10のOS等のミドルウェアや、業務バッチプログラムを含む他のソフトウェアに対するパッチの適用やバージョンアップ、バッチサーバ10のリブートなど、業務バッチプログラム11が処理を実行中の場合には実行できない内容の処理が含まれるものとする。
バッチ管理テーブル13は、業務バッチプログラム11の実行状況を管理するテーブルである。実行状況には、バッチサーバ10のメンテナンスのためにチェックポイントで一旦終了している状況についても含まれる。バッチ管理テーブル13の内容については後述する。
停止依頼フラグ14は、バッチサーバ10のメンテナンスを行うためにメンテナンスプログラム12が起動された際に、業務バッチプログラム11に対して停止を依頼するため、メンテナンスプログラム12によりONに設定されるフラグである。当該フラグは、例えば、各業務バッチプログラム11から参照可能な図示しないメモリやHDDなどの記憶装置上に設定することができる。バッチ管理テーブル13やその他のデータベース上に設定、保持するようにしてもよい。
サーバリスト15は、バッチサーバ10のメンテナンス処理を行う際に、これを通知する(停止依頼を行う)必要がある業務サーバ20の宛先情報などのリストを保持するデータである。通知対象となる業務サーバ20は、上述したように、例えば、バッチサーバ10に対して所定の間隔でファイル転送などのアクセスを行う業務サーバ20であり、バッチサーバ10のメンテナンス中に当該アクセスをさせないようにする必要があるものである。通知対象となる業務サーバ20が固定されている場合には不要とすることも可能である。サーバリスト15には、例えば、各業務サーバ20のホスト名やIPアドレスなどのリストが保持され、メンテナンスプログラム12は、この情報に基づいて、対象となる各業務サーバ20に対して停止依頼を通知する。
業務サーバ20は、図示しないクライアント端末等に対してネットワーク30等を介してオンライン業務機能を提供するサーバ機器であり、例えば、図示しないOSやDBMS、Webサーバプログラムなどのミドルウェア上で稼働するソフトウェアにより実装される業務サーバプログラム21などを有する。また、データベースやファイル、メモリテーブル等により実装される停止依頼フラグ22などのデータを有する。業務サーバプログラム21の種類や内容が異なる複数の業務サーバ20を有していてもよいし、1つの種類の業務サーバ20が複数台並列に設けられ、負荷分散処理を行う構成であってもよい。
業務サーバプログラム21は、クライアント端末等からの要求に基づいてオンライン業務処理を行うプログラムである。本実施の形態では、所定の間隔(例えば、15分毎に1回や、1000件処理毎に1回など)で、それまでに蓄積された複数件の処理依頼データやログファイル等をネットワーク30を介してバッチサーバ10にファイル転送し、業務バッチプログラム11による一括処理を依頼する機能を有するものとする。このとき、後述する停止依頼フラグ22がONとなっている場合は、バッチサーバ10へのファイル転送を行わない(例えば、フラグが解除されるまで待つ、もしくは保留して処理を継続する等)よう実装されているものとする。
停止依頼フラグ22は、バッチサーバ10においてメンテナンスプログラム12が起動された際に、メンテナンスプログラム12からの停止依頼の通知を受けてONに設定されるフラグである。当該フラグは、例えば、業務サーバプログラム21から参照可能な図示しないメモリやHDDなどの記憶装置上に設定することができる。
<処理の流れ>
図3は、バッチサーバ10上の業務バッチプログラム11の処理の流れの例について概要を示したフローチャートである。業務バッチプログラム11は、処理を開始すると、後述するバッチ管理テーブル13に情報を登録した上で、各処理ステップについて順次処理を繰り返すループ処理を開始する(S01〜S05)。
各処理ステップでは、まず、チェックポイントが到来しているか否かを判定する(S02)。チェックポイントは、上述したように、例えば、15分毎に1回や、1000件処理毎に1回などの所定の間隔で到来するよう実装してもよいし、業務バッチプログラムの一連の処理ステップの中で適切な場所に直接埋め込まれていてもよい。チェックポイントがまだ到来していない場合は、対象の処理ステップを通常通り実行し(S04)、次の処理ステップに移ってループ処理を継続する(S05、S01)。全ての処理ステップの実行がされ、ループ処理を終了すると、正常終了として業務バッチプログラム11を終了する(S06)。
ステップS02で、チェックポイントが到来している場合は、チェックポイント時の処理として、バッチサーバ10上で停止依頼フラグ14が立っている(ONに設定されている)か否かを判定する(S03)。停止依頼フラグ14がONに設定されていない場合は、ステップS04に進んで対象の処理ステップの実行を継続する。
ステップS03で、停止依頼フラグ14がONに設定されている場合は、業務バッチプログラム11の処理を一時停止する。すなわち、一時停止後に当該チェックポイントから処理を再開するために必要な情報を記録し(S07)、停止完了フラグ16をONに設定した上(S08)、異常終了として業務バッチプログラム11を終了する(S09)。なお、停止完了フラグ16は、本実施の形態では、後述するバッチ管理テーブル13上に業務バッチプログラム11毎に設定するものとしている。
以上の処理により、業務バッチプログラム11は、各チェックポイントにおいて、停止依頼フラグ14がONに設定されている場合には、自発的に一時停止(本実施の形態ではサスペンドではなく異常終了)することが可能となる。
図4は、バッチサーバ10上のメンテナンスプログラム12の処理の流れの例について概要を示したフローチャートである。メンテナンスプログラム12は、バッチサーバ10においてパッチ適用などのメンテナンスジョブを実行する必要が生じた際に起動される。起動されると、まず、バッチサーバ10上で、業務バッチプログラム11を一時停止させるための停止依頼フラグ14をONに設定する(S11)。
その後、関連する業務サーバ20に対しても、バッチサーバ10へのアクセスを停止するよう、停止依頼を通知する(S12)。関連する業務サーバ20の情報は、例えば、サーバリスト15を参照して取得することができる。なお、本実施の形態では、バッチサーバ10から各業務サーバ20に対して停止依頼の情報を通知するPUSH型の通知としているが、各業務サーバ20が適宜バッチサーバ10に停止依頼フラグ14の状況を問い合わせるPULL型の通知としてもよい。
その後、業務バッチプログラム11が全て停止したか否かを判定する(S13)。すなわち、対象の全ての業務バッチプログラム11が停止完了フラグ16をONに設定しているか否かを判定する。本実施の形態では、上述したように、各業務バッチプログラム11についての停止完了フラグ16の状況は、バッチ管理テーブル13上で管理される。業務バッチプログラム11のみに限らず、ステップS12で停止依頼を通知した全ての業務サーバ20がバッチサーバ10へのアクセスを停止したことも併せて確認するようにしてもよい。
ステップS13で、業務バッチプログラム11が全て停止していない場合は、一定時間Waitした後(S14)、ステップS13に戻って再度業務バッチプログラム11の停止を確認する。業務バッチプログラム11が全て停止した場合は、所望のメンテナンス処理を実行する(S15)。ここでは、メンテナンスプログラム12自身が、バッチサーバ10のOS等に対してパッチ適用等の処理を行ってもよいし、メンテナンス処理が実行可能な状態になったことをシステム管理者等に通知することで、手動でのメンテナンスを促すようにしてもよい。
メンテナンス処理が終了すると、メンテナンスプログラム12は、停止フラグを全てOFFに設定して解除し(S16)、処理を終了する。なお、停止フラグには、バッチサーバ10上の停止依頼フラグ14や業務サーバ20上の停止依頼フラグ22、およびバッチ管理テーブル13上の停止完了フラグ16などが含まれる。
以上の処理により、メンテナンスプログラム12(もしくはシステム管理者等)は、長時間稼働する業務バッチプログラム11を全て一時停止させて作業時間枠を強制的に形成した上でメンテナンス処理を実行することができる。
図5は、業務サーバ20上の業務サーバプログラム21の処理の流れの例について概要を示したフローチャートである。業務サーバプログラム21は、処理を開始すると、各処理ステップについて順次処理を繰り返すループ処理を開始する(S21〜S27)。
各処理ステップでは、まず、処理内容がバッチサーバ10へのアクセス(本実施の形態ではファイル転送)であるか否かを判定する(S22)。ファイル転送でない場合は、対象の処理ステップを通常通り実行し(S23)、次の処理ステップに移ってループ処理を継続する(S27、S21)。全ての処理ステップの実行がされ、ループ処理を終了すると、業務サーバプログラム21を終了する。
ステップS22で、処理ステップがファイル転送である場合は、業務サーバ20上で停止依頼フラグ22が立っている(ONに設定されている)か否かを判定する(S24)。上述したように、ローカルの停止依頼フラグ22の状態を確認するのに代えて、バッチサーバ10に対して停止依頼フラグ14の状態を問い合わせるようにしてもよい。停止依頼フラグ22がONに設定されていない場合は、通常通りバッチサーバ10へのファイル転送処理を実行し(S25)、次の処理ステップに移ってループ処理を継続する(S27、S21)。
一方、ステップS24で、停止依頼フラグ22がONに設定されている場合は、一定時間Waitした後(S26)、ステップS24に戻って再度停止依頼フラグ22の状態を確認する。すなわち、停止依頼フラグ22がOFFに設定される(解除される)まで、バッチサーバ10へのファイル転送を一時的に留保する。
なお、図5の例では、バッチサーバ10へのファイル転送を留保している間、通常の処理ステップについても処理が停止することになる。ここで、業務サーバプログラム21が画面等のユーザインタフェースをクライアント端末等に対して提供する構成の場合、ユーザに対する画面を介した通知として、例えば、バッチサーバ10上で停止依頼フラグ14が立っているのみの場合は「処理に時間がかかる可能性があります」などのメッセージを表示し、停止完了フラグ16が立っている場合は「処理完了まで○○分程度お待ちください」などのメッセージを表示するようにしてもよい。また、可能な場合には、ファイル転送を通常の処理ステップとは非同期とし、ファイル転送のみ留保して通所の処理ステップは継続されるようにしてもよい。
以上の処理により、業務サーバプログラム21は、バッチサーバ10がメンテナンス処理を行っている間は、バッチサーバ10へのファイル転送等によるアクセスを停止することができる。
<データ構成>
図6は、バッチサーバ10上のバッチ管理テーブル13のデータ構成の例について概要を示した図である。バッチ管理テーブル13は、業務バッチプログラム11の実行状況を管理するテーブルであり、例えば、プログラム名、起動日時、停止完了フラグ、チェックポイント、停止日時、再開日時、および終了日時などの各項目を有する。
プログラム名の項目は、対象の業務バッチプログラム11を一意に特定する名称やID等の情報を保持する。起動日時の項目は、対象の業務バッチプログラム11が起動した時点のタイムスタンプの情報を保持する。停止完了フラグの項目は、対象の業務バッチプログラム11が、停止依頼フラグ14がONに設定されているのに基づいて処理を一時停止したことを示すフラグの情報を保持する。チェックポイントの項目は、対象の業務バッチプログラム11が一時停止した時点のチェックポイントを特定する情報を保持する。当該チェックポイントは、対象の業務バッチプログラム11を再実行する際の開始ポイントとなる。
停止日時の項目は、対象の業務バッチプログラム11が一時停止(本実施の形態では、上述したようにサスペンドではなく異常終了)した時点のタイムスタンプの情報を保持する。再開日時の項目は、対象の業務バッチプログラム11が一時停止した後再実行された時点のタイムスタンプの情報を保持する。終了日時の項目は、対象の業務バッチプログラム11が処理を完了した時点のタイムスタンプの情報を保持する。
なお、図6で示した各テーブルのデータ構成(項目)はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
以上に説明したように、本発明の一実施の形態であるバッチサーバメンテナンス方法によれば、業務バッチプログラム11に一時停止可能なチェックポイントを所定の間隔で設けておき、業務バッチプログラム11から参照可能な記憶領域において、メンテナンスプログラム12により停止依頼フラグ14が立てられている場合に、業務バッチプログラム11が次のチェックポイントで自発的に一旦終了する。また、停止依頼フラグ14を立てる際に、関連する業務サーバ20に対しても停止依頼を行うことで、業務サーバ20上の業務サーバプログラム21は、バッチサーバ10へのアクセスを停止する。
これらの処理により、業務バッチプログラム11を通常通り稼働させつつメンテナンスのための停止時間を確保し、バッチサーバ10に対してメンテナンス処理を行うことが可能となる。また、メンテナンスの完了後は、フラグを解除した上で一旦終了されていた業務バッチプログラム11をチェックポイントから再開することができる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
本発明は、長時間のバッチ処理を行うサーバ機器のメンテナンス方法に利用可能である。
10…バッチサーバ、11…業務バッチプログラム、12…メンテナンスプログラム、13…バッチ管理テーブル、14…停止依頼フラグ、15…サーバリスト、16…停止完了フラグ、
20…業務サーバ、21…業務サーバプログラム、22…停止依頼フラグ、
30…ネットワーク、
CP…チェックポイント

Claims (4)

  1. 1つ以上のバッチプログラムが実行中であるバッチサーバに対してメンテナンスを行うバッチサーバメンテナンス方法であって、
    (a)前記バッチサーバに対するメンテナンスを行うために起動されたメンテナンスプログラムが、前記バッチサーバに停止依頼フラグを立てさせる工程と、
    (b)前記各バッチプログラムが、前記バッチサーバに、実行中に所定の間隔で到来するチェックポイントのタイミング毎に、前記停止依頼フラグが立っているか否かを判定させ、前記停止依頼フラグが立っていない場合には実行を継続させ、前記停止依頼フラグが立っている場合にはそれぞれ停止完了フラグを立てて実行を停止させる工程と、
    (c)前記メンテナンスプログラムが、前記バッチサーバに、前記各バッチプログラムに係る前記停止完了フラグが立っているか否かを判定させ、前記各停止完了フラグが全て立っている場合に、前記バッチサーバに対するメンテナンスを行わせる工程と、
    を有する、バッチサーバメンテナンス方法。
  2. 請求項1に記載のバッチサーバメンテナンス方法において、
    前記(a)工程では、さらに、前記メンテナンスプログラムが、前記バッチサーバに、当該バッチサーバに対してアクセスし得る他のサーバに対して停止依頼を通知させ、
    さらに、(d)前記バッチサーバから前記停止依頼の通知を受けた前記他のサーバが、前記バッチサーバに対するアクセスを停止する工程、を有する、バッチサーバメンテナンス方法。
  3. 請求項1に記載のバッチサーバメンテナンス方法において、
    さらに、(e)前記メンテナンスプログラムが、前記バッチサーバに、前記バッチサーバに対するメンテナンスが完了した後、前記停止依頼フラグおよび前記停止完了フラグを解除させる工程と、
    (f)再起動された前記バッチプログラムが、前記バッチサーバに、前記(b)工程において実行を停止された際の前記チェックポイントから実行を再開させる工程と、
    を有する、バッチサーバメンテナンス方法。
  4. 請求項2に記載のバッチサーバメンテナンス方法において、
    さらに、(g)前記他のサーバが、前記バッチサーバ上に前記停止依頼フラグもしくは前記停止完了フラグが立っている場合に、クライアント端末に対して、処理に時間を要する旨を通知する画面を表示させる工程、を有する、バッチサーバメンテナンス方法。

JP2014140112A 2014-07-08 2014-07-08 バッチサーバメンテナンス方法 Active JP6318031B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014140112A JP6318031B2 (ja) 2014-07-08 2014-07-08 バッチサーバメンテナンス方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014140112A JP6318031B2 (ja) 2014-07-08 2014-07-08 バッチサーバメンテナンス方法

Publications (2)

Publication Number Publication Date
JP2016018350A JP2016018350A (ja) 2016-02-01
JP6318031B2 true JP6318031B2 (ja) 2018-04-25

Family

ID=55233541

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014140112A Active JP6318031B2 (ja) 2014-07-08 2014-07-08 バッチサーバメンテナンス方法

Country Status (1)

Country Link
JP (1) JP6318031B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113448711A (zh) * 2021-07-12 2021-09-28 中国银行股份有限公司 一种批量服务停机方法和装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10320184A (ja) * 1997-05-21 1998-12-04 Oki Electric Ind Co Ltd ソフトウェアバージョン管理システム
JPH11191092A (ja) * 1997-12-26 1999-07-13 Hitachi Ltd 業務アプリケーションのステータスを管理するシステム
JP4773715B2 (ja) * 2004-12-01 2011-09-14 富士通株式会社 チェックポイント取得方法
JP5419166B2 (ja) * 2010-07-22 2014-02-19 日本電信電話株式会社 チェックポイント作成装置、チェックポイント作成システム、チェックポイント作成方法及びチェックポイント作成プログラム
JP2014120123A (ja) * 2012-12-19 2014-06-30 Hitachi Ltd 情報処理装置及び情報処理方法

Also Published As

Publication number Publication date
JP2016018350A (ja) 2016-02-01

Similar Documents

Publication Publication Date Title
US6971095B2 (en) Automatic firmware version upgrade system
US9311199B2 (en) Replaying jobs at a secondary location of a service
US10491704B2 (en) Automatic provisioning of cloud services
US8266301B2 (en) Deployment of asynchronous agentless agent functionality in clustered environments
US9348630B2 (en) Virtual machine control program in a cloud computing environment, virtual machine control method in a cloud computing environment, virtual machine control apparatus, and cloud computing system
CN113569987A (zh) 模型训练方法和装置
WO2016045439A1 (zh) 一种vnfm容灾保护的方法、装置和nfvo、存储介质
US11449350B2 (en) Systems and methods for automatically updating compute resources
CN111666134A (zh) 一种分布式任务调度的方法和系统
JP6268991B2 (ja) 情報処理システム、情報処理装置及びプログラム
US8468386B2 (en) Detecting and recovering from process failures
JP2004086769A (ja) アプリケーションの更新処理方法、更新処理システム及び更新処理プログラム
JP5319619B2 (ja) スケールアウト構成に対応したソフトウェア配布システム、方法、及びプログラム
JP6318031B2 (ja) バッチサーバメンテナンス方法
JP2014013473A (ja) ソフトウェア更新装置
JP7243207B2 (ja) 情報処理システム、情報処理装置及びプログラム
US20170017520A1 (en) System and control method
JP5632403B2 (ja) タスク管理システム、タスク管理サーバ、タスク管理方法、及びタスク管理プログラム
TWI740886B (zh) 日誌收集客戶端及其升級方法
CN110188008B (zh) 作业调度主备切换方法、装置、计算机设备及存储介质
US9170802B2 (en) Method and information processing apparatus for extracting software correction patch for virtual machine
JP2013186765A (ja) バッチ処理システム、進捗状況確認装置、進捗状況確認方法、及びプログラム
JP5574905B2 (ja) モジュール配布システム
JP2010224812A (ja) ジョブ管理システムおよび方法
US20230367632A1 (en) Job management system and control method thereof

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170501

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180226

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180313

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180402

R150 Certificate of patent or registration of utility model

Ref document number: 6318031

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250