Share via

Plan for redundancy (Windows SharePoint Services)

  • Article

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2009-04-15

In this article:

  • About redundancy

  • Define server redundancy requirements

  • Plan for a limited server deployment

  • Plan for a minimum level of server redundancy

  • Choosing a baseline server farm topology

  • Plan Web server redundancy

  • Plan search server redundancy

  • Plan database server redundancy

  • Select a baseline topology

This article describes the options for scaling out redundant server roles included in a Windows SharePoint Services 3.0 farm. After reading this article, you will be able to identify and record the redundancy options that are appropriate for the environment.

For more information about availability, see Plan for availability (Windows SharePoint Services).

About redundancy

The term redundancy is often misinterpreted to be synonymous with availability. While 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. A redundant system, however, might not be highly available.

This article describes how to implement redundant servers in an Windows SharePoint Services 3.0 farm.

Define server redundancy requirements

Windows SharePoint Services 3.0 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 decide if you need to build expandable capacity into the server deployment topology by deploying redundant servers (three or more servers), or if it makes sense for the organization to plan for a limited server deployment that has no redundant servers.

Plan for a limited server deployment

If you do not need 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 server.

Single server

Limited-use purposes include the following:

  • Installing Windows SharePoint Services 3.0 for evaluation purposes.

  • Deploying Windows SharePoint Services 3.0 for a limited purpose (such as for a single department) or for a limited number of users.

The recommended starting point for most Windows SharePoint Services 3.0 deployments is at least two server computers:

  • Server 1: Front-end Web server and search server computer

  • Server 2: Dedicated SQL Server computer

    Two-server farm

If you have determined that you do not require server redundancy in the environment, you can now go to the following article to complete the next planning step: Plan for performance and capacity (Windows SharePoint Services). The completion of this planning step will determine the total number of servers recommended for the server deployment plan. You do not need to read the rest of this article.

Plan for a minimum level of server redundancy

To deploy a redundant solution, you must deploy a server farm. By using a server farm, you mitigate against the effects of unexpected downtime as well as downtime that is related to ongoing maintenance, such as operating system updates.

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 provides an overview of these server farms.

Four-server farm

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

  • Servers one and two: Web servers. Search is installed on one of the Web servers.

  • Servers three and four: Clustered or mirrored database server.

    Four-server farm

Five-server farm

The most common redundant server farm topology introduces a middle tier and consists of five server computers.

  • Servers one and two: Web servers.

  • Server three: Search.

  • Servers four and five: Clustered or mirrored database server.

    Five-server farm

This topology optimizes the performance of the front-end Web server computers by offloading search to a dedicated server computer.

Three-server farm

There is another alternative for deploying fewer servers. With a three server farm, you must choose which of the server roles to make redundant: either the Web server role or the database server role.

By adding the third server to the Web tier, you achieve redundancy of the Web server role. The search role can either be installed on either Web server.

While availability is limited, this topology increases the overall performance of the small farm. Use this topology when performance is more important than data redundancy.

Front-end servers for three-server farm

By adding a third server to the database tier, you can help ensure availability of critical data. Plan to use this small-farm topology when availability of your data is critical but temporary loss of user access is acceptable.

Databases for three-server farm

Choosing 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 require redundancy.

The rest of this article describes the redundancy options for each of the server roles. By the time you are finished with this article, you will be able to identify 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 start planning for capacity and performance.

Plan front-end Web server redundancy

Use this section to:

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

  • Plan which Web server load balancing technology to implement.

Most organizations require redundancy at the Web tier. There are a small number of scenarios in which a three-server farm with one server running the Web server role makes sense.

The next step is to plan which load balancing technology to implement. Windows SharePoint Services 3.0 supports two methods of load balancing:

  • Software, such as Network Load Balancing (NLB) services in the Microsoft Windows Server 2003 operating system. NLB runs on the front-end Web servers, and uses TCP/IP to route requests. Because NLB (and other software load balancing solutions) runs on the front-end Web servers, it uses the front-end Web system resources, and thereby reduces the resources you can use for serving Web pages. However, the impact on system resources is not great, and a software solution can handle up to 32 front-end Web servers. For more information about NLB services in Windows Server 2003, see Network Load Balancing Clusters (https://technet.microsoft.com/en-us/library/cc759510.aspx). For more information about NLB services in Windows Server 2008, see Network Load Balancing (https://technet.microsoft.com/en-us/library/cc732855.aspx).

  • Hardware, such as a router or a switch box. Load balancing hardware uses the network to direct Web site traffic between the front-end Web servers. Load balancing hardware is more expensive to set up than software, but it does not affect resources on the front-end Web server resources. Windows SharePoint Services 3.0 can be used with any load balancing hardware.

    We recommend that you set the load balancing affinity to None to improve availability. If you have a custom topology requirement, you may want to configure the affinity differently.

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 front-end Web servers, is slower than either load balancing software or hardware, and is not recommended for use with Windows SharePoint Services 3.0. 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.

Plan search server redundancy

Windows SharePoint Services 3.0 includes one application server role: search. The Windows SharePoint Services 3.0 search application role includes both the search and indexing components. These components cannot be divided. You can install the search role on a Web server or on a dedicated application server. Unless you are deploying Windows SharePoint Services 3.0 to a standalone computer, installing the search role on the same computer as the database is not recommended.

If a server that hosts Windows SharePoint Services 3.0 search fails, search is unavailable. The amount of time required to restore the search capability depends on if existing content indexes can be restored or if new indexes must be generated by re-crawling the content.

Windows SharePoint Services 3.0 can be deployed to multiple servers for capacity reasons; however, the multiple servers are not redundant. In this scenario, each search server is configured to crawl a different set of content databases. Because the primary reason for deploying multiple search servers is to scale for capacity or performance, subsequent planning articles will help you decide if multiple servers are recommended for your deployment. For more information, see Plan for performance and capacity (Windows SharePoint Services).

Plan database server redundancy

Use this section to help you determine if redundancy of the database server role is a requirement for the solution. Subsequent planning topics will help you decide which database redundancy technology is most appropriate for the environment.

The database server role affects the availability of your solution more than any other role. If a Web server or an application 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 it takes to restore the database server role.

Select a baseline topology

After you identify the redundancy requirements for the individual server roles, review the baseline server topologies and choose the topology that is most appropriate for the environment.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable books for Windows SharePoint Services.