<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Fernando,</p>
<p><br>
</p>
<p>Since I have 3 servers then each one will have a connection to the other two. In this case I could setup 3 subnets, one for each link, avoiding in this way to implement bridging (and Spanning Tree) on the servers. My idea is that when I build the server
 I should use the IP addresses of the 40Gb NICs to setup Gluster and everything should to be ok. Anyway, I will test it on a virtual environment before installing.<br>
</p>
<br>
Thanks,<br>
Moacir<br>
<div style="color: rgb(49, 55, 57);"><font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 7 Aug 2017 10:08:32 -0300<br>
From: FERNANDO FREDIANI &lt;fernando.frediani@upx.com&gt;<br>
To: users@ovirt.org<br>
Subject: Re: [ovirt-users] Good practices<br>
Message-ID: &lt;8dd168a0-d5ab-bdf4-5c5d-197909afc515@upx.com&gt;<br>
Content-Type: text/plain; charset=&quot;windows-1252&quot;; Format=&quot;flowed&quot;<br>
<br>
Moacir, I beleive for using the 3 servers directly connected to each <br>
others without switch you have to have a Bridge on each server for every <br>
2 physical interfaces to allow the traffic passthrough in layer2 (Is it <br>
possible to create this from the oVirt Engine Web Interface?). If your <br>
ovirtmgmt network is separate from other (should really be) that should <br>
be fine to do.<br>
<br>
<br>
Fernando<br>
<br>
<br>
On 07/08/2017 07:13, Moacir Ferreira wrote:<br>
&gt;<br>
&gt; Hi, in-line responses.<br>
&gt;<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Moacir<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------------------------------------------------<br>
&gt; *From:* Yaniv Kaul &lt;ykaul@redhat.com&gt;<br>
&gt; *Sent:* Monday, August 7, 2017 7:42 AM<br>
&gt; *To:* Moacir Ferreira<br>
&gt; *Cc:* users@ovirt.org<br>
&gt; *Subject:* Re: [ovirt-users] Good practices<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Aug 6, 2017 at 5:49 PM, Moacir Ferreira <br>
&gt; &lt;moacirferreira@hotmail.com &lt;<a href="mailto:moacirferreira@hotmail.com">mailto:moacirferreira@hotmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; I am willing to assemble a oVirt &quot;pod&quot;, made of 3 servers, each<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; with 2 CPU sockets of 12 cores, 256GB RAM, 7 HDD 10K, 1 SSD. The<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; idea is to use GlusterFS to provide HA for the VMs. The 3 servers<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; have a dual 40Gb NIC and a dual 10Gb NIC. So my intention is to<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; create a loop like a server triangle using the 40Gb NICs for<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; virtualization files (VMs .qcow2) access and to move VMs around<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; the pod (east /west traffic) while using the 10Gb interfaces for<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; giving services to the outside world (north/south traffic).<br>
&gt;<br>
&gt;<br>
&gt; Very nice gear. How are you planning the network exactly? Without a <br>
&gt; switch, back-to-back? (sounds OK to me, just wanted to ensure this is <br>
&gt; what the 'dual' is used for). However, I'm unsure if you have the <br>
&gt; correct balance between the interface speeds (40g) and the disks (too <br>
&gt; many HDDs?).<br>
&gt;<br>
&gt; Moacir:The idea is to have a very high performance network for the <br>
&gt; distributed file system and to prevent bottlenecks when we move one VM <br>
&gt; from a node to another. Using 40Gb NICs I can just connect the servers <br>
&gt; back-to-back. In this case I don't need the expensive 40Gb switch, I <br>
&gt; get very high speed and no contention between north/south traffic with <br>
&gt; east/west.<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; This said, my first question is: How should I deploy GlusterFS in<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; such oVirt scenario? My questions are:<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 1 - Should I create 3 RAID (i.e.: RAID 5), one on each oVirt node,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; and then create a GlusterFS using them?<br>
&gt;<br>
&gt; I would assume RAID 1 for the operating system (you don't want a <br>
&gt; single point of failure there?) and the rest JBODs. The SSD will be <br>
&gt; used for caching, I reckon? (I personally would add more SSDs instead <br>
&gt; of HDDs, but it does depend on the disk sizes and your space requirements.<br>
&gt;<br>
&gt; Moacir: Yes, I agree that I need a RAID-1 for the OS. Now, generic <br>
&gt; JBOD or a JBOD assembled using RAID-5 &quot;disks&quot; createdby the server's <br>
&gt; disk controller?<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 2 - Instead, should I create a JBOD array made of all server's disks?<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 3 - What is the best Gluster configuration to provide for HA while<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; not consuming too much disk space?<br>
&gt;<br>
&gt;<br>
&gt; Replica 2 &#43; Arbiter sounds good to me.<br>
&gt; Moacir:I agree, and that is what I am using.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 4 - Does a oVirt hypervisor pod like I am planning to build, and<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; the virtualization environment, benefits from tiering when using a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; SSD disk? And yes, will Gluster do it by default or I have to<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; configure it to do so?<br>
&gt;<br>
&gt;<br>
&gt; Yes, I believe using lvmcache is the best way to go.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Moacir: Are you sure? I say that because the qcow2 files will be<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; quite big. So if tiering is &quot;file based&quot; the SSD would have to be<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; very, very big unless Gluster tiering do it by &quot;chunks of data&quot;.<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; At the bottom line, what is the good practice for using GlusterFS<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; in small pods for enterprises?<br>
&gt;<br>
&gt;<br>
&gt; Don't forget jumbo frames. libgfapi (coming hopefully in 4.1.5). <br>
&gt; Sharding (enabled out of the box if you use a hyper-converged setup <br>
&gt; via gdeploy).<br>
&gt; *Moacir:* Yes! This is another reason to have separate networks for <br>
&gt; north/south and east/west. In that way I can use the standard MTU on <br>
&gt; the 10Gb NICs and jumbo frames on the file/move 40Gb NICs.<br>
&gt;<br>
&gt; Y.<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; You opinion/feedback will be really appreciated!<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Moacir<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _______________________________________________<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Users mailing list<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Users@ovirt.org &lt;<a href="mailto:Users@ovirt.org">mailto:Users@ovirt.org</a>&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; Users@ovirt.org<br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://lists.ovirt.org/pipermail/users/attachments/20170807/f4181b39/attachment-0001.html">http://lists.ovirt.org/pipermail/users/attachments/20170807/f4181b39/attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 7 Aug 2017 15:26:03 &#43;0200<br>
From: Erekle Magradze &lt;erekle.magradze@recogizer.de&gt;<br>
To: FERNANDO FREDIANI &lt;fernando.frediani@upx.com&gt;, users@ovirt.org<br>
Subject: Re: [ovirt-users] Good practices<br>
Message-ID: &lt;aa829d07-fa77-3ed9-2500-e33cc01414b6@recogizer.de&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;; Format=&quot;flowed&quot;<br>
<br>
Hi Frenando,<br>
<br>
Here is my experience, if you consider a particular hard drive as a <br>
brick for gluster volume and it dies, i.e. it becomes not accessible <br>
it's a huge hassle to discard that brick and exchange with another one, <br>
since gluster some tries to access that broken brick and it's causing <br>
(at least it cause for me) a big pain, therefore it's better to have a <br>
RAID as brick, i.e. have RAID 1 (mirroring) for each brick, in this case <br>
if the disk is down you can easily exchange it and rebuild the RAID <br>
without going offline, i.e switching off the volume doing brick <br>
manipulations and switching it back on.<br>
<br>
Cheers<br>
<br>
Erekle<br>
<br>
<br>
On 08/07/2017 03:04 PM, FERNANDO FREDIANI wrote:<br>
&gt;<br>
&gt; For any RAID 5 or 6 configuration I normally follow a simple gold rule <br>
&gt; which gave good results so far:<br>
&gt; - up to 4 disks RAID 5<br>
&gt; - 5 or more disks RAID 6<br>
&gt;<br>
&gt; However I didn't really understand well the recommendation to use any <br>
&gt; RAID with GlusterFS. I always thought that GlusteFS likes to work in <br>
&gt; JBOD mode and control the disks (bricks) directlly so you can create <br>
&gt; whatever distribution rule you wish, and if a single disk fails you <br>
&gt; just replace it and which obviously have the data replicated from <br>
&gt; another. The only downside of using in this way is that the <br>
&gt; replication data will be flow accross all servers but that is not much <br>
&gt; a big issue.<br>
&gt;<br>
&gt; Anyone can elaborate about Using RAID &#43; GlusterFS and JBOD &#43; GlusterFS.<br>
&gt;<br>
&gt; Thanks<br>
&gt; Regards<br>
&gt; Fernando<br>
&gt;<br>
&gt;<br>
&gt; On 07/08/2017 03:46, Devin Acosta wrote:<br>
&gt;&gt;<br>
&gt;&gt; Moacir,<br>
&gt;&gt;<br>
&gt;&gt; I have recently installed multiple Red Hat Virtualization hosts for <br>
&gt;&gt; several different companies, and have dealt with the Red Hat Support <br>
&gt;&gt; Team in depth about optimal configuration in regards to setting up <br>
&gt;&gt; GlusterFS most efficiently and I wanted to share with you what I learned.<br>
&gt;&gt;<br>
&gt;&gt; In general Red Hat Virtualization team frowns upon using each DISK of <br>
&gt;&gt; the system as just a JBOD, sure there is some protection by having <br>
&gt;&gt; the data replicated, however, the recommendation is to use RAID 6 <br>
&gt;&gt; (preferred) or RAID-5, or at least RAID-1 at the very least.<br>
&gt;&gt;<br>
&gt;&gt; Here is the direct quote from Red Hat when I asked about RAID and Bricks:<br>
&gt;&gt; /<br>
&gt;&gt; /<br>
&gt;&gt; /&quot;A typical Gluster configuration would use RAID underneath the <br>
&gt;&gt; bricks. RAID 6 is most typical as it gives you 2 disk failure <br>
&gt;&gt; protection, but RAID 5 could be used too. Once you have the RAIDed <br>
&gt;&gt; bricks, you'd then apply the desired replication on top of that. The <br>
&gt;&gt; most popular way of doing this would be distributed replicated with <br>
&gt;&gt; 2x replication. In general you'll get better performance with larger <br>
&gt;&gt; bricks. 12 drives is often a sweet spot. Another option would be to <br>
&gt;&gt; create a separate tier using all SSD?s.? /<br>
&gt;&gt;<br>
&gt;&gt; /In order to SSD tiering from my understanding you would need 1 x <br>
&gt;&gt; NVMe drive in each server, or 4 x SSD hot tier (it needs to be <br>
&gt;&gt; distributed, replicated for the hot tier if not using NVME). So with <br>
&gt;&gt; you only having 1 SSD drive in each server, I?d suggest maybe looking <br>
&gt;&gt; into the NVME option. /<br>
&gt;&gt; /<br>
&gt;&gt; /<br>
&gt;&gt; /Since your using only 3-servers, what I?d probably suggest is to do <br>
&gt;&gt; (2 Replicas &#43; Arbiter Node), this setup actually doesn?t require the <br>
&gt;&gt; 3rd server to have big drives at all as it only stores meta-data <br>
&gt;&gt; about the files and not actually a full copy. /<br>
&gt;&gt; /<br>
&gt;&gt; /<br>
&gt;&gt; /Please see the attached document that was given to me by Red Hat to <br>
&gt;&gt; get more information on this. Hope this information helps you./<br>
&gt;&gt; /<br>
&gt;&gt; /<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt;<br>
&gt;&gt; Devin Acosta, RHCA, RHVCA<br>
&gt;&gt; Red Hat Certified Architect<br>
&gt;&gt;<br>
&gt;&gt; On August 6, 2017 at 7:29:29 PM, Moacir Ferreira <br>
&gt;&gt; (moacirferreira@hotmail.com &lt;<a href="mailto:moacirferreira@hotmail.com">mailto:moacirferreira@hotmail.com</a>&gt;) wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; I am willing to assemble a oVirt &quot;pod&quot;, made of 3 servers, each with <br>
&gt;&gt;&gt; 2 CPU sockets of 12 cores, 256GB RAM, 7 HDD 10K, 1 SSD. The idea is <br>
&gt;&gt;&gt; to use GlusterFS to provide HA for the VMs. The 3 servers have a <br>
&gt;&gt;&gt; dual 40Gb NIC and a dual 10Gb NIC. So my intention is to create a <br>
&gt;&gt;&gt; loop like a server triangle using the 40Gb NICs for virtualization <br>
&gt;&gt;&gt; files (VMs .qcow2) access and to move VMs around the pod (east /west <br>
&gt;&gt;&gt; traffic) while using the 10Gb interfaces for giving services to the <br>
&gt;&gt;&gt; outside world (north/south traffic).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This said, my first question is: How should I deploy GlusterFS in <br>
&gt;&gt;&gt; such oVirt scenario? My questions are:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1 - Should I create 3 RAID (i.e.: RAID 5), one on each oVirt node, <br>
&gt;&gt;&gt; and then create a GlusterFS using them?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2 - Instead, should I create a JBOD array made of all server's disks?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 3 - What is the best Gluster configuration to provide for HA while <br>
&gt;&gt;&gt; not consuming too much disk space?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 4 - Does a oVirt hypervisor pod like I am planning to build, and the <br>
&gt;&gt;&gt; virtualization environment, benefits from tiering when using a SSD <br>
&gt;&gt;&gt; disk? And yes, will Gluster do it by default or I have to configure <br>
&gt;&gt;&gt; it to do so?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; At the bottom line, what is the good practice for using GlusterFS in <br>
&gt;&gt;&gt; small pods for enterprises?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; You opinion/feedback will be really appreciated!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Moacir<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Users mailing list<br>
&gt;&gt;&gt; Users@ovirt.org &lt;<a href="mailto:Users@ovirt.org">mailto:Users@ovirt.org</a>&gt;<br>
&gt;&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Users mailing list<br>
&gt;&gt; Users@ovirt.org<br>
&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; Users@ovirt.org<br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://lists.ovirt.org/pipermail/users/attachments/20170807/f9affb2c/attachment.html">http://lists.ovirt.org/pipermail/users/attachments/20170807/f9affb2c/attachment.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Users mailing list<br>
Users@ovirt.org<br>
<a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
<br>
End of Users Digest, Vol 71, Issue 32<br>
*************************************<br>
</div>
</span></font></div>
</div>
</body>
</html>