JP3942216B2 - System monitoring / control method and system monitoring / control apparatus using dual monitoring / controlling processor - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
  In a medium-sized or larger computer system, a monitoring / control processor that is responsible for monitoring, control, and maintenance functions of the system such as the environment, equipment, and power supply is usually provided independently of the main processor (hereinafter referred to as “required”). (Referred to as SCF: System Control Facility).
  The present invention relates to a computer system having dual monitoring / controlling processors in the same system, and in particular, the present invention relates to a system monitoring / controlling method using dual monitoring / controlling processors.And system monitoring and control equipment(Hereinafter, communication between the redundant monitoring / controlling processors will be referred to as inter-SCF communication or SCFLlink as necessary).
[0002]
[Prior art]
Conventionally, computer systems with duplicated resources are known. However, in these systems, there is only one SCF, so when the SCF itself fails, the system becomes inoperable (system down). .
Attempts have also been made to duplicate the SCF itself, but even when the SCF is duplicated, communication between the two SCFs has not been possible in the past, so it is difficult to guarantee exclusive control of common resources or to guarantee operation when one system resource fails. Met.
[0003]
[Problems to be solved by the invention]
By duplicating various resources in the same system, it is possible to realize a highly reliable system that enables no down and north top as a system.
However, when resources are duplicated, each resource must be monitored / controlled by the SCF to realize the operation of one system, and for common resources, control between the SCFs does not compete. It is necessary to perform exclusive control, and it is necessary to constantly monitor and grasp the status of other systems.
[0004]
The present invention has been made in view of the above circumstances, and the first object of the present invention is to make the processing between the two SCFs consistent by enabling communication processing between the duplexed SCFs. In addition, it is possible to quickly carry out appropriate processing even in the event of a single system failure, and to realize a north top system.
The second object of the present invention is to facilitate exclusive control of common resources, disconnection processing at the time of one system failure, and monitoring takeover of other system resources.
The third object of the present invention is to quickly detect a communication abnormality between both duplexed SCFs so that it can be recognized whether it is a hardware abnormality or a communication abnormality due to non-implementation of another system, as well as detection and reception of a reception error. This is to facilitate the process of notifying other systems when an error occurs and the process of searching for a resend event.
[0005]
A fourth object of the present invention is to allow one-system SCF to be exchanged while the system is operating, and to take over internal information of the operating SCF for the actively inserted SCF. To make it work as if it had been operating in a duplex state.
The fifth object of the present invention is to enable automatic recognition of each other's function levels between both duplexed SCFs, thereby eliminating the need to operate in different functional version numbers and always guaranteeing the operation of the duplex system. It is to be.
A sixth object of the present invention is to enable rapid detection of an abnormality at the time of self-diagnosis of another system and to perform appropriate processing when the self-diagnosis is abnormal.
[0006]
[Means for Solving the Problems]
FIG. 1 shows the principle of the present invention. In the figure, 1 is a main processor, 2 is a bus connecting the main processor and the monitoring / controlling processor, 3a and 3b are monitoring / controlling processors that perform monitoring, control, maintenance, etc., and the monitoring / controlling processor 3a, 3b has the same structure, and the communication means 4 is provided between both systems.
5 is a unique resource monitored and controlled by the monitoring / control processors 3a and 3b, and 6 is a shared resource monitored and controlled by both the monitoring / control processors 3a and 3b.
[0007]
  As shown in FIG. 1, in the present invention, the above-described problem is solved as follows.
(1) A monitoring / control processor for monitoring, controlling, and maintaining a system provided independently of the main processor 1 is duplexed, and the system is monitored and controlled by the duplexed monitoring / control processors 3a and 3b. In the system monitoring / control method of the information processing apparatus for monitoring / controlling the information processing system by the duplicated monitoring / controlling processor, the communication means 4 for performing communication between the monitoring / control processors 3a, 3b is provided. Of the redundant monitoring / controlling processor,When a notification event is received from another monitoring / control processor having the transmission right,A monitoring / control processor acquiring a right to send a notification event; andTo other monitoring / controlling processorsA step of assigning a sequence number to a notification event, and the one monitoring / control processorSaidSending to other monitoring / controlling processor;Notification event to which the sequence number received from the other monitoring / control processor is given when a retransmission request is made from the other monitoring / control processor due to the occurrence of a reception error using the sequence number Retransmitting to the other monitoring / controlling processorIs provided.
[0008]
(2) In the above (1), the method further includes the step of abandoning the right to transmit the notification event, wherein the step includes a step in which the one monitoring / control processor that has acquired the right to transmit the notification event has received a predetermined time from When a retention time timeout occurs due to the elapse of time, the notification event transmission right is abandoned by transmitting a notification event to another monitoring / control processor.
(3)the above(2), The one monitoring / controlling processor includes:From other monitoring / controlling processor with transmission rightsThe step of acquiring the transmission right of the notification event includes the transmission right in one monitoring / control processor that does not have the transmission right.AbandonmentWhen a time-out of acquisition time occurs after a certain period of time elapses, the one monitoring / control processor acquires the right to transmit a notification event.
[0009]
(4)the above(3) Further includes a step of performing an error determination, and when the time-out of the acquisition time occurs,With other monitoring / controlling processorsAnd determining that an error has occurred in the one monitoring / controlling processor that has acquired the transmission right.
(5In the system monitoring / controlling apparatus of the information processing apparatus, a dual monitoring / control processor provided independently of the main processor for monitoring, controlling or maintaining the information processing system, and the dual monitoring / controlling apparatus Communication means for communicating notification events between control processors;HaveOne supervisory / control processor of the dual supervisory / control processors is:When a notification event is received from another monitoring / control processor that has the transmission rightThe right to send notification events,Assign a sequence number to the notification event to other monitoring / control processors,Sending a notification event with a sequence number to another monitoring / control processor;Notification event to which the sequence number received from the other monitoring / control processor is given when a retransmission request is made from the other monitoring / control processor due to the occurrence of a reception error using the sequence number Is resent to the other monitoring / controlling processor.
[0010]
(6)the above(5)Each redundant monitor / control processorOne monitoring / control processor that has a transmission right holding timer and has acquired the right to transmit a notification eventInTransmission right holding timerButWhen a time-out occurs after a certain period of time has elapsed since acquisition of the transmission right, the transmission right of the notification event is abandoned by transmitting a notification event to another monitoring / control processor.
[0011]
(7)the above(6), The redundant monitoring / controlling processor isEach has a transmission right acquisition timer,One monitoring / control processor without transmission rightsInOf the transmission rightAbandonmentThe transmission right acquisition timer after a predetermined time fromInWhen a time-out occurs, the right to transmit a notification event is granted to the one monitoring / control processor.
[0012]
(8) In the above (7), each of the duplicated monitoring / controlling processors, when a timeout occurs in the transmission right acquisition timer,With other monitoring / controlling processorsJudge that an error has occurred.
[0013]
  As aboveIn the present invention,It is possible to perform the same operation on the main processor while grasping each other's state, and it is possible to cause the redundant monitoring / controlling processor to perform one operation as a whole.
  In addition, when a one-system abnormality occurs, it is possible to quickly detect this and continue appropriate processing (control with a normal system so that the system does not go down).
  Further, all the transmitted / received events can be managed by the sequence number, and the transmitting side can easily store the transmitted event and extract the retransmitted event at the time of the retransmission request.
  Further, the receiving side can detect the unreceived event by the sequence check in units of events, and the retransmission request to the transmitting side only needs to be notified of the sequence number in which an error has occurred, and the processing is simplified.
[0014]
  In addition, the event ( alive message) Can be known from the timer timeout, and it is possible to know that some abnormality has occurred in the other system due to the timeout.
In addition, the above event ( alive message) By using the function that either one of the transmission rights has, it is possible to perform exclusive control such as access rights to common resources.
  Also,All communication abnormalities can be detected on the receiving side, and the cause of the communication abnormality can be predicted by the detection mechanism, and appropriate processing can be performed for the communication abnormality.
  Further, when a communication abnormality occurs, this is detected promptly and appropriate processing is performed, so that the operation of the system can be guaranteed even when a communication abnormality occurs.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 2 is a diagram illustrating a system configuration and monitoring resources according to the embodiment of this invention. In the figure, 10 is a main processor, 12 and 13 are duplexed SCFs (SCFs 12 and 13 are respectively referred to as #A system SCF 12 and #B system SCF 13), and #A system and #B system SCFs 12 and 13 are It has the same configuration.
The main processor 10 and each of the SCFs 12 and 13 are connected by an SC bus (SCF and main processor communication line) 11.
Reference numeral 14 denotes a signal line (SCFLlink) for hardware connection between the SCFs 12 and 13, which is connected to an inter-SCF communication register as will be described later.
15 is an RS232C interface, 16 is an external uninterruptible power supply (external UPS), 17 is external equipment, EPC is an external power control interface, 18 is an expansion device, RCI is an expansion device control interface, 19 is an expansion device power supply, and EDPCI is an expansion An apparatus power control interface, 20 is a temperature sensor, and 21 is a fan.
Also, 22 is an operator operation panel, 23 is a sub power supply unit (PSU), 24 is a built-in uninterruptible power supply unit (UPS), and 25 is a main power supply unit (PDU).
[0019]
As shown in FIG. 2, duplicated monitoring resources are connected to each of the SCFs 12 and 13, but the external uninterruptible power supply (external UPS) 16, the extended enclosure control interface RCI, the temperature sensor 20, etc. are unique resources. It is.
The main power supply (PDU) 25, the built-in uninterruptible power supply (UPS) 24, the fan 21, the operator operation panel 22 and the like are shared resources and can be monitored from both systems.
Each of the SCFs 12 and 13 is connected to the main processor via the SC bus 11 as described above, but the event of the resource monitored by both systems needs to be notified only once from either system. Further, even in the event of the resource in charge of notification of another system, for example, when any SC bus is disconnected, a replacement notification can be performed from a normal system.
[0020]
Next, the configuration and operation of each part of the embodiment of the present invention will be described.
(1) SCF communication
FIG. 3 is a diagram showing a schematic configuration of inter-SCF communication according to the embodiment of the present invention. In the figure, 10 is a main processor, 11 is an SC bus, and 12 and 13 are duplexed SCF boards.
The #A system SCF boat 12 and the #B system SCF board 13 include inter-SCF communication registers 12a and 13a, respectively, for inter-SCF communication. The inter-SCF communication registers 12a and 13a are connected to the reception register ECOMR1. It consists of a transmission register ECOMR2.
The reception register ECOMR1 of the #A system SCF board 12 and the transmission register ECOMR2 of the #B system SCF board 13 are connected by a signal line 14 for serial transfer in hardware, and the reception of the #B system SCF board 12 is performed. The register ECOMR1 for transmission and the transmission register ECOMR2 of the #A system SCF board 12 are connected by a similar signal line 14, and when data is written to the transmission register ECOMR2, it is transmitted to the SCF of another system, and the reception register ECOMR1 The above data is written in
Reference numerals 12b and 13b denote SCF firmware that performs transmission / reception processing, and reference numerals 12c and 13c denote SCF control CPUs.
[0021]
FIG. 4 is a diagram showing a configuration of reception and transmission registers ECOMR1 and ECOMR2 in the inter-SCF communication registers 12a and 13a.
As shown in the figure, the reception and transmission registers ECOMR1 and ECOMR2 have a 16-bit configuration, the lower 9 bits (FCR, ECOND) are used as a common data area, and the bit 15 (INT) is used as an interrupt.
When 1 is set in the INT bit of the transmission register ECOMR2, 1 is set in the INT bit of the reception register ECOMR1 of the other system, and an interrupt is notified to the SCF control CPU of the system.
Bit 14 (PERR) is set to 1 when the parity is abnormal.
That is, 1-bit parity is added to the 16-bit register by hardware, a parity check is performed by hardware at the time of reception, and 1 is set to bit 14 (PERR) when the parity is abnormal.
[0022]
3 and 4, when a notification event to the other system occurs, the SCF firmware 12b or 13b on the transmission side writes the notification data to the transmission register ECOMR2 and sets 1 to the INT bit.
This data is transmitted to the SCF on the receiving side via the signal line 14 and is written in the receiving register ECOMR1.
When 1 is written to the INT bit of the reception register ECOMR1, an interrupt is raised to the SCF control CPU, and the interrupt handler of the SCF firmware 12b or 13b activated from the CPU reads the reception register ECOMR1 to realize inter-SCF communication. The
[0023]
FIG. 5 is a diagram showing a method for accessing the inter-SCF communication register.
As shown in the figure, the inter-SCF communication registers 12a and 13a of this embodiment can only perform READ / WRITE for each byte.
Therefore, in order to be able to transmit and receive a plurality of bytes, data transmission is performed by a command method, and the data length to be transmitted is defined in advance for each command. In addition, since the transmission data length at the time of occurrence of the notification event is indefinite, a command is always added at the beginning and end of the transmission data of one packet, and transmission is performed byte by byte.
FIG. 6 is a diagram for explaining how to use the inter-SCF communication registers 12a and 13a. As shown in FIG. 6, when transmission data is a command, INT of bit 15 and FCR of bit 8 of the transmission register ECOMR2 are set. Each is set to 1, the command type is set in the upper 4 bits of ECOND of 0 to 7 bits, and the detail code is set in the lower 4 bits.
When the transmission data is data, INT of bit 15 of ECOMR2 is set to 1, FCR of bit 8 is set to 0, and data is set to ECOND of 0 to 7 bits.
[0024]
FIG. 7 is a diagram showing a command-by-command transmission format. As shown in FIG. 7, commands include the following and have the following formats.
▲ 1 “Phase notification”
It is a command transmitted during self-diagnosis, and the detailed code is a phase number indicating the self-diagnosis phase.
▲ 2 “Self-diagnosis error notification”
This command is notified when a self-diagnosis error occurs, and the detailed code is a command sequence number (described later). The transmission data is a log code and a display code for an upper stage and a lower stage of a liquid crystal display device (hereinafter referred to as LCD) provided on the operator operation panel 22.
▲ 3 ▼ "Function version notification"
A command for notifying the function level of the SCF (hereinafter referred to as function version number), “initial notification” and “deactivation notification” for notifying that the SCF is inactive (the SCF is not in operation), There is an “activation response” that is notified when the SCF is in an active state, and the type is notified by a detailed code. The transmission data is the function version of the own system.
[0025]
▲ 4 ▼ “alive message”
By exchanging a predetermined notification event (this notification event is hereinafter referred to as an alive message) between the two SCFs at regular intervals, the status of the other system can always be monitored (the exchange of the alive message will be described later). To do).
“Alive message” in FIG. 7 is a command for notifying the above-mentioned alive message, and includes “normal communication” and “when transmission is abnormal”, and the detailed code is a sequence number.
▲ 5 ▼ “Resend request”
This is a command for requesting retransmission when a reception error occurs, and the detailed code is the sequence number where the error was detected.
▲ 6 ▼ “Data start”
This is a command indicating the start of data, the detailed code is a sequence number, and the transmission data is transmission data + end code.
▲ 7 ▼ “End of data”
This is a command indicating the end of transmission data, the detail code is the transmission data length, and the transmission data is the sum data of the transmitted data.
[0026]
In FIG. 5, transmission is performed as follows.
(a) Transmission is always in 1-byte units, and when the SCF on the sending side writes 1 byte and then writes data continuously, without confirming that the other party has read it, leave an interval of a certain time or more. The data is written (overrun check that writes the next data before the other system reads it is performed on the receiving side).
(b) When one interruption occurs, the receiving side reads the receiving register ECOMR1 once to read notification data from another system.
(c) If alive message notification or notification event occurs during multi-byte data transmission, wait until all data transmission in progress is completed before transmitting.
(d) However, when transmitting a retransmission request at the time of reception error, the retransmission request is interrupted between the data being transmitted without waiting for the completion of transmission of the multi-byte data.
[0027]
FIG. 8 is a diagram showing a transmission sequence when a notification event occurs. As shown in FIG. 8, when a notification event occurs, a data start command is transmitted and then data is transmitted from the first byte to the last byte. On the receiving side, the received data is stored.
When the data end command is notified, the receiving side compares the data length data sent by the end command with the actually received data length.
Further, when sum data that is the sum of all transmission data of one packet is transmitted from the transmission side, sum check is performed.
[0028]
FIG. 9 is a diagram showing processing when a notification event occurs during transmission of a plurality of bytes.
As shown in the figure, when the notification event A occurs and the data of the notification event A is transmitted and the data up to the nth byte is transmitted, even if the notification event B such as an alive message occurs, this data is awaiting transmission. . On the other hand, if a notification event C due to a retransmission request occurs during transmission of the notification event A, the retransmission request is immediately transmitted, and error processing (retransmission processing) is performed on the receiving side. Then, after the transmission of the notification event A is completed, the notification event B that has been waiting for transmission is transmitted.
[0029]
FIG. 10 is a diagram showing a sequence check process in the inter-SCF communication.
When performing inter-SCF communication, a notification event is assigned with a sequence number and transmitted, and the transmission side and reception side use the sequence number to detect an unreceived error and to perform retransmission processing when a reception error occurs. The SCF also includes a transmission event management table that stores a certain number of transmitted events and sequence numbers, and manages the transmission history using the table.
[0030]
That is, data transmission is performed as shown in FIG.
(a) When a notification event (occurrence event, alive message) is transmitted, a series of sequence numbers (0 to n) is assigned to each notification event and transmitted to the SCF of another system together with the notification event (sequence number) If n exceeds n, it is reset to 0).
(b) The transmission side stores a certain number of transmitted events and sequence numbers as transmission history in the management table (for example, n + 1 old data is discarded).
The transmitted event and the sequence number are necessary at the time of retransmission request. When a sequence error occurs and a sequence number is added and a retransmission request is made, the event is extracted from the management table and retransmitted. Also, when retransmitting, a new sequence number is assigned and transmitted.
(c) The receiving side stores the latest value of the received sequence number. This is necessary to detect a reception error from the received sequence number and the received sequence number. If the received sequence number is not the last received sequence number + 1, the [previous received sequence number + 1] to the [current received sequence number + 1]. Request up to another system as a non-reception error up to reception sequence number-1].
[0031]
For example, as shown in FIG. 10, the notification event B (sequence number No. 3) has not been received, and the sequence number No. No. 2 notification event A, sequence number No. 4 notification event C is received, the sequence number no. No. 3 ([No. 2 + 1] = No. 3 to [No. 4-1] = No. 3) is received, and a retransmission request is made.
On the transmission side, when there is a retransmission request, the corresponding event (notification event B) is extracted from the transmission target management table, and a new sequence number No. 5 is retransmitted.
[0032]
(2) Status monitoring by alive message
As described above, by using the above-described inter-SCF communication function, by exchanging a predetermined notification event (this notification event is referred to as an alive message) between the two system SCFs at regular intervals, the status of the other system is always changed. It becomes possible to monitor.
In other words, if you send a alive message to another system, the system keeps the alive message for a certain period of time and then sends it again to the own system. If not, it is possible to determine that an abnormality has occurred in the other system.
[0033]
Specifically, the alive message transmission right (right to send the alive message next while the alive message is being held) is always granted in either system, and the alive message transmission right is set to other. When the alive message is received from the system or when the alive message acquisition timer for a certain time (m) times out, it is acquired.
Further, the system that has acquired the alive message sets a holding timer for a fixed time (n), and when the holding timer times out, transmits the alive message to another system and abandons the transmission right.
By doing so, one of the systems always has the right to send an alive message at normal times. When the alive message transmission right is acquired by the timeout of the acquisition timer, it is determined that some kind of abnormality has occurred in which the other system cannot notify the alive message.
[0034]
11, 12, and 13 are diagrams for explaining the above-described alive message exchange control. FIG. 11 illustrates normal alive message exchange control, FIG. 12 illustrates alive message exchange control when a path is abnormal, and FIG. 13. Indicates the case of non-implementation or hang-up of another system.
In FIG. 11, in the #A system, when the holding timer times out, the alive message is transmitted to the #B system, and the transmission right of the alive message is abandoned. At the same time, an acquisition timer is set to start the operation.
In the #B system, when the alive message is received, the operation of the acquisition timer is stopped, the holding timer is set, and the operation is started.
In the #B system, when the hold timer times out, the alive message is transmitted to the #A system, and the transmission right of the alive message is abandoned. At the same time, an acquisition timer is set to start the operation.
[0035]
In the above alive message exchange control, when an abnormality occurs in the communication path, it is as shown in FIG.
When both systems exchange alive messages with each other, as shown in the figure, if a path error occurs when #A system sends alive message to #B system, alive message is not received in #B system Therefore, the acquisition timer times out and the transmission right is acquired. Then, a holding timer is set, and when the holding timer times out, an alive message is transmitted to the #A system to abandon the transmission right, and an acquisition timer is set to start the operation.
Next, if the alive message from the #A system is not received again by the #B system due to a path abnormality, the #B system acquisition timer times out and the #B system acquires the transmission right as described above.
[0036]
In the example of the one-system communication path abnormality in FIG. 12, the other system is operating, but the alive message transmission right does not overlap, so that exclusive control of the shared resource described later is continued without any problem.
Further, in the above alive message exchange control, when an SCF of another system is not installed or is hung up (stopped), the result is as shown in FIG.
That is, when the alive message is exchanged between the #A system and the #B system, as shown in FIG. 13, the #A system SCF board is removed and becomes unmounted, or the #A system SCF is not installed. In the case of hang-up, as in FIG. 12, the alive message is not received in the #B system, so the acquisition timer times out and the transmission right is acquired. Then, a holding timer is set, and when the holding timer times out, an alive message is transmitted to the #A system to abandon the transmission right, and an acquisition timer is set to start the operation.
Next, if the alive message from the #A system is not received again by the #B system due to a path abnormality, the #B system acquisition timer times out and the #B system acquires the transmission right as described above.
[0037]
As described above, when the #B system acquires the alive message transmission right due to the timeout of the acquisition timer, it can be determined that some abnormality that the #A system cannot notify the alive message has occurred.
Note that the sequence error described above cannot be detected unless a notification event occurs, but even if a notification event does not occur by periodically exchanging alive messages with sequence numbers as described above, Communication abnormality can be detected without problems.
[0038]
(3) Communication error detection, cause isolation, and communication error processing
(I) Definition and cause of communication error
A certain abnormality is detected, and a state where the SCF link is not functioning normally is defined as a communication abnormality.
When the SCF state is viewed from the entire system including the normal time, there are four patterns as shown in FIG.
In FIG. 14, when attention is paid to one-system SCF (#A system), it can be seen that a communication error (patterns 3 and 4 in the figure) occurs when an event from the other party cannot be received.
Here, even if the transmission is normal or abnormal, the processing of the sending system will not change, so the communication error will cause the communication error of the other party, but the own system will not be a communication error .
Also, according to this definition, the cause of a communication error can be broadly divided into a case where the communication path is abnormal (hardware error), a case where another system stops (hangs up), and a case where another system is not installed. There are three possible ways.
[0039]
(Ii) Communication error detection method
As described in (i) above, the receiving side can detect a communication error because it cannot receive normally, but the transmitting side cannot detect whether the other side has received normally. Also, even if it is detected, there is no guarantee that it can be notified to the other party because it is a communication error.
From the above, it is assumed that the communication abnormality is detected on the reception side, and no check is performed on the transmission side.
In this embodiment, as shown in FIG. 15, a communication abnormality is detected by three detection mechanisms. Communication abnormalities for all of the following causes can be detected on the receiving side.
[0040]
(a) Reception error occurred
The occurrence of a reception error can be detected by a parity check, a reception data length check, a reception data sum check, and a sequence check, as will be described later. The cause of the abnormality is a hardware abnormality (communication path abnormality or the like).
(b) alive message acquisition timeout
As described in (2) above, it is possible to detect that some abnormality has occurred due to alive message exchange control.
In this case, the cause of the abnormality is a hardware abnormality (communication path disconnection or the like), another system SCF not mounted, or another system SCF hang-up (stop).
(c) Error factor detection
As other abnormal factors, there are other system SCF non-installation detection, other system SCF stop notification reception, and other system self-diagnosis recognition, as will be described later.
These abnormal factors are when other system SCF is not installed, other system SCF hang-up, other system SCF active exchange (exchange of other system SCF during system operation), and other system self-diagnosis are in progress.
[0041]
(Iii) Receive error detection
The detection of the reception error will be described in detail.
The SCF firmware 12b, 13b includes the following check mechanisms. Each check mechanism detects a reception error. When a reception error is detected, error notification (retransmission request), reply processing (determination of a reception error sequence number) is performed. Is performed as follows.
(a) Parity error detection
If the parity error bit detected by the hardware is ON when reading the reception register ECOMR1, a parity error is assumed.
When a parity error is detected, the received data and the received data are discarded and set to the unreceived state. At this time, no retransmission request is made. This is because a reception error can be detected when the next command is received.
Also, after detecting a parity error, all received data is discarded until the next command is received. When a command is received, a reception error (data length mismatch or sequence error) occurs and a retransmission request is transmitted.
[0042]
(b) Data length mismatch detection
When sending a notification event, if the data length of the transmission data is sent to the command and sent, and the data length of the data received on the receiving side does not match the data length notified by the command, the received data length does not match. To do.
When a data length mismatch is detected, a retransmission request is transmitted to the transmission side, and received data is discarded. The sequence number for which retransmission is requested is the reception completion sequence number + 1 (the sequence number being received).
[0043]
(c) Sum check error detection
When sending a notification event, calculate the sum value of all the sums of the transmission data and transmit it last, calculate the sum of the data being received on the receiving side, and compare it with the sum value sent last To check the validity of the received data.
When a sum check error is detected, a retransmission request is transmitted to the transmitting side when received, and the received data is discarded. The sequence number for which retransmission is requested is the reception completion sequence number + 1 (the sequence number being received).
[0044]
(d) Sequence error detection
As described above, if the sequence number of the received notification event is not the sequence number + 1 of the previously received notification event, a sequence error is assumed.
If data is received without receiving a start command, the data is discarded and left unreceived. This is because the error can be detected again when the end command or the like is received.
When a sequence error other than the above is detected, a retransmission request on the transmitting side is transmitted at the time of detection. The received data is discarded.
The sequence number for which retransmission is requested is a sequence number that has not been received. That is, as described above, [sequence number +1 received normally until the previous time] to [sequence number -1 normally received this time]. When there are two or more unreceived events, retransmission requests are continuously transmitted.
[0045]
(Iv) Processing when communication is abnormal
When a communication abnormality occurs, the following processing is performed to guarantee system operation in the state where the communication abnormality has occurred.
(a) Processing when a communication error is detected
(1) Notify the main processor 10 of “communication abnormality”.
(2) Output error log to memory.
(3) An abnormality is displayed on the LCD of the operator operation panel 22 and a check lamp is turned on.
(b) Processing during communication error
(1) alive message Exchange control continues as it is.
(2) Transmission processing to other systems continues.
(3) Discard events received from other systems.
(4) Do not notify other systems that a reception error has occurred (resend request not sent).
Each SCF independently notifies the system monitoring event when communication is abnormal. Therefore, when an event occurs in the shared resource only in a communication abnormal state, an error notification may be sent from both systems.
[0046]
(V) Communication error cancellation cause and detection method
When a communication error occurs, if the cause is known to be a hardware error (such as an SCF board error), a process that does not recover the communication error until replacement is necessary.
Also, if the other system is not installed or just hangs up, it must be restored by reset. Therefore, the recovery of the communication abnormality is performed when the following conditions are satisfied for each cause.
[0047]
(a) Recovery from parity error, communication path error, etc.
Due to a hardware error, recover by resetting the own system or completing hot replacement of another system. The above recovery is performed as follows. The SCF active exchange will be described in detail later.
Recognize implementation from other SCF not implemented → Receive phase notification → Receive functional version or alive message → Recover communication error
(b) Restoration of other system SCF hang-up or other system SCF not mounted
The other system is reset and recovered upon completion of self-diagnosis. That is, it recovers as follows.
Phase notification reception → Functional version number or alive message reception → Communication error recovery
[0048]
(4) Detection of other system SCF not installed
In duplex system communication, there is a case where operation with only one SCF (the other system is not mounted) must be performed, such as when one system is actively replaced or when another system SCF fails. In this case, a communication abnormality is detected internally, but it is necessary to determine whether it is a real communication abnormality or an abnormality due to non-implementation of another system.
Therefore, in this embodiment, a mechanism for detecting the mounting / non-mounting state of the other system in hardware and notifying the SCF firmware by ON / OFF of the register bit is realized. The SCF firmware can always grasp the mounting status of the other system by polling the register periodically, and updating the internal flag.
[0049]
Specifically, the non-mounting of the other system SCF is detected as follows.
(a) When other system is not installed from the beginning
Since a communication error is detected due to a continuous timeout of the alive message acquisition timer, at this time, the internal flag (indicating the implementation status of the other system) updated by polling is checked, and the cause of the communication error is the SCF of the other system. Judge whether it is due to unimplemented.
(b) When another system's SCF is removed during operation
By polling the above register, it is possible to detect a case where the SCF of another system has changed from mounting to non-mounting. At this time, a communication abnormality process is performed when the other system SCF is not mounted, and then an alive message is acquired. Prevent abnormal processing even if a continuous timer timeout occurs.
By doing the above, even when the system is started up without other systems installed, or when it is unjustly pulled out during operation, an appropriate message (other systems not installed) is sent to the outside instead of a communication error. You can be notified.
[0050]
(5) Resource monitoring and event notification
Each SCF monitors each resource as follows. When a notification event occurs, the SCF notifies the main processor of the event and also notifies the SCF of another system.
(a) Monitoring of event resources unique to one system and monitoring of events
When an event occurs in a specific resource monitored and controlled by each of the duplicated SCFs, such as the external uninterruptible power supply (external UPS) 16, the extended enclosure control interface RCI, and the temperature sensor 20 shown in FIG. An event is notified to the main processor 10 in the detected system.
In addition, the inter-SCF communication function is used to notify information to the other SCF (in order to make an alternative notification from the other SCF in the event that the detection system cannot notify the main processor 10 of an event).
The system notified from the SCF of the other system holds the event to be notified by the SCF of the other system, and does not perform any particular processing.
As described above, when it is detected that the other system cannot notify the main processor 10 of the event, the suspended event and the newly notified event are notified to the main processor 10 on behalf of the other system. Provide alternative notification.
[0051]
(b) Resource monitoring and event notification that can be monitored by both systems
When an event occurs in a shared resource where each redundant SCF monitors and controls one resource, such as the main power supply (PDU) 25, the built-in uninterruptible power supply (UPS) 24, the fan 21, and the operator operation panel 22, It is possible to detect the same event in both systems.
However, if an event is detected in both systems and notified to the main processor 10, the same event will be notified twice from both systems. In addition, in the case of an abnormality in the detection circuit, if it can be detected only by one system, there is a possibility that a contradiction occurs between the SCFs of both systems.
From the above, regarding the shared resource, when an event is detected, the event is transmitted to the other system using the inter-SCF communication function, and the process is not performed until the same event notification is received from the other system. The notification to the main processor 10 is determined in advance by assigning notifications in advance so that no event is notified twice.
When the other system is in an abnormal state, the other system event notification portion is also processed so that the entire system can be monitored.
[0052]
(6) System control during normal operation and abnormal communication
When the duplex communication is abnormal, the system operation is assured by performing the following system control for normal operation.
(I) Normal operation
(a) Monitoring / notification of specific resources
(1) Each system monitors its own resources.
(2) Notification to the main processor 10 is made when an abnormality of the resource in charge is detected.
(b) Responsible for monitoring / notifying shared resources
(1) The shared resource is always monitored by both systems.
(2) The person in charge of notification is fixed in advance.
(3) Notification to the main processor 10 is made when an abnormality of the resource in charge is detected and the same abnormality is notified from another system.
[0053]
(c) Exclusive control of shared resources (LCD display on operator operation panel 22)
(1) By alive message exchange control, an access right is acquired and accessible only when the user has the alive message transmission right.
For example, in the LCD display of the operator operation panel 22 or the exclusive control of the operation switch, the SCF having the alive message transmission right has the access right.
{Circle around (2)} If an access factor occurs when you do not have the access right (alive message transmission right), wait until you have the next access right.
[0054]
(Ii) Operation when communication is abnormal
(a) Monitoring / notification of specific resources
(1) Each system monitors its own resources.
(2) Notification to the main processor 10 is made when an abnormality of the resource in charge is detected.
(b) Responsible for monitoring / notifying shared resources
(1) The shared resource is always monitored by both systems.
(2) The right to notify the main processor 10 is acquired unconditionally.
(3) When a communication abnormality is detected, the main processor 10 is notified without waiting for an abnormality notification from another system.
[0055]
(c) Exclusive control of shared resources (LCD display on operator operation panel 22)
(1) The alive message exchange control is continued as it is, and it can be accessed only when the user has the alive message transmission right as usual.
Even when communication is abnormal, the access right is not given to either. This is to prevent the common resource from becoming inaccessible from other systems, and 100% exclusive control is possible if communication errors occur only in one system using this method. In addition, even when both systems have a communication error, exclusive control is possible without overlapping access rights of both systems by intentionally shifting the acquisition of the initial (immediately after startup) alive message transmission right in both systems. .
{Circle around (2)} If an access factor occurs when you do not have the access right (alive message transmission right), wait until you have the next access right.
[0056]
(7) SCF activity exchange
A description will be given of SCF active exchange for realizing replacement of a failed SCF or the like in an operating state when one system fails in a duplex system.
In the present embodiment, as described below, individual SCFs can be exchanged while the system is operating, and a north top that does not go down due to an abnormality in one system is realized (this SCF exchange during operation is Active exchange or active insertion).
(a) Recognition of activity exchange
In order to perform hot replacement, first, the maintenance tool issues “other system stop notification” to the normal SCF that is operating. The system that has received the “other system stop notification” recognizes that the other system will be hot-replaced from now on, so that it will not be processed abnormally at this time so that it will not perform any error processing even if an abnormality such as non-installation of the other system is detected. Communication abnormally.
As described above, the operating system SCF that has entered a communication abnormal state takes over the monitoring / notification right of the shared resource that was the monitoring range of the other system, and can continue to operate as a system.
[0057]
(b) Recognition of active exchange (after exchange)
When the SCF is replaced and actively inserted, the inserted system is reset, self-diagnosis is started, and a self-diagnosis phase notification is transmitted to the other system.
When the self-diagnosis is completed, the internal takeover information is notified by the SCF command from the main processor 10, and the online state is set.
On the other hand, the system that was operating due to a communication error is notified that the other system has been reset (active replacement) by receiving the self-diagnosis phase notification from the other system, and the function version number notification after the completion of the self-diagnosis ( The communication abnormal state is canceled by receiving (described later). As a result, system control by the duplexed SCF is resumed, and active exchange during operation is realized.
[0058]
FIG. 16 is a diagram showing the procedure of active exchange, and active exchange is realized as shown in the figure (the following (1) to (11) correspond to the circled numbers in FIG. 16).
(1) From the maintenance tool, notify the normal SCF that the other system will be hot swapped. (→ Issuing other system stop notification)
(2) When the other system receives the stop notification, the monitoring abnormality detection for the other system being stopped / unplugged is suppressed. Moreover, while operating in a communication abnormal state internally, a normal SCF takes over the other system monitoring range.
(3) Remove the replacement SCF. In this case, abnormality detection such as non-installation of other systems is not performed.
(4) Insert a new SCF and reset.
(5) The new SCF initiates a self-diagnosis and sends a self-diagnosis phase notification.
(6) The operating SCF recognizes the reset of the other system and is performing self-diagnosis.
(7) A new SCF task is activated and the inserted SCF is notified of the functional version number of the SCF.
[0059]
(8) The operating SCF receives the function version number and performs a function version number check process. Then, the function version number of the own system is notified to the new SCF as a function version number response. Further, the operating SCF recovers the communication abnormality and stops monitoring taking over of resources that were in the other system monitoring range.
(9) When the new SCF receives the function version response from the operating SCF, the new SCF performs a function version check process and notifies the maintenance tool of normal startup of the new SCF.
(10) The maintenance tool recognizes the normal operation of the new SCF, reads the data saved on the disk, and copies the internal information from the SCF on the operation side to the new SCF side. Further, internal information is transferred from the operating SCF to the new SCF by the SCF command.
(11) The new SCF receives the SCF command and transitions to the online state (completion of active exchange).
[0060]
(8) Resource monitoring and event notification after SCF active exchange
As described above, the monitoring / notification of the unique resource and the shared resource after the completion of the active exchange is performed as follows.
(a) Monitoring / notification of specific resources
The system on the operating side continues to monitor / notify its own resources for monitoring / notifying, and the system on the inserting side also monitors its own resources for monitoring / notifying from the start. The system monitors / notifies its own resources.
[0061]
(b) Responsible for monitoring / notifying shared resources
Up to now, the system on the operating side has notified the main processor 10 without waiting for an abnormality notification from another system when an abnormality is detected (when communication is abnormal). The notification right to the processor 10 is taken over as it is, but when an abnormality is detected, the same abnormality notification from another system is waited as described above.
The system on the insertion side monitors the shared resource, but the processing can be simplified by not acquiring the notification right.
(c) Exclusive control of shared resources (LCD display on operator operation panel, etc.)
Since alive message exchange control is restored by active insertion of another system, exclusive control of common resources is automatically performed.
By configuring as described above, even when the SCF is inserted later, it is possible to take over information from the operating SCF and operate both systems without contradiction.
[0062]
(9) Consistency check of function version and countermeasure
If the functional version numbers of the SCFs do not match at the time of simultaneous activation of the SCFs of both systems and when the SCF is activated, a problem occurs in communication between the SCFs.
Therefore, the consistency of the function version number is checked, and if the function version number is inconsistent, the following measures are taken.
(a) Consistency check of function version and countermeasures at the time of SCF simultaneous activation of both systems
The inter-SCF communication is realized by operating both system SCFs according to a determined command interface. However, both system SCFs are configured to be individually replaceable in order to realize a north top system by duplication.
Among the factors that cause the SCF to be replaced, command interface specifications may be added or changed. If the command interfaces differ between the two systems, the operation is not guaranteed.
In order to prevent the above problems, when the SCF is started, the command interface version (function version) is notified / recognized to each other. If the function version does not match, the higher function version is the lower. The command interface of both systems is guaranteed by operating at the functional level of.
[0063]
FIG. 17 is a diagram showing a function version number check result when the both SCFs are activated at the same time and the countermeasures. Specifically, the function version number consistency check and the function version number mismatch are handled as follows.
{Circle around (1)} Before the SCF is activated and the inter-SCF communication is started, the version number information (issue the version number information inquiry command) is communicated between the two SCFs.
Note that the function version information is transmitted when the local SCF is functioning (issues a function version notification command) or when the function version notification command is received from another system (function version response command). Issue). When the function version response command is received, the function version number notification is stopped.
{Circle around (2)} When the function version number immediately after activation is received from the SCF of another system, the self system performs a check by comparing the version numbers and returns the function version information of the own system as a response.
(3) The function version number is checked, and if the function version numbers of the #A system and the #B system are the same, there is no problem and no processing is performed. Further, when the functional version numbers of #A system and #B system are different, the following processing is performed.
The #A system and the #B system SCF recognize that the function version numbers do not match, and display them on the LCD, console, etc. of the operator operation panel to notify the operator of the function version number mismatch.
-Lower the version function of the SCF with the higher function version, and operate the SCF with the lower function version according to the function. When a function is added / changed, since the function of the lower version is known, the new function is supported while the function of the old version is supported.
[0064]
(b) Consistency check of functional version number and corrective action when SCF is inserted
In (a) above, since the SCFs of both systems are activated at the same time, either system has no priority and can be operated in a duplex state if the functions are matched to the lower version. .
However, since the function of the SCF that is already in operation is prioritized at the time of active replacement, if an SCF with a lower version number is inserted, the function of the SCF that is in operation cannot be matched to the system that was inserted later. . Therefore, at the time of active replacement, the insertion in this case is rejected, and the operation is continued in the state before the insertion until the correct SCF is inserted.
[0065]
FIG. 18 is a diagram showing a function version number check result at the time of SCF active insertion and its countermeasure. As described with reference to FIG. 16, the function version number is notified and the function version number is checked. Then, as shown in FIG. 18, when the function version numbers of the #A system and the #B system are the same, there is no problem and the process is not performed.
Further, when the functional version numbers of #A system and #B system are different, the following processing is performed.
-When the function level of the #B system SCF that is actively inserted is higher than that of the already operating #A system SCF, the fact that the function version numbers do not match is displayed on the LCD, console, etc. of the operator operation panel. Thus, the operator is notified, the functional version number of the #B system SCF that is actively inserted is reduced, and the operation is continued in both systems in accordance with the functional version number of the #A system SCF.
If the functional level of the #B SCF that is actively inserted is higher than the #A SCF that is already operating, it is impossible to reduce the functional version number of the #A SCF that is already operating. Notify active insertion abnormality of system SCF. The #A system SCF continues operation in the same state as before insertion.
[0066]
(10) Monitoring operation during self-diagnosis and processing when self-diagnosis abnormality is detected
There are two cases of SCF self-diagnosis: a case where an abnormality is detected by oneself and a case where a hang-up occurs.
In these two cases, the other system needs to recognize the other party's abnormality. Therefore, during the SCF self-diagnosis, the other system always notifies the other system of its own diagnosis phase, and the other system recognizes the other party's abnormality by monitoring it.
Specifically, this is performed as follows.
[0067]
(a) When abnormality is recognized by self-diagnosis
After confirming that the other system has started up normally, notify the other system of the occurrence of an abnormal self-diagnosis. This is because if the SCF is activated at the same time in both systems, the other system may also be performing self-diagnosis, so even if a self-diagnosis abnormality is notified at this time, the other system may not be able to handle the abnormality. is there.
Therefore, it waits for a function version number notification or alive message notification indicating that the other system has started normally, and by receiving this notification, the other system knows that the other party has become abnormal by notifying the other system of the abnormality. be able to.
[0068]
FIG. 19 is a diagram showing a processing sequence when a self-diagnosis abnormality is detected.
In the case of a duplex system, if self-diagnosis is performed simultaneously on both systems, an access error may occur depending on the diagnosis item. Therefore, in this embodiment, one of the systems is determined in advance to perform self-diagnosis in advance, and when one self-diagnosis is completed, the other SCF starts self-diagnosis.
That is, as shown in FIG. 19, when #A system is undergoing self-diagnosis, #B system is performing self-diagnosis idling. Then, idling is continued until the initial diagnosis end phase is received from the #A system or a time-out during the initial diagnosis of the other system is detected.
Under normal conditions, when the self-diagnosis of both systems is completed, the SCFs of both systems are started simultaneously. However, as shown in FIG. Even if an error is notified to the system, the other system is not always operating normally, so a self-diagnosis error notification is transmitted only after receiving a function version notification indicating that the system has started up normally.
[0069]
The #A system that has detected the self-diagnosis abnormality notifies the #B system of the error log code of the abnormality and the LCD display data byte by byte in a predefined command format.
In the #B system that has received the self-diagnosis abnormality notification, it knows that the #A system has detected an abnormality and cannot move, and stores all data in the work area until all data is received. At the time of reception, the received partner's abnormality is registered in an error log, notified to the outside by an LCD display or the like, and appropriate processing is performed so that the operation can be continued in one system.
[0070]
(b) Hang up during self-diagnosis
In this case, since the self-diagnosis phase cannot be notified, the other system can recognize that the other party has hung up due to the timeout of the self-diagnosis phase. The monitoring side does not actually monitor the self-diagnosis phase notification, but recognizes the other party's abnormality by the continuous timeout of the acquisition timer of the alive message, and receives the data notified by the other system last. The register ECOMR1 is examined by going to read. And when it is a self-diagnosis phase, it has a mechanism for recognizing that it has hung up in the diagnosis phase.
[0071]
FIG. 20 is a diagram showing a processing sequence at the time of hang-up during self-diagnosis.
If a hang-up occurs during the self-diagnosis, the process is the same as in FIG. 19 until the normal system (#B system) detects a timeout during the other system (#A system) self-diagnosis. As shown in FIG. 20, the #B system alive message acquisition timer continuously times out and recognizes that the system #A has stopped.
Here, since the self-diagnosis phase that was lastly operated remains in the reception counter ECOMR1, it is possible to know how far the #A system self-diagnosis has been operated by reading the reception counter ECOMR1. Can do. Based on this information, as described above, the error log is registered in the error log and notified to the outside by an LCD display or the like, and appropriate processing is performed so that the operation can be continued in one system.
By doing as described above, even when self-diagnosis is performed in both systems, an abnormality in self-diagnosis can always be detected after the normal system has started up.
[0072]
【The invention's effect】
As described above, the following effects can be obtained in the present invention.
(1) Since communication processing between the duplexed SCFs can be performed, the process between the two SCFs can be made consistent in controlling the duplexed system. In addition, appropriate processing can be quickly performed even in the event of a one-system abnormality, and the north top system can be easily realized.
(2) Exclusive control of shared resources, disconnection processing at the time of one-system failure, and monitoring takeover processing of other system resources can be easily performed.
(3) The status of the other system can always be monitored between the duplexed SCFs, and it is easy to deal with a one-system failure.
[0073]
(4) All the transmission / reception data for each notification event can be managed by the sequence number, and reception error detection, notification processing of another system when a reception error occurs, search processing for a retransmission event, and the like are facilitated.
(5) It is possible to quickly detect a communication abnormality between both duplexed SCFs, and determine whether the abnormality is a hardware abnormality or another system abnormality and perform appropriate processing.
(6) Even if a communication abnormality is detected when the other system is not mounted, it can be recognized as a communication abnormality due to the other system not being mounted without causing a hardware abnormality.
(7) It is possible to send an alternative notification from another system even when an abnormal situation in which the notification event of the specific resource monitored by each SCF cannot be notified from the own system to the main processor.
(8) An event detected by the shared resource monitored by both systems can be processed after confirming that the other system has detected the event. Further, the notification to the main processor is not notified twice from both systems.
(9) Even if a monitoring abnormality occurs in one system between both duplexed SCFs, it is possible to continue the operation without causing the system to go down.
[0074]
(10) One system SCF can be replaced while the system is operating, and a north top / no down system can be realized even when one system fails.
(11) It is possible to take over the internal information of the active SCF for the actively inserted SCF, and it can be operated as if it had always been operating in a duplex state.
(12) Since it becomes possible to automatically recognize each other's SCF function level between both duplexed SCFs, it does not operate with different function versions, and it is possible to always guarantee the operation of the duplex system. .
(13) It is possible to always guarantee the operation of the duplex system even when an SCF with an upgraded function version is inserted during active insertion. Further, even when an SCF whose functional version number has been reduced due to an operation mistake by an operator or the like is inserted, it is possible to reject the insertion without operating as it is.
(14) It is possible to quickly detect abnormalities in the self-diagnosis of other systems, and appropriate measures can be taken.
(15) Even when an error that cannot be output to the error log and LCD display (hang-up) occurs, it is possible to notify the abnormality to the outside by the monitored SCF.
[Brief description of the drawings]
FIG. 1 is a principle configuration diagram of the present invention.
FIG. 2 is a diagram showing a system control configuration and monitoring resources according to an embodiment of the present invention.
FIG. 3 is a schematic diagram of duplexed inter-SCF communication according to an embodiment of the present invention.
FIG. 4 is a diagram illustrating a configuration of an inter-SCF communication register according to the embodiment of this invention.
FIG. 5 is a diagram for explaining a method of accessing an inter-SCF communication register.
FIG. 6 is a diagram for explaining how to use an inter-SCF communication register.
FIG. 7 is a diagram showing a transmission format for each command.
FIG. 8 is a diagram showing a transmission sequence when a notification event occurs.
FIG. 9 is a diagram illustrating processing when a notification event occurs during transmission of a plurality of bytes.
FIG. 10 is a diagram showing a sequence check process in communication between SCFs.
FIG. 11 is a diagram for explaining alive message exchange control at normal time;
FIG. 12 is a diagram for explaining alive message exchange control when a path is abnormal;
FIG. 13 is a diagram for explaining alive message exchange control when not implemented or when hung up.
FIG. 14 is a diagram showing a communication abnormality pattern as seen from the whole system.
FIG. 15 is a diagram showing an abnormality detection mechanism and an abnormality cause.
FIG. 16 is a diagram showing a procedure of SCF activity exchange.
FIG. 17 is a diagram showing the function version number and processing of both systems SCF (when both systems are activated simultaneously).
FIG. 18 is a diagram showing the function version number and processing of both SCFs (at the time of active insertion).
FIG. 19 is a processing sequence when a self-diagnosis abnormality is detected.
FIG. 20 is a processing sequence when a hang-up occurs during self-diagnosis.
[Explanation of symbols]
1 Main processor
2 buses
3a, 3b Monitoring / control processor
4 communication means
5,5 Unique resources
6 shared resources
10 Main processor
11 SC bus
12,13 SCF
14 Signal line (SCFLink)
15 RS232C interface
16 External uninterruptible power supply (external UPS)
17 External equipment
18 Expansion unit
19 Expansion unit power supply
20 Temperature sensor
21 A fan.
22 Operator operation panel
23 Sub power supply unit (PSU)
24 Built-in uninterruptible power supply (UPS)
25 Main power supply unit (PDU)
EPC external power control interface
EDPCI expansion unit power control interface
RCI expansion device control interface
ECOMR1 reception register
ECOMR2 transmission register

Claims (8)

Communication means provided independently of the main processor, for duplicating the monitoring / controlling processor for monitoring, controlling or maintaining the information processing system, and for communicating a notification event between the monitoring / controlling processors Provided,
A system monitoring / control method for an information processing apparatus that performs monitoring / control of an information processing system by the dual monitoring / controlling processor,
When one of the dual monitoring / controlling processors receives a notification event from another monitoring / controlling processor having a transmission right, the one monitoring / controlling processor acquires the transmission right of the notification event;
Said one monitoring / control processor assigning a sequence number to a notification event to another monitoring / control processor ;
The one monitoring / control processor, and sending a notification event sequence number is assigned to the other monitoring / control processor,
Notification event to which the sequence number received from the other monitoring / control processor is given when a retransmission request is made from the other monitoring / control processor due to the occurrence of a reception error using the sequence number Retransmitting to the other monitoring / controlling processor;
A system monitoring / controlling method for an information processing apparatus. The system monitoring / control method further includes the step of abandoning the right to transmit the notification event,
In the above step, one monitoring / control processor that has acquired the right to send a notification event
A step of abandoning the right to transmit the notification event by transmitting a notification event to another monitoring / control processor when a holding time timeout occurs due to the elapse of a certain time from the acquisition of the transmission right. The system monitoring / control method for an information processing apparatus according to claim 1 , wherein The step of the one monitoring / control processor obtaining the transmission right of the notification event from another monitoring / control processor having the transmission right,
In one monitoring / control processor having no transmission right, when a time-out of an acquisition time occurs after a lapse of a certain time since the transmission right is abandoned , the one monitoring / control processor acquires the right to transmit a notification event. The system monitoring / control method for an information processing apparatus according to claim 2 , wherein the system monitoring / control method is a step. The system monitoring / control method further includes a step of performing error determination,
The step is a step of determining that an error has occurred in one monitoring / control processor that has acquired the transmission right by another monitoring / control processor when a timeout of the acquisition time occurs. A system monitoring / control method for an information processing apparatus according to claim 3. A dual monitoring / controlling processor provided independently of the main processor for monitoring, controlling or maintaining the information processing system;
Communication means for communicating notification events between the redundant monitoring / controlling processors,
Among the duplicated monitoring / controlling processors, when one monitoring / controlling processor receives a notification event from another monitoring / controlling processor having the transmission right, it acquires the transmission right of the notification event, and the other monitoring / controlling processor. A sequence number is assigned to the notification event to the processor, the notification event to which the sequence number is assigned is transmitted to another monitoring / control processor, and a reception error occurs from the other monitoring / control processor. When a retransmission request is made using the sequence number , the notification event to which the sequence number received from the other monitoring / control processor is assigned is retransmitted to the other monitoring / control processor. System monitoring / control device for information processing equipment. Each of the duplicate monitoring / controlling processors has a transmission right holding timer,
Notified in one monitoring / control processor having acquired the transmission right of the notification event, the transmission right holding timer, when the time-out with the lapse of a predetermined time from the transmission right acquisition has occurred, to the other monitoring / control processor 6. The system monitoring / controlling apparatus for an information processing apparatus according to claim 5 , wherein the right to transmit the notification event is abandoned by transmitting the event. Each of the duplicate monitoring / controlling processors has a transmission right acquisition timer,
In one monitoring / control processor that does not have the transmission right , when a time-out occurs in the transmission right acquisition timer due to the elapse of a predetermined time from the abandonment of the transmission right , a notification event is sent to the one monitoring / control processor. 7. The system monitoring / controlling apparatus for an information processing apparatus according to claim 6 , wherein a transmission right is given. Each of the duplexed monitor / control processor, when the time-out in the transmission right acquisition timer occurs, according to claim 7, characterized in that it is determined that an error has occurred in the other monitoring / control processor System monitoring / control device for information processing equipment.

Images