Since version 3.0, CloverETL Server does not recognize any differences between cluster nodes. Thus, there are no "master" or "slave" nodes meaning all nodes can be virtually equal. There is no single point of failure(SPOF) in the CloverETL cluster itself, however SPOFs may be in the input data or some other external element.
Clustering offers high availability(HA) for all features accessible through HTTP. This includes sandbox browsing, modification of services configuration (scheduling, launch services, listeners) and primarily graph executions. Any cluster node may accept incoming HTTP requests and process them itself or delegate it to another node.
Since all nodes are equal, almost all requests may be processed by any cluster node:
All graph files, metadata files, etc. are located in shared sandboxes. Thus all nodes have access to them. A shared filesystem may be a SPOF, thus it is recommended to use a replicated filesystem instead.
The database is shared by all cluster nodes. Again, a shared DB might be a SPOF, however it may be clustered as well.
But there is still a possibility, that a node cannot process a request by itself. In such cases, it completely and transparently delegates the request to a node which can process the request.
These are the requests which are limited to one (or more) node(s):
a request for the content of a partitioned or local sandbox. These sandboxes aren't shared among all cluster nodes. Please note that this request may come to any cluster node which then delegates it to a target node, however, this target node must be up and running.
A graph is configured to use a partitioned or local sandbox. These graphs need nodes which have a physical access to the required sandboxes.
Thus an inaccessible partitioned or local sandbox may cause a failure from the request, however...
it is still possible to configure redundant sandboxes stored on other cluster nodes.
these types of sandboxes are used only for scalability on the data level(described below), which is a different approach to using a CloverETL cluster.
CloverETL itself implements a load balancer for executing graphs. So a graph which isn't configured for some specific node(s) may be executed anywhere in the cluster and the CloverETL load balancer decides, according to the current load, which node will process the graph. All this is done transparently.
To achieve HA, it is recommended to use an independent HTTP load balancer. Independent HTTP load balancers allow transparent fail-overs for HTTP requests. They send requests to the nodes which are running.