Carbon Black EDR cluster servers have one of two roles.
-
Primary – Also known as a head-node
-
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 functioningCarbon 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:
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.
