Chapter 26. Tips for undercloud and overcloud services
This section provides advice on tuning and managing specific OpenStack services on the undercloud.
26.1. Review the database flush intervals
Some services use a cron
container to flush old content from the database.
- OpenStack Identity (keystone): Flush expired tokens.
- OpenStack Orchestration (heat): Flush expired deleted template data.
- OpenStack Compute (nova): Flush expired deleted instance data.
The default flush periods for each service are listed in this table:
Service | Database content flushed | Default flush period |
---|---|---|
OpenStack Identity (keystone) | Expired tokens | Every hour |
OpenStack Orchestration (heat) | Deleted template data that has expired and is older than 30 days | Every day |
OpenStack Compute (nova) | Archive deleted instance data | Every day |
OpenStack Compute (nova) | Flush archived data older than 14 days | Every day |
The following tables outline the parameters that you can use to control these cron
jobs.
Parameter | Description |
---|---|
|
Cron to purge expired tokens - Minute. The default value is: |
|
Cron to purge expired tokens - Hour. The default value is: |
|
Cron to purge expired tokens - Month Day. The default value is: |
|
Cron to purge expired tokens - Month. The default value is: |
|
Cron to purge expired tokens - Week Day. The default value is: |
Parameter | Description |
---|---|
|
Cron to purge database entries marked as deleted and older than $age - Age. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Age type. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Minute. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Hour. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Month Day. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Month. The default value is: |
|
Cron to purge database entries marked as deleted and older than $age - Week Day. The default value is: |
Parameter | Description |
|
Cron to move deleted instances to another table - Max Rows. The default value is: |
|
Purge shadow tables immediately after scheduled archiving. The default value is: |
|
Cron to move deleted instances to another table - Minute. The default value is: |
|
Cron to move deleted instances to another table - Hour. The default value is: |
|
Cron to move deleted instances to another table - Month Day. The default value is: |
|
Cron to move deleted instances to another table - Month. The default value is: |
|
Cron to move deleted instances to another table - Week Day. The default value is: |
|
Cron to move deleted instances to another table - Until complete. The default value is: |
|
Cron to purge shadow tables - Age This will define the retention policy when purging the shadow tables in days. 0 means, purge data older than today in shadow tables. The default value is: |
|
Cron to purge shadow tables - Minute. The default value is: |
|
Cron to purge shadow tables - Hour. The default value is: |
|
Cron to purge shadow tables - Month Day. The default value is: |
|
Cron to purge shadow tables - Month. The default value is: |
|
Cron to purge shadow tables - Week Day. The default value is: |
To adjust these intervals, create an environment file that contains your token flush interval for the respective services and add this file to the custom_env_files
parameter in your undercloud.conf
file. For example, to change the OpenStack Identity (keystone) token flush to 30 minutes, use the following snippets
keystone-cron.yaml
parameter_defaults: KeystoneCronTokenFlushMinute: '0/30'
undercloud.yaml
custom_env_files: keystone-cron.yaml
Then rerun the openstack undercloud install
command.
$ openstack undercloud install
You can also use these parameters for your overcloud. For more information, see the Overcloud Parameters guide.
26.2. Tuning deployment performance
OpenStack Platform director uses OpenStack Orchestration (heat) to conduct the main deployment and provisioning functions. Heat uses a series of workers to execute deployment tasks. To calculate the default number of workers, the director heat configuration halves the total CPU thread count of the undercloud. [2]. For example, if your undercloud has a CPU with 16 threads, heat spawns 8 workers by default. The director configuration also uses a minimum and maximum cap by default:
Service | Minimum | Maximum |
---|---|---|
OpenStack Orchestration (heat) | 4 | 24 |
However, you can set the number of workers manually with the HeatWorkers
parameter in an environment file:
heat-workers.yaml
parameter_defaults: HeatWorkers: 16
undercloud.yaml
custom_env_files: heat-workers.yaml
26.3. Running swift-ring-builder in a container
To manage your Object Storage (swift) rings, use the swift-ring-builder
commands inside the server containers:
-
swift_object_server
-
swift_container_server
-
swift_account_server
For example, to view information about your swift object rings, run the following command:
$ sudo podman exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder
You can run this command on both the undercloud and overcloud nodes.
26.4. Changing the SSL/TLS cipher rules for HAProxy
If you enabled SSL/TLS in the undercloud (see Section 4.2, “Director configuration parameters”), you might want to harden the SSL/TLS ciphers and rules that are used with the HAProxy configuration. This hardening helps to avoid SSL/TLS vulnerabilities, such as the POODLE vulnerability.
Set the following hieradata using the hieradata_override
undercloud configuration option:
- tripleo::haproxy::ssl_cipher_suite
- The cipher suite to use in HAProxy.
- tripleo::haproxy::ssl_options
- The SSL/TLS rules to use in HAProxy.
For example, you might want to use the following cipher and rules:
-
Cipher:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
-
Rules:
no-sslv3 no-tls-tickets
Create a hieradata override file (haproxy-hiera-overrides.yaml
) with the following content:
tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets
The cipher collection is one continuous line.
Set the hieradata_override
parameter in the undercloud.conf
file to use the hieradata override file you created before you ran openstack undercloud install
:
[DEFAULT] ... hieradata_override = haproxy-hiera-overrides.yaml ...