El mapa de dominios de fallo, y la prueba de relevo que lo demuestra

Todo diagrama de plataforma tiene tres cajas de base de datos, dos balanceadores de carga y una pareja de caché, y todas ellas llevan la etiqueta «alta disponibilidad». Que lo sea depende de dos documentos que la mayoría de las construcciones nunca produce: un mapa de qué cosas físicas necesita cada réplica, y una hoja de pruebas que registre qué pasó cuando se quitó cada una de ellas. Así escribimos nosotros los dos.

El problema: tres réplicas pueden ser un solo fallo

La redundancia cuenta copias. La disponibilidad depende de si esas copias pueden fallar de forma independiente. Tres nodos de base de datos en tres máquinas virtuales que el planificador colocó por casualidad en dos hosts son, ante un fallo de host, dos nodos. Tres nodos en tres hosts cuyos discos viven todos en una misma cabina de storage son, ante un fallo de cabina, ninguno. Nada en la aplicación ni en el dashboard se lo dice. Tiene que escribirlo.

Paso uno: liste los dominios de fallo

Para una plataforma típica, liste al menos:

• Host: el servidor físico o el blade.
• Chasis: los blades comparten alimentación, refrigeración e interconexiones.
• Cabina de storage: y, por debajo, la ruta del fabric de storage.
• Red: la pareja de switches top of rack, los uplinks, el edge.
• Sede: la acometida eléctrica, la refrigeración, el propio edificio.

Después decida cuáles debe sobrevivir la plataforma. Sobrevivir a la pérdida de cualquier host y de cualquier cabina es una base razonable; sobrevivir a una sede entera necesita una segunda sede y es un diseño distinto.

Paso dos: dibuje el mapa

Haga una tabla con una fila por miembro de cada capa redundante y una columna por dominio de fallo:

Capa	Miembro	Host	Chasis	Cabina
database	db-a	host 1	enclosure 1	array A
database	db-b	host 2	enclosure 2	array B
database	db-c	host 3	enclosure 1	array C
cache	cache-a	host 2	enclosure 2	array A
...

La regla es sencilla: dentro de una capa, ningún dominio de fallo que haya decidido sobrevivir puede contener una mayoría de los miembros. Lea cada columna hacia abajo para cada capa. Dos de tres miembros de la base de datos en enclosure 1 significa que un fallo del chasis rompe el quórum. Corrija la colocación, o acepte el riesgo por escrito.

Paso tres: haga bien la aritmética del quórum

Si necesita sobrevivir a dos fallos de host simultáneos, como a menudo debería una capa de storage, necesita cinco miembros en cinco dominios separados, no cuatro: un cuarto miembro añade coste sin añadir tolerancia.

Paso cuatro: haga que el planificador imponga el mapa

Un mapa que depende de que alguien coloque bien las máquinas estará equivocado después del primer mantenimiento. Haga que la plataforma lo imponga.

En un gestor de virtualización como OLVM, cree un grupo de afinidad negativo y de cumplimiento obligatorio por capa, para que dos miembros nunca puedan correr en el mismo host, ni siquiera después de vaciar un host.

En Kubernetes, use pod anti-affinity obligatoria y un PodDisruptionBudget para cada carga de trabajo con quórum:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      [ { labelSelector: { matchLabels: { app: galera } },
          topologyKey: kubernetes.io/hostname } ]

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: galera }
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: galera }

La anti-afinidad mantiene a los miembros en nodos distintos; etiquete los nodos por chasis y añada una segunda regla sobre esa etiqueta si los chasis son un dominio. El budget significa que una actualización progresiva de nodos nunca puede expulsar a un segundo miembro mientras uno ya está caído. Compruebe el resultado, no la intención:

kubectl get pods -l app=galera -o wide

Paso cinco: la hoja de pruebas de relevo

Ahora demuéstrelo. Para cada capa, quite un miembro tal como lo haría un fallo real, con la aplicación conectada y tráfico real en marcha, y registre qué pasó:

Acción	Esperado	Medido	Qué vieron los clientes
detener el writer de la base de datos	el proxy mueve las escrituras a un superviviente	segundos hasta que se reanudan las escrituras
detener el primario de la caché	Sentinel promociona una réplica	segundos hasta la promoción
hacer fallar un nodo de edge	la dirección flotante pasa al par	segundos, en cada dirección
apagar un host	sus miembros se reconstruyen en otro sitio, el quórum se mantiene
desconectar un camino de la cabina	el tráfico de storage continúa por el otro camino

Ejecute un probe con marca de tiempo desde fuera durante cada prueba, para que «qué vieron los clientes» sea una medición:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://app.example.com/health
  sleep 0.2
done | tee failover-$(date +%F).log

Después restaure cada miembro y registre que se reincorporó limpiamente, como réplica del nuevo primario y no como rival suyo. Una prueba que termina con dos primarios ha encontrado el bug más importante de la hoja.

Paso seis: que lo verifique otra persona

La persona que construyó una plataforma lee las notas de construcción al comprobarla, y las notas de construcción dicen lo que se pretendía. Haga que un segundo ingeniero verifique el mapa contra la plataforma en vivo desde otra máquina: consulte al gestor de virtualización la colocación real, al storage la ubicación real de los discos, al clúster la pertenencia real. Las diferencias entre el mapa y la realidad son los hallazgos que importan.

Su lista de comprobación

• Los dominios de fallo que va a sobrevivir, por escrito.
• Un mapa de cada miembro de cada capa frente a esos dominios, sin mayoría en un solo dominio.
• Tamaños de quórum elegidos por aritmética, solo números impares.
• Anti-afinidad y disruption budgets impuestos por la plataforma, y comprobados.
• Una hoja de pruebas de relevo con tiempos medidos y resultados del lado del cliente para cada capa.
• Verificación independiente contra la plataforma en vivo, no contra las notas.

Si quiere una segunda opinión sobre lo independiente que es de verdad su redundancia, con gusto la mapeamos con usted.

Hable con un ingeniero

Related (rows[1])

Relacionado: Construcción de plataformas de alta disponibilidad · Bases de datos en clúster con Percona XtraDB Cluster · Caché de objetos con failover automático