Forum général.cherche-logiciel Système de fichier distribué 'rapide'

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
1
3
fév.
2017

Bonjour,

J'ai actuellement 3 serveurs hébergés chez OVH et j'utilise docker sur ces machines. J'aimerai afin d'avoir de la redondance ou à défaut de la répartitions des applications avoir un de mes systèmes de fichiers répartis sur les deux serveurs.

J'ai testé glusterfs qui fonctionne très bien sur le papier et qui me permettait d'avoir mon système de fichiers répliqué sur deux des serveurs, le troisième n'étant que consommateur. J'ai vite abandonné l'idée, car le système de fichiers était beaucoup trop lent.

En effet lors que je faisait rien qu'un chown -R sur les fichiers, la mise à jour prenait une dizaine de minutes au lieu d'une seconde ou deux. De la même manière l'accès par php aux fichiers sur le disques était lent, et causé des echecs d'affichage de page. Toutes mises à jour de plugins, et de wordpress échoué à cause de timeout. Je n'ai pas trouvé de bonnes options me permettant d'optimiser les temps de réponses.

Bref, je me suis dit que ce qui me conviendrai ce serait soit :

  • un système de fichiers répliqué ou la lecture est uniquement local, et l'écriture est désynchronisé. Normalement je peux me débrouiller pour que les applications répartis sur les deux serveurs puisse interrogé des dossiers différents, mais qu'en cas de panne de serveur, je puisse rapidement reprendre sur le second serveur. OU
  • un système de fichier répliqué mais où toutes les requêtes passe sur le serveur primaire (lors n'étant qu'une réplication) et que les performances soit du coup proche de NFS. De la même manière la réplication peut être asynchrone.

Avez vous connaissance d'un système de fichiers distribué tel que décrit ? L'idée est que je n'ai que 3 serveurs d'une puissance toute relative (2 kimsufi, 1 vps) et que je ne veux pas d'une usine à gaz.

  • # pas simple avec ton infra

    Posté par  . Évalué à 2.

    un système de fichier répliqué mais où toutes les requêtes passe sur le serveur primaire (lors n'étant qu'une réplication) et que les performances soit du coup proche de NFS. De la même manière la réplication peut être asynchrone.

    bascule à chaud ou non ?

    si tu veux une bascule à chaud, il faut une VIP qui va passer de primaire sur secondaire ainsi quand S1 sera down, S2 prend le relais et tes applis continuent d'interroger l'IP VIP

    mais ca ne pourra pas se faire avec du kimsufi qui ne peuvent pas partager un pool d'IP failover.

    si tu veux faire un systeme "maitre/slave" tu peux simplement faire :
    - un rsync de temps en temps
    - un disque en DRBD : replication de niveau bloc

    le probleme commence à arriver quand tu veux que les 2 serveurs ecrivent tous les deux dans l'espace commun et c'est qu'entre en jeu les systemes de fichiers distribués
    - glusterfs
    - ceph

    pour la performance il faut aussi que tu regardes les bandes passantes alloués en "interne" à tes machines.
    chez kimsufi c'est un reseau à 100Mbps au cul de chaque machine
    donc si tu as en plus un peu de trafic, ben il n'en reste pas beaucoup pour la replication de données entre les machines.

    et evidemment les performances des disques et CPU des machines
    car c'est quand meme cela qui va impacter aussi les performances

    sinon sur internet, il y a des comparatifs de performances hadoop/ceph/glusterfs et ca semble glusterfs qui sort gagnant (sur leur infra)

    on trouve aussi des tunings comme les desactivations des caches, la gestion des buffers…

  • # Pas le bon matos

    Posté par  . Évalué à 1.

    Au vue de ce que tu veux faire tu n'as pas l'offre adéquate…
    Il va plutôt falloir regarder du côté de chez OVH avec son offre vRack par exemple qui te permettrait de mettre en place un lan privé entre tes serveurs afin de réaliser ton FS distribué.
    D'autres hébergeurs proposent peut-être des solutions similaires histoire de comparer les prix ;)

  • # .

    Posté par  . Évalué à 1.

    Salut,

    J'ai fait quasiment la même chose que toi avec 4 conteneurs LXC (sur 3 dédiés OVH et un petit dédié Online). Ça me permet d'avoir des serveurs FTP en "master-master". J'en ai 3 qui sont à la fois server glusterfs et client glusterfs, le quatrième étant uniquement client. J'ai constaté comme toi que les performances étaient très mauvaises sur celui qui est uniquement client. Par contre elles sont tout à fait correctes sur les 3 autres qui sont aussi serveur. Enfin en tout cas à avec un client FTP je n'ai constaté aucune différence. Quand tu as fait ton test, c'était sur l'un des 2 serveurs ou sur le client ?

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 2.

      Sur les deux serveurs. Le client était client mais n'utilisait pas encore les données.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.