JP5054495B2 - 計算機システム、データ管理方法、データ管理プログラム及び処理装置 - Google Patents

計算機システム、データ管理方法、データ管理プログラム及び処理装置 Download PDF

Info

Publication number
JP5054495B2
JP5054495B2 JP2007310068A JP2007310068A JP5054495B2 JP 5054495 B2 JP5054495 B2 JP 5054495B2 JP 2007310068 A JP2007310068 A JP 2007310068A JP 2007310068 A JP2007310068 A JP 2007310068A JP 5054495 B2 JP5054495 B2 JP 5054495B2
Authority
JP
Japan
Prior art keywords
processing
file
program
update
data
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.)
Expired - Fee Related
Application number
JP2007310068A
Other languages
English (en)
Other versions
JP2009134510A (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007310068A priority Critical patent/JP5054495B2/ja
Publication of JP2009134510A publication Critical patent/JP2009134510A/ja
Application granted granted Critical
Publication of JP5054495B2 publication Critical patent/JP5054495B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Stored Programmes (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、複数の処理装置が処理内容の同一性を維持しながらプログラムを実行する分散型計算機システムに関し、特に、分散型計算機システム上で動作するプログラムが使用中のデータファイルを更新する技術に関する。
列車集中制御装置や金融基幹系システムでは、業務を停止することなく、且つ誤動作を起こすことなく、オンライン処理を継続することが求められる。このようなシステムでは、プロセッサ、メモリ、バス等の主要な構成要素を全て多重化することによって、任意の構成要素に故障が発生した時に、正常な処理を継続できることを目的としたFTC(Fault Tolerant Computer)が採用されている。
FTCの一つの形態として、専用ハードウェアの利用による高コスト化を回避するために、市場で大量に流通しているPCアーキテクチャに基づく処理装置をネットワークで接続し、ソフトウェアによって多重並列処理を実行させる形態がある。
ソフトウェアを使用したFTCの一つの形態として、同期タイミングを限定して、処理装置間の処理を実行する形態がある。これは、ゲートウェイ装置が、ブロードキャストを用いて、外部からのメッセージを全処理装置へ入力し、各処理装置は処理結果をメッセージとして出力し、ゲートウェイ装置は、多数決処理を用いて、各処理装置からの出力を単一の出力メッセージに統合するシステムでがある。各処理装置における処理は、入力メッセージの処理を開始した時点ではほぼ同期しているが、割り込みの発生タイミングの違い等の原因によって、入力メッセージの処理が完了するまでにズレを生じる。本明細書では、このような多少のズレを許容するFTCの形態を「緩い同期」を実施するFTCと呼ぶ。
一方、FTCを含む多重並列実行型の分散システムでは、ファイルを同期して更新する技術が必要となる。このような、分散システムにおけるファイル更新の技術としては、特許文献1に記載された技術がある。
特許文献1に開示された分散システムは、少なくとも一つのコントローラに接続された少なくとも二つの計算エレメントを含む計算機システムである。各計算エレメントは他の計算エレメントのクロックとは非同期に動作するクロックを有する。計算エレメントは計算エレメントのそれぞれが命令の第1ストリームをエミュレートされたクロック・ロックステップにおいて実行される第1モードで動作する。そして、計算エレメントのそれぞれが命令の第2ストリームを命令ロックステップにおいて実行する第2モードで動作する。特許文献1に開示された分散システムでは、ファイル更新を含む全ての処理をロックステップ方式により同期しているため、単一の命令が時間的に同時に全ての計算エレメントへ適用される。
特開2001−523855号公報
「緩い同期」を実施するFTCでは、実行中のプログラムを停止することなく、プログラムによって使用されるデータファイルを古いバージョンから新しいバージョンへ更新することが困難になるという問題がある。
例えば、特許文献1に開示されたように、ある時刻を指定してファイルを更新する方法では、「緩い同期」を実施している場合、ファイルを同期して更新できない。「緩い同期」を実施するFTCにおいて、各処理装置は、同期タイミング以外では、同一の処理を異なる時刻に実行するため、ある時刻を指定してデータファイルを更新することはできない。
本発明は、「緩い同期」を実施するFTCにおいて、FTCを構成する複数の処理装置間で、処理内容を一致させながら、実行中のプログラムが使用中のデータファイルを同期して更新することを可能にすることを目的とする。
本発明の代表的な一例を示せば以下の通りである。すなわち、多重並列処理を実行する複数の処理装置と、前記複数の処理装置の動作を管理する管理装置と、前記複数の処理装置と前記管理装置とを接続するネットワークとを備え、前記各処理装置が処理の同一性を維持しながらプログラムを実行する計算機システムであって、前記処理装置は、前記プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、前記プログラムの実行時に使用されるデータを格納する記憶部と、前記ネットワークと接続されるインターフェースとを備え、前記管理装置は、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、前記管理装置は、前記複数の処理装置において実行中のプログラムの処理の進捗状態を取得し、前記取得した進捗状態を参照して、全ての前記処理装置がデータを更新可能な論理的タイミングを求め、前記求められた論理的タイミングを前記プログラムが使用するデータを更新すべき論理的タイミングと決定し、前記処理装置は、前記管理装置によって決定されたデータ更新の論理的タイミングを取得し、前記実行中のプログラムの処理が前記取得した論理的タイミングへ到達したか否かを監視し、前記プログラムの処理が前記取得した論理的タイミングへ到達したときに、当該実行中のプログラムを停止することなくデータを更新することを特徴とする。
本発明の一実施形態によると、データファイルのバージョンの切り替えの前後で処理内容の論理的な同期を維持することができ、プログラムを停止することなくデータファイルのバージョンを更新することができる。
<実施形態1>
以下、本発明に係る分散システムにおけるファイル更新処理及びシステムの実施の一形態を添付図面を参照して説明する。
第1の実施の形態では、4台の処理装置が論理的に同一の処理を多重並列して実行するFTCシステムが、リアルタイム性を満たして制御信号による処理を実行している状態において、実行されている処理を止めることなく、処理装置上で動作するユーザプログラム(UP:User Program)が利用中のデータファイルを更新する方法を説明する。
なお、本実施の形態では処理装置が4台の場合について説明するが、本発明は2台以上の任意の台数の処理装置を備えるシステムに適用可能である。
図1は、本発明の実施の形態のFTCシステムの構成例を示すブロック図である。
本発明の実施の形態のFTCシステムは、管理端末101、複数の処理装置102、ゲートウェイサーバ103及び内部ネットワーク104によって構成される。
ゲートウェイサーバ103は、内部ネットワーク104と外部ネットワーク105との間に位置し、FTCシステムの外部ネットワーク105との入出力処理を実施する計算機である。ゲートウェイサーバ103は、外部ネットワーク105から入力信号を受信すると、入力メッセージを作成し、内部ネットワーク104へ同報送信(ブロードキャスト)する。
また、ゲートウェイサーバ103は、処理装置102が出力したメッセージを、内部ネットワーク104を介して受信する。そして、ゲートウェイサーバ103は、受信した出力メッセージに対して多数決処理を実行し、多数決処理の結果から出力信号を作成し、作成された出力信号を外部ネットワーク105へ送信する。
管理端末101は、CPU、メモリ、記憶装置(ファイル格納部114)及びインターフェース(通信部114、ユーザ操作部111)を備え、ユーザが処理装置102及びゲートウェイサーバ103を操作するために使用する計算機である。
管理端末101は、ユーザ操作部111、更新制御部112、ファイル格納部113及び通信部114を備える。ユーザ操作部111は、ユーザからの入力を受け取るインターフェースである。更新制御部112は、ファイル更新処理を実行する。ファイル格納部113は、更新ファイルを格納する記憶装置である。
通信部114は、内部ネットワーク104へデータを送受信するインターフェースである。管理端末101は、通信部114を介して、内部ネットワーク104と接続されている。
ユーザ操作部111は、ユーザからファイル更新要求を受け取り、受け取ったファイル更新要求を更新制御部112へ送る。
更新制御部112は、ユーザ操作部111からユーザが入力したファイル更新要求を受け取ると、ファイル更新処理を実行する。なお、更新制御部112は、入力メッセージ1200(図12参照)のデータ種別1202毎に、入力メッセージを処理する処理UP名1402と最短処理時間1403を記録した入力メッセージ最短処理時間テーブル1400(図14参照)を備える。なお、入力最短処理時間テーブルの内容は、ユーザによって予め設定される。
処理装置102は、CPU、メモリ、記憶装置(ファイル格納部102)及びインターフェース(通信部124)を備える計算機である。すなわち、処理装置102は、CPUがメモリに格納されたプログラムを実行することによって実現される、ファイル格納部121、ファイルアクセス部122、UP実行部123、通信部125及び更新制御部126を備え、入力メッセージに応じた処理を実行する計算機である。より具体的には、処理装置102は、ゲートウェイサーバ103から入力メッセージ1200(図12参照)を受信すると、受信した入力メッセージに応じた処理を実行し、実行された処理の結果を出力メッセージ1200(図12参照)として送信する。
通信部124は、内部ネットワーク104へデータを送受信するインターフェースである。処理装置102は、通信部124を介して、内部ネットワーク104と接続されている。
また、通信部124は、入力メッセージバッファテーブル1600(図16参照)及びメッセージIDテーブル1700(図17参照)を格納する入力メッセージバッファ125を備える。通信部124は、内部ネットワーク104から入力メッセージを受信すると、受信した入力メッセージを入力メッセージバッファ125の最後尾に格納する。一方、通信部124は、内部ネットワーク104から、更新命令メッセージ1300(図13参照)を受信すると、受信した更新命令メッセージをファイル更新制御部126に送る。
ファイルアクセス部122は、UP実行部123からのアクセス要求に基づいて、ファイル格納部121にアクセスし、アクセスした結果をUP実行部123へ返す。ファイルアクセス部122は、ファイル毎に、そのファイルの最新バージョンの番号の一覧を格納した最新ファイルバージョン番号テーブル1900(図19参照)を備える。さらに、ファイルアクセス部122は、ファイル毎に、ファイル使用中のユーザプログラム及び使用中のファイルのバージョン番号を記録した使用ファイルバージョン番号テーブル2000(図20参照)を備える。
UP実行部123は、一つ又は複数のユーザプログラムを、シングルプロセッサ又はマルチプロセッサ上で動作させ、動作しているユーザプログラムの指示に従って処理を実行する。
更新制御部126は、更新命令メッセージ1300(図13参照)を受け取ると、ファイル更新処理を実行する。更新制御部126は、ユーザプログラム毎に、ファイルのバージョンを更新するタイミングを示すメッセージIDの一覧を記録したファイル更新ポイントテーブル1800(図18参照)を備える。処理される入力メッセージのメッセージIDが、ファイル更新ポイントテーブルに記録されたファイル更新ポイントと一致した場合、該入力メッセージを処理する直前で、ファイルのバージョンを更新する。
管理端末101及び処理装置102は、ブレードサーバ、ワークステーション、パーソナルコンピュータ等の計算機に実装される。
また、内部ネットワーク104及び外部ネットワーク105は、Ethernet(登録商標、以下同じ)、無線LAN等による有線又は無線のネットワークがよい。
図14は、更新制御部112に備わる入力メッセージ最短処理時間テーブル1400の構成を示す説明図である。
入力メッセージ最短処理時間テーブル1400は、データ種別1401、処理UP名1402及び最短処理時間1403を含む。例えば、ユーザプログラム1(UP1)がデータ種別100のメッセージを処理するのに、最低10ミリ秒は必要であることを表す。
図15は、更新制御部112に備わるファイル更新可能範囲テーブル1500の構成を示す説明図である。
ファイル更新可能範囲テーブル1500は、UP名1501及びファイル更新可能範囲1502を含む。ファイル更新可能範囲テーブル1500は、各処理装置102に対応して作成される。例えば、対応する処理装置においてユーザプログラム1がデータファイルを更新することが可能なタイミングが、メッセージIDが10014、10017又は10020の入力メッセージを処理する直前であることを表す。
図16は、通信部124に備わる入力メッセージバッファテーブル1600の構成を示す説明図である。
入力メッセージバッファテーブル1600は、順序1601、メッセージID1602、データ種別1603及びデータ部1604を含む。入力メッセージバッファテーブル1600の各エントリは、処理装置102が受信した入力メッセージに対応し、順序1601が小さいほど早く受信したメッセージであることを示す。例えば、入力メッセージバッファに格納されている入力メッセージの中で5番目に早く受信したメッセージはメッセージIDが10014、データ種別が100、データ部が001010…であることを表す。
図17は、通信部124に備わるメッセージIDテーブル1700の構成を示す説明図である。
メッセージIDテーブル1700は、順序1701、メッセージID1702及びメッセージ種別1703を含む。メッセージIDテーブル1700は、メッセージバッファテーブル1600からデータ部1604を削除することによって作成される。
図18は、更新制御部126に備わるファイル更新ポイントテーブル1800の構成を示す説明図である。
ファイル更新ポイントテーブル1800は、UP名1801、更新ポイント1802から構成される。例えば、ファイル更新ポイントテーブル1800は、ユーザプログラム1が使用中のファイルを更新するタイミングがメッセージIDが10017である入力メッセージを処理する直前であることを表す。
図19は、ファイルアクセス部122に備わる最新ファイルバージョン番号テーブル1900の構成を示す説明図である。
最新ファイルバージョン番号テーブル1900は、ファイル名1901及び最新バージョン番号1902を含む。例えば、ファイル格納部121に格納されたfile1の中で最新のバージョンは11.0であることを表す。
図20は、ファイルアクセス部122に備わる使用ファイルバージョン番号テーブル2000の構成を示す説明図である。
使用ファイルバージョン番号テーブル2000は、ファイル名2001、使用UP名2002及び使用バージョン番号2003を含む。例えば、file2を使用しているユーザプログラムがユーザプログラム2及びユーザプログラム3であり、ユーザプログラム2はバージョン5.0のfile2を、ユーザプログラム3はバージョン5.0のfile2を使用していることを表す。
図12は、処理装置102とゲートウェイサーバ103との間で交換される入出力メッセージ1200のメッセージフォーマットを示す説明図である。
入出力メッセージ(入力メッセージ及び出力メッセージ)1200は、メッセージIDフィールド1201、データ種別フィールド1202及びデータ部フィールド1203を含む。メッセージID1201は、複数の処理装置102が複数の処理装置102が送信する出力メッセージが、同じ入力メッセージに対応するメッセージであるかを判定する為に使用される。データ種別フィールド1202は、データ部フィールド1203に格納されたデータの種別を示す。
図13は、更新命令メッセージ1300のメッセージフォーマットを示す説明図である。
更新命令メッセージ1300は、ファイル名フィールド1301、バージョン番号フィールド1302及びファイル本体フィールド1303を含む。ファイル名フィールド1301はファイル本体1303に格納されるファイルの名称を示し、バージョン番号フィールド1302はファイル本体1303に格納されるファイルのバージョンを示す。
図2は、処理装置102におけるファイルアクセス処理のフローチャートである。
まず、UP実行部123は、ファイル読み書き要求をファイルアクセス部122に送る(ステップ201)。
ファイルアクセス部122は、ファイル読み書き要求を受け取ると、指定されたファイルについて、使用ファイルバージョン番号テーブル2000(図20)を参照して、要求元のユーザプログラム名に対応する使用バージョン番号を検索する(ステップ202)。例えば、要求元のユーザプログラム名がUP2、指定されたファイル名がfile2である場合、使用するバージョン番号は5.0となる。
ファイルアクセス部122は、ファイル格納部121にアクセスし、検索されたバージョンのファイルに対し、要求されたファイル読み書きをする(ステップ203)。
ファイルアクセス部122は、ファイル読み書きの結果をUP実行部123に返す(ステップ204)。
図3は、処理装置102におけるUP実行処理のフローチャートである。
まず、UP実行部123は、データ種別1202を指定して、入力メッセージ1200(図12)を通信部124に要求する(ステップ301)。
更新制御部126は、ファイル更新の要否を判断し、必要であればファイル更新処理を実行する(ステップ302)。ファイル更新処理の詳細は図10にて説明する。
通信部124は、入力メッセージバッファ125から、指定されたデータ種別1202に対応する順序1601が最も小さい入力メッセージを取り出し、データ部1203をUP実行部123へ渡す(ステップ303)。
UP実行部123は、受け取ったデータ部1203を処理し(ステップ304)、処理の結果を通信部124に返す(ステップ305)。
通信部124は、入力メッセージと同じ値を、メッセージID1201及びデータ種別1202へ設定し、受け取った処理の結果をデータ部1203へ設定し、出力メッセージ1200(図12)を作成する(ステップ306)。
通信部124は、作成された出力メッセージをゲートウェイサーバ103へ送信する(ステップ307)。
図4は、ファイル更新処理のフローチャートである。
まず、管理端末101のユーザ操作部111は、ユーザの入力を受けると、更新制御部112ではその内容に従い更新命令メッセージ1300(図13)を作成する。そして、作成された更新命令メッセージを、通信部114を介して全ての処理装置102へ送信する。(ステップ401)。
処理装置102の更新制御部126は、通信部124を介して更新命令メッセージを受信すると、受信した更新命令メッセージに格納された新ファイルを、ファイル格納部121に格納する(ステップ402)。
処理装置102の更新制御部126は、メッセージIDテーブル1700(図17)を作成し、作成されたメッセージIDテーブルを、通信部124を介して管理端末101へ送信する(ステップ403)。
管理端末101の更新制御部112は、全ての処理装置102からメッセージIDテーブルを受信し、受信したメッセージIDテーブルに基づいてファイル更新ポイントテーブル1800(図18)を作成し、作成されたファイル更新ポイントテーブルを、全ての処理装置102へ送信する(ステップ404)。
処理装置102がファイル更新ポイントテーブルを受信すると、受信したファイル更新ポイントテーブルを、更新制御部126のファイル更新ポイントテーブルにマージする(ステップ405)。
処理装置102は、ユーザプログラムが入力メッセージを取得すると、ファイル更新の要否を判定する。ファイル更新が必要であると判定されると、ユーザプログラムのファイル読み書き対象を新ファイルへ切り替える(ステップ406)。
処理装置102は、新しいファイルへの切換が完了した後、古いファイルをファイル格納部121から削除する(ステップ407)。このとき、仕様ファイルバージョン番号テーブル2000を参照して、古いファイルを使用しているユーザプログラムがないことを確認した後に、古いファイルをファイル格納部121から削除するとよい。
図5は、ファイル更新開始処理(図4のステップ401)のフローチャートである。
まず、ユーザ操作部111は、ユーザから更新対象のファイルのファイル名及び更新後のバージョン番号の入力を受けると、入力されたファイル名及びバージョン番号を更新制御部112に送る(ステップ501)。
更新制御部112は、ファイル名及びバージョン番号を受けると、受け取ったファイル名とバージョン番号を持つファイルを、ファイル格納部113から取得する。そして、ファイル名、バージョン番号及び取得したファイル本体に基づいて、更新命令メッセージを作成し、作成された更新命令メッセージを通信部114に送信する(ステップ502)。
通信部114は、受け取った更新命令メッセージを送信する(ステップ503)。
図6は、ファイル格納処理(図4のステップ402)のフローチャートである。
まず、通信部124は、更新命令メッセージを受信すると、受信した更新命令メッセージを更新制御部126に送る(ステップ601)。
更新制御部126は、受け取った更新命令メッセージから、ファイル名1301、バージョン番号1302、及びファイル本体1303を取得する。そして、取得したファイル名及びバージョン番号を指定して、ファイル格納部121にファイル本体を格納する(ステップ602)。
更新制御部126は、ファイルアクセス部122の最新ファイルバージョン番号テーブル1900(図19)の、格納したファイル名に対応するバージョン番号を、格納時に指定したバージョン番号で上書きする(ステップ603)。
図7は、処理装置処理状況収集処理(図4のステップ403)のフローチャートである。
まず、更新制御部126は、通信部124の入力メッセージバッファ125に基づいて、メッセージIDテーブル1700(図17)を作成し、作成されたメッセージIDテーブルを通信部に124に送る(ステップ701)。
通信部124は、作成されたメッセージIDテーブルを管理端末101へ送信する(ステップ702)。
図8は、ファイル更新ポイント決定処理(図4のステップ404)のフローチャートである。
まず、通信部114は、メッセージIDテーブルを受信すると、受信したメッセージIDテーブルを更新制御部112に送る(ステップ801)。
更新制御部112は、受信したメッセージIDテーブル及び入力メッセージ最短処理時間テーブルを参照して、各ユーザプログラムについて、充分な時間が経過した後に処理されるメッセージIDを決定する。そして、決定されたメッセージIDを、メッセージIDテーブルの送信元の処理装置102毎に、ファイル更新可能範囲テーブル1500(図15)に書き込む(ステップ802)。
更新制御部112は、全ての処理装置102からメッセージIDテーブルを受信して処理したか否かを判定する(ステップ803)。一部の処理装置102からメッセージIDテーブルを受信しておらず、又は受信したメッセージIDテーブルの一部が処理されていない場合、更新制御部112は、通信部114がメッセージIDテーブルを受信するのを待ってステップ801に戻る。全ての処理装置102からメッセージIDテーブルを受信し、かつ受信したメッセージIDテーブルの処理が完了している場合、更新制御部112は、空のファイル更新ポイントテーブルを作成する(ステップ804)。
更新制御部112は、全て(本実施の形態では4台)の処理装置102について、ファイル更新可能範囲テーブルの、ファイル更新可能範囲を比較する。更新制御部112は、比較したファイル更新可能範囲の中で、全ての処理装置102が更新可能なタイミングを、ファイル更新ポイントとして決定する(ステップ805)。なお、全ての処理装置102が更新可能なタイミングが得られない場合、再度ステップ401からファイル更新処理をする。
更新制御部112は、選択したユーザプログラム、と決定されたファイル更新ポイントとの組を、ファイル更新ポイントテーブル1800(図18)に追加する(ステップ806)。
更新制御部112は、全てのユーザプログラムについてファイル更新ポイントを決定したか否かを判定する(ステップ807)。一部のユーザプログラムのファイル更新ポイントが決定されていない場合、更新制御部112は、未選択のユーザプログラムを選択しステップ805に戻る。全てのユーザプログラムについてファイル更新ポイントの決定が完了している場合、更新制御部112は、作成されたファイル更新ポイント一覧を通信部114に送り、通信部114は、受け取ったファイル更新ポイント一覧を全処理装置102へ同報送信(ブロードキャスト)する(ステップ808)。
図11は、ファイル更新ポイント決定処理(図4のステップ404)によるデータの変遷を説明する図である。
本実施の形態では、各ユーザプログラムに対応するファイル更新ポイントを決める際、全ての処理装置102がファイルを更新可能なタイミングをファイル更新ポイントとして採用している。
ステップ801において、通信部114は、メッセージIDテーブル1101を受信すると、受信したメッセージIDテーブル1101を更新制御部112に送る。
ステップ802において、更新制御部112は、受け取ったメッセージIDテーブル1101と入力メッセージ最短処理時間テーブル1102から、処理装置A上で動作するユーザプログラムの処理スケジュール1103を算出する。ユーザプログラム1について算出する場合、まず入力メッセージ最短処理時間テーブル1102からユーザプログラム1が処理するデータ種別が100であることを調べる。次に、メッセージIDテーブル1101からデータ種別が100であるメッセージのメッセージIDを取得し、取得したメッセージIDを処理する順番に並べる。
図11に示す例では、最初にIDが10010のメッセージを処理開始し、その後10ミリ秒以上の間隔を開けてIDが10011、10014、10017、10020のメッセージを順に処理する。ユーザプログラム2、ユーザプログラム3についても同様の方法でメッセージの処理順番を求める。
ID更新制御部112は、処理スケジュール1103を使用して、充分な時間の経過後に処理予定のメッセージIDを特定する。ここで充分な時間とは、ファイル更新ポイントテーブル1107の作成を完了し、処理装置A〜Dにファイル更新ポイントテーブル1107を登録するための充分な時間である。図11に示す例では、ユーザが事前に測定した結果、ネットワーク送受信時間が最大2ミリ秒必要で、管理端末101及び処理装置102での処理時間が最大10ミリ秒必要となる。よって、合計12ミリ秒を充分な時間として想定し、12ミリ秒経過(1104)以降に処理予定のメッセージIDの範囲1105を特定している。
更新制御部112は、充分な時間の経過後に処理予定のメッセージIDの範囲1105から、ファイル更新可能範囲テーブル1106を作成する。
更新制御部112は、処理装置B〜Dについても、同様にメッセージIDテーブル1102を受信し、ファイル更新可能範囲テーブル1106を作成する。
その後、ステップ804において、更新制御部112は、空のファイル更新ポイントテーブル1107を作成する。
ステップ805において、更新制御部112は、ステップ803において受信した処理装置A〜Dのファイル更新可能範囲テーブル1106を比較し、ユーザプログラム1については、10014、10017、10020が、4つの処理装置に対するファイル更新可能範囲と分かるため、これらの中で最も早く処理される10014をユーザプログラム1のファイル更新ポイントとして決定する。
そして、ステップ806において、更新制御部112は、ユーザプログラム1と10014の組をファイル更新ポイントテーブル1107に追加する。
更新制御部112は、同様にユーザプログラム2及びユーザプログラム3についてもファイル更新ポイント求め、それぞれ10021及び10019をファイル更新ポイントとして決定し、ファイル更新ポイントテーブル1107に追加する。
ステップ808において、更新制御部112は、作成したファイル更新ポイント一覧1107を通信部114に送る。通信部114は、受け取ったファイル更新ポイント一覧1107を処理装置A〜Dへ同報送信する。
図9は、ファイル更新ポイント登録処理(図4のステップ405)のフローチャートである。
まず、通信部124は、管理端末101から、ファイル更新ポイント一覧を受信する(ステップ901)。
その後、通信部124は、受信したファイル更新ポイント一覧の項目を、更新制御部126のファイル更新ポイント一覧の各項目に上書きする(ステップ902)。
図10は、ファイル更新処理(図4のステップ406)のフローチャートである。なお、このファイル更新処理は、ステップ301でUP実行部123が通信部124に入力メッセージを要求してから、通信部124がUP実行部123に入力メッセージのデータ部を送るまでに実行される処理である。
まず、通信部124は、入力メッセージバッファ125に格納された入力メッセージの中で、指定されたデータ種別とデータ種別が一致し、最も早く入力メッセージバッファ125に追加された入力メッセージを取得して、取得した入力メッセージをキューから削除し、要求元ユーザプログラム名と取得した入力メッセージのメッセージIDを更新制御部126へ送る(ステップ1001)。
更新制御部126は、更新制御部126のファイル更新ポイント一覧から、要求元ユーザプログラム名に対応するファイル更新ポイントを検索する(ステップ1002)。
更新制御部126は、ファイル更新ポイントを発見したか否かを判定する(ステップ1003)。
ファイル更新ポイントを発見しない場合、通信部124は、入力メッセージのデータ部をUP実行部123に送り、処理1007に進む。一方、ファイル更新ポイントを発見した場合、更新制御部126は、通知されたメッセージIDとファイル更新ポイントを比較する(ステップ1004)。
更新制御部126は、通知されたメッセージIDとファイル更新ポイントとが一致するか判定する(ステップ1005)。
メッセージIDとファイル更新ポイントとが一致しない場合、通信部124は、入力メッセージのデータ部をUP実行部123に送り、ステップ1007に進む。一方、メッセージIDとファイル更新ポイントとが一致する場合、更新制御部126は、ファイルアクセス部122に要求元ユーザプログラム名を通知する。そして、ファイルアクセス部122は、最新ファイルバージョン番号テーブルの、全てのファイルについて、要求元ユーザプログラムに対応するバージョン番号を取得し、使用ファイルバージョン番号テーブル2000(図20)の、全てのファイルについて、要求元ユーザプログラムに対応する使用バージョン番号を、取得したバージョン番号で上書きして更新する(ステップ1006)。
通信部124は、UP実行部123に、入力メッセージのデータ部を送る(ステップ1007)。
以上説明したように、本発明の第1の実施形態によると、データファイルのバージョンの切り替えの前後で処理内容の論理的な同期を維持することができ、プログラムを停止することなくデータファイルのバージョンを更新することができる。従って、分散処理システムにおいて、業務実行中にデータファイルを更新することができるようになり、多重並列実行型の分散システムを従来よりも柔軟に運用できるようになる。
<実施形態2>
次に、本発明の第2の実施の形態について説明する。
前述した第1の実施の形態では、メッセージを処理するタイミングを、ファイル更新タイミングに利用したが、第2の実施の形態では、タイマを用いたユーザプログラムの周期処理を実行するタイミングを、ファイル更新タイミングとする。以下、第2の実施の形態のファイル更新方法を説明する。
第2の実施の形態の処理装置102のUP実行部123は、一定周期で処理を実行するタイマを備える。
タイマは、一定の周期毎に、ユーザプログラムを実行させるためのデータ部が空のメッセージを作成し、入力メッセージバッファへ追加する。この空のメッセージのメッセージIDは異なるものを周期毎に繰り返して用い、且つ全処理装置で共通な数値を用いるとよい。
第2の実施の形態の入力メッセージの処理方法は前述した第1の実施の形態と同じである。
以上説明した第2の実施の形態は、前述した第1の実施の形態と組み合わせて用いるとより効果がある。
<実施形態3>
次に、本発明の第3の実施の形態について説明する。
前述した第1の実施の形態では、単一のファイルを更新対象としたが、第3の実施の形態では、複数のファイルを同時に更新する。以下、第3の実施の形態のファイル更新方法を説明する。
処理装置102のファイル格納部121は、ユーザの設定に基づいて、一つ以上のファイルによって構成されるグループへファイル群を分類する。
図21は、第3の実施の形態のファイルアクセス部122に備わる使用ファイルバージョン番号テーブル2000の構成を示す説明図である。
第3の実施の形態の使用ファイルバージョン番号テーブル2000は、ファイル群名2004、使用UP名2002及び使用バージョン番号2003を含む。例えば、file1及びfile2によってファイル群が構成されており、このファイル群を使用しているユーザプログラムがユーザプログラム1であり、ユーザプログラム1はバージョン10.0のfile1を、バージョン5.0のfile2を使用していることを表す。
処理装置102のファイルアクセス部122は、ファイルのグループを単一のファイルのようにアクセス可能なインターフェースをUP実行部123に提供する。UP実行部123は、ファイルアクセス部122によって提供されたインターフェースを介して、前述した第1の実施の形態と同じ方法でファイルへアクセスする。
以上説明した第3の実施の形態によると、複数のファイルを論理的に同期を取って更新することができる。
<実施形態4>
次に、本発明の第4の実施の形態について説明する。
前述した第1の実施の形態では、処理装置102から受信するメッセージIDテーブルに基づいてファイル更新タイミングを決定したが、第4の実施の形態ではユーザの入力によってファイル更新タイミングを決定する。以下、第4の実施の形態のファイル更新方法を説明する。
前述した第1の実施の形態のファイル更新処理におけるステップ403及び404の代わりに、以下の処理を実施する。
(1)管理端末101は、ユーザからの入力に基づいて、ファイル更新タイミングテーブルを作成する。
(2)管理端末101は、作成されたファイル更新タイミングテーブルを全処理装置102に送信する。
<実施形態5>
次に、本発明の第5の実施の形態について説明する。
前述した第1〜3の実施の形態では、管理端末101が処理装置102から情報を収集し、ファイル更新タイミングを決定していたが、第5の実施の形態では管理端末101を用いずに処理装置102間の通信のみによって、ファイル更新タイミングを決定し、ファイル更新を実行する。以下、第5の実施の形態のファイル更新方法を説明する。
前述した第1の実施の形態において、各処理装置102がメッセージIDテーブル1700を管理端末101へ送信する代わりに、メッセージIDテーブル1700を他の全処理装置102にブロードキャストによって送信する。
処理装置102は、他の全ての処理装置102のメッセージIDテーブル1700及び自らのメッセージIDテーブル1700を取得し、取得したメッセージIDテーブル1700を用いてステップ801〜807の処理を実行し、ファイル更新可能範囲テーブル1500を作成する。
処理装置102は、作成したファイル更新可能範囲テーブル1500に基づいて、更新制御部126のファイル更新ポイントテーブル1800を更新する。
以上説明した第5の実施の形態によると、特別なノードを設置することなく、処理装置102のみでファイルを更新することができる。
本発明の第1の実施の形態のFTCシステムの構成例を示すブロック図である。 本発明の第1の実施の形態のファイルアクセス処理のフローチャートである。 本発明の第1の実施の形態のUP実行処理のフローチャートである。 本発明の第1の実施の形態のファイル更新処理のフローチャートである。 本発明の第1の実施の形態のファイル更新開始処理のフローチャートである。 本発明の第1の実施の形態のファイル格納処理のフローチャートである。 本発明の第1の実施の形態の処理装置処理状況収集処理のフローチャートである。 本発明の第1の実施の形態のファイル更新ポイント決定処理のフローチャートである。 本発明の第1の実施の形態のファイル更新ポイント登録処理のフローチャートである。 本発明の第1の実施の形態のファイル更新処理のフローチャートである。 本発明の第1の実施の形態のファイル更新ポイント決定処理によるデータの変遷の説明図である。 本発明の第1の実施の形態の入出力メッセージのフォーマットを示す説明図である。 本発明の第1の実施の形態の更新命令メッセージのフォーマットを示す説明図である。 本発明の第1の実施の形態の入力メッセージ最短処理時間テーブルの構成を示す説明図である。 本発明の第1の実施の形態のファイル更新可能範囲テーブルの構成を示す説明図である。 本発明の第1の実施の形態の入力メッセージバッファテーブルの構成を示す説明図である。 本発明の第1の実施の形態のメッセージIDテーブルの構成を示す説明図である。 本発明の第1の実施の形態のファイル更新ポイントテーブルの構成を示す説明図である。 本発明の第1の実施の形態の最新ファイルバージョン番号テーブルの構成を示す説明図である。 本発明の第1の実施の形態の使用ファイルバージョン番号テーブルの構成を示す説明図である。 本発明の第3の実施の形態の使用ファイルバージョン番号テーブルの構成を示す説明図である。
符号の説明
101 管理端末
102 処理装置
103 ゲートウェイサーバ
104 内部ネットワーク
105 外部ネットワーク
111 ユーザ操作部
112 更新制御部
113 ファイル格納部
114 通信部
121 ファイル格納部
122 ファイルアクセス部
123 UP実行部
124 通信部
125 入力メッセージバッファ
126 更新制御部
1101 処理装置AのメッセージID一覧
1102 入力メッセージ最短処理時間
1103 処理装置AのUP処理スケジュール
1104 12ミリ秒経過時点
1105 ファイル更新可能範囲
1106 ファイル更新可能範囲一覧
1107 ファイル更新ポイント一覧

Claims (6)

  1. 多重並列処理を実行する複数の処理装置と、前記複数の処理装置の動作を管理する管理装置と、前記複数の処理装置と前記管理装置とを接続するネットワークとを備え、前記各処理装置が処理内容の同一性を維持しながらプログラムを実行する計算機システムであって、
    前記処理装置は、前記プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、前記プログラムの実行時に使用されるデータを格納する記憶部と、前記ネットワークと接続されるインターフェースとを備え、
    前記管理装置は、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、
    前記管理装置は、
    前記複数の処理装置において実行中のプログラムの処理の進捗状態を取得し、
    前記取得した進捗状態を参照して、全ての前記処理装置がデータを更新可能な論理的タイミングを求め、前記求められた論理的タイミングを前記プログラムが使用するデータを更新すべき論理的タイミングと決定し、
    前記処理装置は、
    前記管理装置によって決定されたデータ更新の論理的タイミングを取得し、
    前記実行中のプログラムの処理が前記取得した論理的タイミングへ到達したか否かを監視し、
    前記プログラムの処理が前記取得した論理的タイミングへ到達したときに、当該実行中のプログラムを停止することなくデータを更新することを特徴とする計算機システム。
  2. 前記データ更新の論理的タイミングは、前記プログラムにおいて、同一のデータを複数回アクセスする一群の処理の開始時であることを特徴とする請求項1に記載の計算機システム。
  3. 前記管理装置は、前記ネットワークを介したデータの送受信、及び、前記処理装置における計算処理に必要な時間を参照して、前記全ての処理装置がデータを更新可能な論理的タイミングを求めることを特徴とする請求項1に記載の計算機システム。
  4. 多重並列処理を実行する複数の処理装置と、前記複数の処理装置の動作を管理する管理装置と、前記複数の処理装置と前記管理装置とを接続するネットワークとを備え、前記各処理装置が処理内容の同一性を維持しながらプログラムを実行する計算機システムにおけるデータの管理方法であって、
    前記処理装置は、前記プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、前記プログラムの実行時に使用されるデータを格納する記憶部と、前記ネットワークと接続されるインターフェースとを備え、
    前記管理装置は、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、
    前記管理装置は、前記複数の処理装置において実行中のプログラムの処理の進捗状態を取得し、
    前記管理装置は、前記取得した進捗状態を参照して、全ての前記処理装置がデータを更新可能な論理的タイミングを求め、前記求められた論理的タイミングを前記プログラムが使用するデータを更新すべき論理的タイミングと決定し、
    前記処理装置は、前記管理装置によって決定されたデータ更新の論理的タイミングを取得し、
    前記処理装置は、前記実行中のプログラムの処理が前記取得した論理的タイミングへ到達したか否かを監視し、
    前記処理装置は、前記プログラムの処理が前記取得した論理的タイミングへ到達したときに、当該実行中のプログラムを停止することなくデータを更新することを特徴とするデータ管理方法。
  5. 前記データ更新の論理的タイミングは、前記プログラムにおいて、同一のデータを複数回アクセスする一群の処理の開始時であることを特徴とする請求項4に記載のデータ管理方法。
  6. 前記管理装置は、前記ネットワークを介したデータの送受信、及び、前記処理装置における計算処理に必要な時間を参照して、前記全ての処理装置がデータを更新可能な論理的タイミングを求めることを特徴とする請求項4に記載のデータ管理方法。
JP2007310068A 2007-11-30 2007-11-30 計算機システム、データ管理方法、データ管理プログラム及び処理装置 Expired - Fee Related JP5054495B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007310068A JP5054495B2 (ja) 2007-11-30 2007-11-30 計算機システム、データ管理方法、データ管理プログラム及び処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007310068A JP5054495B2 (ja) 2007-11-30 2007-11-30 計算機システム、データ管理方法、データ管理プログラム及び処理装置

Publications (2)

Publication Number Publication Date
JP2009134510A JP2009134510A (ja) 2009-06-18
JP5054495B2 true JP5054495B2 (ja) 2012-10-24

Family

ID=40866329

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007310068A Expired - Fee Related JP5054495B2 (ja) 2007-11-30 2007-11-30 計算機システム、データ管理方法、データ管理プログラム及び処理装置

Country Status (1)

Country Link
JP (1) JP5054495B2 (ja)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH064578A (ja) * 1992-06-22 1994-01-14 Matsushita Electric Ind Co Ltd データベースシステム
JP2006268172A (ja) * 2005-03-22 2006-10-05 Nec Corp サーバシステムおよびオンラインソフトウェア更新方法

Also Published As

Publication number Publication date
JP2009134510A (ja) 2009-06-18

Similar Documents

Publication Publication Date Title
CN110895484A (zh) 任务调度方法及装置
US20150280981A1 (en) Apparatus and system for configuration management
CN110895488B (zh) 任务调度方法及装置
Kailasam et al. Extending mapreduce across clouds with bstream
KR101389290B1 (ko) 네트워킹된 시스템에서 데이터 생성기에 코드를 선택적으로 전달하는 방법
US9733997B2 (en) Event management method and distributed system
CN110895483A (zh) 任务恢复方法及装置
CN110895486B (zh) 分布式任务调度系统
JP4560074B2 (ja) 仮想計算機システム及び同システムにおける仮想計算機復元方法
JP5054495B2 (ja) 計算機システム、データ管理方法、データ管理プログラム及び処理装置
JP6638317B2 (ja) 情報処理システム、情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム
WO2016090938A1 (zh) 一种数据通信方法、装置及计算机存储介质
US9852140B1 (en) Efficient file replication
JP5387083B2 (ja) ジョブ管理システムおよび方法
US10503722B2 (en) Log management apparatus and log management method
US10838479B2 (en) Information processing system, management device, and method of controlling information processing system
US8705537B1 (en) Eventually-consistent data stream consolidation
CN113190532A (zh) 数据处理方法、装置、设备及计算机可读存储介质
JP5445177B2 (ja) 確定クロック判定プログラム及び方法、並びにノード装置
JP5530878B2 (ja) 分散システムにおけるデータレプリケーション管理方法
JP6036690B2 (ja) 分散実行システム及び分散プログラム実行方法
JP2020095322A (ja) 分散ファイル装置、フェイルオーバ方法、プログラム及び記録媒体
JP7475086B1 (ja) 編集方法、編集装置及びプログラム
KR102084014B1 (ko) 데이터 타입 기반의 멀티 디바이스 데이터 동기화를 위한 방법 및 시스템
CN114840054B (zh) 时间同步方法、装置、系统、设备及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100127

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120309

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120417

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120614

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: 20120710

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120727

R150 Certificate of patent or registration of utility model

Ref document number: 5054495

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150803

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees