Nous avons développé une conception de réseau de centre de données qui permet le déploiement de clusters informatiques de plus de 100 XNUMX serveurs avec une bande passante maximale de plus d'un pétaoctet par seconde.
Dans le rapport de Dmitry Afanasyev, vous découvrirez les principes de base de la nouvelle conception, la mise à l'échelle des topologies, les problèmes qui en découlent, les options pour les résoudre, les caractéristiques de routage et la mise à l'échelle des fonctions du plan de transfert des périphériques réseau modernes dans les environnements « densément connectés ». topologies avec un grand nombre de routes ECMP. En outre, Dima a brièvement parlé de l'organisation de la connectivité externe, de la couche physique, du système de câblage et des moyens d'augmenter encore la capacité.
- Bonjour à tous ! Je m'appelle Dmitry Afanasyev, je suis architecte réseau chez Yandex et je conçois principalement des réseaux de centres de données.
Mon histoire portera sur le réseau mis à jour des centres de données Yandex. Il s'agit en grande partie d'une évolution du design que nous avions, mais en même temps il y a de nouveaux éléments. Il s’agit d’une présentation générale car il y avait beaucoup d’informations à regrouper en peu de temps. Nous allons commencer par choisir une topologie logique. Ensuite, il y aura un aperçu du plan de contrôle et des problèmes d'évolutivité du plan de données, un choix de ce qui se passera au niveau physique, et nous examinerons certaines fonctionnalités des appareils. Parlons un peu de ce qui se passe dans un centre de données avec MPLS, dont nous avons parlé il y a quelque temps.
Alors, qu'est-ce que Yandex en termes de charges et de services ? Yandex est un hyperscaler typique. Si nous regardons les utilisateurs, nous traitons principalement les demandes des utilisateurs. Également divers services de streaming et transfert de données, car nous disposons également de services de stockage. Si l'on est plus proche du backend, les charges et les services d'infrastructure y apparaissent, tels que le stockage d'objets distribués, la réplication de données et, bien sûr, les files d'attente persistantes. L'un des principaux types de charges de travail est MapReduce et les systèmes similaires, le traitement des flux, l'apprentissage automatique, etc.
Comment se situe l’infrastructure sur laquelle tout cela se passe ? Encore une fois, nous sommes un hyperscaler assez typique, même si nous sommes peut-être un peu plus proches du côté inférieur du spectre hyperscaler. Mais nous avons tous les attributs. Nous utilisons du matériel de base et une mise à l'échelle horizontale dans la mesure du possible. Nous disposons d'une mutualisation complète des ressources : nous ne travaillons pas avec des machines individuelles, des racks individuels, mais les combinons dans un vaste pool de ressources interchangeables avec des services supplémentaires qui traitent de la planification et de l'allocation, et travaillons avec l'ensemble de ce pool.
Nous avons donc le niveau suivant : le système d'exploitation au niveau du cluster informatique. Il est très important que nous contrôlions pleinement la pile technologique que nous utilisons. Nous contrôlons les points finaux (hôtes), le réseau et la pile logicielle.
Nous disposons de plusieurs grands centres de données en Russie et à l'étranger. Ils sont unis par une dorsale qui utilise la technologie MPLS. Notre infrastructure interne est presque entièrement construite sur IPv6, mais comme nous devons desservir un trafic externe qui provient toujours principalement de IPv4, nous devons d'une manière ou d'une autre transmettre les requêtes arrivant via IPv4 aux serveurs frontaux, et un peu plus aller vers IPv4 externe - Internet - par exemple. par exemple, pour l'indexation.
Les dernières itérations de conceptions de réseaux de centres de données ont utilisé des topologies Clos multicouches et sont uniquement L3. Nous avons quitté L2 il y a quelques temps et avons poussé un soupir de soulagement. Enfin, notre infrastructure comprend des centaines de milliers d'instances de calcul (serveur). Il y a quelque temps, la taille maximale d'un cluster était d'environ 10 100 serveurs. Cela est dû en grande partie à la façon dont peuvent fonctionner ces mêmes systèmes d'exploitation, planificateurs, allocation de ressources, etc. au niveau du cluster. Depuis que des progrès ont été réalisés du côté des logiciels d'infrastructure, la taille cible est désormais d'environ XNUMX XNUMX serveurs dans un cluster informatique, et Nous avons une tâche : être capable de construire des usines de réseaux permettant une mutualisation efficace des ressources dans un tel cluster.
Qu’attendons-nous d’un réseau de centres de données ? Tout d’abord, il existe une grande bande passante bon marché et assez uniformément répartie. Parce que le réseau est l’épine dorsale à travers laquelle nous pouvons mutualiser les ressources. La nouvelle taille cible est d'environ 100 XNUMX serveurs dans un cluster.
Nous souhaitons également, bien sûr, un plan de contrôle évolutif et stable, car sur une infrastructure aussi vaste, de nombreux problèmes surviennent même à partir d'événements simplement aléatoires, et nous ne voulons pas que le plan de contrôle nous apporte également des maux de tête. Dans le même temps, nous voulons minimiser l’état qui s’y trouve. Plus la condition est petite, plus tout fonctionne de manière efficace et stable, et plus il est facile à diagnostiquer.
Bien sûr, nous avons besoin d’automatisation, car il est impossible de gérer manuellement une telle infrastructure, et cela depuis un certain temps. Nous avons besoin d’un soutien opérationnel autant que possible et d’un soutien CI/CD dans la mesure où il peut être fourni.
Avec de telles tailles de centres de données et de clusters, la tâche consistant à prendre en charge un déploiement et une expansion incrémentiels sans interruption de service est devenue très aiguë. Si sur des clusters d'un millier de machines, peut-être près de dix mille machines, elles pouvaient toujours être déployées en une seule opération - c'est-à-dire que nous prévoyons une expansion de l'infrastructure et que plusieurs milliers de machines sont ajoutées en une seule opération, alors un cluster d'une taille de cent mille machines ne surgit pas immédiatement comme ça, il se construit sur une période de temps. Et il est souhaitable que pendant tout ce temps, ce qui a déjà été pompé, l'infrastructure déployée, soit disponible.
Et une exigence que nous avions et que nous avons laissée : la prise en charge de la multilocation, c'est-à-dire la virtualisation ou la segmentation du réseau. Désormais, nous n'avons plus besoin de le faire au niveau de la structure réseau, car le partitionnement est allé vers les hôtes, ce qui a rendu la mise à l'échelle très facile pour nous. Grâce à IPv6 et à un grand espace d'adressage, nous n'avons pas eu besoin d'utiliser des adresses en double dans l'infrastructure interne ; chaque adressage était déjà unique. Et grâce au fait que nous avons transféré le filtrage et la segmentation du réseau aux hôtes, nous n'avons pas besoin de créer d'entités de réseau virtuel dans les réseaux des centres de données.
Une chose très importante est ce dont nous n’avons pas besoin. Si certaines fonctions peuvent être supprimées du réseau, cela facilite grandement la vie et, en règle générale, élargit le choix des équipements et des logiciels disponibles, rendant ainsi les diagnostics très simples.
Alors, de quoi n’avons-nous pas besoin, de quoi avons-nous pu renoncer, pas toujours avec joie au moment où cela s’est produit, mais avec un grand soulagement une fois le processus terminé ?
Tout d’abord, abandonner la L2. Nous n'avons pas besoin de L2, ni réel ni émulé. Inutilisé en grande partie en raison du fait que nous contrôlons la pile d’applications. Nos applications sont évolutives horizontalement, elles fonctionnent avec l'adressage L3, elles ne s'inquiètent pas beaucoup qu'une instance individuelle soit sortie, elles en déploient simplement une nouvelle, il n'est pas nécessaire de la déployer à l'ancienne adresse, car il y a un niveau distinct de découverte de service et de surveillance des machines situées dans le cluster. Nous ne déléguons pas cette tâche au réseau. Le travail du réseau consiste à acheminer les paquets d'un point A à un point B.
Nous n'avons pas non plus de situations où les adresses se déplacent au sein du réseau, et cela doit être surveillé. Dans de nombreuses conceptions, cela est généralement nécessaire pour prendre en charge la mobilité des machines virtuelles. Nous n'utilisons pas la mobilité des machines virtuelles dans l'infrastructure interne du grand Yandex et, de plus, nous pensons que même si cela était fait, cela ne devrait pas se produire avec le support réseau. Si cela doit vraiment être fait, il faut le faire au niveau de l'hôte, et pousser des adresses qui peuvent migrer vers des overlays, afin de ne pas toucher ou faire trop de changements dynamiques au système de routage de la sous-couche elle-même (réseau de transport). .
Une autre technologie que nous n’utilisons pas est le multicast. Si vous le souhaitez, je peux vous expliquer en détail pourquoi. Cela rend la vie beaucoup plus facile, car si quelqu'un s'en est occupé et a regardé exactement à quoi ressemble le plan de contrôle multicast, dans toutes les installations, sauf les plus simples, cela constitue un gros casse-tête. De plus, il est difficile de trouver une implémentation open source qui fonctionne bien, par exemple.
Enfin, nous concevons nos réseaux pour qu'ils ne changent pas trop. On peut compter sur le fait que le flux d'événements externes dans le système de routage est faible.
Quels problèmes se posent et quelles restrictions doivent être prises en compte lorsque nous développons un réseau de centres de données ? Le coût, bien sûr. L'évolutivité, le niveau auquel nous voulons grandir. La nécessité de se développer sans arrêter le service. Bande passante, disponibilité. Visibilité de ce qui se passe sur le réseau pour les systèmes de surveillance, pour les équipes opérationnelles. Prise en charge de l'automatisation - encore une fois, autant que possible, puisque différentes tâches peuvent être résolues à différents niveaux, y compris l'introduction de couches supplémentaires. Eh bien, pas [possiblement] dépendant des fournisseurs. Bien qu'à différentes périodes historiques, selon la section que l'on regarde, cette indépendance était plus facile ou plus difficile à atteindre. Si nous prenons un échantillon représentatif de puces de périphériques réseau, jusqu'à récemment, il était très conditionnel de parler d'indépendance vis-à-vis des fournisseurs, si nous voulions également des puces à haut débit.
Quelle topologie logique allons-nous utiliser pour construire notre réseau ? Ce sera un Clos à plusieurs niveaux. En fait, il n’existe actuellement aucune véritable alternative. Et la topologie Clos est assez bonne, même si on la compare à diverses topologies avancées qui relèvent désormais davantage du domaine d'intérêt académique, si nous avons de grands commutateurs de base.
Comment est structuré grossièrement un réseau Clos multi-niveaux et quels sont les différents éléments qui y sont appelés ? Tout d’abord, le vent s’est levé, pour vous orienter où est le nord, où est le sud, où est l’est, où est l’ouest. Les réseaux de ce type sont généralement construits par ceux qui ont un trafic ouest-est très important. Quant aux éléments restants, en haut se trouve un commutateur virtuel assemblé à partir de commutateurs plus petits. C'est l'idée principale de la construction récursive des réseaux Clos. Nous prenons des éléments avec une sorte de base et les connectons de manière à ce que ce que nous obtenons puisse être considéré comme un interrupteur avec une base plus grande. Si vous en avez besoin d'encore plus, la procédure peut être répétée.
Dans les cas, par exemple, de Clos à deux niveaux, lorsqu'il est possible d'identifier clairement les composants verticaux dans mon schéma, ils sont généralement appelés plans. Si nous devions construire un Clos avec trois niveaux de commutateurs spine (qui ne sont pas tous des commutateurs de frontière ou de ToR et qui sont utilisés uniquement pour le transit), alors les avions auraient l'air plus complexes ; ceux à deux niveaux ressemblent exactement à ceci. Nous appelons un bloc de commutateurs ToR ou leaf et les commutateurs spine de premier niveau qui leur sont associés un pod. Les commutateurs spine du niveau spine-1 en haut du Pod sont le haut du Pod, le haut du Pod. Les interrupteurs situés au sommet de toute l’usine constituent la couche supérieure de l’usine, le dessus du tissu.
Bien sûr, la question se pose : les réseaux Clos existent depuis longtemps ; l'idée elle-même vient généralement de l'époque de la téléphonie classique, les réseaux TDM. Peut-être que quelque chose de mieux est apparu, peut-être que quelque chose peut être fait mieux ? Oui et non. Théoriquement oui, dans la pratique dans un avenir proche, certainement pas. Parce qu'il existe un certain nombre de topologies intéressantes, certaines d'entre elles sont même utilisées en production, par exemple Dragonfly est utilisé dans les applications HPC ; Il existe également des topologies intéressantes comme Xpander, FatClique, Jellyfish. Si vous regardez récemment les rapports de conférences comme SIGCOMM ou NSDI, vous pouvez trouver un assez grand nombre de travaux sur des topologies alternatives qui ont de meilleures propriétés (l'une ou l'autre) que Clos.
Mais toutes ces topologies ont une propriété intéressante. Cela empêche leur mise en œuvre dans les réseaux de centres de données, que nous essayons de construire sur du matériel standard et qui coûtent assez cher. Dans toutes ces topologies alternatives, la majeure partie de la bande passante n’est malheureusement pas accessible via les chemins les plus courts. Par conséquent, nous perdons immédiatement la possibilité d’utiliser le plan de contrôle traditionnel.
Théoriquement, la solution au problème est connue. Il s'agit, par exemple, de modifications de l'état des liens en utilisant le chemin le plus court k, mais, encore une fois, il n'existe aucun protocole de ce type qui serait implémenté en production et largement disponible sur les équipements.
De plus, comme la majeure partie de la capacité n'est pas accessible via les chemins les plus courts, nous devons modifier plus que simplement le plan de contrôle pour sélectionner tous ces chemins (et en passant, cela représente beaucoup plus d'état dans le plan de contrôle). Nous devons encore modifier le plan de transfert et, en règle générale, au moins deux fonctionnalités supplémentaires sont requises. Il s'agit de la possibilité de prendre toutes les décisions concernant le transfert de paquets une seule fois, par exemple sur l'hôte. En fait, il s'agit du routage source, parfois dans la littérature sur les réseaux d'interconnexion, cela est appelé décisions de transfert tout-en-un. Et le routage adaptatif est une fonction dont nous avons besoin sur les éléments du réseau, qui se résume, par exemple, au fait que nous sélectionnons le saut suivant en fonction des informations sur la moindre charge sur la file d'attente. A titre d'exemple, d'autres options sont possibles.
La direction est donc intéressante, mais, hélas, nous ne pouvons pas l’appliquer pour le moment.
D'accord, nous avons opté pour la topologie logique Clos. Comment allons-nous le faire évoluer ? Voyons comment cela fonctionne et ce qui peut être fait.
Dans un réseau Clos, il existe deux paramètres principaux que nous pouvons varier d'une manière ou d'une autre et obtenir certains résultats : la base des éléments et le nombre de niveaux dans le réseau. J'ai un diagramme schématique de la façon dont les deux affectent la taille. Idéalement, nous combinons les deux.
On peut voir que la largeur finale du réseau Clos est le produit de tous les niveaux de commutateurs spine de la base sud, du nombre de liaisons que nous avons, de la façon dont il se ramifie. C'est ainsi que nous adaptons la taille du réseau.
Concernant la capacité, en particulier sur les commutateurs ToR, il existe deux options de mise à l'échelle. Soit on peut, tout en conservant la topologie générale, utiliser des liens plus rapides, soit on peut ajouter davantage de plans.
Si vous regardez la version étendue du réseau Clos (en bas à droite) et revenez à cette image avec le réseau Clos ci-dessous...
... alors c'est exactement la même topologie, mais sur cette diapositive elle est réduite de manière plus compacte et les plans de l'usine se superposent les uns aux autres. C'est le même.
À quoi ressemble la mise à l’échelle d’un réseau Clos en chiffres ? Ici, je fournis des données sur la largeur maximale qu'un réseau peut être obtenu, le nombre maximum de racks, de commutateurs ToR ou de commutateurs leaf, s'ils ne sont pas dans des racks, que nous pouvons obtenir en fonction de la base de commutateurs que nous utilisons pour les niveaux spine, et combien de niveaux nous utilisons.
Voici combien de racks nous pouvons avoir, combien de serveurs et approximativement combien tout cela peut consommer sur la base de 20 kW par rack. Un peu plus tôt, j'ai mentionné que nous visons une taille de cluster d'environ 100 XNUMX serveurs.
On peut voir que dans toute cette conception, deux options et demie sont intéressantes. Il existe une option avec deux couches de spines et des commutateurs à 64 ports, ce qui est un peu court. Il existe ensuite des options parfaitement adaptées pour les commutateurs spine à 128 ports (avec base 128) à deux niveaux, ou les commutateurs avec base 32 à trois niveaux. Et dans tous les cas, où il y a plus de bases et plus de couches, vous pouvez créer un très grand réseau, mais si vous regardez la consommation attendue, il y a généralement des gigawatts. Il est possible de poser un câble, mais il est peu probable que nous puissions obtenir autant d'électricité sur un seul site. Si vous examinez les statistiques et les données publiques sur les centres de données, vous trouverez très peu de centres de données d’une capacité estimée à plus de 150 MW. Les plus grands sont généralement des campus de centres de données, plusieurs grands centres de données situés assez proches les uns des autres.
Il y a un autre paramètre important. Si vous regardez la colonne de gauche, la bande passante utilisable y est répertoriée. Il est facile de constater que dans un réseau Clos, une partie importante des ports est utilisée pour connecter les commutateurs entre eux. La bande passante utilisable, une bande utile, est quelque chose qui peut être donnée à l'extérieur, vers les serveurs. Naturellement, je parle des ports conditionnels et plus particulièrement du groupe. En règle générale, les liens au sein du réseau sont plus rapides que les liens vers les serveurs, mais par unité de bande passante, même si nous pouvons l'envoyer à notre équipement serveur, il reste encore une certaine bande passante au sein du réseau lui-même. Et plus nous créons de niveaux, plus le coût spécifique lié à la fourniture de cette bande à l'extérieur est élevé.
De plus, même cette bande supplémentaire n’est pas exactement la même. Bien que les portées soient courtes, nous pouvons utiliser quelque chose comme le DAC (cuivre à connexion directe, c'est-à-dire des câbles twinax) ou des optiques multimodes, qui coûtent encore plus ou moins raisonnablement. Dès que nous passons à des portées plus longues, il s'agit généralement d'optiques monomodes, et le coût de cette bande passante supplémentaire augmente sensiblement.
Et encore une fois, en revenant à la diapositive précédente, si nous créons un réseau Clos sans surabonnement, alors il est facile de regarder le schéma, de voir comment le réseau est construit - en ajoutant chaque niveau de commutateurs spine, nous répétons toute la bande qui était au bas. Niveau Plus : plus la même bande, le même nombre de ports sur les commutateurs qu'au niveau précédent et le même nombre d'émetteurs-récepteurs. Par conséquent, il est hautement souhaitable de minimiser le nombre de niveaux de commutateurs spinaux.
Sur la base de cette image, il est clair que nous voulons vraiment construire sur quelque chose comme des commutateurs avec une base de 128.
Ici, en principe, tout est comme ce que je viens de dire, c'est une diapositive à examiner plus tard.
Quelles options pouvons-nous choisir en tant que tels commutateurs ? C'est une très bonne nouvelle pour nous que de tels réseaux puissent enfin être construits sur des commutateurs monopuce. Et c'est très cool, ils ont beaucoup de fonctionnalités intéressantes. Par exemple, ils n’ont quasiment aucune structure interne. Cela signifie qu'ils se cassent plus facilement. Ils se brisent de toutes sortes de manières, mais heureusement, ils se brisent complètement. Dans les appareils modulaires, il y a un grand nombre de défauts (très désagréables), quand du point de vue des voisins et du plan de contrôle, cela semble fonctionner, mais, par exemple, une partie du tissu a été perdue et cela ne fonctionne pas à pleine capacité. Et le trafic vers celui-ci est équilibré sur la base du fait qu'il est entièrement fonctionnel et que nous pouvons être surchargés.
Ou, par exemple, des problèmes surviennent avec le fond de panier, car à l'intérieur du dispositif modulaire se trouvent également des SerDes à grande vitesse - c'est vraiment complexe à l'intérieur. Soit les signes entre les éléments transmetteurs sont synchronisés, soit ils ne sont pas synchronisés. En général, tout dispositif modulaire productif composé d'un grand nombre d'éléments contient généralement le même réseau Clos en lui-même, mais il est très difficile à diagnostiquer. Il est souvent difficile, même pour le vendeur lui-même, de faire un diagnostic.
Et il existe un grand nombre de scénarios de défaillance dans lesquels le périphérique se dégrade, mais ne sort pas complètement de la topologie. Puisque notre réseau est vaste, l'équilibrage entre éléments identiques est activement utilisé, le réseau est très régulier, c'est-à-dire qu'un chemin sur lequel tout est en ordre n'est pas différent de l'autre chemin, il est plus rentable pour nous de simplement perdre une partie de les appareils de la topologie plutôt que de se retrouver dans une situation où certains d'entre eux semblent fonctionner, mais d'autres non.
La prochaine caractéristique intéressante des appareils monopuces est qu’ils évoluent mieux et plus rapidement. Ils ont également tendance à avoir une meilleure capacité. Si nous prenons les grandes structures assemblées que nous avons sur un cercle, alors la capacité par unité de rack pour les ports de même vitesse est presque deux fois supérieure à celle des appareils modulaires. Les appareils construits autour d’une seule puce sont nettement moins chers que les appareils modulaires et consomment moins d’énergie.
Mais bien sûr, tout cela n’est pas sans raison, il y a aussi des inconvénients. Premièrement, la base est presque toujours plus petite que celle des appareils modulaires. Si nous pouvons obtenir un appareil construit autour d’une puce avec 128 ports, alors nous pouvons maintenant en obtenir un modulaire avec plusieurs centaines de ports sans aucun problème.
Il s'agit d'une taille sensiblement plus petite des tables de transfert et, en règle générale, de tout ce qui concerne l'évolutivité du plan de données. Tampons peu profonds. Et, en règle générale, des fonctionnalités plutôt limitées. Mais il s'avère que si vous connaissez ces restrictions et prenez soin de les contourner à temps ou simplement de les prendre en compte, alors ce n'est pas si effrayant. Le fait que la base soit plus petite n'est plus un problème sur les appareils avec une base de 128 qui sont enfin apparus récemment : on peut construire deux couches d'épines. Mais il est toujours impossible de construire quelque chose de plus petit que deux qui soit intéressant pour nous. Avec un seul niveau, de très petits clusters sont obtenus. Même nos conceptions et exigences précédentes les dépassaient encore.
En fait, si soudainement la solution se trouve au bord du gouffre, il reste encore un moyen de la mettre à l’échelle. Étant donné que le dernier (ou premier) niveau le plus bas auquel les serveurs sont connectés sont des commutateurs ToR ou des commutateurs leaf, nous ne sommes pas obligés d'y connecter un rack. Par conséquent, si la solution échoue de moitié environ, vous pouvez simplement envisager d'utiliser un commutateur avec une grande base au niveau inférieur et de connecter, par exemple, deux ou trois racks en un seul commutateur. C'est aussi une option, elle a son coût, mais elle fonctionne plutôt bien et peut être une bonne solution lorsque vous devez atteindre environ deux fois la taille.
Pour résumer, nous construisons sur une topologie à deux niveaux de spines, avec huit couches d'usine.
Qu’arrivera-t-il à la physique ? Calculs très simples. Si nous avons deux niveaux de spines, alors nous n'avons que trois niveaux de commutateurs, et nous nous attendons à ce qu'il y ait trois segments de câbles dans le réseau : des serveurs aux commutateurs feuilles, en passant par le spine 1 et le spine 2. Les options que nous pouvons les utilisations sont - ce sont twinax, multimode, monomode. Et ici, nous devons considérer quelle bande est disponible, combien cela coûtera, quelles sont ses dimensions physiques, quelles portées nous pouvons couvrir et comment nous allons procéder à la mise à niveau.
En termes de coût, tout peut être aligné. Les Twinaxes sont nettement moins chers que les optiques actives, moins chers que les émetteurs-récepteurs multimodes, si vous les prenez par vol depuis la fin, un peu moins chers qu'un port de commutation de 100 gigabits. Et, veuillez noter que cela coûte moins cher que l'optique monomode, car sur les vols où un mode unique est requis, dans les centres de données, pour un certain nombre de raisons, il est logique d'utiliser CWDM, tandis que le mode monomode parallèle (PSM) n'est pas très pratique à travailler. avec, de très gros paquets sont obtenus fibres, et si nous nous concentrons sur ces technologies, nous obtenons approximativement la hiérarchie de prix suivante.
Encore une remarque : malheureusement, il n'est pas très possible d'utiliser des ports multimodes 100 à 4x25 démontés. En raison des caractéristiques de conception des émetteurs-récepteurs SFP28, il n'est pas beaucoup moins cher que le QSFP28 100 Gbit. Et ce démontage pour le multimode ne fonctionne pas très bien.
Une autre limitation est qu’en raison de la taille des clusters informatiques et du nombre de serveurs, nos centres de données s’avèrent physiquement grands. Cela signifie qu'au moins un vol devra être effectué avec un seul mod. Encore une fois, en raison de la taille physique des Pods, il ne sera pas possible de faire passer deux travées de twinax (câbles en cuivre).
En conséquence, si nous optimisons le prix et prenons en compte la géométrie de cette conception, nous obtenons une travée twinax, une travée multimode et une travée monomode utilisant CWDM. Cela prend en compte les chemins de mise à niveau possibles.
Voilà à quoi cela ressemble récemment, vers où nous nous dirigeons et ce qui est possible. Il est au moins clair comment évoluer vers des SerDes 50 Gigabit pour le multimode et le monomode. De plus, si vous regardez ce qu'il y a dans les émetteurs-récepteurs monomodes actuels et futurs pour 400G, souvent même lorsque des SerDes 50G arrivent du côté électrique, 100 Gbit/s par voie peuvent déjà aller à l'optique. Par conséquent, il est fort possible qu'au lieu de passer à 50, il y ait une transition vers 100 Gigabit SerDes et 100 Gbps par voie, car selon les promesses de nombreux fournisseurs, leur disponibilité est attendue assez prochainement. Il semble que la période pendant laquelle les SerDes 50G étaient les plus rapides ne sera pas très longue, car les premiers exemplaires des SerDes 100G seront déployés presque l'année prochaine. Et après un certain temps, ils vaudront probablement de l’argent raisonnable.
Encore une nuance sur le choix de la physique. En principe, nous pouvons déjà utiliser des ports 400 ou 200 Gigabit en utilisant des SerDes 50G. Mais il s’avère que cela n’a pas beaucoup de sens, car, comme je l’ai dit plus tôt, nous voulons une base assez grande sur les commutateurs, dans la limite du raisonnable bien sûr. Nous en voulons 128. Et si nous avons une capacité de puce limitée et que nous augmentons la vitesse de liaison, alors la base diminue naturellement, il n'y a pas de miracles.
Et nous pouvons augmenter la capacité totale en utilisant des avions, et il n'y a pas de coûts particuliers ; nous pouvons ajouter le nombre d'avions. Et si nous perdons la base, nous devrons introduire un niveau supplémentaire, donc dans la situation actuelle, avec la capacité maximale disponible actuelle par puce, il s'avère qu'il est plus efficace d'utiliser des ports de 100 gigabits, car ils vous permettent pour obtenir une base plus grande.
La question suivante est de savoir comment la physique est organisée, mais du point de vue de l'infrastructure des câbles. Il s’avère que c’est organisé de façon plutôt amusante. Câblage entre les commutateurs feuilles et les spines de premier niveau - il n'y a pas beaucoup de liens là-bas, tout est construit relativement simplement. Mais si nous prenons un plan, ce qui se passe à l’intérieur, c’est que nous devons connecter toutes les épines du premier niveau avec toutes les épines du deuxième niveau.
De plus, en règle générale, il existe certains souhaits quant à l'apparence à l'intérieur du centre de données. Par exemple, nous voulions vraiment regrouper les câbles en un faisceau et les tirer de manière à ce qu'un panneau de brassage haute densité soit entièrement intégré à un seul panneau de brassage, afin qu'il n'y ait pas de zoo en termes de longueurs. Nous avons réussi à résoudre ce problème. Si vous regardez d’abord la topologie logique, vous pouvez voir que les plans sont indépendants, chaque plan peut être construit seul. Mais lorsque nous ajoutons un tel regroupement et que nous voulons faire glisser l'ensemble du panneau de brassage dans un panneau de brassage, nous devons mélanger différents plans à l'intérieur d'un seul paquet et introduire une structure intermédiaire sous la forme de connexions croisées optiques pour les reconditionner à partir de la façon dont ils ont été assemblés. sur un segment, comment ils seront collectés sur un autre segment. Grâce à cela, nous obtenons une fonctionnalité intéressante : toutes les commutations complexes ne dépassent pas les racks. Lorsqu'il faut entrelacer quelque chose de très fort, « déplier les plans », comme on l'appelle parfois dans les réseaux Clos, tout est concentré dans un seul rack. Nous n'avons pas de liens très démontés, jusqu'aux liens individuels, pour passer d'un rack à l'autre.
Voilà à quoi cela ressemble du point de vue de l'organisation logique de l'infrastructure du câble. Dans l'image de gauche, les blocs multicolores représentent des blocs de commutateurs spine de premier niveau, huit pièces chacun, et quatre faisceaux de câbles provenant d'eux, qui vont se croiser avec les faisceaux provenant des blocs de commutateurs spine-2. .
Les petits carrés indiquent les intersections. En haut à gauche se trouve une ventilation de chacune de ces intersections. Il s'agit en fait d'un module de connexion croisée de 512 ports par 512 qui regroupe les câbles afin qu'ils arrivent complètement dans un rack, où il n'y a qu'un seul plan spine-2. Et à droite, un scan de cette image est un peu plus détaillé par rapport à plusieurs Pods au niveau spine-1, et comment il est emballé dans une connexion croisée, comment il arrive au niveau spine-2.
Voilà à quoi cela ressemble. Le support spine-2 pas encore entièrement assemblé (à gauche) et le support de connexion croisée. Malheureusement, il n'y a pas grand chose à voir là-bas. L’ensemble de cette structure est actuellement déployé dans l’un de nos grands centres de données en cours d’agrandissement. C'est un travail en cours, ce sera plus joli, ce sera mieux rempli.
Une question importante : nous avons choisi la topologie logique et construit la physique. Qu’arrivera-t-il au plan de contrôle ? Il est bien connu par l'expérience d'exploitation, il existe un certain nombre de rapports selon lesquels les protocoles d'état des liens sont bons, c'est un plaisir de travailler avec eux, mais, malheureusement, ils ne s'adaptent pas bien à une topologie densément connectée. Et il existe un facteur principal qui empêche cela : c'est la manière dont fonctionne l'inondation dans les protocoles à état de liens. Si vous prenez simplement l'algorithme d'inondation et regardez comment notre réseau est structuré, vous pouvez voir qu'il y aura une très grande diffusion à chaque étape, et cela inondera simplement le plan de contrôle de mises à jour. Plus précisément, ces topologies se mélangent très mal avec l’algorithme d’inondation traditionnel dans les protocoles à état de liens.
Le choix est d'utiliser BGP. Comment le préparer correctement est décrit dans la RFC 7938 sur l'utilisation de BGP dans les grands centres de données. Les idées de base sont simples : nombre minimum de préfixes par hôte et généralement nombre minimum de préfixes sur le réseau, utiliser l'agrégation si possible et supprimer la recherche de chemin. Nous souhaitons une distribution des mises à jour très soignée, très contrôlée, ce qu’on appelle « Valley Free ». Nous souhaitons que les mises à jour soient déployées exactement une fois lors de leur passage sur le réseau. S'ils naissent du bas, ils montent et ne se déploient qu'une seule fois. Il ne devrait y avoir aucun zigzag. Les zigzags sont très mauvais.
Pour ce faire, nous utilisons une conception suffisamment simple pour utiliser les mécanismes BGP sous-jacents. Autrement dit, nous utilisons eBGP fonctionnant sur un lien local et les systèmes autonomes sont attribués comme suit : un système autonome sur ToR, un système autonome sur l'ensemble du bloc de commutateurs spine-1 d'un pod et un système autonome général sur l'ensemble du Top. de tissu. Il n’est pas difficile de constater que même le comportement normal de BGP nous donne la distribution des mises à jour que nous souhaitons.
Naturellement, l’adressage et l’agrégation d’adresses doivent être conçus de manière à être compatibles avec la manière dont le routage est construit, afin de garantir la stabilité du plan de contrôle. L'adressage L3 dans le transport est lié à la topologie, car sans cela, il est impossible de réaliser une agrégation ; sans cela, des adresses individuelles s'infiltreront dans le système de routage. Et encore une chose, l'agrégation, malheureusement, ne se mélange pas très bien avec le multi-chemin, car quand nous avons le multi-chemin et que nous avons l'agrégation, tout va bien, lorsque l'ensemble du réseau est sain, il n'y a aucune panne. Malheureusement, dès que des pannes apparaissent dans le réseau et que la symétrie de la topologie est perdue, nous pouvons arriver au point à partir duquel l'unité a été annoncée, à partir duquel nous ne pouvons pas aller plus loin là où nous devons aller. Par conséquent, il est préférable d'agréger là où il n'y a plus de chemins multiples, dans notre cas, il s'agit de commutateurs ToR.
En fait, il est possible de regrouper, mais avec précaution. Si nous pouvons procéder à une désagrégation contrôlée en cas de pannes de réseau. Mais c'est une tâche assez difficile, nous nous sommes même demandé si cela serait possible, s'il était possible d'ajouter une automatisation supplémentaire et des machines à états finis qui lanceraient correctement BGP pour obtenir le comportement souhaité. Malheureusement, le traitement des cas extrêmes est très complexe et peu évident, et cette tâche n'est pas bien résolue en attachant des pièces jointes externes à BGP.
Des travaux très intéressants à cet égard ont été réalisés dans le cadre du protocole RIFT, qui sera discuté dans le prochain rapport.
Une autre chose importante est la façon dont les plans de données évoluent dans des topologies denses, où nous disposons d'un grand nombre de chemins alternatifs. Dans ce cas, plusieurs structures de données supplémentaires sont utilisées : les groupes ECMP, qui décrivent à leur tour les groupes Next Hop.
Dans un réseau fonctionnant normalement, sans pannes, quand on remonte la topologie Clos, il suffit de n'utiliser qu'un seul groupe, car tout ce qui n'est pas local est décrit par défaut, on peut remonter. Quand on va de haut en bas vers le sud, alors tous les chemins ne sont pas des ECMP, ce sont des chemins à chemin unique. Tout va bien. Le problème est que, et la particularité de la topologie Clos classique est que si l'on regarde le haut du tissu, à n'importe quel élément, il n'y a qu'un seul chemin vers n'importe quel élément en dessous. Si des échecs se produisent le long de ce chemin, alors cet élément particulier au sommet de l'usine devient invalide précisément pour les préfixes qui se trouvent derrière le chemin interrompu. Mais pour le reste c'est valable, et il faut analyser les groupes ECMP et introduire un nouvel état.
À quoi ressemble l’évolutivité du plan de données sur les appareils modernes ? Si nous faisons LPM (correspondance de préfixe la plus longue), tout va plutôt bien, plus de 100 2 préfixes. Si nous parlons de groupes Next Hop, alors tout est pire, 4 à 16 64. Si nous parlons d'un tableau contenant une description des prochains sauts (ou des contiguïtés), alors cela se situe entre XNUMX XNUMX et XNUMX XNUMX. Et cela peut devenir un problème. Et nous arrivons ici à une digression intéressante : qu’est-il arrivé au MPLS dans les centres de données ? En principe, nous voulions le faire.
Deux choses se sont produites. Nous avons fait de la micro-segmentation sur les hôtes, nous n'avions plus besoin de le faire sur le réseau. Ce n'était pas très bon avec le support de différents fournisseurs, et encore plus avec des implémentations ouvertes sur des boîtes blanches avec MPLS. Et MPLS, du moins ses implémentations traditionnelles, se combine malheureusement très mal avec ECMP. Et c'est pourquoi.
Voici à quoi ressemble la structure de transfert ECMP pour IP. Un grand nombre de préfixes peuvent utiliser le même groupe et le même bloc Next Hops (ou contiguïtés, cela peut être appelé différemment dans différentes documentations pour différents appareils). Le fait est qu'il s'agit du port sortant et de ce sur quoi réécrire l'adresse MAC afin d'accéder au prochain saut correct. Pour IP tout semble simple, vous pouvez utiliser un très grand nombre de préfixes pour un même groupe, un même bloc Next Hops.
L'architecture MPLS classique implique que, en fonction de l'interface sortante, l'étiquette peut être réécrite avec des valeurs différentes. Par conséquent, nous devons conserver un groupe et un bloc Next Hops pour chaque étiquette d’entrée. Et cela, hélas, n’est pas à l’échelle.
Il est facile de voir que dans notre conception, nous avions besoin d'environ 4000 64 commutateurs ToR, la largeur maximale était de 1 chemins ECMP, si nous nous éloignons de la colonne vertébrale-2 vers la colonne vertébrale-XNUMX. Nous entrons à peine dans une table de groupes ECMP, si un seul préfixe avec ToR disparaît, et nous n'entrons pas du tout dans la table Next Hops.
Tout n’est pas désespéré, car les architectures comme le routage de segments impliquent des étiquettes globales. Formellement, il serait possible de réduire à nouveau tous ces blocs Next Hops. Pour ce faire, vous avez besoin d'une opération de type joker : prenez une étiquette et réécrivez-la dans la même sans valeur spécifique. Mais malheureusement, cela n’est pas très présent dans les implémentations disponibles.
Et enfin, nous devons amener le trafic externe vers le centre de données. Comment faire? Auparavant, le trafic était introduit dans le réseau du Clos par le haut. Autrement dit, il y avait des routeurs de périphérie connectés à tous les appareils situés en haut de la structure. Cette solution fonctionne plutôt bien sur les petites et moyennes tailles. Malheureusement, pour envoyer ainsi du trafic de manière symétrique sur l'ensemble du réseau, il faut arriver simultanément à tous les éléments du Top of fabric, et lorsqu'il y en a plus d'une centaine, il s'avère qu'il faut aussi un grand radix sur les routeurs de périphérie. En général, cela coûte de l'argent, car les routeurs de périphérie sont plus fonctionnels, leurs ports seront plus chers et leur design n'est pas très beau.
Une autre option consiste à démarrer ce trafic par le bas. Il est facile de vérifier que la topologie Clos est construite de telle manière que le trafic venant du bas, c'est-à-dire du côté ToR, soit réparti uniformément entre les niveaux dans tout le haut de la structure en deux itérations, chargeant ainsi l'ensemble du réseau. Par conséquent, nous introduisons un type spécial de Pod, Edge Pod, qui fournit une connectivité externe.
Il existe une autre option. C'est ce que fait Facebook, par exemple. Ils l'appellent Fabric Aggregator ou HGRID. Un niveau de colonne vertébrale supplémentaire est introduit pour connecter plusieurs centres de données. Cette conception est possible si nous n'avons pas de fonctions supplémentaires ou de changements d'encapsulation au niveau des interfaces. S'il s'agit de points de contact supplémentaires, c'est difficile. En règle générale, il existe davantage de fonctions et une sorte de membrane séparant les différentes parties du centre de données. Il ne sert à rien d'agrandir une telle membrane, mais si elle est vraiment nécessaire pour une raison quelconque, il est alors logique d'envisager la possibilité de la retirer, de la rendre aussi large que possible et de la transférer aux hôtes. C'est ce que font, par exemple, de nombreux opérateurs de cloud. Ils ont des superpositions, ils partent des hôtes.
Quelles opportunités de développement voyons-nous ? Tout d’abord, améliorer la prise en charge du pipeline CI/CD. Nous voulons voler comme nous testons et testons la façon dont nous volons. Cela ne fonctionne pas très bien, car l’infrastructure est vaste et il est impossible de la dupliquer pour des tests. Vous devez comprendre comment introduire des éléments de test dans l'infrastructure de production sans la laisser tomber.
Une meilleure instrumentation et une meilleure surveillance ne sont presque jamais superflues. Toute la question est un équilibre entre effort et retour. Si vous pouvez l’ajouter avec un effort raisonnable, très bien.
Systèmes d'exploitation ouverts pour les périphériques réseau. De meilleurs protocoles et de meilleurs systèmes de routage, tels que RIFT. Des recherches sont également nécessaires sur l'utilisation de meilleurs systèmes de contrôle de la congestion et peut-être sur l'introduction, au moins à certains moments, du support RDMA au sein du cluster.
À plus long terme, nous aurons besoin de topologies avancées et éventuellement de réseaux utilisant moins de temps système. Parmi les nouveautés, il y a eu récemment des publications sur la technologie de structure pour HPC Cray Slingshot, qui est basée sur Ethernet standard, mais avec la possibilité d'utiliser des en-têtes beaucoup plus courts. En conséquence, les frais généraux sont réduits.
Tout doit rester aussi simple que possible, mais pas plus simple. La complexité est l'ennemi de l'évolutivité. La simplicité et les structures régulières sont nos amies. Si vous pouvez effectuer une mise à l'échelle quelque part, faites-le. Et en général, c’est formidable d’être impliqué dans les technologies de réseau maintenant. Il se passe beaucoup de choses intéressantes. Merci.
Source: habr.com