I worked in Redhat Cluster without clvmd, i did a storage migration where the service was running. Until this point everythig was fine, but when the primary node where the service was running crashed it, the secondary node used the old luns, this happened because nobody synchronized the lvm metadata.<br>
<br><div class="gmail_quote">2012/9/10 David Morton <span dir="ltr"><<a href="mailto:davidmorton78@gmail.com" target="_blank">davidmorton78@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So if we do not use clustered VG's will any changes made to a shared disk (non clustered filesystem) be visible to all cluster nodes ? Or does activating the VG resource effectively 'refresh' the LVM layout prior to any filesystem actions taking place in the event of a failover ?<div>

<br></div><div>We will have one OCFS2 volume so DLM and cLVM are requirements there either way.<br><br><div class="gmail_quote">On Mon, Sep 10, 2012 at 8:44 PM, Lars Marowsky-Bree <span dir="ltr"><<a href="mailto:lmb@suse.com" target="_blank">lmb@suse.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2012-09-10T11:06:15, David Morton <<a href="mailto:davidmorton78@gmail.com" target="_blank">davidmorton78@gmail.com</a>> wrote:<br>


<br>
> Not directly Pacemaker related but a simple question for those who manage<br>
> clusters ...<br>
><br>
> I'm recreating our failover cluster on a new SAN which will use cLVM and<br>
> XFS, I am after some clarification that the "--clustered y" directive is<br>
> the correct and appropriate way to create the volume groups as the LVM<br>
> layout will be visible to both cluster nodes at all times regardless of the<br>
> filesystem mount state ?<br>
><br>
> I'll then create LVM resources in Pacemaker to control the activation of<br>
> the volume groups prior to filesystem mounting.<br>
<br>
If you're using an LVM resource to activate/deactivate the VG in a<br>
fail-over setting, there is no need to use a clustered volume group.<br>
<br>
You gain some protection against admin mistakes by not exposing the VG,<br>
and if you do not need concurrent access to the VG, you can skip using<br>
the DLM/cLVM2, which reduces complexity.<br>
<br>
<br>
Regards,<br>
    Lars<br>
<br>
--<br>
Architect Storage/HA<br>
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)<br>
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde<br>
<br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org" target="_blank">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>
</blockquote></div><br></div>
<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><br clear="all"><br>-- <br>esta es mi vida e me la vivo hasta que dios quiera<br>