Building Storage Services in OpenStack on NetApp - Part II of III

14 minute read

Welcome to part two of the three-part series on creating storage services in OpenStack on NetApp. In this post we will look at how to configure NetApp storage in a OpenStack environment. In part one of the series we looked at how to install and configure OpenStack. In part three we will look at how to configure storage services in OpenStack.

Overview

NetApp has the most unified storage combined with the best feature set in the industry. NetApp provides the only storage operating system which allows you to manage your data on-premise, off-premise, in private clouds, public clouds or even hybrid clouds. NetApp is a perfect fit for OpenStack as a storage platform. In this post we will explore why, discuss options and show you how to properly configure your NetApp storage system for OpenStack.

Below is a diagram illustrating the broad-reaching data management capabilities of Data ONTAP:

ontap_architecture

Storage Considerations

There are currently two OpenStack services which support storage: Cinder (block) and Swift (object). Manilla (file services) is an incubation project and slated for the kilo release later in 2015. For the purpose of this post I am going to focus on Cinder.

E-Series vs FAS

NetApp offers two product lines for storage the E-Series and FAS lines. I would not recommend choosing between E-Series or FAS as they have different uses in terms of OpenStack. E-Series is best used for Swift as a backend to object storage. It is very fast and has a great price to performance value. Swift is an object store and abstracts storage management. You want a fast, resilient, highly available storage system and that is the E-Series. The E-Series storage also has a nice feature called "Dynamic Disk Pools" which implements CRUSH (erasure coding) and it reduces storage footprint from 3x to just 1.25x for Swift in OpenStack environments.

FAS is the clear choice when it comes to Cinder storage where you want data management features and capabilities exposed in OpenStack.

ONTAP 7mode vs Clustered Data ONTAP

In the FAS world there are also two choices. Personally I don't think it is much of a choice. Clustered Data ONTAP is the evolution of FAS storage. It is a scale-out architecture and scales in three dimensions: operations, performance and capacity. It is by far the most complete storage system ever built and certainly most capable storage system on the market today. Clustered Data ONTAP virtualizes storage into what are called Storage Virtual Machines (SVMs) which enable secure multi-tenancy. If we think about cloud computing platforms, multi-tenancy is the basis and a raw ingredient. Clustered Data ONTAP provides world-class data management, scalability in multiple dimensions, unified protocols (ISCSI, NFS, CIFS, and FC) and non-disruptive always-on operations in the same storage system. The only reason not to go with Clustered Data ONTAP is that you already have 7mode and don't have budget, otherwise it is no-brainer. NetApp of course supports 7mode with its OpenStack driver so this is an option for those that can't go with Clustered Data ONTAP.

Storage Protocol

There are two options for connecting storage to Cinder: ISCSI or NFS. At this time Fiber Chanel (FC) is not supported and if we consider cloud computing architectures, FC does not really have the horizontal scalability required. Let's face it we don't need a second segregated island for data traffic, IP networks are proven and scale, FC is simply out of this picture.

Cinder exposes block devices to virtual machines or instances but it can reside on both NFS or ISCSI storage. I would recommend NFS as NFS storage is much easier to manage than ISCSI. However if you are a SAN only shop or coming from a SAN environment, ISCSI might be a nice way to bridge into OpenStack and not have to make changes to how hosts connect to their storage. You can even use a combination of both. You could use NFS for creating Cinder volumes where instances reside and ISCSI for host mount points. Again I would recommend NFS for everything and that is what I am going to cover but I wanted to at least explain both options.

Configuring Clustered Data ONTAP

We have made the following storage decisions for our OpenStack Cinder configuration:

  • FAS (storage platform)
  • Clustered Data ONTAP (storage operating system)
  • NFS (protocol)

Storage Virtual Machines

Configure two storage virtual machines. One will be used to provide storage to Cinder volumes and the other for DR. At a minimum you will need two IPs for each SVM. One for the management LIF and the other the data LIF. Ensure that both SVMs data LIFs are reachable from the OpenStack host.

Create SVMs

  • vserver create -vserver <svm> -subtype default -rootvolume <rootvol> -aggregate <aggr> -rootvolume-security-style unix

Create management LIFs

  • net int create -vserver <svm> -lif data -role data -data-protocol nfs -home-node steve-02 -home-port e0a -address <ip> -netmask <netmask> -firewall-policy mgmt

Create Data LIFs

  • net int create -vserver <svm> -lif data -role data -data-protocol nfs -home-node steve-02 -home-port e0a -address <ip> -netmask <netmask> -firewall-policy data

Ensure NFS services are running on both SVMs

  • nfs status -vserver

If NFS is not running you can start NFS as follows:

  • nfs on -vserver
  • nfs start -vserver

Create Export policy

In order to export NetApp volumes to OpenStack via NFS we need an export policy. Create an export policy as follows:

  • export-policy create -vserver <svm> -policyname openstack
  • export-policy rule create -vserver <svm> -policyname openstack -clientmatch <IP or CIDR> -rorule any -rwrule any

Add export policy to SVM root volume otherwise OpenStack host wont have write permission

  • volume modify -vserver <svm> -volume <rootvol> -policy openstack

Create NetApp Volumes

NetApp volumes are containers for storing files or LUNs. In the case of OpenStack a NetApp volume is a container for Cinder volumes which is a container for block devices. We will create three volumes for Cinder and each volume will define a different storage service e.g. gold, silver and bronze. In addition we will create a fourth volume for storing glance images. The beauty here is that the storage admin can define storage services based on containers and expose them up through Cinder for consumption in OpenStack.

Clustered Data ONTAP allows us to mix SSDs and Spinning Disk in the same storage system to enable building services with different performance characteristics. One can create aggregates which contain NetApp volumes using SSDs, Spinning Disk or even a mix (hybrid aggregates). In addition Clustered Data ONTAP provides QoS at the IOP or bandwidth level which we can use to further define or even restrict our storage services.

Gold Volume

The gold volume will be our most expensive storage service but will have the best performance and availability. We will create a volume on the best performing aggregate and in addition mirror that volume to another SVM.

  • volume create -vserver <svm> -volume openstack_gold -aggregate <aggr> -size 500g -state online -type RW -policy openstack -snapshot-policy none -space-guarantee volume
  • volume mount -vserver <svm> -volume openstack_gold -junction-path /openstack_gold
  • snapmirror initialize -source-path <svm>:openstack_gold -destination-path <svm dr>:openstack_gold_dr
Silver Volume

The silver volume will have a good price to performance but not include DR. We will create volume from a best performing aggregate and enable compression for space savings.

  • volume create -vserver <svm> -volume openstack_silver -aggregate <aggr> -size 500g -state online -type RW -policy openstack -snapshot-policy none -space-guarantee volume
  • volume mount -vserver <svm> -volume openstack_silver -junction-path /openstack_silver
  • volume efficiency on -vserver <svm> -volume openstack_silver
  • volume efficiency modify -vserver <svm> -volume openstack_silver -compression true -inline-compression true
Bronze Volume

The bronze volume will have lower performing storage and be the most cost-effective service. We will create volume from lower performing aggregate and enable dedup for space savings. We will not enable DR.

  • volume create -vserver <svm> -volume openstack_bronze -aggregate <aggr> -size 500g -state online -type RW -policy openstack -snapshot-policy none -space-guarantee volume
  • volume mount -vserver <svm> -volume openstack_bronze -junction-path /openstack_bronze
  • volume efficiency on -vserver <svm> -volume openstack_bronze
  • volume efficiency policy create -vserver <svm> -policy bronze_dedupe -schedule  -duration - -enabled true
Glance Volume

Finally we will create a volume for storing images in Glance. This volume does not have high performance requirements but we will certainly enable dedup to greatly reduce the storage footprint.

  • volume create -vserver <svm> -volume openstack_glance -aggregate <aggr> -size 500g -state online -type RW -policy openstack -snapshot-policy none -space-guarantee volume
  • volume mount -vserver <svm> -volume openstack_glance -junction-path /openstack_glance
  • volume efficiency on -vserver <svm> -volume openstack_bronze
  • volume efficiency policy create -vserver <svm> -policy bronze_dedupe -schedule  -duration - -enabled true

The next post in the series will cover configuring the above NetApp volumes in OpenStack as storage services.

(c) 2014 Keith Tenzer