Add Third-Party Block storage to ViPR using the REST API
Table of Contents
This article also describes the important REST API calls to manage and configure the storage after it has been added, and discovered in ViPR.
This article applies to EMC ViPR 2.0.
This article is part of a series
- Authenticate with the ViPR REST API
- Add physical assets to ViPR:
- Create ViPR virtual assets:
OpenStack version support
For supported versions, see the EMC ViPR Support Matrix available on the EMC Community Network (community.emc.com).
Openstack installation is supported on the following platforms:
- Red Hat Enterprise Linux
- SUSE Enterprise Linux
- Ubuntu Linux
For a list of the supported platform versions, see Openstack documentation at: http://docs.openstack.org.
The following two components must be installed. Both components can be installed on the same server, or on separate servers.
- OpenStack Identity Service (Keystone)
Required for authentication
- OpenStack Block Storage (Cinder)
The core service that provides all storage information.
For complete installation and configuration details, refer to the OpenStack documentation at: http://docs.openstack.org.
Supported third-party block storage systems
ViPR operations are supported on any third-party block storage systems, tested by OpenStack, which use Fibre Channel or iSCSI protocols.
Non-supported storage systemsViPR does not support third-party storage systems using:
- Proprietary protocols such as Ceph.
- Drivers for block over NFS.
- Local drivers such as LVM.
- RBD (Ceph)
Refer to www.openstack.org for information about OpenStack third-party storage systems.
ViPR native driver support and recommendations
- EMC VMAX
- EMC VNX for Block
- EMC VPLEX
- Hitachi Data Systems (with Fibre Channel only)
- Create Block Volume
- Export Volume to Host
- Create a Block Volume for a Host
- Expand block volume
- Remove Volume by Host
- Remove Block Volume
- Create Full Copy
- Create Block Snapshot
- Create volume from snapshot
- Remove Block Snapshot
Using the ViPR, Create VMware Datastore service, to create a datastore from a block volume created by a third-party storage system is not supported. However datastores can be created from third-party block volumes, manually through VMware vCenter.
OpenStack third-party storage configuration recommendations
It is recommended that before adding the storage provider to ViPR, configure the storage provider with only the storage systems that you want to manage with ViPR through the third-party block storage provider.
When the third-party block storage provider is added to the ViPR Physical Assets, all of the storage systems managed by the OpenStack block storage service, which are supported by ViPR, will be added to ViPR.
If you do not configure the storage provider with only the storage systems you want managed through ViPR, it is possible to deregister or delete the storage systems through ViPR after they are added to ViPR. However, it is a better practice to configure the storage provider for ViPR integration prior to adding the storage provider to ViPR.
Cinder does not have any specific standards on backend driver attributes definitions. Refer to the vendor-specific recommendations on how to configure the cinder driver, which may involve installing a vendor specific plugin or CLI.
enabled_backends, which will be commented by default, and add the multiple back-end names. In the following example, NetApp and IBM SVC are added as backend configurations.
- Near the end of the file add the storage system specific entries as follows:
- Restart the Cinder service.
- Create volumes for each type of volume created in OpenStack.
Volumes can be created in the OpenStack UI or the Cinder CLI. The Cinder CLI command to create a volume is:
- Check that the volumes are getting created on the associated storage system. For example, NetApp-iSCSI type volumes should be created only on the NetApp storage system.
Before you begin
- The IP address of the Third-party block storage provider.
- The username and password for connecting to the storage provider. System administrator privileges are required.
- The port number used to connect to the storage provider. The default port number for a Third-party block storage provider is 22.
- The <interface_type> is cinder.
- Authenticate with the ViPR REST API as a System Administrator.
The EMC ViPR REST API Reference provides a description and complete list of parameters for the REST API methods used in this article.
- Add third-party block storage by sending a
POST /vdc/storage-providers request.
The request returns a task whose URI can be queried to determine the when the task is complete.RequestResponse
- Repeat the query of the Third-party storage provider create task, using the task URL from the response body of the POST request, until the message attribute of the task is
Operation completed successfully.
After ViPR discovers a third-party block storage array, a default storage port is created for the storage system, and appears in the Storage Port page, with the name Default, and storage port identifier: > Openstack+<storagesystemserialnumber>+Port+Default.
Fibre Channel configured storage ports
ViPR export operations cannot be performed on an FC connected storage system, which has been added to ViPR without any WWPNs assigned to the storage port. Therefore, ViPR system administrators must manually add at least one WWPN to the default storage port before performing any export operations on the storage system. WWPNs can only be added to ViPR through the VIPR CLI. For steps to configure the storage port through the ViPR CLI refer to Add WWPNs to FC connected third-party block storage ports.
After the WWPN is added to the storage port, you can perform export operations on the storage system from ViPR. At the time of the export, ViPR reads the export response from the Cinder service. The export response will include the WWPN, which was manually added by the system administrator from the ViPR CLI, and any additional WWPNs listed in the export response. ViPR then creates a storage port for each of the WWPNs listed in the export response during the export operation.
After a successful export operation is performed, the Storage Port page displays any newly created ports, in addition to the Default storage port.
Each time another export operation is performed on the same storage system, ViPR reads the Cinder export response. If the export response presents WWPNs, which are not present in ViPR, then ViPR creates new storage ports for every new WWPN.
iSCSI configured storage ports
The default storage port is used to support the storage system configuration until an export is performed on the storage system. At the time of the export, ViPR reads the export response from the Cinder service, which includes the iSCSI IQN. ViPR then modifies the default storage port's identifier with the IQN received from the Cinder export response.
Each time another export operation is performed on the same storage system, ViPR reads the Cinder export response. If the export response presents an IQN, which is not present in ViPR, then ViPR creates a new storage port.
You will need to get at least one valid WWPN for the storage port before continuing.
Use the following CLI commands to add a WWPN to the storage port.
- Get the last three digits of the storage system serial number from the list of storage systems.
- Get the port network ID for the Default storage port. The storage port network ID (PORT_NETWORK_ID) will be an invalid value.
- Add the WWPN (50:01:02:34:05:06:FE:07 in this example) to the storage port.
- Repeat step 2, to validate the value was added to the storage port (PORT_NETWORK_ID).
Refer to the EMC ViPR CLI Reference guide for more information.
When a SAN switch is added to ViPR, the Fibre Channel networks (Brocade Fabrics or Cisco VSANs), are automatically discovered and registered in ViPR. Additionally, through discovery of the SAN switch topology, ViPR discovers, and registers the host initiators for hosts on the network, and identifies which storage systems are associated with the SAN switch.
Refer to Add network systems (fabric managers) and SAN networks to ViPR for more information.
- For Storage Systems that use ViPR services with the iSCSI protocol, the iSCSI host ports must be logged into the correct target array ports before they can be used in the service.