A Virtual Coup: The Server Room of the Future

The server requirements of any modern hospital are daunting; the back-end processing power necessary to operate multiple health information systems across an enterprise of any size requires an ever-shifting configuration of blades, proxies, failover systems, and disaster-recovery solutions. It’s no wonder, then, that a five-hospital system with 2,000 beds and 120 radiologists working on a common PACS has turned to a cutting-edge alternative. According to OhioHealth Information Services, Columbus, the server room of the future may not be a room at all. In 2005, Brian Pace, technical architect for OhioHealth, was looking for a cost-effective way to implement the bevy of new software solutions for which his hospital’s staff was clamoring—and to facilitate a new, comprehensive business-continuity and disaster-recovery strategy. Late that year, OhioHealth first began to consider moving some of its servers to a virtualized environment—including the servers for its Synapse® PACS solution from FUJIFILM Medical Systems USA Inc, Stamford, Conn. “When we started to work on it in late 2005, there was some exposure to the idea of virtualization, but not a tremendous amount of acceptance,” Pace says, “but OhioHealth is very forward thinking, from an IT standpoint. We get on the cutting edge pretty quickly."
A traditional PACS server deployment could grow to as many as 20 servers; in the virtual enviroment, fewer physical devices are needed to produce the same results A traditional PACS server deployment could grow to as many as 20 servers; in the virtual enviroment, fewer physical devices are needed to produce the same results OhioHealth decided to start with mission-critical servers, including some of its PACS servers; the organization turned to VMWare Inc, Palo Alto, Calif, for the technology necessary to bring the selected servers into the virtual environment. The process began in mid-2006 with VMWare's ESX Server 2 solution, which the organization used to virtualize HP Blade physical servers, initially running 60 virtual machines on four physical hosts. Less than three years later, OhioHealth has now converted approximately two thirds of its servers to the virtual environment. The virtual machines used in this virtualization model are tightly isolated software containers that behave exactly like physical computers and contain their own software-based CPU, RAM hard disk, and network interface cards. Multiple virtual machines can share the hardware of any x86 computer—in this case, a server—but remain completely separate from one another. “We had limited disaster recovery for a lot of our systems, including PACS, so this really gave us a lot of flexibility,” Pace recalls. “We’re converting our physical machines to virtual machines and our physical hosts to virtual hosts, creating a low-budget, physical-server disaster-recovery solution.” The virtual-server copy of that physical server is synced nightly, so backup is never more than 24 hours behind. “The PACS servers are on replicated real-time storage, so we can simply bring those up at our disaster recovery site,” Pace says. “We have a replication process where we can replicate specific virtual machines from one site to the other on a daily basis.” After moving to ESX 3, the next version of the VMWare virtualization solution, OhioHealth was able to expand the virtualization further; today, around 500 of its servers are virtualized, running on just over 30 hosts. “The upgraded product could handle more virtual machines, allowing us to do more memory on each,” Pace says. “We weren’t limited as much to a certain type of server. It’s our mindset that there are very few servers that couldn’t be turned into a virtual machine.”

Tips to Ease the Virtual Transition

First, take it slowly. Rather than attempting to virtualize everything at once, opt for a phased approach. Second, get the right training. Some virtual vendors offer online or onsite courses; take advantage of them. Third, check compatibility. Vendors usually offer compatibility matrices that can help you ensure that your hardware is optimal for a virtualized environment. Fourth, get third-party vendors involved. Working with them as you move into the virtual environment facilitates seamless integration of all your applications, from billing systems to RIS and PACS. Fifth, collaborate with other institutions. Hospitals already using the system have learned its ins and outs the hard way and can pass on valuable information (one such tip: virtual servers perform better with a single processor).

Though Pace is still hesitant to take the leap into large clustered databases, he says it’s a possibility in the future. “We could prove that a large database could be run on a VMWare environment, but that doesn’t mean that we should,” he notes. “In those cases, we tend to default to physical servers, but there is starting to be a movement to accept virtual servers.” OhioHealth, however, has not hesitated to virtualize in other areas. “Around 30% of our servers are currently virtualized,” Pace says. “Right now, when an organization within OhioHealth needs a new server, it is (by default) a virtualized server, unless there’s a compelling reason it can’t be.” In the coming year, he hopes to virtualize another 200 servers. Today, all of OhioHealth’s hospital information system (HIS) servers, 18 of its PACS servers and many of its DICOM servers are virtualized. For three months, the organization ran all of its HIS servers virtually on hardware at the disaster-recovery site—an example of the numerous operational efficiencies to be achieved by using a virtualized environment as a business-continuity solution. “The primary reason is disaster recovery,” Pace says. “When that’s on replicated storage, if we lose any part of the facility, we’ll be able to fail over to our second site and run it from there. We have a lot of built-in redundancy in our ESX environment. At our primary site, we could lose up to a third of our ESX hosts and continue to run.”

Emerging Features of Synapse PACS Virtualization

Available with the next Synapse release, these features will include: the ability to deploy a development environment at the customer site for validating new versions, features, and integration with third-party technologies: this can be used by the radiology department for testing applications and technologies used in conjunction with Synapse or radiology practices; the ability to deploy a mock production system that will assist in advanced testing and implementation related to upgrades; intuitive performance adjustment and resource allocation: the system will be able to make resource and performance changes in order to ensure that the most optimal solution and load balancing are available; bidirectional failover, allowing for fully automated failover from the primary location to the secondary location and vice versa; the ability to add and remove resources (memory/RAM): the need to reboot a virtual session after adjusting memory resources will not be required; physical hardware alarms: when an issue occurs with the physical host of the Synapse virtual architecture, the system will generate alarms for that failover and allow for the environment to migrate itself to a better location; and the ability to track changes made within the virtual environment: this will allow for more detailed auditing and faster issue resolution.

Cost is another major benefit. “The virtualized environment costs us around $1,000 per machine, while a physical machine could cost between $4,500 and $6,500,” Pace says. “The cost justification is pretty easy to make.” Because OhioHealth doesn’t operate on a chargeback model, “We can’t charge the PACS team for virtual-machine usage, meaning the cost to the various hospital departments can be as little as zero,” Pace says. That makes it a little easier to ask the departments to contribute to purchasing the hardware necessary to make the virtualized environment more robust.
OhioHealth¹s Riverside Methodist Hospital campus, Columbus, Ohio. Server consolidation also reduces the tangential costs associated with physical server rooms, including power, air conditioning, and space requirements. The cost of using a VMWare virtual server on a typical blade is just $1,000, while the cost of running a similar configuration on a physical server could be as high as $15,000. With administrators and staff alike delighted at the lower costs and more robust backup capabilities of the virtualized environment, Pace sees no need to slow down; in 2009, he expects to see the environment continue to grow exponentially. “We’re going to push harder for this type of server,” he says. “It will be harder to get a physical server, as we go forward." Currently, all PACS servers, except for large database clusters, are virtualized, but that will eventually change, according to Pace. He says, "We’re going to attempt to virtualize larger, tier-1 applications—more of the larger databases. That will strictly be a matter of economics.” The next step is virtual desktops. OhioHealth currently has around 8,000 desktops on three-year leases. “We’re replacing some of them each month,” Pace says. “We currently have virtual-desktop remote access in place, so all our physicians and caregivers can access all our applications remotely.” The desktop end of OhioHealth's PACS is included in this initiative; this enables referring physicians to read reports and view images using the Synapse client, resulting in better customer service and increased referrals.

Emerging VMWare Virtualization Features

These include: bidirectional autofailover, which will allow for automated failover of the virtual environment in a bidirectional fashion; the ability to configure virtual machines with up to eight CPUs and 256 gigabits of RAM; access-control configuration on storage resources; and full support for SATA local storage.

Pace’s team is also launching a pilot to replace physical desktops with a thin client running a virtual desktop back end. “If it goes well, I can see us pushing a thousand of those this year alone,” he says. This could translate to even more cost efficiencies. According to Pace, “It’s hard to support a physical desktop, but easy to support it virtualized" because users cannot load third-party applications on a virtual replica of OhioHealth's hardware. So far, around 50 of OhioHealth’s desktop applications are operating in the virtual environment. Notable holdouts include advanced visualization software. “The virtual desktop environment is not conducive to advanced graphics environments,” Pace says, “so we’re still in the experimental stage on that.” Nonetheless, with anybody in OhioHealth’s extensive network—from clinicians to the physician community at large—able to run virtualized desktops on virtualized servers, Pace is still managing to keep himself busy. “I would suspect that our virtualized environment will see anywhere between 30% and 50% growth this year,” he says. While some vendors have yet to provide support for their applications if they’re being run in a virtualized environment, one reason that OhioHealth brought many of its PACS servers onboard so early in the process was cooperation from the vendor. Having the buy in of a vendor is crucial, Pace says, for getting the application to run on the virtualized system smoothly and efficiently. That’s been OhioHealth’s experience with FUJIFILM, which today boasts special features for Synapse PACS virtualization, including the ability to deploy a development environment at the customer site, the capability of tracking changes within the virtual environment, and more. With the release of the next version of the PACS, even more features for the virtualized environment will become available. “We were talking with Fuji about certifying early on so that we could make the move,” Pace says. “We’ve worked with other vendors to get certification so that we can get the support we need for virtualization.”