Create a public Load Balancer

Implementing Redundancy with Multiple Public Subnets

In our ongoing series on designing and implementing real-world network architectures, today’s focus is on building a load balancer. But before we delve into the technical details, let’s take a moment to observe a subtle yet crucial change in the image we’ve been working with. You’ll notice the term “public subnets” is now plural. Why the shift?

Understanding Load Balancer Redundancy

Recall from our OCI lesson on load balancer that ensuring high availability necessitates redundancy. When deploying a load balancer within a single availability domain subnet, it’s imperative to create a secondary subnet for hosting a backup load balancer. While you interact primarily with the active load balancer, a hidden backup counterpart operates seamlessly, ready to take over if needed.

Configuring Additional Subnets for Redundancy

To achieve this redundancy, we must add a third subnet within another availability domain—either two or three, with the latter being our choice. This additional subnet, designated solely for the load balancer, won’t be visually represented but is essential for bolstering availability.

Step-by-Step Configuration Process

Let’s walk through the configuration steps:

1. Accessing the Console: Log in to the OCI console and navigate to the Networking section.
2. Selecting the Virtual Cloud Network (VCN): Choose the appropriate VCN where the load balancer will reside.
3. Creating the Subnet: Within the VCN settings, navigate to the subnets section and proceed to create a new subnet. We’ll name it “accs LP subnet.”
4. Configuring Subnet Details: Ensure the subnet is availability domain-specific, opting for availability domain 3 in this instance. Define the CIDR block as 10.0.3.0/24, and maintain the settings as a public subnet with the default security list.

Deploying the Load Balancer

Now equipped with the necessary infrastructure, let’s proceed to create the load balancer:

1. Naming the Load Balancer: We’ll name it “web load balancer,” reflecting its role in fronting the web servers.
2. Specifying Addressing and Bandwidth: As a public-facing balancer, its address will be ephemeral. Bandwidth options range from 100 megabits to 1000.
3. Configuring Listeners: Though backend servers aren’t currently in place, we configure a listener on port 80 for HTTP traffic. We designate this listener as “HTTP.”

Completing the Setup

With the load balancer configuration finalized, we’re prompted with a high-risk alert due to the absence of backend servers for health checks. However, this sets the stage for our next lesson, where we’ll focus on creating and integrating the web servers.

Conclusion

In this session, we’ve laid the groundwork for a resilient network architecture by implementing redundancy through multiple public subnets. Stay tuned for our next installment, where we’ll continue building upon this foundation by integrating backend servers and enhancing the functionality of our load balancer.