Par Daniel Pehush et Gunter Zink

The Mission - Attention, bosses devant

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 proposée par un fournisseur et doté d'excellentes fonctionnalités, notamment des ventilateurs remplaçables sur site, des supports de lecteur sans outil et des adaptateurs PCIe Riser sans outil donnant accès à nos cartes de commutateur PCIe et à la carte réseau PCIe. cartes. Les blocs d'alimentation sont même conçus de manière intelligente, de sorte qu'une fois le cordon d'alimentation inséré, vous ne pouvez pas appuyer sur le commutateur pour déverrouiller un bloc d'alimentation du châssis sans débrancher le cordon d'alimentation. Aucune suppression de bloc d'alimentation n'est possible tant que le bloc d'alimentation est alimenté. Cette conception est un excellent moyen de prévenir 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 capacité de préparation des entreprises et nous sommes heureux de le rendre extrêmement rapide pour les fichiers 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 sur un ensemble plus petit pour permettre le partage avec plusieurs périphériques. Le serveur était livré avec deux commutateurs PCIe prenant des voies 8 et ventilés vers des périphériques 8 totaux NVMe U.2, ou voies 32. Alors maintenant, le nombre total de voies disponibles était 104. Comme indiqué, le fournisseur ne souhaitait adresser les créneaux à 20. Par conséquent, si nous supprimions ces périphériques 4 (un total de voies 16), nous aurions des voies 104 disponibles pour un besoin en voies 112. Enfin, nous aurions pu réduire notre carte réseau de périphériques x16 à des périphériques x8, en divisant par deux la bande passante réseau souhaitée par nos clients, puis en disposant de 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) = (carte réseau x16) ✕ (2) + (lecteur x4 NVMe U.2) (24)

Voies disponibles (128) = (x4 Occulink le nombre de ports (xnumx)

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 fabricant a déclaré que le processeur que nous souhaitions utiliser - le TDP Intel Xeon Gold 6126 de 125W - était trop chaud pour être utilisé dans le châssis. Nous devions utiliser un processeur TDP plus faible ne consommant que 85W, nous avons donc testé avec le processeur Intel Xeon Gold 5115. Cela entraînait une baisse indésirable des performances par rapport au processeur 6126. En outre, nous avons configuré le serveur d’une manière non prévue à l’origine par le fournisseur et ajouté des périphériques 4 NVMe qu’ils ne souhaitaient pas prendre en charge. Pour que ce système offre des performances et un stockage corrects à nos clients, nous devions prendre en charge cette configuration de manière thermique.

Nous avons travaillé à la requalification de la validation thermique du serveur. Nous avons ensuite constaté que la qualification thermique initiale du noeud ne prenait en charge que des températures allant jusqu'à 27C! Nous avons discuté avec le fournisseur que, pour que ce produit soit viable, nous devions être en mesure de le prendre en charge dans un environnement aussi chaud que 35C (10C - 35C à 10,000 en altitude. La plage de température de fonctionnement standard pour serveurs / appliances (Classe ASHRAE A2)). Heureusement, le travail ici impliquait seulement deux réunions, changeant le modèle d'alimentation en un système avec un refroidissement plus efficace, et testant tout dans la chambre thermique du fournisseur, résultant en 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

Vient ensuite le moment de mettre notre logiciel. Attendez, ce n'est pas la prochaine étape. la prochaine étape consistait simplement à voir si nous pouvions obtenir notre système d'exploitation vanilla pour démarrer 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 du noyau de base est 4.4. À ce moment, ce noyau ne disposait pas des fonctionnalités nécessaires pour gérer l’échange à chaud NVMe. Nous nous sommes donc tournés vers le noyau d'activation matérielle Ubuntu, 4.8. Ce noyau a les fonctionnalités dont nous avions besoin, mais une incompatibilité médiocre avec un pilote vidéo, ce qui poserait des problèmes lors de l’utilisation d’un panier de blocage ou de KVM, ou ne permettrait pas au serveur de démarrer. Nous avons discuté pendant un certain temps de la mise en liste noire du pilote vidéo, mais la perte de fonctionnalité serait trop grave. Nous avons effectué un autre saut vers le noyau 4.13 du noyau d'activation de matériel Ubuntu. 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 expédions ne compileraient pas. Nous avons donc divisé notre base de produits entre les noyaux. Finalement, un noyau qui semblait avoir les fonctionnalités dont nous avions besoin et aucun inconvénient criant n’a été découvert à ce jour…

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 à améliorer ce produit après l'avoir expédié aux clients. Nos développeurs de logiciels ne restent pas inactifs; 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 plate-forme matérielle chez Qumulo!

Un grand merci aux rédacteurs de cette série en trois parties: Michaela Hutfles, Luke Mulkey et Jason Sturgeon

Partager avec votre réseau

OBTENIR UNE DEMO