Aller au contenu principal

Trois façons de basculer : LoadBalancer, Sentinel et Cluster sur le front-end RESP de Zaris

· 7 minutes de lecture
Clustron Team
Clustron Team
Ingénierie des systèmes distribués

Trois façons de basculer sur le front-end RESP de Zaris

Zaris expose un front-end protocole Redis (RESP) afin que n'importe quel client Redis, dans n'importe quel langage, puisse pointer vers un cluster Zaris et l'utiliser comme store interchangeable. Mais « n'importe quel client Redis » masque un vrai problème : les écosystèmes de clients Redis ne s'accordent pas sur la façon de découvrir la topologie ni de récupérer lorsqu'un nœud disparaît. Un client simple attend un unique point d'accès stable. Un client fondé sur Sentinel attend de pouvoir demander à un service de découverte « qui est le maître ? » Un client en mode cluster attend des slots de hachage et des redirections MOVED/ASK.

Si un store ne parlait qu'un seul de ces dialectes, toute une catégorie de clients serait exclue. C'est pourquoi le front-end RESP de Zaris prend en charge trois modèles de basculement, chacun correspondant à la façon dont une famille particulière de clients Redis s'attend déjà à fonctionner. Vous choisissez le modèle par déploiement ; le client se comporte exactement comme il le ferait face à un vrai Redis.

Une remarque honnête d'emblée, car elle conditionne tout ce qui suit : les trois modèles se placent devant le même store Zaris, répliqué et partitionné. Le modèle que vous choisissez change la sémantique de découverte et de redirection — comment un client trouve un nœud et ce qu'il fait lorsqu'un nœud tombe en panne — et non l'endroit où vos données résident réellement.

Un store, trois dialectes clients​

Un cluster Zaris est composé de plusieurs nœuds aux données partitionnées et répliquées. Lorsque le nœud auquel un client parle tombe, le client doit en trouver un autre et poursuivre — et les clients Redis ont été écrits selon trois mécanismes de découverte différents :

  • Un client simple ouvre simplement une connexion vers un hôte et un port. Il n'a aucune notion de topologie.
  • Un client compatible Sentinel traite la découverte du maître comme un protocole distinct : il interroge Sentinel pour connaître le maître actuel, se connecte, puis ré-interroge après un basculement.
  • Un client en mode cluster récupère une carte de slots au moment de la connexion et route chaque clé vers le nœud qui possède son slot, en suivant les redirections MOVED/ASK.

Zaris répond aux trois. Le modèle est choisi au moment du déploiement à l'aide des variables d'environnement ZARIS_RESP_*.

Modèle 1 — LoadBalancer : l'intégration la plus simple​

Les clients se connectent via un unique point d'accès stable — un Service Kubernetes ou n'importe quel répartiteur de charge L4 — et Zaris route et redirige en interne derrière lui. N'importe quel nœud accepte n'importe quelle clé. Lorsqu'un nœud tombe, il sort de la rotation et la connexion suivante atterrit sur un nœud sain. Cela fonctionne avec n'importe quel client Redis simple, car il ne demande rien de plus que « connecte-toi à cette adresse », et le basculement est transparent derrière le point d'accès.

# 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

Commencez par celui-ci : le moins de pièces mobiles, la plus large compatibilité clients.

Modèle 2 — Sentinel : pour les piles déjà bâties autour de Sentinel​

De nombreuses équipes font déjà passer leur accès Redis par des clients compatibles Sentinel, configurés avec des adresses Sentinel et un nom de maître. Zaris répond donc au protocole Redis Sentinel : le client demande « qui est le maître ? », Zaris le lui indique, et le client se connecte à ce nœud. Lors d'un basculement, le client résout à nouveau via le même chemin de code qu'il utilise déjà et se reconnecte. Rien ne change dans la logique de basculement du client.

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

Choisissez-le lorsque votre pile est déjà fondée sur Sentinel.

Modèle 3 — Cluster : alignement sur les slots CRC16​

Pour les clients qui parlent le protocole Redis Cluster, Zaris répond à CLUSTER SLOTS et CLUSTER NODES et émet des redirections MOVED/ASK avec un routage aligné sur les slots de hachage CRC16 — le même calcul de slot CRC16(key) % 16384 qu'utilise un client Redis Cluster. Comme le routage interne de Zaris et le calcul de slot Redis sont alignés, l'idée que se fait le client du slot auquel appartient une clé correspond au placement propre de Zaris, de sorte qu'il route chaque clé directement vers le nœud propriétaire.

Cela rend redis-cli --cluster et les bibliothèques en mode cluster directement interchangeables. Pendant un rééquilibrage ou un basculement, la propriété d'un slot se déplace et le nœud répond par une redirection ; le client rafraîchit sa carte de slots et suit le mouvement.

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

Optez pour celui-ci lorsque vous exécutez des clients en mode cluster, ou si vous voulez une conscience des slots côté client pour que les clients routent directement vers les propriétaires.

Testé sous arrêt et réintégration​

Les trois modèles ont été validés sous arrêt d'un nœud suivi d'une réintégration. Dans chaque cas, les clients récupèrent — le client LoadBalancer se reconnecte via le point d'accès, le client Sentinel résout à nouveau le maître, et le client cluster rafraîchit sa carte de slots — et le trafic se poursuit sur les nœuds survivants. Un modèle de basculement qui n'a pas été éprouvé sous une perte réelle de nœud n'est qu'une supposition.

Choisir un modèle​

Le modèle est un choix par déploiement, défini via les variables ZARIS_RESP_* :

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

Le guide de décision​

  • LoadBalancer pour l'intégration la plus simple. Fonctionne avec n'importe quel client Redis simple, masque le basculement derrière un unique point d'accès. Commencez ici, sauf raison contraire.
  • Sentinel lorsque votre pile est déjà bâtie autour de Sentinel — les clients conservent leur code existant de découverte du maître et de basculement.
  • Cluster lorsque vous exécutez des clients en mode cluster, ou que vous voulez une conscience des slots côté client afin que les clients routent directement vers le nœud propriétaire et suivent les redirections pendant le rééquilibrage et le basculement.

La frontière honnête​

Les trois modèles se placent devant le même store Zaris, répliqué et partitionné. Quel que soit votre choix, vos données sont placées et répliquées de la même manière en dessous — le modèle ne change que la façon dont les clients découvrent les nœuds et redirigent en cas de panne, pas la durabilité ni le placement des données. Il s'agit d'une décision de compatibilité client superposée à un store unique et cohérent.

Pour les rouages internes du routage — comment l'alignement CRC16 permet aux clients cluster d'atteindre les propriétaires sans proxy — voir comment Zaris parle le protocole Redis.