Veritas Access 7.3 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.6
- Required operating system RPMs for OL 6.7
- Required operating system RPMs for OL 6.8
- Required operating system RPMs for RHEL 6.6
- Required operating system RPMs for RHEL 6.7
- Required operating system RPMs for RHEL 6.8
- 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
- About types of Veritas Access patches
- Downloading Veritas Access 7.3 release
- Upgrading to Veritas Access 7.3 release
- Displaying the current version
- Displaying upgrade history of Veritas Access
- Downloading a Veritas Access patch release
- Displaying all Veritas Access releases that are available in the repository
- Installing Veritas Access patches
- Automatically execute your customized script before or after upgrade
- Upgrading Veritas Access using a rolling upgrade
- Uninstalling Veritas Access
- Appendix A. Installation reference
- Appendix B. Configuring the secure shell for communications
About types of Veritas Access patches
Depending on whether a patch requires a restart of the cluster or not, the Veritas Access patches can be divided into two types:
Patches that do not require a cluster restart.
These patches upgrade the Veritas Access packages and non-critical packages using the direct upgrade method. The direct upgrade method does not bring down any nodes or resources while the patch is applied. The upgrade applies the patch on all the nodes in parallel. The cluster remains in a RUNNING state and clients are served while the upgrade process is running.
Patches that require a cluster restart.
These patches upgrade the critical packages that require a one-time cluster restart using the rolling upgrade method. You can use the rolling upgrade method to install the Veritas Access releases in a guided manner on all the clusters nodes. The rolling upgrade minimizes downtime for highly available clusters by limiting the upgrade time to the amount of time that it takes to perform a service group failover
Note:
Updating these patches on a single node cluster causes service downtime, because both the kernel RPMs and VCS agent RPMs are upgraded in a single phase.
The rolling upgrade has two main phases. The installer upgrades kernel RPMs in phase 1 and VCS agent RPMs in phase 2. The upgrade process divides the cluster into two subclusters, called the first subcluster and the second subcluster. First, the upgrade is performed on the first subcluster. The upgrade process stops all services and resources on the nodes of the first subcluster. All services (including the VIP groups) fail over to the second subcluster. During the failover process, the clients that are connected to the VIP groups of the first subcluster nodes are intermittently interrupted. For those clients that do not time out, the service is resumed after the VIP groups become online on one of the nodes of the second subcluster.
While the upgrade process is running on the nodes of the first subcluster, the nodes of the second subcluster nodes continue to serve the clients. After the first subcluster node has been upgraded, it restarts the services and resources on first stage nodes. Immediately after the first subcluster comes up, the upgrade process stops the services and resources on the remaining nodes. All services and resources are online and serve clients. Meanwhile, the rolling upgrade starts the upgrade process on the remaining nodes. After the upgrade is complete on the remaining nodes, the cluster recovers and services are balanced across the cluster.