gary@uunet.uu.net (Gary Cattelino) (01/03/90)
We are about to purchase a new Sun 4/490 fileserver and I would like to
get advice from the net on how best to set it up and use it.
The 4/490 configuration to be purchased:
32 Mbytes ECC memory, 5 or 6 1-GByte disks, 2 IPI disk controllers, 1/2"
tape, 1/4" tape, 8mm tape (all tapes are in the rack!), 19" monochrome
monitor. The second SCSI hose adapter that is needed for the third tape
drive will also have an external connector for external SCSI devices (or
so I'm told by my Sun sales rep).
BACKGROUND
----------
We currently using the following sun equipment:
Quantity Model Configuration
-------------------------------------------------
6 4/110 8meg memory, 327 meg disk (one with a wren V also)
1 4/260 32meg memory, 2x280 meg disks
3 386i/250 327 meg disk
1 386i/150 91 meg disk
20 Sparc 1 2x104 meg disks, 8 or 16 meg memory
2 Sparc 1 104 meg disk, 8 meg memory
Every machine is currently running standalone each with their own copy of
unix. Files are all over the network and are either being mounted with
NFS or in the automounter tables (one group of people refuse to use the
automounter and like to cross mount everything...sigh). At least most of
the home directories are on a Wren V connected to one of the 4/110s.
As you can see, we are in desperate need of a fileserver.
GOALS
-----
I would like to use the new fileserver to help centralize the
administration of the network and consolidate the file storage in one
place. For example, I would like to easily upgrade the OS without having
to go from machine to machine loading data. Also, centralized backup of
important data is a must!
One possible setup I've been thinking about is to have all the machines
boot and get unix from the file server and use the local disks for swap,
/tmp and local data files. The 386i machines do not have to be booted
from the fileserver and will probably remain standalone (no one really
uses them).
We are using the Suns to process seismic data so we have no problem
filling up disks. I'm not sure if we need to backup the raw seismic data
or not, as it can always be reloaded from tape. The processed data and
intermediate data files might be candidates for backup since to recreate
them from the raw data would require some work.
Any advice on the use of this new fileserver would greatly be appreciated.
How would you partition the file server disks? Should I repartition the
client machines or just do a newfs on the c partition and use a .swap file
in the /tmp partition (with /tmp mounted on the c partition)? What are
the advantages/disadvantages of using a swap file .vs. a swap partition?
Our local Sun FE says that a swap file gives the same performance as a
swap partition and recommends to always use a swap file.
Please mail me or post replies to sun-spots.
P.S. If anyone would like to work here and help me run this network,
please let me know!
Gary A. Cattelino Unocal Science & Technology
sun!sunkist!cerveza!gary gary@unocal.com
uunet!{zardoz,spsd}!cerveza!gary
(714) 528-7201 x2715pcg@compsci.aberystwyth.ac.uk (01/29/90)
In article <4195@brazos.Rice.edu> Gary Cattelino writes: X-Sun-Spots-Digest: Volume 9, Issue 4, message 12 of 12 | |We are about to purchase a new Sun 4/490 fileserver and I would like to |get advice from the net on how best to set it up and use it. | |The 4/490 configuration to be purchased: | |32 Mbytes ECC memory, 5 or 6 1-GByte disks, 2 IPI disk controllers, 1/2" |tape, 1/4" tape, 8mm tape (all tapes are in the rack!), 19" monochrome |monitor. This is wild overkill for a file server. The bottlenecks will be the network interface boards. You may well be advised to buy several smaller machines, one for each disc or couple discs; in this way the paths to the discs will all be independent, each with its own network interface board, cpu, etc... File servers, contrarily to what manufacturers make you believe, are not cpu-bound, they are bandwidth bound; on one side, they are limited in bandwidth from the discs, on the other, by the network interface. Moreover, they are not memory bound at all, even if memory may help caching the discs; but then it is better to cache in the clients, because it cuts down on network transactions as well. I don't know the relative costs of these solutions, but I would buy three smaller machines, give each its 8mm backup and two gigabyte discs. Cost may well be lower, and performance and availability would probalby be much better. Quantity Model Configuration ------------------------------------------------- 1 4/260 32meg memory, 2x280 meg disks Use this as compute server, with *large* swap and /private|/var areas on those two discs; Purdue have done a shell that will automatically remotely execute piggy commands on the least loaded machine on the network, and I think it is available. Else, you can put shell scripts around that manually invoke remote execution for known piggy programs (e.g. troff, tex, spice, etc...) 6 4/110 8meg memory, 327 meg disk (one with a wren V) 3 386i/250 327 meg disk 1 386i/150 91 meg disk 20 Sparc 1 2x104 meg disks, 8 or 16 meg memory 2 Sparc 1 104 meg disk, 8 meg memory Excellent setup. Configure the local discs for swap and temporaries, and maybe roots, centralize user files on the fileservers. In this way you will never have to backup or otherwise deal with the local discs. You have, by the way, too many machines to be usefully served by a single fileserver communicating through a single network interface. One should not go above 10 machines per server in general, or somewhat more if swap and /var|/private are on local discs. You don't really need to have the 327 meg discs on the 386is or the 4/110s, or the second 104 meg on the SS 1s; you can usefully centralize the 327 meg discs, and then give the 386is and the 4/110s some of the second 104 meg discs. The 104 meg discs you could centralize as well, or maybe use for extra swap and /private|/var space for local machines that do especially large jobs. Or you could send me a couple :->... By the way, if, as you say later on, the 386is are not really used, you can use them as fileservers; I would use some of 4/110s as fileservers as well, and save the expense (one could use all the 386is as file servers, but I don't know if you can attach the 1 giga discs and the exabytes to those). Summing up, you have *now* nine 327 meg discs one 91 meg disc, and forty two 104 meg discs that you can reallocate. I would configure your network as: 3 386i/250 104 meg disk, 2x327 meg discs 1 386i/150 91 meg disk, 3x327 meg discs 3 4/110 8meg memory, 104 meg disk, 2x1000 meg discs, 1 8mm tape, etc... 3 4/110 8meg memory, 104 meg disk, 22 Sparc 1 104 meg disk, 8 or 16 meg memory You find yourself with thirteen 104 meg disks spare. Well, this is actually one of the possible configurations, but I assume you see my points in the example above. |As you can see, we are in desperate need of a fileserver. Yes, and no. You are in great need of simpler administration. |I would like to use the new fileserver to help centralize the |administration of the network and consolidate the file storage in one |place. Centralizing things on one or more fileservers will surely help. But beware of potential, awful performance hits. "NFS server xxxx not responding" is the bane of many SUN networks... |For example, I would like to easily upgrade the OS without having to go |from machine to machine loading data. Also, centralized backup of |important data is a must! You are mostly right. Backup can be done over the net, but I would not do it for 6 GBytes of data... Actually going diskless does not necessarily help "having to go from machine to machine", because "discless" is really "remote disc"; in itself, this does not change anything, except backups. You have to be *very* careful if you want to reap the advantages of simplified administration. For example, you want to configure the roots of the clients so that they are *exact* copies of each other (not easy, you need a couple tricks), so that you just update a "master" one and then duplicate it. You also want to do other things, and these appear in a recent posting of mine to sun-spots. |One possible setup I've been thinking about is to have all the machines |boot and get unix from the file server and use the local disks for swap, |/tmp and local data files. If you sue them for local data files, you still have the backup problems. You may use them also maybe for local roots and local shared executable and library files, that in any case need not be backed up because they are copies of a master on the server. Having them locally can improve performance. |Our local Sun FE says that a swap file gives the same performance as a |swap partition and recommends to always use a swap file. Well, I agree, but for other reasons as well. In any case you really want to have local swaps, given that you have the discs to do it, and in that case having a swap partition is the easiest thing. You would go for swap files if you had them on a remote fileserver, but this entails a performance hit, and you need not do it. Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk