Since I'm rambling now, guess I should do the rest of the memory download...
One of the big problems with Linux diskless is it really doesn't scale well, it
doesn't
allow for clients to run multiple versions of the os, nor for different arch
types to
co-exist off one server of a different arch type.
Additionally, a typical diskless setup exports /usr as a read only file system
(which by
most definitions, it is supposed to be). Lots of developers ignore this and
never think
about writing a small file into some /usr/... path during normal operation.
Linux is
usually much better at leaving /usr read only. But there is an argument that
/usr/portage
should be /var/portage. But */portage is pretty easy to move, so it's not a
big deal. See -
http://www.kurobox.com/online/tiki-index.php?page=InstallGentooBeta1
Under the heading - "Configuring Portage"
Another not so well thought out diskless problem with Linux is all the setups
use one kernel
under /tftpboot or, at least the Gentoo Diskless guide uses /diskless, which
makes it
a bit movable, but then falls into showing the path as -
/diskless/xxx.xxx.xxx.xxx (an IP number)
instead of using the node name. The other problem, is they all assume only one
kernel vs. a
kernel for each host.
For a good idea of how a robust diskless setup should be done, please see -
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Admin/Diskless_AG/sgi_html/pr01.html
The SGI IRIX Diaskless Workstation Administration Guide.
So here's a general overview of how a robust diskless infrastructure should be
done -
- The server should be capable of supporting multipe arch types, even
OS types, as
long as the NFS' are compatible.
- The diskless trees should be capable of being moved to other drives
or even servers.
- Clients should be known by host name, not IP. The server's
/etc/hosts, /etc/resolv.conf
should define all that's needed for a client to operate, thus can
simply be copied, intact,
to each client's /diskless/client-name/etc.
- Common files across clients, should reside in common share trees,
which are exported read
only.
- Clients should be capable of operating as full systems, minus having
a local disk.
- A set of wrapper scripts is needed to allow for package management of
share trees
and client trees.
- Client system management, excluding package management, should be
done on the
diskless client.
- DCHP providing is reserved to the diskless server. Nothing says it
can't also provide
general DHCP support for other systems beyond the diskless clients.
- Diskless nodes should be capable of having attached storage, even
shared mounts
from NAS and SAN systems.
- In a production or a secure environment, diskless should be robust
enough to allow
changing it on a daily basis - swapping drives out to meet changing
needs of visiting
clients while still giving access to shared storage. (Linux is not
robust in this aspect.)
fwiw, here are the weekly diskless things I and my piers do with diskless -
Regularly run a 16P O3K booted diskless off a 2P O350 server under IRIX, along
with other nodes - some O2s running under a different share tree, and a Voyager
system (two pipe Gfx visualization system) booted across multiple sub-nets.
Do a weeky update of IRIX on 3 diskless servers and run long term testing -
>110hrs,
max load on 11 clients of mixed arch types. btw - these servers are all on the
same sub-net.
Do daily booting and installs via a diakless boot of new Linux kernels on ia64
systems via
a fileserver running Gentoo. The systems install kernels and other Linux
updates via diskless
network boots, then reboot up as regular systems and run automated system
testing.
Bob
-
--
[email protected] mailing list
