[Liste-clx] Xen et NFSD sont sur un bateau.....

[Olivier Duquesne (DaffyDuke)]

Salut,

J'ai lu rapidement (TLDR sorry).
J'ai l'impression que tu essaye de réinventer freenas non ?
Après, stormshield sur un jail BSD ou un conteneur Docker, je ne sais pas
trop ....

[image: image.png]
[image: image.png]
×
Du coup, là, tu as choisi la solution de François où le NFS est monté
directement dans ton domU c'est çà ?
Tu vas faire de l'aggrégation de port sur le data / NFS du coup ?

A+

Le jeu. 1 mars 2018 à 15:33, VANHULLEBUS Yvan <vanhu_clx at zeninc.net> a
écrit :

> On Thu, Mar 01, 2018 at 02:41:28PM +0100, cacatoes at tuxfamily.org wrote:
> > Ca me rappelle mes tentatives peu fructueuses de faire à peu près la même
> > chose avec LXC, qui est trop "contraint" pour faire tourner NFS sur des
> > conteneurs non privilégiés (qui sont à peu près la norme pour faire
> propre
> > aujourd'hui). Au final, j'étais prêt à faire tourner le serveur NFS sur
> > l'hôte, mais l'hôte dispose aussi d'une façon de partager les répertoires
> > avec les conteneurs (par simple bind). Donc pourquoi faire tourner un
> > serveur NFS sur l'hôte, s'il gère la chose nativement avec des binds
> (côté
> > LAN j'ai des besoins limités donc je m'en tire avec sshfs).
> > Cela dit je pense que ça ne s'appliquera pas à ton cas,
>
> Effectivement, dans mon cas, j'ai besoin d'un vrai solide NFS (ou
> équivalent, d'ailleurs, mais je n'en ai pas trouvé) pour distribuer le
> même /home à des clients physiques sur mon LAN.
>
> Et sshfs dépanne très bien dans certains cas, mais là, il n'est pas du
> tout adapté: j'ai besoin de performances avant tout, sur un LAN déjà
> bien étanche, donc ne nécessitant pas plus que ca de chiffrement super
> fort (après, un truc qui a les performances et la stabilité de NFS, et
> de la sécurité en plus, je suis preneur).
>
>
>
> > et me concernant je
> > n'ai pas non plus fini de travailler la question. Tu me fais d'ailleurs
> > réaliser que je n'avais pas du tout pensé aux dépendances entre les VMs,
> > donc il faudra aussi que je m'amuse à résoudre cette question plus tard.
>
> Et c'est pas simple :)
> Sur mon install actuelle (un autre hyperviseur, et mon ancien serveur
> physique NFS), je gère ca à la main à chaque fois que j'ai besoin de
> redémarrer le firewall, l'hyperviseur ou le serveur NFS.....
>
>
> > Question performance, NFS étant un module noyau, je suppose que
> l'éventuelle
> > perte n'irait pas au delà du coût habituel de la virtualisation du noyau
> que
> > tu fais tourner dans ton XEN, mais je ne connais pas spécialement le
> sujet.
>
> La question principale est là: on perd au niveau de la virtualisation
> du réseau (mais vu mes benchs sur mon hyperviseur actuel qui est
> nettement moins puissant, j'ai une sacré marge tant que mon réseau
> physique est en gigabit), et on perd aussi au niveau des couches de
> gestion disque.
>
> un filesystem sur le Dom0 + un fichier + un filesystem sur le DomU, je
> veux bien croire que c'est plus lent qu'un md (ou un LVM) qui file
> directement du brut à la VM, reste à voir si la perte dans le cas d'un
> md ou un LVM en passe plat est acceptable....
>
>
> Je crois que je vais être bon pour faire un test, tant que le serveur
> n'est pas en prod, pour comparer les 2 (voire les 3, md et LVM dans le
> cas du DomU) et mesurer la différence de perfs....
>
>
>
>
> A +
>
> VANHU.
> _______________________________________________
> Liste-clx mailing list
> Liste-clx at clx.asso.fr
> http://listes.lautre.net/cgi-bin/mailman/listinfo/liste-clx
>
-- 

Oliver Duquesne aka DaffyDuke
http://www.coincoin.fr.eu.org

Excusez les éventuelles erreurs, ce message
a été envoyé depuis un mobile.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/liste-clx/attachments/20180303/580c6c89/attachment-0001.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: image.png
Type: image/png
Taille: 31282 octets
Desc: non disponible
URL: </pipermail/liste-clx/attachments/20180303/580c6c89/attachment-0001.png>