master, planner_reserve
Currently CloudStack has following 3 deployment planners available out-of-the-box:
Each of these planners implements some heuristics that provide ordering of resources on some basis, while choosing resources for VM deployment. Currently in a CloudStack deployment, only one of these planners can be used for all VM deployments. The global parameter 'vm.allocation.algorithm' decides which planner will be used.
However there could be a need to be able to choose different planning strategies within a single CS deployment. So letting Admin choose a deployment planner for a set of VMs will be helpful.
To enable this, proposal is:
When the Deployment planner gets exposed per ServiceOffering, then in a CS deployment multiple planners will have to co-exist.
In such case, we might need resource reservation between planners, so that planner executions do not step onto each other's resource choice.
The existing planners work on the available set of resources in a given datacenter that are shared across various accounts. So all of them can co-exist without an issue since they do not need to book resources exclusively.
However if a planner is added that needs to use resources exclusively for an account, then we will need some kind of resource reservation between planners.
e.g Refer to the Implicit Dedication Planner being added as part of this 4.2 release.
When a planner like the [Implicit Dedication Planner] chooses a host for deployment, DPM can store it as a 'dedicated' host. No other planner will be able to pick it up for any other VM deployment.
We will add this enum to the DeploymentPlanner interface. Each planner should return the resource usage it works with.
E.g: the existing 3 planners (FirstFit, UserDispersing, UserConcentrated) can share resources - so they will return PlannerResourceUsage.Shared
public enum PlannerResourceUsage { Shared, Dedicated;}
As noted above, DPM will check if a host selectd by a planner can be used by that planner by referring to the 'op_host_planner_reservation' record and reserve the host if it can be used.
However, if the host has been picked by another planner for a non-matching usage then DPm will have to re-invoke the planners to find new host.
DeploymentPlanners currently list clusters using some heuristic and for each cluster find a list of suitable host and suitable storagepools. From these list the first pair of host and pool that works together is returned. At this point the ordered list of clusters, hosts and storagepools is thrown away. Now if DPM rejects this chosen host at the reservation step at last, we will execute all the planner logic again.
Instead if DPM has access to the list of clusters ordered by the planner, we will save some iterations calling the HostAllocator and StoragePoolAllocators over and over.
Hence we will introduce a new interface that extends from existing DeploymentPlanner interface that the current planners will implement.
public interface DeploymentClusterPlanner extends DeploymentPlanner { /** * This is called to determine list of possible clusters where a virtual * machine can be deployed. * * @param vm * virtual machine. * @param plan * deployment plan that tells you where it's being deployed to. * @param avoid * avoid these data centers, pods, clusters, or hosts. * @return DeployDestination for that virtual machine. */ List<Long> orderClusters(VirtualMachineProfile<? extends VirtualMachine> vm, DeploymentPlan plan, ExcludeList avoid) throws InsufficientServerCapacityException; PlannerResourceUsage getResourceUsage(); }
Thus the current Planners will be refactored to just return the ordered list of clusters. DPM will execute the rest of the logic:
- Iterate over the cluster list
- For each cluster, call hostAllocators to get a list of suitable hosts
- For each cluster, call storagePoolAllocators to get a list of suitable pools
- Find a potential DeployDestination that consists of host-storagepool to deploy the VM considering factors like: host-storage pool linkage, planner host reservation.
This means that the current API in DeploymentPlanner interace will be deprecated for future usage.
public interface DeploymentPlanner extends Adapter { @Deprecated DeployDestination plan(VirtualMachineProfile<? extends VirtualMachine> vm, DeploymentPlan plan, ExcludeList avoid) throws InsufficientServerCapacityException;
Global config variable to choose a planner if no planner is selected in the ServiceOffering
INSERT IGNORE INTO `cloud`.`configuration` VALUES ('Advanced', 'DEFAULT', 'management-server', 'vm.deployment.planner', 'FirstFitPlanner', '[''FirstFitPlanner'', ''UserDispersingPlanner'', ''UserConcentratedPodPlanner'']: DeploymentPlanner heuristic that will be used for VM deployment.');
Following UI changes are needed:
Add a field 'deployment planner' to the createServiceOffering UI. The parameter is optional. The value should be accepted using an empty input box.