MidoNet L4 Load Balancer

Table of Contents


We introduced MidoNet and its highly distributed architecture in the previous blog.

The key point to highlight is the distributed control plane in MidoNet, unlike a centralized controller offered by other SDN solutions such as OpenFlow. By having the controller functions distributed to agents running on every hypervisor host, complex packet processing and flow translations could be done locally at the edge by leveraging the computation power of the hosts. The more you push to the edge, the more scalability you gain.

In addition to its scalability, MidoNet is also fully symmetric and all the agents have the exact same capabilities. This feature supports users to deploy scalable solutions that can dynamically adjust to the size and the type of traffic, and respond to frequently changing business requests on demand.

In this blog, we introduce one of the latest features of MidoNet that takes this approach even further—the Distributed Layer 4 Load Balancer (L4LB).

Like already existing layer 2 to layer 4 network functions in MidoNet, this newly introduced distributed L4LB is extremely scalable that helps users respond to business demands dynamically.

Now let’s take a look into more details!


Load Balancer functions for IaaS

We see load balancers being used everywhere in modern, highly scalable IT systems today. But not only in on premise systems, Load Balancer (LB) is one of the key features that users expect in a public IaaS cloud service because it works very well with Virtual Machines (VM).

In IaaS cloud services, you can launch as many VMs as you like, on demand. This model helps users to build and deploy elastic IT systems in a matter of minutes and has widespread need in fast moving industries and early startup companies. LB is actually a key component that can leverage these dynamically created VMs to serve bursty requests coming over the Internet. Users can launch VMs and hook them up with LB on the fly to handle more traffic and detach VMs and shut them down when the traffic gets smaller.

What are the key aspects needed for LB to implement such services? Can we build the service just by deploying off the shelf hardware LB appliances? You could but if you are looking for scalability, agility in terms of deployment and are concerned with the cost of the equipment, that’s probably not the best choice. Let’s now look into requirements that would be needed to implement LB services in IaaS cloud.

Firstly, the LB must support multi tenancy where every user shouldn’t be affected by what other users do. Although this is an obvious requirement and you might consider this to be a low hanging fruit, it’s not so easy to implement with existing hardware or appliance based solutions as they weren’t designed for IaaS cloud use case.

Secondly, LB must be highly scalable and elastic as the capacity required for each deployment differs significantly. The LB itself becoming a bottleneck of performance or a single point of failure (SPoF) must be avoided.

What about the LB that MidoNet offers? Unlike existing networking solutions, MidoNet has always been designed for IaaS cloud services and so is L4LB. This is great for cloud service providers who are looking to offer LB services as part of their offerings.

The supported features in MidoNet distributed L4LB are quite simple and straightforward: pseudo round robin algorithm to dispatch the traffic, TCP level health check of the targets, source IP stickiness/persistence. However, all of these features work natively on MidoNet which empower IaaS cloud services. Like already existing layer 2 to layer 4 network functions in MidoNet, the network function runs on commodity hardware which reduces both CapEx and OpEx largely, and are all distributed which eliminates SPoF and performance bottleneck from the system. The distributed architecture of LB also makes it highly scalable.


How MidoNet Distributed Layer 4 Load Balancer works

In the previous blog, we described how MidoNet works. The newly introduced L4LB is no different than the network functions that already exist in MidoNet, and therefore traffic would be handled following the same procedure.


When traffic from the Internet comes to the gateway nodes, MidoNet Agents running on the nodes simulate the virtual network topologies including the L4LB and forward the traffic to the backing targets i.e. destination VMs. Once the virtual network simulation is done in the agents, flows will be set in the datapath, and subsequent packets with the same signature would be handled quickly without going through the simulation. Unlike appliance based approaches, the agent simulates the LB function at the edge and forwards the traffic directly to the target without adding extra hops. This results in better performance of the network.

If you scale-up and add more gateway nodes, the gateway nodes behave as an active-active LB because the agents running on each node will behave exactly the same as described above. On the other hand, you could also remove the nodes and shrink the capacity of the LB dynamically because all agents have the same functionality.

The health status of target VMs is distributed to the agents. If one of the target VMs goes down, it gets removed from the healthy target list maintained within each agent. As a result, each agent stops forwarding the traffic to an unhealthy target VM. If there are existing sessions between agents and an unhealthy target, each agent removes existing flows in the node. When the target gets back to a healthy status, it would be appended to the healthy target list and each agent starts forwarding the traffic to it again.



In this blog, we introduced Distributed Layer 4 Load Balancer, which is one of the latest features supported in MidoNet. The greatest value of this features is that you could deploy highly scalable load balancer in your IaaS cloud. You could always scale up, scale out and even scale down whenever you like and in a matter of minutes. It frees users from existing expensive and inflexible solutions and you could always adjust the deployment dynamically responding to the amount of requests.

The Distributed Layer 4 Load Balancer was introduced in MidoNet v1.4 release in April, and it would be available in OpenStack/Neutron LBaaS (Load Balancer as a Service) API in the upcoming v1.5.1 schedule in August 2014.

Post Navigation