21 publicaciones etiquetados con "Arquitectura"

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.

La mayor parte de lo que se escribe sobre almacenes distribuidos trata del estado estable —lecturas, escrituras, replicación— o de los fallos dramáticos: un failover cuando muere un propietario, un cut-over cuando se mueve una partición. Pero hay un momento más silencioso que decide si algo de eso funciona: el momento en que el clúster se forma. Antes de poder enrutar una sola clave, los nodos tienen que ponerse de acuerdo sobre quién está en el clúster, quién posee qué porción del espacio de claves y —el paso que la mayoría de los sistemas resuelven mal— si es seguro empezar a servir siquiera.

Este artículo sigue esa secuencia de arranque en el orden en que Zaris realmente la ejecuta: membresía, el mapa de particiones y las compuertas de disponibilidad que se interponen entre "el proceso está en marcha" y "el nodo está aceptando tráfico". También traza una línea, con honestidad, entre lo que Zaris implementa por sí mismo y lo que hereda del runtime de clúster subyacente sobre el que está construido.

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 un número que reencuadra cómo piensas sobre un almacén clave/valor. Cuando aislamos el almacén en memoria de Zaris y le damos operaciones sin nada más en el camino —sin socket, sin serialización, sin enrutamiento— un solo hilo sirve lecturas a más de un millón por segundo, y escala limpiamente a más de ocho millones a lo largo de ocho hilos. El almacén, en otras palabras, hace el trabajo real de un GET en menos de dos microsegundos, y enfáticamente no es el cuello de botella.

Y sin embargo un GET completo sobre una conexión TCP real, en la misma máquina, se estanca en unos pocos cientos de miles por segundo. El almacén puede hacer el trabajo cinco veces más rápido de lo que el servidor puede entregarlo. Así que la pregunta de rendimiento interesante sobre Zaris no es "¿qué tan rápido es el almacén?". Es lo contrario: ¿a dónde va todo el tiempo entre el socket y el almacén? Este artículo es la respuesta, trazada operación por operación, porque la brecha entre 1,7 microsegundos de lógica y 10 a 13 microsegundos de CPU de servidor por operación no es ruido —es el piso de latencia, y casi todo él es plomería.

Un failover es lo que ocurre cuando un propietario muere —el clúster tiene segundos para elegir a un superviviente y el mapa de particiones nunca se mueve. La migración es la prima más tranquila y más peligrosa: el propietario está perfectamente sano, y quieres mover una partición fuera de él a propósito —para hacer crecer el clúster, para rebalancear, para drenar un nodo que estás a punto de retirar. Nada ha fallado, que es exactamente por qué el listón está más alto. A un failover se le permiten unas pocas escrituras de cola honestamente perdidas en el peor caso; a una migración planificada no. Si mover una partición del nodo A al nodo B puede perder una sola escritura confirmada, la migración no es una característica, es un pasivo.

Este artículo recorre el protocolo de cut-over que Zaris realmente ejecuta, en orden, y dedica la mayor parte de su tiempo al único paso que todos resuelven mal: el momento en que la fuente finalmente queda "libre" para descartar su copia. Ese paso es un arma cargada, y la ingeniería interesante es el seguro que lleva.

Un GET de clave única es fácil de razonar: haz hash de la clave, encuentra su propietario, pregunta a ese único nodo. SCAN es el tipo de operación opuesto. No tiene clave —hace una pregunta sobre todo el espacio de claves: dame cada clave en este rango, una página a la vez. Y en un almacén particionado y replicado ese espacio de claves no es una sola cosa en un solo lugar. Está dividido en 256 segmentos repartidos sobre cuantos nodos ejecutes, cada nodo sosteniendo solo las porciones que posee actualmente, y todo el conjunto se está escribiendo mientras iteras. No hay índice ordenado global que recorrer. Entonces, ¿de dónde viene el orden, a qué apunta exactamente un token de reanudación, y qué le pasa a tu escaneo cuando una clave se escribe —o una partición se mueve— a mitad de camino?

Este artículo sigue un SCAN a través de las tres capas que realmente lo sirven: un solo segmento, un solo nodo, y el cliente que cose los nodos entre sí. Cada capa resuelve una pieza del problema, y los límites honestos de la operación caen de cómo esas piezas encajan.

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.

La mayor parte de lo que Zaris hace bien —replicar una escritura a un backup, poner al día a una réplica rezagada, traspasar una partición a un nuevo propietario— se reduce a una pregunta silenciosa: ¿cuál es, exactamente, la unidad de datos que se mueve entre nodos? Si esa unidad está bien, la convergencia es casi aburrida. Si deja caer un campo o lleva el equivocado, obtienes una clave eliminada resucitada, una réplica que no puede distinguir lo obsoleto de lo fresco, o la contabilidad de un nodo filtrándose en otro.

En Zaris esa unidad es un solo tipo —StoredRecord— y vale la pena desmontarlo campo por campo, porque cada decisión en él es portante. Este artículo es la anatomía: qué contiene el registro, cómo se enmarca en el cable, por qué una eliminación viaja como un registro en lugar de como una ausencia, por qué hay dos números de versión distintos, y —igual de importante— qué deliberadamente se deja atrás en cada nodo y nunca cruza el cable en absoluto.

Una conmutación por error es el momento en que un almacén distribuido es más honesto sobre lo que realmente es. En estado estable todos los almacenes se ven iguales: una escritura llega a un dueño, se confirma, y sigues adelante. El diseño solo se muestra cuando el dueño desaparece a mitad de frase: un nodo tiene la copia activa de una de tus particiones, le están llegando escrituras ahora mismo, y de pronto ya no está. Eliminado en seco. Particionado por la red. Muerto por OOM. El clúster tiene unos segundos para darse cuenta, acordar un nuevo dueño y hacer que el tráfico vuelva a fluir; y que lo haga correctamente decide si tu escritura confirmada sobrevive o se evapora silenciosamente.

Esta entrada sigue esa secuencia de principio a fin, en el orden en que Zaris realmente la ejecuta, y nombra los casos en los que la respuesta es genuinamente "la escritura se pierde", porque una entrada sobre conmutación por error que solo describe el camino feliz no vale la pena leer.

La mayoría de las razones para recurrir a una caché distribuida en una aplicación .NET nunca mencionan una caché por su nombre. Añades caché de salida (output caching) y quiere un IDistributedCache. Habilitas sesiones y el middleware quiere un almacén de respaldo. Activas el uso compartido de claves de protección de datos entre instancias y, de nuevo, quiere un lugar donde poner bytes que todos los nodos puedan ver. El código de la aplicación está escrito contra una abstracción; la única pregunta es qué implementación registras al arrancar.

Zaris responde a esa pregunta con tres pequeños paquetes NuGet, cada uno apuntando a una costura específica de ASP.NET Core: un IDistributedCache simple, un HybridCache de dos niveles y un almacén de sesiones. Registras una línea al arrancar y el resto de tu aplicación —incluidas las bibliotecas de terceros que solo conocen la abstracción— cachea en un clúster Zaris sin un solo cambio en el código que usa la caché. Esta entrada recorre los tres, y es deliberada sobre dónde se detiene honestamente cada uno.