Bonjour à la communauté Habr ! Récemment, j'ai écrit sur notre carte de cluster de première génération []. Et aujourd'hui, je souhaite vous parler de notre travail sur la version de mémoire vive.
Nous sommes passionnés par les mini-serveurs qui peuvent être utilisés pour le développement local ainsi que pour l'hébergement local. Contrairement aux ordinateurs de bureau ou aux ordinateurs portables, nos serveurs sont conçus pour fonctionner 24/7, et peuvent être rapidement connectés en fédération. Par exemple, il y avait 4 processeurs dans le cluster, et en 5 minutes, il y avait 16 processeurs (sans équipement réseau supplémentaire), le tout dans un format compact, silencieux et économe en énergie.
Au cœur de l'architecture de nos serveurs se trouve le principe du cluster, c'est-à-dire que nous fabriquons des cartes de cluster qui relient plusieurs modules de calcul (processeurs) via un réseau Ethernet sur la carte. Pour simplifier, nous n’avons pas encore fabriqué nos propres modules de calcul, mais nous utilisons des modules Compute Raspberry Pi et nous espérions beaucoup sur le nouveau module CM4. Cependant, tout cela a déraillé avec leur nouveau format, et je pense que beaucoup sont déçus.
Sous le pli, découvrez comment nous sommes passés de V1 à V2 et comment nous avons dû nous adapter au nouveau format du Raspberry Pi CM4.
Ainsi, après avoir créé un cluster de 7 nœuds, la question est : que faire ensuite ? Comment augmenter la valeur du produit ? 8, 10 ou 16 nœuds ? Quels sont les fabricants de modules ? En réfléchissant au produit dans son ensemble, nous avons compris que l'élément essentiel n'était pas le nombre de nœuds ou le fabricant, mais la nature même des clusters en tant qu'élément fondamental. Il faut chercher le bloc de construction minimal qui
Première, sera un cluster tout en ayant la possibilité de connecter des disques et des cartes d'extension. Le bloc de cluster doit être un nœud de base autonome, avec de vastes possibilités d'expansion.
Deuxième, afin que les blocs de cluster minimaux puissent être interconnectés pour former des clusters plus grands et que cela soit efficace en termes de budget et de rapidité de mise à l'échelle. La rapidité de mise à l'échelle doit être supérieure à celle d'une simple connexion d'ordinateurs ordinaires en réseau et beaucoup moins coûteuse que celle du matériel serveur.
Troisième, les blocs de cluster minimaux doivent être suffisamment compacts, mobiles, économes en énergie, rentables et peu exigeants en matière de conditions d'exploitation. C'est l'une des différences clés avec les racks de serveurs et tout ce qui y est lié.
Nous avons commencé par définir le nombre de nœuds.
Nombre de nœuds
Par des raisonnements logiques simples, nous avons compris que 4 nœuds constituent la meilleure option pour un bloc de cluster minimal. 1 nœud n'est pas un cluster, 2 nœuds c'est trop peu (1 maître 1 ouvrier, sans possibilité d'évoluer dans le cadre du bloc, surtout pour des options hétérogènes), 3 nœuds semblent corrects, mais ne sont pas des puissances de 2 et l'évolutivité est limitée dans le cadre du bloc, 6 nœuds coûtent presque le même prix que 7 nœuds (d'après notre expérience, cela entraîne déjà un coût élevé), 8 c'est trop, cela ne rentre pas dans un facteur de forme mini ITX et c'est une solution encore plus coûteuse pour un PoC.
Nous considérons que quatre nœuds par bloc constituent un bon compromis :
- moins de matériaux pour la carte de cluster, donc production moins chère
- multiplier par 4, soit 4 blocs au total donnent 16 processeurs physiques
- schéma stable avec 1 maître et 3 ouvriers
- plus de variations hétérogènes, modules généralistes + modules de calcul accéléré
- facteur de forme mini ITX avec disques SSD et cartes d'extension
Modules de calcul
La deuxième version est basée sur le CM4 et nous pensions qu'elle serait lancée sous forme de SODIMM. Mais…
Nous avons décidé de créer une carte fille SODIMM et d'assembler le CM4 directement en modules pour que les utilisateurs n'aient pas à penser au CM4.
Module de calcul Turing Pi avec support pour Raspberry Pi CM4
En réalité, la recherche de modules a ouvert tout un marché de modules de calcul allant de petits modules à 128 Mo de RAM jusqu'à 8 Go de RAM. A l'horizon, des modules de 16 Go de RAM et plus. Pour héberger des applications basées sur des technologies cloud native, 1 Go de RAM est déjà insuffisant, tandis que l'apparition récente de modules de 2, 4 et même 8 Go de RAM offre de bonnes perspectives de croissance. Nous avons même envisagé des options avec des modules FPGA pour des applications d'apprentissage automatique, mais leur prise en charge a été reportée car l'écosystème logiciel n'est pas encore développé. En explorant le marché des modules, nous avons eu l'idée de créer une interface universelle pour les modules et dans la V2, nous commençons l'unification de l'interface des modules de calcul. Cela permettra aux utilisateurs de la version V2 de connecter des modules d'autres fabricants et de les mélanger pour des tâches spécifiques.
La V2 prend en charge toute la gamme Raspberry Pi 4 Compute Module (CM4), y compris les versions Lite et les modules de 8 Go de RAM.
Périphériques
Après avoir déterminé le fournisseur des modules et le nombre de nœuds, nous avons abordé le bus PCI, sur lequel se trouvent les périphériques. Le bus PCI est une norme pour les périphériques et il est présent dans presque tous les modules de calcul. Nous avons plusieurs nœuds et idéalement chaque nœud devrait pouvoir partager les périphériques PCI en mode requêtes concurrentes. Par exemple, si c'est un disque connecté au bus, alors il est accessible à tous les nœuds. Nous avons commencé à chercher des commutateurs PCI avec la capacité de supporter le multi-hôte et avons découvert qu'aucun d'entre eux ne répondait à nos exigences. Toutes ces solutions étaient principalement limitées à 1 hôte ou à des multi-hôtes, mais sans mode de requêtes concurrentes auprès des points de terminaison. Le deuxième problème est le coût élevé à partir de 50 $ et plus par puce. Dans V2, nous avons décidé de reporter les expériences avec les commutateurs PCI (nous y reviendrons plus tard au fur et à mesure de l'évolution) et avons choisi d'attribuer un rôle à chaque nœud : les deux premiers nœuds ont exposé un port mini PCI express par nœud, le troisième nœud a exposé un contrôleur SATA à 2 ports 6 Gbps. Pour accéder aux disques depuis d'autres nœuds, on peut utiliser un système de fichiers en réseau dans le cadre du cluster. Pourquoi pas ?
Aperçu
Nous avons décidé de partager quelques esquisses sur l'évolution du bloc de cluster minimal au fil du temps durant nos discussions et réflexions.
Nous avons donc abouti à un bloc de cluster avec 4 nœuds 260-pin, 2 ports mini PCIe (Gen 2) et 2 ports SATA (Gen 3). Une commutation gérée Layer-2 avec support VLAN est intégrée sur la carte. Un port mini PCIe est extrait du premier nœud, dans lequel il est possible d'installer une carte réseau pour obtenir un autre port Ethernet ou un modem 5G, transformant ainsi le premier nœud en routeur pour le réseau du cluster et les ports Ethernet.
Le bus de cluster possède plus de fonctionnalités, y compris la possibilité de flasher directement les modules via tous les emplacements et bien sûr des connecteurs FAN sur chaque nœud avec contrôle de la vitesse.
Application
Infrastructure edge pour applications et services auto-hébergés
Nous avons conçu V2 pour l'utiliser comme un bloc de construction minimal pour une infrastructure edge de qualité commerciale/consommateur. Avec V2, il est bon marché de commencer à tester des concepts et de se développer au fur et à mesure, tout en transférant progressivement des applications qui sont économiquement et pratiquement plus viables à héberger en edge. Les blocs de cluster peuvent être interconnectés pour construire des clusters de plus grande taille. Cela peut se faire progressivement sans risques majeurs pour les installations existantes.
processus. Déjà aujourd'hui, il existe un grand nombre d'applications pour les entreprises, .
Station de travail ARM
Avec jusqu'à 32 Go de RAM par cluster, le premier nœud peut être utilisé pour la version desktop du système d'exploitation (par exemple, Ubuntu Desktop 20.04 LTS) et les 3 nœuds restants pour des tâches de compilation, de test et de débogage, ainsi que pour le développement de solutions cloud natives pour des clusters ARM. Comme nœud pour CI/CD sur l'infrastructure périphérique ARM en production.
Le cluster Turing V2 avec des modules CM4 est architecturément presque identique (la différence réside dans les versions mineures d'ARMv8) au cluster basé sur des instances AWS Graviton. Le processeur des modules CM4 utilise l'architecture ARMv8, vous pouvez créer des images et applications pour les instances Graviton 1 et 2 d'AWS, qui, comme vous le savez, sont beaucoup moins chers que les instances x86.
Source : habr.com
