Journal un home rapide

Posté par  (site web personnel) .
Étiquettes : aucune
1
11
juin
2009
Habituellement, dans un environnement unix, on travaille avec différente machine dont le home est partagé, le plus souvent en NFS voir en samba.

Pour avoir travailler avec des serveurs de calcul, la différence de performance entre un disque local et serveur de fichier distant est énorme.

Je voulais savoir si il n'était pas possible de trouver une organisation plus performante.

* Une premier solution soit que le serveur de fichier soit la machine de calcul la plus utilisé. Ce n'est pas très souple d'usage.

* Une autre solution serait l'utilisation de cacheFS qui va arriver dans Linux 2.6.30. Il faut voir ses performances réelles, la gestion de cohérence peut fortement diminuer les performances.

* Utiliser un système de fichier distribué comme GFS. Cela semble le plus novateur mais je ne sais pas ce qu'il en est de la maturité de la solution.

* Avoir un home par machine, eux même monter sur le serveur de fichier. La forme du montage changeant en fonction de la machine, mais les nom serait les mêmes (de la forme ~/Machine/). Évidemment, l'admin sys n'a pas intérêt à se tromper et à se mélanger les mount:)

Cette dernière solution semble la plus performante mais à prix assez lourd en terme d'administration système. Mais j'imagine que cela doit pouvoir se scripter.

Votre avis ?

  • # hou la :)

    Posté par  . Évalué à 5.

    le mien après quelques lenteurs réseaux, un plantage serveur interdisant de poser des verrous sur les fichier est un home en local et rsync
    dans le .xsession j'ai
    [ $(hostname) -eq "maMachine" ] && export HOME=/mon/chemin/local/
    startkde

    et j'ai un cron régulier sur un rsync entre mon home local et le home distant.
    On peut même imaginer lors du login une mise à jour du home local par le home distant :).

    Pour ceux qui font du code dans leur home en nfs, et qui oseraient me dire que le login serait lent, qu'ils observent l'impact d'une compilation sur un home en réseau...

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: hou la :)

      Posté par  . Évalué à 3.

      Même pas besoin de faire une compilation dans son home...
      Je me souviens d'un cours à la fac où le prof nous avait demandé de récupérer le tar.gz de Tomcat et de l'installer en local (après décompression, il peut se démarrer en une ligne de commandes).
      sauf que nous avions quasiment tous lancé la décompression dans ... home !
      Ben le NFS a pas supporté et est tout simplement tombé !

  • # DRBD ?

    Posté par  . Évalué à 2.

    Plutôt qu'un système de fichier distribués, cela peut être un volume répliqué, comme DRBD. C'est peut-être moins souple dans la mesure où une seule machine est primaire à la fois, mais c'est très fiable et en performance c'est pas mal non plus.

    Il faut juste faire attention aux reconstructions en cas de coupure réseau...

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: DRBD ?

      Posté par  . Évalué à 4.

      en fait il faut dans ce cas sur le serveur un volume par home, généralement on à souvent un volume pour tout les home
      je n'ai pas testé mais je ne crois pas que drbd gère le fait de repliquer plusieurs disques sur un seul

    • [^] # Re: DRBD ?

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

      Personnellement j'ai été enchanté par DRBD+Heartbeat sur des serveurs Web et mail. Et pour fiabiliser la synchro, je passais par un cable croisé entre les deux serveurs qui se répliquaient.

      Par contre, depuis DRBD 0.8 qui est désormais stable, tu n'es plus obligé d'être dans une configuration maitre/esclave. Cependant, l'utilisation du mode multi-maître impose de passer par un système de fichier clusterisé tel que OCFS2, GFS ou Lustre.

  • # un home rapide

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

    Le home le plus rapide du monde c'est Usain Bolt , tout le monde sait ça !

  • # home local partagé

    Posté par  . Évalué à 4.

    au boulot on a un truc qui ressemble à ta dernière solution.

    on a tous notre home dans le dossier /local_home de notre machine, et il est exporté en nfs et importé via amd dans le /home de toutes les autres machines.
    Cela nous permet d'être performant sur notre machine, et de quand même avoir accès à notre home et à celui des autres depuis les autres machines.

    ça marche pas trop mal je trouve, faut juste faire gaffe aux chemins absolus de type /local_home/xxx/yyy quand on est pas sur notre machine.

    • [^] # Re: home local partagé

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

      L'intérêt d'un jeu comme cela, c'est d'avoir quelques serveurs rapide sur lequel on se connecte. tout le monde à rarement besoin de la cpu en même temps.
      Il est toujours plus facile d'avoir un ou 2 pc rapide pour un projet, qu'une bonne machine par personne(même si la machine en question doit couter à peine quelques jours du coût d'un ingénieur).

      "La première sécurité est la liberté"

    • [^] # Re: home local partagé

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Pareil ici, sauf que le home local de chaque utilisateur est dans SaWorkstation@/blablabla/home/user, qui n'est pas utilisé directement mais exporté par NFS et monté par autofs dans /home/user. Si l'utilisateur se connecte sur SaWorkstation, son /home/user est monté par autofs avec bind, sinon par NFS lorsqu'il se connecte ailleurs.

      Les listes de users, de leurs workstations et de leurs homes sont déclarées dans un annuaire LDAP qui permet une gestion centralisée du bouzin. Pratique et efficace :)

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Le tout est de savoir où est le goulot d'étranglement

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

      En général, tu ne peux pas toucher facilement au cœur d'un réseau, qui est souvent le facteur limitant.

      Et contrairement à ce que tu crois, je ne suis pas sûr que passer d'un réseau 100 mbits, à un 1Gbits change quoi que ce soit sur les latences. De plus, si tu as un seul gros serveur nas pour le FS, il est chargé par plein d'autres machines, espérer avoir les perfs d'un disque local est purement illusoir.

      Il suffit de voir par exemple l'offre avec QOS d'OVH sur ces RPS en iSCSI, qui garantit à peine 10 Mo/s sur des offres chers.

      Concernant le réseau, une augmentation énorme des perfs peut être obtenu en rajoutant une carte réseau sur le serveur NFS et le relier en direct avec le serveur de calcul mais cela ne scale pas terrible. Les structure de réseau en arbre, sont souvent pas terrible niveau perf, à moins d'avoir un énorme switch tout en haut qui centralise tout.

      "La première sécurité est la liberté"

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: infos sur les RPS OVH

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

        Pour apporter une précision sur les RPS d'OVH :

        C'est une offre entre le serveur dédié classique et le VPS (donc le but est de faire pas cher, mais performant) :
        Le serveur existe vraiment physiquement (CM / CPU / RAM) mais l'ensemble du disque (système et données) est sur le réseau.

        Ils ont testé le iSCSI et le NFS mais vont abandonné le NFS (a priori : en iSCSI ils arrivent à appliquer de la QOS suivant le tarif/mois, en NFS non)

        Pour garantir des choses, ils ont découpé les perfs comme ça :
        - offre initiale (prix selon le CPU et la RAM) : garantie 1Mo/s
        - offre premium (prix initial +10€HT/mois) : garantie 4Mo/s
        - offre business (prix initial +20€HT/mois) : garantie 10Mo/s

        Avec le max proposé (10Mo/s) on arrive quand même à 80Mb/s ce qui est proche de la saturation de la carte réseau 100Mb/s (pour ce type d'offre low-cost ils ne mettent naturellement pas de Gb).

        Ce qui est intéressant :
        Ils avaient beaucoup d'espoir pour le NFS (on est en direct sur le FS hote ZFS, et on peut monter le disque depuis plusieurs machines) mais ce n'est pas facile de gérer la mutualisation. Finalement iSCSI l'a emporté.

        P.S je n'ai pas d'actions chez eux, mais je trouve intéressant de suivre l'évolution de cette offre "hybride".

    • [^] # Re: Le tout est de savoir où est le goulot d'étranglement

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

      Un autre problème c'est que modifier le matos réseau ça coute du temps et de l'argent tandis que changer la config des machines, suivant de quoi tu part, ça coute du temps.

      De plus, dans le cadre évoqué de serveurs de calculs, le réseau doit souvent être partagé entre les transferts de données via NFS et ceux effectués directement par l'algorithme pour la parllélisation du calcul.
      Si une grosse majorité des données snt disponibles en local, on limite les transfert NFS et donc on libère de la bande passante pour MPI par exemple.

      Donc le choix entre améliorer le réseau ou la localisation des données dépend de ce que tu fais. Dans mon cas par exemple, sur le petit cluster ou j'ai travaillé, j'ai gagner énormément en perf lorsque j'ai modifié un programme parrallèle pour qu'il utilise les disque dur locaux plustôt que le NFS pour le stockage des données.

      Chaque machine accede dans plus de 80% des cas à ses données donc il reste moins de 20% du temps ou les données circules sur le réseau qui est quasiment entièrement libre pour les message de MPI.

      Tout ça pour dire que le réseau est loin d'être la seule solution de même que le choix entre :
      - données centralisées et cache local sur les machines ;
      - donnée réparties et système d'accès à distance.

      Il n'y a pas de solution miracle et ça dépend vraiment des applications qui tournent sur le système.

  • # Je n'ai pas le temps je fileSystem.

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

    Si tu cherches un home pressé...

  • # GlusterFS

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

    le projet manque un peu de maturité, mais semble vraiment prometteur.
    http://www.gluster.org/

Suivre le flux des commentaires

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