<br><br><div class="gmail_quote">On Fri, Nov 18, 2011 at 1:55 AM, Florian Haas <span dir="ltr">&lt;<a href="mailto:florian@hastexo.com">florian@hastexo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Trey,<br>
<div class="im"><br>
On 11/18/11 07:22, Trey Dockendorf wrote:<br>
&gt; In preparation to begin testing DRBD I&#39;ve found my superiors have new<br>
&gt; requirements.  The desired setup is 3 nodes in the cluster, replicating<br>
&gt; a LVM volume between all 3.  The volume will contain QCOW2 images for<br>
&gt; KVM, and to have concurrent access I&#39;ve been looking at using GFS2.<br>
<br>
</div>OK, so if it&#39;s 3 nodes that a hypervisor is meant to run on, then that<br>
rules out putting DRBD-based storage and the hypervisors on the same<br>
boxes. (It certainly doesn&#39;t rule out the use of DRBD altogether; see<br>
below).<br>
<div class="im"><br>
&gt; The potential complication is all 3 servers are not identical.  Two are<br>
&gt; identical, Dell 2950s.  The other is a new Dell R510.  The 2950s run 6 x<br>
&gt; SATA 7200RPM in RAID 6, and the R510 has it&#39;s system on RAID1 SAS and 6<br>
&gt; x SAS 10000RPM in RAID 6.  Is it correct that with DRBD, the combination<br>
&gt; of mismatched performance of the disk I/O would be a problem?  How much<br>
&gt; more difficult is a 3 node cluster over 2 node?<br>
<br>
</div>For multiple-node write access, it&#39;s impossible. What DRBD currently<br>
supports is adding a third node in a stacked configuration, but that is<br>
only useful for backup and DR purposes. You can&#39;t really think of the<br>
third node as a fully-fledged member of the virtualization cluster.<br>
<div class="im"><br>
&gt; Also, if I&#39;m able get an iSCSI, what role would DRBD play in the model<br>
&gt; of 3 servers w/ shared storage?  I assume to allow concurrent access to<br>
&gt; the same iSCSI space, that I would have to still use a cluster file<br>
&gt; system (live migration).  Would DRBD then be used to replicate the<br>
&gt; system partitions or with KVM is it only useful to replicate the VM<br>
&gt; store when not using shared storage?<br>
<br>
</div>You can put your iSCSI on DRBD-backed storage, and then use that iSCSI<br>
target as centralized storage for your hypervisors. You may not even<br>
need to set up cLVM. That&#39;s what this talk explains:<br>
<br>
<a href="http://www.hastexo.com/content/roll-your-own-cloud" target="_blank">http://www.hastexo.com/content/roll-your-own-cloud</a><br>
<br>
(Free-of-charge registration required, or just use your Google Profile<br>
or WordPress account, or anything else that supports OpenID, to log in.)<br>
<br>
You can also take a look at this Tech Guide which I wrote while working<br>
at Linbit, which is still hosted on their site:<br>
<br>
<a href="http://www.linbit.com/en/education/tech-guides/highly-available-virtualization-with-kvm-iscsi-pacemaker/" target="_blank">http://www.linbit.com/en/education/tech-guides/highly-available-virtualization-with-kvm-iscsi-pacemaker/</a><br>

<div class="im"><br>
&gt; With or without a shared storage device (most likely without), how would<br>
&gt; failover work for the virtual servers?   Is that where Pacemaker comes<br>
&gt; in?  Basically a way to trigger the still-alive servers to bring up the<br>
&gt; VMs that were running on the failed server.<br>
<br>
</div>Yes, watch the talk. :)<br>
<br>
Cheers,<br>
Florian<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Need help with High Availability?<br>
<a href="http://www.hastexo.com/now" target="_blank">http://www.hastexo.com/now</a><br>
_______________________________________________<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>
</font></span></blockquote></div><br><div><br></div><div>After reading the documents linked previously, most of the DRBD user guide and documents related to Pacemaker, I still have a few conceptual questions.</div><div><br>
</div><div>First, I&#39;ve seen lots of mention of the requirement to to sync the XML data for each VM.  Is this necessary will KVM or Pacemaker be handling this?  Right now I typically store all VM disks at /vmstore which has the same security context as /var/lib/libvirt/images.  Do I also need to replicate the directory containing the domain XML files?</div>
<div><br></div><div>The other questions is do Pacemaker and other services for clustering live on the replicated servers or on external systems? As a follow-up , if they live on the replicated servers, do I have to take measures to ensure those services stay in sync?</div>
<div><br></div><div>Right now I have a good idea of how to structure all this, but just a few low level concepts I have yet to fully understand.  So far I think I can achieve the necessary failover and live migration for the VMs using 2 servers with /vmstore replicated with DRBD.  /vmstore will live on top of GFS2 to allow active/active operation.</div>
<div><br></div><div>Thanks for all the help,</div><div>- Trey</div>