<div dir="ltr"><div class="gmail_extra"><br>
<br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 3:50 AM, Justin Clacherty <span dir="ltr">&lt;<a href="mailto:justin@redfish.com.au" target="_blank" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=justin@redfish.com.au&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">justin@redfish.com.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">Hi,<u></u><u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p>
<p class="MsoNormal">I&rsquo;m just setting up some storage for use with oVirt and am wondering why I might choose glusterfs rather than just exporting a raid array as iscsi.&nbsp; The oVirt team seem to be pushing gluster (though that could just be because it&rsquo;s a Red Hat product).&nbsp; Can anyone answer this one?</p>
</div></div></blockquote><div><br></div><div>If you&#39;re contemplating software iscsi then you probably aren&#39;t working on a production setup that requires high availability or data consistency. If you are, you should take a deep dive on what your single point of failures are. If you&#39;re actually talking about a SAN lun, then I would imagine you aren&#39;t the storage admin, and can leave the particulars in their hands.</div>
<div><br></div><div>Its funny, in RH&#39;s current supported version of RHEV, native gluster storage isn&#39;t even an option. This is a pretty new project, and if you follow the bread crumbs on distributed file systems like glusterfs or ceph you&#39;ll start to see the future advantages. You can also figure that seeing as both projects are spearheaded by RH dev&#39;s that there is likely a lot of cross-talk and feature requests making both projects better, and who wouldn&#39;t promote a better solution?</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal">
<u></u>&nbsp;<u></u></p><p class="MsoNormal">What I have come up with is as follows.<u></u><u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal">For:</p></div></div></blockquote><div><br></div><div>There is too much to cover in any of these advantages, you&#39;re going to need to do a lot of research on each of these &#39;features&#39; if you want to use them successfully.&nbsp;</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>easy to expand<u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>redundancy across storage devices/easy replication<u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>high availablility<u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>performance<u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>it&rsquo;s kind of cool <span style="font-family:Wingdings">J</span><u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>maintenance?<u></u><u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal">Against (these are guesses):<u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>performance? (multiple layers of filesystems everywhere &ndash; fs in vm + image on gluster + gluster + block filesystem)</p></div>
</div></blockquote><div>Its worse than just a ton of software layers. NAS protocols seem to be focused on data consistency, which means they don&#39;t write async to storage. iscsi is typically async and has much better throughput, but also a greater chance for data loss or corruption. Technically you can achieve the same level of performance as iscsi using NFS (backed by glusterfs if you like) but you need to set options on the volume to allow async writes.</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p><u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>complexity</p>
</div></div></blockquote><div>If you&#39;re doing storage properly, the underpinnings are always complex unless you&#39;re paying someone else to do it (read: SAN / managed service provider). Research multipath and HA on software iscsi and you&#39;ll see what I mean.</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p><u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><u></u>maintenance?<u></u><u></u></p>
<p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal">Any help here is appreciated.&nbsp; Also, does the underlying block level filesystem matter here?&nbsp; VMs running under ovirt would be typical business applications &ndash; file serving (samba4), email, databases, web servers, etc.</p>
</div></div></blockquote><div><br></div><div>There is a lot to answer here and I don&#39;t have all the answers. Take a look at the gluster docs for underlying file system requirements. Any block device should work. Specifically I&#39;ll mention that the glusterfs team doesn&#39;t suggest hosting db&#39;s on glusterfs - many small reads/writes are not one of glusters strong points.</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal">
<u></u>&nbsp;<u></u></p><p class="MsoNormal">Cheers,<u></u><u></u></p><p class="MsoNormal">Justin.<u></u><u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=Users@ovirt.org&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">Users@ovirt.org</a><br>

<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div></div>