Skip to content

Scaling and Clustering Updated 2026-05-27

Failover protection with Traffic Distributor

Use the Traffic Distributor health-check module on the Stack Harbor PaaS to pull unhealthy backends out of rotation automatically.

The Traffic Distributor (TD) add-on on Stack Harbor PaaS includes a built-in health-check module that probes backends at a configurable interval and removes unhealthy ones from the routing pool. When the backend recovers, it is re-added automatically. The module is enabled with sensible defaults; the rest of this page covers what those defaults mean and how to change them.

Where the configuration lives

Open the NGINX Config panel on the TD node and navigate to /etc/nginx/nginx-jelastic.conf under Root. Double-click to open it in a new tab for editing. Around line 50 you’ll find the add-on’s configuration block. Inside the upstream common section, look for the check directive — that’s the health-check module.

The check directive

The directive takes one or more parameters:

check interval={interval} fall={fail_count} rise={rise_count} [timeout={timeout}] [default_down={true/false}] [port={port}] [type={type}]

What each one does:

  • interval — delay between two consecutive probes, in milliseconds.
  • fail_count — number of consecutive failed probes before the backend is marked down.
  • rise_count — number of consecutive successful probes before a previously down backend is marked up.
  • timeout — how long the module waits for a reply before counting a probe as failed (milliseconds). Optional.
  • default_down — initial state. true means the backend starts as down until rise_count probes succeed; false means it starts as up. Defaults to true.
  • port — port to probe on. 0 (the default) uses the backend’s default port for the configured protocol.
  • type — protocol to use for the probe. Optional. Choices:
    • tcp — a plain TCP socket connection.
    • ssl_hello — sends a TLS Client Hello and expects a Server Hello in reply.
    • http — sends an HTTP request and parses the response (a 200 is the success criterion).
    • mysql — connects to the MySQL server and reads the greeting.
    • ajp — sends an AJP Cping packet and expects a Cpong response.
    • fastcgi — sends a FastCGI request and parses the response.

A worked example

Take a TD configured with this:

check interval=3000 fall=3 rise=3 type=http

Both backends are probed for a 200 response every 3 seconds. If three probes in a row fail, the backend is marked down and excluded from routing — all traffic goes to the surviving backend. When the failed backend recovers, three successful probes in a row promote it back up and it rejoins the rotation.

If your backend is a MySQL primary behind TD, you would set type=mysql instead; for a TLS-terminated service that needs a TLS-aware probe, type=ssl_hello.

Apply the change without a restart

After saving nginx-jelastic.conf, you do not need to restart the whole NGINX process. Use Reload configuration in the add-on’s menu — a graceful reload that keeps existing connections open and picks up the new check parameters within a few seconds. Confirm in the pop-up.

When to tighten the defaults

  • Shorter interval and lower fall_count — faster failure detection, more aggressive routing changes. Useful when a stale backend would cause noticeable user impact (auth services, payment paths). Be careful about flapping if your backends are noisy.
  • Higher rise_count — wait longer before sending traffic back to a previously failed backend. Useful when the backend may need warm-up after a restart.
  • Lower timeout — drop slow backends faster. Useful when latency matters more than absolute correctness.
  • Traffic Distributor overview — what TD is and when to use it.
  • Traffic Distributor installation — how to attach TD to an environment.
  • Traffic Distributor integration — wiring TD in front of one or several environments.
  • Blue-Green deploy — using TD to swap traffic between two parallel environments.
  • A/B testing — using TD to split traffic by ratio.