<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" 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="h5"><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" 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>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" rel="noreferrer" target="_blank">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br></blockquote></div><br></div></div></div>