First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
Virtualisation speed traps: ways to drag apps down
- — 14 January, 2010 03:29
What has driven the market for virtual servers more than the potential to squeeze several servers worth of performance out of just one physical server? It's the relative ease with which most applications can move from a physical infrastructure to a virtual one.
But make the move without planning, run into a few of the major performance "gotchas", and your apps sitting on a brand-new virtual infrastructure will run like they're locked in an old box that's sitting around because it's too much trouble to throw out. Here are five virtualization performance points to keep in mind.
1. Skimpy Hardware Sure, one main purpose of virtualization is to make physical servers disappear, but that doesn't mean the hardware itself doesn't matter, says Ian Scanlon, IS operations manager for Computacenter, a datacenter and IT services company based in London but covering most of Europe.
Computacenter migrated the 700-plus servers running its internal IT operations to VMware beginning in 2007, and has had very few performance problems, even with applications very demanding of either I/O or computing resources, Scanlon says. All the VMs run on relatively high-end HP blade servers, with 48 GB of RAM and plenty of SAN space each. Without that elbow room, the data warehouse, SQL Server-based applications and other demanding systems might not pass muster with the business units, he says.
2. Weak Supporting Characters Virtual servers definitely save money, but if you focus too much on cost savings when you're setting them up, you're not going to save money or get decent performance, Scanlon says. High-bandwidth network connections, fiber rather than copper, for example, and powerful SAN gear make far more sense than saving a few bucks in capital costs upfront, he says.
"We went into this [migration] with the goal of saving costs, initially, which we haven't really done," he says. "The benefits really are in agility, the amount of time it takes to stand up a new server or expand something, and making management easier and issues like that. We're not really saving much, but I don't think anyone here would say it was the wrong decision."
According to CIO research, plenty of companies do see substantial savings from virtualization efforts, but they value agility gains just as much.
3. Downsized Support Plans Everyone likes getting "free" servers by running several VMs on one physical box, but that doesn't mean you've actually gotten rid of any of the load on your infrastructure, says Chris Wolf, analyst at the Burton Group. In fact, you've probably increased the load on your power, network and storage resources.
Five VMs on a physical host use the same amount of bandwidth and disk space as five physical servers, and require the same amount of configuration, security, management, licensing, patching and all the other work that goes into keeping one application or a whole data center running, Wolf says. Cutting your support plans or failing to plan increases to accommodate new VMs may not make a difference on day one of a migration, but software rot will quickly drag down performance.
4. Finger-Pointing Instead of Troubleshooting In many companies with IT silos, people who don't handle shared responsibility well will pass responsibility for anything running on a virtualized server to the "virtualization guy," says Bob Quillan, senior director of marketing at EMC's Ionix division, which focuses on management of virtual infrastructures.
By creating another silo responsible for something that touches every other department in IT, companies set themselves up for extended rounds of finger-pointing-rather than troubleshooting when something goes wrong. Traditional IT groups aren't used to the speed with which a virtual infrastructure changes (a condition EMC techs refer to as "V-Motion Sickness") so they tend to blame problems first on that. Breaking down silos and working out triage and response procedures that work within a virtual environment as well as a physical one, is the only way to keep a small breakdown from becoming a big one, Quillan says.
5. Overcrowding Your Applications The hypervisor, OS and hardware may all be the same between two VMs running on the same machine (or identical machines): but the applications running on them change the dynamics so completely that you have to continue planning capacity according to the demands of each application on each server, Scanlon says.
It's easy to put half a dozen VMs running a normal application on one physical server, but only two VMs running an I/O-heavy SQL Server app or power-consuming data warehouse, he says.
Running Citrix virtual-application servers on a VM isn't a problem either, unless you forget that the Citrix app itself is a virtual server whose resource demands will skyrocket when everyone who uses it logs in, if you haven't tested it under real-world conditions, he says.
"We've had relatively few problems in performance since we migrated, but I think that's mostly because we started with really good [hardware]," Scanlon says. "It kept us out of a lot of trouble."
Follow everything from CIO.com on Twitter @CIOonline.