Intelligent and elastic resource pools for heterogeneous datacenter environments

Disclosed are methods and systems for intelligent resource pool management of heterogeneous datacenter resources. In one embodiment, intelligent resource pool management is utilized to assist in application provisioning performed based upon a blueprint and deployment model defining requirements of the provisioned application. In other embodiments, intelligent resource pool managers are configured to work in concert with other intelligent resource pool managers and/or a centralized provisioning engine. Resource pools may also be configured in a hierarchical manner whereby higher level resource pools may automatically draw resources from lower level resource pools as directed by one or more intelligent resource pool managers.

BACKGROUND

Datacenters are increasingly being required to rapidly adapt to changes in customer requirements. It is no longer sufficient to provide a fixed, unchanging collection of servers and application software programs. Datacenters could benefit from being able to completely reconfigure servers from heterogeneous physical and logical resources in a short period of time in order to keep up with the constantly varying demands of content and application service providers. The need for a dynamic operating environment has resulted in the development of deployable application servers. Application servers may be deployed using a number of solutions, including script based installations of operating systems and applications remotely launched from a deployment management station, as well as virtual machine (VM) image based installations onto a system running a hypervisor, just to name two examples. In computing, a hypervisor, also called a virtual machine monitor (VMM), is a piece of software/hardware performing a platform-virtualization function that allows multiple instances of an operating system to run on a host computer concurrently (e.g., VMs).

Script-based installations of an application server are typically slow. It may take a significant amount of time to run the script-based installation (up to several hours) and thus may not be adequate to rapidly respond to changes in demand. In contrast, virtual machine images can be deployed more quickly than script-based solutions. However, prior art images of virtual machines must be preconfigured as if they were a homogeneous replica of an application server and thus represent a static resource that cannot be quickly created “on-demand” in response to unexpected requirement and demand changes. Additionally, prior art solutions have relied on centrally managed homogeneous pools of resources to satisfy provisioning requests.

Both script-based and deployment of pre-configured virtual machine images can also include manual processes that may be susceptible to human error. To complicate matters further, existing solutions are not designed to handle a heterogeneous operating environment, wherein different application products, different operating systems, different real (i.e., physical servers), and virtual computer systems may all need to co-exist and work together to optimally satisfy the needs of a datacenter.

SUMMARY

Disclosed are methods, systems and computer readable media to provide intelligent resource pool management for a hierarchy of heterogeneous resource pools. At the lowest level of granularity, a resource pool may contain homogeneous resources. However, providing a hierarchical abstraction layer and intelligent resource pool managers for at least some of the different levels of abstraction could allow for improved decentralized management of resource pools. In one embodiment, intelligent resource pools (IRPs) are configured with an intelligent resource pool manager (IRPM). Each IRPM can be configured with a certain level of autonomy and still cooperatively function in concert with other IRPMs and/or a centralized provisioning engine. Some or all of the IRPMs can utilize the hierarchical abstraction information to automatically draw from lower level resource pools when needed or to automatically replenish higher level resource pools. In one embodiment, an Application Definition blueprint and Deployment model as described in U.S. patent application Ser. No. 12/847,949 filed 30 Jul. 2010 by Suhas A. Kelkar et al. entitled “Application Blueprint and Deployment Model for Dynamic Business Service Management (BSM)” can be utilized by the IRPMs.

DETAILED DESCRIPTION

The present disclosure describes intelligent elastic resource pools implemented using computer hardware and/or software which extend the concept of dynamic datacenter resources to heterogeneous pools of resources that include differing types of physical, virtual and cloud resources. In at least some embodiments, one or more selection algorithms may be used to provide a best fit resource candidate in response to incoming resource requests. Thus, various levels of service can be defined for different pools of resources, and resources may be drawn from each pool depending upon the availability of the resource. For example, if a pool of high performance computers has been exhausted, and a request comes in that requires a level of service that only such computers can provide (e.g., a “platinum” level of service), the request may still be serviced by providing a less-than-requested level of service (e.g., “gold”) if the requesting client has agreed to such downgraded service at an appropriately discounted rate. Similar requests based upon cost criteria (e.g., lowest cost) may also be implemented.

Resource Pools (RPs) can be made into an Intelligent Resource Pool (IRP) by implementing an Intelligent Resource Pool Manager (IRPM). An IRPM can be responsible for a particular kind of resource or for a particular logical grouping of resources. Additionally, RPs may be structured hierarchically and be “chained” with other RPs. Thus, for example, a virtual machine pool with a mix of virtual machine images from various vendors may load such virtual machines (with an appropriate hypervisor) on computer system partitions drawn from a second, similarly created and maintained partition pool. Such chaining also enables an IRP to automatically replenish its pool as resources are allocated so as to maintain a minimum level of resources within the managed pool. In at least some embodiments, such replenishment may be done in anticipation of future demands until all lower-level resources are exhausted.

The use of chained heterogeneous IRPs also creates a level of abstraction that may alleviate the need to hard bind applications to underlying resources. Such an abstraction can provide for easier swapping of resources without adversely affecting the behavior of an application. For example, a generic “web server” application can be provided from a pool of such servers that can include both Apache web servers and Microsoft IIS servers for hosting web sites that are designed to be hosted on either type of server. Thus, the behavior of the web server application is not adversely affected by the web server application resource selected. Similarly, a pool of generic “servers” may be built from a collection of both physical and virtual servers, so long as the performance requirements of the hosted application are met.

Application provisioning refers to selecting one or more servers from a pool of available servers, either real or virtual, and preparing the selected servers for a requesting end-user. Preparing the selected servers includes, but may not be limited to, loading the server with the appropriate software (e.g., operating system, device drivers, middle ware, and applications), configuring network connections and optionally configuring upstream network resources, allocating shared storage and optionally configuring storage adapters and arrays, appropriately customizing and configuring the system, and starting the server with its newly-loaded software. Customizing and configuring may include configuring boot images for the servers by changing their stored parameters to affect how they will be instantiated. For example, patches could be applied to the boot image, an audit could be performed on the boot image, or addresses of the boot image (e.g., network address, gateway address) could be altered. After these setup tasks are performed, either prior to or after the step of instantiating the image, the provisioned server is ready for operation and addition to a datacenter network.

In some disclosed embodiments, a user-selectable application definition (ADF) or blueprint (BP) defines at least part of the structure of an application or an application server in terms of “tiers” and the relationships between tiers. Tiers can represent classes of application servers that are available for selection by a user of a computer system implementing the described embodiments. Examples of tiers that may be defined within a BP include, but are not limited to, a database tier and a web tier. Other applications and application tiers that may be included within a BP will become apparent to those of ordinary skill in the art, and all such applications and application tiers are contemplated by the present disclosure.

A BP may also include one or more deployment options associated with each tier, such as different product choices and combinations. For example, a user may select a BP that includes either JBoss® 4.0 or Tomcat as the product that is to be installed to implement a web tier and either Oracle 10g® or MySQL 5 for a database tier. (JBOSS is a registered trademark of Red Hat, Inc. ORACLE 10G is a registered trademark of Oracle International Corporation. MySQL is a trademark of MySQL AB Company. Tomcat is a trademark of the Apache Software Foundation). Any number of different tiers may be defined, reflecting the broad variety of applications that may be hosted on a deployed server. A BP may also define environment and other variables needed to successfully provision a server. However, because a BP does not specify physical resources, virtual resources or content needed for successful application server provisioning, the BP is therefore portable and can be reused across a wide variety of different resources available within a heterogeneous datacenter.

In some embodiments, a user-selectable deployment intent definition (DDF) or deployment model (DM) may also be defined and can be used to at least partially augment a BP or ADF. The DM conforms to a BP but is a lower level document that focuses on the intent of the deployment (e.g., production, testing, demonstration and quality control uses). The DM can be used to associate product content with each tier defined within the blueprint. Such content may include installation programs, artifacts and configuration scripts that are used to configure the application server and its environment to conform to a user's requirements. The deployment model may further associate resource requirements with the products for each tier such as, minimum required computing, storage and network resource capacities. The deployment model may also include one or more rules that further govern the provisioning and deployment of application server instances (e.g., a maximum number of instances based upon the level of service required/purchased by the user, or a licensing limitation).

In a preferred embodiment IRPs can be configured with an IRPM to utilize BPs and DMs. For more information about application blueprints and deployment models please refer to U.S. patent application Ser. No. 12/847,949 filed 30 Jul. 2010 by Suhas A. Kelkar et al. entitled “Application Blueprint and Deployment Model for Dynamic Business Service Management (BSM)” which is hereby incorporated by reference in its entirety.

As stated above, the present disclosure describes systems and methods for IRPs to assist in server provisioning of heterogeneous datacenter resources and may be extended to include the higher level steps required to facilitate application provisioning. Referring now toFIG. 1A, block diagram100illustrates one possible division of a totality of available resources (block110) divided into three (3) pools (i.e., logical groupings). An Allocated Pool120represents resources that have been provisioned and are currently associated with an executing application or a persistently allocated application (i.e., one that is not provisioned repeatedly when needed). Reserve Pool130represents “raw” resources that have not yet been configured. When “raw” resources are configured they may be added to either the Available Pool140or, if necessary, immediately used to satisfy an allocation request and thus be added to the Allocated Pool120. Available Pool140represents compute, network, and storage, etc. Resources in Available Pool140can be resources that have been pre-configured in anticipation of some expected future need or to satisfy an immediate need.

Referring now toFIG. 1B, block diagram101illustrates an example division of Reserve Pool130and Available Pool140. In this example, Reserve Pool130can be configured with an IRPM (not shown) to be made intelligent and automatically draw from Server Resources131, Network Resources132and Storage Resources133. Similarly, Available Pool140can be configured with an IRPM (not shown) and automatically draw from server resources configured with only an Operating System (OS) (block141), OS plus generic (e.g., default configuration) application resources142, or OS plus specific (e.g., pre-configured with special configuration parameters) application resources143. Additionally, the IRPM of Reserve Pool130may be configured to coordinate with the IRPM of Available Pool140or to coordinate with a centralized Provisioning Engine (270ofFIG. 2described below).

Server Resources131can include a plurality of lower level resource pools (not shown). Some non-limiting examples include:Device Resource Pools: These pools can contain raw devices that are identified by Media Access Control (MAC) addresses, which can either be imaged or network booted for provisioning.Managed Server Resource Pools: These pools can contain managed servers that are either dormant or running. If dormant, the server can be revived for utilization. If running with available capacity, the server can possibly co-host a new request with other applications and thus eliminate an unnecessary instantiation of another server. This type of pool can contain both virtual and physical servers.Virtual Managed Server Resource Pools: Virtual server resource pools can contain managed virtual machines where the hypervisor is also managed. This can allow taking actions such as changing the configuration of a VM, assigning a VM to a VMware® resource pool, or spinning up the VM. (VMware is a registered trademark of VMware, Inc.).Hypervisor Resource Pool: Hypervisor resource pools contain hypervisors which are a source of VMs. New VMs can be created based on a resource request, or existing VMs can be cloned or reconfigured. In the case of VMware, the hypervisor resource pool can also be attached to a VMware resource pool in Virtual Center. These resource pools can be further classified into Solaris zones resource pools and mainframe logical partition (LPAR) resource pools. (Solaris is a registered trademark of Sun Microsystems, Inc.).Frame Resource Pools: Frame resource pools can contain frames (e.g., Cisco®UCS frames) and can specify a “server profile template.” (Cisco is a registered trademark of Cisco Systems Inc.). Server profile templates and frame resources can be used to manufacture a blade server to a request's specifications.

Network Resources132can include a plurality of lower level resource pools (not shown). Some non-limiting examples include:Internet Protocol (IP) Address Resource Pools: These pools can contain IP addresses that can be allocated to servers that require fixed IP addresses. Pool resources can be individual IPs or subnets.Virtual Local Area Network (VLAN) Resource Pools: These pools can contain VLANs that can be assigned to a group of resource requests. Thus an application server and a database server being used for the same application request can reside on the same VLAN.Load Balanced IP Pools: These pools can have sets of IPs which are part of a load-balanced configuration. IPs from this pool can be assigned to a set of web servers, for example, to provide load balancing.Network Address Translation (NAT) Address Pools: Connections can have their source address translated to an address from the pool using NAT rules. NAT address pools can provide an IP configuration that allows specific NATed addresses.Network Container Resource Pools: These pools can contain definitions of network containers which define a set of network resources that provide isolation in a co-hosted environment. The network container can form an envelope around the compute and storage resources for isolation and security.Network Zone Resource Pools: network zones can provide a more granular level of isolation and exist with network containers. Pools of zones are used for application isolation.

Storage Resources133can include a plurality of lower level resource pools (not shown). Some non-limiting examples include:World Wide Port Name (WWPN) Resource Pools: These pools can represent WWPNs that can be assigned to storage adaptors of servers that are being built so that these servers can be later configured for storage volumes.WWPN+WWPN Resource Pools: These pools can represent WWPN end points which point to allocated storage. This can allow for preconfigured storage to be allocated on request.WWPN+WWPN Boot Pools: These pools can represent preconfigured bootable storage for servers that will boot from a storage area network (SAN). This pool is managed separately because bootable SAN volume resources are typically managed differently than non-bootable resources.Network File System (NFS) and Windows® Share Resource Pools: NFS and Windows Shares that are available on the network as storage volumes or common storage across applications can belong to these types of storage pools. (Windows is a registered trademark of Microsoft Corporation).Virtual Machine Disk (VMDK) Resource Pools: VMware VMDK files that can be associated with a VM to provide additional storage or boot/image configuration can be part of this type of resource pool. A new server personality can be created by virtue of associating such a resource to a VM or the VM can be provided with extra storage, which can appear as an extra drive to the guest OS.

As discussed above, block140represents resources that have been at least partially configured. Those of ordinary skill in the art, given the benefit of this disclosure, will recognize that optimizing the granularity of pools and specificity of pre-configuration of resources in pools may vary from one enterprise environment to the next based on particulars of each enterprise environment. Furthermore, after resources have been made available they will typically next be used to satisfy an application provisioning request. Allocated Resource Pool120illustrates resources actively in use or persistently allocated. Allocated Resource Pool120can be configured with an IRPM (not shown) to communicate with other IRPMs or other processes such as a reclamation of resources process150. Reclamation of resources process150may be invoked after a provisioned application on previously allocated resources has completed its task or may be invoked based on timers or threshold requirements and actually reclaim resources from Available Pool140. Additionally, reclamation of resources process150may alternatively be initiated by the IRPM of Reserve Pool130when that IRPM detects a potential inability to satisfy a priority (discussed further below) request for resources.

Referring now toFIG. 2, an overview of a provisioning environment (system200) is described as an example of one possible disclosed embodiment. In accordance with this disclosure, at least some embodiments are implemented in hardware, software or a combination of hardware and software by one or more computer systems communicatively coupled to each other across a network210or bus (not shown). At least one computer system can perform functions that include an IRPM220. Provisioning engine270can automate the provisioning and deployment process and provide an abstraction layer isolating a system user from some details associated with the process. An example of one possible control flow, which could be implemented in system200, is shown in process300ofFIG. 3described further below.

In the example embodiment of system200, a user may request an application instance by identifying a blueprint and a desired deployment model. The identification can take place on a work station computer attached to network210and providing a suitable user interface. The user's blueprint and deployment model request can then be forwarded across network210for processing by provisioning engine270. Provisioning engine270can derive the requested DM (DDF) from the BP (ADF) by augmenting the BP with information from the DM. Next, provisioning engine270alone or with the help of another network attached processor executing an IRPM220can determine which resources, from appropriate resource pools, are needed to meet the request. Provisioning engine270can then interact with one or more IRPMs2,20to select the required storage resource(s) from storage resource pool260and/or compute resources from compute resource pools230-250. IRPMs220can access managed resources and group the resources as necessary to meet a request (e.g., server250, network210and storage resources260). Server resources may be real or virtual and may include, for example, individual computer systems (e.g.,250), logical partitions within a mainframe computer (230) and computer systems running hypervisors such as blade server240. Storage260and network210resources may also be either real or virtual.

After required resources are selected, provisioning engine270can interact with IRPMs220to provision selected resources as specified by the BP and DM. Products or product combinations used to provision the resources may be drawn from one or more homogeneous or heterogeneous pools as determined by one or more IRPMs working together with provisioning engine270(e.g., an image server storing preconfigured images). For example, a pool of virtual machine images configured as generic Oracle® database servers running under Linux® may be provided by the provisioning product for installation on selected resources. (ORACLE is a registered trademark of Oracle Corporation; LINUX is a registered trademark of Linus Torvalds.). Such an installation may be done by copying the virtual machine image to the selected storage resource and configuring a hypervisor on the selected server resource to activate the copied virtual machine image. Once activated and booted, the virtual machine and database server application may be further configured to conform to the requested deployment model (e.g., using one or more installation scripts specified by the deployment model).

In at least some embodiments, pools are managed independently via a dedicated IRPM such as IRPM1(220). Each of IRPMs1through N (220) can autonomously manage a subset of resources to decentralize the overall management process of datacenter resources. Additionally each IRPM220can automatically draw upon lower level resource pools as necessary when the number of available resources in a given pool drops below a threshold value. For example, if the pool of Linux virtual machine images becomes depleted, the IRPM managing the number of Linux virtual machines can automatically draw upon another pool of raw resources to configure or instantiate additional Linux virtual machines. Because the pool replenishing can be performed proactively before an anticipated pool combination is needed, subsequent user requests may be provisioned on-demand with little or no delay. As shown in system200each of IRPMs1-N (220) are remote (i.e., across network210) from the actual resources they are managing. However, some or all IRPMs may also be configured to execute locally with the resources for which the particular IRPM is responsible. Distribution of IRPMs (220) across managed resources is typically a design decision based on particulars of the resource infrastructure.

Referring now toFIG. 3, process300illustrates one possible overview of application provisioning. It will be apparent to those of ordinary skill in the art that acts in accordance with process300may be distributed across one or more IRPMs. Beginning at block310, a Tier is identified based on the provisioning request. Next, at block320the deployment options are identified to satisfy the provisioning request. For example, a request may require Linux and Oracle or may also function properly on Windows and MySQL. Counts of requested resources can be maintained (block330) for capacity planning purposes or for proactive configuring of resource pools as described above. The deployment options can also be taken into account when performing a search for matching resources from the resource pool (decision340). If no matching resources are currently available (the NO prong of340) a system(s) may be configured from reserve pools at block348. If matching resources are available (the YES prong of340) then pool availability counters can be decremented at block345and resources can be assigned to satisfy the request at block350. In either case, after the system(s) are configured processing flow continues to block360where additional required configurations can be performed. At block370, after all configuration steps are complete the system(s) is made available to the requestor. Finally, block380illustrates that a determination can be made to determine if any of the pools need to be replenished from the reserve in anticipation of a future request. Note that block380may be performed as shown, periodically or at any time in process300and, in one embodiment, is performed by each IRPM dynamically throughout process300. Also note that replenishment may comprise replacing resources with different resources capable of performing a similar function. For example, a windows server running Oracle may be configured to replace a Linux server running Oracle when no more Linux instances or licenses for Oracle on Linux are available. This can be thought of as replenishing with substantially similar or resources commensurate with resources utilized to support a previous provisioning request.

Referring now toFIG. 4, exemplary computing device400is shown. One or more exemplary computing devices400may be included in a mainframe computer (not shown). Exemplary computing device400comprises a programmable control device410which may be optionally connected to input device460(e.g., keyboard, mouse, touch screen, etc.), display470or program storage device (PSD)480(sometimes referred to as a direct access storage device DASD, disk or persistent memory). Also, included with program control device410is network interface440for communication via a network with other computing and corporate infrastructure devices (not shown). Note network interface440may be included within programmable control device410or be external to programmable control device410. In either case, programmable control device410will be communicatively coupled to network interface440. Also note, program storage device480represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic storage elements including solid-state storage.

Program control device410may be included in a computing device and be programmed to perform methods in accordance with this disclosure (e.g., those illustrated inFIG. 3). Program control device410may itself comprise processor unit (PU)420, input-output (I/O) interface450and memory430. Processing unit420may include any programmable controller device including, for example, processors of an IBM mainframe (such as a quad-core z10 mainframe microprocessor). Alternatively, in non-mainframe systems examples of processing unit420include the Intel Core®, Pentium® and Celeron® processor families from Intel and the Cortex and ARM processor families from ARM. (INTEL CORE, PENTIUM and CELERON are registered trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company.) Memory430may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid state memory. One of ordinary skill in the art will also recognize that PU420may also include some internal memory including, for example, cache memory.

Aspects of the embodiments are described as a method of control or manipulation of data, and may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable medium may include any mechanism for tangibly embodying information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium (sometimes referred to as a program storage device or a computer readable medium) may include read-only memory (ROM), random-access memory (RAM), magnetic disc storage media, optical storage media, flash-memory devices, electrical, optical, and others.

In the above detailed description, various features are occasionally grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim.

Various changes in the details of the illustrated operational methods are possible without departing from the scope of the following claims. For instance, illustrative flow chart steps or process steps ofFIG. 3may be performed in an order different from that disclosed here. Alternatively, some embodiments may combine the activities described herein as being separate steps. Similarly, one or more of the described steps may be omitted, depending upon the specific operational environment the method is being implemented in. In addition, acts in accordance withFIG. 3may be performed by a programmable control device executing instructions organized into one or more program modules. A programmable control device may be a single computer processor, a special purpose processor (e.g., a digital signal processor, “DSP”), a plurality of processors coupled by a communications link or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as an integrated circuit including, but not limited to, application specific integrated circuits (“ASICs”) or field programmable gate array (“FPGAs”). Storage devices, sometimes called computer readable medium, suitable for tangibly embodying program instructions include, but are not limited to: magnetic disks (fixed, floppy, and removable) and tape; optical media such as CD-ROMs and digital video disks (“DVDs”); and semiconductor memory devices such as Electrically Programmable Read-Only Memory (“EPROM”), Electrically Erasable Programmable Read-Only Memory (“EEPROM”), Programmable Gate Arrays and flash devices.