Salutations à la communauté Habr! J'ai récemment écrit à propos de notre première version du cluster board []. Et aujourd'hui, je veux vous dire comment nous avons travaillé sur la version mémoire vive.
Nous sommes friands de mini-serveurs qui peuvent être utilisés à la fois pour le développement local et l'hébergement local. Contrairement aux ordinateurs fixes ou portables, nos serveurs sont conçus pour fonctionner 24h/7 et 4j/5, ils peuvent être rapidement fédérés, par exemple, il y avait 16 processeurs dans un cluster, et au bout de XNUMX minutes il y avait XNUMX processeurs (pas d'équipement réseau supplémentaire) et tout ça dans un format compact, silencieux et économe en énergie.
L'architecture de nos serveurs est basée sur le principe de construction en cluster, c'est-à-dire nous fabriquons des cartes cluster qui, en utilisant le réseau ethernet de la carte, connectent plusieurs modules de calcul (processeurs). Pour simplifier, nous ne fabriquons pas encore nos propres modules de calcul, mais utilisons des modules de calcul Raspberry Pi et nous espérions vraiment le nouveau module CM4. Mais, tout est allé à l'encontre des plans avec leur nouveau facteur de forme et je pense que beaucoup sont déçus.
Sous la coupe, comment nous sommes passés de la V1 à la V2 et comment nous avons dû sortir avec le nouveau facteur de forme Raspberry Pi CM4.
Ainsi, après avoir créé un cluster pour 7 nœuds, les questions sont - quelle est la prochaine étape ? Comment augmenter la valeur d'un produit ? 8, 10 ou 16 nœuds ? Quels fabricants de modules ? En pensant au produit dans son ensemble, nous avons réalisé que l'essentiel ici n'est pas le nombre de nœuds ou qui est le fabricant, mais l'essence même des clusters en tant que bloc de construction. Nous devons rechercher le bloc de construction minimum qui
première, sera un cluster et pourra en même temps connecter des disques et des cartes d'extension. Le bloc de cluster doit être un nœud de base autonome et avec un large éventail d'options d'extension.
Deuxième, afin que les blocs de cluster minimum puissent être connectés les uns aux autres en construisant des clusters de plus grande taille et de sorte qu'il soit efficace en termes de budget et de vitesse de mise à l'échelle. La vitesse de mise à l'échelle doit être plus rapide que la connexion d'ordinateurs ordinaires à un réseau et beaucoup moins chère que le matériel serveur.
Le troisième, les unités minimales du cluster doivent être suffisamment compactes, mobiles, économes en énergie, rentables et ne nécessitant pas de conditions de fonctionnement. C'est l'une des principales différences par rapport aux racks de serveurs et à tout ce qui s'y rapporte.
Nous avons commencé par déterminer le nombre de nœuds.
Nombre de nœuds
Avec des jugements logiques simples, nous avons réalisé que 4 nœuds est la meilleure option pour le bloc de cluster minimum. 1 nœud n'est pas un cluster, 2 nœuds ne suffisent pas (1 maître 1 travailleur, il n'y a pas de possibilité de mise à l'échelle dans un bloc, en particulier pour les options hétérogènes), 3 nœuds semblent corrects, mais pas un multiple de puissances de 2 et une mise à l'échelle dans un bloc est limité, 6 nœuds ont un prix presque comme 7 nœuds (d'après notre expérience, c'est déjà un gros prix de revient), 8 c'est beaucoup, ne rentre pas dans le facteur de forme mini ITX et une solution PoC encore plus chère.
Quatre nœuds par bloc sont considérés comme le juste milieu :
- moins de matériaux par panneau de cluster, donc moins cher à fabriquer
- multiple de 4, 4 blocs au total donnent 16 processeurs physiques
- circuit stable 1 maître et 3 travailleurs
- variations plus hétérogènes, modules de calcul général + 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 CM4, nous pensions qu'elle sortira au format SODIMM. Mais…
Nous avons pris la décision de créer une carte fille SODIMM et d'assembler le CM4 directement en modules afin que les utilisateurs n'aient pas à penser au CM4.
Module de calcul Turing Pi prenant en charge Raspberry Pi CM4
En général, à la recherche de modules, tout un marché de modules informatiques s'est ouvert, des petits modules avec 128 Mo de RAM à 8 Go de RAM. Des modules avec 16 Go de RAM et plus sont en avance. Pour l'hébergement d'applications edge basé sur des technologies cloud natives, 1 Go de RAM n'est déjà pas suffisant, et l'apparition récente de modules pour 2, 4 et même 8 Go de RAM offre une bonne marge de croissance. Ils ont même envisagé des options avec des modules FPGA pour les applications d'apprentissage automatique, mais leur prise en charge a été retardée car l'écosystème logiciel n'est pas développé. En étudiant 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 à unifier l'interface des modules informatiques. Cela permettra aux propriétaires de la version V2 de connecter des modules d'autres fabricants et de les mélanger pour des tâches spécifiques.
V2 prend en charge toute la gamme de modules de calcul Raspberry Pi 4 (CM4), y compris les versions Lite et les modules de RAM de 8 Go
Périphériques
Après avoir déterminé le fournisseur des modules et le nombre de nœuds, nous nous sommes approchés du bus PCI sur lequel se trouvent les périphériques. Le bus PCI est la norme pour les périphériques et se retrouve dans presque tous les modules informatiques. Nous avons plusieurs nœuds, et idéalement, chaque nœud devrait pouvoir partager des périphériques PCI en mode de requête simultanée. Par exemple, s'il s'agit d'un disque connecté au bus, alors il est disponible pour tous les nœuds. Nous avons commencé à rechercher des commutateurs PCI avec prise en charge multi-hôte et avons constaté qu'aucun d'entre eux ne correspondait à nos exigences. Toutes ces solutions étaient pour la plupart limitées à 1 hôte ou à plusieurs hôtes, mais sans le mode de requêtes simultanées aux points de terminaison. Le deuxième problème est le coût élevé de 50 $ ou plus par puce. Dans la V2, nous avons décidé de reporter les expériences avec les commutateurs PCI (nous y reviendrons plus tard au fur et à mesure de notre développement) et avons suivi le chemin de l'attribution d'un rôle à chaque nœud : les deux premiers nœuds exposaient un port mini PCI express par nœud, le troisième nœud contrôleur SATA 2 ports 6 Gbps exposé . Pour accéder aux disques à partir d'autres nœuds, vous pouvez utiliser le système de fichiers réseau au sein du cluster. Pourquoi pas?
Aperçu
Nous avons décidé de partager quelques esquisses de la façon dont le bloc de cluster minimum a évolué au fil du temps à travers la discussion et la réflexion.
En conséquence, nous sommes arrivés à une unité de cluster avec 4 nœuds à 260 broches, 2 ports mini PCIe (Gen 2), 2 ports SATA (Gen 3). La carte dispose d'un commutateur géré de couche 2 avec prise en charge VLAN. Un port mini PCIe a été supprimé du premier nœud, dans lequel vous pouvez installer une carte réseau et obtenir un autre port Ethernet ou un modem 5G et créer un routeur pour le réseau sur le cluster et les ports Ethernet du premier nœud.
Le bus de cluster a plus de fonctionnalités, y compris la possibilité de flasher des modules directement à travers tous les emplacements et bien sûr des connecteurs FAN sur chaque nœud avec contrôle de vitesse.
application
Infrastructure Edge pour applications et services auto-hébergés
Nous avons conçu la V2 pour qu'elle soit la pierre angulaire minimale d'une infrastructure de périphérie de qualité grand public/commerciale. Avec la V2, il est peu coûteux de commencer la preuve de concept et de l'adapter au fur et à mesure de votre croissance, en transférant progressivement des applications plus économiques et plus pratiques à héberger en périphérie. Les blocs de cluster peuvent être connectés ensemble pour créer des clusters plus grands. Cela peut se faire progressivement sans trop de risques pour l'établissement.
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 de bureau du système d'exploitation (par exemple, Ubuntu Desktop 20.04 LTS) et les 3 nœuds restants pour les tâches de compilation, de test et de débogage, en développant des solutions cloud natives pour ARM groupes. En tant que nœud pour CI / CD sur l'infrastructure de périphérie ARM dans la prod.
Le cluster Turing V2 avec des modules CM4 est presque identique sur le plan architectural (différence dans les versions mineures d'ARMv8) au cluster basé sur des instances AWS Graviton. Le processeur du module CM4 utilise l'architecture ARMv8 afin que vous puissiez créer des images et des applications pour les instances AWS Graviton 1 et 2, qui sont connues pour être beaucoup moins chères que les instances x86.
Source: habr.com