> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/configure-cortex-xdr/data-management/broker-vm/broker-vm-high-availability-cluster.md). # Broker VM High Availability Cluster Learn more about creating Broker VMs in a High Availability Cluster High availability (HA) is a deployment in which at least two Broker VMs are placed in a Broker VM cluster, and their configuration is synchronized to prevent a single point of failure on your network at the hardware and application level. A heartbeat connection between the Broker VM nodes and the Cortex XDR Server ensures seamless failover if a node fails. Setting up a HA cluster provides redundancy and enables data collection continuity. ### Cluster Architecture The Clusters tab on the **`Broker VMs`** page enables you to view your cluster configurations, which display the associated nodes, node statuses, applets configured, and applet statuses. You can add as many clusters as you want in a tenant. Each Cortex XDR cluster can include as many nodes as you need. The cluster operation is fully managed from the tenant, and there is no need to install additional components. There is no need for cluster nodes to communicate with one another on the network. In each cluster, one Broker VM is designated as the Primary cluster node, and the rest of the nodes are designated as standby nodes. The cluster architecture is dependent on the type of applets configured in the cluster. Applets on cluster nodes run either in the active/active mode or in the active/passive mode and exhibit different behaviors as detailed in the table below. ### Applet mode table #### active/active The applets that operate in the active/active mode listen simultaneously on all the nodes in the cluster to achieve High Availability and Load Balancing. Failure of an applet on a particular node causes all traffic to be redistributed to the remaining nodes in the HA cluster. Any applet that is a listener is active/active to ensure the source can send data, and anyone can pick it up based on availability. {% hint style="info" %} #### Note For Load Balancing, you must install a Load Balancer in your network, which will distribute the incoming data between the nodes. {% endhint %} The active/active applets are: * Syslog Collector * Netflow Collector * Windows Event Collector * Local Agent Settings #### active/passive The applets that operate in the active/passive mode retrieve data from the source, and run only on the Primary Node designated in the cluster. The other nodes are synchronized and ready to transition from standby to the active Primary Node should there be a failover. In this mode, all nodes share the same configuration settings, while only one operates at a given time. Any applet that is going outbound and pulling data is active/passive as the applet should only have one active Primary Node at a point in time, and the rest of the nodes should be passive. The active/passive applets are: * Kafka Collector * Network Mapper * CSV Collector * FTP Collector * Files and Folders Collector * DB Collector * Registry Scanner {% hint style="info" %} #### Note The following applets aren't supported when configuring Broker VMs in HA clusters: Cortex Network Scanner, DSPM Fileshare, Registry Scanner, and Transporter. {% endhint %} ### Automatic Failover In each cluster, whenever there's a failure on the Primary node, Cortex XDR automatically switches to one of the standby nodes, initiates the applets on the new Primary node, and continues data collection on that node. Any successful or unsuccessful failover attempt displays an issue in the notification area and is logged in the Management Audit Logs table. The following conditions can trigger a failover for the Primary node: * Connectivity issues between a Primary node and the Cortex XDR server * Application failure, such as failing to start an applet or an applet crashes * Any failure of one of the internal components, such as MariaDB, Redis, RabbitMQ, or Docker engine * Hardware failure, including: * Running out of disk space * CPU usage of more than 95% for more than 10 minutes * Memory usage of more than 95% for more than 10 minutes ### Manual Switchover At any time, you can change the role of the current Primary node in the cluster to another node in the HA cluster, for example, to perform maintenance, by initiating a manual switchover. ### Automatic Upgrades You can configure automatic upgrades within Broker VM HA cluster nodes to update cluster nodes without noticeable downtime or other disruption of the HA cluster service by implementing the rolling upgrade mechanism. An automatic upgrade is performed in the following order: 1. Standby nodes are upgraded one by one. 2. The Primary node is switched over to one of the upgraded standby nodes. 3. The previous Primary node, now a standby node, is upgraded. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/configure-cortex-xdr/data-management/broker-vm/broker-vm-high-availability-cluster.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.