InfoScale™ 9.0 Storage Foundation Cluster File System High Availability Configuration and Upgrade Guide - AIX
- 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
- Upgrading the operating system
- 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
- 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. Support for AIX Live Update
- Appendix B. Installation scripts
- 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 AIX
- Appendix E. High availability agent information
- Appendix F. Sample SFCFSHA cluster setup diagrams for CP server-based I/O fencing
- Appendix G. Changing NFS server major numbers for VxVM volumes
- Appendix H. 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
Support for AIX Live Update (Technology preview)
Veritas InfoScale supports the AIX Live Update feature. Starting with AIX Version 7.2, the AIX operating system provides the AIX Live Update feature that aims to eliminate the workload downtime that is associated with the AIX kernel update operation.
The AIX Live Update feature provides an efficient way to apply the AIX updates, ifixes, service packs, and technology levels without restarting the system. You can trigger the AIX 7.2 Live Kernel Update using the geninstall -k command that updates the OS automatically without any manual intervention or downtime. Though the I/O operations are paused for a few seconds, the critical enterprise workloads remain almost during the Live Update operation. The LKU framework recognizes if InfoScale is installed on the server and takes appropriate action while performing live updates.
Note:
If Live update operation fails due to any AIX specific error, Veritas does not guarantee sanity of machine after LKU operation is completed.
The systems with InfoScale running on it must be LKU compatible
InfoScale is running on a platform where IBM supports LKU with InfoScale
The Technology Level to which you want to upgrade must be supported by InfoScale
LKU should not be executed with the array having 2Mb gatekeeper disk
The Live kernel update operation gets initiated using the geninstall -k command from the original partition where the workload is currently running.
The LKU framework provisions another LPAR on-the-fly with updated kernel extensions. This partition is referred to as a surrogate partition.
The surrogate partition is patched with the updated kernel versions while the workload is still running on the original partition.
Once the surrogate partition is up and running, the workload is moved from the original partition to the surrogate partition using the checkpoint and restart mechanism.
The workload resumes on the surrogate partition in a "chrooted" environment.
When you perform an LKU operation, the geninstall command uses the lvupdate.data configuration file that is available in the /var/adm/ras/liveupdate directory. This configuration file contains the data that is required for the LKU operation. You can use the lvupdate.template file from the /var/adm/ras/liveupdate directory to create the lvupdate.data file. The template file contains the descriptions of all possible fields required for the LKU operation. The following example shows a sample lvupdate.data file:
general:
kext_check = yes
aix_mpio = no
disks:
nhdisk = <hdisk1>
mhdisk = <hdisk2>
hmc:
lpar_id = <lparid>
management_console = <management console ip>
user = <user>
When you create this configuration file, ensure that:
You set the value of aix_mpio field to no to disable the native Multi-Path I/O (MPIO).
Provide hdisk# as values for the nhdisk and mhdisk fields.
nhdisk: The names of disks to be used to make a copy of the original rootvg which will be used to boot the Surrogate.
mhdisk: The names of disks to be used to temporarily mirror rootvg on the Original LPAR.
The size of the specified disks must match the total size of the original rootvg.
These disks should be free. Application or Administrator should not use these disks for any other operation during the Live update operation.
These disks should not be a part of any active or disabled Logical Volume Manager (LVM) volume groups.
These disks should not be a part of any VxVM disk group and should not have any VxVM tag.
Consider the following restrictions for the AIX Live Update operation with InfoScale:
LKU supports only the storage components of InfoScale
LKU is not supported in a CVM environment
LKU is not supported for setups with combined configuration of DMP and third-party driver. For example, native MPIO.
LKU does not support the following InfoScale features:
Clustering for HA or DR
Support for 3rd party multipathing solution
VVR and VFR Replication
Snapshot
FSS
SmartIO
Compression
In-memory statistics handling
Power VC
User initiated VxVM operations during LKU
Read-Write clones (checkpoints)
Cluster Filesystem
Partition Directories
InfoScale product upgrades are not supported through the LKU operation
LKU operation is not supported in high availability configurations for InfoScale
LKU operation is not supported in presence of VxVM swap devices
LKU operation is not supported if any of the administrative tasks like fsadm, fsck is running
LKU operation fails if any changes like volume creation, deletion and so on are made to the VxVM configuration within the LKU start and MCR phase
LKU operation is not supported in presence of vSCSI disk
The integration of InfoScale products and LKU framework is supported only for the Local Mount filesystem
LKU operation fails with the "kernel extensions are not known to be safe for Live Update: vxglm.ext(vxglm.ext64)" error.
A Live Update operation fails if a loaded kernel extension is not marked as safe in the safe list.
If the Group Lock Manager (GLM) is installed on a system, but the VRTSglm package is not marked with the SYS_LUSAFE flag, the LKU operation fails with the "kernel extensions are not known to be safe for Live Update: vxglm.ext(vxglm.ext64)" error.
Workaround:
Mark the VRTSglm package SYS_LUSAFE before initiating the LKU operation.
To add the VRTSglm package to the safe list for the Live Update operation, use the following command:
# lvupdateSafeKE -a /usr/lib/drivers/vxglm.ext\(vxglm.ext64\)
LKU operation fails if the ODM file system is mounted
In the technology preview mode, LKU operation is not supported with VRTSodm.
Workaround:
Unmount the ODM file system using the umount /dev/odm command.
Initiate the LKU operation using the geninstall -k command.