* * * READ ME * * * * * * Veritas Cluster Server 5.1 SP1 RP1 * * * * * * P-patch 2 * * * Patch Date: 2011.05.06 This document provides the following information: * PATCH NAME * PACKAGES AFFECTED BY THE PATCH * BASE PRODUCT VERSIONS FOR THE PATCH * OPERATING SYSTEMS SUPPORTED BY THE PATCH * INCIDENTS FIXED BY THE PATCH * INSTALLATION PRE-REQUISITES * INSTALLING THE PATCH * REMOVING THE PATCH PATCH NAME ---------- Veritas Cluster Server 5.1 SP1 RP1 P-patch 2 PACKAGES AFFECTED BY THE PATCH ------------------------------ Veritas I/O Fencing BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Cluster Server 5.1 SP1 RP1 * Veritas Storage Foundation for Oracle RAC 5.1 SP1 RP1 * Veritas Storage Foundation Cluster File System 5.1 SP1 RP1 * Veritas Storage Foundation High Availability 5.1 SP1 RP1 * Veritas Storage Foundation Cluster File System for Oracle RAC 5.1 SP1 RP1 * Symantec VirtualStore 5.1 SP1 RP1 OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- RHEL5 x86-64 INCIDENTS FIXED BY THE PATCH ---------------------------- This patch fixes the following Symantec incidents: Patch ID: 5.1.101.200 * 2365402 (Tracking ID: 2365394) SYMPTOM: When a VCS node starts up, if even one of the coordination points for the Veritas fencing module (VxFEN) is inaccessible to the node, then VxFEN fails to start on that node. It is desirable that VxFEN must be able to start on the node as long as a majority of the coordination points are accessible to the node when the node starts up. DESCRIPTION: When a node starts up, the following conditions must occur before VxFEN starts on that node: aC/ VxFEN must be able to get the Universal Unique Identifier (UUID) or serial number of each coordination point specified in the /etc/vxfenmode file. aC/ VxFEN must be able to register the node with a majority of CPs specified in the /etc/vxfenmode file. However, due to accessibility issues, if VxFEN fails to get the UUID or serial number of one of the specified CPs, then VxFEN treats it as a fatal failure. The node cannot then join a cluster or start a cluster. As a result, every coordination point becomes a potential single point of failure, and compromises high availability (HA). RESOLUTION: Symantec has modified the fencing module to fix the issue. Each VCS node now stores the UUIDs or serial numbers of all the coordination points that the node registers with. As a result, if a node is later unable to access a specified coordination point, VxFEN can use the stored UUIDs/serial numbers. By design, the fix works only when a majority of coordination points are accessible to the node when the node starts. At the time of a fencing race, the racer needs to have its keys registered on a majority of coordination points in order to be able to win the race. In order to enable this, fencing is designed to not start if a majority of coordination points are not available at the time of startup. This fix applies only to clusters that use customized fencing. As part of the fix, Symantec has introduced two optional attributes to the /etc/vxfenmode file. db_ignore_list : Specifies the type/s of coordination points for which a node must not store the UUID/serial number. To specify multiple values, use a comma- separated list. VxFEN supports the values "none", "disk", and "server". Note: By default, this feature is available only for coordination point servers. To turn it on for disks, you must set the value of the db_ignore_list to "none". db_entries_limit: Specifies the maximum number of UUIDs/serial numbers that a node can store. The default value for this attribute is 1000. If the default value is used, the node approximately requires 1MB of disk space to store the UUIDs/serial numbers. INSTALLING THE PATCH -------------------- /etc/init.d/vcs stop /etc/init.d/vxfen stop rpm -ev VRTSvxfen rpm -ivh /etc/init.d/vxfen start /etc/init.d/vcs start REMOVING THE PATCH ------------------ /etc/init.d/vcs stop /etc/init.d/vxfen stop rpm -ev VRTSvxfen SPECIAL INSTRUCTIONS -------------------- NONE