Handle peak SSL traffic with flexible Load Balancing and Network Load Balancer services
The Oracle Cloud Infrastructure Load Balancing service provides a proxy-based automated traffic distribution from one entry point to multiple servers reachable from your virtual cloud network (VCN) for TCP and HTTP traffic. The service offers a load balancer with your choice of a public or private IP address, and provisioned bandwidth.
The Oracle Cloud Infrastructure Flexible Network Load Balancing service (Network Load Balancer) automates traffic distribution from one entry point to multiple servers in a backend set. It supports distribution of TCP, UDP and ICMP traffic.
Combining the two patterns will allow for a massive scale of SSL connections while allowing offloading of SSL overhead to Load Balancing, eliminating the need for backend certificate distribution and decreasing the overall load on your backend resources.
The net result is being able to scale out to multiple flexible Load Balancers increasing available capacity exponentially while maintaining a single entry point to your workload.
Architecture
This architecture shows how you can horizontally scale SSL connections with a single endpoint using flexible Load Balancing service and Network Load Balancer.
The Network Load Balancer in a public subnet offers a public IP address to ensure applications are always available during peak demand. The Network Load Balancer balances incoming SSL connections to backend servers based on IP protocol data. The flexible load balancers in a private subnet are connected to a single instance pool with autoscaling to allow backend servers to flex and meet the demand. With this architecture, based on incoming traffic patterns, the available bandwidth scales up from the minimum as traffic increases or scales down from the maximum as traffic decreases.
The following diagram illustrates this reference architecture.
Description of the illustration horizontal-scaling-using-lbaas.png
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Instance pool
An instance pool is a group of instances within a region that are created from the same instance configuration and managed as a group.
- Autoscaling
Autoscaling enables you to automatically adjust the number of compute instances in an instance pool based on performance metrics, such as CPU utilization.
When the instance pool scales out or in, the associated load balancer's backend set is updated automatically.
- Network load balancer
The Oracle Cloud Infrastructure Flexible Network Load Balancing service is load balancer that also automates traffic distribution from one entry point, but is a non-proxied pass through that supports distribution of TCP, UDP and ICMP traffic.
Recommendations
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Network Load Balancer
Deploy a single Network Load Balancer in your public subnet while utilizing multiple load balancer instances in the backend.
- Oracle Cloud
Infrastructure Load Balancing service
Deploy your Oracle Cloud Infrastructure Load Balancing instances in a private subnet. It is recommend to perform SSL termination on your Load Balancing instances to reduce overhead on your backend servers.
- Instance Pool
All the Load Balancing instances are attached to a single instance pool configured with application specific configurations. This will ensure that all Load Balancing instances will have the same backend IP and Port combinations to allow Session Persistence across all balancers.
- Autoscale configuration
Make sure that you configure autoscaling to deploy a number of instances to meet your bandwidth and connection requirements in your private subnet.
- Source preservation
Configure source preservation on the Network Load Balancer to allow the Load Balancing Error and Access Log to reflect an accurate source client IP address.
- Logs
This architecture captures logs from the Load Balancing service and VCN flow logs. Each compute instance, Load Balancing and Network Load Balancer attached to a VCN has one or more virtual network interface cards (VNICs). Use VCN flow logs to troubleshoot security rules and to audit the traffic to and from the VNICs. You can also use Load Balancing Error and Access Logs to monitor.
- Access control
Use a combination of Security Lists, NSGs, and load balancer access control lists to follow the principle of least privilege necessary for providing the most granular level of access necessary to properly operate your application.
Considerations
When implementing this architecture, consider the following factors.
- Performance
Deploy a sufficient amount and sizing of Load Balancing instances to meet your bandwidth and connection requirements. Also configuring the proper scale-in, scale-out, and scaling limits in your autoscaling configuration based on your specific application requirements.
- Availability
Create scale-in, scale-out, and scaling limits based on your specific application requirements to ensure availability of your backend resources.
- Logs
Ensure you enable source preservation on the Network Load Balancer to ensure your load balancing error and access logs have the correct source IP.
- Session persistence
When Setting the Routing Policy on the Network Load Balancer you can select 2-5 tuple hashing to configure the level of persistence desired.
When enabling Load Balancing service Session Persistence, ensure that you use a common name for the load balancer Cookie Name and a common instance pool across all Load Balancing instances. This will allow for backend persistence across the entire environment.