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

Dim 4 Mar 11:44:06 CET 2018

On Sun, Mar 04, 2018 at 10:09:22AM +0000, Olivier Duquesne (DaffyDuke) wrote:
> Hello,
[...]
> > 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.

Niveau matos, j'ai pu récupérer gratos du gros legacy, donc je m'en
sers :)

Pas complètement fou avec mes données, je vais quand même y brancher
des disques neufs pour le passage en prod (et accessoirement passer de
disques de 250Go actuels qui seraient déjà trop petits pour mes
données actuelles à du 6, 8 ou 10To, pas encore décidé :) ).

[....]
> > 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.

Xen tourne bien, est officiellement supporté par Stormshield pour les
VMs, j'ai l'habitude de l'utiliser, du coup, clairement, pour changer
de techno à ce niveau il faudrait un très gros argument.

Après, comme on en parlait dans un autre bout de la discussion, j'ai
un peu regardé docker pour certains autres usages, ca me paraissait
élégant (et à priori assez souple en réseau pour faire passer les
dockers par le Stormshield), mais ca nécessite d'installer beaucoup
trop de choses à mon gout sur un hyperviseur (dépendances de
docker.io).
Si quelqu'un a du retour d'infos sur ce point, ca m'intéresse !

> > 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.

A partir du moment où je veux tout mettre sur le même serveur physique
(pour exploiter ses 8 coeurs HT, entre autres....), et où j'ai besoin
d'un Xen pour le Stormshield, l'option FreeNAS en direct sur la
machine, ca devient compliqué / impossible pour moi...

> > > [...]
> > 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.

Le ramfs, c'est un peu indispensable pour ce genre de tests :)
Après, je me suis posé le même genre de questions à propos de la
pertinence tu time cp.... c'est déjà pour ca que j'ai rajouté le sync,
forcément, et après, je me suis dit que c'était au final le plus
proche de ce qui m'intéressait vraiment: des accès disques "normaux"
qui passent par tout le système de caches et de prédiction du kernel.

Sinon, je pouvais aussi faire un bench hdparm (que j'avais à portée de
clavier), pour être très près du matériel, c'est probablement plus
pertinent pour mesurer précisément la perte (ou pas) de performances
d'accès disques quand on passe par Xen en phy ou en file, mais c'est
au final un peu plus éloigné de ma future réalité du quotidien....

Je viens du coup d'aller regarder vite fait la page de iozone, ca a
l'air pas mal du tout comme projet, par contre, faudra que je teste à
l'occasion !

[.....]
> 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.

Ca a effectivement aussi fait partie des arguments: je n'ai besoin que
de NFS (et parfois un peu de sshfs en dépannage pour un portable).
Du coup, FreeNAS est clairement overkill pour moi, et au final me
coûte beaucoup de RAM pour un gain très discutable...

> > 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.

C'est aussi ce qui m'avait un peu fait hésiter à l'époque où
j'étudiais FreeNAS: autant le système de base semble bien maintenu et
facile à mettre à jour, autant j'avais eu un gros doute sur la
maintenance des jails/docks/etc.... disponibles avec (en particulier
délai de réaction pour avoir les correctifs de sécu).

> > > 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" :-)

:)

Alors, déjà, ca n'est absolument pas un "usage de garage": ma salle
seveurs est à la cave ;)

Et si tu veux encore plus de détails, mon hyperviseur actuel sert 24
ethernet physiques, dont plusieurs liens doublés (si une interface
lache, je branche juste sur l'autre et ca repart), 8 interfaces
regroupées en switch (non, vous ne voulez pas savoir que j'en utilise
à peine 2, dont une dans un cas d'usage très discutable :) ), et 1
LACP 4 ports avec le futur serveur :)

Et c'était d'ailleurs aussi une option: garder l'hyperviseur actuel,
mais avec juste le firewall en VM (l'hyperviseur a nettement plus
d'interfaces réseau), et reporter tous les autres usages sur le nouvel
hyperviseur (qui a plus de CPUs), avec donc 4xGb en LACP entre les
deux.

Mais avec plein de VMs potentielles sur le nouveau serveur, j'en
serais arrivé à segmenter bizarre au niveau réseau entre les 2
hyperviseurs, et à avoir au final 24 ethernet physiques qui ne servent
plus vraiment, donc autant éteindre celui là et tout reporter sur
l'autre (avec donc des liens inter VMs qui sont nettement plus rapides).

Ah, et pour ma défense, j'ai quand même un véritable usage de rapidité
disque et réseau: comme l'avait suggéré Francois dans un autre
message, c'est entre autre mes fichiers de bruts de capteurs photo qui
sont stockés sur mon serveur, et qui sont traités sur mon ordi
physique via NFS, donc si je sais avoir des accès plus rapides, ca
accélère grandement le traitement des photos en question :)

Non, en vrai, c'est juste parce que je peux, un peu comme le MX
primaire de mon domaine et l'authentification LDAP :D

> > - 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.