new fileserver setup

[pcg at compsci.aberystwyth.ac.uk]

In article <4195 at 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 at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk