cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: Regarding Cpu and memory overcommit feature.
Date Wed, 06 Feb 2013 03:49:22 GMT
Prachi,
  For Hypervisor not supporting overcommit, the cluster of those
hypervisors cannot have a overcommit. It should not affect the current
capacity calculation. Bharat will be able to elaborate on this.

-abhi

On 06/02/13 1:11 AM, "Prachi Damle" <Prachi.Damle@citrix.com> wrote:

>Hi Bharat / Abhi,
>
>Even currently we always store actuals in the DB in op_host_capacity
>table. During allocation, the overprovisioning ratios are applied
>dynamically to find the overprovisioned "total" capacity.
>So it's good that even the new way will follow that.
>
>>Major differences are
>>1.) In new way we store what we actually allocate in the DB  rather than
>>the one in the service offering.
>>2.) All calculations are done based on the actuals.
>>3.) Depending on the overcommit values we scale down and then allocate.
>
>This is based on the XenServer overcommit support. What will happen for
>rest of the hypervisors, since currently capacity calculation is a
>generic  logic?
>
>
>-Prachi
>
>-----Original Message-----
>From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
>Sent: Monday, February 04, 2013 10:44 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: FW: Regarding Cpu and memory overcommit feature.
>
>
>On 01/02/13 4:22 PM, "Bharat Kumar" <bharat.kumar@citrix.com> wrote:
>
>>Hi All,
>>
>>I have made changes to the way capacity is calculated in Cloudstack ,
>>please review and comment.
>>
>>I will illustrate this with an example.
>>
>>let us say we have a host with
>>Actual Total capacity=4GB ram,
>>
>>and the overcommit ratio be 2.
>>
>>Current way      
>>Total capacity= 4*2= 8GB.
>>Values after deploying 4 VMs with 1GB in service offering.
>>Allocated per vm =1GB.
>>Used=4GB
>>Available=8-4=4GB
>
>>now if we decrease the overcommit ratio to 1 Total Capacity = 4*1=4GB.
>>used Capacity = 4GB.
>>Available = 4-4=0. (implies 100% usage. can also go to more than 100%)
>
>
>We should store the actuals in the db with over commit ratio. And rest of
>the values of available memory and used memory can be calculated form
>that.
>So the new method mentioned below looks consistent.
>
>-abhi
>
>>
>>XenServer uses DMC for memory overcommit, to use this feature we have to
>>set the minimum and maximum ram that we want to allocate.
>>The memory used by the VMs can vary between the minimum and maximum. In
>>case of contention they will be allowed to use the minimum memory
>>allocated
>>to them. Minimum memory is the reserved memory which is guaranteed for
>>the VM. 
>>
>>New WAY.
>>Total Capacity= 4GB.
>>Values after deploying 4VMs with 1GB in service offering.
>>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum
>>and 1GB is the maximum.)
>>Used = 4* minimum allocated per vm = 2GB.
>>Available = 4-2= 2GB.
>>Value that is visible to admin as available = Available * overcommit
>>ratio =2*2= 4GB.
>>Now if we decrease the overcommit ratio to 1
>>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made
>>available by the XenServer using DMC.)
>>(we can still deploy VMs in this case )
>> 
>>Major differences are
>>1.) In new way we store what we actually allocate in the DB  rather than
>>the one in the service offering.
>>2.) All calculations are done based on the actuals.
>>3.) Depending on the overcommit values we scale down and then allocate.
>>
>>Advantages 
>>1.) The usage can never go beyond 100% and is independent of changes in
>>overcommit values.
>>2.) We can deploy more VMs.
>>
>>Also please comment if we need to show actuals on the dashboard or the
>>over provisioned values and why.
>>
>>Regards,
>>Bharat.
>>
>>
>>
>>
>>
>


Mime
View raw message