<div><br><div class="gmail_quote">On Thu, Jul 19, 2012 at 2:14 AM, Jake Grimmett <span dir="ltr">&lt;<a href="mailto:jog@mrc-lmb.cam.ac.uk" target="_blank">jog@mrc-lmb.cam.ac.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Pranith /Anand ,<br>
<br>
Update on our progress with using KVM &amp; Gluster:<br>
<br>
We built a two server (Dell R710) cluster, each box has...<br>
 5 x 500 GB SATA RAID5 array (software raid)<br>
 an Intel 10GB ethernet HBA.<br>
 One box has 8GB RAM, the other 48GB<br>
 both have 2 x E5520 Xeon<br>
 Centos 6.3 installed<br>
 Gluster 3.3 installed from the rpm files on the gluster site<br>
<br>
<br>
1) create a replicated gluster volume (on top of xfs)<br>
2) setup qemu/kvm with a gluster volume (mounts localhost:/gluster-vol)<br>
3) sanlock configured (this is evil!)<br>
4) build a virtual machines with 30GB qcow2 image, 1GB RAM<br>
5) clone this VM into 4 machines<br>
6) check that live migration works (OK)<br>
<br>
Start basic test cycle:<br>
a) migrate all machines to host #1, then reboot host #2<br>
b) watch logs for self-heal to complete<br>
c) migrate VM&#39;s to host #2, reboot host #1<br>
d) check logs for self heal<br>
<br>
The above cycle can be repeated numerous times, and completes without error, provided that no (or little) load is on the VM.<br>
<br>
<br>
If I give the VM&#39;s a work load, such by running &quot;bonnie++&quot; on each VM, things start to break.<br>
1) it becomes almost impossible to log in to each VM<br>
2) the kernel on each VM starts giving timeout errors<br>
i.e. &quot;echo 0 &gt; /proc/sys/kernel/hung_task_<u></u>timeout_secs&quot;<br>
3) top / uptime on the hosts shows load average of up to 24<br>
4) dd write speed (block size 1K) to gluster is around 3MB/s on the host<br>
<br>
<br>
While I agree that running bonnie++ on four VM&#39;s is possibly unfair, there are load spikes on quiet machines (yum updates etc). I suspect that the I/O of one VM starts blocking that of another VM, and the pressure builds up rapidly on gluster - which does not seem to cope well under pressure. Possibly this is the access pattern / block size of qcow2 disks?<br>

<br>
I&#39;m (slightly) disappointed.<br>
<br>
Though it doesn&#39;t corrupt data, the I/O performance is &lt; 1% of my hardwares capability. Hopefully work on buffering and other tuning will fix this ? Or maybe the work mentioned getting qemu talking directly to gluster will fix this?<br>
<br></blockquote><div><br></div><div>Do you mean that the I/O is bad when you are performing the migration? Or bad in general? If it is bad in general the qemu driver should help. Also try presenting each VM a FUSE mount point of its own (we have seen that help improve the overall system IOPs)</div>
<div>If it is slow performance only during failover/failback, we probably need to do some more internal QoS tuning to de-prioritize self-heal traffic from preempting VM traffic for resources.</div><div><br></div><div>Avati</div>
</div></div>