Theory of Operation & Deployment Choices

Manila backends and Clustered Data ONTAP.  Storage Virtual Machines (SVMs, formerly known as Vservers) contain one or more FlexVol volumes and one or more LIFs through which they serve data to clients.

SVMs securely isolate the shared virtualized data storage and network, and each SVM appears as a single dedicated storage virtual machine to clients. Each SVM has a separate administrator authentication domain and can be managed independently by its SVM administrator.

In a cluster, SVMs facilitate data access. A cluster must have at least one SVM to serve data. SVMs use the storage and network resources of the cluster. However, the shares and LIFs are exclusive to the SVM. Multiple SVMs can coexist in a single cluster without being bound to any node in a cluster. However, they are bound to the physical cluster on which they exist.

Manila shares and FlexVol volumes.  Data ONTAP FlexVol volumes (commonly referred to as volumes) and OpenStack File Share Storage shares (commonly referred to as Manila shares) are semantically analogous. A FlexVol volume is a container of logical data elements (for example: files, Snapshot™ copies, clones, LUNs, et cetera) that is abstracted from physical elements (for example: individual disks, and RAID groups).

Manila snapshots versus NetApp Snapshots.  A NetApp Snapshot copy is a point-in-time file system image. Low-overhead NetApp Snapshot copies are made possible by the unique features of the WAFL storage technology that is part of Data ONTAP. The high performance of the NetApp Snapshot makes it highly scalable. A NetApp Snapshot takes only a few seconds to create — typically less than one second, regardless of the size of the share or the level of activity on the NetApp storage system. After a Snapshot copy has been created, changes to data objects are reflected in updates to the current version of the objects, as if NetApp Snapshot copies did not exist. Meanwhile, the NetApp Snapshot version of the data remains completely stable. A NetApp Snapshot incurs no performance overhead; users can comfortably store up to 255 NetApp Snapshot copies per FlexVol volume, all of which are accessible as read-only and online versions of the data.

	Important
	Since NetApp Snapshots are taken at the FlexVol level, they can and are directly leveraged within an Manila context, as a user of Manila requests a snapshot be taken of a particular Manila share.

Manila offers the capability for shares to be accessible through tenant-defined networks (defined within Neutron). This is achieved by defining a share network object. A share network object is made up of a neutron network ID and a neutron subnet ID. The share network object serves two purposes:

Offering this capability to end users places certain requirements on storage platforms that are integrated with Manila to be able to dynamically configure themselves. Share servers are objects defined by Manila that manages the relationship between share networks and shares. In the case of the reference driver implementation, a share server corresponds to an actual Nova instance that provides the file system service, with raw capacity provided through attached Cinder block storage volumes. In the case of the Manila driver for NetApp clustered Data ONTAP, a share server corresponds to a storage virtual machine (SVM), also referred to as a Vserver.

Another way to think about this is that share networks are the networks over which NFS exports and or SMB shares are accessed by clients, share servers are the NFS/SMB servers from which those exports/shares are accessed.

The NetApp driver supports all available network plugins supported by Manila. See the section called “Manila Network Plugins” for more details.

	Note
	One share server is created by Manila for each share network that has shares associated with it.

	Important
	When deploying Manila with NetApp clustered Data ONTAP without share server management, NetApp requires that each Manila backend refer to a single SVM within a cluster through the use of the netapp_vserver configuration option.

With Share Servers.  Within the clustered Data ONTAP driver with share server support, a storage virtual machine will be created for each share server. While this can provide some advantages with regards to secure multitenancy and integration with a variety of network services within OpenStack, care must be taken to ensure that the scale limits are enforced through Manila quotas. It is a documented best practice to not exceed 200 SVMs running on a single cluster at any given time to ensure consistent performance and responsive management operations.

Without Share Servers.  With the clustered Data ONTAP driver without share server support, data LIFs are reused and the provisioning of new Manila shares (i.e. FlexVol volumes) is limited to the scope of a single SVM.

The Storage Service Catalog (SSC) is a concept that describes a set of capabilities that enables efficient, repeated, and consistent use and management of storage resources by the definition of policy-based services and the mapping of those services to the backend storage technology. It is meant to abstract away the actual technical implementations of the features at a storage backend into a set of simplified configuration options.

The storage features are organized or combined into groups based on the customer needs to achieve a particular scenario or use case. Based on the catalog of the storage features, intelligent provisioning decisions are made by infrastructure or software enabling the storage service catalog. In OpenStack, this is achieved together by the Manila filter scheduler and the NetApp driver by making use of share type extra-specs support together with the filter scheduler.

When the NetApp unified driver is used with a clustered Data ONTAP storage system, you can leverage extra specs with Manila share types to ensure that Manila shares are created on storage backends that have certain properties (e.g. thin provisioning, disk type, RAID type) configured.

Extra specs are associated with Manila share types, so that when users request shares of a particular share type, they are created on storage backends that meet the list of requirements (e.g. available space, extra specs, etc). You can use the specs in Table 6.10, “NetApp supported Extra Specs for use with Manila Share Types” later in this section when defining Manila share types with the manila type-key command.

Caution

When using the Manila driver without share server management, you can specify a value for the netapp_login option that only has SVM administration privileges (rather than cluster administration privileges); you should note some advanced features of the driver may not work and you may see warnings in the Manila logs, unless appropriate permissions are set. See the section called “Account Permission Considerations” for more details on the required access level permissions for an SVM admin account.