Open Stack

Ian,

There are serious scalability and performance problems with DB usage in
current scheduler.
Rapid Updates + Joins makes current solution absolutely not scalable.

Bleuhost example just shows personally for me just a trivial thing. (It
just won't work)

We will add tomorrow antother graphic:
Avg user req / sec in current and our approaches.

I hope it will help you to better understand situation.


Joshua,

Our current discussion is about could we remove information about compute
nodes from Nova saftly.
Both our and your approach will remove data from nova DB.

Also your approach had much more:
1) network load
2) latency
3) one more service (memcached)

So I am not sure that it is better then just send directly to scheduler
information.


Best regards,
Boris Pavlovic
---
Mirantis Inc.






On Tue, Jul 23, 2013 at 11:56 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
> On Jul 23, 2013 3:44 PM, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
> >
> > > * periodic updates can overwhelm things.  Solution: remove unneeded
> updates,
> > > most scheduling data only changes when an instance does some state
> change.
> >
> > It's not clear that periodic updates do overwhelm things, though.
> > Boris ran the tests.  Apparently 10k nodes updating once a minute
> > extend the read query by ~10% (the main problem being the read query
> > is abysmal in the first place).  I don't know how much of the rest of
> > the infrastructure was involved in his test, though (RabbitMQ,
> > Conductor).
>
> A great openstack at scale talk, that covers the scheduler
> http://www.bluehost.com/blog/bluehost/bluehost-presents-operational-case-study-at-openstack-summit-2111
>
> >
> > There are reasonably solid reasons why we would want an alternative to
> > the DB backend, but I'm not sure the update rate is one of them.   If
> > we were going for an alternative the obvious candidate to my mind
> > would be something like ZooKeeper (particularly since in some setups
> > it's already a channel between the compute hosts and the control
> > server).
> > --
> > Ian.
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130724/415a88f8/attachment.html>