>>>> I thought "dampen" attribute could help with some of the options, but >>>> actually it is does not. >>> >>> It should do. ?Hard to say without any logs from the two machines. >> >> Unfort. I don't have log files here, can provide you if that would help. >> Are you sure dampen should help here? From my testing it only does: >> "Unless the next attribute value is stable for dampen interval, do not >> change the attribute value in CIB". However, the pingd attribute is >> set for two nodes, thus they are stored in separate XML section >> meaning they are not correlated by dampen. > > But the attribute that is set in both cases is called "pingd", so yes, > dampen should definitely apply here. > What version of pacemaker do you have? That would also be relevant.
# rpm -qa|egrep 'pacem|heart|glue' heartbeat-3.0.1-1.el5.x86_64 cluster-glue-libs-1.0.1-1.el5.x86_64 cluster-glue-1.0.1-1.el5.x86_64 pacemaker-1.0.7-2.el5.x86_64 heartbeat-libs-3.0.1-1.el5.x86_64 pacemaker-libs-1.0.7-2.el5.x86_64 Please find attached ha-debug logs from following tests: 1. dc and non-dc from situation where VM was restarted. Currently active node was DC. 2. dc_noreboot and non-dc_noreboot from situation where VM was not restarted (I would like to achieve this). Currently active node was not the DC. Both tests used dampen=5s So it seems like it would be better to have DC assigned into standby node every time (this would also make failovers faster). But there is no option how ho force DC election or assign the role. Am I right? If dampen handling was fixed later, it would be great. I don't think this is the case, the only relevant commit seems to be: http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/214f0fc258f2 More verbose description how dampen is supposed to work would also be handy. > >> I tried dampen 5s and 0s >> without any effect. >> My issue is that Pacemaker acts immediatelly after getting local >> update request, nomatter what the remote is trying to say. Remote >> update is processed only after migration decision is made and that is >> a bit late. >> >>> >>>> The only thing that worked for me was >>>> restarting of standby CRM, until its monitoring cycle was a bit behind >>>> the active. But I would not be happy with it. >>>> Does anybody have any idea if there could be some option like "Hey, >>>> change of this attribute can trigger resource migration. Let's wait a >>>> while (configured) for standby value update..."? Or any other crazy >>>> ideas? >>>> >>>> Thanks, >>>> Tino >>>>
dc
Description: Binary data
non-dc
Description: Binary data
dc_noreboot
Description: Binary data
non-dc_noreboot
Description: Binary data
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
