KR101511542B1 - Mtehod for Handling Abnormal State of Module Type Data Center Ingra-structure - Google Patents

Abstract

A method for handling anomalous state of a modular data center infrastructure is provided. In an abnormal state processing method according to an embodiment of the present invention, when a virtual machine monitors a device in an abnormal state in the POD, another virtual machine controls other devices to solve the abnormal state. Accordingly, when an abnormality occurs in the equipment constituting the POD in the POD-based modular data center, the virtual machines in the POD can be interrelated and analyzed and processed.

Description

METHOD FOR PROCESSING A MODULAR DATA CENTER INFRASTRUCTURE Abnormal State < RTI ID = 0.0 >

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data center, and more particularly, to a method for processing an abnormal state occurring in a device constituting a data center.

A data center is a facility in which computer systems, communication equipment, and storage devices such as storage are installed. Data centers require large amounts of power as a core infrastructure for storing and distributing big data.

In addition, data sensor servers are sensitive to temperature and humidity, so they must be monitored and managed in real time to maintain proper temperature (16 to 24 degrees) and proper humidity (40 to 55 percent).

In addition, when the power supply is interrupted, there is a problem of information loss and service interruption, so the power supply status is also monitored and controlled.

Currently, a large number of devices constituting the data sensor are monitored and managed in a single management server. However, the processing speed may be too slow to take appropriate measures in a timely manner.

SUMMARY OF THE INVENTION The present invention has been made in order to solve the above problems, and it is an object of the present invention to provide an effective abnormal state processing method in a modular data center based on POD (Portable Optimized Datacenter).

According to an aspect of the present invention, there is provided an abnormal state processing method including: monitoring a first device in a POD (Portable Optimized Datacenter) of a first virtual machine; Notifying the second virtual machine of an abnormal state occurred in the first equipment by the first virtual machine; And controlling, by the second virtual machine, the second device in the POD to resolve the abnormal state.

The method may further include the step of the second virtual machine notifying the first virtual machine of a message containing the operation state for solving the problem and the solution for the abnormal state, ; ≪ / RTI >

In addition, the second virtual machine may be a virtual machine for monitoring the status of the second equipment.

According to another aspect of the present invention, there is provided an abnormal state processing method comprising the steps of: inquiring of a first virtual machine whether the abnormal state has been eliminated; And notifying the first virtual machine of the current status of the first device to the second virtual machine.

In addition, the first virtual machine and the second virtual machine may include those operating independently.

The first virtual machine and the second virtual machine can work together with one dashboard system that receives monitoring data from a plurality of PODs.

Also, the first equipment may be one of a CRAC, a UPS & PDU, and an IT rack, and the second equipment may be one of a CRAC, a UPS & PDU, and an IT rack.

Meanwhile, according to another embodiment of the present invention, a data center system includes: a first virtual machine for monitoring a first device in a POD; And a second virtual machine for controlling the second device to resolve the abnormal state when the first virtual machine is informed of the abnormal state occurring in the first device.

As described above, according to the embodiments of the present invention, when an error occurs in the equipment constituting the POD in the POD-based modular data center, the virtual machines in the POD can be interrelated and analyzed and processed.

In addition, since the virtual machines are divided, it is possible to prevent a failure occurring in one virtual machine from affecting another virtual machine.

1 illustrates an overall system of a data center to which the present invention is applicable;
2 is an enlarged view of one of the PODs shown in FIG. 1,
Figs. 3 to 7 are drawings provided for explanation of a processing procedure when a failure occurs in a VM, Fig.
FIG. 8 is a diagram provided in the description of the detailed structure of a VM,
FIG. 9 is a diagram provided in the description of an agent system provided in equipment to be monitored,
10 is a diagram illustrating a process of sensing (collecting) and monitoring data of a device by a VM and an agent system,
11 is a diagram showing a process of processing a status abnormality (equipment failure) of a device and a message structure used therein,
FIGS. 12 to 18 are diagrams specifically illustrating a process for abnormality of a state of equipment.

Hereinafter, the present invention will be described in detail with reference to the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram showing an entire system of a data center to which the present invention is applicable; FIG. The data center to which the present invention can be applied includes a plurality of POD (Portable Optimized Datacenter) (POD # 1 to POD # n) and a dashboard system, as shown in FIG.

The data center is divided into POD units and constructed / operated. In addition, the data center monitors and manages failures on a per-POD basis, while administrators can monitor and manage all PODs with a dashboard system.

FIG. 2 is an enlarged view of one of the PODs shown in FIG. 1. FIG. As shown in FIG. 2, the POD includes a CRAC, a UPS & PDU, and an IT Rack (200-0 to 200-9, ...).

In addition, the POD has an independent DCMM (Data Center Monitor Middleware) system. That is, there is a DCMM system for each POD. POD's DCMM systems work with the dashboard system.

The DCMM system monitors and manages the status of the devices (CRAC, UPS & PDU, IT Rack) (200-0 ~ 200-9, ...) that make up the POD. And has specialized virtual machines.

Specifically, the DCMM system includes VMs (Virtual Machines) 100-0, 100-1 and 100-2, VL (Virtual Layer) 100-3, and MEP (Multi-core Embedded Platform) ).

The VM # 0 100-0 is a virtual machine for monitoring / managing the CRACs 200-0, 200-4, 200-5, 200-6, ... installed in the POD, and the VM # 1 100 -1 is a virtual machine for monitoring / managing the UPS & PDUs 200-1, 200-7, ... installed in the POD and the VM # 2 100-2 is a virtual machine for monitoring / managing the IT racks 200- 2, 200-3, 200-8, 200-9, ...).

Since the VMs that monitor and manage the POD devices operate independently, any VMs can operate normally without any problems in case of a VM failure.

On the other hand, the spare VMs 100-5, 100-6 and 100-7 are operated as shown in FIG. 3 in case a failure occurs in the VM. As shown in FIG. 4, the active base VMs 100-0, 100-1, and 100-2 collect data from devices, DB, monitor / manage them, and passive-based VMs 100- 5, 100-6, and 100-7) respectively replicate (back up) them.

4, the passive base VMs 100-5, 100-6, and 100-7 are connected to the VMs 100-0, 100-1, and 100-7 of the active base through the FT manager FT_Manager, 2) and Heartbeat, and checks whether the active base VMs 100-0, 100-1, 100-2 are operating normally.

In order to explain the processing procedure when a VM in the active base fails, it is assumed that a failure occurs in the VM # 0 (100-0) as shown in Fig. When a fault occurs in the VM # 0 (100-0), the duplication VM # 1 (100-5) detects this through the heartbeat.

Thereafter, as shown in FIG. 6, the system memory of the failed VM # 0 (100-0) is recovered and the replica VM # 1 (100-5) is changed to Active Base to monitor / manage the CRACs of the POD do.

Next, as shown in Fig. 7, a new duplicate VM 100-8 is created in the passive base, and the VM # 0 (100-5) is copied (backed up) and checked whether it is operating normally.

Hereinafter, the detailed structure of the VMs will be described in detail with reference to FIG. Since only the VMs to be monitored / managed are different and their structures can be implemented in the same manner, one VM is represented as a representative in FIG.

As shown in FIG. 8, the VM includes an SNMP module, a check_snmp module, a DCM daemon, a DCMM, a DB, a DB manager, an FT manager, and an OCM (Overstate Control Module).

DCMM creates configuration files (cfg files) used for target device monitoring per device (host), and the DCM daemon manages periodic monitoring. The configuration file serves as a data collection object that contains commands related to the monitoring of the device.

The check_snmp module obtains data necessary for monitoring by passing the configuration file created by DCMM to the monitoring target device (host) through SNMP. The SNMP module is a module that performs networking with the equipment to be monitored through Ethernet.

The DB administrator stores the data acquired by the check_snmp module in the DB. In addition, the DB administrator provides data stored in the DB to the dashboard system so that the administrator can directly check the status of the devices through the dashboard system.

The FT manager is a module for transferring Heartbeats with other VMs, and the OCM performs fault management and control, which will be described in detail later.

FIG. 9 is a diagram provided for explaining an agent system provided in equipment to be monitored. Like the VM, the agent system is also specialized for the kind of equipment, but its structure is the same.

All equipment has an agent system. The agent system collects data about the equipment and delivers it to the VM's DCMM. The collected data includes temperature, humidity, power consumption, etc. It is needless to say that other data may be further included.

The agent system includes an SNMP agent, a subagent, and a Management Information Base (MIB), as shown in FIG.

The SNMP agent establishes and maintains a communication link with the VM's SNMP, and the handler of the subagent senses (collects) the data requested in the configuration file received from the VM. The MIB stores information that is referred to in data collection / management.

FIG. 10 shows a process of sensing (collecting) and monitoring the data of the device by the VM and the agent system.

As shown in FIG. 10, monitoring data (monitoring data) is collected from an object using a configuration file (keti_host) generated by the DCMM. The data collected includes temperature, humidity, power consumption, and the like.

Then, the check_snmp module of the VM requests / collects the above data to the agent system (SNMP_GET, SNMP_RESPONSE) and stores it in the DB (Insertr data). Thereafter, all or a part of the data stored in the DB (for example, data requested by the administrator) is reported to the dashboard system (select data). The data delivered to the dashboard system is displayed to the administrator in various forms.

The left side of FIG. 11 shows a process for processing a state abnormality (equipment failure) in the equipment. As shown in FIG. 11, when a status abnormality is detected in a device as a monitoring object, the DCM of the VM first analyzes it and delivers the necessary messages for resolution.

The format of the messages used in this process is shown on the right side of FIG. As shown, the messages used for state anomaly control include an Alert message, a handle message, a control message, and a check message.

In the messages, "Msg Type" for indicating the type of message is listed at the front. "Device Type" is a field indicating the type of equipment, such as CRAC, IT Rack, UPS & PDU. "Device ID" is an ID assigned to each device to specify the device.

"Error State" is a field indicating the type of state error (failure) occurring in the equipment, and "Error Information" is additional data necessary for processing the state error.

"Handle State" is a field indicating whether or not a state error can be solved, and "Handle Command" The "Control Command" contains the commands that are passed to the device for troubleshooting.

FIG. 12 specifically shows the processing of a state error (failure), and the message type and the transmission path are specified in FIGS. 13 to 18. FIG. In FIG. 12, it is assumed that a state abnormality (temperature abnormality) occurs in a specific IT rack.

The OCM of the IT Rack VM (VM # 2) detecting the state of the specific IT rack (FIG. 13) (FIG. 13) analyzes the state abnormality and sends an Alert message containing the detailed state information to the CRAC VM (VM # 0) (Fig. 15).

The OCM of the CRAC VM transmits a Handle message containing the resolvability and the operation for solving (when the status is resolved) to the OCM of the IT Rack VM (FIG. 16). Then, the OCM of the CRAC VM transmits a control message to the corresponding device (CRAC #n) for an error resolution (FIG. 17).

Next, the OCM of the CRAC VM transmits a check message to the OCM of the IT Rack VM to check whether the IT Rack is in a normal state (FIG. 18). The OCM in the IT Rack VM then sends an Alert message to the OCM in the CRAC VM, informing the device of its current status.

Since the IT Rack has experienced a temperature anomaly, the IT Rack VM's OCM has sent an Alert message to the OCM in the CRAC VM. If there is a power failure in the IT Rack, the OCM in the IT Rack VM sends an Alert message to the UPS & PDU to initiate a state anomaly procedure.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention.

POD # 1 to POD #n
Dashboard system
100-0, 100-1, 100-2: VM (Virtual Machine)
200-0, 200-4, 200-5, 200-6: CRAC
200-1, 200-7: UPS & PDU
200-2, 200-3, 200-8, 200-9: IT Rack

Claims (8)

The first virtual machine monitoring a first device at a Portable Optimized Datacenter (POD);
The first virtual machine notifying the second virtual machine of an abnormal state occurring in the first equipment; And
And the second virtual machine controlling the second device in the POD to resolve the abnormal state,
Wherein the second virtual machine comprises:
A virtual machine for monitoring the status of the second device,
Wherein the first virtual machine and the second virtual machine,
Operating independently,
And interworking with one dashboard system receiving monitoring data from a plurality of PODs.
The method according to claim 1,
Further comprising the step of the second virtual machine notifying the first virtual machine of a message containing the resolvability and the operation content for resolving the abnormal status.
delete The method according to claim 1,
The second virtual machine inquiring of the first virtual machine whether the abnormal state has been eliminated; And
And the first virtual machine notifies the second virtual machine of the current state of the first equipment.
delete delete The method according to claim 1,
Wherein the first equipment is one of a CRAC, a UPS & PDU, and an IT rack,
Wherein the second device is one of a CRAC, a UPS & PDU, and an IT rack.
A first virtual machine for monitoring a first device in a POD (Portable Optimized Datacenter); And
And a second virtual machine for controlling the second device to resolve the abnormal state when the first virtual machine is notified of the abnormal state occurring in the first device,
Wherein the second virtual machine comprises:
A virtual machine for monitoring the status of the second device,
Wherein the first virtual machine and the second virtual machine,
Operating independently,
Wherein the data center system interacts with one dashboard system that receives monitoring data from a plurality of PODs.

Images