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.

You mentioned disaster recovery for applications. How does virtualization fit in?

We have two separate data centers in the Northeast. We split the resources between them - the servers and the instances. That's how we isolate the applications. If an application needs disaster recovery, we load balance via two servers and separate it that way. This has saved us in physical capital costs. In a traditional sense of distributed computing, you have to buy two of everything. Now we just buy two VMware servers and virtualize the instances for the disaster-recovery plans.

Do you work with other virtualized IT resources?

We have shared storage that's virtualized, so we have redundancy there. We attached the storage to VMware, but use a separate [storage-area network]. We have direct connections to the storage, so all applications have access to that storage.

What other changes have come from the ability to run enterprise applications in a virtual environment?

Now there's no need to buy a server for every project. We can manage these virtual instances via a console. And on the fly, if there's a problem with the VMware session, we can allocate CPU or memory. Applying patches also is centralized now. At the same time, virtualization reduces our costs of physical devices. In most cases within an enterprise, 60% to 70% of application servers are underutilized.