Panorama HA Prerequisites
To configure Panorama in HA, you require a pair of identical
Panorama servers with the following requirements on each:
The same form factor—The peers must be the same
model: both M-700 appliances, both M-600 appliances, both M-500
appliances, both M-300 appliances, both M-200 appliances, or both
deployed on the same
supported hypervisor for Panorama
virtual appliances. For example, to successfully configure HA for
a Panorama virtual appliance deployed on AWS in Panorama mode, the
HA peer must also be deployed on AWS and be in Panorama mode.
The same form factor—The peers must be the same model: both M-700
appliances, both M-600 appliances, both M-500 appliances, both M-300 appliances,
or both M-200 appliances.
For Panorama Virtual Appliances, the hypervisor requirement depends on the PAN-OS
version:
(PAN-OS 12.2.2 and earlier releases) — You can deploy both peers
on the same or different supported hypervisors. For example, to
configure HA for a Panorama Virtual Appliance deployed on AWS, the HA
peer must also be deployed on AWS.
(PAN-OS 12.2.2 and later releases) — You can deploy both peers
on the same or different supported hypervisors. For example, a primary
peer running on VMware ESXi can form an HA pair with a secondary peer
running on Microsoft Azure.
The same mode—The peers must be in the same
Panorama mode: both running in
Panorama mode, or Management Only mode.
Panorama appliances in Log Collector
mode do not support HA.
The same Panorama OS version—Must run the same Panorama
version to synchronize configuration information and maintain parity
for a seamless failover.
The same set of licenses—Must have the same firewall
management capacity license.
(Panorama virtual appliance only) FIPCS-CC Mode—FIPS-CC
mode must be enabled or disabled on both Panorama HA peers.
(Panorama virtual appliance only) Virtual Appliance Resources—Must have the same
number of vCPU cores and memory allocated to successfully synchronize
configuration information.
(PAN-OS 12.2.2 and later releases) For cross-hypervisor HA
deployments, provision both peers with the same vCPU count and memory size.
For example, configure both instances with 8 vCPUs and 32 GB of memory. Two
instances provisioned with the same memory size might report slightly
different values. For example, one might report 32,700 MB and the other
32,768 MB. This happens because each hypervisor reserves a small amount of
memory for its own overhead. Panorama accounts for these minor reporting
differences automatically. If the vCPU count does not match, or if the
memory difference is significant, the peer enters a suspended state and HA
does not form.
(Panorama virtual appliance only) Unique serial
number—Must have unique serial numbers; if the serial number
is the same for both Panorama instances, they will be in suspended
mode until you resolve the issue.
(Panorama mode or mixed mode only) While it is recommended to match the number of
logging disk and the logging disk capacities between the Panorama HA peers, having a
different number logging disks or different logging disk capacities between the
Panorama HA peers does not impact configuration synchronization or HA failover
.
Panorama HA Organization
The Panorama servers in the HA configuration are peers and you
can use either (active or passive) to centrally manage the firewalls,
Log Collectors, and WildFire appliances and appliance clusters,
with a few exceptions (see
Synchronization
Between Panorama HA Peers). The HA peers use the management
(MGT) interface to synchronize the configuration elements pushed
to the managed firewalls, Log Collectors, and WildFire appliances
and appliance clusters to maintain state information. Typically,
Panorama HA peers are geographically located in different sites,
so you need to make sure that the MGT interface IP address assigned
to each peer is routable through your network. HA connectivity uses
TCP port 28 with encryption enabled. If encryption is not enabled,
ports 28769 and 28260 are used for HA connectivity and to synchronize
configuration between the HA peers. We recommend less than 500ms
latency between the peers. To determine the latency, use Ping during
a period of normal traffic.
(PAN-OS 12.2.2 and later releases) For
cross-hypervisor HA deployments, the HA peers communicate over a routable WAN rather
than an L2/L3 adjacent network as in traditional same-hypervisor deployments. Configure
mutually reachable IP addresses on the management interfaces of both Panorama
instances:
- Public cloud instances (AWS, Azure, GCP): The cloud provider assigns both a private
(internal) IP and a public IP to each instance. Configure the public IP address of
the instance in the management interface settings (Panorama > Setup > Interfaces > Management >
Public IP Address). Use this public IP address as the Peer HA IP Address
in the HA configuration on the other peer.
- Private cloud instances (ESXi, Nutanix): Ensure the management interface IP is
routable from the peer's environment. You do not need to make routing configuration
changes on Panorama itself—the intermediate gateway (such as a corporate firewall or
router) must permit IP reachability between the two management IPs.
The 500ms latency recommendation applies to
cross-hypervisor deployments as well. For cross-hypervisor deployments, use the
Recommended HA timer preset to absorb latency jitter across
cloud environments. See
HA Heartbeat Polling and Hello
Messages.
Palo Alto Networks recommends you add
at least three Log Collectors to your Collector Groups to avoid
the Collector Group becoming inoperable if one Log Collector becomes
inaccessible. See
Changes to Default Behavior for
Collector Groups for more information.
