To virtualise or not to virtualise?

In the seventh part of Robert Schifreen's SharePoint 2010 mission, he explains the practical, detailed decisions about configuration and resources, starting with virtualisation

Some experts seem to advise against virtualising the SharePoint database server, but for us the advantages outweighed any potential disadvantages.

In addition, some experts suggest that any more than two virtual CPUs is actually a bad move, since the server spends too much time waiting for CPUs to become available. This is something we'll need to watch. We also took on board a widely held opinion that, on a virtual database server, you should not use auto-growing, thin-provisioned databases because it's too easy for the hypervisor to lose track of how much free space you actually have.

You'll need to change some of the defaults in SQL Server because they're not suitable for SharePoint. For example, the content databases are configured to grow by 1MB at a time. Which means that, if someone uploads a 50MB file, the auto-grow routine will be called 50 times and thus slow down the system. For now, I've changed that figure to 500MB.

It is a valid point that a single database server is also a single point of failure, and it's something that we considered carefully.

Our SAN physically writes each byte twice onto our RAID 10 disks, which provides a fair amount of protection against physical data loss. The data is of course backed up very often and kept off site. We'll also maintain a backup of the database server VM, thus effectively having a hot standby server ready for action at all times. In fact we'll be keeping backups of all the servers for that reason.

Just because SharePoint sees a single database server, there is of course no need for the overall infrastructure to contain only one. Technologies such as SQL Server clustering and mirroring can ensure that all data written to one server is immediately mirrored to another one, and that the backup server can automatically be swapped in if a problem is detected by the main database machine.

We spent some considerable time looking at the possibility of deploying SQL server mirroring (it seemed like a better solution than clustering). However, we ultimately rejected it for a number of reasons.

First, it actually requires three servers rather than two, with the third machine acting as a monitor in order to detect any situation that might require a failover. This seemed unnecessarily complex to me.

Secondly, as already stated, we could achieve a lot of the features of SQL mirroring by simply using the inbuilt abilities of our SAN and our resilient VM infrastructure.

Thirdly, our DBA team had recently had some bad experiences with another mirrored server.

Perhaps most importantly, SQL Server mirroring is incompatible with remote BLOB storage. While we'd ruled out RBS for now, we didn't want to burn our bridges. So I decided that a single SQL server would suffice for the time being, but that we should continue to investigate SQL mirroring for the future in case it became a real necessity.

Many a tier

It was looking like a two-tier farm model would be just what the doctor ordered. Two or three SharePoint servers in tier 1, running IIS and doing all the grunt work, and a database server on tier 2.

But this model has an inherent problem. If you throw lots of servers into the first tier, SharePoint can automatically share most of the grunt-work load between them. That's good news so far. But what it won't load-balance is the IIS role. The second (and subsequent) IIS installations will never be used at all, unless a user surfs to one of those servers explicitly.

Round-robin DNS would have solved this. But it doesn't count as proper load balancing as far as I'm concerned. Another solution was to connect the SharePoint servers to our F5 load-balancing appliances. Users then surf to the public address of the SharePoint pool as defined in the load balancer, and it passes the request to whichever server is the least busy (and makes sure that the remainder of that session remains on the same server).

The downside of this approach is that it requires expertise and input from people outside of the SharePoint team, and I was keen to avoid having to learn and manage yet another critical platform. Especially as I'd be sharing the F5s with other systems and thus might not be granted full access to them.

I decided to take our relationship with SharePoint to the next level, and specced out a three-tier model.

Next: The implications of the model sink in

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.