Re: 2500 Linux workstation !
On Thu, 27 Jul 2000, Catalin Ciocoiu wrote:
>In a slashdot articol somebody lace a interesing question....
>What is the best solution for a network width 2500 Linux WorkStation ?
>I proposed a diskless workstation sollution becose is very robust
>sollution.
>Is it a good sollution ????
>What filesystem can be used for file sharing ?? Is NFS ok ???
>What kind of authentification can be used in this network ?
>
>I waiting your answares !!
One problem with diskless workstations is the issue of what happend when they
all reboot simultaneously (EG power failure). I suggest that you setup a
diskless workstation that is fully configured (X, xdm, etc), reboot it and
track the amount of data transfer that is required. I guess that it might be
about 30M of data access on disk. Multiply that by 2500 and that's 75G of
data transfer, it would be 2 hours of network transfer on 100baseT if you
didn't have timeouts and retransmits. Of course with that load you would
have heaps of timeouts and it would take much longer...
The good thing about diskless booting is that all machines will access mostly
the same files if you have it configured correctly. The boot space of a
diskless machine should fit into cache on the server (so disk bandwidth
shouldn't be an issue). If you have a server with 10 * 100baseT network
interfaces or 1 * 1G interface (the most that the bus bandwidth of typical PC
servers can handle) then it could possibly handle 800 PCs for booting in a
reasonable amount of time (5-10 minutes). So if you had 4 such machines for
running the boot process (IE the root file system) and another set of
machines for /home (which is much harder because the data is more important)
then it could be workable.
One thing I have been thinking of doing (an item on my almost infinitely long
todo list) is to hack a kernel to log the details of file access (file name
and the operation (read/write/etc) and the amount of data to klog and then
have a modified klogd write this data to a file which is outside this logging
(can't have it logging it's own accesses ;). Then I could boot the machine
(NB would need a extra-large klogd buffer to capture file access before klogd
had been loaded) and find out how much disk access really happens at boot.
--
My current location - X marks the spot.
X
X
X
Reply to: