Hideo, renayama19661014@xxxxxxxxx napsal(a): > Hi Honza, > > Thank you for comments. > >> Wait wait wait. This is totally different situation. My expectation was >> ONE cable per node for ONE switch. But you are using TWO switches and >> TWO cables per node. Are you using RRP? Or bonding? > > We use rrp. > >>> A control message of corosync goes each other, and, in the case of this trouble, does a problem not happen? >>> Does it not become the factor that cannot constitute a cluster? >> >> It really depends on technology you are using. Bonding shouldn't have >> problem with such situation, because each of cables is equal and you can >> lost any of them. RRP is totally different story and it will behave >> incorrectly (in a way you've described), because corosync itself will: >> - mark one of ring as failed >> - keep going between operational/gather state >> >> In other words, there will be membership, but very unstable. > > In the case of the constitution of the sw like us, it is necessary to use bonding. > * Not rrp, it is necessary to use bonding. > It's not necessary, because it is expected to replace failed part as soon as possible and chance that two cables fails is very small. Also RRP + bonding can be used for super critical systems (so there are two bond interfaces (each with two nics) and each of them is part of rrp). > We discuss adoption of bonding. > Bonding is well supported technology and I can only recommended it. Another solution can be http://kronosnet.org/ > Is there the plan solving this problem in the future in corosync? > Because it is specifications of corosync, there is not the plan to solve this problem in the future? I was thinking about that. RRP in corosync is implementation of http://corosync.github.com/corosync/doc/icdcs02.ps.gz and this paper turn out to be really more academic then useful for practice. On the other hand, I don't see any good in reimplementing bonding inside corosync, because there is real bonding. Anyway, give a try to bonding, I'm pretty sure it solve problems you are hitting. > > Many Thanks. > Hideo Yamauchi. > > > > Regards, Honza _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
