Tuesday, February 1, 2011

SharePoint 2010 Server Topology Examples

I figured I write a short blog about SharePoint, logical / physical architecture, YET AGAIN!!!

Well I actually received some advice that made me want to tweak my message a little. If you read my earlier blog series on SharePoint 2010 Service architecture you will know how much SharePoint 2010 has changed. Then you may have also read my series on the new SharePoint 2010 Search architecture and found out there have been tons of interesting changes here too.

I had a great presentation from Shane Young (SharePoint MVP) which drove me to write this blog. What I realized is I have to stop thinking about architecting in SharePoint 2007 and take advantage of SharePoint 2010. Heck I should know them given all the new architecture features I have been writing about all this time.

In many SharePoint 2007 implementations, the one service we had much of our planning around was SharePoint Search and the SSP. Now all of those limitations are gone.

I am commonly asked how many servers I need to get started with SharePoint 2010. Now that is a LOADED question because such things as SQL high availability, network, service utilization, enterprise features, etc. which all play into an optimum configuration of SharePoint 2010. There really is no one size fit all. However there is always a good place to start the discussion. Shane Young provided two recommendations which I liked the best.

The Three Server Farm

This one is pretty fun one when you think about. There are a ton of SharePoint 2007 environments out there where there are 3 SharePoint servers and with dedicated SQL Servers. In those cases there are two web front ends and one application server. The one application server runs the index service, maybe something like Excel and the search query services are running on the web front ends. In the SharePoint 2007 days, this gave some good redundancy but with SharePoint 2010 we can do better.

Now one approach you can consider in SharePoint 2010 is just making all three servers the same. Rather novel idea right?

clip_image001

Observations:

  • You now have web traffic distributed across three web front ends.
  • All three servers can support SharePoint 2010 services traffic such as Excel, Visio, Access, etc.
  • Search crawler service should be pretty spiffy because you can configure all three servers to perform full crawling during off hours, and partial crawls depending on how fresh you need to keep search.
  • All three servers can be made redundant from a search perspective by having index mirrors.
  • Search results will actually be quicker because you will have three index partitions that can be searched across simultaneously.

Now I had a colleague point out that this does not fly well because “this does not maximize the separation of services architecture from the web front ends”. I get and completely understand that standpoint but I really do not think that should be a consideration for disqualifying this option. Even though everything is running on each machine, the SharePoint roles / services will continue to run independently in different IIS websites, in separate application pools and with different accounts. There is no reason why you cannot continue to configure it as it if they are running on different machines. This is probably a good thing too because someday you will have to scale SharePoint up to meet demand. Remember you can always scale up by adding boxes or separating services onto their own dedicated machines. All I can say is configure SharePoint 2010 based on your requirements, adhere to best practices, plan as much as you can and do the right configuration for your company.

The Four Server Farm

Now let’s look at a four server SharePoint farm. There will be cases where the three server farm recommendation will not make sense for whatever the valid reason. In this configuration we go a little more “traditional”. In this case, Shane recommend two web front ends and then two application servers.

clip_image002

Observations:

  • We have two dedicated web front ends. Add more if you need to.
  • Application services will run on the same application servers with search. Hopefully they will not interfere with full crawls unless you require dedicated resources for the application services. If you need; just add more application servers.
  • The two application servers give us the needed redundancy we need for search. You will have two crawlers and two index partitions with mirrors to start with.
  • One little trick I was told for this configuration is you should also configure the application servers where the Search crawling component is running to also be web front ends (WFE). Do not load balance them with the other WFEs. Then add the SharePoint site URLs to be searched as entries into the hosts file on the application servers to point back to itself and not to the load balanced URL. What this effectively does is trick the crawler into crawling the WFE on the application server. This will give performance improvements twofold. First the load balanced WFEs where users access content will have no performance issues associated to the crawler crawling content. Second, the load of the network will be reduced because nothing will go across the wire when indexing is occurring.

Additional Notes:

  • High Availability – SQL is a big player in this discussion and you need to read this blog.
  • FAST for SharePoint 2010 - Now if you are going to consider using FAST for SharePoint, I would probably vote for the three server architecture recommendation as a starting off point. Here is a blog series on FAST for SharePoint 2010 if you are interested.

Closing

As I have said, there is no one size fits all. This is just a place to start and based on your plans you will scale up the SharePoint 2010 architecture as needed.

6 comments:

Gerald said...

Jason,

Thanks for a wonderful overview, it has helped allot... I'm in the proces of building a cross farm service enviorment, I would like to build in HA for the service applications MMS, UPA, Web Ana, Secure Store and Search...

While I understand how to build in some HA into search service, I'm not sure how to build it into the other four can you point me to guides or examples on how to get the services into a HA

Thank in advance
Gerald

Jason Apergis said...

Gerald,

Thanks for the feedback. For High Availability for SharePoint Search - did you read my three part blog series on SharePoint 2010 Search - http://www.astaticstate.com/2010/12/sharepoint-2010-search-architecture.html

Jason

Gerald said...

Jason,

Yes, awesome post.. in part it's what got me to inquire on how to get the other 4 services in HA

Thanks in advance
Gerald

Jason Apergis said...

Gerald,

One last comment on HA. I tell lots of clients that SharePoint is sometimes only as good as the SQL Server configuration. Her is something to look into as well - http://www.astaticstate.com/2010/12/sharepoint-2010-high-availability-with.html

Jason

Gerald said...

Jason,

thanks for the additional link, I have my SQL backend components already in a HA configuration.. SQL cluster with a witness server..

what I would like to be able to do is have MMS, UPA, Web Ana, Secure Store in a HA configuration.. to where if one of the servers that host the application service goes offline it "fails" over or picked up by a load balanced service URL... is this possible ? if so could you point me in a direction to find the information ?

Thanks in advance
Gerald

Jason Apergis said...

Many of the services are load balanced between the app servers. So when you turn them on all the servers, you get that HA you are looking for.