Host roles

Hosts in the cluster may be described as the primary host, primary candidates, management hosts, compute hosts, the web server host, or the DB host.

By default, EGO sets the number of CPUs on hosts by the number of physical CPUs. If you have a dual-core processor, you may wish to change the default behavior and set the number of CPUs by cores on hosts.

On the primary host

A cluster requires a primary host. This is the first host installed. The primary host controls the rest of the hosts in the cluster.

On primary candidate hosts

There is only one primary host at a time. However, if primary candidates are specified and the primary host fails, another host automatically takes over the primary host role, allowing work to continue. This process is called failover. When the primary host recovers, the role switches back again.

Hosts that can act as the primary host are called primary candidates. This includes the primary host and all hosts that can take over as the primary host in a failover scenario. All primary host candidates must be management hosts.

Failover for the primary host

During primary host failover, the system is unavailable for a few minutes while hosts are waiting to be contacted by the new primary host.

The primary candidate list defines which hosts are primary candidates. By default, the list includes just one host, the primary host, and there is no failover. If you configure additional candidates to enable failover, the primary host is first in the list. If the primary host becomes unavailable, the next host becomes the primary host. If that host is also unavailable, the next host is considered to become the primary host, and so on down the list. A short list with two or three hosts is sufficient for practical purposes.

For failover to work properly, the primary candidates must share a file system and the shared directory must always be available.
Important: Ensure that the shared directory is not on a primary host or any of the primary candidates. If the shared directory resides on the primary host and the primary host fails, the next candidate cannot access the necessary files.

Management host

Management hosts belong to the ManagementHosts resource group. These hosts are not expected to execute workload units for users. Management hosts run services such as the web server and web services gateway. The primary host and all primary candidates must be management hosts.

Management hosts share configuration files, so a shared file system is needed among all management hosts.

A management host is configured when you run egoconfig mghost on the host. The tag mg is assigned to the management host to differentiate it from a compute host.

Compute host

Compute hosts are distributed to cluster consumers to execute workload units. By default, compute hosts belong to the ComputeHosts resource group.

The ComputeHosts group excludes hosts with the mg tag, which is assigned to management hosts when you run egoconfig mghost. If you create your own resource groups to replace ComputeHosts, make sure they also exclude hosts with the mg tag.

By default, the number of slots on a compute host is equal to the number of CPUs.

Web server hosts

Your cluster includes the following web servers:
  • The web server host for the cluster management console. There is only one host for the cluster management console; it does not need to be a dedicated host. Any management host can be the web server (decided when the cluster starts up).
  • The web server hosts for the RESTful APIs, which include:
    • The ascd web server, which hosts the RESTful APIs for instance group management. Any management host can be the web server.
    • The REST web server, which hosts the RESTful APIs for resource management and package deployment. Any management host can be the web server.

DB host

The DB host runs the database used for reporting in your cluster.
  • For a demo cluster, the Derby database runs as a system service (derbydb) on a management host that you specify during installation. There is no failover, so if this host fails, the reporting setup does not work properly.
  • For a production cluster, you must use a supported commercial database, and the host does not need to be part of the cluster.