F5 DNS Load Balancer Cloud Service provides a global server load balancing (GSLB) solution offered in the cloud as a service. DNS Load Balancer allows you to create individual load balancing services for your apps and websites, providing intelligent distribution of traffic across server resources located in multiple geographies for better speed and reliability. It does this based on Load Balanced Records (LBRs) that hold the top-level information on how the load balancer is to operate. The LBR allows you to specify which hosts you are load balancing, as well as the rules to use to select the best DNS server for each end-user request.
As traffic comes in, the DNS Load Balancer will look at each incoming request and choose an IP endpoint to service that request, based on the origin of the incoming request, the configuration of the IP endpoints, and the status or health of each IP endpoint. To setup a load balancing solution, there are a few steps you’ll go through. First, the load balancer must understand the health of each IP endpoint to make sure it can service requests, so you will assign monitors to the IP endpoints to make that possible. Next, you will likely want to create pools of IP endpoints allowing you to prioritize groups of IP endpoints based on criteria or a load balancing strategy. Next you’ll create regions to categorize incoming requests. Your last step will be to define how requests from various regions will be distributed between the pools you have created. Here are two examples of possible load balancing strategies.
Geography traffic routing example:
This example routes traffic based on request origin and pool location. Looking at the two proximity rules, all requests from Europe will go to the EU pool because it has a higher score. Conversely, all requests from a non-Europe location will go to the global pool because those are not covered by the EU pool’s region. You might choose this strategy to help satisfy Europe’s GDPR. You might think of these two proximity rules as the following logical statement: If the request is from Europe, then send it to the EU Pool; otherwise, send it to the Global pool.
Disaster recovery example:
This example routes all traffic to a primary pool, but if the primary pool should go off-line, then all traffic would be routed to the secondary pool. This happens because both the primary and secondary pools service requests from the same region, but the one with the highest score (the primary pool) will service the request. However, if all endpoints at the primary pool become unable to service requests, then that entire pool goes offline and DNS Load Balancer starts sending requests to the secondary pool. Thus, the secondary site is only used as a backup for a disaster at the primary site or other situations like routine maintenance of the site.