Servers

Making the choice between virtual and physical servers

"Virtualize everything" is a popular M.O. in IT these days, but there are times when physical servers make more sense. Scott Lowe shares his thoughts on the issue.

"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.

Want to keep up with Scott Lowe's posts on TechRepublic?

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

25 comments
blackepyon01
blackepyon01

What happens when the internet slows down? Or when it just IS down? Now the whole office is off work.

bathawes
bathawes

We didn't want to take the risk in a medium scale MOSS farm - physical is "tried and tested" after all. We opted for x64 SQL Server 2008 on Windows Server 2008 on a rather beefy physical box. if you are interested more detail over at http://mossblogger.blogspot.com/.

Cary W FitzGerald
Cary W FitzGerald

What I didn't understand from this posting is what the characteristics of the application cause you to choose physical servers versus virtualization. I presume that Westminster College deploys some mission critical applications using virtualization. What about UM/OCS/SQL distinguishes them from these other applications?

reisen55
reisen55

A consultant I work with skilled in Business Continuity and Disaster work - we survived that little thing called World Trade Center together - noticed that if a server supporting six virtual servers should have a hardware POOF DEAD failure, then six servers cease to exist. I recommend MISSION CRITICAL SERVERS as being set in the traditional model and ONLY redundant or secondary servers be set as VIRTUAL. Second, TEST RESTORATION AT A DISASTER RECOVERY SITE in case you have to reassemble everything.

wmjas.shaw
wmjas.shaw

We ran into another snag with virtual servers last year: Microsoft would not "officially" support many of their products (including SharePoint 2007) in a virtual environment. It was strongly recommended that SharePoint be deployed on physical servers for production.

bulk
bulk

"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." Interesting, but just a bald statement. I'd very much like to understand the reasoning behind this decision. RS

VBJackson
VBJackson

Last year my company virtualized our LOB system. The host server runs Windows 2008 Core and HyperVisor. There are 3 guest machines, a Windows 2003 file/print server that we converted from physical, and 2 Windows 2008 servers. One of the 2008 instances runs IIS, while the other runs SQL Server 2005. I haven't run into any problems with SQL Server, and since the web application on the other guest machine generates 85% of all the queries network utilization has gone down significatly. On the other hand, we use MS Small Business Server. The virtualization project was a part of a network overhaul that included upgrading to SBS 2008, and we decided against running that on a virtual host, due to concerns with having Exchange, DS Services and Authentication services running under a VM.

Richard Noel
Richard Noel

Scott, Thank you for this article. It delivers some good food for thought. Are you storing your video on the SAN or using internal storage? Also, is it running on it's own VLAN?

nonimportantname
nonimportantname

In general should be reserved for the physical domain, IMO. This fear of mine might also be unfounded, as directory replication between PDC/BDC, KDC/TGS authentication and ticketing services, etc. can all be carried out just the same as it would be in a virtual environment. But virtual services DO rely on a physical host after all and if that physical host is not part of the domain created by its virtual guest, it can be confusing and hard to manage. On the flip side, having the host become a member of a domain that is administered by a virtual guest also seems kind of complex...or fluky. Like I said, this is just a fear of mine: like you said, any real-time services should be reserved for the physical realm. Depending on your infrastructure and product, DS just seems too critical to hand over to a virtual environment.

eclypse
eclypse

That seems like the big one to me...

eclypse
eclypse

We have found that this depends completely on the type of virtual environment you have available. In 2001, IIRC, VMware did not have Vmotion, or any of their DRS/HA offerings. IBM only recently came out with their "live partition mobility" and I've never used Citrix, so I'm not sure what all options you have there, but in 2001, there were nowhere near the number of options that there are today. What limits us tends to be IO performance (or lack thereof). Anything else runs pretty well on virtual servers. For most of our apps, this isn't an issue, but IMHO, virtualization makes apps more robust, more highly available, and more quickly recoverable in the event of a hardware failure because you can easily move between physical servers. Makes maintenance easier, hardware replacement easier, etc., etc.

satmanduo
satmanduo

If you are running your environment PROPERLY, you would have HA (high availability) setting turned on and after a physical box goes "Poof" the servers will power on at the opposite ESX box! If you work with a skilled DR person, they should know that! I currently Manage 120 Virtual machines spread across 4 phsyical boxes and also support 160 other physical boxes... 110 of them are moving to virtual in 2010! VMWare virtualization, not that phoney MS one..

dwdino
dwdino

...before deploying multiple virtual infrastructures for DOD, medical, DOE, and oil companies that are 100% virtualized. The only physical boxes in these instances are the phone systems and ESX hosts. Domain controllers, vCenter, MSSQL, SharePoint, SAP, Remedy, etc., all virtual.

TexasJetter
TexasJetter

Your right, if you virtualized 6 servers and the one physical machine goes down so do the 6 servers. By the same token, if you recover one physical server (assuming the hardware failure is not hard disk, which should be redundant anyway) then you recover 6 servers. Lets just say a power spike blew thru my UPSs and fried my power supply. If I had 6 physical servers I would have to troubleshoot and replace 6 devices. If they were all virtualized I would only have to trouble shoot/repair one machine to get 6 back up. It just goes to show you that disaster recovery is a complex study, and after all the time and money spent something will happen you did not plan for...

Jamsan
Jamsan

Have you heard of things like vMotion, SAN replication to alternate sites, site recovery manager and so on? Are you telling me that you and your "consultant" friend who is "skilled" in BC and DR haven't heard of any of these capibilities and really think if a physical server goes down, there's no way to quickly recover the virtual servers running on them? Let me know what company you guys work with so I know never to recommend you.

mredgar2005
mredgar2005

I have 9 total servers running in my server room, on VMware ESX. The only server that is physical (obviously besides the vm hosts) is the Domain Controller. I have a 2nd Domain Controller running virtualized just in case the physical is down or needs a restart. This works amazingly well.

paul.simmons
paul.simmons

We work with some Access databases and SQL. I time stamp jobs. Some take 5 times as long on the virtual server. They run but very slowly. Is that running just fine? As you know going from 1/50 of a second response to 1/10 second response will not be noticed by a user but going from 10 minutes to 50 minutes will be. Perhaps some implementations are better than others.

Scott Lowe
Scott Lowe

The video server does not have its own VLAN and is using all DAS for storage. I couldn't easily justify the additional SAN expenditure for the kinds of storage needs this system had. We actually bought a refurbished DAS device at a very low cost.

CG IT
CG IT

which is better? The answer depends on what you want to do. If you don't want a bunch of boxes to manage, along with the A/C costs, eletrical costs, maintenance costs, VM is the way to go. But like others have mentioned, to provide redundancy and failover, you have to have other servers or assets. Sometimes the redundancy requirement makes the cost savings of VM a wash. Then you have to ask yourself the question, what is better VM or a box? If the box dies, how easy is it to get going? If the box dies and has VM on it, like another poster mentions, if you recover that, how many servers are you recovering? 1 box, 6 servers = recovery 1 box = 6 servers. If you have 1 box and it dies and you got 5 other boxes and they don't die what's better? How much $$ does the company lose if one VM box goes down and 6 servers are gone? Does the cost of VM redundancy make it prohibited? All these question you have to answer with hard data before you decide if VM is the way to go. What comes first chicken or Egg?

chris.jackson
chris.jackson

Microsoft provide a very long list of services they believe will work in a virtual environment including Exchange and SQL but one they leave out is an AD server. We have a client with 160+ virtual AD servers in a large forest and do not see any problems under the virtualisation but as soon as we had a (physical) Exchange issue Microsoft would not progress the query while they believed we still had virtual DCs. As long as you can make sure your roles are split across physical (ESX) hosts and you can manage the order things come up in I do not see any problems.

madmucho
madmucho

Multicore procesors SAN storage SAS disks.... Everithing can be virtualized exchange 2007 sql servers everithing, if you have problems with preformance your planing project of this virt env is bad, plan your raids storage for quest os, plan your RAM usage. We are runing VMWare ESXi enviroment with third party backup solution boot from sun, PXE or on disk array. When disaster recovery comes you need only new Metal on which you boot your Hyperwisor, no drivers hell only copy quest and run. Future is about virtualization.

nonimportantname
nonimportantname

That most people have already taken the plunge, with success, with regard to virtualizing directory services. Maybe we will be okay after all: we're going to be virtualizing our PDC/BDC soon. The only thing I don't like is that my company is MARRIED to Hyper-V, and I would much rather be running VMWare ESX in our environment for obvious reasons.

blarman
blarman

There is a time and place for virtualization, but it isn't suitable for all instances. The point made is that if you lose the physical hardware, you lose all the virtual instances on that hardware. And, no, unless you have stored copies of the virtualized instances somewhere else, you can't get them back. It's like having all the LUN's on your storage device die because the controller freaks out. You are hosed. If you virtualize, make sure that you have copies of each virtualized environment on a separate physical server so that disaster recovery is an option.

eclypse
eclypse

Hopefully, you have one or more SVCs (or equivalent) and more than one storage subsystem behind it/them.

Jamsan
Jamsan

What's the difference between your scenario and 5 different physical servers using the SAN to store all of it's data and the all the LUN's die because of the controller freak out?

Editor's Picks