On 06/04/2014 11:56 AM, Day, Phil wrote:
Hi Jay,
* Host aggregates may also have a separate allocation ratio that
overrides any configuration setting that a particular host may
have
So with your proposal would the resource tracker be responsible for
picking and using override values defined as part of an aggregate
that includes the host ?
Not quite sure what you're asking, but I *think* you are asking whether
I am proposing that the host aggregate's allocation ratio that a compute
node might be in would override any allocation ratio that might be set
on the compute node? I would say that no, the idea would be that the
compute node's allocation ratio would override any host aggregate it
might belong to.
I don't think at the moment hosts have any logic which checks which
aggregate they are in, so that adds another DB query per compute host
every time the resource tracker needs that info - is that going to be
more load on the DB for a large system that the current logic ?
It uses objects, and there would be an extra join to the host_aggregates
table, but not another query. For the record, the way that the scheduler
currently works with host aggregates is poorly-performing due to a DB
call that occur *on every single call to launch instances*:
http://git.openstack.org/cgit/openstack/nova/tree/nova/scheduler/filters/core_filter.py#n81
I like the idea of nodes controlling overcommit and reporting the
adjusted resources to the scheduler - just want to be sure of the
impact.
Cool, good to have you on board with the idea.
(This is beginning to feel like a nova-specs review ;-)
LOL, yes indeed. I like to socialize the idea before pushing up the
spec, though, and this gets me some good feedback with which to write
the spec...
Best,
-jay
-----Original Message----- From: Jay Pipes
[mailto:jaypi...@gmail.com] Sent: 03 June 2014 14:29 To: OpenStack
Development Mailing List Subject: [openstack-dev] [nova] Proposal:
Move CPU and memory allocation ratio out of scheduler
Hi Stackers,
tl;dr =====
Move CPU and RAM allocation ratio definition out of the Nova
scheduler and into the resource tracker. Remove the calculations
for overcommit out of the core_filter and ram_filter scheduler
pieces.
Details =======
Currently, in the Nova code base, the thing that controls whether
or not the scheduler places an instance on a compute host that is
already "full" (in terms of memory or vCPU usage) is a pair of
configuration options* called cpu_allocation_ratio and
ram_allocation_ratio.
These configuration options are defined in, respectively,
nova/scheduler/filters/core_filter.py and
nova/scheduler/filters/ram_filter.py.
Every time an instance is launched, the scheduler loops through a
collection of host state structures that contain resource
consumption figures for each compute node. For each compute host,
the core_filter and ram_filter's host_passes() method is called. In
the host_passes() method, the host's reported total amount of CPU
or RAM is multiplied by this configuration option, and the product
is then subtracted from the reported used amount of CPU or RAM. If
the result is greater than or equal to the number of vCPUs needed
by the instance being launched, True is returned and the host
continues to be considered during scheduling decisions.
I propose we move the definition of the allocation ratios out of
the scheduler entirely, as well as the calculation of the total
amount of resources each compute node contains. The resource
tracker is the most appropriate place to define these configuration
options, as the resource tracker is what is responsible for keeping
track of total and used resource amounts for all compute nodes.
Benefits:
* Allocation ratios determine the amount of resources that a
compute node advertises. The resource tracker is what determines
the amount of resources that each compute node has, and how much of
a particular type of resource have been used on a compute node. It
therefore makes sense to put calculations and definition of
allocation ratios where they naturally belong. * The scheduler
currently needlessly re-calculates total resource amounts on every
call to the scheduler. This isn't necessary. The total resource
amounts don't change unless either a configuration option is
changed on a compute node (or host aggregate), and this calculation
can be done more efficiently once in the resource tracker. * Move
more logic out of the scheduler * With the move to an extensible
resource tracker, we can more easily evolve to defining all
resource-related options in the same place (instead of in different
filter files in the scheduler...)
Thoughts?
Best, -jay
* Host aggregates may also have a separate allocation ratio that
overrides any configuration setting that a particular host may
have
_______________________________________________ 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
