Qué garantiza un clúster Raft: mayorías, un solo líder y lecturas linealizables

Qué es

La página del proyecto Raft (citada) describe el consenso como el acuerdo de varios servidores sobre valores; una vez alcanzada una decisión, es definitiva. Los algoritmos de consenso habituales avanzan mientras cualquier mayoría de sus servidores esté disponible (un clúster de cinco continúa con dos caídos); con más fallos dejan de avanzar, pero nunca devuelven un resultado incorrecto. Raft aplica esto a una máquina de estados replicada: cada servidor mantiene un registro de comandos, y el algoritmo garantiza que, si un servidor aplica un comando como la entrada n-ésima, ningún otro servidor aplica jamás una entrada n-ésima distinta. Raft está basado en un líder; la página del proyecto lo describe como descompuesto en subproblemas relativamente independientes, que el artículo de Raft denomina elección de líder, replicación del registro y seguridad.

La documentación de etcd (citada) indica qué obtiene el cliente: linealización, la ilusión de que cada operación surte efecto en un único instante entre su invocación y su respuesta, de modo que una lectura devuelve el valor más reciente. Las solicitudes linealizables pasan por el proceso de consenso de Raft; en su lugar, una solicitud puede marcarse como serializable para servirse localmente con menor latencia, a riesgo de devolver datos desactualizados.

Por qué importa

Pocos equipos implementan el consenso, pero muchos dependen de él indirectamente: el estado de Kubernetes en etcd, el descubrimiento de servicios, los bloqueos distribuidos, la configuración. Conocer las garantías indica qué esperar durante un incidente: un clúster que ha perdido su mayoría rechaza las escrituras y las lecturas linealizables en lugar de divergir, y un clúster de dos miembros no tolera ningún fallo.

Cómo aplicarlo

• Ejecutar un número impar de miembros, tres o cinco; un número par no añade tolerancia a fallos porque el umbral de mayoría sube con él.
• Ubicar los miembros en dominios de fallo separados, de modo que perder un dominio siga dejando una mayoría.
• Elegir el modo de lectura por llamada: linealizable donde una respuesta desactualizada provoque decisiones equivocadas (concesiones, bloqueos, contadores), serializable para lecturas de gran volumen que toleren el desfase.
• Mantener las entradas pequeñas y el conjunto de datos modesto; cada escritura se replica a una mayoría y se hace duradera antes de confirmarse, por lo que la latencia de sincronización a disco acota el rendimiento.
• Usar escrituras condicionales (comparar la revisión actual y luego actualizar) en lugar de leer-y-luego-escribir desde el cliente; el consenso ordena el registro, no hace atómicas dos llamadas del cliente.

Trampas

Una escritura que agota su tiempo de espera puede haberse confirmado de todos modos; reintentar solo con una operación idempotente. Un servidor que fue líder puede no saber todavía que ha sido reemplazado, por lo que las lecturas basadas en el líder necesitan una comprobación explícita y por lo que quienes sostienen una concesión (lease) siguen necesitando un mecanismo de exclusión (fencing). Perder el quórum es una interrupción de las escrituras, no de los datos.

Dos sedes no bastan

Sobrevivir con mayoría al fallo de un dominio requiere al menos tres dominios de fallo. Entre dos sedes, tres miembros repartidos dos y uno pierden el quórum si falla la sede mayor, y cuatro repartidos de forma pareja lo pierden si falla cualquiera de las dos; ninguna disposición ayuda. Con solo dos sedes, conviene elegir deliberadamente: colocar la mayoría donde se ejecuta la carga de trabajo y aceptar que perder esa sede detiene las escrituras; añadir un tercer miembro pequeño en una ubicación separada como desempate, aceptando que su latencia de ida y vuelta acota ahora las confirmaciones; o mantener el clúster en una sola sede y usar la segunda como destino de respaldo en vez de como participante en el consenso.