[Linux-cluster] CS4 / U2/U3/U4/ problem about cluster_id generation

[Patrick Caulfield]

Alain Moulle wrote:
> Hi
> 
> There is a problem of unicity of cluster_id :
> 
> I have a big configuration with lots of CS4 clusters in pairs.
> The cluster_names are such as :
> iocell1 for first pair
> iocell2 for 2nd one
> ...
> 
> Naming is automatic as there are lots of HA node pairs.
> 
> ok, now let's take the cluster iocell13 and iocell21 and the
> algorythm in cnxman.c :
> 
> static uint16_t generate_cluster_id(char *name)
> {
>         int i;
>         int value = 0;
> 
>         for (i=0; i<strlen(name); i++) {
>                 value <<= 1;
>                 value += name[i];
>         }
>         return value & 0xFFFF;
> }
> 
> For iocell13 :
> [[[[[[["i"/0x69]*2+"o"/0x6f]*2+"c"/0x63]*2+"e"/0x65]*2+"l"/0x6c]*2+&qu
> ot;l"/0x6c]*2+"1"/0x31]*2+"3"/0x33 == 0x6895 == 26773).
> 
> and for iocell21:
> [[[[[[["i"/0x69]*2+"o"/0x6f]*2+"c"/0x63]*2+"e"/0x65]*2+"l"/0x6c]*2+&qu
> ot;l"/0x6c]*2+"2"/0x32]*2+"1"/0x31 == 0x6895 == 26773).
> 
> so we have two identical cluster_id for two different cluster
> (based on cluster names).
> 
> So there is problem because a node denies/un-acks the joins since the same
> "cluster-id" is claimed but with an other Cluster name also checked
> 
> I've checked that algorythm has not been modified since U2 , and therefore
> the problem remains for sure with U4.
> 
> Any idea to solve it for sure ?

Not really, sorry.

It's unlikely to change in the future for RHEL4 because that would break backwards compatibility.

-- 

patrick