Open Stack

On Oct 8, 2015, at 11:03 AM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:

>> Theoretically if the DB knew about what resources were originally available and
>> what resources have been consumed, then it should be able to allocate resources
>> race-free (possibly with some retries involved if racing against other
>> schedulers updating the DB, but that would be internal to the scheduler itself).
> 
> The problem is, it can't.  The scheduler may be making the decision at
> the same time that an update from a compute node is in flight, meaning
> that the scheduler is missing (at least) one piece of information.  When
> you include a database, that just makes the possibility of missing an
> in-flight update worse, because you also have to factor in the latency
> of the database update as well.  Also, we have to factor in the
> possibility that there are multiple schedulers in play, which further
> worsens the possibility of in-flight information critical to the
> scheduling decision.  If you employ some sort of locking to try to
> mitigate all this, you've just effectively thrown away the scalability
> that deploying multiple schedulers was supposed to buy you.

Yes, the multiple scheduler part is very problematic. Not only could an update from the compute node not be received yet, there could also be updates from other schedulers that aren't caught. One of the most problematic use cases is requests for several similar VMs being received in a short period of time, and all scheduling processes handling them picking the same host. In the Cassandra scenario, the first would "win", and others would fail their attempt to update the resource with the claim, forcing them to select a different host without having to first go through the fail/retry cycle of the current design.

-- Ed Leafe





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151008/34b8e0db/attachment.pgp>