Veritas Storage Foundation 5.1 SP1 for Oracle RAC Release Notes (5900-1513, April 2011)
Preferred fencing does not work as expected for large clusters in certain
cases
If you have configured system-based or group-based preferred fencing policy,
preferred fencing does not work if all the following cases are true:
■ The fencing setup uses customized mode with one or more CP servers.
■ The application cluster has more than eight nodes.
■ The node weight for a single node (say galaxy with node id 0) is more than the
sum total of node weights for the rest of the nodes.
■ A network fault occurs and the cluster partitions into two with the single node
(galaxy) on one part and the rest of the nodes on the other part.
Under such circumstances, for group-based preferred fencing, the single node
panics even though more high priority services are online on that node. For
system-based preferred fencing, the single node panics even though more weight
is assigned to the node. [2161816]
See the Veritas Storage Foundation for Oracle RAC Administrator's Guide for more
information on preferred fencing.
Reconfiguring SF Oracle RAC with I/O fencing fails if you use the same CP
servers
When you reconfigure an application cluster that uses server-based I/O fencing
(customized fencing mode), the installer does not remove the application cluster
information from the CP servers before the reconfiguration. As a result, if you
reconfigure the application cluster and choose to configure I/O fencing in
customized mode using the same CP servers, then reconfiguration of server-based
fencing for the application cluster fails. [2076240]
Workaround: Manually remove the application cluster information from the CP
servers after you reconfigure SF Oracle RAC but before you reconfigure
server-based I/O fencing for the application cluster.
See the Veritas Cluster Server Administrator's Guide for instructions to remove
the application cluster information from the CP servers.
CP server cannot bind to multiple IPs (2085941)
Coordination point server (CP server) binds only to a single virtual IP and listens
on the same. Application clusters cannot access the CP server if it fails to establish
connection to this virtual IP. Therefore, if the connection fails because of the
subnet in which the virtual IP of the CP server exists, you cannot access the CP
server even if there is another subnet through which the client can connect to the
CP server over a different IP.
Resolution: No known resolution for this issue.
47Storage Foundation for Oracle RAC Release Notes
Known issues