Navigation ↓
  |  Laurent Denel

Performances des systèmes de stockage: 3 critères à prendre en compte.

Read the English version

Nombreuses sont les solutions de stockage qui revendiquent les meilleures performances du marché. Il est d’autant plus facile de surenchérir qu’il est impossible de comparer objectivement la performance de différents systèmes de stockage. Et pour cause : la performance, quand on parle de stockage de données, s’entend au moins en trois dimensions, l’importance de chacune d’elles étant fonction du cas d’usage. Sans oublier que les performances doivent être corrélées au coût total de possession (TCO) des différentes solutions, difficile à évaluer – a fortiori lorsqu’on y mêle le coût humain d’une migration, dans le cas où l’on substitue un système de stockage à un autre.

Rares sont ceux qui peuvent débourser sans compter pour stocker leurs données, à l’exception de quelques industries de pointe ou centres de recherche. Et encore : mettre le prix fort n’assure pas toujours les meilleures performances. Si l’usage est trop éloigné de ce pour quoi a été conçu le système de stockage choisi, les limites apparaîtront vite. Bref, la performance d’un système de stockage est une notion floue, et cela mérite qu’on s’y attarde pour battre en brèche les arguments marketing trop simplistes qui biaisent souvent les choix des entreprises.

Block, File ans Object Storage performance comparison

Capacité de stockage

Commençons par la dimension la plus évidente : la capacité de stockage. Il faut entendre par là deux choses : le volume de données qu’il est possible de stocker sur un système unique et la facilité avec laquelle il est possible de faire évoluer la capacité de la plateforme pour répondre à la croissance des besoins – on parle alors de scalabilité horizontale (scale-out). Concrètement, il s’agit de pouvoir démarrer « petit » et de faire grossir le cluster de stockage sans effet de palier, sans migrer les données, en conservant tout à la fois la facilité d’administration et des performances linéaires.

À l’a une du critère de la capacité, l’Object Storage apparaît naturellement comme la solution idéale, car elle n’a théoriquement aucune limite. Dans la réalité, les différentes implémentations de l’Object Storage ne sont pas toutes égales devant la promesse originelle de scalabilité infinie. Souvent, lorsque l’on augmente la taille du cluster en ajoutant de nouveaux noeuds, la plateforme doit déplacer les données pour équilibrer la charge entre les différents serveurs. Une opération de « rebalancing » qui peut prendre plusieurs jours ou semaines, voire des mois entiers, affectant sensiblement les performances du cluster et donc la disponibilité des données (lire L’Object Storage tient-il toutes ses promesses ?).

La technologie de software-defined storage développée par OpenIO ne nécessite pas cette redistribution des données lors du scaling. Une prouesse rendue possible par un placement intelligent des données sur les différents nœuds du cluster, en fonction de leur état à l’instant T – tandis que la plupart des solutions d’Object Storage, par simplicité, distribuent les données de manière purement algorithmique, sans tenir compte de l’état de la plateforme. Malgré les limites de certaines solutions, comparativement au block storage et au file system, l’Object Storage est globalement celui qui scale le mieux.

Bande passante

Il faut ensuite considérer la bande passante atteignable, exprimée en méga/giga/téra bits par seconde. La bande passante est importante lorsque l’Object Storage est exploité comme stockage primaire de données comme de la vidéo, ou pour des datasets destinés à être explorés par des algorithmes de machine learning ou d’intelligence artificielle. Ici aussi, l’Object Storage tire son épingle du jeu, en raison de son design distribué, qui autorise la parallélisation de la récupération des données (sous réserve de disposer de ressources CPU suffisantes pour ne pas brider les performances). Du reste, la performance relative à la bande passante dépend des mécanismes d’optimisation de la lecture de la donnée, de leur gestion côté OS et des mécanismes de cache mis en place.

Les supports de stockage utilisés ont également leur importance : rien n’interdit d’exploiter des disques de type flash dans un cluster d’Object Storage pour booster la distribution de certaines données fréquemment utilisées, tandis que d’autres types de fichiers seront stockés sur des médias moins coûteux. C’est ce que l’on appelle le tiering des données. Soit le fait de positionner les données sur la classe de stockage qui répond le mieux aux besoins de l’utilisateur, en fonction du cycle de vie d’un projet, de l’ancienneté des données, leur fréquence d’utilisation… ceci pour réduire les coûts et améliorer les performances.

Le tiering, que l’on opère à travers les storage policies, peut également impliquer de choisir entre différents niveaux de protection des données, et différentes méthodes. Ainsi, pour des questions de performance, la réplication est parfois préférée à l’erasure coding, qui implique un temps de calcul en contrepartie d’un important gain de place : pour obtenir l’équivalent d’une triple réplication, l’overhead lié à l’erasure coding peut descendre à 1,25.

Latence

Évoquons enfin la latence, probablement l’aspect de la performance le moins bien compris. Il s’agit du temps d’accès au premier octet d’un fichier stocké, autrement appelé le Time To First Byte (TTFB). Ce critère est prédominant pour les fichiers de petite taille. Il devient insignifiant à mesure que le poids du fichier croît, puisque le temps de téléchargement du fichier à travers le réseau excède alors le temps d’accès au premier octet.

Par conséquent, lorsque l’on stocke des bases de données, soit des fichiers de grande taille qui sont accédés par petits blocs et partiellement modifiés (lectures/écritures intensives ou I/O à haute fréquence), la latence a toute son importance. Elle contraint directement la vitesse d’exécution des opérations.

La latence est, à plus forte raison, un enjeu dans le contexte des bases de données distribuées. Les gains de performance directement liées à la latence – des microsecondes – sont alors directement perceptibles dans les applications. Le stockage d’e-mails – de nombreux petits fichiers qu’il faut pouvoir afficher à l’utilisateur quasi instantanément – est un autre cas d’usage pour lequel la question de la latence est capitale. Cette dimension de la performance est étroitement liée aux performances intrinsèques du média de stockage, à l’organisation des disques (type de RAID, baies de disques…) et aux solutions logicielles permettant d’accéder aux données proprement dites (compression de données, déduplication, hiérarchisation, allocation fine et dynamique, etc.). Ici, le block storage ou file system, associés à des technologies hardware telles que le full flash, SSD et NVMe, apparaissent comme les solutions les plus adéquates.

La conception même de l’Object Storage, qui fragmente les fichiers et les distribue sur les différents serveurs d’un cluster implique un temps de calcul incompressible pour rassembler les segments d’un fichier avec de le servir. La performance, en termes de latence, s’exprime alors en millisecondes… contre des microsecondes pour les systèmes de stockage en mode bloc purement axés sur la latence. Et cela fait parfois toute la différence.

Object Storage

Si l’on met de côté la capacité en bande passante, pour laquelle l’Object Storage est doté d’un léger avantage, se révèle donc une fracture nette entre les solutions orientées sur la latence et celles orientées sur la capacité. Les premières sont contraintes par un modèle de redimensionnement type scale-up, tandis que les secondes sont designées pour le scale-out, c’est-à-dire la scalabilité horizontale. Autrement dit, de par leur conception, les solutions orientées sur la latence ne seront jamais adaptées au stockage massif de données. Le coût au Go, d’une part, serait trop élevé. D’autre part, des limites techniques apparaissent vite, obligeant à multiplier les systèmes de stockage en parallèle pour subvenir aux besoins croissants de stockage, alors même que les usages de demain tels que le Big Data, le Machine Learning et les techniques d’intelligence artificielle impliquent de dé-siloter les données des entreprises pour constituer des “data lakes”.

Aussi, il apparaît tout aussi absurde de revendiquer les meilleures performances du marché que de dénigrer celles de solutions concurrentes, qui plus est lorsqu’elles ne s’appuient pas sur le même mode de stockage (block, file ou object storage). La performance d’une solution est le fruit de choix techniques, justifiés par l’ambition de répondre à tels cas d’usage plutôt qu’à tels autres. Et c’est très bien comme ça ! Nous verrons d’ailleurs que pour un même cas d’usage, le stockage associé à une machine virtuelle, il peut être malin d’adopter une stratégie qui combine le block storage (quand la machine est en activité) et l’object storage (pour stocker les images des machines en sommeil).

Learn how to choose the right object storage