Comment Facebook a déployé RAID sur ses clusters Hadoop

L’année dernière, Facebook a déployé la technologie RAID dans des larges clusters HDFS (Hadoop Distributed File System), afin d’augmenter ses capacités à plusieurs dizaines de petabytes, tout en minimisant la réplication de données. L’équipe d’ingénieurs en charge du projet a dû faire face à de nombreuses difficultés durant l’ensemble du process, notamment au niveau de la corruption des données et des contraintes d’implémentation de RAID au sein de répertoires particulièrement volumineux.

Le réseau social a également fait le choix d’implémenter cette technologie qui comprend le mécanisme dit de « Erasure codes » dans HDFS afin de réduire le niveau de réplication de données dans HDFS.

RAID (Redundant Array of Independent disks)est  un moyen pour stocker les mêmes données dans différents espaces de stockage (redondants), sur plusieurs disques durs.  HDFS est quant à lui le système de stockage primaire utilisé par les applications reposant sur Hadoop. Il fournit un accès haute performance aux données des clusters Hadoop et est ainsi devenu un outil clé des entreprises dans leur gestion des Big Data et de leurs opérations analytiques.

Dans HDFS, un fichier est répliqué 3 fois, ce qui provoque beaucoup de gâchis en matière d’espace de stockage, indique l’équipe d’ingénieurs de Facebook. La technologie RAID HDFS a permis au réseau social de minimiser la réplication de données et réduire par conséquent ce gâchis.

« Avec les déploiements de RAID sur nos clusters HDFS, les niveaux de réplication globaux ont pu être suffisamment abaissés pour représenter des dizaines de petabytes de capacités alors économisés à la fin 2013 », a indiqué cette même équipe dans un billet de blog.

Mais évidemment, ces opérations de déploiements de RAID dans d’imposants clusters de plusieurs centaines de petabytes de données ne sont pas sans difficultés. « Nous souhaitions partager les enseignements appris lors du projet », affirment les ingénieurs de Facebook.

Les enseignements

Lorsque Facebook a déployé RAID en production, il est apparu que l’espace alors économisé était moins important que ce qui avait été prévu. « Après quelques recherches, nous avons décelé un problème dans RAID, que nous avons baptisé le « problème du petit fichier », expliquent-ils.

L’équipe d’ingénieurs a ainsi établi que les fichiers avec 10 blocs logiques offraient la meilleure opportunité pour économiser de l’espace. Plus le nombre de blocs est petit, plus la capacité à pouvoir économiser de l’espace est réduite. Si un fichier comporte moins de 3 blocs, RAID ne parvient pas à économiser de l’espace. Selon les résultats de recherche de l’équipe, plus de 50% des fichiers dans les clusters en production étaient de taille réduite (moins de 3 blocs).

Pour résoudre ce problème, l’équipe IT a regroupé les blocs. « Nous avons développé un répertoire RAID pour cibler ce problème de petit fichier, en nous basant sur une unique observation : dans Hive, les fichiers dans le répertoire enfant ne sont que rarement modifiés après leur création. Ainsi, pourquoi ne pas traiter ce répertoire comme un fichier, avec plusieurs blocs, puis y appliquer RAID ? »

Empêcher la corruption de données

Un autre problème identifié par l’équipe de Facebook est celui de la corruption des données, occasionné par un bug de la reconstruction logique de RAID. Pour empêcher cela, les ingénieurs ont calculé et stocké les checksums CRC des blocs dans MySQL lors du déploiement de RAID pour qu’à chaque fois que le système reconstruit un bloc défaillant, le checksum soit comparé avec celui dans MySQL pour vérifier la justesse des données, a expliqué l’équipe de Facebook.

Autre difficulté, implémenter RAID dans un répertoire avec plus 10 000 fichiers aurait nécessité  une journée entière pour être finalisée. « Si un dysfonctionnement intervient  lors de l’opération RAID, l’ensemble du processus échoue, et le temps CPU utilisé jusqu’alors est gâché », affirment les ingénieurs. La solution ? «  Paralléliser RAID », via un mapper sur les jobs Mapreduce, où chaque mapper prend en compte seulement une partie du répertoire et y applique RAID. « Ainsi, les dysfonctionnements peuvent être encaissés rien qu’en retentant l’opération sur les mappers impactés. Avec MapReduce, nous sommes capables de mettre en RAID un répertoire important en quelques heures », soutient encore l’équipe.

Actuellement, chez Facebook, la technologie RAID sur HDFS est déployée sur une couche séparée, au-dessus de HDFS. Mais cela pose encore quelques problèmes aux ingénieurs : le gaspillage de bande passante et d’ IO disque.  Autre souci identifié : lorsque des fichiers sont répliqués d’un cluster à l’autre, il arrive parfois que les PARfiles ne soient pas déplacés avec leurs fichiers sources. Cela débouche régulièrement sur des pertes de données.   Pour contrer cela, les ingénieurs de Facebook travaillent à ce que le support de RAID soit intégré nativement à HDFS. « Un fichier pourra être RAIDé lorsqu’il est créé la première fois sur HDFS, économisant ainsi des IO disques. »

« Une fois déployé, le NameNode conserve les informations du fichier et programme le block-fixing quand les blocs RAID sont manquants. Le DataNode a la charge de la reconstruction des blocs. « Cela ôte la dépendance de HDFS RAID par rapport à MapReduce », concluent-ils.

Traduit et adapter de l'anglais par la rédaction