Date: Tue, 30 Jun 1998 19:59:24 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: hackers@FreeBSD.ORG Subject: Anyone interested in an "interesting" project idea? Message-ID: <11704.899261964@time.cdrom.com>
next in thread | raw e-mail | index | archive | help
This is something that DG and I were talking about for awhile on the
phone last night and agreed that it would be a nice feature if one
were also *very careful* to note that this was neither a replacement
or substitute for actual clustering, just one piece of the clustering
universe (ala VMS more than "PVM" and friends) brought into FreeBSD
for administrative convenience.
Right, that disclaimer aside, the basic (and very half-baked, based on
a single conversation :) concept. First, you change pid_t from an
integer to something like this:
typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t;
So that for any given pid, you can find out if it's running on your
machine (hostid = 0) or is really somewhere else.
Then you add some extra smarts to the kernel* to do hostid to network
ID translation (an IP address for now, I guess) and also teach it the
notion of a cluster group, basically some list of hosts which are said
to share the same "cluster identifier." When some operation is
carried out against a foreign pid, like signal delivery, the kernel
would be responsible for mapping the hostid to an actual IP address
and doing an RPC for the remote operation with the user credentials
and such being passed along. Needless to say, such machines would
also have to trust one another. :-)
The cluster naming issues would come up with reporting commands like
ps - if you want ps to show the processes running on every node in
your cluster, for example, you need to have some notion (somewhere) of
which hosts comprise it so that `ps -axC' will generate a nice list of
processes for only your home cluster. You also probably want to be
able to do things like `ps -axC admin' to get a ps for all the hosts
in the `admin' cluster, or allow the default cluster to be overridden
in the environment.
Note that, again, this is *not* anything like actual clustering even
though I'm using that word. It's more like an "administrative unit"
paradigm where you can do any process operations for any machine in
the unit from any other machine. Just think of the possibilities:
<ring ring> "*click* Hey Joe, did you know some crackers are into your
systems? They have 40 eggdrops running on every single one of your
29 shell machines! Heh.."
"Dammit! Is that true?! Hang on!"
# ps -axC shell-group | grep egg
<spew spew - bastards! I'll kill those little &*%$#@!!>
# killall -9 -C shell-group eggdrop
<die, die! haha!>
And isn't that a lot easier than the alternative? :-)
Sure, one can always cobble together kludges which do essentially the
same thing, but it's a real pain compared to simply teaching the
system how to allow process administration to be more group oriented -
one of those features, as DG put it, that you wonder how you ever
lived without once you've had it. I also said `kernel*' earlier since
there's some possibility that you could do a lot of the translation
and lookup stuff in usermode, it wouldn't have to be in the kernel.
You could even strip the extra hostid information off the pid_t's in
the relevant syscall wrappers (kill(), wait(), etc) and do the RPC
before the kernel even gets its hands on the pid, going for minimal
change, but some aspects of this might end up needing to be stuffed
into the kernel anyway for other reasons - it's hard to say without
getting more seriously stuck into the problem.
Anyway, people are always clamoring for project ideas and saying that
we in core don't share enough of our wishlist items with folks, so
here I am. Any volunteers? :-)
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11704.899261964>