To cluster more than two nodes, you will need the following:
- Two or More Microsoft Windows 2000 Datacenter Server Licenses
- Two or More SQL Server 7.0 Enterprise or SQL Server 2000 Enterprise Licenses
- The latest Windows 2000 and SQL Server Service Packs
I want to emphasize that you always want to go with the latest service packs, as many irritating cluster-related bugs have been fixed by them.
Hardware Needed for Clustering
Assuming you are clustering two SQL Servers, you will need at the very minimum the following:
- Two servers with a minimum of 256MB RAM and a single Pentium III CPU.
- One shared disk array that supports RAID 5 or 10, either SCSI or fibre channel.
- Each server must have at least one local SCSI hard disk on its own SCSI controller.
- Each server must have a SCSI or fiber channel adapter to talk to the shared disk array. The shared disk array cannot use the SCSI controller used by the local hard disk or CD-ROM.
- Each server must have two PCI network cards (one for the private connection and one for the public connection).
How you size the physical servers (CPUs, RAM, amount of shared disk array) is very similar to how you would size a non-clustered server if you plan to use an Active/Passive configuration. But, if you intend to use an Active/Active configuration, then ideally each physical server needs to be sized to run all instances of SQL Server that run on both the primary and secondary nodes, should failover occur and both instances of SQL Server have to run on the same physical server.
Ideally, both physical servers should be identical in hardware, drivers, software, and configuration. There are some exceptions to this allowed, but I would not recommend making them. The closer each physical server is to each other, the less problems you will have.
Another very important consideration when selecting clustering hardware is that is must be on Microsoft’s Hardware Compatibility List (HCL) as a supported system. What do I mean by a supported system? Before Microsoft will support your cluster, all of the cluster hardware you select (servers, cards, shared array, etc.) must have been tested as an entire system and approved by Microsoft. If the system you purchase isn’t an approved system, then Microsoft will not help you if you call them, even if you pay them for support.
Even if all of the individual components of your cluster system have been approved individually by Microsoft for clustering, if they have not all been tested as a single system, then you will still not receive any support. That’s why you need to check out the HCL carefully before you order your equipment to ensure that you purchase an approved clustering system.
Unfortunately, Microsoft’s HCL website is often outdated. What this means is that as new equipment comes out (and we always seem to want to use the latest and the greatest), it may not be added to their approved cluster systems for months. You can of course take the risk of selecting equipment that is not part of an approved Microsoft system (hoping that it will eventually be tested and certified by Microsoft), but should you have a problem and call Microsoft, you risk not getting any help from them.
Setting Up and Managing a SQL Server Cluster
This topic could fill a book, but unfortunately, there is not enough room here for that. So what I will do here is just cover the basics so you have some feel for what you face.
Based on my experience with SQL Server clustering, you should keep the following in mind:
- Buy an approved cluster system and have it delivered to you 4-8 weeks before you plan to implement it. This will give you lots of time to learn about it and work out any problems. I guarantee you, you will have problems.
- Consider attending training on clustering, or at least bringing in a consultant in early in the game to help you plan your implementation. If you have never done this before, you will need all the help you can get. Unfortunately, there is not a lot of good information available on clustering, so you will have to fend for yourself more than you usually do.
- Once your cluster is up and running, test it thoroughly as possible using the same databases and clients you intend to use on it when you start production.
- Thoroughly document everything as you build your cluster.
- Develop a plan to regularly monitor the cluster.
- Develop a plan to regularly test the cluster to ensure that it will failover as expected.
- Develop a formal backup and recovery plan, and test it.
- Create a disaster recovery plan for what you intend to do should you loose all the nodes in your cluster.
Implementing and managing a cluster is complex. You will want to assign a team of top network and database administrators to implement and manage it.
Is Clustering for You?
Hopefully, this article has provided you with some additional information on SQL Server clustering that you didn’t have before. And I hope I haven’t scared you away from SQL Server clustering.
While SQL Server clustering is not an easy challenge, it is often a worthwhile one. After installing two SQL Server clusters myself, and currently working on a third, I feel that SQL Server clustering is very valuable for many organizations, and in fact it has reduced my stress own level somewhat. Now I don’t have to worry (as much) about extended periods of down time. Now that the clusters are up, they haven’t presented any problems and are purring away.
]]>