Planning for upgrading clusters

Before upgrading clustered gFilers

Before upgrading your clustered gFilers, complete the following steps.

Step	Action
1	Verify that the cluster is properly configured by using the Cluster Configuration Checker (cf-config-check.cgi). The Cluster Configuration Checker is a Perl script that detects errors in the configuration of a pair of clustered gFilers. It is available on NOW at http://now.netapp.com/NOW/download/tools/cf_config_check/.
2	Identify and resolve any cluster configuration issues before continuing with the upgrade.
3	Determine the method that you will use to upgrade your cluster.

Step

Action

Verify that the cluster is properly configured by using the Cluster Configuration Checker (cf-config-check.cgi).

The Cluster Configuration Checker is a Perl script that detects errors in the configuration of a pair of clustered gFilers. It is available on NOW at http://now.netapp.com/NOW/download/tools/cf_config_check/.

Identify and resolve any cluster configuration issues before continuing with the upgrade.

Determine the method that you will use to upgrade your cluster.

For more information about the Cluster Configuration Checker, see Chapter 7, "Cluster Management" in the Data ONTAP Storage Management Guide.

Cluster upgrade methods

The following methods are available for how you can upgrade cluster partners:

Nondisruptive
Standard

When planning for your upgrade, evaluate the advantages and disadvantages of each method. Each method is described in this section.

How nondisruptive cluster upgrades work

In a nondisruptive upgrade (also called a rolling upgrade), clustering technology is used to enable a takeover gFiler to assume the functions of the "failed" partner while the failed partner is being upgraded. One gFiler, therefore, is always alive. Because the gFiler's cluster partner fulfills service requests during the gFiler's upgrade, no disruption in service is experienced by the clients.

Additionally, because the takeover gFiler assures continuous availability of the failed gFiler's storage, more extensive upgrades requiring a system halt--such as system firmware upgrades and hardware adapter replacements--can be performed without disrupting services that are based on stateless protocols (such as NFS, FCP, and iSCSI).

NetApp recommends that you use the nondisruptive upgrade procedure to minimize service disruption in your clusters when one or more of the following is being performed:

An upgrade within a release family (for example, from 6.5 to 6.5.1)
A release family is the set of releases that have the same feature release name denoted by the first two digits of the release number; for example, 6.5, 6.5R1, and 6.5.1 are in the same release family.

Note
You cannot use the nondisruptive upgrade method if you are upgrading from a release family earlier than 6.5, for example, from 6.4.1 to 6.5.1.
A system firmware upgrade
See Installing system firmware--nondisruptive cluster method for instructions.
Certain hardware upgrades
See Appendix A, Nondisruptive Hardware Upgrade in a Cluster for more information.

Note
The nondisruptive upgrade process is applicable only to clusters; it cannot be used to upgrade a single node.

There is no advantage to employing nondisruptive upgrades for service availability for gFilers serving CIFS, FTP, and NDMP clients. Because these protocols are session-oriented, sessions must be terminated before upgrade procedures to prevent data loss.

How standard cluster upgrades work

In a standard upgrade, you must disable the cluster and update and reboot each node as quickly as possible. When you disable the cluster, each node behaves as a single-node (non-clustered) gFiler; that is, the system services associated with that node are disrupted for as long as it takes the system to reboot. Other maintenance upgrades, such as system firmware and hardware, must also take place when the cluster is disabled.

In general, standard upgrades are most appropriate when you can schedule a downtime for your gFiler.

You must use a standard upgrade for upgrades between Data ONTAP release families.

Mixing Data ONTAP software versions in clusters

You can run different versions of Data ONTAP 6.5x on cluster partners, for example, 6.5 on one partner and 6.5.1 on the other partner. However, you cannot run 6.4.x on one gFiler in the cluster and 6.5 or later on the other.