HP Sizer for Microsoft SharePoint solicits data or uses built-in defaults to determine optimal configurations based on SharePoint deployment best practices. Selectable configurations include entry level, highly available, and application optimized solutions. A "what if" feature allows rapid comparison of the effects of workload changes, platform and storage technology selection, and provides role-based server configurations, capacity utilization, and estimated network traffic. Users can select a configuration and then customize their environment by adding or substituting components within best-practice guidelines.

The tool also addresses one of the most critical areas of SharePoint server design: performance and capacity planning for the storage subsystem. Its storage sizing and configuration capabilities offer detailed best-practice storage volume and RAID recommendations to support database and content storage needs using HP direct-attach storage, HP StorageWorks MSA or EVA Storage SAN solutions.

» Download HP Sizer for Microsoft SharePoint 2010

» Download HP Sizer for Microsoft Office SharePoint Server 2007

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.

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.

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.

In The Shortcut Guide to Untangling the Difference Between High Availability and Disaster Recovery, author and IT expert Richard Siddaway examines HA and DR, and explains how understanding the many differences between the two will allow you to create a proper system to guard against application downtime. Siddaway offers his insight not only on how technology can be used in HA and DR solutions, but also how management of the human element must factor into any successful HA / DR solution.

Download:
http://nexus.realtimepublishers.com/sgudb.php

Download:
http://nexus.realtimepublishers.com/sgscms.php

Chapter 2: Taming Storage Growth—A Modern Perspective

Chapter 3: Data Path Optimization for Enterprise File Serving

Chapter 4: Building High-Performance, Scalable, and Resilient Windows File Serving Solutions

Chapter 5: Building High-Performance, Scalable, and Resilient Linux File-Serving Solutions

Chapter 6: Managing High-Performance, Scalable, and Resilient Data Across the Enterprise