Dynamic network routing based on application load

Abstract

Techniques for dynamic routing based on application load are described herein. These techniques can include receiving load information associated with resources of an application coordination system, the resources allocated for hosting applications, the resources associated with different geographic regions. Based at least in part on the load information, a network controller can determine that a first resource of the application coordination system is less constrained than a second resource of the application coordination system, the first resource associated with a first geographic region and the second resource associated with a second geographic region. Based at least in part on the first resource being less constrained than the second resource, application traffic can be routed through the network to an application hosted by the first resource in the first geographic region.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Utility Model Patent Application No. 17 / 503,660, filed October 18, 2021, and U.S. Provisional Patent Application No. 63 / 155,658, filed March 2, 2021, the entire contents of which are incorporated herein by reference and used for all purposes. Technical Field

[0003] This disclosure generally relates to various techniques for enabling networks (particularly software-defined wide area networks) to make dynamic routing decisions based on application loads across multiple areas. Background Technology

[0004] Traditionally, networks lack knowledge about the health of the applications they connect to. In some cases, networks may attempt to infer application health using various probing techniques. This could include monitoring traffic between clients and applications to detect if an application is experiencing load issues, or sending application requests to application endpoints to measure responsiveness and response time. However, these probing techniques limit the types of optimizations a network can make to provide appropriate application connectivity and restrict its proactiveness. Therefore, with limited knowledge of application health, the best a network can do is react as problems arise rather than proactively mitigating them. Attached Figure Description

[0005] The following is a detailed description with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which that numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not to scale, and the components in the drawings may not be depicted to scale relative to each other.

[0006] Figure 1A and Figure 1B This is a system architecture diagram, illustrating example architectures and data flows associated with some of the techniques described in this article for routing traffic based on application load.

[0007] Figure 2 This is a sample table showing different load information that can be used to determine which application / location traffic should be routed to.

[0008] Figure 3 This is another example table showing different load information that can be used to determine which application / location traffic should be routed to.

[0009] Figure 4This is a flowchart illustrating an example method for performing load-based routing of application traffic.

[0010] Figure 5 This is a computer architecture diagram, illustrating an illustrative computer hardware architecture for implementing various aspects of computing devices that can be utilized to realize the various techniques proposed in this paper. Detailed Implementation

[0011] Overview

[0012] The independent claims describe various aspects of the invention, and the dependent claims describe preferred features. A feature of one aspect may be applied individually to each aspect or in combination with other aspects.

[0013] This disclosure describes various techniques associated with enabling a network to make dynamic routing decisions based on application load across multiple regions. As an example, and not a limitation, methods according to the various techniques proposed herein may include receiving, at a network controller, a request to route traffic across the network, the traffic being associated with an application. Furthermore, the method may include receiving, at the controller, load information associated with a resource of an application coordination system allocated for hosting the application. This load information may include first load information associated with a first resource of the application coordination system, allocated for hosting the application, located in a first geographic region. Additionally, the load information may include second load information associated with a second resource of the application coordination system, allocated for hosting the application, located in a second geographic region different from the first geographic region. The method may also include the controller determining, at least in part, based on the load information, that the first resource is subject to fewer constraints than the second resource. Based at least in part on the fact that the first resource is subject to fewer constraints than the second resource, the controller may route traffic across the network to the application hosted by the first resource in the first geographic region.

[0014] Furthermore, the techniques described herein can be executed as methods and / or performed by a system having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the techniques described above.

[0015] Example Implementation

[0016] As mentioned above, networks traditionally lack knowledge about the health of the applications they connect to. In some cases, networks may attempt to infer application health by using various probing techniques. This could include monitoring traffic between clients and applications to detect if an application is experiencing load issues, or sending application requests to application endpoints to measure responsiveness and response time. However, these probing techniques limit the types of optimizations a network can perform to provide appropriate application connectivity and restrict the network's proactivity. Therefore, with limited knowledge of application health, the best a network can do is react as problems arise rather than proactively mitigating them.

[0017] Therefore, this disclosure describes techniques for integrating networks (e.g., SD-WAN) with application coordination systems (e.g., cloud-native, scalable application service platforms such as Kubernetes or any other application system) to make automated decisions about redirecting traffic based on application load. Compared to existing solutions, these techniques allow the network to have firsthand information about application health provided by the application infrastructure, and the network can use this information to derive routing policies. This deviates from traditional routing algorithms in networks, which forward traffic based on reachability information and network performance.

[0018] In some examples, application health information can be exchanged by the network controller (e.g., an SD-WAN controller / orchestrator) via a shared application programming interface (API) through external components (e.g., a service registry, key-value database, etc.), or even via signaling on data plane packets. In some examples, the controller can proactively retrieve this information, for example, by periodically querying the application coordination system. Additionally or alternatively, the controller can be notified when application load information is updated. For example, the controller can be notified via a subscription service, where the controller subscribes to certain applications and is notified when the load on these applications changes.

[0019] In some examples, load information can consist of multiple pieces of information. For example, load information may include the current infrastructure utilization of an application component, which may be in terms of CPU or memory usage. Additionally or alternatively, load information may include the number of copies of a given application or how many backend components are maintaining the application's current operation.

[0020] In some cases, to use application load information for dynamic routing decisions, the same application may need to be available in different geographic regions. In this way, the network controller can select which region is better suited to receive traffic routed through the network. In the example, application load information can be associated with the geographic region where the application is located.

[0021] In some examples, to use application load for dynamic routing decisions, the network controller and the application coordination system can agree on how to represent the load. For example, one option could be for the application coordination system to display application load in a specific region as a percentage of the total number of supported application loads in that region. Additionally or alternatively, another option could be to represent the load as different tiers (e.g., green, yellow, red, etc.) and pass this information to the network controller.

[0022] Based on the techniques disclosed herein, improvements to computer-related technologies can be achieved. For example, by dynamically allocating traffic to applications based on their current load, the likelihood of resource overload and / or errors can be reduced. Furthermore, this technology allows the network to possess firsthand information about application health provided by the application infrastructure, and the network can use this information to derive routing strategies. Moreover, by allocating traffic to applications based on their current load, computing resources are used more efficiently and effectively by reducing the amount of unused computing resources.

[0023] By way of example, and not limitation, methods based on the techniques disclosed herein may include receiving a request to route traffic over a network associated with an application. In some examples, the network may be a software-defined wide area network (SD-WAN) providing client connectivity to the application. In at least one example, the request is received at a network controller (e.g., an SD-WAN controller / coordinator), a network router, a logical node of the network, and / or the like.

[0024] In some examples, the method may include receiving load information associated with a resource of an application coordination system (e.g., a scalable application service platform such as Kubernetes, Amazon ECS, Docker Swarm, Apache Messos, etc.). The resource may be allocated for hosting applications. For example, the load information may be received by the controller, router, and / or logical node described above. In some examples, the load information may include first load information associated with a first resource of the application coordination system, which is allocated for hosting an application (e.g., a first instance of the application). The first resource may be located in a first geographic region, geographic location, etc. (e.g., the West Coast of the United States), or otherwise associated with it. Furthermore, the load information may include second load information associated with a second resource of the application coordination system, which is allocated for hosting an application (e.g., a second instance of the application). The second resource may be located in a second geographic region, geographic location, etc. (e.g., the East Coast of the United States), or otherwise associated with it.

[0025] In various examples, load information associated with resources can indicate the utilization of resources allocated to host applications and / or other applications in each geographic region. Resources include processing units or memory. Additionally or alternatively, load information can indicate the number of copies of the application or other application instantiated in each geographic region. In some examples, load information can indicate the current load on a resource or the projected future load on a resource.

[0026] In some examples, load information from the application coordination system can be received (e.g., by the controller) via an application programming interface (API), a service registry, or a database (e.g., a key-value database). Additionally or alternatively, load information can be received via telemetry data carried in application traffic. In some examples, load information can be received at least in part based on time period expiration or load information updates.

[0027] In some examples, the method may include determining, at least in part, that the first resource is less constrained than the second resource based on load information. For example, controllers, routers, logical nodes, etc., may determine that the first resource has more available processing units (e.g., CPUs, GPUs, etc.), more available memory, and / or more instantiated copies of the application than the second resource. Additionally or alternatively, controllers, routers, logical nodes, etc., may determine that the first resource may be less constrained than the second resource based on historical utilization data and demand patterns.

[0028] In some examples, a reachability score can be determined for each of the different resources. A reachability score indicates which resources are associated with the shortest routing path. For example, a first reachability score can be determined, associated with an application hosted by a first resource located in a first geographic region. Furthermore, a second reachability score can be determined, associated with an application hosted by a second resource located in a second geographic region. In various examples, controllers, routers, logical nodes, etc., can determine the reachability scores for all resources running applications.

[0029] In various examples, traffic can be routed across the network to an application hosted by a first resource, which is located in or otherwise associated with a first geographic region. For example, traffic may be routed to the application hosted by the first resource at least in part based on the first resource being subject to fewer constraints than a second resource. Furthermore, in some examples, traffic may be routed across the network to the application hosted by the first resource at least in part based on the first reachability score associated with the first resource being better than or equal to a second reachability score associated with the second resource.

[0030] In at least one example, a first portion of the traffic can be routed across the network to an application hosted by a first resource, and a second portion of the traffic can be routed across the network to an application hosted by a second resource. In some examples, the first and second portions of the traffic can be proportional to the availability of the first and second resources. For example, if the first resource / application is running at 40% capacity and the second resource / application is running at 60% capacity, then 60% of new traffic requests can be routed to the first resource / application, and 40% of new traffic requests can be routed to the second resource / application.

[0031] In some examples, traffic can be routed based on a "load-first routing" scheme. In this operating mode, load balancing priorities can be established first, followed by application health, and then other policy / telemetry / metadata attributes available on the network. This means that, where possible, traffic for a specific application that is available in multiple locations can be routed to the location with the best load.

[0032] In some examples, traffic can be routed based on a "load priority routing" scheme. In this operating mode, application load can be combined with other routing parameters and may be used as part of routing decisions (e.g., SD-WAN routing decisions) to break up tie-breaking.

[0033] In some examples, traffic can be routed based on a "load-sharing" scheme. In this operating mode, traffic can be dynamically balanced across different application locations based on the current load at each location.

[0034] Certain implementations and embodiments of this disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are illustrated. However, these various aspects may be implemented in many different forms and should not be construed as limited to the implementations described herein. This disclosure covers variations of the embodiments as described herein. Similar numerals always refer to similar elements.

[0035] Figure 1A and Figure 1BThis is a system architecture diagram illustrating an example architecture 100 and data flow associated with some of the techniques described herein for routing traffic based on application load. Architecture 100 may include a network 102 having a network controller 104 and one or more nodes 106 that route traffic through the network 102. For example, node 106 may route traffic between one or more client devices 108 and one or more applications 110(1)-110(N) (hereinafter collectively referred to as "application 110") (where N represents any number greater than or equal to 1) of different application coordination systems 112(1), 112(2), and 112(N) (collectively referred to as "application coordination system 112") (where N represents any number greater than or equal to 1). In various examples, the same application 110 (or different instances of the same application) may be running at different application coordination systems 112, and node 106 of network 102 may route traffic to application 110 with the least load.

[0036] Network 102 may be a software-defined wide area network (SD-WAN), and controller 104 may be an SD-WAN controller / coordinator. Node 106 may be a logical node and / or any physical device capable of forwarding packets. For example, node 106 may be a router, switch, general-purpose computer, software node, gateway, and / or any other network device capable of forwarding packets through network 102. Network 102 may facilitate traffic communication between client device 108 and application 110 of application coordination system 112. In some examples, network 102 may include an overlay network and an underlay network. The overlay network may include a telecommunications network built on top of and supported by its infrastructure (e.g., physical devices of the underlay network such as node 106). The underlay network may include: a software-defined / API-driven underlay provider (e.g., PacketFabric, Megaport, PCCW Global's ConsoleConnect, etc.), or any other underlay. It should be understood that, for simplicity, although controller 104 is shown residing in the same network 102, controller 104 may reside in a different network than node 106. In some cases, controller 104 may also reside in a different geographical location than node 106, either separately or alternatively.

[0037] Application coordination system 112 may use its infrastructure (e.g., physical devices such as computing resource 114) to host one or more third-party applications, virtual machines, containers, etc. For example, application coordination system 112 may be a cloud-native, scalable application service platform (e.g., a container-coordination system such as Kubernetes, Amazon ECS, DockerSwarm, Apache Messos, etc.). Computing resource 114 of application coordination system 112 may be used to host application 110. Computing resource 114 may include: hardware servers, software servers running on computer hardware, processors, general-purpose computers, etc. In some examples, application coordination system 112 (or computing resource 114) may be located in different geographic regions or geographic locations, or otherwise associated with such regions or locations, such as a first geographic location 116(1), a second geographic location 116(2), and an Nth geographic location 116(N) (collectively referred to as “Geographic Location 116”) (where N represents any number greater than or equal to 1). In some examples, a single application coordination system 112 may be associated with two or more different geographic locations 116. In some examples, computing resources 114 and / or applications 110 may be distributed among the following: different data centers associated with application coordination system 112, different networks associated with application coordination system 112, different regions of cloud service providers, etc.

[0038] about Figure 1A At point “1”, network 102 (e.g., controller 104 or node 106) may receive load information associated with application coordination system 112 and / or load information associated with a specific application 110 hosted by application coordination system 112. In some examples, load information may be received from application coordination system 112 via application programming interface (API), external components (e.g., service registry, database, key-value store, etc.), and / or the like. Additionally or alternatively, load information may be received via telemetry data carried within traffic. In some examples, network 102 may proactively retrieve the load information, for example, by periodically querying application coordination system 112. Additionally or alternatively, when application load information is updated, network 102 may be notified, for example, through a subscription service, where network 102 subscribes to certain applications and is notified when the load of these applications changes. In some examples, load information may indicate the availability or unavailability of processing units (e.g., CPU, GPU, etc.) and / or memory associated with application 110, application coordination system 112, and / or computing resources 114. Additionally or alternatively, load information may indicate the number of copies of each application currently instantiated at geographic location 116 of each application coordination system 112.

[0039] In various examples, load information can be used to determine the load capacity of a specific application 110 and / or the load capacity of the computing resources 114 hosting the specific application 110. For example, load information received from application coordination system 112(1) can be used to determine that application 110 hosted by application coordination system 112(1) and / or computing resources 114 of application coordination system 112(1) are running at 100% capacity. Furthermore, load information received from application coordination system 112(2) can be used to determine that application 110 hosted by application coordination system 112(2) and / or computing resources 114 of application coordination system 112(2) are running at 60% capacity. And further, load information received from application coordination system 112(N) can be used to determine that application 110 hosted by application coordination system 112(N) and / or computing resources 114 of application coordination system 112(N) are running at 40% capacity, and so on.

[0040] about Figure 1B At "2", network 102 may receive new traffic 118 from one or more client devices 108, which will be sent to one of the applications 110. For example, one of the nodes 106 of network 102 may receive new traffic 118. At "3", network 102 may direct new traffic 118 to the application 110 hosted by application coordination system 112(N) at geographic location 116(N), based at least in part on load information indicating that application 110 and / or the resource 114 hosting the application is operating at 40% capacity. For example, network 102 may direct new traffic 118 to the application 110 hosted by application coordination system 112(N) at geographic location 116(N), based at least in part on load information indicating that application 110 and / or the resource 114 hosting the application is operating at 40% capacity.

[0041] In some examples, if network 102 routes traffic according to a "load-sharing" scheme, network 102 may route a first portion of new traffic 118 to application 110 hosted by application coordination system 112(N) at geographic location 116(N), and network 102 may route a second portion of new traffic 118 to application 110 hosted by application coordination system 112(2) at geographic location 116(2). For example, network 102 may route 60% of new traffic 118 to application 110 hosted by application coordination system 112(N) at geographic location 116(N), and network 102 may route 40% of new traffic 118 to application 110 hosted by application coordination system 112(2) at geographic location 116(2).

[0042] Figure 2This is an example table 200 illustrating different load information that can be used to determine which application / location traffic should be routed to. The table may include information associated with application 202 that can be used to determine where traffic should be sent at different time instances. For example, information associated with application 202 may include routing preferences 204, application health 206, and reachability 208.

[0043] As shown in Table 200, application 202(1) in the first geographic location includes a “high” routing preference 204(1), operates at “maximum capacity” 206(1), and has a “good” reachability score 208(1). Application 202(2) in the second geographic location includes a “low” routing preference 204(2), operates at “40% capacity” 206(2), and has a “good” reachability score 208(2). Application 202(N) in the Nth geographic location includes a “high” routing preference 204(N), operates at “60% capacity” 206(N), and has a “good” reachability score 208(N).

[0044] In some examples, traffic can be routed based on a "load-first routing" scheme. In this operating mode, load balancing priorities can be established as follows: first, application health 206, and then other policy / telemetry / metadata attributes available on the network (e.g., routing preferences 204 and / or reachability 208). This means that, where possible, traffic available in multiple locations for a particular application can be routed to the location with the best load. For example, in Table 200, application 202(2) in the second geographic location will receive all traffic routed through the network for application 202 because application 202(2) in the second geographic location has the best application health 206(2) (40% capacity).

[0045] In some examples, traffic can be routed based on a "load priority routing" scheme. In this mode of operation, application load can be combined with other routing parameters and may be used as part of a routing decision (e.g., SD-WAN routing decision) to break ties. For example, in Table 200, application 202(1) in the first geographic location and application 202(N) in the Nth geographic location are equivalent in terms of reachability 208 (e.g., shortest path routing), so the application health 206 (e.g., load) of application 202 in these two locations can be used to break ties. In the case shown in Table 200, application health will break the ties (favoring application 202(N) in the Nth geographic location) because the application health 206(N) of application 202(N) in the Nth geographic location is better than the application health 206(1) of application 202(1) in the first geographic location (e.g., 60% capacity relative to maximum capacity).

[0046] In some examples, traffic can be routed based on a "load-ratio routing" scheme. In this operating mode, traffic can be dynamically balanced across different application locations based on the current application health 206 within each location. This means that if, in Table 200, the load of application 202(1) in the first geographic location is 100%, the load of application 202(2) in the second geographic location is 40%, and the load of application 202(N) in the Nth geographic location is 60%, the network will use this information to send 0% of the traffic to application 202(1) in the first geographic location, 60% of the traffic to application 202(2) in the second geographic location, and 40% of the traffic to application 202(N) in the Nth geographic location.

[0047] Figure 3 This is another example table 300 illustrating different load information that can be used to determine which application / location traffic should be routed to. Example table 300 is similar to... Figure 2 The example table 200 shown, except that in table 300, the application health 306 and reachability 308 of each application 302 are represented in a different pattern to indicate the application health 306 and reachability 308.

[0048] As shown in Table 300, application 302(1) in the first geographic location includes a “high” routing preference 304(1), application health 306 operating at or near maximum capacity (indicated by a dark fill pattern), and a good reachability score 308 (indicated by a light fill pattern). Application 302(2) in the second geographic location includes a “low” routing preference 304(2), application health 306 operating at or near low load capacity (indicated by a light fill pattern), and a good reachability score 308. Application 302(N) in the Nth geographic location includes a “high” routing preference 304(N), application health 306 operating at or near medium load capacity (indicated by a medium fill pattern), and a good reachability score 308.

[0049] In some examples, the different patterns used to indicate the application health 306 and accessibility 308 of each application 302 may additionally or alternatively be represented by different colors, patterns, or other visual indicators. For example, the application health 306 of application 302(1) in a first geographic location may be represented in red to indicate that the application health 306 is at or near maximum capacity (e.g., greater than the threshold capacity). Furthermore, the application health 306 of application 302(2) in a second geographic location may be represented in green to indicate that the application health 306 is at or near good operating capacity (e.g., less than the threshold operating capacity). Furthermore, the application health 306 of application 302(N) in the Nth geographic location may be represented in yellow to indicate that the application health 306 is at or near intermediate operating capacity.

[0050] In some examples, traffic can be routed based on a "load-first routing" scheme. In this operating mode, load balancing priorities can be established as follows: first, application health 306, followed by other policy / telemetry / metadata attributes available on the network (e.g., routing preferences 304 and / or reachability 308). This means that, where possible, traffic available in multiple locations for a particular application can be routed to the location with the best load. For example, in Table 300, application 302(2) in the second geographic location will receive all traffic routed through the network for application 302 because application 302(2) in the second geographic location has the best application health 306 (e.g., green indicates good capacity).

[0051] In some examples, traffic can be routed based on a "load priority routing" scheme. In this mode of operation, application load can be combined with other routing parameters and may be used as part of a routing decision (e.g., SD-WAN routing decision) to break the tie. For example, in Table 300, application 302(1) in the first geographic location and application 302(N) in the Nth geographic location are equivalent in terms of reachability 308 (e.g., shortest path routing), so the application health 306 (e.g., load) of application 302 in these two locations can be used to break the tie. In the case shown in Table 300, application health will break the tie (favoring application 302(N) in the Nth geographic location) because the application health 306 of application 302(N) in the Nth geographic location is better than the application health 306 of application 302(1) in the first geographic location (e.g., yellow indicating intermediate operating capacity versus red indicating at or near maximum operating capacity).

[0052] In some examples, traffic can be routed based on a "load-ratio routing" scheme. In this operating mode, traffic can be dynamically balanced across different application locations based on the current application health 306 of each location. This means that if, in Table 300, the load of application 302(1) in the first geographic location is 100%, the load of application 302(2) in the second geographic location is 40%, and the load of application 302(N) in the Nth geographic location is 60%, the network will use this information to send 0% of the traffic to application 302(1) in the first geographic location, 60% of the traffic to application 302(2) in the second geographic location, and 40% of the traffic to application 302(N) in the Nth geographic location.

[0053] Figure 4 This is a flowchart illustrating an example method 400 for performing load-based routing of application traffic. The document describes... Figure 4 The logical operations can be implemented as: (1) a sequence of actions or program modules implemented by a computer running on a computing system, and / or (2) machine logic circuits or circuit modules interconnected within the computing system.

[0054] The implementation of the various components described herein is a matter of selection dependent on the performance and other requirements of the computing system. Therefore, the logical operations described herein are referred to differently as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented using software, firmware, special-purpose digital logic, and any combination thereof. It should also be understood that it is possible to perform operations that are more complex than those described herein. Figure 4 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. Although the techniques described in this disclosure are directed to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0055] Method 400 begins with operation 402, which includes receiving a request at the network controller to route application-related traffic over the network. For example, the controller 104 of network 102 may receive a request from one or more client devices 108 to route new traffic 118 over network 102 and to route the new traffic 118 to one of applications 110 hosted by computing resources 114 of application coordination system 112.

[0056] In operation 404, method 400 includes receiving, at a controller, first load information associated with a first resource of the application coordination system, the first resource being allocated to host an application, and the first resource being associated with a first geographic region. For example, controller 104 of network 102 may receive first load information associated with a first computing resource 114 of application coordination system 112(N), the first computing resource being associated with a first geographic location 116(N).

[0057] In operation 406, method 400 includes receiving, at the controller, second load information associated with a second resource of the application coordination system, the second resource being allocated to host applications and associated with a second geographic region. For example, controller 104 of network 102 may receive second load information associated with a second computing resource 114 of application coordination system 112(2), the second computing resource being associated with a second geographic location 116(2).

[0058] In operation 408, method 400 includes determining, at least in part, based on load information, that a first resource is subject to fewer constraints than a second resource. For example, the controller may determine that a first computing resource 114 of an application coordination system 112(N) associated with a first geographic location 116(N) is subject to fewer constraints than a second computing resource 114 of an application coordination system 112(2) associated with a second geographic location 116(2) (e.g., 40% application load capacity versus 60% application load capacity).

[0059] In operation 410, method 400 includes routing at least a portion of traffic across the network to an application hosted by a first resource associated with a first geographic region. For example, node 106 of network 102 may route a first portion of new traffic 118 across network 102 to application 110 hosted by a first computing resource 114 of application coordination system 112 (1) associated with a first geographic location 116 (1). Furthermore, in some examples, node 106 of network 102 may route a second portion of new traffic 118 across network 102 to application 110 hosted by a second computing resource 114 of application coordination system 112 (2) associated with a second geographic location 116 (2). In various embodiments, the first portion may be larger than the second portion in proportion to the application load of each application 110 hosted by application coordination system 112.

[0060] Figure 5 This is a computer architecture diagram, illustrating an illustrative computer hardware architecture for implementing various aspects of computing devices that can be utilized to realize the various techniques proposed in this paper. Figure 5The computer architecture shown illustrates conventional server computers, controllers 104, computing resources 114, nodes 106, routers, workstations, desktop computers, laptops, tablets, network devices, e-readers, smartphones, or other computing devices, and can be used to execute any of the software components proposed herein.

[0061] Computer 500 includes a baseboard 502, or “motherboard,” which is a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication paths. In an illustrative configuration, one or more central processing units (CPUs) 504 operate in conjunction with a chipset 506. The CPU 504 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 500.

[0062] The CPU 504 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry (e.g., flip-flops) that maintains one of two binary states, and electronic circuitry (e.g., logic gates) that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adders / subtractors, arithmetic logic units, floating-point units, and so on.

[0063] Chipset 506 provides an interface between CPU 504 and the remaining components and devices on substrate 502. Chipset 506 may provide an interface with RAM 508, which is used as main memory in computer 500. Chipset 506 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 510 or non-volatile RAM (NVRAM), for storing basic routines that facilitate booting computer 500 and transferring information between various components and devices. ROM 510 or NVRAM may also store other software components necessary for the operation of computer 500 according to the configuration described herein.

[0064] Computer 500 can operate in a networked environment using a logical connection to remote computing devices and computer systems via a network (e.g., network 102). Chipset 506 may include functionality for providing network connectivity via NIC 512 (e.g., a Gigabit Ethernet adapter). NIC 512 enables computer 500 to connect to other computing devices via network 524 and / or network 102. It should be understood that multiple NICs 512 may be present in computer 500 to connect the computer to other types of networks and remote computer systems. In some examples, NIC 512 may be configured to perform at least some of the techniques described herein.

[0065] Computer 500 can be connected to storage device 518, which provides non-volatile storage for the computer. Storage device 518 can store operating system 520, programs 522, and data, which have been described in more detail herein. Storage device 518 can be connected to computer 500 via storage controller 514, which is connected to chipset 506. Storage device 518 can consist of one or more physical storage units. Storage controller 514 can be connected to physical storage units via a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0066] Computer 500 can store data on storage device 518 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 518 is characterized as primary or secondary storage, etc.

[0067] For example, computer 500 can store information in storage device 518 by issuing instructions through storage controller 514 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 500 can further read information from storage device 518 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0068] In addition to the aforementioned high-capacity storage device 518, computer 500 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and is accessible by computer 500. In some examples, operations performed by network 102 and / or any components included therein may be supported by one or more devices similar to computer 500. In other words, some or all of the operations performed by network 102 and / or any components included therein may be performed by one or more computer devices 500 operating in a scalable arrangement.

[0069] By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state storage technologies, compact disc ROM (CD-ROM), digital versatile disk (DVD), high-definition DVD (HD-DVD), Blu-ray or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0070] As briefly mentioned above, storage device 518 may store operating system 520 used to control the operation of computer 500. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a MICROSOFT operating system from Redmond, Washington. The server operating system. In another embodiment, the operating system may include a UNIX operating system or a variant thereof. It should be understood that other operating systems may also be used. Storage device 518 may store other systems, applications, and data used by computer 500.

[0071] In one embodiment, storage device 518 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 500, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 500 by specifying how CPU 504 transitions between states. According to one embodiment, computer 500 has access to a computer-readable storage medium storing computer-executable instructions that, when executed by computer 500, perform the above-described... Figures 1A-4 The various processes described herein. The computer 500 may also include a computer-readable storage medium storing instructions for performing any other computer-implemented operations described herein.

[0072] Computer 500 may also include one or more input / output controllers 516 for receiving and processing input from various input devices, such as a keyboard, mouse, touchpad, touchscreen, stylus, or other types of input devices. Similarly, input / output controllers 516 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices. It will be understood that computer 500 may not include... Figure 5 All components shown may include Figure 5 Other components not explicitly shown, or those that may utilize [the technology / method] Figure 5 The architecture shown is completely different.

[0073] Computer 500 may include one or more hardware processors 504 (processors) configured to execute one or more stored instructions. The processors 504 may include one or more cores. Additionally, computer 500 may include one or more network interfaces configured to provide communication between computer 500 and other devices. Network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), etc. For example, network interfaces may include devices compatible with Ethernet, Wi-Fi™, etc.

[0074] Program 522 may include any type of program or process to perform the techniques described in this disclosure for obtaining application network metadata from the service registry to deduce network policies. Program 522 may enable controller 104, node 106, and application coordination system 112 to perform various operations.

[0075] In summary, this paper describes techniques for dynamic routing based on application load. These techniques may include: receiving load information associated with resources of an application coordination system, which are allocated to host applications and associated with different geographic regions. Based at least in part on the load information, a network controller can determine that a first resource of the application coordination system is less constrained than a second resource of the application coordination system, the first resource being associated with a first geographic region, and the second resource being associated with a second geographic region. Based at least in part on the fact that the first resource is less constrained than the second resource, application traffic can be routed across the network to the application hosted by the first resource in the first geographic region.

[0076] Although the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations made to adapt to specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0077] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions are merely illustrative embodiments falling within the scope of the claims of this application.

Claims

1. A method for network routing, the method comprising: The network controller receives requests to route traffic associated with an application through the network. The controller receives load information associated with different instances of the application hosted in different cloud service provider regions, the load information including at least: First load information, associated with a first instance of the application hosted in a first cloud service provider region; and The second load information is associated with a second instance of the application hosted in a second cloud service provider region, which is different from the first cloud service provider region; The controller determines, at least in part, based on the load information, that a first instance of the application is subject to fewer constraints than a second instance of the application; and Traffic is routed through the network to the first instance of the application hosted in the first cloud service provider's region, based at least in part on the fact that the first instance of the application is subject to fewer constraints than the second instance of the application.

2. The method according to claim 1, wherein, The network is a software-defined wide area network (SD-WAN), and the controller is an SD-WAN controller.

3. The method according to claim 1 or 2, wherein, The load information indicates the utilization of resources in the different cloud service provider regions allocated to host the application, including processing units or storage.

4. The method according to claim 1 or 2, wherein, The load information indicates the number of copies of the application instantiated in the different cloud service provider regions.

5. The method according to claim 1 or 2, wherein, The controller receives the load information via one of the following: an application programming interface (API), a service registry, a database, or telemetry data carried in the traffic.

6. The method according to claim 1 or 2, wherein, The controller receives the load information at least in part based on the expiration of a time period or an update of the load information.

7. The method according to claim 1 or 2, wherein, Routing the traffic through the network to a first instance of the application hosted in the first cloud service provider's region includes: The first part of the routed traffic, and The second portion of the traffic is routed, at least in part, based on the fact that the second instance of the application is more constrained than the first instance of the application.

8. The method according to claim 3, wherein, The load information indicates at least one of the current load of the resource or the predicted future load of the resource.

9. The method according to claim 1 or 2, further comprising: The controller determines a first reachability score, which is associated with a first instance of the application that routes the traffic to it. The controller determines a second reachability score, which is associated with a second instance of the application that routes the traffic to it. as well as The routing of traffic to a first instance of the application is also based at least in part on the first reachability score and the second reachability score.

10. A network controller, comprising: One or more processors; as well as A non-transitory computer-readable medium storing one or more instructions, which, when executed by the one or more processors, cause the controller to perform operations, the operations including: Receive a request to route traffic associated with an application through the network; Receive load information associated with different instances of the application hosted in different cloud service provider regions, the load information including at least: First load information, associated with a first instance of the application hosted in a first cloud service provider region; and The second load information is associated with a second instance of the application hosted in a second cloud service provider region, which is different from the first cloud service provider region; Based at least in part on the load information, it is determined that the first instance of the application is subject to fewer constraints than the second instance of the application; and Traffic is routed through the network to the first instance of the application hosted in the first cloud service provider's region, based at least in part on the fact that the first instance of the application is subject to fewer constraints than the second instance of the application.

11. The controller according to claim 10, wherein, The network is a software-defined wide area network (SD-WAN), and the controller is an SD-WAN controller.

12. The controller according to claim 10 or 11, wherein, The load information indicates at least one of the following: the number of copies of the application instantiated in the different cloud service provider regions, or the utilization of resources allocated to host the application in the different cloud service provider regions, including processing units or memory.

13. The controller according to claim 10 or 11, wherein, The controller receives the load information at least in part based on the expiration of a time period or an update of the load information.

14. The controller according to claim 10 or 11, wherein, Routing the traffic through the network to a first instance of the application hosted in the first cloud service provider's region includes: The first part of the routed traffic, and The second portion of the traffic is routed, at least in part, based on the fact that the second instance of the application is more constrained than the first instance of the application.

15. The controller of claim 10 or 11, wherein the operation further comprises: The controller determines a first reachability score, which is associated with a first instance of the application that routes the traffic to it. The controller determines a second reachability score, which is associated with a second instance of the application that routes the traffic to it. as well as The routing of traffic to a first instance of the application is also based at least in part on the first reachability score and the second reachability score.

16. A nontransitory computer-readable medium storing one or more instructions, which, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 9.

17. A network controller, comprising: A means for receiving requests to route traffic over the network, the traffic being associated with an application; A means for receiving load information associated with different instances of the application hosted in different cloud service provider regions, the load information including at least: First load information, associated with a first instance of the application hosted in a first cloud service provider region; and The second load information is associated with a second instance of the application hosted in a second cloud service provider region, which is different from the first cloud service provider region; A means for determining, at least in part, based on the load information, that a first instance of the application is subject to fewer constraints than a second instance of the application; and A means for routing traffic through the network to a first instance of the application hosted in the first cloud service provider’s region, based at least in part on the fact that a first instance of the application is subject to fewer constraints than a second instance of the application.

18. The controller of claim 17, further comprising means for implementing the method of any one of claims 2 to 9.

19. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 9.

Images