I got three replies to my original posting but it was
better than none. :-)
Thank you for your input.
James
+>We're thinking about going 'dataless' here for our
+>SparcStations 1+ and 2's. I'm thinking about setting up
+>a slave server in case the master server goes down.
+>
+>I have a couple of questions:
+>
+>-How easy is it to switch over to a slave server if the
+> master server crashes?
+>
+>-Will the clients hang if the '/usr' is not available
+> during boot time?
+>
+>-What are the advantages/disadvantages in going 'dataless'?
+>
+>-Are they any 'pitfalls' to look out for?
+>
+>
+>-Any other comments about dataless nodes?
+>
+>Thanks
+>James Kwong
========================================================================
From: pln@egret0.Stanford.EDU (Patrick L. Nolan)
In comp.sys.sun.admin you write:
>We're thinking about going 'dataless' here for our
>SparcStations 1+ and 2's. I'm thinking about setting up
>a slave server in case the master server goes down.
>I have a couple of questions:
>-How easy is it to switch over to a slave server if the
> master server crashes?
>-Will the clients hang if the '/usr' is not available
> during boot time?
Yes, indeed. There's very little you can do in this case.
>-What are the advantages/disadvantages in going 'dataless'?
Advantages: Don't need large disks on clients.
Easy modification of some parts of configuration;
just change one copy of a program, and everyone gets it.
Disadvantages: Clients are dead meat if the server or network has
problems. You can't even boot properly in single-user
mode.
Extra network traffic.
Booting across a router is difficult (but doable).
>-Are they any 'pitfalls' to look out for?
>-Any other comments about dataless nodes?
If your local disks are 200 MB or bigger, I would recommend having
a local /usr on each one so it can boot by itself. Make sure
this is a vanilla, straight-out-of-the-box configuration as supplied
by Sun (with security fixes). Use rdist to keep this up to date.
Put all your additional software and local stuff in /usr/local,
and nfs-mount this from the server. The goal is to have the
most frequently changing things on the server, while keeping the
local configurations static.
========================================================================
From: jhb@maths.su.oz.au (John Brownie)
In comp.sys.sun.admin you write:
>We're thinking about going 'dataless' here for our
>SparcStations 1+ and 2's. I'm thinking about setting up
>a slave server in case the master server goes down.
>I have a couple of questions:
>-How easy is it to switch over to a slave server if the
> master server crashes?
No idea - we don't have a salve server.
>-Will the clients hang if the '/usr' is not available
> during boot time?
Yes. If the server goes down, all the clients stop until it comes
up (you get the message NFS server xxx not responding; still trying).
>-What are the advantages/disadvantages in going 'dataless'?
Dataless is a lot better than diskless, especially in terms of speed on
the client. Local swap makes a big difference.
With dataless clients, you don't need to worry about backups (apart
from a backup of the root partition).
One disadvantage is that everything is predicated on the reliablility
of the server (see above).
>-Are they any 'pitfalls' to look out for?
Most people say to set the root partition very small. However, if you
run a windowing system, and stay logged in for a reasonable length of
time, you will eventually fill up /tmp with the data in your windows.
If you deal with large programs, don't try to run the debugger on them
from any machine other than the one which has the program on local disk
- you will be there forever!
>-Any other comments about dataless nodes?
We like using them. In particular, it simplifies backups.
-- John Brownie School of Mathematics and Statistics University of Sydney Internet: jhb@maths.su.oz.au======================================================================== From: jfd@mrjones.octel.com (John F. Detke)
In article <862@caldwr.water.ca.gov> you write: > >We're thinking about going 'dataless' here for our >SparcStations 1+ and 2's. I'm thinking about setting up >a slave server in case the master server goes down. > >I have a couple of questions: > >-How easy is it to switch over to a slave server if the > master server crashes? Depends on how you define "easy" :) Could be as simple as remake NIS maps and reboot the clients. Could involve a lot of changes to files, depend on how you set the "slave". I think a better term would be "alternate".
> >-Will the clients hang if the '/usr' is not available > during boot time? yes, /usr is required during boot. You can muck around with only /, but this is very restricted. See /sbin for available commands.
> >-What are the advantages/disadvantages in going 'dataless'? I wish I kept recent mail I sent. Our primary reason for dataless is that it is the only hope I have (only admin currently, a couple "operators") of upgrading 100 clients' OS.
Primary disadvantage are performance & network traffic. These can both be addresses by partitioning the network via routers such that you have 12-24 clients per network, which has a local server. We have an auspex, which is very good at this kind of thing.
Our dataless means clients have local swap & tmp. Diskless clients (swap over the net) will really beat a network to death.
Client type & OS level are a factor also. This works best with a homogeneous network.
> >-Are they any 'pitfalls' to look out for? For what? dataless or setting up an alternate server? There are always pitfalls. Server performance, network reliability, and many others. If you have lots of admins (high admin/machine ratio, like 1/10) then dataless is questionalble.
If you have a high admin/machine, like 1/40, and have the server machines & network capacity, then I think it is a win. If you have a high reliability requirement, then an alternate server might be worthwhile. We have to spend time & $$ to ensure the primary doesn't go down, but only run 10x6.
> > >-Any other comments about dataless nodes?
Have you ever upgraded the OS on 100 standalone machines?
> >Thanks You're welcome. -- John F. Detke Speaking from, but not for: Octel Communications Corp 890 Tasman Drive M/S 05-04 Milpitas CA 95035 jfd@octel.com
-- James Kwong Calif. Depart. of H2O Resources, Sacramento, CA 95802 DOMAIN kwongj@water.ca.gov UUCP ...!ucbvax!ucdavis!caldwr!kwongj The opinions expressed above are mine, not those of the State of California
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:39 CDT