Performance Implications Of Security Functions In Virtualized Environments
In my VirtSec presentations, I lead my audience through the evolution of virtualized security models that describes what configuration and architecture options we have in implementing existing and emerging security solutions both now as well as projected out to about 3 years from now.
I’ll be posting that shortly.
Three of the interesting things that I highlight that result in having light bulbs go off in the audience are when I discuss:
- The compute (CPU) and I/O overhead that is added by security software running in either the VM’s on top of the guest OS’s, security virtual appliances in the host, or a combination both.
- The performance limitations of the current implementations of virtual networking and packet handling routines due to virtualization architectures and access to hardware
- The complexity imposed when having to manage/map a number of physical to virtual NICS and configuring the vSwitch and virtual appliances appropriately to manipulate traffic flows (at L2 and up) through multiple security solutions either from an intra-host perspective, integrated with external security solutions, or both.
I’m going to tackle each of these issues in separate posts, but I’d be interested in speaking to anyone with whom I can compare results of my testing with.
Needless to say, I’ve done some basic mock-ups and performance testing with some open source and commercial security products in virtualized configurations under load, and much of the capacity I may have gained by consolidating low-utilization physical hosts into a virtualized single host is eroded by the amount of processing needed by the virtual appliance(s) to keep up with the load under stress without dropping packets or introducing large amounts of latency.
Beware of what this might mean in your production environments. Ever see a CPU pegged due to a runaway process? Imagine what happens when every packet between virtual interfaces gets crammed through a virtual appliance in the same host first in order to "secure" it.
I made mention of this in my last post:
The reality is that for reasons I’ve spoken of many times, our favorite ISV’s have been a little handicapped by what the virtualization platforms offer up in terms of proper integration against which we can gain purchase from a security perspective. They have to sell what they’ve got while trying to remain relevant all the while watching the ground drop out beneath them.
These vendors have a choice: employ some fancy marketing messaging to make it appear as though the same products you run on a $50,000+ dedicated security appliance will actually perform just as well in a virtual form.
Further, tell you that you’ll enjoy just as much visibility without disclosing limitations when interfaced to a virtual switch that makes it next to impossible to replicate most complex non-virtualized topologies.
Or, just wait it out and see what happens hoping to sell more appliances in the meantime.
Some employ all three strategies (with a fourth being a little bit of hope.)
This may differ based upon virtualization platforms and virtualization-aware chipsets, but capacity planning when adding security functions is going to be critical in production environments for anyone going down this path.