Windows Version Upgrades

No discussion on highly available upgrades can ignore the operating system. Although you may be a SQL Server DBA, you need to consider that your operating system will need to be upgraded at some point. This is one of the reasons you will need a great working relationship with your systems engineers to ensure that the proper communication flows between groups.

Should You Upgrade Your Version of Windows?

Upgrading to a new version of Windows causes heartache for many administrators because they are changing the foundation of their entire server. Windows is Windows, but as you know, there are differences between Microsoft Windows NT 4.0 Server, Microsoft Windows 2000 Server, and now Microsoft Windows Server 2003. Should you upgrade your operating system? You must answer this question, and the answer here is the same as it was in Chapter 3, Making a High Availability Technology Choice : It depends . If you have a current production system that is running, stable, and has SLAs with valid support contracts in place (that is, the product has not reached the end of its support life from the manufacturer), you might not need to upgrade the operating system. You might want to upgrade it, on the other hand, if your application software (such as SQL Server) has a feature or performance characteristic you need that is dependent on some feature of the new operating system or, say, if you need more scalability, which could be provided by the higher memory and processor capacity of a new operating system. The bottom line is that although you might want to upgrade, you might be able to avoid this for a period of time that you will determine.

If your operating system is near, at, or beyond its supported phase, regardless of the supportability status of your application software, you should consider upgrading your version of Windows. This is not a ploy to trick you into spending money. Microsoft would like you to have stable, available, and supported solutions that you are happy with. It wants you to have the peace of mind that comes from knowing that, should you run into any problems, you can pick up the phone and have someone say, That product is still supported.

Like many customers, you might have a legacy system with no support, but that system should be fine as long as you and your staff can handle any known issues that come up, understand that the manufacturer might not have fixes for other issues that might arise, and know that any downtime that might occur because of that lack of fixes is acceptable from a total cost of ownership (TCO) perspective. You will be able to handle only problems that fall within the realm of what you can fix for an end-of-life product if no more fixes are available from the manufacturer, so understanding and accepting the risk is crucial for systems that may be mission-critical. If that is the case, ensure that any and all relevant documentation is complete and handy.

Another major factor is the abilities built into each version of the operating system. For example, if you are using SQL Server virtual servers, upgrading from Windows NT 4.0 Enterprise Edition to Windows 2000 Advanced Server or even Windows Server 2003 would be a huge benefit because clustering is greatly improved in those versions. Remember to take into account how the technologies you are using might have been enhanced or changed (possibly impacting you in a negative way) in the upgrade to the next version.

Also remember the hardware platform. At some point, the OEMs and hardware vendors who provide the system, adapters, and other components will cease both production and support on a certain operating system or hardware platform. If you later need a replacement component such as a processor, memory, disk controller, network card, or connector, it might not be in the supply chain, and the system would then have a point of failure from which there is no easy recovery. Also, if the software that controls the hardware component is no longer supported, no fixes will be possible for a recurring problem, even if the underlying hardware still functions.

There are many factors that go into a decision to upgrade your operating system ”cost, features, compatibility with your current applications, and so on. Just because an operating system is new does not mean you should wait for one service pack and then upgrade to it automatically, as has been a common practice for years . Windows is tested extremely thoroughly for reliability and stability prior to release, and it gets better with each succeeding release of the operating system. If you need the features or benefits that come with, say, Windows Server 2003, you should definitely consider it for your environment.

Performing a Windows Version Upgrade on a Server

There are really two varieties of Windows upgrades: upgrading stand-alone servers and upgrading clustered servers (that is, server clusters, not Network Load Balancing). When you are running a mission-critical application like SQL Server on your server, minimizing your downtime becomes crucial. The most obvious method of reducing downtime besides planning and testing is to perform your version change onto new hardware and not on your existing servers. Why?

First and foremost, from a contingency standpoint, if something goes wrong on your new hardware during the cutover, your old hardware configuration has not changed, giving you the perfect fallback or rollback plan. In fact, it should be exactly the same as when you stopped allowing traffic to hit it, so you should have zero loss of any data or functionality. If you use the same hardware, your rollback plans might be hard to recover, and if you have to do a complete reinstall, you will never be exactly in the same state you were in prior to reconfiguration. Second, you can reduce the amount of downtime if you can start building your system while the other is up, and then just have to do some minor tasks instead of many things after you stop traffic to the current production server. In terms of making an upgrade available ”whether Windows or SQL Server ”one of the best things you can do is perform it on new hardware. The difference between being down 20 minutes or 20 hours is huge. Last, but not least, you will get the benefits of newer, faster hardware, which should extend the amount of time the system can be kept in production. If you use your existing hardware, which might be more than a few years old, it might work, but how long will you be able to keep it in production? Remember that newer versions of software, including operating systems, require more horsepower. Hardware prices have come down over the past few years and you can get an extremely capable server at a fairly reasonable price.

Tip	In a multiple upgrade scenario, such as upgrading from Windows NT 4.0 to Windows 2000 and SQL Server 7.0 to SQL Server 2000, you should upgrade your operating system first, and then SQL Server.

Important

Remember to test your systems thoroughly after configuration and back them up once you have established that the installation of the new operating system is working properly. This ensures you can recover to the new, known, good configuration. Do not decommission old servers until you know your new ones are working properly!

Upgrading Stand-Alone Servers

Upgrading a stand-alone server is straightforward. If you are using the same hardware, whatever functionality that server hosts will be completely unavailable during the upgrade process. This puts you at risk in the event that things do not go as planned during or after the upgrade and you need to roll back to your previous state. If you are doing this on the same hardware, at that point you will be relying on your backups . It is always best to configure a new server and then decommission the older one after you confirm that it is up and running in the way that it should be.

Note	Doing a version or SKU upgrade can present some challenges if you are a constant consumer of SQL Server or MDAC hotfixes. Be sure to reapply any hotfixes not included in the Windows service pack level on the system if you elect this procedure.

Upgrading Clustered Servers

Upgrading servers in a server cluster is not dissimilar to upgrading stand-alone servers, as each node would individually need to be upgraded. A cluster presents different challenges, however. First and foremost, is your hardware solution still on the cluster Hardware Compatibility List (HCL) for your operating system choice? It might be, but it also might not. If it is not, you will have to buy new hardware. Could you upgrade on your current hardware and have it still work? Maybe, but if problems occur, you will technically have an unsupported solution. The biggest problem would be in terms of driver compatibility for your hardware, especially for components like RAID controllers. Do not put yourself in this situation.

You also now have more than one server that needs to be dealt with because it is an entire solution. How do you handle a multiple-server upgrade and keep your servers somewhat available? The best approach is to use new hardware, but if you are going to utilize the same hardware, the answer is actually easy; perform a rolling upgrade. A rolling upgrade is when you take the resources currently owned by one node and manually fail them over to another node while you are upgrading its operating system. This is where all of your planning comes into place. If you planned your system resource usage properly, you should have no performance impact after a failover and there should be no need to cause another availability interruption by failing the resources back (or to yet another node) until you are going to upgrade the other nodes in the cluster.

Warning

You cannot mix versions of server clusters in a day-to-day production environment. This means that you cannot, say, keep one node at Windows NT 4.0 Enterprise Edition and one at Windows Server 2003 while you are checking things out. Once you make the decision to upgrade your existing server cluster, all nodes must be upgraded. During a rolling upgrade, this state does occur because not all nodes are upgraded at once. A mixed-mode cluster is fully supported in a rolling upgrade scenario but not as a permanent production platform.

More Info

For detailed information on performing a rolling upgrade to a Windows 2000 server cluster and what versions you can upgrade from and to, see http://www.microsoft.com/windows2000/techinfo/planning/incremental/rollupgr.asp for Windows 2000 . For Windows Server 2003, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/deploy/upgrdmigrate/RollUpNT.asp.