As the forum administrator for SQL-Server-Performance.Com, I see hundreds of questions from DBAs on SQL Server clustering. What always surprises me is how misunderstood clustering is. So exactly what do I, and Microsoft, mean when we refer to SQL Server 2005 clustering? Here’s a good working definition:
Microsoft SQL Server 2005 clustering is a high-availability option designed to increase the up-time of SQL Server 2005 instances. A SQL Server 2005 cluster includes two or more physical servers (called nodes) identically configured. One node is designated as the active node where a SQL Server 2005 instance is running in production, and the other node is an inactive node where SQL Server is installed, but not running. Should the SQL Server 2005 instance on the active node fail, the inactive node will become the active node and continue SQL Server 2005 production with minimal downtime.
OK, so far, so good. This definition is straightforward and to the point. But this definition has a lot of implications that are not so clear, and this is where many clustering misunderstandings arise. One of the best ways to more fully understand what clustering can and cannot do is to drill down into the details.
What Clustering Can Do
The benefits of using SQL Server 2005 clustering are very specific. They include:
- Clustering is designed to boost the availability of physical server hardware, the operating system, and the SQL Server services, any of which when fail, causes an instance of SQL Server 2005 to fail. If any of these three fail, another server in a cluster can then automatically be assigned the task of taking over the failed SQL Server 2005 instance, reducing downtime.
- The use of clusters can help reduce downtime when performing maintenance on cluster nodes. For example, if you need to change out hardware on a physical server, or add a new service pack to the operating system, you can do so one node at a time. First, you would upgrade the node that is not running an active SQL Server 2005 instance. Next, you would manually failover from the production node to the now upgraded node, making it the active node. Then you would upgrade the current inactive node. Once it is upgraded, you would fail back to the original node. This cluster feature helps to reduce (not eliminate) the overall down time caused by upgrades.
What Clustering Cannot Do
Notice that this list of what clustering cannot do is much longer than the list of what it can do. This list is long because of the many myths of clustering.
- Clustering is just one part of many required parts to ensure high availability. In many ways, it is even not the most important part, just one of the many pieces of the puzzle. Other aspects of high availability, such as the power supply, are actually much more important. Without power, the most expensive cluster hardware in the world won’t work. If not all of the pieces of the puzzle are in place, then spending a lot of money on clustering may not be a good investment.
- Clustering does not guarantee that there will be no downtime. Some DBAs believe that a cluster will reduce downtime to zero. This is not the case. It can help to reduce downtime, but not eliminate it.
- Clustering is not designed to protect data. This is a great surprise to many DBAs. Data must be protected using other options, such as backups, log shipping, or disk mirroring.
- Clustering is not designed for load balancing. Some DBAs think that clustering provides load balancing between the nodes of a cluster. This is not the case. Clustering only helps boost the uptime of SQL Server 2005 instances. If you need load balancing, you must look for a different solution.
- Clustering requires expensive hardware and software. It requires certified hardware, the Enterprise or Data Center versions of the operating system, and SQL Server 2005. Many organizations cannot justify this high cost.
- Clustering is designed to work within the confines of a data center, and not over geographic distances. Because of this, clustering is not a good solution if you want to failover to another data center located far from your production data center.
- Clustering requires more-highly trained DBAs. SQL Server 2005 clustering is not for beginning DBAs. DBAs with clustering experience command greater salaries.
- While SQL Server 2005 is cluster-aware, not all front-end applications that use SQL Server 2005 as the backend are cluster-aware. For example, even if the failover of a SQL Server 2005 instance is relatively seamless, a front-end application may or may not be so smart. Many applications require users to exit and then restart the front-end application after a SQL Server 2005 instance failover.
Choosing SQL Server 2005 Clustering for the Right Reasons
When it comes right down to it, the only justification for a SQL Server 2005 cluster is to boost the high availability of SQL Server instances. But this justification only makes sense if all the following are true:
- The cost (and pain) of being down is more than the cost of purchasing the cluster hardware and software, and maintaining it over time.
- You have in place the ability to protect your data. Remember, clusters don’t protect data.
- You don’t need to be able to failover to a geographically separate data center.
- You have in place all the necessary pieces required to support a highly available server environment, such as backup power, and so on.
- Your staff includes DBAs who are qualified to install, configure, and administer a SQL Server 2005 cluster.
If all of the above are true, then your organization has all the right reasons for installing a SQL Server 2005 cluster, and you should proceed. But if not all of these pieces are in place, and you are not willing to put them into place, you are most likely wasting your time and money with a SQL Server 2005 cluster, and would probably be better off with an alternative high availability option, such as one of those discussed next.
What Are My Other Options?
SQL Server 2005 clustering is just one of many options available to help ensure the high availability of your SQL Server 2005 instances. In this section, we take a brief look at alternatives to clustering. We start with the least expensive and easy to implement options then take a look at the more expensive and harder to implement options.