README_VCS for VERITAS Cluster Server (tm) 2.1Patch 1

Article:TECH93053  |  Created: 2004-01-14  |  Updated: 2004-01-14  |  Article URL http://www.symantec.com/docs/TECH93053
Article Type
Technical Solution


Environment

Issue



README_VCS for VERITAS Cluster Server (tm) 2.1Patch 1

Solution



* * * READ ME - VERITAS Cluster Server 2.1 - Patch 1 (LINUX) * * *

                 Patch Date:  June 2003


  This document provides information for:

  * FIXES AND ENHANCEMENTS INCLUDED IN THE PATCH
  * LIST OF FILES AFFECTED BY THE PATCH
  * INSTALLING THE CLUSTER SERVER PATCH
  * REMOVING THE CLUSTER SERVER PATCH
  * CHANGES TO THE CLUSTER SERVER 2.1 RELEASE NOTES


BEFORE GETTING STARTED
----------------------

This patch is for VERITAS Cluster Server 2.1 on Linux. You must first install Cluster Server 2.1 before applying this patch.  

For upgrades from Cluster Server 2.0 to Cluster Server 2.1, see instructions in TechNote 259838 (link included below).


For fresh installations of Cluster Server 2.1, see instructions in the VERITAS Cluster Server 2.1 Installation Guide. When installation of Cluster Server 2.1 is nearly complete, the installvcs script prompts you with:
  Installation will now start the Cluster components on all systems
  Do you want to start it now? (Y/N)
Answer NO and follow the instructions in this README for installing the Cluster Server patch on an inactive system.

NOTE: Cluster Server will not run on the 2.4.9-e.16summit kernel without the Cluster Server 2.1 Patch 1installed.

If you are applying this patch to a VERITAS product that includes Cluster Server as a component, refer to the patch installation procedures for that product.


FIXES AND ENHANCEMENTS INCLUDED IN THIS CLUSTER SERVER PATCH
-------------------------------------------------

109605: LLT performance degradation and high CPU usage.

118388: Typo in Mount agent clean entry point.

121376: diskres module asserts incorrectly.

122508: LLT does not work for sap values other than 0xCAFE.

123730: HAD restart leads to broken RSM and possible concurrency violation.


FILES AFFECTED BY THIS CLUSTER SERVER PATCH
--------------------------------

   VRTSvcs:
   
       The entire VRTSvcs package is included with the patch.
   
   VRTSllt:
   
  /lib/modules/2.4.9-e.3[smp]/veritas/vcs/llt.o
   
   VRTSgab:
   
  /lib/modules/2.4.9-e.3[smp]/veritas/vcs/gab.o

   
INSTALLING THE CLUSTER SERVER PATCH ON AN INACTIVE SYSTEM
----------------------------------------------

If Cluster Server is not currently running, use the rpm command to install the patch on each system in the cluster:

1. Remove old versions of Cluster Server packages. On each system, type:

# rpm -ev VRTSvcs
# rpm -ev VRTSgab
# rpm -ev VRTSllt

2. Change directory to the patch location:

    # cd <patch_location>
   
3. Install the Cluster Server  2.1P1 packages using the rpm command. On each system, type:

# rpm -ivh VRTSllt-2.1P1-Linux.i386.rpm
# rpm -ivh VRTSgab-2.1P1-Linux.i386.rpm
# rpm -ivh VRTSvcs-2.1P1-Linux.i386.rpm

4. Upgrade Cluster Server to work with the Red Hat kernel on your systems by copying Cluster Server kernel modules from the directory:
   
      /lib/modules/2.4.9-e.3<kernel-type>/veritas/vcs
     
  to the corresponding directory for your kernel.
   
  For example, steps to copy the Cluster Server kernel modules from 2.4.9-e.3smp to 2.4.9-e.16smp would be as follows:
   
  a. Change directory to the location for the kernel on your system:
   
      # cd /lib/modules/2.4.9-e.16smp
   
  b. Create a VERITAS directory for the modules if this directory does not already exist:
   
      # mkdir veritas
 
  c. Copy the Cluster Server kernel modules into the directory:
   
      # cp -rp /lib/modules/2.4.9-e.3smp/veritas/vcs ./veritas
   
NOTE: If you are using VERITAS File System (tm), you must make additional changes to ensure proper loading of the NFSD module. Before proceeding to Step d, refer to TechNote 243712 (link below).

  d. Repeat Steps a through c on each system in the cluster.


5. Load kernel modules. On each system, type:

       # loadllt
       # loadgab

6. Start low latency transport (LLT). On each system, type:

       # lltconfig -c

7. Verify LLT is configured. On each system, type:

       # lltconfig

   The following message is displayed:

       LLT is running.

8. Start global atomic broadcast (GAB). On each system, type:

       # gabconfig -c -x

9. Verify GAB is configured. On each system, type:

       # gabconfig -a

   Output resembles:

       GAB Port Memberships
       =====================================
       Port a gen 58dc0005 membership 01

   You should see port a for each node on which GAB is running.


10. On each system, type:

       # hastart



INSTALLING THE CLUSTER SERVER PATCH ON A RUNNING CLUSTER
---------------------------------------------

To apply the patch to a running Cluster Server cluster:

1. List the service groups in your cluster and their status. On any system, type:

       # hagrp -state

2. Offline the ClusterService service group if it is running. On any system, type:

       # hagrp -offline ClusterService -sys <system>

3. Make the Cluster Server configuration writeable. On any system, type:

       # haconf -makerw

4. Freeze all service groups. On any system, type:

       # hagrp -freeze <service_group> -persistent

5. Save the configuration file (main.cf) with the groups frozen. On any system, type:

       # haconf -dump -makero

6. Shut down Cluster Server. On any system, type:

       # hastop -all -force

7. Confirm that Cluster Server has shut down. On each system, type:

# gabconfig -a

  Output resembles:
 
       GAB Port Memberships
       =====================================
       Port a gen 23dc0001 membership 01

  Note that the output shows no membership for port h.


8. Unconfigure GAB. On each system, type:

# gabconfig -u

If unconfiguring GAB fails and you receive messages that say the device cannot be unconfigured because it is busy, you must reboot the systems after installing the patch.


9. Unconfigure LLT. On each system, type:

# lltconfig -U

  The following message is displayed:

lltconfig: this will attempt to stop and reset LLT.  Confirm (y/n)?


10. Type Y on each system in response to the message. If unconfiguring LLT fails and you receive messages that say the device cannot be unconfigured because it is busy, you must reboot the systems after installing the patch.

11. Unload the GAB and LLT modules from the kernel. On each system, type:

# unloadgab
# unloadllt

   If either the LLT or GAB kernel modules fails to unload, you must reboot the systems after completing the Cluster Server upgrade.


12. Make a copy of the current main.cf and types.cf configuration files. On one node in the cluster, type:
   
# cp /etc/VRTSvcs/conf/config/main.cf /etc/VRTSvcs/conf/main.cf.save
# cp /etc/VRTSvcs/conf/config/types.cf /etc/VRTSvcs/conf/types.cf.save

13. Make copies of the configuration files /etc/llthosts, /etc/llttab, and /etc/gabtab on each system because these files may vary by system. On each system, type:
   
# cp /etc/llthosts /etc/llthosts.save
# cp /etc/llttab /etc/llttab.save
# cp /etc/gabtab /etc/gabtab.save

14. Shut down the Cluster Server CmdServer. On each system, type:

# pkill -9 CmdServer

15. Remove old versions of Cluster Server packages. On each system, type:

# rpm -ev VRTSvcs
# rpm -ev VRTSgab
# rpm -ev VRTSllt

16. Change directory to the patch location.

17. Install the Cluster Server 2.1P1 packages using the rpm command. On each system, type:

# rpm -ivh VRTSllt-2.1P1-Linux.i386.rpm
# rpm -ivh VRTSgab-2.1P1-Linux.i386.rpm
# rpm -ivh VRTSvcs-2.1P1-Linux.i386.rpm

18. Verify the 2.1P1 packages are installed. On each system, type:

# rpm -qi VRTSllt | grep Version
Version     : 2.1P1      Vendor: VERITAS Software Corporation Inc.

# rpm -qi VRTSgab | grep Version
Version     : 2.1P1      Vendor: VERITAS Software Corporation Inc.

# rpm -qi VRTSvcs | grep Version
Version     : 2.1P1      Vendor: VERITAS Software Corp.


19. Upgrade Cluster Server to work with the Red Hat kernel on your systems by copying Cluster Server kernel modules from the directory
   
      /lib/modules/2.4.9-e.3<kernel-type>/veritas/vcs
     
   to the corresponding directory for your kernel.
   
   For example, steps to copy the Cluster Server kernel modules from 2.4.9-e.3smp to 2.4.9-e.16smp would be as follows:
   
   a. Change the directory to the location for the kernel on your system:
   
       # cd /lib/modules/2.4.9-e.16smp
   
   b. Create a VERITAS directory for the modules if this directory does not already exist:
   
       # mkdir veritas
   
   c. Copy the Cluster Server kernel modules into the directory:
   
       # cp -rp /lib/modules/2.4.9-e.3smp/veritas/vcs ./veritas
   
   NOTE: If you are using VERITAS File System, you must make additional changes to ensure proper loading of the NFSD module. Before proceeding to Step d, refer to TechNote 243712 (link below)

   d. Repeat Steps a through c on each system in the cluster.

       
20. On the node where you plan to run the hastart command first, restore main.cf and types.cf from the location where you saved them in Step 12:
   
# cp /etc/VRTSvcs/conf/main.cf.save /etc/VRTSvcs/conf/config/main.cf
# cp /etc/VRTSvcs/conf/types.cf.save /etc/VRTSvcs/conf/config/types.cf

21. Load kernel modules. On each system, type:

# loadllt
# loadgab

22. Start LLT. On each system, type:

# lltconfig -c

23. Verify LLT is configured. On each system, type:

# lltconfig

   The following message is displayed:
   
    LLT is running.

24. Start GAB. On each system, type:

# gabconfig -c -x

25. Verify GAB is configured. On each system, type:

# gabconfig -a

   Output resembles:
   
GAB Port Memberships
       =====================================
Port a gen 58dc0005 membership 01

   You should see port a for each node on which GAB is running.
   
   
26. Beginning with the system on which you restored main.cf and types.cf, restart Cluster Server on each system in the cluster. On each system, type:

       # hastart

27. After Cluster Server has started on all systems, perform the following steps:

   a. Verify all resources have been probed. On any system, type:

       # hastatus -summary

   b. Unfreeze all service groups. On any system, type:

       # haconf -makerw

       # hagrp -unfreeze <service_group> -persistent

       # haconf -dump -makero

   c. Online the ClusterService service group, if necessary. On any system type:

       # hagrp -online ClusterService -sys <system>


REMOVING THE CLUSTER SERVER PATCH
-------------------------

To remove the patch from a running Cluster Server cluster:

1. On each system, repeat Step 1 through Step 13 of the manual installation procedure.

2. Remove the packages using the rpm command:

# rpm -ev VRTSvcs
# rpm -ev VRTSgab
# rpm -ev VRTSllt
       
3. Verify the patch has been removed from each system. For example, type:  
   
# rpm -qi VRTSllt | grep Version
       
  The command should return no output.
       
       
4. Reinstall the Cluster Server 2.1 packages from the Cluster Server 2.1 CD. On each system, type:

# rpm -ivh VRTSllt-2.1-Linux.i386.rpm
# rpm -ivh VRTSgab-2.1-Linux.i386.rpm
# rpm -ivh VRTSvcs-2.1-Linux.i386.rpm


CHANGES TO CLUSTER SERVER 2.1 RELEASE NOTES
---------------------------------

NOTE: Page numbers cited below refer to the printed document.
     
- Supported Hardware (page 4):  
 
    To the list of supported servers, add:
   
       IBM xSeries 440  


- Software Limitations (page 9)

    To the software limitations, add:
     
At the time of this patch release, support of IBM xSeries 440 systems is on the 2.4.9-e.16summit kernel only. Cluster Server 2.1P1 is required for support of this kernel.
 
     






Legacy ID



259499


Article URL http://www.symantec.com/docs/TECH93053


Terms of use for this information are found in Legal Notices