Patent Application
20240354168
A data center is a facility that houses servers, data storage devices, and/or other associated components such as backup power supplies, redundant data communications connections, environmental controls such as air conditioning and/or fire suppression, and/or various security systems. A data center may be maintained by an information technology (IT) service provider. An enterprise may utilize data storage and/or data processing services from the provider in order to run applications that handle the enterprises' core business and operational data. The applications may be proprietary and used exclusively by the enterprise or made available through a network for anyone to access and use.
Virtual computing instances (VCIs), such as virtual machines and containers, have been introduced to lower data center capital investment in facilities and operational expenses and reduce energy consumption. A VCI is a software implementation of a computer that executes application software analogously to a physical computer. VCIs have the advantage of not being bound to physical resources, which allows VCIs to be moved around and scaled to meet changing demands of an enterprise without affecting the use of the enterprise's applications. In a software-defined data center, storage resources may be allocated to VCIs in various ways, such as through network attached storage (NAS), a storage area network (SAN) such as fiber channel and/or Internet small computer system interface (iSCSI), a virtual SAN, and/or raw device mappings, among others.
As referred to herein, a virtual computing instance (VCI) covers a range of computing functionality. VCIs may include non-virtualized physical hosts, virtual machines (VMs), and/or containers. A VM refers generally to an isolated end user space instance, which can be executed within a virtualized environment. Other technologies aside from hardware virtualization that can provide isolated end user space instances may also be referred to as VCIs. The term “VCI” covers these examples and combinations of different types of VCIs, among others. VMs, in some embodiments, operate with their own guest operating systems on a host using resources of the host virtualized by virtualization software (e.g., a hypervisor, virtual machine monitor, etc.).
Multiple VCIs can be configured to be in communication with each other in an SDDC. In such a system, information can be propagated from a client (e.g., an end user) to at least one of the VCIs in the system, between VCIs in the system, and/or between at least one of the VCIs in the system and a server. SDDCs are dynamic in nature. For example, VCIs and/or various application services, may be created, used, moved, or destroyed within the SDDC. When VCIs are created, various processes and/or services start running and consuming resources. As used herein, “resources” are physical or virtual components that have a finite availability within a computer or SDDC. For example, resources include processing resources, memory resources, electrical power, and/or input/output resources.
While the specification refers generally to VCIs, the examples given could be any type of data compute node, including physical hosts, VCIs, non-VCI containers, and hypervisor kernel network interface modules. Embodiments of the present disclosure can include combinations of different types of data compute nodes.
Cloud automation platforms (e.g., VMware's vRealize Automation (vRA)) offer end users a wide variety of cloud resources for provisioning. These resources may be exposed through a catalog of templates, which consumers use to deploy cloud applications and/or services. Users manage provisioned cloud resources (VCIs, network, storage, etc.) by performing second day (referred to herein as “day-2”) operations and/or actions, which are predefined on an automation platform. Complex use cases, however, involve a non-standard set of resource actions that are be defined and implemented by the automation users themselves. There is a need for extensibility mechanisms to fill that gap by providing infrastructure administrators with the right tools to build and maintain their customized software as a service (SaaS) solutions.
One example for cloud-native extensibility mechanism is “serverless.” Serverless is a development model that allows developers to build and run small, lightweight scripts of code without having to manage servers. Under a serverless model, a cloud provider runs physical servers and dynamically allocates their resources on behalf of users who can deploy code straight into a public or private cloud. This makes for a good extensibility mechanism for cloud users who wish to concentrate on their apps instead of managing complex infrastructure. Embodiments of the present disclosure address the problem of providing an extensibility mechanism for custom day-2 operations on cloud resources by utilizing the serverless development model. For instance, embodiments herein include adding the possibility of running Action Based Extensibility (ABX) actions (e.g., Amazon Web Service (AWS) lambdas, Azure Functions, etc.) as day-2 operations of cloud resources whose lifecycle is managed by a cloud automation platform such as, vRealize Automation (vRA) 8.x/Cloud, for instance.
As referred to herein, a blueprint is a specification for cloud resources deployed by a user. Blueprint architects assemble software components such as VCIs, storage, networks, etc. into blueprints that define the terms users request from a catalog. Typically, blueprints describe fully-fledged applications that include multiple components. A catalog, as referred to herein, includes catalog items (e.g., published blueprints). A catalog provides consumers with a uniform request experience when they might be requesting cloud applications developed on-premises, in the cloud instance, or from other content sources. Deployed blueprints may also be referred to as cloud resources. A resource action, as referred to herein, is an association between an ABX action and a resource type of a blueprint. Stated differently, a resource action makes changes to deployed cloud resources. The present disclosure allows users to configure custom day-2 actions that make changes to deployed cloud resources. While cloud automation platforms may provide a predefined list of operations and/or actions that apply to cloud resources (depending on their type), custom resource actions are operations defined by cloud users for a particular type of resource.
The host 102 can incorporate a hypervisor 104 that can execute a number of VCIs 106-1, 106-2, . . . , 106-N (referred to generally herein as “VCIs 106”). The VCIs can be provisioned with processing resources 108 and/or memory resources 110 and can communicate via the network interface 112. The processing resources 108 and the memory resources 110 provisioned to the VCIs 106 can be local and/or remote to the host 102 (e.g., the VCIs 106 can be ultimately executed by hardware that may not be physically tied to the VCIs 106). For example, in a software defined data center, the VCIs 106 can be provisioned with resources that are generally available to the software defined data center and are not tied to any particular hardware device. By way of example, the memory resources 110 can include volatile and/or non-volatile memory available to the VCIs 106. The VCIs 106 can be moved to different hosts (not specifically illustrated), such that a different hypervisor manages the VCIs 106. In some embodiments, the host 102 can be connected to (e.g., in communication with) a cloud automation platform 114, which can be deployed on a VCI 106.
The cloud automation platform 114 can provide a secure portal where authorized administrators, developers, or business users can request new IT services and/or manage cloud and IT resources while ensuring compliance with business policies. The cloud automation platform 114 can be used to build and/or manage a multi-vendor cloud infrastructure, for instance. One example of such a cloud automation platform is VMware's vRealize Automation (vRA), though embodiments herein are not so limited.
A UI 118 of the cloud automation platform 114 can be used to build and/or manage a cloud infrastructure. One example of such a development platform is VMware's vRealize Automation (vRA), though embodiments herein are not so limited. vRA is a cloud management layer that sits on top of one or more clouds (e.g., different clouds). It can provision complex deployments and offer governance and management of these workloads and the resources in the cloud. The cloud automation platform 114 can be designed to automate multiple clouds with secure, self-service provisioning.
Integration wise, the starting point for the whole flow is the so-called Catalog service 220 which in short accepts provider registrations. Any microservice can provide users with new resource types or day-2 actions if it is registered within the Catalog. In the current scenario, there is a Form service 224 which is a provider that acts as a proxy between the user portal and the ABX service 226 in order to execute serverless functions. The form service 224 can include a form service action execution API and a form service admin portal, for instance.
Whenever a user requests a Custom Resource Type based on ABX actions, the request gets sent to the Catalog service 220 which in turn sends it to the Blueprint service 222. From there, the Blueprint service 222 decides on the appropriate provider which should handle this request. In the cases for ABX-based Custom Resource Types, the selected provider is the Form service 224. After the request arrives, the Form service 224 checks the resource type specified in the request and selects the actions corresponding to the requested operation. When the operation is supposed to be performed on a Custom Resource Type based on ABX actions, then the definition of the Custom Resource Type is retrieved by the Form service database, where this information is present. Then, from the Custom Resource Type information the Create, Read, Update and Delete operations are extracted. According to the data in the request, the appropriate ABX operation is started. If the request is intended for a Custom Resource Type, then it needs to be a day-2 operation for a built-in type. In that case, the Form service 224 retrieves information about the day-2 operation, where it stores which procedure needs to be initiated and sends entire relevant information in a request to the ABX service 226.
Finally, Form service 224 sends a request to the ABX service 226 containing the relevant input information provided by the user in the UI portal. Thereafter, ABX service 226 receives this request and starts a serverless function on an appropriate cloud endpoint 228.
As shown in the example illustrated in
The name field 338 can be used to input a name of the resource action to be created. The display name 340 can be used to input a name to be displayed (e.g., during deployment) for the resource action to be created. In some embodiments the display name and the name of the resource action will be the same. In other embodiments, the display name and the name will be different. The description field 342 can be used to input a description of the resource action. The activate toggle 344 can be selected if immediate availability of the resource is desired. The scope toggle 346 can be selected in order to define which project(s) can consume this resource. If, for example, all projects are desired (default) then the toggle may be selected.
The resource type field 348 can be used to input the resource type that the action is to be associated with (e.g., bound to). In an example, the resource type is Cloud.vSphere.Machine. The action/workflow field 350 can be used to input the action (e.g., ABX action). In some embodiments, an action can be selected from a dropdown list of preexisting actions. The create button 352 can be selected to associate the input resource type with the selected ABX action to create the resource action.
Once the resource action is created via the UI illustrated in
The present disclosure is not limited to particular devices or methods, which may vary. The terminology used herein is for the purpose of describing particular embodiments, and is not intended to be limiting. As used herein, the singular forms “a”, “an”, and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the words “can” and “may” are used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.”
The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 108 may reference element “08” in
The number of engines can include a combination of hardware and program instructions that is configured to perform a number of functions described herein. The program instructions (e.g., software, firmware, etc.) can be stored in a memory resource (e.g., machine-readable medium) as well as hard-wired program (e.g., logic). Hard-wired program instructions (e.g., logic) can be considered as both program instructions and hardware.
In some embodiments, the interface engine 454 can include a combination of hardware and program instructions that is configured to provide an interface of a cloud automation platform. The interface can include a first portion configured to receive an indication of a resource type of a software-defined datacenter (SDDC). The interface can include a second portion configured to receive an indication of an Action Based Extensibility (ABX) action. The interface can include a third portion configured to receive an input to associate the resource type with the ABX action to create a resource action. In some embodiments, the execution engine 456 can include a combination of hardware and program instructions that is configured to execute the resource action in a deployed blueprint containing a resource of the resource type to modify an internal state of the resource.
Memory resources 510 can be non-transitory and can include volatile and/or non-volatile memory. Volatile memory can include memory that depends upon power to store information, such as various types of dynamic random access memory (DRAM) among others. Non-volatile memory can include memory that does not depend upon power to store information. Examples of non-volatile memory can include solid state media such as flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM), 3D cross-point, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magneto random access memory (MRAM), Spin Transfer Torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide based RRAM (OxRAM), negative-or (NOR) flash memory, magnetic memory, optical memory, and/or a solid state drive (SSD), etc., as well as other types of machine-readable media.
The processing resources 508 can be coupled to the memory resources 510 via a communication path 560. The communication path 560 can be local or remote to the machine 558. Examples of a local communication path 560 can include an electronic bus internal to a machine, where the memory resources 510 are in communication with the processing resources 508 via the electronic bus. Examples of such electronic buses can include Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), Advanced Technology Attachment (ATA), Small Computer System Interface (SCSI), Universal Serial Bus (USB), among other types of electronic buses and variants thereof. The communication path 560 can be such that the memory resources 510 are remote from the processing resources 508, such as in a network connection between the memory resources 510 and the processing resources 508. That is, the communication path 560 can be a network connection. Examples of such a network connection can include a local area network (LAN), wide area network (WAN), personal area network (PAN), and the Internet, among others.
As shown in
Each of the number of modules 554, 556 can include program instructions and/or a combination of hardware and program instructions that, when executed by a processing resource 508, can function as a corresponding engine as described with respect to
The machine 558 can include an interface module 554, which can include instructions to provide an interface of a cloud automation platform. In some embodiments, the interface includes a first portion configured to receive an indication of a resource type of a software-defined datacenter (SDDC), a second portion configured to receive an indication of an Action Based Extensibility (ABX) action, and a third portion configured to receive an input to associate the resource type with the ABX action to create a resource action. The machine 558 can include an execution module 556, which can include instructions to execute the resource action in a deployed blueprint containing a resource of the resource type to modify an internal state of the resource.
The present disclosure is not limited to particular devices or methods, which may vary. The terminology used herein is for the purpose of describing particular embodiments, and is not intended to be limiting. As used herein, the singular forms “a”, “an”, and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the words “can” and “may” are used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.”
The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 108 may reference element “08” in
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Various advantages of the present disclosure have been described herein, but embodiments may provide some, all, or none of such advantages, or may provide other advantages.
In the foregoing Detailed Description, some features are 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 disclosed embodiments of the present disclosure have to use more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
