<div dir="ltr">Hi!<div><br></div><div>I am reading the corosync.conf man page.</div><div>Seems that I have to increase <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">token </span>and <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">token_retransmits_before_loss_const.</span></div>

<div><br></div><div><div><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">token<br></dt></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">

This timeout specifies in milliseconds until a token loss is declared after not receiving a token. This is the time spent detecting a failure of a processor in the current configuration. Reforming a new configuration takes about 50 milliseconds in addition to this timeout.</dt>

</div><div><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">The default is 1000 milliseconds.</dt></div></blockquote><div><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br>

</dt><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></dt><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"></dt><dt>token_retransmits_before_loss_const</dt><dd>This value identifies how many token retransmits should be attempted before forming a new configuration. If this value is set, retransmit and hold will be automatically calculated from retransmits_before_loss and token.<br>

The default is 4 retransmissions.</dd></div></div><div><br></div><div>I will try.</div><div>Thanks!</div><div><br></div><div><dt style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></dt></div><div><dd>

<br></dd><dd><br></dd><dd><br></dd><dd><br></dd></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 12:35 AM, Arnold Krille <span dir="ltr"><<a href="mailto:arnold@arnoldarts.de" target="_blank">arnold@arnoldarts.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 12 Aug 2013 19:27:33 +0200 Adrián López Tejedor<br>
<<a href="mailto:adrianlzt@gmail.com">adrianlzt@gmail.com</a>> wrote:<br>
> The problem is the network is out of my control. All the nodes are<br>
> virtual machines over some VMWare ESX.<br>
> We have two different networks, one for the service, and the other<br>
> for the cluster.<br>
> One idea is to create a second ring in the service network, but<br>
> networks are virtualized, so maybe the problem persists.<br>
><br>
> And of course, we don't have stonith. It is the same problem, I have<br>
> no control over the VMWare hosts, and seems that they have to pay an<br>
> extra to use the API needed by the stonith plugin.<br>
><br>
> Meanwhile, I try to find<br>
><br>
> Probably this two problems will be fixed in a couple of months, but<br>
> meanwhile I have try to maintain the cluster up :)<br>
<br>
</div>Sounds a bit as if the hardware-layer has bridging with stp featuring<br>
some seconds of unavailability.<br>
<br>
You could try to increase the corosyncs parameters concerning<br>
communication timeouts.<br>
<br>
Good luck,<br>
<br>
Arnold<br>
<br>_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" target="_blank">http://bugs.clusterlabs.org</a><br>
<br></blockquote></div><br></div>