OpenVidu 2.15.0: Autoscaling

New features

Autoscaling

OpenVidu Pro has always had scalability as one of its main features. But until now, the responsibility for the management of the cluster fell on the users themselves, who had to actively monitor the status of their OpenVidu Pro clusters to add or remove nodes manually. In fact, we’ve observed that many users simply launch a new OpenVidu CE monolithic deployment whenever they need more capacity for more sessions, as this can be currently more convenient than managing an OpenVidu Pro cluster with REST API.

Of course this is not ideal. For that reason, with OpenVidu 2.15.0 we’re pleased to introduced OpenVidu Pro Autoscaling. Now you can let OpenVidu Pro decide when should the cluster grow or shrink according to CPU load. This way you can forget about overloading your system and you can also have the price to pay at any moment adjusted in the most optimal way.

We have added a new Autoscaling section to OpenVidu Pro documentation. We invite you to take a look to it: Autoscaling

OpenVidu Pro advanced autoscaling algorithm will always make the best decision to keep your cluster at its most optimal size

OpenVidu Pro 2.15.0 Autoscaling feature is considered to be in preview phase. What this means is that there could potentially be some bugs affecting its behavior. We recommend some caution in its activation.

Screen sharing in Safari 13

Now Safari users can share their screen as long as they are using Safari ≥ 13. This is great news for lots of people! Available for both OpenVidu CE and OpenVidu PRO.

Vue.js tutorial

OpenVidu tutorials have a new member in their family. Thanks to @Ninjak now you have available a simple Vue.js tutorial. We cannot be more proud of this image below, demonstrating the versatility of OpenVidu in the client side:

Composed quick start recording

OpenVidu recording service has always offered 2 different modes of recording:

  • INDIVIDUAL: media streams are recorded individually in their own files.
  • COMPOSED: media streams are recorded together in the same file in a grid layout. Users can build their own custom layouts with HTML and JS.

INDIVIDUAL recording is very efficient, but lacks the potential of building the recorded files in real time using custom designs. Can be done later in a different process, but of course this is extra work. COMPOSED mode is very powerful, as you can immediately obtain the final desired result just after stopping the recording. But this requires more CPU power per active recording.

Besides, COMPOSED recording requires OpenVidu to launch, manage and drop a recording module during the lifecycle of each recording. This process can make starting COMPOSED recordings a process with a somewhat slow response time. This is where the brand new COMPOSED_QUICK_START mode comes into play: some use cases may benefit of configuring OpenVidu Sessions with this recording mode if they need the recordings to start as quickly as possible, paying as a price a higher CPU usage during the whole lifecycle of the session.

COMPOSED_QUICK_START recording mode is available for both OpenVidu CE and OpenVidu PRO. You have further information in OpenVidu Docs: Composed quick start recording

New OpenVidu deployment commands

You can now run the following commands in your OpenVidu (CE or PRO) installation folder:

  • ./openvidu version : will print out in the terminal all of the installation details of your deployment.
  • ./openvidu report : will log in a file a complete report of the status of your deployment. This file can be very useful to quickly gather all of the information of your deployment in a single place.

Better Elastic stack integration

There are 2 major changes in the way OpenVidu Pro takes advantage of its Elastic stack:

  • Logging: now you can directly review the logs of many of OpenVidu processes from the Kibana dashboard itself, using the “Logs” view. Including redis, coturn, openvidu-server and kms logs.
  • New OpenVidu Clustering dashboard: the new autoscaling feature has brought the need to be able to review the behavior of the cluster and its load over time. For now you can quickly check the CPU load of any Media Node over time.
New clustering Kibana dashboard showing your Media Nodes CPU

Bug fixes

This release brings tons of bug fixes that are worth mentioning.

  • OpenVidu deployment: if the ports of the machine hosting OpenVidu Server weren’t properly closed, the internal Redis database could be easily attacked, allowing external connections that hackers exploited for crypto mining. Some users reported that the CPU usage of the machine was higher than expected, and this was finally identified as the proble. Now the databse is by default password-protected with your OpenVidu secret, so even in the case of forgetting closing non-necessary ports, your Redis database will be secure.
  • Recording: possible concurrent exception for recordings configured with ALWAYS and INDIVIDUAL properties when users published very close in time, resulting in some streams not being recorded. Fixed now. Issue 479.
  • Recording: cancelation of automatic stop of recordings wasn’t working for ALWAYS recordings. Recording would stop even if the conditions to keep the recording alive were met. Now recordings started by ALWAYS mode are only automatically stopped when expected.
  • Webhook: OpenVidu Webhook by default will work in background. Slow endpoints won’t now affect OpenVidu Server responsiveness, which was being delayed when the configured endpoint didn’t respond immediately.
  • Kurento 100% CPU usage: a critical bug was found in the past version of Kurento (the internal media server used by OpenVidu). This may cause a spike of CPU when closing many media endpoints at the same time (for example closing a session with lots of participants), which could leave the CPU hanging at 100% usage level and not being able to recover. This was fixed in Kurento release 6.14.0, the one being used by OpenVidu 2.15.0. You can better appreciate the before and after in the graph below:
  • Autorenewal of OpenVidu certificates: when using the Let’s Encrypt deployment option, the automatic renewal of auto-generated certificates could fail due to a misconfiguration. Now it doesn’t.
  • openvidu-browser: Subscriber object wasn’t changing the Stream object audioActive and videoActive status when calling subscribeToAudio or subscribeToVideo (PR 443)
  • openvidu-browser: Samsung Internet support fix. Some installations of the browser were treated as non-supported. Ironically the browser was being successfully supported in non-Samsung devices, but when the browser run on Samsung phones or tablets, openvidu-browser treated them as non-supported. This is now fixed.
  • openvidu-browser: iPad Pro support. Some users reported problems when using openvidu-browser library on iPad Pro devices (490). This has been addressed.
  • Ionic iOS: ionic iOS: openvidu-browser has been updated to match the new iosrct release (6.0.12) which included the fix of the issue 442. Ionic iOS can now use the modern WebRTC API for adding tracks. Updating iosrtc to 6.0.12 is required with openvidu-browsers 2.15.0.
  • openvidu-angular: good practice with BrowserModule and BrowserAnimationModule. Now these import must be in the main app (1086)
  • openvidu-node-client: didn’t allow configuring an OpenVidu Server hostname with plain HTTP protocol (was always forcing HTTPS). For a Node application deployed in the same host as OpenVidu, plain HTTP can be a valid option to connect openvidu-node-client to OpenVidu Server. Now with 2.15.0 this is possible.
  • OpenVidu Pro: property OPENVIDU_RECORDING_PATH now can be changed. Before 2.15.0 a limitation was forcing this property to remain with its default value.
  • OpenVidu Pro: empty recording folders in Media Nodes were being accumulated. Now they are properly cleaned up after the recorded files have been downloaded by OpenVidu Server Pro Node.
  • OpenVidu Pro: a critical bug when deleting session history entries in OpenVidu Inspector has been fixed. Before, if Sessions where being initialized with the same customSessionId repeatedly over time, deleting the history entry of one of them would delete also the rest of entries belonging to different Sessions with the same customSessionId. Now this doesn’t happen.
  • OpenVidu React Native support: many dependencies have been updated, fixing important bugs. Including react-native-webrtc to latest version (1.75.3), React version in openvidu-react-native tutorial (from 16.8.6 to 16.13.1) and React Native version also in openvidu-react-native tutorial (from 0.60.5 to 0.62.0).

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