JP5131336B2 - How to change the boot configuration - Google Patents

Description

The present invention relates to a boot configuration change method for changing a disk used by a server for booting.

In general, the server boots an OS installed in a built-in disk device. But,
When the disk capacity used by the server increases and the capacity of the disk device becomes insufficient, it is necessary to replace the internal disk of the server. Furthermore, the backup operation of the disk device is troublesome because it is necessary to execute backup software on each server. Also, as the number of servers increases, work to replace the disk devices of many servers,
The trouble of backing up becomes very large.

On the other hand, there is a form in which a server boots using a disk of an external disk device as a disk device via a network. In this configuration, even when the capacity of the disk is insufficient, the disk can be easily added to the external disk device, so that work can be saved. Furthermore, since the backup can be copied between a plurality of disks in the external disk device, labor for running software on the server can be saved. Also, in a computer system in which multiple servers boot from a disk of an external disk device, all the server's disks can be consolidated on one external disk device, so disk expansion and backup operations can be performed on one external disk device. This saves time and labor when the number of servers increases. Further, in this configuration, since it is possible to connect to a plurality of servers of the computer system via a network or a network switch, the boot disk of a certain server connected to the external disk device can be referred from another server. For this reason, in this configuration, when a failure occurs in the active server that is executing a job, it is possible to take over the job by starting another server using the boot disk of the server.

Against this background, a computer system consisting of a server that boots from an internal disk must be connected to an external disk in order to make it possible to save more disks and save backup work, and to take over work by taking over a disk when a server failure occurs. What is desired is a method for transitioning from a device to a bootable configuration. However, to achieve this, it is necessary to copy the server's data part to an external disk device and rebuild the system part such as the server's OS and application software. There is a problem that the amount of work increases.

In addition, in a computer system composed of a server that boots from an external disk device, there is a demand for a method for migrating, for example, a task of a server built in a test environment to another server that is a production environment. As a method for realizing this, it is necessary to boot the migration destination server from the disk of the external disk device used by the server in the test environment. However, to achieve this, it is necessary to change the boot program settings of the migration destination server so that the migration destination server can boot from the disk of the external disk device used by the test environment server. Become.

The problem to be solved by the present invention is that, in the method of changing the disk used by the server for booting, it is not necessary to reconstruct the server OS or application and to set the server boot program. This is to save the disk change work.

When a server that boots using an internal disk is migrated to a configuration that boots from an external disk device, it is necessary to reconstruct the software. Therefore, a large-scale computer system requires a large amount of work.

In the computer system where the server boots from the disk of the external disk device,
To migrate a server's business to another server, the boot program setting must be changed so that the migration destination server can boot from the external disk used by the migration source server. It was necessary.

In a computer system in which at least one server is connected to an external disk device on the network and the server can boot the operation system (OS) from the external disk device, the migration destination disk is separate from the disk that the server used for booting. And the server or another server of the computer system changes the disk used for booting to the migration destination disk by synchronizing the contents of the boot disk and the migration destination disk, and the migration destination The OS and applications installed on the migration destination disk can be started from the migration destination disk by changing the contents of the disk, and the boot program setting of the server is changed to boot from the migration destination disk By making it possible, it is useful for booting the server. To realize the change of the disk to be.

The problem to be solved by the present invention is that in the method of changing the disk used by the server for booting, it is not necessary to reconstruct the server OS or application, and it is not necessary to set the server boot program. Realizes labor saving of changing disk used for booting.

1 shows an overall configuration diagram of the present invention. FIG. Example 1 The block diagram of a server is shown. The block diagram of a management server is shown. A server management table is shown. A disk mapping table is shown. A disk synchronization table is shown. The structure of a disk mapping mechanism is shown. The example of the disk mapping structure to a server is shown. An example of disk synchronization is shown. The sequence diagram of this invention is shown. The processing flow of a server failure detection function is shown. The sequence diagram of a server failure management function and a storage management function is shown. 1 shows an overall configuration diagram of the present invention. FIG. (Example 2) The structure of the security mechanism is shown. (Example 2) The example of the security setting of a network switch is shown. (Example 2) A server management table is shown. ((Example 2) The sequence diagram of this invention is shown. (Example 2) The sequence diagram of a server failure detection function and a storage management function is shown. (Example 2) The sequence diagram of this invention is shown. (Example 2) The block diagram of a server is shown. (Example 3) The example of the synchronous structure by a mirroring mechanism is shown. (Example 3) The sequence diagram of this invention is shown. (Example 3) The sequence diagram of a server failure management function and a storage management function is shown. (Example 3) 1 shows an overall configuration diagram of the present invention. FIG. Example 4 The block diagram of a server is shown. Example 4 The example of the backup structure by a backup mechanism is shown. Example 4 The sequence diagram of this invention is shown. Example 4 An example of a shared disk configuration is shown. Example 4 The sequence diagram of this invention is shown. (Example 5) 1 shows an overall configuration diagram of the present invention. FIG. (Example 6) The sequence diagram of this invention is shown. (Example 6) The sequence diagram of a server failure management function and a storage management function is shown. (Example 6) The sequence diagram of the boot program, network boot function, agent, and boot management function of the active server is shown. (Example 6) The boot configuration table is shown. Example 1 The sequence diagram of the standby server boot program, network boot function, agent and boot management function is shown. Example 1

  FIG. 1 shows an overall view of an embodiment of the present invention. The system of this embodiment includes a plurality of servers 102. Each server is connected to a network switch (NW SW) 104 via a network interface card (NIC) 121 and a network adapter (Adaptor) 120. Here, the network switch may be a switch that handles the IP protocol or a fiber channel switch. Further, the connection destination network switch of the adapter 120 may be a switch different from the NIC 121. The network switch 104 is connected to the external disk device 103 and can be accessed from the server 102. Furthermore, the network switch 104 is also connected to a management server 101 that manages the system. Each server 102 has a built-in BMC (Baseboard Management Controller) 122. The BCM 122 is connected to the management server 101 via a network. This makes it possible to monitor the hardware status of each server and control the power supply. The external disk device is equipped with an external disk device controller 130 for controlling the external disk device, and the external disk device controller 130 has a disk mapping mechanism 131 and a disk synchronization mechanism 132. The disk mapping mechanism 131 manages a disk 133 that can be accessed from the server 102 connected to the external disk device 103. The disk synchronization mechanism 132 controls the contents of the disk 133 in the external disk device to synchronize with the spare disk 134. The management server 101 includes a failover mechanism 110 that takes over the business of the server in which the failure has occurred to another server and a boot configuration change function 120 that changes the boot configuration of the server when a failure occurs in the server. Is done.

FIG. 2 shows a detailed configuration of the server 102 in this embodiment. The server 102 has a memory 201 for storing programs and data, and a CPU 2 for executing the programs in the memory.
02, Adapter 120, NIC 121, and BMC 122. A boot program 220 running on the CPU is provided. Adapter 120 has a unique device identifier (
ID) 204 is stored in the memory. This ID 204 is, for example, a MAC address in the case of a network adapter, and a WWN in the case of a fiber channel host bus adapter. The BMC 122 mainly monitors and controls the hardware of the server 102. When an abnormality occurs in the hardware of the server 102, the failure detection mechanism 205 can detect and notify the outside. Further, the server 102 can be turned on / off remotely through the BMC 122. The boot program 220 is a program such as System BIOS or EFI, for example, and operates so that the server 102 boots from a device used for booting registered in advance in the nonvolatile memory 203 when the server 102 is powered on. The boot program 220 can also boot from the OS received by the adapter 120 from the network.

FIG. 3 shows details of the failover mechanism 110 and the boot configuration change mechanism 120 constituting the management server 101 in FIG. 1 in this embodiment. The failover mechanism 110 includes a server failure detection function 301 that monitors a server failure state, a server failure management function 302 that performs failover operation and server power control when a server failure occurs, a physical location of the server hardware, A server management table 303 that stores business groups, business operation statuses, and server usage statuses, a storage management function 304 that controls disk mapping and synchronization processing used by servers, and a disk mapping table that manages disk mapping statuses 305 and a disk synchronization table 3 for managing the status of disk synchronization processing
06. The boot configuration change mechanism 120 includes a network boot function 307 that enables the server to boot from the network, a boot management function 308 that changes the boot configuration of the server, and a boot configuration table 309 that indicates the status of the boot device of the server. . The network boot function 307 sends the agent 330 to the server 102 via the network, and the server 102 activates the sent agent 330. The network boot function 307 corresponds to, for example, a DHCP server function that enables the server 102 to boot with the PXE protocol.

FIG. 4 shows details of the server management table 303 in FIG. The server management table 303 stores a list of servers managed by the failover function 110, physical location information of each server, business operation information, and status. Table column 4
01 stores the identifier of the server. The server identifier 401 may be information that can identify the server. This is the server serial number or, for blade servers, the blade number. A column 402 indicates the physical location information of the server, and is used for identifying a server corresponding to a failure occurrence part when a failure of the server occurs. A column 403 indicates a business group of the server. The business group includes one or more active servers that are operating a business and a spare server that is not operating the business. When a failure occurs in the active server belonging to the business group, failover is performed to a spare server belonging to the same business group. A column 404 indicates a business operation state of the server. If the business is in operation, it is the active server, and if it is not in operation, it is a spare server. A column 405 indicates the state of the server. Indicates whether the server is operating normally, is in a failed state, or has been failed over. Based on this information, it is possible to check whether there is a server that needs to be failed over, and to identify whether there is a server that can be selected as a failover destination. A column 406 indicates a server failover state.
For a server for which failover has been executed, the server identifier and physical location information of the failover destination of the server are indicated. In addition, the server that has taken over the business by failover indicates an identifier, physical location information, and the like to the server where the business was originally operating before the failover. Based on the information in the column 406, the server can be recovered from the failover state.

FIG. 5 shows details of the disk mapping table 305 in FIG. A column 501 indicates the identifier of the server. This identifier is the same as the column 401 in FIG. A column 502 indicates ID information of the adapter 120 mounted on the server. For example, Adaptor120
Indicates a MAC address if the network card is a network card, and indicates a WWN if the adapter 120 is a fiber channel host bus adapter. A column 503 indicates an identifier of the external disk device in which the boot disk of the server indicated by the column 501 exists. A column 504 indicates an identifier of a boot disk existing in the external disk device of the column 503. The boot disk in the column 504 indicates the identifier of the external disk device in which the spare disk of the server indicated by the column 501 exists. A column 506 indicates an identifier of a spare disk existing in the external disk device of the column 505. Here, the spare disk in the column 506 is a disk that is used for booting by the spare server that takes over the business at the time of failover when a failure occurs in the server. Note that the disk in the column 504 is not necessarily limited to boot disk information, and if the server has a data disk as an external disk, information about the data disk is also added. Similarly, a spare disk in the column 506 and a spare disk for the data disk are added.

FIG. 6 shows details of the disk synchronization table 306 in FIG. Column 601
Indicates an identifier of the external disk device. A column 602 indicates a disk existing in the external disk device shown in the column 601. A column 603 indicates a sub disk that synchronizes the contents of the disk in the column 602. A column 604 indicates whether the contents of the disk indicated by the column 602 and the contents of the disk indicated by the column 603 are in a synchronized state or in a separated state. When in the synchronized state, the change to the disk indicated in column 602 is simultaneously performed in column 60.
This is reflected in the subdisk indicated by 3. In the separated state, the disk indicated by column 602 and the subdisk indicated by column 603 are updated independently. The pair of the disk 504 in the disk mapping table and the spare disk in the column 506 of the disk mapping table shown in FIG. 5 and the pair of the main disk in the column 602 and the subdisk in the column 603 of the disk synchronization table are the same. .

FIG. 7 shows details of the disk mapping function 131 in the external disk device 103 in FIG. The disk mapping function 131 is the disk 1 of the external disk device 103.
33 is mapped to the ID of the adapter 120 installed in the server 102 connected to the disk array device 103 via the network switch 104. Disks cannot be referenced from servers with IDs not in this mapping relationship. As a result, it is possible to perform security settings that allow a certain disk to be accessed only from a certain server. For this security setting, in this embodiment, the disk mapping function 130 has an access permission table shown in FIG. A column 701 indicates an ID that permits access. A column 702 indicates an identifier of a disk accessible by the ID of the column 701.

FIG. 34 shows details of the boot configuration table 309 in FIG. Column 510
1 indicates an identifier of the server. A column 5102 indicates a device used by the server for booting. For example, in the case of a server that boots from an internal disk, it is IDE or SCSI,
For servers booting from Fiber Channel or iSCSI, iSCSI, SAN, etc. Also,
When there are a plurality of adapters 120 used for booting the server, the boot device information can identify the device. Here, a plurality of identifiers of the same server in the column 5101 indicate information for booting from different boot devices on the same server. A column 5103 indicates a device path of the boot device of the server. The device path is, for example, a special device / dev / sda1 indicating an I / O device in the case of Linux. L
Inux boot loaders such as GRUB and LILO use this device path to specify the device to boot. In addition, this device path corresponds to information on a device to be mounted described in this setting file, in which a device mounted by a file system such as Linux EXT3 is set in the file / etc / fstab. The device path is Windows
In the case of (registered trademark), this corresponds to the setup parameter of the boot device multi (0) disk (0) rdisk (0) partiotn (1) of the boot loader set in the boot.ini file. Column 5
Reference numeral 104 denotes a target WWN of the boot device. For example, when the target device is an external disk device, it is the port WWN used for booting the external disk device. A column 5105 indicates the target LUN number of the boot device. The LUN number is a logical identification number of the disk of the external disk device. For example, when the adapter 120 mounted on the server 102 is a fiber channel HBA, the information in the column 5104 and the column 5105 corresponds to information on a target device that the HBA BIOS uses for booting. A column 5106 is boot setting information used by the boot program 220 for booting. Here, the boot program setting information is, for example, the PCI bus number or device number of the adapter 120 used for booting, the UUID for each EFI partition, etc., when the boot program 220 is EFI.

FIG. 8 shows a disk mapping change example in the present embodiment. Server 1 (801
The adapter 810 installed in) has WWN1 (811), and the adapter 820 installed in the server 2 (802) has WWN2 (821). These are connected to the external disk device 103 via the network switch 104. The disk mapping is controlled by the disk mapping mechanism 131. The disks 831 and 833 are mapped to WWN1 (811) of the server 1 (801), and the disk 832 is mapped to WWN2 (821) of the server 2 (802). Yes. The disks 831 and 833 are accessible only from the server 1 (801), and the disk 832 is accessible only from the server 2 (802). The disks 831, 832, and 833 include a boot disk in which an OS and a business application are installed.

FIG. 9 shows an example of disk synchronization in this embodiment. The adapter 910 mounted on the active server (901) has WWN1 (911), and the adapter 920 mounted on the spare server (902) has WWN2 (921). These are connected to the external disk device 103 via the network switch 104. The disk synchronization process is controlled by the disk synchronization mechanism 132, and changes made to the disk 831 are reflected on the disk 931 at the same time. As a result, the contents of the disk 831 and the disk 931 are synchronized. In the example of this figure, the disk 831 is mapped to WWN1 (911) of the active server (901) by the disk mapping mechanism. When a failure occurs in the active server (901), the disk 831 and the disk 931 are immediately separated to cancel the synchronization process, and the disk 931 is mapped to the WWN2 (921) of the spare server (902), By booting the server (902), the active server (901) can take over the work that the active server (901) has been operating in while the active server (901) can access the disk 831.

FIG. 10 shows an operation sequence of the embodiment of the present invention. The sequence shown is the active server 1001, the spare server 1002, the failover mechanism 1003, the disk synchronization mechanism 1004, the disk mapping function 1005, and the boot configuration change mechanism 1006. Step 1030 indicates a disk synchronization start request of the failover mechanism 1003.
In response to this request, the disk synchronization mechanism 1004 starts disk synchronization in step 1040. The disks to be synchronized here are the main disk of the active server 1001 and its subdisks existing in the disk synchronization table shown in FIG. When the synchronization process is started, operation of the active server is started in step 1010. Thereby, the work of the active server 1001 is started. Step 1011 indicates that a failure has occurred in the active server 1001 in operation. In step 1031, the failover mechanism 1003 detects the occurrence of a failure. At the same time, the failure cause analysis work of the active server 1001 in which the failure has occurred is performed in step 1012. This work is a disk dump of the OS memory. In parallel with this step 1012, the failover mechanism 1003 identifies that the failed server is the active server 1001 in step 1032. In response to the result of step 1032, in step 1033, the disk synchronization mechanism 1004 is requested to cancel the synchronization of the primary disk and subdisk of the active server 1001. In step 1041, the disk synchronization mechanism 1004 cancels the synchronization of the main disk and subdisk of the active server 1001. When the synchronization release is completed, the failover mechanism 1003 searches for the spare server 1002 for the active server 1001 in step 1034. For this search, the server management table shown in FIG. 4 is used. In step 1035, the disk mapping mechanism 1005 is instructed to map the subdisk of the active server 1001 to the spare server 1002. In step 1050, the disk mapping mechanism 1005 maps the subdisk of the active server 1001 to the spare server 1002. When the mapping is completed, the activation of the spare server 1002 is requested in step 1036. In step 1020, the spare server 1002 is activated, and information indicating that the boot program has been activated on the network is transmitted. This information is, for example, a magic packet broadcast to the network in order to execute PXE boot. The boot configuration change mechanism 1006 receives the information transmitted in Step 1020 and requests the spare server 1002 to perform a network boot in Step 1061. The spare server 1002 performs a network boot in step 1022, and the booted agent 370 starts communication with the boot configuration change mechanism 1006. In step 1062, the boot configuration change mechanism 1006 notifies the agent 370 of a request for changing the boot program setting of the spare server 1002. In step 1023, the agent 370 changes the boot server setting of the spare server. Here, the setting is changed, for example, for the system BIOS and EFI boot priority of the spare server, the boot device setting, and the boot target device of the adapter 120 such as the HBA. In step 1024, agent 370 reboots the spare server. In step 1021, the spare server 1002 boots using the mapped subdisk, and in step 1021, takes over the work of the active server and restarts. Even after the spare server 1002 takes over the work, the active server 1001 can continue the failure cause analysis work. When the failure cause analysis work is completed, the active server 1001 is stopped in step 1012.

Hereinafter, the sequence in FIG. 10 will be described in more detail. FIG. 11 shows an operation flow of the server failure management detection function 301. Step 1101 indicates that a server failure report notification is received via a network or the like when a server failure occurs. When the BMC 122 of the server 102 shown in FIG. 1 detects a failure, the failure of the server 102 is notified to the server failure detection mechanism 301. When this is received, a server failure report notification is received at step 1101. In step 1102, the identifier of the failed server is specified based on information such as the physical location information of the server where the failure has occurred, which is present in the failure report notification information. Next, in step 1103, the type of fault that has occurred is identified based on the fault type information present in the fault report notification information. In step 1104, the server failure management function 302 is notified of information on the server where the failure has occurred and the type of failure.

FIG. 12 shows details of processing sequences of the server failure management function 302 and the storage management function 304. Step 1201 indicates that the notification of the failure server identifier shown in Step 1104 of FIG. 11 and the type of failure that occurred has been received. In step 1202, the storage management function 304 is requested to cancel the disk synchronization processing of the server where the failure has occurred. At this time, the request includes information on the identifier of the failed server. Step 12
In 03, referring to the disk mapping table shown in FIG. 5 based on the identifier of the failed server, the used disk of the failed server is searched. In step 1204, step 1
Based on the disk information found as a result of the search in step 203, the sub-disk is searched with reference to the disk synchronization table shown in FIG. In step 1205, the disk synchronization mechanism 132 shown in FIG. 1 is requested to cancel the synchronization processing of the combination of the sub disk and the main disk discovered in step 1204. When the disk synchronization mechanism 132 completes releasing the disk synchronization, in step 1206, a notification of completion of the synchronization processing cancellation is received. In step 1207, the server management table shown in FIG. 4 is referred to search for a spare server that becomes a failover destination for the failed server. In step 1208, a request is made to map the spare disk of the failed server to the spare server discovered as a result of step 1207. At this time, the request includes information on the identifier of the failed server. In step 1209,
A request is made to the disk mapping mechanism 131 shown in FIG. 1 to map the spare disk of the failed server to the spare server. In this embodiment, the spare disk in the disk mapping table shown in FIG. 5 and the sub-disk in the disk synchronization table shown in FIG. 6 are the same. The subdisk that requested release is mapped. When the mapping process is completed in the disk mapping mechanism 131, a disk mapping completion notification is received in step 1210. In step 1211, the spare server is activated. As a result, the spare server is activated using the subdisk of the failed server.

FIG. 35 shows details of the processing sequence of the network boot function 307, the boot management function 308, and the agent 370. Step 5211 indicates that the boot program 5200 started after the spare server is started transmits network boot information. Here, the network boot information is, for example, a magic packet sent to a DHCP server in order to execute PXE boot. In step 5212, the network boot function 307 receives the network boot information transmitted in step 5211. Step 5213 indicates that the network boot information is received and the agent 370 is sent to the spare server as a network boot program. In step 5214, the spare server boot program 5200 activates the agent 370 received from the network boot function 307. In step 5215, the agent 370 activated in step 5214 requests boot device update information from the boot management function 308. In step 5216, the boot management function 308 refers to the boot configuration table 309 to obtain information used by the migration source active server for booting and information necessary for the spare server to boot from the spare disk 134. get. In step 5217, the boot server information of the active server and the spare server acquired in step 5216 are compared, the boot setting information of the spare server boot program 220 and the adapter 120, the operating system and application installed on the spare disk 134 It investigates whether there is information to be updated among the boot device and mount point information used by the program, and creates the information to be updated as boot device update information. In step 5218, the boot device update information created in step 5217 is notified to the agent 370. In step 5219, the agent 370 receives the boot device update information, and updates the setting information recorded in the nonvolatile memory 203 if it is necessary to change the boot setting information of the boot program 220 and the adapter 120. Here, if the adapter 120 is a PCI card, for example, the nonvolatile memory 203 also includes a non-volatile memory mounted on a PCI card. For example, when the boot program is EFI, the content to be updated registers the information of the boot program setting information 5106 in the boot configuration table 309 as the EFI boot device path. The update contents of the adapter 120 include, for example, a target WWN and a target LUN, which are boot target devices set in the HBA-BIOS, when the adapter 120 is a fiber channel HBA. In step 5220, referring to the boot device update information, if it is necessary to update the contents of the spare disk, the contents of the spare disk are updated. Here, the contents to update the spare disk include, for example, Linux boot loader boot device information and device mount information when Linux is installed as an operating system on the spare disk. In step 5221, the agent reboots the spare server. After the reboot, the spare server does not perform a network boot, but boots using the spare disk.

In the second embodiment of the present invention, the external disk device controller 130 shown in the first embodiment.
The disk mapping mechanism 131 present in FIG.

FIG. 13 shows an overall view of the second embodiment of the present invention. The difference from the first embodiment is that a security mechanism 141 that operates in the network switch controller 140 of the network switch 104 is provided. Further, the disk mapping mechanism 131 existing in the external disk device controller 130 may not exist. The security mechanism 141 is a security function that restricts devices that can communicate between devices such as the server 102 and the external disk device 103 connected to the network switch. Network switch 104
Examples of typical security functions are VLAN and zoning.

FIG. 14 shows details of the security mechanism 141 shown in FIG. The security mechanism 141 has a security table 1400. A column 1401 shows a list of IDs indicating the physical positions of the ports of the network switch 140. A column 1402 indicates the security group to which the port ID belongs. The security mechanism 141 enables communication between devices connected to the same port in the security group. The port ID in the column 1401 may be a WWN or MAC address that is a unique ID of the adapter 120 of the device connected to the port.

FIG. 15 shows an example of changing the security setting of this embodiment. Here, it is assumed that all the disks (831, 832, and 833) of the external disks are accessible without using the disk mapping mechanism 131 of the external disk device 130. Network switch 1
04, when the security mechanism 141 does not exist, the server 1 (801) and the server 2 (8
02), the disks 831, 832, and 833 are accessible. When the security setting is performed so that the security mechanism 141 groups the port 1 and the port 6 of the network switch 104 into the same group, the server 1 (801) connected to the port 1
) Enables access to the external disk device 103 connected to the port 6, and the port 2
By not permitting access from the server 2 (802) connected to the port 6 to the port 6, the disks 831, 832 and 833 cannot be accessed from the server 2 (802). By changing the security setting of the security mechanism 141 and setting port 2 and port 6 to the same group, the disks 831, 832, and 833 can be accessed from the server 2 (802).

FIG. 16 shows an example of information added to the server management table 303 shown in FIG. 4 in this embodiment. Column 1601, column 1602, and column 1603 are additional information.
A column 1601 indicates the ID of an adapter installed in the server indicated in the column 501, and this is the same as the column 502 in the disk mapping table shown in FIG. A column 1602 indicates a connection destination network switch ID for identifying the network switch 104 to which the adapter having the ID information in the column 1601 is connected. A column 1603 indicates a connection destination network switch port ID which is identification information indicating the position of the port of the network switch 104 to which the adapter having the ID information in the column 502 is connected. Using this information,
The failover mechanism 110 can acquire the network switch 104 to which the server 102 is connected and the port position.

FIG. 17 shows an operation sequence of this embodiment. The sequence shown is the active server 1001, spare server 1002, failover mechanism 1003, disk synchronization mechanism 10.
04, a boot configuration change mechanism 1006, and a security mechanism 1705. Step 1750 is different from the first embodiment. In step 1750, the security setting of the security mechanism 141 is changed so that the spare disk 134 of the active server can be accessed from the spare server. As a result, the spare server can be started up using the spare disk 134 that has become accessible.

FIG. 18 shows a server failure management function 302 and a storage management function 304 in this embodiment.
The details of the processing sequence are shown. Steps 1809 and 1810 are different from the first embodiment. In step 1809, the storage management function 304 performs step 120.
5 requests the security mechanism 141 to make the disk whose synchronization processing has been released accessible from the spare server. In step 1810, the storage management function 304 receives a notification of completion of the security setting change process requested in step 1809 from the security mechanism 141. As a result, the spare server can access the spare disk 134 of the active server from the spare server.

FIG. 19 shows another operation sequence of the present embodiment. The sequence shown is the active server 1001, spare server 1002, failover mechanism 1003, disk synchronization mechanism 1004, boot configuration change mechanism 1006, and security mechanism 1705. Steps 1900 and 1901 are different from FIG. In step 1900, the network switch 10 to which the NIC of the active server is connected to the security mechanism 141.
4 port is unavailable and requests to isolate the active server from the network. In step 1901, the security mechanism 141 of the network switch 104 makes the port of the network switch 104 to which the NIC of the active server 1001 is connected unavailable. Thus, by stopping the flow of information output from the NIC of the active server 1001 to the network, for example, information such as an IP address is avoided from competing with the spare server 1002 activated in step 1020 on the network. Another method for isolating the network is to change the group ID of the port of the network switch 140 to which the NIC of the active server 1001 is connected to a group ID to which no port of the network switch 140 belongs.

In the third embodiment of the present invention, unlike the first embodiment, the external disk device 10 shown in FIG.
Even if the disk synchronization mechanism 132 does not exist in FIG.
3 and the spare disk 134 synchronize the contents of the disk. In the present embodiment, the configuration of the server 102 shown in FIG.
FIG. 20 shows details of the server 102 of this embodiment. The difference from FIG. 2 of the first embodiment is that
The mirroring mechanism 2000 exists. Mirroring mechanism 2000 is CPU20
2, and the server 102 uses the disk 13 of the external disk device 103.
3 provides a function for simultaneously outputting all the information output to 3 to the spare disk 134.

FIG. 21 shows an example of disk synchronization by the mirroring mechanism 2000 of this embodiment. A write command 2100 to the disk 2101 issued from the server 102 is converted by the mirroring mechanism 2000 into a process of writing the same contents to both the disk 2101 and the spare disk 2102 of the external disk device 103. Thus, the disk 210
1 and the contents of the spare disk 2102 can be synchronized. When the server 102 has an internal disk, the mirroring mechanism 2000 can synchronize the contents by writing the same contents to the internal disk and the disk 2101 or the spare disk 2102 of the external disk device 103.

FIG. 22 shows an operation sequence of this embodiment. The sequence shown is the active server 1001, spare server 1002, failover mechanism 1003, disk mapping mechanism 1005, and boot configuration change mechanism 1006. Step 22 is different from the first embodiment.
01 exists, the sequence of the disk synchronization mechanism 1004 does not exist, and the steps related to the disk synchronization mechanism 1004 are reduced. In step 2201, the disk 2101 shown in FIG.
And the contents of the spare disk 2102 start to be synchronized. As a result, even if the disk synchronization mechanism 1004 does not exist, the contents can be synchronized with a plurality of disks.

FIG. 23 shows a server failure management function 302 and a storage management function 304 in this embodiment.
The details of the processing sequence are shown. The difference from the first embodiment is that step 2300 and steps related to the disk synchronization mechanism are reduced. In step 2300,
The disk mapping mechanism is requested to map the spare disk 2102 of the active server shown in FIG. 21 to the spare server.

The fourth embodiment of the present invention is a method in which the server 102 has a local disk when the disk 133 of FIG. 1 shown in the first embodiment does not exist. In the present embodiment, it is assumed that the active server operates a business using a local disk.

FIG. 24 shows an overall view of this embodiment. The difference from FIG. 1 of the first embodiment is that the external disk device 103 does not have the disk 133 and the disk synchronization mechanism 132, the server 102 has the local disk 123, and the management server 101 has the backup mechanism 2400. That is. Note that the server 102 serving as the spare server may not have the local disk 123.

FIG. 25 shows details of the server 102 in this embodiment. The difference from FIG. 2 of the first embodiment is that a local disk 123 is provided.

FIG. 26 shows details of the operation of the backup mechanism 2400 of this embodiment. The backup mechanism 2400 is connected to the local disk 12 of the server 102 via the network switch 104.
3 is read and copied to the spare disk 134 of the external disk device 103.
FIG. 27 shows an operation sequence of this embodiment. The sequence shown is the active server 1001, spare server 1002, failover mechanism 1003, backup mechanism 270.
0, a disk mapping mechanism 1005, and a boot configuration change mechanism 1006. The difference from the first embodiment is that the step 1033 does not exist, the existence of the backup mechanism 2700, and the steps 2701 and 2702. In step 2701, the failover mechanism 1003 requests to back up the contents of the local disk 123 of the active server 1001 to the spare disk of the external disk device. In step 2702, the backup mechanism 2700 receives the backup request from the failover mechanism 1003, and copies the contents of the local disk of the active server 1001 to the spare disk of the external disk device.

FIG. 28 shows an example of the disk configuration of the server and the external disk device in this embodiment. In FIG. 28, the active server 2801 and the spare server 2802 have a shared disk 2803.
By writing the setting data, logs, and the like of the application operating on the active server 2801 to the shared data 2804 on the shared disk 2803, the contents of the spare disk 134 used by the spare server 2802 for booting and the local disk of the active server 2801 281
Even if the contents do not match with 0, the spare server 2802 can be started up in a state where the application settings match with the active server 2801.

The fifth embodiment of the present invention is a method that does not always execute the disk synchronization processing shown in the first embodiment.

FIG. 29 shows an operation sequence of this embodiment. The sequence shown is the active server 1001, spare server 1002, failover mechanism 1003, disk synchronization mechanism 10.
04, a disk mapping mechanism 1005, and a boot configuration change mechanism 1006. Example 1
The difference is that step 1033 does not exist and steps 2901 and 29
02 and step 2903. In step 2901, after the business operation is started in the active server 1001 in step 1010, the failover mechanism 1003 requests the contents of the disk used by the active server 1001 to be synchronized with the spare disk of the external disk device. In step 2902, the disk synchronization mechanism 1004 synchronizes the contents of the disk used by the active server 1001 with the spare disk of the external disk device. Step 29
In 03, the synchronization is released when the contents of the disc match in step 2902. As a result, a failure occurs in the active server 1001 in step 1011, and the active server 100
Even if the contents of the disk used by 1 are destroyed, the contents of the spare disk used by the spare server 1002 are not destroyed.

The sixth embodiment of the present invention is an example in which the server boot disk is changed to another disk instead of migrating the server in the fourth embodiment. In the fourth embodiment, the server boot configuration is changed due to a server failure. However, in this embodiment, any server boot configuration change timing may be used. Therefore, in this embodiment, the server failure detection mechanism 301 of the failover mechanism 110 of the fourth embodiment may not exist. In this embodiment, the server that boots from the internal disk is changed to boot from the external disk device. However, the server that boots from the external disk device can also be changed to boot from the internal disk.

FIG. 30 shows an overall view of another embodiment of the present invention. The difference from FIG. 24 of the fourth embodiment is that the system of the present embodiment includes one server 102. However, a plurality of servers may exist.

FIG. 31 shows a sequence of this embodiment. The difference from FIG. 27 of the fourth embodiment is that there is no spare server, the step related to the active server, and the start of the boot configuration change in step 3101 without being triggered by the occurrence of a failure. In step 3102, the failover mechanism 1003 activates the active server 1001. In step 3103, the active server is activated, and in step 3104, network booting is started. Step 310
In step 5, the active server boot program is updated. In step 3106, the active server is rebooted. In step 3107, the active server boots using the spare disk and resumes the business. In this embodiment, even if the network boot function 307 does not exist,
For example, if the agent 370 is installed on the disk 123 of the active server, the agent 370 operates on the active server in step 3101, and step 310
The sequence from 5 is simply executed.

FIG. 32 shows a detailed sequence of the server failure management function 302 and the storage management function 304 of the failover mechanism 110 in this embodiment. In step 3201, a boot configuration change request is accepted. This request can be requested manually by the computer system administrator,
It may be automatically requested from other software. In step 3202, the storage management function 304 is instructed to map the spare disk to the active server. In step 3203, the storage management function 304 requests the disk mapping function to map the spare disk to the active server. In step 3204, the disk mapping mechanism receives a notification of completion of the disk mapping request in step 3203. Step 3205
Then, the server failure management function 302 activates the active server.

FIG. 33 shows a network boot function 307 and a boot management function 30 in this embodiment.
8 and details of the processing sequence of the agent 370 are shown. The difference from the processing sequence of the first embodiment shown in FIG. 35 is that the spare server is changed to the active server and step 3316. In step 3316, information on the boot device of the spare disk of the active server is acquired from the boot configuration table. For example, when the boot device of the active server is changed from IDE to SAN, in the boot device in column 5102 in FIG.
Change from IDE to SAN.

Even in the case where the disk mapping function 131 of this embodiment does not exist, the security mechanism 141 of FIG. Further, even when the backup function 2400 of the present embodiment does not exist, the mirroring mechanism 2000 shown in FIG.

The boot configuration change method of this patent can be used as a method for taking over a job running on a certain server to another server. In addition, while a business that is one server is in operation, software and hardware updates and replacement work and test work can be performed in parallel on the other server.

101 Management Server 102 Server 103 External Disk Device 104 Network Switch 110 Failover Mechanism 120 Boot Configuration Change Mechanism 120 Adapter
121 NIC
122 BMC
123 Local disk 130 External disk device controller 131 Disk mapping mechanism 134 Spare disk 2400 Backup mechanism

Claims (18)

The management server and server are connected to the external disk device via a network switch.
In the computer system that can be started by booting an operating system from the external disk device or an internal disk of each server, the server is a boot configuration changing method for changing a disk used for booting by the server,
The management server
A synchronization step for requesting synchronization start with the destination disk of the contents of the pre-migration disk used by the server for booting;
Receiving a request to change the disk used by the server from the pre-migration disk to the migration destination disk, and requesting to stop synchronization processing between the pre-migration disk and the migration destination disk;
Compare device paths of the pre-migration disk and the migration destination disk to the server,
A disk content change step for requesting to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to the device path of the migration destination disk when the device path is different;
A boot configuration change method characterized by comprising: 2. The disk content changing step, wherein the server is restarted, the server receives and executes an agent from the management server by network boot, and the agent changes a boot loader setting and a mount setting. Boot configuration change method. After the synchronization step, the management server further compares boot program setting information of the pre-migration disk and the migration destination disk for the server, and if the boot program setting information is different, sets the boot program setting of the server. The boot configuration change method according to claim 1, further comprising a boot program setting change step for requesting to change to the boot program setting information of the migration destination disk. In the boot program setting changing step, the server is restarted, the server receives and executes an agent from the management server by network boot, and the agent changes the boot program setting of the server. The boot configuration change method according to claim 3. In the boot program setting changing step, in addition to the boot program setting information of the pre-migration disk and the migration destination disk for the server ,
4. The boot configuration change method according to claim 3, wherein the target WWN and the target LUN are compared, and if either of them is different, a request is made to change the corresponding information of the boot program setting of the server. The management server and server are connected to the external disk device via a network switch.
Each of the servers is a boot configuration change method for changing a disk used for booting by the server in a computer system that can be started by booting an operating system from the external disk device,
The management server
A boot configuration table that holds device paths in the boot program settings, boot loader and mount settings required for the server and the server to boot from the disk;
A synchronization step for requesting synchronization start of the contents of the pre-migration disk used by the active server, which is one of the servers, for booting with the migration destination disk;
A disk that requests to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to a setting for the spare server to boot from the migration destination disk based on the boot configuration table Content change step;
A boot configuration change method characterized by comprising: In the disk content changing step, the spare server is restarted, the spare server receives and executes an agent from the management server by network booting, and the agent changes a boot loader setting and a mount setting. Item 6
Boot configuration change method. The management server, after the synchronization step, further request to stop the synchronization processing of the pre-migration disk and the migration destination disk,
A boot program setting change step for requesting the spare server other than the active server to be changed to a setting for the spare server to boot from the migration destination disk based on the boot configuration table. The boot configuration changing method according to claim 6, further comprising: In the boot program setting changing step, the spare server is restarted, the spare server receives and executes an agent from the management server by network boot, and the agent changes the boot program setting of the spare server. 9. The boot configuration change method according to claim 8, wherein In the boot program setting changing step, in addition to the boot program setting information of the pre-migration disk and the migration destination disk for the spare server , the target WWN and the target LUN are further compared. 9. The boot configuration change method according to claim 8, wherein the corresponding information of the server boot program setting is changed. The management computer and computer are connected to the external disk device via a network switch.
In the computer system in which the computer can be started by booting an operating system from the external disk device or the internal disk of each computer,
The management computer is
Synchronizing means for requesting synchronization start of the contents of the pre-migration disk used by the computer for booting with the migration destination disk;
A synchronization release unit that accepts a request to change the disk used by the computer from a pre-migration disk to a migration destination disk, and requests to stop synchronization processing between the pre-migration disk and the migration destination disk;
Compare the device path of the pre-migration disk and the migration destination disk for the computer,
If the device path is different, disk content changing means for requesting to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to the device path of the migration destination disk;
A management computer characterized by comprising: The management computer further compares the boot program setting information of the pre-migration disk and the migration destination disk for the computer, and if the boot program setting information is different, sets the boot program setting of the computer to the migration destination disk. 12. The management computer according to claim 11, further comprising boot program setting change means for requesting to change to boot program setting information. The management computer and computer are connected to the external disk device via a network switch.
In each computer system, each of the computers can be started by booting an operating system from the external disk device.
The management computer is
A boot configuration table that holds device paths in the computer and a boot program setting, a boot loader, and a mount setting that are necessary for the computer to boot from the disk;
Synchronizing means for requesting the start of synchronization with the migration destination disk of the contents of the pre-migration disk used for booting by the current computer that is one of the computers,
A disk that requests to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to a setting for the spare computer to boot from the migration destination disk based on the boot configuration table Content change means,
A management computer characterized by comprising: The management computer further compares the boot program setting information of the pre-migration disk and the migration destination disk for the computer, and if the boot program setting information is different, sets the boot program setting of the computer to the migration destination disk. 14. The management computer according to claim 13, further comprising boot program setting change means for making a request to change to boot program setting information. The management server and server are connected to the external disk device via a network switch.
In the computer system in which the server can be started by booting an operating system from the external disk device or the internal disk of each server,
The management server
Synchronization means for requesting synchronization start of the contents of the pre-migration disk used by the server for booting with the migration destination disk;
A synchronization release unit that accepts a request to change a disk used by the server from a pre-migration disk to a migration destination disk, and requests to stop synchronization processing between the pre-migration disk and the migration destination disk;
Compare device paths of the pre-migration disk and the migration destination disk to the server,
If the device path is different, disk content changing means for requesting to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to the device path of the migration destination disk;
A computer system characterized by comprising: The management server further compares the boot program setting information of the pre-migration disk and the migration destination disk for the server, and if the boot program setting information is different, sets the boot program setting of the server to the migration destination disk. 16. The computer system according to claim 15, further comprising boot program setting change means for requesting to change to boot program setting information. The management server and server are connected to the external disk device via a network switch.
Each of the servers is a computer system that can be started by booting an operating system from the external disk device.
The management server
A boot configuration table that holds device paths in the boot program settings, boot loader and mount settings required for the server and the server to boot from the disk;
Synchronization means for requesting the start of synchronization of the contents of the pre-migration disk used for booting by the active server as one of the servers with the migration destination disk;
A disk that requests to change the device path in the boot loader setting and mount setting of the operating system held by the migration destination disk to a setting for the spare server to boot from the migration destination disk based on the boot configuration table Content change means,
A computer system characterized by comprising: The management server further includes synchronization cancellation means for requesting stop of synchronization processing between the pre-migration disk and the migration destination disk;
Boot program setting change means for requesting the spare server to change the setting for booting from the migration destination disk, based on the boot configuration table, the setting of the boot program of the spare server different from the active server 18. The computer system according to claim 17, further comprising:

Images