WO2016067426A1 - 分散コンピューティングシステム及び分散処理方法 - Google Patents

分散コンピューティングシステム及び分散処理方法 Download PDF

Info

Publication number
WO2016067426A1
WO2016067426A1 PCT/JP2014/078976 JP2014078976W WO2016067426A1 WO 2016067426 A1 WO2016067426 A1 WO 2016067426A1 JP 2014078976 W JP2014078976 W JP 2014078976W WO 2016067426 A1 WO2016067426 A1 WO 2016067426A1
Authority
WO
WIPO (PCT)
Prior art keywords
proposal
preparation
computer
memory area
request
Prior art date
Application number
PCT/JP2014/078976
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 US15/307,308 priority Critical patent/US10489340B2/en
Priority to PCT/JP2014/078976 priority patent/WO2016067426A1/ja
Publication of WO2016067426A1 publication Critical patent/WO2016067426A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • 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

Definitions

  • the present invention relates to a technique of a distributed computing system and a distributed processing method.
  • Non-Patent Document 1 discloses a protocol called PAXOS using a distributed agreement algorithm.
  • PAXOS is a protocol that performs voting between computers, and if an agreement over a quorum (in most cases, a majority) is obtained, the result is confirmed for all computers, and no agreement can be obtained from all computers. However, the result can be confirmed if an agreement over the quorum is obtained.
  • Patent Document 1 also describes distributed computing that takes into account exchangeable commands in the PAXOS algorithm, thereby introducing less message delay between receiving a client request and sending a response to the client. The system is described.
  • Non-Patent Document 2 discloses a technique of RDMA (Remote Direct Memory Access) that performs DMA transfer from a memory of a certain computer to a memory of a different remote computer.
  • RDMA Remote Direct Memory Access
  • an object of the present invention is to reduce the time required for consensus formation in a distributed computing system and a distributed processing method related to a distributed agreement algorithm.
  • a distributed computing system includes a plurality of computers connected to each other via a network, and the computers operate in cooperation with each other.
  • the first computer transmits a preparation request including a proposal ID, which is a proposal preparation request, to the second computer.
  • the first computer receives a preparation response including a memory area ID from the second computer as a response to the preparation request
  • the first computer is a request for writing the proposal and includes the proposal and the memory area ID in the preparation response.
  • a write request is transmitted to the second computer.
  • the first computer receives a write success response indicating a write success, which is a response to the write request, from the second computer, it determines that the second computer has agreed to the proposal.
  • the second computer and the new ID in the preparation request A set including the area ID is registered in the management information, and a preparation response including the proposal ID in the preparation request and the new memory area ID is returned.
  • the second computer proposes in the write request received in the memory area specified from the memory area ID. And a write success response is returned to the first computer.
  • FIG. 1 shows a configuration of a distributed computing system according to an embodiment.
  • An example of the function concerning in-memory KVS is shown.
  • the structural example of a proposal number management table is shown.
  • the structural example of a writing destination management table is shown.
  • It is a sequence chart which shows the outline
  • It is a flowchart which shows the detail of the example of a process regarding the preparation request in the preparation reception part of a slave.
  • a computer program (hereinafter referred to as “program”) is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process is appropriately performed as a storage resource (for example, a memory) and a communication interface. Since the processing is performed using at least one of the devices, the subject of the processing may be a processor and an apparatus having the processor. Part or all of the processing performed by the processor may be performed by a hardware circuit.
  • the program may be installed from a program source.
  • the program source may be a program distribution node or a storage medium (for example, a portable storage medium).
  • node 100A in the case of distinguishing and explaining the same type of elements, reference numerals are used like “node 100A” and “node 100B”, and in the case of explaining without distinguishing the same kind of elements, “ In some cases, only a common number among the reference symbols is used, such as “node 100”.
  • FIG. 1 shows a configuration of a distributed computing system according to the embodiment.
  • the distributed computing system forms a cluster with a plurality of nodes 100A, 100B, and 100C.
  • the client 170 and each of the nodes 100A, 100B, and 100C are connected by a network 160.
  • Clients and nodes are types of computers. Examples of the network 160 include a SAN (Storage Area Network), a LAN (Local Area Network), and a WAN (Wide Area Network).
  • SAN Storage Area Network
  • LAN Local Area Network
  • WAN Wide Area Network
  • the node 100 includes a CPU 110, a storage device 120, a memory 130, a network I / F 180, and an RDMA I / F 150.
  • the network I / F 180 is an I / F for connecting the node 100 to the network 160.
  • Examples of the network I / F 180 include an Ethernet (registered trademark) adapter and a Fiber Channel adapter.
  • the RDMA I / F 150 is an I / F for realizing RDMA transfer.
  • RDMA transfer is to perform DMA transfer between its own node and a remote node. For example, when data is RDMA transferred from the RDMA I / F 150A of the node 100A to the RDMA I / F 150B of the remote node 100B, the RDMA I / F 150B directly stores the transferred data in the memory 130B. At this time, the CPU 110B of the remote node 100B does not need to perform processing. This reduces the processing load on the CPU.
  • the RDMA I / Fs 150 may be connected to each other through the network 160, or may be connected to a network other than the network 160, a cable, or the like.
  • the storage device 120 is a device for storing data. Examples of the storage device 120 include an HDD (Hard Disk Drive), an SSD (Solid State Drive), and a flash memory drive.
  • HDD Hard Disk Drive
  • SSD Solid State Drive
  • flash memory drive any type of non-volatile memory drive.
  • the memory 130 is a device for storing programs and data.
  • the memory 130 stores an OS 143 and an in-memory KVS (Key Value Store) 144 which are a kind of programs.
  • Examples of the memory 130 include a DRAM (Dynamic Random Access Memory), an MRAM (Magnetic Random Access Memory), and a FeRAM (Ferroelectric Random Access Memory).
  • CPU 110 processes programs and data stored in memory 130.
  • the CPU 110 processes data transmission / reception through the network I / F 180.
  • Various functions of the distributed computing system are realized by the processing of the CPU 110 of each node 100.
  • the in-memory KVS 144 builds a key-value store on the memory 130, and manages and controls the key-value store.
  • the in-memory KVS 144 may be an in-memory distributed KVS that distributes and manages data in a plurality of nodes 100.
  • FIG. 2 shows an example of functions related to the in-memory KVS 144.
  • the distributed computing system determines whether or not the proposal transmitted from the client 170 is agreed based on the PAXOS protocol.
  • a master node may be referred to as a “master node” and a slave node may be referred to as a “slave node”.
  • the master node 100 and the slave node 100 are not fixed and may be different from time to time.
  • the node 100 includes a preparation transmission unit 1447, a preparation reception unit 1444, an agreement determination unit 1443, a successful transmission unit 1448, a success reception unit 1442, and an RDMA processing unit 1446.
  • the in-memory KVS 144 manages a data storage unit 1441, a proposal number management table 1445, and a write destination management table 1449. These tables 1445 and 1449 are stored in the memory 130, for example.
  • proposal data transmitted from the client 170 is stored.
  • the proposal data stored in the data storage unit 1441 is a consensus formed in the entire distributed computing system. Proposal data for which no agreement has been formed in the entire distributed computing system is not stored in the data storage unit 1441.
  • the preparation transmission unit 1447 is executed by the master node 100 (that is, executed when the node 100 having the in-memory KVS 144 is the master node 100), and prepares for the slave node 100 through the network I / F 180. Send.
  • the preparation request includes at least a sequence number and a proposal number.
  • the sequence number is information for identifying a series of consensus forming processes. If the sequence numbers are different, the process for consensus building is different. That is, when an agreement is formed throughout the distributed computing system and the proposed data is reflected in the data storage unit 1441 of each node 100, the processing of the sequence number is completed.
  • the proposal number is information for identifying proposal data and identifying which proposal data is new. A larger proposal number indicates newer proposal data. Details of the sequence number and the proposal number will be described later.
  • a number is adopted as an ID for each of the sequence and the proposal data.
  • identification information for example, alphabets
  • the sequence ID or the proposal ID it may be adopted.
  • the preparation reception unit 1444 is executed by the slave node 100 (that is, executed when the node 100 having the in-memory KVS 144 is the slave node 100), and receives a preparation request from the master node 100 through the network I / F 180. Then, the preparation reception unit 1444 performs processing related to the preparation request. Then, the preparation reception unit 1444 returns a preparation response including the result of the processing related to the preparation request to the master node 100 through the network I / F 180.
  • the preparation success response includes an ID (hereinafter referred to as “R_KEY”) of the memory area associated with the proposal number included in the preparation request. Details of R_KEY will be described later.
  • the preparation failure response when the process related to the preparation request fails includes information indicating the failure.
  • the preparation reception unit 1444 secures a new memory area. Then, the preparation reception unit 1444 registers a record that associates the proposal number, the new memory area, and R_KEY indicating the new memory area in the proposal number management table 1445. Then, the preparation receiving unit 1444 returns a preparation success response including R_KEY indicating the new memory area to the master node 100.
  • the preparation transmission unit 1447 of the master node 100 writes a record that associates the node ID indicating the node (slave) 100 that is the transmission source of the preparation response with R_KEY included in the preparation response. It may be registered in the management table 1449.
  • the preparation reception unit 1444 has a record having a sequence number included in the preparation request in the proposal number management table 1445, and the proposal number included in the preparation request indicates the sequence number in the proposal number management table 1445.
  • the preparation failure response including the proposal number related to the record having the sequence number is returned to the master node 100.
  • the preparation reception unit 1444 has a record having a sequence number included in the preparation request in the proposal number management table 1445, and the proposal number included in the preparation request indicates the sequence number in the proposal number management table 1445.
  • the preparation reception unit 1444 determines whether or not the proposal has been written in the memory area associated with the proposal number.
  • the proposal data is written into the memory area by RDMA transfer from the master node 100.
  • the preparation receiving unit 1444 If the proposed data has been written in the memory area, the preparation receiving unit 1444 returns a preparation failure response including the proposed data in the memory area to the master node 100.
  • the preparation receiving unit 1444 When the proposal data is not yet written in the memory area, the preparation receiving unit 1444 creates a new memory area in the same manner as when the record having the proposal number included in the preparation request does not exist in the proposal number management table 1445. And a new record is registered in the proposal number management table 1445, and a preparation success response is returned to the master node 100.
  • the RDMA processing unit 1446 is executed in the master node 100 and transmits the proposal data to the plurality of slave nodes 100 using RDMA transfer. That is, the RDMA processing unit 1446 acquires R_KEY corresponding to the RDMA transfer destination slave node 100 from the write destination management table 1449. Then, the RDMA processing unit 1446 performs RDMA transfer (RDMA SEND) of the proposed data to the memory area indicated by the R_KEY of the slave node 100 through the RDMA I / F 150.
  • the write success response or write failure response for the RDMA transfer is stored in a completion queue managed by the RDMA I / F 150 of the master node 100.
  • the agreement determination unit 1443 is executed by the master node 100 and determines whether or not an agreement has been formed for the proposed data based on the vote from each slave node 100. For example, the agreement determination unit 1443 determines that an agreement has been formed on the proposed data when a vote of “agreement” is obtained from the slave nodes 100 that are equal to or larger than a quorum (for example, a majority) of the plurality of slave nodes 100.
  • the agreement determination unit 1443 determines whether or not an agreement is formed based on the write response of the RDMA transfer from the slave node 100 to the master node 100. This determination is performed as follows, for example.
  • the RDMA I / F 150 of the slave node 100 When the RDMA I / F 150 of the slave node 100 receives the RDMA transfer related to the proposed data from the RDMA I / F 150 of the master node 100, the RDMA I / F 150 performs a process of writing the proposed data to the memory area indicated by the R_KEY.
  • the RDMA I / F 150 of the slave node 100 returns a write success response when the proposed data has been successfully written to the RDMA I / F 150 of the master node 100. If the write fails, the write fails. Send back a response. Specifically, the RDMA I / F 150 of the slave node 100 writes a write success response or a write failure response in the completion queue managed by the RDMA I / F 150 of the master node 100.
  • the agreement determination unit 1443 determines that the slave node 100 that has returned the write success response “agrees” with the proposal data, and the slave node 100 that has returned the write failure response “does not agree” with the proposal data. Is determined. In other words, when the write success response related to the RDMA transfer is returned from the slave node 100 having a quorum or more, the agreement determination unit 1443 determines that an agreement has been formed for the proposed data transferred by the RDMA.
  • the agreement determination unit 1443 determines that the RDMA transfer for the slave node 100 has failed. In this case, the master node 100 may perform RDMA transfer again with respect to the slave node 100.
  • the successful transmission unit 1448 is executed by the master node 100, and when the agreement determination unit 1443 forms an agreement on the proposal data, the proposal data is reflected in the data storage unit 1441. Then, the success transmission unit 1448 transmits a success notification to each slave node 100 through the network I / F 180.
  • the success notification includes a sequence number corresponding to the agreed proposal data.
  • the success receiving unit 1442 is executed by the slave node 100, and receives the success notification from the master node 100 through the network I / F 180, and performs the following processing. That is, the success reception unit 1442 extracts R_KEY corresponding to the sequence number included in the agreement notification from the proposal number management table 1445. Then, the success reception unit reads the proposal data from the memory area indicated by the R_KEY and reflects the proposal data in the data storage unit 1441. Thereby, the proposal data agreed in the agreement determination unit 1443 is reflected in all the nodes 100.
  • FIG. 3 shows a configuration example of the proposal number management table 1445.
  • the proposal number management table 1445 is a table for managing the correspondence between the proposal number and the memory area related to RDMA transfer, and is held by the slave node 100.
  • the proposal number management table 1445 has a plurality of records, and each record has a sequence number 14451, a proposal number 14452, an R_KEY 14453, and a memory size 14454 as field values.
  • Sequence number 14451 is information for identifying a series of consensus forming processes. If the sequence numbers are different, the object of consensus building is different.
  • the proposal number 14452 is information for identifying proposal data and identifying which proposal data is new. A larger proposal number 14452 indicates newer proposal data. Even if the proposal number 14452 is the same, if the sequence number 14451 is different, the proposal data is different.
  • R_KEY14453 is an ID of a memory area for RDMA.
  • R_KEY 14453 may be, for example, a memory address itself or information including a memory address.
  • the memory size 14454 is information indicating the size of the memory area indicated by the R_KEY 14453.
  • the memory area indicated by R_KEY14453 “0x4213a2” is associated with the proposal number 14452 “1” in the sequence number 14451 “1”, and the size of the memory area 14454 indicates “100”.
  • the proposal number management table 1445 is updated based on the preparation request received from the master node 100 by the preparation receiving unit 1444 of the slave node 100. As described above, the preparation reception unit 1444 secures a new memory area and registers a record having R_KEY 14453 indicating the new memory area in the proposal number management table 1445 in any of the following cases. . (1) A record having a proposal number included in the preparation request does not exist in the proposal number management table 1445. (2) The preparation receiving unit 1444 has a record having a sequence number included in the preparation request in the proposal number management table 1445, and the proposal number included in the preparation request is the sequence number in the proposal number management table 1445. If the proposal number is larger than the proposal number 14452 related to the record having, and the proposal data has not yet been written in the memory area.
  • R_KEY related to the proposal data transferred from the master node 100 by RDMA does not exist in the proposal number management table 1445 means that the proposal data does not correspond to any of the above (1) and (2). It can be said that there is.
  • the RDMA I / F 150 of the slave node 100 returns a write failure response to the master node 100. Therefore, the RDMA processing unit 1446 of the master node 100 can determine that the slave node 100 “has not agreed” with a write failure response to the RDMA transfer.
  • the fact that R_KEY related to the proposal data transferred by the RDMA from the master node 100 exists in the proposal number management table 1445 indicates that the proposal data corresponds to either (1) or (2) above. It can be said that.
  • the RDMA I / F 150 of the slave node 100 returns a write success response to the master node 100. Therefore, the RDMA processing unit 1446 of the master node 100 can determine that the slave node 100 “agrees” with a write success response to the RDMA transfer.
  • the master node 100 determines whether or not the slave node 100 can agree on the proposal number based on the success or failure of the RDMA transfer. be able to. Thereby, the time required for consensus building in the entire distributed computing system can be reduced.
  • FIG. 4 shows a configuration example of the write destination management table 1449.
  • the write destination management table 1449 is a table for managing the correspondence between the write destination node 100 related to the RDMA transfer and the memory area of the node 100, and is held by the master node 100.
  • the write destination management table 1449 includes a plurality of records, and each record has a node ID 14491 and R_KEY 14492 as field values.
  • the node ID 14491 is information for identifying the node.
  • R_KEY14492 indicates a memory area of a write destination related to RDMA transfer in the node indicated by the node ID.
  • the record 14490 indicates that the node 100 having the node ID 14491 “B” is associated with the memory area indicated by the R_KEY14492 “0x4213a2”.
  • the RDMA processing unit 1446 refers to this record 14490 and executes RDMA transfer related to the proposed data for the memory area indicated by R_KEY “0x4213a2” in the node with the node ID “B”.
  • FIG. 5 is a sequence chart showing an outline of consensus building processing in the distributed computing system.
  • the node 100A is described as a master node and the node 100B is a slave node, the master node 100A performs the same processing on other slave nodes 100 (for example, 100C).
  • the preparation transmission unit 1447 of the master node 100A transmits a preparation request to the slave node 100B through the network I / F at a predetermined opportunity (S101).
  • the OS 143B of the slave node 100B returns an ACK to the master node 100A (S201).
  • the preparation transmission unit 1447 of the master node 100A that has received the ACK determines that the preparation request has been successfully transmitted (S102).
  • the preparation reception unit 1444 of the slave node 100B executes processing related to the preparation request, and returns a preparation response to the master node 100A through the network I / F 180B (S2022). Details of this processing will be described later (see FIG. 6).
  • the preparation transmission unit 1447 of the master node 100 performs processing related to the preparation response returned from the slave node 100B (S103). Details of this processing will be described later.
  • the OS 143A of the master node 100A receives the preparation response, the OS 143A returns an ACK to the slave node 100B.
  • the slave node 100B that has received the ACK determines that the preparation response has been successfully returned (S204).
  • the client 170 transmits the proposal data to the master node 100A (S11). Upon receiving the proposal data, the master node 100 returns an ACK to the client 170 (S104). The client 170 that has received the ACK determines that the transmission of the proposal data has been successful (S12).
  • the RDMA processing unit 1446 of the master node 100A that has received the proposal data transfers the proposal data to each of the plurality of slave nodes 100B, 100C,... (S1041). Details of this processing will be described later (see FIG. 7).
  • the RDMA I / F 150B of the slave node 100B writes the proposal data transferred by the RDMA from the master node 100A to the memory area indicated by R_KEY. Then, the RDMA I / F 150B sends a write success response when the write is successful, a write failure response when the write fails, a completion queue (Completion Queue) of the memory 130B of the slave node 100B, and a master.
  • a completion queue (Completion Queue) of the memory 130B of the slave node 100B
  • a master Store in the completion queue of the memory 130A of the node 100A (S2051). That is, in the completion queue of the memory 130A of the master node 100A, a write response related to the RDMA transfer of the proposed data is stored from each of the plurality of slave nodes 100B, 100C,.
  • the agreement determination unit 1443 of the master node 100A determines whether or not an agreement has been formed in the entire distributed computing system based on the number of write success responses stored in the completion queue of the memory 130A (S1051). Details of this processing will be described later (see FIG. 9). Hereinafter, a case where the agreement determination unit 1443 determines that an agreement has been formed will be described.
  • the successful transmission unit 1448 of the master node 100A stores the proposal data received from the client 170 in S104 in the data storage unit 1441 (S106). Then, the success transmitter 1448 of the master node 100A transmits a success notification through the network I / F 180A to each of all the slave nodes 100B, 100C,... That has returned the write success response (S107).
  • the success reception unit 1442 of the slave node 100B receives the success notification from the master node 100A, the proposal data written in the memory area indicated by R_KEY by RDMA transfer is reflected in the data storage unit 1441B (S2091). Details of this processing will be described later (see FIG. 10).
  • the master node 100A returns the processing result for the proposal data to the client 170 through the network I / F 180A (S108).
  • the processing result may include information indicating whether the proposed data has been accepted by the distributed computing system (that is, whether an agreement has been formed).
  • the client 170 Upon receiving the processing result for the proposal data from the master node 100A, the client 170 returns an ACK to the master node 100A (S13). The master node 100A that has received the ACK determines that the transmission of the processing result for the proposal data has succeeded (S109).
  • FIG. 6 is a flowchart showing details of a processing example related to a preparation request in the preparation reception unit 1444 of the slave node 100B. This process corresponds to the process of S2022 of FIG.
  • the preparation receiving unit 1444 When receiving the preparation request from the master node 100, the preparation receiving unit 1444 performs the following processing.
  • the preparation reception unit 1444 determines whether or not the proposal number management table 1445 has a record having a sequence number 14451 that matches the sequence number included in the preparation request (referred to as “target record” in the description of FIG. 6) ( S2101). If the determination result is affirmative (S2101: YES), the process proceeds to S2102. If the determination result is negative (S2101: NO), the process proceeds to S2111.
  • the preparation reception unit 1444 secures and registers a new memory area for RDMA (Register), and acquires R_KEY indicating the new memory area (S2111).
  • the process of securing and registering a new memory area for RDMA, and the process of associating R_KEY with this new memory area may be performed by the RDMA I / F 150B.
  • the size of the new memory area may be set in advance by an administrator or the like.
  • the preparation reception unit 1444 adds a new record to the proposal number management table 1445.
  • This new record includes the sequence number and proposal number included in the preparation request, the R_KEY acquired in S2111, and the memory size of the new memory area indicated by the R_KEY (S2112).
  • the preparation reception unit 1444 returns a preparation success response including R_KEY acquired in S2111 to the master node 100A (S2113), and ends this process.
  • the preparation reception unit 1444 determines whether or not the proposal number (proposition number X) included in the preparation request is equal to or less than the proposal number 14452 (proposition number Y) included in the target record (S2102).
  • the preparation reception unit 1444 executes the following process. That is, the preparation reception unit 1444 returns a preparation failure response including the proposal number 14452 included in the target record to the preparation transmission unit 1447 of the master node 100A (S2105), and ends this processing. This is because the proposal number X is less than or equal to the proposal number Y because the proposal number X is older or the same as the previously received proposal number Y.
  • the preparation reception unit 1444 executes the following process. That is, the preparation reception unit 1444 deregisters the memory area indicated by the R_KEY 14453 included in the target record (S2103). The deregistration of this memory area may be performed by the RDMA I / F 150B.
  • the preparation reception unit 1444 determines whether or not the writing of the proposed data by the RDMA transfer has been completed in the memory area indicated by the R_KEY 14453 (S2104). For example, the preparation reception unit 1444 may make this determination with reference to its own completion queue.
  • the preparation reception unit 1444 When the proposal data has been written to the memory area indicated by the R_KEY 14453 (S2104: YES), the preparation reception unit 1444 includes the proposal data in the memory area indicated by the R_KEY 14453 for the master node 100A. A preparation failure response is returned (S2106). Then, the preparation reception unit 1444 ends this process.
  • the preparation reception unit 1444 proceeds to the process of S2111. That is, in this case, the preparation reception unit 1444 returns a preparation success response to the master node 100A. This is because the proposal data is no longer written in the memory area, and the slave node 110B should agree to a newer proposal number.
  • FIG. 7 is a flowchart illustrating details of a processing example related to a preparation response in the preparation transmission unit 1447 of the master node 100A. This process corresponds to the process of S103 in FIG.
  • the preparation transmission unit 1447 of the master node 100A receives the preparation response from the slave node 100B (S1201), it performs the following processing.
  • the preparation transmission unit 1447 determines whether or not the preparation response is a preparation failure response including a proposal number (S1202).
  • the preparation transmission unit 1447 uses a proposal number larger than the proposal number included in the preparation failure response, as shown in FIG. The processing after S101 is performed again (S1211). Thereby, the preparation transmitting unit 1447 of the master node 100A can know the proposal number to be included in the next preparation request.
  • the preparation transmission unit 1447 performs the following processing. That is, the preparation transmission unit 1447 determines whether the preparation response is a preparation failure response including proposal data (S1203).
  • the preparation transmission unit 1447 performs again the processing from S101 shown in FIG. 5 using the proposal data included in the preparation failure response. (S1212). Accordingly, the master node 100A can reflect the proposal data written in the slave node 100B to other slave nodes.
  • the preparation transmission unit 1447 executes the following processing. That is, the preparation transmission unit 1447 updates R_KEY 14492 corresponding to the node ID 14491 of the slave node 100B that has transmitted the preparation response in the write destination management table 1449A to R_KEY included in the preparation success response (S1204). And the preparation transmission part 1447 complete
  • FIG. 8 is a flowchart showing details of a processing example in which the RDMA processing unit 1446 of the master node 100A performs RDMA transfer of the proposed data to each slave node 100. This process corresponds to the process of S1041 in FIG. Hereinafter, it is assumed that the slave node of the RDMA transfer destination is the slave node 100B.
  • the RDMA processing unit 1446 of the master node 100A receives the proposal data from the client 170, the RDMA processing unit 1446 performs the following processing.
  • the RDMA processing unit 1446 acquires R_KEY 14492 from the record including the node ID 14491 “B” in the write destination management table 1449 (S1301).
  • the RDMA processing unit 1446 transfers the proposal data received from the client 170 to the memory area indicated by the acquired R_KEY 14492 by RDMA (S1302). For example, the RDMA processing unit 1446 instructs “RDMA Write with Immediate” to the RDMA I / F 150A.
  • FIG. 9 is a flowchart showing details of a processing example in which the agreement determination unit 1443 determines an agreement of one slave node 100B. This process corresponds to the process for one slave node 100B in S1051 of FIG.
  • the agreement determination unit 1443 waits for a reply to the write response related to the RDMA transfer from the slave node 100B (S1401). For example, the agreement determination unit 1443 polls the completion queue managed by the RDMA I / F 150A of the master node 100A at regular intervals, and determines whether a write response is stored. For example, when the write response is stored in the completion queue, the RDMA I / F 150A of the master node 100A issues an interrupt notification indicating that to the agreement determination unit 1443.
  • the agreement determination unit 1443 may execute the following process when a reply of a write response is not received and a timeout occurs (S1402: NO). That is, the agreement determination unit 1443 may determine that the RDMA transfer of the proposed data to the slave node 100 has failed (S1403), and return to S1041 illustrated in FIG. 5 to perform the RDMA transfer again.
  • the predetermined time until timeout may be set in advance by the administrator.
  • the agreement determination unit 1443 executes the following process when a reply to the write response is received within a predetermined time (S1402: YES). That is, the agreement determination unit 1443 determines whether the write response is a write success response or a write failure response (S1404). For example, the agreement determination unit 1443 may check the execution result (Completion Return Status) of the RDMA transfer.
  • the agreement determination unit 1443 determines that the slave node 100B has not agreed to the proposal data (S1405), and ends this processing.
  • the execution result of the RDMA transfer may be an access error to the memory area of the slave node 100B (Remote Access Error).
  • the agreement determination unit 1443 determines that the slave node 100 has agreed to the proposed data (S1406), and ends this processing.
  • the execution result of the RDMA transfer may be success (Success).
  • FIG. 10 is a flowchart showing details of a processing example in which the successful reception unit 1442 of the slave node 100B reflects the proposal data. This process corresponds to the process of S2091 in FIG.
  • the success receiving unit 1442 of the slave node 100B When the success reception unit 1442 of the slave node 100B receives the success notification from the master node 100A, it executes the following processing.
  • the success receiving unit 1442 acquires from the proposal number management table 1445 a record having a sequence number 14451 that matches the sequence number included in the received success notification (referred to as “target record” in the description of FIG. 10) (S2221). ).
  • the success receiving unit 1442 acquires the proposal data from the memory area indicated by the R_KEY 14492 of the target record. Then, the success reception unit 1442 reflects the acquired proposal data in the data storage unit 1441 of the slave node 100B (S2222).
  • the success receiving unit 1442 cancels the registration for RDMA in the memory area indicated by the R_KEY 14492 of the target record (Deregister). Then, the success receiving unit 1442 releases the memory area.
  • the memory size released at this time may be set in advance by an administrator or the like.
  • the success receiving unit 1442 deletes the target record from the proposal number management table 1445 (S2224), and ends this process. As a result, the consensus proposal data is reflected in all nodes.
  • the size of the memory area secured in the slave node 100B is set in advance by an administrator or the like. However, the size of this memory area may be automatically set by the node. An example of the processing is shown below.
  • the master node 100A transmits a preparation request in which the memory size is added to the sequence number and the proposal number to the slave node 100B (S101).
  • the preparation reception unit 1444 of the slave node 100B secures a new memory area based on the memory size included in the preparation request received from the master node 100A, and registers the memory area for RDMA. (Register). Then, the preparation receiving unit 1444 acquires R_KEY associated with the memory area.
  • the preparation reception unit 1444 of the slave node 100B adds the record having the memory size included in the preparation request to the proposal number management table 1445.
  • the successful reception unit 1442 of the slave node 100B deregisters the RDMA in the memory area indicated by the R_KEY of the target record acquired from the proposal number management table 1445 in S2221, and The memory area for the memory size included in the record is released. As a result, a memory area of an appropriate size is secured, and the use efficiency of the memory can be improved.
  • the present invention can be applied to a distributed computing system and a distributed processing method related to a distributed agreement algorithm other than PAXOS, such as ZAB shown in Non-Patent Document 3 or Raft shown in Non-Patent Document 4.
  • Node 110 CPU 120: Storage device 130: Memory 144: In-memory KVS 150: RDMA I / F, 180: Network I / F, 170: Client

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)

Abstract

　分散コンピューティングシステムにおいて、マスターがスレーブに対して提案番号を含む準備要求を送信する。スレーブは準備要求に含まれる提案番号が管理情報に存在しない場合、提案番号に対応付けた新たな識別子を含む準備応答をマスターに返信する。マスターはスレーブに対してその識別子及び提案を含む書込要求を送信する。スレーブはマスターから受信した書込要求に含まれる識別子と対応付けられているメモリ領域に提案を書き込み、書込が成功した場合は書込成功応答を返信する。マスターは書込成功応答を返信したスレーブを、提案に合意したと判定する。

Description

分散コンピューティングシステム及び分散処理方法
　本発明は、分散コンピューティングシステム及び分散処理方法の技術に関する。
　非特許文献１には、分散合意アルゴリズムを使ったＰＡＸＯＳというプロトコルが開示されている。ＰＡＸＯＳとは、計算機間で投票処理を行い、定足数（多くの場合過半数とする）以上の合意が得られれば、結果を全ての計算機に確定するプロトコルであり、全ての計算機から合意を得られなくても、定足数以上の合意が得られれば、結果を確定することができる。また、特許文献１には、ＰＡＸＯＳアルゴリズムにおいて、交換可能なコマンドを考慮に入れ、これにより、クライアントの要求の受信とそのクライアントへの応答の送信の間のより少ないメッセージ遅延を導入する分散コンピューティングシステムが記載されている。また、非特許文献２には、或る計算機のメモリから、リモートの異なる計算機のメモリへＤＭＡ転送を行うＲＤＭＡ（Ｒｅｍｏｔｅ　Ｄｉｒｅｃｔ　Ｍｅｍｏｒｙ　Ａｃｃｅｓｓ）の技術が開示されている。
特開２００６－１５５６１４号公報
Leslie Lamport, "The Part-Time Parliament", ACM Transactions on Computer Systems, volume 16, number 2 on pages 133-169, dated May 1998 InfiniBand Trace Association, "InfiniBand Architecture Specification, Volume 1, Release 1.2.1" Patrick Hunt, Mahadev Konar, Flavio P. Junqueira, Benjamin Reed, "ZooKeeper: wait-free coordination for internet-scale systems", In Proceedings of the 2010 USENIX conference on USENIX annual technical conference Diego Ongaro, John Ousterhout, "In Search of an Understandable Consensus Algorithm", In Proceeding of the 2014 USENIX conference on USENIX Annual Technical Conference
　従来のＰＡＸＯＳでは、マスター計算機（マスターの計算機）は、複数のスレーブ計算機（スレーブの計算機）に提案を送信し、それらのスレーブ計算機からの投票（応答）に基づいて、その提案の合意可否を判定する。このとき、マスター計算機は、各スレーブ計算機から応答が送信されてくるまで待機する必要がある。よって、マスター計算機が合意可否の判定に要する時間は、少なくともその待機時間以上となる。そこで、本発明の目的は、分散合意アルゴリズムに係る分散コンピューティングシステム及び分散処理方法において、合意形成に要する時間を削減することにある。
　一実施形態に係る分散コンピューティングシステムは、互いにネットワーク接続された複数の計算機を備え、各々の計算機が互いに連携して動作する。
　第１の計算機は、提案の準備の要求であり提案ＩＤを含む準備要求を第２の計算機に送信する。また、第１の計算機は、準備要求に対する応答でありメモリ領域ＩＤを含む準備応答を第２の計算機から受信した場合、提案の書き込みの要求であり提案と準備応答内のメモリ領域ＩＤとを含む書込要求を前記第２の計算機に送信する。また、第１の計算機は、書込要求に対する応答であり書込み成功を示す書込成功応答を第２の計算機から受信した場合、第２の計算機が前記提案に合意したと判定する。
　第２の計算機は、第１の計算機から受信した準備要求内の提案ＩＤが、提案ＩＤとメモリ領域ＩＤとの対応関係を表す管理情報に存在しない場合、準備要求内の提案ＩＤと新たなメモリ領域ＩＤとを含んだ組を管理情報に登録し、準備要求内の提案ＩＤと新たなメモリ領域ＩＤとを含む準備応答を返信する。また、第２の計算機は、第１の計算機から受信した書込要求内のメモリ領域ＩＤが管理情報に存在する場合、そのメモリ領域ＩＤから特定されるメモリ領域に受信した書込要求内の提案を書き込み、第１の計算機に書込成功応答を返信する。
　本発明によれば、分散合意アルゴリズムに係る分散コンピューティングシステム及び分散処理方法において、合意形成に要する時間を削減することができる。
実施形態に係る分散コンピューティングシステムの構成を示す。 インメモリＫＶＳに係る機能の一例を示す。 提案番号管理テーブルの構成例を示す。 書込先管理テーブルの構成例を示す。 分散コンピューティングシステムにおける合意形成処理の概要を示すシーケンスチャートである。 スレーブの準備受信部における準備要求に関する処理例の詳細を示すフローチャートである。 マスターの準備送信部における準備応答に関する処理例の詳細を示すフローチャートである。 マスターのＲＤＭＡ処理部が、提案データを各スレーブノードへＲＤＭＡ転送する処理例の詳細を示すフローチャートである。 合意判定部が１つのスレーブノードの合意を判定する処理例の詳細を示すフローチャートである。 スレーブの成功受信部が、提案データを反映する処理例の詳細を示すフローチャートである。
　以下、一実施形態を説明する。以下の説明では、「ｘｘｘテーブル」、「ｘｘｘキュー」又は「ｘｘｘリスト」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」、「ｘｘｘキュー」又は「ｘｘｘリスト」を「ｘｘｘ情報」と呼ぶことができる。以下の説明において、コンピュータプログラム（以下「プログラム」という）は、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信インターフェイスデバイスのうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ、そのプロセッサを有する装置とされてもよい。プロセッサが行う処理の一部又は全部が、ハードウェア回路で行われてもよい。プログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布ノード又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。
　以下の説明では、同種の要素を区別して説明する場合には、 「ノード１００Ａ」、「ノード１００Ｂ」のように、参照符号を使用し、同種の要素を区別しないで説明する場合には、「ノード１００」のように参照符号のうちの共通番号のみを使用することがある。
　図１は、実施形態に係る分散コンピューティングシステムの構成を示す。
　分散コンピューティングシステムは、複数のノード１００Ａ、１００Ｂ及び１００Ｃによってクラスタを構成する。クライアント１７０と、ノード１００Ａ、１００Ｂ及び１００Ｃの各々とは、ネットワーク１６０によって接続されている。クライアント及びノードは、計算機の一種である。ネットワーク１６０の一例としては、ＳＡＮ（Ｓｔｏｒａｇｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）及びＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）などがある。
　ノード１００は、ＣＰＵ１１０と、記憶デバイス１２０と、メモリ１３０と、ネットワークＩ／Ｆ１８０と、ＲＤＭＡ　Ｉ／Ｆ１５０とを有する。
　ネットワークＩ／Ｆ１８０は、ノード１００をネットワーク１６０に接続するためのＩ／Ｆである。ネットワークＩ／Ｆ１８０の一例としては、Ｅｔｈｅｒｎｅｔ（登録商標）アダプタ及びＦｉｂｒｅ　Ｃｈａｎｎｅｌアダプタなどがある。
　ＲＤＭＡ　Ｉ／Ｆ１５０は、ＲＤＭＡ転送を実現するためのＩ／Ｆである。ＲＤＭＡ転送とは、自分のノードと、リモートのノードとの間でＤＭＡ転送を行うことである。例えば、ノード１００ＡのＲＤＭＡ　Ｉ／Ｆ１５０Ａからリモートのノード１００ＢのＲＤＭＡ　Ｉ／Ｆ１５０Ｂへ、データがＲＤＭＡ転送された場合、ＲＤＭＡ　Ｉ／Ｆ１５０Ｂがその転送されたデータを直接メモリ１３０Ｂに格納する。このとき、リモートのノード１００ＢのＣＰＵ１１０Ｂは、処理を行う必要がない。これにより、ＣＰＵの処理負荷が軽減される。ＲＤＭＡ　Ｉ／Ｆ１５０同士は、ネットワーク１６０を通じて接続されてもよいし、ネットワーク１６０とは別のネットワーク又はケーブルなどによって接続されてもよい。
　記憶デバイス１２０は、データを格納するためのデバイスである。記憶デバイス１２０の一例としては、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）及びフラッシュメモリドライブなどがある。
　メモリ１３０は、プログラム及びデータなどを格納するためのデバイスである。メモリ１３０には、プログラムの一種であるＯＳ１４３及びインメモリＫＶＳ（Ｋｅｙ　Ｖａｌｕｅ　Ｓｔｏｒｅ）１４４などが格納される。メモリ１３０の一例としては、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＭＲＡＭ（Ｍａｇｎｅｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）及びＦｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）などがある。
　ＣＰＵ１１０は、メモリ１３０に格納されているプログラム及びデータを処理する。ＣＰＵ１１０は、ネットワークＩ／Ｆ１８０を通じたデータの送受信を処理する。各ノード１００のＣＰＵ１１０の処理により、分散コンピューティングシステムの有する様々な機能が実現される。
　インメモリＫＶＳ１４４は、キーバリューストアをメモリ１３０上に構築し、そのキーバリューストアを管理及び制御する。インメモリＫＶＳ１４４は、複数のノード１００でデータを分散して管理するインメモリ型分散ＫＶＳであってもよい。
　図２は、インメモリＫＶＳ１４４に係る機能の一例を示す。
　分散コンピューティングシステムは、クライアント１７０から送信された提案について、ＰＡＸＯＳプロトコルに基づいて、合意可否を判定する。以下、ＰＡＸＯＳプロトコルにおいて、マスターとなるノードを「マスターノード」といい、スレーブとなるノードを「スレーブノード」という場合がある。マスターとなるノード１００及びスレーブとなるノード１００は、固定されず、その時々で異なってよい。
　インメモリＫＶＳ１４４に係る機能として、ノード１００は、準備送信部１４４７と、準備受信部１４４４と、合意判定部１４４３と、成功送信部１４４８と、成功受信部１４４２と、ＲＤＭＡ処理部１４４６とを有する。また、インメモリＫＶＳ１４４は、データ格納部１４４１と、提案番号管理テーブル１４４５と、書込先管理テーブル１４４９とを管理する。これらのテーブル１４４５及び１４４９は、例えば、メモリ１３０に格納される。
　データ格納部１４４１には、クライアント１７０から送信された提案データが格納される。ここで、データ格納部１４４１に格納される提案データは、分散コンピューティングシステムの全体で合意が形成されたものである。分散コンピューティングシステムの全体で合意が形成されなかった提案データは、データ格納部１４４１に格納されない。
　準備送信部１４４７は、マスターノード１００で実行され（つまりこのインメモリＫＶＳ１４４を有するノード１００がマスターノード１００の場合に実行され）、ネットワークＩ／Ｆ１８０を通じて、スレーブノード１００に対して準備（Ｐｒｅｐａｒｅ）要求を送信する。準備要求には、少なくともシーケンス番号及び提案番号が含まれる。シーケンス番号は、一連の合意形成の処理を識別するための情報である。シーケンス番号が異なる場合、合意形成の処理対象が異なる。すなわち、分散コンピューティングシステムの全体で合意が形成され、提案データが各ノード１００のデータ格納部１４４１に反映されたときに、そのシーケンス番号の処理が完了する。
　提案番号は、提案データを識別すると共に、何れの提案データが新しいかを識別するための情報である。提案番号が大きい程、新しい提案データであることを示す。シーケンス番号及び提案番号の詳細については後述する。また、本実施形態では、シーケンス及び提案データの各々について、ＩＤとして番号が採用されるが、シーケンス又は提案データの新旧の判断が可能な種類の識別情報（例えばアルファベット）がシーケンスＩＤ又は提案ＩＤとして採用されてもよい。
　準備受信部１４４４は、スレーブノード１００で実行され（つまり、このインメモリＫＶＳ１４４を有するノード１００がスレーブノード１００の場合に実行され）、ネットワークＩ／Ｆ１８０を通じて、マスターノード１００から準備要求を受信する。そして、準備受信部１４４４は、その準備要求に関する処理を行う。そして、準備受信部１４４４は、その準備要求に関する処理の結果を含む準備応答を、ネットワークＩ／Ｆ１８０を通じてマスターノード１００に返信する。準備要求に関する処理が成功した場合の準備成功応答は、準備要求に含まれていた提案番号に対応付けられたメモリ領域のＩＤ（以下「Ｒ＿ＫＥＹ」という）を含む。Ｒ＿ＫＥＹの詳細については後述する。準備要求に関する処理が失敗した場合の準備失敗応答は、失敗を示す情報を含む。
　例えば、準備受信部１４４４は、準備要求に含まれる提案番号を有するレコードが提案番号管理テーブル１４４５に存在しない場合、新たなメモリ領域を確保する。そして、準備受信部１４４４は、その提案番号と、新たなメモリ領域と、その新たなメモリ領域を示すＲ＿ＫＥＹとを対応付けるレコードを提案番号管理テーブル１４４５に登録する。そして、準備受信部１４４４は、その新たなメモリ領域を示すＲ＿ＫＥＹを含む準備成功応答を、マスターノード１００へ返信する。マスターノード１００の準備送信部１４４７は、その準備応答を受信すると、その準備応答の送信元のノード（スレーブ）１００を示すノードＩＤと、その準備応答に含まれるＲ＿ＫＥＹとを対応付けるレコードを書込先管理テーブル１４４９に登録してよい。
　例えば、準備受信部１４４４は、準備要求に含まれるシーケンス番号を有するレコードが提案番号管理テーブル１４４５に存在し、且つ、その準備要求に含まれる提案番号が、提案番号管理テーブル１４４５におけるそのシーケンス番号を有するレコードに係る提案番号以下の場合、そのシーケンス番号を有するレコードに係る提案番号を含む準備失敗応答を、マスターノード１００へ返信する。
　例えば、準備受信部１４４４は、準備要求に含まれるシーケンス番号を有するレコードが提案番号管理テーブル１４４５に存在し、且つ、その準備要求に含まれる提案番号が、提案番号管理テーブル１４４５におけるそのシーケンス番号を有するレコードに係る提案番号よりも大きい場合、次の処理を実行する。すなわち、準備受信部１４４４は、その提案番号に対応付けられているメモリ領域に、提案が書込済みであるか否かを判定する。この提案データは、後述するように、マスターノード１００からのＲＤＭＡ転送によって、メモリ領域に書き込まれる。
　そのメモリ領域に提案データが書込済みである場合、準備受信部１４４４は、そのメモリ領域の提案データを含む準備失敗応答をマスターノード１００へ返信する。
　そのメモリ領域に提案データが未だ書き込まれていない場合、準備受信部１４４４は、上述の準備要求に含まれる提案番号を有するレコードが提案番号管理テーブル１４４５に存在しない場合と同様に、新たなメモリ領域を確保すると共に、新たなレコードを提案番号管理テーブル１４４５に登録し、準備成功応答をマスターノード１００へ返信する。
　ＲＤＭＡ処理部１４４６は、マスターノード１００で実行され、ＲＤＭＡ転送を用いて、複数のスレーブノード１００に対して提案データを送信する。すなわち、ＲＤＭＡ処理部１４４６は、書込先管理テーブル１４４９から、ＲＤＭＡ転送先のスレーブノード１００に対応するＲ＿ＫＥＹを取得する。そして、ＲＤＭＡ処理部１４４６は、ＲＤＭＡ　Ｉ／Ｆ１５０を通じて、スレーブノード１００のそのＲ＿ＫＥＹの示すメモリ領域に対し、提案データをＲＤＭＡ転送（ＲＤＭＡ　ＳＥＮＤ）する。そのＲＤＭＡ転送に対する書込成功応答又は書込失敗応答は、マスターノード１００のＲＤＭＡ　Ｉ／Ｆ１５０が管理する完了キューに格納される。
　合意判定部１４４３は、マスターノード１００で実行され、各スレーブノード１００からの投票に基づいて、提案データについて合意が形成されたか否かを判定する。例えば、合意判定部１４４３は、複数のスレーブノード１００の内の定足数（例えば過半数）以上のスレーブノード１００から「合意」の投票を得られた場合、提案データについて合意が形成されたと判定する。本実施形態に係る合意判定部１４４３は、スレーブノード１００からマスターノード１００に対するＲＤＭＡ転送の書込応答に基づいて、合意が形成されたか否かの判定を行う。この判定は、例えば次のように行われる。
　スレーブノード１００のＲＤＭＡ　Ｉ／Ｆ１５０は、マスターノード１００のＲＤＭＡ　Ｉ／Ｆ１５０から提案データに係るＲＤＭＡ転送を受けると、そのＲ＿ＫＥＹの示すメモリ領域に対する提案データの書き込み処理を行う。スレーブノード１００のＲＤＭＡ　Ｉ／Ｆ１５０は、マスターノード１００のＲＤＭＡ　Ｉ／Ｆ１５０に対して、提案データの書込が成功した場合、書込成功応答を返信し、書込が失敗した場合、書込失敗応答を返信する。具体的には、スレーブノード１００のＲＤＭＡ　Ｉ／Ｆ１５０は、マスターノード１００のＲＤＭＡ　Ｉ／Ｆ１５０の管理する完了キューに、書込成功応答又は書込失敗応答を書き込む。合意判定部１４４３は、書込成功応答を返信したスレーブノード１００はその提案データに「合意した」と判定し、書込失敗応答を返信したスレーブノード１００はその提案データに「合意しなかった」と判定する。すなわち、合意判定部１４４３は、定足数以上のスレーブノード１００からＲＤＭＡ転送に係る書込成功応答が返信された場合、そのＲＤＭＡ転送した提案データについて合意が形成されたと判定する。
　なお、スレーブノード１００から所定時間内にＲＤＭＡ転送の書込応答を受けられなかった場合、合意判定部１４４３は、そのスレーブノード１００に対するＲＤＭＡ転送が失敗したと判定する。この場合、マスターノード１００は、そのスレーブノード１００に対して再度ＲＤＭＡ転送を行ってもよい。
　成功送信部１４４８は、マスターノード１００で実行され、合意判定部１４４３において提案データの合意が形成された場合、データ格納部１４４１にその提案データを反映する。そして、成功送信部１４４８は、ネットワークＩ／Ｆ１８０を通じて、各スレーブノード１００に対して成功（Ｓｕｃｃｅｓｓ）通知を送信する。成功通知は、合意された提案データに対応するシーケンス番号を含む。
　成功受信部１４４２は、スレーブノード１００で実行され、ネットワークＩ／Ｆ１８０を通じて、マスターノード１００から成功通知を受信すると、次の処理を行う。すなわち、成功受信部１４４２は、提案番号管理テーブル１４４５から、合意通知に含まれるシーケンス番号に対応するＲ＿ＫＥＹを抽出する。そして、成功受信部は、そのＲ＿ＫＥＹの示すメモリ領域から提案データをリードし、その提案データをデータ格納部１４４１へ反映する。これにより、合意判定部１４４３において合意された提案データが、全てのノード１００に反映される。
　図３は、提案番号管理テーブル１４４５の構成例を示す。
　提案番号管理テーブル１４４５は、提案番号と、ＲＤＭＡ転送に係るメモリ領域との対応関係を管理するためのテーブルであり、スレーブノード１００によって保持される。提案番号管理テーブル１４４５は、複数のレコードを有し、各レコードは、フィールド値として、シーケンス番号１４４５１と、提案番号１４４５２と、Ｒ＿ＫＥＹ１４４５３と、メモリサイズ１４４５４とを有する。
　シーケンス番号１４４５１は、一連の合意形成の処理を識別するための情報である。シーケンス番号が異なる場合、合意形成の対象が異なる。
　提案番号１４４５２は、提案データを識別すると共に、何れの提案データが新しいかを識別するための情報である。提案番号１４４５２が大きい程、新しい提案データであることを示す。提案番号１４４５２が同じであっても、シーケンス番号１４４５１が異なる場合、異なる提案データである。
　Ｒ＿ＫＥＹ１４４５３は、ＲＤＭＡ用のメモリ領域のＩＤである。Ｒ＿ＫＥＹ１４４５３は、例えば、メモリアドレスそれ自体、又は、メモリアドレスを含んだ情報であってもよい。メモリサイズ１４４５４は、Ｒ＿ＫＥＹ１４４５３の示すメモリ領域のサイズを示す情報である。
　図３の提案番号管理テーブル１４４５において、レコード１４４５０は、シーケンス番号１４４５１「１」における提案番号１４４５２「１」には、Ｒ＿ＫＥＹ１４４５３「０ｘ４２１３ａ２」の示すメモリ領域が対応付けられており、そのメモリ領域のサイズ１４４５４は「１００」であることを示す。
　提案番号管理テーブル１４４５は、スレーブノード１００の準備受信部１４４４がマスターノード１００から受信した準備要求を基に更新される。上述のとおり、準備受信部１４４４が、新たなメモリ領域を確保し、提案番号管理テーブル１４４５にその新たなメモリ領域を示すＲ＿ＫＥＹ１４４５３を有するレコードを登録する場合とは、次の何れかの場合である。
（１）準備要求に含まれる提案番号を有するレコードが提案番号管理テーブル１４４５に存在しない場合。
（２）準備受信部１４４４は、準備要求に含まれるシーケンス番号を有するレコードが提案番号管理テーブル１４４５に存在し、且つ、その準備要求に含まれる提案番号が、提案番号管理テーブル１４４５におけるそのシーケンス番号を有するレコードに係る提案番号１４４５２よりも大きい場合であって、そのメモリ領域に提案データが未だ書き込まれていない場合。
　したがって、マスターノード１００からＲＤＭＡ転送された提案データに係るＲ＿ＫＥＹが提案番号管理テーブル１４４５に存在しないということは、その提案データは、上記の（１）及び（２）の何れにも該当しないものであるといえる。そしてこの場合、このＲ＿ＫＥＹの示すメモリ領域は確保されていないため、スレーブノード１００のＲＤＭＡ　Ｉ／Ｆ１５０は、マスターノード１００に対して書込失敗応答を返信する。よって、マスターノード１００のＲＤＭＡ処理部１４４６は、ＲＤＭＡ転送に対する書込失敗応答をもってそのスレーブノード１００は「合意しなかった」と判定できるのである。
　これに対して、マスターノード１００からＲＤＭＡ転送された提案データに係るＲ＿ＫＥＹが提案番号管理テーブル１４４５に存在するということは、その提案データは、上記の（１）又は（２）の何れかに該当するものであるといえる。そしてこの場合、このＲ＿ＫＥＹの示すメモリ領域は確保されているため、スレーブノード１００のＲＤＭＡ　Ｉ／Ｆ１５０は、マスターノード１００に対して書込成功応答を返信する。よって、マスターノード１００のＲＤＭＡ処理部１４４６は、ＲＤＭＡ転送に対する書込成功応答をもってそのスレーブノード１００は「合意した」と判定できるのである。
　すなわち、提案番号管理テーブル１４４５において、提案番号とＲＤＭＡ転送に係るメモリ領域とを対応付けることにより、マスターノード１００は、その提案番号に対するスレーブノード１００の合意可否を、ＲＤＭＡ転送の成功又は失敗によって判定することができる。これにより、分散コンピューティングシステムの全体における合意形成に要する時間を削減することができる。
　図４は、書込先管理テーブル１４４９の構成例を示す。
　書込先管理テーブル１４４９は、ＲＤＭＡ転送に係る書込先のノード１００と、そのノード１００のメモリ領域と、の対応関係を管理するためのテーブルであり、マスターノード１００によって保持される。書込先管理テーブル１４４９は、複数のレコードを有し、各レコードは、フィールド値として、ノードＩＤ１４４９１と、Ｒ＿ＫＥＹ１４４９２とを有する。
　ノードＩＤ１４４９１は、ノードを識別するための情報である。Ｒ＿ＫＥＹ１４４９２は、ノードＩＤの示すノードにおける、ＲＤＭＡ転送に係る書込先のメモリ領域を示す。
　図４の書込先管理テーブル１４４９において、レコード１４４９０は、ノードＩＤ１４４９１「Ｂ」のノード１００には、Ｒ＿ＫＥＹ１４４９２「０ｘ４２１３ａ２」の示すメモリ領域が対応付けられていることを示す。例えば、ＲＤＭＡ処理部１４４６は、このレコード１４４９０を参照して、ノードＩＤ「Ｂ」のノードにおけるＲ＿ＫＥＹ「０ｘ４２１３ａ２」の示すメモリ領域に対して、提案データに係るＲＤＭＡ転送を実行する。
　図５は、分散コンピューティングシステムにおける合意形成処理の概要を示すシーケンスチャートである。
　以下、ノード１００Ａをマスターノード、ノード１００Ｂをスレーブノードとして説明するが、マスターノード１００Ａは、他のスレーブノード１００（例えば１００Ｃ）に対しても同様の処理を行う。
　マスターノード１００Ａの準備送信部１４４７は、所定の契機にネットワークＩ／Ｆを通じて、スレーブノード１００Ｂへ準備要求を送信する（Ｓ１０１）。スレーブノード１００ＢのＯＳ１４３Ｂは、準備要求を受信すると、マスターノード１００ＡへＡＣＫを返信する（Ｓ２０１）。そのＡＣＫを受信したマスターノード１００Ａの準備送信部１４４７は、準備要求の送信が成功したと判定する（Ｓ１０２）。
　スレーブノード１００Ｂの準備受信部１４４４は、準備要求に関する処理を実行し、ネットワークＩ／Ｆ１８０Ｂを通じて、マスターノード１００Ａへ準備応答を返信する（Ｓ２０２２）。この処理の詳細については後述する（図６参照）。
　マスターノード１００の準備送信部１４４７は、スレーブノード１００Ｂから返信された準備応答に関する処理を行う（Ｓ１０３）。この処理の詳細については後述する。また、マスターノード１００ＡのＯＳ１４３Ａは、その準備応答を受信すると、スレーブノード１００ＢへＡＣＫを返信する。そのＡＣＫを受信したスレーブノード１００Ｂは、準備応答の返信が成功したと判定する（Ｓ２０４）。
　クライアント１７０が、マスターノード１００Ａへ提案データを送信する（Ｓ１１）。マスターノード１００は、提案データを受信すると、クライアント１７０へＡＣＫを返信する（Ｓ１０４）。そのＡＣＫを受信したクライアント１７０は、提案データの送信が成功したと判定する（Ｓ１２）。
　提案データを受信したマスターノード１００ＡのＲＤＭＡ処理部１４４６は、提案データを複数のスレーブノード１００Ｂ、１００Ｃ、…の各々へＲＤＭＡ転送する（Ｓ１０４１）。この処理の詳細については後述する（図７参照）。
　スレーブノード１００ＢのＲＤＭＡ　Ｉ／Ｆ１５０Ｂは、マスターノード１００ＡからＲＤＭＡ転送された提案データを、Ｒ＿ＫＥＹの示すメモリ領域に書き込む。そして、ＲＤＭＡ　Ｉ／Ｆ１５０Ｂは、書込が成功した場合は書込成功応答を、書込が失敗した場合は書込失敗応答を、スレーブノード１００Ｂのメモリ１３０Ｂの完了キュー（Ｃｏｍｐｌｅｔｉｏｎ　Ｑｕｅｕｅ）と、マスターノード１００Ａのメモリ１３０Ａの完了キューに格納する（Ｓ２０５１）。すなわち、マスターノード１００Ａのメモリ１３０Ａの完了キューには、複数のスレーブノード１００Ｂ、１００Ｃ、…の各々から、提案データのＲＤＭＡ転送に係る書込応答が格納される。
　マスターノード１００Ａの合意判定部１４４３は、メモリ１３０Ａの完了キューに格納されている書込成功応答の数に基づいて、分散コンピューティングシステム全体における合意が形成されたか否かを判定する（Ｓ１０５１）。この処理の詳細については後述する（図９参照）。以下、合意判定部１４４３が、合意が形成されたと判定した場合について説明する。
　合意が形成されたと判定された場合、マスターノード１００Ａの成功送信部１４４８は、Ｓ１０４でクライアント１７０から受信した提案データを、データ格納部１４４１に格納する（Ｓ１０６）。そして、マスターノード１００Ａの成功送信部１４４８は、書込成功応答を返信してきた全てのスレーブノード１００Ｂ、１００Ｃ、…の各々へ、ネットワークＩ／Ｆ１８０Ａを通じて、成功通知を送信する（Ｓ１０７）。
　スレーブノード１００Ｂの成功受信部１４４２は、マスターノード１００Ａから成功通知を受信すると、ＲＤＭＡ転送によってＲ＿ＫＥＹの示すメモリ領域に書き込まれた提案データを、データ格納部１４４１Ｂに反映する（Ｓ２０９１）。この処理の詳細については後述する（図１０参照）。
　マスターノード１００Ａは、ネットワークＩ／Ｆ１８０Ａを通じて、クライアント１７０に対して、提案データに対する処理結果を返信する（Ｓ１０８）。処理結果には、提案データが分散コンピューティングシステムに受け入れられたか否か（つまり、合意が形成されたか否か）を示す情報が含まれてよい。
　クライアント１７０は、マスターノード１００Ａから提案データに対する処理結果を受信すると、マスターノード１００ＡへＡＣＫを返信する（Ｓ１３）。そのＡＣＫを受信したマスターノード１００Ａは、提案データに対する処理結果の送信が成功したと判定する（Ｓ１０９）。
　図６は、スレーブノード１００Ｂの準備受信部１４４４における準備要求に関する処理例の詳細を示すフローチャートである。本処理は、図５のＳ２０２２の処理に相当する。
　準備受信部１４４４は、マスターノード１００から準備要求を受信すると、次の処理を行う。準備受信部１４４４は、準備要求に含まれるシーケンス番号と一致するシーケンス番号１４４５１を有するレコード（この図６の説明において「対象レコード」という）が提案番号管理テーブル１４４５に有るか否かを判定する（Ｓ２１０１）。その判定結果が肯定の場合（Ｓ２１０１：ＹＥＳ）、Ｓ２１０２に進み、その判定結果が否定の場合（Ｓ２１０１：ＮＯ）、Ｓ２１１１に進む。
　まず、対象レコードが無い場合（Ｓ２１０１：ＮＯ）について説明する。準備受信部１４４４は、新たなメモリ領域をＲＤＭＡ用に確保及び登録し（Ｒｅｇｉｓｔｅｒ）、その新たなメモリ領域を示すＲ＿ＫＥＹを取得する（Ｓ２１１１）。新たなメモリ領域をＲＤＭＡ用に確保及び登録する処理、並びに、この新たなメモリ領域にＲ＿ＫＥＹを対応付ける処理は、ＲＤＭＡ　Ｉ／Ｆ１５０Ｂによって行われてもよい。新たなメモリ領域のサイズは、予め管理者等によって設定されてもよい。
　そして、準備受信部１４４４は、提案番号管理テーブル１４４５に、新たなレコードを追加する。この新たなレコードは、準備要求に含まれていたシーケンス番号及び提案番号と、Ｓ２１１１において取得したＲ＿ＫＥＹと、そのＲ＿ＫＥＹの示す新たなメモリ領域のメモリサイズと、を含む（Ｓ２１１２）。
　そして、準備受信部１４４４は、マスターノード１００Ａに対して、Ｓ２１１１において取得したＲ＿ＫＥＹを含む準備成功応答を返信し（Ｓ２１１３）、本処理を終了する。
　次に、対象レコードが有る場合（Ｓ２１０１：ＹＥＳ）について説明する。準備受信部１４４４は、準備要求に含まれる提案番号（提案番号Ｘ）が、対象レコードの有する提案番号１４４５２（提案番号Ｙ）以下であるか否かを判定する（Ｓ２１０２）。
　提案番号Ｘが提案番号Ｙ以下である場合（Ｓ２１０２：ＹＥＳ）、準備受信部１４４４は、次の処理を実行する。すなわち、準備受信部１４４４は、マスターノード１００Ａの準備送信部１４４７に対して、対象レコードの有する提案番号１４４５２を含む準備失敗応答を返信し（Ｓ２１０５）、本処理を終了する。なぜなら、提案番号Ｘが提案番号Ｙ以下とは、提案番号Ｘが、先に受信した提案番号Ｙよりも古い又は同じという意味だからである。
　提案番号Ｘが提案番号Ｙよりも大きい場合（Ｓ２１０２：ＮＯ）、準備受信部１４４４は、次の処理を実行する。すなわち、準備受信部１４４４は、対象レコードの有するＲ＿ＫＥＹ１４４５３が示すメモリ領域の登録を解除（Ｄｅｒｅｇｉｓｔｅｒ）する（Ｓ２１０３）。このメモリ領域の登録の解除は、ＲＤＭＡ　Ｉ／Ｆ１５０Ｂによって行われてよい。
　そして、準備受信部１４４４は、このＲ＿ＫＥＹ１４４５３が示すメモリ領域に対して、ＲＤＭＡ転送による提案データの書き込みが完了しているか否かを判定する（Ｓ２１０４）。例えば、準備受信部１４４４は、自分の有する完了キュー（Ｃｏｍｐｌｅｔｉｏｎ　Ｑｕｅｕｅ）を参照して、この判定を行ってもよい。
　そのＲ＿ＫＥＹ１４４５３が示すメモリ領域に対して、提案データの書き込みが完了している場合（Ｓ２１０４：ＹＥＳ）、準備受信部１４４４は、マスターノード１００Ａに対して、そのＲ＿ＫＥＹ１４４５３が示すメモリ領域の提案データを含む準備失敗応答を返信する（Ｓ２１０６）。そして、準備受信部１４４４は、本処理を終了する。
　そのＲ＿ＫＥＹ１４４５３が示すメモリ領域への書き込みが完了していない場合（Ｓ２１０４：ＮＯ）、準備受信部１４４４は、上記Ｓ２１１１の処理に進む。つまりこの場合、準備受信部１４４４は、マスターノード１００Ａに対して、準備成功応答を返信する。なぜなら、そのメモリ領域にはもう提案データが書き込まれることはないため、スレーブノード１１０Ｂは、より新しい提案番号に合意すべきだからである。
　図７は、マスターノード１００Ａの準備送信部１４４７における準備応答に関する処理例の詳細を示すフローチャートである。本処理は、図５のＳ１０３の処理に相当する。
　マスターノード１００Ａの準備送信部１４４７は、スレーブノード１００Ｂから準備応答を受信すると（Ｓ１２０１）、次の処理を行う。準備送信部１４４７は、準備応答が、提案番号を含む準備失敗応答であるか否かを判定する（Ｓ１２０２）。
　準備応答が、提案番号を含む準備失敗応答である場合（Ｓ１２０２：ＹＥＳ）、準備送信部１４４７は、その準備失敗応答に含まれている提案番号よりも大きな提案番号を用いて、図５に示すＳ１０１以降の処理を再度行う（Ｓ１２１１）。これにより、マスターノード１００Ａの準備送信部１４４７は、次回の準備要求に含めるべき提案番号を知ることができる。
　準備応答が、提案番号を含む準備失敗応答でない場合（Ｓ１２０２：ＮＯ）、準備送信部１４４７は、次の処理を行う。すなわち、準備送信部１４４７は、準備応答が、提案データを含む準備失敗応答であるか否かを判定する（Ｓ１２０３）。
　準備応答が、提案データを含む準備失敗応答である場合（Ｓ１２０３：ＹＥＳ）、準備送信部１４４７は、その準備失敗応答に含まれる提案データを用いて、図５に示すＳ１０１以降の処理を再度行う（Ｓ１２１２）。これにより、マスターノード１００Ａは、そのスレーブノード１００Ｂに書き込まれた提案データを、他のスレーブノードにも反映させることができる。
　準備応答が、提案データを含む準備失敗応答でない場合（Ｓ１２０３：ＮＯ）、つまり準備応答がＲ＿ＫＥＹを含む準備成功応答である場合、準備送信部１４４７は、次の処理を実行する。すなわち、準備送信部１４４７は、書込先管理テーブル１４４９Ａにおいて、その準備応答を送信してきたスレーブノード１００ＢのノードＩＤ１４４９１に対応するＲ＿ＫＥＹ１４４９２を、準備成功応答に含まれるＲ＿ＫＥＹに更新する（Ｓ１２０４）。そして、準備送信部１４４７は、本処理を終了する。
　図８は、マスターノード１００ＡのＲＤＭＡ処理部１４４６が、提案データを各スレーブノード１００へＲＤＭＡ転送する処理例の詳細を示すフローチャートである。本処理は、図５のＳ１０４１の処理に相当する。以下、ＲＤＭＡ転送先のスレーブノードはスレーブノード１００Ｂであるとする。
　マスターノード１００ＡのＲＤＭＡ処理部１４４６は、クライアント１７０から提案データを受信すると、次の処理を行う。ＲＤＭＡ処理部１４４６は、書込先管理テーブル１４４９内の、ノードＩＤ１４４９１「Ｂ」を含むレコードから、Ｒ＿ＫＥＹ１４４９２を取得する（Ｓ１３０１）。
　そして、ＲＤＭＡ処理部１４４６は、その取得したＲ＿ＫＥＹ１４４９２の示すメモリ領域に対して、クライアント１７０から受信した提案データを、ＲＤＭＡ転送する（Ｓ１３０２）。例えば、ＲＤＭＡ処理部１４４６は、ＲＤＭＡ　Ｉ／Ｆ１５０Ａに対して、「ＲＤＭＡ　Ｗｒｉｔｅ　ｗｉｔｈ　Ｉｍｍｅｄｉａｔｅ」を指示する。
　図９は、合意判定部１４４３が１つのスレーブノード１００Ｂの合意を判定する処理例の詳細を示すフローチャートである。本処理は、図５のＳ１０５１における１つのスレーブノード１００Ｂに対する処理に相当する。
　合意判定部１４４３は、スレーブノード１００ＢからのＲＤＭＡ転送に係る書込応答の返信を待機する（Ｓ１４０１）。例えば、合意判定部１４４３は、マスターノード１００ＡのＲＤＭＡ　Ｉ／Ｆ１５０Ａが管理する完了キューを一定の間隔でポーリングし、書込応答が格納されているか否かを判定する。例えば、マスターノード１００ＡのＲＤＭＡ　Ｉ／Ｆ１５０Ａが、完了キューに書込応答が格納されたときに、合意判定部１４４３に対して、その旨を示す割り込み通知を行う。
　合意判定部１４４３は、書込応答の返信を受けられずタイムアウトした場合（Ｓ１４０２：ＮＯ）、次の処理を実行してよい。すなわち、合意判定部１４４３は、スレーブノード１００に対する提案データのＲＤＭＡ転送が失敗したと判定し（Ｓ１４０３）、図５に示すＳ１０４１に戻り、ＲＤＭＡ転送をやり直してもよい。タイムアウトまでの所定時間は、管理者によって予め設定されてよい。
　合意判定部１４４３は、所定時間内に書込応答の返信を受けられた場合（Ｓ１４０２：ＹＥＳ）、次の処理を実行する。すなわち、合意判定部１４４３は、書込応答が、書込成功応答又は書込失敗応答の何れであるかを判定する（Ｓ１４０４）。例えば、合意判定部１４４３は、ＲＤＭＡ転送の実行結果（Ｃｏｍｐｌｅｔｉｏｎ　Ｒｅｔｕｒｎ　Ｓｔａｔｕｓ）によって確認してもよい。
　書込応答が、書込失敗応答であった場合（Ｓ１４０４：失敗）、合意判定部１４４３は、このスレーブノード１００Ｂは提案データに合意しなかったと判定し（Ｓ１４０５）、本処理を終了する。書込失敗応答は、ＲＤＭＡ転送の実行結果が、スレーブノード１００Ｂのメモリ領域へのアクセスエラー（Ｒｅｍｏｔｅ　Ａｃｃｅｓｓ　Ｅｒｒｏｒ）であってもよい。
　書込応答が、書込成功応答であった場合（Ｓ１４０４：成功）、合意判定部１４４３は、このスレーブノード１００は提案データに合意したと判定し（Ｓ１４０６）、本処理を終了する。書込成功応答は、ＲＤＭＡ転送の実行結果が、成功（Ｓｕｃｃｅｓｓ）であってもよい。
　図１０は、スレーブノード１００Ｂの成功受信部１４４２が、提案データを反映する処理例の詳細を示すフローチャートである。本処理は、図５のＳ２０９１の処理に相当する。
　スレーブノード１００Ｂの成功受信部１４４２は、マスターノード１００Ａから成功通知を受信すると、次の処理を実行する。成功受信部１４４２は、提案番号管理テーブル１４４５から、その受信した成功通知に含まれるシーケンス番号と一致するシーケンス番号１４４５１を有するレコード（この図１０の説明において「対象レコード」という）を取得する（Ｓ２２２１）。
　成功受信部１４４２は、対象レコードのＲ＿ＫＥＹ１４４９２が示すメモリ領域から提案データを取得する。そして、成功受信部１４４２は、その取得した提案データを、スレーブノード１００Ｂのデータ格納部１４４１に反映する（Ｓ２２２２）。
　成功受信部１４４２は、対象レコードのＲ＿ＫＥＹ１４４９２が示すメモリ領域のＲＤＭＡ用の登録を解除（Ｄｅｒｅｇｉｓｔｅｒ）する。そして、成功受信部１４４２は、そのメモリ領域を解放する。このときに解放されるメモリサイズは、管理者等によって予め設定されてもよい。
　成功受信部１４４２は、提案番号管理テーブル１４４５から、対象レコードを削除し（Ｓ２２２４）、本処理を終了する。これにより、合意形成された提案データが、全てのノードに反映される。
　上述では、スレーブノード１００Ｂにおいて確保されるメモリ領域のサイズは、管理者等によって予め設定されていた。しかし、このメモリ領域のサイズは、ノードによって自動的に設定されてもよい。以下に、その処理例を示す。
　図５に示すＳ１０１の処理において、マスターノード１００Ａは、シーケンス番号及び提案番号にメモリサイズを加えた準備要求を、スレーブノード１００Ｂに送信する（Ｓ１０１）。
　そして、図６に示すＳ２１１１において、スレーブノード１００Ｂの準備受信部１４４４は、マスターノード１００Ａから受信した準備要求に含まれるメモリサイズに基づいて新しいメモリ領域を確保し、そのメモリ領域をＲＤＭＡ用に登録（Ｒｅｇｉｓｔｅｒ）する。そして、準備受信部１４４４は、そのメモリ領域に対応付けられたＲ＿ＫＥＹを取得する。
　そして、図６に示すＳ２１１２において、スレーブノード１００Ｂの準備受信部１４４４は、準備要求に含まれていたメモリサイズを有するレコードを、提案番号管理テーブル１４４５に追加する。
　そして、図１０に示すＳ２２２３において、スレーブノード１００Ｂの成功受信部１４４２は、Ｓ２２２１で提案番号管理テーブル１４４５から取得した対象レコードのＲ＿ＫＥＹが示すメモリ領域のＲＤＭＡ用の登録を解除（Ｄｅｒｅｇｉｓｔｅｒ）し、そのレコードに含まれるメモリサイズの分のメモリ領域を解放する。これにより、適切なサイズのメモリ領域が確保され、メモリの使用効率を向上させることができる。
　上述した実施形態は例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。例えば、本発明は、非特許文献３に示されるＺＡＢ又は非特許文献４に示されるＲａｆｔといったＰＡＸＯＳ以外の分散合意アルゴリズムに係る分散コンピューティングシステム及び分散処理方法にも適用できる。
　１００：ノード　１１０：ＣＰＵ　１２０：記憶デバイス　１３０：メモリ　１４４：インメモリＫＶＳ　１５０：ＲＤＭＡ　Ｉ／Ｆ、１８０：ネットワークＩ／Ｆ、１７０：クライアント
 

Claims (12)

  1. 　互いにネットワーク接続された複数の計算機を備えた分散コンピューティングシステムであって、
    　第１の計算機は、
    　　提案の準備の要求であり提案ＩＤを含む準備要求を第２の計算機に送信し、
    　　前記準備要求に対する応答でありメモリ領域ＩＤを含む準備応答を前記第２の計算機から受信した場合、前記提案の書き込みの要求であり前記提案と前記準備応答内のメモリ領域ＩＤとを含む書込要求を前記第２の計算機に送信し、
    　　前記書込要求に対する応答であり書込み成功を示す書込成功応答を前記第２の計算機から受信した場合、前記第２の計算機が前記提案に合意したと判定し、
    　前記第２の計算機は、
    　　前記第１の計算機から受信した前記準備要求内の提案ＩＤが、提案ＩＤとメモリ領域ＩＤとの対応関係を表す管理情報に存在しない場合、前記準備要求内の提案ＩＤと新たなメモリ領域ＩＤとを含んだ組を前記管理情報に登録し、前記準備要求内の提案ＩＤと前記新たなメモリ領域ＩＤとを含む前記準備応答を返信し、
    　　前記第１の計算機から受信した前記書込要求内の前記メモリ領域ＩＤが前記管理情報に存在する場合、そのメモリ領域ＩＤから特定されるメモリ領域に前記受信した書込要求内の提案を書き込み、前記第１の計算機に前記書込成功応答を返信する
    分散コンピューティングシステム。
  2. 　前記第１の計算機は、
    　　複数の第２の計算機の各々に前記準備要求を送信し、
    　　前記複数の第２の計算機のうちの前記準備応答の送信元の第２の計算機に前記書込要求を送信し、
    　　前記書込成功応答を返信した第２の計算機の数が、前記準備要求の送信先の第２の計算機の数に対して所定の定足数を満たす場合、前記提案について合意が形成されたと判定し、前記提案を前記第１の計算機及び前記複数の第２の計算機に反映させる
    請求項１に記載の分散コンピューティングシステム。
  3. 　前記管理情報は、前記合意の形成に係るシーケンスのシーケンスＩＤと、提案ＩＤと、メモリ領域ＩＤとの対応関係を表す情報であり、
    　前記準備要求は、前記提案に対応した提案ＩＤ及びシーケンスＩＤを含む
    請求項２に記載の分散コンピューティングシステム。
  4. 　前記第２の計算機は、
    　　前記第１の計算機から受信した前記準備要求内のシーケンスＩＤが前記管理情報に存在し、且つ、前記準備要求内の提案ＩＤと前記管理情報に存在するシーケンスＩＤに対応付けられている提案ＩＤとの比較の結果が、前記提案が過去の提案と同じかそれより古いことを表している場合、準備の失敗を示す準備応答を前記第１の計算機に返信する
    請求項３に記載の分散コンピューティングシステム。
  5. 　前記準備の失敗を示す準備応答は、前記管理情報に存在するシーケンスＩＤに対応付けられている提案ＩＤを含み、
    　前記第１の計算機は、
    　　前記第２の計算機から前記提案ＩＤを含む前記準備の失敗を示す準備応答を受信した場合、その準備応答に含まれていた提案ＩＤよりも大きい提案ＩＤを含む準備要求を前記第２の計算機に送信する
    請求項４に記載の分散コンピューティングシステム。
  6. 　前記第２の計算機は、
    　　前記第１の計算機から受信した前記準備要求内のシーケンスＩＤが前記管理情報に存在し、前記準備要求内の提案ＩＤと前記管理情報に存在するシーケンスＩＤに対応付けられている提案ＩＤとの比較の結果が、前記提案が過去の提案よりも新しいことを表しており、且つ、前記準備要求内の提案ＩＤに対応付けられているメモリ領域ＩＤから特定されるメモリ領域に対する前記提案の書き込みが完了していない場合、前記準備要求内の提案ＩＤに新たなメモリ領域ＩＤを対応付けることにより前記管理情報を更新し、前記準備要求内の提案ＩＤと前記新たなメモリ領域ＩＤとを含む前記準備応答を前記第１の計算機に返信する
    請求項４に記載の分散コンピューティングシステム。
  7. 　前記第２の計算機は、
    　　前記準備要求内の提案ＩＤに対応付けられているメモリ領域ＩＤから特定されるメモリ領域に対する前記提案の書き込みが完了している場合、準備の失敗を示す準備応答を前記第１の計算機に返信する
    請求項６に記載の分散コンピューティングシステム。
  8. 　前記準備の失敗を示す準備応答は、前記メモリ領域に書き込まれている提案を含み、
    　前記第１の計算機は、
    　　前記第２の計算機から前記メモリ領域に書き込まれていた提案を含む前記準備の失敗を示す準備応答を受信した場合、その準備応答に含まれていた提案を含む書込要求を前記複数の第２の計算機の各々に送信する
    請求項７に記載の分散コンピューティングシステム。
  9. 　前記第１の計算機は、
    　　前記提案について合意が形成されたと判定した場合、前記書込成功応答を返信してきた複数の第２の計算機の各々に対して前記提案に対応するシーケンスＩＤ及び提案ＩＤを含む成功通知を送信し、
    　前記第２の計算機は、
    　　前記第１の計算機から前記成功通知を受信した場合、前記メモリ領域に書き込まれている提案を所定の記憶領域に反映する
    請求項３に記載の分散コンピューティングシステム。
  10. 　前記書込要求に含まれる提案の前記メモリ領域ＩＤから特定されるメモリ領域に対する書き込み、及び、前記書込成功応答の返信は、ＲＤＭＡ（Ｒｅｍｏｔｅ　Ｄｉｒｅｃｔ　Ｍｅｍｏｒｙ　Ａｃｃｅｓｓ）に従う処理である
    請求項１に記載の分散コンピューティングシステム。
  11. 　前記複数の計算機による合意の形成は、ＰＡＸＯＳプロトコルに従う処理である
    請求項２に記載の分散コンピューティングシステム。
  12. 　互いにネットワーク接続された複数の計算機が連携して動作する分散処理方法であって、
    　第１の計算機は、提案の準備の要求であり提案ＩＤを含む準備要求を第２の計算機に送信し、
    　前記第２の計算機は、前記第１の計算機から受信した前記準備要求内の提案ＩＤが、提案ＩＤとメモリ領域ＩＤとの対応関係を表す管理情報に存在しない場合、前記準備要求内の提案ＩＤと新たなメモリ領域ＩＤとを含んだ組を前記管理情報に登録し、前記準備要求内の提案ＩＤと前記新たなメモリ領域ＩＤとを含む前記準備応答を返信し、
    　前記第１の計算機は、前記準備要求に対する応答でありメモリ領域ＩＤを含む準備応答を前記第２の計算機から受信した場合、前記提案の書き込みの要求であり前記提案と前記準備応答内のメモリ領域ＩＤとを含む書込要求を前記第２の計算機に送信し、
    　前記第２の計算機は、前記第１の計算機から受信した前記書込要求内の前記メモリ領域ＩＤが前記管理情報に存在する場合、そのメモリ領域ＩＤから特定されるメモリ領域に前記受信した書込要求内の提案を書き込み、前記第１の計算機に前記書込成功応答を返信し、
    　前記第１の計算機は、前記書込要求に対する応答であり書込み成功を示す書込成功応答を前記第２の計算機から受信した場合、前記第２の計算機が前記提案に合意したと判定する
    分散処理方法。
     

     
PCT/JP2014/078976 2014-10-30 2014-10-30 分散コンピューティングシステム及び分散処理方法 WO2016067426A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/307,308 US10489340B2 (en) 2014-10-30 2014-10-30 Distributed computing system and distributed processing method
PCT/JP2014/078976 WO2016067426A1 (ja) 2014-10-30 2014-10-30 分散コンピューティングシステム及び分散処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/078976 WO2016067426A1 (ja) 2014-10-30 2014-10-30 分散コンピューティングシステム及び分散処理方法

Publications (1)

Publication Number Publication Date
WO2016067426A1 true WO2016067426A1 (ja) 2016-05-06

Family

ID=55856810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/078976 WO2016067426A1 (ja) 2014-10-30 2014-10-30 分散コンピューティングシステム及び分散処理方法

Country Status (2)

Country Link
US (1) US10489340B2 (ja)
WO (1) WO2016067426A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005196763A (ja) * 2003-12-30 2005-07-21 Microsoft Corp 簡略化されたｐａｘｏｓ
JP2006155614A (ja) * 2004-11-23 2006-06-15 Microsoft Corp 一般化されたＰａｘｏｓ
WO2007063944A1 (ja) * 2005-11-30 2007-06-07 International Business Machines Corporation 無停止トランザクション処理システム
JP2012033108A (ja) * 2010-08-02 2012-02-16 Trytech Co Ltd 分散コンピューティングシステムの処理方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8005888B2 (en) * 2003-12-30 2011-08-23 Microsoft Corporation Conflict fast consensus
US9274863B1 (en) * 2013-03-20 2016-03-01 Google Inc. Latency reduction in distributed computing systems
US10122621B2 (en) * 2016-06-16 2018-11-06 Sap Se Modified consensus protocol for eliminating heartbeat network traffic

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005196763A (ja) * 2003-12-30 2005-07-21 Microsoft Corp 簡略化されたｐａｘｏｓ
JP2006155614A (ja) * 2004-11-23 2006-06-15 Microsoft Corp 一般化されたＰａｘｏｓ
WO2007063944A1 (ja) * 2005-11-30 2007-06-07 International Business Machines Corporation 無停止トランザクション処理システム
JP2012033108A (ja) * 2010-08-02 2012-02-16 Trytech Co Ltd 分散コンピューティングシステムの処理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LESLIE LAMPORT: "Paxos Made Simple", Retrieved from the Internet <URL:http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf> [retrieved on 20140114] *
LESLIE LAMPORT: "The Part-Time Parliament", May 1998 (1998-05-01), Retrieved from the Internet <URL:http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf> [retrieved on 20140114] *

Also Published As

Publication number Publication date
US20170046305A1 (en) 2017-02-16
US10489340B2 (en) 2019-11-26

Similar Documents

Publication Publication Date Title
US9923967B2 (en) Storage management system for preserving consistency of remote copy data
US20200241613A1 (en) Persistent reservations for virtual disk using multiple targets
US10664495B2 (en) System and method for supporting data grid snapshot and federation
CN107771321B (zh) 数据中心中的恢复
US11593016B2 (en) Serializing execution of replication operations
US9215278B2 (en) Interconnect delivery process
US11256582B2 (en) System, and control method and program for input/output requests for storage systems
US8140791B1 (en) Techniques for backing up distributed data
EP0935375A1 (en) Name service for a highly configurable multi-node processing system
EP0935374A1 (en) Dynamic and consistent naming of fabric attached storage
JP4309354B2 (ja) ストレージネットワークにおける書き込みオペレーション制御
US11550820B2 (en) System and method for partition-scoped snapshot creation in a distributed data computing environment
US20120246206A1 (en) File server system and storage control method
US8660996B2 (en) Monitoring files in cloud-based networks
US20140059315A1 (en) Computer system, data management method and data management program
CN112307119A (zh) 数据同步方法、装置、设备及存储介质
US8359601B2 (en) Data processing method, cluster system, and data processing program
WO2016067426A1 (ja) 分散コンピューティングシステム及び分散処理方法
JP2010128752A (ja) データベース・システム、サーバ、更新方法およびプログラム
US10938701B2 (en) Efficient heartbeat with remote servers by NAS cluster nodes
US20180227202A1 (en) Reporting progress of operation executing on unreachable host
JP2017111555A (ja) 配布履歴管理プログラム、配布履歴管理装置および配布履歴管理方法
CN113094337A (zh) 用于对分布式存储系统进行读写的方法和装置
CN116938869A (zh) 经hci管理的arp

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15307308

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14904760

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP