Blog

Modern business applications demand high performance and availability. It is increasingly common to deploy applications at multiple locations. Global server load balancing (GSLB) is a typical tool in such use cases. GSLB refers to the intelligent distribution of traffic across resources located in multiple geographies. These resources can be created at on-pre private data centers or hosted in public clouds like AWS or GCP.

1. GSLB Challenge for Cloud Private Network

In a traditional enterprise environment, applications are deployed on VMs with fixed IP addresses. These addresses are then configured as backend pool members in GSLB. In the world of cloud computing and DevOps, the Cattle model is preferred over Pets. Applications are deployed constantly to new VMs or containers during release cycles. Underlay infrastructures also need to scale up/down intelligently in response to workloads. Both scenarios lead to dynamic IP addresses.

Most application deployments on public clouds utilize L4 load balancer to support such elasticity. FQDN is provisioned automatically to be used for application access. One limitation of L4 load balancers is that they tend to be regional resources in pubic clouds. They need to work with GSLB to fulfill multi-region active/active or active/passive requirements.

Not all popular DNS/GSLB solutions support typical cloud deployment patterns. For example, geo-based DNS routing in AWS’s own Route53 only works for public domains. Another popular enterprise solution, F5’s DNS needs to work with LTM to support FQDN backend.

2. GSLB for AWS Private Workloads – Infoblox DTC

This blog presents a solution based on Infoblox DTC.

2.1 Configure Server or Pool in DTC

The first step is to create servers in DTC. In figure 2, the Domain Name option is used with a value of friendly FQDN of regional AWS load balancer. This option allows Infoblox DTC return specified FQDN as CNAME record to client. A server is normally intepreted as a single backend pool member in the context of traditional GSLB. In our example, the FQDN of foo1.aws.internal.example.com actually resolves to multiple IP addresses due to multi-AZ AWS load balancer. On the right-hand, health-check is configured that points to same regional load balancer.

2.2 Configure Topology Ruleset

The major design effort should focus on topology ruleset. DTC ruleset tells Infoblox server IP addresses to return based on the location of a client. In figure 3, two rules are specified. The first rule is based on the extensive attribute (EA) feature of Infoblox. Not shown in this blog, subnet 172.17.0.0/16 is tagged with EA attribute key value pair of Region/”us-east-1″. Supporting EA in topology rule is very powerful, especially for large enterprise customers. The second rule in Figure 3 belongs to Subnet type. It insructs Infoblox to return foo1-dtc-server for client DNS queries sourcing from 172.16.0.0/16,

Infoblox also supports an optional default rule. In case client location does not match any rule explicitly defined in the list, the default rule applies. In this example, foo1-dtc-server is used as the default destination to return.

2.3 Configure LBDN

Last step is to add LBDN and link it to desired FQDN. Under Load Balancing Method, select Topology from drop down. Then pick foo-ruleset-server in Topology Ruleset dropdown.

3. Traffic Flows

Finally, let’s review how traffic flows in both normal and failover scenarios.

3.1 Normal Scenario

The normal condition is defined as where resources in both regions are healthy to serve application requests. Let’s say a user on subnet 172.17.1.0/24 tries to connect to foo.internal.example.com. DNS query is sent to Infoblox. Based on client IP, Infoblox is able to match it to the first rule using EA attribute. Recall that 172.17.0.0/16 is tagged with key/value pair of Region/us-east-1. 172.17.1.x/24 falls in the range of 172.17.0.0/16. That rule tells Infoblox to use foo2-dtc-server as the destination. From the definition of foo2-dtc-server, CNAME record of foo2.aws.internal.example.com is returned by Infoblox to client.

After receiving CNAME, the client sends another DNS query to Infoblox. Make sure on Infoblox, you define subdomain that forward “.aws.internal.example.com” to AWS Route 53. Infoblox looks up foo2.aws.internal.example.com recursively toward Route53. Because Route53 has a A record defined for foo2.aws.internal.example.com that has alias to fooabc-1234567890.us-east-1.elb.amazonaws.com, IP addresses of AWS load balancer in us-east-1 are returned to client. Dig or nslookup to foo.internal.example.com should confirm multiple IP addresses in us-east-1.

3.2 Failover Scenario

In case resources in us-east-1 region become unavailable, Infoblox DTC would deem them “down” as the result of periodical health checks.

When Infoblox receives DNS request from 172.17.1.x/24 client, it again searches through topology ruleset. Even DNS source address still matches the first rule, there’s no healthy server anymore. DTC proceeds to the default rule and returns foo1-dtc-server. Applicantion client changes to send requests to load balancer/application in us-west-1.

A more resilient design is to use DTC pool. In figure 5, two pools are defined using Global Availability method. Both pools include foo1- foo1-dtc-server and foo2-dtc-server. The only difference is the order of the servers. In foo1-dtc-pool, fool1-dtc-server is preferred.

In topology ruleset definition, we change rule1’s destination to foo2-dtc-group. Now in case us-east-1 resources were to fail, foo2-dtc-group still has the remaining foo1-dtc-server to return. DTC does not proceed to the default rule.

3.3 Visualization

DTC provides intuitive visualization for pools and servers. You can also quickly make changes through visualization by clicking on individual components directly.

4. Support of Additional Deployment Patterns on Private Network

Above GSLB solution supports active/active patterns across two AWS regions. It can be extended to hybrid clouds where one of the regions is on-prem data center or another pubic cloud.

If active/passive pattern is desired, you can explore other GSLB Load Balancing Methods under DTC LBDN.