Operating system installation mechanism

A system to facilitate operating system (OS) installation is described. The system includes a server and rack controller, including one or more processors to generate an imaging service comprising an OS image container, transmit data via a first network to initiate a boot up process at a server and download an OS image included in the OS image container via a second network, wherein the second network is separate from the first network.

BACKGROUND

An operating system (OS) image comprises a file or set of files that contain OS executable code, and data files that are to be deployed to one or more computing systems, such as servers. Deployment of an OS image to servers within a data center is typically performed by an imaging service that provisions the servers with compatible OS images.

DETAILED DESCRIPTION

Data centers typically employ image services to provision computing resources (e.g., servers) with OS images. Typically, the image services are provided by a computing device coupled to the data center servers via a multi-drop network. Thus, each server receives an OS image via the same network. Such an install environment is insecure since each deployed OS image is accessible by each device coupled to the network.

In embodiments, an OS image environment is provided. In such embodiments, a one-time image service is generated to provision a particular server with an OS image via a one-to one secure network connection. In further embodiments, an image service comprises an OS imaging service container. In yet further embodiments, the image service is generated in response to receiving a request to provision a server with a selected OS image. Subsequently, the server accesses and downloads the contents of the OS imaging service container. In still a further embodiment, the image service is removed (or deleted) once the server has been provisioned.

Throughout this document, terms like “logic”, “component”, “module”, “engine”, “model”, and the like, may be referenced interchangeably and include, by way of example, software, hardware, and/or any combination of software and hardware, such as firmware. Further, any use of a particular brand, word, term, phrase, name, and/or acronym, should not be read to limit embodiments to software or devices that carry that label in products or in literature external to this document.

It is contemplated that any number and type of components may be added to and/or removed to facilitate various embodiments including adding, removing, and/or enhancing certain features. For brevity, clarity, and ease of understanding, many of the standard and/or known components, such as those of a computing device, are not shown or discussed here. It is contemplated that embodiments, as described herein, are not limited to any particular technology, topology, system, architecture, and/or standard and are dynamic enough to adopt and adapt to any future changes.

FIG. 1illustrates one embodiment of a data center100. As shown inFIG. 1, data center100includes one or more computing devices101that may be server computers serving as a host for data center100. In embodiments, computing device101may include (without limitation) server computers (e.g., cloud server computers, etc.), desktop computers, cluster-based computers, set-top boxes (e.g., Internet-based cable television set-top boxes, etc.), etc. Computing device101includes an operating system (“OS”)106serving as an interface between one or more hardware/physical resources of computing device101and one or more client devices, not shown. Computing device101further includes processor(s)102, memory104, input/output (“I/O”) sources108, such as touchscreens, touch panels, touch pads, virtual or regular keyboards, virtual or regular mice, etc.

In one embodiment, computing device101includes a server computer that may be further in communication with one or more databases or storage repositories, which may be located locally or remotely over one or more networks (e.g., cloud network, Internet, proximity network, intranet, Internet of Things (“IoT”), Cloud of Things (“CoT”), etc.). Computing device101may be in communication with any number and type of other computing devices via one or more networks.

According to one embodiment, computing device101implements a virtualization infrastructure110to provide virtualization of a plurality of host resources (or virtualization hosts) included within data center100. In one embodiment, virtualization infrastructure110is implemented via a virtualized data center platform (including, e.g., a hypervisor), such as VMware vSphere or Linux Kernel-based Virtual Machine. However other embodiments may implement different types of virtualized data center platforms. Computing device101also facilitates operation of a network switching fabric. In one embodiment, the network switching fabric is a software-defined transport fabric that provides connectivity between the host resources within virtualization infrastructure110.

According to one embodiment, the network switching fabric comprises physical infrastructure devices included a plurality of racks. Typically, a rack includes a metal frame to provide standardized structure to mount various rack devices, for example, servers, modems, storage systems, routers, and other equipment, such as power, cooling, and cable management resources, among others. Rack servers typically need to be provisioned with an OS prior to initiation. Accordingly, one or more controllers140are provided to provision OS images to rack servers within data center100.

In one embodiment, a controller140generates a separate imaging service to provision a server. In such an embodiment, the imaging service comprises a container including an OS image (or OS image container). A defined herein, an OS image container comprises a standard unit of software that packages an OS image and all dependencies to enable an OS to operate from one computing environment to another. In a further embodiment, the imaging service (or imaging service container) is an isolated install environment implemented to provision a single server with an OS. Thus, the imaging service container provides a one-to one environment that enables transmission of container contents directly to a server via an isolated (e.g., secure) network connection.

FIG. 2is a block diagram illustrating one embodiment of an OS image install environment200. As shown inFIG. 2, environment200includes controller140coupled to a portal210via a network205and a server280via networks225and255. According to one embodiment, controller140includes an interface201to facilitate coupling to portal210via network205, where network205may comprise the Internet. In such an embodiment, portal210is implemented to generate and transmit OS image containers to controller140via network205and interface201. In a further embodiment, portal210may transmit OS images to controller140, where the OS image containers may be subsequently generated. In one embodiment, an operator at portal210may register the OS image containers with image controller140.

In a further embodiment, controller140and server280are included in the same rack. In such an embodiment, controller140comprises a rack controller that manages the various devices in the rack, including server280. Thus, controller140may implement existing interfaces with server280without having to provide additional resources.

FIG. 3illustrates one embodiment of controller140including an imaging service310, image cache320and container driver330. As mentioned above, imaging service310comprises a container that is used to provision an OS image (e.g., create an instance of an OS) at server280. Image cache320is implemented to store registered OS image containers that may be selected to be implemented in imaging service310. According to one embodiment, container driver330is implemented to generate an image service310. In such an embodiment, container driver330generates an imaging service310by selecting an OS image container and setting up the OS image containers as an imaging service310to provision a server280. In a further embodiment, container driver330implements OS level virtualization to set up the imaging service310. In some embodiments, container driver330may be implemented via Docker software. However in other embodiments, container driver330may be implemented using different virtualization software products (e.g., a virtual machine, Kubernetes, etc.).

In one embodiment, imaging service310includes all software, configuration files, libraries and metadata needed to provision an OS image at server280. In this embodiment, the metadata may comprise information including image file size, file signatures, OS version, how the OS is to be used, types of servers on which the OS operates, etc. In a further embodiment, the metadata may indicate one or more server types with which a particular OS image may be compatible. Thus, the metadata is used to determine which OS image may be applied to which server. Additionally, container driver330performs an integrity verification on a selected OS image container prior to setting up the container as imaging service310. For example, a checksum or hashing operation is performed on the contents of the OS image container to verify that the container has not been tampered with.

Referring back toFIG. 2, controller140is also coupled to server280via a second network225. In one embodiment, controller140includes an interface221coupled to network225. Referring back toFIG. 3, controller140includes a file server340implemented to transmit the contents of imaging service310(e.g., OS image, configuration files, metadata, etc.) to server280via network225for provisioning the include OS at server280. According to one embodiment, server280also includes an interface281(e.g., network interface card (NIC)) coupled to network225to receive imaging service310contents from file server340. In one embodiment, server280establishes a secure link (e.g., a virtual local area network (VLAN) over network225to transfer data from imaging service310. Thus, network225comprises an isolated network between controller and server280.

Referring again toFIG. 2, controller140further comprises an interface251coupled to a baseboard management controller (BMC)221at server280via a third network255(e.g., a management network). BMC221comprises a management interface that enables configuration of boot mode at server280, as well as and powering on/off and booting of server by controller140via network255. According to one embodiment, network interfaces201,221and251may implemented via hardware (e.g., NIC) or via software.

Referring back toFIG. 3, controller140includes a BMC driver350to initiate a boot up process (e.g., e.g., via a Prehoot eXecution Environment (PXE), such as Unified Extensible Firmware Interface (UEIPI) standard) at server280via network255. Additionally, BMC driver350is implemented to power on server280via network255. As a result, BMC221is configured to perform power on and boot operations initiated by BMC driver350.

According to one embodiment, controller140facilitates the provisioning of an OS image by generating an imaging service310instance (or imaging service container) specifically to provision server280. In such an embodiment, container driver330generates the imaging service container in response to a selection of an OS image compatible with the server280that is to be provisioned. Subsequently, BMC driver350sets up a server280boot using a transmission (e.g., via a PXE/UEFI boot HyperText Transfer Protocol (HTTP)) to BMC221via network255.

In one embodiment, the transmission includes information identifying the imaging service container (e.g., a unique identifier), as well as Transport Layer Security (TLS) certificates to be used to establish a secure communication link. Additionally, the transmission includes an installer service kernel (or installer). After the HTTP transmission, BMC driver350powers on server280using BMC221.

Once powered, server280executes the installer to initiate OS provisioning and installation.FIG. 4is a flow diagram illustrating one embodiment of a provisioning process performed by the installer. At processing block410, a secure communication link (e.g., VLAN) is established with file server340using the received TLS certificates. At processing block420, the hardware compatibility of server280is verified against the OS image included in the imaging service container. In one embodiment, the verification is performed using the container metadata.

At processing block430, the server280disk drive is set up for boot. In one embodiment, the server disk set up includes creating disk volumes and installing a boot loader package (e.g., GNU GRand Unified Bootloader (GRUB)). At processing block440, the imaging service container is accessed via the secure communication link. At processing block450, the OS is installed at server280. In one embodiment, the OS is installed by downloading the contents (e.g., OS image, configuration file, etc.) from the imaging service container and writing to the disk drive.

FIG. 5is a flow diagram illustrating one embodiment of a method performed by controller140. At processing block510, a request for an OS install at a server is received. At processing block520, an imaging service container is generated. As discussed above, the imaging service container may comprise an OS image container selected from a plurality of stored OS image containers compatible with the server. At processing block530, a boot is set at the server by transmitting data via a BMC network. As discussed above the transmitted data includes an identifier for the imaging service container and TLS credentials. At processing block540, the server is powered up. Subsequently, the server accesses the imaging service container via a secure VLAN and downloads the contents of the imaging service container for provisioning. At processing block550, the imaging service reports that the downloading of the container contents has been completed. At processing block560, the imaging service container is deleted from the install environment.

The above-described install environment enables the provisioning of servers via secure, one to one communication with imaging service containers. Thus, multiple servers may be simultaneously provisioned via different imaging service containers on separate communication links. For example, each server within a rack may be simultaneously provisioned via separate, isolated VLANs between the controller and a server.

Embodiments may be implemented as any or a combination of one or more microchips or integrated circuits interconnected using a parent board, hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA). The term “logic” may include, by way of example, software or hardware and/or combinations of software and hardware.