cinder/doc/source/contributor/high_availability.rst

High Availability
=================

In this guide we'll go over design and programming considerations related to
high availability in Cinder.

The document aims to provide a single point of truth in all matters related to
Cinder's high availability.

Cinder developers must always have these aspects present during the design and
programming of the Cinder core code, as well as the drivers' code.

Most topics will focus on Active-Active deployments.  Some topics covering node
and process concurrency will also apply to Active-Passive deployments.


Overview
--------

There are 4 services that must be considered when looking at a highly available
Cinder deployment: API, Scheduler, Volume, Backup.

Each of these services has its own challenges and mechanisms to support
concurrent and multi node code execution.

This document provides a general overview of Cinder aspects related to high
availability, together with implementation details.  Given the breadth and
depth required to properly explain them all, it will fall short in some places.
It will provide external references to expand on some of the topics hoping to
help better understand them.

Some of the topics that will be covered are:

- Job distribution.
- Message queues.
- Threading model.
- Versioned Objects used for rolling upgrades.
- Heartbeat system.
- Mechanism used to clean up out of service cluster nodes.
- Mutual exclusion mechanisms used in Cinder.

It's good to keep in mind that Cinder threading model is based on eventlet's
green threads.  Some Cinder and driver code may use native threads to prevent
thread blocking, but that's not the general rule.

Throughout the document we'll be referring to clustered and non clustered
Volume services.  This distinction is not based on the number of services
running, but on their configurations.

A non clustered Volume service is one that will be deployed as Active-Passive
and has not been included in a Cinder cluster.

On the other hand, a clustered Volume service is one that can be deployed as
Active-Active because it is part of a Cinder cluster.  We consider a Volume
service to be clustered even when there is only one node in the cluster.


Job distribution
----------------

Cinder uses RPC calls to pass jobs to Scheduler, Volume, and Backup services.
A message broker is used for the transport layer on the RPC calls and
parameters.

Job distribution is handled by the message broker using message queues.  The
different services, except the API, listen on specific message queues for RPC
calls.

Based on the maximum number of nodes that will connect, we can differentiate
two types of message queues: those with a single listener and those with
multiple listeners.

We use single listener queues to send RPC calls to a specific service in a
node. For example, when the API calls a non clustered Volume service to create
a snapshot.

Message queues having multiple listeners are used in operations such as:

- Creating any volume.  Call made from the API to the Scheduler.
- Creating a volume in a clustered Volume service.  Call made from the
  Scheduler to the Volume service.
- Attaching a volume in a clustered Volume service.  Call made from the API to
  the Volume service.

Regardless of the number of listeners, all the above mentioned RPC calls are
unicast calls.  The caller will place the request in a queue in the message
broker and a single node will retrieve it and execute the call.

There are other kinds of RPC calls, those where we broadcast a single RPC call
to multiple nodes.  The best example of this type of call is the Volume service
capabilities report sent to all the Schedulers.

Message queues are fair queues and are used to distribute jobs in a round robin
fashion.  Single target RPC calls made to message queues with multiple
listeners are distributed in round robin.  So sending three request to a
cluster of 3 Schedulers will send one request to each one.

Distribution is content and workload agnostic.  A node could be receiving all
the quick and easy jobs while another one gets all the heavy lifting and its
ongoing workload keeps increasing.

Cinder's job distribution mechanism allows fine grained control over who to
send RPC calls.  Even on clustered Volume services we can still access
individual nodes within the cluster.  So developers must pay attention to where
they want to send RPC calls and ask themselves: Is the target a clustered
service?  Is the RPC call intended for *any* node running the service?  Is it
for a *specific* node?  For *all* nodes?

The code in charge of deciding the target message queue, therefore the
recipient, is in the `rpcapi.py` files.  Each service has its own file with the
RPC calls: `volume/rpcapi.py`, `scheduler/rpcapi.py`, and `backup/rpcapi.py`.

For RPC calls the different `rcpapi.py` files ultimately use the `_get_cctxt`
method from the `cinder.rpc.RPCAPI` class.

For a detailed description on the issue, ramifications, and solutions, please
refer to the `Cinder Volume Job Distribution`_.

The `RabbitMQ tutorials`_ are a good way to understand message brokers general
topics.


Heartbeats
----------

Cinder services, with the exception of API services, have a periodic heartbeat
to indicate they are up and running.

When services are having health issues, they may decide to stop reporting
heartbeats, even if they are running.  This happens during initialization if
the driver cannot be setup correctly.

The database is used to report service heartbeats.  Fields `report_count` and
`updated_at`, in the `services` table, keep a heartbeat counter and the last
time the counter was updated.

There will be multiple database entries for Cinder Volume services running
multiple backends.  One per backend.

Using a date-time to mark the moment of the last heartbeat makes the system
time relevant for Cinder's operation.  A significant difference in system times
on our nodes could cause issues in a Cinder deployment.

All services report and expect the `updated_at` field to be UTC.

To determine if a service is up, we check the time of the last heartbeat to
confirm that it's not older than `service_down_time` seconds.  Default value
for `service_down_time` configuration option is 60 seconds.

Cinder uses method `is_up`, from the `Service` and `Cluster` Versioned Object,
to ensure consistency in the calculations across the whole code base.

Heartbeat frequency in Cinder services is determined by the `report_interval`
configuration option.  The default is 10 seconds, allowing network and database
interruptions.

Cinder protects itself against some incorrect configurations.  If
`report_interval` is greater or equal than `service_down_time`, Cinder will log
a warning and use a service down time of two and a half times the configured
`report_interval`.

.. note:: It is of utter importance having the same `service_down_time` and
   `report_interval` configuration options in all your nodes.

In each service's section we'll expand this topic with specific information
only relevant to that service.


Cleanup
-------

Power outages, hardware failures, unintended reboots, and software errors.
These are all events that could make a Cinder service unexpectedly halt its
execution.

A running Cinder service is usually carrying out actions on resources.  So when
the service dies unexpectedly, it will abruptly stop those operations.  Stopped
operations in this way leaves resources in transitioning states.  For example a
volume could be left in a `deleting` or `creating` status.  If left alone
resources will remain in this state forever, as the service in charge of
transitioning them to a rest status (`available`, `error`, `deleted`) is no
longer running.

Existing reset-status operations allow operators to forcefully change the state
of a resource.  But these state resets are not recommended except in very
specific cases and when we really know what we are doing.

Cleanup mechanisms are tasked with service's recovery after an abrupt stop of
the service.  They are the recommended way to resolve stuck transitioning
states caused by sudden service stop.

There are multiple cleanup mechanisms in Cinder, but in essence they all follow
the same logic.  Based on the resource type and its status the mechanism
determines the best cleanup action that will transition the state to a rest
state.

Some actions require a resource going through several services.  In this case
deciding the cleanup action may also require taking into account where the
resource was being processed.

Cinder has two types of cleanup mechanisms:

- On node startup: Happen on Scheduler, Volume, and Backup services.
- Upon user request.  User requested cleanups can only be triggered on
  Scheduler and Volume nodes.

When a node starts it will do a cleanup, but only for the resources that were
left in a transitioning state when the service stopped.  It will never touch
resources from other services in the cluster.

Node startup cleanup is slightly different on services supporting user
requested cleanups -Scheduler and Volume- than on Backup services.  Backup
cleanups will be covered in the service's section.

For services supporting user requested cleanups we can differentiate the
following tasks:

- Tracking transitioning resources: Using workers table and Cleanable Versioned
  Objects methods.
- Defining when a resource must be cleaned if service dies: Done in Cleanable
  Versioned Objects.
- Defining how a resource must be cleaned: Done in the service manager.

.. note:: All Volume services can accept cleanup requests, doesn't matter if
   they are clustered or not.  This will provide a better alternative to the
   reset-state mechanism to handle resources stuck in a transitioning state.


Workers table
~~~~~~~~~~~~~

For Cinder Volume managed resources -Volumes and Snapshots- we used to
establish a one-to-one relationship between a resource and the volume service
managing it.  A resource would belong to a node if the resource's `host` field
matched that of the running Cinder Volume service.

Snapshots must always be managed by the same service as the volume they
originate from, so they don't have a `host` field in the database.  In this
case the parent volume's `host` is used to determine who owns the resource.

Cinder-Volume services can be clustered, so we no longer have a one-to-one
owner relationship.  On clustered services we use the `cluster_name` database
field instead of the `host` to determine ownership.  Now we have a one-to-many
ownership relationship.

When a clustered service abruptly stops running, any of the nodes from the same
cluster can cleanup the resources it was working on.  There is no longer a need
to restart the service to get the resources cleaned by the node startup cleanup
process.

We keep track of the resources our Cinder services are working on in the
`workers` table.  Only resources that can be cleaned are tracked.  This table
stores the resource type and id, the status that should be cleared on service
failure, the service that is working on it, etc.  And we'll be updating this
table as the resources move from service to service.

`Worker` entries are not passed as RPC parameters, so we don't need a Versioned
Object class to represent them.  We only have the `Worker` ORM class to
represent database entries.

Following subsections will cover implementation details required to develop new
cleanup resources and states. For a detailed description on the issue,
ramifications, and overall solution, please refer to the `Cleanup spec`_.

Tracking resources
~~~~~~~~~~~~~~~~~~

Resources supporting cleanup using the workers table must inherit from the
`CinderCleanableObject` Versioned Object class.

This class provides helper methods and the general interface used by Cinder for
the cleanup mechanism.  This interface is conceptually split in three tasks:

- Manage workers table on the database.
- Defining what states must be cleaned.
- Defining how to clean resources.

Among methods provided by the `CinderCleanableObject` class the most important
ones are:

- `is_cleanable`: Checks if the resource, given its current status, is
  cleanable.
- `create_worker`: Create a worker entry on the API service.
- `set_worker`: Create or update worker entry.
- `unset_worker`: Remove an entry from the database.  This is a real delete,
  not a soft-delete.
- `set_workers`: Function decorator to create or update worker entries.

Inheriting classes must define `_is_cleanable` method to define which resource
states can be cleaned up.

Earlier we mentioned how cleanup depends on a resource's current state.  But it
also depends under what version the services are running.  With rolling updates
we can have a service running under an earlier pinned version for compatibility
purposes.  A version X service could have a resource that it would consider
cleanable, but it's pinned to version X-1, where it was not considered
cleanable.  To avoid breaking things, the resource should be considered as non
cleanable until the service version is unpinned.

Implementation of `_is_cleanable` method must take them both into account.  The
state, and the version.

Volume's implementation is a good example, as workers table was not supported
before version 1.6:

.. code-block:: python

   @staticmethod
   def _is_cleanable(status, obj_version):
       if obj_version and obj_version < 1.6:
           return False
       return status in ('creating', 'deleting', 'uploading', 'downloading')

Tracking states in the workers table starts by calling the `create_worker`
method on the API node.  This is best done on the different `rpcapi.py` files.

For example, a create volume operation will go from the API service to the
Scheduler service, so we'll add it in `cinder/scheduler/rpcapi.py`:

.. code-block:: python

   def create_volume(self, ctxt, volume, snapshot_id=None, image_id=None,
                     request_spec=None, filter_properties=None,
                     backup_id=None):
       volume.create_worker()

But if we are deleting a volume or creating a snapshot the API will call the
Volume service directly, so changes should go in `cinder/scheduler/rpcapi.py`:

.. code-block:: python

   def delete_volume(self, ctxt, volume, unmanage_only=False, cascade=False):
       volume.create_worker()

Once we receive the call on the other side's manager we have to call the
`set_worker` method.  To facilitate this task we have the `set_workers`
decorator that will automatically call `set_worker` for any cleanable versioned
object that is in a cleanable state.

For the create volume on the Scheduler service:

.. code-block:: python

   @objects.Volume.set_workers
   @append_operation_type()
   def create_volume(self, context, volume, snapshot_id=None, image_id=None,
                     request_spec=None, filter_properties=None,
                     backup_id=None):

And then again for the create volume on the Volume service:

.. code-block:: python

   @objects.Volume.set_workers
   def create_volume(self, context, volume, request_spec=None,
                     filter_properties=None, allow_reschedule=True):

In these examples we are using the `set_workers` method from the `Volume`
Versioned Object class.  But we could be using it from any other class as it is
a `staticmethod` that is not overwritten by any of the classes.

Using the `set_workers` decorator will cover most of our use cases, but
sometimes we may have to call the `set_worker` method ourselves.  That's the
case when transitioning from `creating` state to `downloading`.  The `worker`
database entry was created with the `creating` state and the working service
was updated when the Volume service received the RPC call.  But once we change
the status to `creating` the worker and the resource status don't match, so the
cleanup mechanism will ignore the resource.

To solve this we add another worker update in the `save` method from the
`Volume` Versioned Object class:

.. code-block:: python

   def save(self):

       ...

       if updates.get('status') == 'downloading':
           self.set_worker()

Actions on resource cleanup
~~~~~~~~~~~~~~~~~~~~~~~~~~~

We've seen how to track cleanable resources in the `workers` table.  Now we'll
cover how to define the actions used to cleanup a resource.

Services using the `workers` table inherit from the `CleanableManager` class
and must implement the `_do_cleanup` method.

This method receives a versioned object to clean and indicates whether we
should keep the `workers` table entry.  On asynchronous cleanup tasks method
must return `True` and take care of removing the worker entry on completion.

Simplified version of the cleanup of the Volume service, illustrating
synchronous and asynchronous cleanups and how we can do a synchronous cleanup
and take care ourselves of the `workers` entry:

.. code-block:: python

    def _do_cleanup(self, ctxt, vo_resource):
        if isinstance(vo_resource, objects.Volume):
            if vo_resource.status == 'downloading':
                self.driver.clear_download(ctxt, vo_resource)

            elif vo_resource.status == 'deleting':
                if CONF.volume_service_inithost_offload:
                    self._add_to_threadpool(self.delete_volume, ctxt,
                                            vo_resource, cascade=True)
                else:
                    self.delete_volume(ctxt, vo_resource, cascade=True)
                return True

        if vo_resource.status in ('creating', 'downloading'):
            vo_resource.status = 'error'
            vo_resource.save()

When the volume is `downloading` we don't return anything, so the caller
receives `None`, which evaluates to not keep the row entry.  When the status is
`deleting` we call `delete_volume` synchronously or asynchronously.  The
`delete_volume` has the `set_workers` decorator, that calls `unset_worker` once
the decorated method has successfully finished.  So when calling
`delete_volume` we must ask the caller of `_do_cleanup` to not try to remove
the `workers` entry.

Cleaning resources
~~~~~~~~~~~~~~~~~~

We may not have a `Worker` Versioned Object because we didn't need it, but we
have a `CleanupRequest` Versioned Object to specify resources for cleanup.

Resources will be cleaned when a node starts up and on user request.  In both
cases we'll use the `CleanupRequest` that contains a filtering of what needs to
be cleaned up.

The `CleanupRequest` can be considered as a filter on the `workers` table to
determine what needs to be cleaned.

Managers for services using the `workers` table must support the startup
cleanup mechanism.  Support for this mechanism is provided via the `init_host`
method in the `CleanableManager` class.  So managers inheriting from
`CleanableManager` must make sure they call this `init_host` method.  This can
be done using `CleanableManager` as the first inherited class and using `super`
to call the parent's `init_host` method, or by calling the class method
directly: `cleanableManager.init_host(self, ...)`.

`CleanableManager`'s `init_host` method will create a `CleanupRequest` for the
current service before calling its `do_cleanup` method with it before
returning.  Thus cleaning up all transitioning resources from the service.

For user requested cleanups, the API generates a `CleanupRequest` object using
the request's parameters and calls the scheduler's `work_cleanup` RPC with
it.

The Scheduler receives the `work_cleanup` RPC call and uses the
`CleanupRequest` to filter services that match the request.  With this list of
services the Scheduler sends an individual cleanup request for each of the
services.  This way we can spread the cleanup work if we have multiple services
to cleanup.

The Scheduler checks the service to clean to know where it must send the clean
request.  Scheduler service cleanup can be performed by any Scheduler, so we
send it to the scheduler queue where all Schedulers are listening.  In the
worst case it will come back to us if there is no other Scheduler running at
the time.

For the Volume service we'll be sending it to the cluster message queue if it's
a clustered service, or to a single node if it's non clustered.  But unlike
with the Scheduler, we can't be sure that there is a service to do the cleanup,
so we check if the service or cluster is up before sending the request.

After sending all the cleanup requests, the Scheduler will return a list of
services that have received a cleanup request, and all the services that didn't
because they were down.


Mutual exclusion
----------------

In Cinder, as many other concurrent and parallel systems, there are "critical
sections".  Code sections that share a common resource that can only be
accessed by one of them at a time.

Resources can be anything, not only Cinder resources such as Volumes and
Snapshots, and they can be local or remote.  Examples of resources are
libraries, command line tools, storage target groups, etc.

Exclusion scopes can be per process, per node, or global.

We have four mutual exclusion mechanisms available during Cinder development:

- Database locking using resource states.
- Process locks.
- Node locks.
- Global locks.

For performance reasons we must always try to avoid using any mutual exclusion
mechanism.  If avoiding them is not possible, we should try to use the
narrowest scope possible and reduce the critical section as much as possible.
Locks by decreasing order of preference are: process locks, node locks, global
locks, database locks.

Status based locking
~~~~~~~~~~~~~~~~~~~~

Many Cinder operations are inherently exclusive and the Cinder core code
ensures that drivers will not receive contradictory or incompatible calls.  For
example, you cannot clone a volume if it's being created.  And you shouldn't
delete the source volume of an ongoing snapshot.

To prevent these from happening Cinder API services use resource status fields
to check for incompatibilities preventing operations from getting through.

There are exceptions to this rule, for example the force delete operation that
ignores the status of a resource.

We should also be aware that administrators can forcefully change the status of
a resource and then call the API, bypassing the check that prevents multiple
operations from being requested to the drivers.

Resource locking using states is expanded upon in the `Race prevention`_
subsection in the `Cinder-API`_ section.

Process locks
~~~~~~~~~~~~~

Cinder services are multi-threaded -not really since we use greenthreads-, so
the narrowest possible scope of locking is among the threads of a single
process.

Some cases where we may want to use this type of locking are when we share
arrays or dictionaries between the different threads within the process, and
when we use a Python or C library that doesn't properly handle concurrency and
we have to be careful with how we call its methods.

To use this locking in Cinder we must use the `synchronized` method in
`cinder.utils`.  This method in turn uses the `synchronized` method from
`oslo_concurrency.lockutils` with the `cinder-` prefix for all the locks to
avoid conflict with other OpenStack services.

The only required parameter for this usage is the name of the lock.  The name
parameter provided for these locks must be a literal string value.  There is no
kind of templating support.

Example from `cinder/volume/throttling.py`:

.. code-block:: python

   @utils.synchronized('BlkioCgroup')
   def _inc_device(self, srcdev, dstdev):

.. note:: When developing a driver, and considering which type of lock to use,
   we must remember that Cinder is a multi backend service.  So the same driver
   can be running multiple times on different processes in the same node.

Node locks
~~~~~~~~~~

Sometimes we want to define the whole node as the scope of the lock.  Our
critical section requires that only one thread in the whole node is using the
resource.  This inter process lock ensures that no matter how many processes
and backends want to access the same resource, only one will access it at a
time.  All others will have to wait.

These locks are useful when:

- We want to ensure there's only one ongoing call to a command line program.
  That's the case of the `cinder-rtstool` command in
  `cinder/volume/targets/lio.py`, and the `nvmetcli` command in
  `cinder/volume/targets/nvmet.py`.

- Common initialization in all processes in the node.  This is the case of the
  backup service cleanup code.  The backup service can run multiple processes
  simultaneously for the same backend, but only one of them can run the cleanup
  code on start.

- Drivers not supporting Active-Active configurations.  Any operation that
  should only be performed by one driver at a time.  For example creating
  target groups for a node.

This type of lock use the same method as the `Process locks`_, `synchronized`
method from `cinder.utils`. Here we need to pass two parameters, the name of
the lock, and `external=True` to make sure that file locks are being used.

The name parameter provided for these locks must be a literal string value.
There is no kind of templating support.

Example from `cinder/volume/targest/lio.py`:

.. code-block:: python

   @staticmethod
   @utils.synchronized('lioadm', external=True)
   def _execute(*args, **kwargs):


Example from `cinder/backup/manager.py`:

.. code-block:: python

   @utils.synchronized('backup-pgid-%s' % os.getpgrp(),
                       external=True, delay=0.1)
   def _cleanup_incomplete_backup_operations(self, ctxt):

.. warning:: These are not fair locks.  Order in which the lock is acquired by
   callers may differ from request order.  Starvation is possible, so don't
   choose a generic lock name for all your locks and try to create a unique
   name for each locking domain.

Global locks
~~~~~~~~~~~~

Global locks, also known as distributed locks in Cinder, provide mutual
exclusion in the global scope of the Cinder services.

They allow you to have a lock regardless of the backend, for example to prevent
deleting a volume that is being cloned, or making sure that your driver is only
creating a Target group at a time, in the whole Cinder deployment, to avoid
race conditions.

Global locking functionality is provided by the `synchronized` decorator from
`cinder.coordination`.

This method is more advanced than the one used for the `Process locks`_ and the
`Node locks`_, as the name supports templates.  For the template we have all
the method parameters as well as `f_name` that represents that name of the
method being decorated.  Templates must use Python's `Format Specification
Mini-Language`_.

Using brackets we can access the function name `'{f_name}'`, an attribute of a
parameter `'{volume.id}'`, a key in a dictonary `{snapshot['name']}`, etc.

Up to date information on the method can be found in the `synchronized method's
documentation`_.

Example from the delete volume operation in `cinder/volume/manager.py`.  We
use the `id` attribute of the `volume` parameter, and the function name to form
the lock name:

.. code-block:: python

   @coordination.synchronized('{volume.id}-{f_name}')
   @objects.Volume.set_workers
   def delete_volume(self, context, volume, unmanage_only=False,
                     cascade=False):

Example from create snapshot in `cinder/volume/drivers/nfs.py`, where we use an
attribute from `self`, and a recursive reference in the `snapshot` parameter.

.. code-block:: python

   @coordination.synchronized('{self.driver_prefix}-{snapshot.volume.id}')
   def create_snapshot(self, snapshot):

Internally Cinder uses the `Tooz library`_ to provide the distributed locking.
By default, this library is configured for Active-Passive deployments, where it
uses file locks equivalent to those used for `Node locks`_.

To support Active-Active deployments a specific driver will need to be
configured using the `backend_url` configuration option in the `coordination`
section.

For a detailed description of the requirement for global locks in cinder please
refer to the `replacing local locks with Tooz`_ and `manager local locks`_
specs.


Cinder locking
~~~~~~~~~~~~~~

Cinder uses the different locking mechanisms covered in this section to assure
mutual exclusion on some actions.  Here's an *incomplete* list:

Barbican keys
  - Lock scope: Global.
  - Critical section: Migrate Barbican encryption keys.
  - Lock name: `{id}-_migrate_encryption_key`.
  - Where: `_migrate_encryption_key` method.
  - File: `cinder/keymgr/migration.py`.

Backup service
  - Lock scope: Node.
  - Critical section: Cleaning up resources at startup.
  - Lock name: `backup-pgid-{process-group-id}`.
  - Where: `_cleanup_incomplete_backup_operations` method.
  - File: `cinder/backup/manager.py`.

Image cache
  - Lock scope: Global.
  - Critical section: Create a new image cache entry.
  - Lock name: `{image_id}`.
  - Where: `_prepare_image_cache_entry` method.
  - File: `cinder/volume/flows/manager/create_volume.py`.

Throttling:
  - Lock scope: Process.
  - Critical section: Set parameters of a cgroup using `cgset` CLI.
  - Lock name: `''BlkioCgroup'`.
  - Where: `_inc_device` and `_dec_device` methods.
  - File: `cinder/volume/throttling.py`.

Volume deletion:
  - Lock scope: Global.
  - Critical section: Volume deletion operation.
  - Lock name: `{volume.id}-delete_volume`.
  - Where: `delete_volume` method.
  - File: `cinder/volume/manager.py`.

Volume deletion request:
  - Lock scope: Status based.
  - Critical section: Volume delete RPC call.
  - Status requirements: attach_status != 'attached' && not migrating
  - Where: `delete` method.
  - File: `cinder/volume/api.py`.

Snapshot deletion:
  - Lock scope: Global.
  - Critical section: Snapshot deletion operation.
  - Lock name: `{snapshot.id}-delete_snapshot`.
  - Where: `delete_snapshot` method.
  - File: `cinder/volume/manager.py`.

Volume creation:
  - Lock scope: Global.
  - Critical section: Protect source of volume creation from deletion.  Volume
    or Snapshot.
  - Lock name: `{snapshot-id}-delete_snapshot` or
    `{volume-id}-delete_volume}`.
  - Where: Inside `create_volume` method as context manager for calling
    `_fun_flow`.
  - File: `cinder/volume/manager.py`.

Attach volume:
  - Lock scope: Global.
  - Critical section: Updating DB to show volume is attached.
  - Lock name: `{volume_id}`.
  - Where: `attach_volume` method.
  - File: `cinder/volume/manager.py`.

Detach volume:
  - Lock scope: Global.
  - Critical section: Updating DB to show volume is detached.
  - Lock name: `{volume_id}-detach_volume`.
  - Where: `detach_volume` method.
  - File: `cinder/volume/manager.py`.

Volume upload image:
  - Lock scope: Status based.
  - Critical section: `copy_volume_to_image` RPC call.
  - Status requirements: status = 'available' or (force && status = 'in-use')
  - Where: `copy_volume_to_image` method.
  - File: `cinder/volume/api.py`.

Volume extend:
  - Lock scope: Status based.
  - Critical section: `extend_volume` RPC call.
  - Status requirements: status in ('in-use', 'available')
  - Where: `_extend` method.
  - File: `cinder/volume/api.py`.

Volume migration:
  - Lock scope: Status based.
  - Critical section: `migrate_volume` RPC call.
  - Status requirements: status in ('in-use', 'available') && not migrating
  - Where: `migrate_volume` method.
  - File: `cinder/volume/api.py`.

Volume retype:
  - Lock scope: Status based.
  - Critical section: `retype` RPC call.
  - Status requirements: status in ('in-use', 'available') && not migrating
  - Where: `retype` method.
  - File: `cinder/volume/api.py`.


Driver locking
~~~~~~~~~~~~~~

There is no general rule on where drivers should use locks.  Each driver has
its own requirements and limitations determined by the storage backend and the
tools and mechanisms used to manage it.

Even if they are all different, commonalities may exist between drivers.
Providing a list of where some drivers are using locks, even if the list is
incomplete, may prove useful to other developers.

To contain the length of this document and keep it readable, the list with the
:doc:`drivers_locking_examples` has its own document.


Cinder-API
----------

The API service is the public face of Cinder.  Its REST API makes it possible
for anyone to manage and consume block storage resources.  So requests from
clients can, and usually do, come from multiple sources.

Each Cinder API service by default will run multiple workers.  Each worker is
run in a separate subprocess and will run a predefined maximum number of green
threads.

The number of API workers is defined by the `osapi_volume_workers`
configuration option.  Defaults to the number of CPUs available.

Number of green threads per worker is defined by the `wsgi_default_pool_size`
configuration option.  Defaults to 100 green threads.

The service takes care of validating request parameters.  Any detected error is
reported immediately to the user.

Once the request has been validated, the database is changed to reflect the
request.  This can result in adding a new entry to the database and/or
modifying an existing entry.

For create volume and create snapshot operations the API service will create a
new database entry for the new resource. And the new information for the
resource will be returned to the caller right after the service passes the
request to the next Cinder service via RPC.

Operations like retype and delete will change the database entry referenced by
the request, before making the RPC call to the next Cinder service.

Create backup and restore backup are two of the operations that will create a
new entry in the database, and modify an existing one.

These database changes are very relevant to the high availability operation.
Cinder core code uses resource states extensively to control exclusive access
to resources.

Race prevention
~~~~~~~~~~~~~~~

The API service checks that resources referenced in requests are in a valid
state.  Unlike allowed resource states, valid states are those that allow an
operation to proceed.

Validation usually requires checking multiple conditions.  Careless coding
leaves Cinder open to race conditions.  Patterns in the form of DB data read,
data check, and database entry modification, must be avoided in the Cinder API
service.

Cinder has implemented a custom mechanism, called conditional updates, to
prevent race conditions.  Leverages the SQLAlchemy ORM library to abstract the
equivalent ``UPDATE ...  FROM ... WHERE;`` SQL query.

Complete reference information on the conditional updates mechanism is
available on the :doc:`api_conditional_updates` development document.

For a detailed description on the issue, ramifications, and solution, please
refer to the `API Race removal spec`_.


Cinder-Volume
-------------

The most common deployment option for Cinder-Volume is as Active-Passive.  This
requires a common storage backend, the same Cinder backend configuration in all
nodes, having the `backend_host` set on the backend sections, and using a
high-availability cluster resource manager like Pacemaker.

.. attention::  Having the same `host` value configured on more than one Cinder
   node is highly discouraged.  Using `backend_host` in the backend section is
   the recommended way to set Active-Passive configurations.  Setting the same
   `host` field will make Scheduler and Backup services report using the same
   database entry in the `services` table.  This may create a good number of
   issues: We cannot tell when the service in a node is down, backups services
   will break other running services operation on start, etc.

For Active-Active configurations we need to include the Volume services that
will be managing the same backends on the cluster.  To include a node in a
cluster, we need to define its name in the `[DEFAULT]` section using the
`cluster` configuration option, and start or restart the service.

.. note:: We can create a cluster with a single volume node.  Having a single
   node cluster allows us to later on add new nodes to the cluster without
   restarting the existing node.

.. warning:: The name of the cluster must be unique and cannot match any of the
   `host` or `backend_host` values.  Non unique values will generate duplicated
   names for message queues.

When a Volume service is configured to be part of a cluster, and the service is
restarted, the manager detects the change in configuration and moves existing
resources to the cluster.

Resources are added to the cluster in the `_include_resources_in_cluster`
method setting the `cluster_name` field in the database.  Volumes, groups,
consistency groups, and image cache elements are added to the cluster.

Clustered Volume services are different than normal services.  To determine if
a backend is up, it is no longer enough checking `service.is_up`, as that will
only give us the status of a specific service.  In a clustered deployment there
could be other services that are able to service the same backend.  That's why
we'll have to check if a service is clustered using `cinder.is_clustered` and
if it is, check the cluster's `is_up` property instead:
`service.cluster.is_up`.

In the code, to detect if a cluster is up, the `is_up` property from the
`Cluster` Versioned Object uses the `last_heartbeat` field from the same
object.  The `last_heartbeat` is a *column property* from the SQLAlchemy ORM
model resulting from getting the latest `updated_at` field from all the
services in the same cluster.

RPC calls
~~~~~~~~~

When we discussed the `Job distribution`_ we mentioned message queues having
multiple listeners and how they were used to distribute jobs in a round robin
fashion to multiple nodes.

For clustered Volume services we have the same queues used for broadcasting and
to address a specific node, but we also have queues to broadcast to the cluster
and to send jobs to the cluster.

Volume services will be listening in all these queues and they can receive
request from any of them.  Which they'll have to do to process RPC calls
addressed to the cluster or to themselves.

Deciding the target message queue for request to the Volume service is done in
the `volume/rpcapi.py` file.

We use method `_get_cctxt`, from the `VolumeAPI` class, to prepare the client
context to make RPC calls.  This method accepts a `host` parameter to indicate
where we want to make the RPC.  This `host` parameter refers to both hosts and
clusters, and is used to determine the server and the topic.

When calling the `_get_cctx` method, we would need to pass the resource's
`host` field if it's not clustered, and `cluster_name` if it is.  To facilitate
this, clustered resources implement the `service_topic_queue` property that
automatically gives you the right value to pass to `_get_cctx`.

An example for the create volume:

.. code-block:: python

   def create_volume(self, ctxt, volume, request_spec, filter_properties,
                     allow_reschedule=True):
       cctxt = self._get_cctxt(volume.service_topic_queue)
       cctxt.cast(ctxt, 'create_volume',
                  request_spec=request_spec,
                  filter_properties=filter_properties,
                  allow_reschedule=allow_reschedule,
                  volume=volume)

As we know, snapshots don't have a `host` or `cluseter_name` fields, but we can
still use the `service_topic_queue` property from the `Snapshot` Versioned
Object to get the right value.  The `Snapshot` internally checks these values
from the `Volume` Versioned Object linked to that `Snapshot` to determine the
right value.  Here's an example for deleting a snapshot:

.. code-block:: python

   def delete_snapshot(self, ctxt, snapshot, unmanage_only=False):
       cctxt = self._get_cctxt(snapshot.service_topic_queue)
       cctxt.cast(ctxt, 'delete_snapshot', snapshot=snapshot,
                  unmanage_only=unmanage_only)

Replication
~~~~~~~~~~~

Replication v2.1 failover is requested on a per node basis, so when a
failover request is received by the API it is then redirected to a specific
Volume service.  Only one of the services that form the cluster for the storage
backend will receive the request, and the others will be oblivious to this
change and will continue using the same replication site they had been using
before.

To support the replication feature on clustered Volume services, drivers need
to implement the `Active-Active replication spec`_.  In this spec the
`failover_host` method is split in two, `failover` and `failover_completed`.

On a backend supporting replication on Active-Active deployments,
`failover_host` would end up being a call to `failover` followed by a call to
`failover_completed`.

Code extract from the RBD driver:

.. code-block:: python

   def failover_host(self, context, volumes, secondary_id=None, groups=None):
       active_backend_id, volume_update_list, group_update_list = (
           self.failover(context, volumes, secondary_id, groups))
       self.failover_completed(context, secondary_id)
       return active_backend_id, volume_update_list, group_update_list

Enabling Active-Active on Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Supporting Active-Active configurations is driver dependent, so they have to
opt in.  By default drivers are not expected to support Active-Active
configurations and will fail on startup if we try to deploy them as such.

Drivers can indicate they support Active-Active setting the class attribute
`SUPPORTS_ACTIVE_ACTIVE` to `True`.  If a single driver supports multiple
storage solutions, it can leave the class attribute as it is, and set it as an
overriding instance attribute on `__init__`.

There is no well defined procedure required to allow driver maintainers to set
`SUPPORTS_ACTIVE_ACTIVE` to `True`.  Though there is an ongoing effort to write
a spec on `testing Active-Active`_.

So for now, we could say that it's "self-certification".  Vendors must do their
own testing until they are satisfied with their testing.

Real testing of Active-Active deployments requires multiple Cinder Volume nodes
on different hosts, as well as a properly configured Tooz DLM.

Driver maintainers can use Devstack to catch the rough edges on their initial
testing.  Running 2 Cinder Volume services on an All-In-One DevStack
installation makes it easy to deploy and debug.

Running 2 Cinder Volume services on the same node simulating different nodes
can be easily done:

- Creating a new directory for local locks:  Since we are running both services
  on the same node, a file lock could make us believe that the code would work
  on different nodes.  Having a different lock directory, default is
  `/opt/stack/data/cinder`, will prevent this.
- Creating a layover cinder configuration file:  Cinder supports having
  different configurations files where each new files overrides the common
  parts of the old ones.  We can use the same base cinder configuration
  provided by DevStack and write a different file with a `[DEFAULT]` section
  that configures `host` (to anything different than the one used in the first
  service), and `lock_path` (to the new directory we created).  For example we
  could create `/etc/cinder/cinder2.conf`.
- Create a new service unit:  This service unit should be identical to the
  existing `devstack@c-vol` except replace the `ExecStart` that should have the
  postfix `--config-file /etc/cinder/cinder2.conf`.

Once we have tested it in DevStack way we should deploy Cinder in a new Node,
and continue with the testings.

It is not necessary to do the DevStack step first, we can jump to having Cinder
in multiple nodes right from the start.

Whatever way we decide to test this, we'll have to change `cinder.conf` and add
the `cluster` configuration option and restart the Cinder service.  We also
need to modify the driver under test to include the
`SUPPORTS_ACTIVE_ACTIVE = True` class attribute.


Cinder-Scheduler
----------------

Unlike the Volume service, the Cinder Scheduler has supported Active-Active
deployments for a long time.

Unfortunately, current support is not perfect, scheduling on Active-Active
deployments has some issues.

The root cause of these issues is that the scheduler services don't have a
reliable single source of truth for the information they rely on to make the
scheduling.

Volume nodes periodically send a broadcast with the backend stats to all the
schedulers.  The stats include total storage space, free space, configured
maximum over provisioning, etc.  All the backends' information is stored in
memory at the Schedulers, and used to decide where to create new volumes,
migrate them on a retype, and so on.

For additional information on the stats, please refer to the
:ref:`volume stats <drivers_volume_stats>`
section of the Contributor/Developer docs.

Trying to keep updated stats, schedulers reduce available free space on
backends in their internal dictionary.  These updates are not shared between
schedulers, so there is not a single source of truth, and other schedulers
don't operate with the same information.

Until the next stat reports is sent, schedulers will not get in sync.  This may
create unexpected behavior on scheduling.

There are ongoing efforts to fix this problem.  Multiple solutions are being
discussed: using the database as a single source of truth, or using an external
placement service.

When we added Active-Active support to the Cinder Volume service we had to
update the scheduler to understand it.  This mostly entailed 3 things:

- Setting the `cluster_name` field on Versioned Objects once a backend has been
  chosen.

- Grouping stats for all clustered hosts.  We don't want to have individual
  entries for the stats of each host that manages a cluster, as there should be
  only one up to date value.  We stopped using the `host` field as the id for
  each host, and created a new property called `backend_id` that takes into
  account if the service is clustered and returns the host or the cluster as
  the identifier.

- Prevent race conditions on stats reports.  Due to the concurrency on the
  multiple Volume services in a cluster, and the threading in the Schedulers,
  we could receive stat reports out of order (more up to date stats last).  To
  prevent this we started time stamping the stats on the Volume services.
  Using the timestamps schedulers can discard older stats.

Heartbeats
~~~~~~~~~~

Like any other non API service, schedulers also send heartbeats using the
database.

The difference is that, unlike other services, the purpose of these heartbeats
is merely informative.  Admins can easily know whether schedulers are running
or not with a Cinder command.

Using the same `host` configuration in all nodes defeats the whole purpose of
reporting heartbeats in the schedulers, as they will all report on the same
database entry.


Cinder-Backups
--------------

Originally, the Backup service was not only limited to Active-Passive
deployments, but it was also tightly coupled to the Volume service.  This
coupling meant that the Backup service could only backup volumes created by the
Volume service running on the same node.

In the Mitaka cycle, the `Scalable Backup Service spec`_ was implemented.  This
added support for Active-Active deployments to the backup service.

The Active-Active implementation for the backup service is different than the
one we explained for the Volume Service.  The reason lays not only on the
fact that the Backup service supported it first, but also on it not supporting
multiple backends, and not using the Scheduler for any operations.

Scheduling
~~~~~~~~~~

For backups, it's the API the one selecting the host that will do the backup,
using methods `_get_available_backup_service_host`,
`_is_backup_service_enabled`, and `_get_any_available_backup_service`.

These methods use the Backup services' heartbeats to determine which hosts are
up to handle requests.

Cleaning
~~~~~~~~

Cleanup on Backup services is only performed on start up.

To know what resources each node is working on, they set the `host` field in
the backup Versioned Object when they receive the RPC call.  That way they can
select them for cleanup on start.

The method in charge of doing the cleanup for the backups is called
`_cleanup_incomplete_backup_operations`.

Unlike with the Volume service we cannot have a backup node clean up after
another node's.


.. _API Race removal spec: https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/cinder-volume-active-active-support.html
.. _Cinder Volume Job Distribution: https://specs.openstack.org/openstack/cinder-specs/specs/ocata/ha-aa-job-distribution.html
.. _RabbitMQ tutorials: https://www.rabbitmq.com/getstarted.html
.. _Cleanup spec: https://specs.openstack.org/openstack/cinder-specs/specs/newton/ha-aa-cleanup.html
.. _synchronized method's documentation: https://docs.openstack.org/cinder/latest/contributor/api/cinder.coordination.html#module-cinder.coordination
.. _Format Specification Mini-Language: https://docs.python.org/2.7/library/string.html#formatspec
.. _Tooz library: https://opendev.org/openstack/tooz
.. _replacing local locks with Tooz: https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/ha-aa-tooz-locks.html
.. _manager local locks: https://specs.openstack.org/openstack/cinder-specs/specs/newton/ha-aa-manager_locks.html
.. _Active-Active replication spec: https://specs.openstack.org/openstack/cinder-specs/specs/ocata/ha-aa-replication.html
.. _testing Active-Active: https://review.openstack.org/#/c/443504
.. _Scalable Backup Service spec: https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/scalable-backup-service.html