On 07/15/2015 08:18 AM, Ed Leafe wrote:
What I'd like to investigate is replacing the current design of having
the compute nodes communicating with the scheduler via message queues.
This design is overly complex and has several known scalability
issues. My thought is to replace this with a Cassandra [1] backend.
Compute nodes would update their state to Cassandra whenever they
change, and that data would be read by the scheduler to make its host
selection. When the scheduler chooses a host, it would post the claim
to Cassandra wrapped in a lightweight transaction, which would ensure
that no other scheduler has tried to claim those resources. When the
host has built the requested VM, it will delete the claim and update
Cassandra with its current state.
One main motivation for using Cassandra over the current design is
that it will enable us to run multiple schedulers without increasing
the raciness of the system.
It seems to me that the ability to run multiple schedulers comes from the fact
that you're talking about claiming resources in the data store, and not from
anything inherent in Cassandra itself.
Why couldn't we just update the existing nova scheduler to claim resources in
the existing database in order to get the same reduction of raciness? (Thus
allowing multiple schedulers running in parallel.)
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
