Without any doubt, this paper raises an interesting challenge. Although this high-quality paper is motivated by a real-world problem, it doen'tnecessarily mean that its results can be repeated in a real test-bed using unorganized workloads and users. So, I am going to readthis paper more carefully. By the way, thank you for the paper's link.
________________________________ From: Edison Su <edison...@citrix.com> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>; 'Linux TUX' <azgil.i...@yahoo.com>; Prachi Damle <prachi.da...@citrix.com> Sent: Saturday, 22 June 2013, 2:47 Subject: RE: Resource Management/Allocation for CS Found this paper sounds interesting: http://www.sigmetrics.org/sigmetrics2013/pdfs/p67.pdf "The physical infrastructure is divided into a large pool of compute and storage servers. The former are organized into clusters consisting of tens of servers (typically 32 or so). A public cloud may contain hundreds of such clusters to get a large-scale deployment. The VMs from a single tenant may span an arbitrary set of clusters. This architecture exists for most of the deployments based on solutions from VMware vSphere [27], Microsoft SCVMM [15] and others. In this environment it is infeasible to simply extend currently existing resource allocation mechanisms. The state-of-the-art today includes cluster management solutions like DRS [12] that collect information about VMs from each server in the cluster, and allocate CPU and memory re-sources based on the demand. This clustered model has certain advantages like facilitating VM migrations between servers if the total allocation to VMs on a server exceeds its physical capacity. However, when a tenant's VMs are spread across multiple clusters, a centralized strategy becomes impractical, since it requires dynamic per VM information to be made available at a cloud-level database shared among hundreds of clusters. Not only does this require a large amount of information to be frequently exchanged between clusters, but the centralized algorithms will be CPU intensive due to the large number of VMs it needs to consider. The problem of scalable dynamic resource and we are not aware of any practical existing solution. We envision our algorithm to run at the cluster-level and allow distributed clusters to work together to provide the customer with the abstraction of buying bulk capacity. " Haven't read the whole paper yet, but the above problem statement resonates with me. Our current centralized allocation algorithm may have problem in case of a large of concurrent VMs allocation. > -----Original Message----- > From: Linux TUX [mailto:azgil.i...@yahoo.com] > Sent: Friday, June 21, 2013 2:27 PM > To: Prachi Damle; dev@cloudstack.apache.org > Subject: Re: Resource Management/Allocation for CS > > HiPrachi, > > Thank you for your reply. Surely, this helps. I will work on these > implementations, and then report my ideas back to the community. > > Thanks, > Pouya > > > > ________________________________ > From: Prachi Damle <prachi.da...@citrix.com> > To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>; Linux TUX > <azgil.i...@yahoo.com> > Sent: Saturday, 22 June 2013, 1:28 > Subject: RE: Resource Management/Allocation for CS > > > Hi Pouya, > > All of CloudStack's RA heuristics are applied by deployment planner modules > and host/storagepool allocators to decide the order in which > resource(pods,clusters,hosts,storage pools) will be considered for a VM > deployment/migration. > > Following are the existing flavors of these modules: > random: This just shuffles the list of clusters/hosts/pools that is returned > by > the DB lookup. Random does not mean round-robin - So if you are looking for > a new host being picked up on every deployment - that may not happen. > firstfit: This makes sure that clusters are ordered by available capacity and > first hosts/pools having enough capacity is chosen within a cluster. > userdispersing: For a given account, this makes sure that VM's are > dispersed - so clusters/hosts with minimum number of running VM's for that > account are chosen first. Storage Pool with minimum number of Ready > storage pools for the account is chosen first. > Userconcentratedpod: Always choose the pod/cluster with max. number of > VMs for the account - concentrating VM's at one pod. > > You can find the source code related to above under: > server/src/com/cloud/deploy, plugins/deployment-planners, plugins/host- > allocators, plugins/storage-allocators > > Hope this helps. > > Thanks, > Prachi > > -----Original Message----- > From: Linux TUX [mailto:azgil.i...@yahoo.com] > Sent: Friday, June 21, 2013 5:48 AM > To: dev@cloudstack.apache.org > Subject: Resource Management/Allocation for CS > > Hi All, > > Does anybody can tell me which parts of CloudStack's source code are > related to its Resource Allocation (RA) process? > By RA, I mean the part of code that is responsible for VM migration or > process migration, if there is any. > As you know, there are two kinds of RA, to wit: 1) server side such as VM > migration, or 2) client side such as clients' proprietary schedulers. > Furthermore, client side's RA's success is dependent on knowing sever side's > RA very well. > > So, since i am interested to work on RA of CloudStack, if, with regard to the > above information, you have any idea, please tell me? > Also, if your are working on it, please let me know. Finally, it would be > really > approciated if you tell me which parts of the source code is related to > implementation of CloudStack's RA algorithms. > > Best regards, > Pouya
