Originally published on the Cloud.com wiki. Added by David Nalley. Last modified October, 2011.
The User Dispersing Deployment Planner introduces a new planner to the existing deployment planner set. Goal of this planner is to make the best effort to deploy VMs belonging to the same account into different clusters or pods. The highlights of the feature include:
This section describes each of the functionality introduced in this feature on a high level.
This planner provides the ability to pick resources (cluster or pod) such that VMs belonging to an account are dispersed as much as possible. It is desired in many cases that the VMs belonging to accounts/users should not get deployed to a particular pod or cluster. The reason for this is if that one cluster or pod goes down due to some issue, it affects that particular account completely. Hence this planner is needed.
Allocation logic overview:
Some of these conditions are:
Currently FirstFitPlanner looks directly at the clusters while listing by aggregate capacity. This ensures that the VM load is balanced across clusters. The clusters across pods get considered and VMs may get dispersed across pods or may not.
However admins need the ability to ensure that the VMs get dispersed at pod level also since there are networking/business implications at pod level. This needs us to change the FirstFitPlanner to be able to list pods per aggregate capacity instead of clusters and choose the pod that has better available capacity first.
We plan to provide a configuration parameter to enable admin to select whether the planner should look at the pod level or cluster level.
If pod level is selected, planner should apply the capacity logic to the list of pods under a zone. The user dispersing planner should choose those pods first which have less number of VMs for this account.
Under each pod, the capacity and user dispersing heuristic should be reapplied to all the clusters as well. Thus the dispersion should be done at pods and then at clusters.
Since we will have multiple deployment planners with varied abilities of selecting a deployment destination, we need to provide an admin the ability to select a planner as per requirements.
To enable this, we need to provide planner selection as part of the serviceoffering. And each deploymentPlanner should check the serviceOffering to see if it should handle the VM deployment or not.
This API creates a new serviceOffering.
Changes to this API:
- New String Parameter added: deploymentPlanner
Possible list of values:
- ServiceOfferingResponse: deploymentPlanner
Response object includes the planner chosen for this serviceOffering. It is a String.
There are UI changes to enable an admin to select a planner while creating a ServiceOffering.
Following changes are needed:
- Create ServiceOffering should include a field with tag ‘Deployment Planner to use’
- Value should be a drop down list that currently has
- By default, value should be ‘FirstFitPlanner‘
- On successfully creating the offering, the response page should show the deploymentPlanner value back to the user.
A new Column ‘deployment_planner’ will be added to this table. Upgrade script will have this added:
ALTER TABLE `cloud`.`service_offering` ADD COLUMN `deployment_planner` varchar(255) NOT NULL DEFAULT 'FirstFitPlanner' COMMENT 'Class name of the deployment planner to use';
We need to add a new Configuration parameter to enable admin to choose whether the planner heuristics should be applied at pod level or cluster level.
INSERT IGNORE INTO configuration VALUES ('Advanced', 'DEFAULT', 'management-server', 'apply.planner.heuristics.to', 'cluster', 'Level at which deployment planner should apply heuristics to (cluster or pod)');
We need to add weights to the planner heuristics.INSERT IGNORE INTO configuration VALUES ('Advanced', 'DEFAULT', 'management-server', ‘user.vm.dispersion.weight’, '1', 'Weight for user dispersion heuristic. Weight for capacity heuristic will be (1 – weight of user dispersion)');
This planner will need some changes in order to implement this feature.
This planner will extend the existing FirstFitPlanner to figure out the list of clusters/pods ordered by available aggregate capacity.
It will apply the user dispersing heuristic on top of this list.
Example: Suppose we have pods (P1, P2) and clusters (C1…C3) with hosts (H1…H5) and pools (P1…P4) as follows:
Then this is how we choose the resources:
List Pods in order of available aggregate capacity. Say list is:
Get number of VMs of this account for each pod and list in ascending order. Say it is:
Within each pod list clusters based on aggregate capacity. Say for P1:
List by number of VMs for this account per cluster in ascending order. Say:
o Suppose admin selects to apply the heuristics at cluster level directly instead of pod, we start from listing clusters.
o Assigning weights to capacity and number of VMs:
- As seen above we have two parameters to order the pods or clusters- capacity and number of VMs.
- We plan to provide a global config variable to set weights for these two parameters so that we don’t ignore capacity completely over the number of VMs while reordering the lists.
Thus admin can set something like:
user.vm.dispersion.weight = 0.75
- This means that weight for capacity is 0.25
- We will apply the weights to the capacity and number of VMs to generate a number on which we reorder the clusters or pods.
By default user VM dispersion will have 100% weight. Thus value of user.vm.dispersion.weight = 1 and weight for capacity will be 0.
- Example:
Suppose this is the cluster list in order of capacity:
Cluster |
x = % Full Capacity |
x * weight(0.25) |
C1 |
0.35 |
0.0875 |
C2 |
0.45 |
0.1125 |
C3 |
0.65 |
0.1625 |
And this is the list in order of number of VMs for the given account:
Cluster |
Number of VMs for this account |
Normalized value y = number/total number of VMs existing for this account (10) |
y * weight(0.75) |
C2 |
1 |
0.1 |
0.075 |
C3 |
2 |
0.2 |
0.15 |
C1 |
4 |
0.4 |
0.3 |
Calculate total weight per cluster as, total weight = (x*0.25 + y * 0.75)
Cluster |
Total weight |
C1 |
0.3875 |
C2 |
0.1875 |
C3 |
0.3125 |
Then reorder the list by total weight. The final ordered list will be: