Configuring dynamic bursting to the AWS cloud

Pexip Infinity deployments can burst into the Amazon Web Services (AWS) cloud when primary conferencing capabilities are reaching their capacity limits, thus providing additional temporary Conferencing Node resources.

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

For complete information about dynamic bursting, see Dynamic bursting to a cloud service.

Configuring your system for dynamic bursting to AWS

These instructions assume that you already have a working Pexip Infinity platform, including one or more primary (always on) Conferencing Nodes in one or more system locations. These existing Conferencing Nodes can be deployed using whichever platform or hypervisor you prefer.

Firewall addresses/ports required for access to the AWS APIs for cloud bursting

Access to the AWS APIs for cloud bursting is only required from the Management Node.

The Management Node always connects to destination port 443 over HTTPS.

DNS is used to resolve the AWS API addresses. Currently, Pexip Infinity uses the "Amazon Elastic Compute Cloud (Amazon EC2)" DNS FQDNs listed at http://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region but this may change in the future. An exception is if you are using GovCloud, where ec2.us-gov-west-1.amazonaws.com is used instead.

Setting up your bursting nodes in AWS and enabling bursting in Pexip Infinity

You must deploy in AWS the Conferencing Nodes that you want to use for dynamic bursting, and then configure the Pexip Infinity location containing those nodes as the overflow destination for the locations that contain your primary (always on) Conferencing Nodes:

  1. In Pexip Infinity, configure a new system location for media overflow e.g. "AWS burst", that will contain your bursting Conferencing Nodes.

    (Note that system locations are not explicitly configured as "primary" or "overflow" locations. Pexip Infinity automatically detects the purpose of the location according to whether it contains Conferencing Nodes that may be used for dynamic bursting.)

  2. In AWS, set up a user and associated access policy that the Pexip Infinity Management Node will use to log in to AWS to start and stop the node instances.

    See Configuring an AWS user and policy for controlling overflow nodes for more information.

  3. Deploy in AWS the Conferencing Nodes that you want to use for dynamic bursting. Deploy these nodes in the same manner as you would for "always on" usage (see Deploying a Conferencing Node in AWS), except:

    1. Apply to each cloud VM node instance to be used for conference bursting a tag with a Key of pexip-cloud and an associated Value set to the Tag value that is shown in the Cloud bursting section on the Platform > Global settings page (the Tag value is the hostname of your Management Node).

      This tag indicates which VM nodes will be started and shut down dynamically by your Pexip system, and relates to the access policy document configured in the previous step.

    2. When adding the Conferencing Node within Pexip Infinity:

      1. Assign the Conferencing Node to the overflow system location (e.g. "AWS burst").
      2. Disable (uncheck) the Enable distributed database setting (this setting should be disabled for any nodes that are not expected to always be available).
    3. After the Conferencing Node has successfully deployed, manually stop the node instance on AWS.
  4. In Pexip Infinity, go to Platform > Global settings > Cloud bursting, enable cloud bursting and then configure your bursting threshold, minimum lifetime and other appropriate settings for AWS:

    Option Description
    Enable bursting to the cloud Select this option to instruct Pexip Infinity to monitor the system locations and start up / shut down overflow Conferencing Nodes hosted in your cloud service when in need of extra capacity.
    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.

    See Configuring the bursting threshold for more information.

    Tag name
    and
    Tag value

    These read-only fields indicate the tag name (always pexip-cloud) and associated tag value (the hostname of your Management Node) that you must assign to each of your cloud VM node instances that are to be used for dynamic bursting.

    In some circumstances the Tag value may auto populate as "unknown" instead of the hostname, in which case you should also use "unknown" on your cloud VM node instances.

    Minimum lifetime 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.
    Cloud provider Select AWS.
    AWS access key ID
    and
    AWS secret access key
    Set these to the Access Key ID and the Secret Access Key respectively of the User Security Credentials for the user you set up in the AWS dashboard within Identity and Access Management in step 2 above.
  5. Go to Platform > Locations and configure the system locations that contain your "always on" Conferencing Nodes (the nodes/locations that initially receive calls) so that they will overflow to your new "AWS burst" location when necessary.

    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).

    We recommend that you do not mix your "always on" Conferencing Nodes and your bursting nodes in the same system location.

Configuring an AWS user and policy for controlling overflow nodes

Within AWS you must set up a user and an access policy to be used by Pexip Infinity to start up and shut down the Conferencing Node overflow instances:

  1. From the AWS management console, select IAM (Identity and Access Management).
  2. Set up the access policy for the overflow node instances:

    1. Select Policies and then Create policy.
    2. Select the JSON tab and copy/paste the following text:

      Copy to clipboard
      {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Action": [
      "ec2:Describe*"
      ],
      "Effect": "Allow",
      "Resource": "*"
      },
      {
      "Action": [
      "ec2:StartInstances",
      "ec2:StopInstances"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
      "StringEquals": {
      "ec2:ResourceTag/pexip-cloud": "<bursting-tag-value>"
      }
      }
      }
      ]
      }
    3. Replace <bursting-tag-value> with the Tag value that is shown in the Cloud bursting section on the Platform > Global settings page. (This is the only element of the policy JSON that you need to change.)
    4. Select Review policy.
    5. Enter a policy Name and Description.
    6. Select Create policy.
  3. Create a new user on behalf of the Pexip platform and associate it with the access policy.

    1. Select Users and then Add user.
    2. Enter a User name such as "pexip" and select an Access type of Programmatic access.
    3. Select Next: Permissions.
    4. On the Set permissions page, select the Attach existing policies directly tab.
    5. Use the Filter policies field to search for the policy you have just created above, and then select the checkbox next to that policy.
    6. Select Next: Tags, where you can optionally add some tags.
    7. Select Next: Review where you can review the user details and its associated permissions/policy.
    8. Select Create user.
    9. Either download the user credentials or show and make a note of the Access key ID and the Secret access key — you will enter these values into the Global settings page in the Pexip Infinity Administrator interface.

      (You must copy or download these key values when you create the user; you will not be able to access them again later.)

    10. Finally, select Close.

This policy only allows the "pexip" user i.e. the Pexip Infinity platform, to retrieve a list of instances and to start and stop existing instances that you have tagged as pexip-cloud. The Pexip Infinity platform cannot (and will not attempt to) create or delete AWS instances.

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.

Manually starting an overflow node

If you know that your system will need additional capacity at a specific time due to a predictable or scheduled spike in demand, but do not want to wait for the bursting threshold to be triggered before starting up the overflow nodes, you can manually start up any of your overflow nodes.

Do not manually start an overflow node too early. If you manually start up a node more than the Minimum lifetime minutes before the node is needed, it will most probably get automatically stopped again before it is used.

You can start overflow nodes via the management API or via the Administrator interface:

  • Via the management API: the cloud_node status resource can be used to list all of the available overflow nodes, the cloud_monitored_location and cloud_overflow_location resources retrieve the current load on the primary locations and any currently active overflow locations respectively, and the start_cloudnode resource can be used to manually start up any overflow node. This means that a third-party scheduling system, for example, could be configured to start up the overflow nodes via the management API approximately 10 minutes before a large conference is due to start.

    For example, let's assume that you have:

    • a regular spike in conferencing capacity demand at 9:00am every morning
    • an even usage of about 20% of that spike level during the rest of the day
    • a 30:70 ratio between your "always on" capacity and your overflow cloud capacity

    we would recommend:

    • configuring a low bursting threshold, such as 10-20% of your "always on" capacity (i.e. if your "always on" capacity is 80 HD calls, then set the bursting threshold to 12)
    • getting your scheduling system to call the API to manually start up all of your overflow cloud nodes at 8:50am on weekdays.
  • Via the Pexip Infinity Administrator interface: go to Status > Cloud bursting and select Start for the required nodes (the Start option is in the final column of the Cloud overflow nodes table).

Converting between overflow and "always on" AWS Conferencing Nodes

If you need to convert an existing "always on" AWS Conferencing Node into an overflow node:

  1. In AWS:

    1. Apply to the instance a tag with a Key of pexip-cloud and an associated Value set to the Tag value that is shown in the Cloud bursting section of the Platform > Global settings page.
    2. Manually stop the node instance on AWS.
  2. In Pexip Infinity:

    1. Change the system location of the Conferencing Node to the overflow system location (e.g. "AWS burst").
    2. Disable the node's Enable distributed database setting.

      You should avoid frequent toggling of this setting. When changing this setting on multiple Conferencing Nodes, update one node at a time, waiting a few minutes before updating the next node.

If you need to convert an existing AWS overflow Conferencing Node into an "always on" node:

  1. In AWS:

    1. Remove the tag with a Key of pexip-cloud from the AWS instance.
    2. Manually start the node instance on AWS.
  2. In Pexip Infinity:

    1. Change the system location of the Conferencing Node to a location other than the overflow system location.
    2. Enable the node's Enable distributed database setting.

      You should avoid frequent toggling of this setting. When changing this setting on multiple Conferencing Nodes, update one node at a time, waiting a few minutes before updating the next node.