Navigation ↓
  |  OpenIO

Les coulisses du #TbpsChallenge

Read the English version

Tout ce que vous avez toujours voulu savoir sur le #Tbps (sans oser le demander)

Qu’est-ce que le #TbpsChallenge ?

Pour démontrer la performance et la scalabilité de sa solution d’Object Storage, la startup lilloise OpenIO a déployé sa technologie logicielle de stockage sur un cluster de plus de 350 serveurs physiques, mis à disposition par Criteo Labs. Le benchmark a permis de franchir le cap symbolique du térabit, et même de le dépasser avec un débit utile constaté de 1,372 Tbps. S’il s’agissait de transférer numériquement l’intégralité de la plus grande bibliothèque du monde – celle du Congrès américain, riche de plus de 22 millions d’ouvrages imprimés – l’opération pourrait être bouclée en moins d’une minute (d’après une estimation de l’Université de Berkeley, qui évalue le poids total à 10 To).

Cette performance, réalisée dans les conditions de la production, consacre le design du logiciel de stockage en mode objet développé par OpenIO, pensé pour les nouveaux usages des données, en particulier l’exploitation massive des données par des algorithmes d’IA sur des clusters Big Data / HPC. Inaugurant par ce record le #TbpsChallenge, OpenIO invite les autres acteurs du marché à mettre leur technologie à l’épreuve.

Comment le cluster a-t-il été configuré pour atteindre cette performance ?

OpenIO a une architecture en grille ; c’est un système complètement distribué, avec un couplage faible entre les composants. Il n’y a pas de hiérarchie entre les machines, ni de système de gestion centralisé des transactions. Aucune machine n’intercepte l’ensemble du trafic : chacune exécute les 3 composants d’OpenIO et fait office de passerelle S3, stocke une partie des métadonnées et des données. Ce benchmark a donc consisté à agréger, avec le moins de pertes possible, les performances de chacune des machines du cluster.

Quel système de répartition de charge a été mis en place pour atteindre ce niveau de bande passante sans qu’il n’y ait de point de congestion ?

Les tâches de copie, depuis le datalake de production de Criteo vers le cluster OpenIO, ont été lancées via DistCp (ditributed copie). Cet outil, qui fait partie de l’écosystème Hadoop, peut lire et écrire depuis et vers HDFS ou S3, mais il ne gère pas la répartition de la charge. Aussi, un load balancing à deux niveaux a été mis en place. D’abord, un algorithme type round-robin au niveau de la résolution DNS, côté Criteo, pour router les requêtes adressées au cluster OpenIO vers l’une des 350 passerelles S3.

Puis, comme le round-robin ne répartit pas la charge de manière parfaitement uniforme, OpenIO a implémenté son propre mécanisme de load balancing secondaire, basé sur des redirections intelligentes entre les nœuds pour envoyer la charge sur les serveurs les plus disponibles à l’instant T. Chacune des passerelles OpenIO S3 est capable de partager la charge avec les autres. Ceci a produit un flux d’écriture très régulier, chaque passerelle prenant 1/350 des appels en écriture.

Comment le cluster d’injection était-il connecté au cluster cible ?

Du point de vue du réseau, les 2 plates-formes sont imbriquées l’une dans l’autre, et les serveurs appartiennent au même réseau maillé (full mesh).
En ce sens, le réseau est « illimité » : chaque nœud peut atteindre sa bande passante théorique de 10 Gbps en parlant aux autres nœuds.

Quels types de disques ont été utilisés pour ce benchmark ?

Les serveurs impliqués dans ce benchmark étaient dotés de disques durs magnétiques 3,5″

de 8 To chacun (15 disques par serveurs), qui stockaient les données. Les métadonnées (l’annuaire contenant l’emplacement des chunks de chaque objet sur le cluster) étaient quant à elles stockées sur le disque système (disque SSD de 240 Go) de chaque serveur. Le stockage de ces métadonnées requiert habituellement moins de 1 % de la capacité totale de la plateforme.

Quelles étaient les caractéristiques des serveurs utilisés ?

Dans le cadre de la mise à jour annuelle de ses capacités, Criteo Labs disposait d’un lot de machines physiques neuves, installées dans les racks, mais pas encore intégrées à son cluster de production. Ces machines ont été mises sous tension et prêtées gracieusement à OpenIO pendant quelques jours, le temps de réaliser le benchmark.

Ces serveurs sont taillés pour être des nœuds Hadoop, capables de stocker des données sous HDFS et de réaliser des calculs. Ils sont, en conséquence, généreusement dotés en CPU et RAM. Il s’agit de serveurs standards (commdity servers) 2U, équipés d’une interface réseau 10 Gbps dual port (mais un seul port était activé et câblé).

Voici la configuration détaillée, HPE 2U standard DL380 Gen10, avec :

  • Processeur 2 x Intel Skylake Gold 6140
  • RAM 384 Go (12 x 32 Go – SK Hynix, DDR4 RDIMM @2 666 MHz)
  • Lecteurs système 2 x 240 Go (un seul utilisé pour les métadonnées) Micron 5100 ECO
  • Capacité des disques durs SATA – LFF – Hotswap 15 x 8 To – Hotswap – Seagate
  • Réseau 2 x SFP+ 10 Gbps HPE 562FLR-SFP + Adaptateur Intel X710 (un seul connecté et fonctionnel)

Du point de vue d’OpenIO, ces machines sont sous-optimales en termes de densité (ratio CPU/RAM vs. capacité de stockage). D’ailleurs, la capacité utile du cluster après formatage est de 38 Po, soit assez faible pour 352 serveurs. Un serveur OpenIO typique serait plutôt équipé de disques de 14 To, d’une capacité CPU réduite et 128 Go de RAM auraient été suffisants.

Avec un débit en écriture de 1,372 Tbps, OpenIO a-t-il atteint ses limites de performance ?

Non. Ce benchmark a même démontré le contraire : avec plus de nœuds, plus de bande passante et plus de disques sur chaque serveur, la bande passante atteinte aurait été encore plus élevée, et ce, de manière linéaire. En atteignant 1,372 Tbps de débit utile en écriture, nous avons approché les limites théoriques de la capacité réseau dont nous disposions.

L’écart entre la capacité réseau théorique et la bande passante utile constatée s’explique par deux facteurs. Tout système distribué génère un coût réseau, lié au fait que les machines discutent entre elles pour partager leur état respectif et prendre les décisions. Surtout, le mécanisme de protection des données (erasure coding 14 + 4 dans le cadre de notre benchmark) implique un surcoût réseau conséquent, puisque chaque fichier écrit est partagé en 14 chunks, et 4 chunk supplémentaires sont créés de sorte à pouvoir recréer les données en cas de perte d’un disque ou d’un serveur (il est ici possible de perdre jusqu’à 4 serveurs sans mettre les données à risque). Sur les 18 chunks, 17 sont re-dispatchés sur le cluster, engendrant une consommation de bande passante supérieure au débit efficace vu depuis l’application cliente. On peut également en déduire qu’un benchmark en lecture aurait permis d’observer une bande passante plus élevée. Nous avons, pour ce benchmark, opté pour le cas d’usage le plus « difficile » à réaliser, la lecture n’impliquant pas en général de calcul lié à l’Erasure Coding.

Suivez l’actualité du #TbpsChallenge sur Twitter
En savoir plus en consultant le benchmark report détaillé