Pourquoi n'y a-t-il pas de logiciel

Pendant des décennies, nous avons utilisé des logiciels pour découper des serveurs avec des hyperviseurs de virtualisation afin d'exécuter de nombreuses petites charges de travail sur un morceau de fer relativement gros.

Ce fut une aubaine pour les serveurs X86 pendant la Grande Récession, lorsque la technologie de virtualisation des serveurs était suffisamment mature pour être mise en production (bien qu'elle ne soit pas encore parfaite), permettant la consolidation des serveurs et une utilisation plus élevée des serveurs et même aidant certaines entreprises à sauter une ou deux générations de mises à niveau du serveur à un moment où ils ne pouvaient pas vraiment dépenser de l'argent pour un nouveau fer.

Alors, comment se fait-il que nous n'utilisions pas également des logiciels pour coupler étroitement de nombreux serveurs bon marché afin de créer des blocs de mémoire partagée et de calcul associé pour exécuter des charges de travail plus importantes qu'une seule machine ? Il est beaucoup plus facile de programmer pour un espace mémoire partagé que pour un système informatique distribué faiblement couplé, donc cela nous laisse un peu perplexe. N'aimeriez-vous pas avoir une machine avec une poignée de sockets et des milliers de threads et avoir un logiciel de bas niveau pour gérer l'allocation des ressources ? Pourquoi faire évoluer vos applications et vos bases de données alors que vous pourriez être paresseux et évoluer ?

La technologie permettant de créer des systèmes NUMA à la volée existe depuis de nombreuses années - vous vous souvenez de Virtual Iron, RNA Networks et ScaleMP ? – et a peut-être culminé avec TidalScale, qui a repris l'idée avec ses propres rebondissements sur essentiellement la même histoire et qui a été fondée en mars 2012 par Ike Nassi, Kleoni Ioannidou et Michael Berman.

Soit dit en passant, ces trois autres éditeurs de logiciels qui ont créé des serveurs virtuels NUMA à partir de machines X86 de base ont tous disparu.

Virtual Iron, fondé en 2001, a disparu dans la gueule béante d'Oracle en mai 2009. RNA Networks, fondé en 2006, a été mangé par Dell en juin 2011, et ce fabricant de serveurs a un peu déconné et puis nous n'en avons jamais entendu parler encore. Et ScaleMP, fondée en 2003, était encore assez forte dans le secteur HPC avec son hyperviseur éponyme NUMA lorsque The Next Platform a été fondée en 2015, ScaleMP a été discrètement rachetée par SAP en juin 2021. (Il n'y a pas eu d'annonce à ce sujet pour autant que nous sommes conscients. )

Nassi est le poids lourd de TidalScale et est toujours président et directeur de la technologie.

Après avoir obtenu un baccalauréat, une maîtrise et un doctorat en informatique de l'Université de Stony Brook à New York, Nassi était ingénieur chez Digital Equipment, un innovateur de mini-ordinateurs, et dans les années 1980, il était vice-président chez Encore Computer, un innovateur de systèmes de calcul intensif NUMA, avant de rejoindre Apple pour aider développer son système d'exploitation MacOS et ses langages. (Nassi est l'un des créateurs du langage de programmation Ada et a aidé à créer le langage de programmation Dylan pour l'ordinateur de poche Apple Newton.) Il a fondé le pionnier du réseau maillé Firetide en 2001, puis est devenu scientifique en chef à la branche SAP Research du Géant du logiciel ERP, au service de 2005 à 2011.

Nassi est également professeur auxiliaire de longue date d'informatique à l'Université de Californie à Santa Cruz.

TidalScale a levé 43 millions de dollars en deux tours de financement en capital-risque et, en 2016, a nommé Gary Smerdon au poste de directeur général. Smerdon est un dirigeant de longue date des semi-conducteurs d'AMD qui a ensuite travaillé chez Marvell, Greenfield Networks (acquis par Cisco Systems), Tarari (acquis par LSI Logic où il a occupé divers postes de direction pendant six ans), Fusion-io et Pavalion Data Systems .

Nous avons parlé avec Smerdon lorsque TidalScale 3.0 a été lancé, à l'époque où nous faisions Next Platform TV au plus fort de la pandémie de coronavirus. Et à notre grand regret, nous n'avons pas donné à l'entreprise la couverture appropriée de sa version TidalScale 4.0 l'année dernière. Mais nous le faisons lors de la sortie de TidalScale 4.1, qui vient de sortir.

La société a lancé son premier HyperKernel et sa pile de gestion de système associée pour les serveurs virtuels NUMA en 2016 et a suivi avec une version 2.0 en 2017, mais c'est avec le produit TidalScale 3.0 en septembre 2019 qui a amélioré l'évolutivité des machines NUMA qui pourraient être composées avec HyperKernel, avec un maximum de 64 To de mémoire sur un serveur NUMA défini par logiciel, un maximum de 12 To dans n'importe quel nœud du cluster NUMA, jusqu'au point où 128 To sont adressables. Il s'agit d'une limite dans l'architecture de serveur Xeon SP d'Intel, qui est pour le moment le seul processeur pris en charge par TidalScale.

Rien, en théorie, n'empêche TidalScale de prendre en charge les architectures CPU de serveur AMD Epyc, IBM Power ou Arm avec son HyperKernel. Mais en pratique, une startup doit se concentrer et malgré toute la concurrence à laquelle Intel est confrontée, l'architecture Xeon SP reste celle qui domine dans le datacenter.

Dans un cluster TidalScale NUMA, les nœuds de serveur ne doivent pas nécessairement avoir la même configuration en termes de calcul ou de mémoire. Avec TidalScale 3.0, un maximum de 128 sockets était autorisé sur le cluster NUMA. Évidemment, avec ces maximums, vous pouvez créer des clusters NUMA avec une grande variété de nœuds de serveur de manière asymétrique ou vous pouvez les construire comme les vendeurs de clusters matériels NUMA comme HPE, IBM et d'autres le font avec chaque nœud du cluster étant le même.

Avec la version TidalScale 4.0, toutes ces capacités ont été doublées. Vous pouvez donc disposer d'un maximum de 24 To pour un nœud donné, jusqu'à 256 sockets et jusqu'à 128 To de mémoire totale sur un cluster NUMA défini par logiciel.

D'une certaine manière, TidalScale pousse un peu à contre-courant du matériel. Et de plusieurs autres façons de voir les choses, il n'y a jamais eu de meilleur moment pour un "ubervisor" ou un "hyperkernel" ou tout ce que vous voulez appeler le type d'hyperviseur que Virtual Iron, RNA Networks, ScaleMP et TidalScale ont tous créé individuellement.

De plus, certaines des innovations à l'intérieur de l'HyperKernel de TidalScale le rendent unique par rapport à ses prédécesseurs, et tant que quelqu'un n'achète pas l'entreprise et s'y assied, il y a une chance que cette technologie de clustering NUMA basée sur le logiciel devienne plus omniprésente - en particulier avec les réseaux PCI-Express, Ethernet et InfiniBand offrant une bande passante élevée et une faible latence.

Tout d'abord, parlons de la nature du calcul et du clustering NUMA dans le centre de données aujourd'hui et comment il atténue le besoin de NUMA dans de nombreux cas.

D'une part, les quelques concepteurs de processeurs restants sur le marché des centres de données ont mis en œuvre de meilleures conceptions matérielles NUMA au fil des décennies, et cela a vraiment impliqué l'ajout d'interconnexions cohérentes plus nombreuses et plus rapides, car des transistors plus petits permettaient d'entasser plus de choses sur la matrice. À ce stade, il n'y a pratiquement aucune surcharge dans un système NUMA à deux sockets, et les systèmes d'exploitation qui fonctionnent sur le fer X86 - Linux et Windows Server - ont depuis longtemps été réglés pour tirer parti de NUMA. Intel prend en charge les systèmes à quatre et huit sockets sans colle, c'est-à-dire sans chipset externe supplémentaire.

Avec ses prochains SP Xeon "Sapphire Rapids", nous prévoyons au moins 60 cœurs utilisables par socket et huit contrôleurs de mémoire DDR5 qui pourront prendre en charge peut-être 4 To par socket avec des bâtons de mémoire de 256 Go, éventuellement 8 To par socket avec 512 Go de mémoire des bâtons. Il s'agit d'un socket très dense par rapport aux précédentes générations de Xeon SP. Et Intel prendra en charge le NUMA à huit voies sans colle, ce qui devrait signifier prendre en charge jusqu'à 480 cœurs, 960 threads et 64 To sans colle. C'est un nœud assez gros selon les normes modernes.

Avec son serveur Power E1080 "Denali" basé sur Power10, IBM peut prendre en charge 240 cœurs qui font environ 2 fois le travail d'un cœur X86, avec 1 920 threads (IBM a un multithreading simultané à huit voies sur le Power10, comme il l'a fait avec Power8 et Power9 puces), sur 16 sockets et jusqu'à 64 To de mémoire physique sur ces sockets. IBM a jusqu'à 2 Po d'adressage virtuel sur l'architecture Power10, donc il peut faire plus de mémoire quand il en a envie, et pour autant que nous sachions, il n'en a pas envie et ne va pas faire de DIMM différentiels de 512 Go basé sur la mémoire DDR4 ; Les DDIMM de 256 Go sont le maximum pour le moment.

Ces serveurs NUMA basés sur le matériel ne sont pas bon marché, c'est pourquoi HPE et IBM les fabriquent toujours - souvent pour prendre en charge des bases de données sous des piles d'applications d'entreprise de back-office massives alimentées par des bases de données relationnelles. La base de données en mémoire SAP HANA génère de nombreuses ventes de fer NUMA ces jours-ci.

Mais les dépenses et la configuration rigide des clusters matériels NUMA sont ce qui présente une opportunité pour TidalScale alors même que chaque socket devient plus puissant et qu'une certaine quantité de NUMA est intégrée dans les puces. Il en va de même pour une invention au cœur de TidalScale HyperKernel appelée le CPU virtuel errant.

Dans les architectures matérielles NUMA fournissant un espace de mémoire partagé et découpées par un hyperviseur de virtualisation de serveur, les machines virtuelles sont configurées avec le calcul, la mémoire et les E/S et épinglées à ces ressources. Toutes les données en dehors de cette configuration de machine virtuelle doivent être paginées dans cette machine virtuelle, ce qui crée une latence.

Avec l'HyperKernel, Nassi et son équipe ont créé un nouveau type de processeur virtuel, qui n'est pas un programme exécuté sur un hyperviseur découpé, mais plutôt une abstraction de calcul de bas niveau qui a un ensemble de registres et de pointeurs qui lui sont assignés. Il s'agit d'une très petite abstraction - une page ou deux de mémoire qui tient à l'intérieur d'un paquet Ethernet. Il y a des millions de ces processeurs virtuels créés au fur et à mesure que les applications s'exécutent, et au lieu de déplacer des données vers de grosses machines virtuelles, ces processeurs virtuels voltigent autour des nœuds de serveur et à travers les nœuds liés aux réseaux dans le cluster NUMA défini par logiciel, se déplaçant là où le données, c'est qu'ils doivent effectuer l'opération suivante dans une application.

Cette architecture de vCPU itinérante est décrite en détail dans ce livre blanc, mais en voici l'essentiel : "Chaque vCPU d'un système TidalScale se déplace là où il peut accéder aux données dont il a besoin, où que ces données se trouvent physiquement. Plus le système TidalScale est grand, plus il y a de processeurs physiques et de RAM disponibles pour ses errances, et plus le vCPU errant devient efficace par rapport aux autres options de traitement de beaucoup de données."

Des gains d'efficacité sont obtenus, en partie, grâce à des algorithmes d'apprentissage automatique qui étudient les modèles de calcul et d'accès aux données sur les applications et les bases de données en cours d'exécution, et les vCPU peuvent être agrégés et distribués aux données, tout comme une unité de calcul vectoriel peut regrouper des données et les mâcher en parallèle.

Le résultat est que pour ceux qui ont besoin d'un espace mémoire partagé d'un grand serveur NUMA, pour exécuter un système de gestion de base de données volumineux ou des analyses en mémoire, par exemple, les clients peuvent en créer un à partir de serveurs Xeon SP normaux et d'une commutation Ethernet, et économiser de l'argent par rapport aux systèmes NUMA basés sur le matériel.

"Les clients nous ont dit que nous réduisions leur coût global d'environ 50 %", a déclaré Smerdon à The Next Platform. "Et par rapport à IBM Power Systems, je pense que les économies globales sont beaucoup plus élevées - probablement de l'ordre de 60 à 75% de réduction du coût global."

Nous pouvons penser à d'autres cas d'utilisation, comme ceux que ScaleMP poursuivait il y a dix ans. Dans de nombreux clusters HPC, il existe des centaines ou des milliers de nœuds X86 à deux sockets, puis des dizaines de nœuds X86 à mémoire grasse basés sur du fer NUMA plus lourd pour les parties de la charge de travail qui nécessitent plus de capacité de mémoire pour bien fonctionner.

Imaginez si ces gros nœuds pouvaient être configurés à la volée selon les besoins à partir de serveurs à deux sockets de base ? Mieux encore, vous pouvez créer un cluster de nœuds de mémoire très gros uniquement, ou un mélange de nœuds de mémoire maigres et gros, selon les besoins. À mesure que les charges de travail changent, la configuration du cluster NUMA peut changer.

Quelle est la partie la moins fiable d'un serveur ? C'est le processeur ? C'est un logiciel système ? C'est du réseau ? Non. C'est la mémoire principale. Et comme cette mémoire principale devient de plus en plus dense, il devient plus facile pour un rayon cosmique ou une particule alpha de retourner des bits et de causer toutes sortes de ravages.

La DRAM devient de moins en moins fiable, dit Smerdon, à mesure que la capacité d'une puce DRAM augmente, citant un chiffre de fiabilité 5,5 fois plus faible d'une étude AMD de 2017. Dans le même temps, la quantité de mémoire principale dans le serveur a diminué par un facteur de 10X, et bizarrement, parce qu'Intel a dû modifier les contrôleurs de mémoire pour prendre en charge la mémoire principale Optane 3D XPoint, l'une des choses qu'il a faites a été de reculer les bits de correction d'erreur afin qu'il puisse intégrer Optane dans l'architecture, ce qui a entraîné un taux plus élevé d'erreurs non corrigibles à l'exécution en mémoire pour les puces Xeon SP. Lorsque vous multipliez tout cela, dit Smerdon, la mémoire a un taux de défaillance dans un serveur Xeon SP qui est environ 100 fois plus élevé qu'il y a dix ans.

Et il y a toutes sortes d'histoires d'horreur à ce sujet, qui ne peuvent pas être facilement atténuées en disant que ces erreurs peuvent être couvertes par les mécanismes de tolérance aux pannes inhérents aux plates-formes informatiques distribuées modernes. Sans nommer de noms, Smerdon dit qu'un hyperscaler a dû remplacer 6 000 serveurs par plus de 40 Po de mémoire principale en raison des taux de défaillance élevés. (Il n'est donc pas étonnant que l'architecture AMD Epyc grignote des parts de marché parmi les hyperscalers et les constructeurs de cloud.)

La bonne nouvelle est que les erreurs corrigibles de la DRAM, les pannes d'alimentation et de ventilateur, ainsi que les pertes de connexion et de stockage du réseau et les pannes de périphérique ont toutes une forte probabilité de se produire et qu'elles fournissent toutes une sorte d'avertissement par le biais de la télémétrie du système qu'un crash est à venir. . Et sur un cluster NUMA virtuel avec de nombreux nœuds, lorsqu'un tel avertissement se produit, vous avez donc une chance de déplacer les charges de travail et les données de ce serveur vers une machine adjacente avant que ce crash ne se produise. Vous réparez le serveur, ou le remplacez, le branchez, laissez l'HyperKernel prendre le relais et vous êtes de retour en action.

Voilà, en un mot, ce que fait la fonction TidalGuard de TidalScale 4.1, qui vient de sortir. Les temps d'arrêt coûtent cher, il est donc important de les éviter. Smerdon affirme que 85 % des entreprises doivent disposer d'un minimum de "quatre neuf" de disponibilité pour leurs systèmes critiques, ce qui signifie avoir des systèmes redondants et répliqués. C'est cher, mais cela en vaut la peine étant donné qu'un tiers des entreprises interrogées par TidalScale affirment qu'une heure d'indisponibilité coûte 1 million de dollars ou plus, et même les plus petites entreprises déclarent perdre au moins 100 000 dollars par heure lorsque leurs systèmes sont hors ligne.

En utilisant TidalGuard sur l'HyperKernel, le temps moyen de réparation d'un système est d'environ dix minutes, un facteur de 10 à 1 000 fois supérieur à d'autres méthodes, et les clients peuvent ajouter encore "deux neuf" de disponibilité à leur infrastructure.

Et TidalGuard peut également résoudre un problème dont nous n'avons pas beaucoup parlé, à savoir le nivellement de l'usure des serveurs dans le centre de données.

"Vous savez que vous devez permuter vos pneus, et nous savons tous que la mémoire flash doit équilibrer le nivellement de l'usure, sinon cela ne fonctionne pas", explique Smerdon. "Maintenant, les serveurs - leur mémoire principale, en fait - s'usent à un rythme de plus en plus rapide, mais il n'y a eu aucune surveillance de cela. Mais nous pouvons surveiller cela dans nos clusters, et en fonction de la santé de l'utilisation, nous sommes en mesure d'estimer parmi un pool, quels serveurs ont le plus de vie restante et donnez la priorité à leur utilisation en premier."

Et avec cette fonctionnalité, vous pouvez commencer à prédire quand vous aurez besoin d'une nouvelle flotte et combien de temps elle pourrait durer.

Fait intéressant, la fiabilité, la disponibilité et l'agilité sont les principales raisons pour lesquelles les entreprises déploient TidalScale aujourd'hui, et l'évolutivité et les économies de coûts sont des priorités secondaires.

Si le clustering NUMA défini par logiciel décolle enfin - et nous pensons que cela pourrait être un outil important dans la boîte à outils d'infrastructure composable - alors TidalScale pourrait devenir une cible d'acquisition. Et étant donné depuis combien de temps il est sur le terrain et que nous n'avons pas entendu parler de déploiements à grande échelle de sa technologie, nous parions que TidalScale serait impatient d'être repris par un fournisseur informatique beaucoup plus important pour aider à pousser l'adoption plus largement.

Si Intel n'a pas restitué certains bits de mémoire à la DRAM avec les SP Sapphire Rapids Xeon, Intel pourrait être intéressé par l'acquisition de TidalScale pour aider à corriger ce problème. Mais cela reviendrait à admettre que cela a créé un problème en premier lieu, donc cela semble peu probable.

Etant donné qu'AMD se limite aux machines à un et deux sockets, cela peut être intéressant. Le collectif Arm pourrait également utiliser des serveurs virtuels NUMA, tout comme l'un des fournisseurs de cloud ne souhaitant pas acheter des serveurs distincts à quatre et huit sockets pour leurs flottes. (Amazon Web Services a joué avec TidalScale en interne, et sans aucun doute d'autres hyperscalers et constructeurs de cloud l'ont également fait.) VMware, à la recherche d'un nouvel angle sur la virtualisation des serveurs, pourrait être intéressé, et idem pour les fabricants de serveurs comme HPE, Dell, et Lenovo.

Avec les faits saillants, les analyses et les histoires de la semaine directement de nous dans votre boîte de réception, sans rien entre les deux.Inscrivez-vous maintenant