top of page
Search
Writer's pictureHiep Nguyen

New Cortex XSOAR 6.1 - Architecture guide

Now, it seems to be a lot of components, right? Let’s explain the functionality of each component and internal communication from top to bottom of the diagram:


User: will access XSOAR via Load Balancer IP address instead of directly to each XSOAR application server. That will be the way XSOAR servers deliver high availability for end user side, just as simple as Front end 2-3 tiers web application.


Load Balancer: can be any L4 – L7 LB with health check and some basic to advance load balancing methods. In my lab, I use the native LB of the cloud provider that I used to host the lab.


XSOAR App: in this HA design, the application and database will be separated. XSOAR App can be 2 or 3 servers behind a Load balancer.

The most important part is where XSOAR data (e.g license, settings, playbooks…) can be shared amongst the XSOAR apps? The answer is via NFS mounted folder. And here it is.


NFS: technically, NFS can be installed on one XSOAR app and exported (shared) to another XSOAR app to consume. But it is recommended to install a standalone NFS with regular backup to host the content of “/var/lib/demisto” folder for all XSOAR app.

Then XSOAR app servers will need to mount it’s /var/lib/demisto folder to the NFS so that they can share the content. If XSOAR admin create a playbook on XSOAR app 1, it will be consumed by XSOAR app 2 as well, without any human intervention.


XSOAR host: this one is designed specifically for multi-tenancy deployment where XSOAR host will be the server putting close to end customer environment.

XSOAR host will have multiple tenants configured and most of the workload will be running on the host, of course. That’s why in Palo Alto Networks document, they recommend the sizing should be number of tenants multiplies with recommended XSOAR CPU & memory (e.g 3 tenants x 16 CPU & 32GB RAM = 48 CPU & 96GB RAM)


XSOAR host connects to XSOAR app by TCP port 443, direction in the above diagram.


Elastic Search: ES is the main database (which stores incident data, context data…) and is much better in performance comparing with the legacy BoltDB. ES support clustering natively with minimum of 2 nodes (recommended 3 for highest resiliency).


You can read more about ES clustering on ElasticSearch website, but they key things to remember is that one cluster contains Master and Data node. And in this deployment, make sure all nodes are master-eligible and data node, that’s it.

XSOAR app and host will read/write to ElasticSearch via API (HTTP port 9200 by default).


So, ready to install - start with NFS?

183 views0 comments

Recent Posts

See All

Comments


bottom of page