Release Notes for: o DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 Date: December, 1998 Product Version * DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 (Qualified on Windows NT 4.0 Service Pack 3 and 4) NOTE: When running DCNT V1.1 SP3 on Alpha machines with NT4.0 SP4, a default gateway must be specified for all public NICs on both cluster nodes. Failure to do so may result in lost cluster and NT communications on taking an IP failover object offline. Refer to section 1.10, Default Gateway Mandatory on Alphas Running NT4.0 SP4, for more details. This document provides new and updated information for the DIGITAL Clusters for Windows NT product: * Installation and upgrade notes * New features * Problems resolved since Version 1.1 Service Pack 2 * Problems and restrictions Please retain these instructions for future use. For general information on the DIGITAL Clusters for Windows NT product, visit the web site http://www.windows.digital.com. =========================================================== Contents =========================================================== 1 Installation Notes 1.1 Upgrading to DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 1.1.1 Requirements 1.1.2 Upgrading Your Cluster Servers 1.1.2.1 Server Files Updated by Version 1.1 Service Pack 3 1.2 Installing DIGITAL Clusters for Windows NT Version 1.1, including Service Pack 3 1.2.1 Requirements 1.2.2 Installing DCNT V1.1, including Service Pack 3, on Your Cluster Servers 1.2.2.1 Files downloaded during the DCNT V1.1 + SP3 Installation 1.3 Installing DIGITAL Clusters for Windows NT Remote Cluster Administrator 1.3.1 Requirements 1.3.2 Installing Remote Cluster Administrator 1.3.2.1 Files downloaded during the Remote Clusters Administrator Installation 1.4 Upgrading DIGITAL Clusters for Windows NT Remote Cluster Administrator 1.4.1 Requirements 1.4.2 Upgrading Remote Cluster Administrator 1.4.2.1 Files downloaded during the Remote Clusters Administrator Upgrade 1.5 Cluster Names Must Be Unique 1.6 Uninstall May Leave Some Files Behind 1.7 Installing Products which Use Scripts 1.8 No Remote Cluster Administrator installation or upgrade on a cluster client 1.9 Installing DCNT V1.1 Service Pack 3 on a System Running Microsoft SQL Server 1.10 Default Gateway Mandatory on Alphas Running NT4.0 SP4 2 New Features 2.1 DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 release features 2.1.1 New features 2.1.1.1 Registry Synchronization 2.1.1.2 Network Failover 2.1.1.3 Oracle 8 Support 2.1.1.4 Cluster Administrator Enhancements 2.1.1.4.1 Right Mouse Button Support 2.1.1.4.2 More information added to the Views 2.1.1.4.3 Changes to Creating/Modifying an IP Object 2.1.1.5 Cluster Monitor Enhancements 2.1.1.6 Documentation 3 Problems Resolved Since Version 1.1 Service Pack 2 3.1 An IP Resource's subnet mask Field Can be Changed 3.2 NIC Adapter Names Can Now Exceed 49 Characters 3.3 Disk Performance Monitor Works with Clusters Software 4 Problems and Restrictions 4.1 IP Failover Objects 4.1.1 When Creating or Modifying an IP Object, adapters not listed 4.2 Microsoft SQL Server 4.2.1 Cannot Enroll a database if Both Servers in the Cluster are Not Running 4.2.2 Enroll all SQL Databases in all Groups Before Any Failover 4.2.3 Moving SQL Server Objects Within a Failover Group 4.2.4 Deleting an SQL Server Database 4.2.5 Using the "FOR LOAD" Option When Creating or Altering an SQL Database 4.2.6 SQL Server Databases are Not Listed 4.2.7 If an SQL Server Halts During Database Recovery 4.2.8 Configuring MS SQL with DIGITAL Clusters for Windows NT 4.2.9 Digital Clusters does not support MS SQL DB Replication 4.2.10 MS SQL Server login 4.2.11 Databases and SQL "Devices" on shared cluster disks must have names that are unique in the entire cluster 4.2.12 SQL Server SA password is changed after enrolling databases 4.2.13 MSSQL stored procedures; access denied bug 4.2.14 Wizards that install or alter tempdb to reside on shared storage 4.2.15 SQL Database Must be Unenrolled Before Altering Its Size 4.3 IDE Disks Are Not Supported 4.4 Assign Fixed Drive Letters 4.5 Logon Rights Occasionally Granted Improperly 4.6 Using Cluster Administrator 4.6.1 Cluster Administrator is slow when one of the cluster nodes is down. 4.6.2 Failover Object Names Restricted to 38 Characters 4.6.3 Display Unsynchronized with Cluster Failover Manager Database 4.6.4 With the "Manage SQL Server Databases" dialog open, selecting F1 brings up the wrong help description 4.6.5 Changing Log Disk While Offline is not Recommended 4.6.6 Memory Leaking When Cluster Administrator is left Open 4.7 Defining Share Names 4.8 Lost Delayed Write Popup Boxes 4.9 Disk Administrator 4.9.1 Disk Administrator Shows Orphaned Disks 4.9.2 Changing Drive Partitioning During Cluster Operations 4.10 Potential Problem when Using Microsoft Word Version 6.0a 4.11 Installing Visual C++ 4.2 4.12 NET VIEW to Cluster NetBIOS Name Also Shows Unclustered Shares 4.13 System Hangs When Registry Size is Exceeded 4.14 Cluster Services Do Not Start When a "Program" directory Exists Under the Same Parent Directory as the "Program files" directory 4.15 Uninstalling and Re-installing DIGITAL Clusters for Windows NT Version 1.1 selects the NetBIOS name of one of the cluster's IP Failover Objects as the other servers name. 4.16 IP Failover Objects Corrupted When a Node Rejoins the Cluster with a Different NIC Configuration 4.17 Lotus Domino sample failover script names have changed 4.18 Using the Remote Cluster Administrator 4.18.1 Dual NIC machine may not connect via an IP resource's IP address 4.19 Network Failover 4.19.1 Network Failover Configuration 4.19.2 Testing Loss of Network Connectivity 4.19.3 Recommended Private NIC Binding Order 4.19.4 Disabling Network Failover 4.20 Oracle Failover Support 4.20.1 Oracle 8 or higher: Script-based Format Must be used for Oracle failover 4.20.2 Using an Oracle Instance as an Oracle Failover Object 4.20.3 Creating/Modifying Script-based Oracle Failover Objects/Converting from Parameter-based Format 4.20.4 Converting to Script-based Format Can be Slow if Either Cluster Node is Down 4.21 Registry Synchronization 4.21.1 Defining Registry Synchronization Objects for IIS 3.0 4.22 Cluster Monitor 4.22.1 Cluster Monitor Displays No Information 4.23 SNMP Management of DCNT Done Using ServerWORKS Copyright and Trademark Information =========================================================== 1 Installation Notes =========================================================== This section supplements the installation information in your Configuration and Installation Guide. 1.1 Upgrading to DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 --------------------------------------------------------------- NOTE: Compaq recommends that you remove the cluster client software when prompted during Version 1.1 Service Pack 3 installation. You do not need the cluster client software installed on the servers if NetBIOS and TCP\IP are installed. Compaq recommends that you configure IP failover for new and existing cluster installations. If you have already followed this recommendation, you can uninstall the NT Client software on the Cluster Servers during the Service Pack 3 installation. If you do not uninstall the client software during the installation, you can disable it later by performing the following procedure: 1) From the Start menu, select Settings 2) Select Control Panel from the Settings menu 3) Select Devices 4) Select Digital Clusters File System from the Device list and Click the Startup button 5) Under Startup Type, select the Disabled radio button and click the OK button 1.1.1 Requirements -------------------- Upgrading to DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 requires the following: o DIGITAL Clusters Version 1.1 Service Pack 3 CD-ROM or the self-extracting zip file "DCNT1_1SP3.EXE" NOTE: If DIGITAL Clusters 1.1 Service Pack 3 is obtained as a self-extracting zip file, the directory path names referred to in the follow sections begin at the directory in which you unzip the self-extracting zip file, DCNT1_1SP3.EXE. o Cluster servers running: - Windows NT 4.0 Service Pack 4 or 3 - DIGITAL Clusters 1.1 with or without Service Pack 1 or 2 NOTE: When running DCNT v.1 SP3 on Alpha machines with NT4.0 SP4, a default gateway must be specified for all public NICs on both cluster nodes. Failure to do so may result in lost cluster and NT communications on taking an IP failover object offline. Refer to section 1.10, Default Gateway Mandatory on Alphas Running NT4.0 SP4, for more details. - DIGITAL Clusters for Windows NT is qualified to run on Microsoft Windows NT Server Enterprise Edition. 1.1.2 Upgrading Your Cluster Servers -------------------------------------- NOTE: Clusters V1.1 Service Pack 3 is a rolling upgrade. A rolling upgrade allows cluster resources to remain available to users during this service pack upgrade. Upgrade one server at a time, using the procedure described below. For more detailed instructions, refer to the Version 1.1 Service Pack 3 Addendum document. The Version 1.1 Service Pack 3 Addendum document is located in the \Docs directory on the distribution CD-ROM or in the \Docs sub-directory of the directory in which the self-extracting zip file, DCNT1_1SP3.EXE, was unzipped. To perform a rolling upgrade, follow this procedure: 1. All users must be disconnected from database resources. 2. With both servers in the cluster running, manually failover all cluster resources to one of the servers. 3. On the other server, Exit the Cluster Administrator 4. Install Version 1.1 Service Pack 3 NOTE: To start the installation, go to the \Clu1-1nt.40\V1.2 directory and run the Setup.exe program. 5. Reboot the server 6. Manually failover all cluster resources to the server that was just upgraded to Version 1.1 Service Pack 3. 7. Exit the Cluster Administrator 8. Now install Version 1.1 Service Pack 3 on the second server 9. Reboot the server 1.1.2.1 Server Files Updated by Version 1.1 Service Pack 3 ---------------------------------------------------------- Version 1.1 Service Pack 3 updates the following files on the cluster server: o In the user's target directory (typically C:\Program Files\Digital\Cluster): Readme.txt cuninst.exe fmstat.exe ntcluster.exe ntcluster.cnt ntcluster.hlp sp_dec_find_cluster_dbs.sql sp_dec_find_cluster_fb_dbs.sql sp_dec_list_db_devs.sql sp_dec_list_db_fb_devs.sql sp_fallback_DEC_clean.sql sp_fallback_DEC_perm_svr_db.sql sp_fallback_DEC_enroll_svr.sql decclstr.sql CluClean.sql logwatch.exe fmdisk.dll fmsql.dll fmIp.dll fmsync.dll showtrace.exe * In the user's Windows NT System32 directory (typically C:\WINNT\System32): clumgmt.dll fmlib.dll cfmd.dll mfc40u.dll (if newer version) msvcrt40.dll (if newer version) msvcrt.dll (if newer version) msvcr40d.dll (if newer version) msvcirtd.dll (if newer version) msvcirt.dll (if newer version) mfc40ud.dll (if newer version) msvcrtd.dll (if newer version) * In the user's Windows NT System32\Drivers directory (typically C:\WINNT\System32\Drivers): cluport.sys cludisk.sys aic78xx.sys (if newer version) NOTE: You must re-boot the servers after the upgrade completes successfully. The installation will prompt you to do so. 1.2 Installing DIGITAL Clusters for Windows NT Version 1.1 including Service Pack 3 --------------------------------------------------------------- NOTE: This option is only available on the CD_ROM version of this Service Pack 3 release. NOTE: Compaq recommends that you remove the cluster client software when prompted during Version 1.1 Service Pack 3 installation. You do not need the cluster client software installed on the servers if NetBIOS and TCP\IP are installed. Compaq recommends that you configure IP failover for new and existing cluster installations. If you have already followed this recommendation, you can uninstall the NT Client software on the Cluster Servers during the Service Pack 3 installation. If you do not uninstall the client software during the installation, you can disable it later by performing the following procedure: 1) From the Start menu, select Settings 2) Select Control Panel from the Settings menu 3) Select Devices 4) Select Digital Clusters File System from the Device list and Click the Startup button 5) Under Startup Type, select the Disabled radio button and click the OK button 1.2.1 Requirements -------------------- Installing DIGITAL Clusters for Windows NT Version 1.1, including Service Pack 3, requires the following: o DIGITAL Clusters Version 1.1 Service Pack 3 CD-ROM o Cluster servers running: - Windows NT 4.0 Service Pack 4 or 3 - No previously installed cluster software - DIGITAL Clusters for Windows NT is qualified to run on Microsoft Windows NT Server Enterprise Edition. o The person performing the installation must be logged in as a user with administrative privileges on the cluster nodes. 1.2.2 Installing DCNT V1.1, including Service Pack 3, on Your Cluster Servers -------------------------------------- NOTE: All upgrades or installations are initiated from the same setup.exe. Install DCNT V1.1, including Service Pack 3, on one server at a time, using the procedure described below. For more detailed instructions, refer to the Version 1.1 Service Pack 3 Addendum document. The Version 1.1 Service Pack 3 Addendum document is located in the \Docs directory on the distribution CD-ROM. To perform a fresh installation of DCNT, follow this procedure: 1. Turn off the power for the shared storage and turn on the power for both cluster servers. 2. Install the server software on the first server. After the installation, leave the server turned on but do not reboot it. 3. Install the server software on the second server. After the installation, leave the server turned on but do not reboot it. 4. Turn on power for the shared storage, then reboot the servers one at a time. 5. With the power on for the entire cluster, verify that the software is installed properly and that you can see all your shared disks. 6. Use the Cluster Administrator to assign shared disks to failover groups and Windows NT Explorer to create file shares. 1.2.2.1 Server Files downloaded during the DCNT V1.1 + SP3 Installation ---------------------------------------------------------- Version 1.1 Service Pack 3 installs the following files on the Cluster server: o In the user's target directory (typically C:\Program Files\Digital\Cluster): Readme.txt cuninst.exe fmstat.exe ntcluster.exe ntcluster.cnt ntcluster.hlp sp_dec_find_cluster_dbs.sql sp_dec_find_cluster_fb_dbs.sql sp_dec_list_db_devs.sql sp_dec_list_db_fb_devs.sql sp_fallback_DEC_clean.sql sp_fallback_DEC_perm_svr_db.sql sp_fallback_DEC_enroll_svr.sql decclstr.sql CluClean.sql logwatch.exe fork.exe cluio.exe cluivp.exe clustat.exe cluview.exe cluxfer.exe cns.exe fmcore.exe cfmdsrv.exe fmdisk.dll fmsql.dll fmIp.dll fmscript.dll fmoracle.dll showtrace.exe * In the user's Windows NT System32 directory (typically C:\WINNT\System32): clumgmt.dll fmlib.dll cfmd.dll cfms.dll clucis.dll clunsapi.dll mfc40u.dll (if newer version) msvcrt40.dll (if newer version) msvcrt.dll (if newer version) msvcr40d.dll (if newer version) msvcirtd.dll (if newer version) msvcirt.dll (if newer version) mfc40ud.dll (if newer version) msvcrtd.dll (if newer version) * In the user's Windows NT System32\Drivers directory (typically C:\WINNT\System32\Drivers): cluport.sys cludisk.sys aic78xx.sys (if newer version) 1.2 Installing DIGITAL Clusters for Windows NT Remote Cluster Administrator ----------------------------------------------------------- DIGITAL Clusters for Windows NT Remote Cluster Administrator can be installed and run on any Windows NT systems. This section provides notes on installing the Remote Cluster Administrator. NOTE: A cluster node running DIGITAL Clusters 1.1 Service Pack 2 or Version 1.1 Service Pack 3 has the built in ability to remotely administer other cluster nodes. Therefore, it is both unnecessary and undesirable to install the Remote Cluster Administrator software on a cluster node. NOTE: The Remote Cluster Administrator software will not install or run on a Windows 95 system. 1.2.1 Requirements ------------------- o Any version of Windows NT o The person performing the installation must be logged in as a user with administrative privileges on the machine. 1.2.2 Installing Remote Cluster Administrator --------------------------------------------- NOTE: DIGITAL Cluster Version 1.1 Service Pack 3 upgrade, the Remote Cluster Administrator installation, and the Remote Cluster Administrator upgrade are initiated from the same setup.exe. Use the procedure described in the Version 1.1 Service Pack 3 Addendum document to Install the Remote Cluster Administrator tool. The Version 1.1 Service Pack 3 Addendum document is located in the \Docs directory on the distribution CD-ROM or in the \Docs sub-directory of the directory in which the self-extracting zip file, DCNT1_1SP3.EXE, was unzipped. 1.2.2.1 Files downloaded during the Remote Clusters Administrator Installation ----------------------------------------------------------------- o In the user's target directory (typically C:\Program Files\Digital\Cluster): Readme.txt cuninst.exe ntcluster.exe ntcluster.cnt ntcluster.hlp fmstat.exe * In the user's Windows NT System32 directory (typically C:\WINNT\System32): clumgmt.dll mfc40u.dll (if newer version) msvcrt40.dll (if newer version) msvcrt.dll (if newer version) msvcr40d.dll (if newer version) msvcirtd.dll (if newer version) msvcirt.dll (if newer version) mfc40ud.dll (if newer version) msvcrtd.dll (if newer version) 1.3 Upgrading DIGITAL Clusters for Windows NT Remote Cluster Administrator ----------------------------------------------------------- DIGITAL Clusters for Windows NT Remote Cluster Administrator can be upgraded on any Windows NT systems that has the V1.1 Service Pack 2 version of Remote Cluster Administrator already installed. This section provides notes on upgrading the Remote Cluster Administrator. 1.4.1 Requirements ------------------- o Any version of Windows NT running the V1.1 Service Pack 2 version of Remote Cluster Administrator program. o The person performing the installation must be logged in as a user with administrative privileges on the machine. 1.4.2 Upgrading Remote Cluster Administrator -------------------------------------------- NOTE: DIGITAL Cluster Version 1.1 Service Pack 3 upgrade, the Remote Cluster Administrator installation, and the Remote Cluster Administrator upgrade are initiated from the same setup.exe. Use the procedure described in the Version 1.1 Service Pack 3 Addendum document to Upgrade the Remote Cluster Administrator tool. The Version 1.1 Service Pack 3 Addendum document is located in the \Docs directory on the distribution CD-ROM or in the \Docs sub-directory of the directory in which the self-extracting zip file, DCNT1_1SP3.EXE, was unzipped. 1.4.2.1 Files downloaded during the Remote Clusters Administrator Upgrade ----------------------------------------------------------------- o In the user's target directory (typically C:\Program Files\Digital\Cluster): Readme.txt cuninst.exe ntcluster.exe ntcluster.cnt ntcluster.hlp fmstat.exe * In the user's Windows NT System32 directory (typically C:\WINNT\System32): clumgmt.dll mfc40u.dll (if newer version) msvcrt40.dll (if newer version) msvcrt.dll (if newer version) msvcr40d.dll (if newer version) msvcirtd.dll (if newer version) msvcirt.dll (if newer version) mfc40ud.dll (if newer version) msvcrtd.dll (if newer version) 1.5 Cluster Names Must Be Unique ----------------------------------------------- The names you assign to different clusters in the same LAN must be unique within the first eight characters. Otherwise, it is possible for one cluster to see resources owned by another. For example, the names CLUSTER1 and CLUSTER2 are valid; CLUSTER1A and CLUSTER1B are not. 1.6 Uninstall May Leave Some Files Behind ----------------------------------------- The uninstallation of Digital Clusters V1.1 Service Pack 3 may leave behind some files. For a listing of these files and their locations, see the DIGITAL Clusters for Windows NT Configuration and Installation Guide, Appendix A. NOTE: Some of these same files, with the .old extension, may also be left undeleted. 1.7 Installing Products which Use Scripts ----------------------------------------- When installing any product needing scripts you may wish to refer to the samples provided at: \Clu1-1nt.40\Samples 1.8 No Remote Cluster Administrator installation or upgrade on a cluster client ----------------------------------------------------------------------- The Service Pack 3 installation logic will not allow the user to perform a Remote Cluster Administrator (RCA) installation or upgrade on a system with the cluster client software installed. This prevents the leaving behind of files upon uninstall. Unfortunately the Service Pack 2 RCA installation did allow installation on a client machine. If you did this and want to install or upgrade to SP3 RCA, uninstall the old RCA via the Start menu shortcut or from Control Panel’s Add/Remove Programs. Then manually uninstall the client code using the information in the DIGITAL Clusters for Windows NT Configuration and Installation Guide, Appendix A. 1.9 Installing DCNT V1.1 Service Pack 3 on a System Running Microsoft SQL Server ----------------------------------------------------------------------- When installing DCNT on a system which has Microsoft's SQL Server installed, you will receive a message reminding you to have SQL Service Pack 1 installed. While SQL SP1 is the minimum requirement for clustering SQL databases, for best results Compaq suggests that you install the latest version of the MS SQL Service Pack (sp4 at this writing). In addition, if you are using binary sort order and standard security you may require an additional binary patch provided by Microsoft. See MS Knowledge Base article Q180603. Please contact Customer Support for more information. 1.10 Default Gateway Mandatory on Alphas Running NT4.0 SP4 ----------------------------------------------------------------------- Due to TCP/IP changes in NT4.0 SP4, Alpha machines running NT4.0 SP4 and DCNT V1.1 (or any Service Pack) will lose connectivity when an IP failover object is taken offline unless a default gateway is specified for all public NICs on both cluster nodes. If you cannot specify a default gateway for all public NICs, you must at least specify one for the first bound NIC. The workaround for Alpha cluster nodes is to make sure that all public NICs have a default gateway specified. To specify a default gateway for a particular NIC, use the following procedure: 1) Open Control Panel and double-click the Network icon 2) Choose the Protocol tab and select the TCP/IP Protocol from the list 3) Click the Properties button 4) Select the NIC requiring a default gateway from the listbox 5) Enter a valid machine or gateway address in the Default Gateway field Intel cluster nodes running NT4.0 SP4 do not exhibit this problem. For updated information on a permanent fix for this problem, monitor the Clusters web site at http://www.windows.digital.com/clusters. ============== 2 New Features ============== 2.1 DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3 release features -------------------------------------------------------------- 2.1.1 New features ------------------ 2.1.1.1 Registry Synchronization -------------------------------- DIGITAL Clusters for Windows NT now provides the ability to synchronize application- or service-specific registry information that moves with that application or service upon failover. This information can be any state information or data that is saved in the registry. Like most other failover objects, a registry synchronization failover object can be created, modified, deleted and added to, or removed from, a failover group. A registry synchronization failover object defines a registry key under the HKEY_LOCAL_MACHINE key whose hive is copied to the other node upon failover. Following are some of the issues when using registry synchronization: o In defining a registry synchronization object’s registry hive key, there are two restrictions: a) It cannot be a first generation descendant (child) of HKEY_LOCAL_MACHINE. b) Its hive cannot in any way overlap the hive of another registry synchronization object in the cluster. o Since almost any key can be defined for registry synchronization great care must be taken in defining the hive whose information will be duplicated on the other node upon failover. AS A RULE OF THUMB, DO NOT DEFINE A HIVE THAT INCLUDES MACHINE-SPECIFIC INFORMATION UNLESS IT IS THE SAME ON BOTH MACHINES. o Pay strict attention to the placement of objects in a group. A registry synchronization object should always be placed in the group before an application or service that uses the registry synchronization object’s hive information. o Remember that registry synchronization is not dynamic. That is, changes to an object’s hive do not immediately propagate to the other cluster node. Changes are propagated only at the time of failover. o Registry synchronization does not keep the registry keys defined by a registry synchronization object from becoming out-of-sync. The out-of-sync condition can occur if changes are made to the registry hive on the node that does not have that object on line. The registry hives remain in sync on failover as long as changes are only made by the node that owns that resource. o Previously, the Cluster Log Disk was only used by DCNT to store cluster changes if one of the cluster nodes was down. Now, with the addition of the registry synchronization failover object, having the Log Disk online is mandatory for the proper operation of a registry synchronization object regardless of whether the other node is up or down. If the Cluster Log Disk is offline no registry synchronization can occur. o You can set a flag to make the group that owns a registry synchronization object go off line if that object fails because of Log Disk failure or any other failure. If this flag is not set, you will not have any immediate indication that synchronization did not occur. Set this flag by checking the Take the group OFFLINE check box in the Create or Modify Registry Synchronization Failover Object dialog boxes. For more details on setting up and using this new feature, see the "DIGITAL Clusters for Windows NT 1.1 Service Pack 3 Addendum" and online help. 2.1.1.2 Network Failover ------------------------------------------------ Network Failover, a new feature of DCNT 1.1 Service Pack 3, provides the cluster with the capability of detecting and responding to network failures by failing over a group containing an IP object that is bound to an affected network interface card (NIC). Previously, if a NIC on an active cluster node were to fail or lose connectivity with the network, the active cluster node would be isolated and unable to perform network transactions. Although the other cluster node might still be active on the network and could assume cluster operations, the cluster would be unaware that network connectivity had been lost and thus do nothing. Now, network failover can be configured to cause the group associated with this NIC to failover. This feature detects whenever network connectivity is lost, whether through failure of the NIC card itself or by network failure. In the event of connectivity loss, whether direct or as a side effect of a failed NIC, DCNT performs the same action; it fails all groups containing an IP object bound to or dependent upon the isolated NIC over to the other cluster node. The system detects lack of connectivity by systematically sending a signal to other systems on the network (pinging) and waiting for a response. If return replies are sent, no action is taken. If all "ping" attempts fail for a fixed (user-settable) time period, it is assumed that connectivity has been lost. When connectivity is lost, a message is sent to the partner node, advising it that connectivity is lost. The partner node then attempts, through a similar ping mechanism, to determine if it can see the outside network. If it can, it invokes a failover, taking over responsibility for the group dependent upon the isolated NIC on the cluster partner. In addition, if the failback feature is selected for this group, the first node continues pinging other members of the network until it receives a response. Once a sufficient interval of consistent replies has occurred (this interval is user-defined), the first node requests failback of the group from the partner node. For details on setting up and using this new feature, see the "DIGITAL Clusters for Windows NT 1.1 Service Pack 3 Addendum" and online help.. 2.1.1.3 Oracle 8 Support ------------------------ Versions of DIGITAL Cluster for Windows NT (DCNT), previous to DCNT V1.1 Service Pack 3, use a set of Oracle database related parameters for the creation of an Oracle failover object. These parameters controlled the starting and stopping of the Oracle database. This was achieved by the creation of on-the-fly .bat and .sql files to start/stop the Oracle object. All existing Oracle failover objects on your system use this parameter-based format. With DCNT 1.1 Service Pack 3, a script-based system asks the user directly for the commands to start/stop the Oracle object. This direct control over the starting or stopping of the Oracle object allows the usage of the multi-homing feature introduced in Oracle 8.0.4 or later. Example command scripts can be found on the "\Samples\Oracle" directory on the Service Pack CD (or of the download after unzipped). This new feature also provides an automatic conversion mechanism to upgrade the old parameter-based format to the new script-based format. NOTE: For databases created in Oracle8 version and above, the script-based format must be used. The parameter-based format may not work because the executable name and listener name can change for each Oracle revision. For details on installing, setting up and using this feature, see the "DIGITAL Clusters for Windows NT 1.1 Service Pack 3 Addendum" and online help. 2.1.1.4 Cluster Administrator Enhancements ----------------------------------------- 2.1.1.4.1 Right Mouse Button Support ------------------------------------ Most actions can now be initiated via new right mouse button popup menus. The popup menus are activated by clicking the right mouse button on an item in the view. Which menu pops up depends on which item in the view was selected. 2.1.1.4.2 More information added to the Views --------------------------------------------- Information such as a group's online status, an IP object's NetBIOS name, and which disk is currently the Cluster Log Disk has been added to the Cluster Administrator views. 2.1.1.4.3 Changes to Creating/Modifying an IP Object ---------------------------------------------------- The Create/Modify IP Failover Object dialog has been changed to provide added protection from specifying an IP object that will not work in the clustered environment. The user can no longer enter the IP object's subnet mask, it is automatically set to the subnet mask of the selected adapters that will service the IP object. The user also cannot select adapters for each machine with different subnet masks. 2.1.1.5 Cluster Monitor Enhancements ------------------------------------ a) The "View" menu now provides a "Save Settings" option. Selecting the "Save Settings" option preserves the "Refresh Rate", window size, and window position settings. These values are preserved and used next time Cluster Monitor is started. b) If a failover group is deleted, Cluster Monitor now deletes it from the display -- rather than leaving it on the screen as "Down". c) If a failover group is added, it will now be displayed without the need to stop and restart Cluster Monitor. d) You can now right-mouse-button-click on a group's status to bring up a dialog with details about that group. e) Right-mouse-button-clicking on a column heading (system name) will swap the columns. f) A right-mouse-button-click on a row heading (group name) will reverse the order the groups are displayed. 2.1.1.6 Documentation --------------------- The DIGITAL Clusters for Windows NT Version 1.1 documentation has been updated by the addition of a Version 1.1 Service Pack 3 Addendum. The Version 1.1 Service Pack 3 release includes the following documentation: o Configuration and Installation Guide (hardcopy and .pdf) o Administrator's Guide (hardcopy and .pdf) o Administrator's Guide Addendum (hardcopy and .pdf) o Version 1.1 Service Pack 2 Addendum (.pdf) o Version 1.1 Service Pack 3 Addendum (.pdf) You can view the online (.pdf) versions of these documents in the free Adobe Acrobat Reader, available from http://www.adobe.com. An index is provided for doing full-text searches in Acrobat Reader. If you want to copy the .pdf files from the CD-ROM, copy the full \DOCs folder and keep it together as a unit. NOTE: Context-sensitive help in the Cluster Administrator is only available for menu items and commands. ===================================================== 3 Problems Resolved Since Version 1.1 Service Pack 2 ===================================================== This section describes cluster software problems resolved since the DIGITAL Clusters for Windows NT Version 1.1 Service Pack 2 release. 3.1 An IP Resource's subnet mask Field Can be Changed --------------------------------------------------- When modifying an IP Object with DCNT V1.1 SP2, the user was not able to change the subnet mask field. With DCNT V1.1 SP3, the subnet mask field can be modified, but not by the user. The subnet mask field is now changed automatically to match the subnet mask of the selected adapters. 3.2 NIC Adapter Names Can Now Exceed 49 Characters -------------------------------------------------- Prior to this beta release of DCNT V1.1 SP3, there was a problem with the handling of long NIC adapter titles. When a NIC adapter title was greater than 49 chars long, it would not show up as an available selection in the Create/Modify IP object screens. This problem is fixed with this service pack release. 3.3 Disk Performance Monitor Works with Clusters Software --------------------------------------------------------- Performance Monitor is an administrative tool that is part of Windows NT. In the past DCNT did not allow disk performance monitoring of disks in the shared storage. Now, after running diskperf -y from the command prompt and rebooting you can monitor the disk performance of the shared storage. The results of disk performance monitoring will vary depending on your hardware configuration and are not a factor of the Cluster Software. ============================================================== 4 Problems and Restrictions ============================================================== This section describes known problems and restrictions in DIGITAL Clusters for Windows NT Version 1.1 Service Pack 3. 4.1 IP Failover Objects ----------------------- 4.1.1 When Creating or Modifying an IP Object, adapters not listed ------------------------------------------------------------------- In order for an adapter to appear in the adapter list the following 2 conditions must be met: 1)In Control Panel select the Network applet and select the Adapters tab. The adapter must be listed under "Network Adapters". 2)In Control Panel select the Network applet and select the Bindings tab. Select "all protocols" from the "Show Bindings for" listbox. In the resulting view expand the "TCP/IP Protocol" item. The adapter must be listed under this item and be "Enabled". If the adapter is listed but disabled, that adapter will not show up. If the adapter is not listed under the TCP/IP protocol item then you need to add that protocol for the adapter. Refer to Microsoft's documentation for related instructions. 3)To be listed in the other node’s list, an adapter must have the same subnet mask and be on the same subnet as the adapter currently selected for the connected node. 4.2 Microsoft SQL Server ------------------------ 4.2.1 Cannot Enroll a database if Both Servers in the Cluster are Not Running --------------------------------------------------------------------- You cannot enroll a database unless the MS SQL Server on both cluster nodes is running. If one of the Servers is offline or the SQL service is stopped you will the following error: RPC Server unavailable or SQL Server in an undetermined state. 4.2.2 Enroll all SQL Databases in all Groups Before Any Failover -------------------------------------------------------------- Make sure that all SQL databases on the group's disks are enrolled for failover support. SQL Server setup for Digital Clusters is not complete until all of the databases are enrolled. If some databases are enrolled and others are not, then any failover will result in the SQL Server eventually hanging and unenrolled databases being marked suspect. NOTE: Cluster Administrator will not allow manual failover to continue and displays a warning message if there are any unenrolled databases in the group. 4.2.3 Moving SQL Server Objects Within a Failover Group ------------------------------------------------------- In this release, DIGITAL Clusters software automatically adds or removes SQL Server failover objects from the appropriate failover groups when you perform SQL management functions, such as enrolling SQL databases on a shared disk for failover. Generally, you do not need to add or remove SQL Server failover objects from a group. The one exception is when you want to change the order of objects in a group. For example, you may want to move a script failover object after a SQL Server failover object to ensure the script runs correctly. In this case, you can use the Modify Failover Group dialog box to move the SQL Server failover object by removing it from the group, then reinserting the object in the desired sequence. Make sure to place the object back in the group, or the SQL databases will not be available after the next failover. 4.2.4 Deleting an SQL Server Database ------------------------------------- CAUTION: Before deleting an SQL Server database, first use Cluster Administrator to unenroll it. If you delete an SQL database without first unenrolling the database, no further SQL databases can be enrolled. When you attempt to enroll a new SQL database, the following error is displayed: "Error from CLIFMSQLENROLLDATABASE Incorrect Function" Analysis: Deleting a database, without first unenrolling the database from the cluster, leaves the database information in the fallback tables with no reference to the related database information in the system tables. If you have deleted an SQL Server database, without first unenrolling it, the workaround is to: 1. On the SQL server where the database was deleted, using the original devices, create a database with the exact same name as the one you deleted. 2. Use Cluster Administrator to unenroll this database. 3. Now, delete the database from SQL server. 4. Delete the devices if necessary. If the devices no longer exist or this method fails, please contact Customer Support for further assistance. 4.2.5 Using the "FOR LOAD" Option When Creating or Altering an SQL Database ------------------------------------------------------------------ Using the "FOR LOAD" option prevents anyone from using the database from the time that the CREATE (ALTER) DATABASE statement is issued until the LOAD statement is issued. This is a feature of the SQL Server. The proper procedure is to load the database immediately following database creation before it is enrolled. 4.2.6 SQL Server Databases are Not Listed ----------------------------------------- After installing the cluster software, rebuilding the SQL Server master database, applying an SQL Server Service Pack and then creating a new SQL Server databases, you must either: 1) Stop and start the Cluster Failover Manager Service 2) Or reboot If you don't do one of the above, when you choose SQL Server Databases from the Cluster Administrator's Manage menu, you will not see any SQL Server Databases listed. Also, you will see errors in the fm trace log about: "Stored procedure 'sp_DEC_find_cluster_dbs' not found." 4.2.7 If an SQL Server Halts During Database Recovery ----------------------------------------------------- If an SQL Server halts during a database recovery, the next time the related failover group is on-line on that server the database could be marked "suspect". Solution: 1. If the server in question is the primary server for that failover group, re-boot the server. 2. If the server in question is the secondary server for that group, using the ISQL query tool, execute the sp_fallback_DEC_clean procedure. Then you must activate the database. One way to activate the database is to manually failover the group to the other server and then fail it back again to the secondary server. Another way is to execute the sp_fallback_activate_svr_db stored procedure. 4.2.8 Configuring MS SQL with DIGITAL Clusters for Windows NT ------------------------------------------------------------- MS SQL Server must be configured properly before Digital Clusters can be installed. MSSQL Server will not function properly in a clustered environment using the default configurations if there are large databases and/or a large number of databases and/or a large number of users. Symptoms include but are not limited to inability to enroll, unenroll and failover groups containing databases, SQL Server exception access violation and SQL Server hanging. Both SQL servers need to be configured to support the user connections and database load with the consideration that all databases will be managed from one cluster node in the event of a failover. Recommendations: Settings need to be adjusted to more appropriate values based on recommendations from the Microsoft SQL Server Resource Guide and related documentation. The following values are of particular importance: 1. locks: 32 bytes of memory per lock. Configure this option taking into account that all databases in the cluster will have to be managed from one node during a failover. 2. memory: (In 2K pages) The more memory that can be allocated for SQL Server, the better it will run. The default memory allocation for SQL is not adequate for DCNT, any memory not required by other applications on the node and the Operating System, should be allocated to SQL Server. 3. open databases: Maximum number of databases that can be opened on SQL Server at any one time, per user. Account for all databases in the cluster for each node. 4. open objects: Requires 70 bytes per object. For each failover group containing a database, there will be one user connection which will utilize some of the available open objects allocated in the SQL configuration. The default configuration is inadequate to support databases in a clustered environment. Account for all databases in the cluster for each node. 5. user connections: Number of simultaneous user connections. Each failover group that contains a database will require a connection to SQL Server as well as one connection for each Cluster Administrator session that may be open on any node at a given time. This is in addition to the number of user connections configured for client, application and user access. Each user connection requires 37K of memory. Account for all databases in the cluster for each node. 6. Tempdb: The default size of MSSQL Tempdb is 2 MB. This is inadequate for a production server in a clustered environment. Please consult your MSSQL Server DBA Administrator's Guide for information on how to increase the size of your Tempdb to host all of the databases in the cluster in the event of failover. 4.2.9 Digital Clusters does not support MS SQL DB Replication ------------------------------------------------------------- Due to a bug in the MS stored procedure (sp_serveroption) a clustered database cannot be published or subscribed. In addition, DIGITAL Clusters does not support DB replication because MS SQL Server system databases cannot be failed over (specifically master, msdb and tempdb) thus the scheduled tasks won't be synchronized between two cluster nodes. 4.2.10 MS SQL Server login ------------------------- When using MS SQL Server standard security logins must be set up identically on both cluster nodes. MS SQL database administrators should check the master DB syslogins table. DB users will have permission problems when connecting to a DB after a failover if the login setup between two MS SQL Servers does not match. 4.2.11 Databases and SQL "Devices" on shared cluster disks must have names that are unique in the entire cluster --------------------------------------------------------------- Databases and SQL "Devices" on shared cluster disks must have names that are unique in the entire cluster. As long as the database names are unique, it doesn't matter if they have duplicate dbids on different nodes. Every time a database fails over, the cluster software automatically assigns a new dbid. 4.2.12 SQL Server SA password is changed after enrolling databases ------------------------------------------------------------------ When the SA password is changed on both nodes after one or more databases are enrolled into the Digital NT Cluster, you must also change the password for all the SQL objects on the cluster. 1. Double click SQL object to get "Modify SQL Server Failover Object" 2. Change the password for SA. 4.2.13 MSSQL stored procedures; access denied bug ------------------------------------------------- There is a known bug in SQL 6.5 (through SP4) which produces an SQL 916 error when users with limited permissions attempt to access database objects after a failover has occurred. Microsoft is aware of the problem and has produced a binary patch please see MS Knowledge Base article Q180603 for more information. 4.2.14 Wizards that install or alter tempdb to reside on shared storage --------------------------------------------------------------- Wizards that install or alter the tempdb to reside on the shared storage should not be used with DIGITAL Clusters for Windows NT. In some cases, where installation wizards are used by an application to create or modify SQL Server databases, those applications should be installed prior to bringing the shared storage online and installing DCNT. The databases can then be moved to the shared storage and altered before they are populated and enrolled. Please see your SQL Server documentation for more information. 4.2.15 SQL Database Must be Unenrolled Before Altering Its Size --------------------------------------------------------------- You must unenroll a database before altering it's size, not doing so will cause the database to be marked suspect on failover. 4.3 IDE Disks Are Not Supported -------------------------------- DIGITAL Clusters for Windows NT environments do not support systems that include IDE disks. The ATDISK.SYS driver used for IDE disks is incompatible with the cluster drivers. Using ATDISK.SYS in a cluster causes the system to fail when booted. 4.4 Assign Fixed Drive Letters ------------------------------- After the Windows NT operating system is installed, it is imperative that the drive letter assigned to the system partition (typically C: or D:) remain constant, because hardcoded references to this drive letter are recorded in the Windows NT Registry. For information on assigning fixed drive letters, see the Configuration and Installation Guide. 4.5 Logon Rights Occasionally Granted Improperly ------------------------------------------------ On occasion the Windows NT software does not properly grant the "logon as a service" right to a user account, even though the account was created correctly. If this happens, the cluster services will not start. The workaround for this problem is as follows: 1. Open the Services applet in Control Panel. 2. Select the CFMD server. 3. Click on Startup... then click on OK. The software displays the following message: The user is granted log in as a service. At this point, you can start the cluster services. 4.6 Using Cluster Administrator ------------------------------- 4.6.1 Cluster Administrator is slow when one of the cluster nodes is down. -------------------------------------------------------------------- If one of the cluster nodes in a cluster is turned off, hung, or otherwise incapacitated, the Cluster Administrator takes much longer to complete many of its tasks. Please allow for about 3 minutes of non-response before assuming the software is hung. 4.6.2 Failover Object Names Restricted to 38 Characters -------------------------------------------------------- Failover object names can have a maximum of 38 characters. If you try to add an object with a longer name to a failover group, Cluster Administrator will fail. 4.6.3 Display Unsynchronized with Cluster Failover Manager Database ---------------------------------------------------------- It is possible for the Cluster Administrator display to become unsynchronized with the cluster configuration database in the registry. This can happen if you have two Cluster Administrator sessions open on the same cluster and are making changes from both Cluster Administrator sessions. One session of the Cluster Administrator may be unaware of changes propagated to the registry from the other Cluster Administrator session. Two workarounds exist for this problem: * If you suspect that the Cluster Administrator is out of synch, choose Refresh from the View menu. * Run the Cluster Administrator on only one server at a time. With the ability to remotely administer a cluster, the probability of Cluster Failover Manager Database unsynchronization is increased. Refreshing a previously opened Cluster Administrator session prior to making changes to the cluster is recommended. 4.6.4 With the "Manage SQL Server Databases" dialog open, selecting F1 brings up the wrong help description ------------------------------------------------------------------- To view the correct help description click on the "Help" button rather than F1. 4.6.5 Changing Log Disk While Offline is not Recommended -------------------------------------------------------- Cluster Administrator allows the user to change the Log Disk even if it is currently offline. This action, however, should only be taken in emergency situations since doing this causes the loss of any logged data or registry object snapshots. 4.6.6 Memory Leaking When Cluster Administrator is left Open -------------------------------------------------------- If Cluster Administrator is left open for an extended period of time, an "out of virtual memory" error message may be displayed. This condition depends upon how much physical memory the machine has and whether NIC failover is enabled. Close and reopen Cluster Administrator should this occur. 4.7 Defining Share Names --------------------------- The DIGITAL Clusters for Windows NT software does not prevent the creation of two file shares with the same name if the shares are on different disks and the disks are on line to different cluster servers. DIGITAL recommends that you do not create two shares with the same name on two servers in the same cluster. 4.8 Lost Delayed Write Popup Boxes ----------------------------------- A failover group can transition from on line to off line while the system is still running. This can occur from a voluntary failover or involuntary failover. During a voluntary failover, a system puts a group off line in a controlled manner in response to a user request. An example of this is a group with failback enabled that is on line on the failover server when the primary server comes back up. The failover server does a voluntary failover to the primary server. During a voluntary failover the following happens: * The shares, if any, are made unavailable. * The file system caches are flushed to disk. * The file system is dismounted if possible. * The disk itself is put off line. Every opportunity is taken in this case to assure that cached file system data is returned to disk prior to the failover. During an involuntary failover, a disk goes off line immediately without a chance for any flushes to occur. This may happen in a network partition (communication lost between the two cluster members) where the offline member resumes ownership of a disk because it thought the other was down. This can occur although efforts are made to prevent it. When ownership of a disk is taken from the on line member, the disk becomes inaccessible immediately without the normal graceful offline behavior. As a result of an involuntary failover, the operating system receives errors when it attempts to write the data in the file system cache to the disk as part of normal background processing. The errors appear as popup boxes, indicating that a "delayed write" was unable to be written. The administrator can click OK to close these boxes. These warnings indicate that the disk failed over prematurely and that the administrator's file system I/Os were not written to the disk if they were issued just before, during, and after the disk went off line. Administrators should verify the state of their files and reissue the client operation when the group finishes failing over to the other server. Although the client file operation must be reissued, file system integrity is maintained. 4.9 Disk Administrator ----------------------- 4.9.1 Disk Administrator Shows Orphaned Disks ---------------------------------------------- The cluster software uses the following methods to dismount files systems for failovers: For voluntary failovers: Conventional or Disconnected For involuntary failovers: Disconnected A conventional dismount is tried first. A conventional dismount will fail if another program (such as File Manager) has locked the volume, or if files remain open on the volume. During a disconnected dismount, the disk data structure is disconnected from the underlying I/O system, but left physically present in the system. When the disk fails back to the system, it is reinstantiated. This guarantees that an old file system state associated with the old disk instance does not interfere with the new file system state on the new disk instance. However, as a side effect, the old disk instance remains visible in Disk Administrator, appearing as a gray box for the remainder of the system up time. This is normal behavior for the mechanism and is harmless. The gray box disappears when the system is rebooted. 4.9.2 Changing Drive Partitioning During Cluster Operations ------------------------------------------------------------ When drive partitioning is changed during cluster operations the related disk group may not fail over. The workaround is to reboot the system on which the partition changes were done. For example: Failover group XYZ containing Disk 1, resides on Host A. The administrator on Host A starts Disk Administrator, partitions Disk 1, assigns drive letters to the partitions, and then fails the group to Host B. Host A must now be rebooted before group XYZ will fail back to it 4.10 Potential Problem when Using Microsoft Word Version 6.0a ------------------------------------------------------------ If a document in a cluster share is being edited with Microsoft Word and the contents of the document are saved while the share is being failed over from one server to the other, Word can hang or crash. Once the failed server is rebooted, Word puts up one or more message boxes indicating an unrecoverable or serious disk failure. Clicking OK on these boxes eventually results in a protection failure in the Word application itself. If the application hangs, it can be terminated and the system will return to normal. This problem is not caused by DIGITAL Clusters for Windows NT and has been reproduced using Microsoft Word Version 6.0a on systems without DIGITAL Clusters for Windows NT installed. 4.11 Installing Visual C++ 4.2 ------------------------------ If you plan to install Visual C++ 4.2, first copy MFC40.DLL, MFC40U.DLL and MSVCRT40.DLL from the Windows NT system32 directory (typically C:\WINNT\SYSTEM32) into the Clusters installation directory (typically C:\Program Files\Digital\Cluster). Otherwise, the Cluster Administrator will crash on startup. 4.12 NET VIEW to Cluster NetBIOS Name Also Shows Unclustered Shares ------------------------------------------------------------------- When the "net view" command is used with a cluster NetBIOS name to view network resources, for example: "net view \\netbiosname" both clustered and unclustered shares for the server that currently has the related failover group are displayed. All shares on that server are accessible via \\netbiosname\share, even the hidden ones. This is the expected behavior. 4.13 System Hangs When Registry Size is Exceeded ------------------------------------------------ If the registry size is exceeded Cns.exe and CFMD could go into an infinite loop causing the system to hang. Solution: Increase the registry size and re-boot the system. Use this procedure to increase the registry size: o From the Start menu, select Settings. o Select Control Panel from the Settings menu. o Select "System" o Select the "Performance" tab. o Click the Change button in the Virtual Memory box. o The Current Registry Size is shown at the bottom of the Virtual Memory window. o Specify a greater Maximum Registry Size and click the OK button. o Click OK to close the System Properties window. 4.14 Cluster Services Do Not Start When a "Program" directory Exists Under the Same Parent Directory as the "Program files" directory ------------------------------------------------------------ If you have a "Program" directory under the same parent directory as the "Program files" directory, some cluster services may not start. Also, the Event Log displays an "access denied" error message. Double quotes added to certain cluster registry keys during the installation of DCNT 1.1 Service Pack 1 was supposed to solve this problem, but it created more problems than it fixed. The installation of Service Pack 2 and 3 makes sure the double quotes are removed from those registry keys. Workaround: When installing a fresh installation of DIGITAL Clusters for Windows NT Version 1.1, choose a target directory other than c:\Program Files\... if you have a c:\Program directory. 4.15 Uninstalling and Re-installing DIGITAL Clusters for Windows NT Version 1.1 selects the NetBIOS name of one of the cluster's IP Failover Objects as the other servers name. ------------------------------------------------------------------- During the "Join, Search Cluster" operation in the DIGITAL Clusters for Windows NT Version 1.1 installation, the NetBIOS name of an IP Failover Object is shown as the default for the other server node. If you click Next without fixing this discrepancy the new cluster node will be wrongly configured. Workaround: Verify that the other node's name is correctly identified prior to continuing with the installation. The DCNT V1.1 SP3 full install, available on DC_ROM only, corrects this discrepancy. 4.16 IP Failover Objects Corrupted When a Node Rejoins the Cluster with a Different NIC Configuration ----------------------------------------------------------- If you un-install DCNT on one of the cluster nodes and subsequently rejoin the cluster, the NIC configuration must remain the same as when it left the cluster. If it is different, all IP failover objects will be corrupted and inaccessible from the rejoining node. Workaround: If you are not able to keep the NIC configuration the same, you will need to perform the following procedure from the node that has remained in the cluster. 1) Note which IP failover objects are in which groups and the objects' order in that group 2) Delete all IP failover objects from the cluster 3) Re-create all the IP failover objects 4) Place the IP failover objects back in their respective groups in the proper order within each group. You can add additional NICs and/or change the binding order of existing NICs without causing a problem. It is the NIC or machine replacement that causes the problem. 4.17 Lotus Domino sample failover script names have changed ----------------------------------------------------------- The Lotus Domino Sample failover scripts described in Chapter 4 of the Administrator's Guide have had their names shortened. "Stop_Domino_Mfg.cmd" is now "StopDmfg.cmd" "Start_Domino_Mfg.cmd" is now "StrtDmfg.cmd" The contents of these scripts have not changed. 4.18 Using the Remote Cluster Administrator ------------------------------------------- 4.18.1 Dual NIC machine may not connect via an IP resource's IP address --------------------------------------------------------------- When running on a remote machine that has more than one NIC card enabled, the Remote Cluster Administrator may not allow a connection to a cluster node by using the IP address of an IP resource on that node. When this situation occurs, the IP resource's NetBIOS name, the IP address of the node, and the name of the node (the preferred method) can still be used to make a connection. 4.19 Network Failover --------------------------------------------- 4.19.1 Network Failover Configuration --------------------------------- When you configure your cluster to support Network failover you must configure a private network interface on each node. There are 3 main parts to the create/modify IP Object dialog box. The first 3 lines and the NIC selection window provide information about the identity of the object. The bottom information box contains the information on the NIC in the NIC selection box. The information in this box changes depending on which NIC is clicked on in either of the selection windows. You must select a NIC for each node when configuring your IP Object to insure that the object you are creating is bound to the correct NIC for each node. 4.19.2 Testing Loss of Network Connectivity ----------------------------------------- Disconnecting the network at the server interface or the hub may result in a delay of up to 1-1/2 minutes per NIC beyond the time set in the failover policy for the NIC. This delay is the result of the cluster software attempting to establish a stable communication nexus through the first bound NIC. This problem may not arise on a multihomed system if the loss of connectivity is not being tested for the first bound NIC. 4.19.3 Recommended Private NIC Binding Order ----------------------------------------- In order to ensure that the DCNT cluster can successfully use the private network, set the network bindings as follows: Control Panel - Network - Bindings 1) In "Show Bindings for" text box: select "all protocols". 2) Expand NETBEUI: The first NIC shown should be the NIC which is used for the private network. 3) Expand TCP/IP and WINS: The first NIC should be the public NIC, then the private NIC and then all other public NIC(s). If this is not the case, select the private NIC and use the Move Up button to reposition it first in the list. Then confirm the NetBIOS binding order, using Control Panel - Network - Services - NetBIOS interface - Properties The Private NIC should be the first one (Lana number = 000) If any protocol other than the NetBT for the private NIC is assigned 000, renumber it to another number, then renumber the private NIC NetBT to 000. 4.19.4 Disabling Network Failover ----------------------------------------- When Network failover is enabled, the system pings all its targets. If Network failover is disabled after a period of time during which it was enabled, the system may continue to ping its targets although the failover is disabled. In case of a connectivity loss with Network failover disabled, the system does not invoke a failover. To stop the pinging process, you must either stop and restart the DCNT failover manager service or restart the cluster nodes. 4.20 Oracle Failover Support ------------------------------ 4.20.1 Oracle8 or higher: Script-based Format Must be used For Oracle failover -------------------------------------------------------------- For Oracle8 or higher, one MUST use the script-based format for Oracle failover. Parameter-based Oracle failover objects can cause problems when used for Oracle8 or higher, because of the changes in Oracle Server Manager's executable name and the listener name, which Oracle may change again in subsequent product releases. Refer to the Administrator's Guide Addendum for details on a script-based Oracle failover object. The "Using Oracle Failover Objects" chapter in the addendum addresses why you may want to use the script-based format, the differences between a script-based and a parameter-based format and how to create and modify a script-based Oracle failover object. 4.20.2 Using an Oracle Instance as an Oracle Failover Object ------------------------------------------------------------ Before using an Oracle instance as an Oracle failover object, first make sure the Oracle instance runs without problems locally on each cluster node. You can use the starter database in every Oracle server product for such verification. An example of a problem is using Oracle7.3.2 or lower on Windows NT 4.0 or higher. On Windows NT 4.0, Oracle supports 7.3.3 or higher, but not 7.3.2 or lower. 4.20.3 Creating/Modifying Script-based Oracle Failover Objects/Converting from Parameter-based Format ------------------------------------------------------------ Both cluster nodes must be upgraded to DCNT V1.1 SP3 before creating/modifying a script-based Oracle failover object or converting existing, parameter-based Oracle failover objects to script-based format. 4.20.4 Converting to Script-based Format Can Be Slow if Either Cluster Node is Down. ------------------------------------------------------------ If either cluster node is down or disconnected, converting to the script-based Oracle failover object can become slow, because it needs access to the registries of both cluster nodes to complete the conversion. 4.21 Registry Synchronization ----------------------------- 4.21.1 Defining Registry Synchronization Objects for IIS 3.0 ------------------------------------------------------------ If you define the .\W3SVC\Parameters\Deny IP List or Grant IP List key for a Registry Synchronization object, DCNT will not see the removal of the last entry in the list (meaning, when you go from one entry to zero). We suggest using the .\W3SVC\Parameters key, but you must use the Internet Service Manager to make sure that the Anonymous User Name field is identical for both machines. 4.22 Cluster Monitor -------------------- 4.22.1 Cluster Monitor Displays No Information ---------------------------------------------- If you start the Cluster Monitor and get an hourglass cursor, but no information is displayed in a timely manner, select "Make New Connection" from the View menu and re-enter the connecting node name. 4.23 SNMP Management of DCNT Done Using ServerWORKS ---------------------------------------------- A previous release of DCNT included a separate installation of an SNMP extension-agent DLL and a supporting MIB. This agent extension and MIB allowed for SNMP management of DCNT clusters. These files are no longer supplied as a part of DCNT releases, but are instead part of the ServerWORKS Manager product. The latest version of ServerWORKS Manager can be downloaded at http://www.windows.digital.com/products/. This latest version has not been updated to handle DCNT V1.1 Service Pack 3 changes. Specifically, it has no knowledge of Registry Synchronization objects or NIC failover parameters. ------------------------------------------------------------- Copyright and Trademark Information Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Copyright Compaq Computer Corporation 1998 All rights reserved. The information in this document is subject to change without notice and should not be construed as a commitment by Compaq Computer Corporation. Compaq Computer Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Compaq or its affiliated companies. The following are trademarks of Compaq Computer Corporation: AlphaServer, AlphaStation, DIGITAL, Prioris, ServerWORKS, StorageWorks, and the DIGITAL logo. The following are third-party trademarks: Adaptec is a trademark of Adaptec Inc. Intel is a registered trademark of Intel Corporation. Macintosh is a registered trademark of Apple Computer, Inc. Microsoft, MS-DOS, Windows, and Windows 95 are registered trademarks and Windows NT is a trademark of Microsoft Corporation. NetBIOS is a trademark of Micro Computer Systems, Inc. Oracle and SQL*Net are registered trademarks and Oracle7 is a trademark of Oracle Corporation. OS/2 is a registered trademark of International Business Machines Corporation. SQL Server is a trademark of Sybase, Inc. All other trademarks and registered trademarks are the property of their respective holders.