This article originally appeared in the October 2010 issue of INTERNET TELEPHONY
I think we can all agree that virtualization in the data center allows new, more flexible system deployment models throughout the application stack. Virtualization – and specifically the virtual machine – gives us more control over how we deploy applications and their associated services, where those services reside at any given time, and when we add and remove those services. That flexibility is the core tenant for IT agility.
One of my favorite agile use cases for virtual deployments in the data center is service isolation. Service isolation is an extremely flexible deployment model that gives us granular control over the how, where, and when we manage our applications. Resource segmentation is the most common form of service isolation, where virtual platforms have the ability to isolate and restrict virtual machines and their processes to individual hardware components such as CPUs. Resource segmentation is also a critical component of advanced virtual data center tools such as fault tolerance, live virtual machine migration, and network virtualization. But resource virtualization is only the beginning.
Another major form of service isolation offered by virtualization – and one that’s near and dear to my heart – is isolating the entire application function at the virtual platform level. At a macro level, using virtual machines for QA testing, for multiple desktop images, and for specific functions in the data center are all examples of service isolation.
In the data center, most of us virtualized our Apache Web servers first, choosing to isolate that one particular Web services function for virtualization. Over the years we’ve moved through all the app tiers, virtualizing the presentation tier first, then the logic tier, and eventually even the data tier. And every time we chose to virtualize one of those tiers or a tiny subset of the application stack, we were invoking service isolation.
Applications that carry a heavy computational load are prime candidates for full service isolation, and those virtualized application services can be given very explicit sandboxed areas to live. A cluster of four physical CPU cores can be bound together and presented to the virtual machines as one very powerful virtual CPU, a CPU that’s not shared by any other system or by any other applications. In modern server platforms this system of isolation can be repeated multiple times on the same physical device. This allows us to recreate completely the hardware appliance model – often times with better performance results – in the virtual platform, where as before service isolation required hardware isolation (and a lot of data center real estate).
Security is another great example of service isolation. We may want to deploy isolated firewall devices for different parts of our network so that each virtual device can be individually managed while providing specific firewalling services: one for internal users, one for external users, and one for external partners. We can do this with service isolation by virtualizing the firewalls and deploying them in each segmented portion of the network, even if those segmented networks are all connected to the same physical server that’s running all three firewall instances.
When you combine these two examples of service isolation into one dynamically provisioned system, you get some cool solutions. For example, a DoD contractor may need to crunch very large numbers for CGI (News - Alert) renderings. When the contractor logs into its environment through an isolated firewall, new virtual machines can be created dynamically just for that contractor, assigned to its own very powerful virtual CPUs, and only available during the duration of that specific session. When the contractor is done crunching numbers and logs out, those virtual machines are destroyed and the CPUs released to the next contractor that logs in. That’s really where we see virtualization enabling IT agility down to the service and user levels.
Service isolation doesn’t necessarily have to equate to virtual machine isolation. Today, service isolation is achievable by assigning individual virtual machines to individual tasks, but tomorrow we’ll be able create service isolation on the application level. With true application virtualization – where the app is no longer bound to a base OS and forced to run in a virtual machine container – we’ll be able to isolate further the individual application components. Individual tasks, such as virtualizing user logins to a Web application or binding individual Exchange mailboxes to hardware, can be isolated in the same way we isolate firewalling functions today.
Service virtualization is achievable with physical devices as well; however, complete physical isolation isn’t as flexible or mobile as virtual service isolation. Virtualization allows us to implement a level of service isolation that’s not nearly as approachable in the physical world and to take full advantage of our application infrastructure.
TMCnet publishes expert commentary on various telecommunications, IT, call center, CRM and other technology-related topics. Are you an expert in one of these fields, and interested in having your perspective published on a site that gets several million unique visitors each month? Get in touch.
Edited by Jaclyn Allard