CN107810475A - Method and apparatus for the software life cycle management of virtual computation environmental - Google Patents

Abstract

The method and apparatus for disclosing the software life cycle management for virtual computation environmental.A kind of exemplary method includes determining multiple software upgradings on the physical computing resources in virtual server machine frame system (102) to be arranged on by using processor (912) execute instruction, it is described to determine based on the inventory file received from the software manager associated with the virtual server machine frame system (102), the dependent request of the software upgrading for being identified in inventory file is determined by using processor (912) execute instruction, the order for meeting dependent request of installation software upgrading is determined by using processor (912) execute instruction, and it is arranged in the installation of the software upgrading identified in inventory file by using processor (912) execute instruction.

Description

Method and apparatus for software lifecycle management in a virtual computing environment

related application

Indian Provisional Patent Application Serial No. 3344/CHE/2015 filed June 30, 2015, U.S. Patent Application Serial No. 15/187,452 and Serial No. 15/187,480 both filed June 20, 2016 The U.S. Patent Application for is hereby incorporated by reference in its entirety.

technical field

The present disclosure relates generally to virtual computing environments, and more particularly, to methods and apparatus for software lifecycle management of virtual computing environments.

Background technique

Virtualizing a computer system provides advantages such as the ability to execute multiple computer systems on a single hardware computer, duplicate a computer system, move a computer system between multiple hardware computers, and the like. EXAMPLE SYSTEM FOR VIRTUALIZING COMPUTER SYSTEMS US Patent Application entitled "METHOD AND SYSTEM FOR MANAGING VIRTUAL AND REAL MACHINES" filed September 21, 2007 11/903,374, and U.S. Patent No. 8,171,485, filed March 26, 2007, entitled "METHOD AND SYSTEM FOR MANAGING VIRTUAL AND REALMACHINES" Provisional Patent Application No. 60/919,965, and U.S. Provisional Patent Application No. 61/736,422, entitled "METHODS AND APPARATUS FOR VIRTUALIZED COMPUTING," filed December 12, 2012 As described, all three patent applications are hereby incorporated by reference in their entirety.

"Infrastructure as a Service" (also commonly referred to as "IaaS") generally describes a set of technologies offered by a service provider as a holistic solution. Enterprises can use IaaS as an in-house organizational cloud computing platform (sometimes referred to as a "private cloud") that enables application developers to access infrastructure resources such as virtual servers, storage, and network resources. By providing instant access to the hardware resources needed to run applications, cloud computing platforms enable developers to build, deploy and manage web applications (or any other type of networked application) at a greater scale and faster than ever before program) life cycle.

A cloud computing environment may consist of many processing units (eg, servers). Processing units may be mounted in standardized frames called racks, which provide efficient use of floor space by allowing processing units to be stacked vertically. The racks may additionally include other components of the cloud computing environment, such as storage devices, networking devices (eg, switches), and the like.

Description of drawings

1A is a block diagram of an example environment in which physical racks are prepared by an example system integrator for distribution to customers.

FIG. 1B is a block diagram of an example environment in which an example physical rack is deployed at an example customer premises.

Figure 2 depicts an example physical rack in an example virtual server rack deployment.

3 is a block diagram of an example implementation of the software manager of FIGS. 1A and/or IB.

4 is a block diagram of an example implementation of the example lifecycle manager of FIG. 2 .

5 is a flow diagram representing example machine readable instructions that may be executed to implement the example software manager of FIGS. 1A , 1B and/or 3 .

6-8 are flowcharts representative of machine readable instructions that may be executed to implement the example lifecycle manager of FIGS. 2 and/or 4 .

9 is a block diagram of an example processing platform capable of executing the example machine-readable instructions of FIG. 5 to implement the example software manager of FIGS. 1A , 1B, and/or 3 .

10 is a block diagram of an example processing platform capable of executing the example machine-readable instructions of FIGS. 6-8 to implement the example lifecycle manager of FIGS. 2 and/or 4 .

Detailed ways

Cloud computing is based on the deployment of many physical resources across a network, the virtualization of physical resources into virtual resources, and the provisioning of virtual resources for cross-cloud computing services and applications. When launching a cloud computing environment or adding resources to an established cloud computing environment, data center operators strive to provide cost-effective services while making the resources of the infrastructure (e.g., storage hardware, computing hardware, and networking hardware) Enables pain-free installation/operation and optimizes resources for performance. Existing techniques for building and maintaining data centers to provide cloud computing services often lock data centers into single-source hardware resources, requiring the use of custom virtualization software designed for specific types of hardware. Examples disclosed herein enable the use of vendor-agnostic virtualization software to build and maintain data centers. In this way, data center operators have the flexibility to choose any one of multiple hardware manufacturers to meet the physical hardware needs of the data center, while enabling data center operators to initialize, virtualize and provision new resources with relative ease . That is, a data center operator can use the examples disclosed herein to acquire hardware resources from any of many manufacturers without requiring the data center operator to bear the burden of developing new software to initialize, virtualize, and provision such resources .

The example methods and apparatus disclosed herein facilitate managing the software lifecycle of data center computing elements. For example, the methods and apparatus facilitate updating, patching, upgrading, etc. implementing multiple hardware elements of a computing element in a computing element cluster (e.g., a computing element may be a self-contained physical rack of multiple computing components (e.g., network switches, processing servers, storage, etc.), which can be combined with other self-contained physical racks to form a cloud or cluster of computing resources. In many computing environments, it is undesirable to interrupt, interfere with, etc., the operation of the computing environment (for example, the computing environment may run 24 hours a day hours, and there may be no natural downtime during which the system may be offline for maintenance). Example methods and apparatus assist in scheduling and performing tasks such as updates, patching, upgrades, etc., by utilizing redundant and/or offline/standby computing resources , to reduce and/or eliminate the impact on the operating computing environment.

FIG. 1A depicts an example environment 100 in which physical racks 102 are prepared by an example system integrator 104 for distribution to customers. FIG. 1B depicts an example environment 117 in which an example physical rack 102 is deployed at an example client 118 .

The example environment 100 of FIG. 1 includes an example physical rack 102 , an example system integrator 104 , one or more example hardware/software vendors 106 , an example network 108 , an example virtual system solution provider 110 , and an example virtual imaging device 112 .

The system integrator 104 of the illustrated example receives and fulfills customer orders for computing hardware. The system integrator 104 of the example of FIG. 1A obtains computer hardware and/or software from other suppliers, such as one or more example hardware/software suppliers 106, and assembles the individual hardware components and/or software into functional computing units to Fulfill customer orders. Optionally, system integrator 104 may design and/or build some or all of the hardware components and/or software used to assemble the computing unit. According to the illustrated example, system integrator 104 prepares computing units for other entities (eg, businesses and/or individuals not owned/employed by and not owned/employed by system integrator 104 ). Alternatively, system integrator 104 may assemble computing units for use by the same entity as system integrator 104 (eg, system integrator 104 may be a division of a company that orders and/or utilizes assembled computing units). As used herein, the term “customer” refers to any individual and/or entity that receives and/or operates a computing unit provided by the system integrator 104 . In some examples, system integrator 104 is an entity independent of a device manufacturer, such as a white label device manufacturer that provides unbranded hardware. In other examples, the system integrator 104 is an original equipment manufacturer (OEM) partner or an original equipment manufacturer (ODM) partner that works with an OEM or ODM (e.g., a non-white label equipment manufacturer) that provides branded label hardware. Cooperation. Exemplary OEM/ODM hardware includes OEM/ODM servers such as Hewlett- (HP) servers and servers), and OEM/ODM switches (such as Arista switches) and/or any other OEM/ODM servers, switches or equipment marked by the original manufacturer.

According to the illustrated example, one type of computing unit ordered and/or assembled by an example system integrator 104 is a physical rack 102 . Physical rack 102 is a combination of computing hardware and installed software that can be utilized by customers to create and/or add to a virtual computing environment. For example, the physical rack 102 may include processing units (e.g., multiple blade servers), network switches to interconnect the processing units and connect the physical rack 102 to other computing units (e.g., other computing devices of the physical rack 102 in a network environment). units, such as cloud computing environments) and/or data storage units (eg, network-attached storage, storage area network hardware, etc.). The physical rack 102 of the illustrated example is prepared by the system integrator 104 in a partially configured state to enable rapid deployment of computing equipment at a customer location (eg, in less than 2 hours). For example, system integrator 104 may install operating systems, drivers, operating software, management software, and the like. The installed components may be configured with some system details (e.g., system details that facilitate intercommunication between components of the physical rack 102) and/or may be equipped with software to When powering on, more information can be collected from customers.

To aid in the preparation of the physical racks 102 for distribution to customers, the example system integrator 104 utilizes a virtual imaging appliance 112 to prepare and configure operating systems, system configurations, on the physical racks 102 prior to shipping the example server racks 102 to customers. , software, etc. The illustrated example virtual imaging device 112 is a virtual computing device provided by the example virtual system solution provider 110 to the system integrator 104 via the example network 108 . The example virtual imaging device 112 is implemented by the example system integrator 104 within the system integrator's 104 virtual computing environment. For example, virtual imaging device 112 may be a virtual computing image, a virtual application, a container virtual machine image, a software application installed in an operating system of a computing unit of system integrator 104, or the like. Virtual imaging device 112 may alternatively be provided by any other entity and/or may be a physical computing device, may be multiple physical computing devices, and/or may be any combination of virtual and physical computing components.

The virtual imaging appliance 112 of the illustrated example retrieves software images and configuration data from the virtual system solution provider 110 via the network 108 during preparation of the physical rack 102 for installation on the physical rack 102 . The virtual imaging device 112 of the illustrated example pushes (eg, transmits, sends, etc.) software images and configuration data to components of the physical rack 102 . For example, the virtual imaging device 112 of the illustrated example includes multiple network connections (eg, virtual network connections, physical network connections, and/or any combination of virtual and network connections). For example, virtual imaging device 112 of the illustrated example connects to the management interface of one or more network switches installed in physical rack 102, installs network configuration information on one or more network switches, and restarts one or more switch to load the installed configuration to communicatively couple the virtual imaging device 112 with one or more computing units communicatively coupled via one or more network switches. The example virtual imaging device 112 is also connected to a management network interface (e.g., an out-of-band (OOB) interface) of one or more servers installed in the example physical rack 102 to enable one or more operating systems to be installed (e.g., using Preboot Execution Environment (PXE) boot of the operating system installer). The example virtual imaging appliance 112 is also used to install virtual environment management components (described in further detail below in conjunction with FIGS. 3-6 ) and to cause the virtual environment management components to start up so that they can take over deployment of the example server rack 102 .

The example virtual imaging device 112 is configured to perform many of the operations of the deployment without user intervention and without requiring users of the example system integrator 104 to manually connect to the various interfaces of the components of the example physical rack 102 . Furthermore, the user of the example virtual imaging device 112 is relieved of the burden of locating the various software images needed to configure the example physical rack 102 (e.g., firmware images for one or more network switches, operating system images for one or more servers, One or more operating system drivers for hardware components installed in the physical rack 102, etc.). Additionally, the virtual environment management components deployed by the example virtual imaging appliance 112 are configured by the virtual imaging appliance 112 to facilitate easy deployment of the physical racks 102 at customer locations. For example, the virtual management component installed on the physical rack 102 by the example virtual imaging appliance 112 includes a graphical user interface that guides the customer through the process of entering configuration parameters (e.g., details of the customer network, information about the existing virtual environment, etc. ). In addition, the example virtual management component automatically discovers some information about the guest system (eg, automatically discovers information about existing virtual environments).

The illustrated example network 108 communicatively couples an example system integrator 104 with a virtual system solution provider 110 and communicatively couples an example hardware/software provider 106 with an example virtual system solution provider 110 . According to the example shown, network 108 is the Internet. Optionally, network 108 may be any type of local area network, wide area network, wireless network, wired network, any combination of networks, or the like. Although network 108 of FIG. 1A is shown as a single network, the network may be any number and/or type of networks. For example, the network 108 may be implemented by one or more of a local area network, a wide area network, a wireless network, a wired network, a virtual network, and the like.

Referring to FIG. 1B , an example client 118 is where an example physical rack 102 (eg, multiple physical racks 102 are deployed) resides. For example, client 118 may be a data center, a cloud provider's location, a business location, or any other location where it is desired to implement a virtual computing environment consisting of one or more physical racks 102 . According to the illustrated example, the example client 118 (and the example physical rack 102 located at the example client 118) are communicatively coupled to the example network 108 to connect the example client 118 with the example virtual system solution provider 110. communicatively coupled.

The illustrated example virtual system solutions provider 110 distributes (eg, sells) and/or supports the example virtual imaging device 112 . The virtual system solution provider 110 of the illustrated example also provides a repository 116 of images and/or other types of software (e.g., virtual machine images, drivers, operating systems, etc.) that can be retrieved by A) the virtual imaging device 112 and Installed on the physical rack 102 and/or B) retrievable by the example physical rack 102 after the example physical rack 102 is deployed at the example client 118 (as shown in FIG. 1B ). Virtual system solution provider 110 is optionally implemented by multiple entities (eg, from one or more manufacturers of software) and/or any other type of entity.

The example virtual system solution provider 110 of the illustrated example of FIGS. 1A and 1B includes an example software manager 114 and an example repository 116 . The example software manager 114 and the example repository 116 together provide software to A) the example virtual imaging device 112 of FIG. One or more example physical racks 102 at an example client 118 for updating, upgrading, patching, etc. computing resources included in the one or more example physical racks 102 .

The example software manager 114 receives software from one or more example hardware/software vendors 106 and stores data in an example repository 116 . The software may include new and/or updated drivers, operating systems, firmware, etc. for the computing resources included in the example physical rack 102 . For example, software may include firmware/operating system for a network switch installed in physical rack 102, a hypervisor for execution on server hardware installed in physical rack 102, Drivers for storage devices in the storage device, security updates for operating systems installed in the computing environment provided by the physical rack 102, and the like.

The example software manager 114 receives a request for a rackmount image from the example virtual imaging device 112, retrieves the requested one or more images, and transmits the requested one or more images to the example virtual imaging device 112 via the network 108 , to assist in installing one or more images on the example physical rack 102 via the example virtual imaging device 112 . The example software manager 114 may additionally provide one or more updated images to the example virtual imaging device 112 after receiving updated software from the one or more example hardware/software vendors 106 . For example, the example virtual imaging device 112 may periodically send requests for updated one or more images and/or the example software manager 114 may notify the example virtual imaging device 112 when an updated image is ready (e.g., at After the new software has been received, tested, and added to the new mirror).

The example software manager 114 also receives requests from the example physical racks 102 to update software after the example physical racks 102 have been deployed on the example clients 118 . For example, when example physical racks 102 are deployed at example clients 118 as part of a cluster of physical racks 102, one of physical racks 102 may periodically send requests for updated software packages (e.g., including A set of software associated with a plurality of computing resources installed in the example physical rack 102). In response to such a request, the example software manager 114 retrieves a manifest file that includes the version of the software package so that the physical rack 102 can determine whether the software package includes software that is currently installed on the computing resources of the example physical rack 102. New, updated, improved, etc. software. For example, if the manifest file identifies a newer version than the version of the software package currently installed on the example physical rack 102, then the software package includes new software (e.g., a network switch that has been selected for installation in the example physical rack 102). new firmware on the ). In some instances, virtual system solution provider 110 may support multiple different physical rack implementations (eg, different combinations of computing resources and/or software installed in example physical rack 102 ). In such cases, the manifest file may additionally include identifiers for the particular combination of components in the example physical rack 102 . For example, the manifest file may identify a stock keeping unit (SKU) associated with an example physical rack 102 to allow the physical rack 102 to confirm that the received manifest file identifies software for the particular physical rack 102 .

An example implementation of the example software manager 114 is described in connection with FIG. 3 .

The example repository 116 stores software received from one or more example hardware/software vendors 106 , as well as manifest files generated by the example software manager 114 for the example software. Repository 116 of the example shown is communicatively coupled with example software manager 114 to allow example software manager 114 to store and retrieve software. An example repository 116 is a database. Alternatively, the example repository may be any other type of storage, such as network-attached storage, hard drive, shared network drive, file, folder, or the like.

FIG. 2 depicts example physical racks 202 , 204 in an example deployment of virtual server racks 206 . For example, physical racks 202, 204 may be physical racks in physical racks 102 assembled by example system integrator 104 of FIG. 1A. In the example shown, a first physical rack 202 has an example top of rack (ToR) switch A 210 , an example ToR switch B 212 , an example management switch 207 , and an example server host node ( 0 ) 209 . In the example shown, a management switch 207 and a server host node ( 0 ) 209 run a hardware management system (HMS) 208 for the first physical rack 202 . The example second physical rack 204 shown also has an example ToR switch A 216 , an example ToR switch B 218 , an example management switch 213 , and an example server host node (0) 211 . In the example shown, management switch 213 and server host node (0) 211 run HMS 214 for second physical rack 204 .

In the example shown, the management switch 207 , 213 of the respective physical rack 202 , 204 runs a respective out-of-band (OOB) agent and OOB plugin of the respective HMS 208 , 214 . Furthermore, in the example shown, the server host nodes (0) 209, 211 of the respective physical racks 202, 204 run respective IB agents, IB plugins, HMS service APIs and aggregators.

In the example shown, the HMS 208, 214 is connected to a server management port of a server host node (0) 209, 211 (e.g., using a baseboard management controller (BMC)), to a The ToR switch management port (eg, using a 1 Gbps link) is also connected to the spine switch management ports of one or more spine switches 222 . These example connections form a non-routable private Internet Protocol (IP) management network for OOB management. The HMS 208, 214 of the example shown uses this OOB management interface to the server management port of the server host node (0) 209, 211 for server hardware management. Additionally, the HMS 208 , 214 of the illustrated example uses this OOB management interface to the ToR switch management ports of the ToR switches 210 , 212 , 216 , 218 and to the spine switch management ports of the one or more spine switches 222 for switch management. In the example disclosed herein, ToR switches 210, 212, 216, 218 are connected to server network interface card (NIC) ports (e.g., using 10Gbps links) of server hosts in physical racks 202, 204 for downlink communicate, and connect to one or more backbone switches (eg, using 40Gbps links) for uplink communication. In the example shown, the management switches 207, 213 are also connected to the ToR switches 210, 212, 216, 218 (e.g., using 10Gbps links) for the management switches 207, 213 and the ToR switches 210, 212, 216, 218 internal communication between. Furthermore, in the example shown, the HMS 208, 214 has IB connections to individual server nodes of the physical racks 202, 204 (eg, server nodes in the example physical hardware resources 224, 226). In the example shown, the IB connection is via the operating system running on the server node using OS-specific APIs (such as the vSphere API), command-line interface (CLI), and/or public APIs such as those from the Distributed Management Task Force (DMTF). Interfaces such as information models interface to physical hardware resources 224,226.

The HMS 208, 214 of the respective physical rack 202, 204 interfaces with the virtual rack manager (VRM) 225, 227 of the respective physical rack 202, 204 to use the physical hardware resources 224, 224, 227 of the physical rack 202, 204. 226 (eg, processors, network interface cards, servers, switches, storage devices, peripherals, power supplies, etc.) to instantiate and manage the virtual server rack 206. In the example shown, the VRM 225 of the first physical rack 202 runs on three server host nodes of the first physical rack 202 , one of which is the server host node ( 0 ) 209 . As used herein, the term "host" refers to a functionally indivisible unit of a physical hardware resource 224, 226, such as a physical server, configured or assigned to a virtual rack and/or workload as a whole; all powered on or de-energized; or can be considered a complete functional unit. Furthermore, in the example shown, the VRM 227 of the second physical rack 204 runs on three server host nodes of the second physical rack 204 , one of which is the server host node (0) 211 . In the example shown, the VRMs 225 , 227 of respective physical racks 202 , 204 communicate with each other through one or more spine switches 222 . Furthermore, in the example shown, communication between the physical hardware resources 224, 226 of the physical racks 202, 204 passes between the TOR switches 210, 212, 216, 218 of the physical racks 202, 204 through one or more Backbone switch 222 switches. In the example shown, each of the TOR switches 210 , 212 , 216 , 218 is connected to each of the two spine switches 222 . In other examples, fewer or more spine switches may be used. For example, when physical racks are added to virtual server racks 206, additional spine switches may be added.

In the examples disclosed herein, the ToR switches 210, 212, 216, 218 are managed using a command line interface (CLI) and an API. For example, the HMS 208, 214 uses the CLI/API to populate the exchange objects corresponding to the ToR switches 210, 212, 216, 218. At HMS startup, the HMS 208, 214 populates the initial exchange object with statically available information. In addition, the HMS 208, 214 uses a periodic polling mechanism as part of the HMS switch management application thread to collect statistics and health data (e.g., link status, packet statistics, availability, etc.) from the TOR switches 210, 212, 216, 218 Wait). There is also a configuration buffer as part of the switch object, which stores configuration information to be applied on the switch.

The example VRM 225 , 227 of the example shown in FIG. 2 includes an example Lifecycle Manager (LCM) 228 , 230 . The example LCM 228, 230 is responsible for requesting software from the example virtual system solution provider 110 and managing the installation of the example software. When a manifest file identifying information about a software package is received from the example virtual system solution provider 110, the example LCM 228, 230 determines whether the manifest is applicable to the example physical rack 202, 204, verifies that the software components required to install the software package The existence of dependencies (or the resolution of such dependencies) ensures that sufficient computing resources are available to install the software components of the software package, schedule the software components for installation, and perform the installation of the software components.

FIG. 4 shows an example implementation of the LCM 228 , 230 . For simplicity, the remainder of this description will refer to an example LCM 228 . However, the description and example implementations included therein also apply to the example LCM 230 .

3 is a block diagram of an example implementation of software manager 114 of 1A and/or 1B. The example software manager 114 of FIG. 3 includes an example software receiver 302 , an example package manager 304 and example repository interface 306 and an example request handler 308 .

The example software receiver 302 of the illustrated example receives software components (eg, drivers, firmware, operating systems, applications, etc.) from the example hardware/software vendor 106 and transmits the software components to the example package manager 304 . For example, software receiver 302 may receive notifications from one or more example hardware/software suppliers 106 when new software is available, and/or may periodically query one or more example hardware/software suppliers 106 for new software availability.

The example package manager 304 receives software from the example software receiver 302 , coordinates testing of the software, and adds the software to the example repository 116 after testing. When software is added to the example repository 116, the example package manager 304 adds a reference to the software to the package associated with the software to which it was added (e.g., a collection of software for a particular physical chassis version/implementation) Linked manifest file. For example, package manager 304 may add new entries to the software's manifest file, and/or may replace a previous version of the software identified in the manifest file with a new version of the software. Testing of software can be done by an administrator installing the software on a test physical rack and verifying that the software installs as expected and does not interfere with the operation of the test physical rack (e.g., does not cause errors, does not interfere with our software or hardware) conflicts, etc.) to complete. During testing of software, the example package manager 304 collects dependency information (eg, information about what software components may be required to install the software). The example package manager 304 stores dependency information in a manifest file associated with the software package to which the software is added. For example, the example package manager 304 may receive user input identifying software dependencies, may receive input files identifying software dependencies, may monitor software installations to programmatically determine software dependencies, and the like.

The example repository interface 306 interfaces with the example repository 116 . For example, repository interface 306 may be a database interface of example software manager 114 . Alternatively, repository interface 306 may be any other type of interface that assists example package manager 304 and/or example request handler 308 to store and/or be retrieved manifest files and/or software from example repository 116 .

The example request handler 308 receives a request for a software image and/or updated software package from the example virtual imaging device 112 of FIG. 1A and/or the example physical rack 102 at the example client 118 of FIG. IB. In response to the request, the example request handler 308 retrieves the requested information. For example, the request processor 308 may retrieve the manifest file and send the manifest file to the requesting source (e.g., the example virtual imaging device 112 and/or the example physical rack 102) to allow the requesting source to determine whether the manifest file identifies a physical rack 102 Associated software that is to be installed on the physical rack 102. For example, the manifest file may identify SKUs that are checked against SKUs associated with physical racks 102 . When the requesting source indicates that the manifest file identifies desired software, request handler 308 may retrieve the software (eg, software image, software package, etc.) from example repository 116 and transmit the software to the requesting source.

A flowchart illustrating example instructions for implementing the example software manager 114 of FIGS. 1A , 1B, and/or 3 is described in connection with FIG. 5 .

Although an example manner of implementing the software manager 114 of FIGS. 1A and/or 1B is shown in FIG. 3 , one or more elements, processes and/or devices shown in FIG. 3 may be combined, divided, rearranged , omitted, eliminated and/or implemented in any other way. Additionally, the example software receiver 302, example package manager 304, example repository interface 306, example request handler 308, and/or more generally example software manager 114 of FIG. 3 may be implemented by hardware, software, firmware, and/or Any combination of hardware, software and/or firmware. Thus, for example, any of the example software receiver 302, the example package manager 304, the example repository interface 306, the example request handler 308, and/or more generally the example software manager 114 of FIG. more analog or digital circuits, logic circuits, one or more programmable processors, one or more application-specific integrated circuits (ASICs), one or more programmable logic devices (PLDs), and/or one or more field Programmable logic device (FPLD) to achieve. When reading any apparatus or system claims of this patent to cover pure software and/or firmware implementations, the example software receiver 302, example package manager 304, example repository interface 306, example request handler 308 of FIG. and/or more generally exemplifying at least one of software managers 114, expressly defined herein to include a tangible computer-readable storage device or disk, such as a memory, a digital versatile disk (DVD), that stores software and/or firmware , Compact Disc (CD), Blu-ray Disc, etc. Additionally, the example software manager 114 of FIGS. 1A and/or 1B may include one or more elements, processes, and/or devices in addition to or instead of those shown in FIG. 3 , and/or may include any or all More than one of the elements, processes and devices shown is shown.

4 is a block diagram of an example implementation of the LCM 228 in the example VRM 225 of the example physical rack 202 of FIG. 2 (eg, the physical rack 102 deployed at the example client 118). The example LCM 228 includes an example package manager 402 , an example lifecycle repository 404 , an example user interface 406 , an example dependency analyzer 408 , an example capacity analyzer 410 , and an example installation coordinator 412 .

The example package manager 402 interfaces with the example software manager 114 of the example virtual system solution provider 110 of FIG. Software at rack 202. The example package manager 402 periodically polls the example software manager 114 to determine if there is an updated manifest file to be analyzed for the example physical rack 202 . Optionally, package manager 402 may receive notifications when new manifest files are available (eg, if package manager 402 has registered with virtual system solution provider 110 to receive such notifications). When package manager 402 receives a new manifest, package manager 402 determines whether the manifest applies to the physical rack, and if so, example package manager 402 notifies example user interface 406 that the new manifest has been received. If the example user interface 406 notifies the package manager 402 that the administrator has approved/scheduled the download of the software package, the example package manager 402 retrieves the software identified by the example manifest file and stores the software along with the manifest file in the example lifecycle in the repository.

The illustrated example lifecycle repository 404 stores manifest files and software received from the example virtual system solution provider 110 via the example package manager 402 . An example lifecycle repository 404 is a software database. Alternatively, lifecycle repository 404 may be implemented by any type of file and/or data storage, such as, for example, network-attached storage, hard drives, shared network drives, files, folders, and the like.

The example user interface 406 of FIG. 4 provides notifications to and receives instructions from an administrator of the physical rack 202 . For example, when the example package manager 402 notifies the example user interface 406 that a new manifest/package has been received, the example user interface 406 presents a notification to the administrator and requests information on whether the administrator wants to download the package and/or schedule the package Installed administrator input. When the example user interface 406 receives an instruction from an administrator to download a software package, the example user interface 406 notifies the example package manager 406 . When the example user interface 406 receives an instruction from an administrator to schedule installation of a software package, the example user interface 406 notifies the example dependency analyzer 408 , the example capacity analyzer 410 , and/or the example installation coordinator 412 . The example user interface 406 additionally presents any error notifications generated by the example dependency analyzer 408 , the example capacity analyzer 410 , and/or the example installation coordinator 412 .

Dependency analyzer 408 of the illustrated example receives notification from example user interface 406 that an administrator has requested installation of a software package. In response to the notification, the example dependency analyzer 408 determines the dependency requirements of the software package by analyzing the manifest file, checks the dependency requirements against the current state of the hardware and software components installed on the physical rack 202, and notifies the installation coordinator 412 The order in which the software is installed is desired and/or required by a package dependency. For example, dependency analyzer 408 may determine that version 3.0 of a driver requires version 2.0 to be currently installed, and after determining that version 1.0 is currently installed, add version 2.0 to the installation schedule. In another example, the manifest file may indicate that the web server update requires a database update also identified in the manifest file. In this case, the example dependency analyzer 408 will notify the example installation coordinator 412 that, in this example, a database update should be scheduled prior to updating the web server.

The capacity analyzer 410 of the illustrated example receives a notification from the example user interface 406 that an administrator has requested that a software package be installed. In response to the notification, the example capacity analyzer 410 retrieves the package's manifest file from the example lifecycle repository 404 . The example capacity analyzer 410 determines that the hardware and/or software computing resources of the example physical rack 202 (and possibly other physical racks 202 that are clustered) will be affected by software package installation. For example, capacity analyzer 410 determines which hardware and/or software components will need to be rebooted in order to perform the installation of a software package. Capacity analyzer 410 relates the computing resource impact to the available computing resources of the example physical rack 202 (and clusters of physical racks 202) and the operational requirements of the example physical rack 202 (e.g., indicating required computing resource availability and/or redundancy). Other Service Level Agreements) for comparison. The example capacity analyzer 410 determines whether there are sufficient computing resources to perform software installation without interfering with operational requirements. The example capacity analyzer 410 determines available computing resources by determining affected computing resources (e.g., determining workload domains that have been scheduled for updates), and querying application programming interfaces (APIs) associated with the operating environment (e.g., , query VMware server). For example, the capacity analyzer 410 may determine that there are two ToR switches 210, 212 installed in the example physical rack 202, and thus when a software installation requires a switch reboot to update the switch, one of the ToR switches 210, 212 may reboot once and not The performance of the physical rack 202 is not affected. Optionally, capacity analyzer 410 may determine that all processing resources assigned to a particular workload domain (or any other type of computing resource cluster) are in use (e.g., the workload is currently executing on all computing resources such that no computing resources can be temporarily disabled for updates). In this case, the example capacity analyzer 410 will allocate (or attempt to allocate) one or more additional computing resources (e.g., add another server to the workload domain) so that when the computing resources are updated, the work Workloads may be temporarily migrated (eg, one at a time) from computing resources in a workload domain to one or more additional computing resources. For example, after a workload is migrated from one of the computing resources, the computing resource can be moved to maintenance mode, updated, restarted, returned to operational mode. Thus, in addition to analyzing the capacity for installing software packages, the example capacity analyzer 410 facilitates the addition of capacity when needed. Capacity analyzer 410 communicates information about capacity scheduling to example installation coordinator 412 for use in scheduling installations (eg, to notify installation coordinator 412 of the availability of additional computing resources that may be used during installation).

The example installation coordinator 412 receives the information collected by the example dependency analyzer 408 and the example capacity analyzer 410 and schedules the installation of the software for the software packages identified in the received manifest. The example installation coordinator 412 schedules (or attempts to schedule) the installation of software to satisfy dependency requirements and avoid disrupting the operation of the physical rack 202 (and/or multiple physical racks 202). According to the example shown, installation coordinator 412 schedules devices for independent unavailability (eg, schedules unavailability of redundant devices such that at least one redundant device is always available). Additionally, the example installation coordinator 412 arranges for temporary moves/migration of virtual machines during installation.

A flowchart illustrating example instructions for implementing the example LCM 228 of FIGS. 2 and/or 4 is described in conjunction with FIGS. 6-8 .

Although an example manner of implementing the LCM 228 (and/or the example LCM 230) of FIG. 2 is shown in FIG. 4, one or more elements, processes, and/or devices shown in FIG. rearranged, omitted, eliminated and/or effected in any other way. Additionally, the example package manager 402, example lifecycle repository 404, example user interface 406, example dependency analyzer 408, example capacity analyzer 410, example installation coordinator 412, and/or more generally the example LCM 228 of FIG. , which may consist of one or more analog or digital circuits, logic circuits, one or more programmable processors, one or more application-specific integrated circuits (ASICs), one or more programmable logic devices (PLDs), and/or One or more field programmable logic devices (FPLD) to achieve. When reading any apparatus or system claims of this patent to cover pure software and/or firmware implementations, the example package manager 402, example lifecycle repository 404, example user interface 406, example dependency analysis of FIG. at least one of an example capacity analyzer 408, an example capacity analyzer 410, an example installation coordinator 412, and/or more generally an example LCM 228, expressly defined herein to include a tangible computer-readable storage device or storage that stores software and/or firmware discs, such as memory, digital versatile discs (DVDs), compact discs (CDs), Blu-ray discs, and the like. Additionally, the example LCM 228 of FIG. 2 may include one or more elements, processes, and/or devices in addition to or instead of those shown in FIG. 4, and/or may include any or all of the elements, processes, and /or more than one of the devices.

A flowchart representative of example machine-readable instructions for implementing the example software manager 114 of FIGS. 1A , 1B and/or 3 is shown in FIG. 5 . In this example, the machine readable instructions comprise a program executed by a processor, such as the processor 912 shown in the example processor platform 900 discussed below in connection with FIG. 5 . The program may be embodied in software stored on a tangible computer-readable storage medium, such as a CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), Blu-ray Disc, or memory associated with the processor 912, but The entire program and/or portions thereof may optionally be executed by a device other than the processor 912 and/or embodied as firmware or dedicated hardware. Furthermore, although the example program is described with reference to the flowchart shown in FIG. 5, many other methods of implementing the example software manager 114 could alternatively be used. For example, the order of execution of the blocks may be changed and/or some of the blocks described may be changed, eliminated, or combined.

As noted above, the example process of FIG. 5 may use data stored on a tangible computer-readable storage medium, such as a hard access memory (RAM)) and/or any other storage device or disk in which information is stored for any duration (e.g. for an extended period of time, permanently, transiently, temporarily buffering and/or caching information) coded instructions (e.g., computer and/or machine-readable instructions). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" are used interchangeably. Additionally or alternatively, storage on a non-transitory computer and/or machine-readable medium (e.g., hard drive, flash memory, read-only memory, compact disk, digital versatile disk, cache memory, random access memory) and and/or encoded instructions (e.g., computer and/or machine-readable instructions) on a storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, transiently, temporarily buffering and/or caching information) ) to implement the example process of Figure 5.

As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, the phrase "at least" when used as a transition word in the preamble of a claim is open-ended in the same way that the term "comprises" is open-ended.

The process of FIG. 5 begins when the example software receiver 302 of the example software manager 114 receives software from a hardware/software vendor (block 502). For example, software may include applications, drivers, operating systems, configuration files, and the like. Software may be received in a notification from a hardware/software vendor, may be received by the example software receiver 302 in response to a poll of the software vendor, and the like.

The example software receiver 302 then presents a request to include the new software in the appropriate package (block 504). For example, software receiver 302 may add an item to a task list requesting approval to add software to a package, may present a notification on a graphical user interface, and the like. The example software receiver 302 determines whether an instruction to add software to the package has been received (block 506). When an instruction not to add software to the package has been received, the example software receiver 302 discards the received software (block 508).

When instructions to add software to the package have been received (block 506), the example package manager 304 stores the software for the package (eg, stores the software in the example repository 116) (block 510). The example package manager then marks the software for testing (block 512). For example, an administrator may install software on the example physical rack 102 and/or in the example virtual server rack 206 to verify that the software operates as expected, does not interfere with other operations, etc. The example package manager 304 then determines whether an instruction to continue adding software to the package has been received after the test (block 514). When an instruction not to add the software to the package has been received (eg, because testing of the software identified a problem), the example package manager 304 discards the software (block 508 ).

When the example package manager 304 receives instructions to continue adding software to the package (block 514), the example package manager 304 captures the dependencies of the example software (block 516). Dependencies can be captured by tracking testing of the software to track which dependencies are accessed during testing, by receiving dependency records (e.g., files) identifying dependencies required by the software, by receiving user input identifying dependencies, etc. sex. According to the example shown, the dependency is captured by recording it in a manifest file to be distributed with the package comprising the software. Alternatively, dependencies may be captured in any other way (eg, stored in a database accessed to build the manifest).

The example repository interface 306 publishes the manifest file generated using the dependency information (block 518). According to the example shown, repository interface 306 stores a manifest (eg, and the software identified in the manifest) in example repository 116 of FIG. 1 to enable request handler 308 to service the request. For example, the manifest may be identified as the most current manifest (eg, replacing a previous most current manifest), such that software requests received by the example request handler 308 are serviced by transmitting the most current manifest and/or software.

According to the illustrated example, the example request handler 308 updates the virtual server rack image used by the example virtual imaging device 112 of FIG. The latest software will be used when deploying the virtual server rack (block 520).

The request processor 308 of the illustrated example determines whether a packet acceleration instruction has been received (block 522). The package acceleration directive indicates that the software package should be deployed to the virtual server rack faster than the next planned software release. For example, distribution of packages may be expedited when existing packages contain vulnerabilities that are patched by the most current package. Package acceleration instructions may be received from a user, may be identified in properties of software received by the example software receiver 302, and the like.

When the example request processor 308 determines that a packet acceleration instruction has not been received (block 522), the routine of FIG. 5 terminates. When the example request processor 308 determines that a package acceleration instruction has been received, the example request processor 308 and/or the example repository interface 306 publishes the package for accelerated publication (block 524 ). According to the illustrated example, the example request handler 308 notifies the example repository interface 306 to store in the example repository 116 an indication (eg, a flag) that the package is scheduled for accelerated publication. Thus, when the example request handler 308 receives a request from a virtual server rack (e.g., a software update request), the example request handler 308 will detect this flag and notify the requesting virtual server rack that an accelerated package is available ( For example, used to suggest that a rack of virtual servers should deploy the package, even if it is not when the release is scheduled). Then the program of Fig. 5 is terminated.

6-8 illustrate flowcharts representative of example machine-readable instructions for implementing the example lifecycle manager 228 of FIGS. 2 and/or 4 . In these examples, the machine-readable instructions comprise one or more programs executed by a processor, such as processor 1012 shown in the example processor platform 1000 discussed below in connection with FIGS. 6-8 . The program may be embodied as software stored on a tangible computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), Blu-ray disk, or memory associated with the processor 1012, but the entire Programs and/or portions thereof may optionally be executed by devices other than processor 1012 and/or embodied as firmware or dedicated hardware. Additionally, although the example programs are described with reference to the flowcharts shown in FIGS. 6-8 , many other methods of implementing the example lifecycle manager 228 may alternatively be used. For example, the order of execution of the blocks may be changed and/or some of the blocks described may be changed, eliminated, or combined.

As noted above, the example processes of FIGS. Cache, Random Access Memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g. for an extended period of time, permanently, for a short period of time, temporarily caches and/or caches information) ) coded instructions (e.g., computer and/or machine-readable instructions). As used herein, the term tangible computer-readable storage medium is expressly defined to include any type of computer-readable storage device and/or storage disk, and to exclude propagating signals and to exclude transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" are used interchangeably. Additionally or alternatively, storage on a non-transitory computer and/or machine-readable medium (e.g., hard drive, flash memory, read-only memory, compact disk, digital versatile disk, cache memory, random access memory, and/or or any other storage device or disk in which information is stored for any duration (e.g. for an extended period of time, permanently, for a brief period of time, temporarily cached and/or cached information) (for example, a computer and/or or machine readable instructions) to implement the example processes of FIGS. 6-8.

The process of FIG. 6 begins when the example package manager 402 determines whether the received manifest is new (block 602). The example package manager 402 may receive a package in a request to send a request for a new package to the example request handler 308 of the example software manager 112, which may be received from a notification sent by the example request handler 308 to the example package manager 402 list etc. The example package manager 402 may determine if the manifest is new (e.g., not previously processed), but analyze information stored in the lifecycle manager (e.g., analyze a list of processed packages, analyze version numbers to determine newly received if the version number identified in the manifest's manifest is greater than the version number of the most recently installed package, etc.). When the example package manager 402 determines that the manifest is not new, the package manager 402 discards the manifest (block 604).

When the example package manager 402 determines that the manifest is new (block 602), the example package manager 402 determines whether the manifest revokes a previously received manifest (block 606). For example, the manifest may indicate that a previously received manifest has been revoked and should be prevented from being installed and/or that software identified in the revoked manifest should be uninstalled instead of identifying new and/or updated software (block 608).

When the example package manager 402 determines that the manifest does not revoke the previous manifest (block 606), the example package manager 402 compares the identification information of the virtual server rack 206 with the identification information contained in the manifest to determine whether the manifest identifies a virtual server Rack 206 (block 610). For example, different iterations of virtual server racks using different software can be allocated. When the manifest does not match the virtual server rack 206, the example package manager 402 discards the example manifest (block 606).

When the example package manager 402 determines that the manifest matches the example virtual server rack 206 (block 610), the example user interface 406 notifies the administrator of the virtual server rack 206 that a new manifest has been received (block 612). For example, the example user interface 406 can send electronic messages to administrators, can set notifications, can add tasks to a task list, and the like. The example user interface 406 receives the download schedule from the administrator (block 614). Optionally, the download schedule may be determined automatically by analyzing the system to determine when system resources are available to download software identified in the manifest, and/or may be before, when and/or when the administrator is notified of the new manifest The download will then start automatically. Using this schedule (or automatically), the example package manager 402 downloads the software components identified in the manifest (block 616). Software components may be downloaded from the example software manager 114, from a software distributor, from a hardware manufacturer (eg, the manufacturer may distribute hardware drivers), or the like. The example package manager 402 stores the software package in the example lifecycle repository 404 (block 618). The process of Figure 6 then terminates.

7 is a flow diagram illustrating example machine readable instructions that may be executed to implement the example lifecycle manager 228 to schedule installation of downloaded software (eg, downloaded by the process shown in FIG. 6 ). The example process of FIG. 7 begins when the example user interface 406 receives an instruction to install a previously downloaded software package into the example lifecycle repository 404 (block 702 ). The example installation coordinator 412 checks the validity of the downloaded software (block 704). Validity checks may include validating signatures, fingerprints, checksums, hashes, etc. against known valid values (eg, known values published by example software manager 114 issued by a distributor of the software, etc.). Additionally or alternatively, the software may be scanned for viruses, malware, malicious behavior, and the like. Additionally or alternatively, software compatibility with the example virtual server rack 206 may be checked by analyzing the software operating on the example virtual server rack 206 and the configuration installed on the example virtual server rack 206 (e.g., in An administrator of the example virtual server rack 206 has customized the example virtual server rack 206 outside of the stock configuration implemented by the example virtual imaging appliance 112 .

The example installation coordinator 412 then determines the physical devices to be affected based on the installation instructions (block 706). A package may include software for one or more physical devices included in the physical racks 202 , 204 of the example virtual server rack 206 . For example, the package may include software for upgrading the firmware of the ToR switches A, B 210, 212, 216, 216, 218. In such an example, the example installation coordinator 412 determines that the installation of the software on the ToR switches A, B 210, 212, 216, 216, 218 will require a reboot of each of these switches.

The example dependency analyzer 408 additionally determines which software installations in the package can be performed independently (block 708). A software installation can be performed independently when it is not dependent on another software installation or a process that is not part of the installation. The example dependency analyzer 408 also analyzes the software in the package to determine which software installations are dependent on other software installations or operations (block 710). For example, dependency analyzer 408 may analyze dependency information included in a software package manifest file generated by example software manager 114 . According to the example shown, dependency analyzer 408 represents information in the ordered software inventory from blocks 708 and 710 with dependencies identified in the ordered inventory.

The example installation coordinator 412 analyzes the information collected in blocks 706-710 to generate an installation schedule for software installation in the example virtual server rack 206 (block 712). According to the example shown, installation coordinator 412 schedules installations of non-dependent installations in parallel when those installations do not affect the same physical devices. The installation coordinator 412 additionally schedules the installation of software components to ensure that required dependencies are installed before software that requires them. The example installation coordinator 412 performs the installation of the software according to the generated schedule. Alternatively, the example installation coordinator 412 may arrange for other components to perform the installation (eg, arrange for the software installation using an installation agent for the physical device on which the software is to be installed).

8 is a flow diagram illustrating example machine readable instructions that may be executed to implement the example lifecycle manager 228 to install downloaded software (eg, software installation scheduled by the example process shown in FIG. 7 ). The example process of FIG. 8 begins when the example installation coordinator 412 determines whether a requested software installation includes a request for a non-disruptive installation (block 802). For example, the example user interface 406 may receive a user request to perform a non-disruptive installation (eg, an installation that reduces or eliminates impact on users of the virtual server rack 206 by minimizing completely unavailable resources). For example, the impact on users can be eliminated by making not all redundant resources unavailable at any given time (eg, by updating and restarting ToR switches A, B 210, 212, 216, 218 once). Although non-disruptive installation reduces the impact on users, the installation process may take longer and thus may not be desired by administrators in all cases (for example, when a software patch is required to address a vulnerability or problem with a virtual server rack 206 ).

When a hitless shutdown is not requested (block 802 ), control proceeds to block 816 .

When a non-disruptive shutdown is requested (block 802), the example installation coordinator 412 attempts to schedule physical devices to be independently unavailable (eg, so that not all standby devices are unavailable at any given time). The example capacity analyzer 410 then determines computing resource requirements for executing the one or more workloads assigned to the example virtual server rack 206 (block 806 ). According to the illustrated example, capacity analyzer 410 determines one or more workload requirements by analyzing one or more service level agreements associated with the one or more workloads. Additionally or alternatively, capacity analyzer 410 may perform on-site analysis of one or more workload demands (e.g., by monitoring active, peak, average, etc. resource utilization (e.g., processor utilization, memory utilization , storage utilization, etc.)). The example capacity analyzer 410 then determines whether the installation schedule would reduce the available computing resources to meet the computing needs of one or more workloads (block 808 ). The example capacity analyzer 410 considers computing resource requirements as well as required service level agreement requirements, such as required computing resource redundancy (eg, all processing resources including a requirement for redundant processing resources).

When there are not enough computing resources to perform the installation according to the schedule and meet the computing resource requirements of the one or more workloads (block 808), the example installation coordinator 412 adds additional computing resources to the Clustering (block 812). For example, if a cluster is associated with 8 physical computing resources 224, and all 8 physical computing resources 224 are required to satisfy the demands of executing one or more workloads on the cluster, it is not possible to perform an update of the physical computing resources 224 even once Only one computing resource will be offline. Accordingly, installation coordinator 412 temporarily adds another computing resource (eg, another physical computing resource 224). Computing resources to be added to a cluster may come from a pool of unused, idle, spare, etc. computing resources, may come from another cluster, which includes more than is required to satisfy the demands of one or more workloads executing in the cluster Computing resources More computing resources.

After determining that sufficient computing resources exist (block 808 ) or adding additional computing resources (block 812 ), the example installation coordinator removes virtual computing elements from the computing resources to be updated (block 814 ). A virtual computing element may be moved to execute on another computing resource available in the cluster (eg, processing resources, storage resources, network resources, etc.) and/or another computing resource that has been added to the cluster.

After moving the virtual machine resource (block 814) or determining that a hitless shutdown was not requested (block 802), the example installation coordinator 412 installs the software package on the currently selected computing resource (block 816). According to the example shown, the installation includes any reboots required to prepare the software for execution.

After the computing resource is updated, if the virtual computing resource was moved out of the updated physical computing resource in block 814, the example installation coordinator 412 moves the virtual computing resource back to the updated physical computing resource (block 818).

The example installation coordinator 412 determines whether there are additional physical computing resources to be updated (block 820). When additional computing resources are updated, the example installation coordinator 412 selects the next physical computing resource (block 822) and control returns to block 814 (if a hitless shutdown was requested) or block 816 (if a hitless shutdown was not requested).

When there are no other computing resources to update (block 824), the example installation coordinator 412 determines whether a computing resource is added to the computing cluster (eg, if block 812 was performed) (block 824). The process of Figure 8 terminates when no additional computing resources are added to the cluster. When additional computing resources are added to the cluster, the example installation coordinator 412 returns the added computing resources to their previous state (block 826), and the process of FIG. 8 terminates. For example, installation coordinator 412 may move computing resources back to an idle state, a standby state, another cluster including excess computing resources, or the like.

FIG. 9 is a block diagram of an example processor platform 900 capable of executing the instructions of FIG. 5 to implement the software manager 114 of FIGS. 1A , 1B and/or 3 . The processor platform 900 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet computer such as an iPad ^™ ), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder , Blu-ray player, game console, personal video recorder, set-top box, or any other type of computing device.

The processor platform 900 of the illustrated example includes a processor 912 . The processor 912 of the example shown is hardware. For example, processor 912 may be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. The example processor 912 includes an example software receiver 302 , an example package manager 304 , an example repository interface 306 , and an example request handler 308 .

The processor 912 of the illustrated example includes local memory 913 (eg, a cache). The processor 912 of the illustrated example communicates with main memory including volatile memory 914 and non-volatile memory 916 via a bus 918 . Volatile memory 914 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and/or any other type of random access memory device. Non-volatile memory 916 may be implemented by flash memory and/or any other desired type of memory device. Access to main memory 914, 916 is controlled by a memory controller.

The processor platform 900 of the illustrated example also includes interface circuitry 920 . Interface circuit 920 may be implemented by any type of interface standard, such as Ethernet interface, Universal Serial Bus (USB) and/or PCI Express interface.

In the example shown, one or more input devices 922 are connected to interface circuit 920 . One or more input devices 922 allow a user to enter data and commands into processor 1012 . The one or more input devices may be implemented by, for example, audio sensors, microphones, cameras (still frame or video), keyboards, buttons, mice, touch screens, trackpads, trackballs, etc., and/or voice recognition systems.

One or more output devices 924 are also connected to the interface circuit 920 of the example shown. Output device 1024 can be implemented by, for example, a display device such as a light emitting diode (LED), organic light emitting diode (OLED), liquid crystal display, cathode ray tube display (CRT), touch screen, tactile output device, printer, and/or speakers. The interface circuit 920 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuitry 920 of the illustrated example also includes communication devices, such as transmitters, receivers, transceivers, modems, and/or network interface cards, to facilitate communication via a network 926 (e.g., Ethernet connection, Digital Subscriber Line (DSL), telephone lines, coaxial cables, cellular telephone systems, etc.) exchange data with peripheral machines (eg, computing devices of any kind).

The processor platform 900 of the illustrated example also includes one or more mass storage devices 928 for storing software and/or data. Examples of such mass storage devices 928 include floppy disk drives, hard disk drives, optical disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The encoded instructions 932 of FIG. 5 may be stored in the mass storage device 928, the volatile memory 914, the non-volatile memory 916, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

10 is a block diagram of an example processor platform 1000 capable of executing the instructions of FIGS. 6-8 to implement the lifecycle manager 228 of FIGS. 2 and/or 4 . The processor platform 1000 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet computer such as an iPad ^™ ), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder , Blu-ray player, game console, personal video recorder, set-top box, or any other type of computing device.

The processor platform 1000 of the illustrated example includes a processor 1012 . The processor 1012 of the example shown is hardware. For example, processor 1012 may be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. The example processor 1012 includes an example package manager 402 , an example user interface 406 , an example dependency analyzer 408 , an example capacity analyzer 410 , and an example installation coordinator 412 .

The processor 1012 of the illustrated example includes local memory 1013 (eg, a cache). Processor 1012 of the illustrated example communicates with main memory including volatile memory 1014 and non-volatile memory 1016 via bus 1018 . Volatile memory 1014 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and/or any other type of random access memory device. Non-volatile memory 1016 may be implemented by flash memory and/or any other desired type of memory device. Access to main memory 1014, 1016 is controlled by a memory controller.

The processor platform 1000 of the illustrated example also includes interface circuitry 1020 . Interface circuit 1020 may be implemented by any type of interface standard, such as Ethernet interface, Universal Serial Bus (USB) and/or PCI Express interface.

In the example shown, one or more input devices 1022 are connected to the interface circuit 1020 . One or more input devices 1022 allow a user to enter data and commands into processor 1012 . The one or more input devices may be implemented by, for example, audio sensors, microphones, cameras (still frame or video), keyboards, buttons, mice, touch screens, trackpads, trackballs, etc., and/or voice recognition systems.

One or more output devices 1024 are also connected to the interface circuit 1020 of the example shown. Output device 1024 can be implemented, for example, by a display device such as a light emitting diode (LED), organic light emitting diode (OLED), liquid crystal display, cathode ray tube display (CRT), touch screen, tactile output device, printer, and/or speaker. Thus, the interface circuit 1020 of the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuitry 1020 of the illustrated example also includes communication devices, such as transmitters, receivers, transceivers, modems, and/or network interface cards, to facilitate communication via the network 1026 (e.g., Ethernet connection, Digital Subscriber Line (DSL), telephone lines, coaxial cables, cellular telephone systems, etc.) to exchange data with peripheral machines (eg, any other kind of computing device).

The processor platform 1000 of the illustrated example also includes one or more mass storage devices 1028 for storing software and/or data. Examples of such mass storage devices 1028 include floppy disk drives, hard disk drives, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The encoded instructions 1032 of FIGS. 6-8 may be stored in the mass storage device 1028, the volatile memory 1014, the non-volatile memory 1016, and/or on a removable tangible computer-readable storage medium such as a CD or DVD. .

It will be appreciated from the foregoing that the methods, apparatus and articles of manufacture disclosed above facilitate updating software, firmware, patches, drivers, etc. of computing resources included in a virtual server rack architecture. In some examples, software updates are deployed to various physical computing resources included in virtual server racks while minimizing impact on the operation of those computing resources. In some examples, the lifecycle manager manages the software installation process to schedule software updates for heterogeneous computing environments to ensure that dependencies and software execution requirements are met.

Although certain example methods, apparatus, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Claims (42)

1. A method of updating the software of a virtual server rack system (102), said method comprising: A number of software updates to be installed on physical computing resources in the virtual server rack system (102) are determined by executing instructions with the processor (912), the determination being based on a relationship with the virtual server rack system ( 102) the manifest file received by the associated software manager (114); determining dependency requirements for installing the software update identified in the manifest file by executing instructions with the processor (912); determining, by executing instructions with the processor (912), an order in which dependencies are satisfied for installing the software updates; and Installation of the software update identified in the manifest file is scheduled by executing instructions with the processor (912). 2. The method of claim 1, further comprising determining that the manifest file is associated with the virtual server rack system (102). 3. The method of claim 1, wherein the dependency requirement includes an indication that installing the software update requires prior installation of the identified software version. 4. The method of claim 1, wherein determining the order of installation comprises determining an order that results in first software that is dependent on installation of second software being executed after installation of the second software. 5. The method of claim 1, further comprising identifying a device in the virtual server rack system (102) on which the software update is to be installed. 6. The method of claim 5, further comprising determining that the identified type of device will reboot after installing the software. 7. The method of claim 6, wherein determining the order of installation comprises: determining that the virtual server rack system (102) includes two or more devices of the type; and The order is determined such that at least one of the two or more devices is available during installation of the software update for the two or more devices. 8. A tangible computer-readable storage medium (932), comprising instructions that, when executed, cause a machine (900) to at least: determining a number of software updates to be installed on physical computing resources in the virtual server rack system (102), the determination being based on a manifest received from a software manager associated with the virtual server rack system (102) document; determining dependency requirements for installing said software update identified in said manifest file; determine the order in which dependencies are met for installation of said software updates; and Installation of said software update identified in said manifest file is scheduled. 9. The tangible computer readable storage medium (932) of claim 8, wherein the instructions, when executed, cause the machine (900) to determine that the manifest file is associated with the virtual server rack system (102) Associated. 10. The tangible computer-readable storage medium (932) of claim 8, wherein the dependency requirement includes an indication that installing a software update requires prior installation of the identified software version. 11. The tangible computer-readable storage medium (932) of claim 8, wherein the instructions, when executed, cause the machine (900) to determine that the order of installation includes determining that results in a second software dependent The sequence in which the installed first software is executed after the second software is installed. 12. The tangible computer readable storage medium (932) of claim 8, wherein the instructions, when executed, cause the machine (900) to identify a device in the virtual server rack system (102), the Said software update is to be installed on said virtual server rack system (102). 13. The tangible computer-readable storage medium (932) of claim 12, wherein the instructions, when executed, cause the machine (900) to determine that after the software is installed, the identified type of device will reboot . 14. The tangible computer readable storage medium (932) of claim 13, wherein the instructions, when executed, cause the machine (900) to determine the order of installation by: determining that the virtual server rack system (102) includes two or more devices of the type; and The order is determined such that at least one of the two or more devices is available during installation of the software update for the two or more devices. 15. A device (228) comprising: a package manager (402) for determining a number of software updates to be installed on physical computing resources in the virtual server rack system (102), the package manager (402) based on a manifest file received by a software manager (114) associated with the system (102) to determine the plurality of software updates; a dependency analyzer (408) for determining dependency requirements for installing the software updates identified in the manifest file, and for determining an order in which to install the software updates that satisfy the dependency requirements; and An installation coordinator (412) for scheduling installation of said software updates identified in said manifest file. 16. The apparatus (228) of claim 15, wherein the package manager (402) is further configured to determine that the manifest file is associated with the virtual server rack system (102). 17. The apparatus (228) of claim 15, wherein the dependency requirement includes an indication that installing a software update requires prior installation of the identified software version. 18. The apparatus (228) of claim 15, wherein the dependency analyzer (408) is operative to execute after installation of the second software by determining that the first software that is dependent on the installation of the second software order to determine the order of the installation. 19. The apparatus (228) of claim 15, further comprising a capacity analyzer (410) for identifying equipment in the virtual server rack system (102) on which the software update is to be performed on the virtual server Install on the rack system (102). 20. The apparatus (228) of claim 19, wherein the capacity analyzer (410) is further for determining that a device of the identified type will reboot after installation of the software. 21. The apparatus (228) of claim 20, wherein said installation coordinator (412) determines the order of said installations by: determining that the virtual server rack system (102) includes two or more devices of the type; and The order is determined such that at least one of the two or more devices is available during installation of the software update for the two or more devices. 22. A method for updating software of a virtual server rack system (102), the method comprising: determining whether sufficient computing resources are available in the virtual environment of the virtual rack system (102) for installing the software; identifying alternate computing resources available for use during installation of the software when insufficient computing resources are available in the virtual environment; adding the spare computing resource to the virtual environment; migrating workloads executing on the current computing resource to the alternate computing resource; and Installing the software on the current computing resource. 23. The method of claim 22, wherein the computing resource is a processing unit. 24. The method of claim 23, wherein adding the spare computing resources comprises adding unallocated processing units to the workload. 25. The method of claim 22, further comprising migrating the workload back to the current computing resource after installation of the software is complete. 26. The method of claim 22, further comprising determining whether a non-disruptive installation is requested. 27. The method of claim 26, wherein in response to determining that a non-disruptive installation is requested, determining whether there are sufficient computing resources in the virtual environment of the virtual rack system (102) for installing the software available. 28. The method of claim 5, further comprising, in response to determining that a non-disruptive installation is requested, arranging for the installation of the current computing resource to be completed before beginning the installation on a second computing resource of the same type as the current computing resource. 29. A tangible computer readable storage medium (932), comprising instructions that, when executed, cause a machine (900) to at least: determining whether sufficient computing resources are available in the virtual environment of the virtual rack system for installing the software; identifying alternate computing resources available for use during installation of the software when insufficient computing resources are available in the virtual environment; adding the spare computing resource to the virtual environment; migrating workloads executing on the current computing resource to the alternate computing resource; and Installing the software on the current computing resource. 30. The tangible computer-readable storage medium (932) of claim 29, wherein the computing resource comprises a processing unit. 31. The tangible computer-readable storage medium (932) of claim 30, wherein the instructions, when executed, cause the machine (900) to add the Spare computing resources. 32. The tangible computer-readable storage medium (932) of claim 29, wherein the instructions, when executed, cause the machine (900) to migrate the workload back to the Describe the current computing resources. 33. The tangible computer-readable storage medium (932) of claim 29, wherein the instructions, when executed, cause the machine (900) to determine whether a non-disruptive install is requested. 34. The tangible computer-readable storage medium (932) of claim 33, wherein the instructions, when executed, cause the machine (900) to determine, in response to determining that a non-disruptive install is requested, in the virtual rack system (102) Whether there are enough computing resources available for installing the software in the virtual environment. 35. The tangible computer-readable storage medium (932) of claim 8, wherein the instructions, when executed, cause the machine (900) to schedule an installation of the current computing resource in response to determining that a non-disruptive installation is requested is completed before installation is started on a second computing resource of the same type as the current computing resource. 36. A device (228) comprising: capacity analyzer (410) for: determining whether sufficient computing resources are available in the virtual environment of the virtual rack system (102) for installing the software; identifying alternate computing resources available for use during installation of the software when insufficient computing resources are available in the virtual environment; and install coordinator (412) for: adding the spare computing resource to the virtual environment; migrating workloads executing on the current computing resource to the alternate computing resource; and Installing the software on the current computing resource. 37. The apparatus (228) of claim 36, wherein the computing resource is a processing unit. 38. The apparatus (228) of claim 37, wherein the installation coordinator (412) is further for adding the spare computing resources by adding unallocated processing units to the workload. 39. The apparatus (228) of claim 15, wherein the installation coordinator (412) is to migrate the workload back to the current computing resource after installation of the software is complete. 40. The apparatus (228) of claim 36, wherein the installation coordinator (412) is further for determining whether a non-disruptive installation is requested. 41. The apparatus (228) of claim 40, wherein the capacity analyzer (410) is configured to determine that in the virtual environment of the virtual rack system (102) Whether sufficient computing resources are available to install the software. 42. The apparatus (228) of claim 19, wherein the installation coordinator is configured to schedule installation of the current computing resource on a second computing resource of the same type as the current computing resource in response to determining that a non-disruptive installation is requested. The installation is completed before starting on the resource.