Appendix B

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.

Factors for minimizing service disruption during upgrades

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

The following factors can affect the length of service interruption.

Factor	Comments
The types of services licensed and their susceptibility to time-out errors	See Service and protocol considerations.
The types of applications and their susceptibility to time-out errors	The availability of client applications during upgrades depends on its features, protocols used, and configuration. See your application documentation for more information.
Whether a system firmware upgrade is required	System firmware upgrades can be disruptive in single gFiler and standard cluster upgrades because they require a system halt and reboot. In nondisruptive cluster upgrades, no system halt and reboot is required. For more information, see Chapter 2, Upgrading gFiler Firmware.
Upgrading from a release prior to 6.5	Upgrading from a release prior to Data ONTAP 6.5 interrupts service.
Upgrading within a 6.5 or later release family	Starting with the 6.5 release family, nondisruptive upgrades are available for clusters in the circumstances described in How nondisruptive cluster upgrades work.
Whether the system being upgraded is a single node or a member of a cluster	When you upgrade a single gFiler, you must reboot it. The result is that during the time the gFiler is going through the reboot process services are interrupted. For clusters, less disruption of service occurs if you can use the nondisruptive process. See Planning for upgrading clusters for more information.

Note
All hardware and software upgrades in any storage solution are potentially at least somewhat disruptive to gFiler services. NetApp recommends that you review upgrade options carefully to determine the method of upgrading to maintain optimal service availability.

Service and protocol considerations

During an upgrade, the gFiler 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 but receipt is not acknowledged within a timeout period, a transmission error is assumed to have occurred. In a gFiler environment, if the client's timeout period is greater than the disruption period on the gFiler (for example, a reboot or cluster giveback), the client does not perceive a disruption of gFiler services.

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

The following list summarizes the behavior of gFiler services and protocols in a nondisruptive upgrade.

NFS hard mounts
There is no adverse effect on the clients. Clients might receive some messages similar to NFS server not responding, retrying until the gFiler reboots.
NFS soft mounts
NetApp recommends that you do not use NFS soft mounts for NFS traffic.
FCP, Direct Attached
There is no adverse effect on the clients if the reboot takes less than the user-configurable node and link timeouts on the following hosts:
- For Windows 2000 hosts, these host parameters are called NodeTimeout, HLinkTimeout, and LinkTimeout.
- For Solaris hosts, these host parameters are called nodev-tmo and linkdown-tmo, as set in the /kernel/drv/lpfc.conf file.
The recommended value for these parameters for Direct Attached FCP configurations is to set them all to 255 seconds. (Check NOW for the latest values).
FCP, Fabric Attached
There is no adverse effect on the clients if the reboot takes less than the user-configurable node timeouts on the following hosts:
- For Windows 2000 hosts, this parameter is called NodeTimeout.
- For Solaris hosts, this parameter is called nodev-tmo.
When the host is fabric attached to a gFiler that is not in a cluster, the recommended value for these parameters is 255 seconds.
iSCSI
There is no adverse effect on the clients. Clients might receive some messages similar to Server not responding, retrying until the gFiler reboots.
CIFS
Client sessions are terminated. Inform users to end their sessions before you upgrade.

To upgrade, issue the cifs terminate -t command before the cluster takeover or before the reboot, or issue the reboot -t command.
FTP, NDMP, and HTTP
The state is lost and the operation must be retried by the client user.
Backups and restores
The 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®, Exchange, etc.)
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.