## Cluster <a id="technical-concepts-cluster"></a>
+This documentation refers to technical roles between cluster
+endpoints.
+
+- The `server` or `parent` role accepts incoming connection attempts and handles requests
+- The `client` role actively connects to remote endpoints receiving config/commands, requesting certificates, etc.
+
+A client role is not necessarily bound to the Icinga agent.
+It may also be a satellite which actively connects to the
+master.
+
### Communication <a id="technical-concepts-cluster-communication"></a>
Icinga 2 uses its own certificate authority (CA) by default. The
Icinga 2 v2.8 introduces the possibility to request certificates
from indirectly connected nodes. This is required for multi level
-cluster environments with masters, satellites and clients.
+cluster environments with masters, satellites and agents.
CSR Signing in general starts with the master setup. This step
ensures that the master is in a working CSR signing state with:
If the child node was not the certificate request origin, it only updates
the cached request for the child node and send another cluster message
-down to its child node (e.g. from a satellite to a client).
+down to its child node (e.g. from a satellite to an agent).
If no ticket was specified, the signing master waits until the
to manually copy the master's public CA key into `/var/lib/icinga2/certs/ca.crt`
on the client before starting Icinga 2.
+> **Note**
+>
+> The `client` in this case can be either a satellite or an agent.
+
The parent node needs to actively connect to the child node.
Once this connections succeeds, the child node will actively
request a signed certificate.
Global zones have a special trust relationship: They are synced to all child zones, be it
-a satellite zone or client zone. Since checkable objects such as a Host or a Service object
+a satellite zone or agent zone. Since checkable objects such as a Host or a Service object
must have only one endpoint as authority, they cannot be put into a global zone (denied by
the config compiler).
When the master connects to the child zone member(s), this requires more
resources there. Keep this in mind when endpoints are not reachable, the
TCP timeout blocks other resources. Moving a satellite zone in the middle
-between masters and agents/clients helps to split the tasks - the master
+between masters and agents helps to split the tasks - the master
processes and stores data, deploys configuration and serves the API. The
-satellites schedule the checks, connect to the agents/clients and receive
+satellites schedule the checks, connect to the agents and receive
check results.
Agents/Clients can also connect to the parent endpoints - be it a master or