SharePoint 2013 has certainly raised the bar on the hardware requirements for SharePoint. Where you previously with SharePoint Foundation (SPF) 2010 could get away with a four-core CPU and 8 GB ram and having search work ok, the recommendation in 2013 for a single server farm would look more like 8 cores and 32GB ram. That is double the CPU and four times the RAM, which most likely will take you from one over to two servers. If you are thinking above SPF, then the hardware impact is even bigger, which is needed for Scaling Search in SharePoint 2013.

Note: The reference for the above requirements consists of the requirements for a single server (http://technet.microsoft.com/en-us/library/cc262485.aspx) and the search requirements (http://technet.microsoft.com/en-us/library/jj219628.aspx) combined.

Looking at the above leap in hardware requirements from 2010 to 2013, you see that search is a real resource hog. Coming from the FAST world this is nothing new. FAST ESP had no problem utilizing a lot of CPU, RAM and disk IO, which was carried over to FAST Search Server 2010 for SharePoint, and now is fully embedded in SharePoint 2013. The good thing with the FAST search architecture is that it scales linearly by adding more hardware, at least seen from an architectural point of view.

SharePoint 2013 itself also require more hardware compared to 2010 due to other new components like the distributed cache, the new workflow engine and Office Web Apps which now have to run on its own server(s). Factoring in high availability your minimal farm, without SQL server, typically will look like this:

• 2x Web Front Ends
• 2x App Servers
• 2x Dedicated Search Servers
• 2x Office Web Apps

You could very well host search on the app servers, but if you are also hosting the distributed cache on those servers you may run into weird issues as both the distributed cache and search like to have ample RAM and CPU, and you do not want them to race for the resources.

A typical customer response I often get to this setup is: “That’s an awful lot of servers!”, and frankly, it is. Depending on the number of users and your requirements for high availability, you may scale this down and still have a working farm. However, as content volume grows and search usage increases, you may run into issues. One agile approach is to start with a smaller farm, and then expand it and move components around as needed. The search topology in particular is “somewhat” easy to expand and you can move the components around while running live. If this is your strategy, make sure to test it out before you move into production to make sure you know all the steps involved. One possible solution as outlined in the Internet Sites Search Architectures for SharePoint 2013 is to host the index replicas on the WFE’s.

The rough guidelines for search is that each index partition (one partition or replica per server) can hold up to 10 million items. If you go above this number, you will start seeing index and query latency issues. A rule of thumb query wise is that each CPU core can serve up to four queries per second (QPS). What this means is that a four-core server may deliver up to 16 QPS, and if you have two servers for high availability you may double this numbers as both the primary partition and the replica will deliver search results. Actual QPS numbers will depend on physical vs. virtual servers as well as other components hosted on the servers and peak times.

With all this information in mind, how do you actually scale your search architecture to perfection? The answer is that there is no easy answer. It all depend on the number of items you have to index, what types of items those are (documents, pages, list items), how many users do you have, how often do they search, do you have a lot of search driven pages using the Content By Search web part or similar?
My suggestion is that you start with at least one partition and one replica. If you host these one two App servers, on one WFE and one App server, or on two dedicated search servers is something you have to evaluate depending on the resources you have available, and for medium and small business it might also be a license and monetary issue. If your setup does not work out, then simply change it. To decide if it works or not check the analytics and graphs available on the Search Service Application as well as listen to your users.

References

SharePoint 2013: Capacity Planning, Sizing and High Availability for Search in SPC172 – http://social.technet.microsoft.com/wiki/contents/articles/16002.sharepoint-2013-capacity-planning-sizing-and-high-availability-for-search-in-spc172.aspx

Plan enterprise search architecture in SharePoint Server 2013 – http://technet.microsoft.com/en-us/library/dn342836.aspx

Scale search for performance and availability in SharePoint Server 2013 – http://technet.microsoft.com/en-us/library/jj219628.aspx

Best practices for organizing content for search in SharePoint Server 2013 – http://technet.microsoft.com/en-us/library/jj683124.aspx

If you have any questions or feedback on Mikael’s article please leave a comment below. We would love to hear from you.

Mikael Svenson is a principal Consultant at Puzzlepart where he develops SharePoint Business Apps and consults on SharePoint in general. Mikael is a search enthusiast at heart having authored “Working with Microsoft FAST Search Server 2010 for SharePoint” and also co-authored an upcoming book on SharePoint 2013.A three time SharePoint Server MVP, Mikael is a community contributor blogging on SharePoint as well as being on the board of the Norwegian SharePoint Community and SharePoint Saturday Oslo. Mikael is also a Microsoft Certified Trainer, delivering SharePoint courses when time allows.