One of the questions that we get from customers when we talk to them about load balancing is: “How does a DNS-based load balancer work with my existing load balancing appliances?”
Well, the simple answer is that your existing load balancing technologies—or what we call site load balancers—just don’t work well at the user edge. And today’s network edge is increasingly taking on a very critical role in connecting users to the digital content and services that they need to reach with performance, availability, and security. This is what’s driving a new approach to load balancing that starts at the edge—that point closest to the user.
The way that Oracle Dyn views this is that there are really two elements to a load-balancing architecture:
- The user edge is powered by DNS and steers user traffic to destination endpoints based on a availability of the endpoint, load-balancing parameters, performance rules, geographic rules.
- The site edge or local load-balancers are responsible for directing traffic to the most available compute or storage resource to service that request. The local rules take into account resource availability, load, session maintenance, and security.
In a “federated” system, like the one shown above, global load balancing (GLB) at the user edge works really well with your existing load balancing technologies at the site edge.
What Is This “Federated” Approach Anyway?
What do we mean when we talk about a federated architecture? It’s looking at global load balancing at the user edge and your load balancing appliances at the site edge, independently interoperating. This approach applies load balancing and traffic steering policies at the appropriate layer from the user edge to the host—whether virtual or physical—where the request is actually served.
Each one has unique strengths. Global load balancing at the user edge has a much broader, “big picture” view of the internet while site-based load balancers have the advantage of possessing a granular amount of detail about local resources, their availability, and their performance.
How Do These Load Balancers Fit Together?
So when do certain load balancing and traffic management policies belong at the user edge and not at your local load balancer? And how is that decision made? To answer those questions, let’s look at some of the policies at play.
Both types of load balancers have varying spans of control and different levels of asset knowledge. While site-based load balancers have far greater knowledge of the physical resources under their control, they have only a very narrow scope of visibility and control when it comes to the internet.
Global load balancers at the user edge have a much larger span of control, because of their far more extensive knowledge of paths between users and endpoints.
Policies, procedures, and perspectives
Now it’s time to look at which load balancers can best enforce certain traffic steering policies.
As you can see from the chart above, unless your load balancing begins at the user edge, you’re neglecting a critical piece of your traffic steering strategy—one that can have a negative impact on performance and reliability. Adding DNS-based global load balancing to a federated load balancing system yields key benefits, including:
- Ability to see “best path” connections between users and endpoints
- Better control the end-to-end user journey
- Insight into availability—before traffic is directed along a given path
Each class of load balancers has its place, but to get the full benefits of load balancing, look to a federated approach that brings together the best aspects of each.