Agent-Based Software: Wrong for Virtualization

The time has come for virtualization admins to take a step back and re-evaluate their environments. We have been on a virtualization mission for the past few years and some of us haven't stopped to take a breath and fine-tune or refine these new environments that we're building and that we believe will yield all the benefits that come with virtualizing our servers.

We have done a great job of taking our existing physical environments and virtualizing them, but with that many of us have also imported the same processes, procedures and approaches that were used to build our physical server environments. One of the things I want to focus on this time is the agent-based approach to anything virtual.

You see, back in the physical server world, an agent-based approach to a software deployment was acceptable: The physical server was an isolated container, self-sufficient from a compute, network and -- to some extent -- storage perspective. Placing an agent for backup purposes or for antivirus was a practice we had refined for years and which served us well.

As we virtualized, we brought the same concept into the virtualized environment. I cannot begin to tell you how many times I have advised customers against doing so.

In a virtualized environment, you have a multitude of virtual containers with one thing in common: They all share physical resources. You can have VMs on physical hosts that share compute, network and storage resources. When you take the approach of an agent-based anything on this type of platform, you immediately create a bottleneck, and you create unnecessary duplication. This method limits your ability to scale your environment, as well as hinders your ability to successfully virtualize more of your environment, especially the tier-1 applications that you may have resisted virtualizing to this day.

If you still use an agent to back up your virtual machines, then you are not taking advantage of the VMware vStorage APIs for Data Protection (VADP) that allows back-up software to plug in and offer backup and restore solutions in your virtual environment the right way in a virtualized space. Don't worry about consistent versus non-consistent backups -- all respectable back-up solutions should be able to plug into Microsoft's Volume Shadow Copy Services and provide the desired level of backup and restore. If you own the software but have not upgraded to the version which would allow you to do so, I strongly urge you to invest the time in doing so. If you own software that does not support these APIs, ask your vendor for a road map, and if one does not exist or is too far out, maybe it is time to find a vendor that can react much quicker to the changing world we live in.

Let's move on to antivirus. I have discussed antivirus many times when tackling VDI, but I want to urge you to revisits your anti-virus approach even on server virtualization. Again, having an agent-based antivirus solution will grill the underlying storage from an IO perspective. Every time a scan runs, every time an update to the definition files or the AV engine occurs, it all translates into very intense pressure on storage. As storage is the most critical component that directly impacts a VM's performance, you are faced with a dilemma.

You can, of course, take the antivirus vendors' approach of" "well, you can randomize scans, and you can set different time schedules on how to update definitions, etc." Still, all these recommendations assume that we still have maintenance windows and after-hours cycles to perform these tasks. The reality of the matter is that outage and maintenance windows are shrinking so much that they don't even exist at some enterprises. Randomizing scans and updates is a temporary workaround that does not scale properly, so what is the fix? Well, some organizations have decided to reinforce their storage with more spindles, insert SSDs into the mix, etc. Basically, those organization have thrown hardware at a software problem.

My question to everyone is. why are you not leveraging VMware vShield Endpoint? For VDI, it's a given, but let's examine vShield from a server virtualization perspective. I have a customer with over 1,500 VMs and growing. It's worse than having VDI, and my customer has an AV agent inside every VM. Why?

vShield Endpoint is not expensive, and I promise if you do the math it will be a fraction of the price you are paying for the additional storage. vShield Endpoint injects a driver inside of every VM. This driver is a Virtual SCSI enhanced driver, if you will, which offloads the IO traffic to a vShield Endpoint appliance. The appliance inspects the IO traffic going in and coming out of the VM for malware. This approach allows you to scale in a virtual world. Remember, it is all about shared resources, the concept of an isolated, dedicated set of resources no longer exists. So, our way of thinking has to arrive at the same point where the technology is today.

You have to start correlating things together -- storage teams and virtualization teams cannot remain siloed. You also have to understand how your technologies affect your teams. How do certain processes in a virtualized environment affect storage and vice versa? This spans the network and compute teams as well. We have to break the silo barriers and work together. Otherwise, you defeat the purpose of a virtualized environment.

Now granted, we still find agents to be necessary, I understand that. For some solutions, use an agent. What can you do? However, stay updated on what is happening and try to avoid the agent-based approach whenever possible. I am still dealing with customers that leveraged agents so much in ESX, that they are finding it hard to migrate to ESXi. Your thoughts? Post them here or e-mail me.

Posted by Elias Khnaser on 11/15/2011 at 12:49 PM