EMC Virtual Infrastructure for Microsoft SharePoint Server 2010 Enabled by EMC CLARiiON and VMware vsphere 4

Transcription

1 EMC Virtual Infrastructure for Microsoft SharePoint Server 2010 Enabled by EMC CLARiiON and VMware vsphere 4 A Detailed Review EMC Information Infrastructure Solutions Abstract Customers are looking for best practices for setting up Microsoft SharePoint farms where performance does not degrade as the farms scale. More and more customers are moving to hyper-consolidated, virtualized data centers and private clouds, which increases the potential for performance issues. This solution illustrates large-scale performance testing of a SharePoint 2010 farm to show how the components of the farm scale and how EMC recommends building the configuration according to Microsoft, EMC, and VMware best practices. September 2010

2 Copyright 2010 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part number: h

3 Table of Contents Executive summary... 5 Business case... 5 Solution overview... 5 Key results... 6 Additional feature support... 6 Introduction... 7 Purpose... 7 Scope... 7 Audience... 7 Key components... 8 Component list... 8 EMC CLARiiON CX VMware vsphere... 8 EMC PowerPath/VE... 9 Physical architecture Overview Physical architecture diagram Environment profile Hardware Virtual allocation Software Farm Solution design and validation Overview VMware infrastructure Microsoft SQL Server Microsoft SharePoint 2010 VM resources Configuration observations Test methodology Introduction Data population Testing tools Load generation Acceptable user response times SharePoint user profiles Introduction Browse Search Modify Profile mix

4 Maximum user capacity calculation Test results: 80% Browse, 10% Search, 10% Modify Introduction Tests passed per second Average times per operation type Average CPU utilization (%) Average and maximum IOPS ESX server and virtual machine CPU and memory utilization Test results: 70% Browse, 5% Search, 25% Modify Introduction Tests passed per second Average times per operation type Average CPU utilization (%) Average and maximum IOPS ESX server and virtual machine CPU and memory utilization Test results: 50% Browse, 20% Search, 30% Modify Introduction Tests passed per second Average times per operation type Average CPU utilization (%) Average and maximum IOPS ESX server and virtual machine CPU and memory utilization Conclusion Summary Optimal storage design Simplified host environment configuration Cost effectiveness Support for future growth Next steps

5 Executive summary Business case Microsoft Office SharePoint 2010 has easily found a place in the core business application platforms of many organizations. With its rich functionality, SharePoint integrates easily with core business systems, and therefore quickly becomes a mission-critical application. Customers are looking for best practices on how to set up a SharePoint farm where performance does not degrade as the farm scales. In addition, more and more customers are moving to hyper-consolidated, virtualized data centers and private clouds, which increases the potential for performance issues and underscores the importance of understanding the best practices. The robust search functionality built into SharePoint provides an ideal platform for content management, business collaboration, workflow processes, and other productivity functions, including business intelligence and information accessibility. For this reason also, SharePoint is a critical business platform that must be appropriately protected. SharePoint 2010 adds even more extensibility to application designers, such as Business Connectivity Services (BDC), whereby SharePoint designers can now directly integrate large amounts of data from external services and databases. Faced with the challenge of continuing to meet SharePoint service level agreements (SLA) as a business-critical application, IT resources are stretched to do more, and faster, while continuing to manage IT costs and business disruption risks. Not only do organizations need to manage demands for SharePoint availability and protection, they also need to guarantee preparedness for future growth, while ensuring data center efficiency. Solution overview Understanding the exact requirements to build a well-performing, enterprise-class SharePoint 2010 farm can be a daunting challenge for any IT professional. With such a federated collaboration platform and so many moving parts, each with varying and different needs in terms of CPU, network, and storage, building the right solution becomes nearly impossible without proper guidance. Getting it right the first time is critical. This solution represents a well-performing, enterprise-class SharePoint 2010 farm that is cost-effective, scalable, and highly available. EMC technology and expertise ensure that the solution operates at maximum efficiency while being both manageable and sustainable. An EMC CLARiiON CX4-240 array provides storage and consolidation. VMware vsphere virtualization, in conjunction with VMware High Availability, provides server high availability and consolidation for the entire SharePoint farm. VMware vcenter Server monitors ESX host utilization and ensures that all available host server hardware is evenly utilized for optimal farm performance. The solution illustrates large-scale performance testing of a SharePoint 2010 farm to show how the components of the farm scale and how EMC recommends building the configuration according to Microsoft, EMC, and VMware best practices. 5

6 Key results The key results of the solution validation testing are as follows: The SharePoint farm configured for this solution sustains a maximum capacity of greater than 200,000 users. Storage consolidation is the key to enabling future protection of federated environments in a consistent manner. The EMC CLARiiON CX4-240 provides excellent storage consolidation performance and flexibility. Distributed storage models do not support this. EMC Navisphere Manager and VMware vcenter provide excellent overall end-toend solution management. VMware vsphere 4.0, with its eight-vcpu support, ensures that CPU-dependent virtual machines, such as SQL servers, have enough processing bandwidth to sustain the farm s required performance. Additional feature support The solution supports the following additional features, which can be implemented at any time. Note These features were not tested as part of the validation exercise but serve as examples of extensibility. Rapid backup and recovery using EMC Replication Manager Automated disaster recovery integration using EMC RecoverPoint and VMware Site Recovery Manager (SRM) Remote BLOB storage using EMC SourceOne archiving Protection against potential data leaks using RSA Data Loss Prevention 6

7 Introduction Purpose This white paper is the result of a collaborative effort between application experts at both EMC and Microsoft Corporation. The paper demonstrates a best-in-breed solution for growing SharePoint farms that ensures availability, scalability, and protection. This paper is intended to be used by customers and EMC field personnel as a guide to designing and building a virtualized SharePoint 2010 farm on EMC CLARiiON CX4-240 storage arrays with predictable results. Scope This white paper illustrates how EMC technologies can help streamline, consolidate, and simplify enterprise-class Microsoft Office SharePoint 2010 virtual environments, transforming them into high-performance, scalable solutions. Specifically, this paper describes: Creating a well-performing storage design for a virtualized Microsoft SharePoint 2010 farm on an EMC CLARiiON CX4-240 with a large and very active database. Designing and deploying a SharePoint 2010 farm on VMware vsphere servers. Reporting the performance of the SharePoint 2010 farm under heavy user load. The customer s application experience was a paramount concern during the planning and testing of this environment. This white paper shows how the customer can reduce the cost of a SharePoint investment while ensuring the best levels of performance and availability. The follow-on requirements of rapid backup, automated disaster recovery, archiving, and security were also taken into consideration during the design phase of this solution. Audience The target audience for this white paper includes EMC internal development teams, professional services groups, and system integration partners who are tasked with deploying Microsoft SharePoint 2010 in a customer environment. The paper is also appropriate for customers interested in planning and installing Microsoft SharePoint

8 Key components Component list This section identifies and briefly describes the major components of the validated solution environment. The components are: EMC CLARiiON CX4-240 EMC PowerPath /VE VMware vsphere 4.0 VMware vcenter Server 4.0 EMC CLARiiON CX4-240 Storage performance is the cornerstone on which a well-performing SharePoint environment is built on. Virtualization high availability requires a flexible, shared storage solution. EMC CLARiiON CX4 series arrays meet both of these requirements. EMC CLARiiON CX4 model 240 provides a powerful networked storage system that scales seamlessly (up to 231 TB of capacity) so more applications can be consolidated. The CLARiiON CX4-240 combines CLARiiON s proven five 9s ( percent) availability with innovative technologies such as Flash drives, Virtual Provisioning, a 64-bit operating system, and multi-core processors. The CLARiiON CX4-240 provides UltraFlex technology with dual-protocol (iscsi and FC), online-expandable connectivity options, and the ability to integrate future technologies. With the CLARiiON CX4-240, customers can exploit CX4 advanced functionality to protect data from unexpected events and to decrease energy use. VMware vsphere VMware vsphere 4, the industry s most widely deployed virtualization platform, delivers the only foundation to transform data centers into dynamic, simplified infrastructures for private, public, and hybrid cloud environments. The most comprehensive set of unique capabilities for availability, security, resource optimization, and business continuity have established VMware vsphere as the platform of choice for customers of any size. VMware vsphere abstracts applications and information from the complexity of underlying infrastructure, creating internal cloud infrastructure so IT can focus on the support and enablement of business value. Benefits include: Reduced costs and maximum IT efficiency Increased IT control through service level automation Empowered IT departments with choice 8

9 EMC PowerPath/VE EMC PowerPath/VE delivers PowerPath multipathing features to optimize VMware vsphere virtual environments. With PowerPath/VE, standardized path management can be achieved across heterogeneous physical, and virtual environments. PowerPath/VE enables automated optimal server, storage, and path utilization in a dynamic virtual environment. This eliminates the need to manually load balance hundreds or thousands of VMs and I/O-intensive applications in hyper-consolidated environments. 9

10 Physical architecture Overview The environment consists of three VMware vsphere servers, which contain the entire infrastructure required to operate a SharePoint 2010 farm, including domain controllers, application servers, and Web front ends (WFEs). Microsoft SharePoint Server 2010 uses Microsoft SQL Server 2008 as its data store. EMC CLARiiON CX4-240 provides flexible, highly available storage while ensuring adequate performance to the entire SharePoint farm. VMware vsphere enables server consolidation through virtualization. Physical architecture diagram The following diagram depicts the overall physical architecture of the validated solution environment. 10

11 Environment profile Hardware resources The following table lists the hardware used to validate the solution in this document. Equipment Quantity Configuration Storage array 1 EMC CLARiiON CX4-240 with: 8 FC ports and 4 iscsi ports per SP FLARE * 450 GB / 15k rpm FC drives VMware ESX hosts 3 4-socket quad-core (16 cores) Xeon X GHz, 48 GB RAM VMware vcenter server 1 4-socket quad-core Xeon X GHz, 16 GB RAM Network switch 2 48-port stacked network switches Fiber Channel switch 2 32-port Fibre Channel 4 GB switches Virtual allocation The virtual allocation of hardware resources used in the environment is listed below. Virtual machine role Quantity Configuration Web front end (WFE) 6 4 vcpus, 8 GB RAM Application servers 2 2 vcpus, 4 GB RAM Crawl server 2 4 vcpus, 8 GB RAM Query servers 2 4 vcpus, 8 GB RAM MS SQL servers 2 8 vcpus, 32 GB RAM Domain controllers 2 2 vcpus, 4 GB RAM 11

12 Software resources The following table lists the software used to validate the solution in this document. Software Version Windows Server 2008 Enterprise edition R2 RTM VMware vsphere 4.0 Microsoft SQL Server 2008 (64-bit Enterprise edition) Microsoft Office SharePoint Server 2010 SP1 RTM PowerPath (with VE capabilities) 5.4 Visual Studio Test Suite 2008 Sp1 KnowledgeLake Docloader 1.1 Farm resources The following table lists the SharePoint server farm resources. Item Quantity / type / size SharePoint farm user data 1 TB Concurrency 1% Site collections 10 Sites per site collection 1 VMware VSphere servers (physical) 3 nodes Microsoft SQL 2008 servers (VMs) 2 Web front ends (VMs) 6 Application servers (VMs, also hosting Central Admin) 2 SharePoint 2010 Crawl server (VM) 2 SharePoint Query server (VM) 2 12

13 Solution design and validation Overview The sequence of activities to validate the design of the environment was: Identify the steps required to design and implement an enterprise-level SharePoint Server farm solution around EMC software and hardware Deploy an enterprise SharePoint 2010 farm on the CLARiiON CX4-240 platform Performance test the farm on a vsphere architecture by running a set of workloads generated by KnowledgeLake VSTS simulation code SharePoint farm configuration The SharePoint farm was designed as a publishing portal. There was 1 TB of user content consisting of 10 SharePoint site collections (document centers), each populated with 100 GB of random user data. The SharePoint content databases were: 110 GB data files on 130 GB LUNs (this fill factor layout addresses the potential and expected content database data file growth due to SQL index rebuilds and SharePoint sprawl) 9 GB log files on 10 GB LUNs (SharePoint database log files can grow rapidly due to modifications and uploads of files - binary large objects (BLOBs). SharePoint 2010 storage best practices The TempDB databases resided on RAID 1/0 LUNs according to SQL Server 2008 best practices The Search Databases (Property Store and Crawl Store) resided on RAID 1/0 LUNs, since these databases experienced some of the highest I/O in the farm. Each of these databases was allocated a 100 GB LUN, which, in total, constituted 10% of the farm content. The Content Databases resided on RAID 5 LUNs, since the I/Os for these databases were relatively low. In SharePoint 2010, the Crawl Server Index LUNs hold only incremental crawl data and are therefore much smaller than they were in SharePoint The LUNs can now be just a few gigabytes, even for a 1 TB ContentDB. The Crawl Server Index resided on RAID 5 LUNs. The Query Server Index LUNs were relatively small since the index was partitioned between them. In this solution, each of the two Query servers contained half of the Content Index files. The Query Server Index resided on RAID 5 LUNs. 13

14 SharePoint search configuration SharePoint 2010 s new Search Server introduces new design considerations in a SharePoint farm. Previously, in SharePoint 2007, the Search service consisted of a Crawl server that crawled and maintains its Search content index files, which were then replicated fully to each Query server. Metadata about the content index was held within the SSP search database on the SQL server. Disparity between these two index stores led to the need for a full crawl of all the content data. SharePoint 2007 supported only a single Crawl server, which exposed a single point of failure. In SharePoint 2010, the Search server consists of Crawl servers whose function is purely to crawl and populate the Crawl and Property stores on the SQL server. These crawl servers no longer need to host the content index store. The Query servers split the content between themselves so that each of them holds only a subset of the content index files and queries are distributed between them. The Property Store is the authoritative source for all indexed content and does not need to be in sync with the Crawl servers. Because of these differences between SharePoint 2007 and SharePoint 2010, the Crawl servers now use very little space purely for caching (500 MB) instead of 5% to 30% of user content size. The Search service now apportions and distributes the index content across the Query servers. Office SharePoint Search Server service (OSearch) was used for this solution Search was configured with two Crawl (formerly Index) servers. The Search Index for crawling was partitioned between the two Crawl servers. Search was configured with two Query servers. The search index was split between the two Query servers. The SharePoint 2010 Property Store database resided on a dedicated RAID 1/0 LUN. This database is the search repository. The SharePoint 2010 Crawl Store database resided on a dedicated RAID 1/0 LUN. This database is used when an incremental crawl is done and updates are necessary. Incremental crawls were set to occur every 15 minutes. Network configuration SharePoint best practices for networking were adhered to and dedicated virtual local area networks (VLANs) and NICs were used to set boundaries to aid in security and performance of the farm as an entity. A distributed switch was created in vsphere for both the public and private networks. The WFEs were dual-homed in order to create a logical boundary between the client and data center back-end networks. The SQL servers used only the private network. 14

15 Disk layout This environment used sizing of 100 GB for each SQL SharePoint 2010 content database. A total of 1 TB of user data (equating to 4,600,000 documents) was split into 10 x 100 GB content databases on 130 GB volumes, which was spread across 5 x 400 GB disks using RAID 5 for redundancy. All VMs used the CX4-240 for operating systems and content drives. Search and TempDB databases were allocated RAID 1/0 LUNs. Volume layout Enclosure RAID Group RAID Type Volumes 0_0 0 R5 1 R5 SharePoint Configuration Databases SQL System Databases DC, Application, Index and Query OS Index data Content Database Logs WFE, SQL and Query OS Query data 1_2 2 R5 Content Databases 0_2 and 1_2 5 R1/0 6 R1/0 Search Databases SQL Temp Databases Search Databases SQL Temp Databases 0_2 and 1_2 20 and 21 HS Hot Spares Note: Refer to the disk layout diagram, above, for RAID groups. 15

16 VMware infrastructure VMware VSphere 4.0 was installed on 3 servers to host the farm VMs. A distributed switch was created for the public and private networks. The VMs were distributed as evenly as possible across the 3 servers. All VM boot disks were VMDKs in data stores on the CLARiiON. All secondary disks were raw devices (RDM) on the CLARiiON. RDMs were chosen to provide greater flexibility for future use with products such as Microsoft Clustering and EMC Replication Manager. A separate physical vcenter server was used for configuring and maintaining the farm VMs. Microsoft SQL Server 2008 This environment used sizing of 100 GB for each SQL SharePoint 2010 content database. Two database servers were used to maximize SQL performance. One database server held the SQL internal and SharePoint internal databases, including the Search Database and five Content Databases. The other SQL server held an additional five Content Databases. There were two 100 GB Temp Databases and a 20 GB Temp Database log file for each SQL server. The Property Store Database used 31 GB of a 100 GB LUN and the Crawl Store Database used 26 GB of a 100 GB LUN. The Property and Crawl Store log files shared a 30 GB LUN. All of these LUNs were allocated on two RAID 1/0 RAID groups. Microsoft SharePoint 2010 VM resources Since the WFEs were CPU intensive, each WFE virtual machine was allocated four virtual CPUs. An Application server was configured as the Central Administration server, and one generalized application server was used for farm purposes; for example, for document conversions. Since crawling is a CPU-intensive activity the Crawl servers were configured with four virtual CPUs. To improve the crawl speed, the Crawl servers also ran a dedicated WFE role so that the WFEs were not affected by crawls. In addition, there were two Query servers for search purposes. Configuration observations Two Query servers and two Crawl servers provided the optimal search configuration for the environment, which also provided search resiliency. Two SQL servers were utilized in a scale-out approach to offer additional performance and workload isolation. The EMC CLARiiON CX4-240 had significant additional capacity to service future workloads. 16

17 Test methodology Introduction This section describes the approach and methodology used when testing the environment. Data population The data population tool used a set of sample documents. Altering the document name and metadata (before insertion) made each document unique. There was one load agent host for each WFE, allowing data to be loaded in parallel until the target of 1 TB = 4.6 million documents was reached. The data was spread evenly across the 10 site collections (each collection was a unique content database). Testing tools To simulate load on the SharePoint farm, Microsoft VSTS was used. A client load emulation tool provided by an independent third-party vendor (KnowledgeLake, Inc., an accredited Microsoft Gold Partner) was used to ensure that the SharePoint farm was operating at optimal performance. Load generation To generate and emulate client load, Microsoft VSTS 2008 was used in conjunction with KnowledgeLake code to simulate real-world SharePoint user activity. The VSTS team test rig consisted of a controller and six VSTS team agent hosts. The controller evenly distributed client load across the agent hosts, which evenly distributed the load across the WFEs. Acceptable user response times The following table presents the acceptable user response times for SharePoint operations. The CLARiiON CX4-240 was not stressed during maximum user testing, SP utilization did not exceed 10%, and LUN utilization was within acceptable parameters. Type of operation Example Acceptable user response time Common Browse < 3 seconds Common Search < 3 seconds Uncommon Modify < 5 seconds 17

18 SharePoint user profiles Introduction The user profiles consisted of a mix of three user operations: Browse, Search, and Modify. Browse In a Browse test, the code simulates a user browsing a site until the user reaches an end document listing that contains no subpages. Search In a Search test, the code simulates a user running a stored procedure in the SQL database to find a unique number, in this case an SSN (Social Security Number). The code then performs a web request to search for that unique number. Modify In a Modify test, the code simulates a user retrieving a document. The document ID is extracted from the database prior to each test run. The code then modifies the metadata for that document before saving it back to the farm in its modified form. Profile mix A common mix of user profiles was used to emulate different types of business organizations. For example, some organizations are browse-intensive, while others are search, and/or modify-intensive. User profile Profiles tested Browse / Search / Modify 80/10/10, 70/05/25, 50/20/30 All tests were run from a load controller host that spread the load evenly across each of the six load agent hosts. The load controller host also collected performance metrics for analysis from all of the load agents and hosts in the farm. 18

19 Maximum user capacity calculation All users adhered to a Microsoft Heavy User profile, which specifies 60 requests per hour. A think time of 0% was applied to all tests. 0% think time is the elimination of typical user decision-making time when browsing, searching, or modifying using Office SharePoint Server. Every user request is completed from start to finish without a pause, which generates a continuous workload on the system. The maximum user capacity is derived from the following formula: # = seconds per hour / RPH / Concurrency% * RPS Example: 3600 / 60 / 1% * = 204,900 Example: 3600 / 60 / 10% * = 20,490 (supported user capacity for 10% concurrency) 19

20 Test results: 80% Browse, 10% Search, 10% Modify Introduction The following graphs and table illustrate the results of the 80% Browse, 10% Search, 10% Modify test. The test simulated a read-intensive user profile, which is typical for an organization in which users perform browsing and light collaboration. The environment supported 204,900 Heavy Users (as defined by Microsoft) with 1% concurrency. Tests passed per second Average number of tests passed per second was

21 Average times per operation type The Microsoft-recommended limit for SharePoint operations is 3 seconds per operation. Average times per operation type (in seconds) were: Browse: 2.93 Search: 1.05 Modify:

22 Average CPU utilization (%) Average CPU utilization percentages for each server or server type were: SQL-01: 43.92% SQL-02: 18.15% WFEs: 91.02% Query servers: 5.63% Crawl servers: 3.94% SQL-01 server was busier than SQL-02 because the SharePoint databases, including the search databases, reside on SQL-01. The limiting factor for the SharePoint farm was the WFEs. At 90% CPU utilization, performance began to decrease. Since this was a browse-intensive profile with relatively few modify or search operations, the CPU usage for Index and Query servers was very low. The Crawl server spikes were caused by the incremental crawls (every 15 minutes). 22

23 Average and maximum IOPS Average IOPS for OSs, DBs, and Stores were: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: Maximum IOPS for OSs, DBs, and Stores were: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: Incremental crawls scheduled every 15 minutes caused the Property and Crawl Store spikes. IIS activity caused the WFE OS LUNs to have the highest IOPS. 23

24 ESX server and virtual machine CPU and memory utilization The following table shows the ESX server and virtual machine CPU and memory utilization during testing. Server / VM Average CPU utilization (%) R Average memory consumed (GB) DC App WFE WFE SQL R Index Query WFE WFE SQL R DC App Index Query WFE WFE

25 Test results: 70% Browse, 5% Search, 25% Modify Introduction The following graphs and table illustrate the results of the 70% Browse, 5% Search, 25% Modify test. The test simulated a profile that is typical for an organization in which users perform heavy collaboration but a low ratio of search activities.the test supported 200,820 users with 1% concurrency. Tests passed per second Average number of tests passed per second was

26 Average times per operation type The Microsoft-recommended limit for SharePoint operations is 3 seconds per operation. Average times per operation type (in seconds) were: Browse: 2.58 Search: 0.91 Modify:

27 Average CPU utilization (%) Average CPU utilization percentages for each server or server type were: SQL-01: 50.73% SQL-02: 21.01% WFEs: 93.40% Query servers: 3.00% Crawl servers: 7.12% The relatively high ratio of Modify operations caused the SQL servers and WFEs to have a higher CPU load. The Modify operations also caused a relatively high number of documents to be incrementally indexed, resulting in the Crawl server exhibiting a higher CPU load. 27

28 Average and maximum IOPS Average IOPS for OSs, DBs, and Stores were as follows: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: Maximum IOPS for OSs, DBs, and Stores were as follows: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: A relatively high number of Modify operations caused higher IOPS across all LUNs. 28

29 ESX server and virtual machine CPU and memory utilization The following table shows the ESX server and virtual machine CPU and memory utilization during testing. Server / VM Average CPU utilization (%) R Average memory consumed (GB) DC App WFE WFE SQL R Index Query WFE WFE SQL R DC App Index Query WFE ,97 WFE

30 Test results: 50% Browse, 20% Search, 30% Modify Introduction The following graphs and table illustrate the results of the 50% Browse, 20% Search, 30% Modify test. The test simulated a 212,340-user profile at 1% concurrency, which is typical for an organization in which users perform both heavy collaboration and a high ratio of search activities. Tests passed per second Average number of tests passed per second was

31 Average times per operation type The Microsoft-recommended limit for SharePoint operations is 3 seconds per operation. Average times per operation type (in seconds) were: Browse: 2.86 Search: 1.10 Modify: 1.52 Average CPU utilization (%) Average CPU utilization for each server or server type was as follows: SQL-01: 53.59% SQL-02: 22.23% WFEs: 90.62% Query servers: 14.04% Crawl servers: 8.68% 31

32 Average and maximum IOPS Average IOPS for OSs, DBs, and Stores were as follows: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: Maximum IOPS for OSs, DBs, and Stores were as follows: WFE OS: Content DBs: Property Store: Crawl Store: Temp DB: A relatively high number of both Modify and Search operations caused higher IOPS across all LUNs. 32

33 ESX server and virtual machine CPU and memory utilization The following table shows the ESX server and virtual machine CPU and memory utilization during testing. Server / VM Average CPU utilization (%) R Average memory consumed (GB) DC App WFE WFE SQL R Index Query WFE WFE SQL R DC App Index Query WFE WFE

34 Conclusion Summary This solution illustrates the power of combining EMC CLARiiON CX4 series storage arrays with the virtualization capabilities of VMware vsphere 4.0. The solution: Provides a consolidated, well-performing storage platform for large federated application environments such as enterprise SharePoint 2010 environments Maximizes SharePoint application performance and availability through a design built on best practices at all layers of the solution Minimizes TCO and maximizes ROI of the solution investment at all component levels servers, infrastructure connectivity, and storage Exemplifies ease of deployment, management, and support of such complex environments with an integrated management approach Offers business and application owners a solid, scalable solution with predicable results, which is capable of growing with business requirements Optimal storage design Storage design for SharePoint is a daunting task, especially when a new major version such as SharePoint 2010 is released and requirements are not, as yet, fully known. This solution illustrates that storage requirements can be classified for each SharePoint storage element from a virtual machine boot volume, to an application volume, to a SQL volume. Simplified host environment configuration In the context of an enterprise SharePoint 2010 environment, the profiling of server hardware requirements and the creation and deployment of virtual machines and application volumes are simplified and made more efficient using VMware technologies. Cost effectiveness Storage efficiency is maximized in a single storage platform; in this instance, an EMC CLARiiON CX4-240 storage array. TCO is minimized through VMware virtualization, resulting in the reduction of servers, power, and cooling requirements, floor space, and connectivity requirements. Support for future growth Farm sustainability and growth are achieved through the EMC CLARiiON CX4 series array, which provides storage that is highly available and provides scalability for all components of the solution, from the virtual machines to the SQL Server storage. Next steps To learn more about this and other solutions, contact an EMC representative or visit: 34