HDFS n'est pas un système de fichiers à usage général (general purpose filesystem en anglais) ce qui signifie qu'il n'est pas prévu pour servir de système de fichier de tous les jours (et surtout pas pour une base SQL) où on installe un OS, stocke ses documents etc. Il a été conçu uniquement pour fournir un bon débit en lecture/écriture à des applications lisant des fichiers très volumineux en mode batch (au hasard des applications MapReduce).
En pratique, ça se manifeste de la manière suivante :
- Un fichier consomme au moins un bloc dans HDFS. La taille par défaut est de 64Mo (et HDFS n'est pas conçu pour faire descendre cette limite très bas), ce qui fait qu'un fichier de config de 2Ko va te bouffer 64Mo.
- Les temps d'accès sont élevés.
- Pour assurer la fiabilité, HDFS utilise de la triple réplication par défaut. Donc tu n'auras qu'un tiers de ton espace total disponible. C'est certes configurable mais enfin...
- Il n'est pas possible de monter un système de fichier HDFS (il existe certes un driver fuse mais c'est loin d'être idéal pour les raisons expliquées ci dessus)
- Il a été conçu pour fonctionner sur des serveurs moyen de gamme avec une certaine quantité de RAM.
Comme tu t'en doutes sûrement, la solution la plus fiable est celle que tu emploies actuellement : laisser la base de données sur le NAS. N'importe quelle solution à base de raspberry sera beaucoup beaucoup moins fiable et performante (les performances en lecture des cartes SD sont général pourries, elles sont beaucoup moins fiables qu'un HDD etc.), mais je suppose que tu fais un peu ça pour t'amuser :-)
Il existe des systèmes de fichiers distribués (qui permettent donc de mutualiser l'espace de stockage de plusieurs machines) : Ceph (surement un des plus à la mode), Lustre, GlusterFS, et je pense que c'est ce qu'il faut que tu utilises. J'aurais tendance à te recommander Ceph. Par contre, je ne sais pas si il fait du RAID 5 (je pense qu'il fait sa cuisine en interne pour la réplication de données). Je sais pas trop si Ceph va bien se comporter sur des raspberry, parce que là encore c'est plutôt prévu pour tourner sur des grosses machines.
drdb n'est pas adapté dans ton cas, ça te fera l'équivalent d'un RAID 1 en réseau et non pas d'un RAID 5. Si tu veux vraiment faire un RAID 5 distribué (et sur un réseau ça va avoir des performances vraiment pourries, déjà que ça impacte les performances en local) à titre expérimental, tu peux jouer avec nbd (network block device) qui va te permettre d'accéder à des block device (par exemple une partition sur les cartes SD) distants. Il te restera plus qu'à faire ton RAID 5 dessus. Par contre, tu ne pourras accéder au RAID 5 que depuis un seul raspberry (les autres seront de bêtes esclaves).
# HDFS n'est pas adapté dans ton cas
Posté par X345 . En réponse au message HDFS où comment faire un espace de stockage décentralisé en cluster (genre un raid5). Évalué à 3.
HDFS n'est pas un système de fichiers à usage général (general purpose filesystem en anglais) ce qui signifie qu'il n'est pas prévu pour servir de système de fichier de tous les jours (et surtout pas pour une base SQL) où on installe un OS, stocke ses documents etc. Il a été conçu uniquement pour fournir un bon débit en lecture/écriture à des applications lisant des fichiers très volumineux en mode batch (au hasard des applications MapReduce).
En pratique, ça se manifeste de la manière suivante :
- Un fichier consomme au moins un bloc dans HDFS. La taille par défaut est de 64Mo (et HDFS n'est pas conçu pour faire descendre cette limite très bas), ce qui fait qu'un fichier de config de 2Ko va te bouffer 64Mo.
- Les temps d'accès sont élevés.
- Pour assurer la fiabilité, HDFS utilise de la triple réplication par défaut. Donc tu n'auras qu'un tiers de ton espace total disponible. C'est certes configurable mais enfin...
- Il n'est pas possible de monter un système de fichier HDFS (il existe certes un driver fuse mais c'est loin d'être idéal pour les raisons expliquées ci dessus)
- Il a été conçu pour fonctionner sur des serveurs moyen de gamme avec une certaine quantité de RAM.
Comme tu t'en doutes sûrement, la solution la plus fiable est celle que tu emploies actuellement : laisser la base de données sur le NAS. N'importe quelle solution à base de raspberry sera beaucoup beaucoup moins fiable et performante (les performances en lecture des cartes SD sont général pourries, elles sont beaucoup moins fiables qu'un HDD etc.), mais je suppose que tu fais un peu ça pour t'amuser :-)
Il existe des systèmes de fichiers distribués (qui permettent donc de mutualiser l'espace de stockage de plusieurs machines) : Ceph (surement un des plus à la mode), Lustre, GlusterFS, et je pense que c'est ce qu'il faut que tu utilises. J'aurais tendance à te recommander Ceph. Par contre, je ne sais pas si il fait du RAID 5 (je pense qu'il fait sa cuisine en interne pour la réplication de données). Je sais pas trop si Ceph va bien se comporter sur des raspberry, parce que là encore c'est plutôt prévu pour tourner sur des grosses machines.
drdb n'est pas adapté dans ton cas, ça te fera l'équivalent d'un RAID 1 en réseau et non pas d'un RAID 5. Si tu veux vraiment faire un RAID 5 distribué (et sur un réseau ça va avoir des performances vraiment pourries, déjà que ça impacte les performances en local) à titre expérimental, tu peux jouer avec nbd (network block device) qui va te permettre d'accéder à des block device (par exemple une partition sur les cartes SD) distants. Il te restera plus qu'à faire ton RAID 5 dessus. Par contre, tu ne pourras accéder au RAID 5 que depuis un seul raspberry (les autres seront de bêtes esclaves).
Bref, je te conseille Ceph. Et bon hack :-)