How Can We Help?
NetApp Operational Recommendations
The following are recommendations that should be used when deploying NetApp Clustered ONTAP (cDOT or 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 a specific environment.
### Use Lower Case 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, even in cases such as this, if the opportunity is there, change to lower case if it won’t have any adverse effect on resources (specifically with NFS exports).
### General
* **Autosupport** – add `AutoSupport@red8.com` to both the `-to` and `-partner-address` fields. For end-user destinations, using the `-noteto` field is sufficient; however, if needed, you can use the full autosupport message with the attachments used in the `-to` field.
* **Local Support Account** – create a local service account for vendor access (i.e., `red8svc` or `ntapsvc`) with a password of your choosing and application access of **Console**. If the services are being performed remotely (i.e. via VPN or WebEx) include application access of **SSH**, **Service-Processor** and **HTTP**. This account should only be used when a vendor is performing service on the cluster(s) and should be locked when not in use. This eliminates the need for the vendor to know the `admin` account password.
* **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, you can use the AD domain controllers as the SNTP server and enter the AD domain FQDN. It is recommended to have at least two SNTP server entries. If there is not a dedicated SNTP server, you can use `us.pool.ntp.org`. This can be used as a secondary if there is no secondary server. The complete list of NTP servers can be found at [NTP Pool Project](http://www.pool.ntp.org/en/) if the deployment is outside of the US.
### Maintenance
It is best practice to keep the ONTAP environment up-to-date with firmware, patches, and OS updates. While it is understood that a production environment does not need to be on the “bleeding edge” of all OS updates, it is recommended to maintain certain levels to prevent system outages or data loss. Outside of NetApp service advisements, Red8 recommends the adoption of a scheduled update process for preventative maintenance of the environment.
> **NOTE:** ONTAP is different from 7-Mode in that you can not copy files directly to the cluster(s). For methods to perform updates, please review [Configure Workstation for HTTP or TFTP Services](https://github.com/RedEight/NetApp/wiki/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 this, 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](http://mysupport.netapp.com/matrix/#welcome) before 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 the final testing phase are added to a subsequent maintenance release. Exceptions are clearly communicated in the public report for the controlling bug. Red8 recommends deploying the latest P release of the target code level that has been selected.
* _Debug (D) Release_ – A debug release is an exception hot-fix release that is used on an urgent, as-needed basis. These releases are generally not 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 one particular customer.
* Changes do not automatically roll into the next maintenance release.
* May be deployed for customers 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 updating the disk drive, disk shelf, and disk qualification files quarterly. The updates and the process can be found at:
* [Disk Drive & Firmware Matrix](http://mysupport.netapp.com/NOW/download/tools/diskfw/)
* [Disk Shelf Firmware](http://mysupport.netapp.com/NOW/download/tools/diskshelf/)
* [Disk Qualification Package Instructions](http://mysupport.netapp.com/NOW/download/tools/diskqual/)
* [NetApp® CN1601 and CN1610 Switches](http://mysupport.netapp.com/NOW/download/software/cm_switches_ntap/)
* [Cisco® Ethernet Switches](http://mysupport.netapp.com/NOW/download/software/cm_switches/)
### 7MTT NAS Volumes and Namespace Options
If using the 7MTT process to migrate NAS (CIFS/NFS) data from 7-Mode to ONTAP, the target SVM namespace will be presented with the option on how the volumes are to be mounted and represented in the namespace. There are three 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 changing 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
“`
* **Storage Virtual Machine (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`
“`
svm01_root_DP01
svm01_root_DP02
svm02_root_LS01
svm02_root_LS02
“`
* **Logical Interface (LIF)**
* _Intercluster_ – 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 recommended 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 LIFs_ – unless the SVM is multiprotocol and the need to separate specific protocol traffic over a particular LIF, there should be no reason to have 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** – Before 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 continue 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 types of failover groups that you could have:
* _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.
* _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.
* _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. Two basic formats are recommended: CIDR notation `/` or VLAN `v`. There can be a broadcast domain that has a VLAN tagged port and a non-tagged port as members (i.e., `e0M` and `a0a-500`). Typically used with cluster/node management LIFs, some environments want to have cluster/node management on a tagged port with a failover to a dedicated management port/switch. NetApp’s “My Autosupport” tool will indicate an error condition, which is really a false positive. The `e0M` port can not do VLAN tagging and, when used, is connected to an access port on the switch side. In cases like these, consider using traditional failover groups for cluster management, node management LIFs, and use the formats mentioned above.
“`
192.168.10.0/24
10.17.45.0/16
v100
v215
“`
* **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 more straightforward 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.).
“`
cluster01::> subnet show
(network subnet show)
IPspace: Default
Subnet Broadcast Avail/
Name Subnet Domain Gateway Total Ranges
——— —————- ——— ————— ——— —————
data 10.50.4.0/22 data_v505 10.50.5.1 239/254 10.50.7.1-10.50.7.254
iscsi 10.1.50.0/24 iscsi_v50 – 8/40 10.1.50.201-10.1.50.240
repl 10.1.52.0/24 repl_v52 10.1.52.1 0/0 –
vmnfs 10.1.51.0/24 vmnfs_v51 – 14/30 10.1.51.201-10.1.51.230
4 entries were displayed.
“`