Meter un cuarto servidor en Consul no dio más tolerancia: dio un apagón de 34 minutos
Un equipo migraba Consul a otra sala con la regla de no bajar nunca de tres nodos. El cuarto servidor no añadió tolerancia y sí una forma nueva de perder el quórum.

En marzo empezaron a mover sus servidores de Consul a una sala nueva del centro de datos, de uno en uno, para no bajar nunca de tres nodos. El martes por la tarde entró el primero de los nuevos y esa misma noche un switch entre las dos salas se reinició durante un mantenimiento programado. El descubrimiento de servicios de toda la plataforma dejó de aceptar escrituras durante 34 minutos.
Consul, como etcd y ZooKeeper, solo acepta una escritura cuando la mayoría de sus servidores está de acuerdo. Con tres nodos la mayoría son dos, así que puedes perder una máquina. Con cuatro la mayoría son tres, así que sigues pudiendo perder exactamente una. El cuarto no compró tolerancia y añadió un modo de fallo que antes no existía: cuatro se parten en dos y dos.
Eso fue lo que hizo el switch. Dejó dos servidores viejos en la sala antigua y uno viejo más el nuevo en la nueva. Ningún lado llegaba a tres, así que ninguno podía elegir líder. Los clientes que permitían lecturas obsoletas siguieron respondiendo y los servicios en marcha se seguían encontrando entre sí, pero todo lo que necesitara una escritura se paró. Los despliegues no registraban instancias nuevas. Los resultados de los health checks no se guardaban, así que un nodo que se estropeó durante la partición siguió recibiendo tráfico. Y dos equipos que elegían líder para sus trabajos por lotes mediante sesiones de Consul se quedaron sin líder.
Nunca menos de tres
Lo llamativo es que el plan parecía conservador. "Nunca menos de tres" suena a seguridad. La cifra que importaba no era cuántos servidores tenían, sino cuántos podían caerse, y dónde, antes de que el resto dejara de ser mayoría. Con tres podían perder cualquier máquina. Con cuatro repartidos a medias sobre un enlace que no controlaban, podían perder un switch.
Terminaron la migración añadiendo y quitando servidores por pares, de forma que cada estado intermedio tuviera un número impar, y anotaron qué fallo sobrevivía cada estado antes de empezarlo. Ahora el clúster corre con cinco nodos repartidos en tres salas, colocados para que ninguna sala por sí sola tenga mayoría, y un script comprueba esa ubicación contra el inventario de racks antes de autorizar cualquier cambio de membresía.
Un voto de mayoría no premia añadir votantes: premia dónde se sientan. Un número par de nodos suele significar pagar por un servidor que le da al apagón una vía más de entrada.


