OpenVidu Enterprise High Availability beta
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:
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.
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.
- 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.