Udostępnij za pośrednictwem

SharePoint 2010 Virtualization

  • Artykuł

Virtualized SharePoint farms are becoming increasing prevalent in the market and with the advances and capabilities offered in HyperV, these farms are becoming increasingly sophisticated.
In order to realize the benefits of virtualizing SharePoint farms, a careful process of planning, architecture and management have to be put in place.
In this post , we’ll get to discuss the why’s and when’s of virtualizing SharePoint farms going over the advantages as well as trade-offs as well as best practices that should be adhered to.
We will not be discussing High Availability considerations in this post.

The why and when of virtualizing SharePoint farms.

  • Money Talks! Virtualizing SharePoint farms on top of Hyper-V allows you to run multiple workloads on different isolated virtual machines.
    This reduces the number of physical machines required for a farm, leading to reduced costs in cooling and power consumption as well as hardware maintenance costs.
    Deploying several virtual machines on the same hardware allows you to balance the various physical resources (RAM, CPU, etc…) across the virtual machines as needed.
    A perfect example of this would be Windows Server 2008 R2 SP1’s Dynamic Memory which enables customers to better utilize the memory resources of Hyper-V hosts by balancing how memory is distributed between running virtual machines.
    Memory can be dynamically reallocated between different virtual machines in response to the changing workloads of these machines
  • Let’s go green! Reductions in cooling needs as well as power consumption are a significant factor in turning server farms into eco-friendly assets of an organization.
  • Test and develop! Staging and testing environments should mimic production environment as close as possible, this helps ensure that any unwanted surprises are avoided going from staging to production.
    Using System Center VMM, SharePoint administrators can easily manage multiple virtual farms.
  • Birds of a feather, flock together! SharePoint virtual machines running the same services / roles can be deployed on the same physical server, while optimizing the server setup for that role.
    This can be done to accommodate for roles that require specific SAN configurations, heavily utilize one resource over the other, etc…
  • Uptime is of the essence! Virtualizing the SharePoint servers allows you to utilize Hyper-V’s Live Migration capabilities which allow you to seamlessly move running virtual machines to the best physical computer for performance, scaling, or optimal consolidation without affecting users.
    Furthermore you can connect or disconnect virtual hard drives and pass through disks while a VM is running, providing you with the capability to quickly reconfigure VMs based on workload requirements without the need to restart or take the machines offline.

Best Practices for virtualizing SharePoint farms

SharePoint farms are made up of three primary server roles, Web Servers or Web Front Ends (WFEs), Application Servers and finally Database servers. Each of these 3 types of servers differs greatly in their capacity to be virtualized due to their different utilization of system resources.

Web Servers (WFEs)

Web Front Ends (WFEs) are an excellent candidate for virtualization. WFEs can be added and removed as needed. Its low disk activity and hence low I/O operations are one of the core reasons as to why it is a good candidate for virtualization.

  • Utilize a hardware load balancer, this helps offload CPU as well as I/O pressure from the VMs and to the hardware resulting in increased performance.
  • Provision more than one virtual network adapter to transport different types of traffic across the farm.
  • Applying normal topology, performance and capacity planning is a good place to start planning for the virtual environment and the needed number of servers.
    However you should keep in mind that a slightly larger number of virtual servers may be needed to provide the same level of service and performance during peak times.

Application Servers

Application servers host SharePoint Service applications. These service applications differ in their utilization of system resources based on their functionality.
They will also impact the different server roles differently from each other. Accordingly, for the sake of analyzing them from a virtualization perspective, into 3 main classes, Indexing Servers, Query Servers, Application servers hosting all other SAs.

Query Role Servers

The search process is generally split down into 2 main phases, crawling and querying. The query component is responsible for handling user queries.

  • Avoid dynamically expanding VHDs, instead utilize the Hyper-V pass-through disk feature.
  • Avoid deploying the query component with the crawl/index component on the same hardware.

Index Role Servers

The index servers contain the latest up to date index via crawlers that routinely crawl content sources for new/updated content. This role is generally very IO intensive and therefore it is not always the optimum case to virtualize.

  • Leverage index server as dedicated crawl server
  • Use physical LUNs on SANs instead of VHDs
  • Provide sufficient memory and disk space.

Other roles

Other application servers hosting service applications such as excel, Visio, performance point….These servers are also very good candidates for virtualization.

Database Servers

The database server hosts all of the data for the SharePoint farm over several databases; these include but are not limited to;

  • Configuration database
  • Content database
  • Various Service Applications databases
  • Etc…

SharePoint Server 2010 can be deployed on SQL Server 2005, 2008 or 2008 R2. All of the aforementioned versions support virtualization.
As with the indexing servers, database servers are extremely I/O intensive and thus are not always prime candidates for virtualization.
Virtualized SQL Servers typically perform slower than their physical counterparts, however utilizing the latest Hyper-V technologies that come part of Windows Server 2008 R2, the same throughput can be achieved on virtualized SQL servers at the cost of slightly increased CPU usage.

  • Hyper-V guest virtual machines are limited to a maximum of four CPU cores; therefore, you should run SQL Server within Hyper-V guest virtual machines only if your workload performance can be satisfied by no more than four CPUs.
  • Utilize either pass-through disks or fixed VHDs for your guest virtual machine storage. These are the best option for performance, and they should provide the best results for SQL Server workloads. Dynamic VHDs are not recommended due to performance reasons.
  • Avoid using emulated devices and instead ensure that integration components for Hyper-V have been installed and synthetic devices are being used for I/O, network, and so on. Synthetic devices will provide the best performance with lowest amount of CPU overhead.

General virtualization best practices

Virtual processors

  • Virtual processors should be mapped 1:1 to physical processors, 2:1 mappings or above incur extra overhead and effect performance negatively.
  • Enable hyper-threading on processors that support this technology.
  • Be aware of the virtual processor limit for different guest operating systems, and plan accordingly.
  • Be aware of “CPU-bound” issues; the ability of processors to process information for virtual devices will determine the maximum throughput of said devices, for example, virtual NICs.

Memory

  • Configure an adequate amount of memory for Hyper-V guests. Avoid the usage of paging files as this severely degrades performance.
  • Factor in memory requirements for the host physical machine as well as for Hyper-V memory overheard.
    A good standard for the memory overhead of each VM is 32 MB for the first 1 GB of virtual RAM plus another 8 MB for each additional GB of virtual RAM. This should be taken in to account for the calculations of how many VMs to host on a physical server.
  • Configure Non-Uniform Memory Access (NUMA) correctly. NUMA boundaries are memory limits on physical hosts. Virtual machines can span several NUMA nodes.
    The more NUMA nodes a virtual machine is spread across, the less the gain in performance.

Disk

  • Avoid using dynamically expanding disks.
  • Prefer SCSI controller to IDE controllers
  • Ensure that the SAN is optimized for virtual disk storage.
  • Put virtual hard disks on different physical disks than the hard disk that the host operating system uses.

Network

  • Ensure that integration components are installed on the virtual machines.
  • Use the network adapter instead of the legacy network adapter when configuring networking for a virtual machine.
  • Use virtual switches and VLAN tagging to help improve security and performance and to create an internal network among virtual machines in your SharePoint farm. Associate SharePoint virtual machines to the same virtual switch.
  • Use more than one network adapter on the physical server and dedicate one adapter to Hyper-V Server administration. Do not bind any virtual networks to this adapter.
    If virtual machines are sharing a network adapter, monitor latency and throughput to ensure that the adapter is not oversubscribed.