[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2012042607A1 - 分散コンピューティングシステム - Google Patents

分散コンピューティングシステム Download PDF

Info

Publication number
WO2012042607A1
WO2012042607A1 PCT/JP2010/066906 JP2010066906W WO2012042607A1 WO 2012042607 A1 WO2012042607 A1 WO 2012042607A1 JP 2010066906 W JP2010066906 W JP 2010066906W WO 2012042607 A1 WO2012042607 A1 WO 2012042607A1
Authority
WO
WIPO (PCT)
Prior art keywords
master
stored
client
response
computing system
Prior art date
Application number
PCT/JP2010/066906
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 PCT/JP2010/066906 priority Critical patent/WO2012042607A1/ja
Priority to JP2010538664A priority patent/JPWO2012042607A1/ja
Publication of WO2012042607A1 publication Critical patent/WO2012042607A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error 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/202—Error 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1443—Transmit or communication errors

Definitions

  • the present invention relates to a distributed computing system including a cell and a client including a plurality of replicas that are synchronized with each other, and more particularly to a session management technique between the cell and the client.
  • the following replication technology is known for a distributed computing system including a cell including a plurality of replicas and a client.
  • the virtual IP address of the load balancer serves as a connection window with the client (see Patent Documents 1 and 2), and requests from the client are transmitted to the replica via the load balancer.
  • the response from the replica is sent to the client via the load balancer.
  • the production system (primary system) and standby system (standby system) replicas are provided (see Patent Documents 3 and 4), and the production system replica that provided services to the client fails.
  • the standby replica in the hot standby state takes over the processing of the production replica and continues to provide the service.
  • RAID devices provide a virtualized interface for disks, and store data multiplexed and redundant by mirroring or pooling.
  • the replica group can be seen as one virtual system from the client by the virtualization technology, and the distributed cooperative method between replicas is made into a black box.
  • the client loses the access method to the replica inside the black box. Even if the service is provided, the service provision by the cell stops.
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to provide a distributed computing system that can prevent service stoppage due to the occurrence of a failure at a connection window with a cell client. .
  • the invention according to claim 1 includes a cell including a plurality of replicas synchronized with each other and a client, and manages a session between the cell and the client in the client.
  • First connection means for storing connection information for the client to connect to each replica and a client ID for identifying the client as session information for the connection to any one of the plurality of replicas
  • Processing request means for performing a predetermined processing request and notification of the client ID based on the information, and receiving a processing request from the processing request means to each of the replicas, and indicating that there has been a processing request and the client ID
  • Process request notifying means for notifying other replicas, and receiving a process request from the process request means,
  • a processing execution unit that receives a notification from the processing request notification unit of the replica that has received the processing request and establishes the session with the client based on the client ID and performs the predetermined processing And a distributed computing system.
  • the invention according to claim 2 is the distributed computing system according to claim 1, wherein the predetermined process is an update process.
  • the invention according to claim 3 is the distributed computing system according to claim 1, wherein the predetermined processing request is a session opening request for causing each replica to open the session.
  • the first storage means selects one of the plurality of replicas as a master. , Storing a master ID for specifying which replica is the master, and the processing requesting unit performs the predetermined processing on the replica specified by the master ID stored in the first storage unit. And a notification of the client ID.
  • the invention according to claim 5 is the distributed computing system according to claim 4, wherein the first storage means is selected when one of the plurality of replicas is selected as a reference to be used for reference processing.
  • a reference ID for identifying whether the replica of the first reference is a reference is stored, and the processing requesting unit requests a reference processing for the replica specified by the reference ID stored in the first storage unit. It is characterized by that.
  • a response generation unit that generates a response to the request for the predetermined process, and the master ID in the first storage Second storage means for storing the response generated independently of the means and storing the response generated by the response generation means; and a response transmission means capable of transmitting the response stored in the second storage means to the client And when the response transmission means determines that its replica is the master based on the master ID stored in the second storage means, the response stored in the second storage means It transmits to the said client, It is characterized by the above-mentioned.
  • a response generation means for generating a response to the request for the predetermined processing in each replica, and the master ID in the first storage Second storage means for storing the response generated independently of the means and storing the response generated by the response generation means; and a response transmission means capable of transmitting the response stored in the second storage means to the client And when the response transmission means determines that its replica is the master based on the master ID stored in the second storage means, the response stored in the second storage means It transmits to the said client, It is characterized by the above-mentioned.
  • the invention according to claim 8 is the distributed computing system according to claim 6, wherein the response transmission means determines that its replica is not a master based on the master ID stored in the second storage means. Sometimes, information on the master ID is transmitted to the client instead of the response stored in the second storage means.
  • the invention according to claim 9 is the distributed computing system according to claim 7, wherein the response transmission unit determines that its replica is not a master based on a master ID stored in the second storage unit. Sometimes, information on the master ID is transmitted to the client instead of the response stored in the second storage means.
  • the distributed computing system when there is a master change among the plurality of replicas in each of the replicas, information on the master ID of the new master is sent to the client.
  • a master change notification means for notifying is provided.
  • the distributed computing system when there is a master change among the plurality of replicas in each of the replicas, information on a master ID of a new master is transmitted to the client.
  • a master change notification means for notifying is provided.
  • the invention according to claim 12 is the distributed computing system according to claim 6, wherein when each master has a master change among the plurality of replicas, information on a master ID of a new master is sent to the client.
  • a master change notification means for notifying is provided.
  • the distributed computing system when there is a master change among the plurality of replicas in each of the replicas, information on a master ID of a new master is transmitted to the client.
  • a master change notification means for notifying is provided.
  • the invention according to claim 14 is the distributed computing system according to claim 8, wherein when each master has a master change among the plurality of replicas, information on a master ID of a new master is sent to the client.
  • a master change notification means for notifying is provided.
  • the distributed computing system when there is a master change among the plurality of replicas in each of the replicas, information on a master ID of a new master is transmitted to the client.
  • a master change notification means for notifying is provided.
  • the invention according to claim 16 is the distributed computing system according to claim 8, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when receiving information on the master ID from the response transmission means to the client, the master ID stored in the first storage means If the master ID is not the same as the master ID stored in the master table, the master ID changing unit replaces the master ID stored in the first storage unit with the master ID. Is provided.
  • the invention according to claim 17 is the distributed computing system according to claim 9, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when receiving information on the master ID from the response transmission means to the client, the master ID stored in the first storage means If the master ID is not the same as the master ID stored in the master table, the master ID changing unit replaces the master ID stored in the first storage unit with the master ID. Is provided.
  • the invention according to claim 18 is the distributed computing system according to claim 10, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when the client receives information on the master ID from the master change notification means, the master stored in the first storage means Change the master ID without replacing the master ID stored in the first storage means with the master ID if the master ID is not the same as the master ID stored in the master table. Means are provided.
  • the invention according to claim 19 is the distributed computing system according to claim 11, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when the client receives information on the master ID from the master change notification means, the master stored in the first storage means Change the master ID without replacing the master ID stored in the first storage means with the master ID if the master ID is not the same as the master ID stored in the master table. Means are provided.
  • the invention according to claim 20 is the distributed computing system according to claim 12, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when the client receives information on the master ID from the master change notification means, the master stored in the first storage means Change the master ID without replacing the master ID stored in the first storage means with the master ID if the master ID is not the same as the master ID stored in the master table. Means are provided.
  • the invention according to claim 21 is the distributed computing system according to claim 13, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when the client receives information on the master ID from the master change notification means, the master stored in the first storage means Change the master ID without replacing the master ID stored in the first storage means with the master ID if the master ID is not the same as the master ID stored in the master table. Means are provided.
  • the invention according to claim 22 is the distributed computing system according to claim 14, wherein the first storage means stores a master table for storing a master ID before change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when receiving information on the master ID from the response transmission means or the master change notification means to the client, the first storage means If the master ID is not the same as the master ID stored in the master table, the master ID stored in the first storage means is used as the master ID. A master ID changing means for replacement is provided.
  • the invention according to claim 23 is the distributed computing system according to claim 15, wherein the first storage means stores a master table that stores a master ID before the change when the master ID is changed. If the master ID is the same as the master ID stored in the master table when receiving information on the master ID from the response transmission means or the master change notification means to the client, the first storage means If the master ID is not the same as the master ID stored in the master table, the master ID stored in the first storage means is used as the master ID. A master ID changing means for replacement is provided.
  • the invention according to claim 24 is the distributed computing system according to claim 16, wherein when the master ID changing unit receives information on the master ID from the response transmitting unit, the master ID is a replica of the transmission source Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the invention according to claim 25 is the distributed computing system according to claim 17, wherein when the master ID changing unit receives information on the master ID from the response transmitting unit, the master ID is a replica of the transmission source. Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the invention according to claim 26 is the distributed computing system according to claim 18, wherein when the master ID changing means receives information on the master ID from the response sending means, the master ID is a replica of the sending source. Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the master ID changing unit when the master ID changing unit receives information on the master ID from the response transmitting unit, the master ID is a replica of the transmission source Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the invention according to claim 28 is the distributed computing system according to claim 20, wherein when the master ID changing means receives information on the master ID from the response transmitting means, the master ID is a replica of the transmission source. Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the invention according to claim 29 is the distributed computing system according to claim 21, wherein when the master ID changing unit receives information on the master ID from the response transmitting unit, the master ID is a replica of the transmission source. Or the master ID stored in the first storage means is replaced when the master ID is the same as the master ID stored in the first storage means. It is characterized by not.
  • the invention according to claim 30 is the distributed computing system according to claim 22, wherein the master ID changing means receives the master ID information from the response sending means or the master change notifying means. If the ID is the same as the ID of the replica of the transmission source, or if the master ID is the same as the master ID stored in the first storage means, the ID is stored in the first storage means. The master ID is not replaced.
  • the invention according to claim 31 is the distributed computing system according to claim 23, wherein when the master ID changing means receives information on the master ID from the response sending means or the master change notifying means, the master ID changing means If the ID is the same as the ID of the replica of the transmission source, or if the master ID is the same as the master ID stored in the first storage means, the ID is stored in the first storage means. The master ID is not replaced.
  • a processing request notification means for receiving a processing request from a client at each replica constituting the cell and notifying other replicas of a processing request and a client ID for identifying the client, and the client
  • the processing request is received from the client, or the processing request notification means of the replica that has received the processing request is notified that the processing request has been received, and a predetermined process is performed by establishing a session with the client based on the client ID Since the processing execution means is provided, each replica establishes the same session with the client based on the client ID and performs processing, so that there are a plurality of connection windows with the cell client, and the connection is established. It is possible to prevent the service provision from being stopped due to the occurrence of a failure at the window.
  • 2 is a flowchart showing processing in a client in the distributed computing system of FIG. 2 is a flowchart showing threads when a request packet is received at a server in the distributed computing system of FIG. 1.
  • 2 is a flowchart showing threads when an update processing execution notification in a server is received in the distributed computing system of FIG. 1.
  • 2 is a flowchart showing threads when transmitting a response packet in a server in the distributed computing system of FIG. 1.
  • FIG. 8 is a flowchart showing a file writing process as an example of the updating process of FIG. 7.
  • FIG. It is a flowchart which shows an event acquisition start process as an example of the update process of FIG. It is a flowchart which shows the process at the time of event generation after event management start. It is a flowchart which shows an event acquisition request process as an example of the update process of FIG. It is a flowchart which shows an event acquisition completion process as an example of the update process of FIG. It is explanatory drawing which shows the example of a master selection arrangement
  • FIG. 1 shows a distributed computing system according to this embodiment.
  • the distributed computing system 1 includes a cell 2 and a client 3, and the cell 2 includes a plurality of replicas that are synchronized with each other.
  • a replica three servers 4 that form an agreement by Paxos and synchronize (in the case of distinguishing each server 4 and in the drawings, each server is represented by reference numerals 4a, 4b, and 4c, respectively) are exemplified.
  • replicas are not limited to this.
  • the servers 4a, 4b, and 4c are connected to each other via a dedicated line or an Internet line, and are connected to the client 3 via an Internet line.
  • a request for task processing (application processing) or the like is received from the application of the client 3, the processing is performed as described later, and when a response is generated, the master described below transmits the response to the client 3.
  • the request from such an application includes an update request for updating the data stored in the server 4 and changing its state, and a reference request for referring to the data stored in the server 4 and not changing its state. Yes, the server 4 performs an update process or a reference process in response to each request.
  • One of the servers 4a, 4b, and 4c serves as a master mainly responsible for communication with the client 3 at the time of an update request, and one of the servers 4a, 4b, and 4c serves as a reference from the client 3 at the time of a reference request (hereinafter referred to as "reference"). It is said.) Since the servers 4a, 4b, and 4c form an agreement by Paxos, the Paxos leader may be the master. The Paxos leader may be determined by any known method, or by a method in which the oldest server (the server with the longest startup time and the longest continuous operation time in the cell 2) is used as the leader. Further, since the servers 4a, 4b, and 4c generally have different loads, in this embodiment, a load value is calculated and a value having a small value is used as a reference.
  • the client 3 and the server 4 are general-purpose computers, respectively, and reference numerals 5 and 6 are assigned to control units such as CPUs, and reference numerals 7 and 8 are assigned to storage devices such as memories (each control part 6 and each server 4).
  • each control unit is represented by reference numerals 6a, 6b, and 6c, and each storage device is represented by reference numerals 8a, 8b, and 8c, respectively.
  • an area (session structure) for storing various session information related to the session between the cell 2 and the client 3 is secured, and this is referred to as a client session 9.
  • an area (session structure) for storing various session information is created and secured in the storage device 8 of the server 4 and is referred to as a server session 10 (when each server session 10 is distinguished or in the drawings).
  • the client session 9 stores connection information, client ID, transaction sequence number, master ID, reference ID, master selection array as a master table, update transaction sequence number, and the like.
  • connection information is connection information with the server 4, specifically, each IP address of the servers 4 a, 4 b, 4 c and each connection state between the client 3 and the servers 4 a, 4 b, 4 c (whether or not there is a connection) ).
  • Client ID is a unique ID that identifies a session, and includes a client 3 IP address, a process ID assigned to each process by the client 3, and a tag ID assigned to each tag.
  • Transaction serial number is a serial number in a session attached to a transaction issued by the client 3.
  • Master ID is the ID of the server 4 that the client 3 recognizes as the master.
  • Reference ID is the ID of the server 4 that the client 3 recognizes as a reference.
  • the “master selection array” is used to avoid circulation when the master is changed, and details will be described later.
  • Update transaction sequence number is a number that is replaced with a transaction sequence number when the request from the client 3 is an update request and this is properly processed in the server 4.
  • a request packet is transmitted from the client 3 to the server 4.
  • the request packet includes a client ID, a transaction sequence number, an update transaction sequence number, as shown in FIG. It includes a command indicating request contents and data (request data) necessary for processing the command.
  • the server session 10 stores a client ID, a session state, a request start transaction sequence number, a request end transaction sequence number, a response transaction sequence number, a hold response flag, a hold response list, an event wait flag, a hold event list, and the like.
  • 8 stores a master ID and a reference ID separately from the server session 10.
  • Master ID is the ID of the server 4 that the server 4 recognizes as the master, and is independent of the master ID stored in the client session 9.
  • Reference ID is an ID of the server 4 that the server 4 recognizes as a reference.
  • the servers 4a, 4b, and 4c calculate their own load values by a predetermined method, and exchange the information with each other to recognize the server 4 having the minimum load value as a reference, and store the ID as a reference ID. Store in the devices 8a, 8b, 8c.
  • This reference ID is transmitted from the server 4 to the client 3 by a response packet or a master notification packet described later.
  • the reference ID in the client session 9 is replaced with the reference ID transmitted from the server 4 when it becomes “unknown” indicating that the reference is unknown.
  • the reference ID is set to “unknown” as an initial value, and is also set to “unknown” when the operation of the corresponding server 4 cannot be confirmed.
  • “Client ID” is the client ID in the client session 9 conveyed by the request packet.
  • the server session 10 is managed using a hash or the like so that it can be identified by the client ID.
  • Session state indicates the state of the server session 10, and is opened when a session establishment request is sent from the client 3 to the server 4, and closed when a session closure request is made.
  • the “request start transaction sequence number” is a number that is replaced with the transaction sequence number in the request packet when the server 4 starts the update process or the reference process.
  • the “request end transaction sequence number” is a number that is replaced with the transaction sequence number or the request start transaction sequence number in the request packet when the server 4 finishes the update process or the reference process.
  • the “response transaction sequence number” is a number that is replaced with the transaction sequence number in the request packet or the request start transaction sequence number when the server 4 generates the response packet described below.
  • the response packet includes an ID (replica ID) of the server 4 that transmits the packet, Reference ID, packet type (response type) indicating that the packet is a response packet, client ID for identifying the client 3 and session to which the packet is transmitted, response transaction sequence number, and data indicating response content (response data) including.
  • the server 4 may transmit a master notification packet that notifies the master instead of a response packet.
  • This master notification packet is a server that transmits the packet as shown in FIG. 4 ID (replica ID), reference ID, packet type (master type) indicating that the packet is a master notification packet, and master ID.
  • the “pending response flag” is a flag indicating whether or not the server 4 may transmit a response packet to the client 3 or whether transmission should be held as a hold response. If this flag is “true”, the server 4 regards it as a hold instruction, holds the generated response packet as a pending response, and if this flag is “false”, regards it as a release instruction, and transmits the generated response packet.
  • the “pending response list” is one or a plurality of response packets stored as a pending response.
  • the “event waiting flag” is a flag indicating whether or not the generated event may be transmitted to the client 3 when the server 4 manages the event, or whether transmission should be suspended as a suspended event.
  • an event can be managed by the server session 10, and the server 4 that is instructed to manage the event by the client 3 sets the event waiting flag to “true” if an event acquisition request is received from the client 3.
  • the generated event is transmitted to the client 3.
  • the event waiting flag is set to “false”, and the generated event is not immediately transmitted to the client 3 but is held as a hold event.
  • Any event can be used. For example, when adding or deleting a file to a directory path (changing a directory under the addition or deletion of a file) is used as an event, the directory path is used as an event resource. . Events and event resources are defined by the application.
  • the “pending event list” is one or a plurality of events stored as a holding event.
  • [Distributed computing method] 5 to 15 show a distributed computing method by the distributed computing system 1, that is, a procedure in which an application of the client 3 transmits a reference request or an update request to the cell 2, and the reference process or the update process is performed in the cell 2. (See FIG. 2).
  • step 101 when there is a request from an application (step 101 (denoted as “S.101” in the drawing, the same applies hereinafter)), the control unit 5 of the client 3 increments the transaction serial number (step 102). It is determined whether or not it is an update request (step 103). If it is an update request, the master ID of the client session 9 is referred to (step 104). If it is not an update request, the reference ID is referred to as a reference request (step 105), and the server 4 specified by the referenced ID is sent. The request packet is transmitted to the control unit 6 (step 106).
  • the client 3 performs synchronous transaction communication with the server 4 by sending a request packet and waiting for a response packet. Therefore, the order of the packets is guaranteed by the client 3.
  • the control unit 5 of the client 3 that has transmitted the request packet waits for a response packet or a master notification packet to arrive from the control unit 6 of the server 4, and if there is no response after a certain time, refers to the master ID or reference ID again.
  • the request packet is transmitted (steps 107 to 109).
  • the control unit 6 of the server 4 that has received the request packet acquires the server session 10 from a hash or the like based on the client ID included in the request packet (corresponding to the client ID). If there is no server session 10 to be created, it is newly created: step 202).
  • control unit 6 determines whether or not it is an update request based on a command included in the request packet (step 203).
  • the control unit 6 checks whether or not its own server 4 is a master (step 204), and if it is a master, the contents of the request packet are sent to all the servers 4 (including the master itself). Notification is made (step 205), and an agreement is consulted by Paxos on whether or not the update processing can be performed (step 206). Further, the control unit 6 determines that the master recognized by the client 3 and the server 4 is different if it is not the master in step 204 (for example, if there is a master change but it has not been transmitted to the client 3). In such a case, it is determined that the control unit 6 is not a master.), A master notification packet is transmitted to the control unit 5 of the client 3 (step 207). Upon receiving the master notification packet, the control unit 5 replaces the client ID of the client session 9 with the master ID in the master notification packet, and transmits the request packet again (see steps 109 and 110 in FIG. 5).
  • step 206 if the consent of the majority of servers 4 is obtained and an agreement is formed by Paxos, the master control unit 6 that has received the request packet controls the control units 6 of all the servers 4 (including the master itself). In response to this, an update processing execution notification is transmitted (step 208). As a result, all servers 4 respond to the update request. If no agreement is formed by Paxos in Step 206, the control unit 6 proceeds to Step 201 and enters a standby state for the next request packet.
  • the server 4 that has received the request packet responds to the reference request.
  • the control unit 6 of the server 4 that has received the update processing execution notification acquires the server session 10 from the hash or the like based on the client ID in the request packet (the client ID). If there is no server session 10 corresponding to, a new one is created: Step 302).
  • control unit 6 confirms whether or not the session state of the server session 10 acquired in step 302 is open (step 303), and if not open, transmits an error response to the control unit 5 of the client 3 ( Step 304), the process proceeds to Step 301 to enter a standby state for notification of execution of the next update process.
  • the control unit 6 determines whether the transaction sequence number in the request packet is the same as the response transaction sequence number stored in the server session 10 (described as “response sequence number” in the drawing). It is determined whether or not (step 305). In the case of one request and one response, if the transaction sequence number is the same as the response transaction sequence number, the response packet stored as a pending response including the response transaction sequence number is generated corresponding to the request packet including the transaction sequence number.
  • the control unit 6 confirms that the pending response flag is “false” (step 306) and that its own server 4 is also the master at that time. (Step 307) The response packet held as a hold response is transmitted to the control unit 5 of the client 3 without generating a response packet again (step 308). If the pending response flag is “true” in step 306 or if its own server 4 is not the master in step 307, the control unit 6 proceeds to step 301 and enters a standby state for notification of execution of the next update process. enter.
  • the control unit 6 If the transaction sequence number and the response transaction sequence number are not the same in step 305, the control unit 6 describes the transaction sequence number in the request packet and the request start transaction sequence number stored in the server session 10 (described as “request start sequence number” in the drawing). )) Is the same (step 309). If the transaction sequence number and the request start transaction sequence number are the same, the server 4 is considered to be processing the same request as this time, so the control unit 6 ignores the current request to avoid duplicate processing. .
  • step 309 if the transaction sequence number and the request start transaction sequence number are not the same, the control unit 6 replaces the request start transaction sequence number with the transaction sequence number (step 310). Then, an update process is performed based on the command and request data in the request packet (step 311). When this update process is completed, the request end transaction sequence number (described as “request end sequence number” in the drawing) is used as the transaction sequence number. Replace (step 312).
  • update processing There are many examples of update processing.
  • a request for opening a server session transmitted from the client 3 to the server 4 or a request for closing an opened server session is an update request.
  • the process is an update process.
  • the file writing process is also an update process.
  • a server session establishment process as shown in FIG. 9 is performed as an update process in step 311 (at this time, the control unit 6 performs step 303). (Omitted, the process proceeds from step 302 to step 305).
  • control unit 6 opens the session state of the server session 10 acquired in step 302 (step 501), initializes values of each transaction serial number and the like (step 502), and when these processes are completed, Is sent to the control unit 5 of the client 3 (step 503), and step 401 of FIG. 8 is called to perform transmission processing of the response packet (step 504).
  • control unit 6 determines whether or not it is necessary to transmit a response packet for the current update process (step 401). If not necessary, the control unit 6 proceeds to step 312 (the lock or the like as described later). If so, the control unit 6 may not generate a response packet. In such a case, although one request is one response, the response is delayed until the lock is released.
  • the control unit 6 checks the hold response flag (step 402). If the flag is “true”, the response packet generated in step 503 is added to the hold response list to hold the response packet. The response list is updated (step 403). On the other hand, if the flag is “false”, the pending response list is updated by replacing the pending response list with the response packet generated in step 503 (step 404).
  • control unit 6 replaces the response transaction sequence number with the transaction sequence number (step 405), and confirms whether or not its own server 4 is a master (step 406). If it is a master, the control part 6 transmits the response packet of a pending
  • the command included in the request packet is a server session closing command
  • a server session closing process as shown in FIG.
  • the control unit 6 cancels the open state of the server session 10 opened in step 501 (closes the session state) (step 511), and when this processing is completed, a response packet for notifying the client 3 of that fact is sent. 8 is generated (step 512), and step 401 is called to perform the response packet transmission processing of FIG. 8 (step 513).
  • the request data in the request packet includes the file path name, offset, data to be written, and the length of the data to be written.
  • a file writing process as shown in FIG. 11 is performed.
  • the control unit 6 opens the file (step 521), writes data from the offset (step 522), and closes the file (step 523). Then, a response packet including the written length is generated (step 524), and step 401 is called to perform response packet transmission processing in FIG. 8 (step 525).
  • the control unit 6 determines whether or not the request end transaction sequence number is equal to or greater than the update transaction sequence number in the request packet (step 209), and the request end transaction sequence number is updated. If the transaction sequence number is greater than or equal to the transaction number, the server 4 confirms that the session state has been opened and proceeds to the reference process (step 210), assuming that the update is not delayed and can be used for reference. If the session state is not open, the control unit 6 transmits an error response to the control unit 5 of the client 3 (step 211).
  • the control unit 6 replaces the request start transaction sequence number with the transaction sequence number in the request packet (step 212), and performs reference processing based on the command and request data in the request packet. (Step 213) When this reference process is completed, the request end transaction sequence number is replaced with the transaction sequence number (step 214). Also in the reference process of step 213, the control unit 6 transmits a response packet including the reference contents to the control unit 5 of the client 3, but the method is the same as the response packet transmission process of FIG. And go to step 214).
  • step 209 if the request end transaction sequence number is less than the update transaction sequence number, the control unit 6 interrupts the process and enters a standby state. Then, if the update delay is resolved and the request end transaction sequence number is equal to or greater than the update transaction sequence number in the request packet, the wake-up and interrupted processing is continued.
  • Step 109 the control unit 5 of the client 3 receives the response packet from the server 4, the control unit 5 exits from the standby state of Step 109 (see FIG. 5). If the reference ID is unknown, the reference ID stored in the client session 9 is included in the response packet. (Steps 111 and 112). Subsequently, the control unit 5 determines whether or not the response transaction sequence number in the response packet is the same as an expected value (step 113). This expected value is the same as the transaction sequence number. If the response transaction sequence number is the same as the expected value, it means that an appropriate response to the request has been received. When receiving a response to the update request, the control unit 5 replaces the update transaction sequence number with the transaction sequence number (step 114), and proceeds to step 101 for the next request or is controlled by the application. Return.
  • control unit 5 discards the received response packet (step 115) and returns to step 107. Wait for an appropriate response.
  • the control unit 6 of the server 4 When a plurality of response packets are derived from a single request, for example, in the case of multiple SQL statements in the database, the control unit 6 of the server 4 accumulates the response packets using a hold response flag, and holds a plurality (predetermined number) of hold packets. At this point, the master control unit 6 may transmit the response as a single response. That is, since the control unit 6 can know that a plurality (predetermined number) of response packets are created by analyzing the command of the request packet, the pending response flag is kept until the plurality (predetermined number) of response packets are created. Is set to “true”, the generated response packet is held so as not to be transmitted immediately, and sequentially stored in the pending response.
  • the master control unit 6 adds a plurality of (predetermined number) of response packets with a header to the batch. Send.
  • the server 4 can manage events by the server session 10.
  • an event acquisition start request is transmitted. After the event acquisition start request is transmitted, the client 3 transmits an event acquisition request to request the server 4 to acquire the event. In addition, when the client 3 requests the server 4 to end the event management, an event acquisition end request is transmitted. Since these requests related to event management are update requests, specifically, the following processing may be performed in step 311.
  • the control unit 6 of the server 4 associates the event resource with the server session 10 and stores it in the storage device 8 (step 601).
  • This association is performed by setting a joint between the event resource and the server session 10.
  • the joint includes an event link that links the joint and the event resource, a session link that links the joint and the server session 10, And a post-processing function when the joint is discarded.
  • the event resource to be associated is specified by the request packet of the event acquisition start request, and the server session 10 to be associated is specified at step 302 (or step 202).
  • control unit 6 When the association is completed, the control unit 6 generates a response packet to that effect (step 602) and transmits it to the control unit 5 of the client 3 (step 603).
  • the method is the same as the response packet transmission process of FIG. It is.
  • the processing of the server 4 differs depending on whether an event acquisition request is received from the client 3 or not.
  • the control unit 6 of the server 4 checks the event waiting flag (as described above, and will be described in detail later). As described above, if an event acquisition request is received from the client 3, the event wait flag is “true”, and if no event acquisition request is received from the client 3, the event wait flag is “false”: Step 612). If the event waiting flag is “true”, a response packet is generated to transmit the generated event to the client 3 (step 613), and is transmitted to the control unit 5 of the client 3 in the same manner as in FIG. In step 614), the event waiting flag is set to "false” (step 615).
  • the control unit 6 adds the generated event to the hold event and registers it (step 616), and enters a standby state such as an event acquisition request or the next event occurrence. .
  • the control unit 6 checks whether there is a pending event in the pending event list (step 622).
  • the wait flag is set to “true” (step 623) so that an event generated until the next event acquisition request is held in the hold event list.
  • control unit 6 cuts all the pending events registered in the pending event list in a lump and generates a response packet including these (step 624), and sends the response packet to the control unit 5 of the client 3 Transmission is performed in the same manner as in FIG. 8 (step 625).
  • control unit 6 of the server 4 upon receiving the event acquisition end request, releases the association between the event resource and the server session 10 (step 631), and generates a response packet to that effect (step 631). 632), and transmits to the control unit 5 of the client 3 by the same method as in FIG. 8 (step 633).
  • the servers 4a, 4b, and 4c are not necessarily always in operation (in order to form an agreement by Paxos, it is only necessary that two of the three are in operation), and the master itself may fail. A master change may occur due to a communication failure between the master and another server.
  • the server 4 recognizes the master change, if the server 4 is connected to the client 3, a master notification packet as shown in FIG. 4 can be transmitted to notify the client 3 of the master change.
  • a master selection array for avoiding circulation as shown in FIG. 16 is prepared.
  • the master selection array every time the master ID of the client session 9 is changed, the array element of the server 4 corresponding to the old master ID is marked with “1” (the array element not marked is “0”). .) Therefore, if the client 3 newly receives the master notification packet and the array element of the server 4 corresponding to the master ID in the master notification packet is marked, the master notification packet has notified the old master. Since there is a fear, the control unit 5 of the client 3 considers that the above-mentioned circulation has occurred, and waits for the next master notification packet without replacing the master ID of the client session 9 with the master ID notified by the master notification packet.
  • the server 4 that has transmitted the master notification packet recognizes itself as the master, and no circulation occurs. Then, the control unit 5 of the client 3 sets the replica ID as the master ID of the client session 9 and clears all marks in the master selection array.
  • the master 3 and the server 4 have the same master recognition. do nothing.
  • the control unit 5 marks “1” in the array element of the server 4 corresponding to the master ID in the master notification packet. It is judged whether it is attached. If it is marked, it is determined that the above-described circulation has occurred and that the master is being selected (Jeopard), and the master ID of the client session 9 is unknown, and the next master notification packet is awaited. If not marked, the array element of the server 4 corresponding to the master ID previously stored in the client session 9 is marked, and the master ID of the client session 9 is replaced with the master ID in the master notification packet. .
  • the control unit 5 When the controller 5 detects the disconnection of any of the servers 4a, 4b, and 4c based on the connection information so that the old master whose connection has been disconnected is not recognized as the master, the control unit 5 If the master ID of the client session 9 matches, the array element of the server 4 corresponding to the master ID of the client session 9 is marked.
  • control unit 5 clears all the marks of the master selection array and sequentially sends request packets to the servers 4a, 4b, 4c. And wait for the master notification packet to be sent.
  • each server 4 configuring the cell 2 receives a processing request from the client 3, and notifies that the processing request has been made and the client ID that identifies the client 3 to the other server 4.
  • a processing request notification means for notifying the server 4 and a processing request from the client 3 or a notification to the effect that a processing request has been received from another server 4 that has received the processing request. Since the control unit 6 is provided that functions as a process execution means for establishing a session between them and performing a predetermined process, each server 4 establishes the same session with the client 3 based on the client ID for processing. By doing this, there are multiple connection windows with the cell client, which is caused by a failure at the connection window. It is possible to prevent the stopping of the service provider.
  • the servers that make up the cell may synchronize without relying on Paxos, and the Paxos leader may not be the master.
  • the configuration of the request packet, response packet, master notification packet, and client ID may be different from those described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】　セルのクライアントとの接続窓口における障害発生に起因するサービス提供の停止を防止することができる分散コンピューティングシステムを提供する。 【解決手段】　本発明に係る分散コンピューティングシステム１では、セル２を構成するサーバー４の制御部６が、クライアント３の制御部５から処理要求を受け、処理要求があった旨及びそのクライアント３を特定するクライアントＩＤを他のサーバー４に通知するとともに、クライアント３の制御部５から処理要求を受け、又は、処理要求を受けた他のサーバー４の制御部６から処理要求があった旨の通知を受け、クライアントＩＤに基づいてクライアント３との間でセッションを開設してその処理を行う。

Description

分散コンピューティングシステム
　本発明は、互いに同期が取られる複数のレプリカを含むセルとクライアントとを備える分散コンピューティングシステムに関し、特に、セルとクライアントとの間のセッション管理技術に関する。
　複数のレプリカを含むセルとクライアントとを備える分散コンピューティングシステムについて、例えば以下のようなレプリケーション技術が知られている。
　ロードバランサー（負荷分散装置）が用いられたクラスタシステムでは、ロードバランサーの仮想化されたＩＰアドレスがクライアントとの接続窓口となり（特許文献１及び２参照）、クライアントからの要求はロードバランサーを介してレプリカに伝達され、レプリカからの応答がロードバランサーを経てクライアントに送信される。
　また、高可用性のクラスタシステムでは、本番系（主系）と待機系（予備系）のレプリカが設けられ（特許文献３及び４参照）、クライアントにサービスを提供していた本番系のレプリカが障害によりダウンすると、例えばホット・スタンバイの状態にある待機系のレプリカが本番系のレプリカの処理を引き継いでサービス提供を継続する。
　仮想マシンでは、ハードウェアレベルの仮想化、つまり、物理的に一つのハードウェアの中に複数の仮想ハードウェアを構築し、それら一つ一つをレプリカとして機能させることにより（特許文献５参照）、上記高可用性のクラスタシステムと同様な可用性を実現している。
　ＲＡＩＤ装置では、ディスクを仮想化したインターフェースを提供し、ミラー化やプール化によりデータを多重化・冗長化して保存する。
特開２０１０－８６１４５号公報 特開平９－２１８８４２号公報 特開２００９－２６５６９０号公報 特開平１０－１０５４２４号公報 特開２０１０－３３２８０号公報
　上記各レプリケーション技術では、仮想化技術により、レプリカ群がクライアントから一つの仮想システムとしてみえるだけで、レプリカ間の分散協調方式はブラックボックス化されている。すなわち、クライアントとレプリカ群との接続窓口が一つであり、この接続窓口となる箇所に障害が生じると、クライアントはブラックボックス内部のレプリカへのアクセス方法を失うので、たとえレプリケーションにより高可用性が図られていても、セルによるサービス提供が停止する。
　本発明は、上記の事情に鑑みてなされたもので、セルのクライアントとの接続窓口における障害発生に起因するサービス提供の停止を防止することができる分散コンピューティングシステムを提供することを課題としている。
　上記課題を解決するために、請求項１に係る発明は、互いに同期が取られる複数のレプリカを含むセルとクライアントとを備え、前記クライアントに、前記セルと前記クライアントとの間のセッションを管理するためのセッション情報として、前記クライアントが各レプリカと接続するための接続情報及び前記クライアントを特定するためのクライアントＩＤを記憶する第一の記憶手段と、前記複数のレプリカのいずれかに対し、前記接続情報に基づき所定の処理の要求及び前記クライアントＩＤの通知を行う処理要求手段とが設けられ、前記各レプリカに、前記処理要求手段からの処理要求を受け、処理要求があった旨及び前記クライアントＩＤを他のレプリカに通知する処理要求通知手段と、前記処理要求手段から処理要求を受け、又は、処理要求を受けたレプリカの処理要求通知手段から処理要求があった旨の通知を受け、前記クライアントＩＤに基づき前記クライアントとの間で前記セッションを開設して前記所定の処理を行う処理実行手段とが設けられている分散コンピューティングシステムを特徴とする。
　請求項２に係る発明は、請求項１に記載の分散コンピューティングシステムにおいて、前記所定の処理が、更新処理であることを特徴とする。
　請求項３に係る発明は、請求項１に記載の分散コンピューティングシステムにおいて、前記所定の処理の要求が、前記各レプリカに前記セッションを開設させるためのセッション開設要求であることを特徴とする。
　請求項４に係る発明は、請求項１乃至請求項３のいずれか１項に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記複数のレプリカの一つがマスターとして選ばれる場合に、いずれのレプリカがマスターであるかを特定するためのマスターＩＤを記憶し、前記処理要求手段が、前記第一の記憶手段に記憶されたマスターＩＤにより特定されるレプリカに対し、前記所定の処理の要求及び前記クライアントＩＤの通知を行うことを特徴とする。
　請求項５に係る発明は、請求項４に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記複数のレプリカの一つが参照処理時の参照に供するリファレンスとして選ばれる場合に、いずれのレプリカがリファレンスであるかを特定するためのリファレンスＩＤを記憶し、前記処理要求手段が、前記第一の記憶手段に記憶されたリファレンスＩＤにより特定されるレプリカに対し、参照処理の要求を行うことを特徴とする。
　請求項６に係る発明は、請求項４に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記所定の処理の要求に対する応答を生成する応答生成手段と、前記マスターＩＤを前記第一の記憶手段とは独立して記憶するとともに前記応答生成手段により生成された応答を記憶する第二の記憶手段と、前記第二の記憶手段に記憶された応答を前記クライアントに送信可能な応答送信手段とが設けられ、前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターであると判断したときに、前記第二の記憶手段に記憶された応答を前記クライアントに送信することを特徴とする。
　請求項７に係る発明は、請求項５に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記所定の処理の要求に対する応答を生成する応答生成手段と、前記マスターＩＤを前記第一の記憶手段とは独立して記憶するとともに前記応答生成手段により生成された応答を記憶する第二の記憶手段と、前記第二の記憶手段に記憶された応答を前記クライアントに送信可能な応答送信手段とが設けられ、前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターであると判断したときに、前記第二の記憶手段に記憶された応答を前記クライアントに送信することを特徴とする。
　請求項８に係る発明は、請求項６に記載の分散コンピューティングシステムにおいて、前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターでないと判断したときに、そのマスターＩＤに関する情報を前記第二の記憶手段に記憶された応答の代わりに前記クライアントに送信することを特徴とする。
　請求項９に係る発明は、請求項７に記載の分散コンピューティングシステムにおいて、前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターでないと判断したときに、そのマスターＩＤに関する情報を前記第二の記憶手段に記憶された応答の代わりに前記クライアントに送信することを特徴とする。
　請求項１０に係る発明は、請求項４に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１１に係る発明は、請求項５に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１２に係る発明は、請求項６に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１３に係る発明は、請求項７に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１４に係る発明は、請求項８に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１５に係る発明は、請求項９に記載の分散コンピューティングシステムにおいて、前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする。
　請求項１６に係る発明は、請求項８に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項１７に係る発明は、請求項９に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項１８に係る発明は、請求項１０に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項１９に係る発明は、請求項１１に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項２０に係る発明は、請求項１２に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項２１に係る発明は、請求項１３に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項２２に係る発明は、請求項１４に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項２３に係る発明は、請求項１５に記載の分散コンピューティングシステムにおいて、前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、前記クライアントに、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする。
　請求項２４に係る発明は、請求項１６に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項２５に係る発明は、請求項１７に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項２６に係る発明は、請求項１８に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項２７に係る発明は、請求項１９に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項２８に係る発明は、請求項２０に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項２９に係る発明は、請求項２１に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項３０に係る発明は、請求項２２に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　請求項３１に係る発明は、請求項２３に記載の分散コンピューティングシステムにおいて、前記マスターＩＤ変更手段が、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする。
　本発明によれば、セルを構成する各レプリカに、クライアントからの処理要求を受け、処理要求があった旨及びそのクライアントを特定するクライアントＩＤを他のレプリカに通知する処理要求通知手段と、クライアントから処理要求を受け、又は、処理要求を受けたレプリカの処理要求通知手段から処理要求があった旨の通知を受け、クライアントＩＤに基づきクライアントとの間でセッションを開設して所定の処理を行う処理実行手段とが設けられているので、各レプリカがクライアントとの間にクライアントＩＤに基づき同一のセッションを開設して処理を行うことにより、セルのクライアントとの接続窓口が複数になって、接続窓口における障害発生に起因するサービス提供の停止を防止することができる。
　本発明によれば、セルのクライアントとの接続窓口における障害発生に起因するサービス提供の停止を防止することができるという効果を奏する。
発明を実施するための形態に係る分散コンピューティングシステムを示す説明図である。 要求パケットの例を示す説明図である。 応答パケットの例を示す説明図である。 マスター通知パケットの例を示す説明図である。 図１の分散コンピューティングシステムにおいて、クライアントにおける処理を示す流れ図である。 図１の分散コンピューティングシステムにおいて、サーバーにおける要求パケットを受信したときのスレッドを示す流れ図である。 図１の分散コンピューティングシステムにおいて、サーバーにおける更新処理の実行通知を受信したときのスレッドを示す流れ図である。 図１の分散コンピューティングシステムにおいて、サーバーにおける応答パケットを送信するときのスレッドを示す流れ図である。 図７の更新処理の例としてセッション開設処理を示す流れ図である。 図７の更新処理の例としてセッション閉鎖処理を示す流れ図である。 図７の更新処理の例としてファイル書出処理を示す流れ図である。 図７の更新処理の例としてイベント取得開始処理を示す流れ図である。 イベント管理開始後イベント発生時の処理を示す流れ図である。 図７の更新処理の例としてイベント取得要求処理を示す流れ図である。 図７の更新処理の例としてイベント取得終了処理を示す流れ図である。 マスター選択配列の例を示す説明図である。
　本発明を実施するための形態について、図面を用いて説明する。
〔分散コンピューティングシステムの構成〕
　図１は、本形態に係る分散コンピューティングシステムを示す。この分散コンピューティングシステム１は、セル２とクライアント３とを備え、セル２は互いに同期が取られる複数のレプリカにより構成されている。ここでは、レプリカとして、Ｐａｘｏｓにより合意を形成して同期を取る３つのサーバー４（各サーバー４を区別する場合や図面においては、各サーバーをそれぞれ符号４ａ，４ｂ，４ｃで表す。）を例示するが、レプリカはこれに限られるものではない。
　サーバー４ａ，４ｂ，４ｃは、専用回線又はインターネット回線を介して互いに接続されるとともに、インターネット回線を介してクライアント３に接続されている。そして、クライアント３のアプリケーションからタスク処理（アプリケーション処理）等の要求を受けると、後述のように当該処理を行い、応答を生成した場合にはこれを次述のマスターがクライアント３に送信する。このようなアプリケーションからの要求には、サーバー４に記憶されたデータを更新してその状態を変更する更新要求と、サーバー４に記憶されたデータを参照してその状態を変更しない参照要求とがあり、サーバー４は各要求に応じて更新処理又は参照処理を行う。
　また、サーバー４ａ，４ｂ，４ｃは、そのいずれかが更新要求時にクライアント３との通信等を主として担うマスターになり、そのいずれかが参照要求時にクライアント３からの参照に供するサーバー（以下「リファレンス」という。）になる。サーバー４ａ，４ｂ，４ｃはＰａｘｏｓにより合意を形成するので、Ｐａｘｏｓのリーダーをマスターとすればよい。Ｐａｘｏｓのリーダーの決定は、公知のいずれの方法によっても、あるいは、最長老のサーバー（セル２において起動時刻が最先で連続稼働時間が最長のサーバー）をリーダーとする方法によってもかまわない。また、サーバー４ａ，４ｂ，４ｃは一般に負荷が異なるので、本形態では負荷値を算出してその値が小さいものをリファレンスとする。
　クライアント３及びサーバー４は、ここでは、それぞれ汎用のコンピューターであり、それらのＣＰＵ等の制御部に符号５及び６を、メモリ等の記憶装置に符号７及び８を付す（各制御部６や各記憶装置８を区別する場合や図面においては、各制御部をそれぞれ符号６ａ，６ｂ，６ｃで表し、各記憶装置をそれぞれ符号８ａ，８ｂ，８ｃで表す。）。
　クライアント３の記憶装置７には、セル２とクライアント３との間のセッションに関する各種のセッション情報を記憶する領域（セッション構造体）が確保され、これをクライアントセッション９と称する。同様に、サーバー４の記憶装置８には、各種のセッション情報を記憶する領域（セッション構造体）が作成・確保され、これらをサーバーセッション１０と称する（各サーバーセッション１０を区別する場合や図面においては、各サーバーセッションをそれぞれ符号１０ａ，１０ｂ，１０ｃで表す。）。
　クライアントセッション９には、接続情報、クライアントＩＤ、トランザクション通番、マスターＩＤ、リファレンスＩＤ、マスターテーブルとしてのマスター選択配列及び更新トランザクション通番等が格納される。
　「接続情報」とは、サーバー４との接続情報であって、具体的にはサーバー４ａ，４ｂ，４ｃの各ＩＰアドレス及びクライアント３とサーバー４ａ，４ｂ，４ｃとの各接続状態（接続の有無）に関する情報である。
　「クライアントＩＤ」とは、クライアント３のＩＰアドレス、クライアント３によるプロセスごとに付されるプロセスＩＤ及びタグごとに付されるタグＩＤからなり、セッションを特定するユニークなＩＤである。
　「トランザクション通番」とは、クライアント３が発行するトランザクションに付されるセッション内での通し番号である。
　「マスターＩＤ」とは、クライアント３がマスターとして認識しているサーバー４のＩＤである。
　「リファレンスＩＤ」とは、クライアント３がリファレンスとして認識しているサーバー４のＩＤである。
　「マスター選択配列」とは、マスター交替時の循環の回避に用いられ、詳細については後述する。
　「更新トランザクション通番」とは、クライアント３からの要求が更新要求であって、これがサーバー４において適切に処理されたときに、トランザクション通番で置換される番号である。
　クライアント３がサーバー４に所定の処理を要求する場合、クライアント３からサーバー４に要求パケットが送信されるが、この要求パケットは、図２に示すように、クライアントＩＤ、トランザクション通番、更新トランザクション通番、要求内容を示すコマンド及びコマンドの処理に必要なデータ（要求データ）を含む。
　一方、サーバーセッション１０には、クライアントＩＤ、セッション状態、要求開始トランザクション通番、要求終了トランザクション通番、応答トランザクション通番、保留応答フラグ、保留応答リスト、イベント待ちフラグ及び保留イベントリスト等が格納され、記憶装置８には、サーバーセッション１０とは別に、マスターＩＤ及びリファレンスＩＤが記憶されている。
　「マスターＩＤ」は、サーバー４がマスターとして認識しているサーバー４のＩＤであり、クライアントセッション９に記憶されているマスターＩＤとは独立している。
　「リファレンスＩＤ」は、サーバー４がリファレンスとして認識しているサーバー４のＩＤである。サーバー４ａ，４ｂ，４ｃは、自身の負荷値を所定の方法で算出し、その情報を互いに交換することにより、最小の負荷値を有するサーバー４をリファレンスと認識し、そのＩＤをリファレンスＩＤとして記憶装置８ａ，８ｂ，８ｃに記憶する。このリファレンスＩＤは、後述の応答パケット又はマスター通知パケットにより、サーバー４からクライアント３に伝えられる。クライアントセッション９におけるリファレンスＩＤは、リファレンスが不明であることを示す「不明」となったときに、このサーバー４から伝えられるリファレンスＩＤで置換される。リファレンスＩＤは、初期値で「不明」と設定されるほか、それに対応するサーバー４の稼働を確認することができない場合等に「不明」と設定される。
　「クライアントＩＤ」は、クライアントセッション９におけるクライアントＩＤが要求パケットにより伝えられたものである。サーバー４においては、クライアントＩＤにより同定することができるように、サーバーセッション１０はハッシュ等を用いて管理される。
　「セッション状態」は、サーバーセッション１０の状態を示し、クライアント３からサーバー４にセッション開設要求があればオープンとなり、セッション閉鎖要求があればクローズとなる。
　「要求開始トランザクション通番」とは、サーバー４が更新処理又は参照処理を開始する段階で要求パケット中のトランザクション通番で置換される番号である。
　「要求終了トランザクション通番」とは、サーバー４が更新処理又は参照処理を終了した段階で要求パケット中のトランザクション通番又は要求開始トランザクション通番で置換される番号である。
　「応答トランザクション通番」とは、サーバー４が次述の応答パケットを生成した段階で要求パケット中のトランザクション通番又は要求開始トランザクション通番で置換される番号である。
　サーバー４がクライアント３に応答する場合、サーバー４からクライアント３に応答パケットが送信されるが、この応答パケットは、図３に示すように、そのパケットを送信するサーバー４のＩＤ（レプリカＩＤ）、リファレンスＩＤ、そのパケットが応答パケットであることを示すパケット種別（応答タイプ）、そのパケットの送信先のクライアント３及びセッションを特定するクライアントＩＤ、応答トランザクション通番並びに応答の内容を示すデータ（応答データ）を含む。サーバー４は、自身がマスターでない場合には、応答パケットではなくマスターを通知するマスター通知パケットを送信することがあるが、このマスター通知パケットは、図４に示すように、そのパケットを送信するサーバー４のＩＤ（レプリカＩＤ）、リファレンスＩＤ、そのパケットがマスター通知パケットであることを示すパケット種別（マスタータイプ）及びマスターＩＤを含む。
　「保留応答フラグ」とは、サーバー４が応答パケットを生成したときに、それをクライアント３に送信してよいか、あるいは、保留応答として送信を保留すべきかを示すフラグである。サーバー４は、このフラグが「真」ならばホールド指示と捉え、生成した応答パケットを保留応答として留め、このフラグが「偽」ならばリリース指示と捉え、生成した応答パケットを送信する。
　「保留応答リスト」とは、保留応答として保存された一又は複数の応答パケットである。
　「イベント待ちフラグ」とは、サーバー４がイベントを管理するときに、発生したイベントをクライアント３に送信してよいか、あるいは、保留イベントとして送信を保留すべきかを示すフラグである。分散コンピューティングシステム１では、サーバーセッション１０によりイベントを管理することができ、クライアント３からイベント管理を指示されたサーバー４は、クライアント３からイベント取得の要求があれば、イベント待ちフラグを「真」として、発生したイベントをクライアント３に送信する。また、クライアント３からイベント取得の要求がない状態では、イベント待ちフラグを「偽」として、発生したイベントをクライアント３に直ちに送信せず、保留イベントとして保留する。なお、イベントはどのようなものであってもよく、例えばディレクトリパスに対するファイルの追加や削除（ファイルの追加や削除によるディレクトリ配下の変更）をイベントとする場合には、ディレクトリパスをイベント資源とする。イベント及びイベント資源は、アプリケーションにより定義される。
　「保留イベントリスト」とは、保留イベントとして保存された一又は複数のイベントである。
〔分散コンピューティング方法〕
　図５乃至１５は、分散コンピューティングシステム１による分散コンピューティング方法、すなわち、クライアント３のアプリケーションがセル２に対して参照要求又は更新要求を送信し、セル２において参照処理又は更新処理が行われる手順を示す（図２参照）。
　　〔要求パケットの送信〕
　クライアント３の制御部５は、図５に示すように、アプリケーションからの要求があると（ステップ１０１（図面において「Ｓ．１０１」と記載。以下同様。））、トランザクション通番をインクリメントし（ステップ１０２）、それが更新要求であるか否かを判断する（ステップ１０３）。そして、更新要求であればクライアントセッション９のマスターＩＤを参照し（ステップ１０４）、更新要求でなければ参照要求であるとしてリファレンスＩＤを参照し（ステップ１０５）、参照したＩＤにより特定されるサーバー４の制御部６に要求パケットを送信する（ステップ１０６）。ここで、クライアント３は、サーバー４との間で、要求パケットを送り応答パケットを待つ同期型のトランザクション通信を行う。したがって、パケットの順序はクライアント３により保証されている。
　要求パケットを送信したクライアント３の制御部５は、サーバー４の制御部６から応答パケット又はマスター通知パケットが届くのを待ち、一定時間経っても応答がなければ、再度マスターＩＤ又はリファレンスＩＤを参照して要求パケットを送信する（ステップ１０７乃至１０９）。
　　〔要求パケットの受信〕
　図６に示すように、要求パケットを受信したサーバー４の制御部６は（ステップ２０１）、要求パケットに含まれるクライアントＩＤに基づいて、サーバーセッション１０をハッシュ等から取得する（そのクライアントＩＤに対応するサーバーセッション１０がなければ、それを新規に作成する：ステップ２０２）。
　次いで、制御部６は、要求パケットに含まれるコマンドに基づいて、更新要求であるか否かを判断する（ステップ２０３）。
　更新要求であれば、制御部６は、自身のサーバー４がマスターであるかどうかを確認し（ステップ２０４）、マスターであれば要求パケットの内容を全てのサーバー４（マスター自身も含む。）に通知して（ステップ２０５）、その更新処理を行ってよいかどうかにつきＰａｘｏｓにより合意を諮る（ステップ２０６）。また、制御部６は、ステップ２０４においてマスターでなければ（例えばマスター交替があったにもかかわらずそれがクライアント３に未伝達であると、クライアント３とサーバー４で認識しているマスターが異なることになり、このような場合に制御部６はマスターでないと判断する。）、クライアント３の制御部５にマスター通知パケットを送信する（ステップ２０７）。マスター通知パケットを受信した制御部５は、そのマスター通知パケット中のマスターＩＤでクライアントセッション９のクライアントＩＤを置換し、要求パケットを改めて送信する（図５のステップ１０９，１１０参照）。
　ステップ２０６において、過半数のサーバー４の同意が得られてＰａｘｏｓにより合意が形成されれば、要求パケットを受信したマスターの制御部６は、全てのサーバー４（マスター自身も含む。）の制御部６に対し、更新処理の実行通知を送信する（ステップ２０８）。これにより、全てのサーバー４で更新要求への対応がとられる。ステップ２０６においてＰａｘｏｓにより合意が形成されなければ、制御部６はステップ２０１に移行して次の要求パケットの待機状態に入る。
　これに対し、ステップ２０３において更新要求でなければ、要求パケットを受信したサーバー４で参照要求への対応がとられる。
　　〔更新要求への対応〕
　図７に示すように、更新処理の実行通知を受信したサーバー４の制御部６は（ステップ３０１）、要求パケット中のクライアントＩＤに基づいて、サーバーセッション１０をハッシュ等から取得する（そのクライアントＩＤに対応するサーバーセッション１０がなければ、それを新規に作成する。：ステップ３０２）。
　続いて、制御部６は、ステップ３０２で取得したサーバーセッション１０のセッション状態がオープンであるかどうかを確認し（ステップ３０３）、オープンでなければクライアント３の制御部５にエラー応答を送信し（ステップ３０４）、ステップ３０１に移行して次の更新処理の実行通知の待機状態に入る。
　ステップ３０３においてセッション状態がオープンであれば、制御部６は要求パケット中のトランザクション通番と、サーバーセッション１０に記憶された応答トランザクション通番（図面において「応答通番」と記載。）が、同一であるか否かを判断する（ステップ３０５）。一要求一応答の場合であれば、トランザクション通番と応答トランザクション通番が同一ならば、その応答トランザクション通番を含み保留応答として保存されている応答パケットは、そのトランザクション通番を含む要求パケットに対応して生成されたものと考えられる（つまり、サーバー４は今回と同様の要求に対して既に対応済みであり、今回の要求は重複要求と考えられる。）。したがって、ステップ３０５においてトランザクション通番と応答トランザクション通番が同一であれば、制御部６は保留応答フラグが「偽」で（ステップ３０６）、その時点においても自身のサーバー４がマスターであることを確認すると（ステップ３０７）、あらためて応答パケットを生成することなく、保留応答として保留されている応答パケットをクライアント３の制御部５に送信する（ステップ３０８）。ステップ３０６において保留応答フラグが「真」であるか、あるいは、ステップ３０７において自身のサーバー４がマスターでなければ、制御部６はステップ３０１に移行して次の更新処理の実行通知の待機状態に入る。
　ステップ３０５において、トランザクション通番と応答トランザクション通番が同一でなければ、制御部６は、要求パケット中のトランザクション通番と、サーバーセッション１０に記憶された要求開始トランザクション通番（図面において「要求開始通番」と記載。）が、同一であるか否かを判断する（ステップ３０９）。トランザクション通番と要求開始トランザクション通番が同一であれば、サーバー４は今回と同様の要求を処理している最中であると考えられるので、制御部６は重複処理を避けるべく今回の要求を無視する。
　ステップ３０９において、トランザクション通番と要求開始トランザクション通番が同一でなければ、制御部６は、要求開始トランザクション通番をそのトランザクション通番で置換する（ステップ３１０）。そして、要求パケット中のコマンドや要求データに基づいて更新処理を行い（ステップ３１１）、この更新処理が終了すると、要求終了トランザクション通番（図面において「要求終了通番」と記載。）を上記トランザクション通番で置換する（ステップ３１２）。
　ところで、更新処理の例は数多考えられるが、例えばクライアント３からサーバー４に送信されるサーバーセッションの開設要求や、開設したサーバーセッションの閉鎖要求は更新要求であり、サーバーセッションの開設処理や閉鎖処理は更新処理である。また、ファイルの書出処理等も更新処理である。
　すなわち、要求パケットに含まれるコマンドがサーバーセッションの開設コマンドであれば、ステップ３１１の更新処理として図９に示すようなサーバーセッションの開設処理が行われる（このとき、制御部６は、ステップ３０３を省略し、ステップ３０２からステップ３０５に移行する。）。
　制御部６は、まずステップ３０２で取得したサーバーセッション１０のセッション状態をオープンにするとともに（ステップ５０１）、各トランザクション通番等の値を初期化し（ステップ５０２）、これらの処理が完了すると、その旨をクライアント３の制御部５に通知する応答パケットを生成し（ステップ５０３）、この応答パケットの送信処理を行うべく図８のステップ４０１を呼び出す（ステップ５０４）。
　同図において、制御部６は、今回の更新処理について応答パケットを送信する必要があるか否かを判断し（ステップ４０１）、必要がなければステップ３１２に移行する（後述のようにロック等があると制御部６は応答パケットを生成しないことがあり、このような場合には一要求一応答ではあるものの、応答がロックの解除等があるまで遅延する。）。
　応答パケットを送信する必要があれば、制御部６は保留応答フラグを確認し（ステップ４０２）、フラグが「真」であればステップ５０３で生成した応答パケットを保留応答リストに加えることによって、保留応答リストを更新する（ステップ４０３）。一方、フラグが「偽」であればステップ５０３で生成した応答パケットで保留応答リストを置換することによって、保留応答リストを更新する（ステップ４０４）。
　次に、制御部６は、応答トランザクション通番を上記トランザクション通番で置換し（ステップ４０５）、自身のサーバー４がマスターであるかどうかを確認する（ステップ４０６）。制御部６は、マスターであれば保留応答リストの応答パケットを送信して（ステップ４０７）、マスターでなければ応答パケットを送信することなく、ステップ３１２に移行する。
　そして、このようなサーバーセッションの開設処理が全てのサーバー４で行われることにより、クライアント３と全てのサーバー４との間で同一のセッションが張られることになる。
　要求パケットに含まれるコマンドがサーバーセッションの閉鎖コマンドであれば、ステップ３１１の更新処理として図１０に示すようなサーバーセッションの閉鎖処理が行われる。
　制御部６は、ステップ５０１でオープンにしたサーバーセッション１０のオープン状態を解除（セッション状態をクローズ）し（ステップ５１１）、この処理が完了すると、その旨をクライアント３に通知するための応答パケットを生成し（ステップ５１２）、ステップ４０１を呼び出して図８の応答パケットの送信処理を行う（ステップ５１３）。
　また、要求パケットに含まれるコマンドがファイル書出コマンドである場合、要求パケットの要求データには、書出対象のファイルのファイルパス名、オフセット、書き出すデータ及び書き出すデータの長さが含まれており、ステップ３０９の更新処理として図１１に示すようなファイル書出処理が行われる。
　制御部６は、ファイルをオープンして（ステップ５２１）、オフセットからデータを書き出し（ステップ５２２）、ファイルをクローズする（ステップ５２３）。そして、書き出した長さを含む応答パケットを生成し（ステップ５２４）、ステップ４０１を呼び出して図８の応答パケットの送信処理を行う（ステップ５２５）。
　　〔参照要求への対応〕
　サーバー４がＰａｘｏｓにより合意を形成して処理を進めていく場合には、Ｐａｘｏｓ合意の際に過半数から漏れたサーバー４では直近の更新処理がなされていないこともあり、クライアント３がそのようなサーバー４を参照する事態を回避する必要がある。
　そこで、参照処理に際しては、図６に示すように、制御部６は要求終了トランザクション通番が要求パケット中の更新トランザクション通番以上であるか否かを判断し（ステップ２０９）、要求終了トランザクション通番が更新トランザクション通番以上であれば、そのサーバー４は更新が遅れておらず参照に供し得るとして、セッション状態のオープンを確認して参照処理に進む（ステップ２１０）。セッション状態がオープンでなければ、制御部６は、クライアント３の制御部５にエラー応答を送信する（ステップ２１１）。
　制御部６は、ステップ２１０においてセッション状態がオープンであると、要求開始トランザクション通番を要求パケット中のトランザクション通番で置換し（ステップ２１２）、要求パケット中のコマンドや要求データに基づいて参照処理を行い（ステップ２１３）、この参照処理が終了すると、要求終了トランザクション通番を上記トランザクション通番で置換する（ステップ２１４）。ステップ２１３の参照処理においても、制御部６は参照内容等を含む応答パケットをクライアント３の制御部５に送信するが、その方法は図８の応答パケットの送信処理と同様（ただし、ステップ３１２ではなくステップ２１４に移行する。）である。
　ステップ２０９において、要求終了トランザクション通番が更新トランザクション通番未満であれば、制御部６は処理を中断して待機状態に入る。そして、更新の遅滞が解消して要求終了トランザクション通番が要求パケット中の更新トランザクション通番以上になれば、ウェイクアップして中断していた処理を続行する。
　　〔応答パケットの受信〕
　クライアント３の制御部５は、サーバー４から応答パケットを受信するとステップ１０９（図５参照）の待機状態から脱し、リファレンスＩＤが不明であれば、クライアントセッション９に記憶されたリファレンスＩＤを応答パケット中のリファレンスＩＤで置換する（ステップ１１１，１１２）。
続いて、制御部５は、応答パケット中の応答トランザクション通番が期待する値と同一であるか否かを判断する（ステップ１１３）。この期待値は、トランザクション通番と同一であり、応答トランザクション通番が期待値と同一であれば、要求に対する適切な応答を受信したことになる。制御部５は、更新要求に対する応答を受信した場合には、更新トランザクション通番を上記トランザクション通番で置換し（ステップ１１４）、次の要求のためにステップ１０１に移行するか、又は、アプリケーションによる制御に戻る。
　ステップ１１２において応答トランザクション通番が期待値と同一でなければ、要求に対する不適切な応答を受信したことになるので、制御部５は受信した応答パケットを破棄し（ステップ１１５）、ステップ１０７に戻って適切な応答を待つ。
　なお、例えばデータベースのＳＱＬ複数文のように、一つの要求から複数の応答パケットが派生する場合には、サーバー４の制御部６は保留応答フラグにより応答パケットを蓄積し、複数（所定数）保留されたところでマスターの制御部６が一つの応答として一括送信すればよい。すなわち、制御部６は要求パケットのコマンドを解析して複数（所定数）の応答パケットが作成されることを知り得るので、その複数（所定数）の応答パケットが作成されるまでは保留応答フラグを「真」とし、生成された応答パケットを直ちに送信しないようにホールドして保留応答に逐次蓄積する。そして、複数（所定数）の応答パケットが全て生成されたときに保留応答フラグを「偽」とし、マスターの制御部６が蓄積された複数（所定数）の応答パケットをヘッダを付して一括送信する。
　　〔イベント管理〕
　前述のように、サーバー４は、サーバーセッション１０によりイベントを管理することができる。
　クライアント３がサーバー４にイベント管理の開始を要求するには、イベント取得開始要求を送信する。イベント取得開始要求を送信後、クライアント３がサーバー４に対してイベントの取得を要求するには、イベント取得要求を送信する。また、クライアント３がサーバー４にイベント管理の終了を要求するには、イベント取得終了要求を送信する。これらのイベント管理に関する要求は更新要求であるから、具体的にはステップ３１１において以下のような処理を行えばよい。
　つまり、図１２に示すように、サーバー４の制御部６はイベント取得開始要求を受けると、イベント資源とサーバーセッション１０との関連付けを行い、これを記憶装置８に記憶する（ステップ６０１）。この関連付けは、イベント資源とサーバーセッション１０との間にジョイントを設定することにより行い、ここでは、ジョイントには、当該ジョイントとイベント資源を結び付けるイベントリンク、当該ジョイントとサーバーセッション１０を結び付けるセッションリンク、及び、ジョイントを破棄したときの後処理関数が含まれる。なお、関連付けの対象となるイベント資源は、イベント取得開始要求の要求パケットで特定され、関連付けの対象となるサーバーセッション１０は、ステップ３０２（又はステップ２０２）で特定される。
　関連付けが完了すると、制御部６はその旨の応答パケットを生成し（ステップ６０２）、クライアント３の制御部５に送信するが（ステップ６０３）、その方法は図８の応答パケットの送信処理と同様である。
　イベント取得開始要求を受けた後、イベントが発生すると、クライアント３からイベント取得要求を受けているか否かによって、サーバー４の処理が異なる。
　詳しくは、図１３に示すように、サーバー４の制御部６は、イベント資源におけるイベントの発生を知ると（ステップ６１１）、イベント待ちフラグを確認し（既述のように、また、後に詳述するように、クライアント３からイベント取得要求を受けていればイベント待ちフラグが「真」であり、クライアント３からイベント取得要求を受けていなければイベント待ちフラグが「偽」である。：ステップ６１２）、イベント待ちフラグが「真」であれば、発生したイベントをクライアント３に送信すべく応答パケットを生成し（ステップ６１３）、クライアント３の制御部５に図８と同様の方法で送信して（ステップ６１４）、イベント待ちフラグを「偽」とする（ステップ６１５）。
　これに対し、イベント待ちフラグが「偽」であれば、制御部６は発生したイベントを保留イベントに追加して登録し（ステップ６１６）、イベント取得要求又は次のイベント発生等の待機状態に入る。
　図１４に示すように、クライアント３からイベント取得要求があると（ステップ６２１）、制御部６は保留イベントリストで保留イベントがあるか否かを確認し（ステップ６２２）、保留イベントがなければイベント待ちフラグを「真」として（ステップ６２３）、次のイベント取得要求時までに発生したイベントが保留イベントリストに保留されるようにする。
　ステップ６２２において保留イベントがあれば、制御部６は保留イベントリストに登録された全ての保留イベントを一括して刈り取ってこれらを含む応答パケットを生成し（ステップ６２４）、クライアント３の制御部５に図８と同様の方法で送信する（ステップ６２５）。
　図１５に示すように、サーバー４の制御部６はイベント取得終了要求を受けると、イベント資源とサーバーセッション１０との関連付けを解除して（ステップ６３１）、その旨の応答パケットを生成し（ステップ６３２）、クライアント３の制御部５に図８と同様の方法で送信する（ステップ６３３）。
　〔マスター選択配列〕
　サーバー４ａ，４ｂ，４ｃは必ずしも常時稼働しているわけではなく（Ｐａｘｏｓにより合意を形成するためには、３台のうち２台が稼働していればよい。）、マスター自体に障害が生じたり、マスターと他のサーバーとの間で通信障害が生じたりすることにより、マスター交替が生じ得る。サーバー４がマスター交替を認識したときには、そのサーバー４がクライアント３と接続中であれば、図４に示すようなマスター通知パケットを送信してクライアント３にマスターの変更を通知することができる。
　ところが、マスター交替時には、サーバー４ａ，４ｂ，４ｃの全てが新しいマスターを認識するのに一定の時間を要するので、セル２全体としては新旧のマスターが併存しているかのような状態になる。このとき、旧マスターが新マスターをマスターとして認識し、新マスターが旧マスターを未だマスターとして認識しているとすると、クライアント３が旧マスターに要求を出すと新マスターを通知するマスター通知パケットが返ってきて、新マスターに要求を出すと旧マスターを通知するマスター通知パケットが返ってくるという循環が発生する。この循環は、時間が経てばサーバー４ａ，４ｂ，４ｃの認識が一つのマスターに収束するので、いずれ自然に解消するが、この間、パケットが連続的に流れてしまってネットワーク負荷を引き起こす。
　そこで、本形態では、クライアントセッション９において、例えば図１６に示すような循環回避用のマスター選択配列を用意する。マスター選択配列では、クライアントセッション９のマスターＩＤが替わる度に、旧いマスターＩＤに対応するサーバー４の配列要素に「１」の印が付される（印が付されない配列要素は「０」である。）。よって、クライアント３が新たにマスター通知パケットを受信し、このマスター通知パケット中のマスターＩＤに対応するサーバー４の配列要素に印が付されていれば、このマスター通知パケットは旧マスターを通知してきたおそれがあるから、クライアント３の制御部５は上記循環が生じているとみなし、クライアントセッション９のマスターＩＤをマスター通知パケットで通知されたマスターＩＤに置換することなく次のマスター通知パケットを待つ。
　具体的には、マスター通知パケット中のレプリカＩＤとマスターＩＤが一致していれば、このマスター通知パケットの送信元のサーバー４は自身をマスターと認識していることになり循環は発生していないから、クライアント３の制御部５は、そのレプリカＩＤをクライアントセッション９のマスターＩＤとし、マスター選択配列の印を全部クリアする。
　また、マスター通知パケット中のマスターＩＤとクライアントセッション９のマスターＩＤが一致していれば、クライアント３とサーバー４でマスターの認識が一致しているから、制御部５はマスター選択配列に対して特に何もしない。
　一方、マスター通知パケット中のマスターＩＤとクライアントセッション９のマスターＩＤが一致していなければ、制御部５は、マスター通知パケット中のマスターＩＤに対応するサーバー４の配列要素に「１」の印が付されているか否かを判断する。そして、印が付されていれば、上記循環が生じていてマスター選択中（Ｊｅｏｐａｒｄ）であると判断し、クライアントセッション９のマスターＩＤを不明として次のマスター通知パケットを待つ。印が付されていなければ、それまでクライアントセッション９に記憶されていたマスターＩＤに対応するサーバー４の配列要素に印を付け、クライアントセッション９のマスターＩＤをマスター通知パケット中のマスターＩＤで置換する。
　なお、制御部５は、接続が切断された旧マスターをマスターと認識することがないように、接続情報によりサーバー４ａ，４ｂ，４ｃのいずれかについて接続の切断を検知したときは、そのＩＤとクライアントセッション９のマスターＩＤが一致していれば、クライアントセッション９のマスターＩＤに対応するサーバー４の配列要素に印を付ける。
　また、マスター選択中に一定時間経ってもマスター通知パケットが送られてこない場合には、制御部５はマスター選択配列の印を全てクリアした上でサーバー４ａ，４ｂ，４ｃに順次要求パケットを送信し、マスター通知パケットが送られてくるのを待つ。
　本形態に係る分散コンピューティングシステム１によれば、セル２を構成する各サーバー４に、クライアント３からの処理要求を受け、処理要求があった旨及びそのクライアント３を特定するクライアントＩＤを他のサーバー４に通知する処理要求通知手段と、クライアント３から処理要求を受け、又は、処理要求を受けた他のサーバー４から処理要求があった旨の通知を受け、クライアントＩＤに基づきクライアント３との間でセッションを開設して所定の処理を行う処理実行手段として機能する制御部６が設けられているので、各サーバー４がクライアント３との間にクライアントＩＤに基づき同一のセッションを開設して処理を行うことにより、セルのクライアントとの接続窓口が複数になって、接続窓口における障害発生に起因するサービス提供の停止を防止することができる。
　以上、本発明を実施するための形態について例示したが、本発明の実施形態は上述したものに限られず、本発明の趣旨を逸脱しない範囲で適宜変更等してもよい。
　例えばセルを構成するサーバーはＰａｘｏｓによらずに同期を取ってもよいし、Ｐａｘｏｓのリーダーをマスターとしなくてもよい。また、要求パケット、応答パケット、マスター通知パケットやクライアントＩＤの構成も、上述したものと異なってもかまわない。
１　　　　　　　　　　　分散コンピューティングシステム
２　　　　　　　　　　　セル
３　　　　　　　　　　　クライアント
４ａ，４ｂ，４ｃ　　　　サーバー（レプリカ）
５　　　　　　　　　　　制御部（処理要求手段、要求送信手段、マスターＩＤ変更手段）
６ａ，６ｂ，６ｃ　　　　制御部（処理要求通知手段、セッション開設手段、応答生成手段、応答送信手段、マスター変更通知手段）
７　　　　　　　　　　　記憶装置（第一の記憶手段）
８ａ，８ｂ，８ｃ　　　　記憶装置（第二の記憶手段）
９　　　　　　　　　　　クライアントセッション
１０ａ，１０ｂ，１０ｃ　サーバーセッション

Claims (31)

  1. 　互いに同期が取られる複数のレプリカを含むセルとクライアントとを備え、
    　前記クライアントに、前記セルと前記クライアントとの間のセッションを管理するためのセッション情報として、前記クライアントが各レプリカと接続するための接続情報及び前記クライアントを特定するためのクライアントＩＤを記憶する第一の記憶手段と、前記複数のレプリカのいずれかに対し、前記接続情報に基づき所定の処理の要求及び前記クライアントＩＤの通知を行う処理要求手段とが設けられ、
    　前記各レプリカに、前記処理要求手段からの処理要求を受け、処理要求があった旨及び前記クライアントＩＤを他のレプリカに通知する処理要求通知手段と、前記処理要求手段から処理要求を受け、又は、処理要求を受けたレプリカの処理要求通知手段から処理要求があった旨の通知を受け、前記クライアントＩＤに基づき前記クライアントとの間で前記セッションを開設して前記所定の処理を行う処理実行手段とが設けられていることを特徴とする分散コンピューティングシステム。
  2. 　前記所定の処理が、更新処理であることを特徴とする請求項１に記載の分散コンピューティングシステム。
  3. 　前記所定の処理の要求が、前記各レプリカに前記セッションを開設させるためのセッション開設要求であることを特徴とする請求項１に記載の分散コンピューティングシステム。
  4. 　前記第一の記憶手段が、前記複数のレプリカの一つがマスターとして選ばれる場合に、いずれのレプリカがマスターであるかを特定するためのマスターＩＤを記憶し、
    　前記処理要求手段が、前記第一の記憶手段に記憶されたマスターＩＤにより特定されるレプリカに対し、前記所定の処理の要求及び前記クライアントＩＤの通知を行うことを特徴とする請求項１乃至請求項３のいずれか１項に記載の分散コンピューティングシステム。
  5. 　前記第一の記憶手段が、前記複数のレプリカの一つが参照処理時の参照に供するリファレンスとして選ばれる場合に、いずれのレプリカがリファレンスであるかを特定するためのリファレンスＩＤを記憶し、
    　前記処理要求手段が、前記第一の記憶手段に記憶されたリファレンスＩＤにより特定されるレプリカに対し、参照処理の要求を行うことを特徴とする請求項４に記載の分散コンピューティングシステム。
  6. 　前記各レプリカに、前記所定の処理の要求に対する応答を生成する応答生成手段と、前記マスターＩＤを前記第一の記憶手段とは独立して記憶するとともに前記応答生成手段により生成された応答を記憶する第二の記憶手段と、前記第二の記憶手段に記憶された応答を前記クライアントに送信可能な応答送信手段とが設けられ、
    　前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターであると判断したときに、前記第二の記憶手段に記憶された応答を前記クライアントに送信することを特徴とする請求項４に記載の分散コンピューティングシステム。
  7. 　前記各レプリカに、前記所定の処理の要求に対する応答を生成する応答生成手段と、前記マスターＩＤを前記第一の記憶手段とは独立して記憶するとともに前記応答生成手段により生成された応答を記憶する第二の記憶手段と、前記第二の記憶手段に記憶された応答を前記クライアントに送信可能な応答送信手段とが設けられ、
    　前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターであると判断したときに、前記第二の記憶手段に記憶された応答を前記クライアントに送信することを特徴とする請求項５に記載の分散コンピューティングシステム。
  8. 　前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターでないと判断したときに、そのマスターＩＤに関する情報を前記第二の記憶手段に記憶された応答の代わりに前記クライアントに送信することを特徴とする請求項６に記載の分散コンピューティングシステム。
  9. 　前記応答送信手段が、前記第二の記憶手段に記憶されたマスターＩＤに基づいて自身のレプリカがマスターでないと判断したときに、そのマスターＩＤに関する情報を前記第二の記憶手段に記憶された応答の代わりに前記クライアントに送信することを特徴とする請求項７に記載の分散コンピューティングシステム。
  10. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項４に記載の分散コンピューティングシステム。
  11. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項５に記載の分散コンピューティングシステム。
  12. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項６に記載の分散コンピューティングシステム。
  13. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項７に記載の分散コンピューティングシステム。
  14. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項８に記載の分散コンピューティングシステム。
  15. 　前記各レプリカに、前記複数のレプリカ間でマスターの変更があったときに、新しいマスターのマスターＩＤに関する情報を前記クライアントに通知するマスター変更通知手段が設けられていることを特徴とする請求項９に記載の分散コンピューティングシステム。
  16. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項８に記載の分散コンピューティングシステム。
  17. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項９に記載の分散コンピューティングシステム。
  18. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１０に記載の分散コンピューティングシステム。
  19. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１１に記載の分散コンピューティングシステム。
  20. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１２に記載の分散コンピューティングシステム。
  21. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１３に記載の分散コンピューティングシステム。
  22. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１４に記載の分散コンピューティングシステム。
  23. 　前記第一の記憶手段が、前記マスターＩＤが変更されたときに変更前のマスターＩＤを記憶するマスターテーブルを記憶し、
    　前記クライアントに、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一であれば前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換せず、そのマスターＩＤが前記マスターテーブルに記憶されたマスターＩＤと同一でなければ前記第一の記憶手段に記憶されたマスターＩＤをそのマスターＩＤに置換するマスターＩＤ変更手段が設けられていることを特徴とする請求項１５に記載の分散コンピューティングシステム。
  24. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項１６に記載の分散コンピューティングシステム。
  25. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項１７に記載の分散コンピューティングシステム。
  26. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項１８に記載の分散コンピューティングシステム。
  27. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項１９に記載の分散コンピューティングシステム。
  28. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項２０に記載の分散コンピューティングシステム。
  29. 　前記マスターＩＤ変更手段が、前記応答送信手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項２１に記載の分散コンピューティングシステム。
  30. 　前記マスターＩＤ変更手段が、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項２２に記載の分散コンピューティングシステム。
  31. 　前記マスターＩＤ変更手段が、前記応答送信手段又は前記マスター変更通知手段からマスターＩＤに関する情報を受信したときに、そのマスターＩＤが送信元のレプリカのＩＤと同一である場合、又は、そのマスターＩＤが前記第一の記憶手段に記憶されたマスターＩＤと同一である場合には、前記第一の記憶手段に記憶されたマスターＩＤの置換を行わないことを特徴とする請求項２３に記載の分散コンピューティングシステム。
PCT/JP2010/066906 2010-09-29 2010-09-29 分散コンピューティングシステム WO2012042607A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2010/066906 WO2012042607A1 (ja) 2010-09-29 2010-09-29 分散コンピューティングシステム
JP2010538664A JPWO2012042607A1 (ja) 2010-09-29 2010-09-29 分散コンピューティングシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/066906 WO2012042607A1 (ja) 2010-09-29 2010-09-29 分散コンピューティングシステム

Publications (1)

Publication Number Publication Date
WO2012042607A1 true WO2012042607A1 (ja) 2012-04-05

Family

ID=45892111

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/066906 WO2012042607A1 (ja) 2010-09-29 2010-09-29 分散コンピューティングシステム

Country Status (2)

Country Link
JP (1) JPWO2012042607A1 (ja)
WO (1) WO2012042607A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015057696A (ja) * 2013-09-16 2015-03-26 アクシス アーベー 分散制御システムにおけるアプリケーションデータの管理

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008004569A1 (fr) * 2006-07-06 2008-01-10 Nec Corporation Système à configuration en grappe, grappe pour serveur, élément de grappe, procédé permettant de rendre un élément de grappe redondant, et procédé de distribution de la charge
JP2009217765A (ja) * 2008-03-13 2009-09-24 Hitachi Ltd 複数宛先への同期送信方法、その実施システム及び処理プログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3847364B2 (ja) * 1996-02-14 2006-11-22 富士通株式会社 ロードシェアシステム
JPH10105424A (ja) * 1996-09-26 1998-04-24 Okinawa Nippon Denki Software Kk 二重化サーバのｉｐアドレス割り当て方法
JP4703682B2 (ja) * 2008-04-21 2011-06-15 株式会社東芝 クラスタシステム及びプログラム
JP5446157B2 (ja) * 2008-07-28 2014-03-19 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム
JP2010086145A (ja) * 2008-09-30 2010-04-15 Hitachi East Japan Solutions Ltd 分散処理システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008004569A1 (fr) * 2006-07-06 2008-01-10 Nec Corporation Système à configuration en grappe, grappe pour serveur, élément de grappe, procédé permettant de rendre un élément de grappe redondant, et procédé de distribution de la charge
JP2009217765A (ja) * 2008-03-13 2009-09-24 Hitachi Ltd 複数宛先への同期送信方法、その実施システム及び処理プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015057696A (ja) * 2013-09-16 2015-03-26 アクシス アーベー 分散制御システムにおけるアプリケーションデータの管理

Also Published As

Publication number Publication date
JPWO2012042607A1 (ja) 2014-02-03

Similar Documents

Publication Publication Date Title
CN110224871B (zh) 一种Redis集群的高可用方法及装置
TW497071B (en) Method and apparatus for managing clustered computer systems
US9021459B1 (en) High availability in-service software upgrade using virtual machine instances in dual control units of a network device
US9934242B2 (en) Replication of data between mirrored data sites
US20190205315A1 (en) System and method for synchronizing data between communication devices in a networked environment without a central server
US20160077857A1 (en) Techniques for Remapping Sessions for a Multi-Threaded Application
CN108234307A (zh) 网络方法、网络装置和非暂时性计算机可读存储介质
WO2016070375A1 (zh) 一种分布式存储复制系统和方法
EP4083786A1 (en) Cloud operating system management method and apparatus, server, management system, and medium
CN108234302A (zh) 保持网络装置用的分布式操作系统中的一致性
WO2019061720A1 (zh) 一种数据同步的方法和系统
CN108234306A (zh) 网络装置、网络方法和计算机可读存储介质
CN105262820A (zh) 一种基于Linux操作系统的集群多机互备的方法
JP2005316993A (ja) ネットワーク上においてコンピュータ間でオブジェクトを共有するためのシステムおよび方法
US20140059315A1 (en) Computer system, data management method and data management program
WO2012145963A1 (zh) 数据管理系统及方法
US20180077007A1 (en) Redundant storage solution
WO2016078362A1 (zh) 一种双主控隔离的逐板升级的方法及装置
CN102012944A (zh) 一种提供复制特性的分布式nosql数据库
CN114553693B (zh) 网关升级方法及装置
JP7161008B2 (ja) アプリケーション冗長化管理システムおよびアプリケーション冗長化管理方法
US8627412B2 (en) Transparent database connection reconnect
WO2015196692A1 (zh) 一种云计算系统以及云计算系统的处理方法和装置
JP6740543B2 (ja) 通信装置、システム、ロールバック方法及びプログラム
JP2010044553A (ja) データ処理方法、クラスタシステム、及びデータ処理プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2010538664

Country of ref document: JP

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

Ref document number: 10857822

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10857822

Country of ref document: EP

Kind code of ref document: A1