Xref: utzoo comp.arch:19269 comp.unix.questions:26885 comp.unix.internals:1015 comp.unix.admin:517 comp.unix.large:183 comp.unix.misc:541
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!brahms.udel.edu!gdtltr
From: gdtltr@brahms.udel.edu (Gary D Duzan)
Newsgroups: comp.arch,comp.unix.questions,comp.unix.internals,comp.unix.admin,comp.unix.large,comp.unix.misc
Subject: Re: Killer Micro Question
Message-ID: <15786@brahms.udel.edu>
Date: 14 Nov 90 15:19:01 GMT
References: <16364@s.ms.uky.edu> <3849@vela.acs.oakland.edu>
Followup-To: comp.arch
Organization: Brain Dead Innovations, Inc. (BDI)
Lines: 50

In article <3849@vela.acs.oakland.edu> tarcea@vela.acs.oakland.edu (Glenn Tarcea) writes:
=>In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes:
=>
=>#I have been wondering how hard it would be to set up several 
=>#of the new fast workstations as one big Mainframe.  For instance,
=>#imagine some SPARCstations/DECstations set up in a row, and called
=>#compute servers.  Each one could handle several users editing/compiling/
=>#debugging on glass TTY's, or maybe one user running X.
=>#
=>#But how does each user, who is about to log in, know which machine to
=>#log into?  He ought to log into the one with the lowest load average, yet
=>#without logging on cannot determine which one that is.
=>#
=>
=>  This is not a direct answer to you question, but it may have some merit.
=>It sounds to me that what you are talking about is a lot like a VAXcluster.
=>I have often thought it would be nice to be able to cluster U**X systems
=>together. NFS is a nice utility, but it isn't quite what I am looking for.

   You might want to look into what research has been done in the area
of Distributed Operating Systems. Some of these use Unix(tm) and others
don't. My personal favorite (from reading up on it) is Amoeba, developed
by a group at VU in Amsterdam (including Dr. Tanenbaum, known for several
textbooks and Minix). It was build from the ground up, so it is not Unix,
but one of the first things built on top of it was a Unix system call
server which allowed for fairly easy porting of software.
   Anyway, many (if not most) DOS's will support some form of automatic
load balancing and possibly process migration (a hard thing to do in
general). As for which CPU to log onto, it doesn't matter; the DOS makes
the whole thing look like a single, large machine.
   For a more immediate solution, I put together a simple Minimum Load
Login server on a Sun 3 network here at the U of D (a real kludge, I
must say). To use it, one would "telnet fudge.it.udel.edu 4242". On
that port I have a program that searches a list of 3/60's and parses
a "rup" to each one. It then tosses packets between the caller's port
and the least loaded CPU's telnet port. This is a horrible, ugly solution,
but it works, and one can always just kill the original telnet and
manually start a telnet to the machine selected by the MLL daemon.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration



-- 
                            gdtltr@brahms.udel.edu
   _o_                      ----------------------                        _o_
 [|o o|]        An isolated computer is a terribly lonely thing.        [|o o|]
  |_O_|         "Don't listen to me; I never do." -- Doctor Who          |_O_|