Plan for redundancy (Search Server 2008)

Applies To: Microsoft Search Server 2008

 

Topic Last Modified: 2008-07-31

In this article:

• About redundancy

• Define server redundancy requirements

• Plan for a minimum level of server redundancy

• Choose a baseline server farm topology

• Plan query server redundancy

• Plan database server redundancy

• Evaluate the risks of server failures

This article describes the options for scaling out redundant server roles included in a Microsoft Search Server 2008 farm. After reading this article, you will be able to determine and record the redundancy options that are appropriate for the environment.

Before you read this topic, read the following topics:

• Plan to deploy Search Server 2008 or Search Server 2008 Express

• Determine hardware and software requirements (Search Server 2008)

• Plan for availability (Search Server 2008)

Note that Search Server 2008 and Search Server 2008 Express do not typically host content. Instead, they are primarily used to host Search services, crawl content on Windows SharePoint Services and Microsoft Office SharePoint Server farms or other remote content sources, and respond to queries. In some environments, Search Server 2008 and Search Server 2008 Express can be used to host content. If you plan to use Search Server 2008 or Search Server 2008 Express for hosting content, read the articles in Plan for performance and capacity (Windows SharePoint Services) to ensure that you understand the requirements for hosting content and running Search Server 2008 or Search Server 2008 Express in the same farm.

About redundancy

The term redundancy is often misinterpreted to be synonymous with availability. Although these concepts are related, they are not the same. Redundancy refers to the use of multiple servers in a load-balanced environment for any of several purposes, such as to improve farm performance, to scale out to accommodate additional users, and to improve availability.

Availability is a more specialized concept that refers to a multiple-server environment that is designed to accept connections and operate normally even when one or more of the servers in the farm are not operational. Therefore, availability implies redundancy, and additionally implies a failover mechanism and several other possible characteristics. However, a redundant system might not be highly available.

For more information about availability, see Plan for availability (Search Server 2008).

This article describes how to implement redundant servers in a Search Server 2008 farm.

Define server redundancy requirements

Search Server 2008 supports scalable server farms for capacity, performance, and availability. Typically, capacity is the first consideration in determining the number of server computers to start with. After factoring in performance, availability also plays a role in determining both the number of servers and the size or capacity of the server computers in a server farm.

By the end of this section, you will be able to determine whether you have to build expandable capacity into the server deployment topology by deploying redundant servers, or if it makes sense for the organization to plan for a limited server deployment that has no redundant servers.

Plan for a minimum level of server redundancy

To deploy a redundant solution, you must deploy a server farm.

There are several different server topologies that can be used as a baseline. Each of these topologies builds in a level of server redundancy. This section summarizes these server farms.

Note

In the following descriptions, we refer to servers on which the index role has been installed as index servers, and servers on which the query role has been installed as query servers.

Redundant topologies

This sections contains examples of redundant topologies.

Five or more server farm

The optimal redundant server farm topology introduces a separate index server and consists of five or more server computers, including at least two database server computers in a clustered configuration and at least two query server computers.

Given this topology, you can install the index server role on the dedicated application server. This design optimizes the performance of the query server computers by enabling you to offload indexing to the middle tier.

Note that this topology shows a SQL Server clustering configuration that provides manual failover. For more information about how to configure a SQL Server cluster for automatic failover, see SQL Server 2005 Failover Clustering White Paper or Installing a SQL Server 2008 Failover Cluster, depending on which version of SQL Server you are using.

Four-server farm

The smallest server farm that builds in redundancy consists of four servers:

• Servers 1 and 2: Query role installed on both computers.

• Servers 3 and 4: Clustered or mirrored database server.

When you use a four-server farm, you must carefully decide where to deploy the index server role. The query role cannot be deployed to both the index server and another server in the farm to achieve redundancy. This is because, when the index role is installed on the same server computer as the query role, the index role no longer propagates content indexes to other query servers. Consequently, if you install the index server role to one of the Web servers, you lose the ability to host the query role on both Web servers. You can install the index role on the database server, achieving redundancy of the query role on the Web servers. However, the performance of the database server will be affected, especially when content is being crawled.

Three-server farm

There is another alternative for achieving redundancy when you deploy fewer servers. When you use a three server farm, you must decide which of the server roles to make redundant: either the Web server role or the database server role.

By adding a third server to the Web server tier, you achieve redundancy of the Web server role. The query and index roles can be either installed on the same Web server (see Option A in this section), or they can be installed on different Web servers (see Option B in this section).

Given this topology, the query role cannot be deployed to both Web servers to achieve redundancy. This is because, if the query server role is installed on the same server as the index server, the index server will not propagate the index to other query servers. However, you can install the index role on the database server. This enables you to deploy the query role on both Web servers. However, the performance of the database server will be affected.

Although availability is limited, dedicating two servers to the Web server role increases the overall performance of the small farm. Use this topology when performance is more important than data redundancy.

Non-redundant topologies

Non-redundant topologies might contain more than one server, but are not redundant because there is only one server for each server role. For example, a farm that contains one query server, one index server, and one database server is not redundant.

If you do not have to build additional capacity and performance into the server deployment, the starting point for the server topology is one or two servers. For a limited-use purpose, you can deploy a single Search Server 2008 server or deploy Microsoft Search Server 2008 Express, which is limited by design to a single application server.

The following diagrams show examples of non-redundant topologies.

Choose a baseline server farm topology

Each of the server farm topologies described earlier in this article represents a baseline starting point for designing the deployment. The starting point that best suits the organization depends on the server roles for which you must have redundancy.

The rest of this article describes the redundancy options for each of the server roles. When you are finished with this article, you will be able to determine the baseline topology that can deliver the redundancy that the organization requires. This is the topology that you will use as a baseline when you plan for capacity and performance.

Plan query server redundancy

Use this section to:

• Determine if the organization requires redundancy built into the Web tier.

• Plan which query server load balancing technology to implement.

The query server role can be deployed to multiple servers. The code that is deployed to each server is identical and the query servers do not store any data. In other words, each instance of the query server role remains identical. If one of the server computers fails, no saved data is lost. The query servers automatically load balance requests to these server roles across the available server computers.

The query role can be deployed to any number of Web servers. However, there is one limitation. If the query role is deployed to the same server that hosts the index role, the query role should not be deployed to any other server computers. This is because the index role recognizes that the query role is located on the same server. Therefore, it does not attempt to propagate the index.

The index application server role cannot be redundant in Search Server 2008.In Search Server 2008, the index role is associated with a Shared Services Provider (SSP). The index role builds one index per SSP. You cannot deploy multiple index servers to improve capacity. The index server is associated with a single SSP, and in Search Server 2008, you can only have a single SSP.

The next step is to plan which load balancing technology to implement. Search Server 2008 supports two methods of load balancing:

• Software, such as Network Load Balancing (NLB) services in the Windows Server 2003 operating system. NLB runs on the query servers, and uses TCP/IP to route requests. Because NLB and other software load balancing solutions run on the query servers, they use query server system resources. This reduces the resources that can be used for serving queries. However, the effect on system resources is not great, and a software solution can handle up to 32 query servers.

• Hardware, such as a router or a switch box. Load-balancing hardware uses the network to direct query traffic between the query servers. Load-balancing hardware is more expensive to set up than software. However, it does not affect resource use on the query servers. Search Server 2008 can be used with any load balancing hardware.

Although not recommended, there is a third method of load balancing, round-robin load balancing with Domain Name System (DNS). Round-robin DNS load balancing can use significant resources on the query servers, is slower than either load balancing software or hardware. We do not recommend that you use it with Search Server 2008. Also, round-robin DNS load balancing does not take session load into account when routing a user to a server, which can lead to a server being overloaded.

The article How To Configure Network Load Balancing Parameters in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=124067&clcid=0x409) provides instructions for configuring NLB. If you decide to implement a different technology for load balancing, factor this into the planning and deployment process.

Plan database server redundancy

Use this section to help you determine whether redundancy of the database server role is required for the solution. Subsequent planning topics will help you decide which database redundancy technology is most appropriate for the environment. For more information, see Plan for and design database storage and management.

The database server role affects the availability of your solution more than any other role. If a query server or the index server fails, these roles can quickly be restored or redeployed. However, if a database server fails, your solution depends on restoring the database server. This can potentially include rebuilding the database server and then restoring data from the backup media. In this case, you can potentially lose any new or changed data dating back to the last backup job, depending on how SQL Server 2005 is configured. Additionally, the solution will be completely unavailable for the time that is required to restore the database server role.

Evaluate the risks of server failures

This section summarizes the expected consequences of a single query server or index server failure. In other words, if you deploy the query server role to only one server and the server fails, what are the potential consequences? Understanding the potential consequences will help you prioritize the allocation of servers in the farm. The following table lists application server roles and describes the consequences of downtime for each.

Server role	Consequences of downtime
Query	Users cannot issue full-text queries. Users can still browse through sites and access content exposed through the sites. If your application depends on users or customers being able to find content by searching, plan to deploy the query server role to multiple servers. In a five-server farm, this can easily be done by deploying the query role to the two Web server computers.
Index	Query servers continue to use existing content indexes until the index service is restored and new or updated indexes are generated. Consequently, search results do not include new or changed content while the index role is unavailable.
Database	The farm will be inaccessible to users. Attempts to view pages in the farm will result in error messages. If your application depends on users or customers being able to find content by searching, plan to deploy a clustered database server configuration.

The general redundancy recommendation is to plan to install the query server role to at least two server computers if the availability requirement for the query server role is 99 percent or greater.

If your organization can tolerate temporary loss of this functionality for the time it takes the IT team to deploy an application server role to a different server or to restore service to the existing server, you can consider deploying the role to a single application server.

See Also

Concepts

Plan for availability (Search Server 2008)

Other Resources

Plan for and design database storage and management
How To Configure Network Load Balancing Parameters in Windows Server 2003
SQL Server 2005 Failover Clustering White Paper
Installing a SQL Server 2008 Failover Cluster