Hi all,
I want to build jitsi for multiple region.This is the network topology.
As you see,I will assign the servers to different shards.Shard1 will be deployed in Region_A,and Shard2 will be deployed in Region_B.There will be a Jitsi Meet Server(webserver,prosody,jicofo) and several JVBs in each shard.For a purpose, I want people in different regions to video chat in the same conference.
Is this network topology correct?I need your suggestion.
You just need one HAProxy (using sticky tables) in front of the Shards. The HAProxy does the loadbalancing between the Shards and with the sticky tables, directs participants to the right Shard/meeting.
Thank you for your suggestion!
@Freddie is right, only one HAProxy will do.
Just for the sake of completeness or if someone else is reading this later, let me mention that if you need to have a failover for the HAProxy service itself, you can always put 2 (or more) Haproxies. Just make sure to add them one another in the “peers” section of their configs, so that they sync up, and then add a DNS balancing over their IPs. They will sync their stick tables and as far as Jitsi is concerned, they will act as one. This adds failover, and also some (geo) load balancing (although the load there shouldn’t be a huge trouble, it’s not media).
@Freddie @yasen I have a new question here 
If Tom from Region_A created a conference , and John from Region_B joins the same conference through url link Tom shared,which JMS will John access?
If he accesses JMS in Region_B,will he join the conference Tom created?
haproxy needs to be sticky on room name, so John will connect to Region_A. Otherwise they’ll be in two different conferences (due to being on different shards) with the same name.
Note that you can also extract the JVBs out of the shards, and deploy them as their own clusters.
For very large deployments this can give you the flexibility to expand the regions you have JVBs in, without needing to deploy full shards, since media is more sensitive to latency than signalling. When you have multiple shards in the same region (for handling larger signalling load), doing it this way also lets you scale signalling and media completely independently.
JVB supports connecting to multiple XMPP servers, so you can directly configure your JVBs to connect to multiple shards, but a better way is to have a set of dedicated “backend” prosody instances, which handle shard ↔ JVB communication, so you can add/remove shards and add/remove JVBs without needing to reconfigure anything.
Thank you for your suggestion!
