JP2012238095A - Software image distribution method, software image distribution system and program thereof - Google Patents

Abstract

Even when a large number of servers are incorporated into a cluster, they can be incorporated quickly.
A remote boot device instructs an image repository device 200 to divide a software image to be distributed. Also, starting from the image repository apparatus 200, a chain indicating in what server order the divided pieces (chunks) of the divided software image are transferred is generated. The image repository apparatus 200 and the activation target server that have received this chain refer to the chain and sequentially transfer chunks between the activation target servers like the bucket relay with the image repository apparatus 200 as the starting point. Here, the transfer order shown in the chain is set so that the number of transit switches between the servers to be activated is minimized in consideration of the network topology.
[Selection] Figure 2

Description

  The present invention relates to a software image distribution technique to each server of a cluster system.

  In recent years, in the field of Web server hosting and the like, a form called IaaS (Infrastructure as a Service) etc. in which server management providers such as data centers collectively manage servers and host service providers has become common. (See Non-Patent Document 1). Here, it is necessary to prepare a server that includes a certain amount of standby surplus resources in order to respond quickly to requests when service demand increases or when a server providing that service leaves due to a failure. There is. In recent years, network server cluster architectures that can add and delete server resources dynamically without interruption have emerged, and further operational flexibility and cost reduction of facilities that make up communication networks are expected ( Non-patent document 2).

  In response to such a request, the surplus resources of each network server cluster are aggregated as a resource pool, and when the demand increases or when resources lost due to failures or disasters are replenished, the necessary servers from the resource pool are added to each cluster. In addition to this, a technique for improving the overall facility utilization efficiency is being studied.

  When a server is added to a cluster from a shared resource pool in which surplus resources are aggregated in this way, it is not known in advance what software configuration the server held in the resource pool will take. For this reason, the server of the resource pool is generally in a state that has no software. Therefore, when adding a resource, a software image including a software configuration corresponding to each service is transferred from the repository to a server to be added. Then, after making the necessary settings for this server, it is necessary to incorporate it into the cluster.

Amazon Elastic Compute Cloud (Amazon EC2), [online], [Search March 23, 2011], Internet, <URL: http: //aws.amazon.com/ec2/> Mobicents, [online], [Search March 23, 2011], Internet, <URL: http://www.mobicents.org/> Nishimura Gosei et al., High-speed Remote Boot Device for Flexible Resource Management of Highly Available Network Servers, IEICE Technical Report, NS2010-148, pp.37-42, Jan, 2011.

  Since the software image includes all of the operating system, various middleware, data, and the like, the software image has a large capacity ranging from several to several tens of GB and requires a certain amount of time for transfer. Here, in order to prevent a sudden increase in demand for a cluster or a reduction in service availability even when a server failure is recovered, it is necessary to distribute and start software at high speed even when a plurality of servers are requested at the same time.

  The technology described in Non-Patent Document 3 distributes software images using a communication library that maps a server to a tree structure for distribution. However, this method has a problem that when the number of servers to be added to the cluster increases, the distribution time of the software image increases accordingly. A general communication library abstracts all servers as logical nodes that can communicate with each other, and does not always perform optimal communication in consideration of an actual network topology. For this reason, the network bandwidth cannot be efficiently used when distributing the software image, and it may take more time than necessary to transfer the software image.

  In view of the above, an object of the present invention is to solve the above-described problems and provide means for quickly incorporating even a large number of servers into a cluster.

  In order to solve the above-described problem, the present invention provides a remote power-on instruction for a server to be added to a cluster and operates the server in a network in which a server and switches that connect the servers are connected in a tree structure. The remote boot device that distributes the software image to the image repository device performs the following processing. That is, the remote boot device accepts an input of an addition instruction including the number of servers to be added to the cluster and the type of software image to be distributed to the servers to be added. Then, the remote boot device transmits the input software image type to the image repository device. Next, the remote boot device reads the server information indicating whether each server ID and the server can be added to the cluster based on the input addition instruction, and among the servers indicated in the read server information, Select the server that can be added as the server to be added to the cluster and the number of servers indicated in the add instruction. Then, a remote power-on instruction to each of the selected addition target servers is transmitted via the management network. After that, the remote boot device refers to the topology information that shows the connection relationship between the image repository device, the server, and the switch that connects the server, and adds the pieces when the software image segment is transferred between the addition target servers. Transfer instruction information including the order of the target servers is generated. Then, the generated transfer instruction information is transmitted to the image repository apparatus. Upon receiving this transfer instruction information, the image repository apparatus divides the transmitted type of software image, and divides the divided software image fragment and transfer instruction information into the first activation target in the transfer order included in the transfer instruction information. Send to server. Thereafter, each of the addition target servers that has received the transfer instruction information and the software image fragment transfers the received software image fragment to the addition target server to which the fragment is to be transferred next to its own server in the transfer instruction information. The process of storing in the image storage unit of the server is repeated until all pieces constituting the software image are received and transferred. Thereafter, the activation target server activates its own server from the software image stored in the image storage unit. Here, when the remote boot device generates the transfer instruction information, the order of the addition target servers when transferring between the addition target servers is the minimum number of switches that pass between the addition target servers with reference to the topology information. The order is as follows.

  In this way, the remote boot device can divide the software image into fragments, and cause the addition target server to sequentially transfer the fragments in a predetermined transfer order like a bucket relay. This eliminates the need for the image repository device to send the entire software image to each of the servers to be added to the cluster. Therefore, even when many servers are incorporated into a cluster, they can be incorporated quickly. In addition, the software image fragment transfer order between the addition target servers set in the transfer instruction information is set so that the number of switches passing between the addition target servers is as small as possible. As a result, the number of links through which each fragment is transferred can be reduced as much as possible. Therefore, when each fragment is sequentially transferred between the addition target servers, the use efficiency of the network bandwidth can be improved.

  Further, according to the present invention, each server stores a fragment of the received software image and a chunk table indicating whether or not each of the fragments has been received, transmitted, and stored in the image storage unit. It has a main memory. Then, each server refers to the chunk table and transmits the fragment that has been received or stores it in the image storage unit. Thereafter, when the fragment is transmitted or stored in the image storage unit, the fragment or the storage in the image storage unit in the chunk table is rewritten to have been executed. Then, each server refers to the chunk table and deletes the fragments that have been received, transmitted, and stored in the image storage unit from the main memory.

  In this way, the addition target server sequentially repeats transmission and storage of the received software image fragment, but when the transmission of the software image fragment and storage in the image storage unit is completed, this fragment is deleted from the main memory. Therefore, the limited storage capacity of the main memory can be used effectively.

  In addition, according to the present invention, when each server determines that the order of the addition target servers in the transfer instruction information is the last when the servers are transferred between the addition target servers, Notifying the image repository device of the obtained fragment.

  In this way, the image repository apparatus can confirm to which fragment of the software image (distribution status) the addition target server having the last transfer order among the addition target servers has received.

  In addition, the present invention provides an instruction for remotely turning on a server to be added to a cluster and operating the server in the image repository apparatus in a network in which a server and a switch for connecting the servers are connected in a tree structure. The software image distribution program for instructing the distribution of the software image is a program that executes each step. In other words, the step of accepting an input of an addition instruction including the number of servers to be added to the cluster and the type of software image to be distributed to the server to be added to the computer, and the input type of software image is transmitted to the image repository apparatus And server information indicating whether each server and the server can be added to the cluster are read based on the input step and the input addition instruction, and the server that can be added among the servers indicated in the read server information Selecting the number of servers indicated in the addition instruction as an addition target server to the cluster, and transmitting a remote power-on instruction to each of the selected addition target servers via the management network, an image repository device, the server, and the server The switch connection relationship Generating the transfer instruction information including the order of the server to be added when transferring the fragment obtained by dividing the software image between the servers to be added with reference to the topology information, and the image repository apparatus And a program for executing the step of transmitting to the program. Here, the transfer instruction information is obtained by dividing the type of software image transmitted to the image repository apparatus, and dividing the divided software image fragment and the transfer instruction information into the first transfer order included in the transfer instruction information. For each additional target server that sent to the startup target server and received the transfer instruction information and the software image fragment, the received software image fragment is the additional target to be transferred next to its own server in the transfer instruction information. This is information that directs the transfer to the server. The order of the addition target servers when transferring between the addition target servers is such that the number of switches that pass between the addition target servers is minimized by referring to the topology information. It is in order.

  According to such a program, a general computer can function as the remote boot device of the present invention.

  According to the present invention, even when many servers are incorporated into a cluster, they can be incorporated quickly.

It is the figure which showed the example of a structure of the system of this Embodiment. FIG. 2 is a diagram conceptually illustrating chunk transfer processing in the system of FIG. 1. FIG. 2 is a diagram conceptually illustrating chunk transfer processing in the system of FIG. 1. It is the figure which showed the structure of the remote boot apparatus of FIG. 1, an image repository apparatus, and a server. It is the figure which illustrated the server information of FIG. It is the figure which illustrated the network topology containing the server of FIG. It is the figure which illustrated the topology information of FIG. It is the figure which illustrated the image information of FIG. It is the figure which illustrated the chunk table of FIG. It is a figure for demonstrating the operation | movement procedure of the remote boot apparatus of FIG. It is a figure which shows the production | generation procedure of the chain by the remote boot apparatus of FIG. It is the figure which illustrated the transition of the process table and chain used when the remote boot apparatus of FIG. 1 produces | generates a chain. It is a figure for demonstrating the operation | movement procedure of the image repository apparatus of FIG. It is a figure for demonstrating the operation | movement procedure of the server of FIG. It is a figure for demonstrating the operation | movement procedure of the server of FIG. It is the figure which illustrated the chunk table of FIG.

  Hereinafter, modes (embodiments) for carrying out the present invention will be described. First, the overall configuration of the system according to the present embodiment will be described with reference to FIG. The system according to the present embodiment includes a plurality of servers 300 that are resources for providing services, a remote boot device 100 that remotely starts the server 300, and an image repository device 200 that is a distribution source of software images. The remote boot device 100, the image repository device 200, and the server 300 are connected via a management network 400. The remote activation instruction and the distribution of the software image are performed via the management network 400. Also, the terminal 600 accesses each server 300 via the service network 500 and receives a service provided by each server 300.

  When the remote boot device 100 receives a remote boot (remote start) request for the server 300 from the terminal device (not shown) of the maintenance person, the remote boot device 100 remotely starts the necessary number of servers 300. Then, the remote boot device 100 instructs the image repository device 200 to distribute the software image to the activated server 300.

  Here, as illustrated in FIG. 2, the image repository apparatus 200 logically arranges the activation target servers in a line (chain shape) with the image repository apparatus 200 at the top. Then, the software image is distributed to the startup target servers (servers to be added to the cluster, which is a group of servers 300 that provide services). At that time, the software image is divided into several pieces (chunks) and distributed to each server 300 along the chain (chunk transfer order) in units of chunks. And this starting object server performs reception, transmission, and preservation | save of a chunk by a bucket relay type. That is, when each server 300 receives a chunk, it sequentially transfers this chunk to the next server 300 in the chain. Further, the server 300 saves the software image by saving the received chunk in its own local disk.

  Here, the chain is configured in consideration of the network topology. For example, each server 300 (300A, 300B, 300C, 300D) and the image repository apparatus 200 are connected via a switch 700 (700A, 700B, 700C) as illustrated in FIGS. In such a network topology, when each chunk is sequentially distributed in the order of (0) → (1) → (2) → (3) → (4) in FIG. In addition, there is a possibility that many communications occur, and a plurality of communications may be simultaneously performed on one link. For this reason, there is a possibility that the utilization efficiency of the communication band of the network is deteriorated.

  On the other hand, in this system, the order of (0) → (1) → (2) → (3) → (4) in FIG. Each chunk is delivered sequentially in a limited delivery order. By doing so, the possibility that a plurality of communications are simultaneously performed on one link can be reduced.

  The remote boot device 100 described above includes a communication interface, an input / output interface, a CPU (Central Processing Unit), a RAM (Random Access Memory), and a ROM (Read Only) that can communicate via the management network 400 and the service network 500. This is realized by a computer including a storage unit such as a memory (HDD), a hard disk drive (HDD), and a flash memory.

<Remote boot device>
Next, the remote boot device 100, the image repository device 200, and the server 300 in FIG. 1 will be described in detail with reference to FIG. First, the remote boot device 100 will be described.

  The remote boot device 100 includes a boot request reception unit 110, a remote power management unit 120, a server information management unit 130, a chain generation unit 140, a topology information management unit 150, and a chain transmission unit 160. Further, the remote boot device 100 stores server information 131 and topology information 151 in a predetermined area of a storage unit (not shown). The boot request reception unit 110, the remote power management unit 120, the server information management unit 130, the chain generation unit 140, the topology information management unit 150, and the chain transmission unit 160 are programs executed by the CPU provided in the remote boot device 100. This is realized by an execution process, a dedicated circuit, or the like. When the remote boot device 100 is realized by a program execution process, a program for realizing the functions of the remote boot device 100 is stored in the storage unit.

  The boot request accepting unit 110 accepts a remote boot request including the added number of servers to be activated and the type of software image to be distributed to the addition target server from the terminal device or the like of the maintenance person, and starts a series of remote boot processes. The remote boot request may be received from an external terminal such as a maintenance person's terminal device via a network, or may be received via an input device directly connected to the remote boot device 100.

  The remote power management unit 120 selects the server 300 to be activated and turns on the server 300 remotely. The remote power ON is performed using, for example, IPMI (Intelligent Platform Management Interface) or WoL (Wake on LAN).

  The server information management unit 130 reads and writes the server information 131. As illustrated in FIG. 5, the server information 131 is information indicating the remote operation address of the server 300, the transfer address, and the state of the server 300 for each server ID that is identification information of the server 300. The remote operation address is an endpoint address that is required when the remote power management unit 120 powers on the server 300. In the example of FIG. 5, it is assumed that the server 300 uses IPMI for remote power ON, and an IP (Internet Protocol) address is stored as a value. The transfer address is a network address used when transferring the software image to the server 300. The status of the server 300 stores information indicating whether the server 300 can be used as a resource (whether it can be added to the cluster). In the example of FIG. 5, the state of the server 300 is “available”, “in use”, or “unusable”. “Available” is a server 300 that can be used as a resource (standby), “in use” is a server 300 that currently provides some service and cannot be added to the cluster, and “unavailable” This indicates that the server 300 cannot be used due to a failure or the like.

  Returning to FIG. The chain generation unit 140 generates a chain (transfer instruction information). A chain is information indicating the order in which pieces of software images are transferred between the image repository apparatus 200 and each activation target server. Although details of the chain generation procedure will be described later, the chain generation unit 140 sequentially selects the activation target server having the smallest number of transit switches from the image repository device 200 to the termination activation target server. Generate a chain. As a result, the number of switches through which the chunks are transferred between the servers to be activated can be reduced as much as possible.

  The chain transmission unit 160 transfers the chain created by the chain generation unit 140 to the image repository apparatus 200 and instructs the start of chunk distribution. Details of the chain generation unit 140 and the chain transmission unit 160 will be described later.

  The topology information management unit 150 reads and writes the topology information 151. The topology information 151 is information indicating the connection relationship (topology) of the network server 300, the image repository apparatus 200, and the switch 700 that connects them. The network topology here assumes a general tree configuration. FIG. 7 illustrates the topology information 151. This topology information 151 is topology information 151 indicating the network topology of FIG. 6 and 7, “SW *” indicates the switch ID of the switch 700, and “Svr *” indicates the server ID of the server 300. As illustrated in FIG. 7, the topology information 151 stores, for each switch ID, which is identification information of the switch 700, IDs of parent switches, child switches, and accommodating servers on the tree structure as values. The value of the parent switch is stored as a switch ID, and the maximum number of values is one. In addition, a parent switch does not exist in the switch 700 that is a root in the tree structure like SW0 in FIG. On the other hand, there can be a plurality of child switches. 6 and 7, SW0 has SW1, SW2, and SW3 as child switches. SW1, SW4 to SW6 do not have child switches, and therefore have no value. Since the server ID of the server 300 accommodated in the switch 700 is a value, there can be a plurality of accommodating servers. In addition, since relay switches such as SW0, SW2, and SW3 that connect the switches 700 do not accommodate the server 300, there is no value for the accommodation server.

<Image repository>
Returning to FIG. The image repository apparatus 200 includes a distribution request reception unit 210, an image information management unit 220, and an image distribution unit 240. Further, the storage 230 and the image information 221 are stored in a predetermined area of a storage unit (not shown) of the image repository apparatus 200. The distribution request reception unit 210, the image information management unit 220, and the image distribution unit 240 are realized by a program execution process by a CPU included in the image repository apparatus 200, a dedicated circuit, or the like. When the image repository apparatus 200 is realized by program execution processing, a program for realizing the functions of the image repository apparatus 200 is stored in the storage unit.

  The distribution request reception unit 210 receives image ID and chain transmission from the remote boot device 100 via the management network 400, and starts distribution processing of software image fragments (chunks).

  The image information management unit 220 reads and writes the image information 221. As illustrated in FIG. 8, the image information 221 is information indicating a path for accessing the software image for each piece of software image identification information (image ID). The image information 221 is referred to when the image distribution unit 240 reads a software image from the storage 230.

  Returning to FIG. The storage 230 stores a software image body.

  The image distribution unit 240 divides the distribution target software image into a plurality of chunks, and distributes them along the chain. The image distribution unit 240 receives a chain from the remote boot device 100 and transfers the chain transfer unit (chain reception unit and chain transmission unit) 241 that transfers the chain to the server 300 at the head of the chain, and the distribution target software image in chunks. A chunk dividing unit 242 for dividing and a chunk transmitting unit 243 for transmitting the chunk to the first server 300 shown in the chain are provided. The image distribution unit 240 may further include a distribution status receiving unit 244 that receives a chunk distribution status from the chain end server 300.

<Server>
The server 300 includes a boot unit 310 and an image transfer unit 320. The server 300 also includes an image storage unit 330 in a predetermined area of a storage unit (not shown) such as an HDD. Further, the chunk table 341 is stored in a predetermined area of a main memory (not shown) such as a RAM of the server 300. The main memory stores chunks and chains received from other servers 300. The received chunk is stored in the main memory and then stored in the image storage unit 330.

  The boot unit 310 includes a remote management accepting unit 311 that accepts remote power ON from the remote boot device 100 through an interface such as IPMI, and a selective boot unit 312 that selects boot target software and starts its own server 300. . The selective boot unit 312 is a boot loader such as GRUB (GRand Unified Bootloader), for example. The selective boot unit 312 boots predetermined software upon receiving a remote power ON by IPMI. When the power is turned on, the boot unit 310 of the waiting server 300 boots software for realizing the function of the image transfer unit 320 by the selective boot unit 312. In addition, when all the chunks constituting the distribution target software image are received, the server 300 causes the selective boot unit 312 to restart the server 300 using the software image.

  The image transfer unit 320 includes a chain transfer unit 321, a chunk reception unit 322, a chunk transfer unit 323, and a chunk storage unit 324. The image transfer unit 320 may further include a transfer information management unit 325.

  When the chain transfer unit 321 receives a chain from the previous server 300 or the image repository apparatus 200, the chain transfer unit 321 refers to this chain and transfers the chain to the next server 300. In addition, the chain transfer unit 321 notifies the chunk transfer unit 323 of the received chain, and generates a chunk table 341. As illustrated in FIG. 9, the chunk table 341 is information indicating, for each chunk ID that is identification information of the chunk, a reception flag, a transmission flag, a storage flag, and actual data that is the content of the chunk. Each flag is a flag for managing whether the chunk has been received, transmitted, and stored in the image storage unit 330 in FIG. 4, and “0” is not yet “1”. Indicates finished.

  Returning to FIG. The chunk receiving unit 322 receives a chunk from another server 300 or the image repository apparatus 200. Further, after receiving the chunk, the reception flag of the corresponding chunk ID in the chunk table 341 (see FIG. 9) is set to “1”.

  The chunk transfer unit 323 refers to the chunk table 341 (see FIG. 9), acquires a chunk whose reception flag is “1”, refers to the chain, and transmits it to the next server 300. Further, when the chunk transmission is completed, the chunk transfer unit 323 sets the transmission flag of the chunk in the chunk table 341 (see FIG. 9) to “1”.

  The chunk storage unit 324 stores the received chunk in the image storage unit 330. When the chunk storage is completed, the storage flag of the chunk in the chunk table 341 (see FIG. 9) is set to “1”. Note that the actual data of the chunk in which both the transmission flag and the storage flag of the chunk table 341 are “1” may be released in order to reduce the memory usage on the main memory. The release may be performed collectively in a predetermined cycle, or when the reception flag of the chunk table 341 becomes “1”, the flag values of other chunks are confirmed, and if all the flag values are “1”. You may release sequentially.

  The transfer information management unit 325 refers to the chain, and when it is the server 300 at the end of the chain, the transfer information management unit 325 indicates the distribution status indicating which chunk has been received and what percentage of the entire software image has been received. Notify device 200.

  The image storage unit 330 stores a chunk of the received software image.

  The image transfer unit 320 realizes high-speed bucket relay distribution by performing reception, transmission, and storage of the chunks in parallel. When the image transfer unit 320 completes reception, transmission, and storage of all the chunks constituting the software image, the image transfer unit 320 changes the setting of the selective boot unit 312 and is activated by the system in the software image of the image storage unit 330. Like that. Thereafter, the system in the software image is started by the selective boot unit 312 by restarting the server 300. As a result, the server 300 can provide a service to the terminal 600 of FIG.

<Operation procedure>
<Remote boot device>
Next, an outline of the operation of the system shown in FIG. 1 will be described with reference to FIG. Here, the operation of the remote boot device 100 will be mainly described.

  The boot request reception unit 110 of the remote boot device 100 receives a boot request (remote boot) including the number of servers 300 to be activated and an image ID that is a type of software image to be distributed to the server 300 from a maintenance person's terminal device or the like. (Request) is received (S11).

  When receiving the boot request, the boot request receiving unit 110 notifies the image repository apparatus 200 of the image ID (S12), and checks whether the software image exists in the image repository apparatus 200. If it can be confirmed that the software image exists, the boot request reception unit 110 acquires the server information 131 (see FIG. 5) via the server information management unit 130 (S13), and designates the specified number of servers 300. It selects as a starting object server (S14: Target server selection). In the server information 131, it is conceivable to select the server to be activated from the available servers 300 such as securing the required number from the top, selecting at random, or selecting a server with good hardware performance.

  When the boot request reception unit 110 selects the activation target server, the boot request reception unit 110 notifies the selected activation target server to the remote power management unit 120 and the chain generation unit 140 (S15). Then, the remote power management unit 120 turns on the remote power on the notified server to be activated using means such as IPMI (S16).

  The chain generation unit 140 acquires the topology information 151 via the topology information management unit 150 (S17), generates a chain that is the distribution order of chunks (S18), and notifies the chain transmission unit 160 (S19). Details of the chain generation procedure will be described later using a specific example. Then, the chain transmitting unit 160 transmits the notified chain to the image repository apparatus 200 (S20).

  As described above, the remote boot device 100 transmits a chain, which is a chunk distribution procedure, to the image repository device 200. The image repository apparatus 200 first transmits a chunk to the addition target server at the head of the chain in accordance with the transmitted chain, and thereafter, chunk transfer processing according to the chain is performed between the addition target servers.

<Chain generation procedure>
Here, the chain generation procedure (S18 in FIG. 10) of the chain generation unit 140 of the remote boot device 100 in FIG. 4 will be described in detail with reference to FIGS.

  Here, a case where Svr3, Svr4, Svr6, and Svr7 are selected as activation target servers in the network topology illustrated in FIG. 6 will be described as an example. Note that the chain generation unit 140 in FIG. 4 generates a processing table (see FIGS. 12A to 12I) that is a table indicating the chain generation status at the time of chain generation. The chain generation process is performed with reference to the topology information 151 (see FIG. 7). Further, since the chain generation process proceeds for each switch 700, the switch 700 being processed will be described as S. Each of FIGS. 12A to 12L shows a processing table and a chain when S changes.

  When chain processing starts, the chain generation unit 140 first generates a chain whose head is the address of the image repository device 200 (Rep) that is the chunk distribution source (S1). Then, the chain generation unit 140 refers to the topology information 151, generates a processing table using the switch ID of the switch 700 group directly or indirectly connected to the activation target server as a key, and is the value thereof. All the processing flags are initialized to “0” (S2, see FIG. 12A).

  Then, the chain generation unit 140 starts the processing with the switch 700 (SW6 in FIG. 7) in which the repository (image repository apparatus 200) is accommodated as S (S3).

  The chain generation unit 140 adds the addresses of one or more startup target servers accommodated in the S switch 700 to the end of the chain (next to the chain, immediately after the server 300 added immediately before) (S4). For example, since the activation target server accommodated in SW6 in FIG. 6 is only Svr7, the chain generation unit 140 adds only the address of Svr7 to the chain. Then, the chain generation unit 140 sets the processing flag of SW6 in the processing table to “1” as shown in FIG. 12B (S5).

  Thereafter, if there is a parent switch of S on the topology (Yes in S6), the chain generation unit 140 sets this S as a parent switch (S7), and proceeds to S8. For example, since SW6 in FIG. 6 has a parent switch (SW3), the chain generation unit 140 moves S to SW3 and advances the process to S8.

  On the other hand, if there is no parent switch of S on the topology (No in S6), the chain generation unit 140 ends the chain generation process (S12). That is, the generated chain is output to the chain transfer unit 321 in FIG.

  After S7, the chain generation unit 140 refers to the processing table, and if S does not have a child switch whose processing flag is “0” (No in S8), sets the processing flag of S in the processing table to “1”. (S11), the process returns to S6. For example, when S is SW3 in FIG. 6, there is no child switch (SW6) of SW3 whose processing flag is “0” in the processing table shown in FIG. The processing flag of SW3 in the table is set to “1” (see FIG. 12C), and the process returns to S6. Here, since SW3 in FIG. 6 has a parent switch (SW0) (Yes in S6), the chain generation unit 140 sets S to SW0, which is the parent switch (S7). That is, if there is no unprocessed child switch in S, chain generation unit 140 returns S to the parent switch.

  On the other hand, the chain generation unit 140 refers to the processing table, and if there is a child switch whose processing flag is “0” in S (Yes in S8), that is, if there is an unprocessed child switch, the chain generation unit 140 Moves S to an unprocessed child switch, that is, one of the child switches whose processing flag is “0” (S9). Then, the process proceeds to S10. For example, as shown in the processing table of FIG. 12D, since SW0 has two child switches whose processing flag is “0” (SW1 and SW2 in FIG. 6), the chain generation unit 140 sets S to , SW1 or SW2 (for example, SW1).

  After S9, if there is an S child switch (Yes in S10), the chain generation unit 140 returns to S8. On the other hand, if there is no child switch of S (No in S10), the process returns to S4. That is, when the processing target S is the switch 700 that accommodates the server 300, S4 is executed and the address of the activation target server accommodated in the switch 700 is added to the chain. For example, when S is SW1 in FIG. 6, since SW1 does not accommodate the servers to be activated (Svr3, Svr4, Svr6, Svr7), the chain generation unit 140 does not add a chain. The processing flag of SW1 in the table is set to “1” (S5, see FIG. 12E). Since this SW1 has a parent switch (SW0 in FIG. 6) (Yes in S6), the chain generation unit 140 returns S to the parent switch (SW0) in S1 (S7). Here, as shown in the processing table of (f) of FIG. 12, since SW0 has a child switch (SW2) whose processing flag is “0” (Yes in S8), S is moved to SW2 (S9). ).

  SW2 in FIG. 6 has a child switch (SW4) (Yes in S10), and as shown in the processing table of (g) in FIG. 12, the processing flag of this SW4 is “0” (Yes in S8). , S is set to SW4 (S9). Since this SW4 has no child switch (No in S10) and SW4 accommodates the servers to be activated (Svr3, Svr4), the chain generation unit 140 adds the addresses of Svr3 and Svr4 to the chain (S4). FIG. 12 (h)). Further, the processing flag of SW4 in the processing table is set to “1” (S5, refer to (h) of FIG. 12).

  Next, since SW4 in FIG. 6 has a parent switch (SW2) (Yes in S6), the chain generation unit 140 returns S to SW2 (S7). As shown in the processing table of (i) of FIG. 12, since SW2 has a child switch (SW5 of FIG. 6) whose processing flag is “0” (Yes in S8), S is moved to SW5 (S9). . Since there is no child switch in SW5 (No in S10) and SW5 accommodates the activation target server (Svr6), the chain generation unit 140 adds the address of Svr6 to the chain (S4). The processing flag of SW5 in the processing table is set to “1” (S5, refer to (j) of FIG. 12).

  Since this SW5 has a parent switch (SW2 in FIG. 6) (Yes in S6), the chain generation unit 140 returns S to SW2 (S7). Here, as shown in the processing table of FIG. 12 (k), SW2 has no child switch with the processing flag “0” (No in S8), so the processing flag of SW2 in the processing table is set to “1”. (S5).

  Thereafter, since SW2 has a parent switch (SW0 in FIG. 6) (Yes in S6), the chain generation unit 140 returns S to SW0 (S7). As shown in the processing table of (l) of FIG. 12, since there is no child switch with the processing flag “0” in this SW0 (No in S8), the processing flag of SW0 in the processing table is set to “1” ( S11). Since SW0 has no parent switch (No in S6), the chain generation unit 140 ends the chain generation processing (S12), and transfers the chain that is the transfer order (the chain shown in (l) of FIG. 12). To the unit 321. As described above, the chain generation unit 140 starts the image repository apparatus 200 as a start point in the network topology illustrated in FIG. 6 and has the minimum number of hops to the next start target server (the switch 700 through). Select and add to the chain. Therefore, the generated chains can be arranged so that the number of switches passing between the activation target servers is minimized.

<Image repository device>
Next, the operation procedure of the image repository apparatus 200 will be described with reference to FIG. When receiving the image ID of the software image to be distributed from the remote boot device 100 (S21), the distribution request receiving unit 210 of the image repository apparatus 200 acquires the image information 221 (see FIG. 8) via the image information management unit 220. (S22) The image division (path) of the software image is notified to the chunk division unit 242 (S23).

  The chunk division unit 242 acquires a distribution target software image (image) from the storage 230 based on the image path notified in S23 (S24), and divides the software image into chunks (S25). The chunk division unit 242 develops the divided chunks on the main memory of the image repository apparatus 200.

  Further, when receiving the chain from the remote boot device 100 (S26), the distribution request receiving unit 210 of the image repository device 200 notifies the chain transfer unit 241 of the received chain (S27). Then, the chain transfer unit 241 refers to the notified chain and transfers the chain to the address of the server 300 at the head of the chain (S28). Further, the distribution request receiving unit 210 notifies the chunk transmission unit 243 of the chain received in S26 (S29). The chunk transmission unit 243 acquires the chunk developed on the main memory by the chunk division unit 242 (S30), and transmits the acquired chunk to the server 300 at the head of the chain (S31).

  Further, as described above, the image repository apparatus 200 may receive the distribution status of the chunk from the server 300 at the end of the chain by the distribution status reception unit 244 (S32). The distribution status here is, for example, that the terminal server 300 notifies the number of received chunks, the ratio of received chunks with respect to the entire software image, and the like every predetermined time.

<Server>
Next, the operation of the server 300 will be described with reference to FIGS. 14 and 15. First, the operation of the server 300 other than the server 300 at the end of the chain will be described with reference to FIG.

  As shown in FIG. 14, when the remote management receiving unit 311 of the server 300 receives a remote power ON command from the remote boot device 100 through an interface such as IPMI (S41), the remote boot receiving unit 311 instructs the selective boot unit 312 to boot the machine. (S42). Here, the selective boot unit 312 activates the image transfer unit 320.

  When the chain (parameter information if necessary) is transmitted from the image repository apparatus 200 or another server 300 (S43), the chain transfer unit 321 transmits this chain to the server 300 next to the chain (S44). ). The chain transfer unit 321 notifies the chunk transfer unit 323 of the chain (S45). Further, the chain transfer unit 321 generates a chunk table (see FIG. 9) (S46).

  When the chunk receiving unit 322 receives a chunk from the image repository apparatus 200 or another server 300 (S47), it registers the received chunk in the chunk table 341 via the chain transfer unit 321 (S48). That is, the chunk reception unit 322 sets the reception flag of the chunk ID of the reception chunk in the chunk table 341 to “1”.

  Thereafter, the chunk transfer unit 323 refers to the chunk table 341, acquires a chunk whose reception flag is “1” (S49), and transmits it to the next server 300 in the chain (S50). Also, the chunk storage unit 324 acquires a chunk whose reception flag is “1” (S51), and stores it in the image storage unit 330 (S52). When the transmission and storage of the chunk is completed in this way, the chunk transfer unit 323 and the chunk storage unit 324 set the transmission flag and storage flag of the chunk in the chunk table 341 to “1”, respectively. Thereafter, the chunk transfer unit 323 refers to the chunk table 341, and deletes fragments that have been received, transmitted, and stored in the image storage unit 330 from the main memory.

  Thereafter, when reception, transmission, and storage of all the chunks constituting the software image are completed in each server 300, the chain transfer unit 321 outputs a completion notification to the selective boot unit 312 (S53). Upon receiving this completion notification, the selective boot unit 312 changes the boot target to the system in the software image of the image storage unit 330 and restarts the server 300 (S54). As a result, the system in the software image is activated by the selective boot unit 312.

  As described above, the server 300 performs the chunk reception, transmission, and storage processing (portions surrounded by the broken line in the sequence of FIG. 14) in parallel, so that high-speed bucket relay distribution can be realized.

  Finally, the operation when the server 300 at the end of the chain notifies the image repository apparatus 200 of the distribution status of the chunk will be described with reference to FIG. Similarly to S41 to S43 in FIG. 14, the terminal server 300 receives a remote power ON from the remote boot device 100 (S61) and boots (S62), the chain transfer unit 321 of the server 300 causes the image repository device 200 to Alternatively, the chain transmitted from the other server 300 is received (S63). Thereafter, the chain transfer unit 321 notifies the transfer information management unit 325 of this chain (S64), and generates a chunk table 341 (S65). Here, since the terminal server 300 does not transmit the chunk to the next server 300, the transmission flag of each chunk in the chunk table 341 is set to “1” (see FIG. 16).

  When the chunk receiving unit 322 receives a chunk from the image repository apparatus 200 or another server 300 (S66), it registers in the chunk table 341 as in S48 of FIG. 14 (S67). Then, the chunk storage unit 324 that has confirmed the reception of the chunk performs chunk acquisition and storage in the image storage unit 330 (S68, S69), similar to S51 and 52 of FIG. 14, and the chunk storage unit 324 The storage flag of the chunk in the table 341 is set to “1”. When the transfer information management unit 325 acquires information (chunk information) of each chunk indicated in the chunk table 341 via the chain transfer unit 321 (S70), the transfer information management unit 325 transmits the distribution status including the chunk information to the image repository apparatus 200. (S71). As a result, the image repository apparatus 200 can check how many chunks have reached the server 300 at the end of the chain. Since S72 and S73 are the same as S53 and S54 in FIG.

  According to the system described above, since the chunk of the software image distributed from the image repository apparatus 200 is transferred in a bucket relay manner between the activation target servers according to the chain, the software image can be quickly distributed. Further, when generating the chain, the remote boot device 100 sets the distribution order of the chunks so that the number of switches passing between the activation target servers is as small as possible. Therefore, there is no possibility that the communication band in the network is occupied unnecessarily.

  In the above-described embodiment, the remote boot device 100 and the image repository device 200 have been described as separate devices, but these may be realized by the same device.

  Further, the chunk size when dividing the software image may be a fixed size given in advance, or may be a size dynamically notified from the remote boot device 100 together with the image ID.

  In addition, when transmitting the chunk to the next server 300, the chunk transmission unit 243 of the server 300 may establish and transmit a single connection with the next server 300, or establish a plurality of connections and perform chunking. May be sent in parallel. For example, when N connections are used, the chunk transmission unit 243 transmits 1 / N chunks of the total number of chunks for each connection. By doing in this way, transmission of the chunk between the servers 300 can be performed promptly.

  Further, the distribution status reception unit 244 of the image repository apparatus 200 receives the chunk itself from the terminal server 300 instead of receiving the distribution status from the terminal server 300, and calculates the distribution status based on the received chunk. You may make it do. Further, the distribution status reception unit 244 may receive a request from an external device and return the current distribution status.

  Furthermore, the chain transfer unit 241 of the image repository apparatus 200 may transmit parameters such as the capacity of the software image to be transmitted, the port number used for communication, and the number of connections at the time of chain transfer to the addition target server. The value of this parameter may be determined dynamically at the time of chain transmission, or a static value may be determined in advance.

  In addition, the chain generated by the remote boot device 100 is transferred between each activation target server described in the chain via the image repository device 200. However, the present invention is not limited to this. For example, it may be distributed directly from the remote boot device 100 to each of the image repository device 200 and the activation target server, or the image repository device 200 that has received the chain may be distributed to each of the activation target servers.

DESCRIPTION OF SYMBOLS 100 Remote boot apparatus 110 Boot request reception part 120 Remote power supply management part 130 Server information management part 131 Server information 140 Chain generation part 150 Topology information management part 151 Topology information 160 Chain transmission part 200 Image repository apparatus 210 Distribution request reception part 220 Image information Management unit 221 Image information 230 Storage 240 Image distribution unit 241, 321 Chain transfer unit 242 Chunk division unit 243 Chunk transmission unit 244 Distribution status reception unit 300 Server 310 Boot unit 311 Remote management reception unit 312 Selective boot unit 320 Image transfer unit 322 Chunk receiving unit 323 Chunk transfer unit 324 Chunk storage unit 325 Transfer information management unit 330 Image storage unit 341 Chunk table 400 Management network 500 service network 600 terminal 700 switch

Claims (5)

In a network in which a server and switches that connect the servers are connected in a tree structure, the server to be added to a cluster is instructed to remotely turn on and a software image for operating the server is distributed to the image repository device Remote boot device
Receiving an input of an addition instruction including the number of servers to be added to the cluster and the type of software image to be distributed to the servers to be added;
Transmitting the type of the input software image to the image repository device;
Based on the input addition instruction, the server information indicating whether the server ID and whether or not the server can be added to the cluster is read, and the server that can be added among the servers indicated in the read server information. Selecting the number of servers indicated in the addition instruction as an addition target server to the cluster, and transmitting a remote power-on instruction to each of the selected addition target servers via the management network;
The addition target server when the fragment obtained by dividing the software image is transferred between the addition target servers with reference to the topology information indicating the connection relationship between the image repository device, the server and the switch connecting the server Generating transfer instruction information including the order of:
Performing the step of transmitting the generated transfer instruction information to the image repository device;
The image repository device is
The step of dividing the software image of the transmitted type and transmitting the fragment of the divided software image and the transfer instruction information to the first server to be activated in the transfer order included in the transfer instruction information is executed. And
Each of the addition target servers that has received the transfer instruction information and the software image fragment,
The process of transferring the received piece of the software image to the addition target server to which the piece is transferred next to its own server in the transfer instruction information and storing it in the image storage unit of the own server. Receiving and forwarding all the fragments that make up the
Executing the own server from a software image stored in the image storage unit;
When the remote boot device generates the transfer instruction information,
The order of the addition target servers when transferring between the addition target servers is such that the number of the switches passing between the addition target servers is minimized with reference to the topology information. Software image distribution method. Each of the servers
A main memory for storing the fragment of the received software image and a chunk table indicating whether or not the fragment is received, transmitted, and stored in the image storage unit for each fragment;
With reference to the chunk table, for the fragment that has been received, transmitting the fragment or storing in the image storage unit;
When the fragment is transmitted or stored in the image storage unit, the step of rewriting the transmitted or stored in the image storage unit for the fragment in the chunk table is executed,
2. The step of referring to the chunk table and deleting a fragment that has been executed for reception, transmission, and storage in an image storage unit from the main memory is performed. Software image distribution method. Each of the servers
In the transfer instruction information, when the server determines that the order of the addition target servers is the last when transferring between the addition target servers,
3. The software image distribution method according to claim 1, wherein the fragment received by the server is notified to the image repository apparatus. In a network in which a server and a switch for connecting the servers are connected in a tree structure, an image repository device that distributes a software image for operating the server and an instruction to remotely turn on the server to be added to a cluster A software image distribution system comprising: a remote boot device that instructs the image repository device to distribute the software image;
The remote boot device is:
A boot request that accepts an input of an addition instruction including the number of servers to be added to the cluster and the type of software image to be distributed to the server to be added, and transmits the type of the input software image to the image repository apparatus A reception department;
Based on the input addition instruction, the server information indicating whether the server ID and whether or not the server can be added to the cluster is read, and the server that can be added among the servers indicated in the read server information. A remote power management unit that selects the number of servers indicated in the addition instruction as an addition target server to the cluster, and transmits a remote power-on instruction to each of the selected addition target servers via the management network;
The addition target server when the fragment obtained by dividing the software image is transferred between the addition target servers with reference to the topology information indicating the connection relationship between the image repository device, the server and the switch connecting the server A chain generation unit that generates transfer instruction information in which the order of the switches is set to minimize the number of switches that pass between the addition target servers;
A chain transmission unit for transmitting the generated transfer instruction information to the image repository device,
The image repository device
An image distribution unit that divides the software image of the transmitted type and transmits the fragment of the divided software image and the transfer instruction information to the first activation target server in the transfer order included in the transfer instruction information With
The server
The process of transferring the fragment of the software image to the addition target server to which the fragment is to be transferred next to the server in the transfer instruction information and storing the fragment in the image storage unit of the server itself constitutes the software image An image transfer unit that receives and repeats all fragments to be transmitted,
The image storage unit;
A software image distribution system comprising: a boot unit that activates the server itself from a software image stored in the image storage unit. In a network in which a server and a switch for connecting the servers are connected in a tree structure, a remote power-on instruction is given to the server to be added to a cluster, and a software image for operating the server is distributed to an image repository apparatus A software image distribution program for instructing
On the computer,
Receiving an input of an addition instruction including the number of servers to be added to the cluster and the type of software image to be distributed to the servers to be added;
Transmitting the type of the input software image to the image repository device;
Based on the input addition instruction, the server information indicating whether the server ID and whether or not the server can be added to the cluster is read, and the server that can be added among the servers indicated in the read server information. Selecting the number of servers indicated in the addition instruction as an addition target server to the cluster, and transmitting a remote power-on instruction to each of the selected addition target servers via the management network;
The addition target server when the fragment obtained by dividing the software image is transferred between the addition target servers with reference to the topology information indicating the connection relationship between the image repository device, the server and the switch connecting the server Generating transfer instruction information including the order of:
Transmitting the generated transfer instruction information to the image repository device,
The transfer instruction information to be generated is
The image repository apparatus divides the transmitted type of software image, the fragment of the divided software image, and the transfer instruction information, the first activation target in the transfer order included in the transfer instruction information To the server,
For each addition target server that has received the transfer instruction information and the software image fragment, the received software image fragment is transmitted to the addition target server to which the fragment is to be transferred next to its own server in the transfer instruction information. Information that tells you to transfer it,
The order of the addition target servers when transferring between the addition target servers is such an order that the number of the switches that pass between the addition target servers is minimized with reference to the topology information. Software image distribution program.

Images