Virtualizing SharePoint provides the flexibility and rapid deployment capabilities needed to meet ever-changing and complex business requirements. It provides simplified administration, and the capability to improve service levels via provisioning of management capability of multiple virtual hosts, by rapidly provisioning SharePoint farms and servers, and by transferring physical servers to virtual servers.
Selecting hypervisor: hosted or bare metal?
One of the most important decisions you’ll make when virtualizing your SharePoint farm is the selection of either “bare metal” or “hosted” hypervisor technology to host your SharePoint farm. The “bare metal” hypervisors are software systems, like VMWARE ESX Server and Windows Server 2008 with Hyper-V, which execute directly on the host’s hardware and act as a guest operating system monitor and hardware controller.
The guest operating system that hosts SharePoint software executes above the hypervisor. However, the “hosted” hypervisors are software applications like VMware Server and Microsoft Virtual Server 2005 R2, which run within a conventional operating system environment as a service.
The guest operating system that hosts SharePoint software executes above the operating system and executes on the hardware, creating three layers between SharePoint and the hardware. It’s recommended to use “bare metal” technologies, since they have fewer software layers between the hardware and the guest operating system. Also, they have more performance ability than “hosted” implementations, hence providing greater performance for your SharePoint farm.
Furthermore, Microsoft Windows Server 2008 Hyper V is the recommended option for Microsoft virtualization in an enterprise environment. This is because it has greatly improved network capacity, CPU, and memory capacity; three qualities of which SharePoint will take advantage. If you use VMware in your organization, then it is recommended to use ESX infrastructure (similar to Hyper V) to host your SharePoint farm.
Three layers of a virtual SharePoint farm
The layers of a virtual SharePoint farm are as follows:
First is the physical hardware layer, which comprises the physical resources in your host server, i.e. CPU, disk, memory, and network.
Second is the virtualization platform layer, in Windows Server Hyper V. It comprises the hypervisor and parent partition, and the combined effect of multiple virtual machines that share the same physical resources in the physical hardware layer.
Finally, there is the guest operating system layer, which is where the virtual machine preconfigured with a set of virtual resources resides. It’s the host of SharePoint server roles in your SharePoint farm.
It is very important to note that decisions you make on the physical, virtual resources, and configuration at each of these layers affect the performance of every virtual machine, and therefore the overall performance of your MOSS farm.
The following are the steps to follow when planning for your virtualized SharePoint farm:
- Determine the physical software and hardware requirements for your planned or existing SharePoint farm.
- Determine your virtual machine hardware requirements for your SharePoint farm using the following guideline for each virtual machine in your farm. Allocate 110%-125% of the CPU, memory, and disk resources required by the stated physical hardware requirement to each Hyper V virtual machine.
- Assess whether or not your physical virtualization environment and technology will be able to meet your performance requirements for your SharePoint farm.
- Plan and optimize your host environment servers by ensuring that each has enough physical resources to host the planned virtual SharePoint servers. Don’t forget to account for failover cluster host servers for your virtual machines.
- Plan and optimize your virtualization platform layer by doing the following:
- Understand the virtualization overhead with different mixes of SharePoint VM workloads
- Understand the performance bottlenecks in the underlying storage and network infrastructure, both from a cumulative and individual path perspective
- Group complimentary virtual SharePoint machine workloads (a workload is a single virtual machine) for optimal performance on a physical host based on the performance characteristics of your virtual machines
- Plan and optimize the guest operating system layer by doing the following:
- Use Windows Server 2008 as the guest operating system
- Optimize each virtual guest by ensuring that the four physical and virtual resources utilization are maximized.
- Maximize the application and configuration of each guest machine in your virtual SharePoint environment
- Continually monitor performance and adapt configuration for optimal performance for each host server based on what is happening in your organization. Plan and cater for peak-usage scenarios.
It’s necessary to consider implementation of high availability via virtual machine clustering. Virtualization technologies involve hosting several guest machines on a single host server. This introduces a single point of failure because if the host machine dies, all your guest machines die as well.
Indeed, this could turn out catastrophic. The good news is that it’s possible to cluster your host servers and specify the failover server for your virtual machines in the Windows Hyper V. Hence, upon failure, Hyper V moves the virtual machines to the failover server, thus guaranteeing 24×7 uptime. Also, consider using SAN than local storage for high-availability environments.
If you are not sure how to virtualize older SharePoint environments, Datavail can help. With more than 400 database administrators worldwide, Datavail is the largest pure-play database services provider in North America. With 24×7 managed database services, including database design, architecture and staffing, Datavail can support your organization as it works with SharePoint, regardless of the build you ultimately select.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.