Load-balancing

Load-balancing

Prerequisites

Objective

In this final session, we will scale our application to multiple instances and learn how internal and external services choose which instance to use once the application has been scaled.

Steps

Load-balancers decide which instance of an app internal or external services should use. With DC/OS, you have two different built-in load-balancer options: : Marathon-LB and Named virtual IPs. We have seen both before in the context of service discovery and especially marathon-lb when making app2 publically available. Now we will explore both options in more detail.

  • First, scale app2 to two instances: dcos marathon app update /dcos-101/app2 instances=2
  • Marathon-lb
    • Check app2 as before via http://<public-node>10000. When you do this repeatedly you should see the request being served by different instances of app2.
    • You can also check the Marathon-LB stats via http://<public-node>:9090/haproxy?stats
  • Named VIPs
    • We have seen named vips before for service discovery inside our cluster
    • SSH to the leading master node: dcos node ssh --master-proxy --leader
    • curl dcos-101app2.marathon.l4lb.thisdcos.directory:10000. When you do this repeatedly you should see the request being served by different instances.
  • Scale app2 back to one instance: dcos marathon app update /dcos-101/app2 instances=1

Outcome

We used two different methods to load balance requests for two different instances of our app.

Deep Dive

The two load balancing options in DC/OS offer different advantages and drawbacks that you should take into account when choosing one over the other

  • Marathon-LB is a layer 7 load balancer that is mostly used for external requests. It is based on the well-known HAProxy load balancer and uses Marathon’s event bus to update its configuration in real time. Being a layer 7 load balancer, it supports session-based features such as HTTP sticky sessions and zero-downtime deployments.
  • Named VIPS is layer 4 load balancer used for internal TCP traffic. As it’s tightly integrated with the kernel, it provides a load balanced IP address which can be used from anywhere within the cluster.

Furthermore, there are also other 3rd party solutions that can provide load-balancing on top of DC/OS.