25 publicaciones etiquetados con "Sistemas Distribuidos"

La mayoría de las formas de poner autenticación delante de un almacén de datos distribuido acaban por añadir un segundo sistema distribuido para hacerla funcionar: un servicio de autenticación al que llamar, una base de datos de sesiones que replicar, un endpoint de introspección de tokens que cada nodo tiene que alcanzar en la ruta caliente. Aseguraste el almacén y te compraste una nueva dependencia de disponibilidad y una nueva fuente de latencia.

Zaris toma una ruta distinta, y es una deliberadamente aburrida: una clave de firma por clúster, y tokens que cualquier nodo puede verificar por sí mismo. Un token es un JWT firmado con la clave privada del clúster; cada manager y cada nodo tiene la mitad pública y comprueba la firma sin conexión — sin llamada a un servidor de autenticación, sin quórum, sin consulta a una base de datos. La seguridad está desactivada por defecto, y un clúster con ella desactivada se comporta exactamente como uno no asegurado. Esta entrada trata de qué se activa cuando lo enciendes: la forma del token, el modelo de roles-y-ámbitos, los dos planos donde realmente ocurre la aplicación y — porque fingir lo contrario es cómo la gente adquiere una falsa sensación de seguridad — los bordes operativos que es fácil equivocar.

Dos eventos de aspecto muy diferente en un almacén distribuido resultan ser el mismo problema por debajo. El primero: una réplica se queda atrás de su primario — una pausa de GC, un disco lento, una breve partición de red — y ahora sostiene una copia obsoleta de una partición que debe eventualmente igualar. El segundo: una partición se reasigna a un nodo que nunca la ha tenido, y ese nodo debe adquirir el conjunto de datos entero del propietario actual. Uno es lag de replicación; el otro es migración. Tienen disparadores diferentes, operadores diferentes, historias de fallo diferentes.

Pero la pregunta que cada uno tiene que responder es idéntica: ¿cómo converjo a la verdad actual de esta partición sin congelar las escrituras mientras lo hago? Zaris responde a ambos con un único mecanismo — un log de operaciones ordenado por revisión mantenido por segmento, reproducido desde un punto conocido. Este post trata de ese log: cómo se construye en el camino de escritura, cómo se acota para que no pueda crecer sin límite, cómo se reproduce, y por qué el exacto mismo sustrato lleva tanto a una réplica rezagada como a un propietario completamente nuevo a la convergencia.

El camino feliz de un almacén clave-valor distribuido es fácil de acertar. Una escritura llega al primario, se transmite a las réplicas, todos están de acuerdo y sigues adelante. Si esa fuera toda la historia, la durabilidad sería un problema resuelto y esta entrada no existiría.

Los problemas difíciles viven en las costuras: los momentos breves e incómodos en los que el clúster está en plena transición. Un nodo se reinicia en medio de una migración de partición. Una réplica se queda muy rezagada respecto al activo del que está copiando, y entonces ese activo conmuta por error hacia otro. La propiedad de una partición se mueve a un nodo nuevo mientras aún hay escrituras en vuelo hacia el antiguo. Cada una de ellas es una ventana: un lapso de unos segundos en el que, si el traspaso no es exactamente correcto, una escritura confirmada —una que se le dijo al cliente que había tenido éxito— puede desaparecer silenciosamente. No porque el motor de almacenamiento tenga errores, sino porque dos partes del sistema discreparon, por un instante, sobre quién era dueño de la verdad.

Esta entrada trata sobre cómo Zaris cierra esas ventanas y —la parte que realmente importa— cómo nos convencimos de que funciona, ejecutando el clúster bajo caos continuo y deliberado durante doce horas seguidas.

Zaris 2.0.1 ya está disponible. Es una actualización directa desde 2.0.0 —mismo protocolo de cable, misma API de cliente, mismos formatos en disco y en memoria— y hace dos cosas que valen la pena actualizar: hace que el camino de propiedad y recuperación del clúster sea significativamente más durable bajo fallos, y le da a Zaris un modelo de prueba y licencia integrado y limpio para que puedas evaluarlo y ejecutarlo en producción sin fricción.

La capacidad nunca es la adecuada por mucho tiempo. El tráfico crece, llega un lanzamiento, termina una temporada — y el almacén que dimensionaste el trimestre pasado está o bien al límite o bien medio ocioso. La pregunta que decide si eso es una tarea o una crisis es simple: ¿puedes cambiar el tamaño de un almacén en marcha sin tumbarlo?

Para Zaris la respuesta es sí, con una asimetría importante que vale la pena reconocer de entrada. Escalar hacia afuera — añadir servidores — es la dirección fácil, segura y sin pérdidas, y ocurre en vivo mientras el almacén sigue sirviendo. Escalar hacia adentro — quitar servidores — también está soportado, pero es una operación deliberada y monitorizada porque la data del servidor que se va tiene que ir a algún sitio primero.

Este post recorre ambas direcciones: hacer crecer un almacén con Add-ZrServer, reducirlo con Remove-ZrServer, por qué la reducción necesita un drain, y dónde encaja la consola web.

La mitad de los bugs de conexión "funciona en dev, se rompe en prod" se reducen a lo mismo: los detalles de conexión se escribieron de tres formas diferentes en tres lugares diferentes. El appsettings.json tenía una lista de hosts, el runbook de operaciones pegó otra en una sesión de PowerShell, y la cadena que alguien copió de una wiki tenía un token obsoleto incrustado directamente en ella.

Zaris saca de la mesa toda esa clase de problema con un único formato de connection string agnóstico de plataforma. La exacta misma cadena funciona cuando tu aplicación .NET la lee de la configuración, cuando un operador se la entrega a un cmdlet de PowerShell, y cuando alguien la copia directamente de la consola web. Una ortografía canónica, en todas partes.

Este post desglosa la cadena parte por parte, muestra las tres formas de usarla, y defiende la única regla que más importa en producción: nunca pongas un token en crudo en la cadena.

La forma más rápida de asegurarte de que TLS se omita es forzar un único modelo de confianza sobre todos. Un desarrollador que ejecuta un almacén en una laptop no quiere levantar una CA. Un banco con una raíz offline en un HSM no quiere que tu herramienta acuñe certificados en absoluto. Entrega un almacén que solo conozca uno de esos casos, y la mitad de tus usuarios desactivarán la seguridad para poder trabajar.

Por eso Zaris no elige por ti. Su confianza TLS es enchufable a lo largo de cuatro modos de autoridad certificadora, desde el autofirmado sin configuración hasta certificados que aprovisionas enteramente fuera de banda. Eliges el modo que coincide con la PKI que ya ejecutas, y Zaris encaja en ella en lugar de pedirte que la reconstruyas a su alrededor. TLS no es una talla única, y tratarlo así es exactamente por qué la seguridad se pospone.

Ejecuta Zaris en Kubernetes y el camino feliz es sencillo: los clientes dentro del clúster alcanzan los pods por sus direcciones internas — IPs de pod y nombres de DNS del clúster como zaris-0.zaris.svc — y todo se enruta limpiamente. En el momento en que un cliente vive fuera del clúster, eso se rompe. Una aplicación externa no puede marcar zaris-0.zaris.svc ni una IP de pod; esos nombres y direcciones solo resuelven y enrutan dentro de la red del clúster.

Esto no es una rareza de Zaris — es la división fundamental entre la red interna del clúster y el mundo exterior. Muerde con más fuerza a los clientes conscientes de la topología. Un cliente Redis en modo cluster, o cualquier cliente que descubre nodos y enruta por clave, obtiene un mapa de topología del servidor y se conecta a las direcciones que contiene. Si esas direcciones son internas, un cliente externo recibe un mapa lleno de endpoints que nunca podrá alcanzar.

Zaris resuelve esto con direcciones anunciadas, gestionadas como una "vista de frontera" por listener.

Zaris expone un front-end con protocolo Redis (RESP) para que cualquier cliente Redis, en cualquier lenguaje, pueda apuntar a un clúster de Zaris y usarlo como almacén drop-in. Pero "cualquier cliente Redis" esconde un problema real: los ecosistemas de clientes Redis no se ponen de acuerdo sobre cómo descubrir la topología ni cómo recuperarse cuando un nodo desaparece. Un cliente simple espera un único endpoint estable. Un cliente basado en Sentinel espera preguntarle a un servicio de descubrimiento "¿quién es el master?". Un cliente en modo cluster espera hash slots y redirecciones MOVED/ASK.

Si un almacén hablara solo uno de esos dialectos, toda una clase de clientes quedaría excluida. Por eso el front-end RESP de Zaris admite tres modelos de failover, cada uno acorde a cómo ya espera funcionar una familia concreta de clientes Redis. Eliges el modelo por despliegue; el cliente se comporta exactamente como lo haría contra Redis real.

Una nota honesta de entrada, porque condiciona todo lo que sigue: los tres modelos se sitúan delante del mismo almacén Zaris replicado y particionado. El modelo que elijas cambia la semántica de descubrimiento y redirección — cómo un cliente encuentra un nodo y qué hace cuando uno falla — no dónde reside realmente tu data.

Zaris ya habla en colecciones: hashes, listas, conjuntos y conjuntos ordenados que viven en el servidor y se replican como cualquier otra clave. Los Streams son el quinto tipo, y son el que convierte a Zaris de un almacén en una pieza de infraestructura de mensajería.

Un stream de Zaris es un verdadero registro de solo anexado: las entradas obtienen IDs monótonos, puedes leer rangos y puedes adjuntar grupos de consumidores para que un grupo de trabajadores se reparta el registro entre ellos, haga seguimiento de las entradas pendientes por consumidor y confirme lo que ha procesado. También puedes hacer una lectura bloqueante: un consumidor se detiene y espera a que lleguen nuevas entradas en lugar de iterar en caliente.

Y como es una colección nativa de Zaris, el registro está particionado y replicado exactamente como todo lo demás. Un stream sobrevive a la conmutación por error de un nodo, que es la razón misma para recurrir a la mensajería duradera en primer lugar.