Le Blog Utux

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

Mon blog a pour sous-titre "le sysadmin qui raconte des histoires". Voici donc le récit d'une nuit passée au datacenter pour remettre en fonctionnement nos serveurs suite à une coupure électrique.

Dans la nuit du 30 Juin au 1er Juillet 2015 un important incident électrique a eu lieu dans l'Ouest de la France, impactant de nombreuses villes en Bretagne et dans les Pays de Loire. J'étais d'astreinte cette nuit là et je ne parvenais pas à dormir en raison de la chaleur (38°c en fin de soirée).

0h00. Je constate que plusieurs de nos serveurs ne répondent pas : absence de ping et pas d'accès IPMI / iDRAC donc impossible de faire quoi que ce soit à distance. Je dois donc me rendre en urgence au datacenter.

01h00. Arrivé sur place je croise d'autres techniciens venus eux aussi réparer leurs serveurs. J'entre mais n'ayant pas le code pour ouvrir la baie je suis obligé d’appeler mon collègue. Celui ci me le fourni et me propose de venir me filer un coup de main : vu la situation j'accepte. Une fois la baie ouverte je fais un contrôle visuel des voyants, tout est au vert, la raison de la panne est donc plus profonde. En branchant un PC sur le switch de la baie je fais un premier diag et je constate que les machines virtuelles sont toutes en carafe ainsi que deux serveurs physiques. Je note aussi que les quelques équipements fonctionnels ont un uptime d'à peine une heure, il y a donc eu un redémarrage général (non prévu).

01h30. J'ai trouvé la cause du non démarrage des VMs : le datastore iSCSI est offline. Heureusement je parviens à le remonter rapidement : le daemon iscsi-target était arrêté sur le SAN. Après l'avoir lancé je remonte les VMs, tout passe sauf quelques vieux serveurs Windows qui affichent des BSOD. Je charge une iso win2k3 puis tente des chkdsk mais rien à faire. Mon collègue est arrivé et a emmené de quoi tenir : des gâteaux et de l'eau. Nous attaquons donc ensemble le diagnostic de ces VMs Windows qui ne veulent pas démarrer et comprenons qu'il faut les mettre sur même serveur Xen qu'avant leur exctinction. En effet notre infra Xen est composée de 3 serveurs reliés à un datastore et les VMs peuvent démarrer dessus au choix. Cela ne pose pas de problèmes pour Linux, en revanche un vieux Windows n'aime pas. Nous faisons donc plusieurs essais jusqu'à trouver le serveur qui leur convient, nous paramétrons ensuite Xen pour que ces VMs précisent ne puisse démarrer que sur celui-là.

03h00. Les machines virtuelles sont maintenant fonctionnelles mais pas certains serveurs physiques, nous cherchons donc la raison. En fait un switch réseau a perdu partiellement sa configuration, probablement parce qu'elle n'a pas été sauvegardée dans la flash. En effet si vous avez fait du Cisco vous savez probablement qu'il y a plusieurs niveaux de sauvegarde de la configuration : le running-config (effacé au redémarrage) et le startup-config (permanent). Après avoir réaffecté les VLANs aux bons ports, les serveurs physiques repassent enfin en UP, sauf un.

03h30. Sur ce serveur réticent nous branchons un écran + clavier et constatons qu'il est bloqué au niveau de Grub. Après avoir booté un LiveCD de Gparted nous lançons une réparation du RAID1 logiciel qui est cassé à l'aide de mdadm. Mais la reconstruction ne suffit pas, Grub refuse toujours de booter. Nous démarrons alors à nouveau sur le LiveCD et faisons un chroot pour réinstaller Grub, à coup de update-grub et grub-install (sur sda puis sdb). Cette fois ça fonctionne !

04h30. Échange téléphonique avec le CTO qui nous aide à vérifier que tous les services sont bien rétablis. Nous corrigeons les derniers problèmes existants.

6h00. Nous partons nous coucher pour pouvoir attaquer la journée à 09h00. En ouvrant la porte de sortie du datacenter je constate qu'il fait jour et que le sol est humide alors que j'y suis rentré de nuit sous une chaleur étouffante. J'aperçois aussi d'autres techniciens aller et venir avec des serveurs sous le bras, nous ne sommes donc pas les plus malchanceux.

Résumé : Une brève coupure électrique a provoqué l’extinction puis l'allumage de nos équipements. 1 serveur physique a cassé son RAID1, le datastore pour Xen n'a pas correctement démarré, et le switch a perdu partiellement sa configuration. Malgré la fatigue nous avons gardé la tête froide, aidés par l'adrénaline et les gâteaux. Nous avons résisté à cette épreuve du feu, en équipe, et avons gagné 1 journée de repos en compensation.