JP4950418B2 - Network boot method, network boot system, and network boot program - Google Patents

Description

  The present invention relates to a network boot method, a network boot system, and a network boot program, and more particularly to a method for managing an operating system (OS (Operating System)) for a client to boot via a network.

As a conventional network boot system, a technique for providing a platform for booting each computer connected to a network is known (for example, see Patent Document 1).
JP 2003-330728 A (paragraphs 0013 to 0029, FIGS. 1 to 5)

  The technology described in Patent Document 1 has a problem in that since the number of OSs to be managed increases as the number of types of computers increases, the amount of data to be managed increases and the storage area is compressed, making management complicated.

  Therefore, it is an object of the present invention to reduce the OS for booting a plurality of computers, save a storage area for storing the OS, and easily manage the OS.

Accordingly, the present invention provides a network boot method for a network boot system that causes a computer to boot an operating system via a network as a means for solving the above-described problem. The network boot system includes a plurality of operating systems. The dependency module that depends on the hardware of the computer and the common module that does not depend on the hardware are separately stored, the common module is stored in an intermediate code format, and the dependency module can be executed by the computer in comprising a storage unit, which stores the corresponding from the module storing means for storing separately a plurality of operating systems to each of a plurality of single modules to the hardware configuration of the boot destination of the computer Reading out the module, and compile modules of the intermediate code format of the read each module into a executable format boot destination of the computer, the operating system for each of the computer by combining the respective modules And the step of sending the created operating system to the computer via the network for booting.

  According to the present invention, the OS for booting a plurality of computers having different hardware configurations can be reduced, the storage area for storing the OS can be saved, and the OS can be managed easily.

Hereinafter, a network boot system according to an embodiment of the present invention will be described with reference to the drawings.
First, an example client-server system in which the network boot system 10 is configured as a server will be described with reference to the overall configuration diagram shown in FIG. In the following description, FIG. 1 will be referred to unless there is a particular notice regarding the figure numbers corresponding to the constituent elements.
This client server system includes a network boot system 10, a network 20, a client 30, and an OS storage disk 40. Then, the network boot system 10 that manages each module as an OS component and creates a corresponding OS for each client 30 is created in the OS storage disk 40 via the network 20 in accordance with a boot request from the client 30. The OS is stored, and the OS is booted from the OS storage disk 40 by the client 30.

Next, each configuration of the client server system will be described in detail.
Here, the network boot system 10 will be described assuming a single device (server). However, the network boot system 10 is configured by a plurality of computers that realize each function, and can be distributedly connected to each other via a LAN or the Internet. It is good also as a simple structure. The client 30 will be described as one unit, but the number is not limited. As the OS storage disk 40, for example, a file server is used. However, another OS may be used as long as the OS can be stored. Further, although the OS storage disk 40 is described as a configuration provided outside to be connected to the network boot system 10 via the network 20, the OS storage disk 40 may be configured to be provided inside the network boot system 10.

First, the configuration of the network boot system 10 will be described.
The network boot system 10 is a general computer, and includes hardware such as a CPU (Central Processing Unit), a HDD (Hard Disk Drive), and an interface (not shown), manages the OS as a module, and is a boot destination computer. A network boot process to be described later is realized by executing a network boot program for creating an OS by combining modules according to the hardware configuration described above.

Therefore, the network boot system 10 checks the hardware configuration of the client 30 in accordance with the client communication unit (communication means) 100 that communicates with the client 30 and the boot request from the client 30 (device ID, OS type, etc.). OS configuration information creation means 200 for creating an agent program for extraction as configuration information), an OS creation means 300 for creating an OS according to the boot request and the configuration information, and storing it on the OS storage disk 40, and the client 30 A client OS table 400 storing a list for specifying the OS type to be booted is provided as a function.
Hereinafter, each function of the network boot system 10 will be described.

  The client communication unit 100 receives a boot request from the client 30 via the network 20 and transmits a boot instruction to the client 30. Further, the client communication unit 100 uses the client OS table 400 to determine which OS is to be booted by the client 30. For example, the client OS table 400 is searched using the machine type included in the boot request as a key, and the OS type is extracted. Then, the client communication unit 100 determines that the client 30 boots the extracted OS type OS, and passes the extracted OS type and boot request to the OS configuration information creation unit 200 and the OS creation unit 300.

The OS configuration information creation unit 200 extracts an agent program for acquiring hardware configuration information indicating the hardware configuration of the client 30 as an investigation result in accordance with a boot request from the client 30. The OS configuration information creation unit 210 and a configuration investigation agent table 220.
The OS configuration information creation unit 210 extracts an agent program suitable for obtaining the hardware configuration of the client 30 as configuration information (study result) from the configuration survey agent table 220 and sends it to the client 30.

In the configuration investigation agent table 220, as shown in FIG. 2, an agent program 223 such as a file name “Type1Check.exe” is added to a CPU type 221 such as “CpuType1” and a machine type 222 such as “machine 1”. It is related.
The OS creation means 300 creates an OS to be booted by the client 30, and stores the created OS in the OS storage disk 40. The OS creation unit 310, the compile unit 320, the common module table 330, the hardware And a hardware dependent module table 340.

Hereinafter, each configuration of the OS creation unit 300 will be described.
Based on the boot request and hardware configuration information sent from the client 30, the OS creation unit 310 extracts the common module from the common module table 330 and extracts the dependent module from the hardware dependent module table 340. Combine common modules and dependent modules. The common module is an upper layer module of the OS that does not depend on hardware, and has an intermediate code format. Here, similarly, the dependency module is described as an intermediate code format.

  Further, the OS creation unit 310 creates an OS for the client 30 by causing the compilation unit 320 to compile an OS intermediate code obtained by combining both modules. Further, the OS creation unit 310 stores the created OS in the OS storage disk 40 and issues a boot instruction to the client 30. This boot instruction includes the storage location (address) of the OS in the OS storage disk 40.

  In this example, both the common module and the dependent module are combined and compiled. However, the format of the module stored in each table is not limited as long as it is an executable format. For example, the dependency module may not be an intermediate code format but an execution format depending on hardware. In particular, the driver is a component of the OS used for virtualizing the hardware, and is very closely related to the hardware.

Here, the compiling unit 320, the common module table 330, and the hardware dependent module table 340 will be described in detail in order.
The compiling unit 320 compiles the intermediate code passed from the OS creation unit 310 into a format that can be executed on the hardware of the client 30. Here, a description will be given assuming that the OS created by compilation is stored in the OS storage disk 40 via the OS creation unit 310, but the compilation unit 320 does not go through the OS creation unit 310. 40 may be stored.

The common module table 330 is a list necessary for extracting the common modules. Among the modules constituting the OS for the client 30 to boot, the upper layer modules of the OS that do not depend on hardware are in the form of intermediate code. Is stored.
Specifically, the common module table 330 includes an OS type 331 such as “OS1”, a module name 332 such as “OS1Kernel.exe”, and a module such as “5.0.0.1025” as shown in FIG. Version 333, the position 334 indicating the storage location of the module 332 of the above-mentioned version 333, and the entity of the OS module in the intermediate code format that does not depend on the CPU type (not shown) of the client 30 “982e77fb. The OS binary 335 represented by “... A position 334 represented by “\ OS1System” or the like indicates the storage destination of the OS storage disk 40.

  The hardware-dependent module table 340 is a list for specifying modules such as hardware-dependent drivers. The hardware-dependent module table 340 is a list of drivers and HALs for virtualizing the hardware constituting the client 30 with respect to the upper layers of the OS. Modules such as Hardware Abstraction Layer) are stored.

  Specifically, in the hardware dependent module table 340, as shown in FIG. 4, a device ID 341 such as “PNP0001” for specifying a device, an executable “CpuType1” of a module such as a driver, etc. CPU type 342, OS type 343 such as “OS1” that can use the module, driver name 344 such as “OS1driver1.sys”, driver version 345 such as “5.0.0.1025”, and driver OS storage A position 346 indicating the storage destination of the disk 40 is associated with a driver binary 347 which is a driver entity such as “982e77fd...”. A position 334 represented by “\ OS1System \ drivers” or the like indicates the storage destination of the OS storage disk 40.

The client OS table 400 stores a list for specifying the OS type to be booted by the client 30 and is set when the client 30 boots to register the network boot system 10. .
In this client OS table 400, as shown in FIG. 5, a client identification ID 401 used for uniquely identifying the client 30 and an OS type 402 are associated with each other. For example, a client identification ID “ID-XYZ” is associated with a CPU type such as “OS2”.

  The network 20 enables the network boot system 10, the client 30, and the OS storage disk 40 to communicate with each other, and is configured by a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, and the like. . The network 20 may be a storage network such as a SAN (Storage Area Network).

  The client 30 is a computer such as a personal computer, and includes hardware such as a CPU, an HD, and an interface (not shown), and includes a basic device for booting the OS via the network 20. The client 30 starts up a basic input output system (BIOS) when the power is turned on, and transmits a boot request 500 as shown in FIG. 6 to the network boot system 10 via the network 20 in accordance with a communication protocol running on the BIOS. . The boot request 500 includes, for example, a client identification ID 501 such as “ID-XYZ” 501a for identifying the client 30, a CPU type 502 of the client 30 such as “CpuType3” 502a, and a generic name of the client machine (PC− A machine type 503 (for example, “Machine 3” 503a) for indicating AT (registered trademark) compatibility or the like is included.

The client 30 boots the OS from the OS storage disk 40 specified according to the boot instruction from the network boot system 10 via the network 20. Further, the client 30 moves an agent program transferred from the network boot system 10 on the BIOS, and checks its own hardware configuration by the agent program.
The OS storage disk 40 stores an OS sent from the network boot system 10 via the network 20.

Here, with reference to FIGS. 2, 4, and 7, the result of the client 30 examining the hardware configuration by the agent program 223 will be described.
As shown in FIG. 7, the hardware configuration investigation result 600 includes a list of device IDs 601 (“XP001” 601 a, “XP002” 601 b...) That are device-specific IDs. This device ID 601 specifies the device ID 341 in the hardware dependent module table 340 shown in FIG.

Next, processing for extracting the OS type 402 from the client OS table 400 of the client communication unit 100 will be described with reference to FIGS.
The client communication unit 100 extracts the OS type 402 shown in FIG. 5 from the client OS table 400 using the client identification ID 501 of the boot request 500 shown in FIG. 6 as a key. For example, “OS2” 402a shown in FIG. 5 is extracted using “ID-XYZ” 501a shown in FIG. 6 as a key.

Next, with reference to FIGS. 2 and 6, a process in which the OS configuration information creation unit 210 extracts an agent program will be described.
The OS configuration information creation unit 210 uses the CPU type 502 and machine type 503 included in the boot request 500 shown in FIG. 6 as keys, and the corresponding CPU type 221 and machine type from the configuration investigation agent table 220 shown in FIG. The agent program 223 in the record including “222” is extracted. For example, the agent program 223 such as “Type3Check.exe” 223a shown in FIG. 2 is extracted using “CpuType3” and “Machine 3” shown in FIG. 6 as keys.

  Next, with reference to FIGS. 3 to 7, the OS creation unit 310 uses the boot request 500 shown in FIG. 6 and the hardware configuration investigation result 600 shown in FIG. A process of extracting a common module from the common module table 330 shown in FIG. 5 and extracting a module (driver) from the hardware dependent module table 340 will be described.

  The OS creation unit 310 searches the common module table 330 shown in FIG. 3 using the OS type 402 extracted by the client communication unit 100 as a key, and the module name 332, version 333, and position 334 of the corresponding OS type 331. And the OS binary 335 as the common module is extracted from the corresponding position 334 from the common module table 330. For example, using the “OS2” 402a shown in FIG. 5 as a key, a record including the corresponding OS type 331 of “OS2” is searched, the module name 332 of “OS2Kernel”, the version 333 of “6.0.0.1025”, and “\ The “OS2System” position 334 and the OS binary 335 “21gaff9a...” 335a are extracted. Similarly, “c97a6f29...” 335b is also extracted.

  Further, the OS creation unit 310 uses the OS type 402 extracted by the client communication unit 100, the CPU type 502 shown in FIG. 6, and the device ID 601 of the hardware configuration investigation result 600 shown in FIG. 7 as keys. The hardware dependent module table 340 shown in FIG. 4 is searched. Then, the device ID 341, the CPU type 342, the driver name 344, the version 345, the position 346, and the driver binary 347 of the record corresponding to the OS type 343 are extracted from the hardware dependent module table 340. For example, “OS2” 402a shown in FIG. 5, “CpuType3” 502a shown in FIG. 6, “XP0001” 601a and “XP0002” 601b shown in FIG. 7 are used as keys, and the driver names shown in FIG. 344, version 345, position 346, and driver binary 347 such as “21gaff9a...” 347a, 347b are extracted.

  As described above, the network boot system 10 having the above-described configuration centrally manages the configuration investigation agent table 220, the common module table 330, the hardware dependent module table 340, and the client OS table 400. The module version can be managed efficiently and easily.

  Finally, according to the flowchart shown in FIG. 8, the flow of processing until the client 30 boots the OS will be described with reference to FIGS. In FIG. 8, the left side represents the processing of the client 30, and the right side represents the processing of the network boot system 10. In the following description, FIG. 1 will be referred to unless there is a particular notice regarding the figure numbers corresponding to the constituent elements.

  First, in the client 30, when the power is turned on by the user, the BIOS is activated (Sa1). With this activation, the client 30 transmits the boot request 500 shown in FIG. 6 to the network boot system 10 via the network 20 (Sa2).

  On the other hand, in the network boot system 10, when the client communication unit 100 receives the boot request 500 (Sb1), the client communication unit 100 sets an ID that matches the client identification ID 501 of the boot request 500 shown in FIG. Search from the client identification ID 401 of the client OS table 400 shown. Then, the corresponding OS type 402 is extracted, and the OS type to be booted by the client 30 is determined (Sb2). For example, since the client identification ID 501 shown in FIG. 6 is “ID-XYZ” 501a, referring to the client OS table 400 shown in FIG. 5, the OS type to be booted by the client 30 is “OS2” 402a.

Next, when determining the OS type, the client communication unit 100 passes the OS type determined by the boot request 500 and Sb2 illustrated in FIG. 6 to the OS configuration information creating unit 200 and the OS creating unit 300.
When the OS configuration information creation unit 200 receives the boot request 500 and the OS type shown in FIG. 6 from the client communication unit 100, the OS configuration information creation unit 210 causes the CPU type 502 and the machine type included in the boot request 500 to be included. Based on 503, an agent program 223 for investigating the hardware configuration of the client 30 is extracted from the configuration investigation agent table 220 shown in FIG. 2, and an agent program for the client 30 is determined (Sb3).
Here, since the CPU type 502 shown in FIG. 6 is “CpuType3” 502a and the machine type 503 shown in FIG. 6 is “Machine 3” 503a, “Type3Check.exe” of the corresponding agent program 223 shown in FIG. 223a is extracted.

  Thereafter, the OS configuration information creation unit 210 transmits the determined agent program 223 to the client 30 via the client communication unit 100 and the network 20 (Sb4). Here, “Type3Check.exe” 223 a shown in FIG. 2 is transmitted as the agent program 223.

  Upon receiving the agent program 223 (Sa3), the client 30 executes the received agent program 223 (Sa4), and transmits the hardware configuration investigation result 600 shown in FIG. 7 to the client communication unit 100 of the network boot system 10. (Sa5). Here, as shown in FIG. 7, the client 30 has an investigation result in which devices having device IDs 601 of “XP0001” 601 a and “XP0002” 601 b exist.

On the other hand, in the network boot system 10, when the OS creation unit 300 receives the boot request 500 and the OS type from the client communication unit 100 and receives the hardware configuration investigation result 600 shown in FIG. 7 from the client 30 (Sb5). 3) Extract all data that matches the OS type 402 passed from the client communication unit 100 from the OS type 331 of the common module table 330 shown in FIG. 3, and from that, extract the OS binary shown in FIG. 335 is extracted (Sb6).
Here, the record including the corresponding OS type 331 of “OS2” is searched using “OS2” 402a as a key, the module name 332 of “OS2Kernel”, the version 333 of “6.0.0.1025”, and the location of “\ OS2System” 334 is extracted, and “21gaff9a...” 335a that is binary data corresponding to the OS binary 335 is extracted from “\ OS2System”. Similarly, “c97a6f29...” 335b is also extracted.

  Next, the OS creation unit 300 sends “21gaff9a...” 335 a that is binary data corresponding to the OS binary 335 to the compiling unit 320. Then, the compiling unit 320 compiles the received binary data into an execution file for the CPU in accordance with the CPU type 502 included in the boot request 500 shown in FIG. 6 (Sb7). Here, since the CPU type is “CpuType3” 502a, the compiling unit 320 executes binary data “21gaff9a...” 335a and “c97a6f29. Compile to format. When all the compilations are completed, the compiling unit 320 passes the compiled binary to the OS creation unit 310.

  Next, the OS creating unit 310 uses the compiled binary passed from the compiling unit 320 according to the module name 332, version 333, and position 334 shown in FIG. It is arranged on the storage disk 40 (Sb8). Here, the binary compiled with “21gaff9a...” 335 a is arranged in the location “¥” root of the OS storage disk 40 as the file name “OS2System” and the version “6.0”. “C97a6f29...” 335b is similarly arranged.

  In this way, the OS creation unit 310 extracts, from the hardware-dependent module table 340, modules that satisfy all of the following conditions 1 to 3 for all device IDs 601 included in the hardware configuration investigation result 600 received in Sb5. Then, it is arranged on the OS storage disk 40 in accordance with the information of the driver name 344, version 345, and position 346 shown in FIG.

Condition 1 is that the device IDs 341 in the hardware-dependent module table 340 shown in FIG.
Condition 2 is a condition in which the CPU type 502 of the boot request 500 shown in FIG. 6 matches the CPU type 342 of the hardware dependent module table 340 shown in FIG.
Condition 3 is a condition in which the OS type 402 shown in FIG. 5 on which the client 30 boots matches the OS type 343 in the hardware-dependent module table 340 shown in FIG.

  Here, since the CPU type 502 shown in FIG. 6 is “CpuType3” 502a and the OS type 402 shown in FIG. 5 on which the client 30 boots is “OS2” 402a, the hardware configuration shown in FIG. As a driver for “XP0001” 601a of the device ID 601 included in the investigation result 600, “21gaff9a...” 347a shown in FIG. 4 which is a driver binary, the driver name 344 is “OS2driver1.sys”, and version 345 As “2.1”, it is arranged at the location “¥” route of the OS storage disk 40.

Further, as the driver for “XP0002” 601b of the device ID 601 shown in FIG. 7, the driver binary “21gaff9a...” 347b shown in FIG. 4 has the driver name 344 “OS2driver2.sys”, version 345 is set to “2.1”, and is placed in the position “¥” route of the OS storage disk 40.

  The OS creation unit 310 then arranges all the OS modules and driver modules on the OS storage disk 40, and then notifies the client communication unit 100 that the OS has been completed. Upon receiving the notification that the OS is completed, the client communication unit 100 transmits a boot instruction, which is a command for booting the OS created on the OS storage disk 40, to the client 30 (Sb9). Note that the boot instruction includes the storage destination (address) of each module stored on the OS storage disk 40.

Thereafter, the client 30 receives a boot instruction from the network boot system 10 (Sa6), and boots using each module stored on the OS storage disk 40 (Sa7). Thereby, the network boot system 10 can cause the client 30 to boot the OS.
In the OS storage disk 40, when the boot by the client 30 is completed, the module is deleted. This deletion may be performed when a notification to turn off the power is received from the client 30 or when the storage capacity of the OS storage disk 40 is not sufficient.
As described above, by extracting and configuring the module according to the hardware configuration of the client 30 each time the client 30 is booted, the storage capacity for storing the OS can be reduced.

  In the above description of the embodiment, the agent program 223 is sent from the network boot system 10 to the client 30 to be executed. However, the client program 30 may be incorporated in the BIOS in advance. Alternatively, the agent program 223 may be read from a CD-ROM (Compact Disk Read Only Memory) at every boot without using the network 20. Further, the network boot system 10 may transmit the created module directly to the client 30 without using the OS storage disk 40.

1 is an overall configuration diagram of a client server system including a network boot system of an embodiment. It is a figure which shows the structural example of a structure investigation agent table. It is a figure which shows the structural example of a common module table. It is a figure which shows the structural example of a hardware dependence module table. It is a figure which shows the structural example of a client OS table. It is a figure which shows the structural example of a boot request. It is a figure which shows the structural example of a hardware structure investigation result. It is a flowchart which shows the network boot process of embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Network boot system, 20 ... Network, 30 ... Client, 40 ... OS storage disk, 100 ... Client communication part (communication means), 200 ... OS configuration information creation means, 210 ... OS configuration information creation part, 220 ... Configuration investigation Agent table, 300 ... OS creation means, 310 ... OS creation section, 320 ... compile section, 330 ... common module table (module storage means), 340 ... hardware dependent module table (module storage means)

Claims (5)

A network boot method for a network boot system that causes a computer to boot an operating system via a network,
The network boot system is:
Together they are stored separately multiple operating systems on a common independent module dependent modules and a hardware dependent on the hardware of the computer, and stores the previous SL common module in the intermediate code format, the said dependent module Storage means stored in a computer-executable format ,
Reading each module corresponding to the hardware configuration of the boot destination computer from the storage means;
Compiling an intermediate code format module among the read modules, converting the module into a format executable by the boot destination computer, and combining the modules to create the operating system for each computer;
A step of sending the created operating system to the computer via the network and causing the computer to boot. The network boot method according to claim 1 ,
The network boot system is:
The storage means stores an agent program for investigating the hardware configuration of the computer;
Sending the agent program to the boot destination computer;
The computer
Execute the received agent program, investigate the hardware configuration of the computer, send the investigation results to the network boot system,
The network boot system is:
A network boot method, comprising: obtaining a hardware configuration of the computer from the computer. A network boot program for causing the network boot system, which is a computer, to execute the network boot method according to claim 1 or 2 . A network boot system for booting an operating system onto a computer via a network,
Multiple operating systems are stored separately in a common module which does not depend on dependent modules and a hardware dependent on the hardware of the computer, and stores the previous SL common module in the intermediate code format, the computer the dependent module Storage means stored in a form executable by
The modules corresponding to the hardware configuration of the boot destination computer are read from the storage means, and an intermediate code format module among the read modules is compiled into a format that can be executed by the boot destination computer. And an OS creating unit that converts the modules to create the operating system for each computer, and sends the created operating system to the computer via the network for booting. Network boot system. The network boot system according to claim 4 ,
The storage means stores an agent program for investigating the hardware configuration of the computer;
The OS creation means
Sending the agent program to the boot destination computer;
A network boot system characterized in that the hardware configuration of the computer investigated by the agent program is acquired from the computer.

Images