Patent Grant
11799824
In the field of accessing applications that operate partially or entirely on servers or other machines accessed over a network such as the Internet, a typical application access first involves a client device (e.g., a computer, smart phone, tablet device, etc.) sending a domain name system (DNS) request to a DNS server. In return, the client receives a DNS response that includes a list of one or more IP addresses where the application is hosted. The IP addresses may be specific addresses of servers hosting the application, but commonly are virtual IP (VIPs) addresses that the client can use to send data to a network address translation (NAT) system or load balancer that forwards the data to a specific server that runs the application.
The DNS server can use a simplistic scheme such as round robin to cycle through the list of available IP addresses. In practice and commercially however, a DNS server usually operates in conjunction with a global server load balancing (GSLB) solution. A GSLB solution ensures that the incoming client requests are load balanced amongst the available sites, domains, and IP addresses, based on more sophisticated criterion such as: site or server load, proximity of clients to servers, server availability, performance parameters of latency and response times, etc., and preferably preserves client-server persistence for client “stickiness.” That is, ensuring that as much as possible, a particular client gets assigned to the same server that runs the application each time the client connects.
GSLB solutions manage this across geographically distributed sites for fault tolerance and scale and most commonly client migration. In client migration, clients may move across several sites, owing to physical migration, perceived migration (e.g., owing to better connectivity), failover scenarios, or perhaps even a suspend-resume sequence. To provide a seamless application access experience, or perhaps for conformance, it is necessary to affine (preserve the parallel relationship for) the client's access to a specific site, domain, and server—this is client persistency. Given the potential migration of clients, it becomes important to maintain consistent client persistency information across these geographically disparate sites.
An application can be accessed by millions of clients across hundreds or thousands of sites. This scale poses challenges on the volume of information and also the time within which this information is needed to be exchanged between sites. In the prior art, persistence information stored at GSLB sites might include which IP or VIP address that was assigned to each client that had previously connected through the GSLB to the servers that run the application. However, in order to use this information in a timely way, in the prior art, a persistence entry for each client that accessed the GSLB system, identifying the client and its assigned VIP, had to be kept at each GSLB site. That is, the one GSLB site at which a DNS request for a new client was received, and a VIP assigned to the client, had to distribute a persistence entry for that client to every other GSLB site, in case a future DNS request from the client was received at one of the other GSLB sites. In a system with 10 million clients and 1,000 sites, that would mean that approximately 10 billion copies of persistence entries would have to be distributed throughout the system initially for the 10 million clients. Then the GSLB system would have to send a further 1,000 copies of a new persistence entry, to update the persistence tables for every GSLB site, whenever network conditions rendered an existing persistence entry obsolete (e.g., due to server crashes, etc.). Therefore, there is a need in the art for enhanced client persistence information handling methods.
The method of the present invention solves the problems caused by the DNS servers at every GSLB site in a GSLB system having to have persistence tables for any client DNS request they receive. Rather than storing every persistence entry at every GSLB site, some embodiments of the present invention assign each client a home DNS server cluster (e.g., a cluster of DNS servers at a particular data center in the GSLB system). Any DNS server cluster, referred to as “DNS clusters” herein, which receives a DNS request from a particular client, is able to identify what the home DNS cluster for that client is. The first DNS cluster then forwards the DNS request to the home DNS cluster.
When the forwarded DNS request reaches the home DNS cluster, the home DNS cluster checks a local persistence table and if a client identifier (e.g., IP address, MAC address, etc.) is not found in the persistence table, the GSLB system of the home DNS cluster (e.g., load balancers of the datacenter) assigns a VIP address to the client. The assigned VIP address is then sent to the client, and the home DNS cluster stores a persistence entry for the client in the local persistence table. Because any future DNS requests from the same client will also be routed to the home DNS cluster, there is no need for any other DNS cluster to receive a copy of the persistence entry, other than for backing up the local persistence table. In some embodiments, when the client sends data messages to the assigned VIP address, a NAT or load balancer associated with that VIP address ensures that the client gets assigned to the same server each time (e.g., a particular server in a pool of servers associated with that VIP address).
Some embodiments provide a method that, at a first DNS cluster of a set of DNS clusters, receives a DNS request from a client. The first DNS cluster identifies, based on an identifier of the client in the DNS request, a home DNS cluster of the client. The method forwards the DNS request to the home DNS cluster. The home DNS cluster supplies a DNS response to the client.
Identifying the home DNS cluster, in some embodiments, includes performing a hash on the identifier of the client. Supplying the DNS response, in some embodiments, includes receiving a virtual IP (VIP) address associated with one of a plurality of sets of application servers to the client and providing the received VIP address to the client in the DNS response. In some embodiments, receiving the VIP address includes receiving the VIP address from a load balancer that selects the VIP address from a set of VIP addresses, each VIP address associated with a set of application servers.
The supplied VIP address, in some embodiments, is a VIP address of a load balancer or a network address translation (NAT) engine that (1) assigns, to the client, an IP address of an application server in the set of application servers associated with the VIP address, and (2) creates a record that associates the IP address with the client.
The method of some embodiments further includes creating, in a persistence table of the home DNS cluster, an entry associating the VIP address with the client. In some embodiments, a second DNS request is received from the same client at a second DNS cluster (that is also not the home DNS cluster) of the set of DNS clusters. Upon receiving the second DNS request from the client, the second DNS cluster (1) identifies (based on the identifier of the client in the DNS request) the home DNS cluster of the client in the set of DNS clusters, and (2) forwards the second DNS request to the home DNS cluster. The home DNS cluster supplies, to the client, a second DNS response that includes the supplied VIP address. Supplying the second DNS response, in some embodiments, includes finding, based on the client identifier, the entry in the persistence table of the home DNS cluster. Finding the entry in the persistence table may include applying a counting bloom filter and bloom collision hash to the identifier.
The home DNS cluster, in some embodiments, is a home DNS cluster to multiple clients. The persistence table includes a persistence table entry for each of those clients. The method, in some embodiments, further includes (1) assigning a set of backup home DNS clusters to the home DNS cluster, and (2) backing up the persistence table of the home DNS cluster with each DNS cluster in the set of backup home DNS clusters. Each DNS cluster in the set of DNS clusters, in some embodiments, is a home DNS cluster to a plurality of clients, and each DNS cluster maintains a persistence table for that DNS cluster's clients and clients of a set of DNS clusters that that DNS cluster is assigned as a backup home DNS cluster for.
The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, the Detailed Description, the Drawings, and the Claims is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, the Detailed Description, and the Drawings.
The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following figures.
In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.
The method of the present invention solves the problems caused by the DNS servers at every GSLB site in a GSLB system having to have persistence tables for any client DNS request they receive. Rather than storing every persistence entry at every GSLB site, some embodiments of the present invention assign each client a home DNS cluster (e.g., a cluster at a particular data center in the GSLB system). Any DNS cluster that receives a DNS request from a particular client is able to identify what the home DNS cluster for that client is. The first DNS cluster then forwards the DNS request to the home DNS cluster.
When the forwarded DNS request reaches the home DNS cluster, the home DNS cluster checks a local persistence table and if a client identifier (e.g., IP address, MAC address, etc.) is not found in the persistence table, the GSLB system of the home DNS cluster (e.g., load balancers of the datacenter) assigns a VIP address to the client. The assigned VIP address is then sent to the client and the home DNS cluster stores a persistence entry for the client in the local persistence table. Because any future DNS requests from the same client will also be routed to the home DNS cluster, there is no need for any other DNS cluster to receive a copy of the persistence entry, other than for backing up the local persistence table. In some embodiments, when the client sends data messages to the assigned VIP address, a NAT or load balancer associated with that VIP address ensures that the client gets assigned to the same server each time (e.g., a particular server in a pool of servers associated with that VIP address).
Some embodiments provide a method that, at a first DNS cluster of a set of DNS clusters, receives a DNS request from a client. The first DNS cluster identifies, based on an identifier of the client in the DNS request, a home DNS cluster of the client. The method forwards the DNS request to the home DNS cluster. The home DNS cluster supplies a DNS response to the client.
Identifying the home DNS cluster, in some embodiments, includes performing a hash on the identifier of the client. Supplying the DNS response, in some embodiments, includes receiving a VIP address associated with one of a plurality of sets of application servers to the client and providing the received VIP address to the client in the DNS response. In some embodiments, receiving the VIP address includes receiving the VIP address from a load balancer that selects the VIP address from a set of VIP addresses, each VIP address associated with a set of application servers.
The supplied VIP address, in some embodiments, is a VIP address of a load balancer or a NAT engine that (1) assigns, to the client, an IP address of an application server in the set of application servers associated with the VIP address, and (2) creates a record that associates the IP address with the client.
The method of some embodiments further includes creating, in a persistence table of the home DNS cluster, an entry associating the VIP address with the client. In some embodiments, a second DNS request is received from the same client at a second DNS cluster (that is also not the home DNS cluster) of the set of DNS clusters. Upon receiving the second DNS request from the client, the second DNS cluster (1) identifies, based on the identifier of the client in the DNS request, the home DNS cluster of the client in the set of DNS clusters and (2) forwards the second DNS request to the home DNS cluster. The home DNS cluster supplies, to the client, a second DNS response that includes the supplied VIP address. Supplying the second DNS response, in some embodiments, includes finding, based on the client identifier, the entry in the persistence table of the home DNS cluster. Finding the entry in the persistence table may include applying a counting bloom filter and bloom collision hash to the identifier.
The home DNS cluster, in some embodiments, is a home DNS cluster to multiple clients. The persistence table includes a persistence table entry for each of those clients. The method, in some embodiments, further includes (1) assigning a set of backup home DNS clusters to the home DNS cluster, and (2) backing up the persistence table of the home DNS cluster with each DNS cluster in the set of backup home DNS clusters. Each DNS cluster in the set of DNS clusters, in some embodiments, is a home DNS cluster to a plurality of clients, and each DNS cluster maintains a persistence table for that DNS cluster's clients and clients of a set of DNS clusters that that DNS cluster is assigned as a backup home DNS cluster for.
A cluster of one or more controllers 110 are deployed in each datacenter 102-108. Each datacenter 102-108 also has a cluster 115 of load balancers 117 to distribute the client load across the backend application servers 105 in the datacenter. In this example, the datacenters 102-106 also have a cluster 120 of DNS service engines 125 to perform DNS operations to process, e.g., to provide network addresses for domain names provided in the DNS requests submitted by clients 130 inside or outside of the datacenters 102-106. In some embodiments, the DNS requests include requests for fully qualified domain name (FQDN) address resolutions. Although datacenters 102-106 all include DNS service engines 125, in some embodiments, datacenters such as 108 may include backend servers 105, load balancers 117, or other elements for assigning a client to a particular backend server 105 but not include DNS service engines 125. Although several embodiments are described herein as including backend servers 105, in some embodiments, the applications run partially or entirely on other kinds of servers. One of ordinary skill in the art will understand that the inventions herein apply regardless of what kind of server(s) run the application. In general, servers that run at least some part of the application may be referred to as “application servers”.
Second, the private DNS resolver 165 selects one of the DNS clusters 120. This selection is random in some embodiments, while in other embodiments it is based on a set of load balancing criteria that distributes the DNS request load across the DNS clusters 120. In still other embodiments, the private DNS resolver 165 selects a home DNS for the client 130 (e.g., using a hash of an identifier of the client). In the example illustrated in
Third, the selected DNS cluster 120b resolves the domain name to an IP address. In some embodiments, each DNS cluster 120 includes multiple DNS service engines 125, such as DNS service virtual machines (SVMs) that execute on host computers in the cluster's datacenter. When a DNS cluster 120 receives a DNS request, a frontend load balancer (not shown) in some embodiments selects a DNS service engine 125 in the cluster 120 to respond to the DNS request, and forwards the DNS request to the selected DNS service engine 125. Other embodiments do not use a frontend load balancer, and instead have a DNS service engine serve as a frontend load balancer that selects itself or another DNS service engine in the same cluster for processing the DNS request.
Fourth, the DNS service engine 125b that processes the DNS request then determines (See, e.g., in
In the example illustrated in
After getting the VIP address, the client 130 sends one or more data message flows to the assigned VIP address for the backend server cluster 105d to process. In this example, the data message flows are received by the local load balancer cluster 115d and forwarded to one of the backend servers 105d. In some embodiments, each load balancer cluster 115 has multiple load balancing service engines 117 (e.g., load balancing SVMs) that execute on host computers in the cluster's datacenter.
When the load balancer cluster 115 receives the first data message of the flow, a frontend load balancer (not shown) in some embodiments selects a load balancing service engine 117 in the cluster 115 to select a backend server 105 to receive the data message flow and forwards the data message to the selected load balancing service engine 117. Other embodiments do not use a frontend load balancer, and instead have a load balancing service engine in the cluster serve as a frontend load balancer that selects itself or another load balancing service engine in the same cluster for processing the received data message flow.
When a selected load balancing service engine 117 processes the first data message of the flow, in some embodiments, this load balancing service engine 117 uses a set of load balancing criteria (e.g., a set of weight values) to select one backend server from the cluster of backend servers 105 in the same datacenter 106. The load balancing service engine 117 then replaces the VIP address with an actual destination IP (DIP) address of the selected backend server (e.g., among servers 105) and forwards the data message and subsequent data messages of the same flow to the selected backend server. The selected backend server then processes the data message flow, and when necessary, sends a responsive data message flow to the client 130. In some embodiments, the responsive data message flow is sent through the load balancing service engine 117 that selected the backend server for the initial data message flow from the client 130.
In some embodiments, a load balancer cluster 115 maintains records of which server each client has previously been assigned to and when later data messages from the same client are received, the load balancer cluster 115 forwards the messages to the same server. In other embodiments, data messages sent to the VIP address are received by a NAT engine that translates the VIP address into an internal address of a specific backend server. In some such embodiments, the NAT engine maintains records of which server each client is assigned to and sends further messages from that client to the same server. In some embodiments, the NAT engine may be implemented as part of the load balancer cluster 115.
The controllers 110 facilitate the operations of the DNS system that the GSLB system 100 performs in some embodiments. The controllers 110 may receive system messages to alter the algorithms (e.g., hash formulas) used in some embodiments to determine the home DNS for each client, facilitate selection of backup home DNS clusters, etc. Similarly, in some embodiments, the controllers 110 generate and update hash wheels that associate specific DNS clusters 120 with specific clients. Such hash wheels are described with respect to
The process 200, of
In some embodiments, the process 200 identifies the home DNS cluster by performing a consistent hash. In a consistent hash of DNS clusters and clients, a hash is applied to an identifier of each DNS cluster (e.g., an IP address of the DNS cluster, etc.). The hash maps each DNS cluster to a particular value that may be conceptualized as an “angle” around a (conceptual) circle, the value is sometimes referred to as a “slot.” The resulting set of DNS clusters and their associated values is referred to herein as a “hash wheel.” One of ordinary skill in the art will understand that the angles in some embodiments do not need to be a range used in any standard system for defining angles on a circle, but that any hash that maps identifiers to any defined range of values may be used in some embodiments.
In some embodiments, each DNS cluster is supplied with a list or database identifying the DNS clusters in the GSLB system and a value (e.g., an IP address) to apply a specified hash function to. In other embodiments, the hash wheel is calculated at one location (e.g., a network controller, etc.) then the resulting hash wheel is distributed to each DNS cluster. To assign a client to a home DNS cluster, in some embodiments, the DNS cluster performs a hash on the client ID to map the client ID to a value (e.g., an angle on the hash wheel). The hashed values of the client IDs are sometimes called “keys.” In some embodiments, the hash performed on the client ID is the same hash used on the DNS cluster IDs. In other embodiments, the hash performed on the client ID is a different hash used on the DNS cluster IDs that maps to the same range of angles. After the client ID is mapped to a hash wheel value, the client is then assigned to the DNS cluster that occupies the next slot around the hash wheel in a particular direction (e.g., clockwise or counter-clockwise). In some embodiments, each DNS cluster is associated with multiple slots (e.g., 2, 3, 4, etc.).
As mentioned,
In some embodiments, the controllers 110, of
The three hashed client IDs 315-325 represent the hashed values of the client IDs of three different clients. Each has been hashed to a value on the hash wheel 300. Hashed client ID 315, representing client C1 has been mapped to a value closest to DNS cluster slot 304A, however, in this embodiment, each client is assigned to the DNS cluster that has the next slot in a clockwise direction.
For hashed client ID 315, associated with client C1, the next slot in the clockwise direction is DNS cluster slot 302A, therefore client C1 will be assigned to DNS cluster DNSC1. For hashed client ID 320, associated with client C2, the next slot in the clockwise direction is DNS cluster slot 302B. Slot 302B is the second slot associated with DNS cluster DNSC1, therefore client C2 will also be assigned to DNS cluster DNSC1. Similarly, client C3, associated with hashed client ID 325 has DNS cluster slot 306A as the next slot clockwise of the hashed client ID. Although the embodiment illustrated in
After identifying the home DNS cluster, the receiving DNS cluster, in some embodiments then performs the next operation of process 200 by forwarding (at 215) the DNS request to the identified home DNS cluster. In some embodiments, the hash is performed by an individual DNS service engine of the receiving DNS cluster. In other embodiments, the receiving DNS cluster includes a separate module or set of software instructions that performs all hashing operations for the DNS cluster. The process 200 then ends.
As mentioned above, some DNS clusters use persistence tables to determine whether a client has previously been assigned a VIP.
The process 400, of
After verifying that the DNS cluster is the home DNS cluster of the client that sent the DNS request, the process 400, of
In some embodiments, the persistence table storage 510, or some other storage (not shown) of the DNS cluster 120 also stores data for implementing a counting bloom filter and bloom collision hash to quickly determine whether the client ID is a new client ID. One of ordinary skill in the art will understand that a counting bloom filter and bloom collision hash can be used to quickly identify whether a client ID is possibly in the persistence table 515. For a counting bloom filter, false positives are possible. That is, client IDs can be identified by the counting bloom filter as possibly being in the persistence table when those client IDs are not actually in the persistence table. For a counting bloom filter, false negatives are not possible. That is, client IDs identified by a counting bloom filter as not in the persistence table are definitely not in the persistence table. The counting bloom filter and bloom collision hash are updated as each new client ID (and its assigned VIP) is added to the persistence table 515. In such embodiments, the client tracker 505 uses the counting bloom filter and bloom collision hash to determine whether a client ID is new (e.g., a DNS request from the client is not memorialized in the table) or may have a persistence table entry 520.
If the client ID is determined by the client tracker 505 to possibly have a persistence table entry (using the bloom filter) or if the embodiment doesn't use a bloom filter, then the client tracker 505 searches the persistence table 515 for an entry with that client ID. If an entry is not found (or in some embodiments, if the counting bloom filter indicates there is no entry for a client), the client tracker 505 notifies the DNS service engine 125. The process 400 then continues when the DNS cluster 120 gets (at 420) a VIP from the load balancer. In some embodiments, any VIP for a backend server in the GSLB system may be assigned to a client by the load balancer, including VIPs associated with different data centers than the home DNS cluster of the client or even VIPs associated with data centers that do not have DNS clusters. The process 400 then stores (at 425) the client-VIP pair in the persistence table storage (e.g., persistence table storage 510, of
As mentioned above, in the prior art, GSLB systems with persistence tables required every DNS cluster to store an entry for every client in the system. This meant that each DNS cluster in a prior art system with 10 million clients would have to store 10 million entries in its persistence table. With 1,000 DNS clusters, this would mean passing about 10 billion copies of entries between DNS clusters. In the present invention, with 10 million clients and 1,000 DNS clusters, the average number of clients per DNS cluster would be 10,000. Thus each DNS cluster would have 10,000 persistence table entries, on average, allowing faster lookup of the client IDs than searching a table with 10 million entries. However, if the home DNS cluster of a client in some embodiments became inaccessible, due to network issues, crashes of computers at a datacenter, etc., a DNS request from a client would not reach the home DNS cluster of the client.
To handle issues of unavailable DNS clusters, the DNS clusters of some embodiments each have one or more backup DNS clusters in the GSLB system. The persistence table of each DNS cluster is copied to the backup home DNS cluster or DNS clusters in such embodiments. Even in embodiments with several backup DNS clusters for each DNS cluster, the number of entries that need to be copied for the backups will be less than the number of entries copied in the prior art. For example, in the previously mentioned example with 10 million clients and 1,000 DNS clusters, backing up each DNS cluster on three separate backup home DNS clusters would only require copying 30 million entries (e.g., 10,000 entries for each of 1,000 DNS clusters copied to 3 backups) rather than the previously cited 10 billion. However, to increase the advantages of home DNS clusters over a system in which every DNS cluster maintains a persistence table entry for every previous client that received a VIP from the GSLB system, some embodiments use a small number of backups compared to the total number of DNS clusters. For example, some embodiments use fewer backups for each home DNS cluster than 1/10th the total number of DNS clusters. Other embodiments use fewer backups for each home DNS cluster than ½, or ⅓, or ¼, etc., the total number of DNS clusters.
If the home DNS cluster is not available (at 615) then the process 600 determines whether a backup home DNS cluster for the client is available. In some embodiments, the backup home DNS clusters for a particular home DNS cluster are determined by performing another hash operation on the client ID or an ID of the home DNS. In other embodiments, the backup home DNS clusters for each home DNS cluster in the system may be stored in a list or database table associating each DNS cluster in the system with its backup DNS clusters, etc. If a backup home DNS cluster for the client is available, the process 600 forwards (at 625) the DNS request to the backup home DNS cluster and the process 600 ends. If the process 600 determines (at 620) that there is no backup home DNS cluster, then the process 600 ends there. In some embodiments, if the process 600 is unable to identify an available backup home DNS cluster, then the DNS request is simply sent to the load balancers of the GSLB site of the receiving (non-home) DNS cluster and a VIP is provided. In some embodiments, this failsafe provision is performed without keeping track of the client-VIP pairing in a persistence table. In other embodiments, there is a system for tracking the client-VIP pairing and forwarding a persistence entry for that pairing to the home DNS cluster when it becomes accessible again.
In some embodiments, both the addition and removal of a GSLB site are infrequent and involved operations. Some embodiments implement a “pre-provisioning phase” before the addition or removal of GSLB sites. Any addition or removal of GSLB sites (and their DNS clusters) modifies the consistent hash ring. This affects the client-to-home DNS cluster mapping of the hash. The “pre-provisioning phase” iterates through all the entries in the persistence tables at all the GSLB sites and repatriates them to the new “home DNS clusters” in accordance with the updated consistent hash ring. Once the “pre-provisioning phase” is complete, a coordinated toggle from the topology that uses the previous set of GSLB sites to the topology that uses the updated set of GSLB sites is orchestrated, which ensures minimal disruption.
The process 700 identifies (at 710) a home DNS cluster for each client associated with an entry in a persistence table in any DNS cluster currently in the GSLB system. The process 700 of some embodiments identifies the home DNS cluster for each client associated with a persistence table entry by applying the hash algorithm (e.g., the hash algorithm previously used to allocate clients to the current set of DNS clusters) to the client identifier in the entry and distributing the clients based on the new hash wheel (generated in operation 705). The process 700, for each client that has a new home DNS cluster, moves (at 715) the persistence table entries associated with the client to the new home DNS cluster. This prepares the new home DNS cluster for the updated GSLB setup. That is, after the updated set of DNS clusters replaces (in whole or in part) the original set of DNS clusters, a new DNS request from a client will be routed to the client's new home DNS cluster based on the new hash wheel. When the new DNS request arrives at the new home DNS cluster, a copy of the old persistence table entry for the client will be in the persistence table of the new home DNS cluster enabling the new home DNS cluster to provide the client with a DNS reply that assigns the same VIP to the client as the client had previously been assigned by the old home DNS cluster.
In some embodiments, moving the persistence table entries includes copying the persistence table entries that change home DNS clusters (as identified in operation 710) from the original home DNS clusters of the client associated with that entry to the new home DNS cluster of the client associated with that entry. Once all of the persistence table entries that need to be moved are copied to their new home DNS clusters, the process 700 switches (at 720) from the original DNS clusters to the updated DNS clusters (e.g., removes from the GSLB system any DNS clusters that are not part of the updated set of DNS clusters). The process 700 then ends.
As mentioned above, the persistence table entry for a client is moved only when the client will be assigned to a new home DNS cluster in the updated set of DNS clusters. The client will be assigned a new home DNS cluster when the old DNS cluster is being removed in the update or when a newly added DNS cluster is mapped, by the hash, to a value between the hashed value of the client ID and the client's old home DNS cluster.
In the updated set of DNS clusters, DNS cluster DNSC4 has been removed (e.g., for maintenance, re-assignment to be used with other applications, etc.). Accordingly, updated hash wheel 820 does not include DNS cluster slot 802, associated with DNS cluster DNSC4. Based on the updated hash wheel 820, client C1 is now assigned DNS cluster DNSC1, associated with DNS cluster slot 804, because DNS cluster slot 804 is the next DNS cluster slot in the clockwise direction from the value of hashed client ID 810. However, client C2 is still assigned to cluster DNSC3, associated with DNS cluster slot 808, because DNS cluster slot 808 is still the next DNS cluster slot in the clockwise direction from the value of hashed client ID 812 in the updated hash wheel 820.
In this example, before DNS cluster DNSC4 would be removed from the GSLB, all of the persistence table entries of any clients with DNS cluster DNSC4 as their home would be moved to the client's new home DNS cluster, DNS cluster DNSC1. However, the persistence table entry for clients of DNS cluster DNSC3 would not be moved from DNSC3 because DNSC3 remains the home of those clients. Although all of the persistence entries of DNS cluster DNSC4 would be moved to DNS cluster DNSC1, in the embodiment of
In the updated set of DNS clusters, DNS cluster DNSC5 has been added. Accordingly, updated hash wheel 900 includes DNS cluster slot 902, associated with DNS cluster DNSC5. Based on the updated hash wheel 900, client C1 is now assigned DNS cluster DNSC5, associated with DNS cluster slot 902, because DNS cluster slot 902 is the next DNS cluster slot in the clockwise direction from the value of hashed client ID 810. However, client C3 is still assigned to cluster DNSC4, associated with DNS cluster slot 802, because DNS cluster slot 802 is still the next DNS cluster slot in the clockwise direction from the value of hashed client ID 910 in the updated hash wheel 900.
In this example, the persistence table entries of any clients (1) assigned to DNS cluster DNSC4 as their home in the original set of DNS clusters and (2) assigned to DNS cluster DNSC5 as their home in the updated set of DNS clusters would be moved. The reason for the move would be because, DNS cluster slot 902 is mapped between the hashed client ID values of those clients and the DNS cluster slot 802 in the updated hash wheel 900. The other clients assigned to DNS cluster DNSC4 would not be changing home DNS clusters and thus their persistence table entries would not be moved. One of ordinary skill in the art will understand that in embodiments that assign multiple slots to each DNS cluster, a single newly added DNS cluster might become the new home DNS cluster to persistence table entries from multiple other DNS clusters.
Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer-readable storage medium (also referred to as computer-readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer-readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
The bus 1005 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the computer system 1000. For instance, the bus 1005 communicatively connects the processing unit(s) 1010 with the read-only memory 1030, the system memory 1025, and the permanent storage device 1035.
From these various memory units, the processing unit(s) 1010 retrieve instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments. The read-only-memory (ROM) 1030 stores static data and instructions that are needed by the processing unit(s) 1010 and other modules of the computer system. The permanent storage device 1035, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the computer system 1000 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1035.
Other embodiments use a removable storage device (such as a floppy disk, flash drive, etc.) as the permanent storage device 1035. Like the permanent storage device 1035, the system memory 1025 is a read-and-write memory device. However, unlike storage device 1035, the system memory 1025 is a volatile read-and-write memory, such as random access memory. The system memory 1025 stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory 1025, the permanent storage device 1035, and/or the read-only memory 1030. From these various memory units, the processing unit(s) 1010 retrieve instructions to execute and data to process in order to execute the processes of some embodiments.
The bus 1005 also connects to the input and output devices 1040 and 1045. The input devices 1040 enable the user to communicate information and select commands to the computer system 1000. The input devices 1040 include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices 1045 display images generated by the computer system 1000. The output devices 1045 include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as touchscreens that function as both input and output devices 1040 and 1045.
Finally, as shown in
Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
While the above discussion primarily refers to microprocessors or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself.
As used in this specification, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms “display” or “displaying” mean displaying on an electronic device. As used in this specification, the terms “computer-readable medium,” “computer-readable media,” and “machine-readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals.
While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, several of the above-described embodiments deploy gateways in public cloud datacenters. However, in other embodiments, the gateways are deployed in a third-party's private cloud datacenters (e.g., datacenters that the third-party uses to deploy cloud gateways for different entities in order to deploy virtual networks for these entities). Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202141026460 | Jun 2021 | IN | national |
| 202141026462 | Jun 2021 | IN | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| RE4814 | Madurell | Mar 1872 | E |
| 5109486 | Seymour | Apr 1992 | A |
| 5781703 | Desai et al. | Jul 1998 | A |
| 6148335 | Haggard et al. | Nov 2000 | A |
| 6449739 | Landan | Sep 2002 | B1 |
| 6515968 | Combar et al. | Feb 2003 | B1 |
| 6714979 | Brandt et al. | Mar 2004 | B1 |
| 6754706 | Swildens | Jun 2004 | B1 |
| 6792458 | Muret et al. | Sep 2004 | B1 |
| 6792460 | Oulu et al. | Sep 2004 | B2 |
| 6901051 | Hou et al. | May 2005 | B1 |
| 6976090 | Ben-Shaul et al. | Dec 2005 | B2 |
| 6996778 | Rajarajan et al. | Feb 2006 | B2 |
| 7076695 | McGee et al. | Jul 2006 | B2 |
| 7130812 | Iyer et al. | Oct 2006 | B1 |
| 7246159 | Aggarwal et al. | Jul 2007 | B2 |
| 7353272 | Robertson et al. | Apr 2008 | B2 |
| 7430610 | Pace et al. | Sep 2008 | B2 |
| 7636708 | Garcea et al. | Dec 2009 | B2 |
| 7701852 | Hohn et al. | Apr 2010 | B1 |
| 7743380 | Seidman et al. | Jun 2010 | B2 |
| 7933988 | Nasuto et al. | Apr 2011 | B2 |
| 7990847 | Leroy et al. | Aug 2011 | B1 |
| 8032896 | Li et al. | Oct 2011 | B1 |
| 8112471 | Wei et al. | Feb 2012 | B2 |
| 8131712 | Thambidorai et al. | Mar 2012 | B1 |
| 8412493 | Duchenay et al. | Apr 2013 | B2 |
| 8499066 | Zhang et al. | Jul 2013 | B1 |
| 8588069 | Todd et al. | Nov 2013 | B2 |
| 8856797 | Siddiqui et al. | Oct 2014 | B1 |
| 8874725 | Ganjam et al. | Oct 2014 | B1 |
| 8977728 | Martini | Mar 2015 | B1 |
| 9032078 | Beerse et al. | May 2015 | B2 |
| 9047648 | Lekutai et al. | Jun 2015 | B1 |
| 9071537 | Talla et al. | Jun 2015 | B2 |
| 9083710 | Yadav | Jul 2015 | B1 |
| 9210056 | Choudhary et al. | Dec 2015 | B1 |
| 9256452 | Suryanarayanan et al. | Feb 2016 | B1 |
| 9288193 | Gryb et al. | Mar 2016 | B1 |
| 9300552 | Dube et al. | Mar 2016 | B2 |
| 9300553 | Dube et al. | Mar 2016 | B2 |
| 9319343 | Khandelwal et al. | Apr 2016 | B2 |
| 9329915 | Chandrasekharapuram et al. | May 2016 | B1 |
| 9450700 | Tonder et al. | Sep 2016 | B1 |
| 9459980 | Arguelles | Oct 2016 | B1 |
| 9467476 | Shieh et al. | Oct 2016 | B1 |
| 9477784 | Bhave et al. | Oct 2016 | B1 |
| 9483286 | Basavaiah et al. | Nov 2016 | B2 |
| 9491164 | Fay | Nov 2016 | B1 |
| 9495222 | Jackson | Nov 2016 | B1 |
| 9531614 | Nataraj et al. | Dec 2016 | B1 |
| 9535805 | Ananthanarayanan et al. | Jan 2017 | B2 |
| 9558465 | Arguelles et al. | Jan 2017 | B1 |
| 9571516 | Curcic et al. | Feb 2017 | B1 |
| 9608880 | Goodall | Mar 2017 | B1 |
| 9613120 | Kharatishvili et al. | Apr 2017 | B1 |
| 9626275 | Hitchcock et al. | Apr 2017 | B1 |
| 9674302 | Khalid et al. | Jun 2017 | B1 |
| 9680699 | Cohen et al. | Jun 2017 | B2 |
| 9692811 | Tajuddin et al. | Jun 2017 | B1 |
| 9697316 | Taylor et al. | Jul 2017 | B1 |
| 9712410 | Char et al. | Jul 2017 | B1 |
| 9716617 | Ahuja et al. | Jul 2017 | B1 |
| 9729414 | Oliveira et al. | Aug 2017 | B1 |
| 9749888 | Colwell et al. | Aug 2017 | B1 |
| 9798883 | Gil et al. | Oct 2017 | B1 |
| 9817699 | Stich et al. | Nov 2017 | B2 |
| 9830192 | Crouchman et al. | Nov 2017 | B1 |
| 9882830 | Taylor et al. | Jan 2018 | B2 |
| 9935829 | Miller et al. | Apr 2018 | B1 |
| 9959188 | Krishnan | May 2018 | B1 |
| 9967275 | Kolman et al. | May 2018 | B1 |
| 9979617 | Meyer et al. | May 2018 | B1 |
| 10003550 | Babcock et al. | Jun 2018 | B1 |
| 10015094 | Akers et al. | Jul 2018 | B1 |
| 10127097 | Talla et al. | Nov 2018 | B2 |
| 10212041 | Rastogi et al. | Feb 2019 | B1 |
| 10237135 | Alabsi et al. | Mar 2019 | B1 |
| 10313211 | Rastogi et al. | Jun 2019 | B1 |
| 10372600 | Mathur | Aug 2019 | B2 |
| 10547521 | Roy et al. | Jan 2020 | B1 |
| 10594562 | Rastogi et al. | Mar 2020 | B1 |
| 10630543 | Wei et al. | Apr 2020 | B1 |
| 10693734 | Rastogi et al. | Jun 2020 | B2 |
| 10728121 | Chitalia et al. | Jul 2020 | B1 |
| 10873541 | Callau et al. | Dec 2020 | B2 |
| 10931548 | Iyer et al. | Feb 2021 | B1 |
| 10999168 | Gupta et al. | May 2021 | B1 |
| 11038839 | Vettaikaran et al. | Jun 2021 | B1 |
| 11038840 | Vettaikaran et al. | Jun 2021 | B1 |
| 11044180 | Rastogi et al. | Jun 2021 | B2 |
| 11171849 | Rastogi et al. | Nov 2021 | B2 |
| 11283697 | Rajagopalan et al. | Mar 2022 | B1 |
| 11290358 | Basavaiah et al. | Mar 2022 | B2 |
| 11411825 | Rastogi et al. | Aug 2022 | B2 |
| 11513844 | Aleti et al. | Nov 2022 | B1 |
| 11582120 | Basavaiah et al. | Feb 2023 | B2 |
| 20020078150 | Thompson et al. | Jun 2002 | A1 |
| 20020198984 | Goldstein et al. | Dec 2002 | A1 |
| 20020198985 | Fraenkel et al. | Dec 2002 | A1 |
| 20030191837 | Chen | Oct 2003 | A1 |
| 20030236877 | Allan | Dec 2003 | A1 |
| 20040054680 | Kelley et al. | Mar 2004 | A1 |
| 20040064552 | Chong et al. | Apr 2004 | A1 |
| 20040103186 | Casati et al. | May 2004 | A1 |
| 20040243607 | Tummalapalli | Dec 2004 | A1 |
| 20050010578 | Doshi | Jan 2005 | A1 |
| 20050060574 | Klotz et al. | Mar 2005 | A1 |
| 20050108444 | Flauaus et al. | May 2005 | A1 |
| 20050120160 | Plouffe et al. | Jun 2005 | A1 |
| 20050172018 | Devine et al. | Aug 2005 | A1 |
| 20050188221 | Motsinger et al. | Aug 2005 | A1 |
| 20060167939 | Seidman et al. | Jul 2006 | A1 |
| 20060224725 | Bali et al. | Oct 2006 | A1 |
| 20060242282 | Mullarkey | Oct 2006 | A1 |
| 20060271677 | Mercier | Nov 2006 | A1 |
| 20070136331 | Hasan | Jun 2007 | A1 |
| 20070226554 | Greaves et al. | Sep 2007 | A1 |
| 20080104230 | Nasuto et al. | May 2008 | A1 |
| 20080126534 | Mueller et al. | May 2008 | A1 |
| 20080183876 | Duvur et al. | Jul 2008 | A1 |
| 20090049524 | Farrell et al. | Feb 2009 | A1 |
| 20090154366 | Rossi | Jun 2009 | A1 |
| 20090199196 | Peracha | Aug 2009 | A1 |
| 20100077462 | Joffe et al. | Mar 2010 | A1 |
| 20100208742 | Kafle et al. | Aug 2010 | A1 |
| 20100279622 | Shuman et al. | Nov 2010 | A1 |
| 20100287171 | Schneider | Nov 2010 | A1 |
| 20100293296 | Hsu et al. | Nov 2010 | A1 |
| 20110126111 | Gill et al. | May 2011 | A1 |
| 20110196890 | Pfeifle et al. | Aug 2011 | A1 |
| 20120101800 | Miao et al. | Apr 2012 | A1 |
| 20120110185 | Ganesan et al. | May 2012 | A1 |
| 20120131591 | Moorthi et al. | May 2012 | A1 |
| 20120254443 | Ueda | Oct 2012 | A1 |
| 20120254444 | Harchol-Balter et al. | Oct 2012 | A1 |
| 20120291099 | Grube et al. | Nov 2012 | A1 |
| 20130013953 | Eck et al. | Jan 2013 | A1 |
| 20130086230 | Guerra et al. | Apr 2013 | A1 |
| 20130086273 | Wray et al. | Apr 2013 | A1 |
| 20130179289 | Calder et al. | Jul 2013 | A1 |
| 20130179881 | Calder et al. | Jul 2013 | A1 |
| 20130179894 | Calder et al. | Jul 2013 | A1 |
| 20130179895 | Calder et al. | Jul 2013 | A1 |
| 20130211559 | Lawson et al. | Aug 2013 | A1 |
| 20130212257 | Murase et al. | Aug 2013 | A1 |
| 20130290538 | Gmach et al. | Oct 2013 | A1 |
| 20130326044 | Maldaner | Dec 2013 | A1 |
| 20130343213 | Reynolds et al. | Dec 2013 | A1 |
| 20130346594 | Banerjee et al. | Dec 2013 | A1 |
| 20140006862 | Jain et al. | Jan 2014 | A1 |
| 20140032785 | Chaudhuri | Jan 2014 | A1 |
| 20140059179 | Lam | Feb 2014 | A1 |
| 20140101226 | Khandekar et al. | Apr 2014 | A1 |
| 20140122725 | Batrouni et al. | May 2014 | A1 |
| 20140143406 | Malhotra et al. | May 2014 | A1 |
| 20140173675 | Ahmed et al. | Jun 2014 | A1 |
| 20140215058 | Vicat-Blanc et al. | Jul 2014 | A1 |
| 20140215621 | Xaypanya et al. | Jul 2014 | A1 |
| 20140229706 | Kuesel et al. | Aug 2014 | A1 |
| 20140280886 | Burns | Sep 2014 | A1 |
| 20140282160 | Zarpas | Sep 2014 | A1 |
| 20140304414 | Yengalasetti et al. | Oct 2014 | A1 |
| 20140344439 | Kempf et al. | Nov 2014 | A1 |
| 20140351226 | Christodorescu et al. | Nov 2014 | A1 |
| 20150058265 | Padala et al. | Feb 2015 | A1 |
| 20150074679 | Fenoglio et al. | Mar 2015 | A1 |
| 20150081880 | Eaton et al. | Mar 2015 | A1 |
| 20150106523 | Cui et al. | Apr 2015 | A1 |
| 20150124640 | Chu et al. | May 2015 | A1 |
| 20150134831 | Hiroishi | May 2015 | A1 |
| 20150199219 | Kim et al. | Jul 2015 | A1 |
| 20150212829 | Kupershtok et al. | Jul 2015 | A1 |
| 20150244626 | Childress et al. | Aug 2015 | A1 |
| 20150278061 | Siciliano et al. | Oct 2015 | A1 |
| 20150288682 | Bisroev et al. | Oct 2015 | A1 |
| 20150293954 | Hsiao et al. | Oct 2015 | A1 |
| 20150295780 | Isiao et al. | Oct 2015 | A1 |
| 20150295796 | Isiao et al. | Oct 2015 | A1 |
| 20150358391 | Moon et al. | Dec 2015 | A1 |
| 20150370852 | Shastry et al. | Dec 2015 | A1 |
| 20150381558 | Tuliani | Dec 2015 | A1 |
| 20160064277 | Park et al. | Mar 2016 | A1 |
| 20160065609 | Yan | Mar 2016 | A1 |
| 20160087879 | Matsubara et al. | Mar 2016 | A1 |
| 20160094401 | Anwar et al. | Mar 2016 | A1 |
| 20160094410 | Anwar et al. | Mar 2016 | A1 |
| 20160094431 | Hall et al. | Mar 2016 | A1 |
| 20160094483 | Johnston et al. | Mar 2016 | A1 |
| 20160103717 | Dettori et al. | Apr 2016 | A1 |
| 20160105335 | Choudhary et al. | Apr 2016 | A1 |
| 20160127204 | Ozaki et al. | May 2016 | A1 |
| 20160149832 | Liang et al. | May 2016 | A1 |
| 20160164738 | Pinski et al. | Jun 2016 | A1 |
| 20160182399 | Zadka et al. | Jun 2016 | A1 |
| 20160217022 | Velipasaoglu et al. | Jul 2016 | A1 |
| 20160294701 | Batrouni et al. | Oct 2016 | A1 |
| 20160294722 | Bhatia et al. | Oct 2016 | A1 |
| 20160323197 | Guzman et al. | Nov 2016 | A1 |
| 20160323377 | Einkauf et al. | Nov 2016 | A1 |
| 20160359719 | Travostino | Dec 2016 | A1 |
| 20160378635 | Taylor et al. | Dec 2016 | A1 |
| 20170041386 | Bhat et al. | Feb 2017 | A1 |
| 20170063933 | Shieh et al. | Mar 2017 | A1 |
| 20170093986 | Kim et al. | Mar 2017 | A1 |
| 20170126792 | Halpern et al. | May 2017 | A1 |
| 20170134481 | DeCusatis et al. | May 2017 | A1 |
| 20170195090 | Boidol et al. | Jul 2017 | A1 |
| 20170324555 | Wu et al. | Nov 2017 | A1 |
| 20170331907 | Jagannath et al. | Nov 2017 | A1 |
| 20170344618 | Horowitz et al. | Nov 2017 | A1 |
| 20180004582 | Hallenstål | Jan 2018 | A1 |
| 20180007126 | Borst et al. | Jan 2018 | A1 |
| 20180018244 | Yoshimura et al. | Jan 2018 | A1 |
| 20180041408 | Dagum et al. | Feb 2018 | A1 |
| 20180041470 | Schultz et al. | Feb 2018 | A1 |
| 20180046482 | Karve et al. | Feb 2018 | A1 |
| 20180063193 | Chandrashekhar et al. | Mar 2018 | A1 |
| 20180088935 | Church et al. | Mar 2018 | A1 |
| 20180089328 | Bath et al. | Mar 2018 | A1 |
| 20180136931 | Hendrich et al. | May 2018 | A1 |
| 20180239651 | Gong et al. | Aug 2018 | A1 |
| 20180287902 | Chitalia et al. | Oct 2018 | A1 |
| 20180302375 | Els | Oct 2018 | A1 |
| 20180309637 | Gill et al. | Oct 2018 | A1 |
| 20180335946 | Wu et al. | Nov 2018 | A1 |
| 20180367596 | Bache et al. | Dec 2018 | A1 |
| 20190121672 | Ding et al. | Apr 2019 | A1 |
| 20190123970 | Rastogi et al. | Apr 2019 | A1 |
| 20190199790 | Yang et al. | Jun 2019 | A1 |
| 20190238505 | Richards | Aug 2019 | A1 |
| 20190297014 | Azgin et al. | Sep 2019 | A1 |
| 20200014594 | Lapiotis et al. | Jan 2020 | A1 |
| 20200136939 | Rastogi et al. | Apr 2020 | A1 |
| 20200136942 | Rastogi et al. | Apr 2020 | A1 |
| 20200142788 | Hu et al. | May 2020 | A1 |
| 20200169479 | Ireland | May 2020 | A1 |
| 20200218571 | Chen | Jul 2020 | A1 |
| 20200287794 | Rastogi et al. | Sep 2020 | A1 |
| 20200382390 | Basavaiah et al. | Dec 2020 | A1 |
| 20200382584 | Basavaiah et al. | Dec 2020 | A1 |
| 20210058453 | Balasubramanian et al. | Feb 2021 | A1 |
| 20210119923 | Brown et al. | Apr 2021 | A1 |
| 20210349749 | Guha | Nov 2021 | A1 |
| 20210373971 | Lu et al. | Dec 2021 | A1 |
| 20220141102 | Rastogi et al. | May 2022 | A1 |
| 20220147390 | Akinapelli et al. | May 2022 | A1 |
| 20220237203 | Das et al. | Jul 2022 | A1 |
| 20220286373 | Rajagopalan et al. | Sep 2022 | A1 |
| 20220353201 | Navali et al. | Nov 2022 | A1 |
| 20220368758 | Suri et al. | Nov 2022 | A1 |
| 20220400098 | Rao et al. | Dec 2022 | A1 |
| 20230018908 | Yue et al. | Jan 2023 | A1 |
| 20230024475 | Mandeyam et al. | Jan 2023 | A1 |
| 20230025679 | Mandeyam et al. | Jan 2023 | A1 |
| Number | Date | Country |
|---|---|---|
| 2011352884 | Jul 2013 | AU |
| 2020086956 | Apr 2020 | WO |
| Entry |
|---|
| Author Unknown, “Autoscaler,” Compute Engine—Google Cloud Platform, Jun. 29, 2015, 6 pages, retrieved at http://web.archive.org/web/20150629041026/https://cloud.google.com/compute/docs/autoscaler/. |
| Author Unknown, “Autoscaling,” Aug. 20, 2015, 4 pages, Amazon Web Services, retrieved from http://web.archive.org/web/20150820193921/https://aws.amazon.com/autoscaling/. |
| Author Unknown, “BPF, eBPF, XDP and Bpfilter . . . What are These Things and What do They Mean for the Enterprise?,” Apr. 16, 2018, 11 pages, Netronome, retrieved from https://www.netronome.com/blog/bpf-ebpf-xdp-and-bpfilter-what-are-these-things-and-what-do-they-mean-enterprise/. |
| Catania, V., et al., “PMT: A Tool to Monitor Performances in Distributed Systems,” Proceedings of the 3rd IEEE International Symposium on High Performance Distributed Computing, Aug. 2-5, 1994, 8 pages, San Francisco, CA, USA. |
| Davis, David, “Post #8—Understanding vCenter Operations Badges,” David Davis Blog, Apr. 29, 2014, 5 pages, retrieved from http://blogs.vmware.com/management/2014/04/david-davis-on-vcenter-operations-post-8-understanding-vcenter-operations-badges.html. |
| De George, Andy, “How to Scale an Application,” Jun. 16, 2015, 8 pages, Github.com. |
| Liu, Feng, et al., “Monitoring of Grid Performance Based on Agent,” 2007 2nd International Conference on Pervasive Computing and Applications, Jul. 26-27, 2007, 6 pages, IEEE, Birmingham, UK. |
| Non-Published commonly Owned U.S. Appl. No. 16/905,571, filed Jun. 18, 2020, 40 pages, VMware, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 17/381,001, filed Jul. 20, 2021, 30 pages, VMware, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 17/381,010, filed Jul. 20, 2021, 31 pages, VMware, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 17/568,806, filed Jan. 5, 2022, 29 pages, VMware, Inc. |
| Non-Published commonly Owned Related U.S. Appl. No. 17/837,368 with similar specification, filed Jun. 10, 2022, 37 pages, VMware, Inc. |
| Sevcik, Peter, et al., “Apdex Alliance,” May 24, 2014, 5 pages, www.apdex.org. |
| Wallace, Paul, et al., “Feature Brief: Stingray's Autoscaling Capability,” Brocade Community Forums, May 1, 2013, 5 pages, retrieved from http://community.brocade.com/t5/vADC-Docs/Feature-Brief-Stingray-s-Autoscaling-capability/ta-p/73843. |
| Yar, Mohammed, et al., “Prediction Intervals for the Holt-Winters Forecasting Procedure,” International Journal of Forecasting, Month Unknown 1990, 11 pages, vol. 6, Issue 1, Elsevier Science Publishers B.V. |
| Zhang, Xuehai, et al., “A Performance Study of Monitoring and Information Services for Distributed Systems,” Proceedings of the 12th IEEE International Symposium on High Performance Distributed Computing, June 22-24, 2003, 12 pages, IEEE Computer Society, Washington, D.C., USA. |
| Non-Published commonly Owned U.S. Appl. No. 18/102,696, filed Jan. 28, 2023, 40 pages, VMware, Inc. |
| Number | Date | Country | |
|---|---|---|---|
| 20220400097 A1 | Dec 2022 | US |
