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.gord...@gmail.com> wrote: > > On Jul 23, 2013 3:44 PM, "Ian Wells" <ijw.ubu...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
