16 articles tagués avec « Opérations »

Le chemin heureux d'un store clé-valeur distribué est facile à réussir. Une écriture atterrit sur le primaire, se diffuse vers les réplicas, tout le monde est d'accord, vous passez à la suite. Si c'était toute l'histoire, la durabilité serait un problème résolu et cet article n'existerait pas.

Les problèmes difficiles vivent dans les coutures — ces moments brefs et maladroits où le cluster est en pleine transition. Un nœud redémarre au milieu d'une migration de partition. Un réplica prend beaucoup de retard sur le primaire actif qu'il copie, puis ce primaire bascule vers quelqu'un d'autre. La propriété d'une partition se déplace vers un nouveau nœud alors que des écritures sont encore en vol vers l'ancien. Chacun de ces cas est une fenêtre : une période de quelques secondes où, si le transfert n'est pas exactement correct, une écriture acquittée — une écriture dont on a dit au client qu'elle avait réussi — peut disparaître discrètement. Non pas parce que le moteur de stockage est bogué, mais parce que deux parties du système se sont contredites, un instant, sur qui possédait la vérité.

Cet article traite de la façon dont Zaris ferme ces fenêtres et — la partie qui compte réellement — de la façon dont nous nous sommes convaincus que cela fonctionne, en exécutant le cluster sous un chaos continu et délibéré pendant douze heures d'affilée.

La capacité n'est jamais juste longtemps. Le trafic augmente, un lancement a lieu, une saison se termine — et le store que vous avez dimensionné le trimestre dernier est soit saturé, soit à moitié inactif. La question qui décide si c'est une corvée ou une crise est simple : pouvez-vous changer la taille d'un store en cours d'exécution sans l'arrêter ?

Pour Zaris la réponse est oui, avec une asymétrie importante qu'il vaut la peine d'avouer d'emblée. La mise à l'échelle horizontale — ajouter des serveurs — est la direction facile, sûre et sans perte, et elle se produit en direct pendant que le store continue de servir. La réduction d'échelle — retirer des serveurs — est également prise en charge, mais c'est une opération délibérée et surveillée, car les données du serveur qui part doivent d'abord aller quelque part.

Cet article parcourt les deux directions : agrandir un store avec Add-ZrServer, le réduire avec Remove-ZrServer, pourquoi la réduction nécessite un drain, et où s'insère la console web.

La moitié des bugs de connexion « fonctionne en développement, casse en production » se résument à la même chose : les détails de connexion ont été orthographiés de trois façons différentes à trois endroits différents. Le appsettings.json avait une liste d'hôtes, le runbook d'exploitation en a collé une autre dans une session PowerShell, et la chaîne copiée d'un wiki avait un token périmé incrusté en dur.

Zaris élimine toute cette catégorie de problèmes avec un format de chaîne de connexion unique et indépendant de la plateforme. La même chaîne exacte fonctionne quand votre application .NET la lit depuis la configuration, quand un opérateur la passe à une cmdlet PowerShell, et quand quelqu'un la copie directement depuis la console web. Une orthographe canonique, partout.

Cet article décompose la chaîne partie par partie, montre les trois façons de l'utiliser, et plaide pour la seule règle qui compte le plus en production : ne jamais mettre un token brut dans la chaîne.

Mettre un store distribué sur Kubernetes est facile. L'y mettre avec TLS activé, atteignable depuis l'extérieur du cluster, et un client qui se connecte réellement est là où la plupart des tutoriels s'arrêtent discrètement. Zaris fournit un chart Helm, et nous avons validé tout le chemin — y compris la configuration sécurisée et atteignable de l'extérieur — de bout en bout sur un cluster local.

Cet article est ce tutoriel. Nous l'exécutons sur kind (Kubernetes-in-Docker) afin que vous puissiez reproduire chaque étape sur un ordinateur portable, et nous prenons la route la plus difficile à dessein : TLS activé, certificats avec les bons subject alternative names, accès externe activé, et un client se connectant via le point d'accès sécurisé. Nous appelons cela la configuration Model B — atteignable de l'extérieur et sécurisée, par opposition à un cluster interne uniquement.

Une règle d'exactitude accroche presque chaque premier déploiement, et elle n'a rien à voir avec les certificats : le nom du store dans votre chaîne de connexion doit être égal au clusterId du déploiement. Nous signalerons exactement où cela mord. Tout le reste est identique sur un cluster de production — kind nous offre simplement un endroit propre et jetable pour le prouver.

Exécutez Zaris dans Kubernetes et le chemin heureux est simple : les clients internes au cluster atteignent les pods par leurs adresses internes — IP de pod et noms DNS du cluster comme zaris-0.zaris.svc — et tout route proprement. Dès qu'un client se trouve à l'extérieur du cluster, cela casse. Une application externe ne peut pas appeler zaris-0.zaris.svc ni une IP de pod ; ces noms et adresses ne se résolvent et ne routent qu'à l'intérieur du réseau du cluster.

Ce n'est pas une bizarrerie de Zaris — c'est la séparation fondamentale entre le réseau interne du cluster et le monde extérieur. Elle mord le plus fort avec les clients conscients de la topologie. Un client Redis en mode cluster, ou tout client qui découvre les nœuds et route par clé, récupère une carte de topologie depuis le serveur et se connecte aux adresses qu'elle contient. Si ces adresses sont internes, un client externe obtient une carte remplie de points d'accès qu'il ne pourra jamais atteindre.

Zaris résout cela avec des adresses annoncées, gérées comme une « vue de frontière » par listener.

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.