Patent Application
20150263983
The invention relates generally to cloud based computing, and more specifically to systems and methods of associating hardware and software components and attributes, including high availability attributes and compliance attributes.
Cloud based computing, according to the National Institute of Standards and Technology (NIST) (see NIST Publication 800-145), is a system model for enabling convenient, on-demand network access to a shared group of configurable computing resources such as, but not limited to, servers, storage, and applications, that can be rapidly provided to a user and released by the user with minimal effort by system management and service providers. According to NIST, this cloud model has five characteristics.
The five characteristics are:
Such clouds may be: private, belonging to a single organization and accessible only by members of that organization; community based, such that their users come from multiple organizations having shared goals; public, available to the general public; and hybrid, which is a combination of two or more of the private, community based or public clouds. These clouds are generally used to provide: Software as a Service (SaaS), in which applications are provided by the cloud; Platform as a Service (PaaS) in which user applications from outside the cloud utilize the cloud resource but the user has no control over the platform; and Infrastructure as a Service (IaaS) in which users may utilize and control cloud-provided operating systems and storage to run the user's applications.
Because the cloud's location of resources is generally irrelevant to the user, cloud based applications may be moved from one location to another or from one resource to another transparently, without the user becoming aware. This may be necessary for maintenance, cloud platform expansion or disaster recovery. As such, it is necessary that each application be associated with the hardware, software and attributes it needs to be managed on an individual basis such that those requirements may be moved or replaced without reducing the availability of the application to a user. This process is time consuming and can lead to errors when individual computing resources are not properly allocated.
The present invention addresses these needs.
In one aspect, the invention relates to a method of provisioning a computer application in a cloud environment built on a hardware infrastructure. In one embodiment, the method includes the steps of: providing the computer application (which may be comprised of one or more individual applications, virtual machines, or physical machines); defining the processing requirements of the computer application; defining the storage requirements of the computer application; defining the network requirements of the computer application; defining the policies for the computer application; defining the processing requirements of the computer application, the storage requirements of the computer application, and the policies for the computer application (such as business requirements, security requirements, etc.); combining a superset of the requirements into a Container definition that comprises the computer application and selecting cloud hardware in response to the components of the Container.
In one embodiment, a Container refers to a collection of hardware, software and attributes within which some information technology function is performed. In yet another embodiment, the Container is a collection of descriptors (known as a Deployment Package) that describes the interrelationships among each component of a software application and their relationships to resources outside of the cloud. Related to these various descriptors are “Tags” which describe the desired behavior of each component when consuming resources in the cloud.
In one embodiment, the Deployment Package establishes the application requirements including Images, Volumes, Internal Network Interdependencies, External Network Interdependencies, and security requirements. In another embodiment, Tags describe desired behaviors when consuming cloud resources such as: availability level (strategy to implement), performance level, types of hypervisors to consume, types of storage to consume, types of monitoring to utilize, physical location, and recovery mode (desired behavior for failure recovery).
In yet another embodiment, once an application is deployed, Tags may be manipulated to alter behaviors of components of the application, either permanently or according to a schedule. For example, a requirement that a given Container be required to provide high availability for the computing resources that, at least partially, define the Container can be accomplished by assigning a High Availability Tag to the Container. If high availability is only required for a period of time, a user may schedule such a Tag to be changed in the future, altering the behavior of the application at that time. Upon a change to a Tag (user manipulated or scheduled), a control system termed an “Orchestrator” views the Container as “out of compliance” with user intent and takes steps to re-interpret the Container's Tags and manipulate the cloud to become “compliant” with user intent. In still another embodiment, the Tag is created by a user on a custom basis to describe attributes or business policies for the user's local cloud.
The structure and function of the invention can be best understood from the description herein in conjunction with the accompanying figures. The figures are not necessarily to scale, emphasis instead generally being placed upon illustrative principles. The figures are to be considered illustrative in all aspects and are not intended to limit the invention, the scope of which is defined only by the claims.
In brief overview and referring to
In such a cloud environment, virtualization is frequently used to provide many users with the equivalent of a dedicated server and computation environment while actually using a single physical server 14 and other related hardware. Thus, virtualization is used to reduce the number of servers or other resources needed for a particular project or organization. Present day virtual machine computer systems utilize virtual machines 20 (VM) operating as guests within a physical host computer 14.
Each virtual machine 20 includes its own virtual operating system and operates under the control of a managing operating system or hypervisor 24 executing on the host physical machine 14. Each virtual machine 20 executes one or more applications and accesses physical data storage 34 and computer networks 30 as required by the applications. In addition, each virtual machine 20 may in turn act as the host computer system for another virtual machine. Various configurations of virtual machines can be used as part of a cloud configuration.
A benefit of such a cloud configuration is that virtual machines and their associated applications can be easily moved to various physical locations having the requisite hardware as the needs of the application change or as the hardware experiences failures. Further, multiple virtual machines may be configured as a group to execute one or more of the same programs or to execute multiple programs, which work together as an application. Typically, in the instance of a virtual machine acting as a critical component of the application, that particular virtual machine in the group will be referred to as requiring high availability, and instantiated with a primary or active virtual machine, and any remaining virtual machines associated with the application are the secondary or standby virtual machines.
If something goes wrong with the primary virtual machine, one of the secondary virtual machines can take over and assume the primary's role in the computing system. This redundancy allows the group of virtual machines to operate as a fault tolerant computing system. The primary virtual machine executes applications, receives and sends network data, and reads and writes to data storage while performing automated tasks or as a result of user-based interactions. In such a redundant system, the secondary virtual machines have the same capabilities as the primary virtual machine, but do not take over the relevant tasks and activities unless and until the primary virtual machine fails.
In more detail, referring to
The various components of the data center 1 can be configured as necessary to provide the correct environment for executing an application. As an example, in one embodiment, a virtual machine VM11 executing on server-1 and virtual machine VM21 executing on server-2 are both running the same application in a fault-tolerant configuration. In this exemplary configuration, there is redundant storage 34, 34′ (storage-1 and storage-2) and a network switch 38, 38′ (generally 38) (network resource-1, and network resource-j). As shown, the combination of VM11 and VM21, network resources-2 and network resources-j, storage-1 and storage-2, and the application comprise a fault tolerant system. Various components may be part of more than one system. For example, virtual machine VMm1 on server-m may be part of a system (System-m) that includes network resource-j and storage I, even though network resource-j is also a resource of a different system (System-j).
To make the various possible combinations of hardware and software, physical and virtual machines, and their locations and other attributes manageable to a user, the virtual machines that are required to perform a set of functions for a given user are defined as belonging to a “Container”. A Container in various embodiments also includes other virtual machines which may require alternative availability levels including those that are of lesser importance, and do not require secondary virtual machines. If an application does not require high availability, then the application and its corresponding virtual machine are referred to as a “Commodity”.
In one embodiment, a Container refers to a collection of hardware, software, and attributes within which some information technology function is performed, while in another context, a Container is a collection of descriptors (known as a Deployment Package) that describes the interrelationships among each component of a software application and their relationships to resources outside of the cloud, such as: Images, Volumes, Internal Network Interdependencies, External Network Interdependencies, and security requirements.
Generally, a software application and its deployment environment(s) form a logical Container. A given software application has a number of possible Deployment Packages representing valid hardware and software configurations for the application. The differences among Deployment Packages relate to availability/redundancy performance requirements, business rules, and behavioral characteristics.
As an example, in a valid Deployment Package, certain hardware and software may be necessary for a given software application to have access to a network. Such a valid Deployment Package would include an environment with a network connection. Further, as another example, a business rule can relate to Geographic Location. Thus, there may be a restriction on certain data in an application that requires that the data not leave the United States. In this case, a business rule is constructed which is “Geographic Data Restrictions”, with Tags United States, Canada, Mexico, etc. The Hypervisors would be tagged with their Geographic Location (United States, Canada, Mexico, etc.) and a restriction of “United States” would be placed in the Deployment Package, forcing all placements to remain within the Geography. A list of Deployment Packages is provided for each available application, termed a Catalog Application.
Each Deployment Package includes an associated Network Topology. The Network Topology is a description of the networking environment in which the application will live. A Network Topology can define multiple networks, routings between networks, and routings to and from locations external to the cloud. For each instance specified in the deployment package, there is a specification of the networks in the topology to which they connect, the external connections that are routed, and the internal connection interdependencies among instances in the same deployment package. For example, a Web Server might have a port to a network defined as External which is a connection (routing) to the external web. That same web server may also have a port to an internal network, so that it may pass on requests to internal VM's. Specification of internal connections allows the internal VM's to determine whether traffic from this web server is acceptable. The specification of internal and external connections in the deployment package drives automatic generation of security group (firewall) rules at deployment time.
Referring also to
The virtual machine 20 providing access to the database 34 is more important to the operation of the system than the virtual machines 20′, 20″ providing the user interface. This is because if an interface virtual machine 20′ fails, the network will redirect the user to another user interface machine 20″, but if the database server 20 fails, the system is not able to provide the required data for purchasing the merchandise. Thus, the database server virtual machine 20 should be designated as requiring higher availability than the interface server virtual machines 20′, 20″.
In order to help a user understand the hardware, software and attributes of the system, a label or “Tag” 120 (
Once an application is deployed, the various Tags may be manipulated to alter behaviors of the components of the application, either permanently or according to a schedule. For example, a requirement that a given Container be required to provide high availability for the computing resources that, at least partially, define the Container can be accomplished by assigning a High Availability Tag to the Container. If high availability is only required for a period of time, a user may schedule such a Tag to be changed in the future, altering the behavior of the application at that time. Upon a change to a Tag, either by user manipulation or scheduled change, a control system termed an “Orchestrator” views the Container as “out of compliance” with user intent and takes steps to re-interpret the Container's Tags and manipulate the cloud to become “compliant” with user intent. In still another embodiment, the Tag is created by a user on a custom basis to describe attributes or business policies for the user's local cloud.
The fact that all the virtual machines 20, 20′, 20″ (
In more detail, Tags contain business-specific information related to the workload. In one embodiment, Tags include application category, availability 130, performance 132, hypervisor type 134, storage type 136, recovery mode 138, and location 140. Considering these Tags separately:
In other embodiments, additional Tags may be created by the user to provide a descriptor to aid the user in identifying the Container or application. For example, if all of the elements of a financial transaction system need to be PCI compliant, need to run on an SSD storage device, need to be allocated to a high availability computing environment, or all three of the forgoing, Tags and Containers can be used to properly identify all of these requirements and others as a function of the needs of the organization.
Further, Tags exist as a hierarchy in which more specific Tags take precedence over less specific Tags when the components of the Container are examined by the Orchestrator 44. For example, if the Container 100 has an unspecified availability but a virtual machine 20 in the Container 100 is specified as High Availability, then the virtual machine 20 takes on an availability Tag as High Availability with respect to that virtual Container 100. Each virtual machine in a Container may have the same or different Tags associated with it. Instances within a Container are currently assigned within a “network topology”. This network topology can cross networks and subnets and can cross Availability Zones. Thus, one machine could have one security policy and a second machine could have a different security policy associated with it.
The monitoring of the Container and the virtual machines, and the movement or reconfiguration of the Container or virtual machines, is provided by the rules engine of the Orchestrator 44. The Orchestrator 44 rules system, as discussed below, controls the functioning and provisioning of the virtual systems in the physical servers. To do this, the Orchestrator 44 makes use of Tags that are associated with the components of the Container 100, such as the virtual machines 20 and the Container 100 itself.
The rules of the Orchestrator 44 utilize the Tags to determine how the various systems should function. For example, the Orchestrator 44 can change the location of the Container 100 to an equivalent but different physical location if the hardware in the first location begins to fail and the applications running are designated as High Availability. In this case, the Orchestrator 44 knows what locations have the proper hardware and availability to simply move the Container, and hence all of its components, to the new location by setting the location Tag to the new location.
The capability to move Containers between environments is important for Disaster Recovery (DR). In DR, the system recovers from outages due to varying levels of infrastructure loss. The Orchestrator 44, in the case of hardware failure, can use the Tags to change the locations of the Containers. The Orchestrator in various embodiments produces a report for the user calculating the existence of various hypothetical failures and the success in moving Containers to various alternate locations. To accomplish this, upon the deployment of an application, a file is created which contains enough information to replicate the initial Application deployment from existing images. Changes made to the application after initial deployment are maintained in a history file by an agent that writes all such system changes to disk.
In addition to DR and hardware failure remediation, the Orchestrator also is used for workload placement on hypervisors and load balancing. To perform workload placement, the Orchestrator 1) gathers all potentially useful hypervisors and 2) filters the resulting list using Tags, 3) scores the remaining hypervisors based on capacity and 4) compares the resulting list to suggest a best hypervisor.
In more detail, the Orchestrator first considers all hypervisors of which it is aware and removes from the list any hypervisors that are not enabled, are not managed by the Orchestrator, are being evacuated due to facility issues or which are “blacklisted” as having too high a workload. “Up”, with respect to a hypervisor, refers to the physical hypervisor being in a ‘running’ state. Conversely, “down” refers to a hypervisor that is not in a running state. “Enabled” means that the hypervisor may be utilized, while “Not Enabled” means that regardless of the programmatic state of running or not running, the hypervisor cannot be used. Once the potentially available hypervisors have been selected, these hypervisors are filtered to select those that are capable of accepting the Containers to be placed.
The initial filtering is performed by matching the value of the Container Tag with the value of the hypervisor Tag. A Tag is typically matched as a Boolean value: true/false or yes/no. For example, one filter is the availability filter. With this filter enabled, a Container with “mission critical” applications cannot be placed on a hypervisor designated as Commodity, but a Container designated as holding a Commodity application can be placed on a hypervisor designated as Mission Critical. The degree of match within each category is determined by a numerical value based on the percent match (for example: exact match, best idea, non match), and then the total across all of the tag categories are summed with the highest resulting score being designated as best match.
In order to accommodate the fact that Tag values may not match perfectly, the Orchestrator uses placement rules to make imperfect matches. For example, a placement rule might say that placing a Container designated as a Commodity on a hypervisor designated as Business Critical is permitted, but has a score of 50, while placing that Commodity Container on a hypervisor designated as Mission Critical is also permitted but has a score of 0. This rule will tend to place the commodity workload on Business Critical hypervisors, although this is an imperfect choice.
In addition to the availability filter, other filter embodiments include:
Recovery Mode—This filter filters on whether the hypervisor has shared storage for applications that need shared storage;
Hypervisor type—This filter filters on the type of hypervisor being considered, for example VMWARE®;
Location—This filter determines if the hypervisor exists in the desired geographic location; and
Capacity filter—Determines whether the workload capacity matches the capacity of the hypervisor. This is done to avoid placing a low capacity workload on a high capacity hypervisor (e.g. 8 CPU 16 GB workload on an 8 CPU 192 GB hypervisor). To calculate capacity in this filter, the Orchestrator uses four variables associated with the hypervisor: CPU utilization, memory utilization or availability; storage consumption or free space available; and I/O traffic to determine workload capacity.
In addition, the Orchestrator considers Utilization Percent, which is the Hypervisor free space minus the utilization of the new application divided by the total space; and Weighting results, which is a weighting value applied to each filter according to perceived importance to a user. A weighting value is a user-settable variable that allows the user to be able to order the categories and determine how important they are to the user's business. The weights are then set by the system based on the individual user's business preferences.
Upon completion of this filtering, the calculation returns one or more of: an ordered list of candidate hypervisors; a group of scores associated with each hypervisor; no hypervisor located or recommended hypervisor.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations can be used by those skilled in the computer and software related fields.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus, provided the computer or other apparatus is capable of executing a rules engine. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.
The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting on the invention described herein. Scope of the invention is thus indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are intended to be embraced therein.
This application claims priority to U.S. provisional patent application 61/921,814 filed on Dec. 30, 2013 and U.S. provisional patent application 62/052,130 filed Sep. 18, 2014, both of which are owned by the assignee of the current application, the contents of both of which are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| 61921814 | Dec 2013 | US | |
| 62052130 | Sep 2014 | US |
