Upgrade Panorama in an HA Configuration
Table of Contents
Upgrade Panorama in an HA Configuration
To ensure a seamless failover when you update
the Panorama software in a high availability (HA) configuration,
the active and passive Panorama peers must be running the same Panorama
release with the same Applications database version. The following
example describes how to upgrade an HA pair (active peer is Primary_A
and passive peer is Secondary_B).
If you are upgrading Panorama
and managed devices in FIPS-CC mode to PAN-OS 10.2, you must take
the additional steps of resetting the secure connection status of
the devices in FIPS-CC mode if added to Panorama management while running
a PAN-OS 10.2 release. See Upgrade Panorama and Managed Devices in FIPS-CC Mode for more details
on upgrading Panorama and FIPS-CC devices in FIPS-CC mode.
Before
updating Panorama, refer to the Release Notes for the minimum
content release version required for PAN-OS 10.2.
- Upgrade the Panorama software on the Secondary_B (passive) peer.Perform one of the following tasks on the Secondary_B peer:After the upgrade, this Panorama transitions to a non-functional state because the peers are no longer running the same software release.(Panorama Interconnect plugin only) Synchronize the Panorama Node with the Panorama Controller.Before you begin upgrading a Panorama Node, you must synchronize the Panorama Controller and Panorama Node configuration. This is required to successfully push the common Panorama Controller configuration to your Panorama Node after successful upgrade.(Best Practices) If you are leveraging Strata Logging Service, install the Panorama device certificate on each Panorama HA peer.Panorama automatically switches to using the device certificate for authentication with Strata Logging Service ingestion and query endpoints on upgrade to PAN-OS 10.2.If you do not install the device certificate prior to upgrade to PAN-OS 10.2, Panorama continues to use the existing logging service certificates for authentication.Suspend the Primary_A peer to force a failover.Before you suspend the active-primary peer to force a failover, verify that both HA peers are fully synchronized across all HA checks and all status indicators are green. Resolve any issues highlighted in red and ensure that the status turns green before proceeding with the suspension.On the Primary_A peer:
- In the Operational Commands section (), Suspend local Panorama.Verify that state is suspended (displayed on bottom-right corner of the web interface).The resulting failover should cause the Secondary_B peer to transition to active state.Upgrade the Panorama software on the Primary_A (currently passive) peer.Perform one of the following tasks on the Primary_A peer:After you reboot, the Primary_A peer is initially still in the passive state. Then, if preemption is enabled (default), the Primary_A peer automatically transitions to the active state and the Secondary_B peer reverts to the passive state.If you disabled preemption, manually Restore the Primary Panorama to the Active State.Verify that both peers are now running any newly installed content release versions and the newly installed Panorama release.On the Dashboard of each Panorama peer, check the Panorama Software Version and Application Version and confirm that they are the same on both peers and that the running configuration is synchronized.(Local Log Collectors in a Collector Group only) Upgrade the remaining Log Collectors in the Collector Group.Select and Commit and Push the Panorama managed configuration to all managed devices.After you successfully upgrade Panorama and managed devices to PAN-OS 10.2, a full commit and push of the Panorama managed configuration is required before you can push selective configuration to your managed devices and leverage the improved shared configuration object management for multi-vsys firewalls managed by Panorama.
