Re: available resource declaration language(s)

["Jeff Darcy" <jeff@tambreet.com>]

> If you have a
> cluster - buy a switch.

Better yet, buy two so you don't have a SPOF.


A few comments on the larger issue of how to distribute information...

Broadcast is anathema to many network administrators, and in some networks
it's simply not available, so arguments about X% of total network bandwidth
are meaningless.  Having every node send to N peers is pretty non-scalable
too.  A ring, tree, mesh, torus, or N-dimensional cube is likely to be much
more efficient, and the difficulty of maintaining any of these structures
can be surprisingly low.  At a theoretical level I'm a little leery of
MOSIX-like diffusion models that do not provide a *guarantee* that
information will get from X to Y in a timely manner, but as a practical
matter it seems to work quite well and it certainly scales.

Should resource information be piggybacked on heartbeats?  Probably not,
IMO.  They have different requirements for reliability, bounded delivery
time, etc.  Heartbeats should remain reasonably small and must be processed
expeditiously, whereas resource advertisements might be arbitrarily large
and are not time-critical.  Having a receiver delay handling of heartbeat N
because it's still processing the resource information from heartbeat N-1
would be unacceptable, and you just know that many receiver implementations
would end up doing just that.

There's enough in common between the two problems that maybe there's some
common mechanism that could be used for both, perhaps using a QoS/priority
notion to deal with the differences.  But just dumping the resource info on
top of the heartbeats strikes me as a mistake.



Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/