Configurable edge device platform

Abstract

This invention provides a computing device and method for provisioning different edge devices according to different manifests. [Solution] The method involves a computing device receiving a user request specifying a first set of services to be executed on a first cloud computing edge device, generating a first manifest based at least partially on the request, the first cloud computing edge device provisioning the first set of services according to the first manifest, the computing device receiving a user request specifying a second set of services to be executed on a second cloud computing edge device, generating a second manifest based at least partially on the request, and the second cloud computing edge device provisioning the second set of services according to the second manifest.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 17 / 531,632, filed November 19, 2021, entitled "Composable Edge Device Platforms", and U.S. Patent Application No. 63 / 173,244, filed April 9, 2021, entitled "Cloud Computing Edge Computing Device (Rover)", and these disclosures are hereby incorporated by reference herein for all purposes. These disclosures are incorporated herein by reference for all purposes.

[0002] Technical Field The present disclosure generally relates to edge device platforms. More specifically, the present disclosure relates to configuring these platforms using corresponding manifests that specify the configuration of the devices.

Background Art

[0003] Background In cloud computing, processing and storage are generally performed by one or more service providers implemented in a centralized location. Data can be received from customers at the centralized location, processed there, and then the processed (or other) data can be sent back to the customers. However, having a centralized location for cloud infrastructure components may not be ideal in various scenarios. For example, sending data to a central server for IoT (Internet When there are hundreds or thousands of IoT devices, and especially when those IoT devices are not geographically close to cloud infrastructure computing devices, traditional centralized systems are not ideal. These IoT devices can be considered to be at the "edge" in the sense that they are not close to a central server. [Overview of the Initiative] [Problems that the invention aims to solve]

[0004] Furthermore, a centralized location may not always be ideal for cloud components. For example, when data is collected in a remote area or a location without internet connectivity (e.g., by an IoT device). Current centralized cloud computing environments may not meet time-sensitive requirements when streaming data due to the latency inherent in wide-area network connectivity. Remotely generated data may need to be processed faster than traditional centralized cloud computing systems can allow (e.g., to detect anomalies). Thus, managing traditional cloud computing environments that rely on centralized components presents challenges. For example, a centralized workflow manager may not be optimal for managing workflows of geographically dispersed devices. [Means for solving the problem]

[0005] Brief overview Technologies (e.g., methods, systems, code or instructions executable by one or more processors) for configuring various platforms such as cloud infrastructure and edge computing devices (e.g., computing devices configured to provide computing and storage in remote locations isolated from centralized data centers and without public / private network connectivity). A non-temporary computer-readable storage medium containing the stored information is provided. In some embodiments, configuring these platforms may utilize a corresponding manifest that specifies the configuration for the device. This specification describes various embodiments of methods, systems, and non-temporary computer-readable storage media containing programs, code, or instructions executable by one or more processors.

[0006] One embodiment relates to a method for configuring a platform for cloud infrastructure edge computing devices (sometimes simply called edge devices). The method may include a computing device operated by a cloud computing provider receiving a first user request that includes a first manifest specifying a first set of services to be run on a first cloud computing edge device. In some embodiments, the cloud computing edge device may be a device configured to run selectively within an isolated computing environment while running within an isolated computing environment without access to a public network. The method may further include retrieving a first set of container images corresponding to the first set of services to be run on the first cloud computing edge device. The method may further include provisioning a container containing the first set of container images on the first cloud computing edge device in accordance with the first user request. The method may further include receiving a second user request that includes a second manifest specifying a second set of services to be run on a second cloud computing edge device. The method may further include retrieving a second set of container images from memory corresponding to a second set of services to be run on the second cloud computing edge device. The method may further include provisioning a second container set, including a second container image set, to a second cloud computing edge device in accordance with a second user request. In some embodiments, the second cloud computing edge device may be provisioned with the same or different services as those provisioned on the first cloud computing edge device.

[0007] In some embodiments, a computing device is disclosed. The computing device may consist of one or more processors and one or more memories comprising executable instructions, which, when executed by the one or more processors, cause the computing device to perform the methods disclosed in the above paragraphs.

[0008] Some embodiments disclose a non-temporary computer-readable storage medium that, when executed by one or more processors of a computing device, contains computer-executable instructions that cause the computing device to perform the methods disclosed herein. [Brief explanation of the drawing]

[0009] [Figure 1] This block diagram shows an exemplary high-level architecture for a cloud infrastructure edge computing device according to at least one embodiment. [Figure 2] A block diagram shows an exemplary architecture for connecting a user computing device to a cloud infrastructure edge computing device, according to at least one embodiment. [Figure 3] A block diagram showing an exemplary enclosure for a cloud infrastructure edge computing device according to at least one embodiment. [Figure 4] This is an exploded view showing a cloud infrastructure edge computing device according to this specification, according to at least one embodiment. [Figure 5] This is a block diagram illustrating an exemplary computer architecture for a cloud infrastructure edge computing device according to at least one embodiment. [Figure 6] A block diagram showing a distributed computing cluster including one or more edge computing devices according to at least one embodiment. [Figure 7]This block diagram shows a control plane and flow for executing a workflow by one or more components of a cloud infrastructure edge computing device, according to at least one embodiment. [Figure 8] A block diagram showing a flow for generating a manifest from a user request, according to at least one embodiment. [Figure 9] A block diagram showing an exemplary manifesto according to at least one embodiment. [Figure 10] This block diagram shows another flow for generating a manifest from a user request, according to at least one embodiment. [Figure 11] Block diagram showing an architecture and flow for provisioning one or more data plane resources in an edge computing device, according to at least one embodiment. [Figure 12] This block diagram shows an exemplary method for provisioning different edge devices according to different manifests, according to at least one embodiment. [Modes for carrying out the invention]

[0010] Detailed explanation The following description will explain various embodiments. For explanatory purposes, specific configurations and details will be described to provide a complete understanding of the embodiments. However, it will be apparent to those skilled in the art that embodiments can be carried out without specific details. Furthermore, well-known features may be omitted or simplified in order to avoid obscuring the embodiments described.

[0011] Introduction In some cases, cloud-integrated edge services (e.g., implemented in edge computing devices) may be essential to address the desire to run time-constrained cloud infrastructure applications outside of a centralized data center (e.g., a cloud infrastructure service provider's data center). Such edge computing devices can provide computing and storage at the edge and / or in isolated locations (e.g., remote locations isolated from a centralized data center and without public / private network connectivity (e.g., internet, VPN, dedicated connections)) to enable low-latency processing at or near the point of data generation and ingestion. In some cases, a fleet of portable (and sometimes durable for protection) server nodes (e.g., a fleet of edge devices) may be configured to physically provide cloud infrastructure services to remote locations where cloud technologies have been considered technically impossible or too costly to implement.

[0012] For customers (e.g., users), edge computing devices are cloud computing devices that include virtual machines (VMs), containers, functions, and data files. It can act as an extension of the infrastructure, and block volume or object store services can be delivered from the cloud infrastructure tenancy (e.g., a tenancy of a centralized cloud computing environment) with little to no change, and the customer experience may remain unchanged from the centralized cloud computing experience. Furthermore, edge computing devices are part of the control plane and data infrastructure of the cloud infrastructure service provider. It can be configured to implement both the data plane and the control plane. The data plane can be configured to manage data storage, transfer, processing, etc., while the control plane can be configured to control various services and architectural components of the computing device. When an edge computing device is properly connected to a customer's computing device (e.g., via a local area network (LAN)), the customer can utilize IaaS services (or at least a subset thereof) using the same SDKs and APIs as those used in centralized cloud services.

[0013] The edge computing device can be provided to the customer in a pre-configured form such that the only actions required of the customer are to connect the node to a network (e.g., a local / on-premises network accessible by the user computing device), power it on, and / or log in. The device can be pre-configured in various ways based on the customer's preferences / requirements or can be made in any of various configurations (storage-centric, compute-centric, etc.). The node or cluster of nodes is intended to be portable and movable. That is, when moved and set up again (or used while in transit), the deployment continues to execute from where it was powered off (or continuously). The edge computing device can also monitor the availability of wide area network (WAN) connections (such as the Internet), and when connected to the WAN, can synchronize customer data and management data with the cloud. AN) connection (Internet, etc.), and when connected to the WAN, can synchronize customer data and management data with the cloud.

[0014] Potential use cases for edge computing devices include storage and processing, compute and I / O-intensive applications, machine learning, remote computing, low-latency databases and analytics, and data collection and migration. More specifically, edge devices can be used to store and process large volumes of image, video, audio, and IoT sensor data generated in environments where WAN connectivity is potential or unavailable (e.g., remote locations, oil offshore platforms). This data, after being preprocessed, filtered, compressed, and / or protected, can be transported or transferred to a cloud service provider, where it can be further processed by centralized servers (e.g., traditional cloud service providers). The device can also be used in compute and I / O-intensive applications where low latency is critical, such as tactical reconnaissance or 5G communications. It can also be used for machine learning, running cloud-trained models in a remote location to improve efficiency, intelligence, and / or productivity in manufacturing, document management, transportation, oil and gas extraction, and / or telecommunications. It can also be used for remote computing requiring a high level of security and data confidentiality. Furthermore, this device can be used for low-latency database and analytics workloads, and more applications will be optimized for it over time. Additionally, the device can be used, for example, for data collection and migration of large sets of object and database management system (DBMS) data to cloud service providers, at a faster and lower cost than WAN transfers.

[0015] Edge devices can natively support the distributed cloud paradigm, separate complex multi-step compute workflows into individual components, and these components can be deployed on the infrastructure of edge devices, on-premises, and / or in the cloud. Examples of such distributed workflows are shown in the following scenarios. A large amount of data is collected by an edge computing node (e.g., a disconnected edge computing device) deployed on an airplane (e.g., a military jet) during reconnaissance activities that do not have access to the Internet. This data can be preprocessed almost in real time by a machine learning model pre-trained by a cloud service provider that provided the edge device. Even in the first pass of processing the data using the model, significant anomalies can be detected and warnings (e.g., the bridge may be damaged and the troops need to be detoured) can be issued immediately to the responsible personnel. When the airplane lands, the edge computing device can be physically connected to a network (e.g., an edge station that may be deployed on the runway). A smaller dataset that has been preprocessed and filtered can be loaded at the edge station to a cluster of edge computing device nodes for final processing. The original edge computing device is released and can be loaded onto another (or the same) airplane, for example, to support the next mission. When the processing at the edge station is complete, an update to the 3D map is issued and becomes immediately available. The change set can then be uploaded by the edge station cluster to the data center and used to build future models that provide intelligent tactical predictions for reconnaissance activities and the like.

[0016] It should be understood that the following techniques can be employed in various contexts such as telecommunications, oil and gas, healthcare, hospitality, agriculture, transportation, and logistics.

[0017] The embodiments described herein address these and other issues individually and collectively. Specifically, embodiments of this disclosure provide cloud infrastructure edge computing devices.

[0018] Edge device architecture Edge computing devices (sometimes referred to as “cloud computing edge devices,” “cloud infrastructure edge computing devices,” or simply “edge devices”) extend a user’s centralized cloud computing tenancy by physically deploying the customer’s infrastructure and platform services where the data is generated—that is, at the edge, on-premises, or completely disconnected. Each deployment is created to meet the customer’s specific needs by provisioning VM instance images and data from the customer’s centralized cloud tenancy. These workloads function perfectly offline because the edge devices adapt to connectivity conditions, operate in harsh environmental conditions, and are ready to synchronize with the cloud whenever connectivity is re-established.

[0019] Figure 1 is a block diagram illustrating an exemplary high-level architecture for a cloud infrastructure edge computing device (e.g., edge device 100) according to at least one embodiment. An overview of the software and hardware components of edge device 100 is provided below.

[0020] In some examples, the edge device 100 may include a containerization engine 102 (e.g., Docker, Kubernetes, etc.) configured to implement one or more containers (e.g., corresponding to containers 104A, 104B, 104C-104N, collectively referred to as "container 104"). The containerization engine (e.g., containerization engine 102) may also be a container orchestration system for automating the deployment, scaling, and management of computer applications. In some embodiments, the containerization engine may be configured to provide OS-level virtualization to deliver software in packages called containers. These containers are isolated from each other, can utilize their respective software, libraries, and configuration files, and can communicate with each other via appropriately defined channels. In some embodiments, service 104 may provide any appropriate It may include a number of services (for example, one or more). These services may implement at least some of the centralized cloud functionality. Each service may be standalone or operate as a distributed cluster. The edge device 100 may further include a hypervisor 106 configured to implement one or more virtual machines (for example, virtual machines 108A, 108B, 108C~108N, collectively referred to as "virtual machine(s) 108" or "VM108").

[0021] In some examples, the edge device 100 includes storage 110 (e.g., object storage and / or block storage for storing local data). The edge device 100 includes an operating system (OS) 112. In some embodiments, the OS 112 may be optimized for running on the edge device and / or specialized for running on the edge device. The OS 112 may be configured to manage the hardware of the edge device 100 and support the data plane of services running on the edge device 100. The OS 112 may be configured to support a specific deployment type (e.g., a single edge device deployment or a specific edge device cluster configuration). The OS 112 may be configured to secure the edge device by prohibiting direct customer access or otherwise blocking it.

[0022] In some embodiments, the edge device 100 has any appropriate number of central processing units (CPUs) and / or hardware such as storage drives. It may include a central processing unit (CPU), graphics processing unit (GPU), random access memory (RAM) of any size, one or more ports (e.g., QSFP28, RJ45, dual ports), tamper-evident seals, or any suitable combination of the above components.

[0023] In some examples, basic system functions / services can be accessed via a RESTful API with a custom load of Linux®-based software. The virtual machine(s) 108 may individually be a kernel-based virtual machine (KVM) (for example, a virtual machine managed by a virtualization module within the Linux kernel that enables the kernel to act as a hypervisor) and / or a hardware-based virtual machine (for example, a virtual machine managed by a virtualizer such as Quick EMUlator (QEMU) that can perform hardware virtualization, enabling the virtual machine to emulate a number of hardware architectures). Storage 110 is represented as a separate component from services 104 and VM(s) 108, but can run as a container (e.g., container 104A) or within a VM (e.g., VM108A). In some examples, it may be preferable to implement storage 110 (e.g., object storage, block storage, etc.) as a container.

[0024] Figure 2 shows an exemplary architecture 200 for connecting an edge device described herein (for example, edge device 100 in Figure 1) to a computing device 202 (for example, a user computing device). 202 can be any type of computing device, including but not limited to laptop computers and desktop computers. The edge device 204 (an example of edge device 100 in Figure 1) may include a containerization engine 206 (an example of containerization engine 102 in Figure 1), a hypervisor 208 (an example of hypervisor 106 in Figure 1), and storage 210 (an example of storage 110 in Figure 1).

[0025] Furthermore, as briefly described above, the edge device 100 may include an API proxy 212 for managing RESTful API calls received from the computing device 202. API calls may enter the edge device 204 via a network interface card (NIC) 214 inside the edge device 204. The NIC 214 may be used to connect the edge device 204 to the computing device 202 via a local area network (e.g., LAN 216). API calls received by the NIC 214 may be sent to an exposed endpoint (e.g., endpoint 218) which may implement a web server. The web server can send requests to the API proxy 212, which can route the requests to the appropriate services (e.g., a containerization engine 206, a hypervisor 208, and / or storage 210). The exposed endpoint / web server may also be configured to implement a lightweight console for customer use (e.g., a user interface displayed on the computing device 202).

[0026] The lightweight console can run within a web browser (e.g., Mozilla® Firefox®) on a laptop computer, desktop computer, or other network-accessible device (e.g., connected to a local area network (LAN 216)) that is networked to edge device 204 (e.g., via a router, cable, etc.). Edge device 204 can expose an endpoint 218 for console connections, and a web server can send data to a web browser on computing device 202 via LAN 216.

[0027] Figure 3 shows an exemplary physical enclosure 300 for an edge device described herein (for example, edge device 100 in Figure 1). Various different form factors, shapes, colors, etc., can be employed to construct a (e.g., durable) box capable of housing the edge computing device. The physical enclosure may include a handle 302, as shown, and may include tamper-evident elements such as an indicator that would become apparent if someone broke open the enclosure. In this way, a service provider providing the edge computing device can assure that the device has not been tampered with. In some examples, the physical enclosure 300 may be impossible to open. However, in some cases, it may be possible, but only with extreme measures.

[0028] Figure 4 is an exploded view showing a cloud infrastructure edge computing device described herein (for example, edge device 400, which is an example of edge device 100 in Figure 1) according to at least one embodiment. Various components described with respect to Figures 1 and 2 can be communicatively mounted on one or more motherboards and / or interface cards within edge device 400. The illustrated component configuration is merely one example. The specific locations of the illustrated components are not intended to be limiting, and as stated above, any configuration capable of achieving the functions described herein is permitted. Once the components are mounted, the entire box can be closed, sealed, and locked with tamper-evident components.

[0029] The Edge Device 400 is a single enclosure. The enclosure can accommodate any number of SAS (seriously attached SCSI) solid-state drives (SSDs), and It can be designed to accommodate all other components within the enclosure (e.g., CPU, memory, GPU, etc.). The system may include one or more (e.g., 12Gb) SAS connections to each drive in a fully enclosed sheet metal enclosure designed to fit upright next to a desk, on a tabletop, or in a standard 19-inch rack mounted on L-brackets / shelves.

[0030] The system may include a tamper-proof enclosure, a front security plug with a rear security interlock function that covers the screws that hold the front bezel in place. In some embodiments, the system may include a dual-socket motherboard and any suitable capacity of DRAM. In some embodiments, the system may include any suitable number (e.g., 2, 3, etc.) of SATA SSDs, a storage controller, embedded network connectivity, one or more ports (e.g., dual ports, serial ports, etc.), one or more fans as part of a cooling system, or any suitable combination of the above.

[0031] As a non-limiting example, the edge device 400 may consist of an externally extruded aluminum case with a front secured by a ventilated bezel and a rear panel that exposes only the I / O connections necessary for data transfer and management. The mounting can be designed to accommodate any suitable motherboard, fan, and power supply.

[0032] Figure 5 is a block diagram illustrating an exemplary computer architecture of a cloud infrastructure edge computing device (for example, edge device 500, which is an example of edge devices 100 and 204 in Figures 1 and 2, respectively) according to at least one embodiment. Edge device 500 can be thought of as a cloud integration service that extends some or all of traditional cloud functionality to locations that are inaccessible to or may be inaccessible to cloud data centers. This can be achieved through portable, durable server nodes that provide cloud-like functionality in locations without WAN connectivity. This allows customers to shift selected cloud workloads to remote locations and enable intensive data processing operations near data ingestion points at the edge of the cloud infrastructure.

[0033] The edge device 500 may include any appropriate number of services (e.g., service(s) 502). Each service may run locally on the edge device 500 as a container (e.g., a Docker container). The services(s) 502 may be connected communicably via the onboard network 504 so that communication between services is encrypted (e.g., according to a security protocol such as MACsec). Each container may be assigned an onboard IP address (e.g., a static address) to which traffic can be addressed. In some embodiments, the security protocol (e.g., MACsec) is configured at provisioning time (e.g., before the edge device 500 is shipped to a user). The system software of the edge device (including the services(s) 502) may run in a secure environment protected by boot security software (e.g., Trenchboot Secure Launch). Users may be restricted from accessing the secure environment and / or the onboard network 504. To minimize the amount of resources used by these services, the service code may be compiled and stored on disk to reduce the CPU load on the edge device 500 as well as to reduce RAM space.

[0034] Some example services included in service(s) 502 are the UI console service, the identity control plane (CP) service, and the Ident Data plane (DP) service, compute application programming interface (API) service BIs, compute worker thread service, virtual network: VN) API service, block storage API service, function-as-a-service service Service, event service, object storage management service (for example, implementing a storage platform such as Ceph Storage), compute DP service (for example, the hypervisor 208 example in Figure 2), VN DP service, block storage management service, function-as-a-service API service, function-as-a-service load balancing (LB) service, function-as-a-service process threads These services include distributed data store management services (such as etcd3), dynamic host configuration protocol services, domain name system services, and network time protocol (NTP) services. Some examples of the functions are described below.

[0035] For example, a compute DP service can be configured to isolate 508 VMs on the same hypervisor host (for example, they can be pre-configured and provisioned on edge device 500). The compute DP service can isolate 508 VMs on the same hypervisor host from each other using any suitable container engine (e.g., Docker containers, MicroContainers, etc.). The compute DP service can use any suitable hypervisor (e.g., Quick Emulator (QEMU), Kernel-based Virtual). Virtual hardware emulation can be provided to VM(s) 508 using a Machine (KVM, etc.). In some embodiments, VNIC(s) 506 can be connected to any appropriate number of virtual networks (e.g., subnets of private virtual networks (PVN(s)) 505, and assigned private Internet Protocol (IP) addresses. A single VM may have multiple VNICs from different VCNs and different subnets. The maximum number of VNICs can be limited by a predefined threshold (e.g., configuration data called a "VM shape" or VNIC shape that defines the number of VNICs per VM, etc.). In some embodiments, the predefined threshold applies to each of VM(s) 508. The subnets used by VNIC(s) 506 can be separated by VLANs. In some embodiments, some or all of VNIC(s) 506 may be assigned public IP addresses and / or private IP addresses. Public IP addresses are addresses within network 520, and private IP addresses refer to IP addresses of PVN(s) 505.

[0036] In some embodiments, the edge device 500 provides network address translation (NAT) services, dynamic host configuration protocol (DHCP) services, and domain name system (domain Services such as DNS (Name System) service, Network Time Protocol (NTP) service, metadata service, and public API service. Numerous services enable various network functions. A metadata service may provide initialization data and other metadata to all VM(s) 508. In some embodiments, a DHCP service assigns private IP addresses to each of the VNIC(s) 506, and each VM(s) 508 has one or more VNICs. A DNS service may provide domain name resolution to VM(s) 508 on edge devices 500. NTP may provide time synchronization to VM(s) 508. In some embodiments, a public IP service may be implemented as part of service(s) 502. The service may allow VMs to access public APIs without assigning them a public IP address or configuring a service gateway.

[0037] In some embodiments, at least one of the VM(s) 508 may implement block (or object) storage. In some embodiments, the hypervisor associated with the virtual machine may include a library that enables the hypervisor to use a distributed data storage platform (e.g., Ceph). The library may utilize a protocol associated with the storage platform (e.g., RBD (RADOS Block Device)) to facilitate the storage of block-based data. The distributed data storage platform may be implemented on multiple virtual machines. In some embodiments, the distributed data storage platform supports the creation of snapshots and the copying of block volumes. VM images and VM block volumes may be Ceph block devices. In some embodiments, the VM(s) implementing the distributed data storage platform use system reserved resources (e.g., eight CPU cores, or any subset of the total number of CPUs available on the edge device 500). For example, to provision a boot volume, a block device image may be copied to the boot volume of the block device. The distributed data storage platform may use a block device with multiple nodes for redundancy. If some nodes fail, the block device can continue to operate. In some embodiments, a distributed data storage platform (e.g., Ceph) automatically recovers data from block devices in the event of failures in a small number of nodes. Block storage can be used to store images of any suitable deployable resources. For example, images can be used to launch VMs. In some embodiments, images can correspond to specific VM shapes (e.g., compute-heavy VMs, GPU-optimized VMs, storage VMs, etc.).

[0038] The compute API service may support operations such as 1) starting and stopping VMs, 2) stopping, starting, and restarting VMs, 3) retrieving a list of VMs and / or information about a specific VM, 4) retrieving VM console history API, 5) taking VM snapshots, and 6) attaching / detaching block volumes. In some embodiments, the compute API service can be used to call other services (e.g., compute DP service, identity DP service for authentication and authorization, etc.).

[0039] Some of the functions of other services are described in relation to Figure 7. Generally, each service may not be described in detail herein, but the general functions provided by service(s) 502 may include the functions of cloud services provided by remote cloud service providers. In some embodiments, edge devices 500 may be associated with predefined regions and / or realms so that a portion of service(s) 502 can operate as if it were operating in a cloud computing environment, even though it is running on one or more local devices (one or more edge devices) as a single instance, or whether it has public network access to the cloud computing environment associated with the customer, or may have intermittent access, and is operating as part of a distributed service. "Region" refers to a geographical location where a service center exists. "Realm" refers to a logical collection of regions. Realms may be isolated from each other and may not share data.

[0040] In some embodiments, the edge device 500 uses computing, memory, and networking resources (for example, virtual network interface cards (VNICs) 506) to perform any appropriate tasks. A number of virtual networks (e.g., PVN505) can be provided. A virtual network is a logical network that runs on top of a physical underlying network. One or more customer resources or workloads, such as virtual machines (e.g., virtual machines (VMs) 508 that run compute instances), can be deployed on these private virtual networks using PVN502. Any suitable combination of VMs 508 can perform functions (e.g., compute instances, storage, etc.) that are individually accessible via a virtual NIC (e.g., one of the virtual NICs 506). Each VM that is part of a PVN is associated with a VNIC that allows the VM (e.g., compute instance) to be a member of the PVN's subnet. The VNIC associated with a VM facilitates the communication of packets or frames to and from the VM. The VNIC can be associated with a VM when the VM is created. PVN505 can take many forms, such as peer-to-peer networks, IP networks, etc. In some embodiments, the underlying network traffic of service(s) 502 may be encrypted and / or isolated (for example, by a different PVN or subnet) from the network traffic of one or more VM(s) 508 running on the edge device 500.

[0041] Thus, the Edge Device 500 provides the infrastructure and a range of complementary services that enable customers to build and run a wide range of applications (e.g., compute instances), services, and / or storage in a highly available, physically local, and virtual-hosted environment. Customers do not manage or control the underlying physical resources provided by the Edge Device 500, but they do control the scaling up or down of virtual machines (e.g., compute instances, virtual NICs, block or object storage, etc.), the deployment of applications to those virtual machines, etc. All workloads on the Edge Device 500 may be split across different CPU sets (e.g., VMs and non-VMs). One set (e.g., non-VMs, such as workloads run by service(s) 502) utilizes a subset of the Edge Device 500's CPU cores (e.g., 8), while the other set (e.g., VM workloads, such as those run by VM(s)) utilizes a subset of the Edge Device 500's CPU cores.

[0042] The edge device 500 may be connected to a user device (e.g., computing device 202 in Figure 2) via one or more network interfaces (e.g., NIC2 and / or NIC4) and network 520 in a communicable manner for interacting with and / or managing VM(s) 508. In certain embodiments, a lightweight console may be provided on the user device via a web-based user interface that can be used to access and manage the edge device 500. In some implementations, the console is a web-based application (e.g., one of the services 502) provided by the edge device 500.

[0043] Figure 5 shows a single edge device. However, it should be understood that two or more edge devices may be used as a distributed computing cluster.

[0044] Figure 6 is a block diagram showing a distributed computing cluster 600, which includes one or more edge computing devices (for example, edge devices 602 and 604, each an example of edge device 500 in Figure 5), according to at least one embodiment.

[0045] Each edge device of the distributed computing cluster 600 may be connected via a substrate network 606 (an example of a substrate network 504 in Figure 5). In some embodiments, the edge devices of the distributed computing cluster 600 ("edge computing") An edge node (sometimes called an "edge node") may be connected by a board network 606 using one or more switches (e.g., switches 608 and / or 610). In some embodiments, NIC1 and NIC5 may include specific connectors (e.g., RJ45 connectors), and NIC3 and NIC8 may include the same or different connectors (e.g., QSFP28 100GbE connectors). In some embodiments, only one edge device of the distributed computing cluster 600 is connected to a customer network such as network 620 (an example of network 520 in Figure 5). Thus, traffic between services on an edge device can be encrypted and isolated from other traffic on a given edge device, as can traffic between distributed services operating across multiple edge devices. In some embodiments, each edge device is pre-configured as a specific node of the distributed computing cluster 600. In other embodiments, the user can configure the number and topology of edge devices in the distributed computing cluster 600.

[0046] Figure 7 is a block diagram showing a flow 700 for executing a workflow by one or more components of a cloud infrastructure edge computing device according to at least one embodiment. The components executing the flow 700 may include, but may include, more or fewer services, an API service 702, a database (DB) 704, a service 706, a hypervisor service 708, a PVN CP service, and a block storage CP service 714. In some embodiments, each service in Figure 7 is an example of a service from the services 502 of Figure 5. In some embodiments, at least some of the functions described in relation to the services in Figure 7 may be combined in any suitable combination and provided as a single service or an instance of the same service. As an example, in some embodiments, the functions of services 702-708 may be provided by a single service (for example, the compute CP service described above in relation to Figure 5). In some embodiments, the functions provided by services 702-708 may be provided by a single edge device (for example, edge device 500 in Figure 5) or by two or more edge devices (for example, edge devices 602 and 604 in Figure 6).

[0047] In some embodiments, the API service 702 may be configured to accept work requests that include intended state data describing the intended state of a set of data plane resources (e.g., VM(s) 508 in Figure 5). In a non-limiting example, a user 720 may use a user device (e.g., user device 202 in Figure 2) to access a user interface that allows for various selections indicating a request to launch a VM. User input may be received by the API service 702 (an example of a compute CP service in Figure 5), which may utilize a predefined Launch VM API to generate work requests (WRs) (e.g., WR722) and store the work requests in a distributed database (e.g., DB704). In some embodiments, DB704 may be a compute cluster configured to use etcd3 as an immediate consistency, highly available, transactional distributed database. Generally, a work request indicates the requests and information necessary to create and / or modify a data plane resource such as VM(s) 508. In some embodiments, a work request includes state information indicating the desired state of the data plane resource. In some embodiments, DB704 may be accessible to all services running on any edge device (and by services running on any suitable edge device in an edge device cluster such as distributed computing cluster 600).

[0048] Service 706 (for example, an example of the compute CP service in Figure 5) may be configured to run one or more worker processes (for example, one or more compute threads, such as compute thread 710). Some of these worker processes may be configured by Service 706 at any appropriate time to run a sequential and / or continuous predefined workflow. As an example, Service 706 may configure one or more worker threads (including, for example, compute thread 710) to monitor DB 704 for new work requests (for example, WR722). The compute threads may be configured to determine whether the work request WR722 has already been attended. In some embodiments, this involves checking a predefined storage bucket in DB 704 for a unique identifier associated with WR722. If the unique ID contained within WR722 does not appear in the bucket (or, in other aspects, indicates that the WR has not been picked up for processing), compute thread 710 (e.g., a nanny thread) may initialize a workflow thread (e.g., another instance of compute thread 710), which may then be configured to execute a workflow corresponding to compute thread 710 initiating the VM corresponding to WR722.

[0049] An initialized workflow thread may be coupled to a workflow service (not shown) in a communicative manner (for example, via the underlying network 504 in Figure 5). The workflow service may be configured to identify a predefined workflow corresponding to VM startup and therefore WR722 from one or more predefined workflows. These predefined workflows identify one or more steps / actions to be performed and the sequence for those steps in order to achieve a predefined goal (e.g., starting a virtual machine, stopping / starting a virtual machine, terminating a virtual machine, creating a block volume, deleting a block volume, etc.). The workflow thread may start the VM workflow and oversee its execution by various other entities. In some embodiments, the workflow thread may pass any appropriate portion of the intended state data of a DP resource to any appropriate combination of services.

[0050] As a non-limiting example, one or more APIs may be called to create and add VNICs as part of a workflow for starting a virtual machine (e.g., a VM hosted by hypervisor service 708). Similarly, numerous APIs may be provided for creating and / or adding block storage volume APIs. In some embodiments, a workflow thread may make any appropriate calls to one or more APIs to invoke the functions of PVN CP service 712, which may be configured to create and add VNICs. The workflow thread may then call block storage CP service 714, which may perform any appropriate actions to create and add block storage volumes. A worker thread overseeing the workflow may ensure a specified order (e.g., creating VNICs first before creating block volumes). This worker thread may be configured to catch errors and / or exceptions from one or more services that were called. If no exceptions / errors occur, the worker thread overseeing the workflow may provide the appropriate data to hypervisor service 708 (via the underlying network), which then performs the functions to create the requested VM. The hypervisor service 708 may provide the actual state data of a newly started VM. In some embodiments, a worker thread overseeing the workflow may indicate (for example, that the monitor indicates that the actual state data matches the requested state data and no changes are needed, or that the actual state data does not match the requested state data and changes to the data plane resources are needed) If it is possible to determine the status, the actual status data can be stored in DB704 for later reference.

[0051] In some embodiments, a workflow thread may be communicatively coupled to a cluster manager (not shown). The cluster manager may be configured to manage any appropriate number of compute clusters. In some embodiments, the cluster manager may be configured to manage any appropriate type of compute cluster (e.g., a Kubernetes cluster, a set of compute nodes used to run containerized applications, etc.). A workflow thread may be configured to perform any appropriate action to cause the cluster manager to perform any appropriate orchestration action on the DP resource(s) (e.g., VMs) according to instructions identified to match the DP resource(s) with intended state data. In some embodiments, a monitoring entity (e.g., a workflow thread, a thread initiated by a workflow thread) may be communicatively coupled to the DP resource(s) 116 and configured to monitor the health of the DP resource(s). In some embodiments, the monitoring entity may be configured to store any appropriate health data in DB704.

[0052] The specific operations and services discussed in relation to Figure 7 are illustrative in nature and are not intended to limit the scope of this disclosure. The specific operations performed and services utilized may vary depending on the specific workflow related to the requested operation.

[0053] Figure 8 is a block diagram showing a flow 800 for generating a manifest from a user request, according to at least one embodiment. Figure 8 shows a service provider computer (for example, a service provider computer 802). The service provider computer 802 can be operated by or on behalf of a cloud computing provider. In some embodiments, the service provider computer in Figure 8 implements a cloud computing service for generating a manifest that can configure one or more edge devices. The service provider computer in Figure 8 may be communicably connected to or operating as part of a cloud computing environment operated by a cloud computing provider. The user device 804 may be any suitable electronic device (e.g., a laptop, desktop, smartphone, etc.) and may be communicably connected to the service provider computer 802 via a network (e.g., a public or private network). The service provider computer 802 may be configured to host one or more interfaces to which user input can be provided. These user interfaces may be associated with one or more configured edge devices.

[0054] Flow 800 may begin in 810 where the service provider computer 802 exposes one or more user interfaces from which user input can be obtained. In some embodiments, these user interfaces allow a user to select various services and / or data plane resources configured on one or more edge devices (edge ​​device 806 is one example). As an example, these interfaces may be used to define a configuration (e.g., a particular set of services, a particular number and / or type of virtual machines, or any appropriate attribute of edge device 806). In some embodiments, the user may define a cluster of edge devices and their corresponding configurations. Thus, through these interfaces, the user can define that edge device 806 is compute-intensive (e.g., edge... The attributes of the edge devices can be indicated as follows: (for example, the majority of virtual machines running on edge device 806 provide computing resources), storage-intensive (for example, the majority of virtual machines running on edge device 806 provide storage resources), GPU-intensive (for example, the majority of virtual machines running on edge device 806 provide GPU resources), etc. (for example, based at least in part on the number of virtual machines requested and the specific configuration of these virtual machines selected by the user). The user interface may be any suitable form that allows the user to select and / or define these attributes of one or more edge devices (for example, edge device 806).

[0055] In 812, the user device 804 may submit user input in a user request received by the service provider computer 802. The service provider computer 802 may be hosting a build service within a cloud computing environment.

[0056] In 814, the service provider computer 802 may generate a manifest 815 (e.g., a record, a file, etc.) that corresponds to the user request. Once completed, the manifest 815 can be used to configure edge devices according to the user request. In some embodiments, the service provider computer 802 may generate the manifest 815 based at least in part on a predefined template. In some embodiments, the manifest 815 may be in any suitable format (e.g., JSON, XML, etc.). Once generated, the service provider computer 802 may begin modifying the manifest 815 to correspond to the user request. As an example, the manifest 815 may be modified to include configuration information for one or more edge devices.

[0057] Figure 9 is a block diagram showing an exemplary manifest 900 (an example of manifest 815 in Figure 8) according to at least one embodiment. The manifest 900 includes sections 902 and 904. Section 902 corresponds to one edge device, and section 904 corresponds to another edge device. The manifest 900 may define a configuration of multiple edge devices operating as a cluster. In some embodiments, the manifest 900 may define a cluster identifier in 902. In section 904, any appropriate number of nodes may be provided. In some embodiments, the nodes may be assigned names such as those shown in 906. In 908, the manifest 900 may show a set of device attributes for a given node (e.g., a particular edge device).

[0058] The manifest may contain any appropriate information relating to one or more network interface cards. A network interface card may be defined as having a media access control (MAC) address or other appropriate identifier such as a name. In some embodiments, the manifest 900 may identify the network interface card drivers within section 910. Section 910 may contain any appropriate number of NIC definitions.

[0059] A manifest can identify any number of appropriate services. Manifest 900 indicates at least one service. Within a manifest, various service level attributes can be identified. For example, section 912 may include the name of the service, where an image of the service can be found, the default network name on which the service operates, an indicator showing whether the service starts at boot, and the IP address of the service. Manifest 900 may include any number of appropriate services within section 912.

[0060] While Manifest 900 is shown to include specific attributes of a cluster, node, or device, it should be understood that a manifest can identify any appropriate attribute of a cluster, node, or device. Therefore, the exemplary attributes shown in Figure 9 are not intended to be considered an exhaustive list of all attributes that may be included in any given manifest.

[0061] Returning to Figure 8, at 816, the service provider computer 802 may perform any appropriate actions to generate a list of services from user input and collect artifacts (e.g., container images, OStree commits, etc.) corresponding to that list of services. In some embodiments, the service provider computer 802 may collect these artifacts from one or more storage locations in the cloud computing environment to which the service provider computer 802 belongs. In some embodiments, some of these artifacts may include each container of the set of services requested for a given edge device. The service provider computer 802 may be configured to collect any appropriate number of artifacts corresponding to the number of edge devices defined in the user request.

[0062] In 818, the manifest 815 may be modified to show configuration attributes / details of a specific service running on the edge device. For example, each artifact collected in 816 may, when executed, include an executable script that modifies the manifest file to include an entry corresponding to the service associated with the artifact. The service provider computer 802 may be configured to execute each script for each artifact. Each script may be configured to modify the manifest file to include configuration information corresponding to its respective service. Each script may modify the manifest to include any appropriate entity definitions, which define attributes of a device or service.

[0063] In 820, the service provider computer 802 may execute a predefined set of rules for assigning one or more network addresses to any appropriate number of devices / entities / services identified in the manifest 815. For example, each node in the cluster (for example, each edge device acting as a node in the cluster of edge devices) may be assigned an IP address.

[0064] In 822, the service provider computer 802 may generate an edge device (ED) image based at least in part on the artifacts collected in 818. In some embodiments, the ED image may be an uber-tarball containing the entire container and OStree onbox repository of a given edge device.

[0065] In 824, the service provider computer 802 may be configured to collect any appropriate predefined configuration files, credentials (e.g., API keys, data volume passwords, Macsec keys or other appropriate encryption keys), agents (e.g., a netboot agent), etc.

[0066] In 826, the service provider computer 802 may provision the edge device 806 by providing the edge device 806 with an ED image, manifest, configuration file, credentials, and agent. In some embodiments, it should be understood that a different service provider computer (for example, a service provider computer located in a provisioning center) may perform the provisioning operation than the one that created the manifest.

[0067] In 828, edge device 806 may perform any appropriate actions to provision edge device 806 in accordance with manifest 815. For example, a netboot agent running on edge device 806 may perform actions such as PXE booting, partitioning, dmcrypt setup, file system formatting, querying the service provider computer for artifact URLs, fetching artifacts using the URLs, committing the root file system to the OStree repository, loading containers into the container repository, deploying the OStree commit, fetching remote keys and installing local keys, installing Trenchboot, and sealing the OS partition LUKS key (for example, in trusted platform modules such as chips, hardware security modules, integrated circuit platforms, or other hardware, firmware, and / or software to provide secure initialization of chips, hardware security modules, integrated circuit platforms, or edge devices, and security management of stored secrets including cryptographic keys) using customer passwords provided as credentials.

[0068] After the edge device(s) (edge ​​device 806 is one example) is configured, the cloud computing provider may ship the edge device(s) or, in other words, deliver them to the customer. The edge device(s) may be configured according to the user input provided in 812.

[0069] Figure 10 is a block diagram showing another flow 1000 for generating a manifest 1002 from a user request, according to at least one embodiment. Figure 10 shows a service provider computer 1004 (for example, an example of the service provider computer 802 in Figure 8). The service provider computer 1004 may be operated by or on behalf of a cloud computing provider. In some embodiments, the service provider computer in Figure 10 implements a cloud computing service for generating a configurable manifest (for example, manifest 1002) for one or more edge devices (edge ​​devices 1006 and 1008, each an example of edge device 806 in Figure 8). The service provider computer in Figure 10 may be communicatively connected to or operate as part of a cloud computing environment operated by a cloud computing provider. The user device 1010 may be any suitable electronic device (e.g., a laptop, desktop, smartphone, etc.) and may be communicatively connected to the service provider computer 1004 via a network (e.g., a public or private network not shown). The service provider computer 1004 may be configured to host one or more interfaces to which user input can be provided. These user interfaces may be associated with one or more configured edge devices. In some embodiments, the user may want to operate the distributed computing cluster 1012 using at least edge devices 1006 and 1008. Any appropriate number of edge devices may be utilized in the distributed computing cluster 1012.

[0070] Flow 1000 may begin in 1014 where the service provider computer 1004 exposes one or more user interfaces from which user input can be obtained (for example, from a user device 1010). In some embodiments, these user interfaces allow the user to select various services and / or data plane resources configured on edge devices 1006 and 1008. As an example, these interfaces may allow the user to select a configuration (for example, a particular set of services, a particular number and / or type of virtual machines, or edge devices 1006 and 1008). This can be used to define any appropriate attributes of 1008. In some embodiments, the user may want edge devices 1006 and 1008 to have the same configuration / service set. In other embodiments, the user may specify different configurations and / or service sets for each edge device (for example, one may be compute-intensive and the other storage-intensive). The user interface may be any appropriate format that allows the user to select and / or define these attributes of one or more edge devices (for example, edge device 806).

[0071] In 1016, the user device 1010 may submit user input in a user request received by the service provider computer 1004. The service provider computer 1004 may host a build service within a cloud computing environment. The build service may be configured to receive user requests.

[0072] In 1018, the service provider computer 802 may generate a manifest 1002 (e.g., a record, a file, etc.) that corresponds to the user request. Once completed, the manifest 1002 can be used to configure edge devices 1006 and 1008 according to the user request. In some embodiments, the service provider computer 1004 may generate the manifest 1002 based at least in part on a predefined template. As described above, the manifest 1002 may be in any suitable format (e.g., JSON, XML, etc.). Once generated, the service provider computer 1004 may begin modifying the manifest 1002 to correspond to the user request. As an example, the manifest 1002 may be modified to include configuration information for one or more edge devices.

[0073] In step 1020, any suitable combination of the operations described with respect to steps 816-824 of Figure 8 may be performed to generate an ED image, at least partially based on modifying the manifest 1002 according to the user request and obtaining artifacts, credentials, configuration files, agents, etc., corresponding to the service specified by the user request.

[0074] In 1026, the service provider computer 1004 may provision edge devices 1006 and 1008 by providing the edge devices with ED images, manifests, configuration files, credentials, and agents. In some embodiments, it should be understood that another service provider computer other than the one that created the manifest (for example, a service provider computer located in the provisioning center) may perform provisioning operations for the edge devices of the distributed computing cluster 1012 (in this case, edge devices 1006 and 1008).

[0075] In 1028, each edge device may perform any appropriate action to provision one or more data plane resources in accordance with manifest 1002. For example, a netboot agent running on edge device 1006 (and / or edge device 1008) may perform PXE boot, partition, dmcrypt setup, file system formatting, query artifact URLs (to the service provider computer), fetch artifacts from the datastore using the URLs, commit the root filesystem to the OStree repository, load containers into the container repository, deploy OStree commits, and remote keys (e.g., customer passwords for accessing object store disks). It can perform actions such as fetching and installing local keys, installing Trenchboot, and sealing the OS partition LUKS key to the boot partition.

[0076] After the edge devices 1006 and 1008 are configured, the cloud computing provider may ship the edge devices or, in other words, deliver them to the customer. The edge devices may be configured to operate as a distributed computing cluster 1012 according to user input provided in 1016.

[0077] Subsequently, edge device 1008 may stop operating for some reason (for example, a system failure occurs in 1030). In 1034, user device 1010 (or any suitable user device) is available to request an alternative device (for example, edge device 1032, which is an example of edge devices 802 and edge devices 1006 and 1008 in Figure 8).

[0078] In 1036, the service provider computer 802 may update the manifest 1002 to include configuration information necessary to configure the edge device 1032 according to a user request. In some embodiments, the user request may specify that the edge device 1032 be configured as an exact replacement for the edge device 1008 with the same configuration (e.g., service set, data plane resources, etc.), or in some embodiments, the user request may indicate that a different configuration will be used.

[0079] In 1038, any suitable combination of the operations discussed with respect to steps 816-824 of Figure 8 and the operations in 1020 may be performed to generate an ED image, at least partially based on modifying the manifest 1002 according to the user request and obtaining artifacts, credentials, configuration files, agents, etc., corresponding to the services specified by the user request.

[0080] In 1040, the service provider computer 1004 may provision an edge device 1032 that provides the edge device with an ED image, manifest, configuration file, credentials, and agent. In some embodiments, it should be understood that a different service provider computer (for example, a service provider computer located in a provisioning center) may perform the provisioning operation for the edge device 1032 than the one that created the manifest. Once configured, the edge device 1032 may operate as part of a distributed computing cluster 1012.

[0081] Although not shown in the diagram, at any appropriate time, edge device 1008 (or any edge device in the distributed computing cluster 1012) may be physically returned to the service provider and reconfigured with the same and / or different configurations as previously provided using the same or different manifests (e.g., manifest 1002).

[0082] Figure 11 is a block diagram showing an architecture 1100 and flow for provisioning one or more data plane resources in an edge computing device (an example of an edge device in Figures 1 to 8, 10 and 11) according to at least one embodiment. The architecture 1100 may include a control plane 1102 and a data plane 1104.

[0083] In some embodiments, the control plane 1102 receives a work request that includes intended state data describing the intended state of one or more sets of data plane resources. It can play the role of receiving. For example, a work request may be received by the control plane application programming interface (API) 1106. In some embodiments, a work request may be in the form of a manifest (e.g., manifest 1001, which is an example of a manifest generated by flow 800 in Figure 8 or flow 1000 in Figure 10). In some embodiments, the control plane API 1106 may be an example of a service(s) 502 in Figure 5. The control plane API 1106 may be configured to receive any appropriate number of work requests (e.g., manifest 1001) corresponding to one or more data resources (e.g., a virtual machine, a cluster of virtual machines, etc.) from a user device.

[0084] In some embodiments, manifest 1001 may include an identifier that uniquely identifies it as a work request so that manifest 1001 can be distinguished from other work requests. The request identifier can be an alphanumeric string of any appropriate length that is unique to and can identify the work request. The intended state data may include any appropriate number of parameters. These parameters may define attributes of the requested data plane resource, including, but not limited to, a resource identifier, availability domain, shape corresponding to a node, number of processing units for the resource, random access memory (RAM) capacity for the resource, disk memory capacity, role (e.g., data node, master node), and state (e.g., health). In some embodiments, the control plane API 1106 may be configured to store all received work requests (e.g., manifest 1001) in a data store (e.g., a control plane (CP) data store 1108, which is a distributed data store implemented by a cluster of edge devices on which the edge devices running the components of Figure 11 operate).

[0085] In some embodiments, the CP datastore 1108 may be configured to store work requests and / or intended state data corresponding to the intended state of the data plane 1104. In some embodiments, the CP datastore 1108 may store one or more data plane identifiers of the DP resource 1112(s). It may be configured to store a mapping between the DPID and the intended state data and / or current state data. The intended state data is data that specifies one or more aspects of the DP resource that are requested and for which the DP resource is intended to be modified. The current state data (sometimes called "actual state data") corresponds to one or more parameters that identify the current aspects of one or more of the DP resources that are currently operating.

[0086] The control plane 1102 is a control plane (CP) monitoring component. 1110 may be included. The CP monitoring component 1110 may be configured to periodically (e.g., according to a predetermined frequency, schedule, etc.) determine whether intended state data (e.g., from a previously received work request) received by the control plane API 1106 and stored in the CP data store 1108 matches the current state data stored for the corresponding DP resource (if such DP resource currently exists). The CP monitoring component 1110 may be communicably coupled to non-compute services 1114 (e.g., via the infrastructure network 504 in Figure 5), and non-compute services 1114 may include any appropriate number of cloud computing services configured to manage billing, identity, authorization, etc. In some embodiments, the CP monitoring component 1110, the in-memory workflow manager 1116, and the CP workers 1118 are provided by a common service (e.g., service 706 in Figure 7). Service 706 may be one of the services 502 in Figure 5. Non-compute services 1114 include control plane API 1106, CP monitoring component 1110, and in-memory workflow manager 1 The remaining service set of service(s) 502 may be service(s) 116 and service(s) that implement CP worker(s) 1118(s) (e.g., service(s) 706. In some embodiments, the CP monitoring component(s) 1110 may be communicatively coupled to an in-memory workflow manager(s) 1116 and may be configured to call functions provided by the in-memory workflow manager(s) 1116. For example, if the CP monitoring component(s) 1110 determines that the current state data of a DP resource does not conform to (e.g., does not match) the intended state data stored in the CP data store(s) 814, it may call a function of the in-memory workflow manager(s) 1116 to correct the mismatch.

[0087] In some embodiments, the in-memory workflow manager 1116 may be configured to identify one or more predefined workflows that individually identify the actions to be performed to configure DP resources 1112 according to corresponding intended state data. In some embodiments, the in-memory workflow manager 1116 may be configured to transfer workflow instructions and / or intended state data to a given control plane (CP) worker(s) 1118 to start one or more workers (e.g., compute threads) and to perform actions related to configuring the corresponding DP resources(s) according to the received intended state data. In some embodiments, the CP workers(s) 1118 may provide service-specific orchestration operations. The CP workers(s) 1118 may be communicably coupled to any suitable number of services (e.g., non-compute services(s) 1114), including any suitable combination of compute services, storage services, etc. In some embodiments, the CP workers(s) 1118 may be configured to provide instructions to the data plane (DP) manager 1122 for configuring one or more DP resources. The DP manager 1122 (for example, the hypervisor service 708 in Figure 7) can be configured to create, modify, and / or remove or delete any appropriate DP resources.

[0088] In some embodiments, the DP manager 1122 may be configured to manage any appropriate number of computing components (for example, collectively, DP resources 1112, which may be an example of a computing cluster). In some embodiments, the DP manager 1122 may be configured to manage any appropriate type of computing cluster (for example, a Kubernetes cluster, a set of computing nodes used to run containerized applications, etc.). The CP worker 1118 may be configured to perform any appropriate actions to cause the DP manager 1122 to perform any appropriate orchestration actions on the DP resources 1112, in accordance with instructions identified by the in-memory workflow manager 1116, in order to configure the DP resources 1112 according to intended state data. In some embodiments, the CP monitoring component 1110 may be configured to communicately connect to the DP resources 1112 and monitor the health of the DP resources 1112. In some embodiments, the CP monitoring component 1110 may be configured to transmit any appropriate health data indicating the health of one or more DP resources 1112 (for example, to a user device using any appropriate form of electronic communication). For example, the CP monitoring component 1110 may transmit any appropriate health data to a user device via the control plane API 1106.

[0089] In some embodiments, the CP monitoring component 1110 may be configured to monitor and evaluate the current state data of the DP resource(s) 1112. In some embodiments, the CP monitoring component 1110 may be configured to monitor the current state data of the CP data store 1108. The current state data of DP resources 1112 may be stored / updated. The current state data may be provided to the corresponding CP worker by the DP manager 1122, the CP worker may provide the current state data to the in-memory workflow manager 820, and the in-memory workflow manager 820 may provide the current state data to the CP monitoring component 1110. In some embodiments, CP workers 1118(or more) and / or the in-memory workflow manager 1116 may directly update the CP data store 1108 with the current state data of any appropriate DP resource so that the current state data of a given DP resource is retrieved by the CP monitoring component 1110 at any appropriate time.

[0090] Although the CP monitoring component 1110, the in-memory workflow manager 1116, and the CP worker(s) 1118 are shown as separate components of the control plane 1102, in some embodiments any suitable combination of the CP monitoring component 1110, the in-memory workflow manager 1116, and / or the CP worker(s) 1118 may be provided by a single service (for example, one example of a service from service 706 in Figure 7 or service(s) 502 in Figure 5).

[0091] Figure 12 is a block diagram illustrating an exemplary method 1200 for providing in-memory workflow management in an edge computing device according to at least one embodiment. Method 1200 can be performed by any appropriate number of service provider computers (for example, the service provider computer in Figure 8). In some embodiments, Method 1200 may include more or fewer steps than those shown in Figure 12. It should be understood that the steps of Method 1200 may be performed in any appropriate order.

[0092] Method 1200 may be initiated in 1202 by a first user request specifying a first set of services to be performed on a first cloud computing edge device, which may be received by a computing device operated by a cloud computing provider. An example of this computing device may include the service provider computer 802 in Figure 8. In some embodiments, the cloud computing edge device may be a device configured to selectively run within an isolated computing environment while running within an isolated computing environment without access to a public network. For example, the cloud computing edge device may be an example of the edge device described with respect to Figures 1-8, 10, and 11.

[0093] In 1204, a first manifest may be generated based at least in part on a first user request. The first manifest may specify a first configuration for a first cloud computing edge device. In some embodiments, the first configuration constitutes a first set of services according to the first user request. The first manifest may be an example of manifest 900 in Figure 9.

[0094] In 1206, a first set of services may be provisioned on a first cloud computing edge device in accordance with a first manifest.

[0095] In 1208, a second user request specifying a second set of services to be executed on the second cloud computing edge device may be received by the computing device. In some embodiments, the second set of services may differ from the first set of services.

[0096] In 1210, a second manifest may be generated based at least in part on a second user request. In some embodiments, the second manifest specifies a second configuration for a second cloud computing edge device, the second configuration including a second set of services. The second manifest may be another example of manifest 900 in Figure 9.

[0097] In 1212, a second set of services may be provisioned on the second cloud computing edge device in accordance with the second manifest. In some embodiments, the second cloud computing edge device may be provisioned with services different from those provisioned on the first cloud computing edge device.

[0098] While specific embodiments have been described, various changes, modifications, alternative configurations, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within a specific data processing environment, but can freely operate within multiple data processing environments. Furthermore, while embodiments have been described using a specific set of processes and steps, it will be apparent to those skilled in the art that the scope of this disclosure is not limited to the described set of processes and steps. The various features and aspects of the embodiments described above can be used individually or in combination.

[0099] Furthermore, while embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also included within the scope of this disclosure. Embodiments can be implemented using hardware alone, software alone, or a combination thereof. The various processes described in this disclosure can be executed on the same processor or on different processors in any combination. Thus, where a component or module is described as being configured to perform a particular operation, that configuration can be realized, for example, by designing electronic circuitry to perform the operation, by programming programmable electronic circuitry (such as a microprocessor) to perform the operation, or by a combination thereof. Processes can communicate using a variety of techniques, including but not limited to prior art for inter-process communication. Different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times. Embodiments can be implemented by using a computer program product that, when executed by a processor, includes computer program instructions that cause the processor to perform any of the methods described in this disclosure.

[0100] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will be apparent that additions, reductions, deletions, and other modifications and changes may be made without departing from the broad spirit and scope set forth by the claims. Thus, although specific embodiments of this disclosure have been described, these embodiments are not intended to be limiting. Various modifications and equivalents are included in the appended claims.

[0101] The indefinite article "a" used in the context describing this disclosure (particularly in the context of the claims) ", an, the definite article "the", and similar references are used unless otherwise specifically stated in this disclosure. Unless the context clearly indicates otherwise, it should be interpreted as including both singular and plural forms. (Examples: "comprising," "having," "including") The terms "contains" and "include" should be interpreted as non-restrictive terms (i.e., "includes but not limited to") unless otherwise specified. The term "connected" means that some or all of it is internal, even if something is intervening. It should be interpreted that they are included, attached, or combined together. The ranges of values ​​described herein are intended merely as abbreviations for individually referring to each individual value that falls within that range, and unless otherwise specifically stated herein, each individual value is incorporated into this disclosure as if it were individually stated herein. Unless otherwise specifically stated herein, or unless the meaning is obviously different in content, all methods described herein may be performed in any appropriate order. Any examples or exemplary language described herein (e.g., "like") are intended merely to further illustrate embodiments and, unless otherwise asserted, do not limit the scope of this disclosure. No term herein should be construed as indicating any non-claimed element essential to the implementation of this disclosure.

[0102] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as commonly used to indicate that an item, term, etc., may be X, Y, Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specified. Therefore, such disjunctive language is not generally intended, nor implies, that a particular embodiment requires the presence of at least one X, at least one Y, or at least one Z.

[0103] Preferred embodiments of the Disclosure, including the best known mode for carrying out the Disclosure, are described herein. Modifications of these preferred embodiments will become apparent to those skilled in the art by reading the foregoing description. Those skilled in the art may, as appropriate, adopt such modifications, and the Disclosure may be carried out in ways other than those specifically described herein. Accordingly, the Disclosure includes all variations and equivalents of the subject matter described in the claims appended herein, as permitted by applicable law. Furthermore, unless otherwise stated herein, any combination in any possible variation of the elements described above is incorporated herein.

[0104] All references cited herein, including publications, patent applications, and patents, shall be cited to the same extent as if they were included herein, with each reference clearly and individually indicated as being cited.

[0105] While aspects of the disclosure described above are explained with reference to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the disclosure described above may be used individually or in combination. Furthermore, embodiments may be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method implemented by a computer, The method includes a computing device operated by a cloud computing provider receiving a first user request specifying a first set of services to be performed on a first cloud computing edge device, wherein the cloud computing edge device is a device configured to selectively run within an isolated computing environment while running within that isolated computing environment without access to a public network, and the method further includes: The computing device includes generating a first manifest specifying a first configuration for the first cloud computing edge device, at least in part based on the first user request, the first configuration including the first set of services, and the method further includes The computing device provisions the first set of services on the first cloud computing edge device in accordance with the first manifest, The computing device receives a second user request specifying a second set of services to be executed on the second cloud computing edge device, The computing device generates a second manifest specifying a second configuration for the second cloud computing edge device, at least in part based on the second user request, the second configuration includes a second set of services, and the method further includes: A method comprising the computing device provisioning the second set of services to the second cloud computing edge device in accordance with the second manifest.

2. The method implemented by a computer according to claim 1, wherein at least one of the first manifest or the second manifest is predefined, further specifying at least one of the following: a serial number associated with a cloud computing edge device, a hostname corresponding to the cloud computing edge device, a media access controller having an address corresponding to a network interface device of the cloud computing edge device, or one or more network addresses corresponding to one or more services.

3. The computer-implemented method according to claim 1 or 2, wherein the first cloud computing edge device is one of a plurality of cloud computing edge devices configured to operate as a computing cluster within the isolated computing environment, and the first manifest specifies a corresponding set of services to be performed on each of the plurality of cloud computing edge devices.

4. A computer-based method according to any one of claims 1 to 3, wherein the first service set and the second service set are the same.

5. A method implemented by a computer according to any one of claims 1 to 4, wherein generating the first manifest includes obtaining artifacts corresponding to each service in the first set of services specified in the first user request.

6. Generating the first manifest means that the service among the first set of services A method implemented by a computer according to any one of claims 1 to 5, comprising executing one or more executable scripts individually associated with artifacts corresponding to a device, wherein executing the one or more executable scripts modifies the first manifest to include one or more entity definitions, each entity definition corresponding to a device or service.

7. A method, performed by a computer according to any one of claims 1 to 6, wherein generating the first manifest includes assigning network addresses to one or more entities defined in the manifest.

8. A computing device, One or more processors, The computing device comprises one or more memories containing computer executable instructions, and when the computer executable instructions are executed by the one or more processors, the computing device is configured to: A first user request is received specifying a first set of services to be executed on a first cloud computing edge device, the cloud computing edge device is a device configured to run selectively within an isolated computing environment while running within an isolated computing environment without access to a public network, the computing device is operated by a cloud computing provider, and the computer executable instructions are further sent to the computing device. Based at least in part on the first user request, a first manifest is generated specifying a first configuration for the first cloud computing edge device, the first configuration including the first set of services, and the computer executable instructions further to the computing device, In accordance with the first manifest, the first cloud computing edge device is provisioned with the first set of services. The system receives a second user request specifying a second set of services to be executed on the second cloud computing edge device. Based at least in part on the second user request, a second manifest is generated specifying a second configuration for the second cloud computing edge device, the second configuration including the second set of services, and the computer executable instructions further: A computing device that causes the second cloud computing edge device to provision the second set of services in accordance with the second manifest.

9. The computing device according to claim 8, wherein at least one of the first manifest or the second manifest further specifies at least one of the following: a serial number associated with the cloud computing edge device, a hostname corresponding to the cloud computing edge device, a media access controller having an address corresponding to the network interface device of the cloud computing edge device, or one or more network addresses corresponding to one or more services.

10. The first cloud computing edge device is one of a plurality of cloud computing edge devices configured to operate as a computing cluster within the isolated computing environment, and the first manifest is for each of the plurality of cloud computing edge devices A computing device according to claim 8 or 9, which specifies a corresponding set of services to be performed on an edge device.

11. The computing device according to any one of claims 8 to 10, wherein the first service set and the second service set are the same.

12. The computing device according to any one of claims 8 to 11, wherein generating the first manifest includes obtaining artifacts corresponding to each service in the first set of services specified in the first user request.

13. Generating the first manifest comprises executing one or more executable scripts individually associated with artifacts corresponding to services in the first set of services, the execution of the one or more executable scripts comprises modifying the first manifest to include one or more entity definitions, each entity definition corresponding to a device or service, the computing device according to any one of claims 8 to 12.

14. The computing device according to any one of claims 8 to 13, wherein generating the first manifest includes assigning network addresses to one or more entities defined in the manifest.

15. A non-temporary computer-readable storage medium storing computer-readable instructions, wherein the computer-readable instructions, when executed by one or more processors of a computing device operated by a cloud computing provider, are stored in the computing device. A first user request is received specifying a first set of services to be executed on a first cloud computing edge device, the cloud computing edge device is a device configured to selectively execute within an isolated computing environment while it is running within an isolated computing environment without access to a public network, and the computer-readable instruction is further to the computing device, Based at least in part on the first user request, a first manifest is generated specifying a first configuration for the first cloud computing edge device, the first configuration including the first set of services, and the computer-readable instructions further to the computing device, In accordance with the first manifest, the first cloud computing edge device is provisioned with the first set of services. The system receives a second user request specifying a second set of services to be executed on the second cloud computing edge device. Based at least in part on the second user request, a second manifest is generated specifying a second configuration for the second cloud computing edge device, the second configuration including the second set of services, and the computer-readable instructions further to the computing device, A non-transient computer-readable storage medium that causes the second cloud computing edge device to provision the second set of services in accordance with the second manifest.

16. At least one of the first manifest or the second manifest is predefined, and includes the serial number associated with the cloud computing edge device, the hostname corresponding to the cloud computing edge device, and the cloud computing A non-temporary computer-readable storage medium according to claim 15, further specifying a media access controller having an address corresponding to a network interface device of a connecting edge device, or at least one of one or more network addresses corresponding to one or more services.

17. The non-temporary computer-readable storage medium according to claim 15 or 16, wherein the first cloud computing edge device is one of a plurality of cloud computing edge devices configured to operate as a computing cluster within the isolated computing environment, and the first manifest specifies a corresponding set of services to be performed on each of the plurality of cloud computing edge devices.

18. A non-temporary computer-readable storage medium according to any one of claims 15 to 17, wherein the first service set and the second service set are the same.

19. A non-temporary computer-readable storage medium according to any one of claims 15 to 18, wherein generating the first manifest includes obtaining artifacts corresponding to each service in the first set of services specified in the first user request.

20. Generating the first manifest means This includes executing one or more executable scripts individually associated with artifacts corresponding to services in the first set of services, the execution of which includes modifying the first manifest to include one or more entity definitions, each entity definition corresponding to a device or service, and generating the first manifest further, A non-temporary computer-readable storage medium according to any one of claims 15 to 19, comprising assigning a network address to one or more entities defined in the manifest.

21. A computer program product that includes computer program instructions, wherein when the computer program instructions are executed by a processor, the processor... A first user request is received specifying a first set of services to be executed on a first cloud computing edge device, the cloud computing edge device is a device configured to selectively execute within an isolated computing environment while running within an isolated computing environment without access to a public network, and the computer program instructions are further sent to the processor, Based at least in part on the first user request, a first manifest is generated specifying a first configuration for the first cloud computing edge device, the first configuration including the first set of services, and the computer program instructions further to the processor, In accordance with the first manifest, the first cloud computing edge device is provisioned with the first set of services. The system receives a second user request specifying a second set of services to be executed on the second cloud computing edge device. Based at least in part on the second user request, a second manifest is generated specifying a second configuration for the second cloud computing edge device, the second configuration including the second set of services, and the computer program instructions further: In accordance with the second manifest, the second cloud computing edge device A computer program product that provisions the chair with the second set of services.

Images