Difference between revisions of "RamRatioInResourceTracker"
(Keep ram ration as per node configuration) |
|||
| Line 8: | Line 8: | ||
b) The host have better idea of the memory limit usable. And we can even provide other method to calculate in resource tracker other than simply ration. | b) The host have better idea of the memory limit usable. And we can even provide other method to calculate in resource tracker other than simply ration. | ||
| + | |||
| + | Some challenges here is, it will change the configuration because the original ram_allocation_ration in scheduler may not work anymore. I think we can another option to select the global configuration or per host configuration. And the scheduler update the limits when the global configuration enabled. By default, we will use the global configuration for backward compatibility. As for the host aggregate ram ration, I think we can update the host resource tracker with the ration specified in the host aggregation metadata. | ||
Latest revision as of 20:47, 30 October 2013
Currently there are two method to specify the ram_allocation_ratio. First method is to set the ram_allocation_ratio configuration in scheduler which will be used by ram filter. Second method is set by host aggregate which will be used by AggregateRamFilter.
I think basically the ram ratio will be host specific. For example, depends on the swap size, or the hypervisor's memory over commitment. Although the AggregateRamFilter can provide host specific ram ratio, it have to access DB for each scheduler call and is really a performance issue. Also, if any instance is scheduled to a host before the host aggregate is created/setup, a wrong ram ratio can cause trouble to host like OOM.
With per node configuration, I'd add an column in DB to indicate memory_mb_limit, and this information will be provided by resource tracker. The benefits of the change are:
a) it makes the flow more clean. Currently the process is, scheduler decide the maxium memory that can be used for instances, and passing that information as 'liimts' to the compute manager, the resource tracker make claims decision with 'limits' passing from scheduler. That's a bit strange IMHO. I'd think scheduler makes the scheduler decision, instead of the resource calculation, while resource tracker provide all the resource information.
b) The host have better idea of the memory limit usable. And we can even provide other method to calculate in resource tracker other than simply ration.
Some challenges here is, it will change the configuration because the original ram_allocation_ration in scheduler may not work anymore. I think we can another option to select the global configuration or per host configuration. And the scheduler update the limits when the global configuration enabled. By default, we will use the global configuration for backward compatibility. As for the host aggregate ram ration, I think we can update the host resource tracker with the ration specified in the host aggregation metadata.
