WO2012001809A1 - 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム - Google Patents

監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム Download PDF

Info

Publication number
WO2012001809A1
WO2012001809A1 PCT/JP2010/061281 JP2010061281W WO2012001809A1 WO 2012001809 A1 WO2012001809 A1 WO 2012001809A1 JP 2010061281 W JP2010061281 W JP 2010061281W WO 2012001809 A1 WO2012001809 A1 WO 2012001809A1
Authority
WO
WIPO (PCT)
Prior art keywords
read
attribute information
unit
storage unit
request
Prior art date
Application number
PCT/JP2010/061281
Other languages
English (en)
French (fr)
Inventor
朋憲 間瀬
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2012522408A priority Critical patent/JP5447669B2/ja
Priority to EP10854106.1A priority patent/EP2590079A1/en
Priority to PCT/JP2010/061281 priority patent/WO2012001809A1/ja
Publication of WO2012001809A1 publication Critical patent/WO2012001809A1/ja
Priority to US13/724,502 priority patent/US20130111022A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2089—Redundant storage control functionality

Definitions

  • the present invention relates to a monitoring control device, a server device, a monitoring control method, and a monitoring control program.
  • the server device includes components such as a CPU and memory system board, an input / output (IO) device, a power supply, and a fan. Each of these components has a sensor. And the attribute information of the said sensor is acquired in order that the client which is a terminal which carries out operation management of the server apparatus may monitor the sensor with which each component is provided via the service processor (SP) in the server apparatus connected with these components.
  • SP service processor
  • FIG. 9 is a functional block diagram showing a configuration of a conventional server device.
  • the server device 9 includes system boards 91a and 91b, IO devices 92a and 92b, power supplies 93a and 93b, and fans 94a and 94b. Each of these components has a sensor. Then, the server device 9 connects these components and the system control unit (SP) 95 with, for example, an I2C bus.
  • the system control unit 95 includes a storage device 95a that stores sensor attribute information of each component as an SDR (Sensor Data Record) repository.
  • SDR Sensor Data Record
  • Clients A and B are connected to the server device 9 via a LAN (Local Area Network) and communicate with the system control unit 95. Then, the clients A and B acquire sensor attribute information provided in each component by using a command that matches the specification of the management interface of the server device, for example, called IPMI (Intelligent Platform Management Interface). For example, the client A issues a command requesting acquisition of one sensor information of the SDR repository to the system control unit 95. When acquiring this command, the system control unit 95 reads out one sensor information of the SDR repository from the storage device 95a based on the acquired command, and notifies the client A of the read information. As described above, the client A acquires the notified information in order to monitor the sensors included in each component.
  • IPMI Intelligent Platform Management Interface
  • the reading efficiency may be lowered.
  • the storage device that stores the SDR repository is busy, reading of sensor information is awaited, and it may take time to complete reading of sensor information.
  • sensor information of a large number of sensors is read from the storage device. Therefore, when the storage device that stores the SDR repository is busy, until reading of the sensor information of all the sensors is completed. May take a long time.
  • the server device when reading the sensor information of a specific SDR repository, the server device cannot read the sensor information of the specific SDR repository from the storage device that stores the SDR repository for reasons such as SDR corruption. There is.
  • the server device reserves an SDR related to the sensor information requested to be updated. For this reason, even if a client that is different from the client that requested the update requests acquisition of the same sensor information as the sensor information that requested the update, the server device cannot read the information until the SDR reserve is released. In some cases, it takes time to complete reading.
  • the disclosed technology has been made in view of the above, and an object thereof is to provide a monitoring control device or the like that improves the reading efficiency of the SDR repository.
  • the monitoring control device disclosed in the present application detects a request for reading attribute information related to the component from the outside, and a storage unit that stores attribute information related to the component built in the server device. Another storage unit that determines whether the attribute information can be read from the storage unit, and synchronizes the attribute information corresponding to the read request with the storage unit when it is determined that the attribute information cannot be read. And a control unit that requests execution of the read request to the standby control unit that is duplicated with itself.
  • the monitoring control device disclosed in the present application it is possible to improve the reading efficiency of attribute information related to components built in the server device.
  • FIG. 1 is a functional block diagram illustrating the configuration of the monitoring control device according to the first embodiment.
  • FIG. 2 is a functional block diagram illustrating the configuration of the server apparatus according to the second embodiment.
  • FIG. 3 is a diagram illustrating an example of the data structure of the GetSDR command.
  • FIG. 4 is a diagram illustrating an example of the data structure of the SDR management information.
  • FIG. 5 is a flowchart illustrating the procedure of the monitoring control process according to the second embodiment.
  • FIG. 6 is a sequence diagram of the monitoring control process when the SDR repository is busy.
  • FIG. 7 is a sequence diagram of the monitoring control process when the SDR repository is reserved.
  • FIG. 8 is a diagram illustrating a computer that executes a monitoring control program.
  • FIG. 9 is a functional block diagram showing a configuration of a conventional server device.
  • FIG. 1 is a functional block diagram illustrating the configuration of the monitoring control device 1 according to the first embodiment. As illustrated in FIG. 1, the monitoring control device 1 includes a storage unit 11 and a control unit 12.
  • the storage unit 11 stores attribute information related to components built in the server device 10.
  • the control unit 12 detects a request for reading attribute information regarding a component from the outside, the control unit 12 determines whether the attribute information can be read from the storage unit 11 in response to the read request.
  • control unit 12 determines that the attribute information cannot be read from the storage unit 11
  • the control unit 12 duplexes with the self so that the attribute information corresponding to the read request is read from another storage unit synchronized with the storage unit 11. Request the execution of a read request to the waiting control unit.
  • the monitoring control device 1 requests the standby control unit to execute the read request. For this reason, if the monitoring control apparatus 1 can read the attribute information according to the read request from the other storage unit by the standby control unit, the other storage unit is synchronized with the storage unit 11, so Information can be read, and the reading efficiency of the attribute information can be improved.
  • FIG. 2 is a functional block diagram of the configuration of the server device 10A according to the second embodiment.
  • the server apparatus 10A has a monitoring control apparatus 1A and a monitoring control apparatus 1B inside, and the monitoring control apparatus is duplicated.
  • the “active side” indicating that the monitoring control apparatus 1A is in operation
  • the “standby side” indicating that the monitoring control apparatus 1B is on standby are assumed.
  • the server device 10A conforms to the specification of IPMI (Intelligent Platform Management Interface).
  • the IPMI is a management interface of the server device 10A, and is a standard specification for monitoring the state of components built in the server device 10A and managing the server device 10A.
  • the monitoring control apparatus 1 is applicable to a printed circuit board, for example, it is not limited to this.
  • the monitoring control device 1A is connected to a system board 4A, a power supply 4B, an IO device 4C, and a fan 4D, which are a plurality of components built in the server device 10A. Each of these components includes a sensor. Furthermore, the monitoring control apparatus 1A includes a driver unit 21 connected to a plurality of components, a port 22 connected to a plurality of clients 3 (3A, 3B), SDR (Sensor Data Record) repositories 23A, 23B, and IPMI control units 24A, 24B. , SDR management information 25 and duplex mechanism 26.
  • the driver unit 21 is an interface between each sensor mounted on a plurality of components and the IPMI control unit 24A. In addition, the driver unit 21 is connected to a plurality of components by, for example, an I2C bus.
  • the port 22 is an interface between the clients 3A and 3B and the IPMI control unit 24A, and corresponds to a socket in TCP / IP communication, for example.
  • a GetSDR command a command for reading sensor attribute information issued from the client 3
  • the port 22 notifies the IPMI control unit 24A of the received command.
  • This command is a command conforming to the IPMI specification.
  • the SDR repository 23A stores attribute information of sensors mounted on components built in the server apparatus 10A in association with the sensors.
  • the SDR repository 23A stores data using one record for one sensor.
  • the record storing the attribute information of one sensor is referred to as “SDR”.
  • the sensor attribute information includes, for example, an address assigned to the sensor, a sensor identification number, a sensor type, and upper and lower limit values that can be taken by the sensor, but are limited to these as long as the information relates to the sensor. is not.
  • the SDR repository 23A is synchronized with the SDR repository 23B on the standby side. That is, when the SDR repository 23A is updated, the standby SDR repository 23B is also updated with the same information. As a result, the active-side SDR repository 23A and the standby-side SDR repository 23B hold the same attribute information.
  • the IPMI control unit 24A controls processing conforming to the IPMI specification.
  • the IPMI control unit 24A communicates with the standby-side IPMI control unit 24B through the duplex mechanism 26.
  • the IPMI control unit 24A includes a logical channel unit 31, a command processing unit 32A, a device unit 33, and a handler unit 34A.
  • the logical channel unit 31 includes a plurality of channels. The channel provided in the logical channel unit 31 logically associates the port 22 with the command processing unit 32A. That is, the command processing unit 32A associated with the port 22 by the channel performs command processing to be described later.
  • the command processing unit 32A executes a process corresponding to the received command.
  • This command includes, for example, a GetSDR command that reads a SDR from the SDR repository 23A, and a Reserve SDR Repository command that reserves the SDR repository 23A.
  • the device unit 33 accesses various devices such as the SDR repository 23A according to the command processed by the command processing unit 32A.
  • the data structure of the GetSDR command will be described with reference to FIG. 3A shows the data structure of the request data of the GetSDR command, and FIG. 3B shows the data structure of the response data of the GetSDR command.
  • the request data of the GetSDR command includes a reserve ID 6a, a record ID 6b, an offset 6c, and a read byte number 6d.
  • the reserve ID 6a indicates the identification ID of the SDR to be reserved. In the reserve ID 6a, the lower byte of the reserve ID is set at the 0th byte, and the upper byte of the reserve ID is set at the 1st byte.
  • the record ID 6b indicates the identification ID of the SDR to be read. In the record ID 6b, the lower byte of the record ID is set in the second byte, and the upper byte of the record ID is set in the third byte.
  • the offset 6c indicates a start byte from which data is read out of the record corresponding to the record ID 6b.
  • the number of read bytes 6d indicates the number of bytes to be read.
  • the response data of the GetSDR command includes a completion code 7a, a next record ID 7b, and read data 7c.
  • the completion code 7a indicates the reading result of the sensor attribute information. In the completion code 7a, for example, “0” indicating that the read result is normal and “1” indicating that the read result is abnormal are set.
  • the next record ID 7b indicates the record ID of the record next to the record corresponding to the read record ID 6b.
  • attribute information read from the record corresponding to the record ID 6b of the request data is set.
  • the command processing unit 32A acquires the request data of the GetSDR command to read the attribute information of the specified sensor, analyzes the acquired request data, and requests the device unit 33 to read the SDR repository based on the analysis result To do.
  • This SDR repository read request includes the record ID 6b, the offset 6c, and the read byte number 6d set in the request data.
  • the command processing unit 32A acquires the read result from the device unit 33, and creates response data based on the read result when the acquired read result is normal. Then, the command processing unit 32A outputs the created response data to the logical channel unit 31. On the other hand, the command processing unit 32A will be described in detail below when the read result is abnormal.
  • the command processing unit 32A includes a read request unit 41, an attribute information acquisition unit 42, and an attribute information output unit 43.
  • the read request unit 41 requests the standby side to execute a read request so that this attribute information is read from the SDR repository 23B on the standby side.
  • the case where the reading result is abnormal means that the attribute information of the sensor mounted on the component cannot be read from the SDR repository 23A.
  • the read request unit 41 transmits the request data of the GetSDR command to the standby side when it is determined that the attribute information of the designated sensor cannot be read by the read permission determination unit 44 described later. Request to the handler unit 34A.
  • the attribute information acquisition unit 42 acquires a response to the read request execution request from the standby side. Specifically, the attribute information acquisition unit 42 acquires response data for the GetSDR command requested by the read request unit 41 from the handler unit 34 ⁇ / b> A, and outputs the acquired response data to the attribute information output unit 43. In the response data, if the completion code 7a is normal, the attribute information of the designated sensor is set in the read data 7c.
  • the attribute information output unit 43 outputs the response data acquired by the attribute information acquisition unit 42 to the request source of the read request. That is, if the response data is normal, the attribute information output unit 43 outputs the response data including the attribute information of the designated sensor to the client 3 that is the request source of the read request.
  • the device unit 33 includes a readability determination unit 44.
  • the readability determination unit 44 determines whether or not the sensor attribute information corresponding to the SDR repository read request from the command processing unit 32A can be read from the SDR repository 23A. Specifically, the readability determination unit 44 determines whether or not the SDR repository 23A is in a reserved state based on the SDR management information 25 that stores SDR management information included in the SDR repository 23A.
  • FIG. 4 is a diagram illustrating an example of the data structure of the SDR management information.
  • the SDR management information 25 stores the total number of records 25a, the reserve ID 25b, the start record ID 25c, and the last record ID 25d in association with each other.
  • the total record number 25a indicates the total number of SDRs.
  • the reserve ID 25b indicates a record ID in the reserved state.
  • the start record ID 25c indicates the record ID of the start record.
  • the end record ID 25d indicates the record ID of the end record. That is, the readability determination unit 44 determines whether or not the record ID 6b included in the SDR repository read request matches the reserve ID 25b of the SDR management information 25.
  • the readability determination unit 44 determines that the SDR cannot be read from the SDR repository 23A, and reads the read result indicating that the abnormality is caused by the reserved state. The request unit 41 is notified. Further, when it is determined that the SDR repository 23A is not in the reserved state, the readability determination unit 44 determines whether or not the SDR repository 23A is in a busy state. When it is determined that the SDR repository 23A is busy, the read permission / inhibition determination unit 44 determines that the SDR cannot be read from the current SDR repository 23A, and the read request unit displays the result of reading the abnormality due to the busy state. 41 is notified. Further, when it is determined that the SDR repository 23A is not busy, the readability determination unit 44 reads the attribute information of the designated sensor from the SDR repository 23A.
  • the readability determination unit 44 determines whether or not the read attribute information is damaged. Further, when the readability determination unit 44 determines that the read attribute information is damaged, the readability determination unit 44 determines that the SDR could not be read from the SDR repository 23A, and indicates that the abnormality is due to the damage of the SDR. The read result is notified to the read request unit 41. Further, when it is determined that the read attribute information is not damaged, the readability determination unit 44 outputs a normal read result including the read sensor attribute information to the command processing unit 32A.
  • the handler unit 34A is an interface between the command processing unit 32A and the duplex mechanism 26. Specifically, the handler unit 34A transmits the request data of the GetSDR command requested from the read request unit 41 to the standby side via the duplex mechanism 26. In addition, the handler unit 34A outputs response data to the GetSDR command processed by the standby side to the attribute information acquisition unit 42.
  • the monitoring control device 1B Since the monitoring control device 1B on the standby side has almost the same configuration as the monitoring control device 1A, the same reference numerals are given to the same configuration as the monitoring control device 1A, and the description of the overlapping configuration is omitted.
  • the monitoring control device 1B differs from the monitoring control device 1A in that the handler unit 34A is changed to the handler unit 34B and the SDR repository 23A is changed to the SDR repository 23B.
  • the monitoring control device 1B is different from the monitoring control device 1A in that the command processing unit 32B includes a read request reception unit 51 and an attribute information notification unit 52.
  • the SDR repository 23B is synchronized with the active SDR repository 23A as described above. That is, the SDR repository 23B and the SDR repository 23A hold the same attribute information.
  • the handler unit 34B is an interface between the command processing unit 32B and the duplex mechanism 26. Specifically, the handler unit 34B acquires the request data of the GetSDR command requested from the active side via the standby-side duplex mechanism 26, and outputs the acquired request data to the read request receiving unit 51. Further, the handler unit 34B notifies the active side of the response data notified by the attribute information notification unit 52 via the duplex mechanism 26.
  • the read request receiving unit 51 receives the request data of the GetSDR command from the handler unit 34B, analyzes the received request data, and requests the device unit 33 to read the SDR repository based on the analysis result.
  • the attribute information notification unit 52 acquires a read result from the device unit 33 and creates response data based on the acquired read result. Then, the command processing unit 32B outputs the created response data to the handler unit 34B. In the response data, if the completion code 7a is normal, the attribute information of the designated sensor is set in the read data 7c.
  • FIG. 5 is a flowchart illustrating the procedure of the monitoring control process according to the second embodiment.
  • the command processing unit 32A determines whether a request has been received from the client 3 (step S11). If the command processing unit 32A determines that the request has not been received (No in step S11), the command processing unit 32A waits until the request is received. On the other hand, if the command processing unit 32A determines that the request has been received (step S11 Yes), the command processing unit 32A determines whether the received request is a GetSDR command (step S12).
  • the command processing unit 32A executes command processing for the corresponding request (step S13).
  • the readability determination unit 44 determines whether or not the SDR repository 23A is in a reserved state (Step S12). S14).
  • step S14 If the readability determination unit 44 determines that the SDR repository 23A is in a reserved state (Yes in step S14), the readability determination unit 44 determines that the SDR cannot be read from the SDR repository 23A, and proceeds to step S18. On the other hand, when it is determined that the SDR repository 23A is not in the reserved state (No in step S14), the readability determination unit 44 determines whether the SDR repository 23A is in a busy state (step S15).
  • the readability determination unit 44 determines that the SDR cannot be read from the current SDR repository 23A, and proceeds to step S18. On the other hand, when it is determined that the SDR repository 23A is not busy (No in step S15), the readability determination unit 44 reads the attribute information of the sensor designated by the GetSDR command from the SDR repository 23A (step S16).
  • the readability determination unit 44 determines whether or not the read attribute information is damaged (step S17). When it is determined that the read attribute information is not damaged (No in step S17), the readability determination unit 44 determines that the attribute information has been read and proceeds to step S20.
  • the readability determination unit 44 determines that the SDR could not be read from the SDR repository 23A, and proceeds to step S18.
  • the read request unit 41 transmits the request data of the GetSDR command to the standby side (step S18). That is, as described above, the SDR repository 23A may be reserved, the SDR repository 23A may be busy, or the read attribute information may be damaged. In this case, the read request unit 41 requests the standby side to execute a read request in order to read the sensor attribute information on the standby side.
  • the attribute information acquisition unit 42 acquires SDR information (response data) for the GetSDR command from the standby side (step S19). That is, if the response data completion code 7a is normal (for example, “0”), the attribute information acquisition unit 42 reads the normal attribute of the sensor read from the standby SDR repository 23B. Information will be acquired.
  • the attribute information output unit 43 returns the response data to the client 3 that has requested the GetSDR command (step S20).
  • FIG. 6 is a sequence diagram of the monitoring control process when the SDR repository is busy.
  • the client 3A issues a GetSDR command to the server device 10A in order to read sensor attribute information (step S31). Then, the active side command processing unit 32A requests the device unit 33 to read the SDR repository based on the acquired request data of the GetSDR command (step S32).
  • the readability determination unit 44 of the device unit 33 determines whether or not the sensor attribute information corresponding to the SDR repository read request can be read from the SDR repository 23A. Specifically, the readability determination unit 44 attempts to read the SDR requested to be read. Here, since the SDR attempted to be read is busy, the read permission determination unit 44 determines that the SDR cannot be read from the current SDR repository 23A, and reads the read result indicating that the abnormality is due to the busy state. The request unit 41 is notified (step S33).
  • the read request unit 41 of the command processing unit 32A requests the handler unit 34A to transmit the request data of the GetSDR command to the standby side (step S34). Then, the handler unit 34A transmits the request data of the GetSDR command requested from the read request unit 41 to the standby-side handler unit 34B via the duplex mechanism 26 (steps S35 to S37).
  • the standby-side handler unit 34B outputs the request data of the GetSDR command transmitted from the self-side duplex mechanism 26 to the read request receiving unit 51 of the command processing unit 32B (step S38). Then, the read request receiving unit 51 requests the device unit 33 to read the SDR repository based on the request data of the GetSDR command received from the handler unit 34B (step S39).
  • the device unit 33 on the standby side attempts to read the SDR requested to read the SDR repository, and returns the read result to the attribute information notification unit 52 of the command processing unit 32B (step S40). Then, the attribute information notification unit 52 acquires the read result from the device unit 33, creates response data based on the acquired read result, and notifies the created response data to the handler unit 34B (step S41).
  • the standby-side handler unit 34B transmits the response data notified from the attribute information notification unit 52 to the active-side handler unit 34A via the duplex mechanism 26 (steps S42 to S44). Then, the active-side handler unit 34A returns the response data transmitted from the self-side duplexing mechanism 26 to the attribute information acquisition unit 42 of the command processing unit 32A (step S45). Then, the attribute information output unit 43 of the command processing unit 32A returns the response data acquired by the attribute information acquisition unit 42 to the client 3A (step S46).
  • the monitoring control processing sequence in the case where the active-side SDR repository 23 ⁇ / b> A is busy has been described.
  • the present invention is not limited to this, and the SDR read from the active-side SDR repository 23 ⁇ / b> A may be damaged.
  • the readability determination unit 44 in step S33 tries to read the SDR requested to be read. Then, since the read SDR is damaged, the readability determination unit 44 determines that the SDR could not be read from the SDR repository 23A, and outputs a read result indicating that the SDR is abnormal due to the damage to the read request unit. 41 may be notified.
  • FIG. 7 is a sequence diagram of the monitoring control process when the SDR repository is reserved.
  • the client 3A issues a ReserveSDR Repository command to the server device 10A to reserve the SDR repository 23A (step S51). Then, the active-side command processing unit 32A requests the device unit 33 to reserve the SDR repository based on the acquired request data of the Reserve SDR Repository command (step S52).
  • the device unit 33 sets the SDR repository 23A to the reserved state, and returns response data indicating that the reservation is normal to the command processing unit 32A (step S53). Further, the command processing unit 32A returns the response data acquired from the device unit 33 to the client 3A (step S54).
  • the client 3B issues a GetSDR command to the server device 10A to read out the sensor attribute information (step S55). Then, the active-side command processing unit 32A requests the device unit 33 to read the SDR repository based on the acquired request data of the GetSDR command (step S56).
  • the readability determination unit 44 of the device unit 33 determines whether or not the sensor attribute information corresponding to the SDR repository read request can be read from the SDR repository 23A.
  • the readability determination unit 44 determines that the SDR cannot be read from the SDR repository 23A, and reads out the read result indicating that the abnormality is caused by the reserved state. 41 is notified (step S57).
  • the readability determination unit 44 of the IPMI control unit 24A determines whether or not the attribute information about the component can be read from the SDR repository 23A in response to the read request.
  • the read request unit 41 of the IPMI control unit 24A determines that the attribute information about the part cannot be read from the SDR repository 23A by the read permission determination unit 44, it requests the standby side to execute a read request. To do.
  • the attribute information acquisition unit 42 of the IPMI control unit 24A acquires attribute information for the read request requested from the standby side by the read request unit 41 from the standby side.
  • the IPMI control unit 24A determines that the attribute information related to the component cannot be read from the SDR repository 23A, the IPMI control unit 24A acquires the attribute information that could not be read from the SDR repository 23B on the standby side. .
  • the IPMI control unit 24A can improve the reading efficiency of attribute information related to components.
  • the attribute information output unit 43 of the IPMI control unit 24A outputs the attribute information acquired by the attribute information acquisition unit 42 to the request source of the read request. According to this configuration, the attribute information output unit 43 outputs the acquired attribute information to the request source. Therefore, the request source can acquire the requested attribute information without being aware of the active side and the standby side.
  • the readability determination unit 44 of the IPMI control unit 24A determines whether or not the attribute information can be read from the SDR repository 23A based on the presence / absence of the busy state of the SDR repository 23A. According to this configuration, even when the readability determination unit 44 determines that the attribute information cannot be read because it is busy, if the IPMI control unit 24A can read this attribute information from the standby side, the busy information The waiting time due to the state can be avoided. As a result, the readability determination unit 44 can improve the attribute information read efficiency.
  • the SDR repository 23A of the IPMI control unit 24A stores the attribute information related to the sensor mounted on the component. According to such a configuration, the IPMI control unit 24A can improve the reading efficiency of attribute information related to the sensor mounted on the component.
  • the server device 10A can be realized by mounting each function such as the above-described duplexed IPMI control unit 24A on an information processing device such as a known personal computer or workstation.
  • each component of each illustrated apparatus does not necessarily need to be physically configured as illustrated.
  • the specific mode of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured.
  • the attribute information acquisition unit 42 and the attribute information output unit 43 may be integrated as one unit.
  • the readability determination unit 44 includes a reserve state determination unit that determines whether or not it is in a reserved state, a busy state determination unit that determines whether or not it is in a busy state, and whether or not the read attribute information is damaged. It may be distributed to the attribute information damage determination unit for determining
  • a storage unit such as the SDR repository 23A and the SDR management information 25 may be connected as an external device of the server device 10A via a network.
  • FIG. 8 is a diagram illustrating a computer that executes a monitoring control program.
  • the computer 1000 includes a RAM (Random Access Memory) 1010, a cache 1020, an HDD 1030, a CPU (Central Processing Unit) 1040, and a bus 1050.
  • the RAM 1010, cache 1020, HDD 1030, and CPU 1040 are connected by a bus 1050.
  • the HDD 1030 stores a monitoring control program 1031 having the same function as the IPMI control unit 24A shown in FIG.
  • the HDD 1030 stores SDR repository information 1032 corresponding to the SDR repository 23A illustrated in FIG. 2 and SDR management information 1033 corresponding to the SDR management information 25 illustrated in FIG.
  • the monitoring control program 1031 functions as the monitoring control process 1011.
  • the supervisory control process 1011 expands the information read from the SDR repository information 1032 and the SDR management information 1033 to an area allocated to itself on the RAM 1010, and executes various data processing based on the expanded data. To do.
  • monitoring control program 1031 is not necessarily stored in the HDD 1030, and the computer 1000 may read and execute this program stored in a storage medium such as a CD-ROM. Further, this program may be stored in another computer (or server) connected to the computer 1000 via a public line, the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or the like. In this case, the computer 1000 reads the program from these and executes it.
  • a storage medium such as a CD-ROM.
  • this program may be stored in another computer (or server) connected to the computer 1000 via a public line, the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or the like. In this case, the computer 1000 reads the program from these and executes it.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　監視制御装置（１）が、サーバ装置に内蔵する部品に関する属性情報を記憶する記憶部（１１）と、外部から部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、記憶部（１１）から属性情報を読み出せるか否かを判定し、属性情報を読み出せないと判定した場合に、読み出し要求に応じた属性情報を記憶部（１１）と同期した他の記憶部から読み出させるべく、自己と二重化された待機中の制御部に対して読み出し要求の実行を依頼する制御部（１２）とを備えることとしたので、読み出し要求に応じた属性情報の読み出し効率を向上させることができる。

Description

監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム
　本発明は、監視制御装置、サーバ装置、監視制御方法及び監視制御プログラムに関する。
　サーバ装置は、ＣＰＵやメモリのシステムボード、入出力（ＩＯ）装置、電源及びファン等の部品から構成される。これら部品は、それぞれセンサを備えている。そして、これら部品と接続するサーバ装置内のサービスプロセッサ（ＳＰ）を介して、サーバ装置を運用管理する端末であるクライアントが各部品に備えるセンサを監視するために当該センサの属性情報を取得する。
　ここで、従来のサーバ装置の構成を、図９を参照しながら説明する。図９は、従来のサーバ装置の構成を示す機能ブロック図である。図９に示すように、サーバ装置９は、システムボード９１ａ、９１ｂ、ＩＯ装置９２ａ、９２ｂ、電源９３ａ、９３ｂ及びファン９４ａ、９４ｂを有する。これら部品は、それぞれセンサを備えている。そして、サーバ装置９は、これら部品とシステム制御部（ＳＰ）９５とを、例えばＩ２Ｃバスで接続する。システム制御部９５は、各部品が備えるセンサの属性情報をＳＤＲ（Sensor　Data　Record）レポジトリとして記憶する記憶装置９５ａを有する。
　クライアントＡ、Ｂは、サーバ装置９とＬＡＮ（Local　Area　Network）で接続され、システム制御部９５と通信する。そして、クライアントＡ、Ｂは、例えばＩＰＭＩ（Intelligent　Platform　Management　Interface）と呼ばれる、サーバ装置の管理インタフェースの仕様に合致したコマンドを用いて、各部品に備えるセンサの属性情報を取得する。例えば、クライアントＡは、ＳＤＲレポジトリの１センサ情報の取得を要求するコマンドをシステム制御部９５に発行する。そして、システム制御部９５は、このコマンドを取得すると、取得したコマンドに基づいて、ＳＤＲレポジトリの１センサ情報を記憶装置９５ａから読み出し、読み出した情報をクライアントＡに通知する。このように、クライアントＡは、各部品に備えるセンサを監視するために、通知された情報を取得する。
特開２００１－９２７３８号公報 特開平２－２７８４５７号公報 特開平４－２８３８１０号公報
　しかしながら、従来のサーバ装置では、ＳＤＲレポジトリのセンサ情報を読み出す際、読み出し効率が低下する場合がある。例えば、ＳＤＲレポジトリを記憶する記憶装置がビジーである場合、センサ情報の読み出しが待たされ、センサ情報の読み出しが完了するまでに時間を要する場合がある。特に、センサを多数備えるサーバ装置では、多数のセンサのセンサ情報を記憶装置から読み出すこととなるので、ＳＤＲレポジトリを記憶する記憶装置がビジーである場合、全センサのセンサ情報の読み出しが完了するまでに長時間を要する可能性がある。
　また、別の例では、特定のＳＤＲレポジトリのセンサ情報を読み出す際、サーバ装置では、ＳＤＲの破損等の理由で、ＳＤＲレポジトリを記憶する記憶装置から特定のＳＤＲレポジトリのセンサ情報を読み出せない場合がある。
　さらに、別の例では、１クライアントが、ＳＤＲレポジトリのセンサ情報の更新を要求したとき、サーバ装置では、更新を要求したセンサ情報に関するＳＤＲをリザーブする。このため、更新を要求したクライアントと異なるクライアントが、更新を要求したセンサ情報と同一のセンサ情報の取得を要求しても、サーバ装置では、ＳＤＲのリザーブが解除されるまで当該情報を読み出せず、読み出しが完了するまでに時間を要する場合がある。
　開示の技術は、上記に鑑みてなされたものであって、ＳＤＲレポジトリの読み出し効率を向上させる監視制御装置等を提供することを目的とする。
　本願の開示する監視制御装置は、一つの態様において、サーバ装置に内蔵する部品に関する属性情報を記憶する記憶部と、外部から前記部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、前記記憶部から前記属性情報を読み出せるか否かを判定し、前記属性情報を読み出せないと判定した場合に、前記読み出し要求に応じた属性情報を前記記憶部と同期した他の記憶部から読み出させるべく、自己と二重化された待機中の制御部に対して前記読み出し要求の実行を依頼する制御部とを備える。
　本願の開示する監視制御装置の一つの態様によれば、サーバ装置に内蔵する部品に関する属性情報の読み出し効率を向上させることができるという効果を奏する。
図１は、実施例１に係る監視制御装置の構成を示す機能ブロック図である。 図２は、実施例２に係るサーバ装置の構成を示す機能ブロック図である。 図３は、ＧｅｔＳＤＲコマンドのデータ構造の一例を示す図である。 図４は、ＳＤＲ管理情報のデータ構造の一例を示す図である。 図５は、実施例２に係る監視制御処理の手順を示すフローチャートである。 図６は、ＳＤＲレポジトリがビジーである場合における監視制御処理のシーケンス図である。 図７は、ＳＤＲレポジトリがリザーブされている場合における監視制御処理のシーケンス図である。 図８は、監視制御プログラムを実行するコンピュータを示す図である。 図９は、従来のサーバ装置の構成を示す機能ブロック図である。
　以下に、本願の開示する監視制御装置、サーバ装置、監視制御方法及び監視制御プログラムの実施例を図面に基づいて詳細に説明する。なお、本実施例によりこの発明が限定されるものではない。
　図１は、本実施例１に係る監視制御装置１の構成を示す機能ブロック図である。図１に示すように、監視制御装置１は、記憶部１１及び制御部１２を有する。
　記憶部１１は、サーバ装置１０に内蔵する部品に関する属性情報を記憶する。制御部１２は、外部から部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、記憶部１１から属性情報を読み出せるか否かを判定する。
　また、制御部１２は、記憶部１１から属性情報を読み出せないと判定した場合に、読み出し要求に応じた属性情報を記憶部１１と同期した他の記憶部から読み出させるべく、自己と二重化された待機中の制御部に対して読み出し要求の実行を依頼する。
　このようにして、監視制御装置１は、部品に関する属性情報を読み出せないと判定した場合に、待機中の制御部に読み出し要求の実行を依頼することとした。このため、監視制御装置１は、読み出し要求に応じた属性情報を待機中の制御部によって他の記憶部から読み出せれば、他の記憶部が記憶部１１と同期しているので、部品に関する属性情報を読み出すことができ、当該属性情報の読み出し効率を向上できる。
［実施例２に係るサーバ装置の構成］
　図２は、本実施例２に係るサーバ装置１０Ａの構成を示す機能ブロック図である。図２に示すように、サーバ装置１０Ａは、その内部に監視制御装置１Ａ及び監視制御装置１Ｂを有し、監視制御装置を二重化している。ここでは、説明の便宜上、監視制御装置１Ａが運用中であることを示す「アクティブ側」、監視制御装置１Ｂが待機中であることを示す「スタンバイ側」とする。また、サーバ装置１０Ａは、ＩＰＭＩ（Intelligent　Platform　Management　Interface）の仕様に準拠するものとする。ＩＰＭＩとは、サーバ装置１０Ａの管理インタフェースのことであり、サーバ装置１０Ａに内蔵する部品の状態を監視し、サーバ装置１０Ａを管理する標準仕様のことである。なお、監視制御装置１は、例えばプリント板に適用可能であるが、これに限定されるものではない。
　監視制御装置１Ａは、サーバ装置１０Ａに内蔵する複数の部品であるシステムボード４Ａ、電源４Ｂ、ＩＯ装置４Ｃ及びファン４Ｄと接続する。これら部品は、それぞれセンサを備える。さらに、監視制御装置１Ａは、複数の部品と接続するドライバ部２１、複数のクライアント３（３Ａ、３Ｂ）と接続するポート２２、ＳＤＲ（Sensor　Data　Record）レポジトリ２３Ａ、２３Ｂ、ＩＰＭＩ制御部２４Ａ、２４Ｂ、ＳＤＲ管理情報２５及び二重化機構２６を有する。
　ドライバ部２１は、複数の部品に搭載された各センサとＩＰＭＩ制御部２４Ａとのインタフェースである。また、ドライバ部２１は、複数の部品と例えばＩ２Ｃバスで接続される。ポート２２は、クライアント３Ａ、３ＢとＩＰＭＩ制御部２４Ａとのインタフェースであり、例えばＴＣＰ／ＩＰ通信におけるソケットに相当する。また、ポート２２は、クライアント３から発行される、センサの属性情報を読み出すコマンド（以下、ＧｅｔＳＤＲコマンドという。）を受け付けると、受け付けたコマンドをＩＰＭＩ制御部２４Ａに通知する。このコマンドは、ＩＰＭＩの仕様に準拠したコマンドである。
　ＳＤＲレポジトリ２３Ａは、サーバ装置１０Ａに内蔵する部品に搭載されたセンサの属性情報を、センサに対応付けて記憶する。ＳＤＲレポジトリ２３Ａは、１個のセンサについて１個のレコードを用いて記憶する。この１個のセンサの属性情報が記憶されたレコードを「ＳＤＲ」という。センサの属性情報とは、例えば、センサに付与されたアドレス、センサの識別番号、センサの種別およびセンサが取り得る上下限値があるが、センサに関係する情報であればこれらに限定されるものではない。
　また、ＳＤＲレポジトリ２３Ａは、スタンバイ側のＳＤＲレポジトリ２３Ｂと同期をとっている。すなわち、ＳＤＲレポジトリ２３Ａが更新されると、スタンバイ側のＳＤＲレポジトリ２３Ｂも同一の情報で更新される。これにより、アクティブ側のＳＤＲレポジトリ２３Ａ及びスタンバイ側のＳＤＲレポジトリ２３Ｂは、相互に同一内容の属性情報を保持することとなる。
　ＩＰＭＩ制御部２４Ａは、ＩＰＭＩの仕様に準拠した処理を制御する。また、ＩＰＭＩ制御部２４Ａは、二重化機構２６を通してスタンバイ側のＩＰＭＩ制御部２４Ｂと相互に通信する。さらに、ＩＰＭＩ制御部２４Ａは、論理チャネル部３１、コマンド処理部３２Ａ、デバイス部３３及びハンドラ部３４Ａを有する。論理チャネル部３１は、複数のチャネルを備える。そして、論理チャネル部３１に備えられたチャネルが、ポート２２とコマンド処理部３２Ａとを論理的に関連付ける。すなわち、チャネルによってポート２２と関連付けられたコマンド処理部３２Ａが、後述するコマンド処理を行うことになる。
　コマンド処理部３２Ａは、ＩＰＭＩの仕様に準拠したコマンドを受け付けると、受け付けたコマンドに対応する処理を実行する。このコマンドには、例えばＳＤＲレポジトリ２３ＡからＳＤＲを読み出すコマンドであるＧｅｔＳＤＲコマンドや、ＳＤＲレポジトリ２３ＡをリザーブするコマンドであるＲｅｓｅｒｖｅ　ＳＤＲ　Ｒｅｐｏｓｉｔｏｒｙコマンドがある。デバイス部３３は、コマンド処理部３２Ａによって処理されるコマンドに応じて、ＳＤＲレポジトリ２３Ａ等の各種デバイスにアクセスする。ここで、ＧｅｔＳＤＲコマンドのデータ構造について、図３を参照しながら説明する。図３（Ａ）では、ＧｅｔＳＤＲコマンドのリクエストデータのデータ構造を示し、図３（Ｂ）では、ＧｅｔＳＤＲコマンドのレスポンスデータのデータ構造を示す。
　図３（Ａ）に示すように、ＧｅｔＳＤＲコマンドのリクエストデータには、リザーブＩＤ６ａ、レコードＩＤ６ｂ、オフセット６ｃ及び読出バイト数６ｄが含まれる。リザーブＩＤ６ａは、リザーブするＳＤＲの識別ＩＤを示す。リザーブＩＤ６ａには、０バイト目にリザーブＩＤの下位のバイト、１バイト目にリザーブＩＤの上位のバイトが設定される。レコードＩＤ６ｂは、読み出すＳＤＲの識別ＩＤを示す。レコードＩＤ６ｂには、２バイト目にレコードＩＤの下位のバイト、３バイト目にレコードＩＤの上位のバイトが設定される。オフセット６ｃは、レコードＩＤ６ｂに対応するレコードのうちデータを読み出す開始バイトを示す。読出バイト数６ｄは、読み出すバイト数を示す。
　図３（Ｂ）に示すように、ＧｅｔＳＤＲコマンドのレスポンスデータは、完了コード７ａ、次レコードＩＤ７ｂ及び読出データ７ｃを含む。完了コード７ａは、センサの属性情報の読み出し結果を示す。完了コード７ａには、例えば読み出し結果が正常であることを示す「０」及び異常であることを示す「１」が設定される。次レコードＩＤ７ｂは、読み出したレコードＩＤ６ｂに対応するレコードの次のレコードのレコードＩＤを示す。読出データ７ｃには、リクエストデータのレコードＩＤ６ｂに対応するレコードから読み出された属性情報が設定される。
　コマンド処理部３２Ａは、指定されたセンサの属性情報を読み出すべくＧｅｔＳＤＲコマンドのリクエストデータを取得し、取得したリクエストデータを解析し、解析結果に基づいてＳＤＲレポジトリの読み出しをデバイス部３３に対して依頼する。このＳＤＲレポジトリの読み出し依頼には、リクエストデータに設定されたレコードＩＤ６ｂ、オフセット６ｃ及び読出バイト数６ｄを含む。
　また、コマンド処理部３２Ａは、デバイス部３３から読み出し結果を取得し、取得した読み出し結果が正常である場合には、読み出し結果に基づいてレスポンスデータを作成する。そして、コマンド処理部３２Ａは、作成したレスポンスデータを論理チャネル部３１に出力する。一方、コマンド処理部３２Ａは、読み出し結果が異常である場合については、以下に詳述する。
　コマンド処理部３２Ａは、読出依頼部４１、属性情報取得部４２及び属性情報出力部４３を有する。読出依頼部４１は、読み出し結果が異常である場合に、この属性情報をスタンバイ側のＳＤＲレポジトリ２３Ｂから読み出させるべく、スタンバイ側に対して読み出し要求の実行を依頼する。読み出し結果が異常である場合とは、部品に搭載されたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出せない場合のことを意味する。具体的には、読出依頼部４１は、指定されたセンサの属性情報を後述する読出可否判定部４４によって読み出せないと判定された場合に、ＧｅｔＳＤＲコマンドのリクエストデータをスタンバイ側へ送信するように、ハンドラ部３４Ａに依頼する。
　属性情報取得部４２は、読み出し要求の実行依頼に対する応答をスタンバイ側から取得する。具体的には、属性情報取得部４２は、読出依頼部４１によって依頼されたＧｅｔＳＤＲコマンドに対するレスポンスデータをハンドラ部３４Ａから取得し、取得したレスポンスデータを属性情報出力部４３に出力する。レスポンスデータには、完了コード７ａが正常であれば、指定されたセンサの属性情報が読出データ７ｃに設定されている。
　属性情報出力部４３は、属性情報取得部４２によって取得されたレスポンスデータを読み出し要求の要求元に出力する。すなわち、属性情報出力部４３は、レスポンスデータが正常であれば、指定されたセンサの属性情報を含むレスポンスデータを読み出し要求の要求元であるクライアント３に出力する。
　デバイス部３３は、読出可否判定部４４を有する。読出可否判定部４４は、コマンド処理部３２ＡからのＳＤＲレポジトリの読み出し依頼に応じたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出せるか否かを判定する。具体的には、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａに含まれるＳＤＲの管理情報を記憶するＳＤＲ管理情報２５に基づいて、ＳＤＲレポジトリ２３Ａがリザーブ状態であるか否かを判定する。
　ここで、ＳＤＲ管理情報２５のデータ構造について、図４を参照しながら説明する。図４は、ＳＤＲ管理情報のデータ構造の一例を示す図である。図４に示すように、ＳＤＲ管理情報２５は、総レコード数２５ａ、リザーブＩＤ２５ｂ、開始レコードＩＤ２５ｃ及び最後レコードＩＤ２５ｄを対応付けて記憶する。総レコード数２５ａは、ＳＤＲの総数を示す。リザーブＩＤ２５ｂは、リザーブ状態のレコードＩＤを示す。開始レコードＩＤ２５ｃは、開始レコードのレコードＩＤを示す。終了レコードＩＤ２５ｄは、終了レコードのレコードＩＤを示す。すなわち、読出可否判定部４４は、ＳＤＲレポジトリの読み出し依頼に含まれるレコードＩＤ６ｂがＳＤＲ管理情報２５のリザーブＩＤ２５ｂと一致するか否かを判定する。
　読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがリザーブ状態であると判定した場合には、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、リザーブ状態を理由とした異常である旨の読み出し結果を読出依頼部４１に通知する。また、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがリザーブ状態でないと判定した場合には、ＳＤＲレポジトリ２３Ａがビジー状態であるか否かを判定する。読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがビジー状態であると判定した場合には、現在ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、ビジー状態を理由とした異常の読み出し結果を読出依頼部４１に通知する。また、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがビジー状態でないと判定した場合には、指定されたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出す。
　また、読出可否判定部４４は、読み出した属性情報が破損しているか否かを判定する。また、読出可否判定部４４は、読み出した属性情報が破損していると判定した場合には、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せなかったと判断し、ＳＤＲの破損を理由とした異常である旨の読み出し結果を読出依頼部４１に通知する。また、読出可否判定部４４は、読み出した属性情報が破損していないと判定した場合には、読み出したセンサの属性情報を含んだ正常である読み出し結果をコマンド処理部３２Ａに出力する。
　ハンドラ部３４Ａは、コマンド処理部３２Ａと二重化機構２６とのインタフェースである。具体的には、ハンドラ部３４Ａは、読出依頼部４１から依頼されたＧｅｔＳＤＲコマンドのリクエストデータを、二重化機構２６を介してスタンバイ側に対して送信する。また、ハンドラ部３４Ａは、スタンバイ側によって処理されたＧｅｔＳＤＲコマンドに対するレスポンスデータを属性情報取得部４２に出力する。
　スタンバイ側の監視制御装置１Ｂは、監視制御装置１Ａとほぼ同一の構成を示すので、監視制御装置１Ａと同一の構成については同一符号を示すことで、その重複する構成の説明については省略する。監視制御装置１Ｂが監視制御装置１Ａと異なるところは、ハンドラ部３４Ａがハンドラ部３４Ｂに変更され、ＳＤＲレポジトリ２３ＡがＳＤＲレポジトリ２３Ｂに変更された点である。また、監視制御装置１Ｂが監視制御装置１Ａと異なるところは、コマンド処理部３２Ｂに読出依頼受付部５１及び属性情報通知部５２を備える点である。
　ＳＤＲレポジトリ２３Ｂは、前述したとおり、アクティブ側のＳＤＲレポジトリ２３Ａと同期をとっている。すなわち、ＳＤＲレポジトリ２３ＢとＳＤＲレポジトリ２３Ａとは、相互に同等の属性情報を保持する。
　ハンドラ部３４Ｂは、コマンド処理部３２Ｂと二重化機構２６とのインタフェースである。具体的には、ハンドラ部３４Ｂは、アクティブ側から依頼されたＧｅｔＳＤＲコマンドのリクエストデータを、スタンバイ側の二重化機構２６を介して取得し、取得したリクエストデータを読出依頼受付部５１に出力する。また、ハンドラ部３４Ｂは、属性情報通知部５２によって通知されたレスポンスデータを、二重化機構２６を介してアクティブ側に対して通知する。
　読出依頼受付部５１は、ハンドラ部３４ＢからＧｅｔＳＤＲコマンドのリクエストデータを受け付け、受け付けたリクエストデータを解析し、解析結果に基づいてＳＤＲレポジトリの読み出しをデバイス部３３に対して依頼する。属性情報通知部５２は、デバイス部３３から読み出し結果を取得し、取得した読み出し結果に基づいてレスポンスデータを作成する。そして、コマンド処理部３２Ｂは、作成したレスポンスデータをハンドラ部３４Ｂに対して出力する。レスポンスデータには、完了コード７ａが正常であれば、指定されたセンサの属性情報が読出データ７ｃに設定されることとなる。
［実施例２に係る監視制御処理の手順］
　次に、監視制御処理のシーケンスを、図５を参照して説明する。図５は、実施例２に係る監視制御処理の手順を示すフローチャートである。
　まず、コマンド処理部３２Ａは、クライアント３からリクエストを受け付けたか否かを判定する（ステップＳ１１）。そして、コマンド処理部３２Ａは、リクエストを受け付けていないと判定した場合には（ステップＳ１１Ｎｏ）、リクエストを受け付けるまで待つ。一方、コマンド処理部３２Ａは、リクエストを受け付けたと判定した場合には（ステップＳ１１Ｙｅｓ）、受け付けたリクエストがＧｅｔＳＤＲコマンドであるか否かを判定する（ステップＳ１２）。
　そして、コマンド処理部３２Ａは、受け付けたリクエストがＧｅｔＳＤＲコマンドでないと判定した場合には（ステップＳ１２Ｎｏ）、該当するリクエストのコマンド処理を実行する（ステップＳ１３）。一方、コマンド処理部３２Ａは、受け付けたリクエストがＧｅｔＳＤＲコマンドであると判定した場合には（ステップＳ１２Ｙｅｓ）、読出可否判定部４４が、ＳＤＲレポジトリ２３Ａがリザーブ状態であるか否かを判定する（ステップＳ１４）。
　そして、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがリザーブ状態であると判定した場合には（ステップＳ１４Ｙｅｓ）、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、ステップＳ１８に移行する。一方、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがリザーブ状態でないと判定した場合には（ステップＳ１４Ｎｏ）、ＳＤＲレポジトリ２３Ａがビジー状態であるか否かを判定する（ステップＳ１５）。
　そして、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがビジー状態であると判定した場合には（ステップＳ１５Ｙｅｓ）、現在ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、ステップＳ１８に移行する。一方、読出可否判定部４４は、ＳＤＲレポジトリ２３Ａがビジー状態でないと判定した場合には（ステップＳ１５Ｎｏ）、ＧｅｔＳＤＲコマンドで指定されたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出す（ステップＳ１６）。
　続いて、読出可否判定部４４は、読み出した属性情報が破損しているか否かを判定する（ステップＳ１７）。読出可否判定部４４は、読み出した属性情報が破損していないと判定した場合には（ステップＳ１７Ｎｏ）、属性情報を読み出せたと判断し、ステップＳ２０に移行する。
　一方、読出可否判定部４４は、読み出した属性情報が破損していると判定した場合には（ステップＳ１７Ｙｅｓ）、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せなかったと判断し、ステップＳ１８に移行する。
　続いて、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せない場合には、読出依頼部４１が、ＧｅｔＳＤＲコマンドのリクエストデータをスタンバイ側に送信する（ステップＳ１８）。すなわち、前述したように、ＳＤＲレポジトリ２３Ａがリザーブ状態であったり、ＳＤＲレポジトリ２３Ａがビジー状態であったり、読み出した属性情報が破損していたりした場合がある。この場合に、読出依頼部４１は、センサの属性情報をスタンバイ側で読み出させるべく、スタンバイ側に対して読み出し要求の実行を依頼する。
　その後、属性情報取得部４２は、ＧｅｔＳＤＲコマンドに対するＳＤＲ情報（レスポンスデータ）をスタンバイ側から取得する（ステップＳ１９）。すなわち、属性情報取得部４２は、レスポンスデータの完了コード７ａが正常であることを示す値（例えば、「０」）であれば、スタンバイ側のＳＤＲレポジトリ２３Ｂから読み出されたセンサの正常な属性情報を取得することとなる。
　その後、属性情報出力部４３は、レスポンスデータを、ＧｅｔＳＤＲコマンドをリクエストしたクライアント３に返信する（ステップＳ２０）。
［ＳＤＲレポジトリがビジーである場合における監視制御処理のシーケンス］
　次に、アクティブ側のＳＤＲレポジトリ２３Ａがビジーである場合における監視制御処理のシーケンスを、図６を参照して説明する。図６は、ＳＤＲレポジトリがビジーである場合における監視制御処理のシーケンス図である。
　まず、クライアント３Ａは、センサの属性情報を読み出すべくＧｅｔＳＤＲコマンドをサーバ装置１０Ａに発行する（ステップＳ３１）。すると、アクティブ側のコマンド処理部３２Ａは、取得したＧｅｔＳＤＲコマンドのリクエストデータに基づいて、ＳＤＲレポジトリの読み出しをデバイス部３３に対して依頼する（ステップＳ３２）。
　そして、デバイス部３３の読出可否判定部４４は、ＳＤＲレポジトリの読み出し依頼に応じたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出せるか否かを判定する。具体的には、読出可否判定部４４は、読み出し依頼のあったＳＤＲの読み出しを試みる。ここでは、読み出しを試みたＳＤＲがビジーであるので、読出可否判定部４４は、現在ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、ビジー状態を理由とした異常である旨の読み出し結果を読出依頼部４１に通知する（ステップＳ３３）。
　続いて、コマンド処理部３２Ａの読出依頼部４１は、読み出し結果が異常であるので、ＧｅｔＳＤＲコマンドのリクエストデータをスタンバイ側へ送信するように、ハンドラ部３４Ａに依頼する（ステップＳ３４）。そして、ハンドラ部３４Ａは、読出依頼部４１から依頼されたＧｅｔＳＤＲコマンドのリクエストデータを、二重化機構２６を介してスタンバイ側のハンドラ部３４Ｂに送信する（ステップＳ３５～Ｓ３７）。
　続いて、スタンバイ側のハンドラ部３４Ｂは、自己側の二重化機構２６から送信されたＧｅｔＳＤＲコマンドのリクエストデータをコマンド処理部３２Ｂの読出依頼受付部５１に出力する（ステップＳ３８）。そして、読出依頼受付部５１は、ハンドラ部３４Ｂから受け付けたＧｅｔＳＤＲコマンドのリクエストデータに基づいて、ＳＤＲレポジトリの読み出しをデバイス部３３に対して依頼する（ステップＳ３９）。
　続いて、スタンバイ側のデバイス部３３は、ＳＤＲレポジトリの読み出し依頼のあったＳＤＲの読み出しを試み、読み出し結果をコマンド処理部３２Ｂの属性情報通知部５２に返す（ステップＳ４０）。そして、属性情報通知部５２は、デバイス部３３から読み出し結果を取得し、取得した読み出し結果に基づいてレスポンスデータを作成し、作成したレスポンスデータをハンドラ部３４Ｂに通知する（ステップＳ４１）。
　そして、スタンバイ側のハンドラ部３４Ｂは、属性情報通知部５２から通知されたレスポンスデータを、二重化機構２６を介してアクティブ側のハンドラ部３４Ａに送信する（ステップＳ４２～Ｓ４４）。そして、アクティブ側のハンドラ部３４Ａは、自己側の二重化機構２６から送信されたレスポンスデータをコマンド処理部３２Ａの属性情報取得部４２に戻す（ステップＳ４５）。そして、コマンド処理部３２Ａの属性情報出力部４３は、属性情報取得部４２によって取得されたレスポンスデータをクライアント３Ａに返す（ステップＳ４６）。
　なお、図６では、アクティブ側のＳＤＲレポジトリ２３Ａがビジーである場合における監視制御処理のシーケンスについて説明した。図６では、これに限定されるものではなく、アクティブ側のＳＤＲレポジトリ２３Ａから読み出されたＳＤＲが破損している場合であっても良い。この場合には、ステップＳ３３の読出可否判定部４４は、読み出し依頼のあったＳＤＲの読み出しを試みる。そして、読出可否判定部４４は、読み出したＳＤＲが破損しているので、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せなかったと判断し、ＳＤＲの破損を理由とした異常である旨の読み出し結果を読出依頼部４１に通知するものとすれば良い。
［ＳＤＲレポジトリがリザーブされている場合における監視制御処理のシーケンス］
　次に、アクティブ側のＳＤＲレポジトリ２３Ａがリザーブされている場合における監視制御処理のシーケンスを、図７を参照して説明する。図７は、ＳＤＲレポジトリがリザーブされている場合における監視制御処理のシーケンス図である。
　まず、クライアント３Ａは、ＳＤＲレポジトリ２３ＡをリザーブすべくＲｅｓｅｒｖｅＳＤＲ　Ｒｅｐｏｓｉｔｏｒｙコマンドをサーバ装置１０Ａに発行する（ステップＳ５１）。すると、アクティブ側のコマンド処理部３２Ａは、取得したＲｅｓｅｒｖｅ　ＳＤＲ　Ｒｅｐｏｓｉｔｏｒｙコマンドのリクエストデータに基づいて、ＳＤＲレポジトリのリザーブをデバイス部３３に対して依頼する（ステップＳ５２）。
　そして、デバイス部３３は、ＳＤＲレポジトリのリザーブ依頼に応じて、ＳＤＲレポジトリ２３Ａをリザーブ状態にし、リザーブ正常となるレスポンスデータをコマンド処理部３２Ａに返す（ステップＳ５３）。さらに、コマンド処理部３２Ａは、デバイス部３３から取得したレスポンスデータをクライアント３Ａに返す（ステップＳ５４）。
　その後、クライアント３Ｂは、センサの属性情報を読み出すべくＧｅｔＳＤＲコマンドをサーバ装置１０Ａに発行する（ステップＳ５５）。すると、アクティブ側のコマンド処理部３２Ａは、取得したＧｅｔＳＤＲコマンドのリクエストデータに基づいて、ＳＤＲレポジトリの読み出しをデバイス部３３に対して依頼する（ステップＳ５６）。
　そして、デバイス部３３の読出可否判定部４４は、ＳＤＲレポジトリの読み出し依頼に応じたセンサの属性情報をＳＤＲレポジトリ２３Ａから読み出せるか否かを判定する。ここでは、ＳＤＲレポジトリ２３Ａがリザーブ状態であるので、読出可否判定部４４は、ＳＤＲレポジトリ２３ＡからＳＤＲを読み出せないと判断し、リザーブ状態を理由とした異常である旨の読み出し結果を読出依頼部４１に通知する（ステップＳ５７）。
　以降の処理（ステップＳ５８～Ｓ７０までの処理）については、図６に示すＳＤＲレポジトリがビジーである場合での監視制御処理（ステップＳ３４～Ｓ４６までの処理）と同一内容の処理動作を実行するため、その重複する処理内容の説明については省略する。
［実施例２の効果］
　上記実施例２によれば、ＩＰＭＩ制御部２４Ａの読出可否判定部４４が、読み出し要求に応じて、部品に関する属性情報をＳＤＲレポジトリ２３Ａから読み出せるか否かを判定する。そして、ＩＰＭＩ制御部２４Ａの読出依頼部４１が、読出可否判定部４４によって部品に関する属性情報をＳＤＲレポジトリ２３Ａから読み出せないと判定された場合には、スタンバイ側に対して読み出し要求の実行を依頼する。そして、ＩＰＭＩ制御部２４Ａの属性情報取得部４２は、読出依頼部４１によってスタンバイ側に対して依頼された読み出し要求に対する属性情報を、スタンバイ側から取得する。かかる構成によれば、ＩＰＭＩ制御部２４Ａは、部品に関する属性情報をＳＤＲレポジトリ２３Ａから読み出せないと判定した場合には、読み出せなかった属性情報をスタンバイ側のＳＤＲレポジトリ２３Ｂから取得することとした。この結果、ＩＰＭＩ制御部２４Ａは、部品に関する属性情報の読み出し効率を向上させることができる。
　また、上記実施例２によれば、ＩＰＭＩ制御部２４Ａの属性情報出力部４３は、属性情報取得部４２によって取得された属性情報を読み出し要求の要求元に出力する。かかる構成によれば、属性情報出力部４３は、取得された属性情報を要求元に出力することとした。このため、要求元では、アクティブ側及びスタンバイ側を意識しないで、要求した属性情報を取得できる。
　また、上記実施例２によれば、ＩＰＭＩ制御部２４Ａの読出可否判定部４４は、ＳＤＲレポジトリ２３Ａのビジー状態の有無によってＳＤＲレポジトリ２３Ａから属性情報を読み出せるか否かを判定する。かかる構成によれば、読出可否判定部４４がビジー状態であることによって属性情報を読み出せないと判定した場合であっても、ＩＰＭＩ制御部２４Ａがこの属性情報をスタンバイ側から読み出せれば、ビジー状態による待ち時間を回避できる。この結果、読出可否判定部４４は、属性情報の読み出し効率を向上させることができる。
　また、上記実施例２によれば、ＩＰＭＩ制御部２４ＡのＳＤＲレポジトリ２３Ａは、部品に搭載されたセンサに関する属性情報を記憶する。かかる構成によれば、ＩＰＭＩ制御部２４Ａは、部品に搭載されたセンサに関する属性情報の読み出し効率を向上させることができる。
［プログラム等］
　なお、サーバ装置１０Ａは、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した二重化されたＩＰＭＩ制御部２４Ａ等の各機能を搭載することによって実現することができる。
　また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、属性情報取得部４２と属性情報出力部４３とを１個の部として統合しても良い。一方、読出可否判定部４４を、リザーブ状態であるか否かを判定するリザーブ状態判定部とビジー状態であるか否かを判定するビジー状態判定部と読み出した属性情報が破損しているか否かを判定する属性情報破損判定部とに分散しても良い。また、ＳＤＲレポジトリ２３ＡやＳＤＲ管理情報２５等の記憶部をサーバ装置１０Ａの外部装置としてネットワーク経由で接続するようにしても良い。
　また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図８を用いて、図２に示したＩＰＭＩ制御部２４Ａと同様の機能を有する監視制御プログラムを実行するコンピュータの一例を説明する。
　図８は、監視制御プログラムを実行するコンピュータを示す図である。図８に示すように、コンピュータ１０００は、ＲＡＭ（Random　Access　Memory）１０１０と、キャッシュ１０２０と、ＨＤＤ１０３０と、ＣＰＵ（Central　Processing　Unit）１０４０及びバス１０５０とを有する。ＲＡＭ１０１０、キャッシュ１０２０、ＨＤＤ１０３０、ＣＰＵ１０４０は、バス１０５０によって接続されている。
　そして、ＨＤＤ１０３０には、図２に示したＩＰＭＩ制御部２４Ａと同様の機能を有する監視制御プログラム１０３１が記憶される。また、ＨＤＤ１０３０には、図２に示したＳＤＲレポジトリ２３Ａに対応するＳＤＲレポジトリ情報１０３２及び図２に示したＳＤＲ管理情報２５に対応するＳＤＲ管理情報１０３３が記憶される。
　そして、ＣＰＵ１０１０が監視制御プログラム１０３１をＨＤＤ１０３０から読み出してＲＡＭ１０１０に展開することにより、監視制御プログラム１０３１は、監視制御プロセス１０１１として機能するようになる。そして、監視制御プロセス１０１１は、ＳＤＲレポジトリ情報１０３２及びＳＤＲ管理情報１０３３から読み出した情報等を適宜ＲＡＭ１０１０上の自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種データ処理を実行する。
　なお、上記の監視制御プログラム１０３１は、必ずしもＨＤＤ１０３０に格納されている必要はなく、ＣＤ－ＲＯＭ等の記憶媒体に記憶されたこのプログラムを、コンピュータ１０００が読み出して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等を介してコンピュータ１０００に接続される他のコンピュータ（またはサーバ）等にこのプログラムを記憶させておいても良い。この場合には、コンピュータ１０００がこれらからプログラムを読み出して実行する。
　１、１Ａ、１Ｂ　監視制御装置
　１０、１０Ａ　サーバ装置
　３Ａ、３Ｂ　クライアント
　４Ａ　システムボード
　４Ｂ　電源
　４Ｃ　ＩＯ装置
　４Ｄ　ファン
　２１　ドライバ部
　２２　ポート
　２３Ａ、２３Ｂ　ＳＤＲレポジトリ
　２４Ａ、２４Ｂ　ＩＰＭＩ制御部
　２５　ＳＤＲ管理情報
　２６　二重化機構
　３１　論理チャネル部
　３２Ａ、３２Ｂ　コマンド処理部
　３３　デバイス部
　３４Ａ、３４Ｂ　ハンドラ部
　４１　読出依頼部
　４２　属性情報取得部
　４３　属性情報出力部
　４４　読出可否判定部
　５１　読出依頼受付部
　５２　属性情報通知部

Claims (8)

  1. 　サーバ装置に内蔵する部品に関する属性情報を記憶する記憶部と、
    　外部から前記部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、前記記憶部から前記属性情報を読み出せるか否かを判定し、前記属性情報を読み出せないと判定した場合に、前記読み出し要求に応じた属性情報を前記記憶部と同期した他の記憶部から読み出させるべく、自己と二重化された待機中の制御部に対して前記読み出し要求の実行を依頼する制御部と
    　を有することを特徴とする監視制御装置。
  2. 　前記制御部は、
    　前記読み出し要求に応じて、前記部品に関する属性情報を前記記憶部から読み出せるか否かを判定する読出可否判定部と、
    　前記読出可否判定部によって前記部品に関する属性情報を前記記憶部から読み出せないと判定された場合に、前記待機中の制御部に対して前記読み出し要求の実行を依頼する読出依頼部と、
    　前記読出依頼部によって依頼された前記読み出し要求の実行に対する属性情報を前記待機中の制御部から取得する属性情報取得部と
    　を有することを特徴とする請求項１に記載の監視制御装置。
  3. 　前記属性情報取得部によって取得された属性情報を前記読み出し要求の要求元に出力する属性情報出力部
    　を有することを特徴とする請求項２に記載の監視制御装置。
  4. 　前記読出可否判定部は、
    　前記記憶部のビジー状態の有無によって前記記憶部から前記属性情報を読み出せるか否かを判定することを特徴とする請求項２に記載の監視制御装置。
  5. 　前記記憶部は、
    　前記部品に搭載されたセンサに関する属性情報を記憶することを特徴とする請求項１に記載の監視制御装置。
  6. 　サーバ装置に内蔵する部品の監視を制御する運用中の制御部と、
    　前記運用中の制御部と二重化された待機中の制御部と、
    　前記部品に関する属性情報を記憶する運用中の記憶部と、
    　前記運用中の記憶部と同期させて前記部品に関する属性情報を記憶する待機中の記憶部と、
    　前記運用中の制御部は、
    　外部から前記部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、前記運用中の記憶部から前記属性情報を読み出せるか否かを判定し、前記属性情報を読み出せないと判定した場合に、前記読み出し要求に応じた属性情報を前記待機中の記憶部から読み出させるべく、前記待機中の制御部に対して前記読み出し要求の実行を依頼することを特徴とするサーバ装置。
  7. 　監視制御装置がサーバ装置に内蔵する部品を監視する監視制御方法であって、
    　外部から前記部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、前記部品に関する属性情報を記憶する記憶部から前記属性情報を読み出せるか否かを判定する判定工程と、
    　前記判定工程によって前記部品に関する属性情報を前記記憶部から読み出せないと判定された場合に、前記読み出し要求に応じた属性情報を前記記憶部と同期した他の記憶部から読み出させるべく、前記監視制御装置と二重化された待機中の監視制御装置に対して前記読み出し要求の実行を依頼する読出依頼工程と、
    　を含むことを特徴とする監視制御方法。
  8. 　外部から前記部品に関する属性情報の読み出し要求を検知すると、該読み出し要求に応じて、サーバ装置に内蔵する部品に関する属性情報を記憶する記憶部から前記属性情報を読み出せるか否かを判定する判定手順と、
    　前記判定手順によって前記部品に関する属性情報を前記記憶部から読み出せないと判定された場合に、前記読み出し要求に応じた属性情報を前記記憶部と同期した他の記憶部から読み出させるべく、自己と二重化された待機中の監視制御プログラムに対して前記読み出し要求の実行を依頼する読出依頼手順と、
    　をコンピュータに実行させることを特徴とする監視制御プログラム。
PCT/JP2010/061281 2010-07-01 2010-07-01 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム WO2012001809A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2012522408A JP5447669B2 (ja) 2010-07-01 2010-07-01 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム
EP10854106.1A EP2590079A1 (en) 2010-07-01 2010-07-01 Monitoring control device, server device, monitoring control method, and monitoring control program
PCT/JP2010/061281 WO2012001809A1 (ja) 2010-07-01 2010-07-01 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム
US13/724,502 US20130111022A1 (en) 2010-07-01 2012-12-21 Monitoring control device, server device and monitoring control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/061281 WO2012001809A1 (ja) 2010-07-01 2010-07-01 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/724,502 Continuation US20130111022A1 (en) 2010-07-01 2012-12-21 Monitoring control device, server device and monitoring control method

Publications (1)

Publication Number Publication Date
WO2012001809A1 true WO2012001809A1 (ja) 2012-01-05

Family

ID=45401562

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061281 WO2012001809A1 (ja) 2010-07-01 2010-07-01 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム

Country Status (4)

Country Link
US (1) US20130111022A1 (ja)
EP (1) EP2590079A1 (ja)
JP (1) JP5447669B2 (ja)
WO (1) WO2012001809A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013145315A1 (ja) * 2012-03-30 2013-10-03 富士通株式会社 監視装置、監視方法、および監視プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002157142A (ja) * 2000-11-20 2002-05-31 Nissin Electric Co Ltd 監視制御システムのデータ印字方法
JP2004280337A (ja) * 2003-03-14 2004-10-07 Toshiba Corp プラントデータ収集装置
JP2009025868A (ja) * 2007-07-17 2009-02-05 Yamatake Corp 通信インタフェースモジュールおよびプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615218B2 (en) * 1998-07-17 2003-09-02 Sun Microsystems, Inc. Database for executing policies for controlling devices on a network
US7254575B1 (en) * 2004-03-31 2007-08-07 Emc Corporation System and methods for implementing an adaptive object model
JP5282628B2 (ja) * 2009-03-30 2013-09-04 富士通株式会社 ネットワーク監視制御装置及び監視制御方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002157142A (ja) * 2000-11-20 2002-05-31 Nissin Electric Co Ltd 監視制御システムのデータ印字方法
JP2004280337A (ja) * 2003-03-14 2004-10-07 Toshiba Corp プラントデータ収集装置
JP2009025868A (ja) * 2007-07-17 2009-02-05 Yamatake Corp 通信インタフェースモジュールおよびプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013145315A1 (ja) * 2012-03-30 2013-10-03 富士通株式会社 監視装置、監視方法、および監視プログラム

Also Published As

Publication number Publication date
US20130111022A1 (en) 2013-05-02
JPWO2012001809A1 (ja) 2013-08-22
EP2590079A1 (en) 2013-05-08
JP5447669B2 (ja) 2014-03-19

Similar Documents

Publication Publication Date Title
CN111431740B (zh) 数据的传输方法、装置、设备及计算机可读存储介质
US7225356B2 (en) System for managing operational failure occurrences in processing devices
US20110083021A1 (en) Reliable setting of voltage and frequency in a microprocessor
CN113626286B (zh) 多集群实例处理方法、装置、电子设备及存储介质
US7499987B2 (en) Deterministically electing an active node
US9092396B2 (en) Standby system device, a control method, and a program thereof
CN110633046A (zh) 一种分布式系统的存储方法、装置、存储设备及存储介质
US8499080B2 (en) Cluster control apparatus, control system, control method, and control program
CN111031126B (zh) 集群缓存共享方法、系统、设备及存储介质
JP5447669B2 (ja) 監視制御装置、サーバ装置、監視制御方法及び監視制御プログラム
US8677323B2 (en) Recording medium storing monitoring program, monitoring method, and monitoring system
KR20210044281A (ko) 클라우드 저하 모드에서 지속적인 디바이스 동작 안정성을 보장하기 위한 방법 및 장치
JP2009271858A (ja) 計算機システム及びプログラム
JP5268820B2 (ja) 監視装置用プログラムの書き換え方法
JP6786835B2 (ja) 管理装置、サーバ、シンクライアントシステム、管理方法及びプログラム
JP5691248B2 (ja) タスク引継プログラム、処理装置及びコンピュータ・システム
CN117033084B (zh) 虚拟机备份方法、装置、电子设备及存储介质
JP2019168845A (ja) 情報処理装置とその制御方法
JP5609272B2 (ja) サーバ装置、サーバシステム及びサーバ装置の制御方法
JP5217988B2 (ja) 情報処理装置、プログラムおよび情報処理装置の制御方法
JP5262492B2 (ja) クラスタシステム及びコマンド競合制御方法
CN116521416A (zh) 一种信息处理方法、装置、设备及介质
CN117909183A (zh) 一种i2c设备监控方法、装置、设备及存储介质
CN116069564A (zh) 容器监控方法、装置、设备和介质
JP2011123681A (ja) フェイルオーバー制御方法

Legal Events

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

Ref document number: 10854106

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012522408

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2010854106

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE