25 articles tagués avec « Systèmes distribués »

La plupart des façons de placer de l'authentification devant un store de données distribué finissent par ajouter un second système distribué à faire tourner : un service d'authentification à appeler, une base de données de sessions à répliquer, un point de terminaison d'introspection de jetons que chaque nœud doit atteindre sur le chemin chaud. Vous avez sécurisé le store et vous vous êtes acheté une nouvelle dépendance de disponibilité et une nouvelle source de latence.

Zaris prend une autre route, et c'est délibérément une route ennuyeuse : une clé de signature par cluster, et des jetons que chaque nœud peut vérifier par lui-même. Un jeton est un JWT signé avec la clé privée du cluster ; chaque manager et chaque nœud détiennent la moitié publique et vérifient la signature hors ligne — aucun appel à un serveur d'authentification, aucun quorum, aucune recherche en base de données. La sécurité est désactivée par défaut, et un cluster avec elle désactivée se comporte exactement comme un cluster non sécurisé. Cet article traite de ce qui s'active quand vous l'activez : la forme du jeton, le modèle de rôle-et-portée, les deux plans où l'application se produit réellement, et — car prétendre autrement est la façon dont les gens se donnent un faux sentiment de sécurité — les limites opérationnelles faciles à rater.

Deux événements d'apparence très différente dans un store distribué s'avèrent être le même problème en dessous. Le premier : un réplica prend du retard sur son primaire — une pause de ramasse-miettes, un disque lent, une brève partition réseau — et détient désormais une copie périmée d'une partition qu'il doit finir par faire correspondre. Le second : une partition est réassignée à un nœud qui ne l'a jamais détenue, et ce nœud doit acquérir l'ensemble complet des données auprès du propriétaire actuel. L'un est un retard de réplication ; l'autre est une migration. Ils ont des déclencheurs différents, des opérateurs différents, des histoires d'échec différentes.

Mais la question à laquelle chacun doit répondre est identique : comment converger vers la vérité courante de cette partition sans geler les écritures pendant que je le fais ? Zaris répond aux deux avec un seul mécanisme — un journal d'opérations ordonné par révision, tenu par segment, rejoué depuis un point connu. Cet article porte sur ce journal : comment il est construit sur le chemin d'écriture, comment il est borné pour ne pas pouvoir grossir sans limite, comment il est rejoué, et pourquoi exactement le même substrat conduit à la convergence tant un réplica en retard qu'un propriétaire flambant neuf.

Zaris 2.0.1 est disponible. C'est une mise à niveau transparente depuis la 2.0.0 — même protocole de communication, même API cliente, mêmes formats sur disque et en mémoire — et elle fait deux choses qui valent la mise à niveau : elle rend le chemin de propriété et de récupération du cluster nettement plus durable en cas de panne, et elle dote Zaris d'un modèle d'essai et de licence intégré et propre, afin que vous puissiez l'évaluer et l'exécuter en production sans friction.

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.

Le moyen le plus sûr de garantir que TLS sera contourné est d'imposer un unique modèle de confiance à tout le monde. Un développeur qui exécute un store sur un ordinateur portable ne veut pas monter une CA. Une banque dont la racine hors ligne est dans un HSM ne veut pas du tout que votre outil frappe des certificats. Livrez un store qui ne connaît qu'un seul de ces cas, et la moitié de vos utilisateurs désactiveront la sécurité pour faire leur travail.

Zaris ne choisit donc pas à votre place. Sa confiance TLS est enfichable selon quatre modes d'autorité de certification, du self-signed zéro-configuration jusqu'aux certificats que vous provisionnez entièrement hors bande. Vous choisissez le mode qui correspond à la PKI que vous exploitez déjà, et Zaris s'y insère au lieu de vous demander de tout reconstruire autour de lui. TLS n'est pas une solution universelle, et le traiter ainsi est précisément la raison pour laquelle la sécurité est repoussée.

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.

Zaris s'exprime déjà en collections — hashes, listes, sets et sorted sets qui résident sur le serveur et se répliquent comme toute autre clé. Les Streams sont le cinquième type, et c'est celui qui fait passer Zaris du statut de store à celui d'élément d'infrastructure de messagerie.

Un stream Zaris est un véritable journal en ajout seul : les entrées reçoivent des ID monotones, vous pouvez lire des plages, et vous pouvez attacher des groupes de consommateurs pour qu'un pool de workers se partage le journal, suive les entrées en attente par consommateur et acquitte ce qu'il a traité. Vous pouvez aussi effectuer une lecture bloquante — un consommateur se met en pause et attend l'arrivée de nouvelles entrées au lieu de boucler à vide.

Et parce qu'il s'agit d'une collection Zaris native, le journal est partitionné et répliqué exactement comme tout le reste. Un stream survit au basculement d'un nœud, ce qui est précisément la raison pour laquelle on recourt à une messagerie durable en premier lieu.