Cinder, the successor of Nova Volume, provides volume block storage. It adds persis- tent storage to an instance that will persist until deleted (contrary to ephemeral volumes that will only persist while the instance is running).
Cinder can provide volume storage by using a local file, one or more local disks, Ceph (RADOS) or network storage solutions from NetApp, EMC, or EqualLogic. Using a local file is not recommended for production systems for performance reasons.
The attributes that can be set to configure Cinder depend on the Type of Volume. The only general option is SSL Support: Protocol (see “SSL Support: Protocol ” (page 105) for configuration details).
Raw devices (local disks)
Disk Selection Method
Choose whether to only use the first available disk or all available disks. “Available disks” are all disks, currently not used by the system. Note that one disk (usually
/dev/sda) of every block storage node is already used for the operating system
and is not available for Cinder.
Name of Volume
Specify a name for the Cinder volume.
Local file
Volume File Name
Absolute path to the file to be used for block storage.
Maximum File Size
Maximum size of the volume file. Make sure not to overcommit the size, since it will result in data loss.
Name of Volume
Specify a name for the Cinder volume.
NOTE: Using Local File for block storage
Using a file for block storage is not recommended for production systems, because of performance and data security reasons.
NetApp
Storage Family Type/Storage Protocol
SUSE Cloud can either use the 7-Mode direct driver or the direct driver for clus- tered data ONTAP via iSCSI or NFS. Choose the driver and the protocol your Ne- tApp is licensed for.
122 Deployment Guide
Server host name
The management IP address for the 7-Mode storage controller or the cluster man- agement IP address for the clustered Data ONTAP.
Transport Type
Transport protocol for communicating with the storage controller or clustered Da- ta ONTAP. Supported protocols are HTTP and HTTPS. Choose the protocol your NetApp is licensed for.
Server port
The 7-Mode controller/clustered Data ONTAP port to use for communication. Port 80 is usually used for HTTP, 443 for HTTPS.
User Name / Password
Login credentials for 7-Mode controller/clustered Data ONTAP management.
The vFiler Unit Name if Using vFiler to Host OpenStack Volumes
The vFiler unit to be used for provisioning of OpenStack volumes. Use this only if using MultiStore®.
This setting only applies to the 7-Mode iSCSI direct diver. Name of the Virtual Storage Server (Vserver)
Host name of the Virtual Storage Server. This setting is only visible when using NFS as storage protocol.
List of Netapp NFS Exports
Provide a list of NFS Exports from the Virtual Storage Server. Specify one entry per line in the form of host name:/volume/pathmount-options. Spec-
ifying mount options is optional. This setting is only visible when using NFS as storage protocol.
EMC (EMC² Storage)
IP address of the ECOM server / Port of the ECOM server
IP address and Port of the ECOM server. Unisphere for VMAX Masking View
For VMAX, the user needs to create an initial setup on the Unisphere for VMAX server first. It needs to contain an initiator group, a storage group and a port group
and needs to be put in a masking view. This masking view needs to be specified here.
User Name / Password for accessing the ECOM server Login credentials for the ECOM server.
Thin pool where user wants to create volume from
Only thin LUNs are supported by the plugin. Thin pools can be created using Uni- sphere for VMAX and VNX.
For more information on the EMC driver refer to the OpenStack documentation at
http://docs.openstack.org/grizzly/openstack-block-stor age/admin/content/emc-smis-iscsi-driver.html.
EqualLogic
EqualLogic support is only included as a technology preview and not supported.
Rados (Ceph)
RADOS pool for Cinder volumes
Name of the pool used to store the Cinder volumes.
RADOS user for CephX authentication
Ceph user name.
Other driver (Ceph)
Lets you manually pick and configure a driver. Only use this option for testing purpos- es, it is not supported.
124 Deployment Guide
Figure 5.13: The Cinder Barclamp
The Cinder service consists of two different roles:
cinder-controller
The Cinder controller provides the scheduler and the API. Installing cinder-con- troller on a Control Node is recommended.
cinder-volume
The virtual block storage service. It can be installed on a Control Node, but it is recommended to deploy it on one or more dedicated nodes supplied with sufficient networking capacity, since it will generate a lot of network traffic.
Figure 5.14: The Cinder Barclamp: Node Deployment Example
5.9.1 HA Setup for Cinder
While the cinder-controller role can be deployed on a cluster, deploying cinder-vol- ume on a cluster is not supported. Therefore it is generally recommended to deploy cin- der-volume on several nodes—this ensures the service continues to be available even when a node fails. In addition with Ceph or a network storage solution, such a setup minimizes the potential downtime.
In case using Ceph or a network storage is no option, you need to set up a shared stor- age directory (for example with NFS), mount it on all cinder volume nodes and use the
Local File back-end with this shared directory. Using Raw Devices is not an option, since local disks cannot be shared.
126 Deployment Guide