Dynamic bursting to a cloud service

Pexip Infinity deployments can burst into the Microsoft Azure, Amazon Web Services (AWS) or Google Cloud Platform (GCP) cloud when principal conferencing capabilities are reaching their capacity limits, thus providing additional temporary Transcoding Conferencing Node resources.

This provides the ability to dynamically expand conferencing capacity whenever scheduled or unplanned usage requires it. The cloud Conferencing Nodes instances are only started up when required and are automatically stopped again when capacity demand normalizes, ensuring that cloud provider costs are minimized.

You can also use the management API to monitor and manually start up your overflow nodes, if for example, you want to configure a third-party scheduling system to start up all of your additional capacity prior to a large conferencing event starting.

How it works

Dynamic bursting builds upon Pexip Infinity's standard location capacity overflow logic that defines which overflow location's nodes are used when a particular location reaches its capacity. The dynamic bursting functionality adds to this by automatically starting up those additional cloud nodes when a location is approaching full capacity, so that those overflow nodes will be available if required.

After you have deployed your overflow Conferencing Nodes in Azure, AWS or GCP, and enabled cloud bursting and configured your bursting threshold in Pexip Infinity, everything is then controlled automatically by the Management Node:

  • Whenever the available capacity in a system location containing your principal (always on) Conferencing Nodes hits or drops below your configured threshold, a Conferencing Node in its overflow location is automatically started up. That new node can then start handling any additional conferencing requirements if the original location reaches full capacity.
  • When an overflow Conferencing Node starts to fill up and its location reaches the bursting threshold, a further overflow node is started up, and so on.

  • When call levels subside and an overflow Conferencing Node is no longer hosting conferences and is no longer required, the node is automatically shut down again.

    This sequence of events is explained in more detail in a worked example.

Configuring your system for dynamic bursting

Dynamic bursting is supported on Conferencing Nodes hosted in Microsoft Azure, Amazon Web Services (AWS) or Google Cloud Platform (GCP). For specific configuration instructions for your chosen platform, see:

Configuring the bursting threshold

When enabling your platform for cloud bursting the most important decision you must make is the level at which to set the bursting threshold:

  • The bursting threshold controls when your dynamic overflow nodes in your cloud service are automatically started up so that they can provide additional conferencing capacity. When the number of additional HD calls that can still be hosted in a location reaches or drops below the threshold, it triggers Pexip Infinity into starting up an overflow node in the overflow location.

    For example, setting the threshold to 5 means that when there are 5 or fewer HD connections still available in a location, an overflow node will be started up.

  • When an overflow location reaches the bursting threshold i.e. the number of additional HD calls that can still be hosted on the Conferencing Nodes in the overflow location reaches the threshold, another overflow node in that location is started up, and so on.

    Note that the current number of free HD connections in the original location is ignored when deciding if the overflow location needs to overflow further — however, new calls will automatically use any available media resource that has become available within the original principal location.

  • The bursting threshold is a global setting — it applies to every system location in your deployment.
  • Note that it takes approximately 5 minutes for a dynamic node instance to start up and become available for conference hosting. If your principal deployment reaches full capacity, and the overflow nodes have not completed initiating, any incoming calls during this period will be rejected with "capacity exceeded" messages. You have to balance the need for having standby capacity started up in time to meet the expected demand, against starting up nodes too early and incurring extra unnecessary costs.
  • You can also manually start an overflow node (see the relevant instructions for AWS, Azure or GCP).

See Capacity planning for more information on call types and the relationship between Full HD, HD, SD and audio-only calls.

Deployment guidelines

System locations and Conferencing Nodes:

  • When configuring your principal "always on" locations, you should normally set the Primary overflow location to point at the bursting location containing your overflow nodes, and the Secondary overflow location should normally only point at an always-on location.

    Nodes in a bursting location are only automatically started up if that location is configured as a Primary overflow location of an always-on location that has reached its capacity threshold. This means that if a bursting location is configured as a Secondary overflow location of an always-on location, then those nodes can only be used as overflow nodes if they are already up and running (i.e. they have already been triggered into starting up by another location that is using them as its Primary overflow location, or you have used some other external process to start them up manually).

  • Typically you should assign all of your bursting Conferencing Nodes to a single overflow system location so that all of your main transcoding locations can make use of the same pool of cloud overflow nodes.

    However, if you expect a single conference to require more than three overflow nodes, then you could configure a second cloud overflow location (containing a different set of bursting nodes) and then configure half of your principal locations to overflow to the first cloud overflow location, and the other half of your principal locations to overflow to the second cloud overflow location. In this case, both overflow locations will act (start up and shut down nodes as appropriate) independently of each other.

  • We recommend that you do not mix your "always on" Conferencing Nodes and your bursting nodes in the same system location.
  • Cloud bursting nodes must be deployed as Transcoding Conferencing Nodes (not Proxying Edge Nodes).

Additional guidelines:

  • An overflow cloud bursting node is automatically stopped when it becomes idle (no longer hosting any conferences). However, you can configure the Minimum lifetime for which the bursting node is kept powered on. By default this is set to 50 minutes, which means that a node is never stopped until it has been running for at least 50 minutes. If your service provider charges by the hour, it is more efficient to leave a node running for 50 minutes — even if it is never used — as that capacity can remain on immediate standby for no extra cost. If your service provider charges by the minute you may want to reduce the Minimum lifetime.
  • Do not configure your call control system / DNS to route calls directly to your bursting nodes.
  • The Management Node requires access to the cloud platform's APIs to start and stop the bursting node instances. These requests can be routed via a web proxy if required.
  • A location can trigger a bursting node to start up only if there is some existing media load on that location. This is to ensure that incidents such as a temporary network interruption do not inadvertently trigger bursting.
  • No specific licenses are required for your bursting nodes, but you must ensure that your overall system has sufficient licenses to meet peak conference capacity demand.
  • Your cloud bursting nodes must all be running on the same cloud platform (Azure, AWS or GCP).
  • All log messages that are explicitly related to cloud bursting, such as starting up or shutting down overflow nodes, are tagged with a log module name of administrator.apps.cloudbursting. All other log messages related to those overflow nodes or the conferences they are hosting are reported in the same manner as per standard behavior.

This sequence of actions listed below shows how the process of starting and stopping overflow nodes is managed. It assumes an example scenario where:

  • the system is configured with a bursting threshold of 5
  • there is a single principal location (London) containing 2 "always on" Conferencing Nodes with a total location capacity of 40 connections
  • the principal location is configured to overflow to the cloud overflow location "Bursting Europe"
  • the "Bursting Europe" location contains 2 overflow bursting nodes, each with a capacity of 20 connections.
 Principal location: London Dynamic bursting activity Cloud overflow location: Bursting Europe
Action Call capacity remaining Overflow node A status Overflow node B status Call capacity remaining

1.  

 No conferences in progress 40 none Not running Not running  
2.   A conference starts and has 33 participants 6* none      
3.   1 more participant joins 5 Principal location threshold reached Node A starting    
4.     5 Overflow capacity becomes available Running   20
5.   5 more participants join 0 none ↓   20
6.   1 more participant joins 0 Call media handled by overflow node A

↓

   18*
7.   12 more participants join 0 All new participants handled by overflow node A ↓   6
8.   1 more participant joins 0 Overflow location threshold reached ↓ Node B starting 5
9.     0 Additional overflow capacity becomes available ↓ Running 25
10.   7 more participants join 0 All new participants handled by overflow nodes A and B ↓ ↓ 17*
11.   Conference ends 40 Overflow nodes remain available for further bursting if required ↓ ↓ 40
12.   A new conference starts with 25 participants 14* none ↓ ↓ 40
13.       Overflow node A is unused and has been running for 50 minutes Shutting down ↓ 20
14.       Overflow node B is unused and has been running for 50 minutes Not running Shutting down 0
15.   Conference ends 40   Not running Not running  

* A Conferencing Node reserves 1 HD connection for the backplane to other nodes in the same conference.

Note that if other conferences were running on any of the nodes in these locations, they would consume call capacity and bursting would be triggered in exactly the same way when the remaining capacity within the location reached the threshold.

Viewing cloud bursting status

Current bursting status

Go to Status > Cloud bursting to see an overview of the media load of your principal locations (that contain your "always-on" Conferencing Nodes), and whether your overflow nodes and locations are in use.

  • Any issues relating to your cloud bursting deployment will also be shown on this page.
  • The list of principal locations only includes those locations that are configured with a Primary overflow location that contains bursting nodes.

  • An approaching threshold message is displayed in the Available HD connections column for the principal locations when the number of available HD connections is less than or equal to the bursting threshold plus two.

    This message changes to bursting threshold reached when the number of available HD connections is less than or equal to the bursting threshold (and therefore overflow nodes are started up).

  • You can manually start any overflow nodes by selecting Start for the required node (the Start option is in the final column of the Cloud overflow nodes table).
  • The status page dynamically updates every 15 seconds.

Bursting history

Go to Status > Conferencing Node History to see all of the events (stop, start or running) that have been applied to overflow Conferencing Nodes and, where appropriate, the reason why the event was applied (for example if a node was shut down as there was no longer a need for the extra capacity).