<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
<BR>
<BR>
<BR>
On Wed, 2014-02-05 at 08:49 -0500, Yedidyah Bar David wrote:
<BLOCKQUOTE TYPE=CITE>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <B><FONT COLOR="#000000">From: </FONT></B><FONT COLOR="#000000">&quot;ml ml&quot; &lt;mliebherr99@googlemail.com&gt;</FONT><BR>
        <B><FONT COLOR="#000000">To: </FONT></B><FONT COLOR="#000000">Users@ovirt.org</FONT><BR>
        <B><FONT COLOR="#000000">Sent: </FONT></B><FONT COLOR="#000000">Wednesday, February 5, 2014 12:45:55 PM</FONT><BR>
        <B><FONT COLOR="#000000">Subject: </FONT></B><FONT COLOR="#000000">[Users] Will this two node concept scale and work?</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Hello List,</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">my aim is to host multiple VMs which are redundant and are high available. It should also scale well.</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">I think usually people just buy a fat iSCSI Storage and attach this. In my case it should scale well from very small nodes to big ones.</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Therefore an iSCSI Target will bring a lot of overhead (10GBit Links and two Paths, and really i should have a 2nd Hot Standby SAN, too). This makes scalability very hard.</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">This post is also not meant to be a iscsi discussion.</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Since oVirt does not support DRBD out of the box i came up with my own concept:</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <FONT COLOR="#000000"><A HREF="http://oi62">http://oi62</A>.tinypic.com/2550xg5.jpg</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">As far as i can tell i have the following advantages:</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">--------------------------------------------------------------------</FONT><BR>
        <FONT COLOR="#000000">- i can start with two simple cheap nodes</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">- i could add more disks to my nodes. Maybe even a SSD as a dedicated drbd resource.</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">- i can connect the two nodes directly to each other with bonding or infiniband. i dont need a switch or something between it.</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Downside:</FONT><BR>
        <FONT COLOR="#000000">---------------</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">- i always need two nodes (as a couple)</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Will this setup work for me. So far i think i will be quite happy with it.</FONT><BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <FONT COLOR="#000000">Since the DRBD Resources are shared in dual primary mode i am not sure if ovirt can handle it. It is not allowed to write to a vm disk at the same time.</FONT>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">I don't know ovirt enough to comment on that.</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">I did play in the past with drbd and libvirt (virsh).</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Note that having both nodes primary all the time for all resources is</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">calling for a disaster. In any case of split brain, for any reason, drbd</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">will not know what to do.</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
</BLOCKQUOTE>
I second that, had many problems without proper fencing and even with fencing.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">What I did was to allow both to be primary, but had only one primary</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">most of the time (per resource). I wrote a script to do migration, which</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">made both primary for the duration of the migration (required by qemu)</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">and then moved the source to secondary when migration finished. This</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">way you still have a chance for a disaster, if there is a problem (split</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">brain, node failure) during a migration. So if you decide to go this way,</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">carefully plan and test to see that it works well for you.&nbsp;One source for</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">a split brain, for me, at the time, was buggy nic drivers&nbsp;and bad bonding</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">configuration. So test that well too if applicable.</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">The approach I took seems similar to &quot;DRBD on LV level&quot; in [1], but</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">with custom scripts and without ovirt.</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">You might be able to make ovirt do this for you with hooks. Didn't try that.</FONT>\<BR>
</BLOCKQUOTE>
<BR>
You could use drbd9 but I haven't tested it extensively yet. DRBD 9 has primary on write so you have both sides on passive until one of the nodes want's to write. It should automatically become primary then. This has been done by linbit to decrease split brain and expand to more than two nodes.<BR>
<BR>
<A HREF="http://www.drbd.org/users-guide-9.0/s-automatic-promotion.html">http://www.drbd.org/users-guide-9.0/s-automatic-promotion.html</A><BR>
<BR>
But I don't know why it shouldn't work, maybe not with the node image but you can make a node of a normal rhel/centos/fedora install.<BR>
<BR>
One problem I always have with drbd and RHEL/Centos is that when you don't pay for the Linbit support, you don't get access to the repo and drbd is an additional option on RHEL. On Centos and Fedora the version is always lagging behind, so I have to compile the kernel module everytime for a new version or kernel update.<BR>
<BLOCKQUOTE TYPE=CITE>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">An obvious downside to this approach is that if one node in a pair is</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">down, the other has no backup now. If you have multiple nodes and</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">external&nbsp;shared storage, multiple nodes can be down with no disruption</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">to service&nbsp;if the remaining nodes are capable enough.</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">[1]&nbsp;<A HREF="http://www.ovirt.org/Features/DRBD">http://www.ovirt.org/Features/DRBD</A></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Best regards,</FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">-- </FONT><BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Didi</FONT><BR>
    <BR>
</BLOCKQUOTE>
<BR>
<BR>
</BODY>
</HTML>