Skip to content

explain clustering #929

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
taylordowns2000 merged 2 commits into from
Oct 20, 2026
Merged

explain clustering #929

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
94e0b68
explain clustering
taylordowns2000 Oct 19, 2026
4257405
remove misleading text
taylordowns2000 Oct 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 27 additions & 8 deletions docs/deploy/requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,11 +30,13 @@ your deployment partner can better estimate your total cost of ownership.
4. Will the deployment require high-availability? (i.e., if OpenFn will receive
requests in real-time from other applications rather than run cron-based
jobs, then at least two instances of OpenFn should be run simultaneously
behind a load-balancer, making use of “distributed Erlang” to ensure graceful
application redundancy; if OpenFn will not be responsible for receiving
requests and will only be responsible for making relatively time-independent
outbound requests on a cron schedule, the importance of maintaining a
zero-downtime system is slightly reduced.)
behind a load-balancer, all active at once and joined into one Erlang cluster
(see
[High-Availability on Docker Engine](#c-high-availability-on-docker-engine));
if OpenFn will not be responsible for receiving requests and will only be
responsible for making relatively time-independent outbound requests on a
cron schedule, the importance of maintaining a zero-downtime system is
slightly reduced.)
5. Does OpenFn need to plug into tooling you already run, such as your own
monitoring and alerting, secrets manager, CI/CD pipelines, or change-control
process? Integrating with customer-specific tooling is scoped separately from
Expand Down Expand Up @@ -184,11 +186,27 @@ balancer, which also handles HTTPS. If one host fails, the others keep serving
requests. Use a replicated or managed Postgres service so the database doesn't
become the weak point.

:::tip Run every node, with no spares

Keep all your Lightning nodes running behind the load balancer. Don't set up a
hot or cold spare: every node serves traffic, and if one fails the others take
on its load. The nodes join one Erlang cluster on their own, so you don't need
to build any messaging between them.

Outside Kubernetes, Lightning finds other nodes with gossip by default. Gossip
uses UDP multicast, which most cloud networks block between VMs. On Docker
Engine across several hosts, set `ERLANG_NODE_DISCOVERY_VIA_POSTGRES_ENABLED` to
`true` so nodes find each other through the Postgres database they already
share.
Comment on lines +196 to +200

@Tedion Tedion Oct 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker Engine side only, that's what I've deployed Lightning clustered on.

One thing the tip could add. Postgres discovery only finds peers; the connection is still plain TCP, so you also need the same RELEASE_COOKIE, RELEASE_DISTRIBUTION=name, RELEASE_NODE as a reachable address rather than a container id, a pinned port (ERL_AFLAGS=-kernel inet_dist_listen_min 9100 inet_dist_listen_max 9100) and the firewall open for epmd 4369 plus that port.

Set only the flag and the nodes discover each other and still can't connect.

@taylordowns2000 taylordowns2000 Oct 20, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, let's make sure this information lives in Zeus


:::

```mermaid
flowchart TB
users(Users & webhooks) --> lb1
lb1 --> ex1 & ex2
ex1 & ex2 -- SQL --> db1
ex1 <-. Erlang cluster .-> ex2
subgraph lb["Load balancer"]
lb1(HTTPS termination)
end
Expand All @@ -206,9 +224,10 @@ flowchart TB
### (d) High-Availability on Kubernetes

Run the web app and the worker in separate node pools that scale on their own,
each sized for its workload. This is how OpenFn's own cloud runs. For the
database, use a high-availability managed Postgres service or run Postgres in
the cluster.
each sized for its workload. This is how OpenFn's own cloud runs. As on Docker
Engine, every web app pod is active, and on GKE the pods join one Erlang
cluster. For the database, use a high-availability managed Postgres service or
run Postgres in the cluster.

```mermaid
flowchart TB
Expand Down
30 changes: 25 additions & 5 deletions i18n/es/docusaurus-plugin-content-docs/current/deploy/requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Requisitos
translation_source_hash: de80a04288f28b1b038411af676bcb22d3961597
translation_source_hash: 32e41fc789ea45ec11ccab3e4e6c01de1135f452
translation_review_status: machine
---

Expand Down Expand Up @@ -33,8 +33,9 @@ para que tu socio de despliegue pueda estimar mejor el costo total de propiedad.
4. ¿El despliegue requerirá alta disponibilidad? (Es decir, si OpenFn va a
recibir solicitudes en tiempo real desde otras aplicaciones en lugar de
ejecutar jobs basados en cron, se deberían ejecutar al menos dos instancias
de OpenFn a la vez detrás de un balanceador de carga, usando "Erlang
distribuido" para lograr una redundancia de la aplicación sin interrupciones.
de OpenFn a la vez detrás de un balanceador de carga, todas activas y unidas
en un solo clúster de Erlang (consulta
[Alta disponibilidad en Docker Engine](#c-high-availability-on-docker-engine)).
Si OpenFn no va a recibir solicitudes y solo va a hacer solicitudes salientes
con un horario cron, donde el momento exacto importa poco, mantener un
sistema sin tiempo de inactividad es algo menos importante).
Expand Down Expand Up @@ -194,11 +195,28 @@ balanceador de carga, que también se encarga de HTTPS. Si un host falla, los
demás siguen atendiendo las solicitudes. Usa un servicio de Postgres replicado o
administrado para que la base de datos no se convierta en el punto débil.

:::tip Ejecuta todos los nodos, sin nodos de reserva

Mantén todos tus nodos de Lightning en funcionamiento detrás del balanceador de
carga. No configures un nodo de reserva, ni en caliente ni en frío: todos los
nodos atienden tráfico y, si uno falla, los demás asumen su carga. Los nodos se
unen por su cuenta en un solo clúster de Erlang, así que no tienes que construir
ningún mecanismo de comunicación entre ellos.

Fuera de Kubernetes, Lightning encuentra los demás nodos mediante gossip de
forma predeterminada. Gossip usa multidifusión UDP, que la mayoría de las redes
en la nube bloquean entre máquinas virtuales. En Docker Engine con varios hosts,
establece `ERLANG_NODE_DISCOVERY_VIA_POSTGRES_ENABLED` en `true` para que los
nodos se encuentren a través de la base de datos Postgres que ya comparten.

:::

```mermaid
flowchart TB
users(Users & webhooks) --> lb1
lb1 --> ex1 & ex2
ex1 & ex2 -- SQL --> db1
ex1 <-. Erlang cluster .-> ex2
subgraph lb["Load balancer"]
lb1(HTTPS termination)
end
Expand All @@ -217,8 +235,10 @@ flowchart TB

Ejecuta la aplicación web y el worker en grupos de nodos separados que escalan
por su cuenta, cada uno dimensionado para su carga de trabajo. Así funciona la
propia nube de OpenFn. Para la base de datos, usa un servicio administrado de
Postgres con alta disponibilidad o ejecuta Postgres en el clúster.
propia nube de OpenFn. Igual que en Docker Engine, todos los pods de la
aplicación web están activos y, en GKE, se unen por su cuenta en un solo clúster
de Erlang. Para la base de datos, usa un servicio administrado de Postgres con
alta disponibilidad o ejecuta Postgres en el clúster.

```mermaid
flowchart TB
Expand Down
Loading