Dynamic bursting to a cloud service

Pexip Infinity deployments can burst into the Amazon Web Services (AWS) or Microsoft Azure cloud when primary 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, which is used to define 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 AWS or Microsoft Azure, and enabled cloud bursting and configured your bursting threshold in Pexip Infinity, everything is then controlled automatically by the Pexip Infinity Management Node:

• Whenever the available capacity in a system location containing your primary (always on) Conferencing Node hits or drops below your configured threshold, a Conferencing Node in a system location containing overflow Conferencing Nodes 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 reaches its own 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 Amazon Web Services (AWS) or Microsoft Azure. For specific configuration instructions for your chosen platform, see:

• Configuring dynamic bursting to the AWS cloud
• Configuring dynamic bursting to the Microsoft Azure cloud

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 are not taken into account when seeing if the overflow location needs to overflow further — however, new calls will automatically use any available media resource within those original primary locations that has become available.

• 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 Conferencing Node instance to start up and become available for conference hosting. If your primary 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 or Azure).

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

Viewing cloud bursting status

Current bursting status

Go to Status > Cloud bursting to see an overview of the media load of your primary 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 primary 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 primary 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).

Deployment guidelines and additional information

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

• Typically you should assign all of your bursting Conferencing Nodes to a single overflow system location so that all of your primary 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 primary locations to overflow to the first cloud overflow location, and the other half of your primary 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.

• Do not configure your call control system / DNS to route calls directly to your bursting nodes.
• 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.
• You cannot use both AWS and Microsoft Azure cloud bursting nodes in the same deployment.
• 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.