What is it?
Put simply, clustering is a way of insuring that users enjoy near-uninterrupted service of server failures. It requires some sort of shared disk between the servers - we use our Storage Area Network to provide that.
The oldest example at Drew is "Causeway", our Netware 6.5-based file and print server cluster. It actually consists of two (formally three) servers attached to the SAN, serving out the Users, Depts, Courses, etc. volumes and providing service for most networked printers on campus.
Each "service" (the Users volume, for example) can only be handled by one server at a time. Most of the time, we have the services split between the two servers in Causeway for performance reasons. However, if one server fails (or needs to be shut down for maintenance), the services it was providing "fail over" to the remaining server. Users might see a brief (usually under 30 seconds) disruption, but that's far better than the 20-40 minutes it took us to recover from a server crash before we moved to cluster-based services in 2001.
What services are clustered?
You read about the Causeway file/print cluster above. We have two other clusters.
We have a second Netware 6.5 cluster for GroupWise. Due to the demands of the email software, we are using four servers in the GroupWise cluster, but we can provide service on just two, should we have to. There would be some loss of performance, but it would work.
The third cluster is a two-node Windows Server 2003 Enterprise cluster. We're using it to provide fault tolerant database services, using both Microsoft SQL Server 2000 and the open source MySQL database (both versions 4.1 and 5.0).
In all three cases, the servers are split between the Learning Center and Brothers College. While our only disk array is in the Learning Center, and if it was destroyed we'd be out of commission until a new one is installed, having half of each cluster in Brothers College would speed that process up quite a bit once a new array arrives.