Carbon Black EDR cluster servers have one of two roles:

  • Primary – Also known as a head-node and formerly known as Master

  • Minion – Also known as an index(ing) node

Each cluster membership role fulfills specific functions for a single Carbon Black EDR instance. Together, the nodes in a cluster form a functioning Carbon Black EDR server that have specific functionalities and internal components configured to perform their membership roles.

The following table provides a matrix for Carbon Black EDR services and certain components compared to each role:

Service/Component

Standalone

Primary

Minion

cb-nginx

Yes

Yes

Yes

cb-datastore

Yes

Yes

Yes

cb-coreservices

Yes

Yes

Yes

cb-sensorservices

Yes

Yes

Yes

cb-liveresponse

Yes

Yes

No

cb-allianceclient

Yes

Yes

Yes

cb-datagrid

Yes

Yes

Yes

cb-enterprise

Yes

Yes

Yes

- ThreatIntel

Yes

Yes

No

- Statistics

Yes

Yes

Yes

cb-redis

Yes

Yes

Yes

cb-pgsql

Yes

Yes

No

cb-solr

Yes

Yes

Yes

- Process data

(cbevents core shards)

Yes

No

Yes

- Binary Info data

(cbmodules core)

Yes

Yes

Yes*

- Feed data

(cbfeeds core)

Yes

Yes

No

cb-rabbitmq

Yes

Yes

Yes

Binary (modulestore)

Yes

No

Yes

* replicated by Primary

Solr clustering is performed by breaking up a single Solr core into multiple cores called shards. Shards, which are identified by a numerical integer starting at 0, are then evenly distributed to the indexing nodes (minions) for individual management and distributed querying.

For smaller cluster implementations, the primary can also perform the role of an indexing server and fulfill all roles similar to a standalone server. However, for larger organizations that have more than 60,000 sensors or four minions, the cluster must have a dedicated primary node that is not performing minion duties.

When Carbon Black EDR is clustered, internal nodal communication must occur so that the application behaves as a single instance. Most internal components can operate in this distributed capacity by making standard calls to the other components and/or nodes.

The following diagram illustrates inter-nodal cluster communications:

cluster-install-1

For RabbitMQ to function properly as a single system, it must be clustered. RabbitMQ is an application message bus that exchanges data (or messages) between the processes, application, and servers. Creating a RabbitMQ cluster allows Carbon Black EDR to exchange and queue internal (server process and application) and inter-nodal (node-to-node) messaging for proper operation as a single Carbon Black EDR instance.