Configure the Block Storage scheduler

The Block Storage scheduler (cinderScheduler) selects which back end receives new volumes, validates free space for operations, and determines volume placement for specific operations.

About this task

Use only a single instance of cinderScheduler for scheduling consistency and ease of troubleshooting. While cinderScheduler can be run with multiple instances, the service default replicas: 1 is the best practice.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml.
  2. Edit the CR file and add the configuration for the service down detection timeouts.

    The following example demonstrates this configuration:

    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    metadata:
      name: openstack
    spec:
      cinder:
        template:
          customServiceConfig: |
            [DEFAULT]
            report_interval = 20
            service_down_time = 120
    • report_interval: The number of seconds between Block Storage service components reporting an operational state in the form of a heartbeat through the database. The default is 10.
    • service_down_time: The maximum number of seconds since the last heartbeat from the component for it to be considered non-operational. The default is 60. Note

      Configure these values at the cinder level of the CR instead of the cinderScheduler so that these values are applied to all components consistently.

  3. Edit the CR file and add the configuration for the statistics reporting interval.

    The following example demonstrates configuring these values at the cinder level to apply them globally to all services:

    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    metadata:
      name: openstack
    spec:
      cinder:
        template:
          customServiceConfig: |
            [DEFAULT]
            backend_stats_polling_interval = 120
            backup_driver_stats_polling_interval = 120
    • backend_stats_polling_interval: The number of seconds between requests from the volume for usage statistics from the back end. The default is 60.
    • backup_driver_stats_polling_interval: The number of seconds between requests from the volume for usage statistics from backup service. The default is 60.

      The following example demonstrates configuring these values at the cinderVolume and cinderBackup level to customize settings at the service level.

      apiVersion: core.openstack.org/v1beta1
      kind: OpenStackControlPlane
      metadata:
        name: openstack
      spec:
        cinder:
          template:
            cinderBackup:
              customServiceConfig: |
                [DEFAULT]
                backup_driver_stats_polling_interval = 120
                < rest of the config >
            cinderVolumes:
              nfs:
                customServiceConfig: |
                  [DEFAULT]
                  backend_stats_polling_interval = 120
      Note

      The generation of usage statistics can be resource intensive for some back ends. Setting these values too low can affect back end performance. You might need to tune the configuration of these settings to better suit individual back ends.

  4. Perform any additional configuration necessary to customize the cinderScheduler service.

    For more configuration options for the customization of the cinderScheduler service, see Scheduler service parameters.

  5. Save the file.
  6. Update the control plane:
    $ oc apply -f openstack_control_plane.yaml -n openstack
  7. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status:
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.

Scheduler service parameters

Use scheduler service parameters to configure the cinderScheduler component, including scheduling attempts, default filters, and weighers.

Parameter Description

debug

Provides a setting for the logging level. When this parameter is true the logging level is set to DEBUG instead of INFO. The default is false.

scheduler_max_attempts

Provides a setting for the maximum number of attempts to schedule a volume. The default is 3

scheduler_default_filters

Provides a setting for filter class names to use for filtering hosts when not specified in the request. This is a comma-separated list. The default is AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter.

scheduler_default_weighers

Provide a setting for weigher class names to use for weighing hosts. This is a comma-separated list. The default is CapacityWeigher.

scheduler_weight_handler

Provides a setting for a handler to use for selecting the host or pool after weighing. The value cinder.scheduler.weights.OrderedHostWeightHandler selects the first host from the list of hosts that passed filtering and the value cinder.scheduler.weights.stochastic.stochasticHostWeightHandler gives every pool a chance to be chosen where the probability is proportional to each pool weight. The default is cinder.scheduler.weights.OrderedHostWeightHandler.

The following is an explanation of the filter class names from the parameter table:

  • AvailabilityZoneFilter
    • Filters out all back ends that do not meet the availability zone requirements of the requested volume.
  • CapacityFilter
    • Selects only back ends with enough space to accommodate the volume.
  • CapabilitiesFilter
    • Selects only back ends that can support any specified settings in the volume.
  • InstanceLocality
    • Configures clusters to use volumes local to the same node.