Vidéo: Microsoft Azure OpenDev—June 2017 2025
Comme la mort et les taxes, les défaillances de disque (et le temps nécessaire) inévitable dans Hadoop Distributed File System (HDFS). Dans l'exemple illustré, même si un rack échouait, le cluster pouvait continuer à fonctionner. Les performances en souffriraient car vous avez perdu la moitié de vos ressources de traitement, mais le système est toujours en ligne et toutes les données sont toujours disponibles.
Dans un scénario où un lecteur de disque ou un nœud esclave tombe en panne, le serveur de métadonnées central pour HDFS (appelé le NameNode) découvre finalement que les blocs de fichiers stockés sur la ressource défaillante ne sont plus disponibles. Par exemple, si le nœud esclave 3 échoue, cela signifie que les blocs A, C et D sont sous-répliqués .
Autrement dit, trop peu de copies de ces blocs sont disponibles dans HDFS. Lorsque HDFS détecte qu'un bloc est sous-répliqué, il en commande une nouvelle copie.
Pour continuer l'exemple, dites que le nœud esclave 3 revient en ligne après quelques heures. Pendant ce temps, HDFS a veillé à ce qu'il y ait trois copies de tous les blocs de fichiers. Donc maintenant, les blocs A, C et D ont quatre copies chacun et sont surrepliqués . Comme pour les blocs sous-reproduits, le serveur de métadonnées central HDFS le découvre également et ordonne la suppression d'une copie de chaque fichier.
Un bon résultat de la disponibilité des données est que lorsque des défaillances de disque se produisent, il n'est pas nécessaire de remplacer immédiatement les disques durs défaillants. Cela peut être plus efficacement effectué à intervalles réguliers.
