<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On 20 September 2016 at 16:24, Nikita Konovalov <span dir="ltr"><<a href="mailto:nkonovalov@mirantis.com" target="_blank">nkonovalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>From Sahara (and Hadoop workload in general) use-case the reason we used BDD was a complete absence of any overhead on compute resources utilization. </div><div><br></div><div>The results show that the LVM+Local target perform pretty close to BDD in synthetic tests. It's a good sign for LVM. It actually shows that most of the storage virtualization overhead is not caused by LVM partitions and drivers themselves but rather by the iSCSI daemons.</div><div><br></div><div>So I would still like to have the ability to attach partitions locally bypassing the iSCSI to guarantee 2 things:</div><div>* Make sure that lio processes do not compete for CPU and RAM with VMs running on the same host.</div><div>* Make sure that CPU intensive VMs (or whatever else is running nearby) are not blocking the storage.</div></div></blockquote><div><br></div></span><div>So these are, unless we see the effects via benchmarks, completely meaningless requirements. Ivan's initial benchmarks suggest that LVM+LIO is pretty much close enough to BDD even with iSCSI involved. If you're aware of a case where it isn't, the first thing to do is to provide proof via a reproducible benchmark. Otherwise we are likely to proceed, as John suggests, with the assumption that local target does not provide much benefit. <br><br>I've a few benchmarks myself that I suspect will find areas where getting rid of iSCSI is benefit, however if you have any then you really need to step up and provide the evidence. Relying on vague claims of overhead is now proven to not be a good idea. </div></div>
</div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">Honestly we can have both, I'll work up a bp to resurrect the idea of a "smart" scheduling feature that lets you request the volume be on the same node as the compute node and use it directly, and then if it's NOT it will attach a target and use it that way (in other words you run a stripped down c-vol service on each compute node).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Sahara keeps insisting on being a snow-flake with Cinder volumes and the block driver, it's really not necessary. I think we can compromise just a little both ways, give you standard Cinder semantics for volumes, but allow you direct acccess to them if/when requested, but have those be flexible enough that targets *can* be attached so they meet all of the required functionality and API implementations. This also means that we don't have to continue having a *special* driver in Cinder that frankly only works for one specific use case and deployment.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I've pointed to this a number of times but it never seems to resonate... but I never learn so I'll try it once again [1]. Note that was before the name "brick" was hijacked and now means something completely different.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1]: <a href="https://wiki.openstack.org/wiki/CinderBrick">https://wiki.openstack.org/wiki/CinderBrick</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><br></div></div>