Copyright © 2005 by Network Appliance, Inc.
Copyright © 2005 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.
This document provides release-specific information about the SpinServer® system and the SpinFS® 2.5.5 software. It summarizes the changes and known issues likely to affect SpinServer users. It provides information about features that are not listed in the SpinServer documentation set.
The document is organized into the following sections:
Section 2 provides information about obtaining support.
Section 3 provides information about new features that are available in SpinFS 2.5 and the SpinServer system hardware. It also lists the features and fixes that are included in the latest version of SpinFS.
Section 4 lists interoperability among SpinServer system components.
Section 5 provides information about upgrading to the latest version of SpinFS 2.5.
Section 6 lists product issues, with workarounds where possible.
Section 7 describes the SpinServer documentation set.
You can contact Network Appliance™ Technical Support 24 hours a day and seven days a week.
By E-mail. Send e-mail queries to <support@netapp.com>.
By Phone. In North America, call toll free at +1-888-4-NETAPP or +1-888-463-8277. Press the * (star) key for SpinServer support.
Outside North America, find the toll-free number for your region at www.netapp.com/support/contact.html.
By Web. Open a Web browser and go to now.netapp.com.
This section describes the new features and bug fixes of SpinFS and the SpinServer system.
SpinFS 2.5.5 includes the following new features and fixes.
Performance is enhanced for SpinServer systems that use FAS270c RAID arrays. To enable the performance enhancements, SpinFS 2.5.5 or later must be run on all SpinServers in the system, Data ONTAP™ 6.5.3H2 or later must be run on all FAS270c RAID arrays in the system, and each SpinServer in the system must have the configuration setting described in Section 6.2.1.
Debugging messages for the VFS Location Database (VLDB) were enabled by default, resulting in a large number of messages being written to the message log. (Bug 137789)
Cluster routes that went through a router did not persist when the router was taken down and then brought back up. This resulted in a disruption of cluster operations. (Bug 139383)
CIFS connectivity problems were accompanied by numerous messages of the form kernel: #CifsLog: RaResp -1001/3135/SpinfsUtil.c -1001/289/WriteAndX.c -1001/399/RAResponse.c. (Bug 146637)
Several problems that caused the SpinServer system to panic or freeze were fixed. (Bugs 146559, 148157, 148682)
Leaked network packets resulted in unresponsive virtual interfaces. (Bug 147059)
Creation of a CIFS server failed with a message of the form Tomcat[10564]: Failed to create CIFS Server. Error=Active Directory updates failed. (Bug 147763)
Leaked network packets resulted in problems with UDP, requiring a SpinServer's virtual interfaces to be migrated to a different SpinServer. (Bug 148794)
SpinFS 2.5.4 included the following new features and fixes. See the SpinFS 2.5 Administration Guide and SpinFS 2.5 Administration Reference for information about new and changed commands.
The tools filestorage vfs migratefamily command enables you to migrate a VFS from one virtual server to another.
You no longer need to create or join a cluster before running software-upgrade commands on a SpinServer. (Bug 125791)
The output of the filestorage vfs show-mount and tools filestorage vfs show-mount commands now includes the Used (MB), Storage Pool, and SP Avail (MB) fields. (Bug 126786)
The NDMP service sometimes failed with a segmentation fault. (Bug 127796)
Numerous messages of the form kernellog: FCD: IO to device 16 took 6625 ms were written to the system log for tape LUNs. (Bug 128254)
The tools filestorage lostnfound commands enable you to work with VFSs that are known to the SpinServer's disk function but not to the VLDB. (Bug 127039)
Several problems that caused the SpinServer system to panic or freeze were fixed. (Bugs 131250, 131273, 132499, 138422, 140180, 140661, 141126, 144041)
Two SpinServer processes were unable to communicate with each other, resulting in a large number of error messages being written to the system log, and requiring a system restart to resolve. (Bug 135173)
The default value for the free-space alarm on a storage pool is changed to 5 percent from 1 percent. A VFS move operation fails if there is too little space available on the storage pool; this change provides for more free space on the pool. (Bug 135402)
The NDMP restoration process did not account for VFS SpinShots and mirrors, resulting in incomplete restorations. (Bug 135750)
The NDMP process did not correctly handle deferred SCSI errors, resulting in backup media errors. (Bug 135917)
An NDMP restoration failed when a tape was not loaded quickly enough by the tape robot. (Bug 137094)
CIFS clients were unable to access certain files due to a problem with handling unused TCP connections. (Bug 140196)
The primary server for a storage pool appeared to have a frozen CPU for 42 seconds, and the pool's active secondary server took control of the pool. When the primary server recovered, it attempted to take control of the pool; the pool then had two primaries and was marked as damaged. (Bug 140313)
Virtual interfaces went offline due to quorum issues. (Bug 141054)
The event spinevents sendtestevent command enables you to send test event messages. (Bug 141493)
When a user attempted to open a .mov file from a CIFS client by using Windows® Explorer, the attempt failed with a file not found error. The root problem was a mishandling of certain CIFS path-name components.
A SpinServer's virtual interfaces became unresponsive, and attempts to migrate the virtual interfaces failed. Attempts to restart the SpinServer also failed. (Bug 142065)
The -useclus parameter on the services ntp configure modify command enables you to specify whether to use SpinServers in the cluster as Network Time Protocol (NTP) peers. Possible values are true and false; the default is false. (Bug 142142)
The NOT{expression} syntax of the filestorage scheduler tasks modify and filestorage scheduler tasks new commands did not correctly process comma-separated values. For instance, the expression NOT{dept.eng,dept.hr} did not exclude either dept.eng or dept.hr from the VFS Scheduler task. Comma-separated values are now processed correctly in NOT{expression} expressions. (Bug 142389)
SpinServer system performance degraded due to repeated resets of a Fibre Channel. (Bug 142506)
If a CIFS virtual server was configured into a Windows NT® 4.0 domain that shared a two-way trust relationship with an Active Directory domain, users of the Active Directory domain were unable to be authenticated for access to the virtual server. (Bug 142884)
The tools raid subsystems commands enable you to save and restore RAID subsystem configurations. (Bug 142905)
The timestamps for events written to the audit log were one hour behind the system time. (Bug 143177)
The output of the storage pools show and tools storage pools show commands now includes the Storage Units Present and Storage Units Required fields. The Storage Units Present field lists the storage units that are reported by the SpinServer's disk function, and the Storage Units Required field lists the storage units that are used by the storage pool. The latter field is updated when the storage pools new or storage pools grow command is issued. (Bug 143236)
After an upgrade from SpinFS 2.1 to SpinFS 2.5, the SpinServer did not recognize an attached Hitachi Data Systems® storage array. (Bug 143462)
A SpinServer was not reclaiming network packets, resulting in numerous messages of the form kernel: System temporarily out of Spin Descriptors. (Bug 144068)
Documentum running on Windows 2003 was unable to write folders or files to a VFS. (Bug 144087)
Due to a client-side issue, an AIX 5.2 client looped indefinitely after issuing the ls command to a SpinServer. (Bug 144564)
A CIFS client with a large number of resource SIDs was unable to authenticate to a SpinServer. (Bug 145242)
Some hourly SpinShot™ jobs failed with messages of the form error="vldb: allocate VFS ID.: VLDB is not in quorum". (Bug 146053)
The SpinFS 2.5 Administration Guide and SpinFS 2.5 Administration Reference have been updated with all user-visible changes since SpinFS 2.5.0. The installation instructions in the SpinServer 4100 Quick Start Guide have been updated.
SpinFS 2.5.3 included the following features and fixes:
Support for the following storage products:
NetApp® NearStore® R200
Hitachi Data Systems 9910
See the SpinServer Supported Storage Release Notes for information about supported storage products.
The filestorage mirror replicate command now uses the -maxspinshots parameter to specify how many mirror replicas to retain. The default value for the parameter is 1. (Bug 126099)
A storage pool was unavailable with the status waiting for disks, and a LIP reset did not restore access to the pool. (Bug 128143)
You can now share a Microsoft Excel spreadsheet between users of the Windows version of Excel when the spreadsheet is stored on a CIFS-enabled virtual server. (Bug 129720)
Several problems that caused the SpinServer system to panic were fixed. (Bugs 130013, 130918, 134600, 136616, 137072)
The cluster configuration modify command now includes the -sendmessage parameter, which specifies whether a message is issued when a SpinServer in the cluster is restarted. Possible values are true and false; the default is true (that is, a message is issued at restart). Because system-restart events are categorized as critical, they often trigger pager alerts; specify a value of false if you want to suppress these notifications. (Bug 132419)
The spinservers reboot command now requires the -rebootreason parameter. Specify the reason for restarting the SpinServer as the argument of the parameter. The reason for the restart is written to the event log and is displayed in the subsequent startup message. Before restarting the SpinServer, the spinservers reboot command also saves support data to assist with possible debugging. (Bug 132617)
Several changes were made to the event filters command node to simplify the organization of events. These commands enable you to create filters based on groups of events from different modules and with different severities. (Bug 132903)
The system bootimages setdefault command did not always work correctly. (Bug 133253)
Two storage pools were unavailable with the status waiting for disks, and each pool was listed as having two active secondary servers. (Bug 133955)
The default priority of an active secondary server is now 128 (the lowest priority), not 1 (the highest priority). (Bug 134180)
The output of the raid sets show command now includes the LongOp field, which indicates whether a long-running operation is running on the specified RAID set. (Bug 134951)
The SpinServer system now issues an alert if a battery backup unit (BBU) on a SpinStor® RAID array needs to be reconditioned. (Bug 134900)
The NDMP service failed due to a SCSI problem. (Bug 134987)
When a SpinServer failed, another server attempted to take over its storage pools even though no failover relationship was established between the servers at the time of the failure. (Bug 135073)
During high-availability (HA) configuration, a primary server now verifies that the specified active secondary server is not already serving as active secondary to the maximum number of storage pools. If the maximum is already reached, the failover relationship is not established. (Bug 135556)
The storage pools revertpools command now takes the -deviceids parameter, which specifies the list of pools that are to be reverted. By default, the command reverts all pools. If you are using the CLI, press Tab after typing the parameter to get a complete list of storage pools. (Bug 136139)
The storage pools revertpools command did not use the correct priorities when reverting storage pools to servers. (Bug 136170)
The system log (syslog) service sometimes stopped running. (Bug 136560)
Performance was improved for HA configurations. (Bug 136924)
SpinFS used a version of OpenSSL that had a known security flaw. SpinFS now uses a patched version of OpenSSL. (Bug 137009)
The spinservers shutdown command now requires the -shutdownreason parameter. Specify the reason for shutting down the SpinServer as the argument of the parameter. The reason for the shutdown is written to the event log and is displayed in the subsequent startup message. (Bug 137462)
The storage pools setonline command now requires the -newprimary parameter, which specifies the primary SpinServer of the storage pool that is being set online. The default value for this parameter is the storage pool's home SpinServer. (Bug 139157)
The filestorage mirror show-group command displays information about the mirrors associated with a particular source VFS. The command takes the name of one mirror as the value of the -sinkvfsname parameter, but displays information about all mirrors associated with the specified source VFS. The command displays the following information:
Source VFS name
Sink (mirror) VFS name
Source storage pool
Sink (mirror) storage pool
Sink (mirror) version
Status (online or offline)
A new document, SpinFS 2.5 Messages and Troubleshooting Guide, provides a list of system messages and troubleshooting steps for the SpinServer system.
SpinFS 2.5.2 was an invalid release.
SpinFS 2.5.1 included the following new features and fixes:
The output of the filestorage vfs show-family and tools filestorage vfs show-family commands now includes the following information:
VFS name
VFS type (context, explicit, mirror, or spinshot)
Mount path
Creation time
Storage pool name
Status of the VFS (online or offline)
The following information is no longer in the commands' output but is still provided in the output of the filestorage vfs show and tools filestorage vfs show commands:
Virtual server name
VFS from which the family VFS is mounted
Maximum quota
Amount of data storage that is used by the VFS
Amount of data storage that is available on the storage pool
Export rule set name
(Bug 126852)
When a SpinServer system was started, the critical error message vmdumps not enabled was sometimes issued. This error is not critical, and it was sometimes issued incorrectly (that is, when vmdumps were enabled). The error has been downgraded in severity and is no longer issued incorrectly. (Bug 127855)
The default value for the -auditlogsize parameter on the cluster configuration modify command is changed to 10 from 1. The lower limit is 10 and the upper limit is 10000. (Bug 127977)
A problem that caused the SpinServer system to panic was fixed. (Bug 129440)
Some CIFS-related messages in the SpinServer's /var/log/messages file contained nonsensical characters. (Bug 131385)
The if status revertvifs command reverted all virtual interfaces back to their home ports regardless of whether a particular virtual interface's home port was up or down. The command now reverts each virtual interface only if the home port is up (that is, is able to service the virtual interface). (Bug 132069)
The error message that is issued when a .spinshot directory cannot be located did not include the ID of the affected VFS. (Bug 132415)
SpinFS 2.5.0 included the following new features.
Native netgroup support. When using export rule sets, you can now specify a netgroup name instead of an IP address and network mask to match clients to an export rule. A netgroup is a named collection of arbitrary IP addresses that is stored in an NIS map. Previously, you needed to use the buildexports command to work with netgroups.
Because netgroups can have overlapping membership sets, ordering of export rules in a rule set is no longer automatic. Order the rules in a rule set by using the spinaccess exportrule decreaseposition, spinaccess exportrule increaseposition, spinaccess exportrule movefirst, and spinaccess exportrule movelast commands.
Note: If you are working with netgroups and export rule sets, NetApp recommends that you upgrade all SpinServers in a cluster to SpinFS 2.5. If there are mixed SpinFS versions in a cluster, the SpinServers running older versions of SpinFS do not support native netgroups and ignore netgroup-based rules. Additionally, rules and rule sets cannot be uniformly managed on SpinServers that are running older versions of SpinFS.
Changes to the mount types for VFSs. A mount type must be specified for the filestorage vfs new and filestorage vfs mount commands. The write mount type for VFSs is renamed as explicit. The name of the mount type was changed to prevent confusion when a read-only VFS is mounted. The available mount types are now as follows:
context, for a VFS that inherits the context of its parent VFS (read-write or read-only). This is the default.
explicit, for a VFS that is read-write regardless of the context of its parent VFS. This type can be used if, for instance, you mount a read-write VFS below a VFS mirror.
mirror, for a VFS mirror. VFS mirrors are read-only.
spinshot, for a VFS SpinShot. SpinShots are read-only.
Additionally, you can now mount a source VFS at one location and a mirror of that VFS at another location without having to traverse the .readwrite mount point. This enables you to mount and unmount mirrors without affecting the source VFS.
The ability to monitor the health of a SpinServer and have reports automatically sent by e-mail by using the services support configure commands. Health reports are periodically e-mailed from the cluster. Use the new -mailfrom and -mailserver parameters on the cluster configuration modify command to specify the mail-from address and outbound mail server for a cluster.
The ability to control the services that are available on the SpinServer's management and server ports by using the services firewall configure commands.
The ability to return a storage pool to its home SpinServer automatically after a failover by using the storage pools revertpools command.
By default, a storage pool's home SpinServer is the SpinServer on which the storage pool was created. You can use the storage pools modify command with the -homeserver parameter to change a storage pool's home SpinServer. You must run this command on the SpinServer that is the primary server for the storage pool.
The storage pools show-home command displays the home SpinServer or SpinServers for one or more storage pools. This command is available only in the CLI; in the GUI, the information is available from the output of the Storage Pools → Storage Pools command.
The ability to return a virtual interface to its home port automatically by using the if status revertvifs command.
SpinAuth, a lightweight authentication mechanism that improves the security of NFS access that is otherwise protected only by the AUTH_SYS mechanism. The NFS-standard AUTH_SYS mechanism does not provide secure authentication of client requests; NFS Kerberos provides strong authentication of client requests but has few available client programs. SpinAuth enables users to authenticate by using Kerberos and pass the authenticated identity to a SpinServer, which then caches the credentials for future requests from the users' clients.
Out-of-space alerts for VFSs and storage pools. You can set storage pools and VFSs to issue an alert when they reach a predetermined threshold of remaining space. The alert is issued as a critical event that can be relayed to administrators via a subscription, an SNMP trap destination, or both (see the Administration Guide for information on setting up critical-event subscriptions and SNMP trap destinations). The filestorage vfs new, filestorage vfs modify, storage pools new, and storage pools modify commands include the -freespacealarm parameter to support out-of-space alerts.
The ability to promote a mirror, a SpinShot™, or a SpinShot of a mirror to the parent read-write VFS by using the tools filestorage vfs promote command.
The ability to remove a node from a cluster by using the cluster status deletenode command. To return the SpinServer to the same or a different cluster, use the spinservers joincluster command.
The ability to delete a specific file from a VFS by using the tools filestorage vfs deletefile command. The command can delete a file, a directory, a symbolic link, or a mountpoint.
The ability to show or hide a VFS's .spinshot directory from clients. The -showspinshot parameter on the filestorage vfs new and filestorage vfs modify commands determines whether the VFS's .spinshot directory is visible to clients. The current setting can be determined from the output of the filestorage vfs show command. The parameter is also used with the vservers servers new and vservers servers modify commands to specify the behavior for all new VFSs created on a particular virtual server.
The ability to restrict the use of CIFS access control lists (ACLs). Some Windows applications set ACLs on files during write operations. You can restrict the use of ACLs to suppress this behavior on VFSs by using the -restrictedacl parameter on the filestorage vfs new and filestorage vfs modify commands. The parameter's default value is false (that is, ACLs are used on the VFS). If ACLs are not used on the VFS, then the only permissions you can set on files are UNIX® mode bits, and attempting to modify ACLs from a CIFS client results only in changes to the mode bits. The parameter is also used with the vservers servers new and vservers servers modify commands to specify the behavior for all new VFSs created on a particular virtual server.
The ability to dump and restore the contents of a VFS over a TCP connection by using the vfsdump and vfsrestore commands.
Support for 32k read operations over NFS. This improves performance for NFS clients such as Sun® Solaris® that preferentially use 32k read operations instead of 8k read operations.
Support for Windows 2003 Server.
Support for Mac® OS X v10.3 (Panther) as a CIFS client.
Support for IBM® Tivoli® Storage Manager version 5.2.2.0.
Support for NDMP Direct Access Recovery (DAR).
Online help for SpinManager™ commands is now available from the GUI. Click the Help button at the top of the right-hand pane to launch a separate browser window that displays reference information about the current command node.
SpinFS 2.5 includes commands for working with the SpinAV™ antivirus component; however, the virus-scanning feature is currently not enabled or licensed. Disregard any commands or procedures in the user interface or documentation that are related to virus scanning.
At minimum, the SpinServer system consists of the following set of hardware components. Additional sets of components can be added to expand the system.
Two SpinServer 4100 chassis to create a cluster, with additional SpinServers added in pairs
For each SpinServer, two or more FAS270c RAID disk enclosures, for a minimum of four FAS270c RAID enclosures per SpinServer system
Optionally, one or more DS14mk2 FC JBOD disk enclosures per FAS270c RAID enclosure
One uninterruptible power source (UPS) per SpinServer
Two eight-port or 16-port Fibre Channel switches
See the SpinServer 4100 Quick Start Guide and SpinServer 4100 Installation Guide for more information about the SpinServer system's hardware components. For information about the FAS270c and DS14mk2 FC disk enclosures, see the FAS270/270c Hardware and Service Guide and Fibre Channel DiskShelf14 Hardware Guide, respectively.
SpinFS 2.5 can run on the SpinServer 3300 and the SpinServer 4100.
SpinFS 2.1 and SpinFS 2.5 can run on different SpinServers in the same cluster. The following problems are possible in a cluster in which both SpinFS 2.1 and SpinFS 2.5 are running:
If a virtual interface fails over from a SpinServer running SpinFS 2.5 to a SpinServer running SpinFS 2.1, NFS clients can experience stale file handles and Linux clients can read data that appears to be corrupted. To prevent this behavior, configure the SpinServer system so that virtual interfaces do not fail over between SpinServers running SpinFS 2.1 and SpinServers running SpinFS 2.5.
If you are working with netgroups and export rule sets, any SpinServers running SpinFS 2.1 do not support native netgroups and ignore netgroup-based rules. Additionally, rules and rule sets cannot be uniformly managed on SpinServers that are running older versions of SpinFS. To prevent this behavior, NetApp recommends that you do not use netgroups or export rule sets in a cluster in which both SpinFS 2.1 and SpinFS 2.5 are running.
SpinServer 4100 systems now use FAS270c (RAID) and DS14mk2 FC (JBOD) storage arrays; however, SpinStor® and SpinStor 200 RAID and JBOD storage arrays are still supported. The following table lists clustering interoperability among SpinServer, SpinStor, FAS270c, and DS14mk2 FC components.
Table 1. SpinServer, SpinStor, FAS270c, and DS14mk2 FC Interoperability
| SpinServer 4100 | SpinServer 3300 | SpinStor 200 RAID and JBOD | SpinStor RAID and JBOD | FAS270c RAID | DS14mk2 FC JBOD | |
| SpinServer 4100 | Yes | Yes | Yes | Yes | Yes | Yes |
| SpinServer 3300 | Yes | Yes | Yes | Yes | Yes | Yes |
| SpinStor 200 RAID and JBOD | Yes | Yes | Yes | |||
| SpinStor RAID and JBOD | Yes | Yes | Yes | |||
| FAS270c RAID | Yes | Yes | Yes | Yes | ||
| DS14mk2 FC JBOD | Yes | Yes | Yes | Yes |
This section provides information about upgrading a SpinServer cluster to the latest version of SpinFS. Each SpinServer in the cluster must be upgraded one at a time.
| Caution: |
|
Contact Technical Support before performing a clean installation of SpinFS software on a production SpinServer that is an active part of a cluster. A clean installation is an installation in which you install SpinFS from a SpinFS CD-ROM and then restart the SpinServer. Performing a clean installation deletes all configuration information on the SpinServer and can result in data loss. |
To upgrade a SpinServer, perform the following steps:
Log in as root to the SpinServer that is being upgraded.
If you are upgrading from a CD-ROM, insert the SpinFS CD-ROM into the SpinServer's CD-ROM drive.
Alternatively, if you are upgrading from an archive file, download the file onto the SpinServer. For example, download the archive file named spinfs-X.Y.Z_45000.tgz to the SpinServer as /space1/SpinFS_45000/spinfs-X.Y.Z_45000.tgz.
If you are upgrading from an archive file (*.tgz file) , verify the space available on the root partition (/) as follows:
Run the df command:
# df / Filesystem 1k-blocks Used Available Use% Mounted on /dev/md2 1035596 647752 335236 66% /
If the Use% value is over 80%, remove files from the root partition to free space. Suggested files for removal include the following:
/var/tmp/*
/core/*
If necessary, old messages files such as /var/log/messages.2 or /var/log/messages.2.tgz
Repeat Steps 3a and 3b until the Use% value is under 80%.
Log off from the SpinServer as root and log in to it as an administrator, or run the spinsh command from the root prompt to enter the SpinManager CLI.
Use the system rootfilesystem upgradesoftware command to upgrade the software on the SpinServer. The command has the following syntax:
system rootfilesystem upgradesoftware -ssid spinserver -name file_system_name -installurl {cdrom | file:file_name | ftp:FTP_site}
The following example upgrades the software on the ALTROOT partition of a SpinServer named Server1 from CD-ROM.
spinserver::> system rootfilesystem upgradesoftware -ssid Server1 -name ALTROOT -installurl cdrom
The following example upgrades the software on the ALTROOT partition of a SpinServer named Server1 from an upgrade archive file. The upgrade archive file is at /space1/SpinFS_45000/spinfs-X.Y.Z_45000.tgz.
spinserver::> system rootfilesystem upgradesoftware -ssid Server1 -name ALTROOT -installurl file:/space1/SpinFS_45000/spinfs-X.Y.Z_45000.tgz
The following example upgrades the software on the ALTROOT partition of a SpinServer named Server1 from an upgrade archive file that is on an anonymous FTP server. The FTP server is named ftp.example.com with a public directory named pub, and the upgrade archive file is named spinfs-X.Y.Z_45000.tgz.
spinserver::> system rootfilesystem upgradesoftware -ssid Server1 -name ALTROOT -installurl ftp://ftp.example.com/pub/spinfs-X.Y.Z_45000.tgz
The following example upgrades the software on the ALTROOT partition of a SpinServer named Server1 from an upgrade archive file that is on an FTP server that does not accept anonymous connections. The FTP server is named ftp.example.com with a public directory named pub. The login name for the FTP server is admin, which has a password of S3cr3t. The upgrade archive file is named spinfs-X.Y.Z_45000.tgz.
spinserver::> system rootfilesystem upgradesoftware -ssid Server1 -name ALTROOT -installurl ftp://admin:S3cr3t@ftp.example.com/pub/spinfs-X.Y.Z_45000.tgz
Run the system rootfilesystem show command to determine whether the Sync On Reboot property for the alternate root file system is set to CONFIGURATION, as in the following example:
spinserver::> system rootfilesystem show -ssid Server1 -name ALTROOT SpinServer ID Server1 Name ALTROOT Device /dev/md2 Mount Path /altroot Version 2.0.0 BuildNumber 32012 InstallTime 10/24/2002-11:14:28 Last Sync Time UNKNOWN Last Config Sync Time UNKNOWN Sync On Reboot CONFIGURATION
If the Sync On Reboot property for the alternate root file system is not set to CONFIGURATION, set the property by using the system rootfilesystem modify command, as in the following example:
spinserver::> system rootfilesystem modify -ssid Server1 -name ALTROOT -synconreboot CONFIGURATION
Determine the current boot image by using the system bootimages show command. The command has the following syntax:
system bootimages show [-ssid spinserver -label boot_image]
The following example displays information about all boot images:
spinserver::> system bootimages show
SpinServer ID Label Path Device Current Default
Server1 image1 /boot/vmlinuz /dev/sda2 false false
Server1 image2 /altroot/boot/vmlinuz /dev/sda3 true true
Set the default boot image to the image that has its Current value listed as false by using the system bootimages setdefault command. The command has the following syntax:
system bootimages setdefault -ssid spinserver -label boot_image
The following example sets the default boot image on a SpinServer named Server1 to image2:
spinserver::> system bootimages setdefault -ssid Server1 -label image2
If you are upgrading from a CD-ROM, eject the CD-ROM from the drive.
Restart the SpinServer by using the spinservers reboot command. The command has the following syntax:
spinservers reboot -ssid spinserver
The following example restarts a SpinServer named Server1:
spinserver::> spinservers reboot -ssid Server1
When the SpinServer restarts, it is running the upgraded version of the software.
If this is an initial upgrade from SpinFS 2.1 to SpinFS 2.5, run the services firewall configure modify command with the default parameters and values to ensure that all firewall changes in SpinFS 2.5 are propagated across the system:
spinserver::> services firewall configure modify -mgmtonservports false -svcsonservports true -svcsonmgmtport true
This section provides important notes about SpinFS and the SpinServer system. Notes are designated with bug numbers. You can reference these numbers when following up on a specific issue with Technical Support.
The following notes apply to SpinServer system hardware.
You cannot mix different models of Ethernet cards in the same SpinServer 3300 chassis. Each chassis must have two 3COM Model 3C996-T cards or two Model 3C996B-T cards.
Each SpinServer has two cluster ports. NetApp recommends that you use network switches to connect the cluster links. If you use cables to connect the cluster links directly, the following restrictions apply:
If the IP addresses of the two cluster links on one SpinServer are on the same subnet, connecting both links with cables is not supported. The only supported case in this scenario is connecting only one link.
If the IP addresses of the two cluster links on one SpinServer are on different subnets, connecting both links directly with cables is supported.
(Bug 122701)
If your SpinServer uses 3Com® Ethernet card Model 3C996-T, you can experience poor network performance if the ports are directly connected (that is, not through a switch) and the maximum transmission unit (MTU) setting is 9000. To avoid this behavior, NetApp recommends that you connect the ports through a switch. Alternatively, you can set the MTU value to 1500. Note that this model of card is used only in the SpinServer 3300. (Bug 123519)
If you are using a SpinServer 3300, do not connect all four of its HBA ports to the same RAID subsystem. This configuration can result in World Wide Name conflicts. In a supported configuration, up to two connections can be made from a SpinServer 3300 to a single RAID subsystem. (Bug 125022)
When a SpinServer 4100 server is first powered up, the SCSI alarm LED on the front panel begins to blink and the audible alarm sounds. This is due to a faulty temperature reading. To work around this problem, power down and power up the SpinServer. (Bug 125239)
When connecting a SpinServer to storage, be certain to use the Fibre Channel ports that are on the left side as you face the rear of the SpinServer. These ports are listed in the documentation as ports 0 and 1 but are displayed in SpinManager as ports 2 and 3. (Bug 127002)
On a SpinServer 3300, failure or removal of the power supply (PS1 or PS2) does not result in an event notification or an e-mail alarm being issued. (Bug 127387)
Write caching is now enabled by default on the SpinStor 200 RAID enclosure. This can exercise the battery backup unit (BBU) in the enclosure. See the Administration Guide and Administration Reference for information about the software commands that are used to work with the BBU. If the battery in the backup unit fails, it must be replaced. Contact Technical Support for assistance in replacing the battery.
When a RAID set is rebuilt on a SpinStor 100 RAID enclosure, the enclosure beeps. Normally, the beeping ends when the rebuild process finishes; however, if you issue the raid enclosures mute command during the rebuild process, the beeping continues indefinitely after the rebuild process is complete. This is caused by a bug in the RAID firmware used on the SpinStor 100. To avoid this problem, do not issue the raid enclosures mute command during the rebuild process. If the beeping continues after the rebuild process is complete, issue the raid subsystems reset command. This problem does not occur on the SpinStor 200 RAID enclosure. (Bug 127118)
Currently, the only storage products supported with SpinFS 2.5 are the following. See the SpinServer Supported Storage Release Notes for additional details.
NetApp FAS270c, DS14mk2 FC, and NearStore R200
NetApp (previously Spinnaker Networks®) SpinStor and SpinStor 200
Hitachi Data Systems® 9910
IBM TotalStorage FAStT 900 Storage Server
StorageTek® D178 Disk Subsystem
When creating a SpinServer storage pool from LUNs on a supported storage product, note that a storage pool striped across multiple LUNs uses the smallest LUN size as the size of all of the LUNs. For instance, if you create a storage pool from three 300-GB LUNs and one 100-GB LUN, the storage pool considers all of the LUNs to be 100 GB, resulting in a storage pool of 400 GB, not 1 TB. NetApp recommends that you make all LUNs the same size so that a storage pool uses all of the storage available on its constituent LUNs.
If a SpinServer's uninterruptible power supply (UPS) cable is disconnected when the system starts up, the SpinFS software does not start up; this is the correct behavior. However, when the cable is reconnected, SpinFS does not start automatically. You must restart the SpinServer after the cable is reconnected to start SpinFS. (Bug 123866)
The following notes apply to the SpinFS software.
During the installation of a SpinServer system, make the following configuration changes to optimize performance. Make these changes only to SpinServer systems that use FAS270c storage.
Log in to each SpinServer as root, open the /etc/modules.conf file in a text editor, and add the following lines to the bottom of the file:
options spind lpEnableHolePunching=1 options spinfcd highThrottleLimit=512
Make the same changes in the /altroot/etc/modules.conf file.
Legato® NetWorker® has two methods of doing restoration procedures: the Save Set Recover procedure restores an entire VFS, and a Recover/Directed Recover procedure enables you to choose from a list of directories and files to restore. When you use NetWorker 7.0 for Windows with the NDMP option, a Recover/Directed Recover procedure started from the NetWorker User GUI does not properly initiate a restoration process for a SpinServer. (Note that a Save Set Recover procedure works correctly when started from the GUI.) Instead, this type of restoration procedure must be performed from the command line by using the nsrndmp_recover command. The GUI can be used to browse and select the files that have been backed up; however, when the appropriate directories and files are selected, the restoration of them must be performed from the command line. To restore the directories and files, perform the following steps:
Determine the save-set ID (SSID) of the backup by running the mminfo command on the NetWorker server, as follows. The SSID is the 10-digit internal dump identifier that NetWorker assigns to the dump.
C:\> C:\Program Files\nsr\bin\mminfo.exe -avot -c spinserver
For example, to run the command against a SpinServer named spinnaker1, run the following command:
C:\> C:\Program Files\nsr\bin\mminfo.exe -avot -c spinnaker1 volume client date time size ssid fl lvl name 000091L1 spinnaker1 06/03/2003 15:32:32 PM 61 KB 2663530069 cbN full /simple 000091L1 spinnaker1 06/03/2003 15:32:35 PM 40 GB 2413191060 cbN full /tough
Restore the appropriate directories and files by using the nsrndmp_recover command. The following example restores a file named file1 from a VFS named /simple to a VFS named /restore in the simple directory:
C:\> C:\Program Files\nsr\bin\nsrndmp_recover.exe -c spinnaker1 -S 2663530069 -v off -m /restore/simple /simple/dir1/file1
The following example restores the entire dir1 directory to its original location:
C:\> C:\Program Files\nsr\bin\nsrndmp_recover.exe -c spinnaker1 -S 2663530069 -v off /simple/dir1
If you use Legato NetWorker 6.1.3 and mistakenly add an incorrect VFS name to the backup list (as shown by a backup failure for that VFS), all the VFSs listed after the incorrect entry cannot be restored, even though NetWorker reports that all VFSs are backed up properly. This is a known issue with NetWorker 6.1.3; the problem has been corrected in NetWorker 7.0. (Bug 125576)
Fully restoring a VFS restores mount points such as .readwrite and .spinshot. When working in a restored VFS, be careful not to perform operations that can potentially cross mount points and affect data. For instance, assume you have data from a backed-up VFS named lisa that you restore under a VFS named ralph. If you issue the rm -rf lisa command in the ralph VFS, the operation can cross the .readwrite mount point and delete all data in the lisa VFS. (Bug 127273)
After you replace a disk drive with a disk drive of a different size, the raid diskdrive show command does not update the size of the disk drive to reflect the size of the new disk drive. (Bug 121896)
If you are using a SpinStor RAID array and have a RAID set that is performing a rebuild operation, the raid sets show command does not display a status of Rebuild in the Long Op In Progress field. Additionally, the raid sets rebuildstatus command does not display the current progress of the rebuild operation. This problem does not occur with the SpinStor 200 RAID array. (Bug 123974)
If you replace a RAID controller on a SpinStor 200 RAID enclosure, you can see the following message:
Lost frame for device -1 [1, 0, -1]
This message can be safely disregarded. (Bug 124899)
The raid commands report the sizes of disk drives in gigabytes; however, the commands interpret “gigabyte” as 230 (1,073,741,824) bytes, not one billion bytes. Most disk-drive manufacturers interpret “gigabyte” as one billion bytes, so there can be a discrepancy between the output of the commands and the label on the disk. For instance, the commands can report a 36-GB drive as having a physical size of 34 GB. (Bug 127014)
One or more SpinServers in a cluster can stop synchronizing their time settings against external NTP servers. The unsynchronized servers' clocks then run freely and can drift by several seconds per day. To determine whether a SpinServer is not synchronizing its time setting, log in as root and run the following command:
# /usr/sbin/ntpdc -c peers
If the line listing the SpinServer begins with the character x, the SpinServer is affected. To reset the system time, restart the ntpd daemon on the affected SpinServers. (Bug 139511)
Comments added to CIFS shares are not displayed from CIFS clients. (Bug 121046)
Windows 2000 wild-card patterns are not uniformly supported. (Bug 121070)
When the LSA Restrict Anonymous registry key is set to true on the primary domain controller (PDC), CIFS names and SIDs are not resolved. (Bug 121514)
XCOPY32 or ROBOCOPY cannot copy ACLs to a SpinServer that contains access control entries (ACEs) referring to local users (for example, users that are not a member of any CIFS domain). (Bug 121596)
Removing the Archive bit when setting DOS attributes on files is supported on Windows NT® and Windows XP. (Bug 121644)
Windows 95 and Windows 98 remote administration protocol (RAP) calls are not uniformly supported. (Bug 121645)
UNIX symbolic links are not supported under CIFS. (Bug 121735)
On Windows NT 4.0, attempting to disconnect a network drive that is mapped to a SpinServer can become suspended until Windows times out the attempt. (Bug 121825)
When using Microsoft® Internet Explorer browser, the copy and drag-and-drop functions are not supported for moving one VFS to another on the same virtual server. To work around this issue, use one of the following methods:
Open a Windows command prompt and use the copy command.
In Windows Explorer, select the file, then right-click it and select Copy. Go to the destination, right-click, and select Paste. Alternatively, select the source file and press Ctrl-C to copy it, then go to the destination and press Ctrl-V to paste it.
(Bug 122432)
When a Windows client writes a file to a SpinServer CIFS share, the client explicitly sets inherited ACLs on the file from the containing folder. (Bug 123617)
If a storage pool goes offline while a file is being copied to it from CIFS, you cannot immediately access the failed copy when the storage pool comes back online. Attempting to access the target file (the failed copy) results in a sharing violation. You must close and reopen the client connection before deleting or otherwise working with the target file. (Bug 123646)
Users or groups that have the same name as the CIFS domain cannot set ACLs. This is believed to be the result of a problem in the Windows Primary Domain Controller (PDC). Note that, by default, Windows does not allow users or groups to have the same name as the domain. (Bug 123862)
Assume you have a VFS mounted at /share and a CIFS share named CIFS_SHARE that points to the VFS. If you delete the VFS, you cannot access the share; this is the correct behavior. However, if you then re-create the VFS and mount it at the same location, you still cannot access the share. (Bug 124085)
If a CIFS user is a member of more than 24 groups, CIFS authentication fails for the user. (Bug 124403)
Only one Kerberos server per Kerberos realm is supported. If you are using Kerberos with CIFS and the primary domain controller (PDC) fails, Kerberos authentication cannot be maintained by backup domain controllers (BDCs). If a Kerberos-enabled PDC fails and authentication is maintained by one or more BDCs, NTLM authentication is used. (Bug 126115)
If you are using Windows 2003 Server with Kerberos authentication, you must add the following Windows Registry keys for Kerberos to work. See the Windows documentation for information about setting Registry keys. (Bug 127145)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc] "MaxDatagramReplySize"=dword:00000fa0 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc\Parameters] "MaxDatagramReplySize"=dword:00000fa0
When you use Kerberos authentication with CIFS, a SpinServer's system log can fill up with messages of the form streamdaemons: rpcauthkerberosauth_1_svc: Call to krb5_rd_req() failed with error message: Decrypt integrity check failed. To stop these messages, reset the CIFS server's Kerberos password by using the spinaccess cifs servers resetpassword command. (Bug 128539)
You cannot remove a WINS server from a CIFS domain by using the GUI; however, you can remove it by using the CLI. (Bug 128888)
If you restrict the use of CIFS ACLs, CIFS sticky bits are not set because they cannot be determined from NFS mode bits.
If you use Mac OS X (Panther) with Kerberos authentication to access a CIFS-enabled virtual server, the client can report the error Session setup failed (extended security lookup2): syserr = Permission denied, and a CIFS_Auth_Server error is logged on the SpinServer. This problem is caused by a difference in key-caching behavior between the Microsoft and MIT implementations of Kerberos. To work around this problem, use the kdestroy and kinit programs on the client to clear the old Kerberos credentials and get new ones. Alternatively, you can shorten the time-out period for cached Kerberos credentials on the Microsoft Active Directory Controller. To access the caching time-out settings, click Start → Programs → Administrative Tools → Domain Security Policy, then click Security Settings → Account Policies → Kerberos Policy and adjust the Maximum lifetime for user ticket value from 10 hours to 1 hour.
NFS mount requests for root (/) can fail in the time period between creating a mirror for the root VFS and replicating it. (Bug 122909)
In very rare circumstances, a Red Hat Linux client can freeze when attempting to access data on a SpinServer system. The following conditions must be met for this problem to occur:
There is a high-level directory with multiple VFSs mounted on it, and the VFSs are served by different SpinServers.
One of the SpinServers fails at the precise moment that you use the client to run the ls command or a similar file-checking operation on the high-level directory.
To work around this problem, restart the client. This problem does not occur with other NFS clients, such as Solaris. (Bug 125459)
If you use Linux clients with a SpinServer system, performance can degrade if the clients are set to use 32k packets over UDP. This is a client-side issue. To avoid this situation, NetApp recommends that you set the clients' socket size to 256k (the default for Red Hat Linux is 64k). For more information about optimizing Linux client performance, see http://nfs.sourceforge.net/nfs-howto/performance.html. (Bug 127206)
The following note applies if you are using Solaris™ 10 clients with a SpinServer system. If a Solaris 10 client has a principal in the form host/client_name instead of root/client_name in its /etc/krb5/krb5.keytab file, the client sends NFS service tickets with host/client_name as the principal of the client. Solaris 10 NFS servers map principals that begin with host/ to the anonymous user (typically nobody). To match this behavior on a SpinServer system, create the following Kerberos-to-NIS mappings by using the spinaccess kerb-nis new command:
| Client pattern | Client pattern replacement |
|---|---|
| host/.+ | nobody |
| root/.+ | nobody |
(Bug 142719)
If you have a two-node cluster, NetApp recommends that you enable high-availability mode on the cluster by using the cluster configuration enablehamode command. Using HA mode helps ensure that quorum is not lost in the special case of a two-node cluster.
If you are using SpinServers across a WAN and your network drops packets, SpinServer cluster performance can decrease significantly; specifically, this behavior is seen when the maximum transmission unit (MTU) setting is 1500 and the packet drop rate is 1% or greater. To avoid this behavior, ensure that the packet drop rate is below 1%. The severity of this behavior can be substantially lessened if the WAN can support 9000-byte MTUs. (Bug 125310)
If a cluster is modified by using a series of cluster status commands, the cluster can sometimes become unresponsive due to a voting conflict. Commands that can contribution to this state include cluster status addepsilon, cluster status deletenode, cluster status disablenode, cluster status enablenode, and cluster status removeepsilon. To determine whether an unresponsive cluster is in this state, log in as root to the cluster's SpinServers and run the rdb_dump command. The output of this command lists each RDB unit and its state (online or offline). If a majority of the RDB units are listed as online, the cluster typically recovers on its own.
If a majority of RDB units are listed as offline, run the rdb_dump -qf command. If the command output includes the text State: WS_WaitingForVotes, the cluster requires manual intervention. To recover from this state, restart the Tomcat, vldb, and hamgr processes that are listed as Master in the command output. If this does not clear the problem, or if no processes are listed as Master, restart the same processes on SpinServers that are listed first in the output of the rdb_dump -f command.
If you need additional assistance to diagnose or troubleshoot this problem, contact Technical Support. (Bug 135830)
You must issue the storage pools failover command from the SpinServer that is the current primary server for the affected storage pool. For example, assume that a primary server named Server1 fails and Server2 takes over as the primary server. If you want Server1 to resume as the primary server (after it is brought back online), you must log in to Server2 to run the storage pools failover command. The command fails if you run it from Server1. Alternatively, run the storage pools revertpools command. (Bug 122248)
A storage pool can freeze into a passive state if all of the following conditions are met:
The storage pool is newly configured and no VFSs have been created on it.
The pool is configured for HA.
The pool's primary SpinServer and active secondary SpinServer lose access to the pool's storage units, so that the status of the pool is shown as waiting for disks.
Run the tools storage pools forcetakeover command to restore a storage pool that gets into this state. (Bug 143891)
You must have cookies enabled in your web browser to use the SpinManager GUI. (Bug 123773)
The SpinManager GUI can run very slowly if you are using Internet Explorer 6. To work around this issue, perform the following steps in Internet Explorer:
Click Tools → Internet Options.
Select the General tab. This is the default tab on the Internet Options panel.
Click the Settings button in the Temporary Internet Files area.
For the Check for newer versions of stored pages setting, select Automatically.
Click OK on the Settings panel and the Internet Options panel.
(Bug 124173)
If you are using Netscape® or Mozilla® to navigate the GUI and you select an item from the GUI, then drag and paste it into another window, one or more leading spaces can be added. For instance, if you select the text cd /copyofroot from the GUI in Netscape, then paste it into a UNIX shell window, the text is pasted as cd / copyofroot. This behavior does not occur with Internet Explorer or if you double-click and copy the item before pasting it. (Bug 124840)
If your browser cannot connect to the SpinManager GUI, ensure that all proxy settings on your browser are turned off. (Bug 125531)
As stated in the Administration Guide, NetApp recommends that you use a secure-shell client to access the SpinManager CLI. Secure-shell clients are available from Hummingbird Ltd. and other sources, as well as from the sources listed in the Administration Guide. (Bug 125532)
If you are using Internet Explorer 5.0 or earlier with the SpinManager GUI, the browser hangs if you attempt to access online help. This problem does not occur with Internet Explorer 6.0 or later, or with Netscape or Mozilla. (Bug 127663)
If you are using the CLI to enter multiple arguments for a single parameter, NetApp recommends that you put quotation marks around the arguments to ensure correct parsing. Quotation marks are not required in the GUI. For instance, if you are issuing the event notification handlers new command with values of mail.mycompany.com and mmoore@mycompany.com for the -parameters parameter, enter the command as follows:
spinserver::> event notification handlers new -name foo -type email -parameters 'mail.mycompany.com, mmoore@mycompany.com'
(Bug 127911)
Error messages for the filestorage scheduler jobs commands incorrectly indicate that the commands use the -scheduler parameter, not the correct -schedule parameter. (Bug 127984)
If the SpinServer's hardware clock is not set to Greenwich Mean Time (GMT), you cannot reset the time zone by using the spinservers modify command. (Bug 128882)
If you are logged in to a SpinServer as root and run spinsh commands with the ? parameter to display command parameters, enclose the command and parameter inside single quotation marks, as in the following example:
# spinsh -c 'filestorage vfs show ?'
Not putting the command in quotation marks can have unexpected results. (Bug 139056)
Deleting a mirror's sink does not delete any SpinShots of the sink.
If you have a VFS that is mirrored to two storage pools and you want to delete one of the mirrors, ensure that all mirrors are replicated immediately before deleting any mirrors, or otherwise ensure that all mirrors are synchronized with the source VFS before deleting any mirrors. This prevents clients from receiving potentially out-of-date data from an obsolete mirror. (Bug 126291)
When you are creating a mirror task with the VFS Scheduler, ensure that the VFS specified by the -vfs VFS_name parameter is a source VFS, not a sink VFS (that is, a parent read-write VFS, not another mirror). Specifying a sink VFS as the source of a mirror task can result in errors. (Bug 126453)
If you copy a read-write VFS that has other VFSs mounted below it, the mountpoints of the original VFS are propagated to the copy. For instance, assume you have a VFS named homer that has a VFS named bart mounted below it (/homer/bart). If you make a copy of homer named marge, a mountpoint is created for bart on marge (/marge/bart). NetApp recommends that no more than one mountpoint exist for any given VFS. To delete these superfluous mountpoints, use the tools filestorage vfs deletemountpoint command. (Bug 124757)
Running any of the statistics filesystem vfs commands displays statistics only for VFSs that are directly accessible by the local SpinServer. Statistics for VFSs on storage pools for which the local SpinServer is not a primary server are not shown by these commands. (Bug 127443)
You cannot create a VFS tree with more than 11 mountpoints. (Bug 142405)
SpinFS 2.5 supports 32k read operations over NFS, but SpinFS 2.1 does not. If a cluster includes SpinServers that are running both SpinFS 2.1 and SpinFS 2.5, and a virtual interface fails over from a SpinFS 2.5 system (supporting 32k read operations) to a SpinFS 2.1 system (supporting 8k read operations), a Linux client using the failed-over interface can request 32k, receive only 8k, and appear to have retrieved corrupted data. This is a Linux client problem, not a SpinFS problem. To avoid this problem, configure all virtual interfaces on SpinFS 2.5 systems so that they cannot fail over to SpinFS 2.1 systems. (Bug 127306)
The -floatingsuperuser parameter on the vservers servers modify and vservers servers new commands specifies whether a superuser can log in from any network node. If the value of the -floatingsuperuser parameter is set to false, a superuser can log in only from a specific set of network nodes. If the value of the -floatingsuperuser parameter is set to true, a superuser can log in from CIFS or any form of authenticated NFS (NFS-Kerberos or SpinAuth), on any network node. If you are using unauthenticated (AUTH_SYS) NFS, the -floatingsuperuser parameter has no effect; you must log in from a network node that matches one of the privileged IP address/netmask pairs.
If you use the vservers servers modify command with the -floatingsuperuser parameter on an active virtual server, the command resets all client connections.
If you are restoring data from a VFS dump and the restoration operation is interrupted, the storage pool onto which the data is being restored can be marked BAD and incorrectly list the amount of space used on it. A storage pool that is marked BAD must be fixed by using the SpinFS file-checking utility. Contact Technical Support for assistance. (Bug 126737)
SpinServer and SpinFS documentation is available in PDF format and can be accessed from the SpinManager GUI or from the software CD-ROM. Some SpinServer and SpinFS documentation is also available in HTML format. To access the documentation from the CD, open the root_directory/SpinDocs/index.html file in a web browser, where root_directory is the root directory of the CD-ROM.
Data ONTAP™, FAS270c, DS14mk2 FC, and cabinet documentation is available in PDF format from the NetApp NOW site (now.netapp.com). Some documents are also provided in hardcopy in the FAS270c doc box.
All SpinServer and related documentation is available from the NOW site.
The SpinServer documentation set includes the following books.
SpinFS Architecture Basic Concepts Guide—This document provides an overview of the SpinFS architecture, including the hardware and software components of a SpinServer system.
SpinFS 2.5 Administration Guide—This document is for system administrators who administer and maintain a SpinServer system. It provides information about initialization tasks such as installing and upgrading the SpinFS software, configuring RAID sets, and setting up virtual servers, and on maintenance tasks such as adding new storage, backing up the system, adding a server to a cluster, and monitoring system performance.
SpinFS 2.5 Administration Reference—This document is for system administrators. It provides a comprehensive listing of all system-management commands, including command syntax, parameters, usage scenarios, and examples.
SpinFS 2.5 Messages and Troubleshooting Guide—This document provides a listing of the system events that can be generated by a SpinServer system running SpinFS 2.5. Each system event includes a descriptive message. Causes and troubleshooting actions are listed where appropriate.
SpinServer 4100 Installation Guide—This document is for technicians and system administrators who install and configure the SpinServer product. It provides information about tasks such as designing the system configuration, laying out and installing components in a rack, configuring the power distribution, cabling components together, and attaching the system to a network.
SpinServer 4100 Quick Start Guide—This document is for experienced technicians and system administrators who set up racks and install product components. It provides an overview of system setup and configuration that enables a knowledgeable user to set up and run a simple SpinServer configuration. In addition to being available online, the Quick Start Guide is shipped in hardcopy with the product.
SpinFS Release Notes—This document is for technicians and system administrators; it is required reading for anyone who sets up, maintains, or administers a SpinServer system. It provides late-breaking information about the product, including hardware and software updates, known and resolved product issues, workarounds for known problems, and the latest upgrade procedures.
SpinServer Supported Storage Release Notes—This document provides information about the storage products that are supported by the SpinServer, including notes and tips for configuring supported third-party storage products for use with a SpinServer system.
SpinServer Site Preparation Guide—This document is for technicians and system administrators who are preparing to install and configure a SpinServer system. It describes system and site requirements so that you can gather the necessary information and equipment to prepare a site for the installation of a SpinServer system. This document is available both in PDF format and as a form in Microsoft Word that you can fill out and return to NetAppl personnel.
SpinServer 4100 Field Service Guide—This document provides information about replacing field-replaceable units (FRUs) for the SpinServer 4100 server, SpinStor 200 disk enclosures, UPS, and ATSs.
Connecting SpinServer System Server and Storage Cabinets—This document provides instructions for making Fibre Channel connections between the server cabinets and storage cabinets of a SpinServer system. This document is a supplement to the SpinServer 4100 Quick Start Guide.
SpinServer 3300 documentation. See this documentation if you are running SpinFS on a SpinServer 3300 system. The SpinServer 3300 documentation includes the following books:
SpinServer 3300 Quick Start Guide
SpinServer 3300 Installation Guide
SpinServer 3300 Field Service Guide
Note: The SpinServer 3300 documentation set has not been updated with NetApp information. These documents are provided as reference only for users of legacy SpinServer 3300 systems.
In addition to the SpinServer-specific documentation, the following documentation applies to the SpinServer system:
Data ONTAP 6.5 documentation set
FAS270/270c Hardware and Service Guide
Fibre Channel DiskShelf14 Hardware Guide
42U System Cabinet Guide
The following are known issues in the documentation:
The SpinServer 3300 Quick Start Guide states that it is recommended that the SpinServer's management port, clustering ports, and network (client access) ports be connected to different subnets. It is required that the management port be on a separate subnet from the network ports. (Bug 127725)
The SpinServer 3300 Field Service Guide states that the SpinServer must be powered off before you replace one of the SpinServer's SCSI drives. The SCSI drive is hot swappable; you do not need to shut down the SpinServer before replacing a SCSI drive.
| Next | ||
| Copyright and trademark information |
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.