IBM Tivoli Storage Manager in a Clustered Environment

Chapter 16. The VERITAS Cluster Server for AIX 709

򐂰 Low latency transport (LLT): Low latency transport operates in kernel

space, supporting communication between servers in a cluster, and handles

heartbeat communication. LLT runs directly on top of the DLPI layer in UNIX.

LLT load balances cluster communication over the private network links.

A critical question related to cluster communication is, “What happens when

communication is lost between cluster servers?” VCS uses heartbeats to

determine the health of its peers and requires a minimum of two heartbeat paths,

either private, public, or disk based. With only a single heartbeat path, VCS is

unable to determine the difference between a network failure and a system

failure. The process of handling loss of communication on a single network as

opposed to a multiple network is called

jeopardy. So, if there is a failure on all

communication channels, the action taken depends on what channels have been

lost and the state of the channels prior to the failure. Essentially, VCS will take

action such that only one node has a service group at any one time; in some

instances, disabling failover to avoid possible corruption of data. A full discussion

is included in “Network partitions and split-brain” in Chapter 13, “Troubleshooting

and Recovery”, in the VERITAS Cluster Server User Guide.

16.6 Cluster installation and setup

Installation of VCS on AIX is via installp or SMIT. It should be noted, however,

that if installp is used, then LLT, GAB, and the main.cf file must be configured

manually. Alternatively, the installvcs script can be used to handle the installation

of the required software and initial cluster configuration.

After the VCS software has been installed, configuration is typically done via the

VCS GUI interface. The first step is to carry out careful planning of the desired

high availability environment. There are no specific tools in VCS to help with this

process. Once this has been done, service groups are created and resources are

added to them, including resource dependencies. Resources are chosen from

the bundled agents and enterprise agents or, if there are no existing agents for a

particular resource, a custom agent can be built. After the service groups have

been defined, the cluster definition is automatically synchronized to all cluster

servers.

Under VCS, the cluster configuration is stored in ASCII files. The two main files

are the

main.cf and types.cf:

򐂰 main.cf: Defines the entire cluster

򐂰 types.cf: Defines the resources

These files are user readable and can be edited in a text editor. A new cluster

can be created based on these files as templates.