JP2007213271A - Server information collection method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to easily acquire server information from a server in an OS non-distribution status and to correlate a WWN to specify the server with a preliminarily assigned LU in a module type server system. <P>SOLUTION: An LU 142 in which an OS for acquiring information is stored is placed in a region 146 whose access restriction is not operated by a manager who manages a storage, and the OS for acquiring information is started on a server 105 set so as to be booted from an FCA. A WWN acquired from the OS for acquiring information is associated with an LU for production on a management server 120, and the LU for production is started the second and following times. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method for collecting server information from a server before OS distribution and switching a boot LU on the storage side using the collected server information in a modular server system in which a large number of server devices are connected to a storage device.

  In a modular server system, when a server is newly added to the system, it is necessary to collect and set hardware information of each server in order to distribute and set the OS, middle software, and application, and to manage them.

  Conventionally, since a server after OS distribution is a management target, it is possible to collect server status via an agent on the OS. However, in the case of the server that has just been installed, since the OS is not distributed, the administrator cannot grasp the ID for identifying the server. In general OS distribution software, the MAC address is often an ID for identifying a server. In the system configuration using such OS distribution software, the server is turned on once, network boot is selected on the BIOS screen, and the MAC address displayed for a moment at the time of booting is written.

  On the other hand, in order to acquire server hardware information from a server to which no OS is distributed, there is a method of distributing a server information acquisition mini-OS to a server using network boot.

JP 2002-123396 A

  There are problems of working time and occurrence of mistakes in performing the work of writing the MAC address displayed at the time of booting and associating the MAC address with the OS undistributed server to a large number of servers. On the other hand, in the method of distributing the mini-OS using network boot and acquiring the hardware information of the server using this mini-OS, the VLAN setting of the network switch is changed so that the broadcast packet passes. There was a need to change the boot order setting of the BIOS. Changing the VLAN settings should be avoided because it may affect business operations. Further, it is not realistic to change the boot order setting of the BIOS one by one over several hundred units because it takes a lot of time and labor.

  Therefore, an object of the present invention is to provide a server information collecting method capable of easily acquiring server hardware information from a server to which no OS is distributed. Another object of the present invention is to provide a server hardware information collection method in which there is no need to change VLAN settings for information collection, and BIOS order setting does not require work even after information collection.

  In the present invention, the LU that stores the information collection OS is placed in an area where the manager managing the storage does not restrict access, and the information collection OS is started on the server that is set to boot from the FCA once. The WWN acquired from the information collection OS is associated with the LU used in the production environment via the management server. After this association, the OS is started from the LU used in the production environment where the previous association is executed by the access restriction function provided by the manager managing the storage.

  Server hardware information can be easily obtained from an OS non-distributed server. There is no need to change the VLAN settings for information collection. Further, there is no need to change the BIOS boot order setting after information acquisition.

  FIG. 1 shows the overall configuration of a modular server system according to a first embodiment of the present invention. The plurality of servers 105 are stored in the chassis 101 together with the internal network switch 103 and the service processor (SVP) 102. Each server 105 is connected to an internal network switch 103 via a network interface card (NIC) 107 and connected to a switch 130 via a fiber channel adapter (FCA) 108. The server 105 has a built-in BMC (Baseboard Management Controller) 106. The BMC 106 is connected to the SVP 102, and can perform hardware status monitoring, power control, server 105 reset, and the like via the network.

  In general, the BMC 106 is supplied with a power supply different from that of the server 105, and the BMC 106 can be remotely operated via the network even when the server is stopped. The NIC 107 has a communication function and has a memory for storing a MAC address. The FCA 108 has a memory for storing a WWN (World Wide Name). Generally, since the MAC address and WWN have unique values all over the world, it is possible to identify each individual by these values.

  The switch 130 is also connected to the disk array device 140 and can be accessed from the server 105. The disk array device 140 includes LUs (Logical Units) 142, 143, 144, and 145 and a disk array management mechanism 141 that manages LUs. The internal network switch 103 is connected to a network switch 110 outside the chassis 101. The network switch 110 is also connected to an SVP 102 that manages the chassis 101, a management server 120 that manages the system, and a disk array management mechanism 141 that manages the disk array device 140 and LUs 142 to 145. The server 105 can be logically divided into a plurality of IP networks 109 by VLAN (Virtual LAN) using the internal network switch 103. As a result, it is possible to prevent different business operations executed in adjacent servers from interfering with each other in a network, and this is an indispensable function in current server operation.

  In this embodiment, unicast packets transmitted / received to / from a specific IP address are allowed to pass, but broadcast packets transmitted / received to an unspecified IP address are blocked. Therefore, the plurality of servers 105 are divided into a plurality of VLAN groups 109, and unicast packets to the management server 120 pass. For the management LAN for managing the server 105 by the management server 120 and the business LAN used by the server 105 for business, the same physical network wiring is used. A function similar to a VLAN in an IP network also exists in the storage. This is realized by controlling the disk array management mechanism 141 to group a plurality of LU 144 to form a host group 147 and accept only access from a specific server 105. The LU 144 stores middle software and applications including a production environment OS that provides services. By associating this LU 144 with the WWN of the FCA 108 of the server 105, the OS of the production environment can be started on the server 105, and a business can be provided.

  The LU 142 and LU 143 existing in the area 146 where access control is not performed can be accessed from any server. Here, an OS (Operating System) for collecting information is stored in the LU 142 in advance. By booting this information collection OS, it is possible to collect hardware information such as the MAC address, WWN, and CPU architecture of the booted server. There is no problem with any OS that collects information. In addition, there is no limitation on the OS capacity which is a problem in network booting, and there is no problem if it can be basically expanded on the boot destination memory. In the case of network boot, it is necessary to change the VLAN setting so that a broadcast packet passes. Changing the settings of a network switch that is running a business is very risky because there is a risk that the business on all servers connected to the network switch will stop due to a setting mistake. It should be avoided as much as possible. In this embodiment, since there is no need to change the network switch setting, there is no risk of business interruption due to the network switch setting change.

  In the initial state, the physical connection is completed, the BIOS is set to boot from the FCA, the information acquisition target server 105 is turned off, and the information collection OS is in the area 146 where access control is not performed. Is stored. The LU 143 is an LU that stores information used when the information collection OS acquires an IP address. Details will be described later. A management mechanism 121 exists in the management server 120 and controls processing characteristic of the present invention.

  FIG. 2 shows the configuration of the management mechanism 121. The management mechanism 121 includes an information acquisition mechanism 202, a queue management mechanism 203, a server configuration information table 205, a hardware information table 206, a same server determination table 207, an information collection flag update table 208, and an alert reception mechanism 209. The The management mechanism 121 receives a trigger related to information collection, and issues a command for associating information acquisition and the target LU 144 with the WWN that is the unique ID of the FCA 108. The information acquisition mechanism 202 receives an information acquisition request generated by an alert such as a command execution received by the management mechanism 121, an information acquisition request by pressing a button, or a configuration change, and executes information acquisition. The detailed flow is shown in FIG.

  The queue management mechanism 203 controls the execution order of information acquisition requests. With respect to the server 105, it is difficult to associate information such as the chassis 101 number and slot number (such as a rack name and a stage number for a 1U server) specifying the position with server information such as a MAC address and WWN. For this reason, in this embodiment, as a method for identifying whether or not a server that has been powered on can be taken, power is sequentially turned on. The queue management mechanism 203 is responsible for storing entries in the queue 204 (see FIG. 11), retrieving character entries (see FIG. 12), and confirming all entries (see FIG. 13).

  The server configuration information table 205 includes server location information, VLAN settings, IP address assignment, LU assignment, etc. defined by the user, server information collected by the information collection OS stored in the LU 142, and information collection. The IP address and information acquisition information used when the operating OS is in operation are stored.

  The hardware information table 206 stores server information obtained by booting the information collection OS stored in the LU 142 on the server 105 and collecting information. The server information used in the server configuration information table 205 refers to the hardware information table 206.

  The same server determination table 207 is a table that defines which information is regarded as the same server when the information matches. Further, the same server determination table 207 has a flag that determines whether or not to execute information acquisition by triggering information acquisition when a configuration change alert is received. This makes it possible to control the timing of information acquisition. In addition, it is possible to make it difficult for information mismatch to occur by forcibly collecting information.

  The information collection flag update table 208 is a table that defines an alert that triggers information collection. This makes it possible to collect information triggered by various alerts.

  The alert receiving mechanism 209 receives an alert associated with the configuration change of the server 105, refers to the information collection flag update table, cancels the association between the set WWN and LU 144, and changes the new WWN and LU 144 after the change. A request for acquiring a new WWN is issued to the management mechanism 121 in order to execute the association.

  FIG. 3 shows the configuration of the queue 204. A column 301 stores a queue number and indicates the order of entries. A column 302 stores a chassis number, and a column 303 stores a slot number. Columns 302 and 303 store information for specifying servers as information acquisition destinations. The queue management mechanism 203 sequentially takes out entries from the queue 204, so that processing can be executed sequentially. As a processing procedure, an alert may be added at the end, and in the case of command execution or button press, processing based on a priority order such as adding forward between columns 351 and 352 may be performed. As a result, the server information can be updated or referenced at a timing desired by the user, and the latest information can be provided.

  FIG. 4 shows the structure of the same server determination table. A column 401 stores a year number for the server 105. Column 405 stores the chassis number. A column 403 stores slot numbers. A column 404 stores types of server information determined as the same server. When registering information in the hardware information table 206, for example, when registering information having the same UUID but a different MAC address, the information in the column 404 is updated by overwriting the already registered information. Used to determine whether to register as a server. An acquisition flag is stored in the column 405. The acquisition flag is a flag indicating whether or not information acquisition is executed when a configuration change alert is received. For example, focusing on the column 451, the server with the slot number 0 stored in the chassis number C0 acquires information at the timing of receiving the configuration change, and the latest information is stored in the server configuration information table 205 and the hardware information table 206. Will be stored. In the case of the column 456, information is not collected at the timing of receiving the configuration change alert, and the information is not updated until the user pulls the trigger. When configuration change alerts are raised one after another for the same server, it is better to collect information at the timing of final configuration change because there is a risk that the configuration change will be delayed due to information collection. Such a setting can be realized by setting an acquisition flag.

  FIG. 5 shows the structure of the information collection flag update table 208. A column 501 stores serial numbers for alerts. A column 502 stores alert numbers. A column 503 stores update conditions. Specifically, the server module is inserted into the column 551, the server module is removed from the column 552, the hardware configuration information is changed to the column 553, the I / O module configuration is changed, the SMP (Symmetric Multi-Processor) configuration is changed to the column 554, and the column 555 is changed. An alert that may have changed the server configuration such as UUID change in column 556, MAC address change in column 556, and WWN change in column 557 is registered, and information acquisition is executed based on this. As a specific procedure, the information collection flag in the column 611 of the server configuration information table 205 in FIG. 6 to be described later is changed to “unacquired”.

  FIG. 6 shows the structure of the server configuration information table 206. A column 601 stores server serial numbers. Columns 602 to 604 store hardware information acquired from the hardware configuration information table 206. Column 602 is UUDI, column 603 is MAC address, and column 604 is WWN. Columns 605 to 610 store information defined by the user. Column 605 is a chassis number, column 606 is a slot number, column 607 is a hosted group name, column 608 is an LU assignment, column 609 is a VLAN ID, and column 610 is an IP address. Columns 611 to 613 store flags and values related to the operation of the information collection OS. A column 611 is an information flag. “Unacquired” stored in the column 654 is an initial value, and is changed to “unacquired” when information collection such as reception of an alert occurs. The unacquired column 651 is the latter. “Acquiring” stored in the column 652 indicates that the information collecting OS is acquiring information. When this flag is set, information is not acquired multiple times for the same server. “Acquired” stored in the column 653 indicates that the FCA 108 of the server and the target LU 144 are associated with each other after the information acquisition is performed, that is, the WWN and the LU are associated with each other. When this server is activated, the information collection OS is not booted, and the OS stored in the target LU 144 is booted. Even when information collection is responded to, it is possible to identify which server information is based on the IP address.

  FIG. 7 shows the structure of the hardware information table 206. Server information collected by the information collection OS is stored in this table. A column 701 stores server serial numbers. Column 702 stores UUIDs. A column 703 stores information related to the CPU of the server. The column 704 in the column 703 stores the CPU architecture name, the column 705 stores the number of CPUs installed in the server, and the column 706 stores information on the NIC. Among the columns 706, a column 707 is the number of NICs, and a column 708 is a MAC address. A column 709 stores information regarding FCA. Column 710 in column 709 is the number of FCAs, and 711 is WWN. Column 712 stores the memory capacity. A column 713 stores the type of chipset. Since the information stored in the hardware information table 206 is server information acquired by the OS, the information is not limited to the information shown in the columns 702 to 713.

  FIG. 8 is a processing flow of the alert receiving mechanism 209. In step 801, an alert is received. In step 802, the information collection flag update table 208 is referred to. In step 803, it is confirmed whether the received alert matches the alert number stored in the column 502. If there is no matching alert, the process is completed. If there is a matching alert, the process proceeds to step 804. In step 804, the server mobility information table 205 is referred to, and information regarding the WWN in column 604 and the LU allocation in column 608 is acquired. In step 805, a request for releasing the association between the WWN and LU of the server is issued to the disk array management mechanism 141. In response to this request, the disk array management mechanism 141 executes step 821. In step 821, the association between the WWN and the LU is released. In step 806, the acquisition flag in the column 405 of the acquisition flag update table 208 is referred to. If the flag is “Yes” in step 808, the process proceeds to step 809. If “No”, the process is completed. In step 809, an information acquisition request is issued to the management mechanism 121, and the process is completed.

  FIG. 9 shows a processing flow when the management mechanism 121 receives an information collection request. When the management mechanism 121 on the management server accepts the information collection request, the process proceeds to step 901. In step 901, the management mechanism 121 issues a queue storage request to the queue management mechanism 203. Details thereof will be described later with reference to FIG. In step 902, the management mechanism 121 calls the information processing acquisition mechanism 202. The information acquisition mechanism 202 executes the information collection process shown in FIG. 10, and associates the server 105 with the LU 144 based on the information that runs in the information collection of the server 105 and the association of the WWN and LUN shown in the server configuration information table 205. .

  FIG. 10 illustrates a flow of server information collection and WWN / LU association processing according to the first embodiment. FIG. 10 shows the operation of the information acquisition mechanism 202, the operation of the target server 1041 as a target of information collection, and the operation of the disk array management mechanism 141 in association with each other. The information acquisition mechanism 202 issues a next entry retrieval request to the queue management mechanism 203 in step 1001. Details regarding the extraction of the next entry will be described later with reference to FIG. In step 1002, the information acquisition mechanism 202 refers to the information collection flag in the column 611 of the server configuration information table 205. If it is determined in step 1003 that the information collection flag is “not acquired”, the process proceeds to step 1006, and if not, the process proceeds to step 1004. In step 1004, the information acquisition mechanism 202 issues a request to the SVP 102 to turn on the server using the BMC 106, and the process proceeds to step 1011. In response to this request, the target server 1041 turns the power on via the BMC in step 1042. On the other hand, in step 1006, the information acquisition mechanism 202 confirms the power state of the server. This confirmation is also executed by issuing a request to the SVP 102. In step 1043, the target server 1041 confirms the power supply On / Off via the BMC. If the server power is off, the process proceeds to step 1008. If the server power is on, the process proceeds to step 1012. In step 1008, the information acquisition mechanism 202 issues a request to turn on the power supply to the SVP 102 as in step 1004. In step 1009, the information collection flag in the column 611 of the server configuration information table 205 is changed to “acquiring”. Then, it waits for the notification of the step 1048 from the target server 1041. The target server 1041 is turned on via the BMC in step 1044. In step 1045, the target server 1041 boots the information collection OS from the LU holding the information collection OS. In step 1046, an IP address determination process, which will be described in detail later with reference to FIG. 15, is executed to determine an IP address. In step 1047, the determined IP address is set and the network service is restarted. In step 1048, the determined IO address is notified to the management server 120. The IP address of the management server 120 necessary for this notification is hard-coded in the information collection OS.

  When step 1048 is completed, the information acquisition mechanism 202 proceeds to step 1010. In step 1010, the IP address used by the information collection Yuo OS is entered in the column 613 of the server configuration information table 205 as the information acquisition IP address. This makes it possible to determine which server is sending server information. In step 1011, the information acquisition mechanism 202 issues a remaining entry confirmation request to the queue management mechanism 203. Details of the remaining entry confirmation will be described later with reference to FIG. If it is determined in step 1012 that there is a remaining entry, the process returns to step 1001 to repeat the sequence of booting the information collecting OS and acquiring the IP address, and then proceed to step 1013. If there are no remaining entries, the process proceeds to step 1013.

  In step 13, the information acquisition mechanism 202 sends a server information acquisition request to the information collection OS. When the target server 1041 receives a server information acquisition request in step 1049, the process proceeds to step 1050 to acquire server information. In step 1051, the server information is transmitted to the management server 120. At this time, the processing of step 1050 and step 1051 may be performed separately for each server information item to be acquired. Server information is more reliably transmitted by the division.

  When receiving the server information sent from the server, the information acquisition mechanism 202 enters the server information in the hardware information table 206 in step 1014. In step 1015, necessary information is picked up from the hardware information table 206, and the server configuration information table 205 is updated accordingly. In this embodiment, columns 602 to 604 are to be updated. In step 1016, the information collection flag in the column 611 is changed to “acquired”. In step 1017, the information acquisition mechanism 202 issues a request to the disk array management mechanism 141 to associate the acquired WWN with the LU assignment (column 608) of the server configuration information table 205. Upon receiving this request, the disk array management mechanism 141 associates the WWN with the LU in step 1062. As a result, the server 105 that is next powered on boots from the boot disk of the LU 144, and does not boot the information collection OS. Next, in step 1018, the information acquisition mechanism 202 releases the IP address used by the information collection OS and requests to shut down the information collection OS. The server that has received the request executes the IP address release process in Step 1052 and shuts down the information acquisition OS. Details of the IP address release process will be described later with reference to FIG. The server power is turned off by the shutdown. Depending on the hardware, there is a configuration in which the power is not turned off even when the OS is shut down. In this case, the problem can be solved by adding a step of turning off the power supply to the SVP 102 via the BMC. Next, in step 1019, the information acquisition mechanism 202 releases the IP address from the column 613 of the server configuration information table 205.

  With the above flow, server information can be collected from a server on which no OS is installed. Further, even when the configuration of a server that is already executing a job is changed, server information can be collected without changing the VLAN setting. Further, after collecting the information, it automatically returns to the LU allocation defined in the server configuration information table 205. That is, it is set to boot from a predetermined target LU.

  The queue management mechanism 203 provides functions for storing in the queue 204, retrieving the next entry, and confirming the remaining entries. Until the information collecting OS determines the IP address and notifies the management server 120, it is assumed that the server whose power is turned on always starts the information collecting OS and notifies the IP address. Must be single. For this reason, the queue management mechanism 203 needs to provide a function to be achieved in each flow of FIG. 11, FIG. 12, and FIG.

  First, FIG. 11 shows a flow for storing entries in the queue 204. In step 1201, the queue management mechanism 203 locks the queue 204. In step 1202, the entry is stored in the queue 204. In step 1203, the queue 204 is unlocked. In step 1204, it is determined whether or not the entry is the first entry in the queue 204. If it is the first entry, the process proceeds to step 1205. If it is not the first entry, the process is terminated. In step 1205, the queue management mechanism 203 calls the information acquisition mechanism 202 and ends the process. When the entry is stored in the queue 204 in step 1202, the immediate execution of the information is not expected in the case of the entry serving as a priority trigger. However, in the case of an entry due to a user executing a command or pressing a button, the result is often requested immediately. Therefore, it is desirable to store such entries at the top when storing.

  FIG. 12 shows a flow for retrieving the next entry from the queue 204. The queue management mechanism 203 refers to the queue in step 1221. In step 1222, it is determined whether or not there are remaining entries. If there is a remaining entry, the process proceeds to step 1223, and if not, the process ends. In step 1223, the queue is locked, and in step 1224, the contents of the next entry are returned. In this embodiment, the contents of the entry to be returned are a chassis number and a slot number, and user-defined server information indicating position information. Such information may be acquired from the SVP 102. In the case of a 1U server, information specified by a rack name or the number of stages may be used. In step 1225, the queue management mechanism 203 deletes the returned entry from the queue 204. In step 1226, the queue 204 is unlocked and the process is completed.

  FIG. 13 shows a flow for confirming the remaining entries in the queue 204. The queue management mechanism 203 refers to the queue 204 in step 1241. In step 1242, the presence / absence of a remaining entry is returned and the process is completed.

  FIG. 14 to FIG. 16 are diagrams for explaining the functions of the information collection OS with respect to the IP address used by the information collection OS. There are various implementation methods for determining the IP address locally. In this embodiment, the IP address is managed by accessing the IP address pool LU 143. FIG. 14 shows the data format of data stored in the IP address pool LU 143. The use flag 1484 and the IP address 1485 can be associated with each other. The use flag 1484 indicates whether the corresponding IP address is “in use” or “unused”.

  FIG. 15 shows the flow of the IP address determination process. In step 1401, the information collection OS issues a reserve command, which is a SCSI command, to the IP address pool LU 143. In step 1402, the IP address pool LU 143 is referenced. In step 1403, it is determined whether or not the use flag 1484 is “unused”. If “unused”, the process proceeds to step 1404. When the use flag 1484 is “in use”, the process returns to 1402 to refer to the next use flag. In step 1404, it is determined to use an IP address whose use flag is “unused”, and the use flag is changed to “in use”. In step 1405, a release command is issued to release the IP address pool LU 143. This IP address management is performed only through the IP address pool LU 143. Steps 1422 to 1425 show steps in which the IP address pool LU 143 executes the request of each of the above steps of the information collection OS.

  FIG. 16 shows the flow of the IP address release process. In step 1441, the information collection OS issues a reserve command. In 1442, the IP address pool LU 143 is referred to. In step 1443, the use flag of the IP address being used is changed to “unused”, and a release command is issued in step 1444. Here again, steps 1462 to 1465 show the steps in which the IP address pool LU 143 executes the request of each step of the information collection OS.

  In the first embodiment described above, an LU storing an information acquisition OS is placed in an unrestricted area in the storage area provided by the disk array device, and the server is set to boot from the FCA once. Start the information acquisition OS. The WWN acquired from the information collection OS is associated with the LU used in the production environment via the management server. After this association, the OS is started from the LU used in the production environment where the previous association is executed by the access restriction function provided by the manager managing the storage.

  In the first embodiment described above, when an information collection request is held in the management server, it is necessary to avoid turning on the server manually. On the other hand, the second embodiment is configured to avoid such an erroneous operation.

  The system configuration of the second embodiment is the same as that of the first embodiment in the range of FIG. 1 and FIG. The server information collection and WWN / LU association processing flow shown in FIG. 10 is changed in the second embodiment. More specifically, a change is applied to FIG. 10 to lock the SVC so that the power of other servers is not turned on between step 1001 and step 1010. FIG. 17 shows a flow of information information collection and WWN-LU association processing in the second embodiment.

  In step 1101 of FIG. 17, the information acquisition mechanism 202 issues a next entry retrieval request to the queue management mechanism 203 (see FIG. 12). In step 1102, the SVP 102 is requested to invalidate the power control related to all servers 105. That is, a power control lock request is issued to the SVP 102. In step 1103, the information collection flag in the column 611 of the server configuration information table 205 is referred to. In step 1131, it is determined whether or not the information collection flag is “not acquired”. If “not acquired”, the process proceeds to step 1105. Otherwise, go to Step 1132. In step 1132, the information acquisition mechanism 202 issues a request to the SVP 102 to turn on the power of the target server for which information is to be acquired using the BCM 106, and the process proceeds to step 1110. In response to this request, the target server 1141 is turned on via the BCM (step 1155). In step 1105, the information acquisition mechanism 202 issues a request to confirm the power On / Off of the target server. If it is determined in step 1106 that the power of the target server is Off, the process proceeds to step 1107, and if it is On, the process proceeds to step 1111. In step 1107, the target server is powered on in the same manner as in step 1132. However, since all the power control locks are applied to the server 105 in the above step 1102, the invalidation of the power control for the target server 1141 is canceled in the step 1107, and then the power is turned on. In step 1108, the information week number flag in the column 611 of the server configuration information table 205 is changed to “acquiring”, and the process waits until the target server 1141 receives the notification in step 1147. The target server 1141 is powered on in step 1143 and then boots the information collection OS from the LU holding the information collection OS in step 1144. In step 1045, an IP address is determined. In step 1146, the determined IP address is set and the network service is restarted. In step 1147, the determined IP address is notified to the management server 120. Upon receiving this notification, the information acquisition mechanism 202 enters the IP address determined in step 1109 in the column 613 of the server configuration information table 205 as the IP address used by the information collection OS (step 1109).

  Step 1109 is exactly the same as step 1010 in the flow of the first embodiment shown in FIG. Further, it is exactly the same as the flow of FIG. 10 that the entries of the queue 204 are sequentially taken out and the above-described flow is repeated, and the information acquisition IP address is sequentially assigned to each server from which information is to be collected. However, in the flow of the second embodiment, if it is determined in step 1111 that there are no entries in the queue 204, the process proceeds to step 1133, and the SVP 102 is canceled so as to release the power control invalidation (power control lock) performed in step 1102. Request.

  Since the information collection OS is booted, information is collected for each server for which the IP address to be used is determined, and the association between the WWN and the LU is performed after step 1112 is exactly the same as the operation after step 1013 in FIG. A duplicate description is omitted.

  When the server 105 is turned on manually, the management server does not become the starting point. Also in this case, the third embodiment realizes associating the manually started server WWN with the target LU.

  FIG. 18 illustrates a flow of server information collection and WWN / LU association processing according to the third embodiment. Also in the third embodiment, the system configuration is the same as that of the first embodiment.

  Step 1302 shows the operation of the power source On of the target server 1341 by the operator 1301 on the operation panel. With this as a trigger, the target server 1341 turns on the power in Step 1342. Next, in step 1343, the target server 1341 boots the information collection OS from the LUi 142 including the information collection OS. In step 1344, the server 1341 performs an IP address determination process to determine an IP address. Next, in step 1345, an IP address is set, and in step 1346, the management server 120 is notified of the IP address. The information acquisition mechanism 202 of the management server 120 enters the IP address notified in step 1312 in the column 613 of the server configuration information table 205 as an information collection IP address. In step 1313, the information collection flag in the column 611 is changed to “acquiring”. In step 1314, a server information acquisition request is issued to the target server 1341. When the target server 1341 injures the information acquisition request in step 1347, it acquires server information in step 1347. In step 1349, the server information is acquired and transmitted to the management server 120. The information acquisition mechanism 202 of the management server 120 adds or updates the server information received in step 1315 to the hardware information table 206. In step 1316, the same server determination table 207 is referred to. In step 1317, the presence / absence of the same server is determined based on whether there are duplicate determination server information items specified in the column 404 (FIG. 4) of the same server determination table 207. Then, the process proceeds to step 1319. In step 1318, the duplication target column is updated. This is to prevent a plurality of identical servers from being registered by the server information item specified in the column 404. In step 1319, necessary information is picked up from the hardware information table 206, and the server configuration information table 205 is updated. Since the flow after step 1319 is exactly the same as the flow after step 1014 (FIG. 10) of the first embodiment, a duplicate description is omitted.

  Also in the third embodiment having the above processing flow, as in the first embodiment, the management server associates the WWN obtained by booting the information collection OS on the server and the LU used in the production environment, and the WWN In the boot after the association of the LU, it is possible to boot from the LU used in the production environment and provide the business stored in the LU.

  FIG. 19 shows an information acquisition IP address determination process using the IP network employed in the fourth embodiment of the present invention.

  When the IP address determination process is executed, first, in step 1501, an IP address is randomly determined. At this time, it is desirable that the range selected at random is limited to a local address or the like.

  In step 1502, a request is issued by unicasting the arp command. At this time, similarly to a normal arp request, 00: 00: 00: 00: 00 and FF: FF: FF: FF: FF: FF are stored in the destination MAC address. The destination MAC address stores the IP address of the management server. L Here, it is assumed that the information collection OS knows the IP address of the management server in advance. As an implementation method, the information acquisition OS is provided with hard coding. The source MAC address stores the MAC address of the server 105 on which the information acquisition OS is running. The source IP address stores a random and broken IP address. In step 1522, the management server 120 receives the arp request. In step 1523, the information acquisition IP address in the column 613 is referred to the server configuration information table 205. In step 1526, the source MAC address is copied and stored in the destination MAC address as an arp reply. In step 1527, an arp command is issued by unicast as a reply. In step 1502, an arp reply is received. In step 1504, it is determined whether or not the destination MAC address matches the own MAC address. If there is a match, in step 1524 there is no IP address that matches the information collection IP address, so that IP address can be used, and the process is completed. If they do not match, it means that the MAC address of the management server has been transmitted, and in step 1524, there is an IP address that matches the information collection IP address. Therefore, the processing returns to step 1501 and continues. .

By adopting the above method, there is no need for the IP address pool LU 143, and there is an advantage that the management server can centrally manage information. Therefore, there is no need to have an IP address release process in the information acquisition OS, and only the information acquisition IP address in the column 613 of the server configuration information table 205 on the management server 120 is deleted when the information acquisition OS is shut down. It's okay.
(Other variations)
In the embodiment, a system having an FCA-connected disk array device is shown, but the effect is not reduced even if the present invention is applied to an IP storage or other storage device.

  Further, by copying the LU 145 belonging to the deployment image group 148 to the LU 144 of the embodiment by using the disk copy function, it is possible to distribute the OS after collecting the information. This eliminates the need for the user to perform OS distribution after collecting server information such as the MAC address and UUDI from the server before OS distribution.

  Instead of the information acquisition OS, when a standby server that is cold-standby is periodically started to check whether there is a failure, or when a failure diagnosis OS is stored after a failure occurs, etc. The concept of the present invention is applicable

It is a block diagram which shows the whole Example 1 of this invention. FIG. 3 is a functional block diagram illustrating a configuration of a management mechanism according to the first embodiment. 3 is a data structure diagram of a queue according to Embodiment 1. FIG. 3 is a data structure diagram of the same server determination table of Embodiment 1. FIG. 6 is a data structure diagram of an information collection flag update table according to Embodiment 1. FIG. It is a data structure figure of the server structure information table of Example 1. 3 is a data structure diagram of a hardware configuration information table according to Embodiment 1. FIG. 3 is a flowchart illustrating processing of an alert receiving mechanism according to the first embodiment. 3 is a flowchart illustrating processing of a management mechanism according to the first exemplary embodiment. 3 is a flowchart illustrating processing of an information acquisition mechanism according to the first embodiment. 6 is a flowchart illustrating a process of storing in a queue by the queue management mechanism according to the first embodiment. 10 is a flowchart illustrating a next entry extraction process of the queue management mechanism according to the first exemplary embodiment. 6 is a flowchart illustrating a process of confirming a remaining entry of the queue management mechanism according to the first embodiment. 3 is a data configuration diagram of an IP address pool LU in Embodiment 1. FIG. It is a flowchart which shows the IP address determination process of Example 1. 3 is a flowchart illustrating an IP address release process according to the first embodiment. It is a flowchart which shows the process of the information acquisition mechanism of Example 2 of this invention. It is a flowchart which shows the process of the information acquisition mechanism of Example 3 of this invention. It is a flowchart which shows the IP address determination flow of Example 4 of an Example.

Explanation of symbols

101 Chassis 102 SVP
103 internal network switch 105 server 106 BMC
107 NIC
108 FCA
109 VLAN
110 Network switch management mechanism 120 Management server 121 Management mechanism 130 Switch 140 Disk array device 141 Disk array device management mechanism 142 LU storing information collection OS
143 LU for IP address pool
144 LU
145 Original LU for deployment
146 Area not restricted by disk array management mechanism 147 Area restricted by disk array management mechanism 148 LU area storing deployment image.

Claims (7)

  In a modular server system in which a large number of server devices are connected to a storage device, an operating system for collecting information stored in a logical volume that can be referred to from any server device is started to acquire unique information of the server device, A server information collecting method characterized by performing allocation relating to a volume.   The server apparatus further includes a step of recording the server apparatus specific information acquired by starting the information collecting operating system in correspondence with the logical information in a table in which logical information related to the server apparatus defined by the user is stored in advance. 2. The server information collecting method according to claim 1, wherein the allocation relating to the logical volume is performed based on the table.   The table has a column for storing the necessity of acquiring the specific information corresponding to the server device. When the information acquisition is required, information acquisition and allocation to the logical volume are performed when information acquisition is required. The server information collection method according to claim 2.   4. The server information collection according to claim 3, further comprising a table relating to a configuration change notification that can be acquired from the server device, and rewriting a column of necessity of acquiring the specific information in response to the notification stored in the table. Method.   2. The server according to claim 1, wherein the acquisition of the unique information of the server device includes a procedure of giving the server device an information collection IP address for communicating with the information collection operating system activated on the server device. Information acquisition method.   6. The server information collecting method according to claim 5, wherein power-on control of another server device group is locked until the server device in the process of collecting information completes acquisition of the IP address for collecting information.   5. A table having unique information that is regarded as the same server device, and when it is determined as server information of a certain server device as a result of collecting information, previous information is updated with the acquired information. Server information collection method.

Images