Patent Application
20080294888
The present application claims priority from Japanese application JP2007-133825 filed on May 21, 2007, the content of which is hereby incorporated by reference into this application.
1. Field of the Invention
The present invention relates to a technique for deploying a boot (start) disk image in a computer (deploy target computer) such as a server.
2. Description of the Related Art
In recent years, flexible server construction according to a business load is demanded in operation of a system including a large number of servers. In other words, specifically, shortening of the server construction time is first demanded. For the server construction, it becomes necessary to deploy a boot disk image in a server. Here, the boot disk image refers to an image obtained when a program required for the server to boot is installed in a storage area. Hereafter, however, it is represented by “OS (Operating System) image” (or “image” or “disk image”).
When deploying an OS image in a server, a deployment system first extracts inherent information of the server such as a computer name and network related information from a storage area in which the OS is stored, and generates a master disk. Thereafter, the deployment system delivers a master disk image via a network in response to a deploy order, and copies the image onto a local disk in the server. The deployment is regarded as completed when the copy is completed. By the way, the master disk may be generated so as to contain inherent information of the machine. In this case, it is necessary to rewrite the inherent information by using a dedicated program after copy of the master disk.
In such a conventional technique, a load is applied to the network because the disk image is delivered to the deploy target server via the network, and it takes time until the deployment completion because of network restriction such as communication band restriction. And the time required until the deployment completion increases as the capacity of the master disk increases, and quick scale out of the system cannot be coped with. If as many master disks as the number of deploy target servers are prepared beforehand, a large number of replicas become necessary and the burden on a system manager is heavy. In US2005/0223210A1 (Sasaki et al), therefore, a deployment technique capable of quickly providing a provision destination of an OS image with an OS image stored in a logical volume in a storage system is disclosed.
A deployment method disclosed in US2005/0223210A1 is a technique for conducting deployment quickly in a system in which a plurality of information processing terminals and at least one storage system are connected to a first communication network and a deployment machine is connected to a second communication network (for example, a SAN (Storage Area Network)) which is faster in operation than the first communication network, by copying OS image data stored in a logical volume in a storage system to a logical volume for server via the second communication network.
Even if a fast communication network is used to copy the OS image, however, some time is required to conduct the copying and consequently it takes some time (for example, approximately one hour) until the copying is completed and the deploy target server is brought into a state where the boot can be started. The present invention has been made in view of these problems, and an object thereof is to bring the deploy target server into the state where the boot can be started, in a short time.
The present invention provides a deploy target computer which is connected to a storage device including a replication source logical disk used to store a boot disk image functioning as a program for starting and which becomes a target of deployment of the boot disk image.
The deploy target computer includes a disk mapping processing part for changing over an access destination so as to set the access destination to the replication source logical disk in the storage device when an I/O request is issued from the deploy target computer to the storage device and the I/O request specifies reading the boot disk image, and so as to set the access destination to a replication destination logical disk provided in the storage device, the deploy target computer or an external computer to conduct writing concerning the boot disk image when the I/O request specifies writing concerning the boot disk image. Other means will be described later.
According to the present invention, the deploy target server can be brought into the state where the boot can be started, in a short time by the changeover of the access destination conducted by the disk mapping processing part.
Other objects, features and advantages of the invention will become apparent from the following description of the embodiments of the invention taken in conjunction with the accompanying drawings.
Hereafter, embodiments of the present invention will be described.
The OS image is one form of the boot disk image (which is a general term of images required for the target server 102 to boot). If an image to be deployed is a boot disk image, the boot disk image may include an application image besides the OS image. Each image refers to a state in which its pertinent program is stored in hardware (a state in which driver setting and the like have been conducted).
In
By the way, the SAN need not be a FC-SAN, but may be, for example, an IP (Internet Protocol)-SAN. In such a case, the target server 102 may be connected to the NW-SW 120 instead of the FC-SW 121, and a different NW-SW for communicating with the storage system 130 may be used. In the case where a different NW-SW is provided as a dedicated SW for communicating with the storage subsystem 130, relaxation of network communication restrictions caused by, for example, dissipation of communication bands can be anticipated.
By the way, the HBA 103 is an interface (corresponding to an interface 211 shown in
The target server 102 includes a storage device 105 (for example, a memory or the like) storing an OS 203 and a disk mapping processing program 101, and a processor 106 (for example, a CPU (Central Processing Unit)) for executing the disk mapping processing program 101. The disk mapping processing program 101 is a program for changing over an access destination device of an I/O (Input/Output) request (input/output request, which is simply referred to as I/O as well hereafter) in order to make the OS 203 believe that the OS image copying is instantaneously completed. The processor 106 executes the disk mapping processing program 101 (in other words, the disk mapping processing part 101a (see
The storage subsystem 130 which is an external storage device is a storage device including a processor 134 for arithmetic operation, a logical volume (for example, a virtual disk which can be identified by using a logical unit or the like), a disk controller, and a data reflection part 140. The storage subsystem 130 is, for example, a RAID (Redundant Arrays of Inexpensive Disks) system constituted by arranging a large number of disk-type storage devices (physical disks) on an array. Logical volumes include master data volumes 131 and 132 (which are hereafter referred to as “master data volume 13” unless especially distinguished) (replication source logical disk) for retaining an OS image which becomes an origin of deployment, and a target server volume 133 (corresponding to the target server 102 in one-to-one correspondence) (replication destination logical disk) for target server 102 to be accessed by the target server 102 other than the master data volume. There may be a plurality of master data volumes and a plurality of target server volumes. Each logical volume is assigned a logical volume ID (Identification) for uniquely identifying the logical volume. Access from the outside is conducted by specifying the logical volume ID.
Although only one storage subsystem 130 is shown in
The data reflection part 140 included in the storage subsystem 130 is a processing part for copying data in the master data volume 13 to the target server volume 133. It is not always necessary that the data reflection part 140 is included in the storage subsystem 130, but the data reflection part 140 may be included in an external computer connected to the devices retaining the master data volume 13 and the target server volume 133.
The data reflection part 140 includes a reflection information management part 141, a reflection information table 1000 (which will be described with reference to
The storage subsystem 130 further includes a master image management table 1100 (which will be described with reference to
The deployment machine 110 is, for example, a computer such as a personal computer. The deployment machine 110 includes an interface (not illustrated) for network connection. The deployment machine 110 further includes a processor 111 (for example, a CPU), and a storage device 112 (for example, a memory or a hard disk) for storing deployment software used to order deployment. The deployment machine 110 further includes a communication device (not illustrated) required to order the target server 102 to conduct deployment and request the storage subsystem 130 storing the master data volume 13 and the target server volume 133 to set a path to the WWN 104 in the HBA 103 included in the target server 102. The processor 111 executes deployment software stored in the storage device 112 and issues a deploy instruction to the target server 102 and the master data volume 13. Thereby the deployment machine 110 implements a deploy order function. Heretofore, the general configuration of the deployment system DS shown in
The disk mapping processing part 101a included in the target server 102 will now be described with reference to
As shown in
The I/O trap part 204 conducts processing for trapping an I/O request issued from the OS 203. The I/O trap part 204 is a processing part for exercising control to, for example, prevent trap processing from being executed after a notice that all data in the master data volume 13 have been reflected to the target server volume 133 is received from the data reflection completion detection part 209 which will be described later. The I/O analysis part 205 is a processing part for analyzing an I/O request trapped by the I/O trap part 204 (i.e., for determining whether the I/O request is a read request or a write request).
The physical device control part 206 is a processing part for dynamically changing an access destination device of an I/O request as occasion demands in cooperation with the mapping information management part 207. The physical device control part 206 judges a request classification (read/write) for a target server device (the master data volume 13 or the target server volume 133) included in contents analyzed by the I/O analysis part 205, and changes the access destination device dynamically. By the way, the physical device control part 206 may be, for example, a part that includes a device driver such as a disk driver and that conducts processing to change an access destination of an I/O request. A driver such as an HBA adaptor may have the function of the physical device control part 206. Or the physical device control part 206 may be firmware.
The mapping information management part 207 includes the mapping state management table 900 and the mapping information 208, and manages information required by the physical device control part 206 to change over the I/O destination. The mapping information management part 207 updates the mapping state management table 900 on the basis of information input/output by the interface 211 (an upper concept of the HBA 103).
The data reflection completion detection part 209 detects a data reflection completion notice from the reflection completion notice part 143 that the data reflection part 140 (which will be described in detail later) in the storage subsystem 130 has. Upon detecting the completion of the processing of reflecting the master data volume 131 to the target server volume 133, the reflection completion detection part 209 notifies the path release request part 210 of the completion state and conducts execution of the access path setting release request to the master data volume 13. The path release request part 210 is a processing part for requesting release of an assigning state of the WWN 104 to the master data volume 131 included in the storage subsystem 130 when the reflection completion detection part 209 has detected completion of the data reflection.
Hereafter, an outline of processing for causing the target server 102 which has received a deploy instruction from the deployment machine 110 to be able to boot instantaneously in the deployment system DS according to the first embodiment shown in
First, the deployment machine 110 issues a deploy order concerning the target server 102. Specifically, the deployment machine 110 conducts assignment of logical volume IDs of the master data volume 131 and the target server volume 133 included in the storage subsystem 130 and the host bus adapter (HBA 103) included in the target server, and registers a target server ID (column 1201), a copy source volume ID (column 1202), a copy destination volume ID (column 1203), a reflection information table (column 1204) and an assigned WWN (column 1205) in the data reflection management table 1200 (
As for concrete registration into the mapping state management table 90 included in the interface 211 and the boot path setting method, it is conceivable that the deployment machine 110 distributes a program for table update processing and boot path setting. If thereafter power supply control processing (for example, using magic packet transmission based on “Wake On LAN” technique or the like) is executed on the target server 102 and a power supply of the target server 102 is turned on, then data required for boot processing of the target server 102 are read out from the master data volume 131 and the target server 102 can start the boot.
In other words, if only a time required for path setting in the storage subsystem 130 has elapsed, then the boot processing of the target server 102 can be started without waiting for the completion of copying of the master data volume 131 to the target server volume 133. Therefore, it becomes possible to instantaneously cope with a case where prediction is difficult such as scale-out for the target server 102 rapidly increased in load. By the way, the scale-out means assigning a new target server 102 to the system configuration. Heretofore, the outline ranging from the deploy instruction to start of the boot processing conducted by the target server 102 in the first embodiment has been described.
Values of respective columns are generated by the processor 106 in response to a deploy order from the deployment machine 110, and are referred to by the path release request part 210 in the disk mapping processing part 101a or the like. By the way, it is not always necessary that the mapping state management table 900 includes all columns shown in
By the way, the reflection information table 1000 generated from the data reflection management table 1200 (see
The target server ID (column 1201) is a unique identifier by which a target server 102 executing deployment can be discriminated (identified). The copy source volume ID (column 1202) uniquely identifies a logical volume area assigned as the master data volume 131 of the target server 102. The copy destination volume ID (column 1203) is an identifier of a logical volume area assigned as the target server volume 133. The reflection information table (column 1204) identifies a reflection information table 1000 which retains a copy state between volumes required by the data reflection part 140 to execute asynchronous copy (which is not synchronized with the operation of the disk mapping processing part 101a). The assigned WWN (column 1205) is a value of the WWN 104 in the HBA 103 included in the target server 102.
By the way, a certain copy source volume ID (column 1202) is not associated with only a specific copy destination volume ID (column 1203), but a plurality of copy destination volume IDs (column 1203) may be associated with one copy source volume ID (column 1202). Specifically, this is needed, for example, when deploying a certain master data volume 13 in a plurality of target servers 102.
Subsequently, concrete processing conducted in the deployment system DS will be described.
By the way, the I/O request from the OS 203 is access to a target server volume 133 that can be accessed from the target server 102 in which that OS 203 is operating. If it is judged at the step 401 that the data reflection is completed, therefore, it is possible to execute access to the device without conducting I/O trap processing and without changing the I/O request from the OS 203 at all. In other words, the disk mapping processing part 101a needs to access the master data volume 131 as occasion demands until data in the master data volume 131 is completely reflected to the target server volume 133. After the data in the master data volume 131 is completely reflected to the target server volume 133, however, the disk mapping processing part 101a need not access the master data volume 131, but needs to access only the target server volume 133.
The decision whether the data reflection is completed at the step 401 is made by the data reflection completion detection part 209 in the disk mapping processing part 101a which will be described later.
At step 501, the physical device control part 206 acquires a request classification (write/read) of the trapped I/O request and the access destination area from the I/O analysis part 205. At step 502, the physical device control part 206 makes a decision whether the request classification obtained at the step 501 is read or write. If a result of the decision is a write request, the physical device control part 206 executes step 503.
At step 503, the physical device control part 206 updates the mapping information 208 managed by the mapping information management part 207. Specifically, the physical device control part 206 changes a state of the mapping information 208 corresponding to the access destination area acquired at the step 501 to an already written state (see
On the other hand, if the request classification at the step 502 is the read request, step 504 is executed. At the step 504, the physical device control part 206 refers to the mapping information 208 managed by the mapping information management part 207. Thereafter, the physical device control part 206 executes step 505. At the step 505, the physical device control part 206 makes a decision whether the area to be accessed in the I/O acquired at the step 501 is already written into the target server volume 133. If the request is a read request for an already written area (yes at the step 505), the access is regarded as access to the target server volume 133 without changing the trapped I/O request. If at the step 505 the request is a read request for an area that is not written (no at the step 505), then the physical device control part 206 refers to the mapping state management table 900 retained by the mapping information management part 207, acquires information (information in the column 904, the column 905 and the column 906) required to access the master data volume 131, and changes the access destination in the I/O request to the master data volume 131 (step 506).
Heretofore, the I/O changeover conducted by the physical device control part 206 has been described with reference to
Upon receiving a notice that the path release has completed from the storage subsystem 130, the data reflection completion detection part 209 recognizes a data reflection completion state, and brings about a state in which the I/O trap processing (I/O analysis) is not executed in response to an I/O request from the OS 203 (stops the analysis) (step 603). The data reflection completion detection part 209 refers to the mapping state management table 900 stored in the mapping information management part 207 included in the disk mapping processing part 101a, acquires the target server volume ID in the column 901, the WWN of the port in the storage subsystem 130 storing the target server volume 133 in the column 902, and the value of the WWN 104 stored in the memory of the HBA 103 included in the target server 102 in the column 903, and updates the boot path set in the interface 211 to the target server volume 133.
The processor 134 retrieves an ID corresponding to a logical volume (copy destination volume) to be subject to write processing from the column 1203 in the data reflection management table 1200 stored in the storage subsystem 130, and refers to the reflection information table (column 1204) in the hit pair (row). And the processor 134 changes (updates) a state in a location for the corresponding area of the write request in the reflection information table 1000 identified from the column 1204 to a state in which copying is not to be conducted (step 701).
After the step 701, the processor 134 executes write processing on the requested logical volume (target server volume 133) (step 702).
With respect to two volumes included in the pair, the data reflection part 140 copies an area of the master data volume 131 to be copied to a specific area in the corresponding target server volume 133 at step 802. And the data reflection part 140 updates the corresponding area in the reflection information table 1000 to the already copied area state at step 803. At step 804, the data reflection part 140 checks whether all areas in the reflection information table 1000 are already copied areas. If copying of all areas is not completed (no at the step 804), the data reflection part 140 returns to the step 802, and executes similar copy processing repetitively with respect to all areas.
If copying of all areas is completed (yes at the step 804), then the data reflection part 140 judges all areas to be in the copy completion state at step 805, and causes the reflection completion notice part 143 to notify the data reflection completion detection part 209 in the disk mapping processing part 101a of the data reflection completion state. Since copying is completed, the data reflection part 140 deletes places of the corresponding pair in the data reflection management table 1200 retained by the storage subsystem 130, and deletes the corresponding reflection information table 1000.
In this way, according to the deployment system DS in the first embodiment, the disk mapping processing part 101a changes over the access destination to either the master data volume 131 or the target server volume 133 according to the classification (read/write) of the I/O request. As a result, the disk mapping processing part 101a regards the deployment as completed (regards the state as the state where the boot can be started) without waiting for copy completion of the OS image for the target server 102. Therefore, the target server 102 can start the boot processing instantaneously. Furthermore, since it is not necessary to generate a replica of the OS image beforehand, the disk capacity can be reduced and the utilization efficiency of resources can be raised. In other words, according to the deployment system DS in the first embodiment, it is possible to shorten the time required for server construction, reduce the server construction cost, and implement flexible system operation.
Upon detecting that all data in the master data volume 131 have been copied to the target server volume 133, the disk mapping processing part 101a in the target server 102 disconnects the access path to the master data volume 131. Even if the number of target servers is large, therefore, it is possible to avoid a situation in which accesses concentrate to the master data volume 131.
In addition, copying of data in the master data volume 130 to the target server volume 133 is conducted actively in the storage subsystem 130. As a result, the copy can be completed early.
By the way, each processing in the target server 102 and the storage subsystem 130 can be implemented if a predetermined person generates and executes a program for causing the CPU in the computer to execute the processing.
If the disk mapping processing part 101a is thus provided in the virtualization mechanism, then it becomes unnecessary to provide the disk mapping processing part 101a in the logical section 13000 and it becomes possible for the hypervisor 1304 to manage I/O requests from the guest OSs operating in the logical sections 13000 collectively. In such a case, it is possible to regard virtual servers (not illustrated) operating on a plurality of logical sections 13000 provided on one physical computer 1300 as target servers, and deploy an OS image in a plurality of target servers, and it becomes possible for any target server to start the boot processing instantaneously. Since each concrete processing and effects are similar to those in the first embodiment, description of them will be omitted.
Heretofore, embodiments of the present invention have been described. They are nothing but examples for describing the present invention, and the application range of the present invention is not restricted to the exemplified forms. Furthermore, any combination of the above-described embodiments may become an embodiment of the present invention. In other words, concrete configurations such as hardware and flowcharts can be changed suitable without departing from the spirit of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2007-133825 | May 2007 | JP | national |
