Appendix D

Optimizing Service Availability During Upgrades

About this appendix

This appendix explains the factors affecting service availability during upgrades and provides details about service and protocol behavior.

About service availability during upgrades

Service availability during Data ONTAP upgrades can be optimized through planning and configuration. In some cases, upgrades can be completely nondisruptive from the clients' perspective.

The following factors can affect the availability of filer services during upgrades:

Whether the system being upgraded is a single node or a member of a cluster
Clustered systems are designed to provide optimal service availability.

For more information, see Upgrade host requirements.
The types of services licensed and their susceptibility to timeout errors
See Service and protocol considerations.
Upgrading between release families or within a release family
Upgrades between release families involve more steps and are potentially more disruptive than upgrades within a release family.

For more information, see Planning for upgrading filers running SnapMirror.
Whether a system firmware upgrade is required
System firmware upgrades require a system halt and reboot. They can disrupt services in single filer and standard cluster upgrades but do not affect services in nondisruptive cluster upgrades.

For more information, see Upgrading the system firmware.
Whether disk firmware upgrades are required and on how many disks and disk types
For more information, see Upgrading disk firmware.
The types of applications in use and their susceptibility to timeout errors
The availability of client applications during upgrades depends on features, protocols, and configuration. See your application documentation for more information.

Note
All hardware and software upgrades in any storage solution are potentially at least somewhat disruptive to filer services. Network Appliance recommends that you review upgrade options carefully to determine the best method of upgrading for maintaining optimal service availability.

Service and protocol considerations

During an upgrade, the filer must be rebooted (by issuing the reboot command or by initiating a cluster takeover and giveback) to load the new software. In general, services based on stateless protocols--such as NFS, FCP, and iSCSI--are less susceptible to service interruptions during upgrades than session-oriented protocols--such as CIFS, FTP, NDMP, and HTTP. Furthermore, services based on stateless protocols usually remain available during nondisruptive upgrades of clustered systems.

Stateless protocols usually include a timeout procedure. For example, if a message is sent and receipt is not acknowledged within a timeout period, a transmission error is assumed to have occurred. In a filer environment, if the client's timeout period is greater than the disruption period on the filer (for example, the amount of time a reboot or cluster giveback takes), the client will not perceive a disruption of filer services.

In session-oriented protocols, there is no concept of timeout to protect the service from disruption. If session-oriented filer services are disrupted, state information about any operation in progress is lost and the user must restart the operation.

The following list summarizes the behavior of filer services and protocols during upgrades. See also The Compatibility and Configuration Guide for NetApp's FCP and iSCSI Products, on the NOW site at the following address:
http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/index.shtml.

NFS hard mounts
No adverse behavior on the clients. Clients might receive some messages similar to NFS server not responding, retrying until the filer reboots.
NFS soft mounts
Network Appliance recommends that you not use soft mounts for NFS traffic.
FCP, Direct Attached
No adverse behavior on the clients if the reboot takes less than the user-configurable node and link timeouts on the following hosts:
- For Windows 2000 hosts, the host parameters are called NodeTimeout, HLinkTimeout, and LinkTimeout.
- For Solaris hosts, the host parameters are called nodev-tmo and linkdown-tmo, and are set in the /kernel/drv/lpfc.conf file.
The recommended value for these parameters for Direct Attach FCP configurations is 255 seconds. (Check the NOW site for the latest values.)
FCP, Fabric Attach
No adverse behavior on the clients if the reboot takes less than the user-configurable node timeouts on the following hosts:
- For Windows 2000 hosts, the parameter is called NodeTimeout.
- For Solaris hosts, the parameter is called nodev-tmo.
When the host is fabric-attached to a filer that is not clustered, the recommended value for these parameters is 255 seconds.
iSCSI
No adverse behavior on the clients. Clients might receive some messages similar to Server not responding, retrying until the filer reboots.
CIFS
Client sessions are terminated. Inform users to end their sessions before you upgrade. To do so, issue the cifs terminate -t command before the cluster takeover or before the reboot, or issue the reboot -t command.
FTP, NDMP, and HTTP
State is lost and the operation must be retried by the client user.
Backups and restores
State is lost and the operation must be retried by the client user.

Caution
Do not initiate a backup or restore operation during or immediately before an upgrade. Doing so might result in data loss.
Applications (for example, Oracle or Exchange)
Effects depend on the applications. For timeout-based applications, you might be able to change the timeout setting to longer than the Data ONTAP reboot time to minimize adverse effects.