Tous les deux ans, Google publie un document qui incite tout le monde dans l’industrie informatique à s’arrêter et à réfléchir.
Le Système de fichiers Google en 2003. Le MapRéduire plate-forme d’analyse en 2004. Le BigTable Base de données NoSQL en 2006. Informatique à l’échelle de l’entrepôt en tant que concept en 2009. Le Clé base de données distribuée en 2012. Le Borg contrôleur de cluster en 2015 et à nouveau avec le Planificateur Omega add-on en 2016. Le Jupiter commutateurs de centre de données personnalisés en 2015. Le Expresso pile logicielle de routage Edge en 2017. Le Andromède pile réseau virtuelle en 2018. Google n’a jamais fait d’article sur son système de fichiers Colossus ou GFS2, le successeur de GFS et le fondement de Spanner, mais il l’a mentionné dans l’article Spanner ci-dessus et il a donné une présentation vidéo pendant la pandémie de coronavirus l’année dernière à propos de Colossus pour aider à différencier Google Cloud de ses pairs.
Deux apartés : Regardez où sont les problèmes. Google s’éloigne du traitement des données et des logiciels système qui le sous-tendent et passe par la planification au réseau, à la fois dans le centre de données et à la périphérie, alors qu’il dévoile son travail manuel et ses prouesses techniques au monde.
L’autre chose intéressante à propos de Google maintenant est qu’il n’est pas révélateur ce qu’il a fait il y a des années, comme dans tous ces articles précédents, mais ce qu’il fait Maintenant pour préparer l’avenir. La concurrence pour les talents à l’échelon supérieur de l’informatique est si intense que Google doit le faire pour attirer des cerveaux qui pourraient autrement aller dans une start-up ou l’un de ses nombreux rivaux.
Quoi qu’il en soit, cela fait un moment que le géant des moteurs de recherche et de la publicité n’a pas lâché un gros papier sur nous tous, mais Google l’a refait avec un article décrivant Aigle, une structure de centre de données à faible latence qu’elle a construite avec une logique de commutation et d’interface personnalisée et un protocole personnalisé appelé GNet qui fournit une faible latence et des latences de queue plus prévisibles et nettement inférieures à celles des réseaux Clos basés sur Ethernet et à l’échelle du centre de données que la société déploie depuis longtemps maintenant.
Avec Aquila, Google semble avoir fait ce qu’Intel aurait pu essayer de faire avec Omni-Path, si vous plissez les yeux un peu en lisant l’article, qui a été publié lors de la récente conférence Network Systems Design and Implementation (NSDI) organisée par l’Association USENIX. Et plus précisément, il emprunte certains thèmes à l’interconnexion propriétaire « Bélier » créée par le fabricant de superordinateurs Cray et annoncé dans les machines CX30 « Cascade » en novembre 2013.
Vous vous souviendrez, bien sûr, que Intel a acheté l’interconnexion Bélier à Cray en avril 2012, et avait l’intention de fusionner certaines de ses technologies avec sa variante Omni-Path InfiniBand, qu’il a obtenue lorsqu’elle a acquis cette entreprise de QLogic en janvier 2012. Le Bélier avait un routage adaptatif et un minimum de contrôle de la congestion (qui était parfois flummoxed) ainsi qu’une topologie tout-à-tout de libellule qui est distincte des topologies des réseaux Clos utilisées par les hyperscalers et les constructeurs de nuages et les réseaux Hyper-X parfois utilisés par les centres HPC au lieu des topologies de libellules ou de gros arbres. Il est plus difficile d’ajouter de la capacité aux réseaux de libellules sans avoir à recâbler l’ensemble du cluster, mais si vous créez des machines, alors tout va bien. Le réseau clos all-to-all permet d’ajouter des machines assez facilement, mais le nombre de sauts entre les machines et donc la latence n’est pas aussi cohérent qu’avec un réseau de libellules.
Steve Scott, l’ancien directeur de la technologie chez Cray qui a dirigé la conception de ses interconnexions « SeaStar » et « Gemini » et du Bélier susmentionné, qui étaient au cœur des machines Cray XT3, XT4 et XC, a rejoint Google en 2013 et y est resté jusqu’en 2014 avant de rejoindre Cray pour diriger sa résurgence de supercalcul avec l’interconnexion Slingshot « Rosetta ». Scott nous a dit que le fait de faire partie du groupe de plate-forme de Google lui a vraiment fait apprécier les points les plus fins de latence de queue dans les réseaux, mais il semble que Scott leur ait fait comprendre l’importance des protocoles propriétaires réglés pour un travail spécifique, des commutateurs à rayons élevés sur une bande passante de pointe absolue, la nécessité d’un contrôle de la congestion et d’un routage adaptatif moins fragile que les choses utilisées par les géants de l’Internet. et la topologie de libellule. (Scott a rejoint Microsoft Azure en tant que Technical Fellow en juin 2020, et il est raisonnable de s’attendre à ce que le géant du cloud soit prêt à quelque chose concernant les réseaux avec l’aide de Scott.)
En bref, Intel, qui a dépensé 265 millions de dollars pour acheter ces actifs réseau à QLogic et Cray et Dieu seul sait combien plus de développement et de marketing Omni-Path avant de le vendre à Cornelis Networks, souhaite probablement maintenant avoir inventé quelque chose comme Aquila.
Il y a beaucoup de couches dans cette structure de centre de données Aquila, qui est en phase de prototype en ce moment, et il n’est pas du tout clair comment cela s’interfacera et s’entrelacera avec le DPU « Mount Evans » qu’Intel a conçu en collaboration avec Google et que l’hyperscaler est probablement déjà déployé dans son parc de serveurs. Il pourrait s’avérer que le commutateur convergent / dispositif réseau qui est au cœur du tissu Aquila et le DPU Mount Evans ont une destination commune sur leurs feuilles de route respectives, ou ils conduisent sur des routes parallèles jusqu’à ce que l’on ait un pneu crevé.
Aquila, qui est le mot latin pour aigle, et il ne s’exécute explicitement pas au-dessus – ou en dépit de – les protocoles Ethernet, IP ou TCP et UDP qui sous-tendent Internet. (Pour une bonne image des différences entre ces protocoles imbriqués, voici une excellente explication: « Imaginez l’un de ces systèmes de messages à tubes pneumatiques. Ethernet est le tube utilisé pour envoyer le message, IP est une enveloppe dans le tube et TCP/UDP est une lettre dans l’enveloppe.«
Oubliez tout cela. Google a tout jeté et a créé ce qu’il appelle un protocole de commutation de couche 2 basé sur des cellules et un format de données connexe qui n’est pas des paquets. En fait, une cellule est plus petite qu’un paquet, et c’est l’une des raisons pour lesquelles Google peut obtenir de meilleures performances déterministes et une latence plus faible pour les liaisons entre les nœuds de serveur via la structure Aquila. Le format de cellule est optimisé pour les petites unités de données couramment utilisées dans les réseaux RDMA, et avec la fonctionnalité de réseau convergé d’un ASIC de commutateur haut de rack et d’une carte d’interface réseau, à l’échelle de 1 152 nœuds du prototype d’interconnexion Aquila, il peut effectuer une lecture RMA en moyenne de 4 microsecondes.
Cette bête de commutation / carte réseau convergée, le format de données cellulaires, le protocole GNet pour le traiter très efficacement avec sa propre variante de RDMA appelée 1RMA, la structure réseau définie par logiciel hors bande et la topologie dragonfly créent une interconnexion personnalisée à haute vitesse qui ressemblerait passagèrement à ce qui se passerait si le Bélier et InfiniBand avaient un enfant dans un centre de données hyperscale et que cet enfant pouvait parler et entendre Ethernet à ses bords si nécessaire.
Commençons par le matériel Aquila, puis remontons la pile. Tout d’abord, Google ne voulait pas dépenser beaucoup d’argent pour cela.
« Pour soutenir l’effort de développement matériel avec une équipe de taille modeste, nous avons choisi de construire une seule puce avec à la fois des fonctionnalités de carte réseau et de commutateur dans le même silicium », expliquent les 25 chercheurs de Google qui ont travaillé sur Aquila dans le document. « Notre idée fondamentale et notre point de départ étaient qu’un commutateur à rayon moyen pouvait être incorporé dans le silicium NIC existant à un coût supplémentaire modeste et qu’un certain nombre de ces combinaisons NIC/switch résultantes appelées puces ToR-in-NIC (TiN) pouvaient être câblées ensemble via un fond de panier en cuivre dans un pod, un boîtier de la taille d’un commutateur Top of Rack (ToR) traditionnel. Les serveurs peuvent ensuite se connecter au pod via PCIe pour leur fonctionnalité de carte réseau. Le commutateur TiN fournirait une connectivité à d’autres serveurs de la même Clique via un protocole de couche 2 optimisé, GNet, et à d’autres serveurs d’autres cliques via Ethernet standard.
Il y a beaucoup de choses sur cette puce « torrinique ». Amin Vahdat, qui est le chercheur en ingénierie et vice-président qui dirige l’équipe d’infrastructure des systèmes et des services chez Google et qui a dirigé l’équipe d’infrastructure réseau pendant longtemps avant cela, nous a dit à la même époque l’année dernière que le SoC est la nouvelle carte mère et le centre de l’innovation, et il n’est pas surprenant pour nous que chaque puce Aquila soit en fait un complexe avec deux de ces TiN dans le même paquet (mais pas nécessairement sur la même biche, remarquez). Vahdat est l’un des auteurs de l’article d’Aquila et a sans aucun doute dirigé l’effort de développement.
Comme vous pouvez le voir, il y a une paire d’emplacements PCI-Express 3.0 x16 qui sortent de l’appareil, ce qui permet un gros tuyau de 256 Gb / sec dans un seul serveur ou deux tuyaux demi-gras de 128 Gb / sec pour deux serveurs. De l’autre côté de ce commutateur PCI-Express se trouve une paire de circuits d’interface réseau – un qui parle 100 Gb / sec IP et peut passer à travers la puce pour parler Ethernet et un autre qui parle le protocole propriétaire 1RMA et qui se connecte au commutateur de cellule GNet.
Ce commutateur cellulaire a 32 ports fonctionnant à 28 Gb / sec – pas beaucoup de ports que les commutateurs vont et pas aussi vite que les ports vont, comme Google l’a souligné ci-dessus. Avec la surcharge d’encodage enlevée, ces voies de commutation de cellules GNet fonctionnent à 25 Gb / sec, ce qui est la même vitesse que les ports OpenCAPI « Bluelink » d’IBM sur le processeur Power9 et que les voies dans les tuyaux NVLink 3.0 dans le GPU A100 « Ampere » et les commutateurs NVSwitch associés. Il y a 24 de ces voies de 25 Gb/s qui sont utilisées pour relier tous les nœuds de serveur dans le pod sur des liaisons en cuivre, et il y a huit liaisons qui peuvent être utilisées pour interconnecter jusqu’à 48 pods dans un seul tissu GNet, appelé une « clique », en utilisant des liens optiques. La topologie Dragonfly utilisée chez Cray et maintenant chez Google est conçue explicitement pour limiter le nombre d’émetteurs-récepteurs optiques et de câbles nécessaires pour relier à longue distance des pods de serveurs. Google a apparemment également conçu son propre émetteur-récepteur optique GNet pour ces ports.
L’Aquila TiN dispose de moteurs de traitement des paquets d’entrée et de sortie qui peuvent s’interfacer avec la carte réseau IP et le MAC Ethernet si les données du commutateur cellulaire doivent quitter la structure Aquila et atteindre les réseaux Ethernet de Google.
Google affirme que la conception à puce unique du tissu Aquila visait à réduire les coûts de développement des puces et à « rationaliser la gestion des stocks ». Quiconque attendait un commutateur ou une livraison de carte réseau pendant la pandémie de coronavirus sait exactement de quoi Google parle. La pénurie de cartes réseau ralentit certainement les ventes de serveurs. C’était si mauvais il y a quelques mois que certains magasins HPC dont nous avons entendu parler par l’intermédiaire de revendeurs se tournaient vers l’équipement Omni-Path 100 Gb / sec d’Intel parce qu’il était au moins en stock.
Le point principal de cette architecture de réseau convergé est que Google imbrique un réseau de libellules très rapide à l’intérieur de son réseau Clos à l’échelle du centre de données, qui est basé sur une topologie feuille / colonne vertébrale qui n’est pas un réseau tout-à-tout, mais qui permet à tout d’être interconnecté de manière rentable et évolutive.
Google dit que les liens optiques permettent aux pods Aquila d’être jusqu’à 100 mètres l’un de l’autre et d’imposer une nanoseconde de 30 – a déclaré Google nanoseconde – latence par saut entre les pods interconnectés, c’est-à-dire avec correction d’erreur directe réduisant le bruit et créant une certaine latence.
De nos jours, la plupart des commutateurs ont un calcul intégré, et Google dit que la plupart des commutateurs ont un processeur multicœur 64 bits avec entre 8 Go et 16 Go de mémoire principale. Mais en ayant un contrôleur SDN externe et en utilisant le calcul local sur le package de puce Aquila comme processeur local de point de terminaison pour chaque paire TiN, le package Aquila peut se débrouiller avec un processeur Cortex-M7 monocœur 32 bits avec 2 Mo de SRAM dédiée pour gérer les besoins de traitement local de la pile SDN. Les serveurs externes exécutant la pile GNet n’ont pas été divulgués, mais il s’agit d’une conception courante pour Google.
Le logiciel SDN est écrit en C et C++ et est composé d’environ 100 000 lignes de code ; la puce Aquila exécute le système d’exploitation en temps réel FreeRTOS et la bibliothèque lwIP. Le logiciel expose toutes les API de bas niveau jusqu’au contrôleur SDN, qui peut atteindre et manipuler directement les registres et autres éléments de l’appareil. Google ajoute que la distribution du firmware pour Aquila – et la plupart d’entre eux sur le contrôleur, et non sur l’appareil – était absolument intentionnelle, et que l’idée est que le périphérique TiN peut afficher les liens GNet et Ethernet et tenter de se connecter au serveur DHCP sur le réseau et attendre d’autres ordres de configuration du contrôleur SDN Aquila central.
Un élément intéressant à propos du réseau Aquila est que, comme il s’agit d’une topologie de libellule, vous devez configurer tous les nœuds du réseau dès le départ ou vous devez pouvoir être récusable chaque fois que vous ajoutez des machines pour obtenir toute la bande passante du réseau. (C’est l’inconvénient des réseaux tout-à-tout.) Google fait donc cela, puis ajoute des serveurs au fur et à mesure que vous en avez besoin. Voici à quoi ressemble le schéma des serveurs et du réseau :
La configuration d’Aquila comporte deux pods de 24 serveurs dans un rack et 24 racks dans une clique. Google utilise ses boîtiers de serveur standard, qui ont des cartes réseau sur les cartes d’adaptateur, dans ce cas une carte d’adaptateur PCI qui se connecte à un châssis de commutateur qui a une douzaine d’ASIC T1N sur six cartes d’adaptateur. Le premier niveau du réseau dragonfly est implémenté sur le fond de panier du châssis, et il y a 96 liaisons GNet optiques qui sortent du pod pour connecter les 48 pods ensemble, tout à tout, avec deux routes chacun.
Un effet secondaire d’avoir de nombreux ASIC implémentant le réseau est que le rayon de souffle pour un ASIC donné est assez petit. Si deux serveurs partagent un T1N et que le package T1N possède deux ASIC, l’échec d’un package n’entraîne que quatre serveurs. Si un commutateur haut de rack dans un rack de 48 serveurs brûle, puis 48 serveurs sont en panne. Si tout un châssis de commutateur Aquila tombe en panne, ce ne sont encore que 24 machines qui sont assommées.
À l’avenir, Google étudie l’ajout de plus de calcul au périphérique TiN dans les futurs appareils Aquila, de l’ordre d’un Raspberry Pi à chaque carte réseau, afin qu’il puisse exécuter Linux. Cela permettrait à Google d’ajouter une couche d’abstraction de langage de programmation P4 de niveau supérieur au réseau, ce qu’il veut absolument faire.
Lors des premiers tests, le tissu Aquila était capable d’avoir des latences de queue inférieures à 40 microsecondes pour un temps aller-retour de tissu (RTT dans le jargon du réseau), et avait un accès à la mémoire à distance de moins de 10 microsecondes sur 500 machines hôtes sur un magasin clé-valeur appelé CliqueMap. Cette latence de queue est 5 fois plus petite par rapport à un réseau IP existant, même sous une charge élevée.
Une dernière réflexion. L’échelle du réseau Aquila n’est pas si grande, et pour faire évoluer le calcul plus, il faudra augmenter les ASIC T1N avec plus de ports et peut-être – mais pas nécessairement – avec des taux de signalisation plus élevés pour augmenter la bande passante pour correspondre aux vitesses PCI-Express 5.0. (C’était un prototype, après tout.) Nous pensons que Google choisira un rayon plus élevé plutôt qu’une bande passante plus élevée, ou du moins divisera la différence.
Il y a cependant un autre facteur de performance à considérer. Lorsque Google parlait de Borg il y a sept ans, il y avait 10 000 à 50 000 serveurs dans un pod, ce qui est beaucoup. Mais les serveurs que Google utilisait avaient peut-être une poignée à une douzaine de cœurs par socket et probablement deux sockets par machine. Visez haut et appelez-le une moyenne de 20 cœurs. Mais aujourd’hui, nous avons des dizaines de cœurs par socket de serveur et nous sommes sur le point de plusieurs centaines de cœurs par socket, il ne faudra donc peut-être que quelques milliers de nœuds pour exécuter tous les travaux sauf les plus importants chez Google. Et même les gros travaux peuvent être découpés sur des pods Aquila, puis agrégés sur des liaisons Ethernet régulières. Il y a un facteur d’amélioration de 10 fois dans le nombre de cœurs ainsi qu’une augmentation d’environ 2 fois du facteur des instructions par horloge (IPC) pour le travail sur des entiers au cours de cette période; les performances en virgule flottante ont encore augmenté. Appelez-le un facteur 20X d’amélioration des performances par nœud. Pour autant que nous sachions, les tailles de pod chez Google n’ont pas besoin d’être étirées aussi loin.
Plus important encore, les clusters (O)1000, comme les documents techniques abrégent les clusters de l’ordre de milliers de nœuds, sont assez grands pour effectuer des charges de travail HPC et AI importantes, même s’ils ne peuvent pas exécuter les modèles les plus volumineux. Il sera intéressant de voir quels emplois s’intègrent dans un tissu Aquila et lesquels ne le font pas, et il est intéressant de noter que cette technologie pourrait être parfaite pour l’échelle de nombreuses startups, entreprises, entreprises universitaires et gouvernementales. Donc, même si Aquila n’évolue pas loin maintenant, il pourrait être la base d’un service HPC et AI très performant sur le cloud Google où (O) 1000 est juste ce qu’il faut.
