Le Blog Utux

Je possède depuis plus de 2 ans un HP ProLiant MicroServer Gen8 qui tourne sous FreeNAS et fait office de NAS comme son nom l'indique. Équipé d'un Celeron G1610T, il tourne sous FreeNAS a offert des performances correctes jusqu'à ce que je décide un jour d'activer le chiffrement des disques. Ce processeur ne supporte pas les instructions AES-NI, donc le chiffrement et déchiffrement sont fait de manière logicielle, c'est lourd.

Pour y remédier il est possible de changer le CPU et se tourner vers des Xeon un peu plus costauds. J'ai donc commandé un E3-1260L (4c/8t @2.40Ghz). Niveau TDP on passe de 35W pour le Celeron à 45W ce qui reste correct pour le refroidissement semi-passif, surtout que le CPU ne tourne pas à 100% en permanence. Ce CPU offre 8 cœurs logiques, le turbo, et les instructions AES-NI ce qui devrait booster FreeNAS et les jails FreeBSD que je lui fais supporter.

En attente de réception du CPU !

Un seul serveur n'était pas suffisant pour moi, j'en ai donc acheté un deuxième. J'ai choisi un NUC6CAYH à 122€. Pour ce tarif on a droit à un mini-PC équipé d'un Intel Celeron J3455 (4@1,5GHz) sans RAM ni disque dur.

J'ai ajouté 8GB de RAM (Kingston KVR16LS11/8 pour 72€) et un disque dur 2,5" de 500GB que je stockais dans un placard. A propos de la RAM, attention car le NUC ne supporte que 8GB maximum et il faut respecter la QVL sous peine d'avoir un warning impossible à désactiver à chaque boot.

Matériel

Comme indiqué précédemment, ce NUC vient avec un Intel Celeron J3455, avec 4 vrais coeurs à 1,5GHz et un turbo boost à 2,3GHz. Le tout contenu dans un TDP de 10W, gravé en 14nm et avec les instructions de virtualisation et quelques features telles que AES-NI. Pour ce prix, et pour un usage modéré, c'est très intéressant. L'ensemble n'est pas fanless, mais grandement silencieux à l'usage.

Peut-on se risquer à parler d'un Raspberry Pi killer? Certainement pas, étant donné la gamme de prix et de matériel complètement différents. Mais il faut constater qu'un usage serveur @home est bien plus envisageable avec ce NUC qu'avec une framboise.

Le boîtier peut s'ouvrir par le dessus ou par le dessous, en retirant 4 grosses vis très accessibles, excellent point :) Par le dessous on accède à la cage du disque dur (2,5") ainsi qu'aux 2 slots de RAM

Il faut aussi noter qu'un kit de fixation vertical est fourni, par exemple pour fixer le NUC derrière un écran. Autre chose, ce mini-PC est assez lourd, vu ses dimensions je m'attendais à quelque chose de plus léger, mais ce n'est pas bien grave.

Système d'exploitation

S'agissant d'une plateforme x86_64 avec support uefi et legacy-bios, on peut se faire plaisir. J'ai pour le moment testé 3 systèmes d'exploitation, orientés virtualisation puisque c'est l'usage que je compte faire de ce NUC.

Rien à signer du côté des performances, ni rapide ni lent pour de la virtualisation, surtout avec un stockage sur disque mécanique. Idéal pour un petit labo ou serveur à la maison avec des VM Linux pouvant se contenter de peu de RAM. Je créé autant que possible mes VM avec une allocation dynamique 128/256MB et un stockage 30GB, ce qui permet d'en faire tourner pas mal simultanément.

Conclusion

Pour le moment je suis plutôt satisfait de ce NUC, même si je regrette la limitation à 8GB de RAM. Il offre un bon rapport qualité/prix pour un serveur @home et le Celeron J3455 se comporte plutôt bien avec des containers et de la virtualisation. Ce petit serveur Proxmox VE va se révéler très utile pour compléter mon NAS sous FreeNAS.

EDIT 01/05/2018: Je rencontre des problèmes avec ce NUC. J'ai défini le boot en "legacy" (non uefi) sur le disque, mais il ne détecte pas d'OS au démarrage et je suis obligé, à chaque fois, de brancher un clavier et utilise le menu pour sélectionner mon disque. Ensuite je rencontre des freezes à peu près chaque semaine, c'est très chiant. Je viens de faire une mise à jour du Bios, on va voir si cela résout les problèmes.

EDIT 29/07/2018: Je ne rencontre plus de freezes ni de problèmes de boot depuis que le bios a été mis à jour :)

RX Vega Custom, l'arlésienne ? (hardware.fr)

Aïe... ça ne sent pas bon du tout. Le 15 aout AMD a sorti ses nouveaux GPU Vega avec la RX56 et la RX64. J'en parlais dans cet article et j'étais déjà pessimiste, mais il semble que même les constructeurs ne veulent pas investir dans ces cartes graphiques tant elles sont décevantes.

Avec une quasi absence des notebook et des OEM et l'échec de Vega, on se demande ce qui reste à AMD pour survivre dans le secteur des GPUs. Réponse: les consoles et les RX580 (Polaris) dont le prix a explosé, la faute semble-t-il aux mineurs de cryptomonaies qui s'arrachent ces cartes.

Vega est déjà mort, il faut maintenant attendre Navi en 2018 si tout va bien...

AMD RX Vega64 et RX Vega56 en test (Hardware.fr)

Vega c'est la nouvelle génération de cartes graphiques qui vient d'arriver chez AMD. L'objectif est de se remettre à niveau face à Nvidia qui domine en terme de performances et d'efficacité énergique depuis 15 mois (sortie des GPU Pascal en mai 2016). En effet les GPU Polaris (RX400 et RX500) constituent un rapport performances/prix intéressant pour les gamers et les mineurs mais ils sont loin derrière les GTX1070, 1080 et 1080Ti.

Et il se trouve que le résultat est... mitigé car même si l'objectif est atteint (Vega56 // GTX1070 et Vega64 // GTX1080) la GTX1080Ti reste toujours sans concurrence. Pire encore, Vega est un gouffre à énergie :

Le ventilateur de type blower a également beaucoup de mal à évacuer toute cette chaleur :

Alors oui c'est pas fameux :/ 15 mois de retard, gourmand et bruyant, quel intérêt reste-t-il à Vega ? Et bien pour sa défense, voici quelques points à considérer :

• Nvidia a eu 15 mois pour peaufiner ses drivers, Vega débarque tout juste. Les mises à jour permettront de grappiller quelques %.
• La carte est intéressante pour les possesseurs d'écran Freesync.
• Phoronix mentionne l'excellent support des pilotes libres sur Linux, les déclarant même plus performants que les pilotes propriétaires.
• Le test porte sur la carte de référence mais il faut s'attendre à voir débarquer des modèles personnalisés par les fabricants, avec un refroidissement plus efficace et plus silencieux.
• AMD a une longueur d'avance dans le support de Vulkan et DirectX12 et mène le projet open-source GPUOpen, équivalent de GameWorks en libre (librairies permettant d'améliorer le rendu des jeux, par exemple le moteur physique).
• Au moins Vega permet de concurrencer les GTX1070 et GTX1080 inégalées depuis 15 mois en terme de performances.

Mon ressenti personnel est un peu pessimiste. Ce n'est pas la première fois qu'AMD sort une carte graphique en retard et plus gourmande que Nvidia même si les performances sont à niveau. J'ai envie de dire que c'est le cas depuis 2014 avec les R290X puis les R9 Nano et Fury. L'histoire montre que les gamers préfèrent avoir un bon équilibre performances/consommation/silence. De plus, 15 mois d'avance c'est long et beaucoup (comme moi) ont déjà craqué pour une GTX1070 ou 1080. Après le coup de fraîcheur apporté par RyZen il est dommage de voir qu'AMD nous refait du AMD...

Je lis souvent que le RAID matériel c'est mal car on se retrouve prisonnier du hardware et cela peut poser des problèmes en cas de panne. C'est une idée un peu simpliste c'est pourquoi j'ai décidé de rédiger cet article.

Définition : RAID matériel, semi-matériel, logiciel ?

Même si je pense que tout le monde connaît déjà les différences, voici un petit résumé :

• Logiciel : entièrement géré par le système d'exploitation, ce dernier voit les disques physiques et les utilise pour créer un ou plusieurs périphériques block virtuels qui peuvent ensuite être formatés avec n'importe quel système de fichiers. Sous Linux, c'est md qui remplit ce rôle et il est pris en charge par l'installeur Debian. Il est possible de booter sur du RAID logiciel.
• Matériel : une carte additionnelle disposant d'un contrôleur (CPU + firmware + RAM) sert de couche d'abstraction. Le système d'exploitation ne voit plus les disques, uniquement les grappes (ou unités) gérées par la carte RAID. Il faut parfois un driver additionnel, mais la plupart du temps ils sont en upstream dans le kernel Linux (même avec Debian et son kernel sans blob propriétaire).
• Semi-matériel : aussi appelé fake-RAID, c'est ce qui est proposé sur les cartes mères en complément de l'AHCI et de l'IDE par votre contrôleur de stockage (Intel, JMicron...). Ce dernier agit comme une espèce de parasite et puise dans les ressources système et a besoin de pilotes spécifiques pour être reconnu par le système d'exploitation, sous Linux c'est dmraid, sous Windows ça dépend.<-- Lire entre les lignes : c'est de la merde lowcost et vous ne devez jamais l'utiliser.
• Géré par le FS (ex: ZFS ) : Certains systèmes de fichiers n'ont pas besoin de RAID à proprement parler, ils savent gérer directement la répartition/réplication des données. C'est le cas avec LVM qui dispose d'une implémentation basique ou encore ZFS, le meilleur FS du monde, qui lui dispose de fonctionalités avancées (mirror, stripping, raidz, spares...). <-- Lire entre les lignes : je suis un fanatique de zfs, vous devez l'utiliser.

Mon expérience

Le RAID matériel est souvent le plus simple car abstrait pour l'OS. Le changement des disques se fait à chaud et sur certains modèles il n'y a aucune manipulation à faire pour enclencher la reconstruction de la grappe. Il apporte aussi un gain en performances en raison du cache mais aussi parce qu'il soulage votre système lorsqu'il s'agit de calculer des parités (RAID5,6,50...). Il devient quasiment indispensable si vous souhaitez gérer de très nombreux disques (les cartes mères n'ont souvent pas plus de 8 ports SATA). En revanche, il est vrai que le RAID matériel peut poser des problèmes. Je n'ai jamais vu un contrôleur claquer mais j'ai "souvent" (au moins 3 fois par an sur une dizaine de cartes) subit des lag ou micro-coupures qui peuvent faire passer le système de fichiers en read-only et donc planter le serveur.

Le RAID semi-matériel c'est de la merde, très difficile à faire prendre en charge sous Linux en raison de drivers exotiques non libres. Il puise dans les ressources système pour fonctionner et on ne sait pas comment il se comporte si on change de carte mère ou même si on décide de reset le bios. A réserver au bidouillage ou aux gamers windowsiens qui veulent avoir 2 disques en RAID0 pour gagner en performances (encore qu'un unique SSD les écrase de loin). Mais à fuir en prod.

Le RAID logiciel est le plus sûr, il est upstream, non buggué et le CLI est assez évident. Attention je parle de Linux uniquement, je n'ai pas d'expérience avec le RAID logiciel de Windows. Pensez à installer Grub sur vos deux disques en cas de mirroring (RAID1). En cas de panne du serveur vous pouvez monter vos disques dans une autre machine et récupérer vos données. En cas de changement de disque il y a des opérations à faire en CLI mais ce n'est pas très compliqué.

La gestion par le FS (ZFS) est la méthode la plus souple et la plus puissante puisqu'on élimine une couche. Le FS a accès aux disques et à leur cache et sait comment les gérer et contrôler l'intégrité des données. En plus, en cas de changement de disque l'identification est plus simple et la procédure facilitée. Là encore vous devez faire les opérations en CLI, mais les commandes ZFS sont bien conçues et quasi intuitives.

Conclusion

Tout dépend de l'utilisation du serveur :

1. ZFS est à privilégier si votre serveur est destiné à stocker des données (usage NAS ou SAN) très clairement. Et contrairement à ce qu'on pense, il ne faut pas des quantités astronomiques de mémoire vive, 8GB suffisent pour ZFS + vos services habituels (après ça dépend de la quantité de cache ZARC que vous souhaitez avoir).
2. Le RAID logiciel pour vos serveurs Linux parce que c'est facile à installer, c'est fiable, et le CLI n'est pas très compliqué quand il s'agit de remplacer un disque.
3. Le RAID matériel pour vos serveurs Windows (plus facile pour le boot) ou encore Linux si vous ne souhaitez pas vous embêter à gérer vous-même le RAID ou si vous avez des besoins spécifiques (très grand nombre de disques).