Par Daniel Pehush et Gunter Zink
La mission - Attention, ça avance
Reprenant de notre Blog post précédent, les performances égales, le prochain élément important a été la sélection du (des) fournisseur (s) de nos périphériques de stockage.
Avec la plupart des fournisseurs avec lesquels nous avons parlé, Qumulo avait déjà acheté ou possédait de l'expérience avec leurs disques SSD SATA. Notre expérience en matière de qualification a donné les résultats suivants:
- Fournisseur A: bonne expérience en matière de fiabilité, meilleures performances, pas bon marché, bon approvisionnement
- Fournisseur B: bonne fiabilité, assez rapide, coûteux, défis de la chaîne d'approvisionnement
- Fournisseur C: échec des tests internes
- Vendeur D: échec des tests internes
Eh bien, une seule option correspond à ce que nous voulions offrir aux clients pour le lancement. Ce n'était évidemment pas idéal et nous sommes restés en contact étroit avec ces fournisseurs pour valider les futurs candidats à une utilisation dans nos produits. Nous avons passé suffisamment de temps avec chaque fournisseur pour essayer de faire en sorte que sa solution fonctionne pour nous, mais nous n’avions au final qu’une seule excellente solution.
Le châssis que nous avons choisi est une solution complète d'un fournisseur et est livré avec d'excellentes fonctionnalités, notamment: des ventilateurs remplaçables sur site sans outil, des supports de disque sans outil et des adaptateurs PCIe Riser sans outil qui donnent accès à nos cartes de commutation PCIe et à nos cartes réseau PCIe cartes. Les blocs d'alimentation (PSU) sont même conçus intelligemment, de sorte qu'une fois qu'un cordon d'alimentation est installé, vous ne pouvez pas appuyer sur le commutateur pour déverrouiller un bloc d'alimentation du châssis sans retirer le cordon d'alimentation. Aucun retrait du bloc d'alimentation n'est possible lorsque le bloc d'alimentation est sous tension. Cette conception est un excellent moyen d'éviter les accidents des utilisateurs. Les seuls composants que nous avons intégrés du point de vue de la personnalisation sont les disques et les cartes réseau - quelle facilité! C'est un système bien conçu qui respire la disponibilité de l'entreprise, et nous sommes heureux de le rendre incroyablement rapide pour le fichier avec notre logiciel.
Obstacles sur les pistes ou devrais-je dire sur la voie du développement?
Architecture de voie PCIe
La scène était donc prête pour la première plate-forme matérielle 100% Flash de Qumulo à se qualifier et à être livrée aux équipes logicielles pour que le développement commence. Le châssis est entièrement intégré (L9) d'un fournisseur et dispose d'emplacements 24 pour les périphériques NVMe. C’est tout, comme on pourrait le dire familièrement, à la pointe technologie, mais NVMe est sur le marché depuis un certain temps maintenant, on s’attendait à ce que les choses se passent bien. En plus de la maturité NVMe, nous avons choisi en toute confiance un châssis déjà établi sur le marché. Les équipes de Qumulo ont beaucoup d'expérience dans la création de plates-formes personnalisées. Par conséquent, la fourniture d'une plate-forme standard devrait comporter moins de rides, n'est-ce pas?
Après avoir déjà envoyé un bon de commande pour recevoir un certain nombre de serveurs, il est apparu que, tandis que le châssis 2U est vendu avec des baies 24 pour les périphériques NVMe U.2, seuls les baies 20 sont câblées pour une utilisation réelle. Nous avions prévu d'utiliser toutes les baies 24 et nous avons donc lancé une discussion sur l'architecture PCIe sur la manière dont nous pourrions avoir accès à toutes les baies. Pour commencer, CPU1 dispose d’un total de voies 16 disponibles de PCIe Gen3, tandis que CPU2 dispose de voies 32 de PCIe Gen3. Chaque CPU a une quantité de 2 Occulink PCIe x4 les ports. Pour traiter les périphériques 24 NVMe, chaque périphérique a besoin de voies 4 PCIe Gen3, ce qui représente un total de voies 96 devant être exécutées sur le fond de panier où ces unités sont connectées. Nous avons également besoin de jeux de voies 2 16 pour desservir nos deux cartes réseau 40GbE / 100GbE à double port.
Si vous avez gardé tous ces chiffres en tête, nous avons besoin d’un nombre total de voies 128 PCIe Gen3 et de voies 56 sur lesquelles travailler. Ces chiffres ne correspondent pas! Bien entendu, la conception du serveur est déjà en tant que telle pour résoudre ce problème avec des commutateurs PCIe. Si vous n'êtes pas familier, les commutateurs PCIe peuvent créer plusieurs ensembles de voies à partir d'un ensemble plus petit pour permettre le partage avec plusieurs périphériques. Le serveur était livré avec deux commutateurs PCIe qui occupaient 8 voies et se répartissaient sur 8 périphériques NVMe U.2 au total, soit 32 voies. Alors maintenant, notre total de voies disponibles était de 104 voies. Comme indiqué, le fournisseur ne prévoyait que 20 des emplacements pour être adressables, donc si nous devions couper ces 4 appareils (un total de 16 voies), nous aurions 104 voies disponibles, pour un besoin de 112 voies. Enfin, nous aurions pu réduire nos NIC de périphériques x16 à des périphériques x8, divisant par deux la bande passante de notre réseau souhaitée pour nos clients, et nous aurions alors suffisamment de voies pour satisfaire la plate-forme. Ce… n'était pas une solution qui satisferait nos clients.
Ensuite, nous avons rencontré une restriction mécanique. Il existe des risers PCIe 3 dans les systèmes. Ce sont des cartes PCBA qui alimentent les voies PCIe dans des organisations mécaniques optimales. Le système a été conçu à l'origine pour que Riser1 puisse alimenter trois cartes adaptateur x8 PCIe, Riser2 pour alimenter trois cartes adaptateur x8 PCIe et Riser3 pour alimenter une seule carte adaptateur x4. Il n’y avait pas d’endroit physique pour installer une carte réseau x16 comme nous l’avions souhaité à l’origine! À un moment donné, nous avons envisagé de réduire de moitié la bande passante des périphériques NVMe et de les relier via des voies 2 au lieu de 4 (appelé bifurcation) afin de disposer de suffisamment de voies pour les lecteurs. Le fournisseur est revenu en affirmant que cela utiliserait les périphériques en dehors des spécifications, de sorte que cette option n'était pas une option.
Nous avons travaillé avec le fournisseur pour générer une solution qui ravira nos clients. Nous avons découvert qu’un autre type de carte de montage avait été conçu. nous avons validé ce nouveau riser PCIe, doté d'un emplacement x8 et d'un emplacement x16, réorganisé les choses de manière mécanique et abouti à une solution optimale entre un emplacement x8 et un emplacement x16. Maintenant, CPU1 a alimenté des périphériques 2 NVMe via 2 Occulink PCIe x4 ports et une carte réseau x16 et des périphériques 2 NVMe alimentés par CPU2 via 2 Occulink PCIe x4 ports, une carte réseau x16, deux commutateurs PCIe à port x8, 8 et un commutateur PCIe à port x4, 4. Si nous faisons des calculs rapides…
Voies souhaitées (128) = (x16 NIC) ✕ (2) + (x4 NVMe U.2 Drive) ✕ (24)
Voies disponibles (128) = (x4 Occulink ports) (4) + (CPU1 x16 pour NIC) + (CPU2 x16 pour NIC) + (CPU2 x8, x8, x4 -> x8 8 ports switch x32, x8 8 ports switch x32, x4 4 ports switch x16)
Succès! Nous avons l'architecture PCIe pour tirer pleinement parti du serveur sans compromis! Cela n'aurait pas été possible sans notre persistance et notre collaboration de vendeurs, félicitations bien méritées à notre fournisseur de serveurs / châssis!
Validation thermique
Alors que nous travaillions pour choisir un processeur, le fournisseur a déclaré que le processeur que nous souhaitions utiliser - l'Intel Xeon Gold 6126 TDP de 125W - était trop chaud pour être utilisé dans le châssis. Nous devions utiliser un processeur TDP inférieur qui ne consommait que 85W, nous avons donc testé avec l'Intel Xeon Gold 5115. Cela a eu une baisse indésirable des performances par rapport au processeur 6126. De plus, nous avons configuré le serveur d'une manière que le fournisseur n'avait pas initialement prévue, et avons ajouté 4 périphériques NVMe qu'ils n'avaient pas l'intention de prendre en charge. Pour que ce système fournisse les performances et le stockage corrects à nos clients, nous devions obtenir une prise en charge thermique de cette configuration.
Nous avons travaillé pour que la validation thermique du serveur soit requalifiée. Il nous est alors apparu que la qualification thermique d'origine du nœud ne supportait que des températures jusqu'à 27 ° C! Nous avons discuté avec le fournisseur du fait que pour que ce produit soit viable, nous devions être en mesure de le prendre en charge dans un environnement pouvant atteindre 35 ° C (10 ° C à 35 ° C à 10,000 pieds d'altitude est la plage de température de fonctionnement standard pour les serveurs / appareils. (ASHRAE Classe A2)). Heureusement, le travail ici n'a impliqué que quelques réunions, en changeant le modèle d'alimentation en un modèle avec un refroidissement plus efficace et en testant tout dans la chambre thermique du fournisseur, ce qui a abouti à une plate-forme qualifiée avec le nombre de processeurs et de disques que nous souhaitions!
15mm vs. 7mm U.2 Devices
À un moment donné, nous avons envisagé d’utiliser des disques 7mm NVMe U.2 au lieu de disques 15mm NVMe. Cela nous permettrait d'utiliser une plus grande quantité de disques NVMe sur une plate-forme 1U ou 2U. Cette idée a rapidement été mise de côté lors de la planification avec nos fournisseurs de disques préférés. Le format 7mm semblait disparaître ou ne recevoir aucun support de niveau 1st. Ne voulant pas nous intégrer dans une chaîne logistique difficile et dans une situation non durable, nous avons décidé que les périphériques 15mm U.2 seraient le meilleur choix de périphérique de stockage.
Sélection du noyau 4.13
Ensuite est venu le temps de mettre en place notre logiciel. Attendez, ce n'est pas la prochaine étape; l'étape suivante consistait simplement à voir si nous pouvions faire démarrer notre système d'exploitation vanilla sur la plate-forme. Nous savions qu'avec cette technologie de pointe, nous aurions besoin de tirer parti des fonctionnalités SW / noyau qui peuvent ne pas être présentes dans notre combinaison OS / noyau actuelle. Qumulo fonctionne sur Ubuntu 16.04, dont la version de base du noyau est 4.4. À l'époque, ce noyau n'avait pas les fonctionnalités nécessaires pour gérer le hotswap NVMe. Nous sommes donc passés au noyau d'activation du matériel Ubuntu 4.8. Ce noyau a les fonctionnalités dont nous avions besoin, mais une mauvaise incompatibilité avec un pilote vidéo qui causerait des problèmes lors de l'utilisation d'un crash cart, ou KVM, ou permettrait au serveur de démarrer du tout. Nous avons discuté pendant un certain temps de la liste noire du pilote vidéo, mais la perte de fonctionnalité serait trop importante. Nous avons effectué un autre saut vers un noyau d'activation matérielle Ubuntu 4.13. Idéalement, nous déplacerions toute la gamme de produits vers le même noyau, mais certains packages requis pour les autres plates-formes que nous livrons ne se compileraient pas, nous avons donc divisé notre base de produits entre les noyaux. Enfin un noyau qui semblait avoir l'ensemble des fonctionnalités dont nous avions besoin et aucun inconvénient flagrant n'a été découvert jusqu'à présent ...
Les tests Hotswap génèrent la fragilité du système
À ce stade du cycle de validation, le système a atteint un niveau de fonctionnalité de base. L'un des principaux points de validation de toute plate-forme matérielle est le test hotswap ou hotplug. Les appareils annoncés en tant que tels ne doivent en aucun cas causer d’affaissement ou de choc aux lignes électriques, car ils sont retirés et insérés dans diverses situations. Ils doivent également travailler avec le logiciel hôte et être fonctionnels après un échange à chaud. ne causant pas de problèmes avec le logiciel. Pendant les tests, les choses ont mal tourné. Ce sujet est le gros obstacle / montagne auquel nous avons été confrontés lors de la validation de ce produit, nous en discuterons donc pendant un moment.
Lors des tests hotswap, nous avons identifié une série de problèmes qui nous empêcheraient d’expédier la plateforme. Ce sont tous des problèmes liés à l'interaction du matériel et des logiciels. Certains des modes de défaillance qui se manifesteraient sont énumérés ci-dessous:
- Lors du retrait et de la réinsertion d'un lecteur NVME, le logiciel n'a pas pu détecter la réintroduction du lecteur. Le logement lui-même semblait être désactivé; par conséquent, même l'installation d'un autre lecteur ne permettait pas au système de remarquer que ce lecteur était installé. Par conséquent, le système serait en panne d'un lecteur jusqu'à un cycle d'alimentation.
- Nous avons constaté un cas dans lequel la suppression d'un lecteur n'entraînait pas la suppression du périphérique sous Linux, puis tous les appels sur le périphérique étaient bloqués jusqu'à ce que le nœud soit mis sous tension.
Ces problèmes nous empêchent d’expédier le produit.
Pour corriger ce problème, nous devrions utiliser une fonctionnalité appelée «Périphérique de gestion de volume» ou VMD. Cette fonctionnalité du BIOS assure la stabilité et le contrôle de gestion des voyants pour l’échange à chaud. Nous avons travaillé avec le fournisseur pour activer cette fonctionnalité dans le BIOS. Un petit changement qui nous a incité à prendre une version ultérieure de lspci qui a été publiée pour gérer les nouvelles longueurs d'adresses de périphériques apparues en activant VMD. Jusqu'à ce que ce correctif soit pris, lspci n'était pas fonctionnel. Une autre petite bosse pendant ce voyage.
Génial, nous sommes maintenant supposés résoudre les problèmes de fragilité de disque et contrôler les voyants des périphériques NVMe. Ai-je mentionné que la commande à DEL ne fonctionnait pas du tout sans VMD? Ensuite, nous avons également dû modifier le micrologiciel du commutateur en cours de chargement pour permettre le contrôle par LED des périphériques NVMe.
Nous avons ensuite constaté que la performance des disques utilisés par notre logiciel avait été réduite de 60 pour certaines charges de travail. Avons-nous mentionné que certains des problèmes de fragilité de disque susmentionnés étaient toujours présents? Ce n'est pas vraiment un changement acceptable pour une solution que nous voulions offrir à nos clients. En travaillant avec notre fournisseur et en effectuant diverses opérations de collecte de données et d’expérimentation, en les faisant venir physiquement sur le site et en travaillant main dans la main, nous avons identifié plusieurs correctifs de noyau à sauvegarder pour résoudre les problèmes de fragilité et de performances des disques. Enfin, il a été identifié que le pilote de commutateur, qui était chargé par défaut, entraînait une régression des performances dans le commutateur et que, en collaboration avec le fournisseur, il était déterminé qu'il n'était pas nécessaire pour la plate-forme.
Ce problème et cette résolution étaient détaillés dans quelques paragraphes ci-dessus, mais il s’agissait d’une enquête étalée sur plusieurs mois, avec de nombreuses discussions avec notre fournisseur et de nombreuses expériences et tests menés pour valider une solution.
Les premiers micrologiciels entraînent une mort plus importante que prévu des composants
C’était un autre caillou dans notre chaussure alors que toutes ces enquêtes étaient en cours. Nous avons eu un couple de lecteurs meurent sur nous. Il y a toujours des attentes de mortalité infantile pour tous les composants, mais pour le nombre de défaillances de composants que nous avons connues, nous sommes devenus méfiants. Il s'est avéré que le fournisseur avait déjà été mis au courant du problème et, lorsque nous l'avons signalé, un correctif de micrologiciel était disponible pour le composant. Leçon apprise, demandez toujours la dernière version du firmware et souvent.
Les deuxièmes composants d'approvisionnement vont mal
Lors du lancement, on veut toujours avoir plusieurs sources s’ils le peuvent pour un composant. Dans ce cas, nous avons tenté de qualifier un autre fournisseur pour nos périphériques U.2 NVMe. Cela a conduit à une enquête où les disques ne pourraient pas renégocier avec la plateforme lors du retrait et de la réinsertion. Cela peut sembler familier aux problèmes décrits ci-dessus, mais il s’agit d’un problème complètement différent. Lors de la capture d’une trace de bus et des codes d’erreur des lecteurs, nous avons constaté que le port racine envoyait des commandes à un lecteur après une analyse à chaud ayant une taille de charge utile PCIe incompatible. La carte mère dans ce cas était le coupable. Cela a pris un certain temps à identifier, car nous avions suspecté le lecteur et le commutateur avant de déterminer que la carte mère enfreignait la spécification PCIe. En fin de compte, nous avons identifié un paramètre grub Linux que nous pourrions définir pour obliger le logiciel à agir correctement et à rendre viable ce deuxième composant source. Succès! Ensuite, la performance s’est avérée être une telle régression de notre source principale, nous ne pouvions pas les utiliser! Bummer! Une autre leçon apprise: avant de plonger dans le vif du sujet, assurez-vous qu’il n’est pas plus facile d’identifier un navire arrêté avant de passer trop de cycles.
Sélection de la carte réseau
N'oubliez pas dans cet article où j'ai parlé de l'activation de la plate-forme avec les NIC 2GbE à double port 40 ou les NIC 100GbE? Lorsque vous construisez un serveur de type Ferrari qui coûte $$$$, vous économisez parfois de l'argent en permettant aux clients de commander un composant en fonction de leurs besoins, cela coûte plus cher à votre client en support technique et en supportant davantage Composants. Vers la fin du cycle de développement, nous avons décidé de passer à une option de carte réseau pour permettre une matrice de test plus petite et fournir à la fois 40GbE / 100GbE à partir d'un seul composant. La qualification et le support sont plus faciles, une victoire facile.
Le Résultat
Le résultat de tout cela est que nous avons livré une plate-forme 100% Flash capable de stocker des fichiers sur NFS ou SMB et de diffuser des flux 3 de vidéo non compressée 4K par nœud. Par conséquent, le plus petit cluster viable de nœuds 4T de la série P, 23, est capable de diffuser du flux 12 de vidéo non compressée 4K! Grâce à la capacité de ce matériel, nos équipes logicielles travaillent sans relâche pour optimiser les performances de la plate-forme la plus rapide livrée au monde par Qumulo. Des efforts visant à améliorer les performances sont déployés sur notre plate-forme 100% flash.
C'est la plate-forme de la plus haute qualité que nous avons livrée à ce jour. Et nous avons pu tirer parti de la toile d'un fournisseur pour le faire. Profitant des efforts d'ingénierie et des ressources d'une autre société pour les compléter avec nos propres logiciels et validations. Avec toutes ces performances, nous avons également créé une plate-forme économe en énergie, tirant ~ 250W en mode inactif et, avec la charge de travail multi-flux la plus élevée que nous ayons subie, nous avons enregistré ~ 650W en puissance. Une partie de ces économies d’énergie est due à l’absence de supports de stockage en rotation, ainsi qu’à une gestion sophistiquée de l’alimentation des processeurs et des disques NVME.
En raison de notre cycle de développement logiciel itératif, nous continuerons d'améliorer ce produit après l'avoir expédié aux clients. Nos développeurs de logiciels ne restent pas les bras croisés; ils s'efforcent constamment de fournir le meilleur produit et la meilleure expérience d'amélioration continue de la planète. Nous espérons que vous avez apprécié ce voyage de développement de plates-formes matérielles chez Qumulo!
Un grand merci aux rédacteurs de cette série en trois parties: Michaela Hutfles, Luke Mulkey et Jason Sturgeon
