[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Openais] Re: [Linux-cluster] new userland cman

Steven Dake wrote:
> Patrick
> Thanks for the work
> I have a few comments inline
> On Fri, 2005-09-30 at 14:44 +0100, Patrick Caulfield wrote:

>>- Hard limit to size of cluster (set at compile time to 32 currently)***
> I hope to have multiring in 2006; then we should scale to hundreds of
> processors...

Nice :)

I have some ideas for shrinking the size of the current packets which will help
the current system and lower the ethernet load. I'll start on those shortly.

>>- Always uses multicast (no broadcast). A default multicast address is supplied
>>if none is given
> If broadcast is important, which I guess it may be, we can pretty easily
> add this support...

I was going to look into this but I doubt its really worth it. It's just any
extra complication and will only apply to IPv4 anyway.

>>- libcman is the only API ( a compatible libcman is available for the kernel
>>- Simplified CCS schema, but will read old one if it has nodeids in it.****
>>- Usable messaging API
>>- Robust membership algorithm
>>- Community involvement, multiple developers.
>>* I very much doubt that anyone will notice apart from maybe Dave & me
>>** Could fix this in AIS, but I'm not sure the patch would be popular upstream.
>>It's much more efficient to run them on different ports or multicast addresses
>>anyway. Incidentally: DON'T run an encrypted and a non-encrypted cluster on the
>>same port & multicast address (not that you would!) - the non-encrypted ones
>>will crash.
> On this point, you mention you could fix "this", do you mean having two
> clusters use the same port and ips?  I have also considered and do want
> this by having each "cluster" join a specific group at startup to serve
> as the cluster membership view.  Unfortunately this would require
> process group membership, and the process groups interface is unfinished
> (totempg.c) so this isn't possible today.  Note I'd take a patch from
> someone that finished the job on this interface :)  I for example, would
> like communication for a specific checkpoint to go over a specific named
> group, instead of to everyone connected to totem.  Then the clm could
> join a group and get membership events, the checkpoint service for a
> specific checkpoint could join a group, and communicate on that group,
> and get membership events for that group etc.
> What did you have in mind here?

Actually something /very/ simple. the old cman just had a uint16 in every packet
which was a cluster_id. If the cluster_id in an incoming packet didn't match the
one read from the config file then the packet was dropped. It's really just a
way of simplifying configuration for those using broadcast or a default
multicast address.

In my more evil moments thought it might be worth hijacking the commented out
"filler" in struct message_header :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]