Articles in this section

See more

Openstack Cinder - Quick start with Zadara VPSA as a storage back-end

Product Management
  • Updated
Follow

Overview

This article covers how you can quickly get started using Zadara VPSA driver for Openstack Cinder Project.

The article assumes that the reader has prior experience with Openstack and has a local deployment of Openstack. The main objective is to quickly setup a Zadara VPSA as Cinder's storage back-end. 

Zadara's Openstack Cinder driver is part of the community upstream, and is available "out-of-the-box" since Openstack Newton release and later.

Prerequisites

  • Zadara VPSA Storage array - 19.08 release or later, 20.12-SP1 for the Wallaby release. 
  • Local Openstack deployment - Train release and later.
  • Networking -
    The VPSA will provide a single floating IP to allow both control plane and data path connectivity by default. In case networking segregation is required, the following are required:
    • High-speed connectivity (10Gb/40Gb/100Gb) between Openstack compute nodes and the VPSA to allow iSCSI connectivity. 
    • Control plane connectivity between Cinder nodes and the VPSA.

Cinder volume service configuration

In order to configure Zadara VPSA as the back-end storage, add the following configuration to your cinder.conf configuration file (typically located at /etc/cinder/cinder.conf). 

 

[zadaravpsa]
zadara_vpsa_host = <VPSA FQDN or IP i.e. vsa-00000029-zadara-iop-01.zadaravpsa.com>
zadara_vpsa_port = 443
zadara_access_key = <VPSA User access key i.e. FDZGA51V0SJ36IBXC2JO-223>
zadara_vpsa_use_ssl = True
zadara_ssl_cert_verify = True
zadara_vpsa_poolname = <VPSA Pool id i.e. pool-00010001>
volume_driver = cinder.volume.drivers.zadara.ZadaraVPSAISCSIDriver
volume_backend_name = zadaravolume

 

The above configuration is the minimal required information to get started, the full configuration options can be found at the Openstack official documentation. 

 

Cinder Image-Volume cache

"OpenStack Block Storage has an optional Image cache which can dramatically improve the performance of creating a volume from an image. The improvement depends on many factors, primarily how quickly the configured back end can clone a volume.

When a volume is first created from an image, a new cached image-volume will be created that is owned by the Block Storage Internal Tenant. Subsequent requests to create volumes from that image will clone the cached version instead of downloading the image contents and copying data to the volume.

The cache itself is configurable per back end and will contain the most recently used images. "

The VPSA efficient cloning mechanism will be used for caching the most recently used images.

In order to use it, the following configuration should be applied:

  • In the cinder.conf add the internal tenant project ID & user: 
    cinder_internal_tenant_project_id = PROJECT_ID
    cinder_internal_tenant_user_id = USER_ID
  •  In the storage back-end definition of the VPSA enable image cache:
    image_volume_cache_enabled = True
  • (Optional) Configure the limit of cache size:
     
    image_volume_cache_max_size_gb = SIZE_GB
image_volume_cache_max_count = MAX_COUNT
  • Restart Cinder & Glance services.

Multiple VPSAs / Storage support

Adjust the cinder.conf configuration file to define the volume driver name along with a storage back end entry for each VPSA pool that will be managed by the block storage service. Each back end entry requires a unique section name, surrounded by square brackets (or parentheses), followed by options in key=value format.

 

Once the configuration is in place, restart Cinder's volume.

 

Changes in authentication

Due to security measures taken in VPSA version 19.08 in order to improve the way we store users authentication details, The user is now expected to provide the API key instead of a username/password combination. While username/password authentication will work for VPSA version prior to 19.08, authentication for 19.08 VPSA will be using access key only. The username/password configuration parameters are marked as deprecated and will be removed completely in future Openstack releases.

 

Retrieving the user access key

The VPSA REST API access key can be retrieved in two ways:

  1. VPSA Management UI - once logged in, click on the logged on username (upper right), and click on the "Reset Access Key" (once approved, the access key will be displayed for the logged on user, the access key will be displayed once and cannot be retrieved, in case you have forgot the access key, a new key will be required)
    Additional information can be found at the VPSA User Guide
    mceclip0.png

2. REST API - use the "Reset a user's access key" API as described in Zadara VPSA API documentation 

 

Networking segregation

In case a networking segregation is required (i.e. using a different network for Cinder control plane and data traffic), an additional VNI (Virtual network Interface can be added to the VPSA for this purposes).

Adding a Virtual Network Interface can be done using Zadara's Provisioning Portal or Command Center.

The primary network of the VPSA should be used for data path (the network the VPSA was initially created with), the additional VNI should be used for management purposed.

In this case, in Cinder's configuration the operator needs to set the additional VNI as the VPSA endpoint (i.e. zadara_vpsa_host). 

 

If you encounter any issues, we love to help, please contact support@zadarastorage.com

 

Related articles