Techniques for booting a stateless client

A technique for booting a stateless client includes booting a virtual machine (VM) monitor on the client. The VM monitor is stored in a non-volatile memory area of a memory subsystem (of the client) and a first portion of an operating system (which does not include any state information for the operating system) is stored in the non-volatile memory area of the client. Booting of the operating system for the client is initiated and a remote storage (that stores a second portion of the operating system that includes state information for the operating system) is accessed via a communication link. Booting of the operating system for the client is completed using the second portion of the operating system.

BACKGROUND

This disclosure relates generally to booting a client and, more specifically to techniques for booting a stateless client.

2. Related Art

Small computer system interface (SCSI) standards define commands, protocols, and electrical and optical interfaces for physically connecting and transferring data between computers and peripheral devices. SCSI is most commonly used for hard disk drives and tape drives, but can connect a wide range of other devices, including scanners and compact disc (CD) drives. In computing, an Internet SCSI (iSCSI) protocol may be employed to allow clients (initiators) to send SCSI commands to SCSI storage devices (targets) at remote locations. In a typical implementation, iSCSI employs a transmission control protocol/Internet protocol (TCP/IP) suite for communication that allows two hosts to negotiate and then exchange SCSI commands using IP networks.

Generally, iSCSI is used to emulate SCSI over wide-area networks to create a storage area network (SAN). Unlike some SAN protocols, iSCSI does not require dedicated cabling and can be implemented over existing switching and IP infrastructure. Although iSCSI can communicate with arbitrary types of SCSI devices, system administrators usually use iSCSI to allow servers (such as database servers) to access disk volumes on storage arrays. iSCSI SANs are frequently employed to facilitate consolidation of storage resources across an organizational network to one or more central locations (e.g., data centers) to promote efficient storage allocation. In the context of computer storage, a SAN allows a client to use a network protocol to connect to remote storage resources, such as disks and tape drives on an IP network, for block level input/output (I/O).

From the point of view of class drivers and application software, SAN storage resources appear as locally attached storage devices. In general, employing an iSCSI boot facilitates localization and containment of hard disk drive (HDD) errors at a remote storage location (as diskless clients do not utilize local HDDs for booting), as well as the consolidation and streamlining of information technology (IT) management. Moreover, stateless clients may be readily reconfigured by booting the clients from different OS boot volumes, as needed.

In computing, a hypervisor (virtual machine monitor) is a virtualization platform that is typically utilized to execute multiple operating systems (OSs) simultaneously on a single computer system (client). Hypervisors are generally classified as a type 1 (native or bare-metal) hypervisor (which is software that runs directly on a given hardware platform, as an OS control program) that is a guest OS that runs at a second level above the hardware or a type 2 (hosted) hypervisor (which is software that runs within an OS environment) that is a guest OS that runs at a third level above the hardware.

SUMMARY

According to one or more embodiments of the present invention, a technique for booting a stateless client includes booting a virtual machine (VM) monitor on the client. Booting of an operating system (OS) for the client is initiated (using a first portion of the OS that is stored on the client) and a remote storage (that stores a second portion of the OS that includes state information for the OS) is accessed via a communication link. The VM monitor is stored in a non-volatile memory area (e.g., a first non-volatile memory) of a memory subsystem of the client and the first portion of the OS (which does not include any state information for the OS) is stored in the non-volatile memory area (e.g., in the first non-volatile memory or a second non-volatile memory) of the client. Booting of the OS for the client is completed using the second portion of the OS. In this case, the VM monitor functions as a control program for the OS.

DETAILED DESCRIPTION

Computer program code for carrying out operations of the present invention may be written in an object oriented programming language, such as Java, Smalltalk, C++, etc. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a single processor, on multiple processors that may be remote from each other, or as a stand-alone software package. When multiple processors are employed, one processor may be connected to another processor through a local area network (LAN) or a wide area network (WAN), or the connection may be, for example, through the Internet using an Internet service provider (ISP).

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. As used herein, the term “coupled” includes both a direct electrical connection between blocks or components and an indirect electrical connection between blocks or components achieved using one or more intervening blocks or components.

According to various aspects of the present disclosure, techniques are employed that shorten a time associated with booting a stateless client computer system (e.g., a diskless client). As used herein, the term “stateless” refers to operating system (OS) states and not to other states such as basic input/output system (BIOS) settings, etc. As is also used herein, a stateless client includes a client that does not include a hard disk drive (HDD) and a client that includes an HDD that is not utilized to boot the client or otherwise maintain user unique data related to an OS. In general, the techniques are directed to a stateless client that accesses remote storage (e.g., a storage area network (SAN)) via a communication link (e.g., an Internet connection) to retrieve information (e.g., code and data) to boot an OS and execute applications associated with the client.

As is known, maintaining applications, data, and OSs at a centralized location facilitates easier management of the applications, data, and OSs by information technology (IT) personnel of an organization. For example, should a stateless client fail, data is not lost and the stateless client can be re-booted without re-imaging an HDD of the client. Unfortunately, a boot time of a conventional stateless client may be considerably longer than a conventional client that includes an HDD that is utilized to boot the client or otherwise maintain a state for the client. Moreover, when multiple conventional stateless clients are attempting to boot from a same remote storage, boot time of the clients may be delayed.

According to various embodiments of the present disclosure, a stateless client is configured to boot a virtual machine (VM) monitor (e.g., a Xen™ hypervisor or other client hypervisor) prior to booting an OS (at least a portion of which is located on remote storage) and retrieving user data. In this case, the VM monitor functions as a control program for the OS. Following booting of the VM monitor, the stateless client initiates booting the OS by accessing a first portion of the OS, which is stored in a first non-volatile memory (e.g., a flash memory) of the stateless client and accesses the remote storage (via a communication link) to retrieve a second portion of the OS (that includes state information for the OS).

As an alternative to employing a VM monitor, a basic input/output system (BIOS) may be configured to include a network stack that facilitates accessing a network. In this case, a client OS that is modified to employ iSCSI (for accessing the remote storage) may be employed in conjunction with the BIOS. In one or more embodiments, the communication link is an internet protocol (IP) compatible communication link, e.g., an Internet small computer system interface (iSCSI) link.

According to various aspects of the present disclosure, a technique for booting a stateless client (e.g., a diskless client) includes booting a virtual machine (VM) monitor on the client. Booting of an operating system (OS) for the client is initiated (using a first portion of the OS) and a remote storage (that stores a second portion of the OS that includes state information for the client) is accessed via a communication link. The VM monitor is stored in a non-volatile memory area (e.g., within a first non-volatile memory) of a memory subsystem of the client and the first portion of the OS (which does not include any state information for the OS) is stored in the non-volatile memory area (e.g., in the first non-volatile memory, a second non-volatile memory, or another non-volatile memory) of the client. Booting of the OS for the client is completed using the second portion of the OS. In this case, the VM monitor functions as a control program for the OS.

According to another aspect of the present disclosure, a stateless client includes a memory subsystem and a processor. The memory subsystem includes a non-volatile memory area (e.g., including at least a first non-volatile memory) and the processor is coupled to the memory subsystem. The processor is configured to boot a virtual machine (VM) monitor on the client. The VM monitor is stored in the non-volatile memory area of the client. The processor is further configured to initiate booting of an operating system (OS) for the client. A first portion of the OS is stored in the non-volatile memory area (e.g., in the first non-volatile memory or a second non-volatile memory) of the client. The first portion of the OS does not include any state information for the OS. The processor is also configured to access a remote storage via a communication link. A second portion of the OS is stored in the remote storage and includes state information for the OS. Booting of the OS for the client is completed using the second portion of the OS.

According to another embodiment of the present disclosure, a technique for booting a stateless client includes initiating booting of an operating system (OS) for the stateless client using a first portion of the OS that is stored in a non-volatile memory area of a memory subsystem of the stateless client. In this case, the first portion of the OS does not include any state information for the OS. A remote storage is accessed via a communication link using a basic input/output system (BIOS) that includes a network stack for the communication link. A second portion of the OS is stored in the remote storage and includes state information for the OS. Booting of the OS for the stateless client is completed using the second portion of the OS.

With reference toFIG. 1, a relevant portion of an example computer network100is illustrated that includes a stateless client112that includes a processor102(including one or more central processing units (CPUs)) that is coupled to a memory subsystem108(which includes an application appropriate amount of volatile and non-volatile memory), an input device110(e.g., a keyboard and a mouse), and a video card104. The client112may also include a hard disk drive (HDD) (not shown) that is not utilized to boot the client112. The video card104is coupled to a display106(e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD)). The processor102may be, for example, coupled to an Internet service provider (ISP)114via a network interface card (NIC), such as an Ethernet card (not shown). The client114may be, for example, a laptop computer system, a notebook computer system, a smart phone, or a desktop computer system.

The client114may also take the form of a portable wireless device that is coupled to the Internet or an intranet via a wireless interface (e.g., IEEE 802.11). As is illustrated, the ISP114is coupled to another ISP118via a communication link116(e.g., an Internet connection). The ISP118facilitates communication between a server120(that is coupled to remote storage124) and the client112. When the computer network100corresponds to an intranet, the ISPs114and118may be omitted. While only one remote storage (e.g., a storage area network (SAN) that includes one or more solid state drives, such as magnetic media or flash memory) and one client are depicted inFIG. 1, it should be appreciated that the network100may include multiple clients and/or multiple remote storages.

Moving toFIG. 2, an example boot process200for booting a stateless client (e.g., the client112ofFIG. 1) is illustrated. To improve understanding, the process200is described in conjunction with the network100ofFIG. 1. In block202, the process200is initiated at which point control transfers to block204where the processor102boots a virtual machine (VM) monitor (e.g., a Zen™ hypervisor). Next, in decision block206, the processor determines whether verification of a first portion of an operating system (OS), which is stored in a non-volatile memory area (e.g., a flash memory) included in the memory subsystem108, is warranted. For example, the verification process may be performed every fifty times that the client112is booted. If verification is indicated, control transfers from block206to block216. In block216, the first portion of the OS is compared to an original image of the first portion of the OS that is stored on the remote storage124.

Next, in decision block218, the processor102determines whether the first portions of the OS match. When the first portions of the OS match, control transfers from block218to block208. When the first portions of the OS do not match, control transfers from block218to block220. In block220, the first portion of the OS is received (at the client112) from the remote storage124. Then in block222, the first portion of the OS (that is received from the remote storage124) is stored in the non-volatile memory area. Typically, the first portion of the OS does not include any state information or data for the OS of the client112. Following block222, control transfers to block208. Alternatively, the processor102may initially boot entirely from the remote storage124and store the first portion of the OS in the non-volatile memory area for subsequent boot operations.

In block206when verification is not required, control transfers to block208, where the processor102initiates booting (using the first portion of the OS that is stored in the non-volatile memory area) of the OS on the client112. Next, in block210, the processor102accesses the remote storage124to retrieve (e.g., using iSCSI commands) a second portion of the OS. Typically, the second portion of the OS includes information (e.g., state information and data) that is unique to the client112. It should be appreciated that if the processor102completely processes the first portion of the OS prior to receiving the second portion of the OS the processor102stalls. However, even if the processor102stalls while booting the OS, a total time associated with booting the client112is still usually less than a total time encountered when booting a stateless client configured according to the prior art. In a typical implementation, the second portion of the OS is received prior to complete execution of the first portion of the OS. Next, in block212, the processor102completes booting of the OS. Following block212, control transfers to block214where the process200terminates.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. For example, the present techniques can be implemented in virtually any kind of system. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.