Hari - Please find my answers inline. On 07/01/13 5:27 AM, "Hari Kannan" <hari.kan...@citrix.com> wrote:
>While elaborating this feature, the following issue came to mind: > >Admin could set various overcommit ratios (could setup a different ratio >for each cluster, for example) - however, unless he sets up host tags, >does he or the end user have any control over where the VM actually gets >placed? If, so where is the use for this feature? I see it as follows: > >- Each cluster (depending on the hypervisor platform, storage or h/w >configuration) can handle a different number of VMs per host/cluster - >trying to normalize them can be inefficient, as the ratio has to be setup >for the lowest common denominator - hence, we are providing a finer >granularity for better utilization of resource, irrespective of what the >placement algorithm decides > >- when combined with dedicated resources, it gets better - with dedicated >resources, we will have the capability to tell account A will use cluster >X. If this account is paying for "gold" quality of service, perhaps, >those clusters would have a ratio of 1. If they are paying for "bronze" >QoS, their cluster ratio could be 2. > >To make it better, I wonder if we could introduce the notion of cluster >tags? With cluster tags, you could setup various overcommit ratios for >each of the cluster (if needed) and by matching service offerings, we >could provide various quality of service to end users/accounts - > >If a cluster has a tag, each host "inherits" the tag - i.e. it is >equivalent to setting each host with the same tag as cluster tag >Any individual host could also have a tag - in which case, the default >(inherited) cluster tag, if present, is overwritten with the more >specific tag provided for the host > >Does it make sense? It does make sense :). However I think the cluster tag is always inherited. If the host has a tag it should not overwrite the cluster tag but add to its list. Another question is that do these tags get inherited only for hosts or also the storage ? In case of storage motion coming do we then restrict the migration of these vms to supported clusters only ? Also if the storage also inherits the tags then even the volume migration will happen in supported clusters only. I think it makes sense. > >If it does, does it make sense to introduce tags to pods/zones? I feel >probably not, but thought I would ask any way At this point not. Do we set anything at pod level which will affect say QOS or similar ? I guess not so no use having pod tags. > >For clarification, my understanding of host tags as it stands currently >is depicted at this link >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Tags > >Please review and provide feedback > >Hari > > >-----Original Message----- >From: Hari Kannan [mailto:hari.kan...@citrix.com] >Sent: Wednesday, December 26, 2012 1:06 PM >To: cloudstack-dev@incubator.apache.org; >cloudstack-us...@incubator.apache.org >Subject: RE: [Discuss] Cpu and Ram overcommit. > >What should the behavior be if admin changes the overcommit factor for a >cluster that conflicts with the current situation. For example, lets >assume Cluster X has an over commit factor of 1.5x for memory and the >admin wants to change this to 1x - i.e no overcommit (or changes from 2x >to 1.5x) - however, based on the "older" factor, CS might already have >assigned more VMs - when the admin reduces the overcommit value > >1. if there is no conflict, there is no issue 2a. if there is a conflict >(i.e. current allocation would conflict with the new value) - should we >reject this change? (preferred) 2b. or accept the change but not add >more VMs anymore > >-----Original Message----- >From: Bharat Kumar [mailto:bharat.ku...@citrix.com] >Sent: Wednesday, December 26, 2012 4:39 AM >To: cloudstack-dev@incubator.apache.org; >cloudstack-us...@incubator.apache.org >Subject: Re: [Discuss] Cpu and Ram overcommit. > >Nitin thanks for your suggestions. > >My comments inline > >On Dec 26, 2012, at 3:22 PM, Nitin Mehta <nitin.me...@citrix.com> wrote: > >> Thanks Bharat for the bringing this up. >> I have a few questions and suggestions for you. >> >> 1. Why do we need it per cluster basis and when and where do you >>configure this ? I hope when we change it for a cluster it would not >>require MS reboot and be dynamically understood - is that the case ? > Depending on the applications running in a given cluster the admin >needs to adjust the over commit factor. for example if the >applications running in a cluster are ram intensive he may want to >decrease the ram overcommit ratio for this cluster without effecting the >other clusters. This can be done only if the ratios can be specified on a >per cluster basis. >Also to change these ratios MS restart will not be required. > >> If we make it cluster based allocators will have to check this config >>for each cluster while allocating and can potentially make allocators >>expensive. Same logic applies for dashboard calculation as well. >> What granularity and fine tuning do we require - do you have any use >>cases ? > The intent of having cluster based over provisioning ratios is to >deploy VMs selectively depending on the type of application the vm will >run. By selectively i mean the admin will want to specify in which >clusters to run the VM. This will narrow down the number of clusters we >need to check while deploying. I still don't know the exact way in which >we should control the vm deployment. This definitely needs further >discussion, will be clear once we narrow down all the possible use cases. > > >> 2. What would happen in case of contention ? >In case of contention the the hypervisor specific methods to handle the >contention will come into effect. This feature assumes that admin has >thought of the possible scenarios and has chosen the overcommit ratios >accordingly. >> >> 3. Please remember to take care of alerts and dashboard related >>functionality. Along with this also list Zone/Pod.../host/pool API also >>use this factor. Please make sure that you take care of that as well. >Thanks for the suggestions. > >> >> -Nitin >> >> On 26-Dec-2012, at 11:32 AM, Bharat Kumar wrote: >> >>> Hi all, >>> >>> Presently in Cloudstack there is a provision for cpu overcommit and >>>no provision for the ram overcommit. There is no way to configure the >>>overcommit ratios on a per cluster basis. >>> >>> So we propose to add a new feature to allow the ram overcommit and to >>>specify the overcommit ratios ( cpu/ram ) on a per cluster basis. >>> >>> Motivation to add the feature: >>> Most of the operating systems and applications do not use the >>>allocated resources to 100%. This makes it possible to allocate more >>>resource than what is actually available. The overcommitting of >>>resources allows to run the underutilized VMs in fewer number of >>>hosts, This saves money and power. Currently the cpu overcommit ratio >>>is a global parameter which means there is no way to fine tune or have >>>a granular control over the overcommit ratios. >>> >>> This feature will enable >>> 1.) Configuring the overcommit ratios on a per cluster basis. >>> 2.) ram overcommit feature in xen and kvm. ( It is there for VMware.) >>> 3.) Updating the overcommit ratios of a cluster. >>> >>> Regards, >>> Bharat Kumar. >> >