21 articles tagués avec « Architecture »

Un basculement couvre le moment où un propriétaire meurt : le cluster choisit un survivant et continue de servir. Une migration planifiée couvre le déplacement à dessein de la partition d'un propriétaire sain. Cet article porte sur le troisième acte, celui qui se joue après que les sirènes se taisent — le processus propriétaire d'origine redémarre, rejoint le cluster, et veut récupérer sa partition. Son store rien-sur-disque, tout-en-mémoire est revenu vide. Les données dont il est responsable sont toujours vivantes, mais elles sont vivantes sur les réplicas qui ont continué de servir pendant qu'il était à terre.

Tout le problème de correction tient en une phrase : le propriétaire redémarré ne peut pas être autorisé à faire confiance à sa propre vacuité. Un store vide ressemble exactement à un store que quelqu'un a délibérément vidé. Si le nœud suppose « je suis le propriétaire et je n'ai pas de données, donc cette partition est vide », il servira joyeusement NotFound pour des millions de clés vivantes et, pire, laissera son état vide refluer sur les réplicas et les supprimer. Cet article parcourt les cinq petites politiques pures que Zaris utilise pour s'assurer que cela n'arrive jamais.

La plupart des écrits sur les stores distribués traitent du régime permanent — lectures, écritures, réplication — ou des défaillances spectaculaires : un basculement quand un propriétaire meurt, un cut-over quand une partition se déplace. Mais il existe un moment plus discret qui décide si tout cela fonctionne : le moment où le cluster démarre. Avant qu'une seule clé puisse être routée, les nœuds doivent s'accorder sur qui fait partie du cluster, qui possède quelle tranche du keyspace et — l'étape que la plupart des systèmes ratent — s'il est seulement sûr de commencer à servir.

Cet article suit cette séquence de démarrage dans l'ordre où Zaris l'exécute réellement : l'appartenance, la partition map, et les barrières de disponibilité qui se dressent entre « le processus est lancé » et « le nœud prend du trafic ». Il trace aussi, honnêtement, une ligne autour de ce que Zaris implémente lui-même par rapport à ce qu'il hérite du runtime de cluster sous-jacent sur lequel il est construit.

Tôt ou tard, quelqu'un pose la question : nous avons un cluster dans une région et des utilisateurs dans une autre — ne peut-on pas simplement ajouter quelques nœuds là-bas et laisser un seul cluster couvrir les deux ? C'est un réflexe raisonnable. Un cluster, un espace de noms, une chaîne de connexion, des données partout. Ce réflexe est aussi un piège, et il vaut la peine d'être précis sur le pourquoi.

Un cluster Zaris est conçu pour un réseau de datacenter. L'appartenance est suivie avec des heartbeats sur des minuteries courtes. La possession d'une partition se déplace entre nœuds via une poignée de main qui suppose que l'autre côté répond vite. Le basculement clôture un propriétaire suspecté mort et promeut un réplica à l'échelle de quelques secondes. Chacun de ces mécanismes est calibré pour une liaison où l'aller-retour se mesure en microsecondes et où un nœud « lent » est véritablement malade — et non simplement à quatre-vingts millisecondes et un océan de distance. Mettez la moitié des nœuds de l'autre côté d'un WAN et vous n'avez pas construit un cluster géo-distribué ; vous avez construit un seul cluster qui prend désormais la latence WAN normale pour une défaillance, fait flapper la possession, et risque le split-brain au premier hoquet de la liaison entre régions.

La bonne forme n'est donc pas un seul cluster étiré. Ce sont deux clusters indépendants — chacun autonome, chacun gardant sa possession et son basculement entièrement sur son propre LAN — reliés par un change feed asynchrone et reprenable. Cet article porte sur ce motif : pourquoi l'indépendance est la décision porteuse, et comment le log d'opérations de Zaris vous remet déjà la seule chose dont un réplicateur WAN a réellement besoin — un curseur depuis lequel reprendre.

Voici un nombre qui recadre la façon dont vous pensez un store clé/valeur. Quand nous isolons le store en mémoire de Zaris et lui envoyons des opérations sans rien d'autre sur le chemin — pas de socket, pas de sérialisation, pas de routage — un seul thread sert les lectures à plus d'un million par seconde, et monte proprement à plus de huit millions sur huit threads. Le store, autrement dit, fait le travail réel d'un GET en moins de deux microsecondes, et il n'est emphatiquement pas le goulet d'étranglement.

Et pourtant un GET complet sur une vraie connexion TCP, sur la même machine, plafonne à quelques centaines de milliers par seconde. Le store peut faire le travail cinq fois plus vite que le serveur ne peut le délivrer. La question de performance intéressante au sujet de Zaris n'est donc pas « à quelle vitesse va le store ? ». C'est l'inverse : où part tout le temps entre la socket et le store ? Cet article en est la réponse, tracée opération par opération, car l'écart entre 1,7 microseconde de logique et 10 à 13 microsecondes de CPU serveur par opération n'est pas du bruit — c'est le plancher de latence, et il est presque entièrement de la plomberie.

Un basculement, c'est ce qui arrive quand un propriétaire meurt — le cluster a quelques secondes pour choisir un survivant et la partition map ne bouge jamais. La migration est le cousin plus calme et plus dangereux : le propriétaire est parfaitement sain, et vous voulez déplacer une partition hors de lui à dessein — pour faire grandir le cluster, pour rééquilibrer, pour drainer un nœud que vous êtes sur le point de retirer. Rien n'a échoué, ce qui est exactement pourquoi la barre est plus haute. Un basculement a droit à quelques écritures de queue honnêtement perdues dans le pire des cas ; une migration planifiée, non. Si déplacer une partition du nœud A au nœud B peut perdre une seule écriture acquittée, la migration n'est pas une fonctionnalité, c'est un passif.

Cet article parcourt le protocole de cut-over que Zaris exécute réellement, dans l'ordre, et passe l'essentiel de son temps sur l'étape que tout le monde rate : le moment où la source est enfin « libre » de déposer sa copie. Cette étape est un pistolet armé, et l'ingénierie intéressante est la sécurité dessus.

Un GET à clé unique est facile à raisonner : hacher la clé, trouver son propriétaire, demander à ce seul nœud. SCAN est le genre d'opération opposé. Il n'a pas de clé — il pose une question sur tout le keyspace : donne-moi chaque clé dans cette plage, une page à la fois. Et dans un store partitionné et répliqué, ce keyspace n'est pas une seule chose en un seul endroit. Il est réparti sur 256 segments étalés sur autant de nœuds que vous en exécutez, chaque nœud ne détenant que les tranches qu'il possède actuellement, et l'ensemble est en cours d'écriture pendant que vous itérez. Il n'y a pas d'index trié global à parcourir. Alors d'où vient l'ordre, que pointe exactement un jeton de reprise, et qu'arrive-t-il à votre scan quand une clé est écrite — ou qu'une partition se déplace — en plein milieu ?

Cet article suit un SCAN à travers les trois couches qui le servent réellement : un seul segment, un seul nœud, et le client qui recoud les nœuds ensemble. Chaque couche résout une pièce du problème, et les limites honnêtes de l'opération découlent de la façon dont ces pièces s'emboîtent.

Voici une question qui semble simple et ne l'est pas : qu'arrive-t-il quand un store en mémoire tombe à court de mémoire ?

La réponse naïve est « il plante » — le processus grimpe jusqu'à ce que le système d'exploitation le tue. La réponse un peu moins naïve est « il refuse les écritures ». Zaris ne fait ni l'un ni l'autre par défaut. Un nœud Zaris est un store en mémoire, mais il n'est délibérément pas illimité : chaque nœud est un buffer borné avec un plafond dur, et quand les données qu'il possède approchent ce plafond, le nœud évince ses données les plus froides pour faire de la place. Les écritures continuent de réussir ; la limite tient ; le processus ne gonfle pas. Le nœud se comporte comme un cache, parce qu'en dessous, c'en est un.

L'essentiel de ce que Zaris fait bien — répliquer une écriture vers une sauvegarde, remettre à niveau un réplica en retard, faire basculer une partition vers un nouveau propriétaire — se ramène à une question discrète : quelle est, exactement, l'unité de données qui se déplace entre les nœuds ? Si cette unité est juste, la convergence est presque ennuyeuse. Si elle oublie un champ ou en porte un faux, vous obtenez une clé supprimée ressuscitée, un réplica incapable de distinguer le périmé du frais, ou la comptabilité d'un nœud qui fuit sur un autre.

Dans Zaris cette unité est un seul type — StoredRecord — et il vaut la peine de le démonter champ par champ, car chaque décision qu'il contient est porteuse. Cet article est l'anatomie : ce qu'il y a dans l'enregistrement, comment il est encadré sur le fil, pourquoi une suppression voyage comme un enregistrement au lieu d'une absence, pourquoi il y a deux numéros de version différents, et — tout aussi important — ce qui est délibérément laissé sur chaque nœud et ne traverse jamais le fil du tout.

Un basculement est le moment où un store distribué est le plus honnête sur ce qu'il est réellement. En régime permanent, tout store se ressemble : une écriture atterrit sur un propriétaire, est acquittée, vous passez à la suite. La conception ne se montre que lorsque le propriétaire disparaît au milieu d'une phrase — un nœud détient la copie active de l'une de vos partitions, des écritures y atterrissent à l'instant même, puis il n'est plus là. Tué net. Partitionné par le réseau. OOM. Le cluster a quelques secondes pour s'en apercevoir, s'accorder sur un nouveau propriétaire et faire repartir le trafic — et le fait de s'y prendre correctement décide si votre écriture acquittée survit ou s'évapore discrètement.

Cet article suit cette séquence de bout en bout, dans l'ordre où Zaris l'exécute réellement, et nomme les cas où la réponse est véritablement « l'écriture est perdue » — car un article sur le basculement qui ne décrit que le chemin heureux ne vaut pas la lecture.

La plupart des raisons de recourir à un cache distribué dans une application .NET ne mentionnent jamais un cache par son nom. Vous ajoutez du cache de sortie et il réclame un IDistributedCache. Vous activez les sessions et l'intergiciel réclame un store de secours. Vous activez le partage des clés de protection des données entre instances et, là encore, il réclame un endroit où mettre des octets que chaque nœud peut voir. Le code de l'application est écrit contre une abstraction ; la seule question est quelle implémentation vous enregistrez au démarrage.

Zaris répond à cette question avec trois petits paquets NuGet, chacun ciblant une couture ASP.NET Core spécifique : un IDistributedCache nu, un HybridCache à deux niveaux et un store de session. Vous enregistrez une ligne au démarrage et le reste de votre application — y compris les bibliothèques tierces qui ne connaissent que l'abstraction — met en cache sur un cluster Zaris sans un seul changement dans le code qui utilise le cache. Cet article passe en revue les trois, et est délibéré sur l'endroit où chacun s'arrête honnêtement.