- Part 1 – Architecture and Logical Planning
- Part 2 – Installation
- Part 3 – Development Environment
- Part 4 – Backup and Recovery Strategy
- Part 5 – Virtualization
- Part 6 – Post Deployment (final)
Overview
Planning and installing SharePoint Farm across enterprise network is not a trivial task. SharePoint is rarely installed in an isolated environment, and usually it interferes with the organization strategy and existing infrastructure. Many factors may affect farm design, performance, scalability and redundancy – from hardware devices in organization network, to network topology. As a result, leveraging and finding compromises among those factors helps to build consistent, reliable and flexible environment.
There are several whitepapers on the Microsoft TechNet portal describing requirements for SharePoint Farm, but most of them are either written without taking into account infrastructure scope or filled with irrelevant information that navigate the reader away from the problem scope.
In this document you will find the configuration recommendations regarding different SharePoint areas. All information is represented in the set of recommendations about different actions you need to undertake or pay additional attention when you install and configure your SharePoint environment. We tried to structure all section to follow the natural flow of SharePoint installation from the scratch – from pre-installing analysis requirements to post deployment actions.
We plan several whitepapers in our “Best Practices” series, and we are interested which topis you would like to see in our next SharePoint publications. Please send us your comments and suggestions via this form.
Introduction
Organizations adopting SharePoint face a variety of tasks – from planning, strategy, infrastructure and architecture design, UI Design, migration, and to development. All these tasks imply flexible infrastructural baseline before actual work starts. However, in reality we face the outdated environment and misconfigured farms that are not ready to implement new requirements. In such cases, baseline architecture becomes foundation stone of all SharePoint projects.
Why would we care about infrastructure and not about something else, for example development? Fixing infrastructure errors is very expensive task and leads into significant changes across SharePoint farm. For example, Index Role assigned to the wrong server and incorrectly configured Search can lead to performance and redundancy issues that might require up to 3 days fix. Development errors are not so expensive and can be fixed relatively quickly, but sometime such errors, eventually become infrastructure errors that lead to changes in infrastructure design.
“Architectural Planning”
Plan your farm and network communications before starting actual installation. The first thing to start is designing SharePoint architecture across corporate network. This includes understanding network structure, examining network devices and choosing the right SharePoint topology to fit the existing infrastructure and new requirements.
Examine corporate network
Start from description of the existing network design, location of all applications and system servers. Microsoft Visio 2007 and “Network Diagram” template is a good instrument for this task.
Record the location and information of corporate system servers, like Domain Controllers, File Servers, Mail Servers, Application and others. Dont’ forget about network services – firewalls, proxies, and etc. For example, locations of ISA Servers across corporate network – IP address, list of open ports and the administrative user.
The best way to maintain “Network Diagram” document is to update the single diagram that covers topology of all domains and how they are connected. The following diagram demonstrates the Visio document descibing the servers and devices across organization.
This diagram will give a holistic view of the existing topology and ensure quick access to information across different domains.
Examine network devices
All network devices in the topology play a vital role of how SharePoint performs and interacts among different servers. Information about locations and settings of all routers, switches, and accelerators become very important in planning server locations. For example, location of different WAN and XML accelerators across network affects SharePoint server organization and configuration.
Presence of different network devices affects the connection bandwidth and latency between farm’s servers, and thereby, affects the choice of appropriate SharePoint Farm topology. Network Load Balancers (NLB), routers and switches will affect how fast network response, therefore the farm should be designed with the least impact of these devices.
Refer to the following links for the detailed information about WAN accelerators, NLB and other network devices across SharePoint farms:
- http://technet.microsoft.com/
en-us/library/cc263099.aspx - http://blogs.msdn.com/joelo/
archive/2008/01/17/global- sharepoint-deployment-partner- solutions.aspx - http://blogs.msdn.com/joelo/
archive/2007/01/05/nlb- network-load-balancing-and- sharepoint-troubleshooting- and-configuration-tips.aspx
Network administrator is a friend
The IT administrator is the person who should participate in farm configuration from the very beginning. This person will be responsible for the configuration of all network servers and devices across corporate network.
Most of the SharePoint Farm topologies cross the bounds of domains and from the very beginning specific protocols and ports must be open. The best way to maintain current situation is to have a separate document, shared with administrator, with the description of protocols and ports to open across network services.
Detailed information about system accounts and list of ports is available in the following articles:
- Plan for administrative and service accounts (Office SharePoint Server) http://technet.microsoft.com/
en-us/library/cc263445.aspx - Office SharePoint Server security account requirements http://go.
microsoft.com/fwlink/?LinkID= 92883&clcid=0×409
Measure network latency
Network response time is one of the important factors that can affect SharePoint farm design. Ideally, you need to measure the latency between SharePoint servers and users in order to reorganize servers according the smallest response time.
Network latency is the key point to determine which of the proposed scenarios to implement in the current SharePoint deployment. (Latency is the time required for a packet to travel from one point on a network to another).
Use the Ping tool (ping.exe) to measure latency for:
- users – from the client computer to the Web server on the server farm;
- data centres that host servers of the same farm – from a Web server in the remote data centre to the database server in the primary data centre
Do not forget to divide the round-trip result by two, because all measures are one way only, not round-trip.
Compare results to the data below, and adopt environment to have latency lower those values.
| Number of users | Concurrent users (10%) | Central Solution | Distributed solution |
| 100-5,000 | 10-500 | Bandwidth: 3+ Mbps (dual T1)Latency: < 100 ms | Bandwidth: 1.5 Mbps (T1)Latency: <100 ms |
| 10,000 | 1,000 | Bandwidth: 3+ Mbps (dual T1)Latency: <250 ms | Bandwidth: 1.5 Mbps (T1)Latency: <500 ms |
| 100,000 | 10,000 | Bandwidth: 3+ Mbps (dual T1)Latency: < 250 ms | Bandwidth: 1.5 Mbps (T1)Latency: <500 ms |
The critical bandwidth for any SharePoint farms is 1.5 Mbps (T1) with 500ms latency. Overstepping these values will increase the page-load times dramatically, in 4 times at least. Refer to the diagrams in the “Plan for bandwidth Requirements” document, for more details about the bandwidth and latency results under different conditions.
Available network bandwidth and latency influences geographic deployments significantly. Data transfers across WAN links that span multiple cities, states, provinces, countries, or continents requires really fast lines to provide adequate response time, so design such topologies thoroughly.
More details for bandwidth requirements available in the following article http://technet.microsoft.com/
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 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.
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.
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.
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 loss of access, when Web Server unavailable (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 can’t 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 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 the 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:
| Farm Servers | Performance | Redundancy |
| 3 – 4 | Index on WFE with Query on another boxApp Roles on WFE | Index on Database, with Query on WFEApp Roles on WFE |
| 5 | App Roles on Middle TierDedicated Index Server on Middle Tier | App Roles on WFEDedicated Index Server on Middle Tier |
| 6 | Dedicated Web Server for Crawling, outside NLBDedicated Index Server on Middle Tier | App Roles on Middle Tier in NLBDedicated Index Server on Middle Tier |
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:
- Best practices for My Sites: http://technet.
microsoft.com/en-us/library/ cc262706.aspx - Best practices for team collaboration sites: http://technet.
microsoft.com/en-us/library/ cc850694.aspx - Planning an Extranet Environment for Office SharePoint Server: http://technet.
microsoft.com/en-us/library/ cc262400.aspx
“Logical Planning”
Plan site collections
Plan number of site collections and sub sites in advance – content, location, security. Start with the single site collections and several sub sites rather then creating several site collections, and try to avoid new site collection if there are no requirements for this. The reason of such structure is that each new site collection works as a new application, with isolated scope to features, templates and search. Maintaining such structure is much easier than several site collections.
Organize site collection across several content databases
Do not end up with one big content database, because data optimisation will cause troubles in this case. For the small and development environments, single content database might be a preferable choice. However, for the large farms create several content databases and organize site collections among them. Having several content databases with sites helps to address the following:
- Keep content database size <100 GB, otherwise it could hinder performance (MS recommendation)
- Data usage optimization.
- Simplify farm backup and restoration.
- Flexibility for Disaster Recovery (DR) strategies.
More details about site collections in several content databases available in the following blog post: http://msmvps.com/blogs/
Script actions
Prefer to script installation and SharePoint Farm configuration actions: setting roles, creating web sites and site collections, etc. Configuring successful farm from the first attempt has a change to fail due to complexity of SharePoint. Running scripts to repeat all actions will save time when something went wrong and new server installation is required.
In the next part we will review the actual SharePoint installation and the basic farm configuration.
