cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Linux TUX <azgil.i...@yahoo.com>
Subject Re: Resource Management/Allocation for CS
Date Sat, 22 Jun 2013 12:34:25 GMT
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.su@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>; 'Linux TUX' <azgil.info@yahoo.com>;
Prachi Damle <Prachi.Damle@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.info@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.Damle@citrix.com>
> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>; Linux TUX
> <azgil.info@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.info@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message