HINTS:
How to get a servicegroup to DEFAULTstart on one of the nodes:
#hagrp -modify grpnam AutoStartList nodename
****************************************************************
Process apache (
PathName = "/opt/apache/httpd"
Arguments = "-f /opt/apache/conf/httpd.conf"
)
Simple support for apache web-server (also in VCS WEB-edition)
***************************************************************
5. Verify your configuration:
# cd /etc/VRTSvcs/conf/config
# hacf -verify .
6. Start VCS services:
# /etc/rc2.d/S70llt start
# /etc/rc2.d/S92gab start
# /etc/rc3.d/S99vcs start
***************************************************************
o change the tcp port the VERITAS Cluster Server Cluster Monitor (hagui) uses, a port number in the /etc/inet/services file on each system of the
cluster must be specified. That entry should look like:
vcs 25000/tcp vcs #
All the machines in the cluster will need to be restarted for the change to take effect. When starting the hagui, right click on the cluster name in the Cluster
Monitor system window and set the port to reflect the changed port number. In this example 25000 was used, but any unused tcp port can be used with the
same results.
By default, the hagui uses port 14141.
****************************************************************
Symptom:
How do I test a VERITAS Cluster Server (VCS) agent that doesn't appear to be working correctly?
Solution:
To activate agent debug messages:
# hatype -modify resource_type LogLevel info
To check the status of a resource:
# hares -display resource_name
To bring a resource online:
# hares -online resource_name -sys system_name
This causes the online entry point of the corresponding agent to be called.
To take a resource offline:
# hares -offline resource_name -sys system_name
This causes the offline entry point of the corresponding agent to be called.
To deactivate agent debug messages:
# hatype -modify resource_type LogLevel error
********************************************************************
Symptom:
Sybase agent times out when it is running the online script (on the takeover host), fails to start Sybase and does not put anything useful in the VERITAS
Cluster Server (VCS) logs.
Solution:
The cause can be the incorrect setup of the interface in Sybase's $SYBASE_HOME/interfaces file. By default, the Sybase installation uses the interface
available on the host, which may not be the interface that VCS is failing over. Since the unavailable interface causes a Sybase timeout instead of an error,
nothing is logged in the VCS engine log.
From the VCS Enterprise Agent for Sybase 1.0.2:
"Transparent TCP/IP Failover"
For transparent failover to Sybase clients, create an IP address as part of the Sybase service group. This IP address must match the dataserver and backup
server entries in the $SYBASE_HOME/interfaces file. For information on the format for adding entries to the $SYBASE_HOME/interfaces file, see the
Sybase SQL Server Installation and Configuration Guide."
*******************************************************************
Symptom:
The VERITAS Cluster Server (VCS) version 1.1 Sybase agent fails to recognize that the database is running. The agent triggers a shutdown of the
resource and changes the state to FAILED.
Solution:
The VCS Sybase agent is very sensitive to the order of arguments of the data server process.
If the "-s" is visible as a data server argument but is preceded by a "-d" string which also contained the data server name:
/opt/sybase/bin/dataserver -d/sybase//syst/master.dat -s -e...
you may experience problems with the agent monitoring the Sybase database resources.
Put the "-s" in front of "-d" to solve this monitoring problem.
This the default order, when the files are generated by the Sybase installation utility (Release 11.0.3, 11.5.1, 11.9.2). The order of the argument list does not
influence the behavior of the Sybase server daemons, but have an impact on the VCS agents.
******************************************************************''
Symptom:
How and when to use the ProxyAgent for VERITAS Cluster Server (VCS).
Solution:
The ProxyAgent is used to replicate the state of one resource in a service group into another service group. For instance, it is normal to have IP resources
depend on NIC resources in service groups. Instead of having three or four NIC resources testing the same network interface every sixty seconds, a
ProxyAgent could be used to replicate the state of one NIC resource. In terms of system load there would be one check to determine if the network interface
was active and the other service groups would have a ProxyAgent reflecting the state. In the event of a fault of the NIC resource the ProxyAgent would
fault on that system as well, producing the same behavior. The ProxyAgent is best used to replicate None resources, None means VCS has no control over
either starting or stopping.
****************************************************************'
http://support.veritas.com/menu_ddProduct_CLUSTERSERVER.htm