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 PCF configuration highly available, see the High Availability in CF topic.

Note: In PCF 1.11 and later, Elastic Runtime defaults to a highly available resource configuration.

Scaling Recommendations

The following table provides recommended instance counts for a high-availability deployment and the minimum instances for a functional deployment:

Elastic Runtime Job Recommended Instance Number for HA Minimum Instance Number Notes
Diego Cell ≥ 3 1 The optimal balance between CPU/memory sizing and instance count depends on the performance characteristics of the apps that run on Diego cells. Scaling vertically with larger Diego cells makes for larger points of failure, and more apps go down when a cell fails. On the other hand, scaling horizontally decreases the speed at which the system rebalances apps. Rebalancing 100 cells takes longer and demands more processing overhead than rebalancing 20 cells.
Diego Brain ≥ 2 1 For high availability, use at least one per AZ, or at least two if only one AZ.
Diego BBS ≥ 3 1 Set this to an odd number equal to or one greater than the number of AZs you have, in order to maintain quorum. Distribute the instances evenly across the AZs, at least one instance per AZ.
Consul ≥ 3 1 Set this to an odd number equal to or one greater than the number of AZs you have, in order to maintain quorum. Distribute the instances evenly across the AZs, at least one instance per AZ.
MySQL Server 3 1 If you use an external database in your deployment, then you can set the MySQL Server instance count to 0. For instructions about scaling down an internal MySQL cluster, see Scaling Down Your MySQL Cluster.
MySQL Proxy 2 1 If you use an external database in your deployment, then you can set the MySQL Proxy instance count to 0.
NATS Server ≥ 2 1 In a high availability deployment, you might run a single NATS instance if your deployment lacks the resources to deploy two stable NATS servers. Components using NATS are resilient to message failures and the BOSH resurrector recovers the NATS VM quickly if it becomes non-responsive.
Cloud Controller ≥ 2 1 Scale the Cloud Controller to accommodate the number of requests to the API and the number of apps in the system.
Clock Global ≥ 2 1 For a high availability deployment, scale the Clock Global job to a value greater than 1 or to the number of AZs you have.
Router ≥ 2 1 Scale the router to accommodate the number of incoming requests. Additional instances increase available bandwidth. In general, this load is much less than the load on Diego cells.
HAProxy 0 or ≥ 2 0 or 1 For environments that require high availability, you can scale HAProxy to 0 and then configure a high-availability load balancer (LB) to point directly to each Gorouter instance. Alternately, you can also configure the high availability LB to point to HAProxy instance scaled at ≥ 2. Either way, an LB is required to host Cloud Foundry domains at a single IP address.
UAA ≥ 2 1
Doppler Server ≥ 2 1 Deploying additional Doppler servers splits traffic across them. For a high availability deployment, Pivotal recommends at least two per Availability Zone.
Loggregator Trafficcontroller ≥ 2 1 Deploying additional Loggregator Traffic Controllers allows you to direct traffic to them in a round-robin manner. For a high availability deployment, Pivotal recommends at least two per Availability Zone.

Scaling Up Elastic Runtime

To scale up Elastic Runtime instances, perform the following steps:

  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. To scale your deployment horizontally, increase the number of Instances of a job. See Scaling Recommendations for guidance on the number of job instances required to ensure high availability.

    Note: In PCF 1.12, you cannot scale the Autoscaler job to greater than one instance.

  5. To scale your deployment vertically, adjust 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.

  6. Click Save.

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

Scaling Down Elastic Runtime

If you are deploying a PCF configuration that does not need to be highly available, Pivotal recommends scaling down job instances to the minimum number required for a functional deployment.

To scale down your deployment, perform the following steps:

  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. In the Resource Config screen, decrease the number of Instances for each job. Choose the suggested values outlined in Scaling Recommendations, or in the Scaling Recommendations for Specific Deployment Configurations and click Save.

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

Scaling Down Jobs with Persistent Disk

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.

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.

Scaling Recommendations for Specific Deployment Configurations

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

Deployments Using External Databases

If you are using an external database, you can scale down the instance counts for internal MySQl jobs.

Select the following values in the Resource Config:

Job Instance Count
MySQL Server 0
MySQL Proxy 0

Deployments Using 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 in the table 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
MySQL Server 3
MySQL Proxy 1

Deployments Using an External Blobstore

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

Job Instance Count
File Storage 0

Deployments Using External Load Balancers

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

Job Instance Count
HAProxy 0
Router ≥ 1
Diego Brain ≥ 1

For more information about configuring load balancers in the Resource Config section of Elastic Runtime, see the “Deploying Elastic Runtime” topic for your IaaS. For example:

Create a pull request or raise an issue on the source for this page in GitHub