Block Storage

cinder-api accepts API requests and routes them to cinder-volume for action.

cinder-volume acts upon the requests by reading or writing to the Cinder database to maintain state, interacting with other processes (like cinder-scheduler) through a message queue and directly upon block storage providing hardware or software. It can interact with a variety of storage providers through a driver architecture. Currently, there are drivers for IBM, SolidFire, NetApp, Nexenta, Zadara, GlusterFS, linux iSCSI and other storage providers.

Much like nova-scheduler, the cinder-scheduler daemon picks the optimal block storage provider node to create the volume on.

OpenStack Block Storage deployments will also make use of a messaging queue to route information between the cinder processes as well as a database to store volume state.