To read the press, and even some of my TechRepublic blogs, you might think that the world of the physical server had come to an end in favor of the virtual counterpart.
It's true that many data centers across the globe have embraced virtualization technology as a way to reduce IT costs, green data centers, increase infrastructure availability and flexibility, and for a whole host of other reasons.
However, the future of the physical server is secure, as there are still a number of reasons to use a physical server over a virtual server. In this post, I'll provide some insight into how we at Westminster College decide between the physical and the virtual when we deploy new servers.
When it's time to deploy a new service or to replace physical hardware at Westminster College, we tend to favor a virtual solution over a physical solution. After all, the process for deploying a new virtual server doesn't have any hard costs associated with it. There is no server to buy; the Windows license is already paid for by virtue of the fact that we've purchased Windows Server Data Center licenses for each of our VMware ESX servers; and our SAN has plenty of storage to handle the new load.
Of course, you could argue that a new virtual server is not "free" and does have costs. I agree; after all, we've sized our VMware ESX servers and SAN with future growth in mind, so there have been hardware costs associated with the virtualization project. However, it's also a simple matter to show the lower cost associated with the overall virtual server vs. a new physical unit.
With the thought in mind that we default to deploying a new virtual server as new services are deployed, there are instances in which we continue to deploy physical servers.
First of all, if we deploy a service that supports real-time communication, such as Exchange 2007 Unified Messaging or Office Communications Server, we continue to deploy these services on physical servers. In fact, our current single-server (physical) Exchange 2007 server will give way to a multi-server Exchange infrastructure when we move to Exchange 2010, with the exception of the Unified Messaging role, which will remain on physical hardware.
All of the other Exchange 2010 roles will run in virtual machines. We're currently deploying Office Communication Server 2007 R2 to meet a number of campus needs. That service will run on a pair of physical servers.
In addition to these kinds of services, we also continue to run our primary database services on physical hardware, which is heavily utilized. We deployed a new physical database server just over a year ago and right before we had all of the services deployed that could adequately and comfortably support this need in a virtual environment.
I admit that I remain skeptical about running a multitude of databases in a virtual environment. The physical solution is extremely stable and, with campus operations relying on these services, I'd be a little hesitant to rip and replace. That said, we do have a couple of SQL servers running virtually, and they're running just fine, so my fears may be completely unfounded.
Within the next few months, we have to begin a migration from SQL Server 2005 to SQL Server 2008. We're considering how to deploy this new version, and we'll be testing a virtual solution while we decide whether to go virtual or physical.
Within the past year, we've also deployed an additional significant physical server. We have a centralized system on campus connected to a number of cameras. These cameras store all of their footage on a server. This system consistently runs at high utilization, high network load, and has major storage needs.
It didn't make sense to deploy this service virtually. Although it's an important system, it's not mission critical. We don't need the availability that can come with a properly configured virtual environment.
Although I'm a huge believer in all-things virtual, there are still times when a good old physical server is exactly what's necessary to meet a need. Before simply deploying a new virtual server, make sure that the need can be met without putting undue strain on the other servers running in your virtual pool.