Open Stack

We will face the same issue in multiple nova-scheduler process case, like
Sylvain say, right?

Two processes/workers can actually consume two distinct resources on the
same HostState.




2015-03-05 13:26 GMT+08:00 Alex Xu <soulxu at gmail.com>:

> Rui, you still can run multiple nova-scheduler process now.
>
>
> 2015-03-05 10:55 GMT+08:00 Rui Chen <chenrui.momo at gmail.com>:
>
>> Looks like it's a complicated problem, and nova-scheduler can't scale-out
>> horizontally in active/active mode.
>>
>> Maybe we should illustrate the problem in the HA docs.
>>
>> http://docs.openstack.org/high-availability-guide/content/_schedulers.html
>>
>> Thanks for everybody's attention.
>>
>> 2015-03-05 5:38 GMT+08:00 Mike Bayer <mbayer at redhat.com>:
>>
>>>
>>>
>>> Attila Fazekas <afazekas at redhat.com> wrote:
>>>
>>> > Hi,
>>> >
>>> > I wonder what is the planned future of the scheduling.
>>> >
>>> > The scheduler does a lot of high field number query,
>>> > which is CPU expensive when you are using sqlalchemy-orm.
>>> > Does anyone tried to switch those operations to sqlalchemy-core ?
>>>
>>> An upcoming feature in SQLAlchemy 1.0 will remove the vast majority of
>>> CPU
>>> overhead from the query side of SQLAlchemy ORM by caching all the work
>>> done
>>> up until the SQL is emitted, including all the function overhead of
>>> building
>>> up the Query object, producing a core select() object internally from the
>>> Query, working out a large part of the object fetch strategies, and
>>> finally
>>> the string compilation of the select() into a string as well as
>>> organizing
>>> the typing information for result columns. With a query that is
>>> constructed
>>> using the “Baked” feature, all of these steps are cached in memory and
>>> held
>>> persistently; the same query can then be re-used at which point all of
>>> these
>>> steps are skipped. The system produces the cache key based on the
>>> in-place
>>> construction of the Query using lambdas so no major changes to code
>>> structure are needed; just the way the Query modifications are performed
>>> needs to be preceded with “lambda q:”, essentially.
>>>
>>> With this approach, the traditional session.query(Model) approach can go
>>> from start to SQL being emitted with an order of magnitude less function
>>> calls. On the fetch side, fetching individual columns instead of full
>>> entities has always been an option with ORM and is about the same speed
>>> as a
>>> Core fetch of rows. So using ORM with minimal changes to existing ORM
>>> code
>>> you can get performance even better than you’d get using Core directly,
>>> since caching of the string compilation is also added.
>>>
>>> On the persist side, the new bulk insert / update features provide a
>>> bridge
>>> from ORM-mapped objects to bulk inserts/updates without any unit of work
>>> sorting going on. ORM mapped objects are still more expensive to use in
>>> that
>>> instantiation and state change is still more expensive, but bulk
>>> insert/update accepts dictionaries as well, which again is competitive
>>> with
>>> a straight Core insert.
>>>
>>> Both of these features are completed in the master branch, the “baked
>>> query”
>>> feature just needs documentation, and I’m basically two or three tickets
>>> away from beta releases of 1.0. The “Baked” feature itself lives as an
>>> extension and if we really wanted, I could backport it into oslo.db as
>>> well
>>> so that it works against 0.9.
>>>
>>> So I’d ask that folks please hold off on any kind of migration from ORM
>>> to
>>> Core for performance reasons. I’ve spent the past several months adding
>>> features directly to SQLAlchemy that allow an ORM-based app to have
>>> routes
>>> to operations that perform just as fast as that of Core without a
>>> rewrite of
>>> code.
>>>
>>> > The scheduler does lot of thing in the application, like filtering
>>> > what can be done on the DB level more efficiently. Why it is not done
>>> > on the DB side ?
>>> >
>>> > There are use cases when the scheduler would need to know even more
>>> data,
>>> > Is there a plan for keeping `everything` in all schedulers process
>>> memory up-to-date ?
>>> > (Maybe zookeeper)
>>> >
>>> > The opposite way would be to move most operation into the DB side,
>>> > since the DB already knows everything.
>>> > (stored procedures ?)
>>> >
>>> > Best Regards,
>>> > Attila
>>> >
>>> >
>>> > ----- Original Message -----
>>> >> From: "Rui Chen" <chenrui.momo at gmail.com>
>>> >> To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev at lists.openstack.org>
>>> >> Sent: Wednesday, March 4, 2015 4:51:07 AM
>>> >> Subject: [openstack-dev] [nova] blueprint about multiple workers
>>> supported   in nova-scheduler
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I want to make it easy to launch a bunch of scheduler processes on a
>>> host,
>>> >> multiple scheduler workers will make use of multiple processors of
>>> host and
>>> >> enhance the performance of nova-scheduler.
>>> >>
>>> >> I had registered a blueprint and commit a patch to implement it.
>>> >>
>>> https://blueprints.launchpad.net/nova/+spec/scheduler-multiple-workers-support
>>> >>
>>> >> This patch had applied in our performance environment and pass some
>>> test
>>> >> cases, like: concurrent booting multiple instances, currently we
>>> didn't find
>>> >> inconsistent issue.
>>> >>
>>> >> IMO, nova-scheduler should been scaled horizontally on easily way, the
>>> >> multiple workers should been supported as an out of box feature.
>>> >>
>>> >> Please feel free to discuss this feature, thanks.
>>> >>
>>> >> Best Regards
>>> >>
>>> >>
>>> >>
>>> __________________________________________________________________________
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> __________________________________________________________________________
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150305/34f0a67d/attachment.html>