A new VMTurbo user asked about VMware’s DRS capability to control his environment. He uses DRS to automate vMotions and balance his environment. His question was if VMTurbo (which also uses vMotion) would cause conflicting and potentially excessive vMotions.
What will happen if both VMTurbo and DRS work within a cluster? The short answer is nothing bad. VMTurbo will place workloads to satisfy workload demand with available resource supply. VMTurbo will guarantee the workload performance while utilizing the infrastructure as efficiently as possible; as a side effect it may also balance the cluster. When DRS looks at clusters after VMTurbo, it will likely have nothing to do, and will sit quietly.
So why is VMTurbo’s solution required, even if you have DRS which also performs vMotions?
Before we dive deeper into this question, let’s step back and look at the challenges of using vMotion as a control solution.
vMotion and DRS are both powerful capabilities. A vMotion transfers the VM’s active memory and execution state over a high-speed network, allowing the VM to switch from one host to another without losing state. DRS (Dynamic Resource Scheduler) balances computing capacity for each cluster by spreading the VM workloads across hosts in a cluster and then monitoring the available resources. DRS can also automatically perform vMotions to balance host resources.
But what problem is DRS trying to solve?
DRS is focused on balancing utilization across the cluster. DRS is not focused on workload performance as DRS is not aware of the workload demand and therefore cannot satisfy it. For instance, DRS will balance host utilization, even if that means some workloads’ performance degrades. DRS also does not maximize the infrastructure efficiency (it will evenly distribute the utilization, not maximize it).
VMTurbo solves a different problem. It is focused on assuring workload performance while utilizing the environment as efficiently as possible.
VMTurbo’s approach is unique in that it starts with the application workloads, and understanding all of the virtual resources the guest OS needs to assure application performance. It then maps this shopping list to physical resources in a way that minimizes the performance risk of workload fluctuations (e.g. simultaneously peaking virtual loads will be aligned to separate physical resources).
At the same time VMTurbo will not reserve for workloads more resources than they need, so efficiency is maximized. VMTurbo will only recommend (or execute in automation modes) vMotions when they help solve this problem.
As this user mentioned, his goal is “making the most of the resources while keeping the environment as healthy as possible.” But what really keeps him up at night is the potential that application owners or end-users would complain about poor performance.
By giving a VM all it needs--and only what it needs--performance problems are minimized or eliminated. After all, isn’t that the goal? In order to accomplish this, a solution must be aware of all the resources a VM needs, and not just the host utilization. It also must look at the environment holistically, and align the right resources with the right VMs throughout the environment. Solving this problem across all hosts and all resources is a computational intense task, it may take days to compute. To solve this problem, VMTurbo applies a market based approach to the Compute, Storage and Network resources and leverages efficient market principles to ensure each VM gets the resources it demands.
Of course, the proof is in the pudding
Based on a recent survey conducted by Tech Validate over 60% VMTurbo customers trust VMTurbo’s recommended actions to automate them and get out of the way.
These customers automate VMTurbo’s move recommendations to keep their environment healthy and end-users happy.