Cinder, the successor of Nova Volume, provides volume block storage. It adds per- sistent storage to an instance that will persist until deleted (contrary to ephemeral vol- umes that will only persist while the instance is running).
Cinder can provide volume storage by using different back-ends such as local file, one or more local disks, Ceph (RADOS), VMware or network storage solutions from
EMC, EqualLogic, Fujitsu or NetApp. Since SUSE Cloud 5, Cinder supports using several back-ends simultaneously. It is also possible to deploy the same network stor- age back-end multiple times and therefore use different installations at the same time. When first opening the Cinder barclamp, the default proposal—Raw Devices— is al- ready available for configuration. To optionally add a back-end, go to the section Add New Cinder Back-End and choose a Type Of Volume from the drop-down box. Op- tionally, specify the Name for the Backend. This is recommended when deploying the same volume type more than once. Existing back-end configurations (including the default one) can be deleted by clicking the trashcan icon if no longer needed. Note that at least one back-end must be configured.
The attributes that can be set to configure Cinder depend on the Type of Vol- ume. The only general option is SSL Support: Protocol (see “SSL Support: Protocol
” (page 114) for configuration details).
Raw devices (local disks)
Disk Selection Method
Choose whether to only use the first available disk or all available disks. “Avail- able 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 operat-
ing system and is not available for Cinder.
Name of Volume
Specify a name for the Cinder volume.
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
Thin pool where user wants to create volume from
Only thin LUNs are supported by the plugin. Thin pools can be created using Unisphere 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.
Fujitsu ETERNUS DX
Connection Protocol
Select the protocol used to connect, either FibreChannel or iSCSI. IP / Port for SMI-S
IP address and port of the ETERNUS SMI-S Server. Username / Password for SMI-S
Login credentials for the ETERNUS SMI-S Server. Pool Name
Storage pool (RAID group) in which the volumes are created. Make sure to have created that RAID group on the server in advance. If a RAID group that does not exist is specified, the RAID group is created by using unused disk drives. The RAID level is automatically determined by the ETERNUS DX Disk storage sys- tem.
NetApp
Storage Family Type/Storage Protocol
SUSE Cloud can either use “Data ONTAP” in 7-Mode or in Clustered Mode. In
7-Mode vFiler will be configured, in Clustered Mode vServer will be configured. The Storage Protocoll can either be set to iSCSI or NFS. Choose the driver and the protocol your NetApp is licensed for.
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 port to use for communication. Port 80 is usually used for HTTP, 443 for HTTPS.
User Name/Password for Accessing NetApp
Login credentials.
The vFiler Unit Name
The vFiler unit to be used for provisioning of OpenStack volumes. This setting is only available in 7-Mode.
Name of the Virtual Storage Server (Vserver)
Host name of the Virtual Storage Server. This setting is only available in Clustered Mode when using NFS as storage protocol.
NetApp Volume List
Provide a list of comma-separated volumes names to be used for provisioning. This setting is only available when using iSCSI 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 available when using NFS as storage protocol.
Rados (Ceph)
Use Ceph Deployed by CrowbarSelect true if you have deployed Ceph with SUSE Cloud. In case you are using an external Ceph cluster (see Section 5.4.4, “Using an Externally Managed Ceph Cluster” (page 89) for setup instructions), select false.
Path to Ceph Configuration File
This configuration option is only available, if using an external Ceph cluster. Specify the path to the ceph.conf file—the default value (/etc/ceph/ ceph.conf) should be fitting if you have followed the setup instructions for an
external Ceph cluster.
RADOS pool for Cinder volumes
Name of the pool used to store the Cinder volumes.
RADOS user (Set Only if Using CephX authentication)
Ceph user name.
VMware
vCenter Host/IP Address
Host name or IP address of the vCenter server.
vCenter Username / vCenter Password
vCenter login credentials. Folder for Volumes
Path to the folder used to store the Cinder volumes.
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.
Other driver
Lets you manually pick and configure a driver. Only use this option for testing pur- poses, it is not supported.
Figure 6.14: 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 suffi- cient networking capacity, since it will generate a lot of network traffic.
Figure 6.15: The Cinder Barclamp: Node Deployment Example
6.9.1 HA Setup for Cinder
While the cinder-controller role can be deployed on a cluster, deploying cinder-volume
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 op- tion, since local disks cannot be shared.