Increasing Resiliency With Load Balancers

A Load balancer is one of the most critical components of cloud network deployments.  Over the years, this feature has become fundamental to most networking services. One of the primary use-case for load balancers is to provide redundancy and reliability for applications by sharing traffic across multiple back-ends.  A load balancer distributes user traffic across multiple instances of your applications. By spreading the load, load balancing reduces the risk that your applications experience performance issues.  

Google Cloud Load Balancing is a fully distributed load balancing solution that balances user traffic (HTTP(s), HTTPS/2 with gRPC, TCP/SSL, UDP, and QUIC) to multiple backends to avoid congestion, reduce latency, increase security, and reduce costs. It is built on the same frontend-serving infrastructure that powers Google.com, supporting millions of queries per second globally with consistent high performance and low latency.  Providing the highest reliability is a core tenet of Google Cloud Load Balancers.  Google is constantly investing in the core engineering underlying our Cloud Load Balancers, with the intent to continually find ways to improve overall reliability even further. 

Google Cloud Load Balancers provide reliability through health checks of backends and redirecting traffic to healthy systems. Many of the reliability capabilities are natively built into the foundation of our Load Balancers, so automagically get the significant reliability capabilities Google has engineered into our Load Balancers. However, there are some options that are available to you to customize your Cloud Load Balancer configurations and architectures for your workloads. The reliability options suggested here are optional, and are offered as a means to tailor Cloud Load Balancer deployments for specific use cases. 

Specifically, we will be reviewing two recent advancements that can increase overall Cloud Load Balancer reliability for your workloads: 

1. Additional sharding built into our Global External Load Balancer

The first advancement is built into our next generation Global External Load Balancer. This load balancer includes additional sharding as part of its core architecture. Sharding within the Load Balancer delivers a high degree of reliability and enables higher scalability. Sharding also provides tenant isolation, protecting your workloads against outside issues that may occur. There is nothing for you to enable this ability as it is built into our fully managed solution. For customers using our previous Classic Global External Load Balancer, you may consider upgrading to our latest version to take advantage of these additional reliability improvements. 

2. Using Regional External Load Balancers as a failover option

The second recent advancement comes with the launch of our new Regional External Load Balancer which can be used to increase the overall reliability profile of a deployment even further. Our Regional load Balancers are independent and isolated from Global Load balancers. The Global Load Balancers have very high reliability and availability built-in. But for users that prefer redundancy at every level of their architecture, Regional Load Balancers can be used as a failover option for our Global External Load Balancer. In this case if an outage is detected, typically by using a DNS solution with a health-check option, your traffic can be redirected to one of your Regional Load Balancers.  The below diagram depicts the capability:

To configure a Regional External Load Balancer as a failover option, we recommend:

1. Using our next generation Global External Load Balancer for your primary traffic, as this latest version of our External Load Balancer has the most compatibility with our Regional External Load Balancers.
2. Set up Regional External Load Balancers in the regions you would like to fail traffic over to. You may set up your Regional External Load Balancers wherever they are most convenient for your end-user traffic to be served from. 
3. Configure any DNS solution that supports an Active or Passive health check for your Global traffic. If an outage is detected, configure your DNS to spill traffic into your Regional Load Balancers.
4. It is also a good idea to send a trickle of traffic through the Regional Load Balancer even when an outage is not occurring to assure traffic is being handled correctly in case of an outage. 

It is also good to note that even if you only use our Regional Load Balancers to handle your everyday traffic, and do not use a Global Load Balancer, you can still use Regional External Load Balancers in other regions to act as a failover option. 

It is also a good idea to ask your Google Account Representative about reserving capacity on Regional External Load Balancers, so you have the capacity you need reserved in case it is needed if a failover event does occur. 

And to learn more about our Google Cloud Load Balancers, we invite you to explore our Load Balancer capabilities further or try it out yourself with a tutorial.

By Prakash Daga, Product Manager
Originally published at Google Cloud

Source: Cyberpogo