Pressing the new data center advantage

On identifying applications for virtualization Disaster recovery and virtualization Other virtualized resources Changes to application environment and beyond

As senior application architect for Praxair, a $5.6 billion industrial products supplier in Danbury, Conn., Sam Marrazzo has spent the past year evaluating applications - old and new - for use on virtualized servers. The differences between developing applications using virtual instances rather than physical servers can be astounding, Marrazzo says. For example, he has found that application build times can be up to 100 times faster with virtualization. "Crazy, but true," he says. Here Marrazzo tells Signature Series Editor Beth Schultz what he's learned as an application architect working within a virtualized environment, from how to test an application to how to plan for disaster recovery.

Under what circumstances should an application not be put on a virtualized server?

One of the first baselines we establish is how CPU-intensive an application is. If an application has a sustained CPU requirement for a long period of time, then it's a physical server candidate. So if we see 80% CPU utilization for an hour, that would tell us that VMware [server virtualization software from EMC business unit VMware] as a whole wouldn't be good for that application, that the application is going to require a dedicated CPU. [While Marrazzo evaluates applications for use on virtualized servers, the decision to move to a virtualized environment was made by Praxair's infrastructure group.] When we think about virtualization, we talk about 'blip' applications - applications that see the CPU go up to 100%, then come down to 20% to 60% at full utilization. Those are good for a centralized computing environment where we can manage virtual instances.

Are you setting a baseline for every application, or only select ones?

Any application that comes in [for processing] today is tested. We monitor the CPU and then determine if we need to move it off or not. Excellent candidates are applications for print servers and terminal servers. Also new applications, like our job scheduler, are being brought into VMware.

How does that job-scheduling application run in a virtualized environment and how has it benefited Praxair?

We have been using the job scheduler [from Tidal Software] to run the whole ERP application [from J.D. Edwards]. We selected Tidal because we saw it could run in VMware, and that meant we didn't have to buy new hardware, and because it fits into our disaster-recovery process very nicely - you definitely need a disaster-recovery solution for enterprise scheduling. We physically split Tidal on two separate VMware instances, [each of those running on servers at disparate data centers]. That gives us disaster recovery and isolation.

In the past, we were decentralized from a scheduling perspective. We'd run a job on this system and one on that system, and we couldn't have interdependencies within those jobs. All the jobs were scheduled in their environment without visibility to the outside systems. With Tidal, we get streamlined job scheduling, manageability and a centralized, enterprise view of all the production applications.