<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>> > The setup "almost" works (all seems ok with: "pcs status", "crm_mon<br><div>> > -Arf1", "corosync-cfgtool -s", "corosync-objctl | grep member") , but<br>> > every time it needs a resource promotion (to Master, i.e. becoming<br>> > primary) it either fails or fences the other node (the one supposed to<br>> > become Slave i.e. secondary) and only then succeeds.<br>> ><br>> > It happens, for example both on initial resource definition (when<br>> > attempting first start) and on node entering standby (when trying to<br>> > automatically move the resources by stopping then starting them).<br>> > <br>> > I collected a full "pcs cluster report" and I can provide a CIB dump,<br>> > but I will initially paste here an excerpt from my configuration just<br>> > in case it happens to be a simple configuration error that someone can<br>> > spot on the fly ;> (hoping...)<br>> > <br>> > Keep in mind that the setup has separated redundant network<br>> > connections for LAN (1 Gib/s LACP to switches), Corosync (1 Gib/s<br>> > roundrobin back-to-back) and DRBD (10 Gib/s roundrobin back-to-back)<br>> > and that FQDNs are correctly resolved through /etc/hosts<br>> <br>> Make sure youre DRBD are "Connected UpToDate/UpToDate"<br>> before you let the cluster take over control of who is master.<br><br>Thanks for your important reminder.<br><br>Actually they had been "Connected UpToDate/UpToDate", and I subsequently had all manually demoted to secondary<br>then down-ed before eventually stopping the (manually started) DRBD service.<br><br>Only at the end did I start/configure the cluster.<br><br>The problem is now resolved and it seems that my improper use of rhcs_fence as fence-peer was the culprit (now switched to crm-fence-peer.sh), but I still do not understand why rhcs_fence was called at all in the beginning (once called, it may have caused unforeseen consequences, I admit) since DRBD docs clearly state that communication disruption must be involved in order to call fence-peer into action.<br><br>Many thanks again.<br><br>Regards,<br>Giuseppe<br><br></div> </div></body>
</html>