Patent Application
20080028034
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
Diskless computing device 110 includes, without limitation, a signature generator 112 and an iSCSI initiator 116. The signature generator 112 computes a hardware class identifier 114 (also referred to as a “signature value”) that is unique to the particular hardware configuration of diskless computing device 110. The hardware class identifier 114 has the important characteristic that an operating system boot image suitable to boot one instance of a diskless computing device having a given hardware class identifier will boot any other instance of a diskless computing device having the same hardware class identifier. The signature generator 112 is described in greater detail in the co-pending application entitled “Method to Accelerate Identification of Hardware Platform Classes,” filed on ______, 2006 and having attorney docket number NVDA/P002390.
The iSCSI initiator 116 may behave identically to the well-known behavior of a standard iSCSI initiator, with two additional behaviors. The first additional behavior is that the iSCSI initiator 116 includes the hardware class identifier 114 as a vendor-specific parameter in an iSCSI login request to the storage server 140. The second additional behavior is that the iSCSI initiator 116 transmits iSCSI login requests to a generic virtual disk with a name established to mean a “boot disk” for the purpose of booting the diskless computing device 110.
Diskless computing device 120 is constructed with the same architecture as diskless computing device 110 and includes a signature generator 122, which computes a hardware class identifier 124, and an iSCSI initiator 126 that operates identically to iSCSI initiator 116. Diskless computing device 130 also is constructed with the same architecture as diskless computing device 110 and includes a signature generator 132, which computes a hardware class identifier 134, and an iSCSI initiator 136 that operates identically to iSCSI initiator 116.
Network 160 implements a data network using any technically feasible technique. For example, network 160 may include, without limitation, hubs, switches or routers, or any combination thereof. Ethernet is an example protocol that may be used to transport iSCSI traffic over the network 160.
Storage server 140 includes storage subsystem 146 and at least one instance of an iSCSI target 142. The storage subsystem 146 implements a mass storage system using any feasible mass storage technology and presents a set of virtual disks 150, 152, 154 to the iSCSI target 142. In one embodiment, the iSCSI target 142 is a software module that executes on the storage server 140 and implements the well-known behaviors associated with an iSCSI target. In alternate embodiments, the iSCSI target 142 and the device server 144 may be implemented directly in hardware or as microcode executing on specialized hardware. The iSCSI target 142 includes a device server 144 configured to map iSCSI requests that name the generic virtual disk to a specifically selected virtual disk, as established during the iSCSI login by the hardware class identifiers included in the iSCSI login requests. This mapping forms the basis for an initiator-target ( ) nexus that is established between a given iSCSI initiator and a given virtual disk.
For example, suppose diskless computing devices 110 and 120 have identical hardware configurations and therefore share an identical hardware class identifier that maps to virtual disk 150. At some point in the boot chronology of diskless computing device 110, signature generator 112 computes a hardware class identifier 114 that is included in an iSCSI login request generated by the iSCSI initiator 116. This iSCSI login request names a generic virtual disk as the iSCSI login target. Importantly, iSCSI target 142 is configured to remap this request to the virtual disk in storage server 140 that contains the appropriate boot image for diskless computing device 110 using the hardware class identifier 114. More specifically, the iSCSI target 142 parses out the hardware class identifier 114 that is included in the iSCSI login request. This hardware class identifier 114 is then compared to a list of known hardware class identifiers, where each known hardware class identifier is paired with a specific virtual disk on storage server 140 that contains the boot image for the diskless computing device hardware class represented by the hardware class identifier. If a match is not found, then an error is reported. If a match is found, then the class identifier 114 is associated with the appropriate virtual disk, here, virtual disk 150. The iSCSI target 142 is further configured to associated the iSCSI login request from iSCSI initiator 116 with virtual disk 150. The device server 144 records the association and maps future requests from the iSCSI initiator 116 to the virtual disk 150.
Since diskless computing device 120 has a hardware class identifier 124 equal to the hardware class identifier 114, the iSCSI login process for diskless computing device 120 follows the iSCSI login process for diskless computing device 110. In both cases the iSCSI initiators 116 and 126 request an iSCSI login to a generic virtual disk. In both cases, the iSCSI login request to the generic virtual disk results in an initiator-target nexus involving the virtual disk 150.
Suppose further that the hardware class identifier 134 of diskless computing device 130 has a value associated with virtual disk 152 and is thus different from hardware class identifiers 114 and 124. The iSCSI login process for diskless computing device 130 generally follows the iSCSI login process for diskless computing device 110. However, the resulting initiator-target nexus involves virtual disk 152 as opposed to virtual disk 150. In this example, virtual disk 154 has no corresponding diskless computing device. However, a diskless computing device may be added to the storage client-server system 100 that utilizes virtual disk 154.
The method for associating a diskless computing device with a specific virtual disk begins in step 210, where an iSCSI target 142 residing within the storage server 140 receives an iSCSI login request from an iSCSI initiator residing in a diskless computing device that is a client of the storage server 140. As previously described herein, the iSCSI login request includes a hardware class identifier that uniquely identifies the hardware platform of the diskless computing device. In step 212, the iSCSI target 142 parses out the hardware class identifier from the vendor specific parameters included in the iSCSI login request. In step 214, the iSCSI target 142 attempts to match the hardware class identifier with a known set of hardware class identifiers. In step 216, if no match is available then the storage server 140 does not have a virtual disk residing in the storage subsystem 146 that contains the appropriate boot image for the diskless computing device, and the method terminates in step 218, where an error is reported.
If, in step 216, a matching hardware class identifier is found, then the method proceeds to step 220, where the iSCSI target 142 establishes an initiator-target nexus between the iSCSI initiator and the virtual disk paired with the hardware class identifier. This virtual disk contains the appropriate boot image for the diskless computing device. The method then terminates in step 222.
In sum, by incorporating a hardware class identifier in the iSCSI login process, the association between a diskless computing device with a particular hardware configuration and an appropriate virtual disk containing the boot image tailored for that hardware configuration may be established automatically. As described herein, the diskless computing device generates the hardware class identifier, based on an autonomous, internal hardware discovery process. This hardware class identifier is included as a vendor-specific parameter in an iSCSI login request to the storage server, with a generic boot disk named as the iSCSI login target. The iSCSI target residing in the storage server uses the hardware class identifier to map the iSCSI login request to a virtual disk that contains the boot image that is appropriate for the specific hardware class of the client diskless computing device. Thus, each diskless computing device, regardless of hardware configuration, is capable of booting from a server, with no related manual configuration.
While the forgoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
