Re: 2500 Linux workstation !
Russell Coker wrote:
> 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
> >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...
Whell .... On this network can be more than 1 fileserver and the
can be splited on more network segment. One file server for 50-100
station can be
ok ! The file server for 100 station is on the same net segment width
This can reduce subtantial net traffic over segments.
The /usr dir can be the same. And most files on the slash can be hard
for the same inod( eg: /bin/ls ).
> 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.
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com