Multicluster terminology

Learn about the terms related to IBM® Spectrum Symphony multicluster.

Clusters

An IBM Spectrum Symphony multicluster environment includes a federation cluster (made up of member clusters that use the multicluster features), and an IBM Spectrum Symphony primary management cluster (that is separate from the federation and member clusters, as it manages and coordinates the clusters):
Member cluster
An individual IBM Spectrum Symphony cluster that joins the federation cluster as a member of the multicluster environment so that it can participate in multicluster features. Each member cluster has its own repository. You can have several of these clusters in your IBM Spectrum Symphony multicluster environment.

This cluster includes a management host (on which you enable a multicluster proxy (an SMCP service that discovers and connects hosts), and one or more compute hosts that act as agents.

Do not confuse a member cluster with a lone cluster, which is an independent cluster that is not currently a member of the federation cluster. A lone cluster can request to join the federation cluster and be added to the federation waiting list. Additionally, cluster that once was part of the federation cluster, but has been removed, is no longer considered a member cluster and returns to be a lone cluster. You can think of a lone cluster as one that has not yet joined the federation cluster, or has left the federation cluster.

Federation cluster
A group of IBM Spectrum Symphony member clusters that participate in multicluster features. An IBM Spectrum Symphony multicluster administrator, or a user with the SMC_CLUSTER_CONTROL permission determines and manages which clusters can participate in the federation cluster.

The federation cluster has its own repository, which can be synchronized with the member cluster repositories to keep the member cluster repositories current (for example, if you add a multicluster service package to the federation repository, you can synchronize that update on the cluster member repositories).

IBM Spectrum Symphony multicluster primary cluster (or simply, primary cluster)
This cluster oversees the federation cluster to manage multicluster features such as workload placement and service package deployment across member clusters. The primary cluster resides on a set of hosts to ensure failover, and uses EGO technology for high availability and for managing services within multicluster. It is, therefore, known as the IBM Spectrum Symphony multicluster primary cluster (or simply, primary cluster).

This primary cluster is typically a one- or two-host cluster that runs four EGO services: the IBM Spectrum Symphony multicluster primary daemon, the multicluster management console, the EGO REST server, and the repository service (RS).

Workload placement

Workload placement within IBM Spectrum Symphony multicluster allows you to submit workload to under-utilized clusters within the multicluster. Workload placement minimizes application runtime, as you can distribute workload across two or more clusters so the workload is rebalanced. The two types of workload placement are cluster and application level workload placement.

Cluster workload placement
Workload placement at the cluster level can be referred to as global workload placement. The multicluster administrator manages global workload placement. This administrator identifies the clusters participating in workload placement, defines a set of global (default) rules, and uses reserve clusters.

Once the administrator completes the cluster workload placement configuration at a global level, the multicluster administrator, or multicluster user with authority for specific applications, manages the workload distribution and workload placement rules at the application level.

For details about cluster workload placement, see Workload placement in IBM Spectrum Symphony multicluster.

Application workload placement
Workload placement at the application level is referred to as application workload placement. Although a multicluster administrator can configure workload placement for applications, these tasks are typically performed by a multicluster user.

The multicluster user creates an XML file that defines the placement rules for a workload placement policy and then generates the workload placement policy from the contents of the XML file. The multicluster administrator then grants the workload placement policy owner (creator) permissions so that the user can manage the applications associated with the workload placement policy.

For details about application workload placement, see Workload placement in IBM Spectrum Symphony multicluster.

Bins
Bins is a concept used in conjunction with the multicluster management console. An application can go into a bin that associates the application with a specific placement policy for distributing workload.

Repurposing

Repurposing within IBM Spectrum Symphony multicluster is the act of migrating compute hosts between member clusters within the federation cluster.
Source cluster
The cluster from which hosts are removed during the host repurposing process.
Target cluster
The cluster to which hosts are added during the host repurposing process.