此内容没有您所选择的语言版本。
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
Abstract
Chapter 1. Introduction to NetApp back ends
With the OpenStack Shared File Systems service (manila) you can provision shared file systems that can be consumed by multiple compute instances.
This release supports 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.
With the director you can deploy the Shared File System with a NetApp back end on the overcloud.
Chapter 2. Requirements for NetApp back ends
Prerequisites
- 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 you create as part of the overcloud deployment. For more information about the director user account, see Preparing for director installation in the Director Installation and Usage guide.
- You want to install the Shared File System service on the Controller nodes. This is the default installation method.
This document does not contain information about the different deployment configurations possible for your NetApp back end. For more information about possible NetApp storage deployment configurations suitable for the Shared File System service, see the upstream NetApp documentation in particular, the Theory of Operation and Deployment Choices.
After you complete the configuration for each NetApp back end, you can translate your configuration to a custom environment file and include this environment file in the deployment command. The director uses this file during deployment to orchestrate the configuration of your back end configuration and persists across overcloud updates.
Chapter 3. Creating the NetApp back end environment file
The director already includes default heat templates that configure most of the necessary settings to integrate a NetApp back end. You can also use a custom environment file 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:
/home/stack/templates/netapp-config.yaml
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
- 1
- Replace NETAPP_USER and NETAPP_USER_PASSWORD with the credentials of the administrative account used to access the storage system (specifically, HOSTNAME).
- 2
- Replace HOSTNAME with the storage system or proxy server. This value must be the IP address or hostname of either the cluster management logical interface (LIF) or Storage Virtual Machine (SVM) LIF.
- 3
- SVM specifies the storage virtual machine, previously called a vserver, on the storage cluster where you want to provision shared file systems. This parameter is required if you want the driver to operate without managing share servers. That is, to be limited to the scope of a single SVM.
- 4
- ROOTVAGGR specifies the name of the aggregate where you want to place the root volume when a new storage virtual machine (SVM) is created to correspond to a manila share server. This parameter is required if you set the value of
ManilaNetappDriverHandlesShareServerstotrue, which means the driver manages the life cycle of share servers. This value is not required if the value ofManilaNetappDriverHandlesShareServersisfalse. - 5
- 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 includemethodandapi. - 6
- Set the
ManilaNetappDriverHandlesShareServersparameter totrueorfalseto enable or disable lifecycle management of the share server.
For example:
/home/stack/templates/netapp-config.yaml
parameter_defaults: ManilaNetappLogin: 'netapp_user' ManilaNetappPassword: 'netapp_user_password' ManilaNetappServerHostname: '10.8.18.108' ManilaNetappVserver: 'vserver_1' ManilaNetappRootVolumeAggr: 'aggr1_n1' ManilaNetappTraceFlags: 'method,api' ManilaNetappDriverHandlesShareServers: 'false'
Chapter 4. Deploying the Shared File Systems service with NetApp back ends
This section describes how to use the /home/stack/templates/netapp-config.yaml environment file to orchestrate the configuration of your NetApp back end.
After you create the /home/stack/templates/netapp-config.yaml, environment file, 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
The /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml file is the default heat template provided with the director to deploy NetApp back ends for the Shared File System service. The /home/stack/templates/netapp-config.yaml file that you create in Chapter 3, Creating the NetApp back end environment file applies your custom configuration on top of the configuration in the default heat template.
If you passed any extra environment files when you created the overcloud, pass them again here 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.
Test the back end after director orchestration is complete.
