Introduction

People don't plan to fail; they fail to plan. Single node clustering provides organisations with a ready-made scale-up or high availability platform from the beginning of the deployment.

Often in a project, deliverable deadlines, budget constraints or management directive ends up enforcing the Nike methodology - "Just Do It." This almost always goes hand in hand with "We'll fix it later." How many times have you identified a risk only to be told, "that doesn't apply to us", or "maybe, but we'll deal with that when we come to it."

A little planning and forethought goes a long way, especially in technology projects where a lifecycle can live for 3 - 5 years. This is even truer these days where production systems cannot afford downtime to perform maintenance or performing a side by side upgrade just isn't cost effective.

This is where a single node cluster can be of great assistance. Clustering provides a high availability solution and SQL Server supports Microsoft Clustering Services out of the box. Single node clusters deliver a number of benefits. Of course, there are some additional costs and overhead; however these are usually acceptable when compared to the advantages. As always, apply your own budgeting and cost recovery models to each situation to determine the cost / benefit trade-off.

Advantages

From a technical and, depending on the product, staff view point; a reinstallation on new hardware will often require

• Changing your server names
• Setting up ODBC connections
• Modifying application configuration
• Retraining users

None of this is necessary if you have already deployed a single node cluster; you are simply expanding the underlying infrastructure without impact to the application layer.

One of the biggest problems addressing such issues as scaling up; hardware refresh; and adding high availability (HA), is that to do so usually involves extended downtime and significant effort on the part of all teams supporting the environment. This includes database, application, infrastructure, storage and networking teams. All of this adds up to risk, staff time and lost revenue - all of which equate to $$. As every organisation wants to reduce their operating costs and maximise their revenue (ideally with an increased profit margin), this is an expensive problem.

If you begin with a single node cluster, these tasks are simplified with reduced downtime. All of the above risks and costs are reduced, thus saving your organisation money. This is a good thing.

Scale Up and Hardware Refresh

If you find your initial hardware platform is not meeting your performance or capacity requirements, or your hardware has come to the end of its life (either through vendor support, warranty or usefulness); single node clustering provides a fairly pain free solution to scale up / refresh.

1. Build your new server as required
2. Add the new node to your existing cluster
3. Install SQL Server on the newly added node
4. Fail your cluster groups across to the new node
5. Evict your old node

Adding High Availability

Of course, clustering's primary purpose is to provide a high availability solution for Microsoft solution stacks. Organisations usually deploy solutions to meet their baseline requirements. It is rare that an organisation is in a position to deploy the ideal, bells and whistles, all singing all dancing solution because it meets requirements they may have in the future and it makes the technical staff happy.

If in the early days of your product, HA is not a requirement, it is doubtful that a single node cluster was deployed. Adding HA later will almost certainly require a rebuild. Most of the time this will be a significant time down the line, in which case it is unlikely that the existing hardware platform is still available; thus requiring additional purchase of hardware which adds to the costs in addition to any downtime and staff time.

Again, performing major architecture redesign and implementation has risks and costs. If you have deployed your solution in a single node cluster from the beginning, adding HA is trivial.

1. Build your new server as required
2. Add the new node to your existing cluster
3. Install SQL Server on the newly added node
4. Fail your cluster groups across to the new node

Depending on whether you are going to continue utilising your existing node or replace it completely the next steps will be to add further nodes and / or evict the existing node.

Disadvantages

Every solution has its pros and cons and single node clusters are no different. There is obviously an additional cost and overhead in deploying a clustered solution, whether it is single or multi node. Each of these should be weighed up as would any other design option and the best fit chosen for your organisation.

Because a clustered solution requires specific hardware configurations, they must be taken into account

• Hardware must be on the Microsoft HCL
• At least two Network Cards must be available
• At least two network ports must be available
• Depending on your network, this may require a separate switch or VLAN
• Shared storage must be available

Out of the above list of additional requirements, the primary additional cost is shared storage. If you are not deploying a cluster, local storage may be acceptable to your requirements. This is not available in a clustered environment. Shared storage must be used. Depending on your solution, you have three options

• SAN (Storage Area Network)
• NAS (Network Attached Storage)
• DAS (Direct Attached Storage)

You should choose the most appropriate solution for your requirements.

Choose the best solution for you from both a business and technical view point.

Conclusion

Single node clusters can provide a cost effective solution for future expansion, business requirements or replacement. Often organisation want to reduce costs or are restricted by budgetary constraints; thus only deploying a "fits now" solution. With a little forethought, tight budgets can still deliver an enterprise class solution capable of meeting your requirements today and tomorrow.