Patent Description:
A cloud computing system refers to a collection of computing devices on which data can be remotely stored and accessed. Modern cloud computing infrastructures often include a collection of physical server devices organized in a hierarchical structure including computing zones, clusters, virtual local area networks (VLANs), racks, fault domains, etc. Cloud computing systems often make use of different types of virtual services (e.g., computing containers, virtual machines) that provide storage and computing functionality to various clients and customers. These virtual services can be hosted by respective server nodes on a cloud computing system.

As demand for cloud computing resources continues to grow, and as the demographic of cloud computing users has become more decentralized, additional innovations are needed to meet this change in demand. For example, conventional cloud computing systems have experienced significant costs and challenges in scaling centrally maintained cloud computing datacenters to accommodate a growing user-base. In addition, users may often experience latency issues and demand more speed than can be provided by a remote cloud computing system. Moreover, many individuals and businesses prefer greater control and/or security of cloud computing resources over conventional models in which cloud computing resources are shared between multiple tenants.

In an attempt to overcome various drawbacks and/or shortcomings of conventional cloud computing systems, many customers have expressed a desire to have local edge networks (e.g., computing zones) that provide faster access to cloud computing resources. Implementation of these local computing zones, however, poses a number of difficulties and challenges. For example, where devices of an edge network may logically connect with various devices on the cloud, these connections between edge and cloud often provide limited bandwidth. This limited bandwidth can cause significant delays in communication of data between the edge and cloud. Moreover, attempting to transfer large files in this way can affect other traffic being communicated between devices of the cloud computing system. As a result, performance of edge networks may suffer during periods of high demand, often negating many of the benefits of lower latency that a local computing zone might provide.

These and other problems exist with regard to implementing cloud computing resources on local networks.

<CIT> relates to serving an image to a group of target servers. The technique includes assigning a first target server of a group of target servers as a temporary deployment server. The first target server may be assigned as a temporary deployment server by a master deployment server over a management network. The master deployment server may serve the first target server an image package. The master deployment server may further serve a command over the management network to a second target server of the group of target servers. The second target server may be commanded to retrieve, over a data network, a deployment image of the image to be booted on the second target server.

The present disclosure is generally related to systems and methods for peer booting server nodes on an edge zone. For example, an edge zone (or edge network) may include server nodes configured to host virtual machines thereon that provide low-latency access to various cloud-computing services to customers of a cloud computing system. As will be discussed in further detail below, these server nodes implement a peer booting system in which a server node at a location of an edge network obtains an operating system (OS) file (e.g., an OS boot file) and instantiates an operating system including features and functionalities of an OS provider service. A peer booting system implemented on the server node then acts as an OS provider for other server nodes on the edge zone. As will be discussed below, providing this functionality to other server nodes significantly increases the speed with which operating systems are booted on the server nodes while preventing server nodes on the network from overutilizing limited bandwidth resources.

As an illustrative example, an OS provisioning system implemented on one or more control planes may receive a boot request from a server node at a location of an edge zone. The OS provisioning system can generate a boot response including an identifier of the server node and information associated with an OS provider service on the set of control planes. In one or more embodiments, the OS provisioning system causes the OS provider service to provide an OS file to the server node causing the server node to instantiate an OS instance (e.g., a maintenance OS and/or a full OS) on the server node. In one or more implementations, the OS instance provides OS provider service functionality to the server node that may be used to provide OS files to other server nodes on the edge zone. For example, in one or more embodiments, the OS provisioning system may receive a second boot request from another server node on the edge zone. The OS provisioning system can provide a boot response including instructions associated with locally obtaining the OS file from the server node having the OS previously instantiated thereon. Indeed, the first server node may act as an OS provider service for any number of server nodes on the edge zone.

As will be discussed in further detail below, the present disclosure includes a number of practical applications having features described herein that provide benefits and/or solve problems associated with booting operating systems on server nodes of an edge zone. Some example benefits are discussed herein in connection with various features and functionality of the OS provisioning system as well as a peer booting system on a server node of the edge zone. Nevertheless, it will be understood that benefits explicitly discussed in connection with one or more implementations are provided by way of example and are not intended to be a comprehensive list of all possible benefits of the systems described herein.

For example, by loading a peer booting system on one or more server nodes on an edge zone, the systems described herein significantly reduce an amount of time that it takes to boot devices of an edge zone. Indeed, by providing functionality of the OS provider system on a local server node at the same location as other server nodes of the edge zone, a majority of server nodes on the edge zone can leverage local network speeds that are significantly faster than communicating with devices remotely located on a datacenter. In many cases, the server nodes may utilize wired connections (e.g., optical fiber) between respective devices rather than utilizing a much slower virtual private network (VPN) tunnel that connects data plane devices at the location of the edge zone to control plane devices on the datacenter of the cloud computing system.

In addition to faster boot times, providing access to OS boot files and other types of larger data files (e.g., image files) via a local connection between server nodes on the same edge zone provides a more reliable communication of data between devices. For example, where multiple server nodes may attempt to download image files or other large data files using a trivial file transfer protocol (TFTP), fulfilling these data requests will likely chock the VPN tunnel and result in some or all of the data transfers to fail. Alternatively, providing a local resource with limited functionality of one or more of the control plane devices can provide faster access without chocking the VPN tunnel and causing transfer of data to fail.

Moreover, by avoiding overuse of bandwidth resources to communicate OS boot files and other types of large data files, the bandwidth resources may continue to be used by server nodes of the edge network in other less demanding ways. Indeed, where the server nodes will still use various control plane services that are not located at the edge zone location, having this extra bandwidth will ensure that other requests and responses between the data plane devices and control plane devices will be communicated quickly and reliably between the server nodes of the edge zone and control planes on the datacenter.

As will be discussed in further detail below, implementing the systems and methods as described herein facilitate each of the above benefits without requiring that control plane devices be distributed to edge locations. Indeed, where control planes often provide valuable services to multiple edge locations, implementing peer booting systems on edge zone devices as disclosed herein provides limited local access to OS provider services within the framework of the edge zone without risking security of the cloud computing system. Moreover, this local OS provider functionality is accomplished without increasing management costs that would accompany distribution of control plane devices to every edge zone location.

As illustrated in the foregoing discussion, the present disclosure utilizes a variety of terms to describe features and advantages of the systems described herein. Additional detail is now provided regarding the meaning of some of these terms. For example, as used herein, a "cloud computing system" refers to a network of connected computing devices that provide various services to computing devices (e.g., customer devices). For instance, as mentioned above, a distributed computing system can include a collection of physical server devices (e.g., server nodes) organized in a hierarchical structure including clusters, computing zones, virtual local area networks (VLANs), racks, fault domains, etc. In one or more embodiments, the server devices may be implemented within a datacenter (e.g., a regional datacenter) including any number of server devices connected via an internal network of the datacenter and which provides any number of cloud computing services to clients of the cloud computing system. In one or more embodiments described herein, a cloud computing system includes a combination of multiple datacenters in addition to one or more edge zones extending computational resources of the cloud computing system beyond those provided exclusively within the datacenter(s).

In one or more embodiments described herein, a cloud computing system may include one or more edge zones. As used herein, an "edge zone" or "edge network" may refer interchangeably to an extension of the cloud computing system located on a periphery of the cloud computing infrastructure. The edge zone may refer to a hierarchy of one or more devices that provide connectivity to the cloud computing system to one or more clients connected to or on the same communication network as the edge zone. The edge zone may provide a number of cloud computing services on local hardware without requiring that a client communicate with components internal to a cloud computing system and without sharing resources with other tenants of the cloud computing system. In one or more embodiments, the edge zone provides a virtual access point that enables more direct communication with one or more components on the cloud computing system than another entry point, such as a public entry point, to the cloud computing system. In one or more embodiments described herein, a device (e.g., a server node) on an edge zone may refer to a device at a location associated with devices that make up the edge zone (or simply "an edge location").

In one or more embodiments described herein, the edge zone is associated with a specific datacenter (e.g., a regional datacenter) based on a location of the edge zone within an external network or physical proximity of the edge zone relative to the datacenter. This regional datacenter can serve as a parent for the edge zone and may be selected for a corresponding edge zone based on a low latency the regional datacenter provides to the edge zone as well as the data sovereignty the datacenter ensures within the geography. In one or more embodiments, the edge zone includes a combination of cloud computing hardware provided by and configured to operate in connection with the cloud computing system in combination with additional hardware that is separate from or otherwise independent from the cloud computing system. For example, in one or more embodiments, a server rack may refer to server nodes that are configured to operate in connection within the hierarchy of a cloud computing system and physically installed within an external network including one or more server devices that are not in communication with or otherwise configured to communicate internally with components of the cloud computing system.

As will be discussed in further detail below, server nodes of an edge zone may instantiate an operating system (OS) thereon that provides features and functionality to the server node. In addition, different examples may refer to a maintenance OS and a full OS. As used herein, a "maintenance OS" may refer to a pre-provisioning system or a pre-installation environment that enables the server node to run limited diagnostics for the machine and determine whether the server node is healthy within the framework of the network environment (e.g., including one or both of the edge zone and cloud computing system). As used herein, a "full OS" may refer to a fully operational system or environment in which the server node is ready or otherwise configured to host cloud-based applications and services, such as virtual machines and other computing containers.

In one or more embodiments, the various environments may include data planes and control planes. As used herein, a data plane or data plane device may refer to a machine or host node configured to host cloud-based services thereon. For example, a data plane device may refer to a server node on a server rack having one or more hypervisors thereon that are capable of hosting virtual machines. In one or more examples described herein, a data plane device refers specifically to server nodes that are located on and implemented within a framework of the edge zone. A control plane device may refer to one or more server nodes on a datacenter having features and functionalities associated with managing resources on data plane devices. For example, a control plane device may receive requests for deployment or allocation of cloud computing resources and make determinations associated with which edge zone(s) and even which hypervisor should be tasked with managing deployment of various cloud computing services. Other example control plane features and functionality are discussed herein in connection with control planes on an OS provisioning system.

In one or more examples described herein, one or more control planes devices are located exclusively at a datacenter remote from a location of an edge zone. For example, in one or more implementations, an edge zone may be restricted from hosting one or more services on control planes, such as a service for providing a boot response. For instance, in one or more embodiments, an edge zone may be restricted from providing dynamic host configuration protocol (DHCP) services on a control plane at a location of the edge zone. Thus, in one or more embodiments, the edge zone would be unable to locally provide DHCP responses in providing additional security and data management, such as implementing firewall rules in a network of the control plane. Additional detail will now be provided regarding systems mentioned above in relation to illustrative figures portraying example implementations. For example, <FIG> illustrates an example environment <NUM> showing a cloud computing system <NUM> including a datacenter <NUM> and a plurality of edge zones <NUM>, <NUM>. As shown in <FIG>, the datacenter <NUM> includes one or more control plane device(s) <NUM> (e.g., a control plane system) having components of the operating system (OS) provisioning system <NUM> implemented thereon. As will be discussed in further below, the OS provisioning system <NUM> may include a request manager <NUM>, a provisioning manager <NUM>, and one or more OS provider(s) <NUM>. The request manager <NUM>, provisioning manager <NUM>, and OS provider(s) <NUM> may be implemented on a control plane system, which may include one or more control plane devices on a datacenter <NUM>.

The cloud computing system <NUM> may include any number of datacenters (e.g., regional datacenters) spaced across multiple geographic locations. Further, the datacenter <NUM> (and other datacenters) may include any number of server devices configured to provide features and functionalities of the cloud computing system <NUM> to any number of client devices (e.g., client devices <NUM>). In addition, while <FIG> illustrates a cloud computing system <NUM> as inclusive of the datacenter <NUM>, in one or more embodiments, the cloud computing system <NUM> may refer to the datacenter <NUM> in addition to devices of a plurality of edge zones (discussed below).

As mentioned above, the OS provisioning system <NUM> may include a number of components <NUM>-<NUM> implemented on one or more control plane devices <NUM>. For example, in one or more embodiments, the OS provisioning system <NUM> includes a request manager <NUM> for handling a variety of requests. In one or more embodiments described herein, the request manager <NUM> is implemented on a control plane(s) configured to receive requests for boot files. For instance, as will be discussed below, the request manager <NUM> may refer to a dynamic host configuration protocol (DHCP) server configured to receive DHCP requests including a request for a boot file. The request manager <NUM> may process and provide the request to the provisioning manager <NUM> and/or OS provider(s) <NUM> for further processing.

As further shown in <FIG>, the OS provisioning system <NUM> may include a provisioning manager <NUM>. Similar to the request manager <NUM>, the provisioning manager <NUM> may be implemented on a control plane device and configured to handle registration of an OS provider and provide information associated with a location of the OS provider to one or more server nodes on an edge zone. For example, in one or more embodiments, the provisioning manager <NUM> may provide an identifier of the OS provider(s) <NUM> to a first server node that provides a DHCP request to the request manager <NUM>. In addition, upon receiving subsequent requests from other server nodes, the provisioning manager <NUM> can provide instructions to the server nodes to enable server nodes on the edge zone to connect with one another and communicate boot files over a local network rather than via a VPN tunnel.

As further shown in <FIG>, the OS provisioning system <NUM> includes one or more OS provider(s) <NUM>. Similar to other components <NUM>-<NUM> on the OS provisioning system <NUM>, the OS provider(s) <NUM> may be implemented on one or more control plane device(s) <NUM> of the cloud computing system <NUM>. As will be discussed in further detail below, the OS provider(s) <NUM> can provide access to one or more boot files server node(s) on an edge zone. For example, the OS provider(s) <NUM> can provide an OS file for instantiation on the server node(s) of the edge zone. The OS provider(s) <NUM> may additionally provide one or both of a maintenance OS file or a full OS file. As will be discussed in further detail below, providing the OS file(s) to the server nodes may involve providing functionalities of the OS provider(s) <NUM> to the respective server nodes such that the server node(s) can act as OS provider(s) for other server nodes on the edge zone.

As mentioned above, and as shown in <FIG>, the environment <NUM> shows a number of edge zones <NUM>, <NUM>. Additional detail will be discussed in connection with an example edge zone <NUM> associated with a first location, which may include similar features as any of the additional edge zones <NUM> associated with other locations. As shown in <FIG>, the edge zone <NUM> includes one or more server rack(s) <NUM>, which may include any number of server nodes <NUM>. Each of the server nodes <NUM> may refer to data plane devices, which may include virtual machines deployed thereon. As shown in <FIG>, the server nodes <NUM> may include a peer booting system <NUM>. As will be discussed in further detail below, the peer booting system <NUM> can facilitate instantiation of an operating system thereon (e.g., a maintenance operating system and a full operating system). Once the operating system is booted on a particular server device, the peer booting system <NUM> may act as an OS provider to one or more additional server devices on the edge zone <NUM>. For example, once the operating system is up and running on a first server node, the peer booting system <NUM> may receive an identification of one or more boot requests from other server nodes and initiate communication of one or more OS boot file(s) to other server nodes via a wired or wireless network local to the edge zone <NUM>.

As shown in <FIG>, a set of client devices <NUM> may communicate with and access services of the cloud computing system <NUM> via the edge zone <NUM>. In particular, the client devices <NUM> may provide requests for deployment of virtual machines and other cloud-based services to be hosted on the edge zone <NUM> and/or on the datacenter <NUM>. The client devices <NUM> may refer to various types of computing devices including, by way of example, mobile devices, desktop computers, server devices, or other types of computing devices.

As further shown in <FIG>, devices of the edge zone <NUM> may communicate with components of the cloud computing system <NUM> via a network <NUM>. The network <NUM> may include one or multiple networks that use one or more communication platforms or technologies for transmitting data. For example, the network <NUM> may include the Internet or other data link that enables transport of electronic data between respective client devices <NUM> and devices of the cloud computing system <NUM> and/or edge zone <NUM>. In some cases, network <NUM> includes a virtual private network (VPN) (e.g., a VPN tunnel) and/or a virtual extensible local area network (VXLAN) network connection built on top of the customer network to link the edge zone <NUM> to the cloud computing system <NUM>. As noted above, and as shown in <FIG>, the environment <NUM> may include additional edge zones <NUM> corresponding to different locations and/or different clients/customers. Each of the edge zones <NUM> may include similar features and functionality discussed in connection with the edge zone <NUM> (and other edge zones discussed herein). The datacenter <NUM> may be associated with any number of edge zones having similar or different combinations of server nodes on respective server racks (e.g., in accordance with received hardware requests indicating different virtual machine types and/or computing requirements).

Additional information will now be discussed in connection with an example implementation of the OS provisioning system <NUM> and managing instantiation of OS instances on server nodes of an edge zone. In particular, <FIG> illustrates an example environment <NUM> including an OS provisioning system <NUM> and an edge zone <NUM> having similar features and functionalities as the edge zones <NUM>, <NUM> discussed above in connection with <FIG>.

For example, as shown in <FIG>, the example environment <NUM> includes an OS provisioning system <NUM> including a request manager <NUM>, provisioning manager <NUM>, and OS provider(s) <NUM> having similar features as similar components discussed above in connection with <FIG>. As further shown, the environment <NUM> includes an edge zone <NUM> having a plurality of server nodes 204a-n. One or more of the server nodes 204a-n may have operating systems. For example, a first server node 204a may have an operating system <NUM> (e.g., a full operating system) instantiated and running thereon, which may include a peer booting system <NUM> having similar features as the peer booting system <NUM> mentioned above in connection with <FIG>.

As will be discussed in further detail below, the peer booting system <NUM> may provide one or more features and functionalities as the OS provider(s) <NUM> to other server nodes 204b-n of the edge zone <NUM>. For example, as will be discussed below in connection with <FIG>, the first server device 204a may provide a boot request to the OS provisioning system <NUM> that facilitates receiving a boot file and instantiating the operating system <NUM> on the first server node 204a. Once instantiated, the first server node 204a may act as a source of boot files for the second server node 204b and any additional server nodes on the edge zone <NUM>.

As further shown in <FIG>, the OS provisioning system <NUM> and devices of the edge zone <NUM> communicate via a VPN tunnel <NUM>. In accordance with one or more embodiments described herein, the devices of the edge zone <NUM> and the OS provisioning system <NUM> may communicate data and files via the VPN tunnel <NUM> using TFTP. In one or more embodiments, the server nodes 204a-n may communicate requests via the VPN tunnel <NUM> using DHCP requests. In one or more embodiments, the server nodes 204a-n may communicate outside the established communication path of the VPN tunnel <NUM> by providing a hypertext transfer protocol (HTTP) request to one or more server devices on the cloud computing system <NUM>.

An example implementation of the components shown in <FIG> is discussed in connection with a series of interactions shown in <FIG>. In particular, <FIG> shows a series of interactions between the OS provisioning system <NUM> and a set of server nodes 204a-b including a first server node 204a and a second server node 204b. As noted above, the server nodes 204a-b may refer to data plane devices implemented on a server rack at an edge location.

As further mentioned above, the OS provisioning system <NUM> may be implemented across one or more control plane devices of a control plane system. For example, while not explicitly shown in <FIG>, individual components <NUM>-<NUM> may be implemented on respective control plane devices of a datacenter. For instance, the request manager may be implemented on a first control plane(s). The provisioning manager <NUM> may be implemented on a second control plane(s). The OS provider(s) <NUM> may be implemented on a third control plane(s). Each of the components <NUM>-<NUM> may be implemented on a single or across multiple control plane devices. As an illustrative example, the OS provider(s) <NUM> may include a first OS provider associated with providing boot files for a maintenance OS and a second OS provider associated with providing boot files for a full OS. Thus, while <FIG> describes interactions between the OS provisioning system <NUM> and server nodes 204a-b, one or more embodiments may involve communications between respective components <NUM>-<NUM> on a control plane system, as will be discussed in further detail in connection with <FIG>.

As shown in <FIG>, the OS provisioning system <NUM> and server nodes 204a-b may cooperatively cause an OS instance to be instantiated on the server nodes 204a-b to enable one or both of the server nodes 204a-b to act as an OS provider to one or more additional server nodes on an edge zone (e.g., edge zone <NUM>). In particular, a first server node 204a may perform an act <NUM> of providing a boot request to the OS provisioning system <NUM>. In one or more embodiments, the boot request is a dynamic host configuration protocol (DHCP) request provided to a request manager <NUM> (e.g., a DHCP server) on one of a set of control plane devices. In one or more embodiments, the boot request is communicated via the VPN tunnel <NUM> logically connecting the server nodes 204a-n and various components of the OS provisioning system <NUM>.

The boot request may include various information provided to the OS provisioning system <NUM>. For instance, the boot request may include an indication of action executable by a control plane device on the OS provisioning system. In this example, the boot request may include an identifier for the first server node 204a and/or edge zone as well as information associated with an operating system that the server node 204a wants to instantiate or otherwise boot up. In one or more embodiments, the boot request includes information about specifications of the server node 204a and any other instructions that may be used by components of the OS provisioning system <NUM> is responding to the boot request.

Concurrent with or subsequent to the first server node 204a generating and providing the boot request to the OS provisioning system <NUM>, a second server node 204b may perform an act <NUM> of queuing a boot request. As an example, where an edge zone includes multiple server nodes that are attempting to boot or requesting image files, it may occur where multiple server nodes attempt to generate and provide boot requests to the OS provisioning system <NUM>. In this example, the second server node 204b or other component on a server rack (e.g., a rack manager, a rack switch) may recognize that a boot request has been provided by the first server node 204a and cause the boot request to be queued for the second server node 204b.

In one or more embodiments, the OS provisioning system <NUM> may queue the boot request and proceed in processing the boot request from the first server node 204a prior to performing any further processing of the boot request from the second server node 204b. For example, in one or more embodiments, while the OS provisioning system <NUM> is processing a boot request received from a first server node 204a, the OS provisioning system <NUM> may wait an additional period of time before processing a second boot request from the second server node. This period of waiting may enable the OS provisioning system <NUM> to fully process the boot request and instantiate the OS instance on the first server node 204a. Further, this waiting period may prevent a flood of incoming boot requests from overloading available bandwidth of a VPN tunnel.

Thus, in accordance with one or more embodiments described herein, the OS provisioning system <NUM> can process a boot request from a second server node 204b in a variety of circumstances. For example, the OS provisioning system <NUM> can process a second boot request after servicing a first boot request based on a timeout period providing adequate time for the first boot request to be processed. As another example, the OS provisioning system <NUM> can process a second boot request based on a notification or registration of an OS provider instance at the edge location. In one or more embodiments, the OS provisioning system <NUM> can process a second boot request after verifying that an OS provider instance is already available at the edge location (e.g., an OS provider instance previously instantiated prior to receiving the second boot request).

As shown in <FIG>, in response to the boot request, the OS provisioning system <NUM> can perform an act <NUM> of generating and providing a boot response to the first server node 206a. The boot response may include an identifier of the first node and information associated with an OS provider service on the OS provisioning system <NUM> configured to provide an OS file to the first server node 204a. For example, in one or more embodiments, the boot response includes an IP address for an OS provider <NUM> that enables the first server node 204a to obtain access to an OS file. In one or more embodiments, the boot response further includes an IP address for a provisioning manager <NUM>.

The server node 204a may additionally perform an act <NUM> of obtaining boot file(s) <NUM> from the OS provisioning system <NUM>. For example, the server node 204a may download or otherwise receive an OS file via the VPN tunnel connecting the edge zone <NUM> and the OS provisioning system <NUM>. As will be discussed in further detail below, the server node 204a may receive one or both of a maintenance OS and a full OS for instantiation on the server node 204a. For example, in one or more embodiments, the server node 204a first receives and instantiates a maintenance OS on the server node 204a. After performing one or more verifications of machine health and other diagnostics, the server node 204a may additionally obtain a full OS file from the OS provider(s) of the OS provisioning system <NUM>.

As shown in <FIG>, providing the bot file(s) to the server node 204a may cause the server node to perform an act <NUM> of booting an operating system thereon. For example, as noted above, the server node 204a may boot a maintenance OS and a full OS on the server node 204a to have full functionality within a framework of the edge zone <NUM> and cloud computing system <NUM>. In one or more embodiments, booting the operating system includes implementing a peer booting system <NUM> thereon that has some or all of the same features as the OS provider(s) <NUM> on the OS provisioning system <NUM>. Indeed, in one or more embodiments, the peer booting system <NUM> includes an image of the OS provider(s) <NUM> locally installed on the server node 204a that provide one or more of the services provided by the OS provider(s) <NUM> to any of the additional server nodes on the edge zone <NUM>.

After the server node 204a is fully operational, the OS provisioning system <NUM> may perform an act <NUM> of receiving the queued boot request from the second server node 204b. In one or more embodiments, the second server node 204b provides the queued boot request based on receiving a signal that the first server node 204a is operational and has the full OS instantiated thereon.

Alternatively, in one or more embodiments, the OS provisioning system <NUM> begins processing the boot request previously received from the second server node 204b while the OS provisioning system <NUM> was handling the first boot request from the first server node 204a.

Similar to the first boot request, the second boot request may similarly include information about the second server node 204b including an IP address of the server node 204b and/or edge zone <NUM>. As shown in <FIG>, in response to receiving the queued boot request, the OS provisioning system <NUM> can perform an act <NUM> of generating a queued boot response. In one or more embodiments, the queued boot response is generated and provided to the server node 204a. For example, based on identifying information contained within the boot request, the OS provisioning system <NUM> may determine that one or more server nodes (e.g., the first server node 204a) has a fully operational OS implemented thereon and is capable of providing OS boot files to other server nodes on the edge zone <NUM>.

As shown in <FIG>, for example, in response to receiving the queued boot response, the first server node 204a may perform an act <NUM> of providing or otherwise communicating boot files to the second server node 204b. In one or more embodiments, the first server node 204a provides one or more boot files using a similar process as used when the OS provisioning system <NUM> provided one or more boot files to the first server node 204a. One notable difference between the two different distributions of the server nodes may include the network and/or communication medium over which the boot files are provided. For example, rather than communicating the boot files to the second server node 204b over the VPN tunnel, the first server node 204a may provide the boot files to the second server node 204b via a local network, which may include a wired communication medium between the server nodes 204a-b. In one or more embodiments, the first server node 204a provides the boot file(s) to the second server node 204b via an optical fiber connection between the respective devices, thus resulting in a significant boost in speed with which the OS is instantiated on the second server node 204b.

The first server node 204a may perform a similar process of providing boot files to other server nodes on the edge zone <NUM> in response to boot requests provided by other server nodes to the OS provisioning system <NUM>. Moreover, in one or more embodiments, the second server node 204b may additionally implement a peer booting system thereon that enables the second server node 204b to similarly function as a peer booting device to any of the other server nodes on the edge zone <NUM>. This may be particularly useful where some or all of the server nodes on a server rack or edge zone <NUM> are simultaneously (or near simultaneously) requesting boot files from the OS provisioning system <NUM>.

Additional information will now be discussed in connection with an example implementation within a similar environment as the environment discussed above in connection with <FIG>.

Indeed, <FIG> illustrate additional interactions that may occur in addition or in lieu of one or more of the interactions discussed above in connection with <FIG>. More specifically, <FIG> illustrate an example implementation showing communications that may occur between respective server nodes and specific components of the OS provisioning system <NUM>, which may refer to systems that are implemented on a system of control planes remotely maintained on a datacenter.

For example, <FIG> illustrates a first example environment 400a showing the OS provisioning system <NUM> having the request manager <NUM>, provisioning manager <NUM>, and OS provider(s) <NUM> thereon, which may be implemented on different control plane devices. As further shown, the edge zone <NUM> may include any number of server nodes 204a-n. In this example environment 400a, each of the server nodes 204a-n may refer to empty nodes having no operating systems instantiated thereon and prior to communicating any boot request to the OS provisioning system <NUM>.

As shown in <FIG>, a first server node 204a may perform an act <NUM> of providing a first DHCP request to the request manager <NUM>. In this example, the request manager <NUM> may refer to a DHCP server configured to handle DHCP requests from server devices across any number of edge zones <NUM>. As noted above, the DHCP request may include an IP address or other identifier of the server node 204a as well as any information associated with the edge zone <NUM> that enables the DHCP server to handle the DHCP request.

As shown in <FIG>, the request manager <NUM> may handle the DHCP request by performing an act <NUM> of providing information associated with the server node 204a to a provisioning manager <NUM>. In one or more embodiments, the request manager <NUM> relays the DHCP request based on verifying that the identifier for the first server node 204a corresponds to a server node from an approved edge zone. Where the server node does not correspond to a known or approved edge zone <NUM>, the request manager <NUM> may reject the DHCP request.

Where the DHCP request is provided to the provisioning manager <NUM> (e.g., based on a successful validation of the edge zone <NUM>), the provisioning manager <NUM> may perform one of a number of actions. For example, as shown in <FIG>, the provisioning manager <NUM> may perform an act <NUM> of providing a boot response to the server node 204a including an indication that the DHCP request has been successfully received and processed. In one or more embodiments, the boot response includes an identification of one or more OS provider(s) <NUM> that are capable of servicing a request for an OS boot file. For example, the boot response may include one or more IP addresses that provide access to one or more maintenance OS files and/or full OS files (e.g., OS boot files). In addition to providing the boot response to the server node 204a, the provisioning manager <NUM> may perform an act <NUM> of providing information from the DHCP request to the OS provider(s) <NUM>. For example, in one or more embodiments, the provisioning manager <NUM> provides an IP address and other relevant information to one or more OS provider(s) <NUM> identified within the boot response communicated to the server node 204a. In this way, the server node 204a may have information identifying one or more OS provider(s) <NUM> while the OS provider(s) <NUM> similarly has information identifying the server node 204a.

As shown in <FIG>, the OS provider(s) <NUM> may perform an act <NUM> of providing a maintenance OS file to the first server node 204a. In this example, the server node 204a and/or OS provider(s) <NUM> may initiate contact and cause the maintenance OS file to be downloaded or otherwise transferred from the OS provider(s) <NUM> to the server node 204a. As shown in <FIG>, the maintenance file may be provided via the VPN tunnel <NUM>. In accordance with one or more embodiments described herein, the server node 204a may instantiate the maintenance OS thereon providing various testing and diagnostic functionalities to the server node 204a without providing full functionality of a full OS.

<FIG> illustrates an example environment 400b showing an example implementation in which the first server node 204a obtains a copy of a full OS file for instantiation on the server node 204a. It will be understood that <FIG> shows one or more subsequent acts that may be performed by the OS provisioning system <NUM> and the server node 204a after the acts <NUM>-<NUM> illustrated in <FIG>.

As shown in <FIG>, the first server node 204a may have a maintenance OS instantiated thereon. After performing one or more health checks and verifying functionality of the server node 204a within a framework of the edge zone <NUM> and/or cloud computing system <NUM>, the first server node 204a may perform an act <NUM> of providing another boot request to the OS provisioning system <NUM>. In particular, as shown in <FIG>, the server node 204a may provide a boot request directly to the OS provider(s) <NUM> based on previously received information indicating an identified of one or more OS provider(s) <NUM> capable of servicing an OS boot file request.

In this example, the first server node 204a provides a boot request specifically requesting access to a full OS boot file. Moreover, as shown in <FIG>, the server node 204a may provide the boot request using a different communication medium or protocol from the VPN tunnel. For instance, rather than sending another boot request to a DHCP server using DHCP, the first server node 204a may provide the boot request via hypertext transfer protocol (HTTP). The request may further be provided via an alternative network (e.g., a public network) having more bandwidth resources than the VPN tunnel <NUM>.

As shown in <FIG>, in response to receiving the boot request, the OS provider(s) <NUM> can perform an act <NUM> of providing the OS file (e.g., the full OS file) to the first server node 204a.

The OS provider(s) <NUM> provides the OS file via a different network than the VPN tunnel <NUM> based on the boot request being provided via an HTTP request. Providing the OS file in this way based on the HTTP request enables the OS provider(s) <NUM> to provide a much larger full OS file (e.g., than the maintenance file) to the first server node 204a without using limited bandwidth of the VPN tunnel <NUM>. In this way, the VPN tunnel <NUM> may be used for processing other requests including, by way of example, other DHCP requests that may be received from one or additional server nodes on the edge zone <NUM>.

Upon receiving the full OS file, the first server node 204a instantiates the full OS instance on the server node, which includes implementing a peer booting system <NUM>. For example, <FIG> shows an example implementation in which the first server node 204a has loaded the full OS thereon and implemented the peer booting system <NUM> configured to provide some or all of the same features as the OS provider(s) <NUM> to other server nodes 204b-n on the edge zone <NUM>.

<FIG> shows another example environment 400c in which the full operating system is instantiated on the first server node 204a having a peer booting system <NUM> implemented thereon. It will be understood that <FIG> shows one or more subsequent acts that may be performed by the OS provisioning system <NUM> and server nodes 204a-n after the acts <NUM>-<NUM> illustrated in <FIG>.

As shown in <FIG>, a second server node 204b performs an act <NUM> of providing a second DHCP request to the request manager <NUM> on the OS provisioning system <NUM>. The second DHCP request may include similar information as the first DHCP request in connection with the second server node 204b. For example, the second DHCP request may include any information about the second server node 204b, such as an IP address for the second server node 204b. The DHCP request may additionally include information about the edge zone <NUM> that the request manager <NUM> may use to verify that the second server node 204b originated from the approved edge zone <NUM>. In one or more embodiments, the request manager <NUM> identifies that the second DHCP request originates from a second server node 204b that shares a local network with the first server node 204a.

As shown in <FIG>, the request manager <NUM> may perform an act <NUM> of processing the DHCP request that involves providing information about the DHCP request to the provisioning manager <NUM>. For example, upon verifying that the DHCP request originates from an approved edge zone <NUM>, the request manager <NUM> may provide the second DHCP request (or information obtained from the DHCP request) to the provisioning manager <NUM> for further processing. In one or more embodiments, the request manager <NUM> provides additional instructions indicating that the second server node 204b corresponds to the first server node 204a having the operating system <NUM> (e.g., a full operating system) and peer booting system <NUM> thereon. Alternatively, in one or more embodiments, the provisioning manager <NUM> may make the determination that the server nodes 204a-b are on a common edge zone <NUM>.

As shown in <FIG>, the provisioning manager <NUM> performs an act <NUM> of providing a DHCP response to the second server node 204b. As shown in <FIG>, the DHCP response may be provided directly to the second server node 204b via the VPN tunnel <NUM>. In one or more embodiments, the DHCP response is provided to the second server node 204b upon verifying or otherwise determining that the second server node 204b is on the edge zone <NUM> and capable of receiving the OS file(s) from the first server node 204a.

As shown in <FIG>, the provisioning manager <NUM> provides the DHCP response including an identification of the first server node 204a, which may be done in contrast to the first DHCP response in which an IP address for the OS provider(s) <NUM> on the OS provisioning system <NUM> were identified. Indeed, based on verifying that one or more server nodes on the edge zone <NUM> have a full operating system instantiated thereon, the provisioning manager <NUM> provides IP addresses of one or more server nodes on the edge zone <NUM> having full operating systems without providing information about the OS provider(s) <NUM> as previously performed when a server node is the first of the edge zone <NUM> to provide the boot request(s). In this way, the OS provisioning system <NUM> can facilitate peer to peer booting on the edge zone <NUM> via a direct connection <NUM> (e.g., a wired connection, such as an optical fiber connection) in a way that does not utilize limited bandwidth resources of the VPN tunnel <NUM>.

Turning now to <FIG>, this figure illustrates an example flowchart including a series of acts related to instantiating an operating system on a server node of an edge zone as well as facilitating peer to peer provisioning of operating systems between server nodes of the edge zone. While <FIG> illustrate acts according to one or more embodiments, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown in <FIG>. The act of <FIG> can be performed as part of a method. Alternatively, a non-transitory computer-readable medium can include instructions that, when executed by one or more processors, cause a computing device to perform the acts of <FIG>. In still further embodiments, a system can perform the act of <FIG>.

<FIG> shows a series of acts <NUM> for instantiating an operating system on a server node of an edge zone that can act as an OS provider(s) for one or more additional server nodes on the edge zone.

As shown in <FIG>, the series of acts <NUM> includes an act <NUM> of receiving a first boot request from a first edge zone. In one or more embodiments, the act <NUM> includes receiving, at a control plane system, a first boot request from a first node at an edge location.

In one or more embodiments, the first boot request includes a dynamic host configuration protocol (DHCP) request provided to a DHCP server on the control plane system, and wherein the first boot request is communicated via a virtual private network (VPN) tunnel connecting a plurality of nodes at the edge location and the control plane system. Further in one or more embodiments, the DHCP server is located on a datacenter of a cloud computing system where the datacenter is located at a remote location from the edge location.

As further shown, the series of acts <NUM> includes an act <NUM> of generating a first boot response including an identifier for the first edge node (e.g., a server node) and information associated with an OS provider service. For example, in one or more embodiments, the act <NUM> includes generating, in response to the first boot request, a first boot response including an identifier for the first node and information associated with an operating system (OS) provider service on the control plane system.

In one or more embodiments, generating the first boot response includes providing the identifier for the first node to a control plane hosting the OS provider service thereon where the identifier for the first node includes an internet protocol (IP) address for the first node. Generating the first boot response may also include providing the information associated with the OS provider service to the first node, the information including an IP address for the control plane hosting the OS provider service and instructions associated with obtaining the OS file from the OS provider service.

As further shown, the series of acts <NUM> includes an act <NUM> of providing an OS file to the first edge node and causing the first edge node to instantiate an OS instance thereon. For example, in one or more embodiments, the act <NUM> includes causing the OS provider service to provide an OS file to the first node, wherein providing the OS file to the first node causes the first node to instantiate an OS instance on the first node where the OS instance provides a local instance of the OS provider service on the first node.

In one or more embodiments, causing the OS provider server to provide the OS file to the first node includes providing a maintenance OS file to the first node based on receiving the first boot request where providing the maintenance OS file causes the first node to instantiate a maintenance OS instance on the first node. Causing the OS provider server to provide the OS provide may further include providing a full OS file to the first node that causes the first node to instantiate a full OS instance on the first node. In one or more embodiments, the full OS instance may include the local instance of the OS provider service. In addition, the OS provider service may enable the first node to provide the maintenance OS file and the full OS file to one or more nodes at the edge location.

In one or more embodiments, the first boot request is provided via a first communication protocol. In addition, causing the OS provider server to provide the OS file to the first node may further include receiving, from the first node having the maintenance OS instance instantiated thereon, a request for the full OS file. In one or more embodiments, the request for the full OS file is communicated via a second communication protocol different from the first communication protocol. In one or more embodiments, the first communication protocol may be a dynamic host configuration protocol (DHCP) while the second communication protocol may be a hypertext transfer protocol (HTTP).

A further shown, the series of acts <NUM> includes an act <NUM> of receiving a second boot request from a second edge zone. For example, in one or more embodiments, the act <NUM> includes receiving, at the control plane system, a second boot request from a second node at the edge location.

As further shown, the series of acts <NUM> includes an act <NUM> of providing a second boot response to the second edge node including instructions associated with obtaining the OS file (e.g., a copy of the OS file) from the first edge node. For example, in one or more embodiments, the act <NUM> includes providing, to the second node in response to the second boot request and based on a determination that the OS instance is instantiated on the first node, a second boot response including instructions associated with obtaining the OS file from the first node.

In one or more embodiments, the series of acts <NUM> may include queuing the second boot request based on receiving the first boot request prior to receiving the second boot request and determining that the second boot request originates from a same edge location as the edge location associated with the first node.

In one or more embodiments, providing the second boot response includes providing the second boot response includes providing the instructions associated with obtaining the OS file from the first server node without causing the control plane system to provide the OS file to the second server node. Further, in one or more embodiments, providing the second boot response to the second node causes the second node to access an OS file from the first node and instantiate an OS instance on the second node. In one or more embodiments, the OS instance on the second node enables the second node to act as another local instance of the OS provider service for one or more additional nodes at the edge location.

In one or more embodiments, the first node and the second node include data plane devices that are logically connected to the control plane system via a virtual private network (VPN) between nodes of the edge location and the control plane system. Further, in one or more embodiments, the control plane system includes control plane server devices implemented on a datacenter of a cloud computing system.

The computer system <NUM> includes a processor <NUM>. The processor <NUM> may be a general-purpose single- or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor <NUM> may be referred to as a central processing unit (CPU). Although just a single processor <NUM> is shown in the computer system <NUM> of <FIG>, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

The computer system <NUM> also includes memory <NUM> in electronic communication with the processor <NUM>. The memory <NUM> may be any electronic component capable of storing electronic information. For example, the memory <NUM> may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, on-board memory included with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, and so forth, including combinations thereof.

A computer system <NUM> may also include one or more input devices <NUM> and one or more output devices <NUM>. Some examples of input devices <NUM> include a keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, and lightpen. Some examples of output devices <NUM> include a speaker and a printer. One specific type of output device that is typically included in a computer system <NUM> is a display device <NUM>. Display devices <NUM> used with embodiments disclosed herein may utilize any suitable image projection technology, such as liquid crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence, or the like. A display controller <NUM> may also be provided, for converting data <NUM> stored in the memory <NUM> into text, graphics, and/or moving images (as appropriate) shown on the display device <NUM>.

The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a specific manner. Any features described as modules, components, or the like may also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a non-transitory processor-readable storage medium comprising instructions that, when executed by at least one processor, perform one or more of the methods described herein. The instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform particular tasks and/or implement particular data types, and which may be combined or distributed as desired in various embodiments.

Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

As used herein, non-transitory computer-readable storage media (devices) may include RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

The steps and/or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims. The term "determining" encompasses a wide variety of actions and, therefore, "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining and the like. For example, any element or feature described in relation to an embodiment herein may be combinable with any element or feature of any other embodiment described herein, where compatible.

Claim 1:
A method, comprising:
receiving (<NUM>), at a control plane system, a first boot request from a first node at an edge location;
generating (<NUM>), in response to the first boot request, a first boot response including an identifier for the first node and information associated with an operating system, OS, provider service on the control plane system, wherein the first boot response is transmitted via a virtual private network, VPN;
causing the OS provider service to provide (<NUM>) an OS file to the first node, wherein providing the OS file to the first node causes the first node to instantiate an OS instance on the first node, wherein the OS instance provides a local instance of the OS provider service on the first node, and wherein the OS file is provided via a different network than the VPN;
receiving (<NUM>), at the control plane system, a second boot request from a second node at the edge location; and
providing (<NUM>), to the second node in response to the second boot request and based on a determination that the OS instance is instantiated on the first node, a second boot response including instructions associated with obtaining the OS file from the first node.