InfoScale™ 9.0 Storage Foundation and High Availability Configuration and Upgrade Guide - Linux
- Section I. Introduction to SFHA
- Section II. Configuration of SFHA
- Preparing to configure
- Preparing to configure SFHA clusters for data integrity
- About planning to configure I/O fencing
- Setting up the CP server
- Planning your CP server setup
- Installing the CP server using the installer
- Configuring the CP server cluster in secure mode
- Setting up shared storage for the CP server database
- Configuring the CP server using the installer program
- Configuring the CP server manually
- Configuring CP server using response files
- Verifying the CP server configuration
- Configuring SFHA
- Configuring Storage Foundation High Availability using the installer
- Overview of tasks to configure SFHA using the product installer
- Required information for configuring Storage Foundation and High Availability Solutions
- Starting the software configuration
- Specifying systems for configuration
- Configuring the cluster name
- Configuring private heartbeat links
- Configuring the virtual IP of the cluster
- Configuring SFHA in secure mode
- Configuring a secure cluster node by node
- Adding VCS users
- Configuring SMTP email notification
- Configuring SNMP trap notification
- Configuring global clusters
- Completing the SFHA configuration
- About the License Audit Tool
- Verifying and updating licenses on the system
- Configuring SFDB
- Configuring Storage Foundation High Availability using the installer
- Configuring SFHA clusters for data integrity
- Setting up disk-based I/O fencing using installer
- Setting up server-based I/O fencing using installer
- Setting up non-SCSI-3 I/O fencing in virtual environments using installer
- Setting up majority-based I/O fencing using installer
- Enabling or disabling the preferred fencing policy
- Manually configuring SFHA clusters for data integrity
- Setting up disk-based I/O fencing manually
- Setting up server-based I/O fencing manually
- Preparing the CP servers manually for use by the SFHA cluster
- Generating the client key and certificates manually on the client nodes
- Configuring server-based fencing on the SFHA cluster manually
- Configuring CoordPoint agent to monitor coordination points
- Verifying server-based I/O fencing configuration
- Setting up non-SCSI-3 fencing in virtual environments manually
- Setting up majority-based I/O fencing manually
- Performing an automated SFHA configuration using response files
- Performing an automated I/O fencing configuration using response files
- Configuring I/O fencing using response files
- Response file variables to configure disk-based I/O fencing
- Sample response file for configuring disk-based I/O fencing
- Response file variables to configure server-based I/O fencing
- Sample response file for configuring server-based I/O fencing
- Response file variables to configure non-SCSI-3 I/O fencing
- Sample response file for configuring non-SCSI-3 I/O fencing
- Response file variables to configure majority-based I/O fencing
- Sample response file for configuring majority-based I/O fencing
- Section III. Upgrade of SFHA
- Planning to upgrade SFHA
- About the upgrade
- Supported upgrade paths
- Considerations for upgrading SFHA to 9.0 on systems configured with an Oracle resource
- Preparing to upgrade SFHA
- Considerations for upgrading REST server
- Using Install Bundles to simultaneously install or upgrade full releases (base, maintenance, rolling patch), and individual patches
- Upgrading Storage Foundation and High Availability
- Performing a rolling upgrade of SFHA
- Performing a phased upgrade of SFHA
- About phased upgrade
- Performing a phased upgrade using the product installer
- Moving the service groups to the second subcluster
- Upgrading the operating system on the first subcluster
- Upgrading the first subcluster
- Preparing the second subcluster
- Activating the first subcluster
- Upgrading the operating system on the second subcluster
- Upgrading the second subcluster
- Finishing the phased upgrade
- Performing an automated SFHA upgrade using response files
- Upgrading SFHA using YUM
- Performing post-upgrade tasks
- Optional configuration steps
- Re-joining the backup boot disk group into the current disk group
- Reverting to the backup boot disk group after an unsuccessful upgrade
- Recovering VVR if automatic upgrade fails
- Post-upgrade tasks when VCS agents for VVR are configured
- Resetting DAS disk names to include host name in FSS environments
- Upgrading disk layout versions
- Upgrading VxVM disk group versions
- Updating variables
- Setting the default disk group
- About enabling LDAP authentication for clusters that run in secure mode
- Verifying the Storage Foundation and High Availability upgrade
- Planning to upgrade SFHA
- Section IV. Post-installation tasks
- Section V. Adding and removing nodes
- Adding a node to SFHA clusters
- About adding a node to a cluster
- Before adding a node to a cluster
- Adding a node to a cluster using the Veritas InfoScale installer
- Adding the node to a cluster manually
- Adding a node using response files
- Configuring server-based fencing on the new node
- After adding the new node
- Adding nodes to a cluster that is using authentication for SFDB tools
- Updating the Storage Foundation for Databases (SFDB) repository after adding a node
- Removing a node from SFHA clusters
- Removing a node from a SFHA cluster
- Verifying the status of nodes and service groups
- Deleting the departing node from SFHA configuration
- Modifying configuration files on each remaining node
- Removing the node configuration from the CP server
- Removing security credentials from the leaving node
- Unloading LLT and GAB and removing InfoScale Availability or Enterprise on the departing node
- Updating the Storage Foundation for Databases (SFDB) repository after removing a node
- Removing a node from a SFHA cluster
- Adding a node to SFHA clusters
- Section VI. Configuration and upgrade reference
- Appendix A. Installation scripts
- Appendix B. SFHA services and ports
- Appendix C. Configuration files
- Appendix D. Configuring the secure shell or the remote shell for communications
- About configuring secure shell or remote shell communication modes before installing products
- Manually configuring passwordless ssh
- Setting up ssh and rsh connection using the installer -comsetup command
- Setting up ssh and rsh connection using the pwdutil.pl utility
- Restarting the ssh session
- Enabling rsh for Linux
- Appendix E. Sample SFHA cluster setup diagrams for CP server-based I/O fencing
- Appendix F. Configuring LLT over UDP
- Using the UDP layer for LLT
- Manually configuring LLT over UDP using IPv4
- Broadcast address in the /etc/llttab file
- The link command in the /etc/llttab file
- The set-addr command in the /etc/llttab file
- Selecting UDP ports
- Configuring the netmask for LLT
- Configuring the broadcast address for LLT
- Sample configuration: direct-attached links
- Sample configuration: links crossing IP routers
- Using the UDP layer of IPv6 for LLT
- Manually configuring LLT over UDP using IPv6
- About configuring LLT over UDP multiport
- Appendix G. Using LLT over RDMA
- Using LLT over RDMA
- About RDMA over RoCE or InfiniBand networks in a clustering environment
- How LLT supports RDMA capability for faster interconnects between applications
- Using LLT over RDMA: supported use cases
- Configuring LLT over RDMA
- Choosing supported hardware for LLT over RDMA
- Installing RDMA, InfiniBand or Ethernet drivers and utilities
- Configuring RDMA over an Ethernet network
- Configuring RDMA over an InfiniBand network
- Tuning system performance
- Manually configuring LLT over RDMA
- LLT over RDMA sample /etc/llttab
- Verifying LLT configuration
- Troubleshooting LLT over RDMA
- IP addresses associated to the RDMA NICs do not automatically plumb on node restart
- Ping test fails for the IP addresses configured over InfiniBand interfaces
- After a node restart, by default the Mellanox card with Virtual Protocol Interconnect (VPI) gets configured in InfiniBand mode
- The LLT module fails to start
Configuring private heartbeat links
You now configure the private heartbeat links that LLT (Low Latency Transport) uses.
VCS provides the option to use LLT over Ethernet or LLT over UDP (User Datagram Protocol) or LLT over RDMA, or LLT over TCP. Arctera recommends that you configure heartbeat links that use LLT over Ethernet or LLT over RDMA for high performance, unless hardware requirements force you to use LLT over UDP. If you want to configure LLT over UDP, make sure you meet the prerequisites.
You must not configure LLT heartbeat using the links that are part of aggregated links. For example, link1, link2 can be aggregated to create an aggregated link, aggr1. You can use aggr1 as a heartbeat link, but you must not use either link1 or link2 as heartbeat links.
To establish effective communication between IP addresses configured over VLANs created through private links, LLT (Low Latency Transport) provides VLAN configuration support. When configuring an InfoScale cluster, it is necessary to specify the VLAN interface name to enable LLT over VLAN. This configuration ensures seamless communication between the assigned IPs within VLANs.
See Using the UDP layer for LLT.
See Using LLT over RDMA: supported use cases .
The following procedure helps you configure LLT heartbeat links.
To configure private heartbeat links
Choose one of the following options at the installer prompt based on whether you want to configure LLT over Ethernet or LLT over UDP or LLT over TCP or LLT over RDMA.
Option 1: Configure the heartbeat links using LLT over Ethernet (answer installer questions)
Enter the heartbeat link details at the installer prompt to configure LLT over Ethernet.
Skip to step 2.
Option 2: Configure the heartbeat links using LLT over UDP (answer installer questions)
Make sure that each NIC you want to use as heartbeat link has an IP address configured. Enter the heartbeat link details at the installer prompt to configure LLT over UDP. If you had not already configured IP addresses to the NICs, the installer provides you an option to detect the IP address for a given NIC.
Note:
Ensure that the interface that is used by the LLT links does not have any other IP in the same subnet were the LLT links are configured. Otherwise, the cluster may behave unpredictably.
Skip to step 3.
Option 3: Configure the heartbeat links using LLT over TCP (answer installer questions)
Make sure that the NIC you want to use as heartbeat link has an IP address configured. Enter the heartbeat link details at the installer prompt to configure LLT over TCP. If you had not already configured IP addresses to the NICs, the installer provides you an option to detect the IP address for a given NIC.
Skip to step 4.
Option 4: Configure the heartbeat links using LLT over RDMA (answer installer questions)
Make sure that each RDMA enabled NIC (RNIC) you want to use as heartbeat link has an IP address configured. Enter the heartbeat link details at the installer prompt to configure LLT over RDMA. If you had not already configured IP addresses to the RNICs, the installer provides you an option to detect the IP address for a given RNIC.
Skip to step 5.
Option 5: Automatically detect configuration for LLT over Ethernet
Allow the installer to automatically detect the heartbeat link details to configure LLT over Ethernet. The installer tries to detect all connected links between all systems.
Make sure that you activated the NICs for the installer to be able to detect and automatically configure the heartbeat links.
Skip to step 8.
Note:
Option 5 is not available when the configuration is a single node configuration.
- If you chose option 1, enter the network interface card details for the private heartbeat links.
The installer discovers and lists the network interface cards.
You must not enter the network interface card that is used for the public network (typically eth0.)
Enter the NIC for the first private heartbeat link on sys1: [b,q,?] eth1 eth1 has an IP address configured on it. It could be a public NIC on sys1. Are you sure you want to use eth1 for the first private heartbeat link? [y,n,q,b,?] (n) y Would you like to configure a second private heartbeat link? [y,n,q,b,?] (y) Enter the NIC for the second private heartbeat link on sys1: [b,q,?] eth2 eth2 has an IP address configured on it. It could be a public NIC on sys1. Are you sure you want to use eth2 for the second private heartbeat link? [y,n,q,b,?] (n) y Would you like to configure a third private heartbeat link? [y,n,q,b,?](n)
Do you want to configure an additional low priority heartbeat link? [y,n,q,b,?] (n)
- If you chose option 2, enter the NIC details for the private heartbeat links. This step uses examples such as private_NIC1 or private_NIC2 to refer to the available names of the NICs.
Enter the NIC for the first private heartbeat link on sys1: [b,q,?] private_NIC1 Some configured IP addresses have been found on the NIC private_NIC1 in sys1, Do you want to choose one for the first private heartbeat link? [y,n,q,?] (y) Please select one IP address: 1) 192.168.0.1/24 2) 192.168.1.233/24 b) Back to previous menu Please select one IP address: [1-2,b,q,?] (1) Enter the UDP port for the first private heartbeat link on sys1: [b,q,?] (50000) Enter the NIC for the second private heartbeat link on sys1: [b,q,?] private_NIC2 Some configured IP addresses have been found on the NIC private_NIC2 in sys1, Do you want to choose one for the second private heartbeat link? [y,n,q,?] (y) Please select one IP address: 1) 192.168.1.1/24 2) 192.168.2.233/24 b) Back to previous menu Please select one IP address: [1-2,b,q,?] (1) 1 Enter the UDP port for the second private heartbeat link on sys1: [b,q,?] (50001) Would you like to configure a third private heartbeat link? [y,n,q,b,?] (n) Do you want to configure an additional low-priority heartbeat link? [y,n,q,b,?] (n) y Enter the NIC for the low-priority heartbeat link on sys1: [b,q,?] private_NIC0 Some configured IP addresses have been found on the NIC private_NIC0 in sys1, Do you want to choose one for the low-priority heartbeat link? [y,n,q,?] (y) Please select one IP address: 1) 10.200.59.233/22 2) 192.168.3.1/22 b) Back to previous menu Please select one IP address: [1-2,b,q,?] (1) 2 Enter the UDP port for the low-priority heartbeat link on sys1: [b,q,?] (50010) - If you chose option 3, enter the NIC details for the private heartbeat link.
This step uses an example such as private_NIC1 to refer to the available name of the NIC.
Enter the NIC for the private heartbeat link on sys1: [b,q,?] (eth1) private_NIC1 Some configured IP addresses have been found on the NIC private_NIC1 in sys1, Do you want to choose one for the private heartbeat link? [y,n,q,?] (y) y Please select one IP address: 1) 192.168.1.1/24 2) 192.168.2.1/24 b) Back to previous menu Please select one IP address: [1-2,b,q,?] (1) Enter the TCP port for the first private heartbeat link on sys1: [b,q,?] (50000)
- If you chose option 4, choose the interconnect type to configure RDMA.
1) Converged Ethernet (RoCE) 2) InfiniBand b) Back to previous menu Choose the RDMA interconnect type [1-2,b,q,?] (1) 2
The system displays the details such as the required OS files, drivers required for RDMA , and the IP addresses for the NICs.
A sample output of the IP addresses assigned to the RDMA enabled NICs using InfiniBand network. Note that with RoCE, the RDMA NIC values are represented as eth0, eth1, and so on.
System RDMA NIC IP Address ================================================================= sys1 ib0 192.168.0.1 sys1 ib1 192.168.3.1 sys2 ib0 192.168.0.2 sys2 ib1 192.168.3.2
If you chose option 4, enter the NIC details for the private heartbeat links. This step uses RDMA over an InfiniBand network. With RoCE as the interconnect type, RDMA NIC is represented as Ethernet (eth).
Enter the NIC for the first private heartbeat link (RDMA) on sys1: [b,q,?] <ib0> Do you want to use address 192.168.0.1 for the first private heartbeat link on sys1: [y,n,q,b,?] (y) Enter the port for the first private heartbeat link (RDMA) on sys1: [b,q,?] (50000) ? Would you like to configure a second private heartbeat link? [y,n,q,b,?] (y) Enter the NIC for the second private heartbeat link (RDMA) on sys1: [b,q,?] (ib1) Do you want to use the address 192.168.3.1 for the second private heartbeat link on sys1: [y,n,q,b,?] (y) Enter the port for the second private heartbeat link (RDMA) on sys1: [b,q,?] (50001) Do you want to configure an additional low-priority heartbeat link? [y,n,q,b,?] (n)
- Choose whether to use the same NIC details to configure private heartbeat links on other systems.
Are you using the same NICs for private heartbeat links on all systems? [y,n,q,b,?] (y)
If you want to use the NIC details that you entered for sys1, make sure the same NICs are available on each system. Then, enter y at the prompt.
If the NIC device names are different on some of the systems, enter n. Provide the NIC details for each system as the program prompts.
For LLT over UDP and LLT over RDMA, if you want to use the same NICs on other systems, you must enter unique IP addresses on each NIC for other systems.
- If you chose option 5, the installer detects NICs on each system and network links, and sets link priority.
If the installer fails to detect heartbeat links or fails to find any high-priority links, then choose option 1 or option 2 to manually configure the heartbeat links.
See step 2 for option 1, or step 3 for option 2, or step 4 for option 3, or step5 for option 4
- Enter a unique cluster ID:
Enter a unique cluster ID number between 0-65535: [b,q,?] (60842)
The cluster cannot be configured if the cluster ID 60842 is in use by another cluster. Installer performs a check to determine if the cluster ID is duplicate. The check takes less than a minute to complete.
Would you like to check if the cluster ID is in use by another cluster? [y,n,q] (y)
- Verify and confirm the information that the installer summarizes.