Introduction

In the youth of the Internet, web services were hosted on individual servers. The service was accessible via a public IP address that was configured on the server. With the rapid expansion of the technology, one server did not have enough resources to process all the requests that were coming from the clients. That was one of the first problems that engineers need to resolve.

The quick solution was to expand the server and create a cluster. This is a short time solution because you would need to do a lot of configurations to have a cluster that would have both of the members active.

One solution to the problem is a load balancer. It is configured with the public IP address of the web service, and it will respond to the requests from the clients. In the background, there is a pool of servers that have the same configuration and can process the requests.

Private Load Balancer

If the resources behind a load balancer are not accessed from the Internet, the private LB is the solution that will address both high availability and security concerns. The service will need a Private subnet that is AD specific or regional. In multi AD regions, if the service is provisioned in a regional subnet, if the AD that hosts the primary load balancer fails, there will be redundancy in a different AD for the service. The service will consume 3 IP addresses from the subnet: one for each load balancers and one virtual IP address. Currently, the IP addresses are not configurable, and the service will assign the next available IP addresses from the subnet. I prefer to have a predictable IP address for the LB, and I am creating a separate smaller subnet for the load balancer. In this way, I know that the service will have the second, third, and fourth IP addresses from the subnet (first usable IP address is reserved for the subnet cloud gateway).

Public Load Balancer

If the resources behind the Load Balancer are accessible from the Internet, there is a need for a Public Load Balancer. The service needs two Public subnets that are AD specific or one public regional subnet. In multi AD regions, if the service is provisioned in a regional subnet, if the AD that hosts the primary load balancer fails, there will be redundancy in a different AD for the service. Depending on the subnet type, the service will assign either one private IP address from each AD specific subnet or two IP addresses from the regional subnet.

There are certain things that you need to consider when designing your architecture:

1. Load Balancer type: Public or Private. This will indicate what subnets you will need.

    

2. Subnets types: AD specific or regional. This decision will dictate the fail-over scenario.

    

3. Shape. The shape of the Load Balancer can’t be changed dynamically. You need to stop the service and re-provision a new one with the correct shape.

    

Multi-Tier architecture

When you have multiple tiers in your architecture, Load Balancer will be deployed in different layers.: for the web tier, a Public Load Balancer will be used, for the application layer, a private subnet will be used.

OCI Load Balancer and a 3rd party network appliance

Some customers want to pass all traffic via a network appliance that can act as a firewall, IDS/IPS. The Network Appliance is in front of the Load Balancer and it will NAT the requests from the Internet to the virtual IP of the Load Balancer. This scenario is used by customers who want to have the same vendor on-premise and in the cloud. They are already knowledgeable in the features and management of the Network Appliance and they woluld like to have IDS/IPS bundled together with access logs.

Conclusion

Load Ballancer is a key component in any cloud architecture and a good design will help customers archive a high available service with a better security posture.