Load balancing with HAProxy


#1

Hi,

We plan to have a deployment with the HAProxy in front of multiple shards. Each shard serves one geo region. We hope the HAProxy can distribute a meeting to different shard based on the geo location of the first participant.

However, we’re not sure if this is even possible, or if there’s better way to achieve what we want?

We known HAProxy can distribute a request based on the ip location, but the problem here is that each participant will have different ip address. How can we guarantee all the participants can be routed to the same shard.

Alternatively, HAProxy can also distribute the meeting base on the URL (i.e. meeting name) so that all the participants of the same meeting will be redirected to the same shard, but then we may end up putting users on a server that’s very far from them.

Any thoughts?

Thanks in advance!


#2

So the HAProxy needs to share a table of rooms. Every bosh connection has a ?room= parameter so you need to route calls to the same shard.

This is how meet.jit.si is working today, on the other hand if you want to use the geo-located logic and have better connectivity, you need to deploy the bridges to use octo https://github.com/jitsi/jitsi-videobridge/blob/master/doc/octo.md.
If you configure the system that way, clients will be using singling node on a shard where conference was initially created, maybe not in the same geo region, but then the bridge will be close to them, which is what matters for a video conference.


#3

Thanks for your quick response Damian!

I could be wrong but from what I read, I feel OCTO is relatively new and not very well documented at this point. We are not very confident if we can make it work for our production.

So we were thinking to keep it simple for now. If there’s a way to distribute meetings based on the first participant’s geolocation and somehow distribute the reset of the participants to the same shard, it’s acceptable for us if some of the participants use the bridge that’s not ideal for them. We were hoping to make the tradeoff here to simply the configuration. Maybe this is not doable with HAProxy, I don’t know… Any suggestions?

Also, is there a document on how to config HAProxy for jitsi?


#4

Octo is already running for months on meet.jit.si.
Without it you need all participants to be on the same shard, same jicofo, same jvb, there is no other way, that’s why octo was born.
There is no documentation for haproxy configurations.


#5

Thanks for response! It seems like octo is the only option then.

Even with octo, all participants will be on the same shard, same jicofo, right? Although what matter the most is the jvb.

Out of curious, since jitsi has existed for years before octo, how was load balancing done before? Or maybe the participants were just distributed randomly without considering the geolocation before octo?


#6

You just need a combination of the the two things that you mention – route existing conferences based on the URL, and route new conferences (saving the routing rule) based on the IP of the client. Or am I missing something?

Boris


#7

Thanks for replying Boris.

You are right. But how would haproxy know if a conference is new or an existing one? For example, A started a new call, B and C joined later. After a while them ended the call. Then D restart the same call from a different geo location than A. Can haproxy tell D’s request is for a new conference?


#8

Live conferences generate requests at least once every 60 seconds (depending on the BOSH timeout). HAProxy can timeout conferences that haven’t see requests for a while.

Regards,

Boris


#9

Great idea! We will look into this. Even with octo, I think this is also a good addition - try to keep the participants closer to the signaling-server as well. Thank you so much!