Horizontal scaling with Multiple JVBs Vs. many standalone instances

From reading the tutorials and various posts here, I get the impression that the recommended approach for horizontal scaling is to scale up the number of JVBs within a shard (with option for multiple shards behind haproxy).

Apart from being able to leverage on Jicofo to handle load balancing, are there any other strong reasons to favour this over simply having lots of standalone instances (jitsi-meet + JVB in same host)?

In other words, any compelling reason why one might choose the setup on the left instead of the right?

By no means am I second guessing the expertise and experience of those behind the tutorials/posts. :bowing_man:t4: – I’m simply trying to fill in the gaps in my mental model of how everything ties together.

From an inexperience eye, the setup on the right has its appeal:

  1. A failure in any instance result in a failure of a smaller number of meetings. For the setup on the left, a failure in a JVB instance would have a same effect but a failure in the Jitsi Meet instance would take down half of all meetings running and potentially overload the other when all clients reconnect.
  2. Scaling standalone instances sounds easier than having to orchestrate the addition of JVB components in prosody on the Jitsi Meet instance.
  3. I’ve made an unquantified assumption that the CPU/Mem overheads of Nginx+prosody+jicofo is relatively small compared to JVB so replication across instances has minimal impact on resource ceiling.

P.S. I recognises that the HAProxy instances on the right will have more to do in terms of load balancing, and extra care need to be taken to ensure BOSH and /colibri-ws calls for the same room must all go to the same jitsi instance.

1 Like

Using fewer signaling nodes will make your life easier when it comes to big scale, where you need to monitor every instance and update the haproxy stick tables … If you are talking about 3-4 instances with full jitsi-meet it is ok.
But when it comes to hundreds of those, that will not work

Thanks @damencho, that makes sense.

My simple view also did not account for Jibri – I’m guessing having fewer signalling nodes makes scaling much more efficient since jibris can be allocated to rooms on different JVBs as needed, rather than having to maintain a pool per JVB.

Can you please guide us on how we can achieve 1st or A Type of scaling after doing a quick installation?
look like Jitsi is behind the proxy, so how we can handle SSL, what configuration changes we need to make in HAproxy to send the right user to a particular signaling server and then the right JVB? which ports need to open?

HA proxy stick sessions based on URL param room=…

This is all, rest you leave it to thew shard and jicofo …

  1. A node (Niginx + jitsi + jicofo + prosody ) has e.g domain name and SSL meet1.jit.si

  2. B node has meet2.jit.si domain

each has e.g 3 different JVBs so a total of 6.

Now how can we add HAproxy in front of it.

if I send normal users with meet.jit.si/room_name?jwt=xxx

Why do you use different domain names for nodes? Use the same for all

As emrah mentioned, you’d want to configure all your jitsi shards to the handle the same domain e.g. meet.example.com, but instead of having your DNS resolve that domain name to the IP of your nodes, you’d resolve to the IP of haproxy fronting the shards.

On the haproxy side, you would set your jitsi shards as backends so requests gets forwarded on the shards. It is also important to make sure users of the same meeting get forwarded to the same shard – this can be done by adding a stick table based on the room name. You should be able to find various examples of this in the forum, e.g. [Need Help] How to properly configure HAProxy with multiple shards