Virtualizing SharePoint with VMware

Installing your SharePoint servers on VMware with Virtual Machines (VMs) gives you a lot of flexibility when performing site enhancements, migrations and global site modifications.   It can save you a significant amount of hardware cost and configuration time when installing a new SharePoint Farm or migrating an existing SharePoint Farm to 2010.

Simple SharePoint Farm. For a simple Front End SharePoint/Search Server and Back End/SQL Server you can store the VMs on the same ESX host and not reduce your fault tolerance.  If the Front End server is public-facing, it’s still easy to place that VM in a DMZ or isolated network and dedicate a network interface card (NIC) on the host for that VM.  Even if the SharePoint Servers were installed on physical computers, the Front End Server is not usable without the Back End Server and vice versa.  So instead of purchasing two physical servers, you can virtualize your SharePoint servers on a single server and save a significant amount on hardware, cooling and electrical costs without any reduction in fault tolerance.

Migration.  If you’re considering an upgrade to SharePoint 2010 from a previous version of SharePoint, virtualization can significantly help with the migration process.  Unless you installed SharePoint 2007 within the last two years, you’re probably running Windows Server 2003 as the host OS.  As you know, SharePoint 2010 requires Windows Server 2008 x64 or later and is best supported running SQL Server 2008 R2 x64.  For most installations to run on the ideal platform this means you’re facing an OS upgrade and SQL Server upgrade in addition to the SharePoint upgrade.

Many of you will run the Database Attach upgrade migration method.  This method essentially requires you to bring up a new SharePoint 2010 server farm, detach the databases from SharePoint 2007 and then migrate the site using the SharePoint 2010 Management Shell to upgrade the databases.  For most SharePoint migrations, you’ll probably have to repeat this process several times before you complete a successful migration.  By utilizing VMware’s Snapshot technology you can take a snapshot of your front and back end servers before the migration, test the snapshot and if necessary, revert back to it to correct any errors.  This can save a significant amount of time because you’ll probably have to repeat the migration process several times before it’s successful.  Because you’re probably moving a significant amount of data during the migration, make sure you have adequate room on your ESX Host Storage Group to handle the Snapshot delta files that are created while the snapshot is active. 

Parallel SharePoint Sites.  As you know, there are significant improvements in SharePoint 2010 compared to previous versions.  To take advantage of these improvements a significant re-write of the site may be necessary.  This isn’t necessarily a bad thing, because some of the interfaces probably needed a refresh anyway.  One approach to SharePoint migration is to setup a parallel site in SharePoint 2010 and re-write and migrate the sub-sites one at a time.  You can setup a new Windows 2008 R2 Server that is fully patched in less than 15 minutes on ESX by simply cloning an existing base image, or creating a new machine from a template.  Virtualization simplifies running parallel SharePoint sites because you can often run the new SharePoint site on the same ESX host as long as you have adequate memory, storage and CPU and network bandwidth capacity on the ESX host.  Without virtualization you probably have to purchase two new physical servers to utilize this upgrade approach. 

Memory Over Commitment and Consolidation of Identical Memory Pools.  During the migration/upgrade process you may need to bring up a new SharePoint Farm while the existing farm is still running.  The memory over commitment feature in ESX allows the memory requirements of the VMs to exceed the amount of physical memory on the ESX host.  For the best performance it’s not a good idea to get too aggressive with this feature, but it is a useful feature during the SharePoint migration process.  ESX can also consolidate identical memory pools on VMs.  If a group of VMs are running the same OS, VMware will consolidate identical areas of memory and create pointers to this shared area of memory.  The net effect of this consolidation is a gain of available memory on the ESX host.  For example, if you had four VMs that required 4GB of memory running the same OS on the same ESX host, you will see the memory spike to 16GB when the VMs were started.  After approximately 15 minutes, the memory utilization would drop to roughly 14.5GB on the ESX host due to the consolidation of identical memory pools on the ESX host.  To really leverage this feature, run the same OS for all of the VMs running on a given ESX host. 

Paravirtualized SCSI (PVSCSI) Driver.  If you’re running on a SAN, and your SharePoint Server has high disk I/O and CPU utilization, consider using the PVSCSI driver on the SharePoint VM (as well as other VMs).  You should get approximately 12% better throughput with lower CPU utilization on the ESX host.  The PVSCSI driver was introduced with vSphere 4.0 and is only supported with Windows Server 2003 and 2008.  Both Fibre Channel and iSCSI SANs can benefit from the PVSCI driver.  You’ll experience the largest gains on heavily loaded SANs with I/O per second (IOPS) greater than 2000 because the PVSCSI driver consolidates or coalesces disk requests from the SAN.

Site Recover Manager (SRM) for Disaster Recovery. If you’re concerned about disaster recovery of your SharePoint VMs as well as your entire virtualization infrastructure, you can implement SRM to plan, test and failover to your remote Disaster Recovery (DR) site.  SRM leverages the remote replication feature of your Storage Area Network (SAN).  Testing the DR plan is one of the major challenges of DR.  Typically it’s not performed often enough or sometimes not at all.  SRM allows you to perform a non-disruptive failover test to your remote site and revise and fine-tune your DR plan as necessary.  IP addresses of the VMs in the remote site can be automatically reconfigured with IP addresses that match the IP scheme of the remote DR site.  The failover plan can be executed from a single click, and can launch user-defined scripts during the recovery process.  SRM can automate a series of complex manual steps which simplifies the failover process.  SRM can even assist with the failback process which can be as complicated as the original failover process.

SharePoint 2010 has some really great features, but upgrading from an existing site can be a significant undertaking.  Running SharePoint farms on VMs simplifies and streamlines the task of creating, migrating and running parallel SharePoint sites on VMware.  If you’re running on a SAN consider using the PVSCSI Driver for the best VM performance and the SRM to test and automate your DR failover process.