Become familiar with SharePoint farm communications

Before discussing servers’ redundancy and farm topologies let us review farm servers and how they communicate with each other. The following picture from “Planning an Extranet Environment for Office SharePoint Server” TechNet article illustrates the communication channels within a server farm and which servers handle client's request.

When a user issues a query, the query is sent to a Web server. The Web server communicates with the query server to build a list of results, and then communicates with the computer running Microsoft SQL Server to extend the list of results with summarization text, URLs, and security trimming. In parallel, the Web Server gets page data from SQL Server and renders them on fly. This diagram will help in understanding which roles to use on farm servers.

Identify Farm Size

When you start new SharePoint project it's very important to understand the size of a farm you are planning to end up, because it impacts on:

• SharePoint farm topology
  There are three farms topologies to choose between - Small, Medium and Large. Your farm topology choices are usually dictated by the number of users and content your plan to use inside SharePoint.

There are several recommendations to following the next values for the farm size (I would delete them on 5, actually)

• Small farm: Typically < 50,000 users
• Medium farm: Typically < 100,000 users
• Large farm: Typically < 500,000 users

The number of users varies depending on usage profiles, type of data being saved, and the type of hardware and network the system is deployed on.

• SQL Server configuration
  Determine your SQL Server deployment size by using the following table:
  1. If your deployment parameters are generally < than the listed values, your deployment can be considered small - 4 GB is the minimum required memory (SQL 2005)
  2. If your deployment parameters are approximately = to the listed values, your deployment can be considered medium - 8 GB is recommended for medium size deployments
  3. If your deployment parameters are generally > than the upper limits of most of the listed values, your deployment can be considered large - 16 GB and greater above is recommended for large deployments

• Capacity planning
  The general rule is to plan for 1 RPS (requests per second) per 1000 users (on the minimum recommended hardware)
  • Small Farm (single WFE) can serve about 100 RPS
  • Medium Farm (two WFE) can serve about 200 RPS

Plan a baseline topology

Analyse the existing infrastructure and plan a SharePoint topology for 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” http://technet.microsoft.com/en-us/library/cc288334.aspx)

There are several different topologies - from three to six servers in farm, which can be used as a baseline. Which one to choose depends on the level of redundancy and available hardware. Not all clients can afford topology with six or ten servers in farm due to budget limitation or data centre capabilities. Finding the compromise between numbers of servers, type of hosting and servers’ roles become critical task, because this choice will affect performance and extensibility of the SharePoint farm for several years ahead.

Three servers farm
The minimum availability for the farm with few servers can be achieved with "3-servers farm" topology. In the current topology Web and Application Servers locate together on the one box and the database is on another box. The remaining, third, server gives a choice of which server role make redundant – Web server role or the database server role.

The farm with the two Web Servers provides redundancy of the Web and Application roles, improving the overall performance. A drawback of this design is that your data is not redundant (left farm).
In other case, farm with two Database Servers (cluster) provides data redundancy, increasing availability of critical data, but users might suffer from temporary access loosing (right farm).

The "3-servers farm" is one of the most questionable farms in terms of redundancy and performance. This limitation in the number of servers cannot provide redundancy of Query Server and high performance at the same time.

Redundancy can be achieved with Query Roles on both Web App servers. In this case, Database Server is the only place for Index Role, but this will hinder the overall performance. The Index Role is very CPU and HDD consuming role and that is why database servers are not very optimal place for this role. Alternative solution is to assign Index Role to the Web Server with the Query Role, but this will not work effectively, because in this case, index will not be propagated to another Query Server in farm.

If performance is one of the priorities then consider using Query Server and Index Server Roles on different Web Application Servers. This is flexible design in terms of extensibility, because with the new servers in farm changing roles of Index and Query servers is not required.

Interestingly, a TechNet article (http://is.gd/8QbS, page 26) explains that a Query Server cannot be used with Web Applications server for 3-servers farm. The reality is that, Web App and Query Role together are super common, more common than not (one of the reasons is that Query Server doesn’t use Network-Load Balancer - it uses its own algorithm). What they actually mean in the TechNet article is that having the Index Role on database server is not at all a recommended solution.

Four servers farm
Additional, forth server will add redundancy either for Data Server or for Web Server. However, it does not help much with performance. Current topology suffers from the same "3-servers farm" drawbacks – no place for Index Server with Query Role redundancy.

Five+ servers farm

The most common and highly available server farm topology is "5+ servers farm", the farm with middle tier server.

This middle tier server solves all issues of three and four servers topology by providing the dedicated tier for Index and Application roles. Additional servers in farm will extend middle tier, by assigning new roles to those servers - Excel Calculation Services Role, and Microsoft Office Project Server 2007 Role.

The following table summarize farm topology:

To optimize the overall performance of five and more servers SharePoint Farm, configure a dedicated Web Server for crawling content, especially when crawling a server farm that contains more than 500 gigabytes (GB) of content or crawling content over the WAN. To ensure that user requests are not affected by content crawling, remove the dedicated Web server from the network load balancing rotation. This is especially important in global environments in which the off-peak hours of a regional farm—when crawl jobs are likely to be schedule —coincide with the peak hours of the central farm.

Plan extranet topology

Choose the topology based on requirements for external users. This topology will provide a basis of network extensibility for applications servers and communications between them.
The simplest topology is “Edge firewall topology”, which is represented by following diagram, from TechNet article.

This topology applicable for the small farms, when there is no need to separate internal services from corporate network and secure communications between server farms. All remote users are separated from farm by ISA server which plays a role of remote proxy.

For the big farms, when security of communications is a priority, the recommended topology is “Back-to-back perimeter topology”. This is very flexible and adaptable topology for network changes

The main advantage of this topology is that it isolates the server farm in a separate perimeter network. Layers logically separate all servers and communications are under control – any security damages affect only specific layer, not the entire farm. External user access is isolated to the perimeter network and users can be isolated in different AD for remote and corporate access.

There are some other extranet topology variations, but mostly all of them are based on “Back-to-back perimeter topology” with some modification.
Detailed information about farm topologies can be found in the following documents:

1. Best practices for My Sites http://technet.microsoft.com/en-us/library/cc262706.aspx
2. Best practices for team collaboration sites http://technet.microsoft.com/en-us/library/cc850694.aspx
3. Planning an Extranet Environment for Office SharePoint Server http://technet.microsoft.com/en-us/library/cc262400.aspx

Staff needs

One commonly overlooked component of a successful implementation is staffing. Architects and administrators usually do a good job creating a bill of goods for hardware and software, but they often forget to secure funding for personnel to adequately develop and maintain a new system. SharePoint Server 2007 can consume a large amount of human resources if used to its full potential. Understand what types of dedicated personnel are required in the beginning, and start getting stakeholders' support immediately.
(Note: F = One full time person and P = One part time person.)

---