Data plane API in a distributed computing network

Abstract

Embodiments relate to data plane APIs in distributed computing networks. Some embodiments relate to a distributed computing system comprising a plurality of computing nodes for providing resources to a user and a two or more tier hierarchy of controllers that couple the computing nodes to a user interface via a control plane, wherein at least one computing node receives a local application program interface (API) call from an application running on the at least one computing node, the local API call causing the at least one computing node to configure a local resource without requiring a command from the control plane.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on June 27, 2017, with application number "201780037925.5" and invention title "Data Plane API in Distributed Computing Networks". Background Technology

[0002] In distributed computing service environments (such as cloud service networks), users have limited exposure to the physical or logical layers of the network. Typically, users access their accounts through a management portal that accepts their configuration and management commands. The distributed computing network then routes commands as appropriate through the cloud service stack to configure and manage the user's resources. Therefore, whenever a user needs to perform any configuration or management action, the command must traverse the entire cloud service stack, starting from the user interface portal. Summary of the Invention

[0003] The present invention is provided to introduce a choice of concepts in a simplified form, which is further described below in the detailed description. The present invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the protected subject matter.

[0004] The implementation provides a control plane application programming interface (API) that operates at the lowest layer of the cloud service stack. Specifically, the API is used to implement control endpoints with the utmost fine-grained precision. For example, the API can execute commands at the virtual machine (VM) layer using an agent on a server node. This allows VMs to cycle without having to restart the entire server node. The control plane API can also allow nodes to self-manage. Attached Figure Description

[0005] To further clarify the above and other advantages and features of the embodiments of the present invention, a more specific description of the embodiments of the present invention will be provided with reference to the accompanying drawings. It will be understood that these drawings merely depict typical embodiments of the invention and are therefore not intended to limit its scope. The invention will be described and explained using additional specificity and detail through the use of the accompanying drawings, in which:

[0006] Figure 1 It is a high-level block diagram of a system with multiple distributed nodes.

[0007] Figure 2 This is a table illustrating the different stages during which the operation is primarily applied.

[0008] Figure 3 It is a block graph of nodes configured at the local layer.

[0009] Figure 4 The diagram illustrates a node with resources configured at the local tier.

[0010] Figure 5 This is a flowchart illustrating a method for controlling resources in a distributed computing system, based on an example embodiment.

[0011] Figure 6 This is a high-level block diagram of an example data center that uses the data plane API disclosed herein to provide cloud computing or distributed computing services. Detailed Implementation

[0012] Figure 1 This is a high-level block diagram of a system 100 with multiple distributed nodes 101. Node 101 can represent, for example, a server in a single data center or multiple data centers, as part of a cloud service network. Node 101 can host containers 102, which is a generic name for the types of technologies that can host application logic. For example, container 102 can host storage devices 103, websites 104, virtual machines (VMs) 105, or other forms of encapsulation. Container 102 is a unit of computation that holds code (e.g., application-specific code, VM code, OS code, etc.). Many containers 102 can run simultaneously on a single server node, and containers can be moved from node to node.

[0013] Resources on node 101 are used by data center tenants (such as cloud service network customers). To access node 101, users access a global portal 106, which may be a web-based user interface (UI) that provides access for, for example, account setup, maintenance, and configuration. Portal 106 provides users with access to one or more regional controllers 107, which allow users to create and configure resources. Regional controllers 107 provide access to one or more cluster controllers 108, which control the node 101 assigned to the user.

[0014] To deploy container 102, the tenant selects the size and number of hosts, and then the container service manages the deployment details. The tenant can provide models specifying the extent to which local decisions are allowed within the container (such as scale-up, scale-down, local restart, network allowance criteria, disk attach / remove criteria, container run size options, etc.). For simplicity, the example illustrated here refers to container 102 hosting VM 105, but it will be understood that the data plane API can be used by container 102 hosting any application logic. To deploy VM 105, for example, a user logs into portal 106 and requests a specific VM model to be deployed (e.g., the VM model can specify parameters such as "running no more than X replicas of the VM, no less than Y replicas of the VM, and starting with N replicas"). The portal forwards the instruction to region controller 107, which identifies the cluster controller 108 controlling a set of nodes 101 that will host the VM. Cluster controller 108 then instructs node 101n to load VM 105. When instructions are provided via portal 106, the commands must traverse the entire stack down to node 101.

[0015] Figure 1 The system can represent components in a virtual software-defined network running across multiple data centers. The network's control plane and data plane can be distributed across data centers. The control plane carries command packets for the deployment and management of applications and services on control node 101. The data plane supports the execution of applications while they are running. Figure 1 This is a highly simplified diagram of the system. Those skilled in the art will understand that any number of layers in the control plane are permitted, and that systems incorporating this invention are not limited to only area controllers and cluster controllers.

[0016] Figure 2 This is a table illustrating the operations that primarily occur during different phases of the application. The control plane handles a large number of operations during application deployment and decomposition. During application runtime, the data plane actually handles all operations. In the existing system, to control or manage operations on node 101 (such as restarting VM 105), instructions must be initiated to the region controller 107 via portal 106 or via instruction 109 on the stack. In response to instruction 109, the region controller 107 generates instructions to the cluster controller 108 via the control plane, which then forwards the instructions to node 101 on the control plane. Node 101 then executes the instructions by restarting VM 105. Similarly, cluster-level operations (such as increasing or decreasing the number of active VMs 105 across node 101) must be initiated at the portal 106 or region controller 107 layer in the existing system.

[0017] For VM 105 to make API call 109, the VM will typically require a certificate or other authorization from the data center to perform such an operation. This certificate is associated with a level of freedom that is not normally provided to the running system. By entering the normal control plane path, the application will have the ability to make a wide variety of changes. This will make it more difficult to defend against runaway services running on the system, such as an uncontrolled autonomous repair engine that limits the number of VMs available for application expansion during runtime. Furthermore, requiring all VM control and management commands to be initiated above the control plane adds latency to their execution.

[0018] The embodiments disclosed herein allow node 101n or VM 105 to generate local API calls 110 at the data plane layer to perform certain node-level operations. Alternatively, node 101a or VM 105 implements API calls 111 to cluster controller 108 to perform certain cluster-level operations. The use of these APIs 110 avoids control plane involvement in operations that do not affect local nodes or services outside the cluster. In existing systems, requests for configuration changes, such as instructions for an initial number of VMs (e.g., “run N copies of the target VM”), are passed down to the control plane to cause new VMs to run on a specific set of nodes. In addition to the initial target, the APIs disclosed herein differ from normal control plane input by specifying permissible limitations. The data plane APIs disclosed herein do not require traversal of the control plane. Instead, data plane API calls are made locally and grant degrees of freedom for limited local decisions. For example, data plane API calls allow certain actions within parameters specified in a particular model defining the target resource. This allows compute nodes to make decisions regarding the scaling up or scaling down of VMs at the local layer. Data plane API calls generate local operations within those container model parameters, such as scaling up, scaling down, local restart, network permission criteria, disk attachment / removal criteria, resizing container run size, etc.

[0019] The following examples illustrate the types of local management that can be provided to data center nodes without invoking the control plane.

[0020] Automatic cleanup of VMs. This operation can be used to restart VMs running potentially corruptible software, so that when restarted, the VM is known to be free of either corruptible software or corruptible state. Applications that need to restart and clean up VMs can call the automatic cleanup API at the node layer. The application makes the API call that initiates the VM restart, and if the VM has not restarted within a specified period (e.g., N minutes), the API forces the VM to restart. By making these statements available at the node layer, tenants can manage their VM pools locally without invoking the control plane. Furthermore, these calls do not have to be made at the top of the stack; they will require the relevant instructions to be propagated down the stack from the control plane.

[0021] Cleaning up remote VMs. This is a variation of the automatic cleanup API described above. Using this API, the first VM or instance of an application running on the first VM can force the cleanup of a second VM to restart. For example, a local work queue manager on a VM can drive coordination with other VMs that have finished their work.

[0022] Limited scaling. This API allows tenants to launch new VMs up to pre-allocated limits. Pre-allocated limits can be defined, for example, in a tenant's account or in a deployment model, giving tenant permissions to perform limited operations at the node or cluster tier.

[0023] Limited scaling down. This API allows tenants to disable the limit on VMs scaling down to pre-allocated space.

[0024] Network Attach / Tear Down. This API allows tenants to attach VMs to a specific network (such as a tenant's virtual network) during certain operations. This allows users to access the network when needed and then tear it down when finished without having to call the control plane every time.

[0025] Disk Attach / Remove. This API allows tenants to attach data disks to VMs as needed and then remove them when they are no longer required.

[0026] Resizing. This API allows tenants to modify the container runtime size within the limits defined by the container model.

[0027] Tenants may be able to invoke other operations (such as hibernation and container relocation) directly from the data plane.

[0028] These APIs do not require changes to the data center topology. Depending on the API invoked, the operation is called at the appropriate layer within the data center topology. For example, an auto-cleanup operation can be called at the node layer, and a scale-up / scale-down operation can be called at the cluster controller layer.

[0029] API calls are functional statements of operations requested without requiring tenants to have knowledge of the data center architecture. Therefore, tenants do not need to define how the operation should be performed or which elements of the data center need to be included in the operation. For example, a VM or an application running on a VM can simply request an automatic cleanup API to restart the VM without having to identify a specific server in the data center. This allows tenants to implement these operations even if the VM has been moved or if the internal structure of the data center has changed.

[0030] Figure 3 This is a block diagram of node 301, which can be a specific server in a data center. Operating system 302 controls the operation of node 301. Node 301 hosts multiple VMs 303, which communicate with the operating system via an internal bus or a wired server 304. VMs 303 can make local requests to host 301 through wired server 304. An external bus or network 305 allows the node to communicate with controller 306 or other nodes (not shown).

[0031] Code running on the local VM 303 can call local management APIs (such as those described herein). For example, code running on a specific VM 303 can call the auto-cleanup API to request node 301 to restart the VM. Host node 301 can then take action locally to restart the VM without issuing external requests or requiring instructions from the data center control plane.

[0032] Figure 4 The diagram illustrates a node 401 with an operating system 402. Node 401 is hosting at least four VMs 403a-d. In the illustrated example, VM1 403a is managing jobs assigned to node 401. During normal operation, VMs 403b-d work on jobs assigned by VM1 403a. If one of VMs 403b-d stops responding to VM1 403a or otherwise operates inappropriately, VM1 403a can send an API call to the host operating system 402, requesting the failed VM to be restarted. For example, if VM3 403c stops responding to network packets from VM1 403a or fails to perform its assigned job, the managing VM can request VM3 403c to be restarted or cleaned up. If VM1 403a and VM3 403c are on the same host node 401, then node 401 can then locally decide whether to restart or modify VM3 403c.

[0033] In an alternative embodiment, VM1 and VM3 can be on different host nodes or servers, in which case API calls from VM1 can be routed to a higher layer (such as to the cluster controller that oversees the two host nodes). API calls from VM1 403a can be forwarded by the host node's operating system or can be automatically routed to a higher layer, depending on how the data center is configured to handle this type of API call. If the API call is routed to a higher layer, the cluster controller can then locally decide whether to instruct the host node of VM3 to restart or clean up VM3. As described relative to host node 401, the cluster controller can also act locally to restart VM3 without issuing external requests or requiring instructions from the data center control plane.

[0034] Figure 5 This is a flowchart illustrating a method for controlling resources in a distributed computing system, according to an example embodiment. The distributed computing system may include, for example, multiple compute nodes that provide resources to users. The distributed computing system includes two or more layers of controllers that couple the compute nodes to the user interface via a control plane. In step 501, the distributed computing system receives a model defining the logic of a VM or other container application to be hosted. The model may specify, for example, the extent to which local decisions are permitted within the container (such as scaling up, scaling down, local restart, network permission criteria, disk attach / remove criteria, container run size options, etc.). In step 502, the portal forwards VM deployment instructions across the control plane of the distributed computing system to one or more nodes or servers that will host the VM. In step 503, the VM is deployed and run on the nodes under the control of a local controller (such as a cluster controller).

[0035] In step 504, the node receives a local API call from the VM or an application running on the VM requesting local configuration changes. In step 505, the node configures the VM in response to the local API call without requiring commands from the control plane. In response to the API call, the node can clean up or restart the VM, clean up or restart another VM, start one or more new VMs, shut down one or more VMs, attach the VM to a communication network or disk, detach a container from the communication network, etc.

[0036] Figure 6 This is a high-level block diagram of an example data center 600 that provides cloud computing or distributed computing services using data plane APIs as disclosed herein. Data center 600 may be included in... Figures 1 to 5The features disclosed herein. Multiple servers 601 are managed by a data center management controller 602. A load balancer 603 distributes requests and workloads across network 601 to prevent any single server from becoming overwhelmed. The load balancer 603 maximizes the available capacity and performance of resources within data center 600. A router / switch 604 supports data traffic between servers 601 and between data center 600 and external resources and users (not shown) via an external network 605, which may be, for example, a local area network (LAN) or the Internet.

[0037] Server 601 may be a standalone computing device and / or an individual blade within a rack that can be configured as one or more server devices. Server 601 has an input / output (I / O) connector 606 that manages communication with other database entities. One or more host processors 607 on each server 601 run a host operating system (O / S) 608, which supports multiple virtual machines (VMs) 609. Each VM 609 may run its own O / S, such that each VM O / S 160 on the server may be different, the same, or a mixture of both. VM O / S 160 may be, for example, different versions of the same O / S (e.g., different VMs running...). Different current and older versions of the operating system. Additionally, or alternatively, VMO / S can be provided by different manufacturers (e.g., some VMs run...). Operating system, while other VMs are running. (Operating system). Each VM 609 may also run one or more applications (Apps) 611. Each server 601 also includes a storage device 612 (e.g., a hard disk drive (HDD)) and memory 613 (e.g., RAM), which can be accessed and used by the host processor 607 and VM 609 for storing software code, data, etc. In one embodiment, VM 609 may employ a data plane API as disclosed herein.

[0038] Data Center 600 provides pooled resources on which customers or tenants can dynamically provision and scale applications as needed without having to add servers or additional networks. This allows tenants to obtain the computing resources they need without having to acquire, provision, and manage infrastructure on a per-application, self-organizing network basis. Cloud computing data center 600 allows tenants to dynamically scale resources up or down to meet their current business needs. Furthermore, data center operators can provide usage-based services to tenants, so that they pay only for the resources they use when they need them. For example, a tenant might initially use a VM 609 on server 601-1 to run their application 611. As demand for application 611 increases, data center 600 can activate additional VMs 609 on the same server 601-1 and / or on a new server 601-N as needed. If demand for the application later decreases, these additional VMs 609 can be deactivated.

[0039] Data center 600 can provide guaranteed availability, disaster recovery, and backup services. For example, the data center can designate a VM 609 on server 601-1 as the primary location for a tenant's applications, and in the event of a failure of the primary VM or server 601-1, a second VM 609 on the same or a different server can be activated as a standby or backup. Without requiring tenant intervention, database manager 602 automatically moves incoming user requests from the primary VM to the backup VM. Although data center 600 is illustrated as a single location, it will be understood that server 601 can be distributed across multiple locations globally to provide additional redundancy and disaster recovery capabilities. Furthermore, data center 600 can be an on-premises private system serving a single enterprise user, or a publicly accessible distributed system serving multiple unrelated customers and tenants, or a combination of both.

[0040] Domain Name System (DNS) server 614 resolves domains and hostnames to IP addresses for all roles, applications, and services in data center 600. DNS log 615 maintains a record of which domain names have been resolved by roles. It will be understood that DNS is used here as an example and other name resolution services and domain name record services can be used to identify dependencies. For example, in other embodiments, IP or packet debugging, code instrumentation, or code tracing.

[0041] The Data Center Health Monitor 616 monitors the health of the physical systems, software, and environment within the Data Center 600. When problems are detected using servers, blades, processors, or applications within the Data Center 600, or when network bandwidth or communication issues arise, the Health Monitor 616 provides feedback to the Data Center Manager.

[0042] Access control service 617 determines whether a user is permitted to access specific connections and services on cloud service 600. Directory and identity management service 618 authenticates user credentials used by tenants on cloud service 600.

[0043] An example distributed computing system includes: multiple compute nodes for providing resources to users; and a two- or more-layered hierarchy of controllers that couples the compute nodes to the user interface via a control plane, wherein at least one compute node receives local API calls from code executed on at least one compute node, the API calls enabling at least one compute node to configure local resources without requiring commands from the control plane.

[0044] In an additional embodiment, the resource is a container specified by a model that defines the restrictions that local decisions are allowed to be made.

[0045] In additional embodiments, the container model defines a virtual machine, a specific application, or an operating system.

[0046] In an additional embodiment, local API calls enable compute nodes to automatically clean up containers running code.

[0047] In an additional embodiment, local API calls cause compute nodes to clean up containers on the same compute node other than those on the running node.

[0048] In an additional embodiment, local API calls cause the compute node to start one or more new containers.

[0049] In an additional embodiment, a local API call causes the compute node to shut down one or more containers.

[0050] In an additional embodiment, local API calls cause compute nodes to attach containers to a communication network.

[0051] In an additional embodiment, a local API call causes the compute node to attach the container to the disk.

[0052] In an additional embodiment, local API calls enable compute nodes to resize the runtime space available for containers.

[0053] In an additional embodiment, the system also includes a cluster controller coupled to two or more compute nodes, wherein a local API call from a first container on a first compute node causes a second container on a second compute node to be cleaned up.

[0054] In an additional embodiment, the system also includes a cluster controller coupled to two or more compute nodes, wherein a local API call from a first container on a first compute node causes a second container on a second compute node to start.

[0055] An example method for controlling resources in a distributed computing system is implemented on a computer and includes: receiving local API calls from an application running on a compute node in the distributed computing system, and configuring local resources in response to the local API calls without requesting commands from the control plane.

[0056] In other embodiments of the method, the distributed computing system includes multiple computing nodes for providing resources to users, and the distributed computing system includes a two- or more-layered hierarchy of controllers that couple the computing nodes to the user interface via a control plane.

[0057] In other embodiments of the method, the resources include containers, and the application includes code that executes on the containers.

[0058] Other embodiments of the method include configuring local resources in response to API calls without requiring commands from the control plane.

[0059] Other embodiments of the method include: automatically cleaning up the container in response to API calls.

[0060] Other embodiments of the method include: starting one or more new containers or shutting down one or more containers in response to a local API call.

[0061] Other embodiments of the method include attaching the virtual machine to a communication network or disconnecting the container from the communication network in response to a local API call.

[0062] Other embodiments of the method include attaching the container to the disk or detaching the container from the disk in response to a local API call.

[0063] Although the subject matter has been described in language specific to structural features and / or methodological actions, it will be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A computer-implemented method for controlling resources in a distributed computing system, the distributed computing system comprising multiple computing nodes, the computer-implemented method comprising: Receive a request to deploy a container based on a model, wherein the model specifies limitations on local decision-making; The control plane across the distributed computing system forwards deployment instructions for the container to the computing nodes among the plurality of computing nodes; Deploy the container on the computing node; Receive local application programming interface (API) calls from the container at the compute node; Determine that the local API call is within the constraints imposed on local decision-making; as well as Local resources can be configured in response to the local API calls, without requiring commands from the control plane.

2. The computer-implemented method of claim 1, wherein the model is at least in part based on information received from the tenant.

3. The computer-implemented method of claim 1, wherein the local API call causes the compute node to automatically clean up the virtual machines included in the container.

4. The computer-implemented method according to claim 1, wherein, The local API call is routed to the cluster controller and causes the second compute node to clean up the virtual machines on the second compute node, which is coupled to the cluster controller.

5. The computer-implemented method of claim 1, wherein the local API call causes one or more new containers to start within pre-allocated constraints.

6. The computer-implemented method of claim 5, wherein the local API call is routed to a cluster controller and causes a second container on a second compute node to start, the compute node and the second compute node being coupled to the cluster controller.

7. The computer-implemented method of claim 1, wherein the local API call causes the compute node to shut down one or more containers within pre-allocated limits.

8. The computer-implemented method of claim 1, wherein the local API call causes the computing node to attach the container to the communication network.

9. The computer-implemented method of claim 1, wherein the local API call causes the compute node to attach the container to the disk.

10. The computer-implemented method of claim 1, wherein the local API call causes the compute node to adjust the size of the runtime space available for the container.

11. A computer-implemented method, comprising: At the computing node of the distributed computing system, a local application programming interface (API) call is received for an operation associated with a local resource of the distributed computing system, wherein the local API call does not identify the location of the local resource in the distributed computing system. Ensure that the local API call is within the constraints of local decision-making; The local API calls are routed within the distributed computing system, wherein the local API calls are routed below the control plane; as well as Perform the operation specified in the local API call without requiring commands from the control plane.

12. The computer-implemented method of claim 11, wherein the local API call does not define how the operation should be performed.

13. The computer-implemented method of claim 11, wherein the local API call does not define which elements of the distributed computing system are included in the operation.

14. The computer-implemented method of claim 11, wherein the local resource is located on the computing node, and the local API call is routed to the computing node.

15. The computer-implemented method of claim 11, wherein the local resource is located on a second compute node, and the local API call is routed to a cluster controller that oversees the compute node and the second compute node.

16. A computer storage device, comprising instructions executable by one or more processors to cause a computing system to perform the following operations: Receive local application programming interface (API) calls to modify target resources located in the data center; Determine that the local API call is within the constraints of local decision-making and falls within the parameters specified in the model defining the target resource; and Modify the target resource based on the local API call, without requiring instructions from the control plane of the data center.

17. The computer storage device of claim 16, wherein the target resource is an existing container.

18. The computer storage device of claim 16, wherein the target resource is a new container.

19. The computer storage device of claim 16, wherein the target resource resides on a first compute node, and the local API call is received from a container on a second compute node different from the first compute node.

20. The computer storage device of claim 16, wherein the data center comprises two or more layers of a plurality of computing nodes and a controller, the controller coupling the plurality of computing nodes to a user interface via the control plane.

Images