<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 6:17 PM, David Caro <span dir="ltr">&lt;<a href="mailto:dcaro@redhat.com" target="_blank">dcaro@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 05/25 17:06, David Caro wrote:<br>
&gt; On 05/25 16:09, Barak Korren wrote:<br>
&gt; &gt; On 25 May 2016 at 14:52, David Caro &lt;<a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a>&gt; wrote:<br>
&gt; &gt; &gt; On 05/25 14:42, Barak Korren wrote:<br>
&gt; &gt; &gt;&gt; On 25 May 2016 at 12:44, Eyal Edri &lt;<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>&gt; wrote:<br>
&gt; &gt; &gt;&gt; &gt; OK,<br>
&gt; &gt; &gt;&gt; &gt; I suggest to test using a VM with local disk (preferably on a host with SSD<br>
&gt; &gt; &gt;&gt; &gt; configured), if its working,<br>
&gt; &gt; &gt;&gt; &gt; lets expedite moving all VMs or at least a large amount of VMs to it until<br>
&gt; &gt; &gt;&gt; &gt; we see network load reduced.<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; This is not that easy, oVirt doesn&#39;t support mixing local disk and<br>
&gt; &gt; &gt;&gt; storage in the same cluster, so we will need to move hosts to a new<br>
&gt; &gt; &gt;&gt; cluster for this.<br>
&gt; &gt; &gt;&gt; Also we will lose the ability to use templates, or otherwise have to<br>
&gt; &gt; &gt;&gt; create the templates on each and every disk.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; The scratch disk is a good solution for this, where you can have the<br>
&gt; &gt; &gt;&gt; OS image on the central storage and the ephemeral data on the local<br>
&gt; &gt; &gt;&gt; disk.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; WRT to the storage architecture - a single huge (10.9T) ext4 is used<br>
&gt; &gt; &gt;&gt; as the FS on top of the DRBD, this is probably not the most efficient<br>
&gt; &gt; &gt;&gt; thing one can do (XFS would probably have been better, RAW via iSCSI -<br>
&gt; &gt; &gt;&gt; even better).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That was done &gt;3 years ago, xfs was not quite stable and widely used and<br>
&gt; &gt; &gt; supported back then.<br>
&gt; &gt; &gt;<br>
&gt; &gt; AFAIK it pre-dates EXT4<br>
&gt;<br>
&gt; It does, but for el6, it was performing way poorly, and with more bugs (for<br>
&gt; what the reviews of it said at the time).<br>
&gt;<br>
&gt; &gt; in any case this does not detract from the<br>
&gt; &gt; fact that the current configuration in not as efficient as we can make<br>
&gt; &gt; it.<br>
&gt; &gt;<br>
&gt;<br>
&gt; It does not, I agree to better focus on what we can do now on, now what should<br>
&gt; have been done then.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; I&#39;m guessing that those 10/9TB are not made from a single disk but<br>
&gt; &gt; &gt;&gt; with a hardware RAID of some sort. In this case deactivating the<br>
&gt; &gt; &gt;&gt; hardware RAID and re-exposing it as multiple separate iSCSI LUNs (That<br>
&gt; &gt; &gt;&gt; are then re-joined to a single sotrage domain in oVirt) will enable<br>
&gt; &gt; &gt;&gt; different VMs to concurrently work on different disks. This should<br>
&gt; &gt; &gt;&gt; lower the per-vm storage latency.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That would get rid of the drbd too, it&#39;s a totally different setup, from<br>
&gt; &gt; &gt; scratch (no nfs either).<br>
&gt; &gt;<br>
&gt; &gt; We can and should still use DRBD, just setup a device for each disk.<br>
&gt; &gt; But yeah, NFS should probably go away.<br>
&gt; &gt; (We are seeing dramatically better performance for iSCSI in<br>
&gt; &gt; integration-engine)<br>
&gt;<br>
&gt; I don&#39;t understand then what you said about splitting the hardware raids, you<br>
&gt; mean to setup one drdb device on top of each hard drive instead?<br>
<br>
<br>
</div></div>Though I really think we should move to gluster/ceph instead for the jenkins<br>
vms, anyone knows what&#39;s the current status of the hyperconverge?<br>
<br></blockquote><div><br></div><div>Neither Gluster nor Hyper-converge I think is stable enough to move all production infra into.</div><div>Hyperconverged is not supported yet for oVirt as well (might be a 4.x feature)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That would allow us for better scalable distributed storage, and properly use<br>
the hosts local disks (we have more space on the combined hosts right now that<br>
on the storage servers).<br></blockquote><div><br></div><div>I agree a stable distributed storage solution is the way to go if we can find one :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt; btw. I think that the nfs is used also for something more than just the engine<br>
&gt; storage domain (just to keep it in mind that it has to be checked if we are<br>
&gt; going to get rid of it)<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Looking at the storage machine I see strong indication it is IO bound<br>
&gt; &gt; &gt;&gt; - the load average is ~12 while there are just 1-5 working processes<br>
&gt; &gt; &gt;&gt; and the CPU is ~80% idle and the rest is IO wait.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Running &#39;du *&#39; at:<br>
&gt; &gt; &gt;&gt; /srv/ovirt_storage/jenkins-dc/658e5b87-1207-4226-9fcc-4e5fa02b86b4/images<br>
&gt; &gt; &gt;&gt; one can see that most images are ~40G in size (that is _real_ 40G not<br>
&gt; &gt; &gt;&gt; sparse!). This means that despite having most VMs created based on<br>
&gt; &gt; &gt;&gt; templates, the VMs are full template copies rather then COW clones.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That should not be like that, maybe the templates are wrongly configured? or<br>
&gt; &gt; &gt; foreman images?<br>
&gt; &gt;<br>
&gt; &gt; This is the expected behaviour when creating a VM from template in the<br>
&gt; &gt; oVirt admin UI. I thought Foreman might behave differently, but it<br>
&gt; &gt; seems it does not.<br>
&gt; &gt;<br>
&gt; &gt; This behaviour is determined by the parameters you pass to the engine<br>
&gt; &gt; API when instantiating a VM, so it most probably doesn&#39;t have anything<br>
&gt; &gt; to do with the template configuration.<br>
&gt;<br>
&gt; So maybe a misconfiguration in foreman?<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; What this means is that using pools (where all VMs are COW copies of<br>
&gt; &gt; &gt;&gt; the single pool template) is expected to significantly reduce the<br>
&gt; &gt; &gt;&gt; storage utilization and therefore the IO load on it (the less you<br>
&gt; &gt; &gt;&gt; store, the less you need to read back).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That should happen too without pools, with normal qcow templates.<br>
&gt; &gt;<br>
&gt; &gt; Not unless you create all the VMs via the API and pass the right<br>
&gt; &gt; parameters. Pools are the easiest way to ensure you never mess that<br>
&gt; &gt; up...<br>
&gt;<br>
&gt; That was the idea<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; And in any case, that will not lower the normal io, when not actually<br>
&gt; &gt; &gt; creating vms, as any read and write will still hit the disk anyhow, it<br>
&gt; &gt; &gt; only alleviates the io when creating new vms.<br>
&gt; &gt;<br>
&gt; &gt; Since you are reading the same bits over and over (for different VMs)<br>
&gt; &gt; you enable the various buffer caches along the way (in the storage<br>
&gt; &gt; machines and in the hypevirsors) to do what they are supposed to.<br>
&gt;<br>
&gt;<br>
&gt; Once the vm is started, mostly all that&#39;s needed is on ram, so there are not<br>
&gt; that much reads from disk, unless you start writing down to it, and that&#39;s<br>
&gt; mostly what we are hitting, lots of writes.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; The local disk (scratch disk) is the best option<br>
&gt; &gt; &gt; imo, now and for the foreseeable future.<br>
&gt; &gt;<br>
&gt; &gt; This is not an either/or thing, IMO we need to do both.<br>
&gt;<br>
&gt; I think that it&#39;s way more useful, because it will solve our current issues<br>
&gt; faster and for longer, so IMO it should get more attention sooner.<br>
&gt;<br>
&gt; Any improvement that does not remove the current bottleneck, is not really<br>
&gt; giving any value to the overall infra (even if it might become valuable later).<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Barak Korren<br>
&gt; &gt; <a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a><br>
&gt; &gt; RHEV-CI Team<br>
&gt;<br>
&gt; --<br>
&gt; David Caro<br>
&gt;<br>
&gt; Red Hat S.L.<br>
&gt; Continuous Integration Engineer - EMEA ENG Virtualization R&amp;D<br>
&gt;<br>
&gt; Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
&gt; Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
&gt; IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
&gt; Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
&gt; RHT Global #: 82-62605<br>
<br>
<br>
<br>
--<br>
David Caro<br>
<br>
Red Hat S.L.<br>
Continuous Integration Engineer - EMEA ENG Virtualization R&amp;D<br>
<br>
Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
RHT Global #: 82-62605<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&amp;D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div>