WO2012160690A1 - 多重化システム、方法、およびプログラム - Google Patents

多重化システム、方法、およびプログラム Download PDF

Info

Publication number
WO2012160690A1
WO2012160690A1 PCT/JP2011/062076 JP2011062076W WO2012160690A1 WO 2012160690 A1 WO2012160690 A1 WO 2012160690A1 JP 2011062076 W JP2011062076 W JP 2011062076W WO 2012160690 A1 WO2012160690 A1 WO 2012160690A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
response
multiplexing
parameter
setting table
Prior art date
Application number
PCT/JP2011/062076
Other languages
English (en)
French (fr)
Inventor
渡辺 聡
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2013516143A priority Critical patent/JP5703375B2/ja
Priority to PCT/JP2011/062076 priority patent/WO2012160690A1/ja
Publication of WO2012160690A1 publication Critical patent/WO2012160690A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82Solving problems relating to consistency

Definitions

  • the present invention is a multiplexing technique for verifying a computer system by inputting a request to two computer systems of a production system and a standby system.
  • the operation is verified using the standby computer system.
  • the same request is input to two computer systems of the production system and the standby system, the responses from the two computer systems are collated, and the operation of the changed system is verified.
  • Patent Document 1 discloses a capture process for capturing data transmitted / received in a production system by a capture device, a capture data transfer process for transferring captured data to a test device, and a production system using the transferred data. It is described that the system operation test and the test support device can be operated in parallel in the application program development process without any modification of the production system by performing the system operation test process. ing.
  • Patent Document 2 discloses that “in a verification system for verifying the functions of a plurality of server devices that execute business processing, a load distribution device, an input parallel device, and an output collation device.
  • the load distribution device is a client device.
  • the generated input is transmitted to one of the plurality of server devices, and a production server device to be subjected to function verification is selected from the plurality of server devices, and the verification server device is selected for the function verification.
  • the input parallel device transmits the same content input to the production server device and the verification server device, causes them to execute the same business process, and collates each output data by the output collation device. It is described.
  • the operation verification of the standby system is performed by inputting the request to the two computer systems of the production system and the standby system and collating the responses from the two computer systems. Is an issue.
  • the execution order may not match between the production system and the standby system. For example, it is assumed that a request for purchasing the product A is received from the client X, and a request for purchasing the product A is also received from the client Y.
  • these two processes are executed in parallel, there is a possibility that the processes are performed in the order of client X and client Y in the production system, and the processes are performed in the order of client Y and client X in the standby system.
  • the client X purchase request is successful and the client Y purchase request is sold out.
  • the client X purchase request is sold out and the client Y purchase request is successful.
  • the responses are mismatched even though the two systems are operating normally. For example, when a process for updating data is executed in a system including a database, the response varies depending on the execution order of the processes. Therefore, system operation verification cannot be performed unless the execution order of the processes is matched.
  • An object of the present invention is to provide a multiplexing system, method, and program that can solve the above-described problems and can match the execution order of processing between a production system and a standby system.
  • a multiplexing system for processing received requests, wherein requests are sent to a first system, a second system, a first system, and a second system.
  • a system control unit for transmitting the system control unit transmits a request to the first system, suspends transmission of the request to the second system, waits for a response to the request from the first system,
  • a multiplexing system configured to cause a second system to execute requests in the order in which processing for requests is executed in the first system.
  • a multiplexing method in the system control unit that controls the received request to be processed by the first system and the second system.
  • the business processing for the request was executed in the first system
  • a multiplexing method is provided that, in order, causes a second system to perform a business process for a request.
  • a multiplexing unit for a system control unit that includes a processing unit and a storage unit and controls the received request to be processed by the first system and the second system.
  • the program is executed by the processing unit of the system control unit, so that the request is transmitted to the first system, the transmission of the request to the second system is suspended, and the request from the first system.
  • a multiplexing program characterized by waiting for a response to the request, and causing the second system to execute the business process of the request in the order in which the business process for the request is executed in the first system.
  • FIG. 1 is a schematic diagram of a multiplexing system according to a first embodiment.
  • FIG. 2 is a hardware configuration diagram of a system control unit according to the first embodiment.
  • FIG. 3 is a functional diagram of a system control unit according to the first embodiment. It is a flowchart figure which shows the operation
  • a duplex system composed of a first system of the production system and a second system of the standby system
  • the multiplexing system of the present invention has one production system and one standby system, respectively. It is not limited to a duplex system consisting of a system.
  • FIG. 1 is a schematic diagram of the multiplexing system of the first embodiment.
  • the request input to the switch 102 via the Internet 101 is returned to the Internet 101 after the corresponding business process is executed in the production system 104 which is the first system.
  • the system control unit 103 is provided, and the request is transmitted to both the production system 104 and the standby system 105 that is the second system.
  • the response from the standby system 105 is not sent back to the Internet 101 but is used for verifying the response result.
  • the production system 104 and the standby system 105 have the same system configuration, and are composed of a plurality of application servers (AP), a database (DB) corresponding to each application, and data (Data) via a load balancer. However, it is not limited to such a configuration.
  • each application server AP
  • AP application server
  • a request to purchase a certain product is assumed, and as a response after the business process from the production system 104 or the standby system 105 is executed, a purchase completion response is assumed.
  • FIG. 2 is a diagram illustrating an example of a hardware configuration of the system control unit 103 according to the present exemplary embodiment.
  • the system control unit 103 has a normal computer configuration.
  • the system control unit 103 includes an input / output interface 202 connected to the bus 201 therein, and an input / output device such as a keyboard or a display (not shown) can be connected thereto.
  • a system administrator can operate the system control unit 103 via an input / output device.
  • the system control unit 103 includes a central processing unit (CPU) 203 that is a processing unit connected to the internal bus 201, and a memory 204 that is a storage unit, and stores programs stored in the memory 204. Can be executed.
  • CPU central processing unit
  • a network interface 206 is provided to communicate with the switch 102, the production system 104, and the standby system 105.
  • FIG. 3 is a diagram illustrating an example of a functional configuration of the system control unit 103 according to the present embodiment.
  • the request execution determination unit 301 is a program stored in the disk device 207, stored in the memory 204, and implemented as a program executed by the CPU 203.
  • the request management table 302 and the request setting table 303 are data tables stored in the memory 204, and the contents thereof will be described in detail later with reference to FIGS.
  • FIG. 4 is a flowchart illustrating an example of the operation of the request execution determination unit 301 when the system control unit 103 according to the present exemplary embodiment receives a request from the switch 102.
  • the request execution determination unit 301 transmits the received request to the production system 104.
  • the request execution determination unit 301 determines whether the received request is a request registered in the request setting table 303.
  • a request that needs to match the execution order of processing between the production system and the standby system is registered in the request setting table 303 in advance.
  • FIG. 5 is a diagram illustrating an example of the contents of the request setting table 303.
  • a parameter name 501, a parameter 502, and a serialized parameter name 503 are registered in the request setting table 303.
  • “command” is registered in the parameter name 501
  • “order” is registered in the parameter 502
  • “item_id” is registered in the serialized parameter name 503.
  • the corresponding request is a request registered in the request setting table 303 illustrated in FIG.
  • the request setting table 303 it is assumed that a system administrator or the like is set in advance through an input / output device or the like that requires the execution order of processing to be matched between the production system and the standby system.
  • the system control unit 103 transmits the received request to the standby system 105 in processing 407.
  • requests that are not registered in the request setting table 303 are executed in the standby system without controlling the order because there is no need to match the execution order of processing between the production system and the standby system.
  • the requests registered in the request setting table 303 are executed in the standby system by waiting for the end of the actual process and executing in the standby system. Match the order.
  • the system control unit 103 registers the received request in the request management table 302 in process 403.
  • FIG. 6 is a diagram illustrating the contents of the request management table 302.
  • a request 601, a serialization parameter 602, a start time 603, a request confirmation time 604, and a standby system execution flag 605 are registered in the request management table 302.
  • the serialization parameter 602 is a parameter specified as the serialization parameter name in the request setting table 303.
  • the standby system execution flag 605 is a flag indicating that the request is being executed in the standby system 105.
  • FIG. 7 is a flowchart illustrating the operation of the request execution determination unit 301 when the system control unit 103 according to the present embodiment receives a response after the business process is executed from the production system 104.
  • the request execution determination unit 301 transmits the response to the switch 102 in process 701.
  • determination 707 it is determined whether the response is a response to a request set in the request setting table 303.
  • the request execution determination unit 301 sets a request confirmation time 604 in the entry of the request that is the response to the request management table 302 in process 702.
  • the request confirmation time 604 is a time at which the system control unit 103 receives a response or a request confirmation time described in a response message.
  • the request execution determination unit 301 extracts all entries having the same serialization parameter 602 as the request from the request management table 302. For example, an entry having the serialization parameter “0001” corresponding to the serialization parameter name “item_id” described above is extracted.
  • the determination 704 when the result is “Yes”, that is, for the extracted entry, there is no entry for which the standby execution flag 605 is set, and the request start time 603 that is older than the oldest request determination time 604 of the extracted entry. If not, the process proceeds to process 705.
  • the determination 704 since there is no request start time 603 older than the oldest request determination time 604, it can be determined that there is no possibility that the processing order is reversed. This is because requests started after the oldest request start time 603 are not yet started when the request with the oldest request start time 603 is confirmed, and the execution order cannot be reversed.
  • the oldest request determination time 604 request is transmitted to the standby system 105.
  • the standby system execution flag 605 is set in the entry of the request, and the process ends. Note that if the result of the determination 707 or the determination 704 is “No”, the processing ends as it is.
  • FIG. 8 is a flowchart illustrating the operation of the request execution determination unit 301 when the system control unit 103 receives a response from the standby system 105.
  • the request execution determination unit 301 determines in determination 806 whether the response is a response to the request set in the request setting table 303. If the result of determination 806 is “Yes”, the request execution determination unit 301 deletes the entry of the request that is the basis of the response from the request management table 302 in process 801.
  • step 802 all entries having the same serialization parameter 602 as the corresponding request are extracted. If it is determined in step 803 that there is no request start time 603 older than the oldest request determination time 604 in the extracted entry, the processing proceeds to step 804. In determination 803, since there is no request start time 603 older than the oldest request determination time 604, it can be determined that there is no possibility of processing reversal. Therefore, in process 804, the oldest request determination time 604 request is transmitted to the standby system, and in process 805, the standby system execution flag 605 is set in the entry of the request.
  • a request to the standby system is determined when a request that requires the execution order to be matched between the production system and the standby system is determined, and a request that requires the execution order to be matched is executed. Hold the transmission. Then, after waiting for a response of execution completion in the production system, requests are transmitted to the standby system one by one in the order of execution in the production system.
  • the processing is executed in a multiplex manner, and in the standby system, for a request that requires the execution order to be matched, the processing is serialized and executed in a multiplex manner. In the production system, since the processing is executed in multiple, the performance of the production system does not deteriorate.
  • the time when the process is started in the production system is recorded, and the time when the process is confirmed is described in the response request, and the execution is performed using these times. Confirm that the order does not change and send a request to the standby system. As a result, the request execution order can be matched between the production system and the standby system.
  • the request execution determination unit of the system control unit that transmits a request to the first system and the second system suspends transmission of the request to the second system, and Wait for the response of the first system, send requests to the second system in the order in which the business processes were executed on the first system, and serialize the execution of the requests on the second system.
  • the execution order of the business processing can be matched between the first system and the second system.
  • each configuration, function, processing unit, processing unit, and the like of the above-described embodiments may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. It may be realized by software by interpreting and executing a program that realizes each configuration, function, and the like. Information such as programs, tables, and files for realizing each function is stored not only in a memory and a disk device but also in a recording device such as an SSD (Solid State Drive) or a recording medium such as an IC card, an SD card, or a DVD. It can also be downloaded and installed via a network or the like as necessary.
  • SSD Solid State Drive
  • the present invention is useful as a multiplexing technique for verifying a computer system by inputting a request to two computer systems of a production system and a standby system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

 クライアントから受信したリクエストを、第一、第二の計算機システムで実行する場合に、二重系の処理の実行順序を一致させる。受信したリクエストを第一のシステム104と第二のシステム105に送信するシステム制御部103を備え、システム制御部は、第二のシステムへのリクエストの送信を保留し、第一のシステムの応答を待合せて、第一のシステムで業務処理が実行された順序で、第二のシステムにリクエストを送信し、第二のシステムでのリクエストの実行をシリアライズするため、第二のシステムからの応答を待って、次のリクエストを第二のシステムに送信することで、第一のシステムと第二のシステムで業務処理の実行順序を一致させるリクエスト実行判断部を備える。

Description

多重化システム、方法、およびプログラム
 本発明は、リクエストを本番系と待機系の2つの計算機システムに入力し、計算機システムの検証をするための多重化技術である。
 計算機システムに対して、プログラムの改修や設定の変更など実施する場合、待機系の計算機システムを用いて、動作検証を行う。例えば、本番系と待機系の2つの計算機システムに同じリクエストを入力して、2つの計算機システムからの応答を照合し、変更したシステムの動作を検証することが行われている。
 このような技術分野の背景技術としては、特許文献1、特許文献2がある。特許文献1には、本番系システム内で送受信されるデータをキャプチャー機器によりキャプチャーするキャプチャー処理と、キャプチャーされたデータをテスト機器へ転送するキャプチャーデータ転送処理と、転送されたデータを用いて本番系システムの運転テストを行なう処理とを行なうようにすることにより、本番系システムの改造を何ら行なうことなく、アプリケーションプログラムの開発工程における本番系システムとテスト支援装置との並行運転を行なうことが記載されている。
 また、特許文献2には、「業務処理を実行する複数のサーバ装置の機能を検証する検証システムにおいて、負荷分散装置と入力併走装置と出力照合装置とを備える。負荷分散装置は、クライアント装置の生成した入力を前記複数のサーバ装置のいずれかへ送信する。それらの複数のサーバ装置の中から機能の検証の対象とする本番サーバ装置を選び、その機能の検証のために検証サーバ装置とを設ける。そして、入力併走装置は、本番サーバ装置と検証サーバ装置とに同じ内容の入力を送信し、各々で同等の業務処理を実行させて、各々の出力データを出力照合装置により照合する。」と記載されている。
特開2005-73043号公報 特開2007-257588号公報
 本発明においても、背景技術と同様に、リクエストを本番系と待機系の2つの計算機システムに入力し、2つの計算機システムからの応答を照合することにより、待機系システムの動作検証を実施することを課題とする。
 しかしながら、2つの計算機システムにおいて、複数のリクエストを並列に実行した場合には、その実行順序が、本番系と待機系で一致しない可能性がある。例えば、クライアントXから商品Aを購入するリクエストを受信し、クライアントYからも同じく商品Aを購入するリクエストを受信したとする。この2つの処理が並列に実行された場合、本番系ではクライアントX、クライアントYの順に処理が行われ、待機系では、クライアントY、クライアントXの順に処理が行われる可能性がある。
 この場合、本番系では、クライアントXの購入リクエストが成功、クライアントYの購入リクエストが売り切れになり、テスト系では、クライアントXの購入リクエストが売り切れ、クライアントYの購入リクエストが成功となるケースが生じうる。このケースでは、2つのシステムが正常に動作しているにもかかわらず、応答が不一致になる。例えば、データベースを含むシステムにおいて、データを更新する処理を実行する場合、その応答は処理の実行順序によって変わる。そのため、処理の実行順序を一致させないと、システムの動作検証が実施できない。
 本発明の目的は、上述した課題を解決し、本番系と待機系で処理の実行順序を一致させることが可能な多重化システム、方法、及びプログラムを提供することにある。
 上記の目的を達成するため、本発明においては、受信するリクエストを処理する多重化システムであって、第一のシステムと、第二のシステムと、第一のシステムと第二のシステムにリクエストを送信するシステム制御部とを備え、システム制御部は、第一のシステムにリクエストを送信し、第二のシステムへのリクエストの送信を保留し、第一のシステムからのリクエストに対する応答を待合わせ、第一のシステムでリクエストに対する処理が実行された順序で、第二のシステムにリクエストを実行させる構成の多重化システムを提供する。
 また、上記の目的を達成するため、本発明においては、受信するリクエストを第一のシステムと第二のシステムで処理するよう制御するシステム制御部における多重化方法あって、システム制御部は、第一のシステムにリクエストを送信し、第二のシステムへのリクエストの送信を保留し、第一のシステムからのリクエストに対する応答を待合わせることにより、第一のシステムでリクエストに対する業務処理が実行された順序で、第二のシステムにリクエストの業務処理を実行させる多重化方法を提供する。
 更に、上記の目的を達成するため、本発明においては、処理部と記憶部とを備え、受信するリクエストを第一のシステムと第二のシステムで処理するよう制御するシステム制御部のための多重化プログラムであって、システム制御部の処理部で実行されることにより、第一のシステムにリクエストを送信し、第二のシステムへの当該リクエストの送信を保留し、第一のシステムからのリクエストに対する応答を待合わせ、第一のシステムでリクエストに対する業務処理が実行された順序で、第二のシステムにリクエストの業務処理を実行させることを特徴とする多重化プログラムを提供する。
 本発明の構成により、本番系と待機系で処理の実行順序を一致させることが可能な多重化システムを提供できる。
第1の実施例の多重化システムの概要図である。 第1の実施例に係わる、システム制御部のハードウェア構成図である。 第1の実施例に係わる、システム制御部の機能図である。 第1の実施例に係わる、リクエスト実行判断部の動作を示すフローチャート図である。 第1の実施例に係わる、リクエスト設定テーブルの内容を例示する図である。 第1の実施例に係わる、リクエスト管理テーブルの内容を例示する図である。 第1の実施例に係わる、リクエスト実行判断部の動作を示すフローチャート図である。 第1の実施例に係わる、リクエスト実行判断部301の動作を示すフローチャート図である。
 以下、実施例を図面に従い説明する。なお、多重化システムとして、本番系の第一のシステムと、待機系の第二のシステムからなる二重化システムを例示して説明するが、本発明の多重化システムは、それぞれ一個の本番系、待機系からなる二重化システムに限定されるものではない。
 図1は第1の実施例の多重化システムの概要図である。インターネット101を介してスイッチ102に入力されたリクエストは、第一のシステムである本番系104で、対応する業務処理が実行された後、その応答がインターネット101に返される。本実施例のシステムでは、システム制御部103を設けて、リクエストを本番系104と第二のシステムである待機系105の両方に送信する。そして、待機系105からの応答は、インターネット101に送り返すことはせず、応答結果の検証などに使用する。本番系104と待機系105は、同一のシステム構成を備えており、ロードバランサーを介して複数のアプリケーションサーバ(AP)と、それぞれのアプリケーションに対応するデータベース(DB)と、データ(Data)から構成されるが、このような構成に限定されるものではない。
 本番系104や待機系105では、例えば、アプリケーションとしてオンラインショッピングなどの処理が、各アプリケーションサーバ(AP)で実行される。インターネット101からの入力としては、ある商品を購入するするリクエストなどが想定され、本番系104や待機系105からの業務処理が実行された後の応答としては、購入完了の応答などが想定される。
 図2は本実施例のシステム制御部103のハードウェア構成の一例を示す図である。図2より明らかなように、システム制御部103は通常のコンピュータ構成を有する。システム制御部103は、その内部に、バス201に接続された入出力インターフェース202を備え、ここに図示を省略したキーボードやディスプレイなどの入出力デバイスを接続できる。システムの管理者は、入出力デバイスを介して、システム制御部103を操作することができる。また、システム制御部103は、内部バス201に接続された、処理部となる中央処理部(Central Processing Unit:CPU)203と、記憶部であるメモリ204を備え、メモリ204に格納されたプログラムを実行することができる。また、記憶装置インターフェース205と、記憶部であるディスク装置207を備え、ディスク装置207に格納されたプログラムをメモリ204に格納することができる。また、ネットワークインターフェース206を備え、スイッチ102や本番系104や待機系105と通信することができる。
 図3は、本実施例のシステム制御部103の機能構成の一例を示す図である。リクエスト実行判断部301はディスク装置207に格納されたプログラムであり、メモリ204に格納して、CPU203によって実行されるプログラムとして実装される。また、リクエスト管理テーブル302、および、リクエスト設定テーブル303は、メモリ204に格納されるデータテーブルであり、後にその内容を図5、図6を用いて詳述する。
 図4は、本実施例のシステム制御部103がスイッチ102からリクエストを受信した場合の、リクエスト実行判断部301の動作の一例を示すフローチャートである。処理401において、リクエスト実行判断部301は、受信したリクエストを、本番系104に送信する。ここに、受信したリクエストとは、「http://www.xxx.com/command=order&item_id=0001&user_id=0001」といった形式の電文である。
 リクエスト実行判断部301は、判断402において、受信したリクエストが、リクエスト設定テーブル303に登録されたリクエストか否かを判断する。本実施例においては、本番系と待機系で処理の実行順序を一致させる必要のあるリクエストを、このリクエスト設定テーブル303に予め登録しておく。
 図5は、リクエスト設定テーブル303の内容の一例を示す図である。図5に例示するように、リクエスト設定テーブル303には、パラメータ名501、パラメータ502、シリアライズパラメータ名503が登録される。図5の例では、パラメータ名501には「command」、パラメータ502には「order」、シリアライズパラメータ名503には「item_id」が登録されている。ここに、パラメータ名501とは受信したリクエストの「=」ではさまれた項目の前半部分であり、パラメータ502とは受信したリクエストの「=」ではさまれた項目の後半部分である。受信したリクエストが上述した「http://www.xxx.com/command=order&item_id=0001&user_id=0001」の場合、「command=order」のパラメータ名が「command」であり、パラメータが「order」であることから、該当リクエストが、図5に例示したリクエスト設定テーブル303に登録されたリクエストであることが判断できる。なお、リクエスト設定テーブル303には、入出力デバイスなどを介して、予めシステムの管理者などが、本番系と待機系で処理の実行順序を一致させる必要のあるものを設定しているものとする。なお、この本番系と待機系で処理の実行順序を一致させる必要のあるパラメータとしては、上述の「order」の他、「reserve」などがある。
 図4の判断402の判断結果が「No」の場合、システム制御部103は、処理407において、受信したリクエストを待機系105に送信する。つまり、リクエスト設定テーブル303に登録されていないリクエストについては、本番系と待機系で処理の実行順序を一致させる必要がないので、順序の制御をせずに待機系で実行する。本実施例の多重化システムでは、リクエスト設定テーブル303に登録されたリクエストについては、本番系の処理の終了を待ち合わせて、待機系で処理を実行することにより、本番系と待機系で処理の実行順序を一致させる。判断402の判断結果が「Yes」の場合、システム制御部103は、処理403において、受信したリクエストをリクエスト管理テーブル302に登録する。
 図6は、リクエスト管理テーブル302の内容を例示する図である。図6に示すように、リクエスト管理テーブル302には、リクエスト601、シリアライズパラメータ602、開始時刻603、リクエスト確定時刻604、待機系実行フラグ605を登録する。リクエスト601とは、スイッチ102から受信した電文そのものであり、例えば、「http://www.xxx.com/command=order&item_id=0001&user_id=0001」といった電文が登録される。シリアライズパラメータ602とは、リクエスト設定テーブル303のシリアライズパラメータ名に指定されたパラメータである。例えば、リクエストが、「http://www.xxx.com/command=order&item_id=0001&user_id=0001」であり、シリアライズパラメータ名が「item_id」の場合、シリアライズパラメータには「0001」を設定する。開始時刻603には、処理401において該当リクエストを本番系104に送信した時刻を設定する。待機系実行フラグ605は、当該リクエストが、待機系105で実行中であることを示すフラグである。
 図7は、本実施例のシステム制御部103が、本番系104から業務処理が実行された後の応答を受信した場合の、リクエスト実行判断部301の動作を例示するフローチャートである。本番系104から応答を受信すると、リクエスト実行判断部301は、処理701において、応答をスイッチ102に送信する。また、判断707において、該応答がリクエスト設定テーブル303に設定されているリクエストに対する応答か否かを判断する。判断707の結果が「Yes」の場合、リクエスト実行判断部301は、処理702において、リクエスト管理テーブル302に対して、応答のもとになったリクエストのエントリにリクエスト確定時刻604を設定する。ここに、リクエスト確定時刻604とは、システム制御部103が応答を受信した時刻、あるいは、応答の電文に記載されているリクエスト確定時刻とする。
 続いて、処理703において、リクエスト実行判断部301は、リクエスト管理テーブル302から、該リクエストと同じシリアライズパラメータ602を持つエントリをすべて抽出する。例えば、上述のシリアライズパラメータ名「item_id」に対するシリアライズパラメータ「0001」を持つエントリを抽出する。判断704において、結果が「Yes」の場合、すなわち抽出したエントリについて、待機系実行フラグ605が設定されているエントリがなく、かつ、抽出したエントリの最も古いリクエスト確定時刻604より古いリクエスト開始時刻603がない場合、処理705に進む。
 判断704において、最も古いリクエスト確定時刻604より古いリクエスト開始時刻603がないことから、処理順序の逆転が発生する可能性がないと判断できる。なぜなら、最も古いリクエスト開始時刻603より後に開始されたリクエストは、最も古いリクエスト開始時刻603のリクエストが確定した時点で、未だ開始されておらず、実行順序の逆転は生じ得ないからである。そこで、処理705において、最も古いリクエスト確定時刻604のリクエストを待機系105に送信し、処理706において、該リクエストのエントリに待機系実行フラグ605を設定して終了する。なお、判断707、あるいは判断704の結果が「No」の場合も、そのまま終了する。
 図8は、システム制御部103が、待機系105から応答を受信した場合の、リクエスト実行判断部301の動作を例示するフローチャートである。待機系105から応答を受信すると、リクエスト実行判断部301は、判断806において、該応答がリクエスト設定テーブル303に設定されているリクエストに対する応答か否かを判断する。判断806の結果が「Yes」の場合、リクエスト実行判断部301は、処理801において、リクエスト管理テーブル302から、応答のもとになったリクエストのエントリを削除する。
 また、処理802において、該当リクエストと同じシリアライズパラメータ602をもつエントリをすべて抽出する。判断803において、抽出したエントリにおいて、最も古いリクエスト確定時刻604より古いリクエスト開始時刻603がない場合、処理804に進む。判断803において、最も古いリクエスト確定時刻604より古いリクエスト開始時刻603がないことから、処理の逆転が発生する可能性がないことを判断できる。そこで、処理804において、最も古いリクエスト確定時刻604のリクエストを待機系に送信し、処理805において、該リクエストのエントリに待機系実行フラグ605を設定する。
 以上説明した実施例の多重化システムでは、本番系と待機系で実行順序を一致させる必要があるリクエストを判別し、実行順序を一致させる必要があるリクエストを実行する場合に、待機系へのリクエスト送信を保留し。そして、本番系での実行完了の応答を待って、本番系で実行した順序に従って、1つずつ待機系にリクエストを送信する。このように、本番系では処理を多重で実行し、待機系では、実行順序を一致させる必要があるリクエストについては、その処理を1多重にシリアライズして実行する。本番系では、処理を多重で実行するため、本番系の性能は低下しない。
 また、上述した実施例の多重化システムでは、本番系で処理を開始した時刻を記録しておくとともに、処理が確定した時刻を応答リクエストに記載しておき、これらの時刻を使用して、実行順序の入れ替わりが発生しないことを確認して、待機系にリクエストを送信する。これにより、本番系と待機系でリクエストの実行順序を一致させることが出来る。
 更に、上述した実施例の多重化システムでは、第一のシステムと第二のシステムにリクエストを送信するシステム制御部のリクエスト実行判断部は、第二のシステムへのリクエストの送信を保留し、第一のシステムの応答を待合せて、第一のシステムで業務処理が実行された順序で、第二のシステムにリクエストを送信し、第二のシステムでのリクエストの実行をシリアライズするため、第二のシステムからの応答を待って、一つずつ、第二のシステムにリクエストを送信することで、第一のシステムと第二のシステムで業務処理の実行順序を一致させることが出来る。
 なお、本発明は上述した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。
 また、上述した実施例の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよいし、上述の通り、各構成、機能等を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやディスク装置のみならず、SSD(Solid State Drive)等の記録装置、または、ICカード、SDカード、DVD等の記録媒体におくことができるし、必要に応じてネットワーク等を介してダウンロード、インストロールすることも可能である。
 本発明は、リクエストを本番系と待機系の2つの計算機システムに入力し、計算機システムの検証をするための多重化技術として有用である。
101 インターネット
102 スイッチ
103 システム制御部
104 本番系
105 待機系
201 内部バス
202 入出力インターフェース
203 CPU
204 メモリ
205 記憶装置インターフェース
206 ネットワークインターフェース
207 ディスク装置
301 リクエスト実行判断部
302 リクエスト管理テーブル
303 リクエスト設定テーブル

Claims (15)

  1. 受信するリクエストを処理する多重化システムであって、
    第一のシステムと、
    第二のシステムと、
    前記第一のシステムと前記第二のシステムに前記リクエストを送信するシステム制御部とを備え、
    前記システム制御部は、
    前記第一のシステムに前記リクエストを送信し、前記第二のシステムへの前記リクエストの送信を保留し、
    前記第一のシステムからの前記リクエストに対する応答を待合わせ、前記第一のシステムで前記リクエストに対する業務処理が実行された順序で、前記第二のシステムに前記リクエストの業務処理を実行させるリクエスト実行判断部を有する、
    ことを特徴とする多重化システム。
  2. 請求項1に記載の多重化システムであって、
    前記リクエスト実行判断部は、
    前記第二のシステムでのリクエストの実行をシリアライズするため、送信したリクエストに対する前記第二のシステムからの応答を待って、前記第二のシステムに新たなリクエストを送信する、
    ことを特徴とする多重化システム。
  3. 請求項2に記載の多重化システムであって、
    前記システム制御部は、
    前記第二のシステムへの送信を保留するリクエストを設定するリクエスト設定テーブルを備え、
    前記リクエスト実行判断部は、
    前記リクエスト設定テーブルに設定されたリクエストを前記システム制御部が受信した場合に、前記第二のシステムへの当該リクエストの送信を保留し、
    前記リクエスト設定テーブルに設定されていないリクエストを受信した場合には、当該リクエストの送信を保留せずに前記第二のシステムに送信する、
    ことを特徴とする多重化システム。
  4. 請求項3に記載の多重化システムであって、
    前記リクエストには、パラメータ名と、当該パラメータ名に対応するパラメータと、シリアライズパラメータ名と、当該シリアライズパラメータ名に対応するシリアライズパラメータが含まれており、
    前記リクエスト設定テーブルの設定項目には、前記パラメータと前記シリアライズパラメータ名を含み、
    前記リクエスト実行判断部は、
    前記リクエスト設定テーブル中に設定された前記シリアライズパラメータ名に対応する前記シリアライズパラメータが等しいリクエストごとに、前記第一のシステムと前記第二のシステムで業務処理の実行順序を一致させる、
    ことを特徴とする多重化システム。
  5. 請求項4に記載の多重化システムであって、
    前記システム制御部は、
    前記リクエストの前記シリアライズパラメータと、リクエスト開始時刻と、リクエスト確定時刻と、待機系実行中フラグとを設定するリクエスト管理テーブルを備え、
    前記リクエスト実行判断部は、
    前記第一のシステムから応答を受信した際、当該応答が前記リクエスト設定テーブルに設定されたリクエストに対する応答である場合には、
    前記リクエスト管理テーブルの前記リクエスト確定時刻に、当該応答を受信した時刻、又は当該応答に記載された時刻を記録し、
    当該応答のリクエストの前記シリアライズパラメータを特定し、
    前記第二のシステムへの送信を保留している前記リクエストから、前記シリアライズパラメータが等しいリクエストを抽出し、
    抽出したリクエストの中に、前記第二のシステムで実行されているリクエストがなく、かつ、最も古い前記リクエスト確定時刻より古い前記リクエスト開始時刻がない場合に、抽出した前記リクエストの中で前記リクエスト確定時刻が最も古いリクエストを前記第二のシステムに送信する、
    ことを特徴とする多重化システム。
  6. 請求項5に記載の多重化システムであって、
    前記リクエスト実行判断部は、
    前記第二のシステムから応答を受信した際、
    該応答が前記リクエスト設定テーブルに設定されたリクエストに対する応答である場合には、当該リクエストの記録を前記リクエスト管理テーブルから削除し、
    当該応答のリクエストの前記シリアライズパラメータを特定し、前記第二のシステムへの送信を保留している前記リクエストから、前記シリアライズパラメータが等しいリクエストを抽出し、抽出した前記リクエストの中に、最も古い前記リクエスト確定時刻より古い前記リクエスト開始時刻がない場合に、抽出した前記リクエストの中で、前記リクエスト確定時刻が最も古いリクエストを前記第二のシステムに送信する、
    ことを特徴とする多重化システム。
  7. 受信するリクエストを第一のシステムと第二のシステムで処理するよう制御するシステム制御部における多重化方法あって、
    前記システム制御部は、
    前記第一のシステムに前記リクエストを送信し、前記第二のシステムへの前記リクエストの送信を保留し、
    前記第一のシステムからの前記リクエストに対する応答を待合わせることにより、前記第一のシステムで前記リクエストに対する業務処理が実行された順序で、前記第二のシステムに前記リクエストの業務処理を実行させる、
    ことを特徴とする多重化方法。
  8. 請求項7に記載の多重化方法であって、
    前記システム制御部は、
    前記第二のシステムでのリクエストの実行をシリアライズするため、送信したリクエストに対する前記第二のシステムからの応答を待って、前記第二のシステムに新たなリクエストを送信する、
    ことを特徴とする多重化方法。
  9. 請求項8に記載の多重化方法であって、
    前記システム制御部は、
    前記第二のシステムへの送信を保留するリクエストを設定するリクエスト設定テーブルを備え、
    前記リクエスト設定テーブルに設定されたリクエストを受信した場合に、前記第二のシステムへの当該リクエストの送信を保留し、
    前記リクエスト設定テーブルに設定されていないリクエストを受信した場合には、当該リクエストの送信を保留せずに前記第二のシステムに送信する、
    ことを特徴とする多重化方法。
  10. 請求項9に記載の多重化方法であって、
    前記リクエストには、パラメータ名と、当該パラメータ名に対応するパラメータと、シリアライズパラメータ名と、当該シリアライズパラメータ名に対応するシリアライズパラメータが含まれており、
    前記リクエスト設定テーブルの設定項目には、前記パラメータと前記シリアライズパラメータ名を含み、
    前記システム制御部は、
    前記リクエスト設定テーブル中に設定された前記シリアライズパラメータ名に対応する前記シリアライズパラメータが等しいリクエストごとに、前記第一のシステムと前記第二のシステムで業務処理の実行順序を一致させる、
    ことを特徴とする多重化方法。
  11. 請求項10に記載の多重化方法であって、
    前記システム制御部は、
    前記リクエストのシリアライズパラメータと、リクエスト開始時刻と、リクエスト確定時刻と、待機系実行中フラグとを設定するリクエスト管理テーブルを備え、
    前記第一のシステムから応答を受信した際、当該応答が前記リクエスト設定テーブルに設定されたリクエストに対する応答である場合には、当該リクエストの確定時刻として、当該応答を受信した時刻、又は当該応答に記載された時刻を前記リクエスト管理テーブルの前記リクエスト確定時刻に記録し、
    当該応答のリクエストの前記シリアライズパラメータを特定し、
    前記第二のシステムへの送信を保留しているリクエストから、前記シリアライズパラメータが等しいリクエストを抽出し、
    抽出したリクエストのなかに、前記第二のシステムで実行されているリクエストがなく、かつ、最も古い前記リクエスト確定時刻より古い前記リクエスト開始時刻がない場合に、抽出した前記リクエストのなかで前記リクエスト確定時刻が最も古いリクエストを前記第二のシステムに送信する、
    ことを特徴とする多重化方法。
  12. 請求項11に記載の多重化方法であって、
    前記システム制御部は、
    前記第二のシステムから応答を受信した際、
    該応答が前記リクエスト設定テーブルに設定されたリクエストに対する応答である場合には、当該リクエストの記録を前記リクエスト管理テーブルから削除し、
    当該応答のリクエストの前記シリアライズパラメータを特定し、前記第二のシステムへの送信を保留しているリクエストから、前記シリアライズパラメータが等しいリクエストを抽出し、抽出した前記リクエストの中に、最も古い前記リクエスト確定時刻より古い前記リクエスト開始時刻がない場合に、抽出した前記リクエストの中で、前記リクエスト確定時刻が最も古いリクエストを前記第二のシステムに送信する、
    ことを特徴とする多重化方法。
  13. 処理部と記憶部とを備え、受信するリクエストを第一のシステムと第二のシステムで処理するよう制御するシステム制御部のための多重化プログラムであって、
    前記システム制御部の前記処理部で実行されることにより、
    前記第一のシステムに前記リクエストを送信し、前記第二のシステムへの前記リクエストの送信を保留し、
    前記第一のシステムからの前記リクエストに対する応答を待合わせ、前記第一のシステムで前記リクエストに対する業務処理が実行された順序で、前記第二のシステムに前記リクエストの業務処理を実行させる、
    ことを特徴とする多重化プログラム。
  14. 請求項13に記載の多重化プログラムであって、
    前記システム制御部の前記処理部で実行されることにより、
    前記第二のシステムでのリクエストの実行をシリアライズするため、送信したリクエストに対する前記第二のシステムからの応答を待って、前記第二のシステムに新たなリクエストを送信する、
    ことを特徴とする多重化プログラム。
  15. 請求項14に記載の多重化プログラムであって、
    前記システム制御部の前記記憶部には、前記第二のシステムへの送信を保留するリクエストを設定するリクエスト設定テーブルを備えており、
    前記システム制御部の前記処理部で実行されることにより、
    前記リクエスト設定テーブルに設定されたリクエストを受信した場合に、前記第二のシステムへの当該リクエストの送信を保留し、
    前記リクエスト設定テーブルに設定されていないリクエストを受信した場合には、当該リクエストの送信を保留せずに前記第二のシステムに送信する、
    ことを特徴とする多重化プログラム。
PCT/JP2011/062076 2011-05-26 2011-05-26 多重化システム、方法、およびプログラム WO2012160690A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013516143A JP5703375B2 (ja) 2011-05-26 2011-05-26 多重化システム、方法、およびプログラム
PCT/JP2011/062076 WO2012160690A1 (ja) 2011-05-26 2011-05-26 多重化システム、方法、およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/062076 WO2012160690A1 (ja) 2011-05-26 2011-05-26 多重化システム、方法、およびプログラム

Publications (1)

Publication Number Publication Date
WO2012160690A1 true WO2012160690A1 (ja) 2012-11-29

Family

ID=47216792

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/062076 WO2012160690A1 (ja) 2011-05-26 2011-05-26 多重化システム、方法、およびプログラム

Country Status (2)

Country Link
JP (1) JP5703375B2 (ja)
WO (1) WO2012160690A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07306794A (ja) * 1994-05-12 1995-11-21 Mitsubishi Electric Corp 分散システム及び分散システムの高信頼化方法
JPH09282296A (ja) * 1996-04-10 1997-10-31 Hitachi Ltd 多重化ノード間通信制御方式
JP2003067214A (ja) * 2001-08-27 2003-03-07 Nippon Telegr & Teleph Corp <Ntt> サーバシステム、仲介装置、クライアントサーバ型システムにおける誤り隠蔽方法
JP2004030204A (ja) * 2002-06-25 2004-01-29 Jmnet Inc 負荷分散装置及びそれに接続するノードコンピュータ

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3490473B2 (ja) * 1993-02-17 2004-01-26 松下電器産業株式会社 プロセッサ間通信システム
JP2679674B2 (ja) * 1994-05-02 1997-11-19 日本電気株式会社 半導体製造ライン制御装置
JP3006491B2 (ja) * 1996-06-03 2000-02-07 日本電気株式会社 トランザクション実行状態管理システム、管理方法、および管理プログラムを記憶する媒体
JP3823169B1 (ja) * 2005-12-06 2006-09-20 データアクセス株式会社 データ制御装置、システム、方法、及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07306794A (ja) * 1994-05-12 1995-11-21 Mitsubishi Electric Corp 分散システム及び分散システムの高信頼化方法
JPH09282296A (ja) * 1996-04-10 1997-10-31 Hitachi Ltd 多重化ノード間通信制御方式
JP2003067214A (ja) * 2001-08-27 2003-03-07 Nippon Telegr & Teleph Corp <Ntt> サーバシステム、仲介装置、クライアントサーバ型システムにおける誤り隠蔽方法
JP2004030204A (ja) * 2002-06-25 2004-01-29 Jmnet Inc 負荷分散装置及びそれに接続するノードコンピュータ

Also Published As

Publication number Publication date
JPWO2012160690A1 (ja) 2014-07-31
JP5703375B2 (ja) 2015-04-15

Similar Documents

Publication Publication Date Title
US9524133B2 (en) Printing server group including a print service of transferring a print job to a printer via a network
EP2682863B1 (en) Installing applications remotely
US11526342B2 (en) Cancel and rollback update stack requests
JP5512215B2 (ja) ジョブ処理システム及びその方法、そのプログラム
US10209976B2 (en) Automated application installation
JP6357780B2 (ja) ネットワークシステム及び情報通知方法
JP2014534535A (ja) ストア横断型電子情報開示
US8789151B2 (en) Remote device communication platform
JP4488427B2 (ja) 印刷システム、印刷管理サーバ、印刷制御方法、プログラム及びコンピュータ読み取り可能な記憶媒体
JP6102296B2 (ja) 情報処理システム、情報処理装置、認証方法及びプログラム
JP6927282B2 (ja) 情報処理装置、端末装置、プログラム及び情報処理システム
JP5703375B2 (ja) 多重化システム、方法、およびプログラム
JP2007102794A (ja) フロントエンド処理機能を有する情報処理システム
JP6269155B2 (ja) 配信方法、端末装置、及び配信システム
CN103838586A (zh) 文件开启的系统及方法
JP3886852B2 (ja) フロントエンド処理機能を有する情報処理システム
JP5847495B2 (ja) 情報処理装置および制御方法およびプログラム
JP5681140B2 (ja) 印刷される記事のコンテンツ識別を利用し、顧客オーダーレコードを維持することによって、プリントオンデマンドジョブを管理するための方法およびシステム
JP2016024721A (ja) サーバシステム、方法、およびそのプログラム
JP5668816B2 (ja) 印刷装置の制御方法及び印刷装置
JP4724491B2 (ja) 資源配布管理プログラム、資源配布管理方法および資源配布管理装置
JP5660174B2 (ja) ディスプレイの制御方法及びデバイスアダプタ
JP2011113170A (ja) 認証サーバ及び方法
JP2011107921A (ja) ソフトウェア実行制御管理方法および管理システム
JP2005055961A (ja) タスク間通信プログラム及びタスク間通信方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11866145

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013516143

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11866145

Country of ref document: EP

Kind code of ref document: A1