MOSS Architecture & Shared Services


From Martin Kearn's A Marvellous Point blog, an article about MOSS architecture and hared services:

I have been doing some work recently on MOSS architecture for large deployments and thought that I’d share some of my findings. MOSS architecture is very similar to SharePoint 2003 in some ways but different in a few crucial areas.

So what is the same?

MOSS adopts a typical 3-tier model with web servers at the front, application servers in the middle and a database server at the back where all the data and config is stored.

The front-end web servers are simple web servers that can be network load balanced to achieve additional performance and fault tolerance (like 2003). The backend database is a typical SQL 2005 database service and can be clustered as you’d expect.

So what is different?

The interesting bit is what goes on in the middle. With MOSS, it is mandatory to have a Shared Service Provider. This is a collection of application servers that provide shared services out to any portals or sites that need them. These services include:

  • Search

  • Index

  • Audience compilation

  • User profiles database

  • My Sites

  • Business Data Catalogue

  • Excel Services

Any of the above services can exist on any number of servers within the SSP. For example, for a small-ish deployment you could have them all on one box, or you could scale them out onto different boxes as you see fit. There are no rules that govern where these services reside within the SSP or how many servers you have servicing them. For example if you want 10 search servers – got for it … “fill your boots” as we’d say here in England!

This model is very similar to the 2003 approach with one crucial difference,  the SSP has no portal affiliation. This means that you are not forced to have a specific parent/child style portal topology in order to use Shared Services which was one of the big sticking points with Sharepoint 2003 shared services.

So what does the ‘Portal’ actually do now?

For starters, it is now called ‘Corporate Intranet Site’, not ‘portal’ and it is just another type of site collection that is hosted on an IIS site (called web applications in MOSS). Portals no longer contain any application services such as search, my site etc – all these services now have to come from an SSP. This means that all you need to host a portal is a web server and a place to put the content database.

Different portals can live on their own hardware which is completely isolated from any other hardware other than the fact that it consumes services from a centrally managed SSP. Alternatively, you can put some of your portals on shared hardware and some on dedicated.

I always hear requirements around different business units wanting their own portal which has its own visual style, custom webparts, different SLAs etc . With this model, there does not have to be any affiliation between any portals or sites if it is not required.

This diagram outlines the logic of how SSP provide services that are consumed by several site collections:

So does this mean that ‘Supported Farm configurations’ have gone?

In short, yes!

This model means that you can scale any element of the system out as you see fit. However, there are several recommended server layouts that will meet most scenarios. These broadly follow the small, medium and large models of Sharepoint 2003, but should be considered as starting points only. You can easily deviate to a different setup depending on your requirements.

So how does all this map to physical servers?

All three tiers (web, application, database) of the SharePoint model can be hosted on a single machine or scaled out to a huge collection of servers to meet the requirements.

Most organisations will want some level of fault tolerance and separation between server roles. Typically these kind of organisations will have at least 2 web servers running your portals and sites, at least one application server hosting all services (maybe a second for fault tolerance) and one database cluster. This diagram shows this model:

Larger organisations may want to have separate web servers for each of their portals, sites and my sites. They may also have multiple application servers as part of the SSP. This diagram describes this model:

I hope this was usefull. There is an increasing amount of content on the public Microsoft sites now about this stuff, so be sure to have a dig around.

You can find this artcle here

Computer developer/consultant from Portugal. You can find me at ricardo.magalhaes@gmail.com

Posted in Sharepoint, Sharepoint
2 comments on “MOSS Architecture & Shared Services
  1. Aakif says:

    Hi,

    I m using sharepoint 2007 in a secured environment where local service and netwrok services account has very restricted access and these accounts are blocked in SQL machine. I have a small server topology. Now after configuration everything is working except Audiences. They are not giving any error when I compiled but they are always empty (0 membership). I checked the Event viewer but it also did not contain any error regarding this. So am I missing anything because it is working perfectly in non-restricted test environment.

    Thanx

  2. Remco Ploeg says:

    Hi,

    Aakif did you resolved this issue already? I have the same problem here. No errors nothing. Can someone please sent me an email with the solution?

    thanks,

    Remco Ploeg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: