The Metacloud Block Storage service (
cinder) adds persistent storage to a virtual machine. Block Storage provides an infrastructure for managing volumes, and interacts with Metacloud Compute to provide volumes for instances. The service also enables management of volume snapshots and volume types.
The Block Storage service consists of the following components:
- cinder-api—Accepts API requests, and routes them to the
- cinder-volume—Interacts directly with the Block Storage service, and processes such as the
cinder-scheduler. It also interacts with these processes through a message queue. The
cinder-volumeservice responds to read and write requests sent to the Block Storage service to maintain state. It can interact with a variety of storage providers through a driver architecture.
- cinder-scheduler daemon—Selects the optimal storage provider node on which to create the volume. A similar component to the
- cinder-backup daemon—The
cinder-backupservice provides backing up volumes of any type to a backup storage provider. Like the
cinder-volumeservice, it can interact with a variety of storage providers through a driver architecture.
- Messaging queue—Routes information between the Block Storage processes.
To administer the Metacloud Block Storage service, refer to the section Using Block Storage.
Metacloud Block Storage enables you to add extra block-level storage to your Metacloud Compute instances.
The Metacloud Block Storage service works through the interaction of a series of daemon processes named
cinder-* that reside persistently on the host machine or machines.
When you purchased Metacloud, you made a choice between local disk ephemeral storage and Block Storage. With local disk storage, the storage for VMs is located on the compute nodes and does not use the
cinder service. The disks associated with VMs are ephemeral, meaning that they effectively disappear from the user’s view when you terminate a virtual machine. With Block Storage, the storage resource outlives computing resources and is always available, regardless of the state of a running instance.
To administer the Metacloud Block Storage service, it is helpful to understand that block storage is different from object storage and file system storage. When you chose Block Storage configuration options for Metacloud, you chose a storage configuration in these broad categories: Ceph, iSCSI, or NFS. Within the iSCSI category, you could choose different storage drivers. Metacloud currently supports SolidFire and Pure storage for iSCSI through
cinder drivers. Any device that supports NFS is supported for
cinder, but the storage is not fully managed by Cisco Metacloud.
To an end user, using Block Storage looks like adding a simple raw disk to an instance. Once attached to a running instance, the volume cannot be shared to another VM.
Ceph offers basic storage array functionality such as data replication in a software application. For Metacloud, only Block Storage is provided through Ceph, not Block Storage plus object storage. Ceph uses the RADOS protocol, not iSCSI. Ceph is a low initial-cost storage system, but it is not ideal for performance-sensitive environments. Live migration (moving instances while running from one compute node to another) is affected by your storage choice. Metacloud does not support true live migration when using Ceph as the migration takes a lot longer when using Ceph and is non-determinisitic. For more information, see Using Ceph Storage with Ephemeral Storage.
Another storage option for Metacloud is iSCSI through the
cinder Block Storage service. Metacloud has a tested option with the Pure and SolidFire storage drivers, providing high availability and performance for cloud applications. Many storage solutions integrate well with iSCSI due to the driver architecture. For more information, see Pure Storage Driver and Solidfire Storage Driver,
Using Network File Systems (NFS)
Network File Systems are commonly used for shared storage. With Metacloud you can use NFS for VM boot and data drives as well as storing images. It is a manual operation to create and link NFS storage to hypervisors, but you can use NFS shares in Metacloud, using the Block Storage service. You cannot integrate ephemeral (local) disks and you cannot snapshot a volume with NFS. For more information, see NFS Storage Driver.
Deploying NFS and Ceph in the same cluster is not currently supported.
Instance evacuation is supported with the Metacloud 4.0 release. Instance evacuation lets you evacuate a single instance off a failed Compute host while preserving its IP addresses, network configuration, and instance access controls. If the instance leverages shared storage (with Ceph or NFS) for the Compute root disks, Metacloud preserves all the instance disk data and, at the end of the evacuation, reboots the instance.