Key Concepts
Share
A Manila share is the fundamental resource unit allocated by the Shared
File System service. It represents an allocation of a persistent,
readable, and writable filesystem that can be accessed by OpenStack
compute instances, or clients outside of OpenStack (depending on
deployment configuration). The underlying connection between the
consumer of the share and the Manila service providing the share can be
achieved with a variety of protocols, including NFS and CIFS (protocol
support is dependent on the Manila driver deployed and the selection of
the end user).
Warning
A Manila share is an abstract storage object that may or may not
directly map to a “share” concept from the underlying backend
provider of storage.
Manila shares can be identified uniquely through a UUID assigned by the
Manila service at the time of share creation. A Manila share may also be
optionally referred to by a human-readable name, though this string is
not guaranteed to be unique within a single tenant or deployment of
Manila.
The actual capacity provisioned in support of a Manila share resides on
a single Manila backend within a single resource pool.
Backend
A Manila backend is the configuration object that represents a single
provider of resource pools upon which provisioning requests for shared
file systems may be fulfilled. A Manila backend communicates with the
storage system through a Manila driver. Manila supports multiple
backends to be configured and managed simultaneously (even with the same
Manila driver).
Note
A single Manila backend may be defined in the [DEFAULT] stanza
of manila.conf; however, NetApp recommends that the
enabled_share_backends configuration option be set to a
comma-separated list of backend names, and each backend name have
its own configuration stanza with the same name as listed in the
enabled_share_backends option. Refer to the section called
“Theory of Operation: Manila.conf” for an example of the use of this option.
Storage Pools
With the Kilo release of OpenStack, Manila has introduced the concept of
“storage pools”. The backend storage may present one or more logical
storage resource pools from which Manila will select as a storage
location when provisioning shares. In releases prior to Kilo, NetApp’s
Manila drivers contained some logic that determined which aggregate a
Manila share would be placed into; with the introduction of pools, all
scheduling logic is performed completely within the Manila scheduler.
Important
For NetApp’s Manila drivers, before Xena release, a Manila storage pool is
an aggregate defined within ONTAP. From Xena release, the storage pool can
be either an aggregate (FlexVol provisioning) or a set of aggregates
(FlexGroup provisioning, see Deployment Choice: Utilizing FlexGroup Pool).
Driver
A Manila driver is a particular implementation of a Manila backend that
maps the abstract APIs and primitives of Manila to appropriate
constructs within the particular storage solution underpinning the
Manila backend.
Caution
The use of the term “driver” often creates confusion given common
understanding of the behavior of “device drivers” in operating
systems. The term can connote software that provides a data I/O
path. In the case of Manila driver implementations, the software
provides provisioning and other manipulation of storage devices but
does not lay in the path of data I/O. For this reason, the term
“driver” is often used interchangeably with the alternative (and
perhaps more appropriate) term “provider”.
A Manila share type is an abstract collection of criteria used to
characterize Manila shares. They are most commonly used to create a
hierarchy of functional capabilities that represent a tiered level of
storage services; for example, a cloud administrator might define a
premium share type that indicates a greater level of performance
than a basic share type, which would represent a best-effort level
of performance.
The collection of criteria is specified as a list of key/value pairs,
which are inspected by the Manila scheduler when determining which
resource pools are able to fulfill a provisioning request. Individual
Manila drivers (and subsequently Manila backends) may advertise
arbitrary key/value pairs (also referred to as capabilities) to the
Manila scheduler for each pool, which are then compared against share
type definitions when determining which pool will fulfill a provisioning
request.
Snapshot
A Manila snapshot is a point-in-time, read-only copy of a Manila share.
Snapshots can be created from an existing Manila share that is
operational regardless of whether a client has mounted the file system.
A Manila snapshot can serve as the content source for a new Manila share
when the Manila share is created with the create from snapshot option
specified.
Important
In the Mitaka and Newton release of OpenStack, snapshot support is
enabled by default for a newly created share type. Starting with the
Ocata release, the snapshot_support extra spec must be set to
True in order to allow snapshots for a share type. If the
‘snapshot_support’ extra_spec is omitted or if it is set to False,
users would not be able to create snapshots on shares of this share
type.
Other snapshot-related extra specs in the Ocata release (and later)
include:
If an extra-spec is left unset, it will default to ‘False’, but a
newly created share may or may not end up on a backend with the
associated capability. Set the extra spec explicitly to False,
if you would like your shares to be created only on backends that do
not support the associated capabilities. For a table of NetApp
supported extra specs, refer to Table 6.10,
“NetApp supported Extra Specs for use with Manila Share Types”.
Important
From Ussuri release, a share can be created from a snapshot and be placed
in a pool or backend different from the parent share. To allow shares to
be placed in other pools or backends, make sure to set
use_scheduler_creating_share_from_snapshot=True in the manila
configuration file.
To perform the operation across clusters, the replication feature must be
enabled and the back end property replication_domain must be
configured. More details are available here.
Share Group
A Manila share group is a grouping construct that makes it possible
to group shares. Share groups make it possible to perform actions
on a group of shares, such as generating consistent, point-in-time
snapshots simultaneously. Share group snapshots can be created from
an existing Manila share group. All shares stored in a share group
snapshot can be restored by creating a share group from a share group
snapshot.
Note
When using NetApp’s Manila drivers, before Xena release, Share Groups are
synonymous with the conventional Consistency Group construct. From Xena,
if FlexGroup pool is configured, the consistency group is not supported, so the
Share Groups will not have the features of a Consistency Group.
Beginning with the Rocky release, OpenStack recommends the usage of Share
Groups to create a grouping construct which operates on groups of shares.
Note
All shares in a share group must be on the same share network
and share server.
Warning
From Xena release, configuring FlexGroup pool drops the consistency group
support for the entire backend. Even FlexVol pools lose its support.
Share Access Rules
Share access rules define which clients can access a particular Manila
share. Access rules can be declared for NFS shares by listing the valid
IP networks (using CIDR notation) which should have access to the share.
In the case of CIFS shares, the Windows security identifier (SID) can be
specified.
Important
For NetApp’s Manila drivers, share access is enforced through the
use of export policies configured within the NetApp storage
controller.
Warning
There is an outstanding issue when attempting to add several access
rules in close succession. There is the possibility that the share
instance access-rules-status will get changed to a status of
“updating multiple” on the API after the manager has already checked
if the status is “updating multiple”. This error will cause the
allow/deny APIs to become stuck for this particular share instance.
If this behavior is encountered, there are two potential
workarounds. The least disruptive solution is to deny any already
applied rule and then add back that same rule as was just deleted.
The second solution is to restart the Manila driver in order to
invoke a resync of access rules on the backend driver.
Security Services
Security services are the concept in Manila that allow Finer-grained
client access rules to be declared for authentication or authorization
to access share content. External services including LDAP, Active
Directory, Kerberos can be declared as resources that should be
consulted when making an access decision to a particular share. Shares
can be associated to multiple security services.
Important
When creating a CIFS share, the user will need to create a Security
Service with any of the 3 options (LDAP, Active Directory or
Kerberos) and then add this Security Service to the already created
Share Network.
Important
Starting from Wallaby release, Manila is able to add/update security
services that are currently being used. Updating a security service requires
that both former and latter security servers have the same type. While
adding a security service to an in-use share network, make sure that the
share network does not contain any security service of the same type,
otherwise the operation will be denied. For more details on such operations,
please refer to the
security service modification session
Share Networks
A share network is an object that defines a relationship between a set of
tenant’s networks/subnets (as defined in an OpenStack network service
(Neutron or Nova-network)) and the Manila shares created by the same
tenant; that is, a tenant may find it desirable to provision shares such
that only instances connected to a particular OpenStack-defined network
have access to the share.
Note
As of Kilo, share networks are no longer required arguments when
creating shares.
Share Network Subnets
A share network subnet is an entity that defines a relationship between a
single tenant’s network/subnet (as defined in an OpenStack network
service (Neutron)) and the Manila share instance created by the same.
Since Train release, such information that once belonged to the share network
entity, is now under the share network subnet object.
This change led to another change in the share server object, which is now
associated to a share network subnet instead of a share network.
The share network subnet is defined for each Availability Zone (AZ) during
share network creation. From Yoga release, a single AZ of the share network
can be configured with multiple share network subnets (they must be on the
same VLAN segment).
Share Servers
A share server is a logical entity that manages the shares that are
created on a specific share network. Depending on the implementation of
a specific Manila driver, a share server may be a configuration object
within the storage controller, or it may represent logical resources
provisioned within an OpenStack deployment that are used to support the
data path used to access Manila shares.
Share servers interact with network services to determine the
appropriate IP addresses on which to export shares according to the
related share network. Manila has a pluggable network model that allows
share servers to work with OpenStack environments that have either
Nova-Network or Neutron deployed. In addition, Manila contains an
implementation of a standalone network plugin which manages a pool of IP
addresses for shares that are defined in the manila.conf file. For
more details on how share servers interact with the various network
services, please refer to Figure 6.2. Manila Workflow - Share Creation with Share Servers and Figure 6.3. Manila Workflow - Share Creation without Share Servers.
Important
Within the NetApp Manila driver, a share server is defined to be a
storage virtual machine (also known as a Vserver) within the
ONTAP system that is associated with a particular
backend. The NetApp Manila driver has two operating “modes”:
One that supports the dynamic creation of share servers (SVMs)
for each share network - this is referred to as the NetApp
Manila driver with share server management.
One that supports the reuse of a single share server (SVM) for
all shares hosted from a backend - this is referred to as the
NetApp Manila driver without share server management.
Important
Starting from the Stein release, Manila supports managing and unmanaging share
servers. This makes it possible to import share servers and manage them using
Manila. For a detailed example, refer to the
Importing and exporting Manila Share servers.
Note
From Train release, the share server is no longer associated to a share
network, but with the share network subnet instead.
Share Replicas
Share replicas are a way to mirror share data to another storage pool so
that the data is stored in multiple locations to allow failover in a
disaster situation. Manila currently allows three types of replication:
writable, readable, and DR.
Writable - Synchronously replicated shares where all replicas are
writable. Promotion is not supported and not needed.
Readable - Mirror-style replication with a primary (writable) copy
and one or more secondary (read-only) copies which can become
writable after a promotion of the secondary.
DR (for Disaster Recovery) - Generalized replication with secondary
copies that are inaccessible. A secondary replica will become the
primary replica, and accessible, after a promotion.
Important
The NetApp Unified Driver for ONTAP provides DR replication only if you are
operating without Share Server management until Stein Release. From Train
release, the NetApp Unified Driver for ONTAP with Share Server
management does support DR style replication. From Xena release, the NetApp
Unified Driver also supports the Readable replication type, in older
releases, only the DR type was supported.
Share Migration
Starting with the Ocata release, NetApp’s Manila driver supports
non-disruptive migration of Manila shares - along with the filesystem
metadata and snapshots, if desired. This can be useful in a variety of
use-cases, such as during maintenance or evacuation.
Share migration is a 2-step process which includes starting the
migration process using the manila migration-start command, and then
completing the process using the manila migration-complete command.
For the list of migration commands, refer to
“Table 6.9, “Manila API Overview - Share Migration”.
Caution
FlexGroup shares cannot be migrated.
Share Management
Managing and unmanaging of shares is an admin-only operation that makes it
possible to control the visibility of shared filesystem storage with respect
to Manila. Managing a share refers to registering a non-Manila share with its
size, shared filesystem protocol, share-server and export path into Manila
management. Unmanaging a share refers to unregistering a Manila share and
removing it from Manila’s database. The unmanage option can be reverted, thus
making it possible to import the share to Manila control if desired.
Important
When managing a share, Manila assigns a new UUID to the share and renames
the share on the storage backend to the following format: share_<share_instance_id>.
This ensures that the same share cannot be managed twice.
Share Server Management
Since share-servers are logical containers that associate shares with share-networks,
there is also a provision to manage and unmanage them. Admin users can manage
share-servers by specifying the host, share-network and the driver-specific identifier
that are used to uniquely identify the share-server. This functionality helps in
importing share-servers and their associated shares and snapshots that were created
in another system/deployment. Similarly, share-servers can also be unmanaged and
removed from Manila’s database.
Important
When managing a share-server, Manila assigns a new UUID to the share-server
and renames the share-server on the storage backend to the following format:
os_<id>, where <id> is the newly assigned UUID. This ensures that the
same share-server cannot be managed twice.
Share Server Migration
Starting with the Victoria release, NetApp’s Manila driver supports the
migration of Manila share servers - along with its shares, snapshots and access
rules. This functionality can be useful to handle situations like back end
evacuation or optimization.
As with share migration, a 2-phase approach is available, which allows
administrators control the right time to complete the operation, which ends on
clients disruption. This process of migrating share servers involves different
operations, but you need only to “start” the migration, and after the service
has completed the first phase of the migration, request to “complete” the
operation, in the moment that the disruption of clients can occur. For the list
of all share server migration commands, refer to
“Table 6.10, “Manila API Overview - Share Server Migration”.
Important
In order to have share server migration working across ONTAP clusters, they
must be peered in advance and have a valid SnapMirror license installed.
Share Server Migration With SVM DR
NetApp’s Manila driver supports share server migration if all the
following restrictions are fulfilled:
Source and destination back ends belong to different clusters;
Source and destination clusters have the same ONTAP system version, which
must be greater than or equal to 9.4;
Source and destination share networks don’t have different security service
configurations;
Source and destination back ends have compatible capabilities (FlexVol
Encryption, SnapRestore license, etc);
Destination back end must have enough free space to handle the source share
server and all its shares and snapshots;
The requested migration can be disruptive;
The share server does not contain any FlexGroup share.
Share Server Migration With SVM Migrate (Available From Xena Release)
SVM Migrate, different from SVM DR is a NetApp specific mechanism developed
to allow administrators to move entire share servers from one cluster to
another. This mechanism is meant to actually migrate share servers in a very
efficient way. This migration mechanism supports non-disruptive migrations,
as long as no network changes are perceived when an administrator specifies a
new share network in the migration start process.
NetApp’s Manila driver supports share server migration using SVM Migrate on
Xena release if all the following requirements are met:
Source and destination back ends belong to different clusters;
Source and destination clusters have the same ONTAP system version, which
must be greater than or equal to 9.10;
Source and destination share networks don’t have different security service
configurations;
Source and destination back ends have compatible capabilities (FlexVol
Encryption, SnapRestore license, etc);
Destination back end must have enough free space to handle the source share
server and all its shares and snapshots;
The share server does not have NFS version 4.0 enabled;
Both source and destination clusters are AFF;
Both source and destination clusters contain a pre created policy from type
‘migrate’.