In the Cloud Controller pane, you configure the Cloud Controller.

To configure the Cloud Controller pane:

  1. Click Cloud Controller.

  2. Enter your Cloud Controller database encryption key if all of the following are true:

    • You deployed TAS for VMs previously.
    • You then stopped TAS for VMs or it ended.
    • You are redeploying TAS for VMs with a backup of your Cloud Controller database.

      For more information, see Backing up and restoring Operations Manager.
  3. Cloud Foundry API rate limiting prevents API consumers from overwhelming the platform API servers. Limits are imposed on a per-user or per-client basis and reset on an hourly interval. Under Cloud Foundry API rate limiting, select one of the following options:

    • To configure Cloud Foundry API rate limiting:
    • Select Use.
      1. For General limit, enter the number of requests a user or client is to be allowed to make over an hour-long interval for all endpoints that do not have a custom limit. The default value is 2000.
      2. For Unauthenticated limit, enter the number of requests an unauthenticated client is to be allowed to make over an hour-long interval. The default value is 100.
    • To disallow Cloud Foundry API rate limiting, select Do not use.
  4. (Optional) For Database connection validation timeout, enter in seconds the database connection validation timeout period you want to configure. The default value is 3600. To configure Cloud Controller to make an additional query to the database whenever connections are checked out from the pool, enter -1. Configuring -1 in this field has performance implications.

  5. (Optional) For Database read timeout, enter in seconds the database read timeout period you want to configure. The default value is 3600.

  6. (Optional) For Cloud Controller monit health check timeout, enter in seconds the amount of time to wait before an HTTP request from the Cloud Controller monit health check is closed. The default value is 6.

  7. (Optional) For Age of audit events pruned from Cloud Controller database, enter in days the age at which audit events are to be pruned from the Cloud Controller database. The default value is 31.

  8. (Optional) For Age of completed tasks pruned from Cloud Controller database, enter in days the age at which completed tasks are to be pruned from the Cloud Controller database. The default value is 31.

  9. (Optional) Rotate the Cloud Controller database (CCDB) encryption key using the Encryption key ledger field. For more information, see Rotating the Cloud Controller database encryption key.

  10. For Available Stacks, configure the set of stacks you want to make available to app developers on the platform:

    1. Select the stacks to expose to developers. cflinuxfs4 is the latest stack, based on Ubuntu Jammy Jellfish (22.04), and is recommended. cflinuxfs3, an older stack based on Ubuntu Bionic Beaver (18.04), remains supported as well. Lastly, tanzu-jammy refers to the Tanzu Jammy Full stack. This stack uses the same operating system as cflinuxfs4, but is based on the Paketo stacks and is compatible with Cloud Native Buildpacks. Operators have the following four configuration options:

      • cflinuxfs4 only
      • cflinuxfs3 and cflinuxfs4
      • cflinuxfs4 and tanzu-jammy
      • cflinuxfs3, cflinuxfs4, and tanzu-jammy
    2. Select a Default stack. This stack is used whenever an app is pushed with no stack specified. The available options are cflinuxfs3 and cflinuxfs4. tanzu-jammy is not supported as a default stack. If you select a stack list that does not include cflinuxfs3, then cflinuxfs4 is used as the default stack.

  11. (Optional) Number of local workers per Cloud Controller VM. Defaults to 2. See Scaling Local Workers for more information.

  12. (Optional) Enable Prometheus metrics for Cloud Controller. Defaults to disabled. For more information, see Cloud Controller metrics.

  13. (Optional) Enable StatsD metrics for Cloud Controller. Defaults to enabled. For more information, see Cloud Controller metrics.

  14. (Optional) Enable Cloud Controller web server to utilize multiple CPU cores. This allows the Cloud controller API VMs to utilize multiple CPU cores. This uses the Ruby Puma web server instead of Thin. This feature is still beta, and uses a different format for primary metrics (Prometheus). Please consult your Broadcom support team before turning on. For more information on these properties see Scaling Puma Web Server.

    1. Select the number of Puma Workers. This is the number of child process to run as part of Puma clustered mode. This should not exceed the number of CPU cores available to the Cloud Controller API VM. The number of CPU cores can be found on the Resource Config page in the Ops Manager UI.

    2. Maximum number of threads per Puma Workers. For Cloud Controller running Puma to be able to handle as many concurrent requests as an API server running Thin, it’s recommended that Number of Workers x Number of Threads is greater or equal to 20. Default threads is 10.

    3. Maximum database connections per Puma Worker. The total number of connections is equal to Number of Workers x Maximum database connections per Worker. Be aware that incorrectly setting this may lead to too many connections for your Database. See Scaling Puma Web Server for more information.

    Important If reducing the number of overall Cloud Controller API VMs consider increasing the number of local workers per Cloud Controller VM property. See Scaling Local Workers for more information.

  15. Click Save.

check-circle-line exclamation-circle-line close-line
Scroll to top icon