Saltar al contenido principal

Tres formas de hacer failover: LoadBalancer, Sentinel y Cluster en el front-end RESP de Zaris

· 6 min de lectura
Clustron Team
Clustron Team
Ingeniería de Sistemas Distribuidos

Tres formas de hacer failover en el front-end RESP de Zaris

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.

Un almacén, tres dialectos de cliente​

Un clúster de Zaris son varios nodos con data particionada y replicada. Cuando el nodo con el que un cliente está hablando cae, el cliente tiene que encontrar otro y continuar — y los clientes Redis se escribieron contra tres mecanismos de descubrimiento diferentes:

  • Un cliente simple solo abre una conexión a un host y puerto. No tiene concepto de topología.
  • Un cliente consciente de Sentinel trata el descubrimiento del master como un protocolo aparte: consulta a Sentinel por el master actual, se conecta y vuelve a consultar tras un failover.
  • Un cliente en modo cluster obtiene un mapa de slots al conectarse y enruta cada clave al nodo propietario de su slot, siguiendo las redirecciones MOVED/ASK.

Zaris responde a los tres. El modelo se elige en el momento del despliegue con flags de entorno ZARIS_RESP_*.

Modelo 1 — LoadBalancer: el drop-in más simple​

Los clientes se conectan a través de un único endpoint estable — un Service de Kubernetes o cualquier balanceador de carga L4 — y Zaris enruta y redirige internamente por detrás. Cualquier nodo acepta cualquier clave. Cuando un nodo muere, sale de la rotación y la siguiente conexión aterriza en un nodo sano. Esto funciona con cualquier cliente Redis simple, porque no pide nada más allá de "conéctate a esta dirección", y el failover es transparente tras el endpoint.

# One stable endpoint in front of the whole cluster.
redis-cli -h redis.example.com -p 6379 SET user:42 "ada"
redis-cli -h redis.example.com -p 6379 GET user:42
apiVersion: v1
kind: Service
metadata:
  name: zaris-resp
spec:
  type: LoadBalancer
  selector:
    app: zaris
  ports:
    - name: resp
      port: 6379
      targetPort: 6379

Empieza por aquí: la menor cantidad de piezas móviles, el mayor soporte de clientes.

Modelo 2 — Sentinel: para stacks ya construidos en torno a Sentinel​

Muchos equipos ya ejecutan el acceso a Redis mediante clientes conscientes de Sentinel, configurados con direcciones de Sentinel y un nombre de master. Por eso Zaris responde al protocolo Redis Sentinel: el cliente pregunta "¿quién es el master?", Zaris se lo dice, y el cliente se conecta a ese nodo. En un failover, el cliente vuelve a resolver a través del mismo camino de código que ya usa y se reconecta. Nada de la lógica de failover del cliente cambia.

redis-cli -h zaris-sentinel.example.com -p 26379 \
  SENTINEL get-master-addr-by-name zaris-primary

Elige este cuando tu stack ya esté basado en Sentinel.

Modelo 3 — Cluster: alineado por slots CRC16​

Para clientes que hablan el protocolo Redis Cluster, Zaris responde a CLUSTER SLOTS y CLUSTER NODES y emite redirecciones MOVED/ASK con enrutamiento alineado a hash-slots CRC16 — la misma aritmética de slots CRC16(key) % 16384 que usa un cliente Redis Cluster. Como el enrutamiento interno de Zaris y la aritmética de slots de Redis están alineados, la idea del cliente sobre a qué slot pertenece una clave coincide con la propia ubicación de Zaris, de modo que enruta cada clave directamente al nodo propietario.

Eso convierte redis-cli --cluster y las librerías en modo cluster en un drop-in. Durante un rebalanceo o un failover, la propiedad de un slot se mueve y el nodo responde con una redirección; el cliente refresca su mapa de slots y lo sigue.

redis-cli -c -h 10.0.0.10 -p 6379 SET user:42 "ada"
redis-cli -h 10.0.0.10 -p 6379 CLUSTER SLOTS

Elige este cuando ejecutes clientes en modo cluster, o cuando quieras conciencia de slots en el lado del cliente para que estos enruten directamente a los propietarios.

Probado bajo kill y rejoin​

Los tres modelos se validaron bajo kill de nodo seguido de rejoin. En cada uno, los clientes se recuperan — el cliente LoadBalancer se reconecta a través del endpoint, el cliente Sentinel vuelve a resolver el master, y el cliente cluster refresca su mapa de slots — y el tráfico continúa contra los nodos supervivientes. Un modelo de failover que no se ha ejercitado bajo pérdida real de nodos es una conjetura.

Seleccionar un modelo​

El modelo es una elección por despliegue, configurada mediante flags ZARIS_RESP_*:

env:
  - name: ZARIS_RESP_ENABLED
    value: "true"
  - name: ZARIS_RESP_FAILOVER_MODEL
    value: "cluster"   # or "loadbalancer" / "sentinel"

La guía de decisión​

  • LoadBalancer para el drop-in más simple. Funciona con cualquier cliente Redis simple, oculta el failover tras un único endpoint. Empieza aquí salvo que tengas una razón para no hacerlo.
  • Sentinel cuando tu stack ya está construido en torno a Sentinel — los clientes conservan su código existente de descubrimiento de master y failover.
  • Cluster cuando ejecutas clientes en modo cluster, o quieres conciencia de slots en el lado del cliente para que estos enruten directamente al nodo propietario y sigan las redirecciones durante el rebalanceo y el failover.

El límite honesto​

Los tres modelos están delante del mismo almacén Zaris replicado y particionado. Elijas el que elijas, tu data se ubica y se replica de la misma forma por debajo — el modelo cambia solo cómo los clientes descubren nodos y redirigen ante un fallo, no la durabilidad ni la ubicación de la data. Es una decisión de compatibilidad de cliente superpuesta sobre un único almacén consistente.

Para los detalles internos de enrutamiento — cómo la alineación CRC16 permite que los clientes cluster alcancen a los propietarios sin un proxy — consulta cómo Zaris habla el protocolo Redis.