LATEST VERSION: 1.9 - CHANGELOG
Pivotal Cloud Foundry v1.9

Scaling Elastic Runtime

Page last updated:

This topic discusses how to scale Elastic Runtime for different deployment scenarios. To increase the capacity and availability of the Pivotal Cloud Foundry (PCF) platform, and to decrease the chances of downtime, you can scale a deployment up using the instructions below.

If you want to make a Diego or PCF configuration highly available, see the Zero Downtime Deployment and Scaling in CF topic.

Steps for Scaling Elastic Runtime

  1. Navigate to the Pivotal Cloud Foundry Operations Manager Installation Dashboard.

  2. Click the Elastic Runtime tile in the Installation Dashboard.

  3. Select Resource Config. Scaling ert

  4. You can scale your deployment horizontally, by increasing the number of Instances of a job. You can also scale your deployment vertically, by adjusting the Persistent Disk Type and VM Type of a job to allocate more disk space and memory. If you choose Automatic from the drop-down menu, Elastic Runtime uses the recommended amount of resources for the job.

    If you scale down or delete a job that uses persistent disk, Elastic Runtime marks the disk as “orphaned.” Orphaned disks are not attached to any job, and Elastic Runtime deletes them after five days. You can use the BOSH CLI to list and recover orphaned disks. Follow the instructions in the “Prepare to Use the BOSH CLI” section of the “Advanced Troubleshooting with the BOSH CLI” topic to log in to the BOSH Director, and then follow the procedures in “Orphaned Disks” in the BOSH documentation.

    If you are using one of the following configurations, choose the values in the corresponding table to scale instances for your particular deployment:

    External Databases

    If you are using an external database, choose the following values in the Resource Config:

    Job Instance Count Notes
    MySQL Server 0
    MySQL Proxy 0
    Cloud Controller Database (Postgres) 0
    UAA Database (Postgres) 0

    Internal MySQL

    If you are using the internal MySQL database on a clean install, or on an upgrade from a configuration that previously used internal MySQL databases, you do not need to change the default values shown below. If you need to change back to this configuration, choose the values shown below in the Resource Config.

    Note: Changing back to this configuration deletes any data written to your other database option.

    Job Instance Count Notes
    MySQL Server 3
    MySQL Proxy 1
    Cloud Controller Database (Postgres) 0
    UAA Database (Postgres) 0

    Internal Databases (for Upgrades)

    If you are upgrading from a previous installation that used both Postgres and MySQL databases, you must maintain this configuration to avoid data loss.

    Job Instance Count Notes
    MySQL Server 3
    MySQL Proxy 1
    Cloud Controller Database (Postgres) 1
    UAA Database (Postgres) 1

    External Blobstore

    If you are using an external Blobstore, choose the following value in the Resource Config:

    Job Instance Count Notes
    File Storage 0

    External Load Balancer

    If you are using an external load balancer, choose the following values in the Resource Config:

    Job Instance Count Notes
    HAProxy 0
    Router ≥ 1 For Amazon Web Services, set the Elastic Load Balancer name in the Router’s “External Load Balancer” field.
    Diego Brain ≥ 1 For AWS, if you have the Diego SSH feature enabled, set the SSH ELB name in the Router’s “External Load Balancer” field.
  5. Choose the suggested values outlined in each scenario above, and click Save.

  6. Return to the Installation Dashboard and click Apply Changes.

Was this helpful?
What can we do to improve?
View the source for this page in GitHub