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 storage system services during upgrades:

Whether the system being upgraded is a single node or a cluster partner
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 Resolving upgrade issues.
Whether a system firmware upgrade is required
System firmware upgrades require a system halt and reboot. This can disrupt services in single storage system 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 what type of RAID protection applies to those disks
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 storage system services. Make sure 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 storage system 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.

Note
If you are planning to perform a nondisruptive upgrade on a system with FCP or iSCSI hosts, see About nondisruptive cluster upgrades.

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 storage system environment, if the client's timeout period is greater than the disruption period on the storage system (for example, the amount of time a reboot or cluster giveback takes), the client does not perceive a disruption of storage system services.

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

For stateless protocols:

The following list summarizes the behavior of storage system services and stateless 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 storage system reboots.
NFS soft mounts
You are advised not to use soft mounts for NFS traffic.

When the host is fabric-attached to a storage system that is not clustered, the recommended value for these parameters is 255 seconds.
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 parameter is called nodev-tmo, which is set in the /kernel/drv/lpfc.conf file.
The recommended value for these parameters for non-multipathed FCP configurations is 255 seconds. (Check the NOW site for the latest values.)
FCP, Fabric Attached
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 storage system that is not multipathed, the recommended value for these parameters is 255 seconds.
iSCSI
No adverse behavior on the clients unless otherwise noted--see iSCSI targets unavailable after upgrading to Data ONTAP 7.1. Clients might receive some messages similar to Server not responding, retrying until the storage system reboots.

For session-oriented protocols:

The following list summarizes the behavior of storage system services and session-oriented protocols during upgrades.

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 client user must retry the operation.
Backups and restores
State is lost and the client user must retry the operation.

Attention
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.