Hello,
I have joined this list because I am considering a purchase of either (~ 1/2 tB) :
1. A Netapp 760 Filer. 2. An Auspex file server.
3. Beefed up local RAID.
to serve as common, high performance, *shared* file space for two Origin2000 servers. I imagine a dedicated high speed network between the toaster and the two origins will be put in place if we go with the netapp type solution. I would appreciate your frank comments on the Filer's performance and reliability.
Thanks, nathan
On Thu, 3 Jun 1999, Nathan O. Siemers wrote:
- A Netapp 760 Filer.
Since you're only looking at two boxes accessing it, go with gigabit ethernet instead of etherchannel or single 100B-T if your origins can handle it. The 760 is nice in that it has 3 redundant power supplies. I would also consider buying another one and cluster the two together. Put one database on one and the other on the remaining one. If one of them decides to flake out for some reason the second one will take over the first one's identity in addition to its own in a matter of seconds. Also, get redundant power supplies for the disk shelves and put them on two independent power grids. Do something similar with the head(s).
- An Auspex file server.
Ugly, but not without merit for some applications. For your application, I'd try to stay away from it, but if you can acquire database file sanity check/incremental and differential backup tools for SunOS, it may be advantageous. OTOH, the backup devices will still probably be the bottleneck.
- Beefed up local RAID.
This is a good possibility especially since you're planning to use it with only two servers. Consider the cost and reliability issues, as well as administrative ease. You may get a performance boost over NAS boxes with gigabit if you use Fibre Channel instead of SCSI.
Above all onsider your current disk use and projected growth and pit it against the ease of expanding your database files. With NACs this is trivial up to 1.5 TB, which from what I hear will shortly be raised.
Tom
On Thu, 3 Jun 1999, Nathan O. Siemers wrote:
I have joined this list because I am considering a purchase of either (~ 1/2 tB) :
- A Netapp 760 Filer.
[...]
to serve as common, high performance, *shared* file space for two Origin2000 servers. I imagine a dedicated high speed network between the toaster and the two origins will be put in place if we go with the netapp type solution. I would appreciate your frank comments on the Filer's performance and reliability.
Watch for this option if you benchmark a NetApp.
This is from the ONTAP 5.2.1 documentation on CD. It appears to be a hidden option; that's why I didn't see it when we viewed the output of the `options` command.
5_2_1/doc/html/sag/stats7.htm
Improving filer performance [...] Improving performance on directory lookups
Turning the nfs.big_endianize_fileid option On improves performance on directory lookups for clients that use the file ID in the file handle as a hash key in certain ways. Enable this option if your NFS clients are mainly running HP-UX or IRIX.
Note: If you turn the big_endianize_fileid option On, all NFS clients that have mounted directories from the filer must unmount and remount them; otherwise, they get "stale file handle" errors on all references to files already opened on the filer until they unmount and remount all directories.
Until next time...
Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Until next time...
Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill@mathworks.com http://www.mathworks.com ---
This is from the ONTAP 5.2.1 documentation on CD. It appears to be a hidden option;
Prior to ONTAP 5.0, the file ID field of a file handle was in the native byte order of the processor; as all our machines have processors running in little-endian mode, that meant it was little-endian. We added that option, as a visible option, in some release whose number I no longer remember, in order to keep some NFS clients from hashing most file handles into the same hash bucket, and thus having to search through lots of file handles when looking up the "rnode" for a file given a file handle.
In ONTAP 5.0, we changed the file handle format to include an indication of the volume on which the file exists; there's a bit in the file handle indicating whether it's an "old-style" or a "new-style" file handle - NFS requests that contain an "old-style" file handle will return "old-style" file handles, and requests that contain "new-style" file handles will return "new-style" file handles. Mount requests return "new-style" file handles.
Given that we'd changed the file handle format anyway, we figured we might as well make the file ID field big-endian. Once we'd done that, the only reason for that option is to let machines that had been running with that option, and that had handed out "old-style" file handles with big-endian file IDs, continue to handle those file handles correctly.
Given that
... If you turn the big_endianize_fileid option On, all NFS clients that have mounted directories from the filer must unmount and remount them; otherwise, they get "stale file handle" errors on all references to files already opened on the filer until they unmount and remount all directories.
and that, on a 5.x system, the mount daemon hands out "new-style" file handles, there is no difference between turning the option on and having all clients remount file systems, and leaving the option off and having all clients remount file systems; both of them cause all clients to have "new-style" file handles, which means they have file handles with big-endian file IDS.
Therefore, we made the option hidden.
It appears, however, that we didn't fix the documentation, and it still says there's a reason why you'd want to turn that option on; I'll file a bug on that.
-
Guy Harris -
Nathan O. Siemers -
tkaczma＠gryf.net -
Todd C. Merrill