VMTurbo, was the third presenter, finishing off the first exciting day of Virtulization Field Day 4 in Austin. It was great to see Eric Wright, also known as @discoposse in his new role as Technology Evangelist. Actually, I wish he was more a part of the presentation because it was easy to be engaged with his presenting style. Canadian, Nicholas Cage anyone?
VMTurbo uses a well known supply and demand economy model in order to ensure application performance and maximize efficiency. The customer sets a desired state and VMTurbo, using its supply chain model, is proactive in it’s recommendations to migrate, increase/decrease CPU and so forth on a virtual machine ensuring performance before an anomoly can affect your critical VM or application. Customers see a 20-40% VM density increase because of the data analytics of your workloads.
You can even determine the best place to deploy a new application workloads based on the projected demand and existing application workload demand within your clusters.
Instead of being a monitoring tool and alerting you that something is wrong in your environment, it presents decisions to mitigate risk. For example, chatty VMs will be placed together to eliminate network hops. This isn’t an issue, just creating a better opportunity for performance. You can have a cluster appear balanced in usage but maybe a VM is having high CPU ready times because it is over-sized. VMTurbo will suggest a right-size for the VM in order to alleviate the ready queue or perhaps recommend another host to be added to the cluster. This is common in a lot of environments since “more is better” can be a common way of thinking for delivering CPU and Memory to an application.
So back to the economy model of buyers and sellers. Your data-center is represented as a supply chain where your VMs are consumers and infrastructure components are supply.
Applications are grouped in a vPod and the infrastructure (hypervisor, storage, etc) are grouped into a dPod. If memory is in high demand, the cost goes up to your VMs or grouped vPod. Cost of transaction is also taken into account. If the cost will be too high and the gain not worth the cost, recommendations will not be given. This ensures that you don’t have a VM bouncing back and forth in a cluster or going up and down in allocated RAM, CPU, etc.
If you schedule an event to take place, let’s say rightsizing a VM but recent activity shows it would suffer with the change then it will not take place.
To me this sounds like a dynamic resource pool that I don’t have to babysit or script to maintain shares for my critical applications!
Now on to my favorite part, RESTful APIs! Not only does VMTurbo utilize them to interact with components such as Arista but you can also dig in and get information out of VMTurbo. Eric ha a great post regarding the awesome that is API.
Part 2 will be – CHARGEBACK!