Some time ago we discussed the effects of diversity and heterogeneity on network and storage management disciplines. With greater hardware diversity and rapid commoditization of the bottom of the supply chain, data center operators try to find common ways to provide reliable service delivery.
A very popular and rapidly emerging trend is using virtualization policies as a way to declare and conform to the intent. In general, this is the right way: if you know your goals just state them and have some smart piece of software to enforce this policy. The tricky part is figuring out the intent.
Let’s consider several examples of policies and try to understand what and how they try to accomplish this. First, as we discussed several times is affinity rules. In an attempt to minimize the latency between frequently talking applications the policy requires the underlying layers (like vSphere DRS) to keep certain VMs running on the same host. Once the policy is in place and declared, the VMs will be kept together. The issue here is the intent. Is this the right way? I don’t think so.
This policy doesn’t state the intended level of service, it declares the minimal distance between the VMs which may or may not help to guarantee the level of service. This minimal distance is only one aspect impacting the level of service. For example, if you bring the VMs together on the same host but this host is struggling with very high CPU and memory utilization, the level of service will suffer.
So what is the better way of doing this? The policy mechanisms are still good, let’s just raise the level of policies to the end user goals. For example, a goal could be to deliver the expected service in consumer terms. If you run an online shopping application consisting of the load-balanced web front-end and application and database tiers processing the requests you could just state how many user requests per unit of time you want to process to satisfy your business requirements. For example, this is how you would do it in VMTurbo Operations Manager:
The fact that certain VMs talk to each other is not a matter of policy, it is a matter of demand between applications and infrastructure. If some specific load demand requires certain components to be closer to each other but also get all needed resources to fulfill the policy, let the control solution figure it out. Once it is determined the actions could be move certain VMs closer to each other:
Or increase the front-end tier capacity to comply with the increased end-user demand:
As you can see, policies controlling demand bring us much closer to accomplishing end user goals than policies which try to limit supply at the infrastructure level. The problem with controlling the supply is that you really don’t know what the demand is and the supply controlling decision can seriously impact end user performance.
Another good example is storage policies trying to control IOPS or space of the underlying storage without understanding what the demand is. You may find statements like “Free space should never be less than 20%” or “IOPS utilization should be at 50%”. These threshold don’t take into account which applications need these resources and they only accomplish managing the utilization levels of the infrastructure.
Is there a better way? Yes. Again, even if you are an infrastructure owner you could express a policy in end user terms. For example, try to minimize the latency for all the applications using your storage:
Then VMTurbo Operation Manager can suggest the actions which will comply with this end user demand and maintain the needed latency, for example, by moving VMs across datastores:
These are only a few examples which stress the importance of controlling the application demand and end-user aspects of it instead of dealing with supply.
Next time you are in the market for solutions to help you deliver a reliable service try to identify those which use these terms in their policies. It’d be useful to think in terms of what your end users think. Do you know what they are?