NetApp Back End Guide for the Shared File System Service
Deploying Multiple NetApp Back Ends for the Shared File System Service in a Red Hat OpenStack Platform Overcloud
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. Introduction
The OpenStack Shared File Systems service (manila) enables users to provision shared file systems that can be consumed by multiple compute instances.
This release supports the use of the NetApp unified driver (
manila.share.drivers.netapp.common.NetAppDriver). This driver allows the Shared File System service to use NetApp storage controllers (running Data ONTAP) as a back end.
The recommended method for configuring a Shared File System back end is through the director. Doing so involves writing a custom environment file.
Chapter 2. Requirements
The following sections assume that:
- A NetApp storage controller is deployed and ready to be used as a back end.
- You intend to use only one NetApp storage controller as a back end for your Shared File System service.
- You can use the director installation user account, which is created as part of the overcloud deployment. For more information, see Creating the stack user in the Director Installation and Usage guide.
- The Shared File System service will still be installed on the Controller nodes, as is the default behavior.
This document does discuss the different deployment configurations possible for your NetApp back end. To learn more about possible NetApp storage deployment configurations suitable for the Shared File System service, consult the upstream NetApp documentation (in particular, see Theory of Operation and Deployment Choices).
After mapping your target configuration (the settings you want for each NetApp back end), you can translate your configuration to a custom environment file. The director uses this file to orchestrate the configuration of your back ends and makes them persistent across overcloud updates.
Chapter 3. Create the Environment File
The director already includes Heat templates to configure most of the necessary settings to integrate a NetApp back end. An environment file allows you to define settings specific to your deployment.
To start, log in as the
stack user on the undercloud and create an environment file with the following contents:
parameter_defaults: ManilaNetappLogin: 'NETAPP_USER' # 1 ManilaNetappPassword: 'NETAPP_USER_PASSWORD' ManilaNetappServerHostname: 'HOSTNAME' # 2 ManilaNetappVserver: 'SVM' # 3 ManilaNetappRootVolumeAggr: 'ROOTVAGGR' # 4 ManilaNetappTraceFlags: 'TRFLAGS' # 5 ManilaNetappDriverHandlesShareServers: 'false' # 6
- Replace NETAPP_USER and NETAPP_USER_PASSWORD with the credentials of the administrative account used to access the storage system (specifically, HOSTNAME).
- Replace HOSTNAME with the storage system or proxy server. The value of this option should be the IP address or hostname of either the cluster management logical interface (LIF) or Storage Virtual Machine (SVM) LIF.
- SVM specifies the storage virtual machine (previously called a vserver) name on the storage cluster on which provisioning of shared file systems should occur. This parameter is required if the driver should operate without managing share servers (that is, be limited to the scope of a single SVM).
- ROOTVAGGR specifies the name of the aggregate upon which the root volume should be placed when a new storage virtual machine (SVM) is created to correspond to a manila share server. This parameter is required if the value of
ManilaNetappDriverHandlesShareServersis set to
true, which means the driver manages the life cycle of share servers. This value is not required if the value of
- Replace TRFLAGS with a comma-separated list of options that control which trace info is written to the Shared File System service logs when the debug level is set to
True. Supported values include
ManilaNetappDriverHandlesShareServersparameter sets whether the driver should handle the lifecycle of the share server (
falsemeans it should not).
parameter_defaults: ManilaNetappLogin: 'netapp_user' ManilaNetappPassword: 'netapp_user_password' ManilaNetappServerHostname: '10.8.18.108' ManilaNetappVserver: 'vserver_1' ManilaNetappTraceFlags: 'method,api' ManilaNetappDriverHandlesShareServers: 'false'
The next section describes how to use the
/home/stack/templates/netapp-config.yaml environment file to orchestrate the configuration of your NetApp back end.
Chapter 4. Deploy the Shared File System Service with NetApp Back Ends
After you create
/home/stack/templates/netapp-config.yaml, log in as the
stack user on the undercloud and deploy the configured back end by running:
$ source ~/stackrc $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml -e /home/stack/templates/netapp-config.yaml
/usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml used here is the environment file provided with the director for deploying NetApp back ends for the Shared File System service. The
/home/stack/templates/netapp-config.yaml file created in the previous section allows you to override the default settings to suit your deployment.
If you passed any extra environment files when you created the overcloud, pass them again here by using the
-e option to avoid making undesired changes to the overcloud. For more information, see Modifying the Overcloud Environment in the Director Installation and Usage guide.