-
-
Notifications
You must be signed in to change notification settings - Fork 201
Description
Current VmAllocationPolicy
implementations make VM placement decisions for each VM at a time.
They don't allow placing a group of VMs together to optimize placement and/or avoid VMs in that group to be placed into different Hosts.
If VMs into a group are inter-communicating VMs that are supposed to be placed into the same Host to reduce network traffic and communication delay, this is not ensured.
Even if VMs are not intercommunicating, group placement may be more efficient in some situations.
For instance, consider there are 3 VMs requiring 2 PEs each one and there are the following Hosts where these VMs can be placed, everyone with a specific amount of available Pes.
Host 1 | Host 2 | Host 3 | Host 4 |
---|---|---|---|
4 PEs | 2 PE | 10 PEs | 12 PEs |
Best Fit VM Placement
If it's used a Best Fit allocation policy (which selects the Host with less available PEs which fits the VM, maximizing resource usage), the allocation may be:
Host 1 | Host 2 |
---|---|
VM 1, VM 2 | VM 0 |
If these 3 VMs are supposed to be a clone of each other, running some service such as a Web Server, and they used to balance workload, the presented allocation is the best, since it has a failure tolerance level of 2 (if 2 Hosts fail, one VM will continue to run in the third Host and the service is not stopped).
However, if these are VMs from different customers, doesn't matter if they are placed into the same of different Hosts. In this case, the presented placement just increases the number of used Hosts, which may lead to increased energy consumption.
Worst Fit VM Placement
If it's used a Worst Fit allocation policy (which selects the Host with more available PEs with fits the VM, maximizing resource idleness), all VMs may be allocated to Host 4.
Host 4 |
---|
VM 0, VM 1, VM 2 |
As discussed above, if those VMs belong to the same customer and are used for workload balance, this placement doesn't enable fault tolerance and one VM may interfere with other one's performance. On the other hand, if they belong to different customers, this placement maximizes resource usage and minimize energy consumption.
Problems with presented policies
As can be seen, the kind of policy to be used depends on the desired goal.
Considering the VMs belong to different customers (DatacenterBrokers
), the two presented placement aren't the most efficient ones.
The Best Fit placement used 2 Hosts when it could be selected only the Host 3 to place all VMs and reduce the number of active Hosts.
The Worst Fit placement placed all VMs into a single Host, as aimed in this example. However, using Host 3 instead of 4 would be enough for all these 3 VMs, without overloading it.
This way, if a VmAllocationPolicy considered placing a group of VMs together, a Best Fit placement would be able to select Host 3 to place all these VMs.
A brief explanation of why you think this feature is useful
It will give more flexibility for the developer to implement and assess different placement policies, considering distinct scenarios and goals.
Features not Implemented
- Doesn't allow deciding what to do when there is no Host with enough capacity to place all VMs into a group. In such a case, the allocation of the entire group fails. There would be an option to indicate if the broker should just work that way or, when no Host is found, if it should try to create as many VMs from the group as possible.