The Advanced Features pane includes new capabilities that might have certain constraints. Although these features are fully supported, VMware recommends caution when using them in production environments.
If you intend to deploy Diego Cells only through one or more isolation segment deployments, use this option to remove all Diego Cells from the TAS for VMs deployment. You might wish to do this to completely separate updates to Diego Cells from updates to the rest of the TAS for VMs deployment.
Important At least one isolation segment must deploy non-isolated Diego cell VMs so that the TAS for VMs installation has the shared Diego cells that are necessary to host system components that run as apps. Do not deploy app-based system components or run smoke-test errands until the non-isolated Diego cells in these isolation segment deployments are present.
If your apps do not use the full allocation of disk space and memory set in the Resource Config tab, you might want use this feature. These fields control the amount to overcommit disk and memory resources to each Diego Cell VM.
For example, you might want to use the overcommit if your apps use a small amount of disk and memory capacity compared to the amounts set in the Resource Config settings for Diego Cell.
Note Due to the risk of app failure and the deployment-specific nature of disk and memory use, VMware has no recommendation for how much, if any, memory or disk space to overcommit.
To use overcommit:
Select Advanced Features.
In the Diego Cell memory capacity field, enter in MB the total desired amount of Diego Cell memory. See the Diego Cell row in the Resource Config tab for the current Diego Cell memory capacity settings that this field overrides.
In the Diego Cell disk capacity field, enter in MB the total desired amount of Diego Cell disk capacity. See the Diego Cell row in the Resource Config tab for the current Diego Cell disk capacity settings that this field overrides.
Click Save.
Important Entries made to each of these two fields set the total amount of resources allocated, not the overage.
If your apps require a longer period of time to finish in-flight jobs and gracefully shut down, you can increase the graceful shutdown period. By default, this graceful shutdown period is set to 10 seconds.
When TAS for VMs requests a shutdown of an app, the processes in the container have a period of time to gracefully shut down before the processes are forcefully terminated. For more information, see Shutdown in App Container Lifecycle.
If you significantly increase the value of the graceful shutdown period, platform upgrades and updates might become slower. This is because each Diego Cell uses the graceful shutdown period when it is cleaning up evacuated app instances and waits for each app to gracefully shut down.
VMware recommends using isolation segments to separate apps that have different shutdown requirements to ensure Diego Cell update times are reliable. For more information, see Installing Isolation Segment.
Caution To avoid unexpected behavior, you must ensure that App graceful shutdown period has the same value in all environments that have deployed apps.
To increase the app graceful shutdown period:
Select Advanced Features.
In the App graceful shutdown period field, enter the number of seconds that you want the platform to wait for an app instance to exit after it is signaled to gracefully shut down. The default and minimum value is 10
.
Click Save.
Some private networks require extra configuration so that internal file storage (WebDAV) can communicate with other TAS for VMs processes.
The Non-RFC-1918 private network allow list field is provided for deployments that use a non-RFC 1918 private network. This is typically a private network other than 10.0.0.0/8
, 172.16.0.0/12
, or 192.168.0.0/16
.
Most TAS for VMs deployments do not require any modifications to this field.
To add your private network to the allow list:
Select Advanced Features.
Append a new allow
rule to the existing contents of the Non-RFC-1918 private network allow list field. Include the word allow
, the network CIDR range to allow, and a semi-colon (;
) at the end. For example:
allow 172.99.0.0/24;
Click Save.
The cf CLI connection timeout field allows you to override the default five-second timeout of the Cloud Foundry Command Line Interface (cf CLI) used within your TAS for VMs deployment. This timeout affects the cf CLI command used to push TAS for VMs errand apps such as Notifications, App Autoscaler, and Apps Manager.
Set the value of this field to a higher value, in seconds, if you are experiencing domain name resolution timeouts when pushing errands in TAS for VMs.
To modify the value of the cf CLI connection timeout:
Select Advanced Features.
Enter a value, in seconds, to the cf CLI connection timeout field.
Click Save.
You can allow TLS communication for clients of the internal system database. This feature is in beta, and the Allow TLS for internal MySQL database (beta) check box is deselected by default. For more information about the internal system database, see Managing internal databases.
To allow TLS communication for clients of the internal system database:
Select Advanced Features.
Select the Allow TLS for internal MySQL database (beta) check box.
Click Save.
You can configure the maximum number of concurrent database connections that Diego and container networking components can have.
To configure the maximum number of concurrent database connections:
Select Advanced Features.
Enter a value in each field beginning with Maximum number of open connections… for a given component. The placeholder values for each field are the default values.
Click Save.
When there are not enough connections available, such as during a time of heavy load, components might experience degraded performance and sometimes failure. To resolve or prevent this, you can increase and fine-tune database connection limits for the component.
Decreasing the value of this field for a component might affect the amount of time it takes for it to respond to requests.
You can disallow rolling app deployments. For more information, see Rolling app deployments.
To disallow rolling app deployments:
Select Advanced Features.
Select the Disallow rolling app deployments check box.
Click Save.
By default, Log Cache keeps 100,000 envelopes per source. An envelope wraps an event and adds metadata. For sources that produce more than 100,000 envelopes, this default might not be long enough for you to specify a time period for a historical query.
To set the maximum number of envelopes stored per source above the default:
Select Advanced Features.
Enter the Maximum number of envelopes stored in Log Cache per source.
Click Save.
By default, Usage Service deletes granular data after 365 days.
To configure this retention period:
Select Advanced Features.
In the Usage Service data retention period field, enter the number of days of granular data you want to retain.
Click Save.
To avoid performance or data migration issues, VMware recommends that you do not retain data for longer than 365 days. Configuring this field does not affect monthly summary records.
For more information, see Usage data retention in Reporting App, Task, and Service Instance Usage.