Some limitations have required us to use both Route53 and global accelerator in combination:
Global Accelerator isn’t available in all regions, so we continue to use latency based routing for those regions
It’s only IPv4, so all IPv6 traffic still uses latency based routing
The switch for us was a single step, as we already used ALBs in each region to terminate SSL and route to resources within the region.
So enabling global accelerator was as simple as pointing a new accelerator to each region and including the ALB from that region as the target. From there all our traffic flows as usual. Then we simply advertise the global accelerator IPs instead of the ALB ips from Route53.
I am curious to know the reason you are using aws global accelerator. Does the vanilla jitsi installation without global accelerator not give good video/audio experience (latency/jitter) ?
If yes, how did you realize that the experience is not good. Did you talk with other participants in the meeting and/or did you collect latency/jitter stats without global accelerator and decided that vanilla installation does not provide good experience to participants?
I am struggling with understanding the experience and stats. At what point in metrics/stats of latency and jitter should I assume that the experience is not good (assuming that there is no way to get feedback from participants) . Are there any software to emulate 2 or 5 or 10 or 50 connections in a single jitsi meeting to know the performance.
Lastly is there any solution other than aws global accelerator that can be used?
Also how does zoom solve this problem? Do they use global accelerator (or should I say - did they use global accelerator before their latest contract with aws recently?) Or do they have dedicated terabytes/petabytes of bandwidth between their data centers available to short circuit the open internet (the way global accelerator does)
damencho is in essence correct. In our deployment we’re using the global accelerator for our http(s) ingress only. This allows us to direct traffic to resources closest to the user. From there we do our own routing to the eventual prosody where the user joins a conference.
The benefit to us is also as damencho said, we can more easily steer traffic between various resources and regions based on their health or current load. We haven’t seen a significant speed increase between users connecting via global accelerator vs. traditional DNS, but since that’s not why we’re using it, that hasn’t been measured very deterministically either.
We use a mesh of HAProxy nodes at our edge, which own the mapping between a room name/URL and a specific shard where the prosody, jicofo, etc reside. We then direct users to the nearest HAProxy to them geograpically (or latency-wise at least). Then once they hit our HAProxy node, they are proxy’d to the appropriate shard. Hope this helps!
The load is balanced via haproxy load balancing algorithms. We use an haproxy agent on each shard, which adjusts the weighting that the HAProxy uses when assigning conferences to new shards, based on the participant count on each shard.