This TechNote will examine the contents of a basic VERITAS Cluster Server (VCS) configuration file - /etc/VRTSvcs/conf/config/main.cf.
The basic unit of a VERITAS Cluster Server configuration is the resource. VERITAS Cluster Server is comprised of the engine (the "had" and "hashadow" daemons) and agents. Agents are responsible for keeping track of Cluster Server resources of a well-defined type. The resource types are defined, by default, in the /etc/VRTSvcs/conf/config/types.cf file.
For example, the mount agent is responsible for mounting, unmounting, and monitoring the status of VCS controlled file systems. It is necessary for the mount agent, therefore, to be aware of at least the device to mount ("BlockDevice" attribute) and the mount point (the aptly named "MountPoint" attribute). For more information on the agents bundled with VCS and their attributes, see the VERITAS Cluster Server Bundled Agent Guide.
Resources will also have dependencies. A resource dependency exists when one requires another be online or offline before it can be online or offline. By way of example, a mount resource might depend on a volume resource (the volume agent monitors a VERITAS Volume Manager volume).
A collection of resources and their dependencies are a service group. VERITAS Cluster Server failover occurs at the service group level. This configuration is stored in the file /etc/VRTSvcs/conf/config/main.cf. In the following example, the actual file contents appear in bold with an explanation of each entry purpose underneath.
# more main.cf
include "types.cf"
"include" statements tell VCS which files contain the definitions of resources. The file "types.cf" contains the definitions for the standard VCS bundled agents. Other VERITAS agents, such as the Enterprise Agent for Oracle, will be bundled with their own definition file (OracleTypes.cf, in the Oracle case), requiring a separate "include" statement.
cluster vcs_01 (
)
The name of the cluster of which this node is a part.
system camcs12 (
)
system camcs9 (
)
The "system" statements tell the cluster nodes which other systems are members of the same cluster. Note that these are VCS-defined system names, which do not necessarily have to be the same as the systems host name defined in /etc/hosts. These names are defined in /etc/llthosts.
group MyServiceGroup (
The "group" keyword indicates that a service group configuration follows. The first portion of the service group contains attributes which apply at the service group level, such as SystemList (see following) or Parallel.
SystemList = { camcs9 = 0, camcs12 = 1, camcs13 = 2 }
The "SystemList" attribute tells VCS which nodes of this cluster can activate this service group, and in what order VCS should attempt to fail over. Assuming the service group was online on camcs9, on failover VCS will first attempt to bring the group up on camcs12. If the online should fail on camcs12, it will then try to bring it up on camcs13.
AutoStartList = { camcs9 }
The "AutoStartList" attribute defines which nodes will automatically bring the service group online at VCS startup. If the AutoStartList contains more than one system, each system will first check to see if the service is already online on another node in the cluster before attempting to bring the service group online locally.
)
The above 'close-paren' ends the service group attribute section. At this point, the resources which make up the service group are now listed, along with their attributes.
Application MyApp(
A Resource begins with the Type of resource (Application), the user defined resource name ("MyApp"), and an open-paren. Resource attributes will be read in until a close-paren is encountered. Each resource has a unique set of attributes - for more information on each of the attributes, see the VCS Bundled Agent Guide.
StartProgram = "/apps/MyApp/online"
StopProgram = "/apps/MyApp/offline"
CleanProgram = "/apps/MyApp/clean"
MonitorProgram = "/apps/MyApp/monitor"
)
Close-paren, indicating the application resource configuration is finished.
Other resources will follow, filling out the rest of the service group:
DiskGroup MyDG (
DiskGroup = "mydg"
)
Mount MyMount (
MountPoint = "/mount"
BlockDevice = "/dev/vx/dsk/myvol"
)
Volume MyVol (
DiskGroup = "mydg"
Volume = "myvol"
)
The final portion of the service group configuration is the resource dependency tree. Dependencies are specified in the format "resourceX requires resourceY" - resourceY is the pre-requisite for resourceX. A resource will not be brought online until its prerequisite resources are online. Additionally, a resource will not be brought offline if there are others that require it still online.
MyApp requires MyMount
MyMount requires MyVol
MyVol requires MyDG
In this case, the DiskGroup resource MyDG will be brought online first, followed by the volume resource MyVol, followed by MyMount, and finally MyApp. The order will be reversed on offline - MyApp will be brought offline first (as there are no resources which require it), followed by MyMount, MyVol, and finally MyDG.
