Designing a SharePoint farm: Tiers before bedtime

In the eighth part of Robert Schifreen's SharePoint 2010 journey, he finds that reading between the lines is an essential part of understanding Microsoft's approach to specifications.

The three-tier model semed the best way forward for performance, convenience and reliability for our SharePoint farm. The first tier contains a SharePoint server doing nothing but IIS things. The second tier comprises three more SharePoint servers doing everything except the IIS things. Tier 3 is still SQL Server. In this layout, the middle tier machines can load-balance themselves and we can keep adding new servers to this layer if there are performance problems.

The big spike in IIS usage will come when students get to join what will start off as a staff-only system, so my plan is to possibly bring a second IIS server into the first at that point, and have different points of entry for staff and students.

This will add some useful resilience and also some natural load balancing. (In truth, the second tier machines will have the IIS role enabled, so I can surf to them directly for troubleshooting and in order to provide some emergency resilience. But the existence of this facility will not be widely advertised.)

I did briefly toy with the idea of splitting tier 2, instead of them all being general 'everything except IIS' servers, and dividing the loads more specifically. I'd seen recommendations, for example, that database indexing should be allocated its own server.

I discounted the idea for two reasons. First, I want to minimise the number of different server configurations I have to manage. Second, if all three servers do precisely the same roles, it's simple to bring down any one of them for maintenance without having to reconfigure any of the others.

Having decided on a farm architecture, we also needed to think about the storage architecture too. The web, and especially TechNet, is full of warnings that storage can be the major bottleneck, and that it's best to split the major data paths across separate physical drives.

We originally drew up a plan that saw us using around 20 separate drive volumes on the SQL server, to include content databases, non-content databases, search indexes, transaction logs, tempdb, and so on.

A subsequent session with SharePoint 911 convinced us that this was not a wise move because it would be too difficult to manage. Also, our SAN should be able to take care of ironing out any storage bottlenecks anyway. So we decided to start off with a couple of 1.6TB volumes, to put all the databases on those, and then to request further volumes from our SAN people as and when required. Moving a database from one volume to another, within the same SQL server, is relatively painless.

A terabyte here, a terabyte there

At present, 1.6TB is the maximum volume size that our VM infrastructure supports. This is because our version of VMware is limited to 2TB volumes, of which our server people need 20 percent to ensure smooth running and reliable backups.

SharePoint being SharePoint, of course, means that you can't really put a full 1.6TB of data in a single database, even though SharePoint and SQL Server are supposed to be grown-up, enterprise-level products.

The web, and especially TechNet, is full of warnings that storage can be the major bottleneck.

Microsoft originally advised that databases should never grow to more than 200GB, after which one could expect unspecified performance problems. With the release of SP1 of SharePoint, Microsoft revised the figures upwards to around 1TB, assuming you don't use features such as workflow or have lots of item-level permissions.

Microsoft being Microsoft, of course, there's no actual code changes in that area with SP1, and it's just a revision of the recommendations. Those new figures that are advertised alongside SP1 actually apply even if you don't install it.

Crucially, a SharePoint site collection can't span more than a single database. The classic recommended model for a SharePoint-based intranet is to have it in a single site collection, in order that SharePoint can most easily manage the navigation. But even at 1TB, that's a real limit that we could potentially reach. This greatly affected the structure of our staff intranet, and the way we architect its databases.

Next: Partitioning the intranet and dealing with disaster

Robert Schifreen has reported on and implemented online technology since the early 1980s. His latest project has been a large SharePoint 2010 installation in tertiary education. We will be serialising his experiences, positive and negative, in getting it to the stage where it's ready for action; the entire series will also be available as a downloadable white paper.