Les centres de données modernes disposent de centaines d’appareils actifs installés, couverts par différents types de surveillance. Mais même un ingénieur idéal disposant d’une surveillance parfaite sera capable de réagir correctement à une panne de réseau en quelques minutes seulement. Dans un rapport présenté lors de la conférence Next Hop 2020, j'ai présenté une méthodologie de conception de réseau DC, qui présente une caractéristique unique : le centre de données se répare tout seul en quelques millisecondes. Plus précisément, l'ingénieur résout sereinement le problème, alors que les services ne le remarquent tout simplement pas.
Pour de nombreux ingénieurs réseau, un réseau de centre de données commence bien entendu par les ToR, avec un commutateur dans le rack. Les ToR comportent généralement deux types de liens. Les petits vont vers les serveurs, d'autres - ils sont N fois plus - vont vers les spines du premier niveau, c'est-à-dire vers ses liaisons montantes. Les liaisons montantes sont généralement considérées comme égales et le trafic entre les liaisons montantes est équilibré sur la base d'un hachage de 5 tuples, qui inclut proto, src_ip, dst_ip, src_port, dst_port. Pas de surprises ici.
Ensuite, à quoi ressemble l’architecture du plan ? Les épines du premier niveau ne sont pas reliées entre elles, mais sont reliées par des superépines. La lettre X sera responsable des superépines ; c’est presque comme une connexion croisée.
Et il est clair qu’en revanche les tori sont reliés à toutes les épines du premier niveau. Qu’est-ce qui est important dans cette image ? Si nous avons une interaction à l’intérieur du rack, alors l’interaction passe bien sûr par les TdR. Si l’interaction se produit à l’intérieur du module, alors l’interaction se produit à travers les spines de premier niveau. Si l’interaction est intermodulaire – comme ici, ToR 1 et ToR 2 – alors l’interaction passera par les épines du premier et du deuxième niveaux.
En théorie, une telle architecture est facilement évolutive. Si nous disposons d'une capacité portuaire, d'un espace disponible dans le centre de données et d'une fibre pré-installée, le nombre de voies peut toujours être augmenté, augmentant ainsi la capacité globale du système. C'est très simple à faire sur papier. Ce serait comme ça dans la vie. Mais l’histoire d’aujourd’hui ne porte pas sur cela.
Je veux que les bonnes conclusions soient tirées. Nous avons de nombreux chemins à l’intérieur du centre de données. Ils sont conditionnellement indépendants. Un chemin à l’intérieur du centre de données n’est possible qu’à l’intérieur des ToR. A l’intérieur du module, nous avons le nombre de chemins égal au nombre de voies. Le nombre de chemins entre les modules est égal au produit du nombre de plans et du nombre de superspines dans chaque plan. Pour que ce soit plus clair, pour avoir une idée de l'échelle, je donnerai des chiffres valables pour l'un des centres de données Yandex.
Il y a huit avions, chaque avion possède 32 superépines. En conséquence, il s'avère qu'il y a huit chemins à l'intérieur du module, et avec l'interaction intermodule, il y en a déjà 256.
Autrement dit, si nous développons Cookbook et essayons d'apprendre à construire des centres de données tolérants aux pannes et qui s'auto-réparent, alors l'architecture planaire est le bon choix. Cela résout le problème de mise à l’échelle et, en théorie, c’est simple. Il existe de nombreux chemins indépendants. La question demeure : comment une telle architecture peut-elle survivre aux échecs ? Il y a divers échecs. Et nous en discuterons maintenant.
Laissez l’une de nos superépines « tomber malade ». Ici, je suis revenu à l'architecture à deux plans. Nous nous en tiendrons à ces exemples car il sera simplement plus facile de voir ce qui se passe avec moins de pièces mobiles. Laissez X11 tomber malade. Comment cela affectera-t-il les services hébergés dans les centres de données ? Beaucoup dépend de l’apparence réelle de l’échec.
Si la panne est bonne, elle est captée au niveau de l'automatisme du même BFD, l'automatisme met volontiers les joints problématiques et isole le problème, alors tout va bien. Nous avons de nombreux chemins, le trafic est instantanément redirigé vers des itinéraires alternatifs et les services ne remarqueront rien. C'est un bon scénario.
Un mauvais scénario est celui où nous avons des pertes constantes et que l'automatisation ne remarque pas le problème. Pour comprendre comment cela affecte une application, nous devrons passer un peu de temps à discuter du fonctionnement de TCP.
J'espère ne choquer personne avec cette information : TCP est un protocole de confirmation de transmission. Autrement dit, dans le cas le plus simple, l'expéditeur envoie deux paquets et reçoit un accusé de réception cumulatif : "J'ai reçu deux paquets".
Après cela, il enverra deux autres paquets et la situation se répétera. Je m'excuse par avance pour quelques simplifications. Ce scénario est correct si la fenêtre (le nombre de paquets en vol) est de deux. Bien entendu, dans le cas général, ce n’est pas nécessairement le cas. Mais la taille de la fenêtre n'affecte pas le contexte de transfert des paquets.
Que se passe-t-il si nous perdons le paquet 3 ? Dans ce cas, le destinataire recevra les paquets 1, 2 et 4. Et il dira explicitement à l'expéditeur en utilisant l'option SACK : « Vous savez, trois sont arrivés, mais celui du milieu a été perdu. Il dit : "Ack 2, SACK 4".
A ce moment, l'expéditeur répète sans problème exactement le paquet perdu.
Mais si le dernier paquet de la fenêtre est perdu, la situation sera complètement différente.
Le destinataire reçoit les trois premiers paquets et commence tout d'abord à attendre. Grâce à quelques optimisations dans la pile TCP du noyau Linux, il attendra un paquet couplé à moins que les indicateurs n'indiquent explicitement qu'il s'agit du dernier paquet ou quelque chose de similaire. Il attendra l'expiration du délai d'expiration du délai ACK, puis enverra un accusé de réception sur les trois premiers paquets. Mais maintenant, l'expéditeur attendra. Il ne sait pas si le quatrième colis a été perdu ou s’il est sur le point d’arriver. Et afin de ne pas surcharger le réseau, il essaiera d'attendre une indication explicite indiquant que le paquet est perdu ou que le délai RTO expire.
Qu’est-ce que le délai d’expiration du RTO ? Il s'agit du maximum du RTT calculé par la pile TCP et d'une certaine constante. De quel type de constante il s'agit, nous allons maintenant en discuter.
Mais l’important est que si nous manquons encore de chance et que le quatrième paquet est à nouveau perdu, alors le RTO double. Autrement dit, chaque tentative infructueuse signifie doubler le délai d'attente.
Voyons maintenant à quoi correspond cette base. Par défaut, le RTO minimum est de 200 ms. Il s'agit du RTO minimum pour les packages de données. Pour les paquets SYN, c'est différent, 1 seconde. Comme vous pouvez le constater, même la première tentative de renvoi de paquets prendra 100 fois plus de temps que le RTT à l'intérieur du centre de données.
Revenons maintenant à notre scénario. Que se passe-t-il avec le service ? Le service commence à perdre des paquets. Laissez le service avoir d'abord une chance conditionnelle et perdre quelque chose au milieu de la fenêtre, puis il reçoit un SACK et renvoie les paquets perdus.
Mais si la malchance se répète, alors nous avons un RTO. Qu'est-ce qui est important ici ? Oui, nous avons beaucoup de chemins dans notre réseau. Mais le trafic TCP d'une connexion TCP particulière continuera à passer par la même pile cassée. Les pertes de paquets, à condition que notre X11 magique ne s'éteigne pas tout seul, n'entraînent pas un flux de trafic vers des zones qui ne posent pas de problèmes. Nous essayons de livrer le paquet via la même pile cassée. Cela conduit à un échec en cascade : un centre de données est un ensemble d'applications en interaction, et certaines des connexions TCP de toutes ces applications commencent à se dégrader - car la superspine affecte toutes les applications qui existent à l'intérieur du centre de données. Comme le dit le proverbe : si on ne ferre pas un cheval, le cheval boite ; le cheval est devenu boiteux - le rapport n'a pas été remis ; le rapport n'a pas été remis - nous avons perdu la guerre. Seulement ici, le décompte se fait en secondes à partir du moment où le problème surgit jusqu'au stade de dégradation que les services commencent à ressentir. Cela signifie que les utilisateurs peuvent manquer quelque chose quelque part.
Il existe deux solutions classiques qui se complètent. Le premier concerne les services qui essaient de mettre la main à la pâte et de résoudre le problème comme ceci : « Modifions quelque chose dans la pile TCP. Faisons des délais d'attente au niveau de l'application ou des sessions TCP de longue durée avec des contrôles de santé internes. Le problème est que de telles solutions : a) ne sont pas du tout évolutives ; b) sont très mal contrôlés. Autrement dit, même si le service configure accidentellement la pile TCP de manière à la rendre meilleure, premièrement, il est peu probable qu'il soit applicable à toutes les applications et à tous les centres de données, et deuxièmement, très probablement, il ne comprendra pas que cela a été fait. correctement, et que sais-je encore. Autrement dit, cela fonctionne, mais cela fonctionne mal et n'évolue pas. Et s’il y a un problème de réseau, à qui la faute ? Bien sûr, CNO. Que fait le CNO ?
De nombreux services pensent que le travail dans la CNO se déroule à peu près comme ceci. Mais pour être honnête, pas seulement.
Le NOC dans le schéma classique est engagé dans le développement de nombreux systèmes de surveillance. Il s’agit à la fois d’une surveillance en boîte noire et en boîte blanche. À propos d'un exemple de surveillance de la colonne vertébrale par boîte noire Alexander Klimenko au dernier Next Hop. D’ailleurs, cette surveillance fonctionne. Mais même une surveillance idéale aura un décalage dans le temps. Cela dure généralement quelques minutes. Après son déclenchement, les ingénieurs en service ont besoin de temps pour revérifier son fonctionnement, localiser le problème, puis éteindre la zone problématique. Autrement dit, dans le meilleur des cas, le traitement du problème prend 5 minutes, dans le pire des cas, 20 minutes, s'il n'est pas immédiatement évident où se produisent les pertes. Il est clair que pendant tout ce temps - 5 ou 20 minutes - nos services continueront à souffrir, ce qui n'est probablement pas bon.
Qu’aimeriez-vous vraiment recevoir ? Nous avons tellement de façons. Et des problèmes surviennent précisément parce que les flux TCP malchanceux continuent d’emprunter le même itinéraire. Nous avons besoin de quelque chose qui nous permettra d'utiliser plusieurs routes au sein d'une seule connexion TCP. Il semblerait que nous ayons une solution. Il existe TCP, appelé TCP multipath, c'est-à-dire TCP pour plusieurs chemins. Certes, il a été développé pour une tâche complètement différente : pour les smartphones dotés de plusieurs périphériques réseau. Pour maximiser le transfert ou créer un mode principal/sauvegarde, un mécanisme a été développé qui crée plusieurs threads (sessions) de manière transparente pour l'application et vous permet de basculer entre eux en cas de panne. Ou, comme je l'ai dit, maximiser la séquence.
Mais il y a ici une nuance. Pour comprendre de quoi il s’agit, il va falloir regarder comment les threads sont établis.
Les threads sont installés séquentiellement. Le premier thread est installé en premier. Les fils de discussion suivants sont ensuite définis à l'aide du cookie qui a déjà été convenu dans ce fil de discussion. Et voici le problème.
Le problème est que si le premier thread ne s’établit pas, les deuxième et troisième threads n’apparaîtront jamais. Autrement dit, TCP multivoie ne résout pas la perte d'un paquet SYN dans le premier flux. Et si le SYN est perdu, le TCP multipath se transforme en TCP normal. Cela signifie que dans un environnement de centre de données, cela ne nous aidera pas à résoudre le problème des pertes dans l'usine et à apprendre à utiliser plusieurs chemins en cas de panne.
Qu'est-ce qui peut nous aider ? Certains d'entre vous ont déjà deviné, d'après le titre, qu'un champ important dans notre article ultérieur sera le champ d'en-tête de l'étiquette de flux IPv6. En effet, c'est un champ qui apparaît en v6, il ne l'est pas en v4, il occupe 20 bits, et son utilisation fait l'objet de controverses depuis longtemps. C'est très intéressant - il y a eu des différends, quelque chose a été corrigé dans la RFC, et en même temps une implémentation est apparue dans le noyau Linux, qui n'a été documentée nulle part.
Je vous invite à m'accompagner dans une petite enquête. Jetons un coup d'œil à ce qui s'est passé dans le noyau Linux au cours des dernières années.
année 2014. Un ingénieur d'une grande entreprise respectée ajoute aux fonctionnalités du noyau Linux la dépendance de la valeur de l'étiquette de flux sur le hachage du socket. Qu’essayaient-ils de réparer ici ? Ceci est lié à la RFC 6438, qui traite du problème suivant. À l’intérieur du centre de données, IPv4 est souvent encapsulé dans des paquets IPv6, car l’usine elle-même est IPv6, mais IPv4 doit d’une manière ou d’une autre être fourni à l’extérieur. Pendant longtemps, il y avait des problèmes avec les commutateurs qui ne pouvaient pas regarder sous deux en-têtes IP pour accéder à TCP ou UDP et y trouver src_ports, dst_ports. Il s'est avéré que le hachage, si vous regardez les deux premiers en-têtes IP, s'est avéré presque corrigé. Pour éviter cela, afin que l'équilibrage de ce trafic encapsulé fonctionne correctement, il a été proposé d'ajouter le hachage du paquet encapsulé de 5 tuples à la valeur du champ label de flux. À peu près la même chose a été faite pour d'autres schémas d'encapsulation, pour UDP, pour GRE, ce dernier utilisant le champ GRE Key. D’une manière ou d’une autre, les objectifs ici sont clairs. Et au moins à cette époque, ils étaient utiles.
En 2015, un nouveau patch vient du même ingénieur respecté. Il est très intéressant. Il dit ce qui suit : nous allons randomiser le hachage en cas d'événement de routage négatif. Qu'est-ce qu'un événement de routage négatif ? Il s’agit du RTO dont nous avons parlé plus tôt, c’est-à-dire que la perte de la queue de la fenêtre est un événement véritablement négatif. Certes, il est relativement difficile de deviner que c'est cela.
2016, une autre entreprise réputée, également grande. Il démonte les dernières béquilles et fait en sorte que le hachage, que nous rendions auparavant aléatoire, change désormais à chaque retransmission SYN et après chaque timeout RTO. Et dans cette lettre, pour la première et la dernière fois, l'objectif ultime est énoncé : garantir que le trafic en cas de pertes ou de congestion des canaux puisse être réacheminé en douceur et emprunter plusieurs chemins. Bien sûr, après cela, il y a eu beaucoup de publications, vous pouvez facilement les retrouver.
Mais non, c’est impossible, car il n’y a pas eu une seule publication sur ce sujet. Mais nous le savons !
Et si vous ne comprenez pas bien ce qui a été fait, je vais vous le dire maintenant.
Qu'a été fait, quelle fonctionnalité a été ajoutée au noyau Linux ? txhash prend une valeur aléatoire après chaque événement RTO. C'est le résultat très négatif du routage. Le hachage dépend de ce txhash et l'étiquette de flux dépend du hachage skb. Il y a ici quelques calculs sur les fonctions ; tous les détails ne peuvent pas être placés sur une seule diapositive. Si quelqu'un est curieux, vous pouvez parcourir le code du noyau et vérifier.
Qu'est-ce qui est important ici ? La valeur du champ d’étiquette de flux devient un nombre aléatoire après chaque RTO. Comment cela affecte-t-il notre malheureux flux TCP ?
Si un SACK se produit, rien ne change car nous essayons de renvoyer un paquet perdu connu. Jusqu'ici, tout va bien.
Mais dans le cas du RTO, à condition d’avoir ajouté un label de flux à la fonction de hachage sur ToR, le trafic peut emprunter un itinéraire différent. Et plus il y a de voies, plus il y a de chances qu'il trouve un chemin qui ne soit pas affecté par une panne sur un appareil spécifique.
Un problème demeure : le RTO. Bien sûr, il existe une autre voie, mais on perd beaucoup de temps là-dessus. 200 ms, c'est beaucoup. Une seconde est absolument sauvage. Auparavant, j'ai parlé des délais d'attente pendant lesquels les services sont configurés. Ainsi, une seconde est un délai d'attente, qui est généralement configuré par le service au niveau de l'application, et le service aura même relativement raison en cela. De plus, je le répète, le RTT réel à l’intérieur d’un centre de données moderne est d’environ 1 milliseconde.
Que pouvez-vous faire avec les délais d’attente RTO ? Le timeout, qui est responsable du RTO en cas de perte de paquets de données, peut être configuré relativement facilement depuis l'espace utilisateur : il existe un utilitaire IP, et l'un de ses paramètres contient le même rto_min. Étant donné que le RTO, bien sûr, doit être ajusté non pas globalement, mais pour des préfixes donnés, un tel mécanisme semble tout à fait réalisable.
Certes, avec SYN_RTO, tout est un peu pire. Il est naturellement cloué. Le noyau a une valeur fixe de 1 seconde, et c'est tout. Vous ne pouvez pas y accéder depuis l'espace utilisateur. Il n'y a qu'une seule façon.
L'eBPF vient à la rescousse. Pour faire simple, ce sont des petits programmes C. Ils peuvent être insérés dans des hooks à différents endroits de l'exécution de la pile noyau et de la pile TCP, avec lesquels vous pouvez modifier un très grand nombre de paramètres. En général, l’eBPF est une tendance à long terme. Au lieu de supprimer des dizaines de nouveaux paramètres sysctl et d'étendre l'utilitaire IP, le mouvement s'oriente vers eBPF et étend ses fonctionnalités. À l'aide d'eBPF, vous pouvez modifier dynamiquement les contrôles de congestion et divers autres paramètres TCP.
Mais il est important pour nous qu'il puisse être utilisé pour modifier les valeurs SYN_RTO. De plus, il existe un exemple publié publiquement : . Qu'est-ce qui a été fait ici ? L’exemple fonctionne, mais en soi il est très approximatif. Ici, on suppose qu'à l'intérieur du centre de données, nous comparons les 44 premiers bits ; s'ils correspondent, alors nous sommes à l'intérieur du centre de données. Et dans ce cas, nous modifions la valeur du délai d'attente SYN_RTO à 4 ms. La même tâche peut être accomplie avec beaucoup plus d’élégance. Mais cet exemple simple montre que cela est a) possible ; b) relativement simple.
Que sait-on déjà ? Le fait que l'architecture plane permette la mise à l'échelle s'avère extrêmement utile pour nous lorsque nous activons l'étiquette de flux sur les ToR et obtenons la possibilité de contourner les zones à problèmes. La meilleure façon de réduire les valeurs RTO et SYN-RTO est d'utiliser les programmes eBPF. La question demeure : est-il sécuritaire d’utiliser une étiquette de flux pour l’équilibrage ? Et il y a ici une nuance.
Supposons que vous disposiez d'un service sur votre réseau qui réside dans anycast. Malheureusement, je n'ai pas le temps de rentrer dans les détails de ce qu'est anycast, mais il s'agit d'un service distribué avec différents serveurs physiques accessibles via la même adresse IP. Et voici un problème possible : l'événement RTO peut se produire non seulement lorsque le trafic traverse la structure. Cela peut également se produire au niveau du tampon ToR : lorsqu'un événement incast se produit, il peut même se produire sur l'hôte lorsque celui-ci renverse quelque chose. Lorsqu'un événement RTO se produit et qu'il modifie l'étiquette du flux. Dans ce cas, le trafic peut être dirigé vers une autre instance anycast. Supposons qu'il s'agisse d'un anycast avec état, il contient un état de connexion - il peut s'agir d'un équilibreur L3 ou d'un autre service. Un problème surgit alors, car après RTO, la connexion TCP arrive sur le serveur, qui ne sait rien de cette connexion TCP. Et si nous n'avons pas de partage d'état entre les serveurs anycast, alors ce trafic sera abandonné et la connexion TCP sera interrompue.
Que pouvez-vous faire ici? Dans votre environnement contrôlé, où vous activez l'équilibrage des étiquettes de flux, vous devez enregistrer la valeur de l'étiquette de flux lorsque vous accédez aux serveurs anycast. Le moyen le plus simple est de le faire via le même programme eBPF. Mais voici un point très important : que faire si vous n'exploitez pas de réseau de centre de données, mais êtes un opérateur télécom ? C'est aussi votre problème : à partir de certaines versions de Juniper et Arista, ils incluent par défaut une étiquette de flux dans leurs fonctions de hachage - franchement, pour une raison qui ne m'est pas claire. Cela peut vous amener à abandonner les connexions TCP des utilisateurs passant par votre réseau. Je vous recommande donc fortement de vérifier les paramètres de votre routeur ici.
D'une manière ou d'une autre, il me semble que nous sommes prêts à passer à l'expérimentation.
Lorsque nous avons activé l'étiquette de flux sur ToR et préparé l'agent eBPF, qui vit désormais sur les hôtes, nous avons décidé de ne pas attendre le prochain gros échec, mais de procéder à des explosions contrôlées. Nous avons pris ToR, qui comporte quatre liaisons montantes, et mis en place des drop sur l'une d'entre elles. Ils ont dessiné une règle et ont dit : maintenant vous perdez tous les paquets. Comme vous pouvez le voir à gauche, nous avons une surveillance par paquet, qui est tombée à 75 %, soit 25 % des paquets sont perdus. À droite se trouvent des graphiques des services vivant derrière ces TdR. Il s'agit essentiellement de graphiques de trafic des interfaces avec les serveurs à l'intérieur du rack. Comme vous pouvez le constater, ils ont coulé encore plus bas. Pourquoi ont-ils baissé - non pas de 25 %, mais dans certains cas de 3 à 4 fois ? Si la connexion TCP n’a pas de chance, elle continue d’essayer d’atteindre la jonction interrompue. Ceci est aggravé par le comportement typique du service à l'intérieur du DC - pour une demande utilisateur, N demandes aux services internes sont générées et la réponse sera envoyée à l'utilisateur soit lorsque toutes les sources de données répondent, soit lorsqu'un délai d'attente se produit au niveau de l'application. niveau, qui doit encore être configuré. Autrement dit, tout va très, très mal.
Maintenant, la même expérience, mais avec la valeur de l'étiquette de flux activée. Comme vous pouvez le constater, à gauche, notre suivi des lots a diminué du même 25 %. C'est tout à fait exact, car il ne sait rien des retransmissions, il envoie des paquets et compte simplement le rapport entre le nombre de paquets livrés et perdus.
Et à droite se trouve le calendrier des services. Vous ne retrouverez pas ici l’effet d’une articulation problématique. Au cours de ces mêmes millisecondes, le trafic s'est déplacé de la zone à problème vers les trois liaisons montantes restantes qui n'étaient pas affectées par le problème. Nous avons un réseau qui se guérit tout seul.
Ceci est ma dernière diapositive, il est temps de résumer. Maintenant, j'espère que vous savez comment créer un réseau de centres de données auto-réparateur. Vous n'aurez pas besoin de parcourir l'archive du noyau Linux et d'y rechercher des correctifs spéciaux ; vous savez que l'étiquette Flow dans ce cas résout le problème, mais vous devez aborder ce mécanisme avec prudence. Et je souligne encore une fois que si vous êtes un opérateur télécom, vous ne devez pas utiliser flow label comme fonction de hachage, sous peine de perturber les sessions de vos utilisateurs.
Les ingénieurs réseau doivent opérer un changement conceptuel : le réseau ne commence pas par les TdR, ni par le périphérique réseau, mais par l'hôte. Un exemple assez frappant est la manière dont nous utilisons eBPF à la fois pour modifier le RTO et pour corriger l'étiquette de flux vers les services anycast.
La mécanique des étiquettes de flux convient certainement à d’autres applications au sein du segment administratif contrôlé. Il peut s'agir de trafic entre centres de données, ou vous pouvez utiliser ces mécanismes de manière spéciale pour gérer le trafic sortant. Mais je vous en parlerai, j'espère, la prochaine fois. Merci beaucoup pour votre attention.
Source: habr.com