SolidFire

Kilo - Kilo - Kilo - Kilo - Kilo - Kilo - Kilo - Kilo -

The SolidFire Cluster is a high performance all SSD iSCSI storage device that provides massive scale out capability and extreme fault tolerance. A key feature of the SolidFire cluster is the ability to set and modify during operation specific QoS levels on a volume for volume basis. The SolidFire cluster offers this along with de-duplication, compression, and an architecture that takes full advantage of SSDs.

To configure the use of a SolidFire cluster with Block Storage, modify your cinder.conf file as follows:

volume_driver = cinder.volume.drivers.solidfire.SolidFireDriver
san_ip = 172.17.1.182         # the address of your MVIP
san_login = sfadmin           # your cluster admin login
san_password = sfpassword     # your cluster admin password
sf_account_prefix = ''        # prefix for tenant account creation on solidfire cluster (see warning below)

Warning

	Warning
The SolidFire driver creates a unique account prefixed with `$cinder-volume-service-hostname-$tenant-id` on the SolidFire cluster for each tenant that accesses the cluster through the Volume API. Unfortunately, this account formation results in issues for High Availability (HA) installations and installations where the `cinder-volume` service can move to a new node. HA installations can return an Account Not Found error because the call to the SolidFire cluster is not always going to be sent from the same node. In installations where the `cinder-volume` service moves to a new node, the same issue can occur when you perform operations on existing volumes, such as clone, extend, delete, and so on.

The SolidFire driver creates a unique account prefixed with $cinder-volume-service-hostname-$tenant-id on the SolidFire cluster for each tenant that accesses the cluster through the Volume API. Unfortunately, this account formation results in issues for High Availability (HA) installations and installations where the cinder-volume service can move to a new node. HA installations can return an Account Not Found error because the call to the SolidFire cluster is not always going to be sent from the same node. In installations where the cinder-volume service moves to a new node, the same issue can occur when you perform operations on existing volumes, such as clone, extend, delete, and so on.

	Note
	Set the `sf_account_prefix` option to an empty string ('') in the `cinder.conf` file. This setting results in unique accounts being created on the SolidFire cluster, but the accounts are prefixed with the `tenant-id` or any unique identifier that you choose and are independent of the host where the `cinder-volume` service resides.

Table 2.30. Description of SolidFire driver configuration options
Configuration option = Default value	Description
[DEFAULT]
`sf_account_prefix` = `None`	(StrOpt) Create SolidFire accounts with this prefix. Any string can be used here, but the string "hostname" is special and will create a prefix using the cinder node hostsname (previous default behavior). The default is NO prefix.
`sf_allow_template_caching` = `True`	(BoolOpt) Create an internal cache of copy of images when a bootable volume is created to eliminate fetch from glance and qemu-conversion on subsequent calls.
`sf_allow_tenant_qos` = `False`	(BoolOpt) Allow tenants to specify QOS on create
`sf_api_port` = `443`	(IntOpt) SolidFire API port. Useful if the device api is behind a proxy on a different port.
`sf_emulate_512` = `True`	(BoolOpt) Set 512 byte emulation on volume creation;
`sf_template_account_name` = `openstack-vtemplate`	(StrOpt) Account name on the SolidFire Cluster to use as owner of template/cache volumes (created if does not exist).

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page

Legal notices