udp traffic with Iperf for haproxy

user2567806 picture user2567806 · Jul 6, 2015 · Viewed 15.7k times · Source

I'm working on my personal project on "performance evaluation" of Haproxy using Docker Container. I'm programming with Python and uses iperf for traffic generation.

I created several Docker containers as clients and servers. The clients are supposed to send udp traffic to servers via Haproxy container which acts as a load balancer.

The issue is when I try to send udp traffic from clients to servers, Haproxy refuses the connexions. I did not find in the official documentation how to bind or listen to UDP port.

Thank you in advance for your reply.

Here is a copy of my haproxy.cfg.

global quiet nbproc 4 daemon listen tcp_haproxy 172.17.4.230:5001 balance roundrobin server server0 172.17.4.227:5001 server server1 172.17.4.228:5001 server server2 172.17.4.229:5001

Answer

helmbert picture helmbert · Jul 6, 2015

As I read it, this question is more about UDP load balancing than Docker. Please feel free to correct me if I misread the question.

You probably won't like this answer, but here goes. HAProxy does not support UDP. The official homepage describes HAProxy as TCP and HTTP proxy explicitly (by implication, this means "no UDP"). There are also this question on ServerFault regarding the topic of UDP load balancing, which also discusses and quickly dismisses HAProxy.

Since I don't like "that's not possible, deal with it" as an answer myself, let's have a look at alternatives.

  1. Some resources that ask about UDP load balancing end up recommending IPVS as load balancer. It's part of the Linux kernel, which makes it a bad solution if you're looking for something based on Docker. If that's not a deal breaker for you, there a short example on the Wikipedia page that can be adjusted to your scenario with three UDP servers:

    ipvsadm -A -u 172.17.4.230:5001 -s rr
    ipvsadm -a -u 172.17.4.230:5001 -r 172.17.4.227:5001 -m
    ipvsadm -a -u 172.17.4.230:5001 -r 172.17.4.228:5001 -m
    ipvsadm -a -u 172.17.4.230:5001 -r 172.17.4.229:5001 -m
    
  2. A quick Google search turns up alternative open-source solutions like Pen. Might also be worth a look?

  3. Sure you can't use TCP instead? ;)