 | ||
| About Low Latency Transport (LLT) | ||
|---|---|---|
| Prev | About inter-system cluster communications | Next |
The Low Latency Transport protocol is used for all cluster communications as a high-performance, low-latency replacement for the IP stack.
LLT has the following two major functions:
Traffic distribution
LLT provides the communications backbone for GAB. LLT distributes (load balances) inter-system communication across all configured network links. This distribution ensures all cluster communications are evenly distributed across all network links for performance and fault resilience. If a link fails, traffic is redirected to the remaining links. A maximum of eight network links are supported.
Heartbeat
LLT is responsible for sending and receiving heartbeat traffic over each configured network link. The heartbeat traffic is point to point unicast. LLT uses ethernet broadcast to learn the address of the nodes in the cluster. All other cluster communications, including all status and configuration traffic is point to point unicast. The heartbeat is used by the Group Membership Services to determine cluster membership.
The heartbeat signal is defined as follows:
LLT on each system in the cluster sends heartbeat packets out on all configured LLT interfaces every half second.
LLT on each system tracks the heartbeat status from each peer on each configured LLT interface.
LLT on each system forwards the heartbeat status of each system in the cluster to the local Group Membership Services function of GAB.
GAB receives the status of heartbeat from all cluster systems from LLT and makes membership determination based on this information.
Figure: Heartbeat in the cluster shows heartbeat in the cluster.
LLT can be configured to designate specific cluster interconnect links as either high priority or low priority. High priority links are used for cluster communications to GAB as well as heartbeat signals. Low priority links, during normal operation, are used for heartbeat and link state maintenance only, and the frequency of heartbeats is reduced to 50% of normal to reduce network overhead.
If there is a failure of all configured high priority links, LLT will switch all cluster communications traffic to the first available low priority link. Communication traffic will revert back to the high priority links as soon as they become available.
While not required, best practice recommends to configure at least one low priority link, and to configure two high priority links on dedicated cluster interconnects to provide redundancy in the communications path. Low priority links are typically configured on the public or administrative network.
If you use different media speed for the private NICs, Symantec recommends that you configure the NICs with lesser speed as low-priority links to enhance LLT performance. With this setting, LLT does active-passive load balancing across the private links. At the time of configuration and failover, LLT automatically chooses the link with high-priority as the active link and uses the low-priority links only when a high-priority link fails.
LLT sends packets on all the configured links in weighted round-robin manner. LLT uses the linkburst parameter which represents the number of back-to-back packets that LLT sends on a link before the next link is chosen. In addition to the default weighted round-robin based load balancing, LLT also provides destination-based load balancing. LLT implements destination-based load balancing where the LLT link is chosen based on the destination node id and the port. With destination-based load balancing, LLT sends all the packets of a particular destination on a link. However, a potential problem with the destination-based load balancing approach is that LLT may not fully utilize the available links if the ports have dissimilar traffic. Symantec recommends destination-based load balancing when the setup has more than two cluster nodes and more active LLT ports. You must manually configure destination-based load balancing for your cluster to set up the port to LLT link mapping.
See Configuring destination-based load balancing for LLT.
LLT on startup sends broadcast packets with LLT node id and cluster id information onto the LAN to discover any node in the network that has same node id and cluster id pair. Each node in the network replies to this broadcast message with its cluster id, node id, and node name.
LLT on the original node does not start and gives appropriate error in the following cases:
LLT on any other node in the same network is running with the same node id and cluster id pair that it owns.
LLT on the original node receives response from a node that does not have a node name entry in the /etc/llthosts file.
