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.
This topic covers:
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.
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
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.
Current bursting status
Go to Conferencing Nodes), and whether your overflow nodes and locations are in use.to see an overview of the media load of your primary locations (that contain your "always-on"
- 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 Cloud overflow nodes table). for the required node (the option is in the final column of the
- The status page dynamically updates every 15 seconds.
Go to 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).to see all of the events (stop, start or running) that have been applied to overflow
- 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.
When configuring your "always on" locations, you must set the Primary overflow location to the bursting location containing your overflow nodes. (Automatic bursting, and the stopping and starting of overflow nodes only applies to the Primary overflow location; the Secondary overflow location can only be used for standard overflow i.e. to other "always on" nodes.) You should configure the Transcoding location as normal to the location that will initially handle the call media (before overflow/bursting is required).
- 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 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 main 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.
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 primary location (London) containing 2 "always on" Conferencing Nodes with a total location capacity of 40 connections
- the primary 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.
|Primary 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|
|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||Primary 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||
|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.