Bonjour à tous,
Je reviens poser mes petites questions sur THE LINUXFORUM FR …
J'aimerai créer un cluster de stockage réseau non conventionnel. Présenter mon architecture sera bcp plus simple.
Aujourd'hui j'ai :
- 1 nas avec 2 disques en RAID 1 qui héberge un site web et une base mysql.
- 3 raspberry pi qui font chacun fonctionner des services et qui interroge la base mysql présent sur le nas
Mon problème c'est que j'use mon NAS avec toutes ces requêtes. Mon NAS est avant un espace de stockage et ça m'embête de me dire que 100 fois/minutes les disques soient sollicités à cause de la base mysql et des requêtes en webservices.
Ce que j'aimerai faire :
- 3 raspberry possédant chacun une carte SD de 4Go
- mutualiser de l'espace de stockage présent sur chacun de mes raspberry pour former un raid 5, accessible en lecture/écriture par tous les raspberry.
- Faire un cluster avec des noeuds actifs/actifs qui hébergeront des services systèmes capable de migrer sur un autre noeud en cas de défaillance matériel/système
- Le cluster possèdera une VIP qui permettra aux services d'accéder à la base mysql et la VIP me permettra d'accéder au site web
Côté configuration du cluster et gestion des services, je sais faire.
Par contre comment faire pour mutualiser de l'espace disque de chacun des serveurs pour former un espace de stockage commun sans passer par un SAN/NAS ??
Au travers de mes recherches sur les clusters j'ai trouvé drdb qui est une architecture de stockage distribuée, permettant la réplication de périphériques de bloc (disques, partitions, volumes logiques etc…) entre des serveurs. Ca conviendrait ?
Quand est il du comportement de la base mysql ? si le noeud 1 démarre ce service, puis que ce même service migre sur un autre noeud ? Est-ce que je ne risque pas d'avoir des problèmes de corruption de base de données ?
J'ai trouvé aussi la solution HADOOP semble être bien complexe à mettre en oeuvre, surtout pour des serveurs si peu puissant car c'est en java :-/
Ah oui une dernière question. Existe t'il l'équivalent de luci/ricci sous debian ? Gérer une solution en cluster via une interface graphique c'est quand même nettement plus cool. A moins de passer sous centos…
Merci d'avance pour vos réponses :-)
# une piste pour la base de données
Posté par NeoX . Évalué à 2.
à l'epoque ou je m'etais posé la question,
il fallait chercher autour du mode "master/master" pour mysql et
il faillait jouer des indices ou index je ne sais plus pour que le premier serveur ait les index impairs, le 2e serveur les index pairs.
mais j'espere qu'à l'age du cloud il y a des modes cluster pour mysql
# HDFS n'est pas adapté dans ton cas
Posté par X345 . É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 :-)
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par popof . Évalué à 1.
Merci pour ta réponse.
OK je comprends bien, c'est très clair. Et oui, c'est avant tout pour m'amuser. C'est de la geekerie à l'état pure :-)
Admettons que le Raid1 me suffise et que je base mon cluster sur 2 noeud uniquement, (donc 2 RPI, et 2 SDcard uniquement), drbd pourrait être suffisant ?
En fait, tout bien réfléchi, je ne pense pas utiliser la SDcard pour faire le Raid ce sera uniquement le système de fichier. Trop dangereux, ca m'est arrivé une bonne dizaine de fois d'avoir, suite à un reboot sauvage, flingué mon système de fichier et du réinstaller le système.
Je pense plutôt mettre une petite clé usb de 8Go, sur chacun des raspberry, faire du LVM et faire la réplication du système de fichier dessus.
Est-ce que dans ce cas drbd serait la meilleure solution ?
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par X345 . Évalué à 1.
Cette dernière solution que tu proposes me parait plus raisonnable (i.e. y'a plus de chances qu'elle fonctionne de manière à peut près fiable). Drdb sera adapté pour faire un "RAID1 réseau" entre tes deux clés USB sur deux rapsberry différents.
En plus drdb sera surement beaucoup plus léger que Ceph.
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par lenod . Évalué à 1.
Ça avait l'air marrant comme ça, et j'aurai bien fait la même chose, mais d'après la documentation de ceph :
Donc un raspberry c'est peut-être un peu limite (enfin, on peut avoir de bonnes surprises).
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par popof . Évalué à 1.
En fait j'avais pensé à ça :
http://maniaque.org/2013/01/cluster-mysql-drbd-heartbeat
http://docs.chezwam.org/docs/2010/05/21_replication-mysql-avec-drbd.html
Techniquement ça a l'air de tenir la route, après faut voir à l'usage …
De toute façon, je vais essayer sur 2 raspberry et sur 2 cubieboard.
Le plus gros problème (de par l'expérience que j'ai du raspberry), ce n'est pas la mise en cluster des services (surtout si c'est pour faire la répartition de charge), c'est l'utilisation de mysql qui prend 60% de la RAM.
A voir…
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par mururoa69 . Évalué à 1.
Imho tu n'uses pas ton nas. Les disques ça tourne en permanence et c'est fait pour ça.
Par contre si tu arrives à faire ce que tu veux, là tu vas vraiment user tes cartes SD avec leur mémoire flash qui ne sont pas -du tout- faites pour ça.
Et l'idée d'avoir une sorte de filesystem partagé sur des devices qui ne seront vu que par une machine à la fois et sans quorum c'est, heu, original. Ça devrait être -légerement- compliqué de gérer la perte d'une SD et/ou d'une machine.
[^] # Re: HDFS n'est pas adapté dans ton cas
Posté par popof . Évalué à 0.
lol j'ai acheté les cubieboard, on verra bien si ça marche et surtout si ça s'avère être une solution stable et pérenne…
En fait l'idée de supprimer la base de données sur mon nas synology ds412j c'est surtout de récupérer de la mémoire. Il suffit que je télécharge des fichiers depuis le "download manager" et là les requêtes http/mysql deviennent hyper lente… C'est la vrai raison.
j'ai l'impression (je dis bien c'est du feeling hein), "temps de travail/criticité/disponiblité/reprise sur erreur", avoir un filesystem partagé me semble plus simple à mettre en place qu'un cluster mysql…
Pour drbd, rien ne m'empêche de rajouter un 3ème noeud pour avoir un quorum de disque ? faut juste rajouter 80€pour une 3ème cubieboard + sd + clé usb :-)
Pour la perte éventuelle d'une carte SD, une fois mon noeud Y préconfiguré, j'en fais une image de secours. Du coup il me suffira de connecter la SD à mon ordi et recopier l'image de secours. Les données sensibles étant sur la clé usb…
Ouais dis comme ça ça a l'air cool mais à maintenir… on verra dans le temps lol
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.