WO2007094041A1 - Server managing device and server managing program - Google Patents

Abstract

[PROBLEM TO BE SOLVED] In providing services by servers, when an operating server becomes out of order, an operation follows to switch the operating server to a spare server so that the services can be continued. In this case, however, since it is necessary for such a spare server to be always a standby, its power consumption is wasteful. If the spare server ismade turned off, it takes time to switch. [SOLVING MEANS] A server managing device is provided with a table for managing server states, an instructing means for instructing a spare server to turn on in the case that electric power for the spare server is cut off, and another instructing means for instructing the spare server to turn off when a status signal confirms that the electric power is turned on, so that switching time for switching server devices can be shortened.

Description

 Specification

 Server management apparatus and server management program

 Technical field

 [0001] The present invention relates to a server management apparatus and a server management program for managing a plurality of servers, and in particular, a server management apparatus and a server management apparatus for performing an operation check on a standby server among a plurality of servers. The server management program.

 Background art

 [0002] In providing a service using a server, if an abnormality occurs due to various factors in the server that is actually operating to provide the service (hereinafter referred to as an active server! /). The service may be stopped. When such an abnormality occurs, the operation server generally replaces the standby server (hereinafter referred to as the standby server) with an operation server by sending an abnormality signal to avoid service stoppage ( For example, see Patent Document 1.)

 Patent Document 1: Japanese Patent Laid-Open No. 3-125159

 Disclosure of the invention

[0003] (Problems to be solved by the invention)

 In the prior art, the spare server must always be activated. This is to reduce service downtime by enabling quick server replacement in the event of an abnormality.

 [0004] However, with the recent large scale of server systems, the number of active servers has increased, and the number of standby servers has increased accordingly. That is, in a system having a plurality of services, there are a plurality of active servers and a standby server corresponding to the active server.

 [0005] Therefore, the plurality of standby servers consumes power by themselves even though they do not provide services, and also consumes power to cool the servers.

[0006] On the other hand, when the standby server is turned off to reduce power consumption, it takes a lot of time to replace the server when an abnormality occurs on the active server. One screw had fallen. In addition, when the standby server is turned off, it is unclear even if an abnormality has occurred on the standby server, and there is a problem that server replacement cannot be performed when an abnormality occurs on the active server.

 (Means for solving problems)

 The present invention provides a table for managing the status of whether or not a server is powered off, an instruction means for instructing the server to power on when there is a server in a powered off state, and a power on from the Sano. When the status signal is confirmed, it functions as an instruction means to turn off the power.

[0007] In addition, a power-off instruction is given to the server.

 [0008] Further, the table further manages the status of whether or not the sano is in operation, and the power-off instruction is for other servers, and the server is not in the operating state and is not in the power-off state. Do.

 [0009] Furthermore, when an abnormal status signal is received from the server, there is further provided an output means for outputting an abnormal status message.

[0010] Further, the power-on instruction is given at regular intervals.

 (The invention's effect)

 As described above, it is possible to power on a server that is in a power-off state, and it is possible to maintain the number of servers that are on standby, thus reducing power consumption and ensuring system safety. It becomes possible.

 Brief Description of Drawings

FIG. 1 is a system configuration diagram.

 FIG. 2 is a data configuration diagram of the server management DB 30 in the first embodiment.

 FIG. 3 is a flowchart for identifying a standby server in the first embodiment.

 FIG. 4 is a flowchart of a standby server migration instruction in the first embodiment.

 FIG. 5 is a flowchart of server standby server migration processing according to the first embodiment.

 [FIG. 6] FIG. 6 is a flowchart for identifying a power-off server in the first embodiment.

FIG. 7 is a flowchart of a power-off server migration instruction in the first embodiment. FIG. 8 is a flowchart of server power-off server migration processing in the first embodiment.

 FIG. 9 is a diagram showing a data configuration of the server management DB 30 in the second embodiment.

 [FIG. 10] FIG. 10 is a flowchart of a confirmation method of a power-off server when the confirmation flag 36 in the second embodiment is used.

 FIG. 11 is a diagram showing a data configuration of the server management DB 30 in the third embodiment.

FIG. 12 is a flowchart of a power check method for each server according to the third embodiment.

 FIG. 13 is a data configuration diagram of the time management DB 40 in the fourth embodiment.

 FIG. 14 is a flowchart of server state transition by time according to the fourth embodiment.

FIG. 15 is a hardware configuration diagram.

 BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a diagram showing a system configuration diagram of a server management system of the present invention.

[0014] Servers 01 to XX are servers to be managed by the server management system, and each have a recovery function and a failure detection function. Each server has a state in which the power is turned off (hereinafter referred to as a power-off server), a standby server in a standby state, and an active server in an active state.

[0015] Server 01 to server XX function as a power-off server, a standby server, and an active server in response to an instruction from management server 10.

The power-off server enters a standby server state after receiving power-on, hardware confirmation, and network connection confirmation.

The standby server becomes an active server state by copying a program and data for executing a service.

[0018] The power-off server receives the power-on, confirms the hardware, confirms the network connection, copies the service program and data, and enters the state of the active server.

[0019] The active server is copied with a program and data that function as a standby server. More standby server status.

 [0020] When the active server and the standby server receive the power-off instruction, the active server and the standby server turn off the power and enter the power-off server state.

[0021] The standby server does not need to have information for executing the service, but needs to guarantee that it can operate as an active server.

[0022] In order to guarantee the operation of the power-off server, it is also necessary to move it periodically for reasons such as avoiding a failure due to dust contamination.

The management server 10 is a server that manages the servers 01 to Sano xx.

The management client 20 is a client terminal used when an administrator wants to operate the management server 10.

 The server management DB (database) 30 is a database that manages the states of the servers 01 to XX.

[0026] The time management DB 40 is a database used when the number of servers to be operated is changed according to a preset time.

 [0027] The management server 10 is connected to the management client 20, the servers 01 to xx, the server management DB 30 and the time management DB (database) 40 via a network.

 The method in which the management server 10 confirms the status of each server can be performed by a method in which the management server 10 instructs the status acquisition request to each server. It is also possible by a method in which each server outputs status information held by the server to the management server 10. Check the status at regular intervals, for example.

 Here, switching between the standby server and the active server will be briefly described.

 [0030] The management server 10 acquires the status of each of the servers 01 to XX to be managed. When an abnormal state of the active server is detected, the active server is changed to the standby server and an instruction to set the standby server as the active server is output. In this case, when other devices that make up the system are determined based on the network information, the setting is switched so that the active server that detects the abnormality and the standby server to be changed to the active server are the same server. By performing the above processing, the service outage period can be minimized.

[0031] Further, after correcting the failure of the active server, it is possible to restore the original as the active server. The active server and the standby server can be replaced.

 (Example 1)

 Next, the data configuration of the server management DB 30 in the first embodiment will be described.

FIG. 2 is a diagram illustrating a data configuration of the server management DB 30 according to the first embodiment.

The server management DB 30 in the first embodiment includes a Sano ID 31, a status 32, a service 33, a power-off time 34, and an operation start time 35. The server ID 31 is an identifier assigned to the servers 01 to XX. In the system according to the present embodiment, it is assumed that the server identifiers are set from 01 to XX in order. Status 32 stores the status of the server. The management server 10 acquires the server status periodically or for each specific event and stores it in the status 32. Service 33 stores the type of service performed by the active server. In this embodiment, there are two types of services, service A and service B. The power-off time 34 stores the time when the power-off server is in a power-off state. The operation start time 35 stores the time when the server became a standby server.

Hereinafter, a process in which the management server 10 changes the state of the power-off server to the standby server and a process of changing the state of the standby server to the power-off server will be described.

FIG. 3 is a flowchart for specifying a standby server.

 The management server 10 refers to the server management DB 30 and extracts a list of servers 31 whose status 32 is “power off” (S301). Next, the data record with the oldest power-off time 34 corresponding to the list of servers 31 extracted in S301 is selected, and the selected server is specified as a server to be changed to a standby server (S302).

 [0037] When the management server 10 identifies a power-off server to be a standby server from the group of power-off servers, the management server 10 performs processing to make the power-off server a standby server.

 FIG. 4 is a flowchart for the processing when the management server 10 issues an instruction to shift from the power-off Sano to the standby server.

 [0039] The management server 10 transmits a power-on instruction to the server (specific server) specified in S302 (S401).

[0040] The management server 10 determines whether or not startup completion information has been received from the specific Sano ( S402).

 If the activation completion information has not been received from the specific server (S402: No), it is determined whether or not a predetermined time has passed (S403). If it has been a certain time after a certain time (S 403: No), it continues to wait for startup completion information from the specific server. On the other hand, if a certain time has passed (S403: Yes), error information is output (S406) because there is a possibility of hardware failure of the specific server and network failure between the management server 10 and the specific server.

 [0042] When the start completion information is received from the specific sano (S402: Yes), the management server 10 transmits an information acquisition instruction for acquiring the current state to the specific server (S404).

[0043] The server status includes normal, warning, error, and no response types. Normal indicates that the system is operating normally. The warning is when the specific server itself can detect the failure location of the specific server, such as when any port in the specific server is broken. An error is a state in which a hardware failure has occurred, and the specific server itself cannot detect the failure location of the specific server. Also, “no response” means a state in which a start completion has been received but no response has been received to a status acquisition request, and communication via the network has been established.

 [0044] The management server 10 acquires the status from the specific sano (S405), and if the status is "normal" (S405: Yes), the subsequent processing from the power-off server to the standby server has been completed normally. Accordingly, the information in the server management DB 30 is updated (S407). Specifically, the data record of Sano ID31 corresponding to the specific server in the server management DB30 is searched, the status 32 is updated from “Power off” to “Standby”, the information of the power off time 34 is deleted, and the operation is started. Store the current time at time 35.

 On the other hand, if the status is other than “normal” (S405: No), error information is output assuming that there is some problem with the specific server (S406).

 [0046] Next, the transition process from the power-off Sano to the standby server performed by the specific server will be described.

FIG. 5 is a flowchart of standby server migration processing of a specific server. When the activation instruction is received from the management server 10 (S501), the specific server starts the activation process. Specific The server performs activation processing (S502), and when activated (S502: Yes), transmits activation completion information to the management server 10 (S503).

 Next, when the specific server receives a status acquisition request from the management server 10 (S504), it returns status information (S505).

 [0049] It should be noted that in order to confirm whether or not the specific server is operating normally, it is possible to wait for a predetermined time. For example, it may operate immediately after startup, but an abnormality may occur after a while. Therefore, for example, it is possible to wait for about 15 minutes and determine that the specific server is operating normally only when the specific server is operating normally. This determination can be made by the management server 10 in S405.

 [0050] When it is confirmed that the specific server has operated normally, the management server 10 performs a process of turning off the power of any of the current standby servers.

 FIG. 6 is a flowchart for identifying a power-off server.

 The management server 10 refers to the server management DB 30 and extracts a list of servers 31 whose status 32 is “standby” (S601). Next, the data record having the oldest operation start time 35 corresponding to the list of servers 31 extracted in S601 is selected, and the selected server is specified as a server to be changed to a standby server (S602). The server specified here is assumed to be the second specified server.

 FIG. 7 is a flowchart in which the management server 10 performs a process for instructing the second specific server to transition from the standby server to the power-off server.

The management server 10 transmits a power-off instruction to the second specific server in S602 (S7

01).

 [0055] The management server 10 determines whether or not the power-off completion information has been received from the second specific server (S702).

[0056] If the power-off completion information is received from the second specific server! /, (S702: No), it is determined whether or not a predetermined time has passed (S703). If a certain period of time has passed and it is ヽ ヽ (S703: No), it continues to wait for the power-off completion information from the second specified sano. On the other hand, if a certain period of time has passed (S703: Yes), there is a possibility of a hardware failure of the second specific server or a network failure between the management server 10 and the specific server. (S704).

 [0057] When power-off completion information is received from the second specific server (S702: Yes), information in the server management DB 30 is updated (S705). Specifically, the data record of Sano ID31 corresponding to the second specific server of the server management DB30 is searched, the status 32 is updated from “standby” to “power off”, and the current time is set to the power off time 34. Is memorized and the information of operation start time 35 is deleted.

 [0058] Next, the transition process from the standby sano to the power-off server performed by the second specific server will be described.

 FIG. 8 is a flowchart of the power-off server migration process of the second specific server. When the power-off instruction is received from the management server 10 (S901), the second specific server starts the power-off process. The second specific server performs power-off processing (S902), and when power-off is completed (S902: Yes), power-off completion information is transmitted to the management server 10 (S903).

 (Example 2)

 Next, another embodiment for confirming the operation of the power-off server will be described.

This embodiment is a method of checking the operation of a power-off server by sequentially performing power-on and power-off processing on the power-off server when a specific time comes using a table.

FIG. 9 is a diagram illustrating a data configuration of the server management DB 30 according to the second embodiment.

The server management DB 30 according to the second embodiment has a configuration including a Sano ID 31, a status 32, and a confirmation flag 36.

 [0063] The server ID 31 and the status 32 have the same contents as those in the first embodiment, and a description thereof will be omitted.

The confirmation flag 36 is information attached to a server whose status 32 is a power-off state. An initial value of “0” is attached to the server that is turned off, and “1” is attached when power-on is confirmed.

FIG. 10 is a flowchart of the confirmation method of the power-off server when the confirmation flag 36 is used.

 The management server 10 executes this flowchart every preset time.

The management server 10 initializes the confirmation flag 36 of the server management DB 30 (sl001). This initialization is based on status 32 corresponding to server ID 31 and status 32 is “Active”. Or, if it is in the “standby” state, no value is input to the confirmation flag 36 to remove the force to be checked for operation, while if the status 32 is in the “power off” state, the initial value of the flag Set “0” as.

The management server 10 continues until all the flags set in the confirmation flag 36 are other than “0”.

 (sl002: Yes), the processing after S1003 is performed (S1002: No).

The management server 10 performs the following processing for the server ID 31 whose confirmation flag 36 is “0”.

 The management server 10 issues a power-on instruction to the power-off server corresponding to the server ID 31 (sl003).

 The process of turning on the power is the same as that of FIG. In the present embodiment, the specific server in FIG. 4 means an s 1003 power-off server. However, when updating the server database in S407, the process of setting the confirmation flag 36 to “1” is performed. In the case of sending error information in S406, the confirmation flag 36 is set to “0”. , Set to a value other than “1”.

 [0072] When an error occurs (sl004: Yes), the management server 10 extracts the next target server.

 [0073] On the other hand, if an error does not occur (s 1004: Yes), that is, the server that has been confirmed to be turned on, the server is turned off (s 1005). The power-off process can be performed by the same process as in FIG. The specified server in Fig. 7 is the server that has been confirmed to be powered on.

 When confirming that the power is turned off, the same processing is performed for the next server whose confirmation flag 36 is “0”.

 As a result of the above processing, when all the confirmation flags 36 are other than “0”, the current operation confirmation ends.

 [0076] With the above processing, it is possible to accurately grasp the operating status of each server without simultaneously starting the server power supply when checking the operation at regular intervals.

 (Example 3)

Next, another embodiment for checking the operation of the power-off server will be described. [0077] For example, in a system in which the server operation check process by the management server 10 operates as an independent process, even if the power-on instruction is given to the target server after the management server 10 is accessed, The server needs time to start. As a result, a failure that does not meet the waiting time for the operation check of the management server 10 occurs. In such a system, the above problem can be solved by turning on the power of each power-off server immediately before the operation check processing by the management server 10 and turning off the power after checking the operation by the management server 10. can do.

Also in the present embodiment, the configuration of the server management DB 30 is changed.

FIG. 11 is a diagram illustrating a data configuration of the server management DB 30 according to the third embodiment.

[0080] The server management DB 30 of the third embodiment is configured by a Sano ID 31, a status 32, a start flag 37, and a start time 38.

Since the server ID 31 and the status 32 have the same contents as in the first embodiment, description thereof is omitted.

[0082] The start flag 37 is information indicating whether or not a power-on instruction is issued to a server in a power-off state. When the power-on flag 37 is "0", the status 32 of the server management DB 30 indicates that the power is off. Indicates that the management server 10 has not given a power-on instruction. If the value is 1, the status 32 of the server management DB30 is in a power-off state and the management server 10 has a power-on instruction. , That is, a state in which the server is running. Set to “2” when startup is complete. Other values indicate the state of failure, operation, standby, etc.

 The startup time 38 is a value that stores in advance the time required for each server corresponding to the server ID 31 to complete startup normally after the power is turned off.

The management server 10 obtains the time for performing the operation check in advance.

 [0085] In addition, the management server 10 sets the value of the start flag 37 to "0" for a server whose status 32 is "power off", and for servers in other states! / Set a value other than “0”.

 The subsequent processing is processing performed by the management server 10, and is processing that is repeatedly performed before the operation confirmation processing for each server by the management server 10.

FIG. 12 is a flowchart of the power check method for each server according to the third embodiment. The management server 10 acquires the current time (sl201).

 The management server 10 calculates the remaining time until the operation confirmation time from the difference between the operation confirmation time and the current time (sl202).

The management server 10 checks the activation flag 37 and extracts a record with the activation flag 37 being “0” (sl203).

 Here, if there is no data record (sl204: no), that is, if all the servers are not power-off servers, the subsequent processing is unnecessary, so the processing ends.

[0092] On the other hand, when the extracted data record exists (sl204: yes), the following processing is performed.

When the data record can be extracted, the management server 10 compares the remaining time with the activation time 38 corresponding to the extracted record (sl205).

 Here, when the activation time 38 of all the data records is shorter than the remaining time (sl206: Yes), the subsequent processing is unnecessary, and the processing ends.

 On the other hand, when the activation time 38 is equal to or longer than the remaining time (sl206: No), the activation flag 37 is set to “1” indicating activation (sl207) together with a power-on instruction. As a result, in the next pre-startup confirmation, the flag value is not “0”, so the check target force is also eliminated.

 Then, the power-on process (sl208) is executed for the server corresponding to the startup time 38.

 The processing for powering on the server is the same as the processing in FIG. 4 in the first embodiment.

 Note that the specific server in FIG. 4 means the power-off server of si 208 in this embodiment.

 However, when the server management DB 30 of S407 is updated, the activation flag 37 is changed from “1” indicating activation to “2” indicating activation completion.

 [0099] When the power-on instruction is completed for all servers having a data record with the startup time 38 shorter than the remaining time (sl 209: Yes), this process ends.

 [0100] The process according to Fig. 12 is performed until immediately before the start of the operation check.

[0101] The management server 10 confirms the operation of the managed server when the operation confirmation time elapses. After that, power-off processing is performed for all servers whose start flag 37 is “2”. [0102] With the above processing, it is possible to confirm the operation of a server that does not need to be kept powered on by turning on the power for a short time.

 [0103] In the above example, the method of checking the operation of the server at a specific time has been described. However, the application can also be applied when the time for checking the operation is determined individually for each server! . In this case, it can be realized by setting the operation confirmation time for each server, calculating the remaining time from the difference between the current time and the current time, and comparing it with the start time 38 of each data record. is there.

 (Example 4)

 FIG. 13 is a diagram showing a data configuration of the time management DB 40.

 [0104] The time management DB 40 is composed of time 41, standby server number 42, active server number service A43, and active server number service B44. Time 41 is 24 hours divided into 3 hours. Dividing every three hours is merely an example, and can be set as appropriate, such as daily, weekly, or minute units. The number of standby servers 42 is the number of standby servers set corresponding to time 41. The administrator can arbitrarily set the number of standby servers in advance. The number of active servers service A43 and the number of active servers service B44 are the number of active servers that are operated for service A and service B corresponding to time 41.

 [0105] The active server number service A43 and the active server number service B44 are two items. However, this embodiment is a system in which two types of services, service A and service B, exist. Yes, the number of items increases as the number of services increases.

 FIG. 14 is a flowchart of server state transition according to time.

 [0107] First, the management server 10 extracts the time 41 of the time management DB 40 corresponding to the current time (S1401).

 The management server 10 reads the number of standby servers 42 corresponding to the time 41, the number of active servers 43 corresponding to the service A, and the number of active servers 44 corresponding to the service B (S1402).

 The management server 10 reads the number of servers that provide services corresponding to the services A and B currently running on the system from the service 33 and status 32 of the server management DB 20 (S1403).

[0110] Judge whether the number read by S 1402 and the number read by S 1403 are different (S1404).

 [0111] If they are different (S1404: Yes), the number of servers is adjusted (S1405). The number of servers can be adjusted by, for example, a method of powering off an operating server with a long operating time or a method of powering off a server with low server processing capacity. Set the power-off server as the standby server and active server. Give priority to the standby server and switch to the active server. Various judgments can be made. These determination definitions are defined in advance.

 [0112] The management server 10 can monitor the degree of congestion for each service and dynamically change the state of the active server, standby server, and power-off server as described above.

 Next, a description will be given of a system in which the number of active servers and the number of standby servers are dynamically changed according to time.

 In general, a server system has a higher processing speed if the number of servers to be processed is large. Therefore, it is possible to change the standby server to an active server according to the load status. Also, in a server system in which multiple services are performed in parallel, service A is lightly loaded and service B is heavy. By switching the resulting server as an active server that processes service B, efficient server operation becomes possible.

 [0115] In order to cope with the above state, the administrator sets the time management DB 40 in advance, and defines the number of active servers and the number of standby servers per hour. It is also possible to start the active server and the standby server corresponding to the time.

 FIG. 15 is a hardware configuration diagram.

 FIG. 15 is a diagram illustrating an example of a hardware configuration of the server management system, the management server 10, the management client 20, and the servers 01 to XX.

 [0118] The server and client shown in the figure have a CPU 11, a memory 12, an input means 13, an output means 14, a storage means 15, a network connection means 16, etc., and these are connected to the node 17. It has become. The configuration shown in the figure is an example and is not limited to this.

The CPU 11 is a central processing unit that controls the server and the client computer as a whole. [0120] The memory 12 is a memory such as a RAM that temporarily stores the program and data stored in the storage means 15 during program execution, data update, and the like. The CPU 11 executes various processes including the process related to the server management operation described with reference to FIGS. 3 to 12 using the program and data read out to the memory 12.

 [0121] The input means 13 is, for example, a keyboard, a mouse, a touch panel, or the like.

 [0122] The output means 14 is, for example, a display (display device).

 [0123] The storage means 15 is, for example, a node disk device or the like, and includes a program (including a program that causes a computer to execute the process related to the server management operation described above) and data (the server management DB30 and the time management DB40 described above). Are stored).

[0124] The network connection device 17 is configured to connect to a network (such as the Internet) and to transmit / receive programs and data to / from an external information processing device.

[0125] It is also possible to download a recording medium on which the program is recorded or a program.

 [0126] A program or data for executing the various processes described above may be read out, stored in the memory 12, and executed, or the program or data may be stored in a network ( A program or data stored in an external program or server may be downloaded via the Internet.

 It should be noted that the server managed by this server management system is a server that can be powered on and off via the network. Furthermore, if the server has a power saving function, the state transition from the standby sano to the power-off server can also be realized by turning off the power with the power saving function. Here, the power saving function is a function that can stop the power supply while maintaining the operation status such as the memory status.When the power is turned on, the state when the server is powered off by the power saving function can be reproduced immediately. It is a function that becomes.

 [0128] Although the present invention has been described in detail above, the present invention is not limited to the above-described embodiment, and various improvements and modifications may be made without departing from the scope of the present invention. Of course!

 Industrial applicability

[0129] The invention provides server management capable of reducing power consumption and ensuring system safety. Can be provided.

Explanation of symbols

 10 Management server 10 20 Management client 30 Server management DB 30 40 Time management DB

Claims

The scope of the claims  [1] On the computer,  A table for managing whether or not each server is in a power-off state among a plurality of servers, and a power-on instruction means for instructing the server to power on when there is a server in a power-off state  Power off instruction means for instructing power off to any of the plurality of servers when the power on status signal is confirmed from the sano;  A server management program characterized in that it functions as 2. The server management program according to claim 1, wherein the power-off instruction by the power-off instruction means is issued to a server that has confirmed the power-on status signal.  [3] The table further manages the status of whether the sano is in operation,  The power-off instruction by the power-off instruction means is given to a server that is not in an operating state and is not in a power-off state. 1. The server management program according to 1. [4] The server management program according to claim 1, further comprising output means for outputting an abnormal state message when an abnormal state status signal is received from the server.  [5] The power-on instruction by the power-on instruction means is performed at regular intervals. The server management program according to claim 1. [6] On the computer,  A table for managing information on whether or not each server is in a power-off state and information on whether or not operation has been confirmed among a plurality of servers,  Determining means for determining whether or not there is server information by checking the operation in the table in a power-off state;  A power-on instruction means for instructing the server to power on when the determination means determines that there is a corresponding server; When the power-on status signal is confirmed from the Sano, the server is instructed to turn off the power, and the data corresponding to the server in the table has been confirmed. Power off instruction means to record information,  Repeating means for repeating the power-on instruction means and the power-off instruction means until there is no server information corresponding to the table;  A server management program characterized in that it functions as [7] A table for managing whether or not each server is in a power-off state among a plurality of servers, and when there is a server in a power-off state in the table, a power-on instruction for instructing the server to power on Means,  Power off instruction means for instructing power off to any of the plurality of servers when the power on status signal is confirmed from the sano;  A server management apparatus that functions as: 8. The server management apparatus according to claim 7, wherein the power off instruction by the power off instruction means is issued to the server. [9] The table further manages the status of whether the sano is in operation,  8. The server management according to claim 7, wherein the power-off instruction by the power-off instruction means is issued to a server that is another server and is not in operation and is not in a power-off state. apparatus.  10. The server management apparatus according to claim 7, further comprising output means for outputting an abnormal condition when an abnormal status signal is received from the server. 11. The server management apparatus according to claim 7, wherein the power-on instruction by the power-on instruction means is given at regular intervals. [12] A table for managing information on whether or not each server is in a power-off state and information on whether or not operation has been confirmed among a plurality of servers,  A determination means for determining whether or not the server information has power by checking the operation when the power is off in the table;  A power-on instruction means for instructing the server to power on when the determination means determines that there is a corresponding server; When the power-on status signal is confirmed from the Sano, the server is instructed to turn off the power, and the data corresponding to the server in the table has been confirmed. Power off instruction means to record information,  Repeating means for repeating the power-on instructing means and the power-off instructing means until there is no server information corresponding to the table. A server management device comprising: