<div dir="auto">Hey Joe,<div dir="auto"><br></div><div dir="auto">Thanks! So shall we settle on fio as a standard IO micro benchmarking tool? Seems to me the minimum we want is throughput and IOPs oriented tests for both the guest OS workload profile and the some sort of large working set application workload. For the latter it is probably best to ignore multiple files and focus solely on queue depth for parallelism, some sort of mixed block size profile/s, and some sort of r/w mix (where write <=50% to acknowledge this is ephemeral storage so hopefully something is using it soon after storing). Thoughts?</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Blair</div><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu., 14 Jun. 2018, 00:24 Joe Topjian, <<a href="mailto:joe@topjian.net" target="_blank" rel="noreferrer">joe@topjian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, you can! The kernel documentation for read/write limits actually uses /dev/null in the examples :)<div><br></div><div>But more seriously: while we have not architected specifically for high performance, for the past few years, we have used a zpool of cheap spindle disks and 1-2 SSD disks for caching. We have ZFS configured for deduplication which helps for the base images but not so much for ephemeral.</div><div><br></div><div>If you have a standard benchmark command in mind to run, I'd be happy to post the results. Maybe others could do the same to create some type of matrix?<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 13, 2018 at 8:18 AM, Blair Bethwaite <span dir="ltr"><<a href="mailto:blair.bethwaite@gmail.com" rel="noreferrer noreferrer" target="_blank">blair.bethwaite@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi Jay,</div><div dir="auto"><br></div><div dir="auto">Ha, I'm sure there's some wisdom hidden behind the trolling here?</div><div dir="auto"><br></div><div dir="auto">Believe me, I have tried to push these sorts of use-cases toward volume or share storage, but in the research/science domain there is often more accessible funding available to throw at infrastructure stop-gaps than software engineering (parallelism is hard). PS: when I say ephemeral I don't necessarily mean they aren't doing backups and otherwise caring that they have 100+TB of data on a stand alone host.</div><div dir="auto"><br></div><div dir="auto">PS: I imagine you can set QoS limits on /dev/null these days via CPU cgroups...</div><div dir="auto"><br></div><div dir="auto">Cheers,<div><div class="m_-8804648875412397986m_-5763195226305573069h5"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu., 14 Jun. 2018, 00:03 Jay Pipes, <<a href="mailto:jaypipes@gmail.com" rel="noreferrer noreferrer" target="_blank">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/13/2018 09:58 AM, Blair Bethwaite wrote:<br>
> Hi all,<br>
> <br>
> Wondering if anyone can share experience with architecting Nova KVM <br>
> boxes for large capacity high-performance storage? We have some <br>
> particular use-cases that want both high-IOPs and large capacity local <br>
> storage.<br>
> <br>
> In the past we have used bcache with an SSD based RAID0 write-through <br>
> caching for a hardware (PERC) backed RAID volume. This seemed to work <br>
> ok, but we never really gave it a hard time. I guess if we followed a <br>
> similar pattern today we would use lvmcache (or are people still using <br>
> bcache with confidence?) with a few TB of NVMe and a NL-SAS array with <br>
> write cache.<br>
> <br>
> Is the collective wisdom to use LVM based instances for these use-cases? <br>
> Putting a host filesystem with qcow2 based disk images on it can't help <br>
> performance-wise... Though we have not used LVM based instance storage <br>
> before, are there any significant gotchas? And furthermore, is it <br>
> possible to use set IO QoS limits on these?<br>
<br>
I've found /dev/null to be the fastest ephemeral storage system, bar none.<br>
<br>
Not sure if you can set QoS limits on it though.<br>
<br>
Best,<br>
-jay<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" rel="noreferrer noreferrer noreferrer" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" rel="noreferrer noreferrer" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div></div>