Willing to know about Jitsi Videobridge AutoScale? We can help you.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how our Support techs assist with this query.

Jitsi Videobridge AutoScale

Basically, Jitsi Videobridge acts as the media server hence is the component that consumes the most resources.

Scaling becomes a necessity when the traffic starts to increase in your system.

The jitsi performance test shows that a single videobridge can handle 1000 streams on a c5.xlarge server at 550Mbps bitrate.

There are few platforms or methods to handle auto scaling.

1. Firstly, using AWS native services
2. Using Azure native services
3. Then, using Google Cloud native services
4. Using cloud provider servers with Kubernetes to manage the clusters
5. Also, using bare metal servers with Kubernetes to manage the clusters

Services from AWS

Mainly the following services would be used

AWS EC2: All the servers would be c5.xlarge  EC2 instances

AWS EC2 Autoscaling groups : These groups are responsible for handling the autoscaling functionality of the servers.

We can set scaling up and scaling down policies, create launch configurations, adjust parameters like max, min capacities of the group.

AWS SQS: Keeps the details of the performance of the servers as a message queue.

AWS Cloudwatch: Cloudwatch monitor the servers and fires alarms when the defined thresholds are reached.

High-Level Architecture of the system

Main components

• Jitsi-Meet – Web component of the system and all the videobridges from the group connect to this
• Jitsi Videobridge – Media Server of Jitsi which routes all the streams to clients
• Queue – A queue of messages which contain details of servers reaching threshold limits
• JVB monitoring – Monitors all JVB servers and fires an alarm if threshold limit is reached which is then used by the autoscaling group

The Setup

Install Jitsi-Meet on an EC2 Server

Install JVB in an EC2 server, create a script in JVB which will check with

SQS every minute Finally create an AMI of JVB.

Create a launch configuration in EC2 – This configuration would useto spin up new servers when scaling up.

For the configuration, use the AMI create in the previous step.

Choose the instance type as per your requirements.Please provide the other information accordingly.

Create an autoscaling group

1. Firstly, choose the above launch configuration
2. Then, choose the VPC and subnets that you are going to set this up
3. Select the group size keeping in mind the traffic conditions.
4. Skip the scaling policy for now
5. Finally, create a notification for all event types

• Go to the created autoscaling group and create a dynamic scaling policy.
• Select “Target Tracking scaling” and select Metric type as “Network out”.
• Give the threshold value considering the network bandwidth capabilities of the server.
• Create another policy with keeping the network out as 375000000 bytes.

Create a queue using SQS

• This queue will receive the instance IDs of servers that need to shutdown

The Process

• When the threshold limits defined in the scaling policy is reached it will either try to spin up or shut down servers.
• If it decides to shut down a server,
• It chooses a server randomly and tries to shut down it. But since we have set up a lifecycle hook it breaks this and puts the instance ID in the queue.
• Each server will check every minute with the SQS whether it needs to shut down by cross-checking the instance IDs of the queue.
• If the server’s instance ID matches with the instance ID on the queue it will execute a script to gracefully shut down. This will ensure that the instance will only shut down when the conferences are over.
• If it decides to spin up a new server/s,
• A new server/s will spin up based on the launch configuration.

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our skilled Support Engineers at Bobcares demonstrated about Jitsi Videobridge AutoScale