Process Structure

There are four processes that make up the Cinder service:

cinder-api is an WSGI application that accepts and validates REST (JSON or XML) requests from clients and routes them to other Cinder processes as appropriate over AMQP.
cinder-scheduler determines which backend should serve as the destination for a volume creation or movement request. It maintains non-persistent state for backends (e.g. available capacity, capabilities, and supported extra specs) that can be leveraged when making placement decisions. The algorithm utilized by the scheduler can be changed through Cinder configuration.
cinder-volume accepts requests from other Cinder processes and serves as the operational container for Cinder drivers. This process is multi-threaded and typically has one thread of execution per Cinder backend as defined in the Cinder configuration file.
cinder-backup handles the interaction with potential backup targets (e.g. OpenStack Object Storage Service (Swift)) when a client requests a volume backup to be created or managed.

Figure 4.2. Cinder Processes Concept Diagram

The following section walks through the steps that occur when a user requests the creation of a new volume from Cinder.

Figure 4.3. Cinder Workflow - Volume Creation

Client issues request to create volume through invoking REST API (client may use python-cinderclient CLI utility).
cinder-api process validates request, user credentials; once validated, puts message onto AMQP queue for processing.
cinder-volume process takes message off of queue, sends message to cinder-scheduler to determine which backend to provision volume into.
cinder-scheduler process takes message off of queue, generates candidate list based on current state and requested volume criteria (size, availability zone, volume type (including extra specs)).
cinder-volume process reads response message from cinder-scheduler from queue; iterates through candidate list by invoking backend driver methods until successful.
NetApp Cinder driver creates requested volume through interactions with storage subsystem (dependent on configuration and protocol).
cinder-volume process collects volume metadata and connection information and posts response message to AMQP queue.
cinder-api process reads response message from queue and responds to client.
Client receives information including status of creation request, volume UUID, etc.

The following section walks through the steps that occur when a user requests that a Cinder volume be attached to a Nova compute instance.

Figure 4.4. Cinder & Nova Workflow - Volume Attach

Client issues request to attach volume through invoking Nova REST API (client may use python-novaclient CLI utility).
nova-api process validates request, user credentials; once validated, invokes Cinder API to get connection information for specified volume.
cinder-api process validates request, user credentials; once validated, posts message to volume manager over AMQP.
cinder-volume reads message from queue, invokes Cinder driver corresponding to volume to be attached.
NetApp Cinder driver prepares Cinder volume in preparation for attachment (specific steps dependent on storage protocol used).
cinder-volume process posts response information to cinder-api process via AMQP queue.
cinder-api process reads response message from cinder-volume from queue; passes connection information in RESTful response to Nova caller.
Nova creates the connection to the storage with the returned information from Cinder.
Nova passes the volume device/file to the hypervisor, who then attaches the volume device/file to the guest VM as an actual or virtualized block device (dependent on storage protocol).