One of my readers, Steve, posed a good question to me asking which option would be the preferred option between SQL Clustering and SQL Mirroring.
As with all technology decisions, there isn’t any one answer that fits all. There is only a decision that’s the right decision for any given company with a given culture, given specific constraints at a precise moment in time. When the culture, technology (hardware or software) or any constraints (like budgets, available skill sets etc.) changes, the original decision may not remain the right decision and the evaluation *should* be recalculated. I say should because it’s not always practical to revisit technology decisions frequently. That being said, how often have you posed the question “Why is it being done like this?” and received the answer “Because that’s how we’ve always done it.” or “Because we’ve done it that way for years.”? Given the fast pace at which technology changes, every major technology decision should be accompanied by a clear timeline for Return on Investment (ROI). I believe at the end of that timeline, plus 50%, the original decision should be re-evaluated. If not enough has changed in the equation to warrant an altering of the original decision, then savings continue post ROI. If however factors have shifted dramatically, then it should be time to re-evaluate. Change is the only constant…
OK, OK. I’ll get off my soap box now and reflect, based on my own personal experience, on Steve’s question. It is a very good question indeed and I’m just going to reflect my abbreviated view here.
Hardware cost. Clustering has greater hardware cost due to the shared storage requirement of the cluster. Clustering generally means SAN storage is involved. If you don’t already have a SAN, or have plans and budget for a SAN, clustering will be an expensive option.
Idle hardware. I’ve never met a CFO who liked the idea of having a Extra hardware idle, giving no benefit to the organization, or should I say active benefit. That’s usually the tunnel vision view of the bean counters. With Mirroring, the passive node is just waiting for failover and while we as technologists know and understand that in itself, that is an important function, CFOs generally want to see more Active/Active use of their hardware.
Automatic failover. Yes, both solutions provide automatic failover… sort of. Clustering is true hardware level failover without requiring applications to do anything because the instance is virtualized. Mirroring on the other hand requires application code to be using ADO.NET or SQL Native Client in order to do Client Redirect properly and create the automatic failover ability.
Clustering doesn’t do load balancing or scaling. You have to manually spread your SQL instances across the cluster nodes in order to load balance. Peer-to-peer mirroring allows data access from any of the peers, resulting in better scaling.
Update conflicts. Mirroring doesn’t resolve update conflicts resulting from multi peer updates mentioned in #4, out of the box. As a result, the benefit in scaling listed in #4 could be offset by having to deal with update conflicts.
Expertise required. Clustering is very complex and most DBAs avoid it if they can. If you’re going to cluster, you have to have people with the skill set on hand to maintain it. Mirroring on the other hand is a less complex topic that can be mastered by most DBAs. Mirror + 1
Assuming per #3 that not all your applications are “Designed for Mirror”, security and update patching can become a problem when you’re running something like a 99.999% uptime SLA. A cluster backup node can be patched and failover forced to the patched/backup node. You can then patch the primary node and let the system run on the backup node until the next time patching needs to be done. At that point in time, the patch process will fail the cluster back over to the primary node.
Storage redundancy. A Mirror has redundant storage. A Cluster has shared storage. True, SAN technology will have RAID redundancy built in, but at least a RAID5 redundancy design is used in all data storage, so it stands to reason that all members of a Mirror will have some form of redundancy anyway. The question is how far apart your mirror members are. It’s not likely that a Cluster will survive a complete Datacenter loss, but a Mirror with an off site member could.
As you can see, there are many pros and cons to each solution and what is the right solution for you, will depend on your given factors in the equation.
If you can afford both the hardware and the technical expertise involved in doing clustering, then it has been the tried and true method to use. True, mirroring is making inroads on this title, but most DBAs will still opt for clustering if given the choice. From personal experience, I’ve encountered less problems with *PROPERLY* run SQL Clusters than with Mirrors.
CheersC
That’s why you’re reading this post. 
