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

Dim 4 Mar 11:09:22 CET 2018

Hello,

Le dim. 4 mars 2018 10:52, VANHULLEBUS Yvan <vanhu_clx at zeninc.net> a écrit :

> On Sat, Mar 03, 2018 at 12:29:14PM +0000, Olivier Duquesne (DaffyDuke)
> wrote:
> > Salut,
> >
> > J'ai lu rapidement (TLDR sorry).
> > J'ai l'impression que tu essaye de réinventer freenas non ?
>
> Dans mon idée d'origine (où je gardais l'hyperviseur actuel à coté, et
> où le nouveau serveur ne faisait que NAS + quelques services), j'avais
> regardé du coté de FreeNAS, et c'était clairement un candidat.
>

Dans mon cas j'étais parti de rien avec un HP micro serveur sur une
suggestion de @aifsair, classique plus facile de faire un nouveau projet
que maintenir du legacy.

>
> > Après, stormshield sur un jail BSD ou un conteneur Docker, je ne sais pas
> > trop ....
>
> Et c'est effectivement quand je me suis dit que c'était plus pertinent
> de faire tourner mon hyperviseur directement sur cette machine (qui
> doit donc aussi héberger le NAS), et qu'il y allait y avoir entre
> autres une VM Stormshield, que Xen est revenu dans l'histoire...
>

Oui xen a une assez bonne réputation. Il est probable qu'AWS y soit pour
quelque chose.

>
> A un moment, j'ai aussi réfléchi à avoir un FreeNAS en VM, mais on en
> revient à la même problématique de départ de pertes de performances.
>

Ah moi dans le use case je ne l'imaginais pas en vm parce que pour y mettre
des jails c'est moins élégant.

>
>
> > [...]
> Entre temps, j'ai fait un peu de benchs vite fait des perfs disque
> depuis le Dom0 ou un DomU (file: et phy:md).
> Mon système de mesures était un peu simpliste: quelques gros fichiers
> randoms de 100Mo  en RAMFS, un time (cp fichiers dest && sync), et une
> calculatrice pour en déduire un débit :)
>

Ahah autant le ramfs n'est pas si simpliste que ça autant un time cp est
peu pertinent à cause des caches disques et autres algo de predictions.
Essaye iozone qui est super simple. Il en existe plein d'autres.

>
> Et au final, j'ai été assez bluffé par les perfs de Xen: en file:, je
> note environ 10% de pertes de perf, et encore, je ne suis pas tout à
> fait certain que ca ne soit pas une subtile variation de vitesse du
> disque à cet endroit là, et en phy:md, par rapport à la même partition
> montée sur le Dom0, les éventuelles différences de perfs sont trop
> fines pour être clairement mesurables par ma méthode !
>
>
> Du coup, je commence clairement à pencher pour un /dev/md sur le Dom0
> qui est directement transmis à une VM qui fera serveur NFS.
> Et je vais quand même passer par LVM au niveau de la VM, pour une
> toute autre raison: j'ai commencé à regarder les possibilités
> d'utilisation d'un SSD en tant que cache en lecture, et j'aimerais
> bien me garder l'option de lvmcache :)
>

Oui je faisais ça chez Atos il y a des années, mais je n'ai pas retouché à
xen depuis.

>
>
> Je pourrais aussi repartir sur un FreeNAS, c'est un peu tentant, mais
> en vrai dans mon cas, je n'aurai pas tellement l'usage de ZFS, alors
> que, coté perfs, faudrait que j'alloue entre 6 et 10Go de RAM au
> FreeNAS, alors que la même quantité de disque servi en ext4 ne me
> nécessitera probablement pas plus de 2-4 Go (et encore....).
>

C'est vrai zfs demande beaucoup de RAM. Moi même j'ai dû faire une
extension à force d'ajouter des jails. Mais l'intérêt n'est pas que dans
zfs, le côté cool est que freenas gère le partage d'un même volume en multi
protocol : NFS, iscsi, appletalk.... Mais tu n'en as peut-être pas besoin.

>
> Et puis, un pool de serveurs Debian, ca reste assez confortable à
> maintenir à jour :)
>

Oui maintenir un freenas c'est une case à cocher mais mettre à jour les
images des jails et aussi chiant que des images Docker. Et je n'ai pas
encore vu d'équivalent à clair pour Jail.

>
> > Tu vas faire de l'aggrégation de port sur le data / NFS du coup ?
>
> Je n'ai pas compris la question :)
>
> Tu parles de LACP ?
> Si c'est ca, la réponse est non:
>

Oui je pensais à ça. Je suis épaté par le détail ci dessous pour un usage
"de garage" :-)

>
> - pour les VMs en interne, le lien est "aussi rapide que possible"
>   avec Xen, j'ai déjà testé sur mon hyperviseur actuel, et entre 2 VMs
>   je sais largement dépasser le Gb/s avec un seul lien.
>
> - sur mon LAN, je n'ai pas de switch gérant LACP, et surtout j'ai un
>   seul gros consommateur, actuellement en Gb/s. Par contre, je
>   commence à regarder du coté des interfaces 10Gb/s, Asus et Gigabyte
>   en ont sorti des pas trop chères (basées sur le même chipset
>   supporté apparemment sur les noyaux Linux récents), et Asus a aussi
>   fait un switch avec 2 liens 10Gb/s+8 liens Gb/s, qui serait parfait
>   dans mon cas, et qui est là aussi pas trop cher (pour du 10Gb/s...).
>   C'est coté serveur que je dois voir ce que je peux brancher (chassis
>   rackable, carte mère serveur, connectiques déportées, etc....).
>
>
>
> A +
>
> VANHU.
>
> >
> > 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.
>
>
> _______________________________________________
> 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/20180304/f637e873/attachment-0001.html>