InfoScale™ 9.0 Storage Foundation Cluster File System High Availability Configuration and Upgrade Guide - Solaris
- Section I. Introduction to SFCFSHA
- Introducing Storage Foundation Cluster File System High Availability
- Section II. Configuration of SFCFSHA
- Preparing to configure
- Preparing to configure SFCFSHA 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
- Verifying the CP server configuration
- Configuring SFCFSHA
- Overview of tasks to configure SFCFSHA using the product installer
- Starting the software configuration
- Specifying systems for configuration
- Configuring the cluster name
- Configuring private heartbeat links
- Configuring the virtual IP of the cluster
- Configuring SFCFSHA 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 SFCFSHA configuration
- About the License Audit Tool
- Verifying and updating licenses on the system
- Configuring SFDB
- Configuring SFCFSHA 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
- Performing an automated SFCFSHA 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
- Configuring CP server using response files
- 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
- Manually configuring SFCFSHA 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 SFCFSHA cluster
- Generating the client key and certificates manually on the client nodes
- Configuring server-based fencing on the SFCFSHA 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
- Section III. Upgrade of SFCFSHA
- Planning to upgrade SFCFSHA
- About the upgrade
- Supported upgrade paths
- Transitioning between the InfoScale products
- Considerations for upgrading SFCFSHA to 9.0 on systems configured with an Oracle resource
- Preparing to upgrade SFCFSHA
- Considerations for upgrading REST server
- Using Install Bundles to simultaneously install or upgrade full releases (base, maintenance, rolling patch), and individual patches
- Performing a full upgrade of SFCFSHA using the installer
- Performing a rolling upgrade of SFCFSHA
- Performing a phased upgrade of SFCFSHA
- 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 SFCFSHA stack on the first subcluster
- Preparing the second subcluster
- Activating the first subcluster
- Upgrading the operating system on the second subcluster
- Upgrading the second subcluster
- Completing the phased upgrade
- Performing an automated SFCFSHA upgrade using response files
- Upgrading Volume Replicator
- Upgrading VirtualStore
- Upgrading SFCFSHA using Boot Environment upgrade
- Performing post-upgrade tasks
- Planning to upgrade SFCFSHA
- Section IV. Post-configuration tasks
- Section V. Configuration of disaster recovery environments
- Section VI. Adding and removing nodes
- Adding a node to SFCFSHA 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
- Starting Veritas Volume Manager (VxVM) on the new node
- Configuring cluster processes on the new node
- Setting up the node to run in secure mode
- Starting fencing on the new node
- After adding the new node
- Configuring Cluster Volume Manager (CVM) and Cluster File System (CFS) on the new node
- Configuring the ClusterService group for the new node
- Adding a node using response files
- Configuring server-based fencing on 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
- Sample configuration file for adding a node to the cluster
- Removing a node from SFCFSHA clusters
- About removing a node from a cluster
- Removing a node from a cluster
- Modifying the VCS configuration files on existing nodes
- Modifying the Cluster Volume Manager (CVM) configuration on the existing nodes to remove references to the deleted node
- Removing the node configuration from the CP server
- Removing security credentials from the leaving node
- Updating the Storage Foundation for Databases (SFDB) repository after removing a node
- Sample configuration file for removing a node from the cluster
- Adding a node to SFCFSHA clusters
- Section VII. Configuration and Upgrade reference
- Appendix A. Installation scripts
- Appendix B. Configuration files
- Appendix C. 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 and disabling rsh for Solaris
- Appendix D. High availability agent information
- Appendix E. Sample SFCFSHA cluster setup diagrams for CP server-based I/O fencing
- Appendix F. Reconciling major/minor numbers for NFS shared disks
- Appendix G. 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
Configuring private heartbeat links
After configuring the cluster name, configure the private heartbeat links that LLT uses.
VCS provides the option to use LLT over Ethernet or LLT over UDP (User Datagram Protocol). Arctera recommends that you configure heartbeat links that use LLT over Ethernet 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.
See Using the UDP layer for LLT.
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.
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.
Skip to step 3.
Option 3: 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.
Skip to step 5.
Note:
Option 3 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.
Answer the installer prompts. The following example shows different NICs based on architecture:
For Solaris SPARC:
You must not enter the network interface card that is used for the public network (typically bge0.)
Enter the NIC for the first private heartbeat link on sys1: [b,q,?] bge0 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,?] bge1 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)
For Solaris x64:
You must not enter the network interface card that is used for the public network (typically e1000g0.)
Enter the NIC for the first private heartbeat link on sys1: [b,q,?] e1000g1 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,?] e1000g2 Would you like to configure a third private 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) - 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.
For LLT over UDP, if you want to use the same NICs on other systems, you still must enter unique IP addresses on each NIC for other systems.
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.
- If you chose option 3 , 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 5 for option 3.
- 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.