La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée par: renaud07 le 25 février 2019 à 16:05:33
-
Bonjour à tous,
Mon NAS commençant à être bien plein, je réfléchis à la manière de le faire évoluer. Actuellement il tourne avec 2 HDD de 1 To (principal/sauvegarde) + un SSD de 32 Go avec une debian minimale qui fait tout. Il est sur une base Asrock Q1900-ITX.
Liste des évolutions envisagées :
-ajouter de la RAM (2 Go actuellement, passage à 6 ou 8 Go)
-installer proxmox
-séparer la partie web/DHCP/DNS de la partie NAS (avec openmediavault) + un windows server (pour faire mumuse avec AD et Wsus principalement)
-séparer encore plus les services dans des containers ?
-ajouter des ports SATA (6-8 disques, je pense monter à 6 voir 8 To)
-faire un RAID
-ajouter une carte réseau sur le mini PCI-E (agrégation, 2Gb/s en tout)
Pour les ports SATA, bien que limité par l’unique PCI-E x1, je pense mettre une carte avec 4 ports pour avoir 1Gb/s par disque, vu que les HDD même les plus performants sont aux alentours des 100 Mo/s ça devrait passer, non ? Et vu que tous les ports seront pris, je passerais par l’USB3 pour le système, pas trop pénalisant ?
Pour le RAID, j’hésite. Étant donné qu’on a des HDD de plus en plus gros, le risque de panne lors d’une (longue) reconstruction d’un RAID 5 par exemple n’est pas négligeable. Mais en même temps avec un RAID 50 + l’agrégation y’a moyen de faire quelque chose qui dépote (pour peu que j’investisse aussi dans un switch 10G, ça va revenir cher tout ça :P) J’ai aussi envisagé le RAID 10, moins stressant en cas de reconstruction mais on gâche 50 % de l’espace, c’est dommage au vu de la somme investie. Ou alors je pars sur ZFS, qui est apparemment plus rapide pour reconstruire d’après un test que j’ai lu. BTRFS est hors course puisque le mode RAID5/6 est toujours instable (dommage).
Autre interrogation : l’emplacement des données. Actuellement tout est sur les HDD y compris mes sites web. Hors, je remarque que lors du premier accès, genre après un reboot, que le disque gratte à fond et les sites mettent plusieurs secondes pour s’afficher, ce qui est assez pénible alors qu’on est en local. Du coup, vaudrait-il mieux que je les migre sur le SSD ? Ou c’est simplement dû au fait que le HDD est plein à 90 % (donc fragmentation en hausse) ?
Les sauvegardes : Pour la partie data, ce sera répliqué sur un disque externe (voir dans un futur - probablement lointain - sur un second NAS) par contre je ne sais pas comme organiser la partie VM… Faire une backup sur le SSD est un peu stupide. Leur réserver un dossier sur les HDD me paraît pas mal, seul problème, si j’attache un partage NFS, lorsqu’il faudra sauvegarder OMV, ça va coincer…
Que faire ? Dédier une partition ? (mais pas sûr que je puisse si les disques sont en passtrough sur OMV ?) Utiliser un disque supplèmentaire ?
Voilà voilà, vos avis sont bienvenus :)
-
Ayant un SSD de 120 Go en attente pour ma tour, je l'ai finalement pris pour installer proxmox (et j'ai bien fait de garder l'autre), car les premiers essais ne sont pas très concluants surtout avec les sites web qui sont horriblement lents, mais vraiment, il a fallut que j'attende plus de 3 minutes pour que le backend de prestashop s'affiche !! Pareil avec wordpress qui a mis "que" 30 sec, quelle réactivité ::)
Au début, je pensais que ça venait des droits sur les fichiers (qui ont été modifiés lors de la copie), mais non. C'est d'autant plus frustrant qu'ils sont sur le SSD. J'ai également testé en montant un partage NFS à partir du HDD mais c'est exactement pareil...
Je n'arrive pas à comprendre d'où peut venir cette lenteur extrême... ni la RAM ni le CPU sont saturés pourtant. Maigre consolation, l'affichage de l’accueil des sites est à peu près aussi rapide que d'habitude (qq secondes tout au plus). Ce n'est à priori pas non plus un problème de BDD puisque qu'il n'y a eu aucune erreur lors de la restauration.
Hormis cette anomalie, les VM en elles-mêmes tournent correctement, un boot en 15 sec chrono, pas de ralentissement notable.
-
Pour etre sur d'avoir bien compris :
Avant tu etais sans proxmox (en bare métal) avec 2 GO de ram
Ton second test est avec proxmox et combien de ram ?
Il faut savoir que l'hyperviseur (proxmox) te coute en resources ce qui peut etre anodin sur une machine bien taillée mais catastrophique si tu es deja limité en resource (RAM par exemple)
-
Je n'ai pas encore rajouté la RAM, donc toujours 2 Go. Effectivement proxmox me prend environ 700 Mo et ça swap légèrement sur le SSD.
Je viens de tester en désactivant la swap et en allouant 768 Mo à la VM. Bilan : toujours pareil et la RAM n'est pas pleine (environ 300 Mo utilisés).
Ayant un autre proxmox en service, sur une machine encore plus ancienne (athlon X2 5400B) avec 4 Go de RAM, certes, et 1 Go attribué à la VM, le nextcould installé dessus n'est pas aussi lent... Il faudrait que je compare.
-
Tu ne perds pas qu'en RAM en ajoutant un hyperviseur, tu perds aussi en acces disque si tu n'a pas VT-d activé (tous les proc ne le supportent pas)
C'est pour cela que j'avais abandonné mes N54L pour passer sur d'autres machines, mais je sais que le xeon sur gen8 le supporte
-
Tu ne perds pas qu'en RAM en ajoutant un hyperviseur, tu perds aussi en acces disque si tu n'a pas VT-d activé (tous les proc ne le supportent pas)
C'est pour cela que j'avais abandonné mes N54L pour passer sur d'autres machines, mais je sais que le xeon sur gen8 le supporte
Même avec un passthrough sur un ESXi ?
-
Je veux bien perdre en perfs, mais de là à autant ralentir le truc c'est un peu étonnant quand même.
Enfin, si c'est réellement la cause (le J1900 ne supporte pas le VT-d apparemment), et bien tant pis, je repasserais sur ma bonne vieille Debian qui me donne entière satisfaction (et stabilité) depuis 3 ans, même si pour certaines tâches, j'aurais préféré avoir une interface web conviviale (pour la partie NAS notamment)... Webmin aide bien, mais c'est pas encore ça niveau intuitivité.
-
Même avec un passthrough sur un ESXi ?
Le passthrough sous esxi n'a pas ce probleme effectivement mais la on parle de proxmox
-
Je veux bien perdre en perfs, mais de là à autant ralentir le truc c'est un peu étonnant quand même.
Enfin, si c'est réellement la cause (le J1900 ne supporte pas le VT-d apparemment), et bien tant pis, je repasserais sur ma bonne vieille Debian qui me donne entière satisfaction (et stabilité) depuis 3 ans, même si pour certaines tâches, j'aurais préféré avoir une interface web conviviale (pour la partie NAS notamment)... Webmin aide bien, mais c'est pas encore ça niveau intuitivité.
De memoire avec mon N54L j'avais une degradation terrible, genre 20mo/s sur un HDD, seul le SSD avait une performance qui devenait moyenne
-
Le passthrough sous esxi n'a pas ce probleme effectivement mais la on parle de proxmox
Juste que j’hésitai à passer sous proxmox sur mon N54L pour tester.
Là tu me donnes une bonne raison de ne pas le faire :)
-
De memoire avec mon N54L j'avais une degradation terrible, genre 20mo/s sur un HDD, seul le SSD avait une performance qui devenait moyenne
Pour le coup, en transfert de fichiers sur OMV (avec les disques en passthrough), c'est pas trop dégueulasse, environ 50 Mo/s avec SMB. j'ai à peine plus avec ma debian aux petits oignons (environ 60 Mo/s). Pas testé NFS encore.
EDIT : Me voilà déçu : NFS est moins rapide que SMB (45 contre 55 Mo/s) alors qu'avec ma debian c'est l'inverse, NFS atomise SMB, le gigabit étant "presque" à fond (entre 80 et 90 Mo/s) :(
Je crois qu'on peut dire que ce test de proxmox est un échec. Je tenterais bien ESXi mais si c'est pour aboutir au même résultat...
-
Le passthrough sous esxi n'a pas ce probleme effectivement mais la on parle de proxmox
Proxmox c'est du KVM, je suis surpris que les perfs I/O soient si dégradées : les drivers paravirtualisés (virtio) ont bien été utilisés ?
-
Proxmox c'est du KVM, je suis surpris que les perfs I/O soient si dégradées : les drivers paravirtualisés (virtio) ont bien été utilisés ?
Pour mon cas, oui :
-
Bonsoir,
J’ai enfin décidé de remplacer cette carte mère par quelque chose de plus consistant.
Après recherche, j'ai jeté mon dévolu sur une Asrock B85M Pro4 (https://www.asrock.com/mb/Intel/B85M Pro4/index.asp) que j'ai trouvé pour 30€ avec un défaut néanmoins : 2 pins du socket tordu, d'après le vendeur elle fonctionne quand même et puis ça ne doit pas être bien difficile à redresser. (j'avais aussi une b250m pro4 pour le même prix, mais elle avait 3 pins tordu et 2 emplacements de RAM HS, j'ai préféré ne pas tenter le diable... et la plateforme étant récente j'aurais douillé sur la DDR4 et le CPU)
Elle possède une carte réseau intel et surtout l'activation du VT-d dans le BIOS. Ce qui est apparemment le cas de quasi toutes les CM Asrock et ça c'est cool.
Maintenant, je lui cherche un CPU. Y'a t-il une bonne différence entre les i5 basse conso et les normaux ou c'est juste en charge ? Car vu qu'en théorie un NAS est au repos 90% du temps je me demande si ça vaut le coup de payer plus cher ces déclinaisons au TDP réduit ?
-
Et voici la nouvelle config :
-Asrock B85M Pro4 : 30€
-i5 4590T : 50€
-2x4 Go 1333 Mhz : 20€
J'ai reçu la CM ce matin. Plus qu'à attendre le CPU et la RAM.
Finalement j'ai bien fait de conserver mon Cooler Master TX3 evo, ça ira nickel pour ce CPU :)
-
Après quelques sueurs froides, j'ai réussi à détorde les pins mais ça a été hyper délicat, avec une aiguille et une pince à épiler bien trop grosse pour ce genre de travaux... Y'en a une qui était totalement retournée, j'ai bien cru que j'allais la casser. Si je me suis pas trompé c'est une pin de VSS (AC36), donc pas trop grave (ce qui explique pourquoi ça marche encore).
Au final elles sont de nouveau à peu près dans la bonne position, j'espère que ça ira. Verdict la semaine prochaine (j'ai peur)
-
CPU reçu jeudi. Tout fonctionne. La conso est de 30w au repos et 60w en charge avec toujours 2 HDD, c'est pas mal comparé aux 20w du J1900.
Il n'y a pas non plus besoin de beaucoup de ventilation, je n'ai laissé que le ventilo du boitier et il ne dépasse pas les 50° en charge. Bon point là aussi.
J'ai installé proxmox et openmediamvaut, mais j'ai un petit soucis au niveau des données SMART. Elles ne s'affichent pas en mode scsi ou virtio. En mode SATA oui, mais ce sont des données génériques et non celles du disque.
Apparemment c'est censé fonctionner en SCSI (en mode Virtio SCSI), mais pas dans mon cas... J'avais pensé mettre en passtrough le contrôleur SATA, mais malheureusement tout est géré par le chipset (je croyais qu'il y avait 2 ports géré par un chip dédié car en 3gb/s, mais non).
Lors de l'ajout, y'a un petite erreur mais je ne pense pas que ça influe (ça le fait dans tous les modes) :
qm set 100 -sata1 /dev/disk/by-id/ata-ST1000DM003-1CH162_Z1DB47W0
Use of uninitialized value $volname in string eq at /usr/share/perl5/PVE/API2/Qemu.pm line 70.
update VM 100: -sata1 /dev/disk/by-id/ata-ST1000DM003-1CH162_Z1DB47W0
Use of uninitialized value $volname in string eq at /usr/share/perl5/PVE/API2/Qemu.pm line 148.
-
Après plus ample recherche, il n'y a apparemment pas solution propre pour gérer SMART sans passtrough complet du contrôleur SATA.
Donc je me demandais si ça revenait au même de faire gérer le tout par proxmox directement ? Et dans le cas d'un RAID, est-ce ok pour attacher /dev/mdX à omv et que le RAID soit géré par proxmox ? Pas de risque de perte de données en cas de crash d'un HDD ? Ça ne reviendrait pas un peu à un RAID matériel où le système n'a pas connaissance de ce qu'il se passe en dessous ?
Alors oui je sais que PM ne supporte pas officiellement le RAID, mais on peut quand même l'installer.
-
C'est officiel : Je passe à 2 To de stockage avec 3x1 To en RAID (on commence gentiment :P)
Viens alors le choix de la solution :
-mdadm
-btrfs
-zfs
Étant donné que j'ai déjà expérimenté des corruptions de données avec un HDD qui avait son alimentation qui coupait (mais qui bizarrement ne le fait plus depuis que j'ai échangé les prises d'alim...) je pense plutôt me tourner vers les deux derniers qui intègre des mécanisme de protection contre la corruption, chose que mdadm ne fait pas à priori.
J'ai vu que btrfs avait encore quelques bugs sur la gestion en RAID5/6... dommage. Reste donc ZFS qui est largement éprouvé.
J'hésite à l'installer sur OMV ou remplacer par FreeNAS. Y'a aussi la fameuse contrainte de la RAM... Je ne sais pas trop quoi en penser, certains disent qu'on peut s'en servir quand même mais que les perfs seront moindres, d'autres ne le recommande pas du tout si on a pas une quantité suffisante de RAM.
Sachant que j'ai 8 Go mais que tout ne sera pas alloué (autres VMs oblige).
Des avis ?
-
Étant donné que j'ai déjà expérimenté des corruptions de données avec un HDD qui avait son alimentation qui coupait (mais qui bizarrement ne le fait plus depuis que j'ai échangé les prises d'alim...) je pense plutôt me tourner vers les deux derniers qui intègre des mécanisme de protection contre la corruption, chose que mdadm ne fait pas à priori.
Ah ? J'utilise un pool de 7 disques + un spare en RAID 6 sous mdadm. Il y a vraiment un risque de corruption ?
Sinon, bravo pour l'upgrade :) Perso, j'utilisais OMV, mais j'ai fini par trouver que ça me limitait trop (par exemple, je voulais mon propre postfix, qui rentrait en compétition avec celui installé par OMV). J'ai donc fini par passer sur une Debian Server toute simple :)
-
Ah ? J'utilise un pool de 7 disques + un spare en RAID 6 sous mdadm. Il y a vraiment un risque de corruption ?
Un RAID simple détecte seulement si un disque est ok ou non, mais si par exemple un écrit n'importe quoi mais qu'il ne l’indique pas au système (genre secteurs morts), le disque ne sera pas mis de côté et des données incorrectes seront quand même écrites. C'est ce qu'on appelle couramment la corruption silencieuse.
Un article qui explique bien la chose en comparant ZFS avec un RAID classique : https://www.klennet.com/notes/2019-07-04-raid5-vs-raidz.aspx la partie intéressante est celle-ci :
With silently corrupt data, RAIDZn can reconstruct damaged data, thanks to the extra checksum provided by ZFS. Having no extra help, traditional RAID does not recover from silent data corruption, because it does not know which block to reconstruct.
Sinon, bravo pour l'upgrade :) Perso, j'utilisais OMV, mais j'ai fini par trouver que ça me limitait trop (par exemple, je voulais mon propre postfix, qui rentrait en compétition avec celui installé par OMV). J'ai donc fini par passer sur une Debian Server toute simple :)
Je me demande aussi si je ne vais pas remettre une debian minimale comme avant. Car j'ai par exemple un bug bizarre lorsque j'uploade une image iso un peu grosse par proxmox.
L'écriture ne se fait pas en temps réel mais seulement à la fin. Du coup vu que ça écrit une grosse quantité de données très rapidement sur le disque la consommation de RAM augmente et me fait planter le partage samba... qui revient quelques secondes après mais c'est assez pénible.
-
Mdadm fait un test mensuel sur les disque, qui prend quand même 16 heures pour mon pool de 7 disques de 2 To. À ce moment là, mdadm ne vérifie pas la présence de données corrompues ?
-
Ça vérifie la cohérence des données, oui. Par contre j'ai lu des choses contradictoires sur le fait que ça les répare automatiquement...
-
Visiblement, avec un RAID 6 on peut détecter et réparer les corruptions de données (contrairement aux autres RAID) : https://mirrors.edge.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf (partie 4)
Après, ça "doit" être implémenté dans mdadm (ou non)...