ekzman - Fotolia

Actualites

Stockage objet : comment OpenIO est parvenu à atteindre 171 Go/s

En battant un record mondial sur les vitesses d’écriture, la startup française a surtout démontré que son stockage objet est le seul où l’ajout de nœuds fait croître d’autant les performances.

Yann Serra
par
Publié le: 22 oct. 2019

Le système de stockage objet OpenIO, mis au point par la startup française du même nom, vient de battre un record mondial de vitesse en atteignant un débit de 1,37 Tbit/s (environ 171 Go/s) en écriture sur un cluster de 350 machines. Techniquement, la prouesse n’est pas tant le débit total mesuré, mais plutôt le fait que la performance de ce système ne cesse de croître quand on ajoute des nœuds serveur.

En stockage objet, en effet, ajouter des machines à un cluster ne fait d’ordinaire qu’augmenter sa capacité. La vitesse, elle, dépend du contrôleur qui sert de passerelle entre les serveurs de calcul et ceux bardés de disques ; elle n’augmente a priori pas, ou alors faiblement en ajoutant des contrôleurs.

« Jusqu’à présent, personne n’associait le stockage objet à la performance. Il s’agissait juste d’avoir le plus de place possible, à faible coût, pour archiver des fichiers, éventuellement traités en différé par des applications documentaires. Mais la situation a récemment changé avec l’arrivée d’outils de messagerie compatibles. Dès lors, le stockage objet a basculé dans une problématique d’usage en temps réel par des humains », explique au MagIT, Laurent Denel, PDG et co-fondateur d’OpenIO.

Il précise qu’avoir du stockage objet à la performance élastique présentera un avantage économique pour toutes les nouvelles applications d’analytique qui ont besoin d’écrire en temps réel de nouvelles informations parmi de grands volumes de données. Il cite l’IoT et les moteurs de Machine Learning. Le test mené par OpenIO a d’ailleurs été effectué sur des serveurs prêtés par Critéo, le champion français du ciblage publicitaire, qui utilise ce genre de logiciels.

Sous peu, l’hébergeur OVH devrait d’ailleurs proposer en ligne des clusters OpenIO dédiés au Big Data et à l’intelligence artificielle.

Chaque nœud est à tour de rôle la passerelle S3

La capacité de croître continuellement en vitesse dans OpenIO s’explique par une architecture qui dévie des modèles habituels. Ici, tous les composants fonctionnels s’exécutent depuis tous les nœuds du cluster.

Dans les systèmes de stockage objet courants, un nœud-passerelle présente aux serveurs applicatifs une API objet (S3, OpenStack Swift, etc.) afin qu’ils l’identifient comme le point d’accès pour lire et écrire leurs informations. Cette passerelle est épaulée par un certain nombre de services d’index et de métadonnées, qu’elle exécute elle-même ou qui sont confiés à des nœuds tiers, afin de répartir ou localiser l’information sur les disques les plus adéquats des nœuds présents dans le cluster de stockage. Plus les requêtes s’intensifient du côté des serveurs applicatifs, plus la passerelle fait office de goulet d’étranglement.

Dans OpenIO, chaque nœud serveur exécute un composant pour présenter l’API S3, un autre pour lire et écrire les données et un dernier pour lire et écrire les métadonnées. La répartition des accès depuis les serveurs ne se fait plus dans le cluster lui-même, mais en amont. Soit en incrémentant à chaque requête l’adresse IP de la cible S3 dans le DNS, soit en demandant aux serveurs applicatifs eux-mêmes de le faire.

Dans le cas précis du benchmark effectué chez Critéo, 2500 serveurs applicatifs dans un cluster Hadoop utilisaient ainsi la commande Apache DisCp (Distributed Copy) pour savoir sur quel nouveau nœud OpenIO envoyer leurs prochaines écritures. Cette technique a surtout été utilisée pour permettre ici au système de stockage HDFS d’Hadoop de communiquer avec un stockage S3. Hors Hadoop, les nœuds OpenIO exécutent eux-mêmes un algorithme de Round-Robin pour informer le serveur DNS présent sur le réseau de la nouvelle adresse IP du nœud S3.

« Nous parlons de “grille consciente” pour décrire notre architecture. À chaque cycle, la nouvelle adresse IP est issue d’un tirage aléatoire. Mais si le nœud qui reçoit la requête est trop chargé, il renvoie au serveur applicatif qui tente d’écrire une commande de redirection via l’API S3. Tout le génie de notre système est que cette redirection pour égaliser la charge reste efficace malgré le grand nombre de nœuds dans le cluster OpenIO », indique Laurent Denel, qui explique que ses équipes ont développé le système en langage C pour être au plus proche du matériel.

Lors du test mené chez Critéo, l’équipe d’OpenIO a activité au fur et à mesure des lots de 50 nœuds jusqu’à atteindre un cluster de 350 serveurs de stockage. « Nous avons fait cette expérience pour montrer que, contrairement aux solutions concurrentes, l’ajout de nouveaux nœuds ne conduit à aucun re-brassage de la flotte disponible. La croissance de la capacité et le rééquilibrage de la charge sont immédiats et, de fait, les performances grimpent de manière linéaire », dit-il.

1,37 Tbit/s pour l’écriture et 2 Tbit/s pour l’erasure coding

Les nœuds de stockage sur lesquels a été mené le test de performance, sont des serveurs bi-sockets Xeon Gold 6140 (2x 18 cœurs) dotés chacun de 384 Go de RAM, de 15 disques durs SATA de 8 To pour les données et d’un SSD pour le système. « C’est une configuration surdimensionnée en puissance de calcul. Un nœud OpenIO pilote généralement 24 disques de 12 à 14 To avec seulement 128 Go de RAM et 8 à 12 cœurs. Nous avons même des clients qui installent 60 disques par nœuds. DailyMotion a le record, avec 90 disques par nœud. Ici, nous avons juste pris les serveurs que Critéo mettait à notre disposition », assure Laurent Denel. Il précise que le système OpenIO supporte de fonctionner avec des nœuds radicalement différents dans son cluster.

Un nœud OpenIO se contente d’une double connexion Gigabit Ethernet pour fonctionner. Les serveurs de Critéo étant pourvus d’une double connexion 10 Gbit/s (redondante), la bande passante totale du cluster de 350 machines était donc de 3,5 Tbit/s.

« Les 1,37 Tbit/s que nous avons mesurés sont la bande passante effective des écritures en provenance des serveurs Hadoop sur le cluster OpenIO. Les 2 Tbit/s restants sont utilisés par nos nœuds pour l’Erasure coding, c’est-à-dire pour répliquer entre nœuds des blocs d’information afin que les données ne soient jamais perdues », précise le PDG. 

L’Erasure Coding est réglable à volonté. Dans le cadre de ce test, le nœud qui reçoit les données à écrire les tronçonne en 14 morceaux (des « chunks »), crée 4 chunks redondants, conserve l’un d’eux, puis envoie les 17 chunks restants vers 17 nœuds. OpenIO ne gérant que des chunks d’un maximum de 100 Mo, les objets de plus de 1,4 Go subissent plusieurs cycles de tronçonnage. À l’inverse, les objets les plus petits ne sont pas tronçonnés, mais juste répliqués quatre fois vers d’autres nœuds.

Le fait de créer quatre chunks redondants ou de créer quatre répliques des objets plus petits signifie qu’aucune donnée ne sera perdue même si quatre nœuds tombent en panne en même temps.

Il est à noter que le test mené par OpenIo chez Critéo ne mesure pas la vitesse de lecture. En théorie, celle-ci devrait être meilleure que la vitesse d’écriture, car le nœud interrogé n’a qu’à rapatrier les 14 chunks essentiels d’un objet pour l’envoyer vers le serveur qui le demande. « Nous n’avons pas mesuré la vitesse de lecture, car elle est suffisamment rapide sur l’ensemble des solutions de stockage objet. Seules les écritures posent un problème de performances et c’est bien celui-ci que nous résolvons », conclut Laurent Denel.

Pour approfondir sur Editeurs