Virtualizing SharePoint Server 2007 Series - SharePoint server role recommendations for virtualized environments

Article
03/08/2009

Each role in the SharePoint farm have finer nuances that need to be taken into account before deciding whether it is a good candidate for virtualization. This topic highlight some of the key considerations for each role in your farm.

This topic discusses:

Virtualizing the web role
Virtualizing the query role
Virtualizing the index role
Virtualizing other roles
Virtualizing the database role
Other farm considerations

Virtualizing the web front end (WFE) role

The web role’s responsibility in a SharePoint farm is to respond to user requests for pages. This involves fetching content from the SharePoint databases and “look and feel” from the database and file system and then rendering, caching (depending on settings), and returning the page to the user. It is a good candidate for virtualization, as long as SharePoint architects take a few key factors into consideration:

Do not put all your eggs in one basket! Do not host all your WFE’s on the same physical host. Split these virtual machines over a minimum of two physical host machines. This ensures hardware redundancy. If one physical host fails, the remaining web front end server can take over the load.
Dedicate virtual network adaptors and virtual switch to internal and external MOSS farm communication. For example, ensure separate virtual network adaptors are provisioned to enable you to dedicate virtual network adapters to transport different types of traffic.
Consider using hardware load balancing over software load balancing: Hardware load balancing offloads CPU and I/O pressure from the WFE’s to hardware layer thereby improving availability of resources to SharePoint. Examples of Hardware: F5 BIG IP, Citrix Netscaler, Cisco Content Switch. Software load balancing examples are Windows Network load balancing, Round Robin load balancing with DNS. It's a trade-off between cost and performance.

Virtualizing the query role

The query role’s responsibility is to respond to search requests from the web role and secondly to maintain a propagated copy of the index stored on the Query servers local file system. It is a good candidate for virtualization, as long as SharePoint architects take a few key factors into consideration:

For best performance, use fastest disk infrastructure possible: Prefer dedicated physical volumes on underlying SAN infrastructure using the “pass through” disk feature of Hyper V or fixed disk VHDs on that LUN over dynamically expanding virtual hard disks. Performance of a fixed size VHD is practically en par with pass-through disks and has management and backup advantages.
Don’t put your query and index server on the same underlying physical disk: Index server is heavy read write while query server is constantly updating its own copy of the index. Therefore contention to underlying disk will slow read I/O for your query servers in your MOSS Farm.
Combine or split the Web/Query role: SharePoint architects often combine web and query roles. In the virtualized environments this is also a good practice but it largely depends on your environment and performance requirements. Virtualization environments provide the flexibility to split combined web/query role onto separate machines.

Virtualizing the index role

The index role’s responsibility is to maintain an up-to-date index by crawling the index corpus using the configured incremental and full crawl schedules. It then needs to propagate the index to all the query servers. The Index server role in a SharePoint farm is often times the most memory intensive role, making it a less ideal candidate for virtualization if SharePoint already consumes all the memory the physical server has available. This by no means rules it out as a candidate to be virtualized, it simply reduces the advantages that can be gained by virtualizing the server, as more of the host’s resources will need to be dedicated to the task.

To increase index role suitability for virtualization might entail increasing memory the physical host server has available, therefore taking advantage of the consolidation effects with other workloads. Alternatively the virtualized index server could be moved to a larger system to host it side by side with other workloads of the SharePoint farm. In the end this really depends on the available infrastructure as well as the deployment goals of the SharePoint farm.

Crawling recommendation: Use index server to be dedicated crawl server to avoid network hop.
For best performance, use fastest disk infrastructure possible: Prefer dedicated physical volumes on underlying SAN infrastructure using the “pass through” disk feature of Hyper V or fixed disk VHD on that LUN over dynamically expanding virtual hard disks.
Physical or Virtual Machine?: If the environment is small, is a test or dev environment, or does not crawl significant amounts of content, it is perfectly viable to use virtual disk files for the Index role. For very large production SharePoint farms, or for farms that are crawling a significant amount of content, the memory requirements and disk IO activity may prompt SharePoint architects to install the index role on a physical server.

Virtualizing other roles

Other role’s, such as Excel Services, document conversions services are good candidates for virtualization. These roles are similar to the web server role in that, as resource requirements of the individual application increase, additional servers can be added to the farm.

Virtualizing the database role

The database role’s responsibility is store, maintain and return data to the other roles in the farm. This role has the highest amount of disk IO activity and can often have very high memory and processor requirements. Virtualization of SQL Server 2005 and 2008 is supported. Depending on your environment's requirements will determine whether you choos physical or virtual deployment options.

The argument for physical:

SQL Server is already a consolidation layer and will host 7-10 SharePoint databases at a minimum. Recommended content database size is 100 GIG. Some enterprise deployments have 100's of content databases over multiple SQL instances.
Longer response times impacts ALL downstream roles in a SharePoint farm: Virtualization introduces some latency downstream in the application and UI server roles of a MOSS farm. If every SQL request takes longer that impact might be magnified in the application and UI layers, especially considering that multiple roundtrips occur frequently to complete a single transaction.
It will experience heavy CPU, Memory, Disk I/O, and NIC usage. It is importanty to understand that virtualization by itself adds some resource requirements to the system. Which need to be taken into account. Secondly the resource requirements of the workload need to fit into a virtual machine in order to make sense in a virtual environment. If either the available hardware is not able to support the load of multiple virtual machines or the smallest unit of a workload does not fit into the envelope of a VM then physical deployment is the right thing to do. In the end, the important thing here is that this role needs to perform independent of if it is running in a VM or physical.
Possible ramifications to SharePoint: If the overall performance evaluation or virtual machines are not adequately spec'ced, this might result in slower response times for the end user and, in the background processes, slower performance of long running background operations which could increase operation time outs. This would be similar to running on physical hardware with insufficient capacity.

If you decide to virtualize the database layer:

Assess first using Microsoft Assessment and Planning Toolkit (www.microsoft.com/map)
Implement SQL Aliases in your SharePoint farm
Assign as much RAM as needed and CPU as possible
Offload the Disk I/O from the virtual machines and prefer pass through or fixed size disks over dynamically expanding disks.
Split SQL cluster over two physical hosts for minimum data layer availability. (hardware redundancy and load distribution)
Check the SQL CAT whitepaper on virtualizing SQL on Hyper-V: https://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx
SQL Clustering – Do not virtualize the passive node of a SQL cluster: It defeats the reason you clustered in the first place, which is high availability of your databases. Either virtualize the entire database layer or keep all physical! You cannot virtualize part of a SQL cluster. You can, but virtualizing the passive node of the active-passive SQL Server cluster is not recommended. Why? Typically you lose about 15-25% percent in performance using virtualized database hardware and over time portal usage will grow resulting in greater database load requirements. Over time your physical host will get squeezed by the other virtual slices until the point when the virtual passive node may not handle physical node’s load. It defeats the reason you clustered in the first place.
SQL Clustering of virtual database nodes is supported.UPDATE: The guidance has now been updated to support guest clustering provided the virtualization technologies are certified using the SVVP program. See https://support.microsoft.com/kb/956893 (Thanks James Daniel)

Other farm considerations

Ensure high availability through virtual machine clustering: Virtualization technologies involve hosting multiple guest machines on a single host server. This introduces a single point of failure, in that if the host machine dies, all your guest machines die as well. It’s bad to lose one server, Its is catastrophic to lose 10! In the Windows Hyper V world, it is possible to cluster your host servers and specify failover server for your virtual machines. For example, if failure occur on host motherboard, Hyper V moves the virtual machines to the failover server. In addition you can use Quick Migration to statefully migrate virtual machines from one physical host to another.. Moving forward with Hyper-V R2 you will in addition be able live migrate a virtual machine from one host to another without downtime, all this is part of the Windows infrastructure, no additional licensing or purchase required. A similar feature is also available in other 3rd party hypervisors like Xen and VMware ESX at additional cost. Last but not least it goes without saying, that you rather use SAN than local storage for high availability environments.

Do you have any tips and learning's from your environment? Post a comment and I will add to the lists and series.