On 09/20/2016 05:48 PM, John Griffith wrote: > On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas > <duncan.tho...@gmail.com <mailto:duncan.tho...@gmail.com>> wrote: > > On 20 September 2016 at 16:24, Nikita Konovalov > <nkonova...@mirantis.com <mailto:nkonova...@mirantis.com>> wrote: > > Hi, > > 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. > > 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. > > So I would still like to have the ability to attach partitions > locally bypassing the iSCSI to guarantee 2 things: > * Make sure that lio processes do not compete for CPU and RAM > with VMs running on the same host. > * Make sure that CPU intensive VMs (or whatever else is > running nearby) are not blocking the storage. > > > 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. > > 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. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > 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).
Don't we have at least scheduling problem solved [1] already? [1] https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/instance_locality_filter.py > > 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. > > 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. > > [1]: https://wiki.openstack.org/wiki/CinderBrick > > Thanks, > John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
