Here are instructions for scaling VMware Tanzu Application Service for VMs (TAS for VMs) for different deployment scenarios.
For information about capacity scaling indicators for TAS for VMs, see Key capacity scaling indicators.
TAS for VMs defaults to a highly available resource configuration. For more information, see High Availability in TAS for VMs.
To increase the capacity and availability of the TAS for VMs platform, and to decrease the chances of downtime, you can scale a deployment up using the following instructions.
Scaling recommendations
The following table provides the instance counts that VMware recommends for a high-availability deployment and the minimum instances for a functional deployment:
| VMware Tanzu Application Service for VMs (TAS for VMs) Job | Recommended Instance Number for HA | Minimum Instance Number | Notes |
|---|---|---|---|
| Diego Cell | ≥ 3 | 1 | The optimal balance between CPU and 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 Diego Cell fails. On the other hand, scaling horizontally decreases the speed at which the system re-balances apps. Re-balancing 100 Diego Cells takes longer and demands more processing overhead than re-balancing 20 Diego Cells. |
| Diego Brain | ≥ 2 | 1 | For high availability, use at least one per AZ, or at least two if only one AZ. |
| Diego BBS | ≥ 2 | 1 | For high availability in a multi-AZ deployment, use at least one instance per AZ. Scale Diego BBS to at least two instances for high availability in a single-AZ deployment. |
| MySQL Server | 3 | 1 | If you use an external database in your deployment, you can set the MySQL Server instance count to 0. To scale down an internal MySQL cluster, see Scaling Down Your MySQL Cluster in Scaling Internal MySQL. |
| 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 | ≥ 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 Gorouter 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. |
| UAA | ≥ 2 | 1 | |
| Doppler Server | ≥ 2 | 1 | Deploying additional Doppler servers splits traffic across them. For a high-availability deployment, VMware recommends at least two per AZ. |
| Loggregator TrafficController | ≥ 2 | 1 | Deploying additional Loggregator TrafficController instances allows you to direct traffic to them in a round-robin manner. For a high-availability deployment, VMware recommends at least two per AZ. |
| Log Cache | ≥ 3 | 1 | Deploying additional Log Cache instances increases the total storage, sharding data by app ID. If app logs and metrics are sharded to an unavailable instance, they are unavailable when the designated instance is unavailable regardless of the number of instances or AZs. Data is not re-balanced unless you increase or decrease the number of desired instances in Operations Manager and apply changes. |
| CredHub | ≥ 3 | 1 | CredHub is a scalable component. For high availability, use at least one instance per AZ, or at least three instances if only one AZ is present. |
Scaling up TAS for VMs
You can determine when to scale up TAS for VMs components by reviewing the capacity scaling indicators. For more information, see Key Capacity Scaling Indicators.
To scale up TAS for VMs instances:
-
Go to the Tanzu Operations Manager Installation Dashboard.
-
Click the TAS for VMs tile.
-
Select Resource Config.
-
To scale your deployment horizontally, increase the number of Instances of a job. For guidance on the number of job instances required to ensure high availability, see Scaling Recommendations.
-
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 dropdown, TAS for VMs uses the recommended amount of resources for the job.
-
Click Save.
-
Return to the Tanzu Operations Manager Installation Dashboard, click Review Pending Changes, and click Apply Changes.
Scaling down TAS for VMs
If you are deploying a TAS for VMs configuration that does not need to be highly available, VMware recommends scaling down job instances to the minimum number required for a functional deployment.
To scale down your deployment:
-
Go to the Tanzu Operations Manager Installation Dashboard.
-
Click the TAS for VMs tile.
-
Select Resource Config.
-
In the Resource Config page, 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.
-
Click Save.
-
Return to the Tanzu Operations Manager Installation Dashboard, click Review Pending Changes, and click Apply Changes.
Scaling down jobs with persistent disk
If you scale down or delete a job that uses persistent disk, TAS for VMs marks the disk as orphaned. Orphaned disks are not attached to any job, and TAS for VMs deletes them after five days.
Use the BOSH CLI to list and recover orphaned disks. Follow the instructions in Advanced Troubleshooting with the BOSH CLI 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 use one of the following configurations, choose the values in the corresponding table to scale instances for your particular deployment:
- Deployments Using External Databases
- Deployments Using Internal MySQL
- Deployments Using an External Blobstore
- Deployments Using External Load Balancers
Deployments using external Databases
If you use an external database, you can scale down the instance counts for internal MySQL jobs.
Select the following values in the Resource Config pane:
| Job | Instance Count |
|---|---|
| MySQL Server | 0 |
| MySQL Proxy | 0 |
Deployments using internal MySQL
If you use 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.
To revert back to this configuration, choose the values shown in the Resource Config pane.
Caution Changing back to this configuration deletes any data written to your other database option.
| Job | Instance Count |
|---|---|
| MySQL Server | 3 |
| MySQL Proxy | 2 |
Apps that do not use MySQL for VMware Tanzu are not affected by the scaling process when you redeploy TAS for VMs. In addition, redeploying TAS for VMs with the MySQL cluster means that the TAS for VMs API is unavailable for a brief period of time. For example, you are not able to push apps or query their state during this time.
For more information, see the MySQL for VMware Tanzu documentation.
Deployments using an external blobstore
If you use an external blobstore, select the following value in the Resource Config pane:
| Job | Instance Count |
|---|---|
| File Storage | 0 |
Deployments using external load balancers
If you use an external load balancer, select the following values in the Resource Config pane:
| Job | Instance Count |
|---|---|
| Router | ≥ 1 |
| Diego Brain | ≥ 1 |
For more information about configuring load balancers in the Resource Config pane of the TAS for VMs tile, see Configuring load balancing for TAS for VMs.
