Ah sorry for the cc oversite.<br><br>Network policies pretty much block me from any funky moves so it seems I will be going with the dual primary, OCFS2, Fencing and Pacemaker solution.<br>How does dual primary impact performance? Obviously there will be slower IO due to locks etc but how significant is this?<br>
<br>Thanks<br><br>Lawrence<br><br><br><div class="gmail_quote">On 1 February 2012 14:19, Felix Frank <span dir="ltr">&lt;<a href="mailto:ff@mpexnet.de">ff@mpexnet.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Lawrence,<br>
<br>
please be careful to CC the list (everyone&#39;s hearing half a conversation<br>
otherwise ;-)<br>
<div class="im"><br>
On 02/01/2012 12:38 PM, Lawrence Strydom wrote:<br>
&gt; Hi Felix.<br>
&gt;<br>
&gt; My setup is, supposed to be, fairly straightforward.  Two web servers,<br>
&gt; one in production and the second as a hot standby.<br>
&gt; The problem comes in with availabillity of IP addresses though. These<br>
&gt; are hosted servers and the hosting company won&#39;t provide more than one<br>
&gt; Live IP per machine. This means I can&#39;t use a floating virtual IP which<br>
&gt; fails over to the second node as that would require a third live IP.<br>
<br>
</div>You could send node1&#39;s IP floating and remove node2&#39;s public IP. Add<br>
internal IPs to both machines, so the passive node is reachable by<br>
hopping through the one with the public IP.<br>
<br>
Unless, of course, there are network policies in place that forbid such<br>
shenanigans.<br>
<div class="im"><br>
&gt; Instead the hosting company provides fail over of the real IP of the<br>
&gt; primary server to the secondary server through their control panel.<br>
&gt; Weird I know but I didn&#39;t choose them, just got given the job.  Ok so<br>
&gt; now I need data to be synchronous over both servers in case of primary<br>
&gt; node failure so dual primary would make sense as the IP fail over is<br>
&gt; already taken care of and no further action will be required to make the<br>
&gt; data available on the secondary node.<br>
<br>
</div>Fair enough. So the answer would probably still be the same: Do use<br>
pacemaker. The easier way will be to just manage DRBD+Apache, or even<br>
DRBD only. However, the production node is selected independently from<br>
pacemaker, which makes for an odd (and error-prone) design.<br>
<br>
Otherwise, you can set up Pacemaker + Fencing + OCFS2 + Dual-Primary and<br>
get away without promotions. But it&#39;s more challenging.<br>
<br>
HTH,<br>
Felix<br>
</blockquote></div><br>