ARX Import Restrictions for NetApp Volumes

Summary

Deciding the optimal points to import a customer’s NetApp filer can be challenging. Ideally the ARX should import at the highest point possible on the filer in order to keep the total ARX Managed Volume count low.

On a NetApp filer the highest possible point would be the volume level. For various technical reasons, which will be discussed below, importing at the NetApp volume level is restricted to a limited set of configurations and should only be used if all technical requirements are met. Some of these restrictions have been lifted with newer versions of ARX code. For environments where importing at the NetApp volume is not possible, the recommended design involves importing at the individual qtree level which may require additional Managed Volumes and hence a larger ARX configuration. This App Note will cover the various options for Volume vs. qtree level import.

NetApp Qtree Overview

Some ARX features are bounded by restrictions of certain operations when qtrees are used within NetApp volumes. A qtree is defined as a special subdirectory in a volume that acts as a virtual sub-volume with special attributes, primarily quotas and permissions. Below is an example of a NetApp volume with multiple qtrees. Note that a qtree can only exist at the root path of the volume.

Since qtrees are essentially separate file systems that can even store different permissions sets such as UNIX vs. NTFS some operations are simply not possible between qtree boundaries. This is true for any NFS or CIFS client as well as for the ARX.

Namespace Design Considerations

When sizing a customer environment to determine the number of Managed Volumes needed within the ARX, a determination must be made on the optimal point for the ARX to import the existing file systems. Both the NetApp volume and the qtrees within the volume can be considered possible points of import. Since there is a finite number of Managed Volumes within each ARX system, the namespace design needs to ensure the number of supported Managed Volumes is not exceeded.

How Many Managed Volumes are Required?

When sizing a customer environment, the total number of ARX Managed Volumes is needed to properly select the right ARX platform. To accomplish this, a determination must be made on the optimal point for the ARX to import the existing file systems. There may be more than one option when picking which locations are best for import into ARX Managed Volumes. A Managed Volume consists of shares which are NFS exports or CIFS shares mapping to a physical file system.

A Managed Volume with four shares

Since there is a finite number of Managed Volumes per ARX the namespace design needs to ensure the number of supported Managed Volumes is not exceeded. If the total number of Managed Volumes required will exceed the limits of the chosen ARX platform, then an alternate design may be needed, or possibly a larger ARX platform or additional ARX’s will be required. Below is a summarization of the Managed Volume limits per ARX platform, and per Volume Group within the respective platforms.

Importing at the NetApp Volume Level

It is always best to find the highest point within the file system for the ARX to import to reduce the number of ARX Managed Volumes required. There are cases where the highest possible export or share cannot be used. Using a NetApp filer as an example the highest level exports/shares that exist are at the NetApp Volume level. Although importing at the NetApp Volume would be ideal for the ARX because there are fewer volumes than qtrees, it is not always possible.

NetApp volumes may contain qtrees, which are file systems unto themselves so importing at the NetApp volume layer may hide certain file system characteristics from the ARX. In general the ARX can only import at the NetApp Volume level if the security style (UNIX/NTFS) of the volume, and all child qtrees within the volume are identical. NetApp MIXED mode security style is not supported by ARX under any circumstances. MIXED mode qtrees or volumes must be converted to NTFS or UNIX and re-permissioned before importing into an ARX Managed Volume.

If there is a mix of different security styles within the volume then import must occur at the qtree level to avoid potential conflicts in file system capabilities. Below is a summary of what environments are right for import at the NetApp volume level and which ones are not.

Within a NetApp filer, volumes and qtrees may be configured to support different security styles; either NTFS, UNIX, or MIXED. In order for the ARX to import a NetApp Volume that contains qtrees, the volume as well as all child qtrees within the volume must be configured for the same security style. They must be all NTFS or all UNIX, the ARX does not support MIXED mode.

Prior to DMOS version 6.1.0 the ARX did not support import at the NetApp Volume level if the volume was accessed in a Multiprotocol manner (CIFS + NFS concurrently). This restriction has now been lifted in DMOS 6.1.0 and later so that the ARX can now import at the Volume level in any case as long as the security styles are consistent within the Volume.

Below is an example of NetApp volumes that contain qtrees that are configured for the same security style. As long as DMOS 6.1.0 or later is used, these can now be imported at the NetApp Volume level even if they are accessed using multiprotocol.

If the NetApp Volume contains no qtrees currently, and will not in the future, then ARX import at the NetApp Volume level is supported.

ARX Import at the NetApp Volume level is not supported if the Volume or any of its child qtrees contain differing security styles. The Volume and its child qtrees must either be all NTFS, or all UNIX. Below is an example of a NetApp volume with both NTFS and UNIX qtree security styles. In this case Volume level import is not possible, so the ARX will be forced to import the individual qtrees or the customer must re-align their volumes so that they have uniform security styles.

If the NetApp Volume is exported multiprotocol (NFS and CIFS concurrently) then import at the NetApp Volume level is not supported unless DMOS 6.1.0 or later is used, even if the Volumes and all qtrees are all the same security style. Below is an example of non-supported configurations for volume level import because of multiprotocol with qtrees and the older DMOS versions. Upgrading to DMOS 6.1.0 or later will allow Volume level import in these cases.

Other Considerations for Volume Level Import

Importing at the NetApp Volume level will also prevent two ARX features from working. The Save-on-Migrate feature, also known as migrate-retain-files, will not work when NetApp Volume level import is performed. ARX Shadow Copy replication is not allowed on any ARX Managed Volume where an import occurred at the NetApp Volume level. These unsupported configurations for NetApp volume level import are depicted below:

Other considerations for NetApp Volume level import are quotas, and qtree creation. The ARX will track and report free space based on the level it imports using the proxy user or root to query free space. If there are qtree quotas then the ARX will may not report them correctly. There are free space enhancements in DMOS 6.1.0 that may allow the ARX to report free space more accurately in these environments. Check with your F5 SE for more details.

Qtrees will appear as normal directories in the root of the Managed Volume to the ARX. If a new qtree needs to be added after a NetApp volume has been imported it will result in a metadata inconsistency. Qtrees cannot be created by NFS or CIFS clients accessing the NetApp through ARX, they must be created via the NetApp CLI or GUI. This will be analogous to creating a new directory behind the ARX from a client. In order for this new qtree to be visible to clients the ARX metadata must be updated. A manual sync directory must be run to add the new qtree to ARX metadata and then it will be accessible to clients through the ARX. This can be done via the ARX CLI or GUI after the qtree has been added. The qtree must be empty in order for the directory sync to detect and add the new qtree to ARX metadata.

How to Reduce Managed Volume Count with Qtree Level Imports

If the environment has more file systems than can be handled by the desired ARX platform, then alternate cut-in techniques such as using the ARX’s presentation namespace, aggregating more than one file system per Managed Volume, or possibly larger ARX platforms needs to be explored. Below is an example of merging multiple NetApp file systems (qtrees) into a single ARX Managed Volume to reduce total Managed Volume count on the ARX. In this case four file systems are being merged into a single Managed Volume. Although NetApp was used in this example the same concept applies to any vendors file systems.

When merging more than one file system into a single Managed Volume a detailed collision analysis must be performed. This can be done via the no-modify import functionality on the ARX to generate reports of any potential conflicts. Once collisions are understood they can be corrected manually before import, or the ARX can rename offending collisions during import if given permission to do so by the administrator. If there are any common directory names, then they will merge (assuming permissions are the same) as long as the parent directory structure is the same. Clients connecting to this Managed Volume through the ARX will see the aggregated content from all file systems. Below is an example of a client’s view of the merged file systems.

If each file system has unique top level directories then the merging will be clean, and no collisions will occur. Clients that connect to the root share or export will end up seeing the aggregated top level directory structure from all the file systems as seen on the left of the diagram below. Clients that map to shares exporting below this level, (or NFS mounting below this level) will not see any merged content as long as the parent directory structure is unique on each file system. This is seen on the right of the diagram below.

Some installations have chosen to manually introduce a unique top level directory per file system to eliminate potential merging of data and collisions. Just before ARX import, all top level folders are moved into the unique empty top level directory. This will guarantee a clean merge of the file systems, and client presentation can still be preserved by sharing out from the unique top level directory or any sub-directory as seen below:

The aggregation example above is useful if a migration is required to move all these file systems to a single target. Since the ARX policies operate within the confines of a Managed Volume the file systems need to be merged before they are migrated. Instead of running a collision analysis the data could be pushed down into a unique top level directory which would ensure that there are no collisions.

ARX migration policies do not run between Managed Volumes. If data is to be migrated from one file system to another they must reside within the same ARX Managed Volume. Many F5 customers have taken advantage of this flexibility to re-layout their data as part of the migration.

Author Bio

Jim McCarron is a Manager of Field Systems Engineering for the F5 Data Solutions (ARX/Data Manager/ARX-CE) Sales business unit.