Sandy, Hm I don't know that algorithm. But our approach doesn't have exponential exchange. I don't think that in 10k nodes cloud we will have a problems with 150 RPC call/sec. Even in 100k we will have only 1.5k RPC call/sec. More then (compute nodes update their state in DB through conductor which produce the same count of RPC calls).
So I don't see any explosion here. Best regards, Boris Pavlovic Mirantis Inc. On Fri, Jul 19, 2013 at 11:47 PM, Sandy Walsh <sandy.wa...@rackspace.com>wrote: > > > On 07/19/2013 04:25 PM, Brian Schott wrote: > > I think Soren suggested this way back in Cactus to use MQ for compute > > node state rather than database and it was a good idea then. > > The problem with that approach was the number of queues went exponential > as soon as you went beyond simple flavors. Add Capabilities or other > criteria and you get an explosion of exchanges to listen to. > > > > > On Jul 19, 2013, at 10:52 AM, Boris Pavlovic <bo...@pavlovic.me > > <mailto:bo...@pavlovic.me>> wrote: > > > >> Hi all, > >> > >> > >> In Mirantis Alexey Ovtchinnikov and me are working on nova scheduler > >> improvements. > >> > >> As far as we can see the problem, now scheduler has two major issues: > >> > >> 1) Scalability. Factors that contribute to bad scalability are these: > >> *) Each compute node every periodic task interval (60 sec by default) > >> updates resources state in DB. > >> *) On every boot request scheduler has to fetch information about all > >> compute nodes from DB. > >> > >> 2) Flexibility. Flexibility perishes due to problems with: > >> *) Addiing new complex resources (such as big lists of complex objects > >> e.g. required by PCI Passthrough > >> https://review.openstack.org/#/c/34644/5/nova/db/sqlalchemy/models.py) > >> *) Using different sources of data in Scheduler for example from > >> cinder or ceilometer. > >> (as required by Volume Affinity Filter > >> https://review.openstack.org/#/c/29343/) > >> > >> > >> We found a simple way to mitigate this issues by avoiding of DB usage > >> for host state storage. > >> > >> A more detailed discussion of the problem state and one of a possible > >> solution can be found here: > >> > >> > https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit# > >> > >> > >> Best regards, > >> Boris Pavlovic > >> > >> Mirantis Inc. > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> <mailto: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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
