Patent Application
20110126186
Generally, the present invention relates to computing devices and environments involving virtual machines. Particularly, although not exclusively, it relates to software appliances in such environments and maintaining them in situations requiring upgrades and/or patching. Other embodiments contemplate computing systems and computer program products, to name a few.
Software appliances have for sometime been positioned as a cost effective and simple way to deploy applications. As is known, software appliances are single images purpose built to run a single or a set of related applications. They are pre-configured and pre-tuned to undertake this role, which contrasts with the traditional software deployment model requiring: installing a correct operating system version based on the to-be-hosted application; configuring and tuning the operating system for optimal hosting; installing the application; and configuring and tuning the application.
In an appliance, however, all of these steps can be performed during appliance creation thereby relieving the end-user of unnecessary complexity which is typically error prone. Also, appliances can be targeted for hosting on physical hardware or as virtual machines on a virtualization host. Appliances hosted as virtual machines are becoming popular as support for virtualization becomes ubiquitous.
Notwithstanding appliance packaging addressing many of the installation, configuration and tuning issues associated with software deployment, patch management remains a significant issue requiring addressing. Unfortunately, the current state of the art treats patching/updating appliances exactly the same as patching/updating server and client machines. One problem with this relates to the granularity of patches existing at the package level, thereby bestowing responsibility of applying patches on the end-user or administrator. Also, once a set of patches are applied, the system may not function as expected because of the potential mismatch of the various software components that together constitute the system.
Another problem with the art relates to “mapping” between a software installation and a piece of hardware. In traditional data centers with N servers, administrators need to ensure N instances of operating systems being properly patched to an appropriate patch level. This one-to-one mapping persists even when the software instance is not active.
With virtualized data centers, however, patching problems are exacerbated. That is, M workloads may be concurrently executing on the N computing devices, whereby M=K*N and K is an average consolidation factor of virtual machines hosted on a server greater or equal to one. Consider here the situation in which a “L-A-M-P” appliance is instantiated to concurrently run a thousand instances on a much smaller number of servers (e.g., one hundred servers). Using the traditional maintenance model, patching/updating is required one thousand times for copies of the same image when in fact the end-user may choose to keep in persistent store only one image of the (LAMP) appliance. Additionally, there could exist an arbitrary number of workload images, P, that remain un-instantiated at any given point in time. Ultimately, system administrators need to ensure that all the workloads under management (M+P) have been appropriately patched.
In either traditional or virtualized environments, opportunities to test the efficacy of the patches remains with the end-users or administrators since they apply them. Absent feedback, this prevents the patch provider and/or appliance builder from knowing the effectiveness of the patches relative to various problems. It also further burdens the end users and administrators to communicate their feedback.
Accordingly, a need exists in the art for better appliance maintenance. The need further extends to at least the following: exploiting special attributes of appliances to simplify maintenance; avoiding treating appliances as if they are traditional non-virtualized software stacks; testing efficacy of patching; alleviating end user and administrator burdens; considering how appliance images are scalably managed in a data center, e.g., a single image being used to instantiate a large number of service instances; minimizing appliance maintenance costs; and eliminating patch-related errors. Any improvements along such lines should also contemplate good engineering practices, such as simplicity, ease of implementation, unobtrusiveness, stability, etc.
By applying the principles and teachings associated with software appliance maintenance in computing system environment, the foregoing and other problems become solved. Broadly, methods and apparatus update original appliance images with single new images in persistent storage. Only a single act of maintenance occurs instead of multiple patches for many instantiations of the same image. This keeps the appliance definition as a fixed number of bits. It also facilitates instantiation of multiple appliances from the single image.
During creation, an appliance binary of an original appliance is partitioned into kernel files, application overlay files and a configuration file. The kernel file enables booting the operating system image as a standalone “purpose built” operating environment. Once the operating environment is booted, the fully configured (and tuned) application file is overlaid to create the appliance. The virtual machine configuration file is used to spawn an appropriate virtual machine that is assigned the requested resources (as specified in the configuration file) in which the bootable OS image of the application is brought up.
Also, the kernel file is booted by an appliance owner during instantiation. An identifier of the appliance is sent back to the appliance creator to determine whether an updated operating system image exists. If so, a whole updated image is delivered back to the owner where it replaces the original image in persistent storage. Pluralities of appliances are instantiated from the updated image. If not, appliance boot sequence continues, including applying application overlay files. The overlays are obtained during appliance shutdown by taking snapshots of application-specific files and system files that the instantiated appliance may have modified during execution. Other features contemplate computing systems, executable instructions loaded on one or more computing devices for undertaking the foregoing, and computer program products available as a download or on a computer readable medium. The computer program products are available for installation on a network appliance or an individual computing device.
Certain advantages realized by embodiments of the invention include, but are not limited to: significantly simplifying appliance maintenance, including minimizing costs; maintaining appliance images, not patches; minimizing or eliminating patch-related errors; managing appliances via the operating environment; and scalable solutions that conserve network bandwidth.
These and other embodiments of the present invention will be set forth in the description which follows, and in part will become apparent to those of ordinary skill in the art by reference to the following description of the invention and referenced drawings or by practice of the invention. The claims, however, indicate the particularities of the invention.
The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:
In the following detailed description of the illustrated embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention and like numerals represent like details in the various figures. Also, it is to be understood that other embodiments may be utilized and that process, mechanical, electrical, arrangement, software and/or other changes may be made without departing from the scope of the present invention. In accordance with the present invention, methods and apparatus are hereinafter described for appliance maintenance in a computing environment with virtual machines.
With reference to
An intervening Xen, Hyper V, KVM, VmWare or other hypervisor 150, also known as a “virtual machine monitor.” or virtualization manager, serves as a virtual interface to the hardware and virtualizes the hardware. It is also the lowest and most privileged layer and performs scheduling control between the virtual machines as they task the resources of the hardware platform, e.g., memory, processor, storage, network (N) (by way of network interface cards, for example), etc. The hypervisor also manages conflicts, among other things, caused by operating system access to privileged machine instructions. The hypervisor can also be type 1 (native) or type 2 (hosted). According to various partitions, the operating systems, applications, application data, boot data, or other data, executable instructions, etc., of the machines are virtually stored on the resources of the hardware platform.
In use, the representative computing device 120 is arranged to communicate 180 with one or more other computing devices or networks. In this regard, the devices may use wired, wireless or combined connections to other devices/networks and may be direct or indirect connections. If direct, they typify connections within physical or network proximity (e.g., intranet). If indirect, they typify connections such as those found with the internet, satellites, radio transmissions, or the like. The connections may also be local area networks (LAN), wide area networks (WAN), metro area networks (MAN), etc., that are presented by way of example and not limitation. The topology is also any of a variety, such as ring, star, bridged, cascaded, meshed, or other known or hereinafter invented arrangement.
As noted earlier, software appliances packaged as virtual machines are becoming very popular and soon may become the preferred manner for deploying applications. With reference to
With this structuring of the appliance 200, there are various interesting techniques to maintain the bootable OS image as it relates to update/patch maintenance. Consider for instance a product SuSe Studio by the assignee of this invention (Novell, Inc.). SuSe Studio is a hosted service that permits independent software vendors (ISVs) to build or create appliances. Typically, these appliances are built using SLES as the appliance OS. One of the services offered with this is management of the OS. Applied to this invention, Novell can now ensure that the bootable operating system component of the appliance 200 is maintained by Novell. This will keep certain that the operating system remains current regarding all relevant patches. With reference to
In the appliance creation phase, the appliance binary is partitioned as seen in
At the appliance owner's site, the kernel file is booted for the appliance when the appliance is first instantiated, step 410. This is seen as item 1 “boot kernel” on a computing device 320 remote from the appliance creator. Once the base system comes up, it communicates back to the appliance creator using the entity handle described, item 2 and step 420. Upon receipt of the handle, the appliance builder 300 determines whether an updated whole operating system image is available for this appliance, step 430. It does this, in one instance, by comparing (330) RPM's or DLL's of the original image provided to the appliance owner against those of the current image stored at 340. If the operating system image at the appliance owner's site is current, nothing more needs to occur and the appliance boot sequence continues at step 440.
If there is an updated operating system image, on the other hand, the whole image is delivered from the customer care center of the appliance building entity, item 3, Upon receipt, this newly downloaded OS image replaces in persistent storage 350 the OS component of the application image at the customer site, step 450. Thereafter, this newly downloaded OS image 355 is used to instantiate appliances at step 460 on computing devices 320, 360. It may also do so under the guidance of an instantiation or deployment engine 370. Of course, any application overlays 375 from earlier usage of the appliances are also provided according to step 230 in
As a result, the foregoing scheme ensures that the customer always gets a fully patched bootable OS image for each appliance under management. This scheme fully automates patch management for the appliance user. Furthermore, the proposed protocol ensures that only one instance of the bootable OS image is managed by the appliance vendor even though the customer may have arbitrary number of instances of this appliance on many virtual or physical computing devices. This ensures scalability. Also, the customer can sign up for this image maintenance at the time of initial creation, thereby offloading patching responsibility from end-users and administrators of the appliance owner to the vendor. Furthermore, since the appliance creator has access to all the components of the appliance, the updated OS can be tested at the appliance creator's site before posting back the updated image for download by the customers. This avoids patching related problems at the customer site and alleviates maintenance obligations of the end users and administrators. It should be also appreciated that the foregoing eliminates pushing down of patches in lieu of pushing down images. In turn, appliances are maintained as a fixed set of bits and considers how appliance images are managed in data centers, e.g., a single image being used to instantiate a large number of service instances.
In other embodiments, skilled artisans should recognize that the foregoing schema can be applied to the application stack as well as the operating system.
In still other embodiments, skilled artisans will appreciate that enterprises can implement some or all of the foregoing with the assistance of system administrators acting on computing devices by way of executable code. In turn, methods and apparatus of the invention further contemplate computer executable instructions, e.g., code or software, as part of computer program products on readable media, e.g., disks for insertion in a drive of computing device, or available as downloads or direct use from an upstream computing device. When described in the context of such computer program products, it is denoted that items thereof, such as modules, routines, programs, objects, components, data structures, etc., perform particular tasks or implement particular abstract data types within various structures of the computing system which cause a certain function or group of function, and such are well known in the art.
The foregoing has been described in terms of specific embodiments, but one of ordinary skill in the art will recognize that additional embodiments are possible without departing from its teachings. This detailed description, therefore, and particularly the specific details of the exemplary embodiments disclosed, is given primarily for clarity of understanding, and no unnecessary limitations are to be implied, for modifications will become evident to those skilled in the art upon reading this disclosure and may be made without departing from the spirit or scope of the invention. Relatively apparent modifications, of course, include combining the various features of one or more figures with the features of one or more of the other figures.
