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.
We listen on the basic web ports, 80 and 443. We use HTTP and HTTPS respectively. We don’t have any client affinity. We point the endpoint groups to the relevant ALBs in each region.
For health checks we are using a basic health check endpoint which reports failure if the ALB cannot access any servers registered with it.
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)
I see thanks @damencho
What is the reason for your using global accelerator?
my naïve understanding was that you can speed up the data compared to public internet.
I’m not so familiar with the specifics, bit it gives you the closest server by region and you can use it to have more people in a certain region or turn off completely a region.
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.
@Aaron_K_van_Meerten thanks for the reply.
You mentioned that you do your own routing. How is this done. It will be interesting to understand how it is done on aws.
Also how do you access the health of the resources and their load. Is it something that you do realtime? What framework do you use for this.
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.