Bonjour, je suis à la recherche d'une solution technique permettant de partager un système de fichiers entre plusieurs machines et tolérant aux pannes de nodes. je reprends ici un bout de commentaire posté précédemment sur la dernière news samba :
Dans une plateforme d'hébergement web assez costaude, soient un load balancer, des frontaux, des serveurs applicatifs, et des serveurs de bases de données. On peut sans problème dupliquer les reverse proxy en frontal, ainsi que les serveurs de BDD, qui sont équipés de mécanismes de réplication performants. Le problème se situe au niveau des serveurs applicatifs.
Certaines applications (PHP par exemple) peuvent générer des pages à la volée (comme sur DLFP). Ces pages, une fois créées, ne doivent pas l'être de nouveau sur les jumeaux du serveur. Bien sûr on pourrait coder les sites en fonction, mais on souhaite être totalement indépendant de la plateforme. Il faut donc partager le système de fichiers afin de synchroniser ces données. Pour l'instant on monte un NFS à partir d'une autre machine, mais il faut bien avouer que c'est cracra et que c'est pas très "haute disponibilité". Je cherche une solution du genre DRBD, avec écriture sur tous les nodes.
On m'a répondu SAN et baie de disque partagée avec OpenGFS. Mais ce n'est pas ce que j'attends : je chercher un solution entièrement logicielle.
Existe-t-il un système de fichier distribué tolérant aux pannes de nodes permettant l'accès à plusieurs nodes en écriture ? j'ai beau avoir fait des heures de google, je n'ai rien trouvé.
Que vaut OpenGFS du point de vue stabilité et performance? Est-il mature?
Je suis intéressé par tout retour d'expérience dans ce domaine. Merci! :)
Forum Linux.général File system distribué pour cluster
7
fév.
2005
# NFSv4
Posté par Ramón Perez (site web personnel) . Évalué à 3.
La nouvelle version de NFS, NFSv4 permet de faire de la réplication et migration de serveurs.
C'est encore en développement sur Linux mais sur d'autres Unix ça fonctionne. Sur Solaris par exemple :
http://iforce.sun.com/protected/solaris10/adoptionkit/tech/nfsv4.ht(...)
# LUSTRE?
Posté par guignome (site web personnel) . Évalué à 1.
[^] # Re: LUSTRE?
Posté par Arachne . Évalué à 2.
# Petite question ...
Posté par harbort1 . Évalué à 0.
Parce que j'ai souvent entendu parlé de base de données avec les propriétés dont tu parles. Y en a même des libres ! (par exemple, Mnesia, base de donnée liée au langage Erlang a ces caractéristiques)
D'autre part, quand on en est à vouloir de la haute performance, distribuée et tout et tout, je me dis qu'un peu d'abstraction aide bien les choses ... et donc il me semble logique de recourrir à une base de donnée plutôt qu'à un système de fichier (qui peut être vu comme une implémentation particulière d'une base de donnée).
Enfin voilà, tout ça pour dire que le problème est peut-être mal posé (enfin, sinon faudrait me dire qu'est-ce qui nécessite absolument l'utilisation d'un système de fichier) et que regarder du côté des base de données me semble préférable (oui, je sais, je radote :P )
[^] # Re: Petite question ...
Posté par Arachne . Évalué à 2.
Dans le texte : "Bien sûr on pourrait coder les sites en fonction, mais on souhaite être totalement indépendant de la plateforme."
Et je n'ai pas encore vu d'apache retirer les fichiers php à traiter d'une base de données.
[^] # Re: Petite question ...
Posté par harbort1 . Évalué à 1.
J'avoue que je ne sais pas dans quelle mesure c'est facile à faire, mais n'importe quel CMI récupère ses pages HTML dans une base de donnée déjà !
Ensuite, vu la modularité de Apache, écrire un module qui permette de récupérer un fichier non pas dans un système de fichier mais dans une base de donnée ne me semble pas une tâche insurmontable ! Si les quelques connaissances que j'ai ne sont pas trop fausses, il est possible d'écrire un module qui récupère l'adresse de la page oueb demandée et qui fournit à Apache la page qui correspond.
# un truc gruik qui marche pour de vrai.
Posté par PLuG . Évalué à 2.
et qui a l'avantage d'etre simple et non intrusive (pas de driver dans le kernel ...,
tout en mode user).
C'est la réplication via un process genre RSYNC ou UNISON.
les 2 sont scriptables, unison a l'avantage de savoir detecter dans quel sens il faut repliquer les données.
Inconvenients:
-> pas intégré au systeme de fichiers
-> pas de garantie pour le process qui ecrit que tout sera répliqué dans un temps donné.
-> comment on le déclenche ? cron toutes les 5 minutes ? process daemon qui lance a intervalles réguliers ? evenements (fam ...) sur le fs ?
Avantages:
-> marche tout de suite,
->cross plateforme (tous unix et possible sous windows mais marche moins bien)
-> simple a mettre en place.
en pratique j'ai plusieurs clusters qui marchent comme cela apres avoir testé drdb et d'autres trucs. j'ai opté pour un "daemon" que j'ai ecrit en perl et qui lance la réplication entre 2 sleep parametrables en durée. Ca marche plutot bien, surtout si les ecritures sont "relativement" rares et que l'absence potentielle d'un fichier n'est pas grave.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.