Supporting Cloudera components

The following table lists the components and the layout for a five node cluster.

Table 1. Cloudera Runtime component distribution for a five node Cloudera Observability on premises cluster
Service	Node 1 (All master components of all services)	Node 2, 3, 4 (Worker nodes + ZooKeeper + Cloudera Observability processing components)	Node 5 (Worker nodes + Cloudera Observability processing components + Cloudera Observability UI )
Cloudera Management Service	`Alert Publisher` `Event Server` `Host Monitor` `Reports Manager` `Service Monitor`
HBase	`Gateway` `Master` `Thrift Server (optional)`	`Gateway` `RegionServer`	`Gateway` `RegionServer`
HDFS	`Balancer` `Gateway` `NameNode` `NFS Gateway (optional)` `SecondaryNameNode`	`DataNode` `Gateway`	`DataNode` `Gateway`
Hive	`Gateway` `Metastore Server` `HiveServer`	`Gateway`	`Gateway`
Hue (Optional)	`Load Balancer` `Hue Server`
Impala	`Catalog Server` `StateStore`		`Impala Daemon`^*
Kafka		`Kafka Broker`
Phoenix	`Query Server`	`Query Server`	`Query Server` Configuring multiple Phoenix Query Server hosts reduces bottlenecks. The number of Phoenix Query Server hosts must be proportional to the number of Cloudera Observability on premises roles. For example, if you have roles on 5 nodes, at least 5 Query Servers are recommended for Phoenix. Cloudera Observability on premises internally balances loads on those hosts.
ZooKeeper		`Server`

^* To enable High Availability for Impala across daemons, you can manually configure multiple hosts by setting up HAProxy. For information, see Apache Impala documentation.