Jay, thanks for raising this up .
+1 for this .
A related question about the CPU and RAM allocation ratio, shall we apply
them when get hypervisor information with command "nova hypervisor-show
${hypervisor-name}"
The output shows like
| memory_mb |
15824
|
| memory_mb_used |
1024
|
| running_vms |
1
|
| service_host |
node-6
|
| service_id |
39
|
| vcpus |
4
|
| vcpus_used | 1
vcpus is showing the number of physical CPU, I think that's not correct.
Any thoughts ?
2014-06-03 21:29 GMT+08:00 Jay Pipes <jaypi...@gmail.com>:
> 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
>
--
ChangBo Guo(gcb)
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
