Introduction
Virtualizing Microsoft’s Tier 1 applications used to be incredibly difficult. The company wouldn’t support the efforts and the software itself was not always friendly towards virtualized environments. How times have changed!
Everywhere you turn, what used to be “unvirtualizable” applications are now being moved into well-constructed virtual environments. In particular, there has been a lot of press around what needs to be done to virtualize some of Microsoft’s Tier 1 applications, including Exchange Server, SQL Server and SharePoint, among others. In this article, I am going to discuss what we are doing at Westminster College to move some of these applications into our VMware vSphere-hosted virtual infrastructure.
To get started, I will tell you that, depending on product, we are at different stages of our virtual migration:
- Windows Server – It stands to reason that Windows Server itself has to be able to be virtualized before anything else can be done. Windows servers have been undergoing virtualization for a really long time now.
- SQL Server 2008 – We have already deployed a SQL Server instance under VMware. Specifically, we have deployed a virtual SQL server to handle some new reporting tasks that we wanted to undertake. The new virtual SQL system also supports a couple of small production databases. Eventually, we will move all of our SQL workloads to virtual machines.
- Exchange Server 2010 – We have built our initial Exchange 2010-based virtual infrastructure under VMware vSphere and plan to migrate our current Exchange 2007 mailboxes to the new servers very soon.
- SharePoint 2010 – We are currently running SharePoint 2007 for both our public-facing web site as well as to handle some intranet-based tasks. Our goal is to begin SharePoint 2010 planning as soon as possible in order to begin taking advantage of the significant enhancements that have been made to the product, particularly in the realm of business intelligence. Since we are still a few weeks away from our SharePoint 2010 virtualization project, I will not be discussing this product in this article, but will do so in a future one.
General Planning
If you are attempting to virtualize Microsoft’s major applications, you should make sure to understand Microsoft’s virtualization support limitations and any licensing implications inherent in the undertaking. If you ignore the company’s guidance, you could find yourself unable to get support or, worse, on the wrong end of a software audit.
I am not going to try to go over each and every possible licensing scenario in this document. There are simply too many variations on a per product-basis. I will, however, provide some general licensing information.
Hypervisor support policies
Microsoft knowledge base article 957006, entitled Microsoft server software and supported virtualization environments, provides specific information related to supportability for virtualized Microsoft software. The first item of note revolves around what virtualization platforms Microsoft will support for their server-based applications. It is no surprise that the company supports Hyper-V, but Microsoft definitely realizes that there are a lot of other options out there when it comes to the underlying hypervisor. For non-Microsoft virtualization platforms, Microsoft has launched what they call the Windows Server Virtualization Validation Program (SVVP). SVVP provides a standard method by which Microsoft validates the underlying platform to ensure that their software will run well enough to be considered supportable when customers call in with troubles.
Step 1 in your “virtualize everything” endeavor consists of making sure that your hypervisor – both the product and the version – are supported by Microsoft.
Virtualized Application Support
Your next step is to make sure that the Microsoft application you intend to virtualize is supported by Microsoft in a virtual environment. Although many of the company’s products work just fine in their virtual containers, there are some that the company would not support. For example, if you are planning to deploy a supplemental Exchange 2003 server, you will need physical hardware to stay within support guidelines. Virtual Exchange servers are supported only for Exchange Server 2007 SP1 or later; we will be talking more about Exchange later in this article.
Knowledgebase article 957006 provides general guidance only for virtualized application support. Use that article as a starting point, but not as a sole information source.
Non-Compliance
Obviously, organizations do not have to adhere to Microsoft’s support policies as they relate to virtualization, but failure to do so has support implications. If you’re running a non-compliant system, support may require that you first bring the environment into compliance before providing assistance for a problem.
Windows Server
What is there to say about Windows Server licensing that hasn’t been said for years? Solving Windows server sprawl is one of the biggest reasons that virtualization has such significant ROI. As such, I’m not going to spend a lot of time talking about Windows Server here except to talk about licensing.
Microsoft provides attractive virtualization benefits in the Enterprise and Datacenter editions of Windows Server. For each server licensed under an Enterprise license, you’re entitled to run up to four virtual machine instances (with Windows server on each) on that system without having to pay any additional licensing fees. With the Data Center edition, you’re allowed unlimited virtual Windows instances.
These licensing benefits apply even if you’re running a non-Microsoft hypervisor such as vSphere. Where I work, I’ve purchased processor-based Windows Server Data Center licenses under our campus agreement and applied these licenses to our VMware vSphere hosts. Now, I no longer need to license the individual Windows instances running on virtual machines.
SQL Server 2008/2008 R2
In many cases, SQL Server can be virtualized just like any other workload. Obviously, if you are running a massive physical box with a dozen quad-core processors, 96 GB of RAM and a full SAN dedicated to SQL, it would be tough to replicate that workload in a virtual environment, which leads to an important point. Make sure your workload can operate within the confines of your virtual environment. Further, make sure that you do not cut corners on architecture design just because you are going virtual. Disk layout, RAM and processing power still matter!
For a whole lot of information about SQL Server performance in a virtual environment, read this VMware-provided white paper that discusses the issue in depth.
For a little over a year now, I have run a couple of SQL Server 2008 servers under VMware ESX in a production capacity. Each virtual machine is sized to accommodate the need, both from a disk capacity standpoint as well as RAM (2 GB each, which is sufficient for the workload). These SQL servers are currently handling only reporting tasks, but we’re actively planning a migration from our physical SQL servers to ones of the virtual variety.
We also have one legacy SQL Server 7 system still in production. About two years ago, we performed a physical to virtual migration using a product from Platespin (now owned by Novell) that basically grabs a physical machine and copies everything to a virtual one. We’re fully aware that SQL Server 2000 is not supported in a virtual environment. Heck, SQL Server 2000 is not supported at all anymore, but we have one legacy application that relies on this system and the physical server was on its last legs, hence the migration to a virtual environment. We are almost to a point at which we will be able to retire this system but in the meantime, moving this application to our virtual environment made a lot of sense and, while not adhering to Microsoft’s support policies, provided us with a way to keep the service operating while we work on decommissioning it.
For us, our SQL virtualization strategy so far has worked extremely well. We’ve been relatively careful about pushing the envelope with regard to SQL Server, particularly since it supports critical operational workloads.
SQL Server Licensing
When licensing SQL Server on a per socket basis, there are some things to keep in mind. Beyond the core feature set, there are some real benefits to purchasing the Enterprise edition of SQL Server 2008:
- SQL Server 2008 Standard – 1 VM per processor license. Can’t exceed per-processor licensing limitations.
- SQL Server 2008 Enterprise – Unlimited VM’s per license as long as all physical processor sockets are licensed.
With SQL Server 2008 R2 Microsoft has added a Datacenter edition to the product lineup and synchronized the processor-based virtualization licensing with that of the Windows Server product line:
- SQL Server 2008 R2 Standard – 1 VM per license
- SQL Server 2008 R2 Enterprise – 4 VM’s per license
- SQL Server 2008 R2 Data Center – Unlimited VM’s per license
Exchange Server 2010
Behind only Windows itself, I think it’s safe to say that Exchange has piqued the most interest with regard to virtualization and Microsoft has made massive steps toward making Exchange eminently virtualizable.With massive reductions in IOPS needs finally bringing Exchange’s resource requirements more in line, storage performance is no longer a major issue with the software. From a virtualization standpoint, the biggest challenge in virtualizing Exchange is its RAM-hungry nature. By design, Exchange servers will eat up all the RAM you give them.
Microsoft is pretty specific about what kinds of availability features are and are not supported in a virtual environment. They also dictate some other limits. Here is a look at some of the key considerations to make when you consider going this route:
General
- Exchange 2010 supports a 2:1 virtual:physical processor ratio. On hosts holding Exchange virtual machines, you can have no more two times the physical core count in virtual processors across all hosted virtual machines. This can certainly significantly limit virtual machine density.
Roles
- The Unified Messaging role is not supported in a virtual environment. If you need Unified Messaging, you’ll need to install this role to a physical machine.
- All other Exchange 2010 roles are supported.
Storage
- Dynamically expanding virtual disks are not supported.
- Differencing disks are not supported.
- Believe it or not, Microsoft does support VM-based Exchange servers using an iSCSI initiator from within the virtual machine to access storage, but this is not a recommended configuration due to reduced performance. It’s recommended to stay with the hypervisor’s iSCSI connection mechanisms.
- Network Attached Storage (file level) is never supported , no matter how it’s presented.
Availability
- Database Availability Groups (DAGs) cannot be used in conjunction with hypervisor tools that enable high availability, or migration solutions that will mailbox servers to different hosts. Exchange DAG member virtual machines need to be configured to not participate in these kinds of availability groups.
- Because snapshots are not application-aware and could result in unintended behavior, you cannot take snapshots of Exchange virtual machines.
For a complete list of requirements, look here.
We have deployed just two Exchange 2010 servers for our rollout at Westminster College. One server will house mailboxes and also holds the client access servers and hub transport roles. The second server also holds the client access server and hub transport roles. The CAS roles used network load balancing. We’ve opted against the use of DAGs for now. We are storing our mailboxes on RAID 10-based storage and we continue to take regular backups. We’re a small place, though. We have less than 200 constantly accessed mailboxes, but once students are counted, that number grows to more than 1,500 mailboxes. Our students, however, aren’t on the system all day long, so their I/O impact is minimal; they mainly consume disk space, which we have in abundance. As such, we’re comfortable that our two virtual machine approach will work well for us.
From a VM RAM standpoint, we’re starting on the low end and will add RAM as is becomes necessary to do so. For now, each of our Exchange VMs has 8GB, but I do expect that number to grow a bit.
Summary
This article was intended to act as a primer for our efforts at Westminster College to virtualize our tier 1 Microsoft applications. As we continue our efforts, I will be reporting back!
