Veritas Access Installation Guide
- Introducing Veritas Access
- Licensing in Veritas Access
- System requirements
- Important release information
- System requirements
- Linux requirements
- Operating system RPM installation requirements and operating system patching
- Kernel RPMs that are required to be installed with exact predefined RPM versions
- OL kernel RPMs that are required to be installed with exact predefined RPM versions
- Required operating system RPMs for OL 6.8
- Required operating system RPMs for OL 7.3
- Required operating system RPMs for OL 7.4
- Required operating system RPMs for RHEL 6.6
- Required operating system RPMs for RHEL 6.7
- Required operating system RPMs for RHEL 6.8
- Required operating system RPMs for RHEL 7.3
- Required operating system RPMs for RHEL 7.4
- Software requirements for installing Veritas Access in a VMware ESXi environment
- Hardware requirements for installing Veritas Access virtual machines
- Management Server Web browser support
- Supported NetBackup versions
- Supported OpenStack versions
- Supported Oracle versions and host operating systems
- Supported IP version 6 Internet standard protocol
- Linux requirements
- Network and firewall requirements
- Maximum configuration limits
- Preparing to install Veritas Access
- Deploying virtual machines in VMware ESXi for Veritas Access installation
- Installing and configuring a cluster
- Installation overview
- Summary of the installation steps
- Before you install
- Installing the operating system on each node of the cluster
- Installing Veritas Access on the target cluster nodes
- About NIC bonding and NIC exclusion
- About VLAN Tagging
- Replacing an Ethernet interface card
- Configuring I/O fencing
- About configuring Veritas NetBackup
- About enabling kdump during an Veritas Access configuration
- Reconfiguring the Veritas Access cluster name and network
- Configuring a KMS server on the Veritas Access cluster
- Automating Veritas Access installation and configuration using response files
- Displaying and adding nodes to a cluster
- Upgrading Veritas Access and operating system
- Upgrading Veritas Access using a rolling upgrade
- Uninstalling Veritas Access
- Appendix A. Installation reference
- Appendix B. Troubleshooting the LTR upgrade
- Appendix C. Configuring the secure shell for communications
How LLT supports RDMA for faster interconnections between applications
Low Latency Transport (LLT) maintains two channels (RDMA and non-RDMA) for each of the configured RDMA links. Both RDMA and non-RDMA channels can transfer data between the nodes. LLT provides separate Application Program Interfaces (APIs) to the clients (such as CFS and CVM) to use these channels. The RDMA channel is mainly used for data transfer by the client; while the non-RDMA channel is created over the UDP layer, and LLT uses it mainly for sending and receiving heartbeats. Group Membership Services/Atomic Broadcast (GAB) decides cluster membership for the cluster according to the health of the non-RDMA channel. The connections of the RDMA and non-RDMA channels are under separate management, while the connect and disconnect operations for the RDMA channel are triggered based on the status of the non-RDMA channel.
If the non-RDMA channel is up while the RDMA channel is down, the data is transferred over the non-RDMA channel with lower performance until the RDMA channel is fixed. The system logs display a message when the RDMA channel is up or down.
LLT uses the Open Fabrics Enterprise Distribution (OFED) layer and the drivers on the operating system to communicate with the hardware. LLT over RDMA allows applications running on one node to directly access the memory of an application running on another node over an RDMA-enabled network. While over a non-RDMA network, LLT clients have to create intermediate data copies to complete the read or write operation on the application. The RDMA network brings low latency, higher throughput, and minimized CPU host usage, and boosts application performance. LLT and GAB clients CFS and CVM can use LLT over RDMA.