Puedes reconstruir srv-tramontana en cincuenta minutos. Puedes probar cualquier cambio antes de aplicarlo, detectar una intrusión, cifrar los secretos, diagnosticar una latencia anómala y recuperar un arranque roto. Y aun así, si esa máquina se cae, Tramontana Reservas está caída.

Un disco que falla, una fuente de alimentación, un corte de red del proveedor, un kernel que no arranca tras una actualización, o simplemente el mantenimiento programado de la infraestructura donde vive. En el mejor de los casos, cincuenta minutos de interrupción — y eso suponiendo que alguien esté despierto para lanzar el playbook. Todo el trabajo de siete módulos descansa sobre una única máquina, que es la definición exacta de un punto único de fallo.

Esta lección ataca ese problema, y lo hace con una advertencia por delante: la alta disponibilidad es cara, compleja y, mal hecha, empeora la fiabilidad en lugar de mejorarla. Un sistema con más piezas tiene más formas de fallar. La lección termina con el análisis honesto de si Tramontana necesita esto, porque la respuesta profesional no siempre es que sí.

1. Vocabulario: disponibilidad, nueves, MTBF y MTTR
2. Escalado vertical y horizontal
3. Redundancia: activo-pasivo y activo-activo
4. El estado es el problema difícil
5. Balanceo de carga: capas, algoritmos y comprobaciones de salud
6. HAProxy en la práctica
7. Alta disponibilidad del balanceador: keepalived y VRRP
8. Split-brain y quórum
9. Replicación de datos
10. Clústeres, Pacemaker y fencing
11. Diseño para Tramontana y análisis de coste
12. Probar los fallos provocándolos

El área está llena de términos que se usan como sinónimos y no lo son. Fijarlos ahorra malentendidos caros.

La disponibilidad es la fracción de tiempo en que el servicio responde correctamente. Se expresa en porcentaje, y en «nueves»:

Mirar esa tabla despacio corrige la intuición de casi todo el mundo. 99,99 % significa menos de un minuto de caída a la semana, incluidas las actualizaciones, los reinicios por kernel nuevo y los fallos del proveedor. Con un único servidor, un solo reinicio mensual de tres minutos ya te sitúa por debajo de tres nueves y medio. Y cada nueve adicional multiplica el coste aproximadamente por tres.

Tres distinciones que conviene tener claras:

• Fiabilidad es la probabilidad de funcionar sin fallo durante un intervalo. Un sistema puede ser muy disponible y poco fiable: falla a menudo, pero se recupera en segundos.
• Durabilidad se refiere a los datos: la probabilidad de no perderlos. Es independiente de la disponibilidad — un sistema puede estar caído y tener los datos perfectamente a salvo.
• MTBF (tiempo medio entre fallos) y MTTR (tiempo medio de reparación) descomponen la disponibilidad:

Y esa fórmula contiene la decisión estratégica de toda la lección: hay dos formas de subir la disponibilidad. Aumentar el MTBF —fallar menos: mejor hardware, más pruebas, menos cambios— o reducir el MTTR —recuperarse antes—. En la práctica, reducir el MTTR es casi siempre más barato y más eficaz, porque el MTBF tiene un techo físico y el MTTR no.

Es exactamente lo que hiciste en 07-06 sin llamarlo así: pasar el MTTR de 8 horas a 50 minutos multiplicó la disponibilidad sin comprar un solo componente.

Y la relación con lo que ya tienes acordado con Marta:

Hay un hueco ahí: nadie ha fijado un objetivo de disponibilidad. Y sin él, no se puede decidir cuánto invertir.

La fila que importa aquí es la penúltima. Duplicar la memoria de srv-tramontana la haría más rápida y exactamente igual de frágil. El escalado horizontal es lo que permite que el fallo de una máquina no sea el fallo del servicio, y por eso esta lección va de escalado horizontal aunque el problema no sea de capacidad.

Tener dos máquinas no es tener redundancia: hay que decidir qué hace cada una.

El riesgo del activo-pasivo se subestima siempre y merece nombre propio: un nodo pasivo que nunca se usa es un nodo del que no sabes si funciona. Se instaló hace ocho meses, no ha recibido las últimas actualizaciones, tiene un certificado caducado o un disco lleno. El día del fallo, descubres que el respaldo también falla. La única defensa es usarlo periódicamente: conmutar a propósito cada pocas semanas.

Aquí está el núcleo conceptual de la lección, y lo que separa un diseño que funciona de uno que parece funcionar.

Replicar procesos es fácil: arrancas la misma aplicación en dos máquinas y ya tienes dos. Replicar estado es difícil, y el estado está en más sitios de los que parece.

Inventario del estado de Tramontana Reservas:

Esa fila de las tareas programadas es la que más problemas da en la práctica, porque nadie piensa en ella al duplicar un servidor. Con dos nodos idénticos, tramontana-respaldo.timer se dispara a las 02:30 en ambos: dos copias simultáneas al mismo destino, compitiendo por el flock —que es local a cada máquina y por tanto no protege nada—. La solución exige un bloqueo distribuido o ejecutar las tareas solo en un nodo designado.

Una aplicación sin estado (stateless) es aquella cuyas instancias no guardan nada entre peticiones: todo el estado está en la base de datos o en un almacén compartido. Es el requisito para el activo-activo, y casi nunca se cumple sin trabajo de desarrollo. En Tramontana:

Conclusión honesta: Tramontana no es una aplicación sin estado hoy. Antes de montar nada, hacen falta dos cambios en la aplicación: sesiones externalizadas y ficheros en almacenamiento compartido. Eso es trabajo de desarrollo, y decírselo a Marta antes de comprar servidores es parte del trabajo.

Un balanceador reparte peticiones entre varios servidores. Opera en una de dos capas:

Para HTTP, la capa 7 es casi siempre la correcta: permite terminar TLS en un punto, repartir según la ruta, reintentar una petición que falla y hacer comprobaciones de salud significativas.

leastconn es el más adecuado para Tramontana: una consulta de disponibilidad tarda 40 ms y un informe de facturación varios segundos, así que repartir por turnos amontonaría las lentas en el mismo nodo.

Es la pieza que hace útil el balanceador: sin ella, seguiría enviando tráfico a un servidor caído.

Lo correcto es usar ambas. Y aquí encaja algo que tienes desde el Módulo 4: revision_salud.sh devuelve 0, 1 o 2 — correcto, aviso, crítico. Esa gradación es exactamente lo que un balanceador necesita, si la aplicación expone un extremo equivalente:

Y la distinción que casi nadie hace bien: una comprobación superficial es peor que ninguna. Si el extremo de salud solo responde «estoy vivo» sin comprobar la base de datos, el balanceador seguirá enviando tráfico a un nodo que no puede atender ninguna petición. Si comprueba demasiado —por ejemplo, una consulta pesada—, un problema de la base de datos marca todos los nodos como caídos y el servicio desaparece por completo, cuando podría haber servido al menos las páginas estáticas.

El equilibrio: comprobar las dependencias críticas con una operación barata. Una consulta SELECT 1 con tiempo límite, no un informe.

La sticky session ata a cada cliente a un nodo, por cookie o por IP. Resuelve el problema de las sesiones en memoria... y crea otros:

• El reparto se desequilibra: un nodo puede acabar con el triple de carga.
• Cuando un nodo cae, todos sus usuarios pierden la sesión de golpe.
• Impide drenar un nodo para mantenimiento sin afectar a nadie.
• Enmascara el problema real en lugar de resolverlo.

Es una solución transitoria aceptable mientras se externalizan las sesiones. Como solución permanente, no.

Para desplegar sin cortar el servicio, un nodo tiene que poder salir del reparto ordenadamente: dejar de recibir peticiones nuevas y terminar las que ya tiene en curso.

Repetido nodo a nodo, eso es un despliegue sin interrupción. Y es la respuesta a algo que quedó pendiente desde 04-07: desplegar.sh reinicia el servicio, y ese reinicio son unos segundos de peticiones rechazadas. Con dos nodos y drenaje, cero.

Cuatro detalles de esa configuración que merecen explicación:

slowstart 30s. Cuando un nodo vuelve tras un fallo, sus cachés están frías y sus grupos de conexiones vacíos. Enviarle un tercio del tráfico de golpe puede tumbarlo otra vez, y entrar en un ciclo de caídas. slowstart sube su peso progresivamente durante 30 segundos.

rise 2 fall 3. Asimétrico a propósito: se necesitan tres fallos seguidos para sacar un nodo (evita falsos positivos por un pico) pero solo dos éxitos para devolverlo. Sacar de golpe por un fallo transitorio es cómo un balanceador provoca una caída.

option redispatch con retry-on. Si el servidor elegido falla, reintenta en otro. Con un matiz importante: reintentar un POST puede duplicar una reserva. HAProxy solo reintenta cuando la petición no se ha enviado o el método es idempotente.

El stick-table con límite de tasa. Es fail2ban de 06-03 en la capa 7: cuenta peticiones por IP en ventanas de 10 segundos y devuelve 429 al superar el umbral. Complementario, no sustituto: fail2ban bloquea a nivel de red y este a nivel de aplicación.

Nginx puede hacer lo mismo con upstream, y es la opción natural si ya lo tienes como proxy inverso — que es lo que montarás en 08-01:

La diferencia práctica: Nginx solo hace comprobaciones pasivas en su versión libre; las activas son de la versión comercial. HAProxy las trae de serie, y por eso es preferible cuando el balanceo es la función principal.

Y aquí está el error de diseño más común del área, tan frecuente que merece enunciarse solo:

Poner un balanceador delante de dos servidores no elimina el punto único de fallo: lo mueve al balanceador.

Antes tenías una máquina que podía caer. Ahora tienes tres, y si cae la que reparte, el servicio desaparece igual — con la agravante de que ahora hay más piezas que pueden fallar.

La solución es VRRP (Virtual Router Redundancy Protocol): dos balanceadores comparten una IP virtual flotante, la que apunta el DNS. Uno la tiene; si deja de anunciarse, el otro se la queda en segundos.

El mecanismo: el nodo con más prioridad anuncia la VIP cada segundo. Si el respaldo deja de oír anuncios durante tres intervalos, asume que el principal ha caído, se asigna la IP y envía un ARP gratuito para que los conmutadores de la red actualicen sus tablas. La conmutación tarda entre 3 y 4 segundos.

El track_script con weight -40 es lo que evita el fallo más tonto de esta arquitectura: sin él, un nodo donde keepalived funciona pero HAProxy está muerto retiene la VIP alegremente, y el servicio queda caído aunque el otro balanceador esté perfectamente. Con él, la prioridad de lb1 baja de 100 a 60, por debajo de los 90 de lb2, y la VIP se mueve.

Y enable_script_security con script_user es una precaución de seguridad real: keepalived corre como root y ejecuta esos scripts; sin esas directivas, un script con permisos laxos es una escalada de privilegios.

El fallo característico de cualquier sistema redundante, y el que causa las pérdidas de datos más graves.

Split-brain ocurre cuando los nodos dejan de verse entre sí pero ambos siguen funcionando. Cada uno concluye que el otro ha caído, y ambos se declaran principales:

• Dos balanceadores anuncian la misma IP virtual → tráfico impredecible, conexiones cortadas.
• Dos bases de datos aceptan escrituras → los datos divergen, y reconciliarlos después puede ser imposible.

El escenario que lo provoca no es que un nodo caiga —eso se maneja bien—, sino que la red entre ellos se corte mientras ambos siguen vivos y atendiendo clientes. Es más frecuente de lo que parece: un conmutador que falla, una regla de firewall mal puesta, una saturación momentánea.

Las tres defensas:

Y la conclusión que hay que retener:

Con dos nodos no hay quórum posible. Ninguno puede tener mayoría de dos. Por eso un clúster serio tiene tres nodos, o dos más un testigo.

Esto tiene una consecuencia directa en el diseño de Tramontana: un par de balanceadores con VRRP es aceptable, porque el peor caso —dos nodos anunciando la misma IP unos segundos— es molesto pero recuperable. Un par de bases de datos con conmutación automática no lo es: el peor caso es la divergencia de datos, y no se recupera. De ahí la recomendación del apartado siguiente.

PostgreSQL replica mediante el registro de escritura anticipada (WAL): el primario envía sus cambios a una o más réplicas.

Y el compromiso, que hay que entender antes de elegir: con replicación síncrona, cada escritura espera al viaje de ida y vuelta a la réplica. En la misma red local, uno o dos milisegundos. Entre centros de datos, decenas. Y si la réplica cae, el primario se bloquea esperando confirmación — a menos que se configure synchronous_standby_names con la sintaxis adecuada, lo que abre la puerta a perder datos justo cuando más importa.

Para Tramontana, con un RPO de 4 horas acordado, la replicación asíncrona es más que suficiente: perder los últimos segundos de transacciones está muy dentro de lo tolerado.

Ese retraso_bytes es la métrica que hay que vigilar: es cuántos datos se perderían si el primario cayera ahora. Va directa a la monitorización, junto a la edad de la última copia de 05-08.

La recomendación profesional, y va en contra de la intuición:

Con dos nodos, la conmutación de base de datos debe ser manual. Sin quórum, un fallo de red entre primario y réplica puede promover la réplica mientras el primario sigue aceptando escrituras, y entonces hay dos bases de datos divergentes. Recuperar de ahí puede significar perder transacciones o reconciliar a mano.

Herramientas como Patroni hacen conmutación automática segura, pero requieren un almacén de configuración distribuido con quórum propio (etcd o Consul), que a su vez necesita tres nodos. Es decir: automatizar la conmutación de forma segura exige, como mínimo, cinco máquinas. Es una decisión de arquitectura, no una casilla que marcar.

Para /opt/tramontana/shared/uploads:

NFS tiene la ironía característica: se monta para dar alta disponibilidad y, si no se hace también redundante, empeora la fiabilidad, porque ahora dos servidores dependen de una tercera máquina.

La respuesta moderna es el almacén de objetos: es lo que usan las aplicaciones diseñadas para escalar horizontalmente. Exige trabajo de desarrollo, y es la misma conclusión del apartado del estado.

Para escenarios más complejos —bases de datos, sistemas de ficheros compartidos, recursos con dependencias— existe la pila Pacemaker + Corosync:

• Corosync: comunicación entre nodos, pertenencia al clúster y quórum.
• Pacemaker: gestión de recursos, con dependencias y restricciones.

Un recurso es cualquier cosa que el clúster gestiona (una IP, un servicio, un sistema de ficheros), y las restricciones expresan reglas: «la IP debe estar donde está el primario de PostgreSQL», «este servicio debe arrancar después de aquel».

Y el concepto sin el cual nada de esto funciona de verdad:

Fencing (o STONITH, Shoot The Other Node In The Head): antes de tomar los recursos de un nodo que parece caído, el superviviente se asegura de que está apagado, cortándole la energía o destruyendo su máquina virtual.

Por qué es imprescindible: si el nodo A parece caído pero en realidad solo está congelado o incomunicado, y B toma sus recursos —monta el sistema de ficheros, promueve la base de datos, coge la IP—, cuando A se recupere ambos escribirán en los mismos datos. La corrupción resultante puede ser irrecuperable.

En hardware físico se hace con IPMI, iLO o unidades de distribución de energía gestionables. Y la regla del área es contundente: un clúster sin fencing configurado no es un clúster fiable. Muchos proyectos lo desactivan «temporalmente» porque complica las pruebas, y esa es exactamente la configuración que provoca la pérdida de datos el día del fallo.

Qué protege cada capa, y qué no:

Las tres últimas filas son las que hay que subrayar ante la dirección. La redundancia no protege contra los errores lógicos: un DELETE equivocado se replica en milisegundos a la réplica. Para eso están las copias de 05-08, y esta arquitectura no las sustituye en absoluto.

Lo que la lección viene prometiendo, y lo que Marta lleva tres respuestas pidiendo:

Coste de la arquitectura completa (5 máquinas frente a 1):

Coste de la indisponibilidad. La pregunta que hay que responder antes:

Pero ese cálculo bruto es engañoso por tres motivos, y decirlo es parte del análisis:

1. Las reservas no son uniformes. Se concentran de tarde y en fin de semana. Una caída de dos horas un martes de madrugada puede costar cero; la misma caída un viernes por la tarde, mucho más que la media.
2. Una reserva perdida no siempre se pierde. Muchos clientes vuelven a intentarlo. El coste real está entre el 20 % y el 50 % de la cifra bruta.
3. Hay coste reputacional, no lineal y difícil de cuantificar, especialmente si la caída coincide con una campaña.

Estimación razonable del coste anual de indisponibilidad, con distintos objetivos:

El ahorro de pasar de 99,5 % a 99,9 % es de unos 2.700 € al año. Eso hay que compararlo con el coste de la arquitectura completa —cuatro máquinas más, seis semanas de trabajo inicial y cuatro horas mensuales indefinidas—, que muy probablemente lo supera.

Y aquí está el análisis que casi nadie hace, y que cambia la recomendación:

El primer paso captura la mayor parte del beneficio por una fracción del coste, y esto es lo habitual en disponibilidad: los primeros nueves son baratos y los siguientes se encarecen exponencialmente. La razón es que la mayoría de las interrupciones no vienen de un fallo de hardware, sino de despliegues, reinicios y mantenimiento — y todo eso se cubre con dos nodos de aplicación y drenaje de conexiones, sin tocar la base de datos.

Fase 1 (ahora): fijar un objetivo formal de disponibilidad con Marta. Sin objetivo no se puede decidir cuánto invertir. Y medirla, porque el 99,5 % actual es una estimación, no un dato.

Fase 2 (1-2 meses): dos nodos de aplicación y un balanceador. Sesiones externalizadas y ficheros en almacén de objetos, que es trabajo de desarrollo. Elimina las interrupciones por despliegue y por fallo de un nodo, que son la mayoría.

Fase 3 (evaluar después): segundo balanceador con VRRP, y réplica de PostgreSQL con promoción manual.

Fase 4 (probablemente nunca): conmutación automática de base de datos. Exige quórum, es decir, cinco máquinas y un almacén distribuido. Para una empresa de este tamaño, la complejidad supera al beneficio.

Un sistema de alta disponibilidad no probado no es un sistema de alta disponibilidad: es una arquitectura que crees que funciona. Y la historia del área está llena de casos en que el respaldo falló el día que hizo falta.

La prueba 4 es la más incómoda y la más importante: no se puede «aprobar» con dos nodos, porque sin quórum el split-brain es inevitable. Lo que se hace es documentar el comportamiento observado y el procedimiento de recuperación, para que el día que ocurra nadie improvise.

La ingeniería del caos lleva esto más lejos: inyectar fallos de forma continua y automatizada en producción, con la lógica de que si los fallos ocurren todos los días, el sistema está obligado a tolerarlos y el equipo obligado a saber responder. Para Tramontana es desproporcionado; el principio —provoca los fallos tú, en horario laboral, en lugar de esperarlos— es aplicable a cualquier escala, y encaja con el simulacro semestral que propusiste en 07-06.

• Poner un balanceador y creer que ya hay alta disponibilidad. Solo has movido el punto único de fallo. El balanceador necesita su propia redundancia.
• Configurar VRRP sin track_script. Un nodo con keepalived vivo y HAProxy muerto retiene la IP virtual, y el servicio queda caído con ambos balanceadores «funcionando».
• Conmutación automática de base de datos con dos nodos. Sin quórum, una partición de red produce dos primarios y datos divergentes. Manual, hasta que haya tres nodos.
• Desactivar el fencing «temporalmente». Es la configuración que provoca la corrupción de datos el día del fallo. Un clúster sin fencing no es fiable.
• Comprobaciones de salud superficiales. Un /salud que solo dice «estoy vivo» hace que el balanceador envíe tráfico a un nodo que no puede atender nada.
• Comprobaciones de salud demasiado profundas. Un fallo de la base de datos marca todos los nodos como caídos, cuando podrían haber servido algo.
• Sacar un nodo al primer fallo. Un pico transitorio saca el nodo, la carga se concentra en los demás, y caen en cascada. fall 3 y slowstart.
• Olvidar que los timers se ejecutan en todos los nodos. Dos copias de seguridad simultáneas, dos purgas. El flock es local y no protege.
• Sesiones persistentes como solución permanente. Enmascara el problema real, desequilibra la carga, y cuando un nodo cae pierde todas sus sesiones.
• Creer que la replicación sustituye a las copias. Un borrado accidental se replica en milisegundos. La redundancia protege del fallo de hardware, no del error humano.
• NFS sin redundancia para dar alta disponibilidad. Añades un punto único de fallo del que ahora dependen dos servidores.
• No probar los fallos. Un sistema de alta disponibilidad no probado es una arquitectura que crees que funciona.
• Consejo de método. Antes de diseñar nada, fija el objetivo de disponibilidad y mide el actual. Sin esos dos números, cualquier inversión es una intuición disfrazada de arquitectura.

Diseña el extremo /salud que debe exponer la aplicación para que HAProxy tome buenas decisiones. Especifica qué comprueba, qué no, qué códigos devuelve y con qué latencia, y explica cómo se relaciona con revision_salud.sh.

Escribe el rol de Ansible que despliega la configuración de HAProxy y keepalived en los dos balanceadores, teniendo en cuenta que la configuración difiere entre ellos y que aplicarla mal deja el servicio sin IP.

Marta pregunta directamente: «¿Necesitamos alta disponibilidad?». Redacta la respuesta con el análisis completo y una recomendación clara.

Solución 1

Diseño del extremo /salud:

Los tres estados y su respuesta:

La relación con revision_salud.sh es la parte conceptual del ejercicio. Ambos responden a la misma pregunta desde lados distintos, y esa complementariedad hay que aprovecharla en lugar de duplicar trabajo:

Lo correcto es que revision_salud.sh consuma /salud en lugar de reimplementar las comprobaciones:

Cuatro decisiones de diseño que hay que justificar:

1. El estado degradado devuelve 200, no 503. Es contraintuitivo y es correcto: si el almacén de ficheros falla, el nodo puede seguir atendiendo consultas de disponibilidad, que son la mayoría del tráfico. Sacarlo del reparto reduciría la capacidad sin ganar nada. La cabecera permite que la monitorización lo detecte sin que el balanceador actúe.
2. Latencia acotada por diseño. Con 3 segundos de intervalo y dos nodos, son 40 peticiones por minuto. El objetivo es menos de 50 ms, y de ahí que las comprobaciones caras estén cacheadas 30 segundos.
3. Sin autenticación, pero restringido por red. Debe ser accesible sin credenciales para que HAProxy lo consulte, y no debe estar expuesto a Internet: el detalle del JSON es información útil para un atacante. Se bloquea en el frontend:

   http-request deny if { path_beg /salud } !{ src 10.0.2.0/24 }
   

4. Sin efectos secundarios y sin bloqueo. Un /salud que escribe en la base de datos o toma un bloqueo puede provocar el fallo que pretende detectar. La comprobación de escritura del almacén va cacheada y en segundo plano.

Y la advertencia final, que es el error más común: /salud no debe comprobar dependencias que no son propias de este nodo. Si comprobara el estado de la base de datos con una consulta pesada, un problema de PostgreSQL sacaría todos los nodos a la vez y el servicio desaparecería por completo, cuando podría haber devuelto al menos una página de error decente.

Solución 2

Y el play que garantiza el despliegue de uno en uno:

Las decisiones que evitan dejar el servicio sin IP:

Y lo que hay que añadir al runbook: este rol se prueba primero en el entorno de pruebas con dos balanceadores virtuales, y en producción se ejecuta con --check --diff antes que en serio. La virtual_router_id debe ser única en el segmento de red: dos clústeres VRRP con el mismo ID en la misma red interfieren entre sí, y es un fallo desconcertante de diagnosticar.

Solución 3

¿Necesita Tramontana Reservas alta disponibilidad? Para: Marta Vidal · De: Operaciones de sistemas · 18 de agosto de 2026

Respuesta breve: alta disponibilidad completa, no. Un primer paso, sí, y con una relación coste-beneficio muy favorable. Recomiendo dos servidores de aplicación con un balanceador, que captura la mayor parte del beneficio por una fracción del coste.

---

Primero, un dato que nos falta. No tenemos un objetivo de disponibilidad acordado ni la medimos. Estimo que estamos alrededor del 99,5 %, unas 44 horas de caída al año, contando reinicios por actualización, despliegues y algún incidente. Es una estimación, no un dato, y lo primero que propongo es empezar a medirlo — cuesta muy poco y sin ese número cualquier inversión es una intuición.

Lo que ya hemos conseguido sin gastar nada. La disponibilidad depende de dos cosas: con qué frecuencia falla el sistema y cuánto tarda en recuperarse. En las últimas semanas hemos reducido drásticamente lo segundo: reconstruir el servidor por completo ha pasado de ocho horas a cincuenta minutos, automatizando su configuración. Eso ya ha mejorado la disponibilidad sin comprar una sola máquina, y es la clase de mejora que hay que agotar antes de duplicar infraestructura.

Qué costaría estar caídos. Con unas 500 reservas mensuales de 313,70 € de media, el ingreso medio es de unos 218 € por hora. Ese número hay que matizarlo en tres sentidos:

• Las reservas se concentran por la tarde y en fin de semana. Una caída de madrugada un martes puede no costar nada; la misma un viernes por la tarde cuesta bastante más que la media.
• Muchos clientes que encuentran la web caída vuelven a intentarlo. El coste real está probablemente entre el 20 % y el 50 % de la cifra bruta.
• Hay un coste de imagen, no lineal y difícil de cuantificar, sobre todo si coincide con una campaña.

Con una estimación prudente (35 %):

Disponibilidad	Caída al año	Coste estimado
99,5 % (situación actual)	44 h	~3.340 €
99,8 %	17,5 h	~1.330 €
99,9 %	8,8 h	~670 €

Las tres opciones, con su coste real.

	Qué incluye	Inversión	Disponibilidad	Ahorro anual
A. No hacer nada	Lo actual	0	~99,5 %	—
B. Dos servidores + balanceador	2 máquinas, 1 semana de trabajo	Baja	~99,8 %	~2.000 €
C. Arquitectura completa	4 máquinas, 6 semanas, +4 h/mes	Alta	~99,9 %	~2.670 €

Lo importante está en la comparación entre B y C: la opción C cuesta varias veces más que la B y aporta apenas 670 € adicionales de ahorro anual. La razón es que los primeros nueves son baratos y los siguientes se encarecen mucho — y, sobre todo, que la mayoría de nuestras interrupciones no vienen de fallos de hardware, sino de despliegues, reinicios y mantenimiento, y eso se resuelve entero con la opción B.

Qué nos daría exactamente la opción B:

• Despliegues sin interrupción. Hoy cada despliegue son unos segundos de servicio cortado. Con dos servidores se actualiza uno mientras el otro atiende, y el cliente no nota nada.
• Mantenimiento sin ventana. Reiniciar por un kernel nuevo deja de ser una interrupción programada.
• Tolerancia al fallo de un servidor de aplicación. El sistema lo detecta en menos de diez segundos y deja de enviarle tráfico solo.
• Capacidad para picos, como beneficio secundario.

Qué NO nos daría, y hay que decirlo con claridad:

• Si cae la base de datos, el servicio cae. La promoción de la réplica sería manual, de 5 a 15 minutos.
• Si cae el balanceador, el servicio cae. Es la opción C.
• Si cae la infraestructura del proveedor, todo cae.
• Y nada de esto protege contra un borrado accidental o una corrupción de datos: eso se replicaría al instante a todos los nodos. Para eso están las copias, que seguirían siendo igual de necesarias.

Hay una condición previa que no es técnica de sistemas. Tramontana Reservas guarda hoy dos cosas dentro de cada servidor: las sesiones de las personas que navegan, y las fotos que se suben. Con dos servidores, quien iniciara sesión en uno aparecería desconectado al ser atendido por el otro, y una foto subida a uno no se vería desde el otro. Antes de montar nada hace falta trabajo de desarrollo —externalizar las sesiones y guardar los ficheros en un almacén compartido—, unas tres o cuatro semanas. Es la parte del proyecto que hay que planificar con Luis, y sin ella la opción B no funciona.

Y una advertencia profesional. La redundancia añade piezas, y cada pieza puede fallar de formas nuevas. Un sistema mal montado es menos fiable que uno simple bien mantenido. Por eso no recomiendo la opción C: la complejidad que añade —replicación, promoción, riesgo de que dos servidores escriban a la vez datos incompatibles— exige un nivel de vigilancia y de pruebas que hoy no podemos sostener con la plantilla actual. Es mejor una arquitectura sencilla que entendemos y probamos que una sofisticada que nadie ha ensayado.

Recomendación, en tres pasos.

1. Este mes, coste cero: fijar un objetivo formal de disponibilidad —propongo 99,8 %— y empezar a medirla. Con eso podremos decidir con datos en lugar de con estimaciones.
2. En dos o tres meses: desarrollo de las dos condiciones previas, y despliegue de la opción B. Empezaría con un solo balanceador, asumiendo que es un punto único de fallo pero mucho menos propenso a caer que la aplicación completa.
3. Revisar en un año, o antes si cambia algo: si el volumen de reservas crece de forma significativa, si una caída nos cuesta un cliente importante, o si medimos una disponibilidad peor de lo estimado.

Y una última cosa. Aparte de todo lo anterior, quiero programar un simulacro semestral: provocar los fallos a propósito, en horario laboral, y comprobar que la recuperación funciona. Un sistema de respaldo que nunca se ha probado es un sistema del que no sabemos nada, y esto vale tanto para la arquitectura futura como para el procedimiento de reconstrucción que ya tenemos. El primero, en septiembre.

Sabes de qué se habla cuando se habla de alta disponibilidad, y con la precisión que el tema exige. Los nueves tienen números concretos —99,99 % es menos de un minuto de caída a la semana—, la disponibilidad se descompone en MTBF y MTTR, y reducir el MTTR suele ser mucho más barato que aumentar el MTBF: es exactamente lo que hiciste en 07-06 al bajar la reconstrucción de ocho horas a cincuenta minutos, sin comprar nada. Sabes que el escalado vertical no aporta disponibilidad, que un nodo pasivo que nunca se usa es un nodo del que no sabes nada, y sobre todo que el estado es el problema difícil: las sesiones, los ficheros subidos y las tareas programadas son lo que impide duplicar un servidor sin más.

Has montado un balanceador con HAProxy que reparte por leastconn, sondea la salud cada tres segundos con fall 3 y rise 2 asimétricos, devuelve los nodos con slowstart para no tumbarlos de nuevo, y permite drenar conexiones para desplegar sin cortar — resolviendo lo que quedó pendiente desde 04-07. Le has dado redundancia con keepalived y una IP virtual flotante, con el track_script que evita el fallo más tonto de esta arquitectura: un balanceador con keepalived vivo y HAProxy muerto reteniendo la IP. Y conoces los dos conceptos sin los cuales todo esto es teatro: el split-brain, que con dos nodos no se puede evitar porque no hay quórum posible, y el fencing, sin el cual un clúster no es fiable por mucho que arranque.

Y has hecho el análisis que Marta llevaba tres lecciones pidiendo, con la conclusión que no siempre gusta: la arquitectura completa no compensa. Dos servidores de aplicación con un balanceador capturan la mayor parte del beneficio por una fracción del coste, porque la mayoría de las interrupciones no vienen de fallos de hardware sino de despliegues y mantenimiento. Que la respuesta profesional a «¿necesitamos alta disponibilidad?» pueda ser «una parte, y por este orden» es tan importante como saber montarla. Junto con la advertencia que cierra el asunto: la redundancia mal hecha empeora la fiabilidad, y un sistema sencillo que se entiende y se prueba vale más que uno sofisticado que nadie ha ensayado.

Con esto se cierra el Módulo 7, y con él la parte más avanzada del curso. Has aprendido a mirar dentro del sistema: la cadena de arranque completa y cómo intervenir cuando se rompe, el diagnóstico con strace, perf y eBPF cuando los contadores no bastan, y el ajuste del kernel con la regla de no tocar lo que no se ha medido. Y has aprendido a multiplicarlo: virtualización con KVM y el entorno de pruebas que el curso echaba en falta desde el Módulo 4, contenedores entendidos como lo que son —procesos aislados, no máquinas pequeñas—, automatización con Ansible que convirtió la configuración en código y el RTO en cincuenta minutos, y por fin la redundancia que quita a srv-tramontana su condición de punto único de fallo.

En el Módulo 8: Proyectos Prácticos todo eso se aplica a construcciones completas, de principio a fin. Montarás un servidor web con Nginx como proxy inverso y TLS delante de la aplicación — y ahí se cierra por fin el cifrado en tránsito que quedó preparado en 06-05 y lleva desde entonces esperando. Configurarás un servidor de base de datos PostgreSQL en condiciones, con su ajuste, sus copias y su replicación. Construirás un servidor de medios doméstico, que es el proyecto donde comprobar que todo lo aprendido se aplica igual fuera del trabajo. Levantarás un servidor VPN con WireGuard para acceder a la red interna sin exponer nada. Desplegarás un clúster de Kubernetes, que es donde los contenedores de 07-05 y la orquestación se juntan. Y cerrarás con la puesta en producción: la checklist completa, la monitorización con Prometheus y Grafana que se mencionó en 05-07, y el procedimiento de operación diaria de un sistema que ya no es un laboratorio. Actualiza el snapshot de tu VM y nos vemos allí.