SharePoint 2010 Physical Topology

•SharePoint 2010 Service Architecture
•SharePoint 2010 Logical Architecture
•SharePoint 2010 Architecture and Design Models
•SharePoint 2010 Performance and Capacity Case Studies
•SharePoint 2010 Capacity Planning
•SharePoint 2010 Cache Strategies
•SharePoint 2010 Databases
•SharePoint 2010 Physical Topology

Introduction

In this blog I am going to build off what we has been discussed thus far in this series. Whenever I start working with a new SharePoint client, the first thing that comes up is what is needed to install to get going. Well that answer is always based on business requirements however I am rather quickly forced into a corner to show them how it works J

To be able to define the physical topology you need to know:

• SharePoint service architecture
• SharePoint logical architecture
• Having a strong understanding of availability, capacity, and continuity

Once you have a good idea of that, you will be in a good position to draw out sketches of the Physical Topology for SharePoint you need. For SharePoint 2010, things have changed a lot and the logical architecture is significantly more flexible and scalable. I would say the game has changed in lots of regards.

In this blog I am going to focus on understanding some of the decision logic I would go through when architecting a new SharePoint 2010 farm.

Getting Started

I am going to keep this simple as possible. The first place to get started is to understand your business requirements so you can come up with a list of services that you need. You can read my previous post on SharePoint service architecture.

Next once you have understanding of what services are needed, you will need to come up with a logical architecture for SharePoint. In this series I went over a lot of the design decisions for coming up with that logical architecture for SharePoint.

Here is a refresh on some of those logical architectures. You may come up with a diagram as simple as this one below which is for a Single Farm Single Service Group where services are shared across farms.

You may come up with something like below which is a Single Farm with Multiple Service Groups. The service groups provide dedicated services to site collections.

You may come up with something more complicated which is a Multi Farm environment with centrally hosted services and localized dedicated services.

You come up with a Multi-farm with application services that are partitioned so services are centralized but data is not shared.

Or you may come up with a hosted partitioned farm where farm subscribe to centralized services.

To get more details I recommend you read the Logical Architecture posting of this series.

Selection of a logical architecture should driven by business requirements. The logical architectures I presented above are by no means the only ones; you can come up with tons of different permutations. What I did want to demonstrate is that I made no assumptions yet on how many machines would be needed to support the logical architectures. I will say in a perfect world this would always be true however sometimes the physical architecture affects the logical architecture.

Physical Topology

When we start talking physical topology we need to identify how we are going to configure the environment. There are three types of machines you will have in your farm:

1. Web tier
2. Application tier
3. Database tier

There were a couple things I left out where going over the logical architecture:

• I did not discuss web or database tiers. I focused only on understanding the application services.
• I did not discuss how many services would be configured one a single application server or across multiple application servers. Understanding how many servers are needed will be driven by capacity and availability planning which I have also discussed in this series. So it is really important to understand the demographics of the users, their profile, their expectations and how they plan to use SharePoint for both the short and long term.
• The service groups that I defined in the logical architecture do not drive what services will be configured onto what machines. What we need to focus on is identifying services that have common performance characteristics and configure them onto dedicated server resources (physical or virtual).

There is some basic guidance that Microsoft provides that will help you get started which I am going to go over.

Limited Deployments

This is described as either:

• One-server farm with all the tiers installed on one server.
• Two-server where the web and application tiers are installed one server and the database would be installed on an existing SQL Machine.

Small Farm Topology Deployments

This farm would be scaled out a little more to support more users or provide dedicated servers for services. Web servers, search service and other application services will be distributed across multiple machines. Some potential configurations are:

• Three-server configuration where there are two web servers that are load balanced. We web server will have the query server configured (which searches an index) and one will be dedicated for all other application services. The third machine is the SQL machine.
• Four-server configuration where there are two load balanced web servers with the query service running on each. The third server is dedicated to hosting application services and the fourth is used for SQL Server.
• Five-server configuration is similar to the four-server farm but we separate the index service onto a separate application server.
• Six-server configuration which is the same as the five-server farm except we create dedicated SQL database for search service to better support crawling.





Microsoft states that two WFEs can support 10,000 to 20,000 users. As well this configuration can support searching up to 10M documents.

The five and six-server farm configurations are very common configurations out there today. It is highly recommended starting place for a company division or for a dedicated solution farm because:

• There is redundancy for the WFEs – if one goes down users can still access the site.
• There is performance improvement for users because there are two load balanced WFEs.
• The application services are dedicated to a machine.
• Search indexing which can be an expensive operation is dedicated onto a separate application server.
• Separating the search query and index services provide both performance improves in search and redundancy (i.e. users can still search of the search server is down).

The three and four-server farms I really do not see as viable configurations. At minimum you need to consider a five or six-server farm for production environments.

Medium/Large Farm Topology Deployments

There is no definition which says exactly that X amount servers means you have a medium or large farm. Really I always start with a five farm configuration and from there I will start scaling out servers based on capacity requirements and the logical architecture that I created earlier.

Some observations:

• Adding more web servers will support more users. A rule of thumb is every web server will support an additional 10,000 users.
• Based on capacity and availability requirements, add more application servers and spread your services across those servers. These servers can be dedicated to supporting specific service applications. The logical architecture you created will not have a one-to-one mapping of services to server. In some cases, you may have to create multiple servers to support a single service from the logical architecture. Review the blog in this series on capacity planning for more information.
• There is a potential that you may want to scale content databases onto their own dedicated database server. You may have to consider adding more databases to better support search.
• You may consider creating dedicated WFEs for search, so when content is crawled, the WFEs that users use is not affected.
• Scaling out search is very important. SharePoint Search is more scalable and if you are considering using FAST, even more servers will have to be considered. I am not going to dive deeply into scaling search in this blog.
• It is highly recommended to plan out server groups and with service applications that have similar requirements. You can consider centrally hosting these servers and making them available to other farms.

Extranet/Internet Farm Topology Deployments

Extranets and Internets will require you to have an understanding of how you are going to secure SharePoint with a DMZ. This model by Microsoft is the best place to start. The diagrams for SharePoint 2010 are identical to the ones for SharePoint 2007. I usually recommend implementing the Split Back-to-Back server configuration. Even though the configuration may be more complex, all of the application and database servers will reside behind the firewall and only the WFEs will be placed onto the DMZ.

References
Hopefully this will help you get started with architecting your SharePoint 2010 environments.

• SharePoint 2010 Products Deployment
• Topologies for SharePoint Server 2010
• Extranet Topologies for SharePoint 2010 Products
• SharePoint 2010 Products: Virtualization Process