Sistemas Distribuidos

Basado en los apuntes de Unmesh Joshi

¿Qué significa que un sistema sea distribuido?

Corre en varios servidores, de 1 a N según el porte del cluster
Manejan datos y por lo tanto son sistemas que tienen un estado

Los sistemas distribuidos, en términos simples son sistemas donde las responsabilidades y tareas están divididas entre varios servidores, esto si bien puede sonar totalmente positivo, llevar las soluciones que utilizamos a nivel local a un esquema distribuido implica ponerse a pensar y solucionar nuevos problemas inherentes a la distribución.

Cuando tenemos datos que están guardados en multiples servidores empiezan a aparecer problemas.

Los Procesos fallan

En cualquier momento y por multiples causas pueden morir los procesos, algunos ejemplos son:

Se destruye un proceso porque el servidor esta en proceso de mantenimiento.
Se destruye porque no hay mas recursos de hardware disco, cpu, etc.
Por trabajar en un contexto cloud, puede haber eventos no relacionados al servidor que lo tiren (se me ocurre saturación de la red de un rack)

Los procesos son reesponsables de guardar los datos, y por lo tanto tienen que estar diseñados para dar durabilidad y garantizar el estado de esos datos. Incluso ante la caída abrupta de un proceso hay que preservar toda la data que se le dijo al cliente que habíamos recibido y guardado.

La solución para esto puede ser utilizar WAL y/o tener la información distribuida entre varios nodos.

Problemas de red

Entonces que sucede si nuestra información esta en N (siendo N>1) servidores, como hacemos para que cada servidor, sepa que otros servidores están disponibles (y por lo tanto con quien deben sincronizarse la data, por ejemplo el WAL).

En el protocolo TCP/IP no hay un limite superior a las demoras que puedan existir en la transmisión de mensajes a través de la red. Por mas grande que sea el ancho de banda, un cliente de la red puede generar una saturación de la red generando problemas de demora a otros clientes.

Por lo tanto, ¿cuánto tiempo debe esperar un servidor la respuesta de otro, para darlo por muerto?

Para esto se utiliza el HeartBeat, donde periódicamente por ejemplo cada servidor envía un mensaje al resto, si alguno no contesta, se lo marca como no disponible y el cluster sigue con su tarea.

Pero, si el cluster tuviera 5 servidores, 2 en la costa oeste de AWS y 3 en la este, y por un problema de red dejaran de verse estos datacenters, ¿que pasa si un cliente manda una escritura y luego una lectura, y estas son atendidas por un servidor de cada lado?

A esto se le conoce como Split Brain, donde si ambos “conjuntos” de servidores aceptan las operaciones que les llegan, no habría consistencia de datos de cara al cliente, además de que una vez que vuelvan a unirse las 2 zonas, no habría manera de resolver los conflictos.

Para evitar esto, debemos tener un mecanismo, que para 2 conjuntos de servidores que están desconectados entre ellos, impida que ambos conjuntos continúen operando. Para lograr esto, cada operación en un servidor es considerada exitosa solo si la mayoría de los nodos del cluster la confirman. Esto genera que si un servidor no puede conseguir mayoría, entonces no podrá brindar su servicio y algunos clientes verán errores, pero el cluster va a mantener un estado consistente. A la cantidad de nodos necesarios para hacer mayoría se le llama Quorum.

Ahora que tenemos Quorum, sabemos que vamos a tener suficientes copias de cada dato, para soportar la caída de algunos nodos. Pero que sucede si cuando mandamos una operación de escritura, esta solo se logra impactar en un nodo, y en ese momento vamos a hacer una lectura del Quorum. Aqui podriamos tener 2 respuestas:

Si el nodo donde escribimos exitosamente esta levantado entonces podríamos obtener la respuesta correcta.
Si el nodo donde escribimos esta caído, obtendriamos un valor viejo.

Para evitar estas situaciones, alguien tiene que llevar al día los acuerdos del quorum para cada operación y solo darle a los clientes valores que esten disponibles en todos los nodos. Para esta coordinación se utiliza la técnica de Lider y Seguidores.

Ahora que tenemos un Lider, este debe decidir, que cambios ya estan disponibles para ser visibles por los clientes y cuales aun no fueron replicados por el cluster. Para este problema se utiliza la High Water Mark que trackea la operación en el WAL que se tiene confirmación de que fue replicada a un Qourum de seguidores. Cualquier operación del WAL menor a la HighWater Mark es visible para los clientes del cluster y además el líder mantiene esa marca actualizada en los seguidores para que la conozcan por si tienen que pasar a ser Lideres.

Procesos pausados

Pendiente