Getting to Clustered Windows Server 2003

 <  Day Day Up  >  

Getting to Clustered Windows Server 2003

This section discusses the various methods to get a Windows Server 2003 cluster. You'll also learn the pros and cons for updates versus new installs along with the gotchas.

Consolidating Applications onto a Windows Server 2003 Cluster

Server consolidation offers great promises for lowering cost. However, when the servers are clustered, consolidation without proper understanding and planning can be a failure that results in higher costs. Clusters are used primarily to improve availability through the concept of N+1 redundancy. The thinking goes that as N increases , the added cost of the extra server gets diluted over more applications, and hence savings can be obtained while increasing application availability.

Consolidation planning for a cluster can be quite complicated. Depending on what applications are consolidated onto the cluster, availability can easily be diminished. Furthermore, as N increases, the number of applications affected increases, and the cost of downtime increases. Normal server consolidation planning involves determining the degree of segregation needed between applications in order to reduce possible negative effects:

  • No segregation : All applications are loaded on the system without additional support.

  • Resource management : All applications are loaded on the system and a resource manager (WSRM from Microsoft, ProcessControl from Microsoft, HP Resource Partition Manager, Aurema AMRTech ”A third-party product licensed by Microsoft for its customers, and so on) allocates and manages resource to prevent negative application interaction.

  • Software partitioning : Virtual machines (using products like Connectix, VMware, and so on) are created onto the physical machine and each virtual machine runs a specific application.

  • Hardware partitioning : A single large server is partitioned to run as multiple separate machines. This usually is a high-end solution with large NUMA (NonUniform Memory Access) servers.

However, when consolidating onto a cluster, the last three options are not available because they are not compatible with clustering ”only ad-hoc consolidation without segregation can be performed on a cluster. Therefore, the key to successful consolidation on a cluster is to limit and simplify applications. For example, whereas consolidation onto a cluster of multiple SQL (Structured Query Language)-based applications is likely to yield cost saving (as long as all applications can be maintained on the same version on SQL), consolidations of applications like SQL and Oracle or SQL and Exchange are very likely to cause major problems that lead to low availability for the following reasons:

  • In the case of SQL and Oracle, availability is likely to be affected by conflicts between shared files used by both software applications, but rarely at the same version (Microsoft calls this DLL [Dynamic Link Library] hell).

  • In the case of SQL and Exchange, the problem is likely to come from different large memory architectures: SQL uses the PAE (Physical Address Extension) architecture for accessing more that 4GB of physical memory for large memory. Exchange uses the 3GB architecture for providing more virtual memory to applications at the expense of the operating system (OS).

For the concept of N+1 high availability to really work, all servers must have identical software configurations to allow failover. Yet if the applications have incompatible requirements, the configuration becomes a compromise that affects all applications.

Supported Features and SKUs

Windows Server 2003 has four SKUs (Stock Keeping Units, a term to refer to an edition) that support some form of clustering, as shown in Table 13.1. Unlike Windows 2000, the number of nodes supported in an MSCS-based cluster is the same for the Enterprise Edition and the Datacenter Edition.

Table 13.1. Server SKU Features
 

Windows Server 2003 edition

 
 

Web

Standard

Enterprise

Datacenter

MSCS cluster nodes

N/A

N/A

8

8

NLB cluster nodes

32

32

32

32

Maximum memory

2GB

4GB

32GB in 32-bits 64GB in 64-bits

64GB in 32-bits 512GB in 64-bits

Maximum CPU

2

4

8

32 CPUs in 32-bits64 CPUs in 64-bits


In addition to the SKUs shown in Table 13.1, Microsoft has a few other special-purpose Windows Server 2003 SKUs available:

  • SBS (Small Business Server) is built upon the Standard Edition and is not suitable for clustering due to the built-in infrastructure limits.

  • Windows Storage Server 2003 is a file serving-optimized SKU targeted to NAS (Network Attached Storage) servers. There are two flavors of this release: Enterprise Edition with cluster support and Standard Edition without cluster support. Because the systems are bundled, the cluster functionality is limited to the set of features allowed by the OEM. This SKU acts more like black boxes than general-purposes servers, and upgrade options are limited and are specific to each model. If you plan on using the clustering features, make sure they are supported by the OEM with your applications.

Getting to Windows Server 2003

Just like all roads can lead to Rome, there are many paths that can lead you to a Windows Server 2003 cluster deployment. However, knowing which one is optimum for you can require a lot of preparation and background research. Experience shows that the more time you spend on pre-upgrade readiness, the smoother the upgrade will go, and the less time will be spent troubleshooting problems!

Upgrading versus Clean Install

To upgrade on existing hardware or not to upgrade on existing hardware ”that is the question! There are three possible paths to Windows Server 2003:

  • Upgrade existing system in place

  • Clean-install existing system

  • Replace existing system and migrate users and applications

Quite a few whitepapers discuss the upgrading options. However, it all boils down to a few simple facts:

  • If you upgrade in place and something goes wrong, it's harder to go back.

  • For most clustered applications, rolling upgrades are not an option due to lack of support from the application vendor.

  • A new install takes a little longer, but leaves the servers cleaner and probably more stable.

  • Windows Server 2003 has about the same resource footprint as Windows 2000.

  • Both Microsoft and OEMs took the opportunity of this upgrade to drop support for a lot of old underpowered hardware.

So if you are thinking of upgrading on existing hardware, you first need to check your hardware against the supported list. For ProLiant servers, you can check your specific model through two whitepapers: "Implementing Microsoft Windows Server 2003 on ProLiant Servers" at http://h71025.www7.hp.com/support/reference_library/viewdocument.asp?countrycode=1000&prodid=378&source=TC030609IN.xml&dt=21&docid=18760 and "ProLiant Cluster Support for Microsoft Windows Server 2003, Enterprise Edition" at http://h18000.www1.hp.com/solutions/enterprise/highavailability/microsoft/win2003.html . However, a summary of the rules are

  • No support for servers with CPU slower than 550MHz

  • No support for ProLiant 1850 servers regardless of the CPU speed

  • No support for NICs (Network Interface Cards) using the NetFlex3.sys driver

  • No support for EISA adapters

  • No support for ISA adapters

  • No support for any FDDI

In general, if you have hardware that is no longer being supported, it's cheaper for you to buy new hardware than to try to upgrade your existing hardware. Furthermore, it gives you the luxury of performing the migration with minimal downtime.

Other points to consider when deciding on an upgrade or new install include the following:

  • Windows and Windows applications have a tendency to leave behind lots of orphaned files. Disk space is cheap, so the disk space is not as much a problem as the fact that files exist that are not maintained and are of unknown origins. A complete reinstall allows your system to start from a known state. The older a server installation is, the greater the number of orphaned files that have accumulated .

  • For file servers, migrating to a new server might also be an occasion to clean house. Let users decide what needs to be moved and what can safely be archived and left behind.

  • Are you going to bundle the Windows Server 2003 migration with other work, such as application upgrades, facility upgrades, facility moves, and application migration? This is not recommended as troubleshooting problems can become extremely hard, but sometimes you don't have a choice.

  • In some environments, such as a single Exchange server infrastructure, it can be complicated to migrate users. If you have one of those environments, an upgrade could be much simpler than a clean install.

  • You might be forced to change the Windows SKU (see the following sections for more information), and depending on what path you have to take, you might not be given a choice to upgrade.

  • You might have existing unexplained problems for which you have implemented a workaround until you are given the chance to reinstall and start over.

No matter whether you choose to upgrade an existing hardware or not, see the "Migration Overview - Considerations for Microsoft Windows Server 2003, Enterprise Edition" whitepaper at ftp://ftp.compaq.com/pub/solutions/enterprise/ha/microsoft/win2003/5981-6929EN.pdf .

Upgrade Paths

Microsoft usually allows upgrades from similar SKUs and upgrades to more functional SKUs. However, it's not possible to upgrade while downgrading the SKU functionality. Table 13.2 shows the supported SKU upgrade paths (see http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/supportedpaths.mspx for more detailed information).

Table 13.2. Server SKU Upgrade Paths

To Windows Server 2003

Web

Standard

Enterprise

Datacenter

Windows 2000 Server

NO

YES

YES

NO

Windows 2000 Advanced Server

NO

NO

YES

NO

Windows 2000 Datacenter Server

NO

NO

NO

YES

Windows NT 4.0

NO

YES

YES

NO

Windows NT 4.0 Terminal Server Edition

NO

YES

YES

NO

Windows NT 4.0 Enterprise Edition

NO

NO

YES

NO


Customers running HP ProLiant hardware with Windows 2000 Datacenter Server face a special challenge. HP decided to wind down its Windows 2000 Datacenter program (the program ended December 31, 2003) and transition to a 64-bit Windows Server 2003 Datacenter program. In the future, HP will sell and support new customers only on the 64-bit version of Windows Server 2003, Datacenter Edition. No further 32-bit server Datacenter certifications are planned. Therefore, existing ProLiant Windows 2000 Datacenter customers have four choices:

  • Stay with Windows 2000 Datacenter, using the current configuration. Hardware upgrades are not possible because no new configuration certifications are planned. Software upgrades will be limited to SP3 or SP4 with appropriate hotfixes.

  • Reinstall using Windows 2000 Advanced Server. This is the only solution that preserves a Windows 2000 software base when configuration changes are needed.

  • Reinstall using Windows Server 2003, Enterprise Edition. This is the only solution that preserves the support for more than a two-node cluster. However, this will also require a hardware upgrade of the storage subsystem because HSG80 does not support greater than a two-node cluster in Windows Server 2003.

  • Migrate to a 64-bit server with Windows Server 2003, Datacenter Edition. Multiple 64-bit server models are already available with Windows Server 2003 Datacenter Edition. The best candidates for this option are those running SQL 2000 applications or Oracle applications because they have already been released for 64-bit Windows.

note

It isn't possible to add cluster members to existing Windows 2000 Datacenter clusters because no new Datacenter-certified HP hardware can be purchased, and mixing non-Datacenter servers with Datacenter servers is not supported.


It is crucial to remember that the Datacenter program was designed for high availability. High availability is not obtained by running a special version of Windows (Windows 2000 Datacenter files are mostly identical to Advanced Server files), but rather through a culture of change management and a partnership between customers, OEMs, and Microsoft. Therefore, the benefits of the program can be achieved with the right hardware, discipline, and support relationships regardless of the OS version and SKU.

Another change Microsoft made when releasing Windows Server 2003 is to move away from the simple HCL (Hardware Compatibility List) and move to the Windows Catalog. It allows greater input from the vendors and gives greater control to the vendors . Each version and SKU of Windows has a set of requirements that hardware and software must meet to get the proper logo and get included in the catalog. The major impact for clusters is that the catalog cluster section lists cluster components instead of a complete cluster. Therefore, Microsoft now supports clusters with dissimilar servers as long as each server is in the cluster catalog, the cluster has approved shared storage, and the whole cluster configuration is approved and supported by the OEM.

Rolling Upgrades versus Downtime Upgrades

A cluster rolling upgrade occurs when a node is upgraded while the applications resources are served by another node in the cluster. In theory, it allows a cluster to be upgraded without ever experiencing downtime. Because clusters are designed to provide high availability, Administrators want and expect rolling upgrade options. Unfortunately, MSCS architectural design, in which high availability is provided by an application monitor implemented as a resource DLL, makes rolling upgrades difficult because it involves running a cluster with different nodes having different combinations of software versions interacting and potentially providing different functionality. If you're considering a rolling upgrade, you need to think about the following:

  • Is the application monitor resource DLL on a shared disk or on the system disk?

  • Will the application monitor resource DLL be upgraded?

  • When the cluster is in the mixed version state, will failover be possible, and will it work?

Determining compatibility can be very complicated and requires that you take the following into consideration:

  • If you are upgrading the OS, you need to determine whether the combination of old OS/old application and new OS/old application are supported by the vendor.

  • If you are upgrading the application, you need to determine whether the combination of old OS/old application and old OS/new application are supported by the vendor.

  • Does the new version of the software change the Registry layout for any of the keys being replicated by the cluster?

  • Does the upgrade change any of the APIs (Application Program Interfaces) between the updated software and the nonupdated software?

  • Does the upgrade require a conversion of the application data?

  • After the first node has been upgraded and you have tested moving your resources to that new node, can you move the resources back to the node with the older version of the software if something does not work as expected? A lot of those upgrades are one-way.

For Microsoft-supplied software, Microsoft strives to allow and test rolling upgrades; however, the exclusion list and exception list often end up being longer than the supported list. For example, Microsoft does not support rolling upgrades for clusters containing IIS (Internet Information Service) resource, MSDTC resource, or MSMQ resources.

The bottom line is that unless you have a simple file-serving cluster, performing a rolling upgrade can be so much more complicated than performing a downtime upgrade that the resulting loss of availability caused by problems can easily offset the intended uptime gain. Also, the downtime during a rolling upgrade will likely be the unscheduled kind, which is much more detrimental than the scheduled downtime of a scheduled upgrade. In any case, you should not blindly rely on any vendor, but should test the rolling upgrade on a test cluster to uncover all the hidden pitfalls of your configuration.

Finally, if you are running a cluster with Windows NT 4.0, a direct rolling upgrade to Windows Server 2003 is not supported. Rather, if you choose to perform a rolling upgrade, you will need to perform it in two steps: first a rolling upgrade from Windows NT 4.0 to Windows 2000 and then a rolling upgrade from Windows 2000 to Windows Server 2003. Should you be running a cluster with Windows NT 4.0 on hardware that is supported by Windows Server 2003, it is likely to be easier to perform a nonrolling upgrade (planned downtime upgrade) to Windows Server 2003. That kind of upgrade from clustered Windows NT 4.0 to clustered Windows Server 2003 is fully supported.

Replacement Upgrades

Another upgrade option is to actually completely replace the hardware and perform a parallel-install upgrade. This is also the option you will use if most of your existing hardware is not supported by Windows Server 2003, and you decide to buy brand new hardware. This is also one of the smoothest upgrade paths because it allows you to back off at almost any point. When replacing a cluster, the hardest thing to decide is the network replacement model. There are multiple options:

  • Offline replacement : The replacement cluster is installed and configured while not connected to the corporate network. This allows you to assign the same IP and network name to the new cluster, but prevents you from directly copying the data unless you can use another temporary network. For example, this would not allow Exchange to join the organization and migration of mailboxes, but would work well for an SQL cluster where you could use a common private network between the old and new cluster to transfer data.

  • Temporary IP address and network name : Used in building the new cluster, and after the switchover is ready, the IP and network name are modified. This works fine for most Windows Server 2003 out-of-the-box applications: for instance, file servers, print servers, WINS (Windows Internet Naming Service), DHCP (Dynamic Host Configuration Protocol), and so on. But most complex applications do not easily let you change the VS (Virtual Server: IP Address resource + Network Name resource + Physical Disk resource) name.

  • DNS redirection : This allows you to use a permanent new IP and network name, and use a DNS (Domain Name Server) alias (CNAME) to point to the real names when you're ready. However, this does not work for NetBIOS name resolution or for applications that hard-code the VS name.

  • New IP and network name : In this scenario, you just create a new cluster using new IP addresses and the network name and migrate the data. Then, you keep those new IP addresses and the network names in production. This works best when the application masks the VS name, and would be the method of choice for Exchange.

After you have decided on the best way to migrate, you can install your new cluster and test things without impacting users. Only after everything is ready, do you move over. Furthermore, if you encounter problems, you still have the old cluster and can go back to it without major downtime. After your migration is done, you can keep the old cluster for awhile to make sure you do not run into hidden problems.

This method has the added advantage of cleaning up all leftover files that are on your existing cluster, but do not belong there anymore.

StorageWorks Minimums

Because clusters rely heavily on shared storage for their functionality, you must make sure that when you plan the migration of your cluster to Windows Server 2003, you also plan the storage migration. First, you will need to inventory your storage/SAN configuration. Do not forget to include things like your SAN switch in your configuration audit.

Because Windows Server 2003 provides new storage driver architecture, you must upgrade all your storage software and drivers. The following list shows the minimum versions required for HP to support Windows Server 2003. However, those versions are already old and going to the latest versions whenever possible is recommended.

  • SecurePath : Version 4.0B or later.

  • HSG : 8.7a solution kit with ACS v8.7-1.

    note

    Windows 2003 does not support HSG transparent failover mode (single HBA [host bus adapter]). Also, StorageWorks engineering does not support clusters with more than two nodes on Windows Server 2003.


  • KGPSA HBA : HBA firmware 3.82a1, BIOS 1.61a2, and driver 5-4.82a14.

  • HA/F500 EVA : Kit v2.0A.

  • HSV1x0 : Controller firmware v.2.003.

  • MSA1000 : Firmware 2.38 with 1.86 EMU and 6.31 MSA (Microsoft Systems Architecture) support CD.

  • SWVR (Storage Works Virtual Replicator) 4.0 : Support maximum of two-node cluster. When upgrading from pre-v4.0 versions of SWVR, make sure you read the full documentation as some upgrade paths require a complete backup and restore of the data.

    note

    SWVR stands for Storage Works Virtual Replicator. This product has had many different names through its life, the latest being HP OpenView Virtual Replicator. However, most people and Knowledge Base articles use the acronym SWVR, so we will stick with that.


  • SWCC 2.5 : Not supported on Windows Server 2003. This product is used only with HSG. HSV-based configurations are replacing HSG-based configurations. However, it appears to work.

Note that the RA4x00 SAN storage is currently not supported on Windows Server 2003. This should not present much of a problem because the RA4x00 family of SAN storage is likely to be used with ProLiant servers that are not supported under Windows Server 2003. However, if you have one of those configurations you want to upgrade, you will need to keep checking the HP support site for change in the support status or replace the storage subsystem.

Obtaining storage driver upgrades is usually easy, as the latest storage drivers are available on the HP storage support Web site. The Platform Kit(CD) for EVA can be found on the Web at http://h18006.www1.hp.com/products/storageworks/softwaredrivers/enterprise/inex.html. However, other firmware and platform CDs can only be obtained through a support contract or through purchase of the distribution. You might need to contact your HP sales/VAR contact for more information.

StorageWorks Upgrades

If you have a cluster using SecurePath, you need to determine whether you are booting from the SAN. If you boot from the SAN, upgrading to 2003 is supported and should work. However, at this writing it was reported that an upgrade may fail with a Stop 0x7B or the installation may halt with the error "Setup could not locate the Windows installation you want to upgrade." It was determined by HP, Emulex, and Microsoft engineers to be a driver issue that will be fixed in a future release of the Emulex driver. Please note that this will occur when performing an upgrade from Windows 2000 to Windows Server 2003 only on systems that boot from a SAN. It does not occur on a fresh Windows Server 2003 installation. There is a workaround available until the updated Emulex driver is ready. If you are planning to upgrade Windows 2000 systems booting from a SAN, make sure you contact HP StorageWorks support for information regarding the workaround and the driver update.

If you have SecurePath and do not boot from the SAN, you should follow this order of operation, as documented in customer advisory OS030605_CW01. (See http://h71025.www7.hp.com/support/reference_library/viewdocument.asp?countrycode=1000&prodid=2067&source=OS030605_CW01.xml&dt=3&docid=18503.)

1. Upgrade HBA firmware if needed. This is likely to require scheduling a field engineer visit.

2. Upgrade to SecurePath 4.0B with Windows 2000 drivers if not already there. Follow the instructions in the SecurePath kit.

3. Remove all SAN connections. Label all connections before removing to make reconnecting easy.

4. Upgrade to Windows Server 2003. Follow the Microsoft instructions.

5. Apply HP drivers from the latest HP System Support kit.

If your cluster has SWVR, you should first upgrade your Windows 2000 cluster to SWVR 4.0 and apply the latest fixes. Then, you can upgrade the cluster to Windows Server 2003. In July 2003, Microsoft released the security hotfix MS03-026 and then superseded it in September 2003 with MS03-039. Both of those security hotfixes have an incompatibility with SWVR 4.0 that can cause all SWVR data to be lost when applied. If you need to build or rebuild a cluster, make sure you are aware of the procedure for applying those hotfixes to a cluster with SWVR 4.0.

The procedure requires that SWVR be stopped when the hotfixes are applied. If you have any questions or doubts , make sure you have a good backup and also consider contacting HP Services for advice. The steps are

1. Set the cluster group (s) with SWVR storage offline.

2. Stop the SWVR Management Service (esmgrs).

3. Stop the SWVR Lifeguard Service (swvrmon).

4. Apply the hotfixes.

5. Reboot your machine.

warning

If you do not follow this precise order, you are likely to lose the data on the SWVR volumes during RPC (Remote Procedure Call) security hotfix installation.


Clustered Exchange Server

Exchange Server 2000 is not supported on Windows Server 2003, as described in Microsoft KB article 321648, so you must upgrade to Exchange Server 2003 before upgrading to Windows Server 2003. The cluster support in Exchange Server 2003 is not significantly changed from that in Exchange Server 2000. However, minor tweaks have improved it. For example, Exchange 2003 cluster resources come online faster than Exchange 2000 cluster resource because the dependencies have been modified to allow better parallelism.

To upgrade, follow these steps (note that each step is significant and represents an upgrade on its own that needs to be planned and executed independently):

1. Upgrade your cluster to Windows 2000 SP3 if needed.

2. Upgrade your cluster to Exchange Server 2003. Follow the Exchange Server 2003 Deployment guide ( especially the cluster chapter) to perform the upgrade, which will include the following steps:

  • Upgrade the forest to Exchange Server 2003 schema using /forestprep .

  • Upgrade the domain to Exchange Server 2003 schema using /domainprep .

  • Upgrade your Windows 2000 Exchange Server 2000 cluster to Exchange Server 2003.

  • Finish the VS upgrade using the Upgrade Exchange Virtual Server option in the Cluster Administrator (see Figure 13.1.).

    Figure 13.1. Virtual Server Upgrade option found in SA only.

3. Follow Microsoft KB article 821834, "Required Cluster Service Account Permissions Are Different in Exchange 2000 Server and Exchange Server 2003," to secure your clustered Exchange Server 2003.

4. Upgrade your cluster from Windows 2000 to Windows Server 2003.

Exchange is a cluster-aware application; however, careful planning is suggested before deploying Exchange in a cluster. Exchange is an application that can both scale up and scale out. In order to reduce the hardware requirements for Exchange, many organizations might be tempted to consolidate multiple Exchange servers onto a larger server and cluster it to improve availability. Deployment experience shows that large Exchange clusters do not have the reliability that could be expected. Furthermore, a scale out configuration with many smaller Exchange servers can often provide a better overall availability by providing greater flexibility in response to a failure.

Clustered IIS

Microsoft has been pushing NLB as the solution of choice for clustering Web servers through IIS. In Windows Server 2003, Microsoft has remove support for clustered SMTP (Simple Mail Transfer Protocol) server and NNTP (Network News Transfer Protocol) server. Furthermore, Microsoft has dropped the resource DLL that was used to support IIS clustering and moved to a simpler and less powerful generic script written in VBS (Visual Basic Script) to support IIS.

A script named IIS_SWITCH.VBS is provided with Windows Server 2003 to migrate Windows 2000 IIS clustered environment to Windows Server 2003. The script migrates the VS from using a DLL-based application monitor to using a generic script. However, some functionality will be lost if your clustered Web server was supporting multiple IIS5 sites. Rolling upgrades are not possible when upgrading an IIS cluster. To upgrade an IIS cluster, you must follow these steps:

1. Move all IIS resources to one node.

2. Upgrade all other nodes to Windows Server 2003 except for the node with the IIS resource.

3. From the command prompt on an upgraded node, execute the %WinDir%\System32\inetsrv\iis_switch command.

4. Move and start IIS on the upgraded node.

5. Upgrade the final node.

note

Before you perform an IIS upgrade, you should review whether this might be a good time to migrate to an NLB-based cluster. The "Network Load Balancing (NLB)" section (at the end of this chapter) discusses some improvements Microsoft made to NLB to allow it to support a wider range of Web serving requirements, and there should be very few reasons left to keep an MSCS-based IIS cluster.


Clustered SQL

SQL 2000 is probably one of the best candidate applications for clustering. The 32-bit SQL 2000 setup program has a hard-coded limit to four nodes clustering. That limit will be lifted when the next version of SQL (code-named Yukon) ships and the limit doesn't exist in the shipping 64-bit version of SQL 2000. However, four nodes allow a good N+1 SQL deployment with high availability at a moderate cost.

Note that installing SQL 2000 on Windows Server 2003 clusters is a little complicated. Microsoft has modified Windows Server 2003 to prevent communication from occurring while SQL is at a preSP3 version. Unfortunately, the SQL cluster wizard requires communication to install, and it's not possible to apply SP3 until SQL is installed. Check Microsoft KB article 815431, "PRB: Installation of a Named Instance of SQL Server 2000 Virtual Server on a Windows 2003-Based Cluster Fails," to get the installation procedure for SQL 2000 on a Windows Server 2003 cluster.

note

If you are still running SQL 6.5 or SQL 7.0, you will have to upgrade to SQL 2000 before attempting to upgrade to Windows Server 2003. SQL 6.5 and SQL 7.0 are not supported in a Windows Server 2003 cluster.


NAS Cluster

HP offers some clustered NAS servers. NAS servers were supposed to be black boxes that never needed attention. However, due to the proliferation of malignant attacks, security requires that attention be paid to these servers. Applying any software update not specifically certified for those bundled systems voids the support you receive from HP. Make sure you check the HP storage NAS Web site before attempting any updates to these systems. (See http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00047273&locale=en_US.)

Earlier clusters ran Windows Power NAS, which is a specially tuned version of Windows 2000, in addition to some special-version storage- related software not available for general release. The systems are bundles that are certified, tested, and supported as a bundle by a NAS team. The systems certified and sold with Windows Power NAS cannot be upgraded to Windows Server 2003 or even to Windows Storage Server 2003 without the NAS team testing and providing a BIOS locked distribution. Newer NAS systems shipping with Windows Storage Server 2003 also cannot be upgraded to any other Windows Server 2003 SKUs.

Compaq Intelligent Cluster Administrator

HP officially discontinued the Compaq Intelligent Cluster Administrator (CICA) at the end of 2002. Equivalent functionality can be obtained by using a combination of Insight Manager and HP OpenView (OVOW). HP does not plan to make a follow-on product. CICA will not work on Windows Server 2003 and is not supported on that version. If you have a cluster with CICA installed that you plan on upgrading to Windows Server 2003, you need to first uninstall CICA before starting the migration.

 <  Day Day Up  >  


Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
ISBN: B004C77T6A
EAN: N/A
Year: 2004
Pages: 214

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net