16 publicaciones etiquetados con "Operaciones"

Un failover cubre el momento en que un propietario muere: el clúster elige un superviviente y sigue sirviendo. Una migración planificada cubre mover la partición de un propietario sano a propósito. Este artículo trata del tercer acto, el que corre después de que las sirenas se apagan —el proceso propietario original reinicia, se reúne al clúster, y quiere su partición de vuelta. Su almacén de nada-en-disco, todo-en-memoria volvió vacío. Los datos de los que es responsable siguen vivos, pero están vivos en las réplicas que siguieron sirviendo mientras estaba caído.

Todo el problema de corrección está contenido en una frase: al propietario reiniciado no se le puede permitir confiar en su propia vacuidad. Un almacén vacío se ve exactamente como un almacén que alguien limpió deliberadamente. Si el nodo asume "soy el propietario y no tengo datos, por lo tanto esta partición está vacía", servirá alegremente NotFound para millones de claves vivas y, peor, dejará que su estado vacío fluya de vuelta a las réplicas y las elimine. Este artículo recorre las cinco políticas pequeñas y puras que Zaris usa para asegurar que eso nunca ocurra.

Tarde o temprano alguien hace la pregunta: tenemos un clúster en una región y usuarios en otra —¿no podemos simplemente añadir unos cuantos nodos allá y dejar que un clúster abarque ambas? Es un instinto razonable. Un clúster, un namespace, una cadena de conexión, datos en todas partes. El instinto también es una trampa, y vale la pena ser preciso sobre por qué.

Un clúster de Zaris está diseñado para una red de datacenter. La membresía se rastrea con heartbeats en temporizadores cortos. La propiedad de una partición se mueve entre nodos mediante un handshake que asume que el otro lado responde rápido. El failover aísla a un propietario sospechoso de estar muerto y promueve una réplica en cuestión de segundos. Cada uno de esos mecanismos está calibrado para un enlace donde el viaje de ida y vuelta se mide en microsegundos y un nodo "lento" está genuinamente enfermo —no meramente a ochenta milisegundos y un océano de distancia. Pon la mitad de los nodos al otro lado de una WAN y no habrás construido un clúster geo-distribuido; habrás construido un clúster que ahora confunde la latencia normal de WAN con un fallo, flapea la propiedad y arriesga split-brain la primera vez que el enlace entre regiones tiene un hipo.

Así que la forma correcta no es un clúster estirado. Son dos clústeres independientes —cada uno autocontenido, cada uno con su propia propiedad y failover quedándose enteramente en su propia LAN— unidos por un change feed asíncrono y reanudable. Este artículo trata sobre ese patrón: por qué la independencia es la decisión portante, y cómo el log de operaciones de Zaris ya te entrega lo único que un replicador de WAN realmente necesita —un cursor desde el cual reanudar.

Aquí hay una pregunta que suena simple y no lo es: ¿qué ocurre cuando un almacén en memoria se queda sin memoria?

La respuesta ingenua es "se cae" —el proceso trepa hasta que el sistema operativo lo mata. La respuesta un poco menos ingenua es "rechaza escrituras". Zaris no hace ninguna de las dos por defecto. Un nodo de Zaris es un almacén en memoria, pero deliberadamente no es uno ilimitado: cada nodo es un buffer acotado con un techo duro, y cuando los datos que posee se acercan a ese techo el nodo expulsa sus datos más fríos para hacer espacio. Las escrituras siguen teniendo éxito; el límite se sostiene; el proceso no se hincha. El nodo se comporta como una caché, porque por debajo, lo es.

Aquí hay un resultado de benchmark que parece una contradicción. Un nodo de Zaris sirviendo una carga de trabajo intensiva en lecturas tope en poco menos de medio millón de ops/seg y se niega a trepar —añade más conexiones de cliente, más generadores de carga, y el número no se mueve. El diagnóstico obvio es "está saturado". Excepto que el gráfico de CPU dice otra cosa: el nodo está al cuarto de su CPU disponible, aproximadamente. Tres núcleos de cada cuatro están ociosos, y el throughput está plano.

Eso no es un nodo limitado por núcleos, y —si lo has descartado con cuidado— tampoco es un benchmark limitado por el cliente. Es una tercera cosa, y es un clásico: el pool de workers de despacho de solicitudes era más estrecho de lo que el trabajo quería ser, así que las solicitudes se encolaban mientras los núcleos estaban de brazos cruzados.

La mayor parte de lo que lees sobre un almacén de datos trata del camino de datos: lecturas, escrituras, el protocolo de cable, lo rápido que va. Pero antes de que nada de eso importe, alguien tiene que poner la cosa en pie: decidir cuántas particiones tiene, cuántas copias de cada una, dónde viven los puertos, arrancarla, confirmar que levantó sana y vigilarla mientras corre. Eso es el plano de control, y en Zaris vive en PowerShell.

Este es un recorrido de operador de día uno. Crearemos un workspace, aprovisionaremos un almacén, lo arrancaremos y luego volveremos a leer su estado en vivo, todo desde el módulo AdminShell. Sin consola web, nada editado a mano. Y como el sentido de una historia de operador es la confianza, seremos explícitos sobre las decisiones que New-ZrStore pone ante ti y lo que cada una cuesta de verdad.

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.

Hay una línea de razonamiento tentadora cuando despliegas un almacén replicado en Kubernetes: fijé replicationFactor: 2, así que cada partición tiene un backup, así que sobrevivo a la pérdida de un nodo. Suena hermético. También es, para un tamaño de clúster sorprendentemente común, incorrecto — e incorrecto de la forma silenciosa que solo aparece la primera vez que un pod realmente muere.

Zaris en Kubernetes almacena la data en memoria y la hace durable por replicación, no por disco: el volumen de data del nodo es un emptyDir, y un pod reprogramado reconstruye a partir de la copia que tiene otro pod. Ese diseño es sólido — pero se apoya enteramente en que haya una copia en otro pod. Que esa copia exista no lo decide replicationFactor por sí solo. Lo decide la aritmética entre tu número de pods y tu factor de replicación, y si te equivocas en esa aritmética el almacén correrá perfectamente, servirá cada lectura y escritura, y en silencio sostendrá una partición que no tiene a dónde replicarse.

El licenciamiento es la parte de un producto en la que la mayoría de los ingenieros nunca quieren pensar, y se nota. El patrón habitual es una bomba de tiempo: se comprueba una fecha, y cuando pasa, el software te castiga — lanza una excepción al arrancar, corrompe o borra el estado local para evitar que lo "robes", o simplemente revienta y se lleva tu data con él. Ese diseño trata a tus propios operadores como adversarios, y falla justo en el momento en que menos te lo puedes permitir: en producción, después de que el reloj girara silenciosamente.

Zaris adopta la postura opuesta. La comprobación de licencia es el interruptor más crítico para la seguridad de un almacén de datos distribuido, así que está construida como tal: una única función de política pura y determinista, un camino de aplicación elegante y totalmente reversible que nunca destruye un byte, y un reloj por máquina que se reanuda en el instante en que activas una clave. Este post recorre cómo funciona realmente ese ciclo de vida en el código que se envía — porque la ingeniería interesante aquí está en lo que se niega a hacerte.

Aquí hay un hecho sobre cualquier almacén clave-valor particionado que los diagramas pulidos tienden a omitir: el nodo que posee tu clave se moverá. Un nodo falla y sus particiones conmutan por error a sus réplicas. Escalas horizontalmente y las particiones migran al nuevo miembro. Un primario preferido vuelve y la propiedad conmuta de vuelta a él. Cada uno de esos eventos significa que el nodo con el que tu cliente hablaba felizmente hace un milisegundo es, en este momento, el nodo equivocado para algún conjunto de claves.

La experiencia ingenua del cliente en ese momento es fea: un reinicio de conexión, un genérico "error de servidor" o —peor— una escritura que aterriza en un nodo que ya no es el dueño activo y silenciosamente no va a ninguna parte. El cliente .NET de Zaris está construido para que nada de eso llegue a tu código. Un cambio de propiedad se convierte en un estado tipado, el cliente reencamina al nuevo dueño, y el reintento está acotado tanto por un presupuesto de intentos como por una fecha límite de reloj de pared. En el caso común, tu PutAsync simplemente tarda unos milisegundos más y devuelve Ok. Esta publicación trata de la maquinaria que hace que eso sea cierto y —no menos importante— de los casos que deliberadamente no disimula.

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.