SharePoint Search 2010 in a Small Scale Farm - Hardware

Hello, my name is Hernando Silva and, as some of you might know from Dan's previous posts , for the last year I participated in the planning, deployment and management of the SharePoint 2010 Search service at a small scale.

In this post I will begin to introduce you to our Divisional (a.k.a. Departmental) farm for the Office organization. This deployment was intentionally planned to be oversized to make sure that it would scale to accommodate pre-released builds of SharePoint 2010 and other products (see the capacity planning document for the definition of a Divisional Portal and, also, take a look at this case study for more details about this specific deployment). In working with Dan in this series of posts, I hope to provide additional knowledge based on what we learned in some of the smaller scale deployments. 

We wanted to use this farm to ensure that we would satisfy our goals for query latency and crawl freshness, on a deployment of this scale.

We did interesting experiments in this deployment, like using Solid State Disks for our SQL server, use site data to redirect the crawl to the crawl target server, use resource governor in SQL to control the behavior of the crawl, etc. I will try to explain all those experiments in further posts so you can learn about them and use them according to your needs. 

Hardware & Topology

The Office organization has about 7.3 M items stored in the farm, distributed over 25 Content DBs, which require about 1.9 TB in our Content SQL server. 

The SharePoint 2010 Search service disk space usage was as follows:

SQL Server:

· Admin DB: 1.8 GB

· Crawl DB: 167 GB

· Property Store DB: 34 GB

Query Server:

· About 25 GB of per Query Server for the index. 

From the Search point of view the hardware was designed to help us satisfy 2 major requests, sub-second query latencies and crawl freshness of about 5 minutes.

The roles for the servers in our Divisional farm are:

· 1 Web Front-Ends.

· 2 Web Front-Ends combined with a Query Server & the Search Query and Site Settings Service

· 1 Web Front dedicated as a Search crawl target (this server does not participate in NLB)

· 3 App servers, which are used for non-Search activities

· 1 Search crawler

· 3 SQL servers

o Content Databases

o Usage and Analytics Databases

o Search Databases. 

Graphically, the topology of the farm looks like:

Below, is the detailed description of the servers that are being used by the SharePoint 2010 Search service.

Web Servers Specs 

There are four Web servers in the farm. 3 are used to serve content (2 of which are also used as the Search Query/Search Query and Site Settings Servers). The other server is used as the search crawl target (to reduce the load on our content servers while search is crawling)

Search Crawler Specs 

There is one SharePoint 2010 Search crawler server in the farm.

* These drives were big ,not because of a requirement from the product, but because they were readily available at the time when the hardware was being configured

Database Servers Specs 

This is the database server that is dedicated to SharePoint 2010 Search.

At this point, many of you might be wondering why did we decided to go with this topology. No worries… in the next posting I will drill down into the topology components and the reasoning behind those choices, so … stay tuned! 

Hernando Silva

Software Engineer in Test

Microsoft Corp