Skip to content

What is auto-clustering

A working definition of auto-clustering on the Stack Harbor PaaS — when to enable it, what it actually configures, and which stacks support it.

A cluster is two or more instances of a service running in coordination so the system survives the loss of any single node and can spread incoming load. For any production workload that matters, a cluster is the recommended shape — but configuring one from scratch is not trivial. Stack Harbor PaaS automates the common cases. Auto-clustering is the feature that turns on the production topology for a supported stack with one switch in the topology wizard.

What auto-clustering gives you

When you enable auto-clustering on a layer, the platform handles the configuration steps that are usually fiddly and error-prone:

  • Selecting and applying the replication scheme appropriate to the stack (primary-secondary, primary-primary, Galera, replica set, etc.).
  • Installing and wiring up the proxy or load-balancing component the stack needs in front of it (ProxySQL for MySQL/MariaDB/Percona, Pgpool-II for PostgreSQL, NGINX for application servers, etc.).
  • Configuring authentication between cluster members (keys, replication users) and persisting that config across container lifecycle operations.
  • Setting up auto-discovery so new nodes added by horizontal scaling are joined to the cluster automatically — and removed cleanly on scale-in.
  • Pre-wiring failover detection where the topology supports it (Pgpool-II for PostgreSQL, MongoDB replica-set election, etc.).

The result is a production-ready cluster that takes a few minutes to spin up, not a few days.

Which stacks support auto-clustering today

Auto-clustering is currently available in the topology wizard for these stacks:

  • Application servers — Tomcat / TomEE, GlassFish, Payara, Jenkins, WildFly.
  • SQL databases — MySQL, MariaDB, Percona, PostgreSQL.
  • NoSQL databases — MongoDB, Couchbase, Redis, OpenSearch.
  • Storage — Shared Storage Container (Gluster-based replicated volume).

Each of these has its own dedicated page (or section) in this documentation covering the specifics — what the proxy layer looks like, what the default node count is, and how the platform handles failover.

How to enable it

In the topology wizard, pick the stack you want. If auto-clustering is available for it, an Auto-Clustering switcher appears in the central pane. Hover the question-mark icon to see a short description of what will be configured. Some stacks expose additional settings once the switch is on — MariaDB lets you choose between primary-secondary, primary-primary, and Galera, for example; MySQL/MariaDB/Percona let you exclude the ProxySQL nodes if you do not need them.

Configure the rest of the environment as usual — node count, cloudlet limits, region, public IPs — and create. The platform handles the cluster setup in the background. You can watch progress under Import > JPS > View Logs if you want to see what’s happening.

One detail to know: once auto-clustering is configured on a layer, it cannot be disabled from the topology wizard. If you change your mind, you create a new environment with the topology you want.

Beyond the topology-wizard set

The Marketplace under the Clusters category exposes a wider set of prepackaged clusterization solutions, including some that go beyond what the wizard auto-clustering covers. If a stack you need is not in the wizard list, check the Marketplace before assuming you need to roll your own.

Where to go next

  • Auto-clustering via topology wizard — full reference for the stacks listed above, including the JPS properties for use in packaged solutions.
  • Database auto-clustering — MariaDB / MySQL / Percona specifics, including ProxySQL and the available replication schemes.
  • PostgreSQL auto-clustering — the primary-secondary topology with Pgpool-II, automatic and manual failover.
  • MongoDB auto-clustering — replica-set configuration, election timings, and the connection string that survives a failover.
  • Horizontal scaling — how cluster members are added and removed over the lifetime of the layer.