Veritas Cluster VCS Cheat Sheet
Concepts
VCS is built on three components: LLT, GAB, and VCS itself. LLT
handles kernel-to-kernel communication over the LAN heartbeat links,
GAB handles shared disk communication and messaging between cluster
members, and VCS handles the management of services.
Once cluster members can communicate via LLT and GAB, VCS is started.
In the VCS configuration, each Cluster contains systems, Service
Groups, and Resources. Service Groups contain a list of systems
belonging to that group, a list of systems on which the Group should
be started, and Resources. A Resource is something controlled or
monitored by VCS, like network interfaces, logical IP's, mount point,
physical/logical disks, processes, files, etc. Each resource
corresponds to a VCS agent which actually handles VCS control over the
resource.
VCS configuration can be set either statically through a configuration
file, dynamically through the CLI, or both. LLT and GAB configurations
are primarily set through configuration files.
Configuration
VCS configuration is fairly simple. The three configurations to worry
about are LLT, GAB, and VCS resources.
LLT
LLT configuration requires two files: /etc/llttab and /etc/llthosts.
llttab contains information on node-id, cluster membership, and
heartbeat links. It should look like this:
# llttab -- low-latency transport configuration file
# this sets our node ID, must be unique in cluster
set-node 0
# set the heartbeat links
link hme1 /dev/hme:1 - ether - -
# link-lowpri is for public networks
link-lowpri hme0 /dev/hme:0 - ether - -
# set cluster number, must be unique
set-cluster 0
start
The "link" directive should only be used for private links.
"link-lowpri" is better suited to public networks used for heartbeats,
as it uses less bandwidth. VCS requires at least two heartbeat signals
(although one of these can be a communication disk) to function
without complaints.
The "set-cluster" directive tells LLT which cluster to listen to. The
llttab needs to end in "start" to tell LLT to actually run.
The second file is /etc/llthosts. This file is just like /etc/hosts,
except instead of IP->hostnames, it does llt node numbers (as set in
set-node). You need this file for VCS to start. It should look like
this:
0 daldev05
1 daldev06
GAB
GAB requires only one configuration file, /etc/gabtab. This file lists
the number of nodes in the cluster and also, if there are any
communication disks in the system, configuration for them. Ex:
/sbin/gabconfig -c -n2
tells GAB to start GAB with 2 hosts in the cluster. To specify VCS
communication disks:
/sbin/gabdisk -a /dev/dsk/cXtXdXs2 -s 16 -p a
/sbin/gabdisk -a /dev/dsk/cXtXdXs2 -s 144 -p h
/sbin/gabdisk -a /dev/dsk/cYtYdYs2 -s 16 -p a
/sbin/gabdisk -a /dev/dsk/cYtYdYs2 -s 144 -p h
-a specifies the disk, -s specifies the start block for each
communication region, and -p specifies the port to use, "a" being the
GAB seed port and "h" the VCS port. The ports are the same as the
network ports used by LLT and GAB, but are simulated on a disk.
VCS
The VCS configuration file(s) are in /etc/VRTSvcs/conf/config. The two
most important files are main.cf and types.cf. I like to set $VCSCONF
to that directory to make my life easier. main.cf contains the actual
VCS configuration for Clusters, Groups, and Resources, while types.cf
contains C-like prototypes for each possible Resource.
The VCS configurationis very similar to the C language, but all you
are doing is defining variables. Comments are "//" (if you try to use
#'s, you'll be unhappy with the result), and you can use "include"
statements if you want to break up your configuration to make it more
readable. One file you must include is types.cf.
In main.cf, you need to specify a Cluster definition:
cluster iMS ( )
You can specify variables within this cluster definition, but for the
most part, the defaults are acceptible. Cluster variables include
maximum number of groups per cluster, link monitoring, log size,
maximum number of resources, maximum number of types, and a list of
user names for the GUI that you will never use and shouldn't install.
You then need to specify the systems in the cluster:
system daldev05 ( )
system daldev06 ( )
These systems must be in /etc/llthosts for VCS to start.
You can also specify SNMP settings for VCS:
snmp vcs (
Enabled = 1
IPAddr = 0.0.0.0
TrapList = { 1 = "A new system has joined the VCS Cluster",
2 = "An existing system has changed its state",
3 = "A service group has changed its state",
4 = "One or more heartbeat links has gone down",
5 = "An HA service has done a manual restart",
6 = "An HA service has been manually idled",
7 = "An HA service has been successfully started" }
)
IPAddr is the IP address of the trap listener. Enabled defaults to 0,
so you need to include this if you want VCS to send traps. You can
also specify a list of numerical traps; listed above are the VCS
default traps.
Each cluster can have multiple Service Group definitions. The most
basic Service Group looks like this:
group iMS5a (
SystemList = { daldev05, daldev06 }
AutoStartList = { daldev05 }
)
You can also set the following variables (not a complete list):
* FailOverPolicy - you can set which policy is used to determine
which system to fail over to, choose from Priority (numerically based
on node-id), Load (system with the lowest system load gets failover),
or RoundRobin (system with the least number of active services is
chosen).
* ManualOps - whether VCS allows manual (CLI) operation on this Group
* Parallel - indicats if the service group is parallel or failover
Inside each Service Group you need to define Resources. These are the
nuts and bolts of VCS. A full description of the bundled Resources can
be found in the Install Guide and a full description of the
configuration language can be found in the User's Guide.
Here are a couple of Resource examples:
NIC networka (
Device = hme0
NetworkType = ether
)
IP logical_IPa (
Device = hme0
Address = "10.10.30.156"
)
The first line begins with a Resource type (e.g. NIC or IP) and then a
globally unique name for that particular resource. Inside the paren
block, you can set the variables for each resource.
Once you have set up resources, you need to build a resource
dependancy tree for the group. The syntax is "child_resource requires
parent_resource." A dependancy tree for the above resources would look
like this:
logical_IPa requires networka
The dependancy tree tells VCS which resources need to be started
before other resources can be activated. In this case, VCS knows that
the NIC hme0 has to be working before resource logical_IPa can be
started. This works well with things like volumes and volumegroups;
without a dependancy tree, VCS could try to mount a volume before
importing the volume group. VCS deactivates all VCS controlled
resources when it shuts down, so all virtual interfaces (resource type
IP) are unplumbed and volumes are unmounted/exported at VCS shutdown.
Once the configuration is buld, you can verify it by running
/opt/VRTSvcs/bin/hacf -verify and then you can start VCS by running
/opt/VRTSvcs/bin/hastart.
Commands and Tasks
Here are some important commands in VCS. They are in /opt/VRTSvcs/bin
unless otherwise noted. It's a good idea to set your PATH to include
that directory.
Manpages for these commands are all installed in /opt/VRTS/man.
* hastart starts VCS using the current seeded configuration.
* hastop stops VCS. -all stops it on all VCS nodes in the cluster,
-force keeps the service groups up but stops VCS, and -local stop VCS
on the current node, and -sys systemname stop VCS on a remote system.
* hastatus shows VCS status for all nodes, groups, and resources.
It waits for new VCS status, so it runs forever unless you run it with
the -summary option.
* /sbin/lltstat shows network statistics (for only the local host)
much like netstat -s. Using the -nvv option shows detailed information
on all hosts on the network segment, even if they aren't members of
the cluster.
* /sbin/gabconfig sets the GAB configuration just like in
/etc/gabtab. /sbin/gabconfig -a show current GAB port status. Output
should look like this:
daldev05 # /sbin/gabconfig -a
GAB Port Memberships
===============================================================
Port a gen f6c90005 membership 01
Port h gen 3aab0005 membership 01
The last digits in each line are the node IDs of the cluster
members. Any mention of "jeopardy" ports means there's a problem with
that node in the cluster.
* haclus displays information about the VCS cluster. It's not
particularly useful because there are other, more detailed tools you
can use:
* hasys controls information about VCS systems. hasys -display
shows each host in the cluster and it's current status. You can also
set this to add, delete, or modify existing systems in the cluster.
* hagrp controls Service Groups. It can offline, online (or swing)
groups from host to host. This is one of the most useful VCS tools.
* hares controls Resources. This is the finest granular tool for
VCS, as it can add, remove, or modify individual resources and
resource attributes.
Here are some useful things you can do with VCS:
Activate VCS: run "hastart" on one system. All members of the cluster
will use the seeded configuration. All the resources come up.
Swing a whole Group administratively:
Assuming the system you're running GroupA on is sysa, and you want to
swing it to sysb
hagrp -switch GroupA -to sysb
Turn off a particular resource (say, ResourceA on sysa):
hares -offline ResourceA -sys sysa
In a failover Group, you can only online the resource on system on
which the group is online, so if ResourceA is a member of GroupA, you
can only bring ResourceA online on the system that is running GroupA.
To online a resource:
hares -online ResourceA -sys sysa
If you get a fault on any resource or group, you need to clear the
Fault on a system before you can bring that resource/group up on it.
To clear faults:
hagrp -clear GroupA
hares -clear ResourceA
Caveats
Here are some tricks for VCS:
VCS likes to have complete control of all its resources. It brings up
all its own virtual interfaces, so don't bother to do that in your
init scripts. VCS also likes to have complete control of all the
Veritas volumes and groups, so you shouldn't mount them at boot. VCS
will fail to mount a volume unless it is responsible for importing the
Volume Group; if you import the VG and then start VCS, it will fail
after about 5 minutes and drop the volume without cleaning the FS. So
make sure all VCS-controlled VG's are exported before starting VCS.
Resource and Group names have no scope in VCS, so each must be a
unique identifier or VCS will fail to load your new configuration.
There is no equivalent to perl's my or local. VCS is also very case
sensitive, so all Types, Groups, Resources, and Systems must be the
same every time. To make matters worse, most of the VCS bundled types
use random capitalization to try to fool you. Copy and paste is your
friend.
Make sure to create your Resource Dependancy Tree before your start
VCS or you could fuck up your whole cluster.
The default time-out for LLT/GAB communication is 15 seconds. If VCS
detects a system is down on all communcations channels for 15 seconds,
it fails all of that system's resource groups over to a new system.
If you use Veritas VM, VCS can't manage volumes in rootdg, so what I
do is encapsulate the root disk into rootdg and create new volume in
their own VCS managed VG. Don't put VCS and non-VCS volumes in the
same VG.
Don't let VCS manage non-virtual interfaces. I did this in testing,
and if you fail a real interface, VCS will unplumb it, fail it over to
a virtual on the fail-over system. Then when you try to swing it back,
it will fail.
Notes on how the configuration is loaded
Because VCS doesn't have any determination of primary/slave for the
cluster, VCS needs to determine who has the valid configuration for
the cluster. As far as I can tell (because of course it's not
documented), this is how it works: When VCS starts, GAB waits a
predetermined timeout for the number of systems in /etc/gabtab to join
the cluster. At this point, all the systems in the cluster compare
local configurations, and the system with the newest config tries to
load it. If it's invalid, it pulls down the second newest valid
config. If it is valid, all the systems in VCS load that config.
#######################################################################################
Creating Service Group
# haconf -makerw àTo open Cluster configuration
#hagrp -add
#hagrp -modify
To Allow service group to run in two system with priority 1 to system1
#hagrp -modify
To allow system 1 to start specified service group.
#hagrp -display
To verify service group can auto start and
it is a failover service group.
#haconf -dump -makero
à To save cluster and make configuration
file main.cf read only.
#view /etc/VRTSvcs/conf/config/main.cf
To view configuration file for changes
Adding Resources to a Service Group Nic
#hares -makerw
#hares -add
#hares -modify
#hares -modify
#hares -modify
#hares -online
#hares -display
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Adding Resources to a Service Group IP
#hares -add
#hares -modify
#hares -modify
#hares -modify
#hares -modify
#hares -online
#hares -display
#ifconfig -a
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Adding Resources to a Service Group Disk Group
#hares -add
#hares -modify < nameDG1> Critical 0 (zero)
#hares -modify < nameDG1> DiskGroup < nameDG1>
#hares -modify < nameDG1> Enabled 1
#hares -online < nameDG1> -sys
#hares -display < nameDG1 >
#vxprint -g
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Adding Resources to a Service Group Disk Volume
#hares -add
#hares -modify < nameVOL1> Critical 0 (zero)
#hares -modify < nameVOL1> Volume < nameVOL1>
#hares -modify < nameVOL1> DiskGroup < nameDG1>
#hares -modify < nameVOL1> Enabled 1
#hares -online < nameVOL1> -sys
#hares -display < nameVOL1 >
#vxprint -g
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Adding Resources to a Service Group Mount
#hares -add
#hares -modify < nameMount1> Critical 0 (zero)
#hares -modify < nameMount1> BlockDevice < path_nameVOL1>
#hares -modify < nameMount1> MountPoint < mount_point>
#hares -modify
#hares -modify
#hares -modify < nameMOunt1> Enabled 1
#hares -online < nameMount1> -sys
#hares -display < nameMount1>
#mount
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Adding Resources to a Service Group Process Resource
#hares -add
#hares -modify < nameProcess1> Critical 0 (zero)
#hares -modify < nameProcess1> Pathname < /bin/sh>
#hares -modify < nameProcess1> Arguments < /name1/loopy spacename 1>
#hares -modify < nameProcess1> Enabled 1
#hares -online < nameProcess1> -sys
#hares -display < nameProcess1 >
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
Linking Resources in Service Group
#hares -link
#hares -link
#hares -link
#hares -link
#hares -link
#hares -dep
#hares -dump
#view /etc/VRTSvcs/conf/config/main.cf
Testing the Service Group
#hagrp -switch
#hastatus -system
#hagrp -switch
#hastatus -summary
Setting Resources to Critical
#hares -modify
#hares -modify
#hares -modify
#hares -modify
#hares -modify
#hares -modify
#haconf -dump
#view /etc/VRTSvcs/conf/config/main.cf
#haconf -dump -makero
########################################################################################
Veritas Cluster Tasks
Create a Service Group
hagrp -add groupw
hagrp -modify groupw SystemList sun1 1 sun2 2
hagrp -autoenable groupw -sys sun1
Create a disk group resource , volume and filesystem resource
We have to create a disk group resource, this will ensure that the disk group has been imported before we start any volumes
hares -add appDG DiskGroup groupw
hares -modify appDG Enabled 1
hares -modify appDG DiskGroup appdg
hares -modify appDG StartVolumes 0
Once the disk group resource has been created we can create the volume resource
hares -add appVOL Volume groupw
hares -modify appVOL Enabled 1
hares -modify appVOL Volume app01
hares -modify appVOL DiskGroup appdg
Now that the volume resource has been created we can create the filesystem mount resource
hares -add appMOUNT Mount groupw
hares -modify appMOUNT Enabled 1
hares -modify appMOUNT MountPoint /apps
hares -modify appMOUNT BlockDevice /dev/vx/dsk/appdg/app01
hares -modify appMOUNT FSType vxfs
To ensure that all resources are started in order, we create dependencies against each other
hares -link appVOL appDG
hares -link appMOUNT appVOL
Create a application resource
Once the filesystem resource has been created we cab add a application resource, this will start, stop and monitor the application.
hares -add sambaAPP Application groupw
hares -modify sambaAPP Enabled 1
hares -modify sambaAPP User root
hares -modify sambaAPP StartProgram "/etc/init.d/samba start"
hares -modify sambaAPP StopProgram "/etc/init.d/samba stop"
hares -modify sambaAPP CleanProgram "/etc/init.d/samba clean"
hares -modify sambaAPP PidFiles "/usr/local/samba/var/locks/smbd.pid" "/usr/local/samba/var/locks/nmbd.pid"
hares -modify sambaAPP MonitorProcesses "smbd -D" "nmdb -D"
Create a single virtual IP resource
create a single NIC resource
hares -add appNIC NIC groupw
hares -modify appNIC Enabled 1
hares -modify appNIC Device qfe0
Create the single application IP resource
hares -add appIP IP groupw
hres -modify appIP Enabled 1
hres -modify appIP Device qfe0
hres -modify appIP Address 192.168.0.3
hres -modify appIP NetMask 255.255.255.0
hres -modify appIP IfconfigTwice 1
Create a multi virtual IP resource
Create a multi NIC resource
hares -add appMultiNICA MultiNICA groupw
hares -local appMultiNICA Device
hares -modify appMulitNICA Enabled 1
hares -modify appMulitNICA Device qfe0 192.168.0.3 qfe1 192.168.0.3 -sys sun1 sun2
hares -modify appIPMultiNIC NetMask 255.255.255.0
hares -modify appIPMultiNIC ArpDelay 5
hares -modify appIPMultiNIC IfconfigTwice 1
Create the multi Ip address resource, this will monitor the virtual IP addresses.
hares -add appIPMultiNIC IPMultiNIC groupw
hares -modify appIPMultiNIC Enabled 1
hares -modify appIPMultiNIC Address 192.168.0.3
hares -modify appIPMultiNIC NetMask 255.255.255.0
hares -modify appIPMultiNIC MultiNICResName appMultiNICA
hares -modify appIPMultiNIC IfconfigTwice 1
Clear resource fault
# hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A sun1 RUNNING 0
A sun2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
B groupw sun1 Y N OFFLINE
B groupw sun2 Y N STARTING|PARTIAL
-- RESOURCES ONLINING
-- Group Type Resource System IState
E groupw Mount app02MOUNT sun2 W_ONLINE
# hares -clear app02MOUNT
Flush a group
# hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A sun1 RUNNING 0
A sun2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
B groupw sun1 Y N STOPPING|PARTIAL
B groupw sun2 Y N OFFLINE|FAULTED
-- RESOURCES FAILED
-- Group Type Resource System
C groupw Mount app02MOUNT sun2
-- RESOURCES ONLINING
-- Group Type Resource System IState
E groupw Mount app02MOUNT sun1 W_ONLINE_REVERSE_PROPAGATE
-- RESOURCES OFFLINING
-- Group Type Resource System IState
F groupw DiskGroup appDG sun1 W_OFFLINE_PROPAGATE
# hagrp -flush groupw -sys sun1
##################################################################################################################################################################################
1 VERITAS CLUSTER SOLARIS
1.1 Overview
* Conf files:
Llt conf: /etc/llttab [should NOT need to access this]
Network conf: /etc/gabtab
If has: /sbin/gabconfig -c -n2 , will need to run
/sbin/gabconfig -c -x if only one system comes up and
both systems were down.
Cluster conf: /etc/VRTSvcs/conf/config/main.cf
Has exact details on what the cluster contains.
* Most executables are in: /opt/VRTSvcs/bin or /sbin
1.2 Stato delle licenze:
* /opt/VRTS/bin/vxlicrep
* Per aggiungere licenze:
cd /opt/VRTSvcs/install
./licensevcs
1.3 Amministrazione via web (porta 8181)
* http://10.74.24.122:8181/vcs/index
1.4 Amministrazione con interfaccia grafica:
* hagui
1.5 Utili informazioni sul cluster:
* hastatus -summary
* haclus -display
* hares -list
* hasys -display
* hatype -list
* hagrp -list
* hagrp -display
* Per la conf HW, può essere utile lanciare anche
prtdiag. Su Fujitsu ci sono:
* /opt/FJSVmadm/sbin/hrdconf -l
* /usr/platform/FJSV,GPUSK/sbin/prtdiag
1.6 Verifica LLT - Low Latency Transport
* /etc/llthosts
* /etc/llttab
* Per verificare i links attivi per LLT.
lltstat -n (da eseguire su ogni sistema)
Si può usare anche lltstat -nvv. Mostra i sistemi nel
cluster e gli heartbeat di rete (i links, sono 2 in
genere per sistemi ben configurati)
* Per lo stato delle porte: lltstat -p
* Verifico che il modulo è caricato dal kernel:
modinfo | grep llt
* Se devo fare l'unload del modulo dal kernel
modunload -i llt_id
1.7 Verifica GAB - Group Membership and Atomic Broadcast
* /etc/gabtab (c'è l'heartbeat dei dischi)
* Esempio di gabtab:
/sbin/gabdiskhb -a /dev/dsk/c2t1d2s3 -s 16 -p a
/sbin/gabdiskhb -a /dev/dsk/c2t1d2s3 -s 144 -p h
/sbin/gabconfig -c -n2 (il numero dopo n indica il
quorum, ovvero i sistemi che devono essere attivi per
formare il cluster VCS affinchè parta)
* Lanciare il comando /sbin/gabconfig -a
Ci sono situazioni particolari:
* Output vuoto: GAB non sta girando
* Se appare jeopardy (che significa "pericolo") invece
di solo membership, allora un link è broken
* verifica del GAB sui dischi: mostra l'heartbeat dei dischi.
gabdiskhb -l
* Verifico che il modulo è caricato dal kernel:
modinfo | grep gab
* Se devo fare l'unload del modulo dal kernel
modunload -i gab_id
1.8 Verifica main.cf
* Per verificare la sintassi del file
/etc/VRTSvcs/conf/config/main.cf si usa hacf:
# cd /etc/VRTSvcs/conf/config
# cd /etc/VRTSvcs/conf/config
# ./hacf -verify .
1.9 Configurazione globale dei gruppi gestiti dal cluster
* basta guardare il file
/etc/VRTSvcs/conf/config/main.cf. Si vedono molti
dettagli, i parametri di default per esempio, col
comando seguente:
* /opt/VRTS/bin/hagrp -display
Si verifica la configurazione. Sono incluse le
dipendenze dei pacchetti. Ad esempio:
#Group Attribute System Value
ClusterService Administrators global
ClusterService AutoFailOver global 1
ClusterService AutoRestart global 1
ClusterService AutoStart global 1
ClusterService AutoStartIfPartial global 1
ClusterService AutoStartList global prodsshr1 prodsshr0
ClusterService AutoStartPolicy global Order
ClusterService Evacuate global 1
ClusterService ExtMonApp global
ClusterService ExtMonArgs global
ClusterService FailOverPolicy global Priority
ClusterService FaultPropagation global 1
ClusterService Frozen global 0
ClusterService GroupOwner global
ClusterService IntentOnline global 1
ClusterService Load global 0
ClusterService ManageFaults global ALL
ClusterService ManualOps global 1
ClusterService NumRetries global 0
ClusterService OnlineRetryInterval global 0
ClusterService OnlineRetryLimit global 0
ClusterService Operators global
ClusterService Parallel global 0
ClusterService PreOffline global 0
ClusterService PreOnline global 0
ClusterService PreonlineTimeout global 300
ClusterService Prerequisites global
ClusterService PrintTree global 1
ClusterService Priority global 0
ClusterService Restart global 0
ClusterService SourceFile global ./main.cf
ClusterService SystemList global prodsshr1 1
prodsshr0 2
ClusterService SystemZones global
ClusterService TFrozen global 0
ClusterService TFrozen global 0
ClusterService Tag global
ClusterService TriggerEvent global 1
ClusterService TriggerResStateChange global 0
ClusterService TypeDependencies global
ClusterService UserIntGlobal global 0
ClusterService UserStrGlobal global
ClusterService AutoDisabled prodsshr0 0
ClusterService AutoDisabled prodsshr1 0
ClusterService Enabled prodsshr0 1
ClusterService Enabled prodsshr1 1
ClusterService PreOfflining prodsshr0 0
ClusterService PreOfflining prodsshr1 0
ClusterService PreOnlining prodsshr0 0
ClusterService PreOnlining prodsshr1 0
ClusterService Probed prodsshr0 1
ClusterService Probed prodsshr1 1
ClusterService ProbesPending prodsshr0 0
ClusterService ProbesPending prodsshr1 0
ClusterService State prodsshr0 |OFFLINE|
ClusterService State prodsshr1 |ONLINE|
ClusterService UserIntLocal prodsshr0 0
ClusterService UserIntLocal prodsshr1 0
ClusterService UserIntLocal prodsshr1 0
ClusterService UserStrLocal prodsshr0
ClusterService UserStrLocal prodsshr1
#
beadm_sg Administrators global
beadm_sg AutoFailOver global 1
beadm_sg AutoRestart global 1
beadm_sg AutoStart global 1
beadm_sg AutoStartIfPartial global 1
beadm_sg AutoStartList global prodsshr1 prodsshr0
beadm_sg AutoStartPolicy global Order
beadm_sg Evacuate global 1
beadm_sg ExtMonApp global
beadm_sg ExtMonArgs global
beadm_sg FailOverPolicy global Priority
beadm_sg FaultPropagation global 1
beadm_sg Frozen global 0
beadm_sg GroupOwner global
beadm_sg IntentOnline global 1
beadm_sg Load global 0
beadm_sg ManageFaults global ALL
beadm_sg ManualOps global 1
beadm_sg ManualOps global 1
beadm_sg NumRetries global 0
beadm_sg OnlineRetryInterval global 0
beadm_sg OnlineRetryLimit global 0
beadm_sg Operators global
beadm_sg Parallel global 0
beadm_sg PreOffline global 0
beadm_sg PreOnline global 0
beadm_sg PreonlineTimeout global 300
beadm_sg Prerequisites global
beadm_sg PrintTree global 1
beadm_sg Priority global 0
beadm_sg Restart global 0
beadm_sg SourceFile global ./main.cf
beadm_sg SystemList global prodsshr1 1 prodsshr0 2
beadm_sg SystemZones global
beadm_sg TFrozen global 0
beadm_sg Tag global
beadm_sg TriggerEvent global 1
beadm_sg TriggerResStateChange global 0
beadm_sg TypeDependencies global
beadm_sg UserIntGlobal global 0
beadm_sg UserStrGlobal global
beadm_sg AutoDisabled prodsshr0 0
beadm_sg AutoDisabled prodsshr1 0
beadm_sg Enabled prodsshr0 1
beadm_sg Enabled prodsshr1 1
beadm_sg PreOfflining prodsshr0 0
beadm_sg PreOfflining prodsshr1 0
beadm_sg PreOnlining prodsshr0 0
beadm_sg PreOnlining prodsshr1 0
beadm_sg Probed prodsshr0 1
beadm_sg Probed prodsshr1 1
beadm_sg ProbesPending prodsshr0 0
beadm_sg ProbesPending prodsshr1 0
beadm_sg State prodsshr0 |ONLINE|
beadm_sg State prodsshr1 |OFFLINE|
beadm_sg UserIntLocal prodsshr0 0
beadm_sg UserIntLocal prodsshr1 0
beadm_sg UserStrLocal prodsshr0
beadm_sg UserStrLocal prodsshr1
#
1.10 VERITAS Cluster Basic Administrative Operations
1.10.1 Administering Service Groups
* To start a service group and bring its resources
online
# hagrp -online service_group -sys system
* To start a service group on a system (System 1) and
bring online only the resources already online on
another system (System 2)
# hagrp -online service_group -sys system
-checkpartial other_system
If the service group does not have resources online
on the other system, the service group is brought
online on the original system and the checkpartial
option is ignored. Note that the checkpartial option
is used by the Preonline trigger during failover.
When a service group configured with Preonline =1
fails (system 1) fails over to another system (system
2), the only resources brought online on system 1 are
those that were previously online on system 2 prior
to failover.
* To stop a service group and take its resources
offline
# hagrp -offline service_group -sys system
* To stop a service group only if all resources are
probed on the system
# hagrp -offline [-ifprobed] service_group -sys
system
* To switch a service group from one system to another
# hagrp -switch service_group -to system
The -switch option is valid for failover groups only.
A service group can be switched only if it is fully
or partially online.
* To freeze a service group (disable onlining,
offlining, and failover)
# hagrp -freeze service_group [-persistent]
The option -persistent enables the freeze to be
remembered when the cluster is rebooted.
* To thaw a service group (reenable onlining,
offlining, and failover)
# hagrp -unfreeze service_group [-persistent]
* To enable a service group
# hagrp -enable service_group [-sys system]
A group can be brought online only if it is enabled.
* To disable a service group
# hagrp -disable service_group [-sys system]
A group cannot be brought online or switched if it is
disabled.
* To enable all resources in a service group
# hagrp -enableresources service_group
* To disable all resources in a service group
# hagrp -disableresources service_group
Agents do not monitor group resources if resources
are disabled.
* To clear faulted, non-persistent resources in a
service group
# hagrp -clear [service_group] -sys [system]
Clearing a resource automatically initiates the
online process previously blocked while waiting for
the resource to become clear. - If system is
specified, all faulted, non-persistent resources are
cleared from that system only. - If system is not
specified, the service group is cleared on all
systems in the group s SystemList in which at least
one non-persistent resource has faulted.
1.10.2 Risorse di un gruppo di risorse
* prodsshr0:{root}:/>hagrp -resources beadm_sg
tws_client
beadm_dg
beadm_mip
beadm_mnt
twsdm_mnt
prodsshr_mnic
bea_admin
TWS_vol
beadm_vol
prodsshr0:{root}:/>
1.11 VERITAS: Comandi Amministrazione VCS
1.11.1 Cluster Start/Stop:
* stop VCS on all systems:
# hastop -all
* stop VCS on bar_c and move all groups out:
# hastop [ -local ] -sys bar_c -evacuate
* start VCS on local system:
# hastart
1.11.2 Users:
* add gui root user:
# haconf -makerw
# hauser -add root
# haconf -dump -makero
1.11.3 - Set/update VCS super user password:
* add root user:
# haconf -makerw
# hauser -add root
password:...
# haconf -dump -makero
* change root password:
# haconf -makerw
# hauser -update root
password:...
# haconf -dump -makero
1.11.4 Group:
* group start, stop:
# hagrp -offline groupx -sys foo_c
# hagrp -online groupx -sys foo_c
* switch a group to other system:
# hagrp -switch groupx -to bar_c
* freeze a group:
# hagrp -freeze groupx
* unfreeze a group:
# hagrp -unfreeze groupx
* enable a group:
# hagrp -enable groupx
* disable a group:
# hagrp -disable groupx
* enable resources a group:
# hagrp -enableresources groupx
* disable resources a group:
# hagrp -disableresources groupx
* flush a group:
# hagrp -flush groupx -sys bar_c
1.11.5 Node:
* freeze node:
# hasys -freeze bar_c
* thaw node:
# hasys -unfreeze bar_c
1.11.6 Resources:
* online a resouce:
# hares -online IP_192_168_1_54 -sys bar_c
* offline a resouce:
# hares -offline IP_192_168_1_54 -sys bar_c
* offline a resouce and propagte to children:
# hares -offprop IP_192_168_1_54 -sys bar_c
* probe a resouce:
# hares -probe IP_192_168_1_54 -sys bar_c
* clear faulted resource:
# hares -clear IP_192_168_1_54 -sys bar_c
1.11.7 Agents:
* start agent:
# haagent -start IP -sys bar_c
* stop agent:
# haagent -stop IP -sys bar_c
1.11.8 Reboot a node with evacuation of all service groups:
* (groupy is running on bar_c)
* # hastop -sys bar_c -evacuate
* # init 6
* # hagrp -switch groupy -to bar_c
1.12 Starting Cluster Manager (Java Console) and
Configuration Editor
1. After establishing a user account and setting the
display, type the following commands to start Cluster
Manager and Configuration Editor:
* # hagui
* # hacfed
2. Run /opt/VRTSvcs/bin/hagui.
##############################################################################################################################################################################
Hi All,
I'm newbie in vcs & trying to learn cli before switchover to learn hagui. If you dont mind, could you verify the below commands & their sequences?
DiskGroup ora9idg (
DiskGroup = ora9idg
StartVolumes = 1
StopVolumes = 0
)
IP ora9idg_IP (
Device = qfe3
Address = "192.168.1.2"
NetMask = "255.255.255.0"
)
Netlsnr ora9idb_lsnr (
Owner = oracle
Home = "/oraclesw/product/9.2.0.1.0"
TnsAdmin = "/oraclesw/product/9.2.0.1.0/network/admin"
Listener = ora9idb_lsnr
MonScript = "./bin/Netlsnr/LsnrTest.pl"
)
..
# haconf makerw
# hares add ora9idg DiskGroup ora9idb-Group (assuming ora9idb-Group already exists)
# hares add ora9idg_IP IP ora9idb-Group
# hares add ora9idb_lsnr Netlsnr ora9idb-Group
# hatype add DiskGroup
# hatype add IP
# hatype add Netlsnr
# hares modify ora9idg DiskGroup ora9idg sys vcs-test-phys2
# hares modify ora9idg StartVolumes 1 sys vcs-test-phys2
# hares modify ora9idg StopVolumes 0 sys vcs-test-phys2
# hares modify ora9idg_IP Device add qfe3 192.168.1.2 sys vcs-test-phys2
# hares modify ora9idg_IP NetMask 255.255.255.0
# hares modify ora9idb_lsnr Owner oracle sys vcs-test-phys2 -sys vcs-test-phys2
# hares modify ora9idb_lsnr Home "/oraclesw/product/9.2.0.1.0" -sys vcs-test-phys2
# hares modify ora9idb_lsnr TnsAdmin "/oraclesw/product/9.2.0.1.0/network/admin" -sys vcs-test-phys2
# hares modify ora9idb_lsnr Listener ora9idb_lsnr -sys vcs-test-phys2
# hares modify ora9idb_lsnr MonScript "./bin/Netlsnr/LsnrTest.pl" -sys vcs-test-phys2
# haconf dump makero
After that I can online either a service-group or each of a resource to make sure they are fine before I fails over? In that case, will it automatically copy the new resource entries in main.cf on 2nd node to the 1st node? Im trying to add & bring a new service-group online w/o disturbing a running cluster.
I also see a User s guide doc mentions that after creating a resource type, use haattr command to add its attributes. However, I see hares cli also has a capability to add attributes as well. So, Im wondering which one would you recommend? Any helps are appreciated. Thx.
TIA,
-Chris