Quorum

Basado en los apuntes de Unmesh Joshi

Pensemos en un sistema distribuido, donde para agregar tolerancia a caídas, la data se replica en el cluster.

¿Cuántos nodos necesitan conocer la información para que el dueño del dato tenga certezas de su capacidad de tolerancia?

• Si lo replicamos a todos los nodos demoraremos mucho en darle un OK al cliente que esta generando el dato, y ocuparemos el espacio del dato * la cantidad de nodos
• Si lo replicamos en un solo nodo, entonces no tenemos tolerancia a la caída de muchos nodos.

El quorum es una técnica para balancear estos dos extremos entre performance y tolerancia.

Significado

Si la mayoría de los nodos de un cluster dan el ok de que recibieron una operación (por lo cual esta escrita en sus WAL), decimos que el cluster acepta que recibió esa operación. Se conoce cómo Quorum a esta cantidad de nodos, si el cluster tiene N nodos, el quorum sera de (n/2+1).

La cantidad de fallos que un cluster soporta, esta dada por ClusterSize - Quorum.

Entonces para un cluster de 5 nodos tenemos que:

• Necesita 3 para poder dar OK a una operación.
• Soporta la caída de 2 nodos sin verse afectado.

Operaciones donde necesitamos un Quorum:

• Mantener data actualizada en el cluster : Se usa la High Water Mark para que solo la información disponible en la mayoría de los servidores este disponible para los clientes.
• Eleccion de un líder: En un esquema de Lider y seguidores, se necesita Qourum de votos para poder ser elegido.

Tipos

• Basados en un Líder: Zab, Paxos y Raft, donde la tarea de actualizar la data y replicarla se realiza en el lider. Mysql por ejemplo usa Paxos, MongoDB usa Raft desde la 3.4 y Zookeeper usa Zab.
• Sin Lider: Son más difíciles de implementar pero aseguran mas disponibilidad, se utilizan en protocolos de blockchain.

Consideraciones en contexto de replicación

1. Cada vez que escribimos en el cluster, la data debe ser replicada en varios nodos. Esto agrega un overhead a la operación por cada nodo adicional en el que hay que escribir, por lo cual los tiempos de escritura son directamente proporcionales a la cantidad de nodos en el quorum. Un análisis en zookeper

2. La cantidad de nodos que soporta el cluster que están caídos depende del tamaño del cluster, pero esto no significa que agregar 1 nodo al cluster lo haga mas robusto (recordemos el problema del Brain Split), por ejemplo un cluster de 3 o 4 nodos tiene la misma tolerancia a fallos.

Debido a esto, la mayoría de los sistemas basados en Quorum, tiene 3 o 5 nodos (hasta 7 seria aceptable). Con 5 nodos soportamos 2 caídas sin tener una penalización muy grande en la tasa de escritura.

Podemos ver una tabla con las diferentes configuraciones y sus características

Nodos	Quorum	Caidas	Carga
1	1	0	100
2	1	0	85
3	2	1	82
4	3	1	57
5	3	2	48
6	4	2	36
7	5	3	31

Ejemplos

• Elasticsearch
• La visualización interactiva de Raft, un algoritmo para conseguir consenso en sistemas distribuidos.
• En cassandra con el Consistency Level, se configura este tipo de tolerancia, la siguiente lista va de mayor tolerancia y menor latencia a la mayor latencia con la menor tolerancia para la operación de escritura:
  • ALL Si queremos que se escriba en todos los nodos
  • EACH_QUORUM Si queremos que se escriba en quorum de cada datacenter
  • QUORUM Si queremos que se escriba en quorum
  • LOCAL_QUORUM Si queremos que se escriba en quorum del datacenter actual
  • ONE queremos que se escriba en un nodo de replica
  • TWO queremos que se escriba en dos nodos de replica
  • THREE queremos que se escriba en tres nodos de replica
  • LOCAL_QUORUM Igual a ONE pero asegura que sea local al datacenter actual
  • ANY En un nodo sea cual sea.