Global server load balancing service based on domain name system

Abstract

A system performs efficient domain name system (DNS)-based global server load balancing. The system periodically monitors server health of a server that processes a request directed to a virtual server. Updated server health information is used to process a DNS query that requests an assignment server to process a request directed to a virtual server. The system maintains metadata describing the server based on a user request associated with the virtual server. The system updates information stored in a database based on a request associated with the virtual server, such as creating, updating, or deleting information describing the virtual server. The system disseminates the updated information to a plurality of data plane clusters. The system receives DNS queries and answers them based on the updated information describing the server.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 389,791, filed on July 15, 2022, and U.S. Provisional Application No. 63 / 470,140, ​​filed on May 31, 2023, each of which is incorporated herein by reference in its entirety. Technical Field

[0003] The described subject matter relates generally to load balancing of servers and, more particularly, to a global server load balancing service based on a Domain Name System (DNS). Background Art

[0004] Domain Name System (DNS) load balancing distributes traffic across more than one server to improve performance and availability. Organizations use different forms of load balancing to speed up websites and private networks. Without load balancing, web applications and websites cannot handle traffic efficiently. DNS translates website domain names (such as www.xyz.com) into network addresses, such as IP (Internet Protocol) addresses. DNS servers receive DNS queries for the IP address of the request domain. DNS load balancing configures domains in the Domain Name System (DNS) so that client requests for the domain are distributed across a group of server machines. A domain can correspond to a website, a mail system, a print server, or another service. Poor DNS load balancing causes slow request performance by overloading some servers, and causes low server utilization by not sending enough requests to some servers to effectively utilize them by keeping them busy. Summary of the invention

[0005] A system performs efficient global server load balancing based on Domain Name System (DNS). The system periodically monitors the server health of servers that handle requests directed to virtual servers. Updated server health information is used to process DNS queries that request the assignment of servers to handle requests directed to virtual servers.

[0006] According to an embodiment, a system maintains metadata describing a server based on user requests associated with a virtual server. The virtual server is identified by a uniform resource locator (URL), and the request for the virtual server is processed by one or more servers from a plurality of servers. The system receives a request associated with a virtual server, such as to create, update, or delete information describing the virtual server. The system updates information stored in a database based on the request. The database stores records mapping virtual servers to servers. The system propagates the updated information to a plurality of data plane clusters. Each data plane cluster includes a database for storing metadata that describes a plurality of servers.

[0007] The system periodically updates one or more server health measurements for each of a plurality of servers. The server health measurements are updated for each of a plurality of data plane clusters. The server health measurements are associated with a location within the data plane cluster and are associated with a communication protocol for reaching the server from a computing device in the location. For example, the communication protocol associated with the server health measurement may be one of TCP (Transmission Control Protocol), HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Secure Transfer Protocol) or ICMP (Internet Control Message Protocol). The system processes DNS queries using information describing server health. Thus, the system receives a DNS query from a client device, which requests a server to process a request for a URL pointing to a particular virtual server. The system identifies one or more candidate servers for processing a request for a URL pointing to a particular virtual server based on information stored in a DNS cache. The system selects a candidate server from one or more candidate servers based on factors including the server health measurement of the server and a location associated with the client device. The system sends a response to the DNS query to the client device. The response identifies a candidate server for processing a request for a URL pointing to the virtual server.

[0008] According to an embodiment, the system monitors the server health of a server for processing requests directed to a virtual server, and responds to a DNS query using the monitored health information. The system identifies multiple servers, each of which is associated with a virtual server. For example, the system may receive a request associated with a virtual server identified by a uniform resource locator (URL), and based on the request, update information stored in a database, wherein the database includes a record mapping the virtual server to the server. The request may be metadata information for creating, updating, or deleting a virtual server. The system creates multiple server health check tasks. Each server health check task is used to determine a server health measurement of a server relative to a location. Each server health measurement is associated with a communication protocol for reaching the server from a computing device in the location. The communication protocol associated with the server health measurement may be one of tcp, http, https, or icmp. The system divides multiple server health check tasks into a sequence of multiple task buckets.

[0009] The system monitors the health of multiple servers by periodically repeating a set of steps. The system processes multiple server health check tasks within a time interval. The time interval includes multiple time subintervals. Multiple task buckets are processed in a sequential order, and each task bucket is processed during the time subinterval assigned to the bucket. The processing of the task buckets includes the following steps. The system sends each server health check task to a worker process associated with a communication protocol. The worker process determines a server health measurement of the server by communicating with the server using the communication protocol of the worker process. The system receives the server health check results from the worker process and propagates the server health check results to multiple data plane clusters. The system processes DNS queries, each DNS query requesting a server to process a request directed to a virtual server. The system processes the DNS query by selecting a server based on the server health check results.

[0010] The disclosed technology may be implemented as a computer-implemented method, may be implemented as a non-transitory computer-readable storage medium including instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method steps disclosed herein, or may be implemented as a computer system including one or more computer processors and a non-transitory computer-readable storage medium including instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method steps disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 The figure illustrates the overall system environment of the DNS-based global server load balancing service according to an embodiment.

[0012] Figure 2 An example of traffic flow with set-based load balancing according to an embodiment is shown.

[0013] Figure 3A An example screenshot of a user interface illustrating virtual servers mapped to real servers identified using IP addresses is shown according to an embodiment.

[0014] Figure 3B An example screenshot of a user interface illustrating virtual servers mapped to real servers identified using host names is shown according to an embodiment.

[0015] Figure 3C Another example screenshot of a user interface illustrating virtual servers mapped to real servers identified using host names is shown in accordance with an embodiment.

[0016] Figure 4A is a flow chart illustrating an overall process for handling a DNS query according to an embodiment.

[0017] Figure 4B is a flow diagram illustrating a process for maintaining metadata describing a virtual server according to an embodiment.

[0018] Figure 4C is a flow chart illustrating a process for processing a DNS query according to an embodiment.

[0019] FIG. 5A to FIG. 5B The system architecture of the control plane and the data plane and their interactions according to an embodiment are illustrated.

[0020] Figure 6 The use of database transactions to handle change events according to an embodiment is shown.

[0021] Figure 7 The interaction of various components of the data plane and the control plane according to an embodiment is shown.

[0022] Figure 8 The overall process of the server health check system according to the embodiment is shown.

[0023] Fig. 9 A flow chart illustrating a scheduler process according to an embodiment is shown.

[0024] Fig.10 A flow chart illustrating a multiplexer process according to an embodiment is shown.

[0025] Fig.11A Various aspects of a user interface for managing health check views are illustrated according to one embodiment.

[0026] Fig. 11B Illustrated are various aspects of a home page of a user interface according to one embodiment.

[0027] Fig. 11C Various aspects of a user interface for a namespace view are illustrated according to one embodiment.

[0028] Fig.11D Various aspects of a user interface for a virtual server view are illustrated according to one embodiment.

[0029] Fig.11E Various aspects of a user interface for a virtual server audit view are illustrated according to one embodiment.

[0030] Fig.11F Illustrated are various aspects of a user interface for a virtual server detail view according to one embodiment.

[0031] Fig.11GIllustrated are various aspects of a user interface for a virtual server health check status view according to one embodiment.

[0032] Fig.12 is a block diagram of an example computer suitable for use as a server or a client device.

[0033] The accompanying drawings and the following description describe certain embodiments only by way of illustration. Those skilled in the art will readily appreciate from the following description that, without departing from the principles described, alternative embodiments of structure and method may be adopted. Where feasible, similar or similar reference numerals are used in the accompanying drawings to indicate similar or similar functionality. In the case where elements share a common number followed by different letters, this indicates that the elements are similar or identical. Unless otherwise indicated by the context, a single reference number generally refers to any one or any combination of such elements. DETAILED DESCRIPTION

[0034] Figure 1 The overall system environment of a DNS-based global server load balancing service according to an embodiment is illustrated. The load balancing system 100 allows users to efficiently create virtual servers for the backends of services running on physical servers. The load balancing system performs load balancing on the traffic of the virtual servers by region, health, weight, or any combination of these. The load balancing system includes a control plane implemented as a control plane cluster 110 and a data plane implemented as a plurality of data plane clusters 120a, 120b, 120c, 120d, 120e, 120f, etc. References to the control plane herein correspond to the control plane cluster 100. References to the data plane herein correspond to the data plane cluster 120.

[0035] Different data plane clusters can be implemented in different geographic regions. For example, data plane clusters 120a and 120b can be on one continent, while data plane clusters 120c and 120d can be on different continents. The control plane handles change requests entering the system via application programming interface (API) requests or user interface (UI) requests. The data plane is responsible for various functions, including: (1) providing records to clients. (2) performing health checks on target backends. (3) synchronizing data from the control plane. (4) providing health check status changes, etc. Each data plane cluster 120 is a complete, fully functional version of the data plane that operates independently. The system implements various types of load balancing mechanisms, such as weight-based load balancing or other types of load balancing. The system performs health checks, so if a server is down, the system will not return that server as a result of a DNS query, and therefore will not send requests to that server. The system can be configured to allow responses from specific regions.

[0036] The system performs DNS-based load balancing, which is intended to provide load balancing through DNS resolution. The system receives a DNS query from an application and processes it to map the received domain name or alias to an IP address provided as a result of the DNS query and used by the application to connect to the server. This is different from traditional load balancers that intercept traffic, such as network load balancers. The system receives a request from an application (e.g., a browser such as Chrome). The request may be to connect to a target domain or alias, such as www.xyz.com. The application attempts to resolve the alias by performing a DNS query. The DNS query can be forwarded to a cache server. If the cache does not have a reply to the DNS query, the system forwards the request to the authoritative server. The system performs a query to determine the network address (e.g., IP address) provided as a result of the query. The application connects directly to the target server through the network address.

[0037] The system can perform different types of load balancing, such as round-robin load balancing, set-based load balancing, or other types of load balancing. The system implements a DNS round-robin load balancing strategy by using a set of DNS resource records with multiple IP addresses that are cycled for each DNS request returned by the DNS caching infrastructure. This provides uniform near-time distribution across multiple IP addresses because the cache layer has all the information from all servers in the set and is able to provide load-balanced responses for each query.

[0038] Figure 1 Like reference numerals are used to identify like elements. A letter following a reference numeral (such as "120A") indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter (such as "140") refers to any or all elements in the drawings that carry that reference numeral. For example, "140" in the text refers to reference numerals "120A," "120B," and / or "120N" in the drawings.

[0039] Figure 1The various systems shown communicate via a network. The network provides communication channels, and other elements of the networked computing environment can communicate via these communication channels. The network may include any combination of local area networks and wide area networks using wired or wireless communication systems. In one embodiment, the network uses standard communication technologies and protocols. For example, the network may include communication links using technologies such as Ethernet, 802.11, Worldwide Microwave Access Interoperability (WiMAX), 3G, 4G, 5G, Code Division Multiple Access (CDMA), Digital Subscriber Line (DSL), etc. Examples of networking protocols for communicating via a network include Multi-Protocol Label Switching (MPLS), Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) and File Transfer Protocol (FTP). Data exchanged through the network can be represented using any suitable format, such as Hypertext Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, one or more any suitable technologies may be used to encrypt some or all of the communication links of the network.

[0040] Figure 2 An example of a traffic flow with set-based load balancing according to an embodiment is shown. The control plane cluster 110 (also referred to as the control plane) receives a request 210 from a service provider 205 to associate a virtual server alias with a real server (e.g., server 1 and server 2). The real server is also referred to herein as a server. The request 210 can be received from a user interface (UI) or an API. For audit purposes, the request 210 can be logged in a database 220 and added to a queue 225, such as a RabbitMQ TM . The request is handled by the data plane cluster 120 and processed by the authoritative server 230. The authoritative server 230 interacts with a health checker 235, which polls various servers including Server 1 and Server 2. The authoritative server 230 responds 245 based on various factors, including the location of the user, the health of the target server, and the weight associated with each server. Once the virtual server alias is associated with a real server (e.g., Server 2), the mapping is stored in one or more DNS caches 260. The client 265 can perform a DNS query to find 250 the virtual server alias. Depending on the DNS cache 260 that handles the request, the client 265 receives the server associated with the virtual server alias (e.g., Server 2). According to an embodiment, the weights of the servers are configurable and can be assigned by the user. However, in other embodiments, the system can automatically determine the weights based on various factors, such as the type of machine on which the server is running, the speed of the network connection to the server, etc.

[0041] Figure 3AAn example screenshot of a user interface according to an embodiment is shown, illustrating virtual servers mapped to real servers identified using IP addresses. To create a virtual server with round-robin load balancing, the system creates real servers with the same collection name. The disadvantage of this approach is that the system can only use IP addresses in the collection and cannot use host names or combine IPs with host names in the collection. Figure 8 As shown, the virtual server 215 is mapped to a tree of real servers 220a, 220b, 220c.

[0042] The system also supports set-based load balancing, allowing host names to be used in sets assigned to virtual servers. The system creates more than one set within a location. According to an embodiment, a client makes a DNS query to a DNS cache infrastructure. The system can configure records with a default time-to-live (TTL) value of T seconds (e.g., 5 seconds). Every T seconds, the cache forwards the request to the authoritative server, which responds with one of the sets associated with the virtual server. The response is then cached for T seconds. During this T second period, any client that queries the cache will get the same set as the reply.

[0043] Figure 3B An example screenshot of a user interface according to an embodiment is shown, which illustrates a virtual server mapped to a real server identified by a host name. As shown in Figure 3, a virtual server 310 is mapped to two real servers 320a, 320b identified by a host name. However, unlike round-robin DNS load balancing, there are two sets S1 and S2. Each set has a single real server based on a host name within it. Virtual hosts are assigned to regions 315, which are global, but can be Americas, Europe, the Middle East and Africa, Asia, etc. The weight of each set is indicated as 325A, 325B. Each circle corresponding to entities such as virtual hosts, real hosts, regions, etc. shown in the user interface indicates the health of the entity. For example, a green circle may indicate good health, and a red circle may indicate poor health.

[0044] Figure 3C Another example screenshot of a user interface illustrating virtual servers mapped to real servers identified using host names is shown in accordance with an embodiment. Figure 3C The health of real servers 320A, 320B is illustrated as being associated with each data plane cluster illustrated in the set of data plane clusters 330. The health of a real server may be associated with a location within each data plane cluster, such as a build. Thus, the health of the same real server may be different for two different data plane clusters. Similarly, the health of a real server may be different for two different locations within the same data plane cluster.

[0045] Figure 4A 404 is a flow chart illustrating an overall process for processing DNS queries according to an embodiment. The system maintains 402 metadata describing virtual servers. The control plane 110 of the system receives requests associated with virtual servers, such as create, update, and delete requests, and updates metadata describing the virtual servers in the database 220. The metadata of the control plane is propagated to the data plane. The health checker 235 of the data plane 120 of the system monitors and maintains 405 the health of the various real servers of the system. The data plane 120 of the system receives and processes DNS queries based on the metadata and the health of the real servers.

[0046] The details of step 402 are in Figure 4B Further illustrated in Figure 4B The details of step 405 are described in Figure 8 Figure 2. Figure 8 The details of step 408 are described in Figure 4C Figure 2. Figure 4C Give a description.

[0047] Figure 4B is a flow diagram illustrating a process for maintaining metadata describing a virtual server according to an embodiment. Figure 4B The process shown provides Figure 4A The details of step 402 are shown in FIG.

[0048] The control plane 110 receives 410 a request to update metadata describing a virtual server, such as a request to create a new virtual server, a request to modify an existing virtual server, or a request to delete an existing virtual server, via a UI or API. The system updates 412 data stored in the database 220 based on the request. If the received request is a request to create a new virtual server, the system adds a new record associated with the new virtual server to the database 220. If the received request is a request to modify the new virtual server, the system modifies the record associated with the virtual server in the database 220. If the received request is a request to delete a virtual server, the system deletes the record associated with the virtual server from the database 220.

[0049] The record includes metadata describing the real server associated with the virtual server, such as the real server ID; record type (using IP address or host name to indicate whether the record is a real server); record data (the actual IP address or host name corresponding to the real server); collection name; collection weight; the region where the real server exists (Global, Americas, Europe, Middle East and Africa, Asia); location, such as the name of the data center where the real server is maintained, the region in the cloud platform, the name of the building where the real server is maintained (an enumeration value identifying the location); health check type, indicating the type of network communication or communication protocol used to check the health of the real server, such as none, icmp (Internet Control Message Protocol with ping support), tcp (transmission control protocol), http (hypertext transfer protocol), or https (hypertext transfer protocol secure); health check data, indicating the value received from the real server in response to the health check request; the time of the last health check; the current state of the real server (on, off, disabled); and so on.

[0050] The control plane pushes updates to the record to queue 225. Changes to the record are propagated 418 to the various data planes. Thus, a subset of data stored in database 220 that is relevant to answering the DNS query is sent to the data plane and stored in the data plane's database 228. The data plane updates 420 the DNS cache based on the database update to the record. The data stored in the DNS cache is used to process the DNS query.

[0051] If a DNS authoritative server receives a request to resolve an alias, the DNS authoritative server provides a response based on a number of factors: the weight of the real server, the health of the real server (if health checking is enabled), and the location of the calling client. Because DNS is used, traffic may also be directed to the real server despite a health check or a weight of zero (0). DNS records are looked up from a cache, and each DNS record has a TTL of, for example, five seconds. Therefore, depending on when the client last looked up that record and which DNS cache was hit, the client may still get a record that is down (or zero weighted) because it is cached.

[0052] When a user attempts to resolve a virtual server alias, there may be many factors that affect the target backend server provided in the DNS query response. This is because of the DNS caching layer. For example, assume there is a virtual server with two real servers weighted 2:1, and health checks are enabled on these real servers. The server health observed by the system may be different from the actual health. For example, if there is network latency, the system may observe that the server is unhealthy even if it is healthy, because of the latency in reaching the server. Assuming that the servers are healthy, as observed by the system, regardless of their actual health, the first query to the DNS authoritative server and the second query result in the first real server being returned as a response. Assuming that the third query to the DNS authoritative server results in the second real server being returned as a response. This response is cached by the DNS cache, and any new client that attempts to use that alias (which happens to go through the same cache server) will get that response within the next five seconds (because that is the TTL of the Nimbus record).

[0053] Furthermore, there may be multiple (e.g. 12) authoritative servers that can respond to a user query, each of which may be at various stages of iteration to balance the weight of the real servers, and there are also hundreds of cache servers, all of which may be at various stages of the TTL for that record. Therefore, the system may return different results depending on the context.

[0054] The system allows for zone routing to map virtual server aliases to real servers. According to an embodiment, the system uses the location of the user / client device sending the request to decide which server to provide in response to a DNS query. The system determines the location of the user (or client device receiving the request) by detecting the location of the DNS cache that forwarded the request. The system also has a database of every subnet deployed across the enterprise and its location. When a request comes into the system, the system obtains the source IP of the DNS request (usually the DNS cache IP address) and calculates the subnet of the IP and determines the location of the client device based on the location associated with the subnet.

[0055] The system relies on the DNS caching infrastructure to make decisions about the user's location. If the local or regional set of DNS caches is down, the system may misunderstand the user's location and provide answers for a different region than expected.

[0056] Figure 4C430 is a flow diagram illustrating a process for processing a DNS query according to an embodiment. The system receives 430 a DNS query and validates the DNS query. The DNS query may specify a virtual server and request a real server to handle requests directed to the virtual server. The system finds 432 all real servers for the virtual server. If the system determines 435 that no real server was found, the system returns 438 an error indicating that no real server was found for the specified virtual server.

[0057] If the server finds one or more real servers, the system identifies the real servers by performing the following steps. Based on the health checks performed, the system excludes 440 real servers that are known to be unhealthy. If the set to which the server belongs is disabled or has a weight of zero (or any weight value indicating that the set should not be used), the system also excludes 440 the server. If there are multiple regions associated with the set, the system filters the servers based on the region to identify only servers that match the client region that sent the request. If more than one real server or set of real servers remains, the system selects 445 servers that have regions near the client region. According to an embodiment, the system stores routing plans for regions. If all servers in a given region are down or unavailable, and the service provider configures the system to use regional routing with health checks, the system uses another set of regions to determine which real server can be provided as a reply to the DNS query. Examples of regions include America, Europe, Asia, etc., but are not limited to these. If Area A, Area B, Area C, and Area D represent different areas, the routing plan for Area A can be an ordered list of areas such as Area A→Area C→Area B→Area D, and the routing plan for Area C can be Area C→Area D→Area A→Area B.

[0058] According to an embodiment, the system stores a routing plan to determine an alternate region in the event that a server in a region is unavailable. The routing plan identifies a sequence of regions in order of priority. The system traverses the sequence of regions specified in the routing plan order to identify the regions. For example, assume that the routing plan specifies the sequence region A→region B→region C→region D. If there are no available servers in region A, the system searches for applicable servers in region B; if there are no available servers in region B, the system searches for applicable servers in region C; if there are no available servers in region C, the system searches for applicable servers in region D, and so on. The system identifies servers from the regions identified based on the routing plan. If a server cannot be identified based on the routing plan, the system can return any healthy server.

[0059] If there are multiple servers or sets of servers, the system selects 450 a server or set of servers based on the weights and previous servers returned in response to a received DNS query for the particular virtual server. Thus, the system returns the remaining real servers so that the number of times a server set (or servers) is returned is proportional to the weight of the server set (or the weight of the set associated with the server) within a given time interval. For example, if the weight of server set S1 is w1 and the weight of server set S2 is w2, and w1 is greater than w2, then set S1 (or servers from set S1) is more likely to be returned in response to a DNS query for a virtual server than set S2. In addition, the system ensures that the ratio of the probability p1 of returning set S1 compared to the probability p2 of returning set S2 matches the ratio of weights w1 and w2. The system stores 455 the selected server and returns the server in response to the query. The system stores information indicating the number of times a server or set of servers has been returned in response to a DNS query identifying a virtual server, so that when a DNS query is received again, the historical information can be used to determine the response to the DNS query.

[0060] Figures 5A to 5B The system architecture and interaction of the control plane and data plane according to an embodiment are illustrated. Users can use the system to efficiently (within seconds) create aliases (virtual servers) for backends (real or physical servers) running services, and load balance traffic by region, health, weight, or any combination of these. There can be multiple data plane clusters that operate independently of each other. Therefore, if one of the data plane clusters is not operating or cannot be reached, other data plane clusters can be used. Therefore, the data plane can be upgraded independently of other data planes. For example, during the upgrade of one data plane cluster, the remaining data plane clusters can provide the required services. The control plane cluster supports high request rates, such as thousands of requests per minute. Similarly, the system can perform health checks at very high rates, such as thousands of health checks per second.

[0061] The control center node 510 executes a control center process 512 that receives the request via a user interface or API. Data describing the request may be stored in a database 517, such as MongoDB. TMetc. document database. If a change request is received via the control plane, the change is reliably executed and fed to the data plane using the transaction of the database. The control plane stores information such as logs, audit information, etc. in DB 550. The control plane mode interacts 515 with the data plane via queue 522. If the system needs to write information based on a change request received via the API, the system will change the write data and the audit information of the change in the transaction for the database 517. Auditing changes allows the security of implementing system changes by allowing experts to review the changes that have occurred and the users who performed the changes. Examples of processed change events include creating a new virtual server alias, deleting a virtual server alias, updating the weight of a server, changing a virtual server alias definition, etc. According to an embodiment, the database 517 supports change streams so that a process can subscribe to changes in the change stream. Therefore, every time there is a change, the change will be pushed down to the queue 522. Any data plane cluster will consume the change.

[0062] Control plane nodes perform various tasks such as logging requests, authorization checks, auditing backups, etc. Control plane nodes are stateless and can be scaled horizontally. Even if a control plane node stops functioning, the data plane cluster can continue to operate.

[0063] The data plane is responsible for various functions. Data plane nodes provide records to clients via the DNS protocol. Data plane nodes calculate the reply provided back to the client based on many different factors, such as the location of the client, record configuration including weights and health checks. The data plane performs health checks on the target backend. The data plane provides a mechanism to synchronize data from the control plane. The data plane provides a mechanism to provide health check status changes back to the control plane.

[0064] Changes received by the data plane are processed by the data synchronization service, which propagates the changes to the data plane's data repository or sites within the data repository. Even if the same change is propagated to multiple data planes, two different data planes may respond to the same DNS query in different ways. For example, a first data plane cluster may return server S1 in response to a DNS query specifying virtual host V1, while a second data plane cluster may return server S2 in response to the same DNS query specifying virtual host V1. This may be due to various reasons, such as because different data planes may determine different values ​​for the health of a server, data may be stored in each data plane's cache for different lengths of time, etc. The data plane nodes also take into account factors such as the location of the client to determine the correct result for a DNS query received from the client.

[0065] The system associates each change event with a sequence ID to ensure that no change event is lost. The sequence ID is monotonically increasing. The nodes in the data plane cluster include a cache that stores information about the data plane's data repository. The data plane receives and processes client requests. The data plane nodes determine the correct real server for the virtual server alias.

[0066] Figure 6 The use of database transactions to process change events according to an embodiment is shown. The database is a document database that stores documents as collections. The received change event 605 is processed using an appropriate service 610 to implement the change. The service 610 creates a database transaction 612. The change event is saved as a document 620 in the appropriate collection class of the database. The data of the change event is passed to an audit service 615. The audit service creates an audit document 625. The audit document 625 has time data and is immutable. The system uses a database 630 to generate a monotonically increasing timestamp. A sequence ID is also generated for each transaction. Some sequence IDs may have to be discarded (in the case of a rollback). However, the system does not track discarded sequence IDs (to avoid the situation where the data plane attempts to read an uncommitted sequence ID). The wait timeout used by the system is longer than the automatic rollback timeout of the database. The system determines that any sequence ID not found is the result of a rollback.

[0067] The database 630 includes an audit collection class. The system persists audit documents (within the same transaction as above) into the audit collection class. Any kind of failure within the transaction boundary will not cause any changes to the database, as the failure will be properly rolled back (or via a timeout). There may be multiple threads / processes reading the change stream 635 for high availability. These publish the same message to a queue 645 (e.g., RabbitMQ). The consumer's (data plane) manages duplicate messages.

[0068] Providing service 640 listens to changes to the audit collection class via the database change stream.A single audit message may result in multiple messages (and vice versa) being delivered to the queue exchange.

[0069] Figure 7The interactions of various components of the data plane and control plane according to an embodiment are shown. Interaction A-1 shows that when changes pass through the control plane, they are submitted to a queue (as an event log). These changes are picked up and processed in order (by sequence ID). The lack of a sequence ID in one virtual server will not affect other virtual servers. Skipping sequence IDs is supported. Interaction A-2 shows that in case out-of-order updates are received (or the queue mechanism is interrupted), API is used as a fallback mechanism to obtain the sequence ID via HTTP. Interaction A-2 shows that the data is maintained in the database as a completely flattened record. This write-time consistency is preferred, so slower writes are possible (e.g., 1000 writes per second).

[0070] The Data Sync service supports incremental (event log) updates as well as full data sync. Full data sync acts as a backup mechanism to ensure that the data on both sides is correct. Full data sync is performed periodically. The service also synchronizes subnet information required for zone routing. Interaction B-1 represents the client resolving the DNS query via the caching infrastructure. Interaction B-2 represents the query being forwarded to the name server. This component is responsible for DNS protocol translation. Once encoded, the request is sent to the DNS answer service. Interaction B-3 represents the DNS answer service receiving the encoded structured request. It asks the database (possibly via cache) for the data attached to the requested record. It performs any computational logic required (health, zone, weight, etc.) and returns the final structured reply to the name server for DNS protocol translation to the response. Interaction B-4 represents finding data by indexing search on the data repository. The data repository must perform well at scale and be read-optimized. The data model needs to be lightweight and simple enough to retrieve data quickly. Interaction B-5 represents logging every query received by the name server. Ideally, log aggregation of certain metrics should be stored for long term storage. The lifecycle of a full request-response may be short.

[0071] Datastore D-1 is the central component of the system. Reads from the datastore are fast because the workload is a read-heavy profile. No data is stored or backed up because the data is mastered and managed via the control plane. The datastore contains subnet data as well as metadata for the site.

[0072] Log storage D-2 is used to store large amounts of data. Log storage D-2 is write-optimized and has an automatic data removal policy due to the volume of DNS and health check logs. The log storage is shared by all data planes.

[0073] The site health monitoring service D-3 is responsible for ensuring that all components of a site are performing optimally. If components are not performing optimally, the site health monitoring service D-3 is responsible for raising alarms and shutting down the site to protect the entire data plane from the impact of a bad site.

[0074] The Site Health Monitoring Service D-3 also reports to the control plane and coordinates (via the control plane) to ensure that at least one site is up before shutting down a site in the event of a component failure. The Site Health Monitoring Service D-3 also acts as a web server for site management functions.

[0075] The health check scheduler service will try to discover all target endpoints that C-1 needs to check on a periodic basis (every second) and try to schedule the work. The scheduler is multi-instance and distributed to improve reliability.

[0076] Workers are simple execution engines that perform C-2 checks directly against the target backend. Workers (all together within the site) process at least 15k checks per second. Once the work is completed, the results are reported C-3 to the result processor.

[0077] The processor stores C-4 the final state per record for easy lookup as well as state change information. Change triggers are used to push C-5 health audit events into the state synchronization service. Messages are converted C-6 and provided back to the control plane via the state change queue. The system supports full (and current) state synchronization of all records. All work is reported C-7 to the log repository for query and analysis.

[0078] Figure 8 The overall process of the server health check system according to the embodiment is shown. The health check system consists of two parts: (1) the master scheduler process (MSP), which is responsible for managing and scheduling health checks and managing results; and (2) the worker manager, which is responsible for starting and managing health check workers that perform server health check tasks. Tasks may also be referred to as jobs in this article.

[0079] The system is highly scalable and capable of performing a large number of health check operations, for example, using state-of-the-art processing hardware, the system can process approximately 30,000 checks per second in a cluster at half the capacity of a CPU core. The main scheduler process consists of the following four components: (1) Service Engine 802, responsible for managing inter-process communication, resilience, and failover; (2) Multiplexer 810 (or job multiplexer), responsible for distributing jobs to workers and managing responses from workers; (3) Writer 830, responsible for propagating responses to the database, name server, and control plane; and (4) Scheduler 805, responsible for job scheduling. Each component can be implemented as a process, such as a daemon. Each component is configurable and reads a set of configuration parameters to start processing.

[0080] The service engine 802 handles the check heartbeats of all major components (e.g., multiplexer 810, writer 830, scheduler 805) and can turn them on / off based on the health of the system. For example, if the service engine 802 determines that a component (e.g., scheduler 805) has changed, the service engine attempts to restart the scheduler 805. If the service engine 802 determines that components such as scheduler 805 cannot be restarted, the service engine 802 can take the entire data plane cluster offline because the data plane cluster cannot monitor the health of the server and therefore cannot accurately process DNS queries. Therefore, the DNS query is redirected to another data plane cluster. However, if the system performs a site health check and determines that the data plane cluster is the only running data plane cluster, the system will keep the data plane cluster running so that the system can process DNS queries, even if the results are inaccurate, instead of shutting down the entire system.

[0081] Fig. 9 A flow diagram illustrating a scheduler process according to an embodiment is shown. The scheduler 805 identifies 910 various servers to check their health. The scheduler 805 opens a connection to a queue to monitor ongoing changes and a connection to a database to read all records from the database into memory. The scheduler 805 reads all initial health check status data from the database into memory as well as any DNS namespace information. The scheduler 805 opens a connection, such as a TCP socket connection, to a multiplexer 810. The records loaded by the scheduler 805 store information describing the various servers, including their mapping to virtual servers and the currently known health information of the server indicating whether the server is up or down.

[0082] The scheduler 805 repeatedly performs the following steps. The scheduler 805 reads 912 the ongoing record changes in the queue and ensures that the record in the database matches the copy of the record in memory. The scheduler 805 can filter the records, for example by checking the metadata of the record to determine whether health checks are disabled for any record.

[0083] The scheduler 805 creates multiple server health check tasks. Each server health check task is configured to determine a server health measurement of a server relative to a location (e.g., a data plane cluster or a build within a data plane cluster). Each server health measurement is associated with a communication protocol used to reach the server from a computing device in a specific location. Examples of communication protocols that can be associated with a worker include TCP (Transmission Control Protocol), HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure), or ICMP (Internet Control Message Protocol). The worker uses the corresponding communication protocol to reach the server. If the worker is able to reach the server within a threshold time, the worker determines that the health of the server is good, otherwise the worker determines that the server is not healthy.

[0084] The scheduler divides 915 the plurality of server health check tasks into a sequence of task buckets. Thus, the tasks are divided into a plurality of task buckets, and each bucket is assigned a sequence number indicating the order in which the task buckets are processed within a time interval.

[0085] The system monitors the health of multiple servers by periodically repeating the following operations, such as processing all buckets within a time interval (e.g., 10 seconds) and then repeating the process within the next time interval. The system processes multiple server health check tasks within the time interval. The scheduler divides the time interval into multiple time subintervals, one time subinterval corresponding to each bucket. For example, if there are 10 buckets and the time interval is 10 seconds long, then each second of the 10 seconds is assigned to a bucket. Multiple task buckets are processed in the order of the task bucket sequence, and each task bucket is processed during the time subinterval assigned to the bucket.

[0086] Therefore, the scheduler repeats steps 918, 920, 923, 925 in each time subinterval. The system selects 918 the bucket corresponding to the time subinterval based on the sequence number of the bucket. If the scheduler determines 920 that there are unfinished tasks in the previous time subinterval, the scheduler adds the unfinished tasks to the current bucket so as to continue the unfinished tasks. The scheduler sends 923 the server health check tasks in the task bucket to the worker process. Each worker process determines the server health measurement of the server by communicating with the server using the communication protocol of the worker process. The scheduler determines statistics, such as the number of unfinished tasks that are continued, the number of workers in operation, etc., and sends 925 statistics via the user interface of the control plane for display. The scheduler also sends a heartbeat signal to the service engine, indicating the health of the scheduler itself.

[0087] Fig.10A flow chart illustrating a multiplexer process according to an embodiment is shown. The multiplexer process receives a job from a scheduler and ensures that the job is processed by a worker process. The multiplexer process opens 1010 a connection (e.g., a TCP socket) with the scheduler. The multiplexer process opens 1012 a connection (e.g., a TCP socket) with a worker process. The multiplexer process periodically repeats steps 1015, 1018, 1020, 1023, 1025. The multiplexer process receives 1015 a collection of jobs, such as a job bucket, from the scheduler. The multiplexer process sends 1018 the job to the worker process. The multiplexer process receives 1020 a job execution result from the worker process, indicating the health of the server. The multiplexer process also receives a heartbeat signal from the worker process indicating the health of the worker process. The multiplexer process writes 1023 the result of the job to the writer process, which stores the information in a database and propagates the information to various data planes via a queue. The multiplexer process 1025 adjusts the worker process to which the next job is assigned based on the status (health or heartbeat signal) of the received worker process.

[0088] The writer process opens connections to the queue and database. The writer process also opens a connection to the multiplexer to listen to information provided by the multiplexer process. The writer process reads the results of the server health check from the multiplexer and determines whether the health status of any server has changed, that is, from top to bottom or from bottom to top. The writer process writes state change information to the database and queue describing the servers that changed state. The writer process also provides statistics to the control plane, such as the number of servers that changed state. The writer process also sends a heartbeat to the service engine describing the health of the writer process.

[0089] The worker manager process starts worker processes. Each worker process opens a connection to the multiplexer process to listen to the tasks that the worker should perform in the multiplexer process and provide the multiplexer with the results of the server health check. The worker process receives information identifying the server for performing the health check and performs the health check by attempting to connect to the server using the communication protocol associated with the worker. The worker process can receive an indication of successful communication or an indication of failed communication from the server. The indication of failure can be a timeout or an error message received as a result of the communication protocol. The worker process writes the results to the multiplexer process. The worker process also sends a heartbeat signal to the multiplexer process, indicating the health of the worker process itself.

[0090] The results of the health check are provided by the multiplexer process to the writer process, which provides the results to the database and queue. The health check information is propagated from the database and queue to each data plane cluster. The data plane cluster stores the health check information in the DNS cache and uses this information to provide the latest results in response to DNS queries.

[0091] Screen shots of the user interface displayed via the control plane are described below. FIG. 11A to FIG. 11G Medium picture.

[0092] Fig.11A Various aspects of a user interface for managing a health check view according to one embodiment are illustrated. The user interface allows a user (e.g., a system administrator) to request a health check. User interface 1105 shows various types of health checks. User interface 1108 displays statistics describing health check information.

[0093] Fig. 11B Various aspects of a home page of a user interface according to one embodiment are illustrated.The user interface allows a user to perform various types of operations, including creating a namespace 1112, creating a virtual server 1114, and updating the weights 1118 of a set of real servers.

[0094] Fig. 11C Various aspects of a user interface for a namespace view according to one embodiment are illustrated. The user interface shows a list 1132 of all namespaces. A user can filter 1134 the namespaces using search criteria.

[0095] Fig.11D Various aspects of a user interface for a virtual server view according to one embodiment are illustrated. The user interface shows a list 1142 of all virtual servers. A user can filter 1144 virtual servers using search criteria.

[0096] Fig.11E Various aspects of a user interface for a virtual server audit view are illustrated according to one embodiment.The audit view shows various actions 1152 and users 1154 who performed those actions.

[0097] Fig.11F Various aspects of a user interface for a virtual server detail view according to one embodiment are illustrated.The user interface shows a mapping of virtual servers to different real servers 1162 and weights of real servers from different locations 1164 corresponding to different data plane clusters.

[0098] Fig.11G Various aspects of a user interface for a virtual server health check status view according to one embodiment are illustrated. The user interface shows various real servers and their health 1172 as well as different types of metadata, including timestamps of health checks, corresponding virtual servers, and the like.

[0099] Computing system architecture

[0100] Fig.12is a block diagram of an example computer 1200 suitable for use as a server or client device. The example computer 1200 includes at least one processor 1202 coupled to a chipset 1204. The chipset 1204 includes a memory controller hub 1220 and an input / output (I / O) controller hub 1222. Memory 1206 and a graphics adapter 1212 are coupled to the memory controller hub 1220, and a display 1218 is coupled to the graphics adapter 1212. Storage devices 1208, keyboard 1210, pointing device 1214, and network adapter 1216 are coupled to the I / O controller hub 1222. Other embodiments of the computer 1200 have different architectures.

[0101] exist Fig.12 In the illustrated embodiment, storage device 1208 is a non-transitory computer-readable storage medium, such as a hard drive, a compact disk read-only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 1206 holds instructions and data used by processor 1202. Pointing device 1214 is a mouse, trackball, touch screen, or other type of pointing device, and can be used in conjunction with keyboard 1210 (which can be an on-screen keyboard) to enter data into computer system 1200. Graphics adapter 1212 displays images and other information on display 1218. Network adapter 1216 couples computer system 1200 to one or more computer networks, such as network 170.

[0102] Figure 1 and 2 The type of computer used by the entity of can vary depending on the embodiment and the processing power required by the entity. For example, the computer may lack some of the above components, such as keyboard 1210, graphics adapter 1212 and display 1218.

[0103] Additional considerations

[0104] Some parts of the above description describe embodiments from the perspective of algorithmic processes or operations. These algorithmic descriptions and representations are often used by those skilled in the art of computing to effectively convey the essence of their work to other technicians in the field. Although described functionally, computationally, or logically, these operations are understood to be implemented by computer programs, including instructions for execution by a processor or equivalent circuit, microcode, etc. In addition, without loss of generality, it is sometimes convenient to refer to these functional operation arrangements as modules.

[0105] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in this specification does not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is merely for convenience. The description should be understood to mean that there are one or more elements or components unless it is clear that the meaning is different.

[0106] If a value is described as "approximately" or "substantially" (or derivatives thereof), such value should be interpreted as being exactly + / - 10%, unless another meaning is apparent from the context. For example, "approximately 10" should be understood as "within the range of 9 to 11".

[0107] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated otherwise, "or" refers to an inclusive or, not an exclusive or. For example, a condition A or B is satisfied by any of the following: A is true (or present) and B is false (or absent), A is false (or absent) and B is true (or present), and both A and B are true (or present).

[0108] After reading this disclosure, those skilled in the art will appreciate that there are additional alternative structures and functional designs. Therefore, although specific embodiments and applications have been illustrated and described, it is to be understood that the described subject matter is not limited to the precise configurations and components disclosed. The scope of protection should only be limited by the following claims.

Claims

1. A method for global server load balancing based on a domain name system (DNS), the method comprising: receiving a request associated with a virtual server identified by a uniform resource locator (URL), wherein the request to the virtual server is processed by one or more servers from a plurality of servers; updating information stored in a database based on the request, wherein the database stores records mapping virtual servers to servers; propagating the updated information to a plurality of data plane clusters, each data plane cluster comprising a database for storing metadata describing the plurality of servers; periodically updating, for each of the plurality of data plane clusters, one or more server health measurements for each of the plurality of servers, wherein the server health measurements are related to a location within the data plane cluster and are associated with a communication protocol for reaching the server from a computing device in the location; receiving a DNS query from a client device, the DNS query requesting a server to process a request for the URL directed to a particular virtual server; identifying, based on information stored in the DNS cache, one or more candidate servers for handling requests for the URL directed to the particular virtual server; selecting a candidate server from the one or more candidate servers based on factors including a server health measure of the server and a location associated with the client device; as well as A response to the DNS query is sent to the client device, the response identifying the candidate server for handling requests directed to the URL of the virtual server.

2. The method of claim 1, wherein a new virtual server is requested to be created and associated with one or more server sets, each server set having a weight indicating a likelihood that a server in the server set is assigned to the virtual server.

3. The method of claim 2, wherein the factors include a weight of a set of servers to which a particular server belongs. 4 . The method of claim 1 , wherein the factors include a server previously returned in response to a DNS query requesting a server for the virtual server.

5. The method of claim 1, wherein the communication protocol associated with the server health measurement of the server is one of: TCP (Transmission Control Protocol), HTTP (Hypertext Transfer Protocol), or HTTPS (Hypertext Transfer Protocol Secure), or ICMP (Internet Control Message Protocol).

6. The method of claim 1, wherein identifying the one or more servers for the virtual server comprises selecting a server from a zone, wherein the zone is determined based on a routing plan associated with the virtual server, the routing plan comprising a sequence of zones. 7 . The method of claim 1 , wherein the location of the client device is determined based on the DNS cache that received the request from the client device.

8. A method for global server load balancing based on a domain name system (DNS), the method comprising: identifying a plurality of servers, each server being associated with a virtual server; creating a plurality of server health check tasks, each server health check task for determining a server health measurement of a server relative to a location, each server health measurement being associated with a communication protocol for reaching the server from a computing device in the location; Dividing the plurality of server health check tasks into a sequence of a plurality of task buckets; Monitoring the health of the plurality of servers by periodically and repeatedly processing the plurality of server health check tasks within a time interval, the time interval comprising a plurality of time subintervals, the plurality of task buckets being processed in the order of the sequence of the plurality of task buckets, each task bucket being processed during the time subinterval assigned to the bucket, the processing comprising: sending each server health check task to a worker process associated with a communication protocol, wherein the worker process determines a server health measure of a server by communicating with the server using the communication protocol of the worker process, receiving the results of the server health check from the worker process, and propagating said results of the server health check to a plurality of data plane clusters; as well as The processing requests the server to process a DNS query of the request directed to the virtual server, and the processing includes selecting a server based on the server health check result.

9. The method according to claim 8, wherein the processing of the task bucket further comprises: determining that one or more tasks in the task bucket are not completed at the end of the time subinterval corresponding to the task bucket; as well as The one or more tasks of the bucket are added to a next bucket in the task bucket sequence.

10. The method according to claim 8, further comprising: receiving a request associated with a virtual server identified by a uniform resource locator (URL), wherein the request to the virtual server is processed by one or more servers from a plurality of servers; as well as Information stored in a database is updated based on the request, wherein the database includes records mapping virtual servers to servers.

11. The method of claim 8, wherein processing a DNS query received from a client device comprises: identifying one or more candidate servers for the virtual server based on information stored in the DNS cache; selecting a particular server from the one or more candidate servers based on factors including the measure of the health of the server and a location associated with the client device; as well as A response identifying the server is provided to the client device.

12. The method of claim 8, wherein the communication protocol associated with the health measurement of the server is one of: TCP (Transmission Control Protocol), HTTP (Hypertext Transfer Protocol), or HTTPS (Hypertext Transfer Protocol Secure), or ICMP (Internet Control Message Protocol).

13. The method of claim 8, wherein propagating the results of the server health check to a plurality of data plane clusters comprises: The results of the server health check are written to a queue, wherein each of the plurality of data plane clusters listens to changes written to the queue to update data stored in a DNS cache. The method of claim 8 , wherein the health result of a server indicates whether the server is on or off.

15. A non-transitory computer-readable storage medium storing instructions which, when executed by one or more computer processors, cause the one or more computers to perform the steps of any one of the methods of claims 1 to 14.

16. A system comprising: processor; as well as A non-transitory computer-readable storage medium storing instructions which, when executed by one or more computer processors, cause the one or more computers to perform the steps of any one of the methods of claims 1 to 14.

Images