Print Download PDF Send Feedback

Previous

Next

Upgrading ClusterXL Deployments

In This Section:

Planning a Cluster Upgrade

Minimal Effort Upgrade on a ClusterXL Cluster

Zero Downtime Upgrade on a Cluster

ClusterXL Optimal Service Upgrade

Connectivity Upgrade

Planning a Cluster Upgrade

Before you upgrade a ClusterXL, consider the available upgrade options.

Effort and time efficient upgrades with some loss of connectivity

Upgrades that guarantee minimal connectivity loss

An administrator can customize the Firewall, VPN, CoreXL, and SecureXL configuration on cluster members by configuring the relevant kernel parameters in special configuration files - $FWDIR/boot/modules/fwkern.conf, $FWDIR/boot/modules/vpnkern.conf, $PPKDIR/boot/modules/simkern.conf, $FWDIR/conf/fwaffinity.conf. For examples, see sk25977. During the upgrade, all customized configuration files are overwritten with the default configuration files.

If you upgrade the cluster through CLI, you can preserve the customized configuration. To do that, you must back up the configuration files before the upgrade and restore them manually immediately after upgrade, before the cluster members are rebooted. See sk42498 for details.

If you upgrade the cluster gateways through Portal, they are rebooted automatically immediately after the upgrade, and the customized configuration is lost.

Note - If configuration customizations are lost during the upgrade, different issues can occur in the upgraded cluster. Cluster members can stop detecting each other, cluster members can move to undesired state, and traffic can be dropped.

Ready State During Cluster Upgrade/Rollback Operations

When cluster members of different versions are on the same network, cluster members of the new (upgraded) version remain in state Ready, and cluster members of the previous version remain in state Active Attention. Cluster members in the state Ready do not process traffic for the cluster Virtual IP address and do not synchronize with other cluster members.

To prevent cluster members from being in Ready state:

Upgrading 32/64-bit Cluster Members

High Availability cluster deployments are supported on 32-bit and 64-bit kernel operating systems. Make sure that all cluster members are running the same 32-bit or the same 64-bit operating system. If the kernel versions are different among the cluster members, those that are running the 64-bit version will stay in the state Ready and will not synchronize with the other cluster members or process any traffic for the cluster Virtual IP address.

Upgrading Third-Party and OPSEC Certified Cluster Products