Cluster replacement upgrade procedure

Secure Firewall 7.6.4-69 or later 7.6.x versions, and 10.0.0 or later versions, use a new cluster interface addressing convention. Existing clusters retain their legacy convention after an upgrade, but newly deployed members use the new convention and cannot join.

To add capacity, build a replacement cluster and migrate traffic:

Procedure

Step 1

Keep the existing cluster serving traffic.

Step 2

Deploy the replacement cluster at its final size, using a new CCL subnet. Use Secure Firewall version 7.6.4-69 or later 7.6.x versions, or version 10.0.0 or later. Keep all members on the same build, assign cluster-node-id tags from 1 to N, and enable metadata tags.

Step 3

Confirm the new cluster is healthy. Register it with the Management Center, apply the equivalent policy, and deploy.

Step 4

Edit the target group attributes before registering the replacement nodes. Under Target configuration, set Target failover strategy to No rebalance. Under Target deregistration management, set Deregistration delay (draining interval) to a value longer than your longest-lived flow. The maximum allowed value is 3600 seconds.

Note

  • Set target failover first: Target groups are created with Rebalance existing flows. With rebalancing enabled, deregistering the old nodes moves their established flows to the remaining healthy targets in the replacement cluster. That cluster has no state for those flows and drops them. No rebalance allows existing flows to drain.

  • Deregistration delay is a timer: The load balancer completes deregistration when the draining interval expires, regardless of whether connections remain. A connection count of zero does not extend the interval.

Step 5

Register the new nodes with the existing target group, then deregister the old nodes. New traffic flows use the healthy replacement nodes. Existing flows on the old nodes drain.

Step 6

After the old cluster’s connection count reaches zero, remove its targets and instances, then unregister it from the Management Center.

Note

  • Check connections: Use the show conn count command on the old devices. The load balancer reports flows for the entire target group and cannot show which cluster owns each flow while both are registered.

  • Rollback: Keep the old cluster until the replacement is validated. If needed, restore traffic to the old cluster before deleting it.

  • Record the build: Note the replacement cluster’s release and build to select compatible versions for future nodes.

  • Observe the version boundary: Use version 7.6.4-69 or later 7.6.x versions, or version 10.0.0 or later versions. Older 7.6.4 builds use the legacy addressing scheme.

  • Plan for the overlap: Both clusters run concurrently. Confirm that Smart Licensing entitlements and vCPU quota cover the combined node count.