<br><br><div class="gmail_quote">On Fri, Nov 25, 2011 at 9:53 AM, Florian Haas <span dir="ltr"><<a href="mailto:florian@hastexo.com">florian@hastexo.com</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 11/25/11 06:23, Trey Dockendorf wrote:<br>
> After reading the documents linked previously, most of the DRBD user<br>
> guide and documents related to Pacemaker, I still have a few conceptual<br>
> questions.<br>
><br>
> First, I've seen lots of mention of the requirement to to sync the XML<br>
> data for each VM. Is this necessary will KVM or Pacemaker be handling<br>
> this? Right now I typically store all VM disks at /vmstore which has<br>
> the same security context as /var/lib/libvirt/images. Do I also need to<br>
> replicate the directory containing the domain XML files?<br>
<br>
</div>Yes. You can do that by putting those into a separate directory in<br>
/vmstore as well (or on NFS, for that matter), and then use<br>
ocf:heartbeat:symlink to manage your symlinks from /etc/libvirt/qemu. Or<br>
your can just use csync2 to keep the configurations in sync.<br>
<div class="im"><br>
> The other questions is do Pacemaker and other services for clustering<br>
> live on the replicated servers or on external systems? As a follow-up ,<br>
> if they live on the replicated servers, do I have to take measures to<br>
> ensure those services stay in sync?<br>
<br>
</div>I'm not sure what you mean here exactly, but if your question boils down<br>
to "do I run Pacemaker on my DRBD nodes?", then yes, definitely so.<br>
<div class="im"><br>
> Right now I have a good idea of how to structure all this, but just a<br>
> few low level concepts I have yet to fully understand. So far I think I<br>
> can achieve the necessary failover and live migration for the VMs using<br>
> 2 servers with /vmstore replicated with DRBD. /vmstore will live on top<br>
> of GFS2 to allow active/active operation.<br>
<br>
</div>What do you use for fencing?<br>
<span class="HOEnZb"><font color="#888888"><br>
Florian<br>
<br>
--<br>
Need help with DRBD?<br>
<a href="http://www.hastexo.com/knowledge/drbd" target="_blank">http://www.hastexo.com/knowledge/drbd</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br>
<a href="http://lists.linbit.com/mailman/listinfo/drbd-user" target="_blank">http://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
</div></div></blockquote></div><br><div><br></div><div>Excellent, thanks for the clarification.</div><div><br></div><div>Correct, I wasn't sure if Pacemaker lives on the DRBD nodes. With Pacemaker on the DRBD nodes, is there any syncing necessary or will CMAN handle that? I'm getting that from <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a>.</div>
<div><br></div><div>For fencing I would be using STONITH. Though that seems "extreme". Does STONITH essentially create a failure when the conflicting system is shutdown, such that services from it will be brought online on the healthy node?</div>
<div><br></div><div>Also, one specific use case I haven't seen much information on is what it is that actually performs the VM migration in KVM once a node fails. Based on what I've read it would seem that's Pacemaker's job, but haven't seen that specific scenario mentioned yet.</div>
<div><br></div><div>Thanks</div><div>- Trey</div>