- Create a new web performance and load test project. On the Visual Studio Ultimate menu, chooseFile, New, and then Project. Expand either Visual C# or Visual Basic and choose Test. Choose Web Performance and Load Test Project and choose OK.
- The Web Performance Test Editor displays with a blank test. To record the test, choose the Add Recording button.
- A new blank web browser window appears with the web test recorder panel on the left side. Enter the name of your SharePoint site in the browser address bar. Visual Studio Ultimate will record and list the URLs in the web test recorder panel.
- Perform the following steps to navigate to the SharePoint sub site SampleSite and add a new item to the site task list:
- Choose SampleSite from the top of the SharePoint site.
- From the menu on the left side, choose Tasks.
The SampleSite > Task: All Tasks page appears.
- To add a new task to the list, choose the Add new Item link.
The Tasks – New Item dialog box appears. The only required field is Title and the value entered does not matter. Complete the information on the dialog box and choose Save.
- The web browser returns to the SampleSite > Tasks: All Tasks, which now lists the new task added in the previous step.
- To end the recording, choose Stop on the Web Test Recorder panel.
The Dynamic Parameter detection dialog box appears. It indicates detection progress. This should only take a short while to complete.
Visual Studio Ultimate will return you to the Web Performance Test Editor where your newly created web performance test is displayed.
- Choose SampleSite from the top of the SharePoint site.
- To confirm that the test is running correctly, first browse the SharePoint site to view the existing list items:
- Return to Visual Studio Ultimate and choose the Run test button on the Web Performance Test Editor. Your test runs, performing your recorded actions to add a new item to the task list in SharePoint.
- Choose refresh on the browser window with your SharePoint site and you should now see a new task item added to the list.
Archives For SharePoint 2010 Virtualization
Over the last few months, I’ve had a number of conversations with customers regarding the virtualization of SQL Server for the database-tier of SharePoint Server 2010 deployments. Historically, administrators have been hesitant to virtualize SQL Server database servers out of concerns for performance. With advances in virtualization technology and the adoption of new IT standards, virtual deployments have become the new norm in many organizations.
Still, virtualization is not the right choice for every workload. The purpose of this blog is to highlight the key considerations that go into deciding whether to virtualize the SharePoint database-tier.
Support for Virtualization
The first thing to consider is the SQL Server support policy for virtualization. SQL Server 2005+ enjoys support on a wide range of virtualization platforms with two important limitations. First, mobility technologies, i.e. VMWare VMotion, are not supported with the exception of Hyper-V Live Migration which has received thorough testing with SQL Server. Second, virtualization snapshots are not supported on any platform, including Hyper-V.
Microsoft SharePoint Server 2010 is fully supported when you deploy it in a virtual environment that is supported by Windows Server 2008 or by Windows Server 2008 Hyper-V technology. SharePoint Server 2010 is also supported for virtualization technologies that are accredited by the Server Virtualization Validation Program (http://go.microsoft.com/fwink/?LinkId=125649) environment.
This article is one of a series of Best Practice articles for Microsoft SharePoint Server. This article describes best practices for SharePoint Server 2010 virtualization. For more articles in the series, see Best practices (SharePoint Server 2010). For additional information and resources regarding Best Practices for SharePoint Server 2010, see the Best Practices Resource Center (http://go.microsoft.com/fwlink/?LinkID=125981).
The best practices in this article are ordered based on the sequence in which they would apply as you move from creating a virtual machine to deploying SharePoint Server.
Read More: SharePoint Virtualization Best Practices
Why Virtualize SharePoint?
Virtualizing SharePoint and its server components can provide many business and technical benefits. With virtualization, you can consolidate hardware and ease server management and provisioning—helping to promote cost savings, business continuity, and agile management. Moreover, SharePoint virtualization is ideal for organizations that have more than one SharePoint farm, such as those with high availability production, testing, and development environments. The remainder of this section describes additional benefits of SharePoint virtualization in greater detail.
Hardware consolidation essentially allows you to run different SharePoint servers and various server components sharing the same hardware set. Hardware consolidation yields a variety of benefits:
Resource utilization and balancing: With SharePoint virtualization and the built-in enhancements of the Hyper-V 64-bit multiprocessor and multicore technology, you can run multiple workloads on different, isolated virtual machines—helping to use and balance resources more efficiently. Because you manage only a single physical server that runs isolated virtual machines, it is easier to provision and balance various resources, such as RAM and disk space, for different SharePoint server components.
Reduced costs for physical infrastructure, maintenance, power, and cooling: Server consolidation reduces server count, which, in turn, reduces the cost of SharePoint infrastructure and maintenance. Consequently, cooling needs and power consumption are also reduced. From the perspective of environmental sustainability, SharePoint virtualization can be a major contributor to the Green IT movement.
Less physical space: By virtualizing SharePoint farms, you can provide required capabilities with fewer servers, thereby freeing up space originally allotted for servers.
SharePoint 2010 virtual Architectures for Small-to-Medium Farms
SharePoint 2010 Virtual Architectures for Medium-to-Large Farms
Solution from HP
HP recommends this 4-server configuration for larger solutions where high-availability is a requirement, the expected user population is up to 1000 users (assuming an active user concurrency of typically 25-50%), and usage of various SharePoint Application services (for example Excel Services, PerformancePoint, etc.) is planned. The expected solution workload is mostly collaboration and portal activity, with some use of team sites and My Sites, but also includes extended use of the various new SharePoint 2010 application services (for example, Excel services, Office client services, and others). SharePoint 2010 has extended the possible topologies for the Search service by enabling more than one Index Search service to be run on separate servers. This feature can be used to provide redundancy for the service (high availability), or to divide the crawl sources across multiple services, thus improving overall crawl speed, and to apply differing crawl rules and frequencies to better match the business need regarding freshness of specific index data.
This configuration example utilizes two HP ProLiant DL585 G7 servers that are configured with four 12-core processors, 64GB of RAM, and eight internal SAS disk drives each, and are connected to an HP 4400 Enterprise Virtual Array (EVA4400) storage device to provide failover cluster support for 6 Hyper-V R2 virtual machines (VMs). Each VM is configured with 4 virtual CPUs, 8GBs of RAM, and a 40GB VHD container file that is hosted on a single 500GB LUN configured as a Cluster Shared Volume provided by the EVA4400 device. In this 6 VM example the WFE and Query roles, Index Service role and Application services role are each deployed on two VMs. In this case, it is to provide increased capacity, as the high-availability needs are already met by Hyper-V R2 running on an active/active failover cluster. Further, the solution is sized such that each physical server is running at no more that 50% of maximum recommended capacity. Thus should failover occur, the remaining server can support the total VM load and not impact performance.
SQL Server is installed into a separate active/passive cluster of an additional two HP ProLiant DL585 G7 servers, each have four 12-core processors, 64GB of RAM, and storage for the SQL databases is provided via the same EVA4400 SAN.
Solution from HP
HP recommends this configuration for virtualized medium-sized solutions where high-availability is a requirement, and the expected user population is up to 500 users (assuming an active user concurrency of typically 25-50%). The expected solution workload is mostly collaboration and portal activity, with some use of team sites and My Sites. SharePoint 2010 has extended the possible topologies for the Search service by enabling more than one Index Search service to be run on separate servers. This feature can be used to provide redundancy for the service (high availability), or to divide the crawl sources across multiple services, thus improving overall crawl speed, and to apply differing crawl rules and frequencies to better match the business need regarding freshness of specific index data.
For approximately 500 users and above, the environment will need to be divided up into four physical servers, two running Hyper-V R2 VMs in a cluster, and two dedicated to a physical SQL Server failover cluster. In this example, two HP ProLiant DL580 G7 servers, each configured with four 8-core processors and 64GBs of RAM, will support the Web Front End/Query and Index services in an active/active failover cluster. This cluster will use a shared HP P2000 G3 MSA LFF array to provide a single Cluster Shared Volume for all the VHD (virtual hard disk) file containers. In this example the WFE and Query services are supported on two child partitions, which are configured to have four virtual CPUs (vCPUs), and 8GBs of RAM each. The Index Search service runs on two further child partitions, along with the Central Administration and other application services.
SQL Server is installed on a non-virtualized failover cluster consisting of two HP ProLiant DL580 G7 servers with four 8-core processors, configured with 64GBs of RAM each, eight internal SAS disk drives, and an HP P2000 G3 MSA SFF array. Two “Hot” RAID0+1 volumes of eight disks each and a single “Cold” RAID5 volume of eight disks are created to support SQL Server.
Solution from HP
HP recommends this 2-server solution for SMB customers who are looking to deploy solutions in a virtualized environment using Microsoft Hyper-V R2, and also wish to employ high-availability technologies to ensure continuity of service. The expected user population is up to 150 users (assuming an active user concurrency of typically 30-50%).
It uses the same SharePoint service deployment topology as the “Medium-sized configuration (3-server solution)” physical server solution, but deploys the three roles onto three virtual machines (VMs) rather than three physical servers. The two servers are formed into an active/active failover cluster and then run Hyper-V R2 to virtualize the environment. The three roles are then deployed onto three VMs across the cluster, each VM being configured with 4 virtual CPUs (cores) and appropriate memory.
The total server memory has been sized to support the VMs and any Hypervisor and OS overhead. Nominally the SharePoint WFE and Query Search roles would run on Server “A”; and the Index Search and SQL roles on Server “B”. However should a server fail for some reason, the solution has been sized such that the remaining active server can support the full required load and role VMs will automatically fail-over to the running server. Storage utilizes an HP P2000 G3 MSA to provide the required SAN technology to support the failover cluster. An AMD-based solution is shown.
Planning SharePoint Server 2010 Virtualization