Un grupo de central en servidores separados¶

Redundancia explica de qué consta una instalación con reserva y qué cambia la segunda instancia. Esta página trata de montarla: qué ajustes recibe cada máquina, qué se les dice a los streamers y qué comprobar cuando todo esté levantado.

Lo que se describe aquí es un parque de servidores independientes — una máquina por instancia. Para probar lo mismo en un solo portátil, sin alquilar servidores, siga el laboratorio en Docker: el mismo grupo se levanta con contenedores en unos minutos.

Qué se despliega exactamente¶

Una instalación con reserva tiene cuatro partes, y solo una de ellas es Catena:

• Un clúster PostgreSQL, accesible por todas las instancias en una misma dirección. Es el único almacén de estado y la única parte cuya tolerancia a fallos Catena no asume.
• Dos o más instancias de central — máquinas separadas con la misma configuración, que se diferencian en sus roles y en su dirección anunciada.
• Streamers — máquinas separadas a las que se da no la dirección de una instancia, sino la lista de direcciones del grupo.
• Un punto de entrada del operador — una sola dirección con una instancia viva detrás: un nombre DNS con conmutación o un balanceador.

La regla con la que empieza una instalación así: central y la emisión viven en máquinas distintas. Un streamer local dentro del proceso de central no sirve aquí — comparte la suerte del proceso, y sus streams mueren junto con el plano de control.

Cuántos de cada uno¶

La configuración de una instancia de central¶

Las instancias de un grupo se diferencian en exactamente dos líneas: la dirección anunciada y el conjunto de roles. Todo lo demás es idéntico, incluida la cadena de conexión a la base de datos.

La primera instancia:

listeners:
  http:
    - port: 80

central:
  database_url: postgres://central:contraseña@db.example.com:5432/central
  admin_keys:
    - clave-de-gestion
  roles: [run, migrate, layouter, stats]
  advertise_url: http://central-a.example.com

api_auth:
  login: admin
  password: contraseña-del-operador

La segunda es la misma, sin el rol migrate y con su propia dirección:

central:
  database_url: postgres://central:contraseña@db.example.com:5432/central
  admin_keys:
    - clave-de-gestion
  roles: [run, layouter, stats]
  advertise_url: http://central-b.example.com

Los roles son declaraciones, no asignaciones¶

Un rol en la configuración significa «esta máquina está lista para hacer este trabajo», no «esta máquina lo hace». Qué instancia hace realmente el trabajo lo decide PostgreSQL y no la configuración — por eso layouter y stats los declaran las dos, y eso no es un error ni un arranque doble.

• run — servir peticiones: la consola, el API de gestión, la recepción de la sincronización de los streamers, la exportación de métricas. La necesita cada instancia.
• migrate — aplicar las migraciones del esquema al arrancar.
• layouter — ejecutar las pasadas de la colocación.
• stats — mantener la imagen del «ahora mismo» de todo el clúster.

El único rol que no se puede dejar en todas es migrate. No está protegido por un mandato: dos procesos que arranquen a la vez lanzarán las migraciones a la carrera. Por eso el esquema lo aplica una instancia y las demás arrancan después de ella.

Es también la razón para no dejar roles vacío en la segunda instancia: una lista vacía no significa «ningún rol», sino los cuatro, migrate incluido.

La dirección anunciada¶

advertise_url es la dirección por la que los vecinos del grupo alcanzan esta máquina. Hace falta porque la imagen del «ahora mismo» la mantiene una instancia mientras las demás llegan a ella por la red: el titular anota su dirección y los vecinos la leen de ahí.

La dirección de un balanceador no sirve aquí — llevaría al vecino de vuelta a sí mismo. La dirección debe ser la de una máquina concreta.

El ajuste puede omitirse: una instancia sin dirección anunciada funciona por completo e incluso puede mantener la imagen, pero los vecinos no llegarán a ella y lo dirán en el log. En la consola una fila así queda marcada; ver la comprobación tras el despliegue.

Licencia¶

La licencia la necesita cada proceso de central, no una por grupo: sin ella el proceso ni siquiera arranca. La clave y el producto declarado son los mismos en todas las instancias.

Quién hace qué: los mandatos¶

El trabajo cuyo duplicado sería dañino lo hace una sola instancia del grupo: la que ha tomado el mandato correspondiente. El mandato vive en PostgreSQL y se emite en una conexión propia, por lo que la muerte del proceso lo libera sola, sin analizar ejecutores colgados con tiempos de espera: si la sesión murió, el mandato está libre.

Los mandatos son varios y son independientes. Central no tiene un líder único: layouter y stats pueden acabar en máquinas distintas, y eso es un estado normal, no un desequilibrio.

Cada emisión lleva un número — la época. Crece al cambiar de titular y viaja con cada escritura: una instancia que despierta de una pausa y ya no es la titular recibe un rechazo en la escritura, en lugar de estropear la colocación a posteriori. Por eso la mudanza de un mandato es segura y no exige confirmación manual.

El cambio de titular tarda segundos — lo que PostgreSQL necesita para notar la sesión muerta y el vecino para venir a por el mandato liberado.

Una instancia que no tiene ningún mandato no es una reserva ni está dormida: sirve por completo la consola, el API y la sincronización de los streamers. El mandato solo afecta al trabajo de fondo.

La configuración de un streamer¶

El streamer se dirige al grupo, no a un proceso, así que en su configuración va una lista de direcciones:

managed_by:
  name: streamer-01
  url:
    - http://central-a.example.com
    - http://central-b.example.com
  join_token: token-de-union

El orden de la lista es una preferencia de partida, no una vinculación permanente. El streamer se queda en su dirección actual mientras esta responda y pasa a la siguiente tras una petición fallida. No vuelve por sí solo: mientras la nueva dirección responda no hay nada que ganar cambiándola, y rotar por igualar solo repartiría la máquina por el grupo.

La segunda dirección es obligatoria, no deseable. Una interrupción del bucle de sincronización es la única señal de vida de un streamer que tiene central. Un streamer que se quede con una sola dirección muerta figura como offline minuto y medio después, tras lo cual el layouter mueve honestamente sus streams a otra máquina — desde una viva y emitiendo. La muerte de una instancia de gestión se convierte en la mudanza de medio aire.

Conviene repartir la lista por mitades del parque: dar a una mitad la primera instancia como primera dirección y a la otra la segunda. En estado tranquilo la carga de sincronización queda repartida y, al morir cualquiera de las instancias, solo se muda su mitad.

El punto de entrada del operador¶

El operador necesita una sola dirección que encuentre por sí misma una instancia viva: un nombre DNS con conmutación o un balanceador delante del grupo. Un manejador de peticiones no guarda estado propio, así que cualquier instancia puede responder a la petición de un operador.

Los streamers no deben pasar por ese punto de entrada: tienen su propia lista de direcciones, y un intermediario de más en el camino de la sincronización solo añade un punto de fallo.

Orden de despliegue¶

1. Levantar PostgreSQL y crear la base de datos.
2. Arrancar la primera instancia — la que tiene el rol migrate. Esperar a que responda a las peticiones: el esquema se aplica antes de estar lista.
3. Arrancar las demás instancias.
4. Abrir la ventana de unión y levantar los streamers, dando a cada uno la lista de direcciones del grupo.
5. Apuntar el punto de entrada del operador al grupo.

El paquete en las máquinas de las instancias es catena-base, el mismo que reciben los streamers: a la pregunta de instalación sobre un PostgreSQL existente se responde con la dirección de la base compartida, mientras que los roles y la dirección anunciada vienen de la configuración de arriba. El paquete catena no hace falta aquí — monta la base en su propia máquina, y un grupo la necesita aparte de las instancias.

El orden solo importa en el primer paso: las demás instancias no arrancarán antes que el esquema, y los streamers no se unirán antes de que haya un central vivo.

Qué comprobar tras el despliegue¶

Todo lo que hay que mirar está en la consola, en la sección Clúster → Central.

• La tabla tiene tantas filas como instancias. Una fila aparece a los segundos de un arranque. Si no aparece, la instancia no llegó a la base de datos.
• Cada fila tiene rellena la «Dirección anunciada». La marca «sin anunciar» significa que los vecinos no llegarán a esa instancia: le falta advertise_url.
• La columna «Roles reclamados» muestra los roles declarados. Asegúrese de que migrate está declarado exactamente en una.
• La columna «Mandatos en curso» no está vacía al menos en una instancia. Vacía en todas significa que ninguna declaró los roles layouter y stats, y el grupo no tiene ni colocación ni imagen del «ahora mismo».
• La columna «Compilación» es la misma en todas las filas. Versiones distintas en un grupo son un estado normal solo mientras dure una actualización.
• La sección «Streamers» muestra todo el parque desde cualquier instancia. Media parte del parque visible en una dirección y la otra media en otra significa que las instancias no ven la imagen de la otra: revise advertise_url.

No hace falta probar la conmutación a mano, y no conviene hacerlo en una instalación en servicio — para eso está el laboratorio, sobre un banco desechable.

Qué no hace este esquema¶

• No hace redundante la base de datos. La tolerancia a fallos de PostgreSQL es tarea de la propia base: una réplica con conmutación o una instancia gestionada de un proveedor.
• No sustituye a los backups. La reserva protege de la pérdida de una máquina, no de un borrado por error — ver Backup y restauración.
• No toca el aire. Los streams emiten y graban el archivo sin central; solo se hace redundante la gestión, ver Autonomía del streamer.