Yes, of course you can use Microsoft clustering to provide a highly available platform for Exchange Server 2007. In fact, there are two ways to do it.
- First there is the technology known as Single Copy Clusters(SCC). This is basically the same kind of server clustering we bet with Exchange Server 2003 Enterprise. You need to have a storage solution that will allow all nodes to access the disks and it will host the Quorum and the Physical Disk resources needed to cluster the databases and transaction logs.
- Second, there is the technology known as Clustered Continuous Replication (CCR) which has some really wonderful capabilities not found in basic Server Clustering.
The real fun comes in with CCR. Now, there is no need for high cost storage devices. You can use nice and fast direct attached storage (DAS) to meet the storage requirements. OK, somebody just said, "Whoa, what about the quorum, and how does this work when everyone says you need shared storage media for server clustering." Let's address this right now.
Quorum - For server clustering, we had the choice of using a quorum hosted in the shared storage media (i.e. Fibre SAN or iSCSI SAN) or using Majority Node Set (MNS) for the quorum. MNS keeps a local copy on each node of the cluster and so long as there is a majority, the cluster will run. So, with a two node cluster, having two nodes running MNS does not allow for a failure. One out of two is not a majority. So, to make MNS work, we need at least three nodes. Wait... If you remember, we talked about the new File Share Witness (FSW) before. If we use the FSW along with MNS, we can get a third (non-cluster node) server involved to help us out. What we do with FSW is we install the hotfix on both cluster nodes and create a share on another server to host a third copy of the quorum information. Microsoft recommends that we use a Hub Transport server for the file share in this case. OK, so our quorum is taken care of by using two nodes and a File Share Witness.
Data Storage - Normally the stores and the transaction logs are maintained in a SAN to allow access to all nodes of a cluster for Exchange Server. With CCR, we can host the databases locally to each node. CCR uses a form of log shipping to copy transactions from the active node to the passive node. In the event of failover, the passive node will run Exchange. Yep, I hear you. "Wow, that sounds great, but won't there be lost transactions if the active node did not completely replicate to the last second?" Yep, you would be right if you asked that one. This mis-matched state is known as a lossy failover. To resolve this issue, Exchange Server 2007 uses the Transport Dumpster. Basically, what happens is that the newly active node (formerly passive node) that has less information than the previous active node (now dead or now passive) because the logs were not fully shipped over to it. The replication service can request that transactions be replayed by the other servers (in particular the Hub Transport server) to the newly active server to get it up to date. Yes, it is still possible that some data will be lost (such as marking messages read/unread, moving messages between folders, and accepting/rejecting meeting requests), but it is minimal and should not involve any lost mail.
With CCR, the costs of clustering Exchange mailbox servers is greatly reduced because of the improvements in technology allowing us to get rid of extremely expensive SANs and use of less expensive DAS.
Clustering of Exchange just got a great deal more fun!