OpenVidu 2.20.0: High Availability in AWS

NEW FEATURES

OpenVidu Enterprise edition comes with beta support for a High Availability deployment, with replication of all nodes and load balancing for clients. It is made up of 2 different AWS Auto-Scaling groups, managing the 2 different types of nodes of OpenVidu’s Master-Worker architecture.

The main difference between a regular OpenVidu Pro deployment and a high availability OpenVidu Enterprise deployment is the replication of Master Nodes. In the image below, on the left a regular OpenVidu Pro deployment and on the right a high availability OpenVidu Enterprise deployment:

To the left, a regular OpenVidu Pro cluster. To the right, an OpenVidu Enterprise High Availability cluster. Replication of Master Nodes brings multiple advantages in terms of scalability and fault tolerance.

The replication of Master Nodes achieves two objectives:

  • In case of a Master Node failure the workload can be automatically distributed to other nodes, making the system fail-safe and preventing downtime upon a Master Node crash.
  • An OpenVidu Enterprise high availability cluster is able to handle more clients at the same time, as Master Nodes are no longer a bottle neck.

A more accurate architectural description is available in the next image. As can be seen, an AWS Load Balancer is used to evenly distribute the client load, and an AWS ElastiCache database is used to manage shared information between different Master Nodes. All Master Nodes may communicate with all Media Nodes. Two clients connected to the very same OpenVidu session will be connected to the same Media Node, but might be connected to different Master Nodes.

Detailed architectural diagram of an OpenVidu Enterprise High Availability cluster. AWS provides all of the required components.

Visit the official documentation to deploy your OpenVidu Enterprise High Availability cluster!

Individual recording for OpenVidu Enterprise with mediasoup

One of the limitations of using mediasoup with OpenVidu Enterprise is now fixed: INDIVIDUAL recording is already possible when using mediasoup.

New property “ip” for the Connection object

The Connection object now has an `ip` property with the IP of the client, just as OpenVidu Server sees it. This can help further identifying your final users. Of course, this property is also available in the official server SDKs openvidu-java-client and openvidu-node-client.

BUG FIXES

  • Recording: for OpenVidu deployments in AWS, the first time a COMPOSED recording was initialized inside a node, it could take a long time to return. The operation usually finished with an error. This has to do with the EBS volumes from the AMIs which are pulled down from S3 when data is read for the first time. Now the content is cached before the node starts, so the problem is fixed and the first recording starts as fast as any other.

Stay tuned for next iterations! You can follow us on Twitter and a Star in GitHub is always welcome :)

--

--

--

Easy videoconference in your web or mobile app

Love podcasts or audiobooks? Learn on the go with our new app.

PromQL tutorial for beginners

iPhone 12 vs Designers

How To Fix BLU Studio X9 HD Not Charging [Troubleshooting Guide]

Low-code Architecture for Any Application

What is DevEd?

Deploying a Prisma cluster to Kubernetes

Preventing “Denial of Service via Image Processor”

Wheel of Fortune: Building My First Ruby App

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
OpenVidu

OpenVidu

Easy videoconference in your web or mobile app

More from Medium

How to Deploy Next.js App to AWS EC2 in Production and Set up CI/CD with Github Actions

Next.js

NPM might be executing malicious code in your CI without your knowledge

Setup Vault and Enable OIDC using Google Oauth2

Do You Have a Strategy to Manage Open Source Risks in Web Applications?