16 publicaciones etiquetados con "Operaciones"

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.

Llevar un almacén distribuido a Kubernetes es fácil. Llevarlo ahí con TLS activado, alcanzable desde fuera del clúster, y un cliente que realmente se conecta es donde la mayoría de los recorridos se detienen silenciosamente. Zaris incluye un chart de Helm, y hemos validado todo el camino — incluida la configuración asegurada y alcanzable externamente — de extremo a extremo en un clúster local.

Este post es ese recorrido. Lo ejecutamos en kind (Kubernetes-in-Docker) para que puedas reproducir cada paso en una laptop, y tomamos el camino más difícil a propósito: TLS habilitado, certificados con los subject alternative names correctos, acceso externo activado, y un cliente conectándose por el endpoint asegurado. A esto lo llamamos la configuración Model B — alcanzable externamente y asegurada, frente a un clúster solo interno.

Una regla de corrección hace tropezar a casi todos los primeros despliegues, y no tiene nada que ver con los certificados: el nombre del almacén en tu connection string debe ser igual al clusterId del despliegue. Señalaremos exactamente dónde muerde eso. Todo lo demás es idéntico en un clúster de producción — kind solo nos da un lugar limpio y desechable para demostrarlo.

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.