Policy-based provisioning of NAS Storage on a vFiler with SnapVault backup

by Frequent Contributor on ‎2013-03-22 04:20 AM

This is a  workflow example which generates a CIFS and/or NFS-accessible storage area and, optionally, snapvault storage as well. It uses a number of custom functions and some possibly interesting features:

- All storage must be provisioned from a vfiler.

- The necessary size for the volume is calculated from the size of the dataset and some standard policies (the expected amount of data (=dataset) should make the user-visible portion of the volume 85% full).

- Storage selection is based on the Service Class, Location, and VLAN used to access the NAS data.

Two structures are needed in DFM to make this work:

1. Service class is defined by a DFM group "ServiceClasses". The members of that group are the various service classes themselves. Each service class group has array members which are members of that service class. Thus ServiceClass->Foo->Bar means that the array Bar is a member of the Foo service class. For provisioning primary storage, the service class NEARSTORE is excluded from the selection.

2. Location is defined by the DFM group "Locations", which is structured in the same manner as ServiceClasses.

The VLAN selection criteria requires that the storage being created be available on the selected VLAN. This limits the possible vfilers which may be used to provision the data. The vlan user query currently limits the selectable VLANs to those starting with 'vlan-' or 'storage-', you will probably have to change these in your environment.

- Once the vfilers are found that match the above criteria, the containing arrays are ordered by CPU usage (lowest to highest, based on one standard deviation above average over the last week) and the controller with the lowest usage is selected. The aggregates on that controller are ordered from lowest to highest IOPS usage in the same manner and the least-loaded aggregate with sufficient space is selected.

- An operator override is provided; if the automatically selected aggregate/array/vfiler is unsuitable for some reason (for example, that aggregate is about to be removed from the system, or the vfiler is dedicated for a different application), the operator can change the selection to any other aggregate/array/vfiler which matches the primary selection criteria (Service Class, Location, and VLAN).

- The location for the optional SnapVault relationship is handled similarly, although the operator need only specify the Location (as the NEARSTORE service class will automatically be selected and no vfilers are used in that storage class). The SnapVault relationship is built between vfiler0 units and the operator needs to select over which common network the SnapVault traffic should flow. The relationship is updated once per day at a randomly selected time. There is a custom command which handles creating this SnapVault relationship.

Warning!

This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.

In accordance to our Code of Conduct and Community Terms of Use DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information
  • Copyrighted materials without the permission of the copyright owner

Files and content that do not abide by the Community Terms of Use or Code of Conduct will be removed. Continued non-compliance may result in NetApp Community account restrictions or termination.