Communication among VCS components
When you install VCS, user-space components and kernel-space components are installed on a system. The VCS engine, also known as the high availability daemon (HAD) exists in the user space. The HA daemon contains the decision logic for the cluster and maintains a view of the cluster. The VCS engine on each system in the cluster maintains a synchronized view of the cluster. For example, when you take a resource offline, or bring a system from the cluster online, VCS on each system updates the view of the cluster.
The kernel-space components consist of the Group Atomic and Broadcast (GAB) and Low Latency Transport (LLT) modules. Each system that has the VCS engine installed on it communicates through GAB and LLT. GAB maintains the cluster membership and cluster communications. LLT maintains the traffic on the network and communicates heartbeat signal information of each system to GAB.
About the VCS startup sequence
The start and stop variables for the Asynchronous Monitoring Framework (AMF), LLT, GAB, I/O fencing (VxFEN), and VCS engine modules define the default behavior of these modules during a system restart or a system shutdown. For a clean VCS startup or shutdown, you must either enable or disable the startup and shutdown modes for all these modules.
VCS startup depends on the kernel-space modules and other user-space modules starting in a specific order. The VCS startup sequence is as follows:
- LLT
- GAB
- I/O fencing
- AMF
- VCS
For more information on setting the start and stop environment variables, VCS modules, and starting and stopping VCS, see:
In a single-node cluster, you can disable the start and stop environment variables for LLT, GAB, and VxFEN, if you have not configured these kernel modules. If you disable LLT and GAB, set the ONENODE variable to Yes in the/etc/default/vcs file.
The following topics provide information on troubleshooting startup issues:
VCS documentation for other releases and platforms can be found on the SORT website.
