SharePoint is an enormously flexible platform, allowing you to use many combinations when allocating services across the servers. When you are architecting any system’s topology, there are always two principal goals that you should consider: performance and high availability. How responsive does it need to be? How available does it need to be? As much as possible, it’s best to quantify these requirements as they become part of your solution’s service level agreement (SLA).
Designing the right topology for a SharePoint farm is both an art and a science. The process involves many variables, such as user count, anticipated load per user, stakeholder expectations, business continuity requirements, budget, security, and government regulations—not to mention the ubiquitous CPU, RAM, disk, and network factors.
Despite these complexities, some fairly standard topologies are commonly found in SharePoint farms. They are good starting points for the architectural process. Five such designs are shared in this section.
Fortunately, the implementation of the topology is fairly trivial, once you understand how SharePoint works. Between Central Administration and PowerShell, you can quickly and easily deploy the services as needed.
When designing your farm’s topology, bear in mind that farm servers are intended to be in close proximity, usually in the same datacenter. This could mean that multiple farms are needed.
NOTE Before officially selecting the topology, consider staging the different designs and performing various tests, including load and stress testing. That way, you have quantitative, empirical proof that this design will meet your requirements.
Understanding the Single-Server Farm
A single-server farm is one server where all three roles—web front end (WFE), application server, and database server—run on the same machine. This type of farm is usually only found in development or evaluation environments. See Figure 5.1.
Figure 5.1: Single-server farm
The single-server farm can be a stand-alone farm (as covered in Chapter 1, “Installing SharePoint 2010”)—one that can never be scaled out to additional servers. A single-server farm could also be a complete server farm that is running SQL Server locally. Either way, a single-server farm is rarely recommended for a production environment, unless the user count is very small (less than 100) and high availability is not needed.
Understanding the Two-Server Farm
In a two-server farm, one server is the WFE and application server, and the database server is placed on its own dedicated machine. A two-server farm is the smallest size farm that can be easily scaled to larger farms. This makes it a common starting point for new farms that begin as pilots or at the department level but are expected to grow in size.
A dedicated database server increases performance dramatically. With scaled-up hardware, a two-server farm may be able to support as many as 10,000 users. But it does not provide any fault tolerance. See Figure 5.2.
Figure 5.2: Two-server farm
Understanding the Three-Server Farm
In a three-server farm, the database server should be dedicated. A three-server farm can be designed in two primary ways. The options involve where to run the WFE and application server roles. For environments with somewhat heavy web requests that need some fault tolerance, it is common to go with a design like the one in Figure 5.3, with two servers running as a WFE and as an application server. The WFE servers are network load balanced, adding performance and fault tolerance. Application services, in particular query services, can be run on both WFE servers to ensure an even distribution of work.
Figure 5.3: Three-server farm with load balancing
Another option is to separate out the three tiers (WFE, application server, and database server) onto three separate servers, as shown in Figure 5.4. Although this approach is a bit easier to implement than the design with two WFE servers, it is advantageous only if you have heavy application service requests—for instance, Excel Calculation Services—that require a dedicated server. No fault tolerance exists in this design, but fault tolerance can be achieved by adding another WFE, application server, or database server.
Figure 5.4: Three-server farm with dedicated roles
Understanding the Medium-Server Farm
A medium-server farm can exist in many configurations and sizes. In most cases, a medium-server farm uses separate, dedicated servers for each of the three roles: WFE, application server, and database server. How many servers run each role will vary depending on the usage, along with performance and fault tolerance requirements.
Assuming that search is a major component (and it is in most farms), the query and crawl services associated with search are typically put on their own group of servers. You’ll learn more about scaling search in the section “Scaling the Search Service” later in this chapter.
Figure 5.5 shows one design for a medium-server farm. A farm of this type can scale up to perhaps as many as 30,000 users, but the most noticeable drawback is the lack of fault tolerance in the database role, making it a single point of failure.
Figure 5.5: Medium-server farm
Understanding the Large Farm
A large SharePoint farm extends the concept of the medium-server farm by adding more servers in areas where they are needed. In fact, this need is not usually known when drafting the design on paper. In most cases, a large farm starts out as a small or medium farm and just keeps growing. For example, if heavy Visio Services usage becomes a bottleneck, you can dedicate Visio Services to its own application server.
Again, scaling by adding new servers is done to achieve performance and high-availability goals. You’ll learn more details about achieving these two goals for each of these server roles in later sections of this chapter.
TIP If performance is your primary goal, it is best to first scale up the server (such as adding RAM) before scaling out to new servers.
As you scale to a large farm, here are some general guidelines to keep in mind:
- A single WFE can usually handle no more than 10,000 users. For heavy, concurrent users, this number can quickly drop to fewer than 2,000 per WFE.
- For performance reasons, do not allocate more than four WFE servers for each database server.
- For medium or large farms, keep servers dedicated to a single role—that is, do not have servers that are both a WFE and an application server.
- Do not install non-SharePoint-related software, services, or databases on SharePoint servers.
- Keep database servers dedicated to a single farm.
- As much as possible, servers of the same role type—in particular WFE servers that are load balanced or clustered/mirrored SQL servers—should have nearly identical hardware.
- Virtualization is supported by Microsoft across all three roles, but virtualizing database servers has the greatest impact on performance.
- For performance reasons, WFE and application servers should be on the same physical network or virtual local area network (VLAN).
- Keep all servers with like roles on either physical or virtual hardware. For example, if you will have three WFE servers and two application servers, all three WFE servers should be either physical or virtual.
- Setting up database mirroring or clusters in SQL Server does not increase performance.
NOTE All servers in a farm should be co-located in near proximity, usually in the same datacenter. Whether servers not on the same physical LAN can work together depends on the performance and latency of the network. In most cases the network speed should be at least 1 Gbps with a ping latency of 1 ms or less.