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:
· Admin DB: 1.8 GB
· Crawl DB: 167 GB
· Property Store DB: 34 GB
· 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)
2 quad core @2.33 GHz
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 2: Swap and BLOB Cache
Number of NICs
SharePoint Server 2010 (pre-release version)
Services running locally
Query Server/Search Query and Site Settings
Search Crawler Specs
There is one SharePoint 2010 Search crawler server in the farm.
2 quad core @2.5GHz Xeon
Windows Server 2008 R2, 64 bit
4x136GB 15K SAS (2 RAID 1 Disks)
2x418GB 15K, SAS (RAID 1) *
* 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.
SQL Server - Search DBs
2 quad core @3.2 GHz
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
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!
Software Engineer in Test