[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inventory
David L. Nicol writes:
> Or at least defining what is and is not a "cluster service."
> For instance, PVM and rsh, as beautiful and useful as they
> are, do not require any blurring of the line between what is running
> in which box.
Just the opposite: they will have problems when you blur the
lines between boxes. Nodes need not have distinct names, and any
process migration can dump you right back where you came from!
Think of the above problem on a common SMP system. Can I rsh
from CPU 2 to CPU 3 in any meaningful way?
> It's stunning the level of not-made-here-itis that these projects
> can accumulate.
It's to be expected I think. Transport capabilities vary widely
and goals differ. Throwing together a Beowulf is not the same as
building fault-tolerant compact PCI systems for telecom.
> Lets focus on one thing that we know all clustering schemes have, and
> see if we can standardize it, then go from there. My nominee of a
> suitable case for this treatment remains node numbering.
>
> Consensus appears that there is a standard file that can be read from
> to determine one's node number, or written to to change it.
To me, the node ID is a small integer, from 2 to 2000 perhaps.
The boot loader may directly set the value, using the System.map
file to determine location. It could be a command line option.
> Mosix "clutters up" /proc with all of its controls and displays; and
> it has been suggested that it is preferable to define a New File System
> for a clustering architecture's controls and mount it somewhere rather
> than doing this. I like this approach since not only does it reduce
> the amount of patching (new clusterfs instead of altered procfs) it
If you need a big tree: new file system
If you need a file: use /proc for it
Hacking up /proc is needed anyway, for a shared PID space.
> trivially allows participation in multiple clusters by mounting multiple
> clusterfses at multiple places
I see this as featuritis. Boot into a cluster, and shutdown to leave.
> Are all in agreeement with the above notes and ideas?
No. More likely, are all in mutual disreeement?
Linux-cluster: generic cluster infrastructure for Linux
Archive: http://mail.nl.linux.org/linux-cluster/