KR20030006661A - Method and system for managing server failure - Google Patents

Abstract

PURPOSE: A method and system for managing a server trouble are provided to inform a trouble to a server manager, perform an emergency recovery, and suggest a method for dealing with the trouble by automatically sensing a trouble state of a server. CONSTITUTION: A CMS(Connection Management System,110) is mounted in a user server, manages resources in a system and an error event, etc., and checks/transmits a trouble. A CAS(Connection Accept Server,210) receives data transmitted from the CMS(110), and converts the data into normal data. A DPS(Data Passing Server,220) stores data being output from the CAS(210) in a database(230). An NDS(Network Diagnostic Server,240) is communicated with an NDC(Network Diagnostic Client) in a user server, checks a network trouble, inputs a trouble in the database(230), and outputs information with respect to a pre-set emergency state. A DAS(Data Analyze Server,250) processes and outputs various kinds of data for analyzing data stored in the database(230). An ACS(Automatic error Calling Server) is connected to a public network or the Internet and transmits information with respect to a pre-set emergency state being output in the NDS(240) and the DAS(250) to a wire/wireless telephone or an E-mail of a pre-set server manager.

Description

METHOD AND SYSTEM FOR MANAGING SERVER FAILURE}

The present invention relates to a user server management technology, and more particularly, to a server management method and system for preventing a server failure and quickly coping when a failure occurs.

In recent years, as computers become larger and faster, computer failures due to system errors, viruses, and the like frequently occur. In particular, in the case of a large server, failures due to various factors such as operation of various applications and data storage, reading, and transmission may occur frequently. Therefore, each company has a separate server administrator who manages these servers to manage them and to handle them in case of failure.

However, server management requires specialized skills, and the hiring of such specialized personnel requires considerable costs. Therefore, in particular, a small company does not employ a professional technician as the server administrator, but selects an appropriate person from the existing manpower of the company and maintains it as a server administrator. In such a case, server management is difficult to perform smoothly, and moreover, it is almost impossible to cope smoothly in case of server failure.

In addition, even if a server administrator with specialized skills is employed to manage the server, if the server administrator is remote from the server for business trips or the like, it is difficult for the server to be notified of the status of such a server quickly when the server fails. It was difficult to cope with the occurrence smoothly. Moreover, even when the server administrator is notified of the failure of the server, it is difficult to immediately deal with it because it is remote, which can result in enormous loss such as the server crashing.

Accordingly, a first object of the present invention is to provide a server management method and system for automatically detecting a failure state of a server.

It is a second object of the present invention to provide a server management method and system capable of efficiently notifying a server administrator when a server failure occurs.

It is a third object of the present invention to provide a server management method and system for solving a server failure by performing an emergency recovery when a server failure occurs.

It is a fourth object of the present invention to provide a server management method and system capable of analyzing the state of a server, predicting a future change in the state of the server, and suggesting a countermeasure therefor.

In order to achieve the above object, the present invention provides a system monitoring module for monitoring the server status in the user server and analyzing the failure factors in the event of a failure and classifying them into warning, danger, and emergency situations. Warnings and risks Disasters are automatically notified to the server administrator by e-mail, general telephone, mobile phone, etc., and emergency cases are automatically performed due to serious situations such as server downtime when left unattended. In addition, time series analysis is performed by database of the components representing the status of the user server, so that the current server system status can be grasped and diagnostic consulting on the matters to be noted and the measures to be taken in advance is provided.

1 is a schematic overall block diagram of a server management system according to an embodiment of the present invention;

2 is an exemplary diagram of a user output screen for managing a storage medium such as a hard disk according to an embodiment of the present invention.

3 is an exemplary diagram of a user output screen for CPU state management according to an embodiment of the present invention.

4 is an exemplary view of a user output screen for memory usage management according to an embodiment of the present invention.

5 is an exemplary view illustrating a user output screen for managing login authentication attempts according to an embodiment of the present invention.

6 is an exemplary diagram of a user output screen for managing swap usage according to an embodiment of the present invention.

7 is an exemplary view of a user output screen for process state management according to an embodiment of the present invention.

8 is an exemplary view of a user output screen for managing server user information according to an embodiment of the present invention.

9 is an exemplary diagram of a user output screen for managing host information according to an embodiment of the present invention.

10 is an exemplary diagram of a user output screen for managing a configuration file according to an embodiment of the present invention.

11 is an exemplary view of a user output screen for network failure management according to an embodiment of the present invention.

12 is an exemplary diagram of a user output screen for network management according to an embodiment of the present invention.

13 is an exemplary diagram of a user output screen for managing an important file according to an embodiment of the present invention.

14 is an exemplary view of a user output screen showing the overall server system status according to an embodiment of the present invention.

15 is an exemplary diagram of a user output screen for setting a server status level according to an embodiment of the present invention.

16 is a schematic flowchart of a server emergency automatic recovery control according to an embodiment of the present invention.

17 is a schematic flowchart of a server diagnostic consulting operation according to an embodiment of the present invention.

18 is an overall flowchart of a server management operation according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, specific details such as specific components are shown, which are provided to help a more general understanding of the present invention, and it is understood that these specific details may be changed or changed within the scope of the present invention. It is self-evident to those of ordinary knowledge in Esau.

1 is a schematic overall block diagram of a server management system according to an embodiment of the present invention. Referring to FIG. 1, the server management system according to the present invention first manages system internal resources and error events in the user server 100, and checks for abnormalities and transmits them to the call center 200. 110 is provided. In this case, the CMS 110 and the call center 200 may be connected through the Internet, and the CMS 110 transmits a data packet using an IP (Internet Protocol) address assigned to the call center 200 as a destination address. . In this case, the transmitted data may be encrypted and transmitted according to a preset encryption scheme.

The call center 200 includes a CAS (Connection Accept Server) 210 for decrypting the data transmitted from the CMS 110 and converting the data into normal data, and DB (Database) 230 for data output from the CAS 210. Communication with the DPS (Data Passing Server) 220 and the NDC (Network Diagnostic Client) (not shown) included in the user server 100 to check whether there is an abnormality of the network to the DB 230 In response to a preset emergency situation, a network diagnostic server (NDS) 240 for outputting information about the emergency situation and the data of the DB 230 are analyzed to analyze the data stored in the DB 230. Implement in real time, and when a predetermined emergency occurs, the DAS (Data Analyze Server) 250 for outputting information on this, and the emergency output from the NDS 240 and the DAS 250 connected to the public network and the Internet network Information about what happened Automatic error calling server (ACS) 260 that transmits to wired / wireless telephone and e-mail of the set server administrator, and DB 230 for server monitoring on the web while connected to the Internet. It is configured to include a CWS (CMS Web Server) 270 having a function of showing the contents of.

In addition, in the server management system, the ACS 260 may process and output a preset number received from a server manager to a mobile phone or a general phone for manipulation of the user server 100. The information output from the ACS 260 is provided to an RPS (Remote Process Server) (not shown) provided in the call center 200, and the RPS is provided to the RPC (referred to in the user server 100 based on the information). Remote Process Client) to properly manipulate the user server 100. Accordingly, the server administrator can operate the user server 100 to a certain degree even from a remote location.

Having such a configuration, information about various servers transmitted from the CMS 110 of the user server 100 is stored in the DB 230 via the CAS 210 and the DPS 220 of the call center 200, In addition, various kinds of information on the network status are stored in the DB 230 by the (NDS) 240, and the information stored in the DB 230 is analyzed by the DAS 250 and output on the monitor screen in real time. In addition, if it is determined that a predetermined emergency situation has occurred due to the analysis of the stored information, the information about this is notified to the server administrator via the ACS 260.

In this server management operation, server management items include storage media management such as hard disk, CPU process performance management, memory usage management, login authentication management, swap (SWAP) usage management, process status management, server user information management, host information management, Configuration file management, network management, and major file management. Description of this management operation will be described in detail with reference to the accompanying drawings.

2 illustrates an example of a user output screen for managing a storage medium such as a hard disk drive (HDD). Referring to FIG. 2, the space used ratio is checked against the total space by the mounted file system, and the space used against the total space is also checked. It checks the total capacity, usage capacity, and remaining capacity on the HDD or storage media, manages the file-system not exceeding the given threshold, and reads the usage rate against the usage period to report the wear rate and replacement time. Information on the space used of the storage medium as shown in Figure 2 is transmitted from the CMS 110 of the user server 100 as shown in Figure 1 to the call center 200, DB ( 230 is tabled and stored. At this time, the information is transmitted by checking the state of the storage medium at preset time intervals. In addition, the data stored in this way is output to the user through the monitor screen by the CWS (270).

3 is an exemplary diagram of a user output screen for CPU state management. Referring to FIG. 3, in order to check the CPU process status check, the CPU type is first identified and the CPU usage is extracted. At this time, the number of clocks of the CPU, CPU user usage, CPU system usage, standby usage for CPU input / output, and CPU idle period are checked. In the example of FIG. 3, the CPU has a user process rate of 1%, a system process rate of 3%, an I / O wait process rate of 0%, and a CPU system idle rate of 96%. Similarly, the information on the CPU status is transmitted from the CMS 110 of the user server 100 as shown in FIG. 1 to the call center 200 and tabled in the DB 230 of the call center 200. Stored.

In this way, the CPU process is checked by the user, the system, and the I / O wait, and the reset process amount is checked. This feature can be used to determine CPU scalability and current availability by parallel or serial installation of the CPU and as a useful resource for process occupancy over the entire system. This feature also prevents system slowdowns and unplanned downtime.

4 is an exemplary diagram of a user output screen for managing memory usage. Referring to FIG. 4, the total memory size is checked to check the memory usage, and the memory size currently being used is checked.

This memory usage management is a function that performs all checks on the memory resources inside the system. It can effectively handle the swap disk usage caused by insufficient memory, select the type according to the memory usage tendency, and add / change memory in the future. Enables complete system configuration. In addition, memory addition / deletion can be checked and used as a basis for hardware changes.

5 is an exemplary diagram of a user output screen for managing login authentication attempts. Referring to FIG. 4, the login authentication attempt check may be used as a tracking basis for the login attempt by checking the login attempt ID, password, attempt time, attempt IP address, terminal node device type, and the like. This can be judged on the basis of whether or not a security system should be attached, and can act as a simple intrusion detection.

6 is an exemplary diagram of a user output screen for managing swap usage. Referring to FIG. 6, the swap usage check records and manages the total size of the swap device and the size in use. By analyzing the usage statistics, the usage efficiency of the swap device can be diagnosed to determine the time to secure the swap space.

Such information can be used as a basis for determining whether or not memory is expanded, and processing time delayed by swap usage can be solved.

7 is an exemplary view of a user output screen for process state management according to an embodiment of the present invention. Referring to FIG. 7, the process status check records and manages the process name, process ID, user ID, CPU occupancy, total memory size, used memory, current state of the process, CPU usage period, etc., for each process daemon. Will be performed efficiently.

This function provides useful data for deciding whether to introduce a distributed system, and this information can be used as a useful data to read whether the system is overloaded during software testing.

8 is an exemplary diagram of a user output screen for managing server user information. Referring to FIG. 8, the server user information check records the number of registered server users, the number of currently connected users, and the like to determine the number of concurrent users for a certain period of time.

This information can be used as a useful data for determining user usage against system performance.

9 is an exemplary diagram of a user output screen for managing host information. Referring to FIG. 9, the host information check records and manages unique information (IP, OS, Domain, Name, etc.) of the host, thereby providing data useful for detecting a change.

10 illustrates an example of a user output screen for managing a configuration file. Referring to FIG. 10, the configuration file check may provide information useful for identifying a cause of a failure in the event of a failure such as a system down by storing information about the change in the main configuration file.

11 is an exemplary view of a user output screen for network failure management. Referring to FIG. 11, network failure management is a function performed by the NDS 240 as shown in FIG. 1, and whether the service is interrupted due to the server system down or network disconnection of the customer at a predetermined time interval (about 30 seconds). It checks and records and notifies you when a failure occurs, so you can know the system status even when the server administrator is moving or outside.

12 is an exemplary diagram of a user output screen for network management. Referring to FIG. 12, the network check records a network adapter and an IP address of the user server 100, a gateway address, a flag, a "Refs", a usage amount, a device name, and the like, to facilitate network management. This network management can be used as a useful data to determine the cause of the network down because it can know the usage by each IP address.

13 is an exemplary view of a user output screen for managing important files. Referring to FIG. 13, the critical file check is a check function that reads whether important files are arbitrarily changed or changed in content, and provides convenience for administrators who need to check important configuration files.

Each item for server management as described above with reference to FIGS. 2 to 13 may be viewed by an administrator, and may be output as a whole so that a normal or failure state may be easily checked.

14 is an exemplary view of a user output screen showing the overall server system status. Referring to FIG. 14, the system status monitoring area 141 and the network status monitoring area 142 are provided to indicate the system status of the entire server, and the system status monitoring area 141 includes a check time, a disk status, and a CPU. There are items on the status, memory status, swap status, important file permission change status, authentication attempt status, reboot status, and the like. The network status monitoring area 142 may include items on a check time and a network status. The grades for each item's status can be categorized as normal / warning / disability / emergency, for example, and the grades for each condition can be easily indicated by marking them with appropriately colored markers.

On the other hand, it is possible to properly classify the settings for the disability level, such as normal / warning / disability / emergency situation according to the setting of the administrator. Referring to FIG. 15, a user may arbitrarily set a failure grade setting for each server management item. For example, in order to set a failure grade of a management item of a hard disk, a warning condition may be set in the disk threshold setting item 151. 90%, 95% for disabilities and 98% for emergencies.

When each item is a warning / disability / emergency situation in the above-described disability grade situation, it is extracted as a text state and sent to the administrator e-mail, and the text is converted into voice to make a notification by making a wired / wireless call. At this time, it operates repeatedly until it is notified to the administrator so that certain notification is possible. In addition, this notification history can be stored and stored as future error occurrence data.

Having such a configuration and operation, the server management system according to the present invention will have a variety of functions different from the conventional. First, the server management system of the present invention can identify network down and system down. That is, in the conventional server management system, when the server system performing the server management function is down, it is not possible to identify whether the network is down or the system is down. On the contrary, in the server management system of the present invention, since the CMS 110 and the NDS 240 are separately provided in the user server 100 and the call sensor 200, identification thereof may be possible.

Of course, even if the network is down or the system is down, the contents of the notification are the same, but the CMS 110 itself continues to run even if the network is down and stores the data on its own server, so it is possible to check this at the time the network is connected. Do. Accordingly, when the user server 100 system is down, the CMS 110 module itself is also down, so that the stored data is not found and this enables to determine whether the system is down soon.

In addition, in the conventional server management system, when the server management system is down, it is impossible to notify the failure situation. On the contrary, in the server management system of the present invention, only the CMS 110 is installed and executed in the user server 100, and the receiving call center servers (CAS, NDS, DPS, DB, ACS, CWS, DAS) are provided at a remote location. (110) Failure notification is possible regardless of module down. This function is more accurate because the system network status is monitored from time to time by the NDS (240).

In addition, the ACS 260, which is in charge of voice notification on the phone, is equipped with a TTS (Text to Speech) reader product and plays a role of reading an error situation by voice. Therefore, since the text to speech (TTS) function of converting text generated when an error occurs to speech is used, any text message contents can be transmitted by voice.

In addition, the server management system of the present invention allows not only to construct and service several servers, but also to designate a plurality of IP addresses of call centers to be round-robin when the service system is down in the CMS 110 module itself. It transfers to normal service system to enable sending and receiving work. Accordingly, when a specific call center 200 is down, the CMS 110 accessing it transmits management information of the user server to a call center that should be set in advance when the call center 200 is down. Allows the call center to manage its user server.

In addition, when the CMS 110 module transmits management information of the corresponding user server to the CAS 210, the CMS 110 module compares the previously transmitted data with the data to be transmitted at present, and changes the parts by itself. Only the packing is transmitted to the CAS 210 to reduce the amount of data to be transmitted. Accordingly, even when the CMSs 110 of several user servers simultaneously send data to the CAS 210, the CAS 210 can properly process all the data.

In this case, the data communication between the CMS 110 and the CAS 210 is performed by using a specific port designated by a service provider and transmitting data according to a predetermined encryption protocol to prevent hacking and information leakage to the user server.

In addition, when an administrator wants to monitor the situation of the user server 100 by accessing the call center 200 through the Internet, the CWS 270 executes screen refreshes at intervals of 10 seconds, for example, to implement information in real time. Support the function. In this case, the screen monitored on the web is merely input to the DB 230, and network traffic between the CMS 110 and the CAS 210 due to the monitoring does not occur.

On the other hand, as shown in FIG. 15, it can be seen that in the server management of the present invention, the emergency situation in which the server failure level is the highest among the respective management items is set to about 98 to 99%. As can be seen from this configuration, the present invention does not take various actions such as notifying the user after the system is down due to a failure, but notifies the administrator before the system is down so that the administrator can take action. Prevent the system from crashing.

However, even if the server administrator is informed that such a server failure is in an emergency state due to various reasons, such as the server administrator is remote, it may be difficult to take immediate action or it may be difficult to take effective measures due to lack of technical expertise of the server administrator. . In such a case, an automatic emergency recovery operation is performed in accordance with a feature of the present invention to prevent a serious situation such as the user server eventually crashing. This will be described in more detail with reference to the accompanying drawings.

16 is a schematic flowchart of a server emergency automatic recovery control according to an embodiment of the present invention. Referring to FIG. 16, first, in step 161, the CMS 110 of the user server 100 extracts various management information of the server and transmits the management information to the call center 200. In step 162, the call center 200 analyzes the transmitted information to determine whether a failure corresponds to the set failure level as illustrated in FIG. 15. When a failure occurs, in step 163, the emergency recovery processing method for the predetermined server failure is derived, and in step 163, it is transmitted to the user server 100. Accordingly, in step 165, the user server 100 performs an emergency recovery process. Thereafter, the call center 200 notifies the server administrator of the result of the emergency repair process in step 166.

The items of the automatic emergency recovery operation for such an emergency are all server failures as shown in Figs. 2 to 13, such as disk, CPU, memory, swap, network, daemon, port, and important file changes. Management items may correspond. For example, a case where a management item is a hard disk as shown in FIG. 2 and a failure state of the hard disk is set to 98% as shown in FIG. 15 will be described. When it is confirmed in step 162 that the usage of the hard disk reaches 98%, a predetermined emergency recovery processing method is derived in step 163, where the emergency recovery processing method does not need to be kept important among the files stored on the hard disk. It can be set to delete the preset files (eg, "Temporary File"). Accordingly, in step 163, the user server 100 deletes the set files to secure a disk space. This emergency repair operation may be merely an unsolvable measure of temporarily dealing with a disk emergency. However, by doing this, you can prevent the system from crashing to some extent and free up server administrators to follow up.

On the other hand, in the present invention by analyzing the accumulated and stored information for a certain period of the state of the server can predict the future change of the server state and can propose a countermeasure.

17 is a schematic flowchart of a server diagnostic consulting operation according to an embodiment of the present invention. Referring to FIG. 17, first, in step 171, the call center 200 periodically extracts information on a state of the user server 100 through the CMS 110 of the user server 100, and then extracts the information in step 172. The stored information in the DB 230. Thereafter, the stored data is statistically processed for a preset period of time in step 173, and time series analysis is then performed using the statistical data in step 174. In step 175, the time series analysis results determine the state of the user server 100 up to the present, and extract information for predicting the future of the server state using a data mining technique. Thereafter, in step 176, diagnostic consulting on the server status is performed using the propensity analysis algorithm based on the extracted various information.

The items of the state information extracted from the user server 100 for the server diagnostic consulting operation may be the same as the items identified for the failure emergency recovery. For example, in the case where the item of the status information for the diagnostic consulting operation is a hard disk, the above operation is described. When the usage of the hard disk is periodically extracted to 40%, 50%, 60%, etc., By time series analysis of the data, it can be expected that after a certain period of time, the space on the hard disk will reach the fault setting class. According to this expectation, it is possible to notify the administrator of appropriately set consulting information, such as notifying that the capacity of the hard disk is insufficient, and suggesting that the capacity of the hard disk is expanded or deleting unnecessary files.

18 is an overall flowchart of a server management operation according to an embodiment of the present invention. Referring to FIG. 18, in operation 18a, the CMS 110 extracts data regarding the state of the server from the user server 100. Thereafter, in step 18b, the CMS 110 transmits the extracted state data to the call center 200. In step 18c, the call center 200 analyzes the state data according to the set state as shown in FIG. 15. As a result of the analysis, if it is determined that a failure occurs in step 18d, the process proceeds to step 18e. If it is determined that a failure does not occur, the process proceeds to step 18j and stores the state data in the DB 230 in step 18j.

On the other hand, it is determined whether or not the automatic emergency recovery operation is performed in step 18e that is determined that the failure occurred in step 18d. If it is set not to perform the automatic emergency recovery operation, the operation proceeds to step 18i. If it is set to perform the automatic emergency recovery operation, the operation proceeds to step 18f. In step 18f, the fault history is analyzed, and then in step 18g, a predetermined emergency recovery plan is derived. In step 18h, the emergency recovery process is performed according to the emergency recovery method. Thereafter, in step 18i, the server administrator is notified of the result of the operation, and then the process proceeds to step 18j to store information on all these situations.

Thereafter, in step 18k, it is determined whether the data stored in the DB 230 is secured as much as time series analysis is possible. If the analysis data amount is not secured, the process proceeds to step 18a and the process is repeated. If the analysis data amount is secured, the process proceeds to step 18l to extract statistical data from the DB 230. After that, the time series analysis operation is performed in step 18m, and the future change is predicted in step 18n. After that, in step 18o, the server diagnosis consulting operation according to the predicted future change is performed.

As described above, the user server failure automatic recovery and the user server consulting operation may be performed by the process as shown in FIG. 18.

Meanwhile, in the above description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be defined by the described embodiments, but by the claims and equivalents of the claims.

As described above, the present invention automatically detects a failure situation of a user server, and not only notifies the server administrator efficiently when a server failure occurs, and can also solve the server failure by performing an emergency recovery for the failure of the server. Furthermore, by analyzing the server status periodically, it is possible to perform consulting operations that can predict future changes in server status and suggest ways to cope with it.

Claims (7)

In the server failure management system, CMS (Connection Management System) installed in the user server to manage system internal resources and error events, and to check and transmit any abnormality, A CAS (Connection Accept Server) for receiving the data transmitted from the CMS 110 and converting the data into normal data, a Data Passing Server (DPS) for storing the data output from the CAS in a database, and the user server. NDS (Network Diagnostic Server) which communicates with NDC (Network Diagnostic Client), checks the network for abnormality and inputs the abnormality to the database, and outputs information on a preset emergency situation, and the data stored in the database. DAS (Data Analyze Server) which processes and outputs various data for analysis, and information about the occurrence of preset emergency situation output from the NDS and the DAS connected to a public network or the Internet network, by wired / wireless Includes Automatic Error Calling Server (ACS), which provides the ability to send by phone and e-mail. Server Fault management system that is characterized by having a call center for configuration. The server of claim 1, wherein the call center includes a CWS (CMS Web Server) having a function of displaying the contents of the database so that the server manager can monitor the server on the web when connected to the Internet. Fault Management System. In the server failure management method, Extracting and transmitting a plurality of types of management information of the server from the user server; A process of determining whether the call center corresponds to a predetermined emergency disorder situation by analyzing the extracted; In the case of the emergency failure situation, deriving a predetermined emergency recovery processing method for each failure and transmitting the same to the user server; And performing an operation according to the emergency recovery processing method at the user server. The method of claim 3, wherein the items of the emergency recovery operation for the emergency failure situation include storage medium management, CPU process performance management, memory usage management, login authentication management, swap usage management, process state management, and server user information management. At least one of host information management, configuration file management, network management, and main file management. 4. The method of claim 3, wherein the emergency recovery method deletes a file which is preset to be not important to be stored in the hard disk when the emergency failure situation is a hard disk failure. In the server failure management method, Extracting and transmitting a plurality of types of management information of the server from the user server; Analyzing and storing the extracted information in a call center; Statistically processing the stored information for a preset period of time; Performing time series analysis using the statistically processed information; Determining the state of the user server as a result of the time series analysis and extracting information for predicting the future of the server state using a data mining technique; And a process of performing diagnostic consulting on a server state using the propensity analysis algorithm. In the server failure management method, Extracting data about the state of the server from the user server and transmitting it to the call center; Analyzing the failure state through the state data in the call center; Storing information on the analysis result; If it is determined that a failure has occurred as a result of the analysis, determining whether the automatic emergency recovery operation for the failure is set; If it is set to perform the automatic emergency recovery operation, deriving a predetermined emergency recovery method according to the failure and performing an operation according to the emergency recovery method; Notifying the server administrator of the result of the operation and storing information about the result of the processing; Determining whether the data stored in the database is secured as much as possible for time series analysis; If the data amount is secured, extracting data to perform a time series analysis operation; Predicting future changes according to the time series analysis; And performing a preset server diagnosis consulting operation according to the predicted future change.