SQL Server Magazine

Web Abstract:

A simple SharePoint configuration of two servers is an ideal candidate for server virtualization. A setup of one Microsoft IIS Server system running SharePoint as the Web front end and one server running Microsoft SQL Server as the database back end, especially if you don't anticipate heavy usage, can be virtualized using Microsoft Virtual Server 2005 or VMware Server (both free products), or VMware ESX Server, and run on one physical server. Sound intriguing? Let's take a look at why you would want to do such thing, and then consider what you'll need to do to successfully implement server virtualization of your SharePoint setup.

Benefits of Virtualizing a SharePoint Server 2007 Farm
You'll find several benefits in virtualizing a simple Microsoft Office SharePoint Server 2007 server farm. These range from increased security, to better performance, to lower costs.

Increased security. Virtualizing servers can help increase security, especially if your SharePoint 2007 server is accessed from the Internet. As you know, SharePoint Server 2007 data is typically stored on a SQL Server back-end database. If both applications are installed on a single server, the database server is also exposed to the Internet. However, if the servers are virtualized, only the SharePoint Server 2007 front-end server is exposed to the Internet, protecting the database on a separate virtual server not exposed to the Internet.

No loss of fault tolerance. Running two virtual server guests on the host server won't reduce your fault tolerance. This is because the SharePoint Server 2007 server won't work without the database back end and vice versa. In other words, if you lose either the SharePoint Server 2007 front-end server or the back-end database server, the portal will go down. Easier bare-metal restores. The virtual server guest configuration and logical disks are stored as files on the virtual server host. Backing up these files is essentially the same as performing a bare-metal backup of the virtual server guests. Moving the virtual server guest to a different host simply means copying files to a different host and starting the virtual server guest on the host server. You can replicate virtual server guest files to a remote disaster recovery site by using third-party server replication applications such as Neverfail's products or by using Distributed File System Replication (DFSR), which is an integral part of Windows Server 2003 R2. This greatly simplifies the recovery of the SharePoint Server 2007 server farm.

Faster setup time. If you create a base image of the virtual server guest, you can significantly reduce the time it takes to bring up a new virtual server guest to 15 minutes or less, compared to two or more hours to bring up a new physical server.

Reduced costs. It's usually less expensive to purchase a large host server instead of two dedicated smaller servers. Hardware maintenance costs are also potentially reduced, and fewer servers means lower electric and cooling bills.

The 32- or 64-Bit Question
If you decide you'd like to try server virtualization, there's one thing you need to consider before you even select your virtualization software platform—you must decide whether to use the 32- or 64-bit versions of SharePoint Server 2007 and SQL Server 2005. If your hardware supports the x64 version of Windows Server 2003 R2 as a virtual server guest, I strongly suggest using the 64-bit versions of SharePoint Server 2007 and SQL Server 2005. SQL Server 2005 and SharePoint Server 2007's indexing functions are potentially intensive in terms of memory, disk, and processor use, and using the 64-bit version of these software applications can improve performance. One drawback of using the x64 version of SharePoint is the inability to run iFilters from third-party sources. For example the PDF iFilter doesn't work with the x64 version of Windows SharePoint Services 3.0 and SharePoint Server 2007.

Additionally, running the x64 versions of SharePoint Server 2007 and SQL Server 2005 in a virtual environment does limit your choice of virtual server software because only VMware Server and ESX Server are capable of running x64-based guest servers. Virtual Server 2005 supports 32-bit guests. If you use VMware Server, your server hardware must be capable of running both an x64 version of Windows 2003 as the host software and running x64 virtual server guests.

Even if your server supports x64 virtual server guests, for some processors, such as the Intel model, you'll probably have to enable the support for this feature by going into the server's BIOS, then restarting the host server. In my experience, most servers ship with support for x64 guests disabled by default. If you plan to use VMware Server, you'll need to see whether your server is capable of running x64 guests. (To do so, you can download the Processor Check Utility for 64-Bit Compatibility at http://www.vmware.com/download/server/drivers_tools.html.)

If you plan to use ESX Server, you'll need to go to the VMware site to make sure that your server (and SAN, if applicable) is listed as compatible. ESX Server recently added support for Intel's new quad-core processors. For the best performance of the virtual server guests, use ESX Server as the host OS, because it provides near-native hardware performance, requires less host memory, and can provide as much as 16GB of RAM for a virtual server guest. It's very Linux-like, however, so if you're not familiar with Linux or ESX Server, be prepared for a learning curve.

If you're new to virtualization and the portal won't be used too heavily, consider using VMware Server with Windows Server 2003 R2 x64 as the host OS, because VMware Server is free and you're probably already familiar with the Windows OS. VMware Server also has a wider range of virtual guest OS support than does Virtual Server 2005.

   Prev. page   [1] 2 3     next page