JP2012221101A - Inter-processing part mismatching detection method under consideration of reboot due to failure and shared device and cluster system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve inter-processing part mismatching detection accompanied by reboot with a method of making it unnecessary for a host to manage any telegraphic message identifier or change the telegraphic message identifier for each processing.SOLUTION: In a shared device including a first processing part connected to a first host, a second processing part connected to a second host, and a storage part to be used by the first processing part and the second processing part, the first processing part is configured to, when receiving the transmission request of a first message from the first host, transmit a request to the second processing part, and the second processing part is configured to transmit the message to the second host, and to transmit a reply to the first processing part, and the first processing part is configured to determine whether or not the pertinent reply is the reply corresponding to the transmission request of the first message by collating the boot and reboot frequencies of the first processing part.

Description

  The present invention relates to inconsistency detection between processing units in an apparatus including a plurality of processing units.

  In a large computer system such as a mainframe, a cluster system in which a plurality of hosts are coupled to each other is used to improve scalability and availability.

  In the cluster system, processing is performed while the hosts exchange data, and there is a method for realizing communication between the hosts by performing message communication between the hosts via a shared device having an interface with a plurality of hosts.

  The sharing device used at this time includes a plurality of processing units and a storage unit shared by the processing units. The message communication function here means that a processing unit that has received a message transmission request from a host issues a request to the other processing unit, and the processing unit that has received the request transmits a message to the host. If the transmission is successful, a reply is returned to the original processing unit, and the processing unit that has received the reply returns a reply to the requesting host.

  Here, consider a case where a processing unit that receives a request from the host reboots due to a failure immediately after issuing a request to the other processing unit, and receives a different transmission request from the host after rebooting. In this case, after issuing a request for this request to the other processing unit, if a reply to the previous request is returned from the other processing unit, there is a problem that this reply is mistaken as a reply to the subsequent request. It was.

  As a method for solving such a problem, for example, it is conceivable to use the technique described in Patent Document 1. In the technique described in Patent Literature 1, it is possible to identify each process by adding a message identifier for each processing request and referring to the message identifier.

JP 2003-085060 A

  As described above, each process can be identified by using the technique described in Patent Document 1.

  However, in the technique described in Patent Document 1, it is necessary to change the message identifier for each process, and there is a problem that the process associated with the assignment and confirmation of the message identifier becomes complicated.

  Further, the technique described in Patent Document 1 has a problem that each server as a host needs to manage a message identifier. In addition, the technique described in Patent Document 1 does not consider rebooting of the processing unit of the shared apparatus, and there is a problem that mismatch occurs due to passing between the processing units depending on the timing at which the reboot occurs. It was not a direct solution.

  Therefore, in this embodiment, it is possible to detect inconsistencies between processing units associated with rebooting in a method that does not require the host to manage the message identifier and does not need to change the message identifier for each process. Another object of the present invention is to provide a method for detecting inconsistencies between processing units in consideration of reboot due to a failure, a shared apparatus, and a cluster system.

  According to the first aspect of the present invention, the first processing unit connected to the first host, the second processing unit connected to the second host, the first processing unit, and the second processing unit And a storage unit used by the first processing unit, when the first processing unit receives a transmission request for the first message from the first host, the second processing unit A first process that transmits a request, the second processing unit receiving the request transmits the message to the second host, transmits a reply to the first processing unit, and receives the reply. The unit determines whether the reply is a reply according to the transmission request for the first message, and the determination is associated with the request and the reply on the storage unit, respectively. 1 processing unit boot and Sharing apparatus is provided which comprises carrying out by collating the number of reboots.

  According to a second aspect of the present invention, a first processing unit connected to a first host, a second processing unit connected to a second host, the first processing unit and the second In the inconsistency detection method performed by the shared device having a storage unit used by the first processing unit, when the first processing unit receives a transmission request for the first message from the first host, the second processing unit The second processing unit that has received the request transmits the message to the second host, transmits a reply to the first processing unit, and sends the reply to the first processing unit. The received first processing unit determines whether the reply is a reply according to the transmission request for the first message, and the determination corresponds to the request and the reply on the storage unit, respectively. Attached Mismatch detection method characterized in that it is carried out by collating the boot and the number of reboots the processor is provided.

  According to the present invention, a request and a reply can be associated with each other even if a reboot occurs by using the value of the boot counter area in the shared device as a factor, so that the message identifier is not managed in the host. In addition, it is possible to detect inconsistencies between processing units due to rebooting in a method that does not require changing the message identifier for each process.

It is a figure showing the basic composition of the embodiment of the present invention. It is a flowchart showing the basic operation | movement of the boot frequency registration part in embodiment of this invention. It is a flowchart showing the basic operation | movement of the host request | requirement process part in embodiment of this invention. It is a flowchart showing the basic operation | movement of the other process part request | requirement part in embodiment of this invention. It is a flowchart showing the basic operation | movement of the other process part reply process part in embodiment of this invention.

  Next, embodiments of the present invention will be described in detail with reference to the drawings.

  Referring to FIG. 1, the present embodiment includes a shared device 1000, a first host 2000, and a second host 3000.

  In this embodiment, the first host 2000 and the second host 3000 perform processing while exchanging data with each other via the shared apparatus 1000. The exchanged data may be based on any standard or protocol. This embodiment can be implemented in conformity with an arbitrary communication method.

  The shared apparatus 1000 includes a storage unit 110, a first processing unit 120, and a second processing unit 130.

  Further, the first processing unit 120 is directly connected to the first host 2000 but is not directly connected to the second host 3000. Similarly, the second processing unit 130 is directly connected to the second host 3000 but is not directly connected to the first host 2000. Connection with each host can be performed by any method, and there is no particular limitation on the connection method.

  The storage unit 110 is a storage device, and has a plurality of areas depending on the application. Specifically, the storage unit 110 has a boot counter area, a request area, a reply area, and a communication data area. Each of these areas is prepared for each processing unit. Therefore, in the present embodiment, the first boot counter area 111, the first request area 113, the first reply area 115, and the first communication data area 117 are provided as areas for the first processing unit 120. ing. In addition, a second boot counter area 112, a second request area 114, a second reply area 116, and a second communication data area 118 are provided as areas for the second processing unit 130.

  Specific uses of these areas will be described later.

  The first processing unit 120 and the second processing unit 130 have local memories 121 and 131 (referred to as “LM” where appropriate in the following description and drawings).

  In addition, the first processing unit 120 and the second processing unit 130 are, respectively, boot count registration units 122 and 132, host request processing units 123 and 133, other processing unit request processing units 124 and 134, and other processing. Part reply processing parts 125 and 135.

  The boot count registration units 122 and 132 have a function of registering the boot count incremented in the boot counter area of the storage unit 110 when the first processing unit 120 and the second processing unit 130 are booted and when rebooting.

  The host request processing units 123 and 133 have a function of issuing a request to another processing unit when a transmission request is received from a host to which the host request processing unit 123 or 133 is connected.

  When receiving a request from the host request processing unit of the other processing unit, the other processing unit request processing units 124 and 134 transmit a message to the host to which the other processing unit request processing unit 124 is connected, and after successful transmission, the requesting host request processing unit Has a function of returning a response (hereinafter referred to as “reply” as appropriate).

  The other processing unit reply processing units 125 and 135 have a function of returning a reply to the host to which the other processing unit reply processing units 125 and 135 are connected when receiving a reply from the other processing unit request processing unit.

  Next, the operation of each unit of the present embodiment will be described in detail with reference to the flowcharts of FIGS.

  FIG. 2 is a flowchart showing the operation of the boot number registration units 122 and 132. The boot number registration units 122 and 132 operate when a processing unit including the boot number registration unit 122 boots and reboots.

  Referring to FIG. 2, at the time of booting and rebooting, the boot count registration units 122 and 132 read the value of the boot counter area assigned to the own processing unit in the storage unit 110 (step A1).

  Next, the read value is compared with the maximum value that can be taken by the boot counter (step A2). If the two values are equal as a result of the comparison in step A2 (Yes in step A2), 1 is registered in the boot counter area (step A3). That is, the boot counter value after processing is “1”.

  On the other hand, if the two values are not equal as a result of the comparison in step A2 (No in step A2), 1 is added to the value of the current boot counter area (step A4). That is, the boot counter value after processing is “current boot counter value + 1”.

  Thus, the operations of the boot count registration units 122 and 132 are completed.

  FIG. 3 is a flowchart showing the operation of the host request processing units 123 and 133.

  Referring to FIG. 3, the host request processing units 123 and 133 stand by until a communication request from the host is received (No in step B1).

  When the communication request is received (Yes in Step B1), the communication message accompanying the received communication request is stored in the communication data area assigned to the processing unit to which the communication destination host is connected (Step B2).

  Next, the value of the boot counter area assigned to the own processing unit of the storage unit 110 is read (step B3), and the read value is assigned to the processing unit to which the communication destination host of the storage unit 110 is connected. Store in the request area (step B4). Thereafter, the process returns to step B1 again and waits until a communication request from the host is received.

  FIG. 4 is a flowchart showing the operation of the other processing unit request processing units 124 and 134.

  Referring to FIG. 4, the other processing unit request processing units 124 and 134 monitor the value of the request area allocated to the own processing unit of the storage unit 110 (step C1).

  And it waits until a value other than 0 is written in the request area allocated to the self-processing part of the memory | storage part 110 (in step C2 No).

  When a value other than 0 is written (Yes in step C2), the written value is temporarily stored in the LM in the processing unit. Further, the request area is cleared to 0 as the value written in the LM is temporarily saved (step C3).

  Next, the communication message stored in the communication data area assigned to the own processing unit of the storage unit 110 is read (step C4).

  Then, the communication message read in step C4 is transmitted to the host connected to itself (step C5), and the process waits until a response (reply) is received from the host (No in step C6).

  When a response from the host is received (Yes in step C6), the value temporarily stored in the LM from the request area is stored in the reply area of the storage unit 110 allocated to the request source processing unit. (Step C7) Thereafter, the process returns to Step C1 again, and the value of the request area is monitored.

  FIG. 5 is a flowchart showing the operations of the other processing unit reply processing units 125 and 135.

  Referring to FIG. 5, the other processing unit reply processing units 125 and 135 monitor the value of the reply area allocated to the own processing unit of the storage unit 110 (step D1).

  It waits until a value other than 0 is written in the reply area assigned to its own processing unit in the storage unit 110 (No in step D2).

  When a value other than 0 is written (Yes in step C2), the written value is temporarily stored in the LM in the processing unit. Further, as the value written in the LM is temporarily stored, the reply area is cleared to 0 (step D3).

  Next, the temporarily stored value is compared with the value of the boot counter area assigned to the own processing unit of the storage unit 110 (step D4). If the two values are equal as a result of the comparison in step D4 (Yes in step D4), the communication completion is reported to the host connected to itself (step D5). Then, the process returns to step D1.

  On the other hand, if the two values are not equal as a result of the comparison in step D4 (No in step D4), the process returns to step D1 without doing anything. That is, in this case, the completion of communication is not reported to the host connected to itself.

  The above is the operation of each part in the present embodiment.

  Next, the operation of this embodiment will be described in detail with a specific example.

  In this specific example, the case where the first processing unit 120 reboots due to a failure in the middle of processing when performing message communication from the first host 2000 to the second host 3000 is taken as an example. explain. For explanation, it is assumed that the value of the first boot counter area 111 at this time is 1 (step S4).

  The first host 2000 requests the first processing unit 120 for message communication. Then, the host request processing unit 123 of the first processing unit 120 that monitors the communication request from the host recognizes the reception of the request (Yes in Step B1).

  The host request processing unit 123 stores the communication message accompanying the received communication request in the second communication data area 118 assigned to the second processing unit 130 that is a processing unit connected to the communication destination host ( Step B2).

  Next, in order to issue a request to the second processing unit 130, the value of the first boot counter area 111 is read (step B3). Then, the value read in step B3 is stored in the second request area 114 (step B4).

  Next, the other processing unit request unit 134 of the second processing unit 130 monitoring the second request area 114 allocated to itself has a value other than 0 written in the second request area 114 (Yes in step C2).

  The other processing unit request unit 134 temporarily stores the written value in the LM 131, and clears the second request area 114 with 0 (step C3).

  Next, the communication message stored in the second communication data area 118 is read (step C4), the communication message is transmitted to the second host 3000 (step C5), and the response from the second host 3000 is received. Wait (step C6).

  When a response from the second host 3000 is received (Yes in Step C6), the value temporarily stored in the LM 131 from the second request area 114 is stored in the first reply area 115 (Step C7). .

  Next, the other processing unit reply processing unit 125 of the first processing unit 120 monitoring the first reply region 115 assigned to itself has a value other than 0 written in the first reply region 115. When this is recognized (Yes in step D2), the written value is temporarily stored in the LM 121, and the first reply area 115 is cleared to 0 (step D3).

  Next, the value temporarily stored in the LM 121 is compared with the value in the first boot counter area 111 (step D4). Here, since the two values are usually equal (Yes in step D4), a communication completion response is returned to the first host 2000 (step D5).

  Here, it is assumed that the first processing unit 120 reboots immediately after issuing a request to the second processing unit 130. At this time, in the first processing unit 120, the value of the first boot counter area 111 is updated to 2 by the boot count registration unit 122 immediately after rebooting (Yes in steps A1 and A2 and A3).

  In this state, when a reply is received from the second processing unit 130, in the process of comparing the value temporarily stored in the LM 121 with the value of the first boot counter area 111 (step D4), the temporarily stored value is Although the value is 1 before rebooting, the value in the first boot counter area 111 is 2 after rebooting, so the comparison does not match (No in step D4), and communication with the first host 2000 is completed. No response is made.

  The embodiment of the present invention described above has many effects as described below.

  The first effect is that the normal end of communication between processing units can be confirmed with certainty.

  The reason is that the request and reply can be associated even if a reboot occurs by using the value of the boot counter area as a factor. There is a difference between the request and reply correspondence only when a reboot occurs.

  The second effect is that the processing is light.

  The reason is that once the value of the boot counter area, which is a request factor, is incremented once in the boot process (including the reboot process), it is not necessary to increment the value until a reboot occurs thereafter. Compared to the method of incrementing the request factor for each communication issuance, the same effect can be obtained with less processing.

  The sharing apparatus according to the embodiment of the present invention can be realized by hardware, but the computer reads a program for causing the computer to function as the sharing apparatus from a computer-readable recording medium and executes the program. Can also be realized.

  Further, the inconsistency detection method according to the embodiment of the present invention can be realized by hardware, but the computer reads a program for causing the computer to execute the method from a computer-readable recording medium and executes the program. Can also be realized.

  Moreover, although the above-described embodiment is a preferred embodiment of the present invention, the scope of the present invention is not limited only to the above-described embodiment, and various modifications are made without departing from the gist of the present invention. Implementation in the form is possible.

  In addition, the present embodiment has advantageous effects in the following points as compared with general techniques.

  In general technology, the message identifier is changed for each processing request. However, in the present embodiment, the identifier (number of boots) is not changed for each processing request and is different. That is, in this embodiment, it is incremented only when the device is (re) booted, and the load can be reduced by minimizing the update of the identifier.

  In general technology, for example, the number of boots is used to limit the number of boots of each boot device. On the other hand, this embodiment has an effect that the number of boots can be used in order to prevent passing of communication between the processing units.

  A part or all of the above-described embodiment can be described as in the following supplementary notes, but is not limited thereto.

(Supplementary Note 1) A first processing unit connected to the first host, a second processing unit connected to the second host, and a memory used by the first processing unit and the second processing unit A sharing device having
When the first processing unit receives a transmission request for the first message from the first host, the second processing unit transmits a request to the second processing unit and receives the request. Transmits the message to the second host and transmits a reply to the first processing unit, and the first processing unit that receives the reply responds to the transmission request for the first message. Determine if it ’s a reply,
The determination is performed by comparing the number of boots and reboots of the first processing unit associated with the request and the reply on the storage unit, respectively.

(Supplementary Note 2) In the sharing device according to Supplementary Note 1,
In the determination, if the number of times of booting and rebooting of the first processing unit respectively associated with the request and the reply matches, it is determined that the reply is valid and the first A sharing apparatus, characterized in that if a reply process is not performed for the host, the reply is judged to be invalid and the reply is discarded.

(Supplementary Note 3) In the sharing apparatus according to Supplementary Note 1 or 2,
When the first processing unit transmits the request, the first processing unit records its own boot and reboot times in the storage unit, and the second processing unit receives the request and records the recorded boot and reboot times. And the second processing unit transmits the reply and records the number of boots and reboots stored by the second processing unit in the storage unit, and the first processing unit stores the memory A sharing apparatus that performs the determination by comparing the number of times of booting and rebooting recorded in a storage unit with the number of times of booting and rebooting recorded in the storage unit by the second processing unit.

(Appendix 4) In the sharing device according to any one of appendices 1 to 3,
The sharing apparatus, wherein the first processing unit also operates as a second processing unit, and the second processing unit also operates as a first processing unit.

(Supplementary Note 5) A first processing unit connected to the first host, a second processing unit connected to the second host, and a memory used by the first processing unit and the second processing unit And a cluster system including the first host and the second host connected to the shared device,
The first host and the second host communicate via the shared device;
The cluster system, wherein the shared device is the shared device according to any one of appendices 1 to 4.

(Supplementary Note 6) A first processing unit connected to the first host, a second processing unit connected to the second host, and a memory used by the first processing unit and the second processing unit Inconsistency detection method performed by a shared device having
When the first processing unit receives a transmission request for the first message from the first host, the second processing unit transmits a request to the second processing unit and receives the request. Transmits the message to the second host and transmits a reply to the first processing unit, and the first processing unit that receives the reply responds to the transmission request for the first message. Determine if it ’s a reply,
The determination is performed by comparing the number of boots and reboots of the first processing unit associated with the request and the reply on the storage unit, respectively. .

(Appendix 7) In the inconsistency detection method described in Appendix 6,
In the determination, if the number of times of booting and rebooting of the first processing unit respectively associated with the request and the reply matches, it is determined that the reply is valid and the first A mismatch detection method characterized in that if a reply process is not performed for a host in step S3, the reply is judged to be invalid and the reply is discarded.

(Supplementary note 8) In the inconsistency detection method according to supplementary note 6 or 7,
When the first processing unit transmits the request, the first processing unit records its boot and reboot times in the storage unit, and the second processing unit receives the request and records the recorded boot and reboot times. Read and store itself, the second processing unit transmits the reply and records the number of boots and reboots stored by the second processing unit in the storage unit, and the first processing unit stores itself in the storage unit. A mismatch detection method, wherein the determination is performed by comparing the recorded number of boots and reboots with the number of boots and reboots recorded in the storage unit by the second processing unit.

(Supplementary note 9) In the mismatch detection method according to any one of supplementary notes 6 to 8,
The mismatch detection method, wherein the first processing unit also operates as a second processing unit, and the second processing unit also operates as a first processing unit.

(Supplementary Note 10) A first processing unit connected to the first host, a second processing unit connected to the second host, and a memory used by the first processing unit and the second processing unit Inconsistency detection performed by the cluster system including the first host and the second host connected to the shared device and the shared device,
The first host and the second host communicate via the shared device;
9. The inconsistency detection method, wherein the sharing apparatus performs the inconsistency detection method according to any one of appendices 6 to 8.

  The present invention is suitable for communication between hosts in a cluster system in which a plurality of hosts are connected in a large computer system such as a mainframe.

110 storage unit 111 first boot counter area 112 second boot counter area 113 first request area 114 second request area 115 first reply area 116 second reply area 117 first communication data area 118 first Second communication data area 120 First processing unit 121, 131 Local memory 122, 132 Boot count registration unit 123, 133 Host request processing unit 124, 134 Other processing unit request processing unit 125, 135 Other processing unit reply processing unit 130 Two processing units 1000 Shared device 2000 First host 3000 Second host

Claims (10)

A first processing unit connected to the first host; a second processing unit connected to the second host; and a storage unit used by the first processing unit and the second processing unit. In a shared device having
When the first processing unit receives a transmission request for the first message from the first host, the second processing unit transmits a request to the second processing unit and receives the request. Transmits the message to the second host and transmits a reply to the first processing unit, and the first processing unit that receives the reply responds to the transmission request for the first message. Determine if it ’s a reply,
The determination is performed by comparing the number of boots and reboots of the first processing unit associated with the request and the reply on the storage unit, respectively. The sharing apparatus according to claim 1,
In the determination, if the number of times of booting and rebooting of the first processing unit respectively associated with the request and the reply matches, it is determined that the reply is valid and the first A sharing apparatus, characterized in that if a reply process is not performed for the host, the reply is judged to be invalid and the reply is discarded. The sharing apparatus according to claim 1 or 2,
When the first processing unit transmits the request, the first processing unit records its own boot and reboot times in the storage unit, and the second processing unit receives the request and records the recorded boot and reboot times. And the second processing unit transmits the reply and records the number of boots and reboots stored by the second processing unit in the storage unit, and the first processing unit stores the memory A sharing apparatus that performs the determination by comparing the number of times of booting and rebooting recorded in a storage unit with the number of times of booting and rebooting recorded in the storage unit by the second processing unit. The sharing apparatus according to any one of claims 1 to 3,
The sharing apparatus, wherein the first processing unit also operates as a second processing unit, and the second processing unit also operates as a first processing unit. A first processing unit connected to the first host; a second processing unit connected to the second host; and a storage unit used by the first processing unit and the second processing unit. A cluster system including the shared device and the first host and the second host connected to the shared device,
The first host and the second host communicate via the shared device;
The cluster system according to claim 1, wherein the shared device is the shared device according to claim 1. A first processing unit connected to the first host; a second processing unit connected to the second host; and a storage unit used by the first processing unit and the second processing unit. Inconsistency detection method performed by a shared device having
When the first processing unit receives a transmission request for the first message from the first host, the second processing unit transmits a request to the second processing unit and receives the request. Transmits the message to the second host and transmits a reply to the first processing unit, and the first processing unit that receives the reply responds to the transmission request for the first message. Determine if it ’s a reply,
The determination is performed by comparing the number of boots and reboots of the first processing unit associated with the request and the reply on the storage unit, respectively. . The inconsistency detection method according to claim 6,
In the determination, if the number of times of booting and rebooting of the first processing unit respectively associated with the request and the reply matches, it is determined that the reply is valid and the first A mismatch detection method characterized in that when a reply process is not performed for a host in step S3, the reply is judged to be invalid and the reply is discarded. The inconsistency detection method according to claim 6 or 7,
When the first processing unit transmits the request, the first processing unit records its own boot and reboot times in the storage unit, and the second processing unit receives the request and records the recorded boot and reboot times. And the second processing unit transmits the reply and records the number of boots and reboots stored by the second processing unit in the storage unit, and the first processing unit stores the memory A mismatch detection method, wherein the determination is performed by comparing the number of boots and reboots recorded in a storage unit with the number of boots and reboots recorded in the storage unit by the second processing unit. The mismatch detection method according to any one of claims 6 to 8,
The mismatch detection method, wherein the first processing unit also operates as a second processing unit, and the second processing unit also operates as a first processing unit. A first processing unit connected to the first host; a second processing unit connected to the second host; and a storage unit used by the first processing unit and the second processing unit. Inconsistency detection performed by the cluster system including the shared device and the first host and the second host connected to the shared device,
The first host and the second host communicate via the shared device;
The inconsistency detection method according to claim 6, wherein the sharing apparatus performs the inconsistency detection method according to claim 6.

Images