On Mon, Aug 10, 2015 at 9:30 AM, Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> Steven Dake <steven.dake@xxxxxxxxx> schrieb am 09.08.2015 um 01:02 in Nachricht > <CAPwfPsjd_SGrC923OUU=Q4LeUki_4nKExUCrZAT8Y7CiX8Ccng@xxxxxxxxxxxxxx>: >> Be careful with bonding - there are several different operational modes and >> only one works. We tested bonding extensively at RHT with corosync and >> came to the conclusion that only one bonding mode was reliable with >> corosync. I don't recall what the bonding mode # was specifically, perhaps >> Honza could read the documentation and report. > > Hi! > > I hope there won't be another message saying only one type of NIC was found to be working with Corosync ;-) My experience is that if higher level protocol natively supports multiple links with proper failure detection and failover, using lower level aggregation just makes things worse. I'd rather see proper support for multiple links on corosync level. > Before making statements like the one above, precisely list the requirements that corosync has, preferably referencing the bugs that lead to those requirements. > My basic idea is: If some UDP protocol like NFS works with a specific network connection, why shouldn't corosync work with a connection of equal quality? Because different protocols have different requirements? You can lose lot of NFS datagrams it will try recover indefinitely if suitably configured; but corosync likely have much stricter requirements and may not tolerate connectivity loss during switch between links. > > Regards, > Ulrich > >> >> Regards >> -steve >> >> >> On Mon, Aug 3, 2015 at 2:52 AM, <renayama19661014@xxxxxxxxx> wrote: >> >>> Hi Honza, >>> >>> Thank you for comments. >>> >>> >> I want you to teach Bugzilla of the contents of the problem that >>> happened >>> > in "active" if you know it. >>> >> ...Or information about the constitution of a cluster and the resource >>> that >>> > the problem happens. >>> > >>> > Actually, no document really exists. Active mode inability to deliver >>> > messages until failed ring is marked as failed is consequence of how >>> > active mode works. >>> > >>> >> >>> >> We want to discuss the future policy based on the information. >>> > >>> > I would suggest bonding. It's wider tested technology and as far as I >>> > can tell it has less corner edges than RRP. >>> >>> >>> Okay! >>> >>> We discuss future setting from now on. >>> As you say, we may be going to use bonding, too. >>> >>> Many Thanks! >>> Hideo Yamauchi. >>> >>> >>> >>> ----- Original Message ----- >>> > From: Jan Friesse <jfriesse@xxxxxxxxxx> >>> > To: renayama19661014@xxxxxxxxx; COROSYNC <discuss@xxxxxxxxxxxx> >>> > Cc: >>> > Date: 2015/8/3, Mon 16:18 >>> > Subject: Re: [Question] About "Add note about rrp active >>> beeing unsupported". of corosync2.3.5 >>> > >>> > Hideo, >>> > >>> > renayama19661014@xxxxxxxxx napsal(a): >>> >> Hi Honza, >>> >> >>> >> >>> >>>>> In addition, is there a point to be careful about when we >>> > continue >>> >>> using >>> >>>> "ative"? >>> >>>> >>> >>>> Only (but big) problem with active is that active doesn't make >>> >>> progress >>> >>>> if one of link fails until link is marked as failed. Passive always >>> >>>> makes progress (= works) even link is failed and failure is not yet >>> >>>> detected. >>> >> >>> >> >>> >> I want you to teach Bugzilla of the contents of the problem that >>> happened >>> > in "active" if you know it. >>> >> ...Or information about the constitution of a cluster and the resource >>> that >>> > the problem happens. >>> > >>> > Actually, no document really exists. Active mode inability to deliver >>> > messages until failed ring is marked as failed is consequence of how >>> > active mode works. >>> > >>> >> >>> >> We want to discuss the future policy based on the information. >>> > >>> > I would suggest bonding. It's wider tested technology and as far as I >>> > can tell it has less corner edges than RRP. >>> > >>> > Regards, >>> > Honza >>> > >>> >> >>> >> Best Regard, >>> >> Hideo Yamauchi. >>> >> >>> >> >>> >> >>> >> ----- Original Message ----- >>> >>> From: "renayama19661014@xxxxxxxxx" >>> > <renayama19661014@xxxxxxxxx> >>> >>> To: COROSYNC <discuss@xxxxxxxxxxxx> >>> >>> Cc: >>> >>> Date: 2015/7/28, Tue 09:55 >>> >>> Subject: Re: [Question] About "Add note about rrp >>> > active beeing unsupported". of corosync2.3.5 >>> >>> >>> >>> Hi Honza, >>> >>> >>> >>> Thank you for comments. >>> >>> >>> >>> >>> >>>>> In addition, is there a point to be careful about when we >>> > continue >>> >>> using >>> >>>> "ative"? >>> >>>> >>> >>>> Only (but big) problem with active is that active doesn't >>> > make >>> >>> progress >>> >>>> if one of link fails until link is marked as failed. Passive >>> > always >>> >>>> makes progress (= works) even link is failed and failure is not >>> > yet >>> >>>> detected. >>> >>> >>> >>> >>> >>> >>> >>> Does this mean that "actvie" setting delays the delivery to >>> > the node >>> >>> of the message of the normal interface until the interface that failed >>> > becomes >>> >>> "faulty"? >>> >>> >>> >>> Does it mean that the reconstitution of the cluster may happen until >>> an >>> >>> inoperative interface becomes "faulty" by this delay? >>> >>> >>> >>> If it is this phenomenon, I can understand a problem. >>> >>> >>> >>>> But as long as you are happy with rrp active, use active. >>> >>> >>> >>> >>> >>> Because the number of the nodes that we treated was not so big, a big >>> > problem of >>> >>> "active" has not occurred. >>> >>> >>> >>> I argue with a member and think about the use of future >>> > "rrp_mode". >>> >>> >>> >>> Best Regards, >>> >>> Hideo Yamauchi. >>> >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>>> From: Jan Friesse <jfriesse@xxxxxxxxxx> >>> >>>> To: renayama19661014@xxxxxxxxx; COROSYNC >>> > <discuss@xxxxxxxxxxxx> >>> >>>> Cc: >>> >>>> Date: 2015/7/27, Mon 18:46 >>> >>>> Subject: Re: [Question] About "Add note about rrp >>> > active >>> >>> beeing unsupported". of corosync2.3.5 >>> >>>> >>> >>>> renayama19661014@xxxxxxxxx napsal(a): >>> >>>>> Hi All, >>> >>>>> >>> >>>>> I thank for release of corosync2.3.5. >>> >>>>> >>> >>>>> We used the "rrp_mode:active" setting so far. >>> >>>>> >>> >>>>> The "rrp_mode: active" did not seem to be >>> > recommended when I >>> >>> saw >>> >>>> release note of corosync2.3.5. >>> >>>>> >>> >>>>> >>> >>>>> What is the cause that was not recommended from this time? >>> >>>> >>> >>>> It was actually never recommended, only change it's now noted >>> > in the >>> >>> man >>> >>>> page. >>> >>>> >>> >>>> >>> >>>>> In addition, is there a point to be careful about when we >>> > continue >>> >>> using >>> >>>> "ative"? >>> >>>> >>> >>>> Only (but big) problem with active is that active doesn't >>> > make progress >>> >>> >>> >>>> if one of link fails until link is marked as failed. Passive >>> > always >>> >>>> makes progress (= works) even link is failed and failure is not >>> > yet >>> >>>> detected. >>> >>>> >>> >>>> But as long as you are happy with rrp active, use active. >>> >>>> >>> >>>> Regards, >>> >>>> Honza >>> >>>> >>> >>>>> >>> >>>>> * We want to know a problem and the influence that were >>> > not >>> >>> recommended >>> >>>> in detail. >>> >>>>> >>> >>>>> >>> >>>>> Best Regards, >>> >>>>> Hideo Yamauchi. >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> discuss mailing list >>> >>>>> discuss@xxxxxxxxxxxx >>> >>>>> http://lists.corosync.org/mailman/listinfo/discuss >>> >>>>> >>> >>>> >>> >>> >>> >>> _______________________________________________ >>> >>> discuss mailing list >>> >>> discuss@xxxxxxxxxxxx >>> >>> http://lists.corosync.org/mailman/listinfo/discuss >>> >>> >>> >> >>> >> _______________________________________________ >>> >> discuss mailing list >>> >> discuss@xxxxxxxxxxxx >>> >> http://lists.corosync.org/mailman/listinfo/discuss >>> >> >>> > >>> >>> _______________________________________________ >>> discuss mailing list >>> discuss@xxxxxxxxxxxx >>> http://lists.corosync.org/mailman/listinfo/discuss >>> > > > > > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss