This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Compute in Archimate – Part 4.
Cinder = Block Storage
Cinder is a Block Storage service for OpenStack.
Mission: To implement services and libraries to provide on demand, self-service access to Block Storage resources. Provide Software Defined Block Storage via abstraction and automation on top of various traditional back-end block storage devices.
The block storage system manages the creation, attaching and detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs. In addition to local Linux server storage, it can use storage platforms including Ceph, CloudByte, Coraid, EMC (VMAX and VNX), GlusterFS, IBM Storage (Storwize family, SAN Volume Controller, XIV Storage System, and GPFS), Linux LIO, NetApp, Nexenta, Scality, SolidFire and HP (StoreVirtual and StoreServ 3Par families).
Cinder = Block Storage Structural Logical Architecture
Cinder virtualizes the management of block storage devices in software. Cinder provides end users with a self-service REST or CLI API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device. This is done through the use of either a reference implementation (LVM) or plugin drivers for other storage.
Cinder uses a sql-based central database that is shared by all Cinder services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, cinder will be moving towards multiple data stores with some kind of aggregation system.
The Auth Manager component responsible for users/projects/and roles. Can back-end to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system.
The scheduler: decides which host gets each volume.
A volume: manages dynamically attachable block devices. There can be many of these of different types each of which has a specific driver.
Cinder = Block Storage Behavioural Services Architecture
These are the REST & CLI Services offered by Cinder for Block Storage. For each Service below there are one or many sub-services or commands that can be found here: https://developer.openstack.org/api-ref/block-storage/v3
The next blog in the series is OpenStack Cloud Images in Archimate – Part 6.