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
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
