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)
Server |
WFE/Query Server/QP |
Crawl Target |
Processor(s) |
2 quad core @2.33 GHz |
2 quad core @2.33 GHz |
RAM |
32 GB |
16 GB |
Operating system |
Windows Server® 2008, 64 bit |
Windows Server 2008, 64 bit |
Size of the SharePoint drive |
6x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS and Product Disk 2: Swap, BLOB Cache and Index Disk 3: Logs and Temp directory |
3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS and Product Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory |
Number of NICs |
2 |
2 |
NIC Speed |
1 Gigabit |
1 Gigabit |
Authentication |
NTLM |
NTLM |
Software version |
SharePoint Server 2010 (pre-release version) |
SharePoint Server 2010 (pre-release version) |
Services running locally |
Query Server/Search Query and Site Settings |
No services |
Search Crawler Specs
There is one SharePoint 2010 Search crawler server in the farm.
Server |
Search Crawler |
Processor(s) |
2 quad core @2.5GHz Xeon |
RAM |
16 GB |
Operating system |
Windows Server 2008 R2, 64 bit |
Size of the SharePoint drive |
4x136GB 15K SAS (2 RAID 1 Disks) 2x418GB 15K, SAS (RAID 1) * Disk 1: OS and Product Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory |
Number of NICs |
2 |
NIC Speed |
1 Gigabit |
Authentication |
NTLM |
Software version |
SharePoint Server 2010 (pre-release version) |
Services running locally |
Crawl Server |
* 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.
Server |
SQL Server - Search DBs |
Processor(s) |
2 quad core @3.2 GHz |
RAM |
32 GB |
OS |
Windows Server 2008 R2, 64-bit |
Storage and geometry |
2x136GB 15K SAS (RAID 0) 6x60GB Solid State Disks, SATA (RAID 5) Disk 1: OS. SQL Server y Swap Disk 2: Search and Temp DBs and log files |
Number of NICs |
2 |
NIC Speed |
1 Gigabit |
Authentication |
NTLM |
Software version |
SQL Server 2008 R2 (Pre-Release) |
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
Comments
Anonymous
June 29, 2010
will a dedicated crawler still work if you are on a virtualized server environment, both WFE and Application Server tier is virtualized here, by a dedicated crawler i mean a dedicated crawl target serverAnonymous
June 29, 2010
Yes, it should work. Having your hardware virtualized shouldn’t imply any differences in the behavior of the product (except, maybe, for performance) as long as your virtual machines satisfy the minimum hardware requirements.Anonymous
June 29, 2010
One more point. In SharePoint 2010 we changed the way how we define the dedicated crawler target and that will be explained in a future post.