> 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-3.x/cortex-xdr-3.x-documentation/data-management/broker-vm/broker-vm-high-availability-cluster/configure-high-availability-cluster.md). # Configure High Availability Cluster You can create a High Availability (HA) cluster by either creating a new cluster from scratch and then adding applets and Broker VM nodes to the cluster, or by creating a new cluster from an existing standalone Broker VM. There is no limit to the number of clusters and nodes that you can add. There are a number of different ways that you can configure the HA cluster to acheive fault tolerance depending on your system requirements. For example, once a cluster is created from scratch, you can start by configuring the applets that you want the cluster to maintain and then adding the Broker VM nodes that will be managed by the cluster to maintain this configuration, or vise versa. When you create a new cluster from an existing Broker VM, the cluster inherits the applets already configured, which can help save time with your cluster configuration. **Guidelines** Note the following guidelines: * For the cluster to start working and provide services, you need at least one operational node. Until this node is added, the cluster is unavailable. Once a node is added, the cluster begins operating, but it's not considered healthy. * For the cluster to be healthy and maintain HA and redundancy, you need at least two working nodes in the cluster. * For active/active applets that require load balancing, you must install a Load Balancer in your network to distribute the incoming data between the nodes. {% hint style="warning" %} ### Prerequisite Be sure you do the following task before creating a cluster from an existing Broker VM: * If the Broker VM is explicitly specified in some Agent Settings profile, which mean Cortex XDR agents retrieve release upgrades and content updates from this Broker VM, you must change the Broker VM's current designated role. To do this, you need to modify the Agent Settings profile by removing the specific selection of this broker as a Download Source for XDR agents (**Endpoints** → **Policy Management** → **Prevention** → **Profiles** → **Edit Profile** → **Download Source** → **Broker Selection**). After you create the cluster for this broker, you can go back the Agent Settings profile and select the cluster that you created from this broker to be used as a Download Source for XDR agents. {% endhint %} Perform the following procedures in the order listed below.
Task 1. Open the Broker VMs page in Cortex XDR Select **Settings** → **Configurations** → **Data Broker** → **Broker VMs**.
Task 2: Determine how you want to create an HA cluster. * To create a cluster and then add Broker VMs to the cluster, click **Add Cluster**. * To create a new cluster from an existing Broker VM in the **Brokers** tab, right-click a standalone Broker VM, and click **Create a Cluster from this Broker**.

Important

Task 3. Set the applicable parameters Define the following parameters: * **Load Balancer FQDN** Specify the domain name of your Load Balancer FQDN as configured in your local DNS server. The Load Balancer FQDN settings affect the Windows Event Collector and Local Agent Settings applets. When creating a cluster from an existing Broker VM and either a WEC or Local Agent Settings applet are enabled in the Broker VM, the **Load Balancer FQDN** is mandatory to configure, and is automatically populated based on the Broker VM settings. * **Load Balancer Health Check options** Implementing a Load Balancer requires exposing a health check API that is called by the Load Balancer at regular intervals. You can access the health check page by sending an HTTP request to `http[s]://:/health/`. A successful HTTP response of `200 OK` as the status code indicates the Broker VM’s readiness to receive logs. When **Disabled** the Load Balancer Health Check listening port is blocked. When **Enabled** (default), the listening port is opened, and you must define the Port number (default **8088**) and **Protocol** (default **`HTTP`**).

Note

The Broker VM Load Balancer Health Check requires HTTP/1.1 or higher. Legacy HTTP/1.0 is no longer supported. Ensure your external load balancer is configured to use HTTP/1.1 or above when performing health checks.

Important

When the Protocol is set to HTTPS, you may need to perform a few follow-up steps to establish a validated secure SSL connection with the Broker VM.

  • If you're using your own Certificate Authority (CA) to sign the certificates, you'll need to place the CA in the client, such as the Load Balancer, and upload the certificates to the Broker VM.
  • If you're using a Trusted CA Signed SSL Certificate, you'll only need to upload it to the Broker VM.
  • If the SSL Server Certificates of the Broker VM are self-signed certificates, no further steps are necessary.
* **Auto Upgrade options** You can configure automatic upgrades within Broker VM HA cluster nodes to update cluster nodes without noticeable down-time or other disruption of the HA cluster service by implementing the rolling upgrade mechanism. Setting automatic upgrades includes these parameters: * **Auto Upgrade** In a HA cluster configuration, the rolling upgrades process is automatically performed by default whenever a new version of the Broker VM is available. If you want to upgrade the Broker VM nodes manually, clear the **Use Default (Enabled)** checkbox, and set **Auto Upgrade** to **Disabled**. You can manually upgrade the Broker VM nodes individually by right-clicking the Broker VM and selecting **Upgrade Broker version**. * **Days In Week** You can configure the days in the week that the rolling upgrades are performed. By default, the upgrades are configured to run every day. * **Schedule** You can configure whether the rolling upgrades are performed at any time during the day or at a specific time by setting a time range of at least 4 hours. Once configured, the rolling upgrades are only performed when the cluster **STATUS** is **Healthy**. 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.
Task 4. Save your changes Click **Save**. The cluster is now listed in the **Clusters** tab of the **Broker VMs** page, whose output differs depending on how the cluster was created: **New cluster added** When the cluster is added from scratch, the cluster is listed as an empty folder, and you can start to add Broker VM nodes and applets to this cluster. While the cluster doesn’t have any peer nodes, the **STATUS** is **Unavailable**. Cluster added from an existing Broker VM When the cluster is added from an existing Broker VM, the cluster inherits all applet settings from the Broker VM. You can leave the configuration as is or add/remove additional applets as desired. This node automatically becomes the first node (Primary) in the cluster. You can now add other Broker VM nodes to this HA cluster. While the cluster contains only one Broker VM node, the **STATUS** is **Warning**.
Task 5. Add Broker VMs to your cluster as you require to achieve fault tolerance and high availability For the cluster to be healthy and maintain HA and redundancy, you need at least two working nodes in the cluster. * To add Broker VM, see [Add Broker VM to cluster](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/data-management/broker-vm/manage-broker-vm/add-broker-vm-to-cluster.md). * To add applets, see [Add applet to cluster](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/data-management/broker-vm/broker-vm-high-availability-cluster/manage-broker-vm-clusters/add-applet-to-cluster.md).
--- # 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-3.x/cortex-xdr-3.x-documentation/data-management/broker-vm/broker-vm-high-availability-cluster/configure-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.