Search in SharePoint 2013 has been completely redesigned, providing a new scalable and flexible architecture. To provide a powerful search solution, the base of your search topology must be solid. This requires some basic understandings of search, and how it is designed to provide the scalability and extensibility. Unless your search topology would make impact on the whole farm from the performance perspective.
Having talked with many folks about Search in SharePoint 2013, I have realized that they still think something not correct in basis of SharePoint search, even from seasoned SharePoint developers. With a little hope to help people mitigate problem and save time when implementing Search in SharePoint 2013, this article is going to give you the list of common misunderstandings that I have collected.
Starting Search service is to make search functionality work
Because SharePoint folks see SharePoint Server Search in Manage Services on Server page, they think that to make search functionality work, they simply need to start SharePoint search-related services, specially SharePoint Server Search service on servers
In fact, these services need to work together with search components which are provisioned after you create a new search service application. In which, Search Host Controller service manages the search components. Search Query and Site Settings Service is called by web front-end to handle queries depending on where search query component is allocated.
Without search components running, starting these services will not make search functionality work.
Each web application requires a search service application
This is not really a misunderstanding in SharePoint 2013 search. However, having such in mind, your search topology will probably become a burden to your farm. When creating a new search service application, it automatically provisions 6 search components: Admin, Crawl, Content Processing, Analytics Processing, Index and Query Processing. Because these components trigger noderunner.exe which consumes pretty much memory, if you have many search service application your server will have some problems with performance some time. I have recently involved in explaining and proposing a new search architecture for a big farm which has totally 6 search service application. Each of the search service applications serves for a dedicated content source. The most common scenario you need to have each service application for a web application is in shared SharePoint hosting where and you don’t want to utilize the capability of multi-tenancy. In this scenario, each web application is an instance of a customer/organization.
If you want to schedule or to have dedicated crawling configuration, you can create a new content source, but all are supposed to be in the same search service application. This approach is to provide a consolidated search framework serving for different SharePoint-based applications in your farm.
There is only server playing Search role in your farm
Many farm architecture documentation I’m in charge of review have the same design in which there is a dedicated server hosting all search components. Imagine your farm has 3 public facing websites serving for thousands of people every day with search-intensive customization. Your search server in this case would go into overloading. Having a dedicated search server is proper design. However we can distribute workload by hosting different components on different servers. Being said, search component can be deployed into multiple servers. For example, you can have search query component on the web front-end server while the others are on application servers. In this case, saying your farm having a dedicated server is no longer true.
I’m not saying you can’t use a dedicated server for Search. What I want to indicate here is that the perception should be changed in order to design a performance-protective SharePoint farm including search.
I would say this is the most of most common misunderstandings. For those who are even familiar with SharePoint farm or development, they still think having a pair of search service applications is a good direction for high availability of search. This is completely wrong. There is no way to specify a server to deploy a search service application. Imagine if a server goes down, how can your search continue functioning?
High availability in search from the view of logical architecture is to have a set of search components running on two servers. If a server can’t function search query for instance, search query and site setting services will load balance the query to another server where there is one query component running.
Having a high availability at database layer is also a worth consideration for search.
This article is a good companion along with you when you plan for search topology. Search in SharePoint 2013 is not complicated. It’s really flexible and can be scaled out very quickly. Before designing search topology, stick all these misunderstandings into your notebook.