The name of the blog was inspired by the C#using statement that allows programmers to specify when objects that use resources should release them; and in the same way, you can use my tips, tricks, and try-outs at your own disposal ;)

Entries in Design Patterns (1)

Friday
Feb252011

Looking SharePoint Topologies as Patterns (MOSS 2007)

When I first had to deal with SharePoint 2007 server topologies I had to understand the different possible configurations so I can come up with a configuration that takes performance, availability, redundancy and flexibility in to account. So, I thought it would be cool to think of SharePoint server configurations as patterns and anti-patterns and be able to identify them quickly without going into details and be able to communicate it to others.

To start with, let me just define what design patterns in Software engineering are (got it from Wikipedia):

Pattern: a design pattern is a general reusable solution to commonly occurring problem in software design.

Anti-Pattern: an anti-pattern is a design pattern that may be commonly used but is ineffective and/or counterproductive in practice.

SharePoint Server Roles

Let me first describe the different server roles in SharePoint 2007.

Be aware: it's targeted for MOSS 2007 (not SharePoint 2010).

WFE   

Any server in SharePoint that has the “Windows SharePoint Services Web Application” service is a Web-Front-End. That means your Web Applications is configured on each one of the web-front-ends and can potentially receiver requests from end-users through IIS Web Sites.

Whether a WFE serves end-users or not matters on which one of the WFEs you load balance and expose it to end user requests. So that means just because a server has the “Windows SharePoint Services Web Application” service installed, it does not mean it is receiving requests from end-users (very important point).

 

QUERY

A server with a query role is a search server in SharePoint that has the “Office SharePoint Server Search” service running and configured for serving search queries.

SharePoint out-of-the-box can load balance the query role for you. That means you can have more than one server with the query role.

INDEX 

A server with a query role is a server in SharePoint that has the “Office SharePoint Server Search” service running and configured for indexing content.

SharePoint by design cannot load balance the index role. That means you can only have one server having the index role, unless you configure another SSP (you can only have one index per SSP).

 

EXCEL

A server with an excel role is a server in SharePoint that has the “Excel Calculation Service” running. It is basically used to do excel calculation and render excel content to SharePoint sites. And, this role can be load balanced easily by SharePoint.

CA

A server hosting the Central Administration Web Application

 

DB

A database server (or cluster) hosting the content databases, the configuration database and other SharePoint databases.

 

The Standalone Configuration

I will start with the standalone configuration, because that’s where all the anti-patterns arise. The standalone configuration is basically having all the roles on a single server and we will branch out patterns and anti-patterns from it.

 

The Anti-Patterns

Propagation Anti-Pattern

One of the common mistakes when configuring an application server is assigning the same server the Query and Index role. Don’t ask me why, but for some reason if the index finds the query role on the same box, the indexer assumes that there is no other server in the farm that has the query role, therefore does not propagate index to other query servers. So, don’t forget! Make sure you don’t assign the query and index role for the same server and assume other load balanced query servers to be functional.

 

Disk-I/O Anti-Pattern

Database Operations really depends a lot on the physical storage, and a lot of Disk I/O happens on a database server. Because of that, having the WFE role on the same server will affect the performance of the SharePoint site because the worker process will compete with the database server for resources. And this is actually the first thing you should avoid, as you will improve your SharePoint site performance significantly if you have the database role on a dedicated box.

Exposed-CA Anti-Pattern

A common mistake you can make, is hosting the central administration Web Application on a Web Front End (a web front end that actually serves requests). Say, the WFE box is compromised, that would expose the central administration for an attack (you wouldn’t want that, would you?). You need to take care of one thing though, the central administration web application located on a complicatedly separate box could still be vulnerable, and so you need to plan how to protect the central admin box from the WFEs (be it with some kind of firewall, or whatever).  

 

The Patterns

Database-Separation Pattern

Like I mentions on the Disk-IO anti-pattern, you can easily increase your SharePoint site performance by having a dedicated server. And, that’s the first thing you should consider, therefore the Database-separation pattern.

Request-Separation Pattern

This pattern separates the Web-Front-End from the Application server. Using this pattern, you solve 2 major issues:

  • By separating the WFE from the CA, you can have a chance to protect the Central Administration Web Application.
  • The indexing can consume server resources. So, separating the WFE from the indexer will be another performance boost after applying “The database separation pattern”.

Query-Separation Pattern

I mentioned earlier that if the index and query are on the same box, the index will not propagate index on to other query servers. So, by separating the query role into a different server, you avoid the propagation issue and at least you give yourself the flexibility to add more query servers as you need them (note that I have the WFE and the Query role on the same box, if you only have 3 boxes then that’s the best way to go, but if you anticipate a lot of query requests it might be a good idea to have a dedicated query server).

 

Target-Box Pattern

Didn’t we talk about “The exposed-CA anti-pattern” and “the competing-Indexer anti pattern” earlier? Then, WTF is the WFE role doing with the CA and Index role? The answer is simple: I am not really using the second WFE for end-user requests (the one with the CA and other roles), it’s not load balanced or does not get end-user requests at all. I can even hide it behind a firewall. The reason I have it: is to avoid the request load on the end-user WFEs that is coming from the indexer. You basically have a target box for the indexer. Target box pattern also avoids the extra hop on the network, because the calls from the indexer would be local.

 

Request-Load-Balancing Pattern

You have applied “The database separation pattern”, “The request separation pattern”, “The query separation pattern”, and you have avoided the exposure of the CA, you have increased the performance of the WFE, and you have given the query a chance for load balancing.

So, now it’s time to care for your Web-Front-Ends. By adding a second WFE not only you make your SharePoint more available (if one is down, you got the other still running) but you also increase performance by distributing request loads. Note that, your query request is also load balanced, this makes your farm more available (if one query is down, the other will take it).

 

Available-Database Pattern

When you first applied “The database-separation pattern”, you gained a significant performance. Now, you should plan how to make your server available. Pretty simple, you use SQL Server clustering. Take note here, that SharePoint doesn’t really know about the database cluster; SharePoint just refers to the database as if it was a single server. And, it’s pretty much the job of SQL server to manage the cluster. You pretty much have two options when clustering database servers: Active-Active or Active-Passive clustering. You either have both as active or you can have one active and the other passive where one of the database servers is active and the other stays inactive and waiting for the other to fail and take over, therefore “The available-Database pattern” (I am not an expert on this subject but you can use the technique of Database Mirroring to make your database redundant).

 

X5 Pattern

When you apply “The database-separation”, “The request-separation”, “The query-separation”, “The target-box”, “The available-database” and “the request-load-balancing” patterns, you end up with a minimum of 5 servers forming an X, therefore I call it the X5 pattern. Note that if you’re avoiding “The propagation anti-pattern” and trying to load balancing search then you pretty much end up assigning the query roles to both WFEs.

 

Web-X6 Pattern

This is pretty much the X5 pattern, with one additional server targeted for Web request. From applying the X-5 pattern we ended up load balancing the query role on both WFEs, and now you might need to plan to have an additional WFE not to over kill the 2 WFEs. That also gives you a chance to just leave the index alone and separate the Excel to the 3rd WFE or perhaps load balance the Excel role between the 3rd WFE and the application box. With this pattern, you can pretty much load balance WFE, Query and perhaps Excel services.

App-X6 Pattern

The Web-X6 pattern can perhaps fit for a farm where WFEs do a lot of user authentication for collaboration reasons (authentication could be expensive, so therefore an additional WFE would definitely help). On the other hand, The Application-X6 pattern targets the query role. If you are expecting a lot of search queries, then it might be a better idea to have a dedicated query server than having a 3rd WFE, for that reason you add a 2nd application server and that can primarily be used for query but you can also use it to host a second CA or separate the CA from the index server (btw if you are having the CA with Query server you can perhaps stop IIS, and start it back whenever you need it, that way you don’t have to worry about having using up the memory), and you can also use the same box to load balance the Excel Role if Excel services availability is very important.

 

Conclusion

This was more of an excercise to go through the process of identifying and understand the different topologies. Please make sure you research and plan before you configure your farm, and don’t take the patterns black-and-white, as you have to come up with your own topology that best fits your budget and your business.

Thanks,

using(NaT)