Service Pack Installations

Something as simple as a service pack installation is not so simple in a cluster. Whether doing a Windows or SQL Server service pack, there are added considerations to keep in mind before proceeding with them.

Windows Service Packs

After you make any major change on your system, you should always reinstall the latest Windows service pack as it may overwrite important DLL files that are used by clustering. This is especially important right after you cluster Windows. When you cluster Windows, it uses the I386 directory, which contains the base Windows files to copy. Even if your system previously had a service pack installed on it, those files would be overwritten by the cluster installation. Once your cluster installation is complete, you would have a hodgepodge of files from base Windows to whatever service pack you've installed.

Each Windows service pack contains a lot of fixes that are critical for running a cluster. I would recommend never running a Windows cluster with anything less than Windows 2000 Service Pack 3 due to the number of fixes that were released in that service pack. Even though the service pack will let you do otherwise, you should always follow these steps when installing a Windows service pack:

1. Log onto the server you want to install the service pack on and open Cluster Administrator.

2. Optionally, you can fail over any resource that the server owns. I would recommend doing this since the service pack will require a reboot.

3. Right-click on the server name where you're installing the service pack and select Pause Node.

4. Install the service pack and reboot.

5. After the reboot, open Cluster Administrator, right-click on the server you just installed the service pack on, and select Resume Node.

6. Perform steps 1-5 on the next node in the cluster.

   Caution 

   Never leave two nodes on two different service pack levels.

SQL Server Service Packs

The SQL Server service pack installation is much like the base installation as it's cluster-aware. The installation takes anywhere from 20-45 minutes based on the speed of your hardware. Install the service pack just as you would if the SQL Server weren't in a cluster from the cluster resource's preferred owner. Make sure that the node is failed over to the preferred owner before starting the service pack. The first screen of the installation (shown in Figure 11-32) will ask you what virtual SQL Server name you want to install the service pack on.

Figure 11-32: Choosing the virtual SQL Server name to install the service pack on

If you mistype the virtual SQL Server name, you will receive this error message:

Click OK and type the name of the valid virtual server name. If you can't remember the name, go to Cluster Administrator and find the name in the SQL Server cluster group.

You will then need to type the user name and password that you want to use to copy and install the service pack with on the Remote Information screen (shown in Figure 11-33). I use the account that starts the cluster for this. This account needs to be a valid administrator on both nodes.

Figure 11-33: Remote Information screem

Note 

You may be prompted to reboot both nodes based on whether the communication components were upgraded. You can troubleshoot the setup the same way you troubleshoot the installation of SQL Server.

One thing to keep in mind is that whenever you perform a service pack upgrade in a cluster it will upgrade both nodes at the same time for that instance of SQL Server. Since the SQL Server tools are shared, any instance installed on the cluster will have the upgraded tools as well. This may be an undesired effect of the service pack installation.

SQL Server Hotfix Installations

Hotfix installations are not cluster aware in SQL Server 2000 (at the time I wrote this book). To install a hotfix, use the following steps:

1. Back up the files that are to be affected by the hotfix.

2. Go to the node that does not own SQL Server and run the hotfix on that node. Attempt to fail over SQL Server to ensure that the service will start.

3. While the service is on the second node, perform the hotfix on the first node.

4. Move the resource group back to the primary node.

   Caution 

   Hotfix installations will cause minor outages while you install the files.