Categories

NetApp Operational Recommendations

Created On
Last Updated On
bypreshmarketing
Print
You are here:
< All Topics

The following recommendations should be considered when deploying NetApp Clustered ONTAP (cDOT/ONTAP) systems. It is understood that some items may not be in every environment and that there may be preexisting standards for others. However, if there are no preexisting standards, this should be viewed as a base to start from and can be adjusted to fit within certain environments.

Use Lowercase Letters

Since ONTAP has UNIX-like qualities where case matters (i.e. vol1, Vol1, VOL1 are all different), it is recommended to use lower case letters for all items, with a few exceptions (to be listed below). Other exceptions may also come from volumes that have been transitioned over from 7-Mode environments as a result of the 7-Mode Transition Tool (7MTT). However, in such cases, if the opportunity exists, change to lower case if it will not have any adverse effect on resources (specifically with NFS exports).

General

  • Administrative Account – Configuring administrative access to clustered Data ONTAP is a necessary first step to securing the system. Starting with a new installation, it is necessary to configure the cluster-level (Cserver) admin accounts first. Then, after SVMs are created, each SVM (Vserver) administrator can configure additional SVM administrator accounts within that SVM as needed. Setting up an administrative account (whether cluster-level Cserver or SVM-level Vserver) follows the same process. For admin accounts it is recommended:
    • Use a separate login ID for each person (no sharing)
    • Unique login passwords for each person should be kept secret
    • Use a sufficiently complicated password and use password policies to enforce complexity

Alternatively, many organizations can benefit from using the same authentication model as for their users (clients). Therefore, they might want to provide a way for administrators to authenticate using LDAP to Active Directory. The article NetApp ONTAP Active Directory Authentication has the procedures for configuration. Additional information on admin account and other security recommendations can be found in Clustered Data ONTAP Security Guidance | TR-4393.

  • Administrative Accounts – if permitted by policy, add AutoSupport@red8.com to both the -to and -partner-address fields. This allows for Red8 engineering to receive any Autosupport messages generated. For internal destinations, using the -noteto field is sufficient, however, if the full autosupport message with the attachments are warranted, use to the -to field. Additionally, as there can only be five email recipients, use of a distribution list, where possible, is preferred.
  • Local Support Account – if permitted by policy, create local service account for vendor access (i.e. red8svc or ntapsvc) with application access of Console, SSH, Service-Processor and HTTP. This account would only be used whenever a vendor is performing service on the cluster(s) and should be locked when not in use. This eliminates the need of the vendor knowing the admin account password.
  • Management LIFs – for both the Cluster Management (cluster_mgmt) and Node Management (node_mgmt1) LIFs, it is recommended to assign them to the e0M port. The e0M port is specifically designated for all management access and does not allow any data access traffic. Red8 configures all cluster and node management to the e0M port.
  • Time Services – Date and time synchronization is a must to provide accurate logging of events in the environment. A dedicated time source (internal/external) is preferred. If this is an Active Directory environment, use the AD domain controllers as the SNTP server by entering in the AD domain FQDN. It is recommended to have at least two SNTP server entries. If there is not a dedicated SNTP server use us.pool.ntp.org. This can be used as a secondary if there is not a secondary server. The complete list of NTP servers can be found at NTP Pool Project for deployments outside of the US.

Maintenance

It is recommended practice to keep the ONTAP environment up-to-date with firmware, patches and OS updates. While it is understood that a production environment need not to be on the “bleeding edge” of all OS updates, it is recommended to maintain certain levels in order to prevent system outages or data loss. Outside of NetApp service advisements, Red8 recommends that the adoption of a scheduled update process for preventative maintenance of the environment.

NOTE: ONTAP is different from 7-Mode in that there is not an easy way to copy files directly to the cluster(s). For methods to perform updates, please review Configure Workstation for HTTP or TFTP Services.

  • ONTAP Updates – ONTAP upgrades, which are non-disruptive, generally are performed for three reasons: deployment of new hardware that requires a minimum code release, to utilize new features in software or to correct an issue (bug) that has occurred in the environment. Outside of these, it is good practice to perform ONTAP upgrades on a biannual schedule as a form of preventative maintenance. For all ONTAP releases, it is imperative that interoperability has been validated by checking the NetApp Interoperability Matrix Tool prior to deployment.
    • Patch (P) Release – A patch release delivers timely fixes for bugs that customers encounter. The majority of customer-requested bug fixes are delivered through patch releases rather than debug (D) releases. P releases are not available before the release is classified as GA.
      • Fixes for customer-encountered bugs
      • 1-2 months build frequency
      • QA regression testing of fixes

      Significant fixes in a P release are in all subsequent maintenance releases for that feature release family. P releases that are provided after the maintenance release has gone into final testing phase are added to a subsequent maintenance release. Exceptions are clearly communicated in the public report for the controlling bug. Red8 recommends the deployment of the latest P release of the target code level that has been selected to be deployed. Additionally, if this is a new install, Red8 will install the latest P release of the target code unless otherwise specified.

    • Debug (D) Release – A debug release is an exception hot-fix release that is used on an urgent, as-needed basis. These releases are not normally planned and are provided only in case of extraordinary need. D release deployment should only be done by the direct recommendation of NetApp Support!
      • Provides a specific change for a specific customer
      • Changes do not automatically roll into the next maintenance release
      • May be deployed for customer who can’t wait for a P release or the next maintenance release
      • Not classified as a GA release
      • Provides fixes that are urgent and cannot wait for the next P release
      • Have limited testing.
  • Firmware Updates – NetApp issues firmware updates for their motherboards, Flash Cache cards, service processors, disk drives, disk shelves and cluster network/management switches. These firmware updates are included in ONTAP updates as well as separately. Red8 recommends the update of the disk drive, disk shelf and disk qualification files on a quarterly basis. The updates and the process to apply the updates can be found at:

7MTT NAS Volumes and Namespace Options

If using the 7MTT process to migrate NAS (CIFS/NFS) data from 7-Mode to ONTAP, the target Storage Virtual Machine (SVM) namespace will be presented with the option on how the volumes are to be mounted and represented in the namespace. There are 3 options:

  • Option 1: Preserve 7-Mode Mount Paths – this option will present all volumes in the format /vol/<7-Mode volume-name>. Only use this option if there are 7-Mode exports that are presented as /vol/volume-name and active *NIX systems are mounting to that export.
  • Option 2: Use 7-Mode Volume Name – this option will mount all volumes in the format of /<7-Mode volume-name> and not allow modifications to the name. This is also the default way that ONTAP would present a non-nested volume and will mount at the root / level of the namespace.
  • Option 3: Use clustered Data ONTAP Volume Name – this option is the preferred option and will mount all volumes in the format of /. This option allows to change the target volume name (i.e. – all lower case and prefixed with _ ) and will mount at the root / level of the namespace.

Naming Conventions

  • Aggregates – use the format __. The exception to this is for the root aggregates which should be _mroot_ONLY.
    cluster01_01_sas01_900g
    cluster01_01_sas02_1200g
    cluster01_01_sata01_4t
    cluster01_02_mroot_ONLY
    cluster01_02_ssd01_3800g
  • SVM Resources – regardless if at the cluster level or the data SVM level, it is recommended that all SVM resources (i.e. volumes, LIFs, polices, etc.) should be prefixed with _.
    svm01_root
    svm01_lif01
    svm01_vol01

    • SVM Root Volume Mirrors (Data Protection/Load Sharing)for these volumes use the format _root_DP or _root_LS. Review NetApp Protecting SVM Root Volume for more information.
      svm01_root_DP01
      svm01_root_DP02
      svm02_root_LS01
      svm02_root_LS02
  • Logical Interface (LIF)
    • Intercluster (SnapMirror) – use the format _IC
      cluster01-01_IC01
      cluster01-02_IC01
    • Fibre Channel – use the format ___fc. This allows for complete identification of where the cable is plugged in on the controller side and which fabric. Additionally, if performing zone documentation on the SAN switch, complete identification of the source can be made. It is recommend to use the complete nodename in the event there are multiple ONTAP clusters in the environment going to the same SAN fabric (UCS, Brocade, etc.).
      svm01_cluster01-01_0e_fcA
      svm01_cluster01-02_0g_fcB
      svm02_cluster02-05_3a_fcA
      svm02_cluster02-06_4a_fcB
    • iSCSI – use the format __iscsi
      svm01_cluster01-01_iscsi01
      svm01_cluster01-02_iscsi01
    • Data LIFsunless the SVM is multiprotocol and the need to separate specific protocol traffic over a specific LIF exists, there should be no reason in having the protocol designated in the LIF name. However, if the protocol for the LIF needs to be specified then use the format _. Admin only LIFs for SVMs would use the format _admin.
      svm01_cifs01
      svm01_lif01
      svm02_admin01
      svm02_nfs01
    • VMware over NFS LIFs – NetApp Best Practices for VMware over NFS have been updated and the original LIF per datastore is no longer suggested. The current recommendation is a single NFS LIF per node where NFS datastores will reside. As such, the suggested LIF name is _vmnfs. This allows for further distinction between NFS LIFs that are being used for application or file services.
      svm01_vmnfs01
      svm01_vmnfs02
  • Failover Groups – prior to ONTAP 8.3, failover groups were used to make sure that network communication for LIFs (admin, data, intercluster, etc.) continued in the event of a network or system failure. In these failover groups, the valid ports for the communication to persist are added. These ports (physical, VLANs, interface groups) would be put in a respective failover group for the SVM and then the failover group would be applied to the respective LIFs. In 8.3+, failover groups have been superseded by Broadcast Domains. There are four general failover groups:
    • Cluster Management – use the format fg-cluster_mgmt and put the ports (physical or logical) on all of the nodes where the cluster management LIF will have valid network access.
    • Node Management – use the format fg-_mgmt and put the ports (physical or logical) of the node where that specific node management LIF will have valid network access. Node management LIFs are local to the controller where they reside.
    • Intercluster – use the format fg-_IC and put the ports (physical or logical) of the node where that specific intercluster LIF will have valid network access. Intercluster LIFs are local to the controller where they reside.
    • Data Access – there are options for data access (CIFS/NFS) LIFs. It can be based on the interface name with the format fg- or, if using VLAN tags, fg-v. Other descriptors can be used but these two represent the simplest form.
      fg-cluster_mgmt
      fg-cluster01-01_mgmt
      fg-cluster01-02_mgmt
      fg-cluster01-01_IC
      fg-cluster01-02_IC
      fg-e0a
      fg-a0a-15
      fg-v75
  • Broadcast Domains – As mentioned above, since ONTAP 8.3, Broadcast Domains have replaced failover groups. Similar to Failover Groups, only the ports (physical, VLANs, interface groups) that are valid for that subnet should be members of the Broadcast Domain. Red8 recommends using CIDR notation /. In some small environments there may not be a separate network for management traffic and the e0M port resides on the same subnet as user data. In cases like these consider creating a separate Broadcast Domain called Admin and place the e0M ports inside.
    192.168.10.0/24
    10.17.45.0/16
    Admin
  • Subnets – Subnets enable the allocation of specific blocks, or pools, of IP addresses for the ONTAP network configuration. This enables the creation of LIFs more easily when using the network interface create command, by specifying a subnet name instead of having to specify IP address and network mask values. A subnet is created within a broadcast domain. It is recommended to use subnets because they make the management of IP addresses much
    easier, and they make the creation of LIFs a simpler process. It also provides the opportunity for better documentation of the environment. It is suggested to name the subnets for the application/traffic type they are used for (i.e. – management, VMware over NFS, iSCSI, data, etc.).
Table of Contents