Chapter 12. Virtualizing SharePoint Components
In This Chapter
Microsoft’s Virtualization Support Story
Virtualization Infrastructure Requirements and Recommendations
Software Recommendations and Licensing Notes
Virtualization of SharePoint Roles
Exploring Sample Virtualized SharePoint 2013 Architecture
Virtual Machine Management with System Center Virtual Machine Manager
Server virtualization technologies have become so common that they are the de facto standard for server deployment in many organizations. It’s becoming more and more common to run into data center environments that operate with the assumption that all new servers will be deployed as virtual machines (VMs) unless there’s some specific reason not to virtualize. This is a significant change from even just a few years ago when the situation was reversed and servers were deployed on physical equipment unless there was a specific reason to virtualize.
So, what about Microsoft SharePoint? Should you virtualize some or all of a SharePoint environment and take advantage of the consolidation, optimization, and flexibility options that virtualization infrastructure provides? The reality is that SharePoint environments, particularly those running SharePoint Server 2013, can be robustly deployed on virtual servers as long as sufficient resources are allocated to virtual guests and the virtual hosts are scaled correctly. Deploying SharePoint improperly in a virtual environment can lead to slowness and other performance problems and can decrease management confidence in virtualization as a whole, so it’s vital to review virtualization design criteria for SharePoint in advance.
Microsoft’s Virtualization Support Story
The support story for Microsoft products running on virtualization hardware is long and complicated. Until several years ago, Microsoft offered limited support for its flagship server products, such as SQL Server, Exchange Server, and SharePoint Server. Microsoft even left open the option that a support problem might need to be duplicated on physical hardware if support technicians couldn’t determine the nature of the problem in a virtual environment. Adding to Microsoft’s weak support story was the fact that Virtual Server 2005 R2 was its virtualization product during the early days of Microsoft Office SharePoint Server (MOSS) 2007. Virtual Server 2005 R2 wasn’t a hypervisor-based product and couldn’t virtualize 64-bit guests, which limited supported environments to those running the 32-bit versions of MOSS 2007. This greatly curtailed the performance that could be achieved, particularly for the database role, which was the most resource intensive and could take advantage of the 64-bit architecture the most. In addition, web front ends usually required significantly more memory than a 32-bit platform.
Two significant developments changed this story. The first was Microsoft’s release of a 64-bit-capable hypervisor named Hyper-V. The second was the development of a program called the Server Virtualization Validation Program (SVVP), which outlined Microsoft’s official support stance on running its products on third-party hypervisor virtualization platforms. This program, outlined in the Microsoft article “Support Policy for Microsoft Software Running in Non-Microsoft Hardware Virtualization Software” (http://support.microsoft.com/kb/897615), allowed for support of Microsoft products on third-party virtualization products that were validated by Microsoft and complied with certain criteria, namely the ability to give guest sessions direct access to hardware resources via a virtualization hypervisor. These two developments opened the doors for Microsoft servers running on VMs and gave peace of mind to organizations that needed to deploy supported virtualized solutions.
SharePoint Virtualization Support
The 2007 wave of SharePoint products—which includes Windows SharePoint Services 3.0 (WSS 3.0) and MOSS 2007—was the first to gain broad virtualization support from Microsoft. However, in production, most clients opted to virtualize only the web role and sometimes the search query role. Other roles weren’t usually implemented, for various reasons. For example, the index role was often implemented only on physical hardware because of heavy processor and memory constraints and the limitation in SharePoint 2007 of one index server per shared services provider.
With SharePoint 2010 and then later SharePoint 2013, Microsoft’s official support stance is that any SharePoint role or service is supported for hardware virtualization. SharePoint 2013 is positioned as an excellent virtualization candidate because of virtualization technology advances. In addition, advances in hardware virtualization make it easier to virtualize I/O-intensive applications such as SQL Server. As a result, many organizations are looking at virtualizing their new SharePoint 2013 farms.
Virtualization Infrastructure Requirements and Recommendations
The key to a stable and high-performance virtualized SharePoint environment is using the proper architecture in the virtualization hosts. Out-of-the-box settings and slow disks might work for a test environment, but specific requirements need to be met when building the host system for proper performance to be achieved. Therefore, be sure to follow these minimum requirements when you design the virtualization host infrastructure:
The processors must support hardware-assisted virtualization, which is available in processors that include a virtualization option. Specifically, this means processors with Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) technology.
Hardware-enforced data execution prevention (DEP) must be available and enabled.
SharePoint guests must be deployed on a Hyper-V hypervisor or a third-party hypervisor that is part of the SVVP, which include popular hypervisors such as VMware ESX and Citrix XenServer.
Sufficient memory must be allocated for the host operating system (OS). If you’re using Hyper-V, you need to reserve at least 1GB of RAM for use by the Hyper-V host. If you’re using a third-party hypervisor, check with the individual provider to determine the minimum amount of memory required.
A dedicated network interface card (NIC) must be allocated for host management. This NIC must be separate from the NICs used by the VMs.
Use multiple independent drive arrays of disk spindles. Best practice is to allocate a dedicated set of disk spindles or storage array for the host OS, another for the guest OS virtual disks, and at least two more (logs and database volumes) for virtualized SQL Server sessions. Be sure to allocate the required amount of disk input/output operations per second (IOPS) values for the SharePoint databases, including a recommended 2.0 IOPS per gigabyte for the content databases.
Fixed-size or pass-through (raw device mapping) virtual hard disks (VHDs) can be used for best guest disk performance. Pass-through disks give you the fastest performance. Fixed-size disks are also faster than dynamically expanding disks, which can suffer performance hits when they’re resizing.
Consider pass-through (raw device mapping) NICs for the best network performance or, at minimum, configure virtual NICs to use a single virtual switch for SharePoint servers.
A 2:1 ratio for the number of virtual processors to physical cores is the maximum that should be used in a production environment. A virtual host that has too many allocated virtual CPUs can be overloaded and perform poorly. Therefore, you need to have a 2:1 ratio (or less) for the virtual processor-to-physical core ratio. For example, if your host is a 2-processor 12-core system (24 cores total), the maximum number of virtual processors that can be allocated and running at any one time is 48. If each VM is allocated eight virtual processors, the number of running VMs is capped at six on that host. Highest performance environments limit the ratio to 1:1.
In addition to these technical requirements for the virtualization host, keep in mind these recommendations when you set up your virtual environment:
You should allocate a dedicated NIC for failover, such as in the scenario when you use virtual host failover software such as Hyper-V Live Migration.
You should give as much memory and as many processor cores to your virtual hosts as your budget allows. Virtual hosts with multiple multicore processors and large amounts of RAM (256GB or more) are becoming commonplace because of the virtual host software’s ability to take advantage of the additional resources, and because host failover solutions require additional resources. When it comes to sizing virtualization hosts, there’s a sweet spot that balances the cost of the additional components against the need to have fewer hosts. Generally, the virtualization overhead required to run virtual servers is only 5%, so the cost of adding memory and processor cores is more than made up by the advantages of having those additional resources.
You should run only the virtualization software and the virtualization role on the virtual hosts. (The two exceptions are antivirus and backup software.) Overloading a virtual host with other software or other server roles can significantly degrade guest performance. In addition, from a Windows Server licensing perspective, running any roles other than the virtualization role on a Windows Server requires one additional license. However, if the host runs only virtualization host software, the host OS isn’t counted when determining the number of Windows licenses used as part of Microsoft’s virtualization licensing program.
For performance reasons, you shouldn’t install all the SharePoint roles and the SQL Server role on the same VM. Even small environments should use at least two VMs—one for the SQL Server database role and the other for the SharePoint front-end and application roles.
Software Recommendations and Licensing Notes
It’s highly recommended that you use the latest virtualization host software from your particular vendor. For example, the latest version of Hyper-V is included with Windows Server 2012. Hyper-V 3.0, included in Windows Server 2012, has significant performance improvements over the early versions Hyper-V, such as I/O improvements for fixed-size VHDs and support for up to eight processors on virtual guests. Hyper-V 2.0, included in Windows Server 2008 R2, introduced new features such as Core Parking, Live Migration, TCP Offload, the Jumbo Frames feature, and support for Second-Level Address Translation (SLAT)-enabled processors. If you’re virtualizing SharePoint on Hyper-V, also consider deploying the virtual host on Server Core to minimize its security footprint, OS disk overhead (2GB versus 10GB), and memory use.
Microsoft provides cost-effective virtualization licensing options for Windows Server, which lets organizations save significantly on Windows Server licenses when virtualizing servers. The three types of virtualization server licensing are as follows:
Windows Server Standard Edition, which allows a single physical OS environment (POSE) or up to two virtual OS environment (VOSE) licenses with each Standard Edition license. Note that a virtualization host that’s dedicated to virtualization tasks doesn’t consume a license, regardless if it’s running Windows Server (such as in the case of Hyper-V). Note that Windows Server 2008 R2 only supports a single VOSE per Standard Edition license.
Windows Server Enterprise Edition, which allows for up to four VOSEs to be run at any one time on the host. Note that only running VMs are counted. So, if a VM is shut down, it doesn’t count against the four concurrent VOSEs permitted by the Enterprise Edition license. Note that Enterprise Edition is only supported by Windows Server 2008 R2, and there is no equivalent edition available with Windows Server 2012.
Windows Server Datacenter Edition, which is a per-processor (not per core) license for the virtual host (for example, a dual quad-core server would require two licenses) that grants you the right to run an unlimited number of VMs on the host.
These licensing options apply not only to Hyper-V but also to any hypervisor that is part of the SVVP. For organizations with a significant investment in virtualization infrastructure, buying the appropriate number of Datacenter Edition licenses to cover all your virtual hosts is the most cost-effective.
Virtualization of SharePoint Roles
Virtualization requirements vary by server role. It is subsequently important when designing that you understand the individual requirements of each role.
Virtualization of the Web Role
The best candidate for virtualization is the SharePoint server that has the web role, which means it runs Microsoft Internet Information Services (IIS) and handles all web requests sent to SharePoint. Table 12.1 shows resource guidelines for virtualized SharePoint servers that have the web and other roles.
As you can see in Table 12.1, a SharePoint server that holds only the web role (otherwise known as the web server) should be allocated at least two virtual processors and a minimum of 12GB RAM (preferably at least 16GB RAM), along with a single VHD for the OS. If a web server needs to handle more web traffic, you can simply allocate additional web servers that have the same specifications. The size of the host OS disk should be at least 12GB plus three times the total amount of memory allocated to the VM, but it’s good practice to size this volume larger (usually around 50GB to 100GB) to allow the host OS to grow in size.
Virtualization of the Application Roles
The next likely candidates for virtualization include the SharePoint server with one or more service application roles (otherwise known as the application server). Application servers can include various service applications, such as Access Services, PerformancePoint Services, Machine Translation Services, or the Managed Metadata Service. For purposes of design, this excludes the search services, which are technically service applications, but for architectural purposes are usually classified as part of a different server role.
As Table 12.1 shows, the typical virtualized application server consists of a VM with two virtual processors and a minimum of 12GB RAM allocated to it. It needs a single VHD that’s presized in the 50GB to 100GB range for the guest OS. Note that these numbers can vary, depending on how many service applications are installed on a single machine and how many people use the applications.
In smaller organizations, the application role and the web role are often combined onto a single SharePoint server. Combining the roles increases the memory and processor requirements of the guest session.
Virtualization of the Search Role
Third in line for virtualization is the SharePoint server or servers that hold the search role (otherwise known as the search server), which provide SharePoint’s indexing and querying functionality. SharePoint 2013 doesn’t have the same single-index restrictions that SharePoint 2007 did, which makes this role more scalable and allows for more distributed deployment models.
The typical virtualized search server consists of a VM with four virtual processors and 12GB RAM allocated to it (see Table 12.1), assuming that SharePoint 2013’s out-of-the-box search functionality is being used. Like the application server numbers, the search server numbers can vary, depending on how many items are being indexed and how heavy the search requirements are.
The search server needs a single VHD that’s presized in the 50GB to 100GB range for the guest OS and another VHD for the index and query corpus. The size of this VHD varies, depending on how much full text is indexed from various sources.
The crawler component is used by SharePoint to crawl documents for search purposes. Multiple crawl components can be created on different servers for redundancy.
In smaller organizations, the search role is often combined with the web role. Combining these roles can increase the memory and processor requirements of the guest session.
Virtualization of a Server with All Three Roles
Many organizations combine the web, application, and search roles on a single virtualized SharePoint server. This is often the case in smaller organizations that want to deploy SharePoint across two guest sessions to be highly available but have a smaller number of guests.
Although combining the three roles results in additional load on an individual server session, many of the same processor and memory guidelines that apply to a dedicated web role server apply to a combined server, as Table 12.1 shows.
The typical virtual web/query/search server role system consists of a VM with eight virtual processors and 12GB to 20GB RAM allocated to it, depending on how many users the system supports. It has a single VHD presized in the 50GB to 100GB range for the guest OS and another VHD for the index and query corpus.
SharePoint administrators familiar with earlier versions of SharePoint might be dismayed at the memory requirements of SharePoint 2013, but the fact is that SharePoint 2013 requires much more memory than earlier versions. RAM requirements can be lessened, however, by turning off nonessential service applications. In general, to reduce the overall requirements of the SharePoint servers, it is recommended to turn on only those service applications required by the business.
Virtualization of the Database Role
The SQL Server database role is the last but most challenging server role to virtualize. The server with the database role (otherwise known as the database server) needs the lion’s share of RAM and processor allocation. A minimum of eight virtual processors and 16GB RAM should be allocated to the database server. For best performance, though, at least 24GB RAM should be allocated.
Like SharePoint VMs, SQL Server VMs require either fixed-sized or pass-through VHDs. The same disk considerations that apply to physical SQL Server machines apply to virtual SQL Server machines. So, be sure to allocate enough disk spindles for the database and logs volumes. In addition, be sure to follow standard best practices for SharePoint-SQL Server optimization, such as presizing the tempdb and moving it to fast disk volumes.
Keep in mind that these guidelines are simply guidelines. Actual performance is dictated by the type of disk, hardware architecture, and other factors. Some organizations calculate their hardware requirements and then just add RAM or reduce the number of databases on a single SQL Server session.
Microsoft supports both forms of SQL mirroring, SQL AlwaysOn Availability Groups (AOAGs), and clustering as high-availability (HA) options in a virtualized SQL Server environment. In addition, host failover options such as Hyper-V Live Migration are supported for SQL Server VMs. One fact to note, however, is that all SQL Server databases within a SharePoint farm need to be restored from the same point in time as the other databases. This applies to virtualization snapshot technology or storage area network (SAN)-based snapshots of SQL Server databases.
Exploring Sample Virtualized SharePoint 2013 Architecture
There are many ways to deploy SharePoint 2013 in a virtualized environment. However, some designs are more widespread than others and reflect common needs across many organizations. For example, high availability is becoming a must for the critical document management and collaboration functionality in SharePoint. All the new high-availability options in SharePoint 2013 are available for virtual environments and can actually be easier to deploy because of the flexibility that virtualization provides.
Figure 12.1 illustrates a small virtualized SharePoint 2013 environment with all components running on a single virtual host. This type of deployment doesn’t have any built-in high availability or disaster recovery (DR), but it’s the simplest environment to set up, and it can still take advantage of virtualization benefits and scalability. In addition, architects can install multiple farms into the same environment, as shown in Figure 12.1. Table 12.2 shows sample server specifications for an environment of this size. These specifications assume 500 active users in the environment.
The next design, illustrated in Figure 12.2, provides a virtualization architecture that provides a high level of availability, disaster tolerance, and scalability for an environment with 2,000 active users. The entire SharePoint environment is deployed across two virtual hosts, which provides for high availability of the environment. SQL Server databases are replicated between two SQL servers using SQL 2012 AOAGs, providing for automatic failover in the event the virtual host or virtual guest fails. For more information about using SQL AOAGs for high availability, see Chapter 17, “Safeguarding Confidential Data in SharePoint 2013.”
These high-availability and disaster-recovery options are possible without the need for shared storage, a SAN, or host availability solutions. Table 12.3 lists the sample virtual host and guest architecture guidelines for the solution in Figure 12.2.
Virtualization technologies allow for a high degree of scalability and aren’t limited to small and mid-sized organizations. For example, the architecture that Figure 12.3 shows provides for tens of thousands of SharePoint users, full disaster tolerance, and high availability, all with the high performance expected from SharePoint. In this particular model, multiple SQL Server instances hold copies of the databases in SQL AOAGs. In addition, workload is streamlined and spread out using server groups to divide tasks for different SharePoint server roles, and the web tier is broken into two components: one for users and another for crawl and administration. In this example, host-based failover solutions such as Hyper-V Live Migration could also conceivably provide for failover of individual guest sessions between failed hosts.
These three examples illustrate some of the potential design options available for a virtual SharePoint environment. Every environment is unique, and specifics vary based on business and technology needs. However, you can use these architecture examples as a starting point for developing a high-performance virtualized SharePoint 2013 environment.
Virtual Machine Management with System Center Virtual Machine Manager
If managing multiple virtual host machines, centralized management software is also highly recommended. Microsoft has released its own product for VM management and is positioning it as an enterprise utility that allows for centralized control over a broader virtualization environment. This tool, part of the System Center line of products, is known as System Center Virtual Machine Manager (VMM). The latest version of VMM, the 2012 SP1 edition, has the following tools and capabilities:
P2V and V2V: VMM allows for physical-to-virtual (P2V) or virtual-to-virtual (V2V) migration capabilities, allowing existing physical systems or VMware guests to be migrated to an equivalent Hyper-V guest session.
Hyper-V, VMware, and Citrix XenServer management support: VMM provides for the ability to manage Microsoft Hyper-V, VMware, and XenServer hosts and guests through the interface.
Creation of template servers: VMM supports the creation of server templates, which can be used to automate the creation of virtual guests, including SharePoint role servers, a concept explored in subsequent sections of this chapter.
Exploring the VMM Console
VMM 2012 SP1’s management console, shown in Figure 12.4, provides a wide degree of functionality that can be used to manage virtual SharePoint guests. This console allows a distributed virtualized SharePoint farm to be more tightly managed, and gives administrators a tool they can use to easily move guest sessions between one or more hosts (and to perform other virtualization tasks).
Provisioning Farm Members from Virtual Server Templates
VMM allows SharePoint administrators to define a library of templates and VMs that can be used to provision new SharePoint sessions. For example, a Windows Server 2012 server template could be created with the right amount of memory and virtual processors, plus a pair of virtual hard drives for the OS and index files. With SharePoint 2013 binaries installed on that system, it can then be turned into a template that can be used to provision new SharePoint farm members or even entirely new farms.
VMM Template Options, shown in Figure 12.5, allow administrators to modify the type of disks that are installed, set different memory options, and also specific OS options such as those that allow the server to be automatically added to a domain, be validated with a valid server key, and also to have a script run after first login. For example, a custom PowerShell script could be run automatically after login that joins the SharePoint template server to an existing farm or creates a new farm from scratch.
Using this concept, an organization could easily set up a scenario where developers are given the rights, through the self-service portal, to provision a new SharePoint guest session. After provisioning the server, they could then log in to that session and have it automatically run a PowerShell script that would create a new farm. With the proper hardware, developers could provision an entirely new SharePoint environment within 10 to 15 minutes and have that farm completely independent from other farms.
For this scenario to work, the SQL server used must be on a different system, because SQL doesn’t lend well to name changes after it has been installed. In this scenario, a single SQL instance can hold the databases from multiple farms. Commonly, a single SQL guest session would be used for all development farms created in this manner.
A farm provisioning script (ProvisionFarm.ps1) is provided here as an example of the type of script that can be configured to run automatically upon login to the virtual session provisioned. For more complex scripts, see Chapter 4, “Advanced SharePoint 2013 Installation and Scalability,” which contains new service application provisioning scripts which can be automated. You can download these scripts from http://tinyurl.com/SPFarm-Config:
PROVISIONFARM.PS1
$configType = read-host "Do you wish to create a new farm? (Y/N)"
if ($ConfigType -eq "N") {
$DatabaseServer = read-host "Preparing to join existing farm. Please specify the
name of your SQL Server";
$ConfigDB = read-host "Next, specify the name of your Farm Configuration
Database";
$Passphrase = read-host "Finally, please enter your Farm passphrase"
-assecurestring
} else {
$DatabaseServer = read-host "Preparing to create a new Farm. Please
specify the name of your SQL Server (ex SERVER or SERVERINSTANCE[,PORT])";
$FarmName = read-host "Please specify a name for your Farm (ex. SP2013Dev)";
$ConfigDB = $FarmName+"_ConfigDB";
$AdminContentDB = $FarmName+"_CentralAdminContent";
Write-Host "Please enter the credentials for your Farm Account (ex. COMPANYABC
SP_Farm)";
$FarmAcct = Get-Credential;
$Passphrase = read-host "Enter a secure Farm passphrase (must meet password
complexity requirements)" -
assecurestring;
$Port = read-host "Enter a port number for the Central Administration Web App";
$Authentication = read-host "Finally, specify your authentication provider
(NTLM/Kerberos)";
}
if ($ConfigType -eq "N") {
if((Get-PSSnapin | Where {$_.Name -eq "Microsoft.SharePoint.PowerShell"}) -eq
$null) {
Add-PSSnapin Microsoft.SharePoint.PowerShell;
}
Connect-SPConfigurationDatabase -DatabaseName $ConfigDB -DatabaseServer
$DatabaseServer -Passphrase $Passphrase
} else {
if((Get-PSSnapin | Where {$_.Name -eq "Microsoft.SharePoint.PowerShell"}) -eq
$null) {
Add-PSSnapin Microsoft.SharePoint.PowerShell;
}
Write-Host "Your SharePoint Farm is being configured..."
New-SPConfigurationDatabase -DatabaseName $ConfigDB -DatabaseServer
$DatabaseServer -AdministrationContentDatabaseName `
$AdminContentDB -Passphrase $Passphrase -FarmCredentials $FarmAcct
}
Initialize-SPResourceSecurity
Install-SPService
Install-SPFeature -AllExistingFeatures
New-SPCentralAdministration -Port $Port -WindowsAuthProvider $Authentication
Install-SPHelpCollection -All
Install-SPApplicationContent
Write-Host "Your SharePoint 2013 Farm has been created!"
if ($ConfigType -eq "Y") {
$WebAppCreation = read-host "Would you like to provision a Web Application using
the default Team Site Template? (Y/N)";
if ($WebAppCreation -eq "Y") {
$HostHeaderQ = read-host "Would you like to specify a host header? (Y/N)";
if ($HostHeaderQ -eq "Y") {
$HostHeader = read-host "Please specify a host header for your Web
Application (ex. intranet.contoso.com)";
$URL = "http://"+$HostHeader;
Write-Host "Creating your Web Application...";
$ap = New-SPAuthenticationProvider
New-SPWebApplication -Name "SharePoint 2013 Team Site" -Port 80
-HostHeader $FQDN -Url $URL -ApplicationPool
"Content_AppPool" -ApplicationPoolAccount (Get-SPManagedAccount $FarmAcct.UserName) -DatabaseServer $DatabaseServer -
DatabaseName $FarmName + "_TeamSite_ContentDB_01" -AuthenticationProvider $ap;
New-SPSite $URL -OwnerAlias $FarmAcct.UserName -Language 1033 -Template
"STS#0" -Name "Team Site";
Write-Host "Configuration completed.";
}
else {
Write-Host "Creating a Web Application using the default Team Site
Template..."
}
}
else {
Write-Host "Configuration completed.";
}
}
$serviceAppsConfig = read-host "Do you wish to configure Service Applications?
(Y/N)"
if($serviceAppsConfig -eq "Y") {
PowerShell -File "Configure-ServiceApps.ps1" $appPoolName $managedAccountName
$FarmName
}
else {
Write-Host "Press any key to continue..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
}
The high-level steps involved in running this scenario are as follows:
1. Create a new Windows Server 2012 guest session in VMM with at least 12GB RAM and four virtual CPUs allocated to it. (Remember that SharePoint 2013 has large resource requirements.) Give the session two virtual hard drives: one for the OS and another for the index.
2. Install the SharePoint 2013 binaries on the guest session but don’t run the Config Wizard. Copy the Provisioning Farm PowerShell script into a directory on the server, such as C:Scripts. See step 3 for the syntax of the script name.
3. Using VMM, turn the guest session into a server template. Specify within the server template to automatically add the machine into a domain and to run powershell.exe -noexit C:scriptsProvisionFarm.ps1.
4. Use the self-service portal to provision a new server based off the template. After the session has been created and added to the domain, log in to the system and walk through the farm provisioning script. Because the SharePoint 2013 binaries are already installed, the script can provision a new farm or add the server into an existing farm.
Within approximately 15 minutes, a new SharePoint farm can be provisioned with running web applications and services. Using this approach, modifications can also be made to the PowerShell script to expand the functionality of the script, such as by adding the ability to provision service applications. In addition, it can be made to run completely without user input, providing for a 100% automated farm provisioning solution.
This same process can be used with other virtualization management software, such as the third-party VMware VirtualCenter. The concepts still apply: Just install the SharePoint 2013 binaries, and then create a server template. Using a provisioning script, you can then automatically create a new virtual farm or add additional members to it.
Summary
Server virtualization can provide significant advantages and can let SharePoint architects design highly available and disaster-tolerant environments more easily than could be done solely on physical hardware. In addition, virtualized environments have consolidation, optimization, and cost-saving benefits that make them ideal for many organizations. With proper thought into host and guest virtualization architecture, you can deploy a fault-tolerant and high-performance SharePoint environment that lets you fully capture the benefits of virtualization for your organization.
Use of a virtualization management tool such as System Center VMM can be particularly advantageous because it allows for scenarios such as the one described in this chapter, where a virtualized SharePoint 2013 farm can be automatically provisioned from templates in a matter of minutes, thus enabling developers and farm architects to provision quality-controlled SharePoint farms on an as-needed basis.
Best Practices
The following are best practices from this chapter:
Do not over-allocate memory or processor resources; maintain a maximum of a 2:1 ratio between the number of allocated virtual CPUs on guests and the number of cores on the host.
Use an approved hypervisor for virtualization, such as Microsoft’s Hyper-V on Windows Server 2012 or a third-party hypervisor that is part of the SVVP such as VMware ESX or Citrix XenServer.
Allocate up to 1GB of the memory of the virtual host to running the virtualization host software.
Highly consider pass-through (raw device mapping) NICs and pass-through disks rather than virtual NICs or virtual hard drives; the best performance can be achieved with them. This is particularly true for virtual SQL database servers.
If using Microsoft’s Hyper-V hypervisor, use the latest version included with Windows Server 2012; it has significant performance improvements over the initial versions of Hyper-V.
Do not install anything other than virtualization software on the host sessions. Exceptions to this rule may include backup or antivirus software, although you should avoid these if possible.
Consider the use of Server Core for the host OS session if using Microsoft’s Hyper-V hypervisor for virtualization. This cuts down on the overall system requirements and provides a more streamlined host.
Consider the use of a tool such as Microsoft’s System Center VMM for virtualization guest and host management and for scenarios such as those where farm members need to be provisioned quickly and reliably.