Comment faire rentrer 48 NUC dans 1 baie serveur ? - MiniMachines.net

Comment faire rentrer 48 NUC dans 1 baie serveur ?

Comment multiplier les serveurs sans alourdir ni la consommation électrique, ni exploser son budget tout en restant confiné dans un espace minimal. Tout simplement en utilisant des NUC et de la matière grise.

Dja est un lecteur de longue date qui commente de loin en loin sur le site mais qui m’a aujourd’hui envoyé un email un peu particulier. Par ce long lundi de Juillet, je suppose que le rythme des vacances lui a offert l’opportunité de faire un petit compte rendu de son installation, il m’explique comment il a réussi à réunir pas moins de 48 NUCs dans 1 baie serveur 12U pour solutionner ses besoins.

Dja travaille dans une société qui accompagne des entreprises pour les aider à analyser et mesurer leurs actions sur le web. Le genre de services qui demande une assez grosse densité de serveurs pour mener à bien des tâches composées d’une multitudes de petites requêtes. Pour traiter ces données, des programmes en C ont été codés et tournent sur des distributions Linux sur mesures (Debian / Devuan). La solution la plus efficace pour traiter ces données n’est pas de virtualiser1 de nombreux serveurs à partir d’un matériel hyper performant mais plutôt de multiplier les machines de manière à profiter au mieux de chaque système.

En clair, il est préférable de multiplier des machines autonomes qui peuvent se répartir la charge de travail. Cela permet en plus d’éviter les imprévus en cas de problèmes d’alimentation ou de soucis techniques. Les autres baies peuvent absorber la charge sans que le système entier soit en panne.

Mini ITX

La version Mini ITX « classique »

Pendant des années Dja a fait appel à des solutions Mini ITX développées sur mesures du type de ce que vous voyez au dessus. Actuellement, pas mal de son infrastructure serveur utilise encore ce système. Seulement, cela ne permet que de monter 7 serveurs par baie et pose des soucis d’alimentation. Pour y remédier, une première tentative de développement d’une plateforme NUC avec un partenaire industriel s’est soldée par un échec.? Le marché était probablement jugé trop petit pour développer un produit de A à Z. D’autres rapprochements avec d’autres entités se sont soldés par des devis bien trop élevés pour être rentables…

2018-07-30 16_46_34-minimachines.net

4 rangées de 12 NUC : 48 NUC !

En se creusant la tête une solution bien plus simple a été trouvée. En achetant deux imprimantes 3D2 et en désignant des supports adaptés, il a été possible de faire entrer 12 serveurs sur une base de NUC là où 7 serveurs existaient auparavant.

2018-07-30 16_46_47-minimachines.net

La carte du NUC et sur la gauche le support 2.5″ pour le stockage. Impression en ABS obligatoire pour des contraintes de chaleur

Mis en service il y a 2 ans, ce concept de serveurs sur mesures à imprimer tourne depuis sans faille. L’ajout d’une unité prendra le temps d’imprimer les divers éléments nécessaires et, comme me l’explique Dja, pas un seul châssis métallique n’a été acheté depuis.

La beauté de ce système, outre sa simplicité et son faible coût3 est qu’il solutionne énormément de soucis rencontrés par les utilisateurs de ce type de solution serveur.

2018-07-30 16_50_58-minimachines.net

Les différents éléments a imprimer en ABS.

La premier est la facilité de dimensionnement. Suivant les besoins, il est facile d’acheter une baie et d’imprimer les supports de NUC nécessaires. Il n’est pas nécessaire d’attendre le besoin pour commencer à imprimer d’ailleurs, il est possible de préparer une éventuelle installation en amont en lançant des impressions d’avance de manière  pouvoir facilement remplir une baie quand le besoin s’en fait sentir.

NUC5i5MYHE

Une carte de NUC5i5MYHE

Cela permet également de suivre les évolutions des machines et d’ajouter des engins au fur et à mesure des sorties. Il suffit de piocher dans les gammes de NUC supportant les instructions vPro pour ajouter un nouvel engin. Les machines actuellement installées embarquent 32 Go de mémoire vive et peuvent accueillir un disque mécanique SATA de 2 To. Si la carte mère des NUC évolue, il suffira de retravailler le fichier à imprimer pour prendre en compte les éventuelles modifications.

2018-07-30 16_49_18-minimachines.net

Les deux supports de ventilateur en face arrière

Mais le gros point fort est de solutionner beaucoup des risques de pannes rencontrés dans les salles machine. Le design des châssis imprimés a permis d’optimiser la ventilation au maximum. Les ventilateurs des 48 NUC sont remplacés par l’ajout de deux ventilateurs de 92 x 92 mm qui aspirent de l’air frais et recrachent de l’air chaud. En cas de panne, la ventilation est facile et peu onéreuse à changer. L’ensemble doit également générer beaucoup moins de bruit.

2018-07-30 16_52_00-minimachines.net

C’est d’ailleurs le même constat pour le reste du matériel. Si une alimentation, un stockage ou un NUC tombait en panne, cela ne paralyserait pas l’ensemble de la solution. Il suffit d’extraire la partie problématique et de la remplacer.

C’est enfin un moyen de limiter tous les problèmes électriques liés aux systèmes d’alimentation des machines Mini-ITX.

L’ensemble des fichiers nécessaires pour réaliser le même type d’installation est disponible gratuitement sous la forme de fichiers pour impression 3D. Ils sont disponibles sous licence GNU-GPL sur Thingiverse. Vous y trouverez d’ailleurs le détail des divers éléments utilisés (alimentation, connecteurs, ventilateurs, NUC) ainsi que des informations et conseils.

Je trouve l’idée géniale et la réalisation absolument spectaculaire : Accessible et intelligente, évolutive et proposant un ratio encombrement / service optimum, je suis pour le moins admiratif du résultat obtenu.

Notes :

  1. créer de petits serveurs virtuels à partir d’un gros processeur avec de multiples coeurs comme un Xeon par exemple
  2. Ultimaker 2
  3. La bobine de 2Kg de PLA, matériaux utilisé pour imprimé les châssis coûte environ 32€
37 commentaires sur ce sujet.
  • 30 juillet 2018 - 19 h 09 min

     » La solution la plus efficace pour traiter ces données n’est pas de virtualiser1 de nombreux serveurs a partir d’un matériel hyper performant mais plutôt de multiplier les machines de manière a profiter au mieux de chaque système. »

    Ca m’intéressait de savoir pourquoi, quelqu’un aurait une idée ? Merci

    Répondre
  • fpp
    30 juillet 2018 - 19 h 17 min

    Tiens, c’est marrant ça. Il y a …une quinzaine d’années, maintenant, j’ai vu quelque chose de très similaire à l’Université Robert Schumann de Strasbourg.

    Tout le « back-office » et le SI pédagogique de la fac tenaient dans quelques baies d’une salle blanche.
    Bien sûr les NUC Intel n’existaient pas à l’époque, mais ils avaient à peu près la même chose en bourrant les baies de… Mac Mini :-)

    Y paraît que le rapport Q/P était alors au plafond du marché, et les perfs nickel…

    Répondre
  • FQ
    30 juillet 2018 - 19 h 48 min

    Top installation, c’est vraiment super propre. Chapeau bas.

    Répondre
  • dja
    30 juillet 2018 - 20 h 12 min

    @David:
    Je tente de repondre sur nos choix non virtualises. Je sais, ce n’est pas a la mode…

    Plusieures raisons majeures:
    – Un xeon qui couvrirait l’equivalent CPU de 4 nucs i5-i7 de production (16 coeurs) coute 3000$. Uniquement le CPU… C’est plus que le prix de 4 nucs complets (ram, cpu, ssd). Parce que c’est grand public, gros volume = petit prix. Nous faisons du HPC et nous utilisons les instructions processeurs avancees, le SIMD sur un i5 tourne aussi bien que sur un Xeon. Ce sont des petits joyaux dans ces processeurs et souvent sous-exploités.
    – Un xeon consomme beaucoup d’energie, bien plus que 4 nucs.
    – La densite: la surconsommation electrique entraine un tres faible remplissage de la baie, donc un cout d’espace mensuel incompressible, soit en ajout de kVA, soit en ajout de baie. Vous mettez une dizaine de gros serveurs xeon dans une baie de 42U. Donc disons 40-50 VMs. Avec l’infra NUC, vous embarquez 96 NUCs sur 3-4 kVA.
    – Une infrastructure virtualisee ralentit les I/O disque et la latence reseau (sur-couche, mutualisation, SMP). 100K d’IOPs d’un SSD, 4 virtuels, 25K d’IOPs par VM. Avec 4 NUCs, c’est lineaire: 4x100K d’IOPs. Idem pour la latence reseau. Idem pour la capacite reseau intrinseque du kernel linux, du hardware reseau, …
    – Le ‘SPoF’. Si votre hardware craque, votre gestion de vm craque, vous perdez x VMs.
    – Le downtime. Pour intervenir sur le hardware, vous devez arreter x VMs.

    La virtualisation est une solution, parmi tant d’autres, pour certains type d’applicatifs, mais il y a beaucoup de defauts et qui etaient intolerables dans notre infrastructure maitrisee.

    Répondre
  • 30 juillet 2018 - 20 h 52 min

    C’est beau ❤😉

    Répondre
  • 30 juillet 2018 - 21 h 03 min

    article super intéressant. et réalisation au top.

    il me semble d’ailleurs que (fut un temps ?), google faisait aussi la même chosr, en utilisant du matis ‘standard’ dans ses data centers plutôt que de gros serveurs pro.

    gg en tout cas.

    une question néanmoins: on comprend que vous obtenez une plus fine granularité pour les pannes, mais ça implique donc en retour une « plus fine granularité » (donc plus de temps) pour la maintenance, non ?

    Répondre
  • dja
    30 juillet 2018 - 22 h 08 min

    @brazomyna:
    En fait c’est tout le contraire.

    Nous avons en permanence 10% de l’infrastructure qui est disponible en allocation pour la production ou le remplacement de machine.
    Nous avons un uptime de deux ans sur beaucoup de nucs. Nous avons eu un defaut de carte reseau sur une et quelques ssd. Nous avons plus de 600 unités en production.
    Donc une fois toutes les deux semaines, en fonction des nodes qui sont mortes, notre admin sys charge dans son sac une dizaine de ssd, des cartes nuc, mini-itx ou des linecards completes de rechange, il met tout ca dans son sac a dos, scooter, et se fait une intervention en une journée (une demi journée par datacenter pour la France).
    L’installation des nodes est automatisé par PXE et elles rejoignent un bloc de serveurs de rechange. Ils sont réalloués et resynchronisés en nocturne.

    Avec des serveurs classiques, il est impossible d’intervenir sans voiture pour transporter le matériel. Le matériel devient souvent hétérogéne, car on commande rarement autant de serveurs d’un coup et les gammes se renouvellent trés vite au niveau serveur, donc c’est pénible à commander, à maintenir et à recevoir.
    On est également moins motivé pour tout redonder avec ce genre de matériel… et c’est là où les problèmes de disponibilité arrivent.

    Avec cette infra NUC/mini-itx, on trouve encore du matériel en vente qu’on utilisait il y a 3 ans, on peut upgrader, passer une commande… des ssds, des cpus, de la ram, des nucs… je les recois le lendemain et on peut même bénéficier des bons plans de Pierre ;-) par exemple dernièrement, SSD 1to crucial pendant les soldes.

    Je n’ai pas de complexes. J’ai bossé sur des infras classiques, grosses, et même sur des z-series IBM. J’ai fait dans le gros, le cher, le gratifiant socialement, celui à la mode… celui qui pose toujours problème.
    Désormais, je m’en fiche, du cloud, de la virtualisation. Je prends ce dont j’ai besoin et qui performe le plus.
    J’ai des serveurs en ABS avec des NUCs dedans, des serveurs metal avec des mini-itx… mais j’en ai beaucoup ;)

    Répondre
  • 31 juillet 2018 - 0 h 35 min

    @dja: merci pour ce retour d’xp détaillé.

    Répondre
  • 31 juillet 2018 - 7 h 59 min

    Bonjour, comment gérez vous la résilience des donnes car il n’y a pas de raid, non ?

    Impressionnant !!!

    Répondre
  • 31 juillet 2018 - 9 h 13 min

    @dja:
    Cela fait plaisir de voir des gens qui font l’effort de sortir des sentiers battus pour concevoir des solutions plus adaptées que celles des industriels ne savant que coller au marketing d’Intel.
    Accessoirement, cela illustre aussi le niveau de fiabilité d’un produit grand public: Bien intégré (alimenté/ventilé), cela tiens le choc.
    Ce n’est pas sans rappeler certaines universités (les universitaires étant souvent fauchés, ils doivent aussi assez souvent être inventifs… Dans un passé lointain, j’ai vu des VHS servir d’enregistreurs à bande bien meilleurs que les solutions pro: Densité de données, résistance aux vibrations pour des manips aéroportées…) qui a la sortie de la PS3 s’en faisaient des clusters, mettant même un peu à mal le business model de Sony: Vendre les consoles à perte et se refaire sur les jeux. D’autant plus simple que Linux était supporté sur les premières versions.
    Sony n’a pas refait la même « erreur » avec la PS4. Surtout que les 2 modèles concurrents ont une architecture plus proche d’un PC que par le passé…

    Répondre
  • 31 juillet 2018 - 10 h 06 min

    J’avoue que la partie redondante des disque m’intrique, comment faire un raid entre deux nuc comportant un disque et que les deux soit actif

    genre la moitier du disque du premier nuc et en parité avec le deuxieme nuc sur la moitier de son stockage

    Répondre
  • 31 juillet 2018 - 10 h 21 min

    @dja Et coté alimentation, chaque NUC a garder son bloc alim dédié? Si oui, je serais réellement curieux de voir comment tu as pu organiser cela pour ne pas que ca devienne un « bordel immonde » (le point avec lequel j’ai tres souvent du mal avec mon matos :D )

    Répondre
  • 31 juillet 2018 - 10 h 27 min

    Merci @Pierre pour cet article et bravo @Dja pour cette réalisation qui sort du carcan actuel VM/Cloud/SDN… etc etc
    Les clusters et le edge computing sont l’avenir !

    Répondre
  • 31 juillet 2018 - 11 h 00 min

    Apparement ceph gère cela ainsi que glusterfs qui à l’air plus performant mais cela n’est possible que sous linux à savoir si windows le permet

    en tout cas, la virtu serait possible grace à des nuc et proxmox qui gère cela nativement, le seul inconveniant direct c’est l’installation de proxmox sur tout les nuc donc consommation du CPU et RAM supplémentaire

    dans ton cas dja avec debian et ce genre de systeme partagé tu dois bien t’en sortir en tout cas merci pour toutes les idées (article et commentaires) que vous m’avez apporté ca porte à réflexion et j’en apprend beaucoup

    Répondre
  • dja
    31 juillet 2018 - 11 h 19 min

    @jean:
    @leclerc:
    Nous fonctionnons en mode « grappe » (grid computing), nous n’utilisons pas d’architecture étagée car elles créent des SPoF (single point of failure).
    En fonction du client et de la charge attendue, nous allouons un nombre de nodes (1 node = 1 serveur). Chaque node est frontale web et base de donnée. C’est du ‘shared-nothing’, c’est à dire que toutes les nodes qui composent un grid disposent de l’intégralité de la donnée.
    Dans cette configuration, toute l’intelligence est dans la base de donnée, le cache, les échanges inter-node. Nous avons tout développé en C.
    Une fois qu’on a ca: ‘chaque node est indépendante en ressource’, on se retrouve avec une architecture où la répartition de charge et le ‘fail-over’ sont simplissimes. Ca peut être faire en pur software avec, par exemple sous linux, IPVS.
    Les nodes d’un même grid sont réparties sur plusieurs baies voir plusieurs datacenters.
    La beauté dans tout ca, c’est qu’un grid peut ensuite discuter avec un autre grid, etc… chaque grappe est fiabilisée et tous les SPoF sont éliminés.
    On se retrouve avec une architecture où les serveurs physiques sont « jetables », ils peuvent sortir de la production en une simple commande, être alloués dans une autre grappe et resynchronisés, …

    Si c’est en mode serveur de fichier, pour faire simplement du raid-1 réseau, il y a beaucoup de solutions qui existent: GlusterFS, Lustre, drdb,.. ou si la réplication ne doit pas être instantannée, il suffit de faire du rsync.

    @goaryser:
    J’ai détaillé les références du matériel dans la page thingiverse si tu veux.
    Pour l’alimentation, nous utilisons des Tracopower TXH 600-124. Ca sort du 600W en 24V et alimente donc les 4 ventilateurs et 12 NUCs d’une rangée.
    Elles sont isolées donc on peut en théorie en mettre deux en // (pas testé). Pour l’instant nous n’avons eu aucune défaillance de ces alimentations.
    L’alimentation est fixée sur des supports (également imprimés) qui se fixent sur une simple plaque 19″ 1U (ca sert normalement à combler les trous dans une baie). Cette plaque est fixée sur le portant arrière de la baie donc côté ventilateurs du shelf.
    Le cablage passe par les trous au dessus des ventilateurs, arrive sur chaque line-card (il y a des supports de cable imprimés sur la line-card), sort en connecteur Molex Micro-Fit 3.0 qui se connecte sur le NUC.
    Le seul cablage frontal de la baie est donc le cablage réseau.

    Merci à tous.

    Répondre
  • Ted
    31 juillet 2018 - 11 h 54 min

    Je ne veux pas revenir sur le fond, mais ça a l’air d’être une solution adaptée uniquement à ce type de besoin (via le fait que les perf SIMD équivalent que sur Xeon). Et même pour du HPC je n’ai jamais vu un client nous dire qu’ils préféraient des i5 plutôt que des Xeon. Donc on est vraiment sur un besoin de niche.

    « Un xeon consomme beaucoup d’energie, bien plus que 4 nucs. » C’est sûrement vrai. Par contre 4 alim avec 4x la perte lié à son rendement. Un xeon en 4u aura double alim pour redondance. Après si pour le besoin très spécifique ici, avoir de la redondance n’est pas important, ni le management (IPMI etc), ni la fiabilité (ECC etc) du fait que c’est ici du grand public et non du serveur, ça justifie la solution. Et la différence de prix. Et je parle pas du support, SLA, etc avec du matos pro (souvent ça explique le prix).

    Par contre pour la virtu:
    – La densité, sur un Xeon 4U avec du KVM c’est plutôt 120 VM minimum. Je parle d’une moyenne pour de l’usage classique (ntier appli J2EE + bdd), pas pour du HPC. Sinon pour une alim 750W (ex dell R630, ou R730) on est plutôt autour des 1Kva.
    – Une infrastructure virtualisee ralentit les I/O disque et la latence reseau. Il y a toujours un overhead avec la virtu. Et le fait qu’on multiplie les machines sur un même controleur interne. Mais il y a des pistes pour améliorer ça, surement en faiseant exploser le budget.
    – « Le ‘SPoF’. Si votre hardware craque, votre gestion de vm craque, vous perdez x VMs. » pas toujours vrai. Avec du stockage reparti ou centralisé (nfs par ex), la VM redemarre direct sur un autre hyperviseur. Donc certes ya downtime, mais très faible. ça fait parti des avantages qui font que justement la virtu est à la mode (en plus de la surmutualisation des ressources)
    – « Le downtime. Pour intervenir sur le hardware, vous devez arreter x VMs. » Alors là, c’est étonnant de lire ça en 2018 :p Et la migration ?? Avec la virtu, c’est 0 downtime de maintenance justement. C’est sa force.

    C’est juste histoire de partager nos expériences, je suppose clairement qu’il y avait d’autres arguments pour justifier ce bel exemple de « physiqualisation » (ie l’inverse de la virtualisation). Qui est aussi un peu à la mode tout de même (avec les serveurs ARM par ex).

    Répondre
  • 31 juillet 2018 - 13 h 16 min

    @David

    A mon avis c’est surtout que les petits systèmes sont moins cher que les gros à puissance équivalente.
    Et c’est aussi moins « exotique » à administrer pour ceux qui ne sont pas habitués aux hyperviseurs.

    Répondre
  • 31 juillet 2018 - 13 h 55 min

    Merci dja,

    Serait-il possible d’avoir des photo de tout le matos monté stp

    Pour me faire une idée, concernant les alimentation des NUC tu as donc du soudé les connecteurs ?

    Répondre
  • 31 juillet 2018 - 14 h 04 min

    @Ted:
    Attention à l’ECC côté DDR: Cela apporte plutôt une aide au diagnostic en mettant vraiment le doigt sur la mémoire (et même le boîtier en cause) si elle a un souci: On ne se retrouve pas avec le florilège d’exceptions que l’on peut connaitre et d’interprétation souvent plus difficile.

    Certes, il y a en général la correction d’erreur à 1 bit (erreurs multiples c’est en général détection simple dont la défense sera un reboot avec réinitialisation complète du contrôleur mémoire) à la volée (en lecture, le handler d’exception erreur simple bit se chargeant de ré-écrire la donnée corrigée ; on sait jamais, un second bit pourrait faillir avant la lecture suivante pour une donnée variant peu et finir en reboot!).

    Cette capacité, limitée, de correction d’erreur peut donner une illusion de fiabilité apportée.

    Jusqu’au moment ou les problèmes concernent justement les données de redondance ECC (sur un boitier DDR supplémentaire, c’est la raison pour laquelle la mémoire ECC est plus cher: Il en faut un de plus sur une barrette!): Là, le moindre bit en erreur va selon toute probabilité se traduire par une incohérence avec les données (sur des boitiers pourtant non défaillants) réelles multiple bit. Et c’est ainsi que l’on se retrouve avec une machine inutilisable, qui le serait en fait à initialiser la DDR sans ECC (par reprogrammation de la SPD EEPROM contenant les données d’initialisation propre au type de barrette sur un PC par exemple, ou modif setup boot-loader/BIOS afin de pouvoir forcer un mode non-ECC).

    Répondre
  • dja
    31 juillet 2018 - 14 h 51 min

    @Ted:

    >> Je ne veux pas revenir sur le fond, mais ça a l’air d’être une solution adaptée uniquement à ce type de besoin (via le fait que les perf SIMD équivalent que sur Xeon). Et même pour du HPC je n’ai jamais vu un client nous dire qu’ils préféraient des i5 plutôt que des Xeon. Donc on est vraiment sur un besoin de niche.

    Il y a deux choses: peu de serveurs proposent du i5/i7 classique, pas de xeon = pas d’ecc.
    Un Xeon c’est un i5/i7 avec un gros cache L2/L3, ca sert pour le SIMD (même si nos tests n’ont pas démontré d’impact flagrant).
    99.99% des serveurs en production en datacenter font tourner des serveurs web, des bases de données pré-compilées qui n’exploitent même pas 2% des instructions SIMD.
    Donc le seul point c’est l’ECC, je reponds aprés.

    >> « Un xeon consomme beaucoup d’energie, bien plus que 4 nucs. » C’est sûrement vrai. Par contre 4 alim avec 4x la perte lié à son rendement. Un xeon en 4u aura double alim pour redondance. Après si pour le besoin très spécifique ici, avoir de la redondance n’est pas important, ni le management (IPMI etc), ni la fiabilité (ECC etc) du fait que c’est ici du grand public et non du serveur, ça justifie la solution. Et la différence de prix. Et je parle pas du support, SLA, etc avec du matos pro (souvent ça explique le prix).

    Je mets une alim pour 12 NUCs. Donc nettement plus efficace énergétiquement que n’importe quel serveur xeon.
    L’IPMI complet, je l’ai via le vPro NUC.

    L’ECC, c’est une longue histoire. En 10 ans d’activité sur ces infra non-ECC, +600 machines, nous avons cramé (block défectueux) environ une vingtaine de barette en production. Les machines sont passées sur memtest 4 cycles avant le passage en production. Au moindre doute, c’est à dire un software C qui segfault avec erreur intracable ou suréaliste, nous lancons un memtester dans le userland (donc sans reboot). C’est trés rare.

    Donc le surcout Xeon pour avoir de l’ECC, c’est surfait. Surtout quand on conçoit une plateforme qui décorréle sa fiabilité de la fiabilité du hardware, ce qui devrait toujours être le cas, ce que tout bon développeur ou architecte systeme prend en compte en permanence.

    >> Par contre pour la virtu:
    >> – La densité, sur un Xeon 4U avec du KVM c’est plutôt 120 VM minimum. Je parle d’une moyenne pour de l’usage classique (ntier appli J2EE + bdd), pas pour du HPC. Sinon pour une alim 750W (ex dell R630, ou R730) on est plutôt autour des 1Kva.

    120 VMs. Ce sont des VMs type Atom 600Mhz alors… et si elles chargent toutes, ca tombe à 100Mhz…
    J2EE est inefficace. Le java n’est pas fait pour la performance.
    Une appli Tomcat monte en mémoire, prend immédiatement minimum 2-3Go de ram. Je serais curieux de voir 120 VMs lancer un Tomcat. Vous avez 400 Go de ram dans votre gros dell R730 ?

    >> – Une infrastructure virtualisee ralentit les I/O disque et la latence reseau. Il y a toujours un overhead avec la virtu. Et le fait qu’on multiplie les machines sur un même controleur interne. Mais il y a des pistes pour améliorer ça, surement en faiseant exploser le budget.

    Oui c’est du FusionIO ou du SAN en fiber-channel + ssd.
    Je vous laisse voir les prix ;)

    >> – « Le ‘SPoF’. Si votre hardware craque, votre gestion de vm craque, vous perdez x VMs. » pas toujours vrai. Avec du stockage reparti ou centralisé (nfs par ex), la VM redemarre direct sur un autre hyperviseur. Donc certes ya downtime, mais très faible. ça fait parti des avantages qui font que justement la virtu est à la mode (en plus de la surmutualisation des ressources)

    Si vous faites du basculement live, vous devez avoir en permanence un serveur de spare pour chaque serveur de production. Ca double le cout de l’infrastructure.

    >> – « Le downtime. Pour intervenir sur le hardware, vous devez arreter x VMs. » Alors là, c’est étonnant de lire ça en 2018 :p Et la migration ?? Avec la virtu, c’est 0 downtime de maintenance justement. C’est sa force.

    Vous avez la version de la communication des vendeurs de plateforme virtualisée.
    Sur des bases de données à gros volume et/ou haute fréquence, le basculement de VMs vers un serveur de spare est loin d’être transparent ;-) C’est du vécu.

    Mon point de vue est assez agnostique, en tout cas j’essaie ;) Ce sont des sujets assez interessants et donc pleins de passion.
    La virtualisation repond à un besoin indéniable: software simple, faible besoin en performance, en IO, gros budget, faible maitrise bas-niveau et donc besoin d’administration systeme simple facile à recruter. Ca repond à des besoins de DSI qui veulent se rendre la vie supportable sans se casser la tête, il suffit de faire passer des grosses lignes de budgets en amortissement.
    Si vous devez héberger une appli interne (Java?) avec des accés maitrisés, une latence dont on se fiche, la question ne se pose presque pas, la virtualisation est probablement le meilleur choix.

    J’espère juste apporter à ma petite échelle une regard différent sur ce qui peut être monté en infrastructure technique.

    Répondre
  • dja
    31 juillet 2018 - 15 h 08 min

    @leclerc:
    Les connecteurs Micro Fit sont sertis tout simplement, avec une pince. Ca produit un connecteur de qualité industriel et c’est rapide à faire. Les références des connecteurs sont sur la page thingiverse.

    La seule soudure est le regroupement de chacun des 2 brins des 6 cables d’alimentation du NUC qui arrivent sur un cable électrique classique (0.75mm) pour venir se visser sur l’alimentation. Ca pourrait trés bien être un simple domino en fait.

    Les ventilateurs ont également droit à leur cable, un connecteur JST ou Molex classique, pour pouvoir les changer si besoin.

    Mon admin sys va faire des photos demain, je rajouterai ca sur la page thingiverse…

    Sincérement, je ne pensais pas que ca allait passionner autant de monde… c’est génial.

    Merci à tous.
    Il y a peut-être une vie aprés le Cloud ;-)

    Répondre
  • Ted
    31 juillet 2018 - 16 h 11 min

    @dja en effet nos R730 ont entre 788Go de RAM et 1To pour les plus gros. Bien vu. Nous avons environ 6000 VM mais je vois mal repasser ça sur 6000 machines physiques. Mine de rien la mutualisation (via la virtu), permet d’avoir des serveurs à 95% de charges de moyen, alors qu’avant on était plutôt à 5%… Bien sûr car dans notre cas, ce n’est pas du HPC.

    Pour l’ECC, avec des machines disposant d’autant de RAM, c’est pratique d’avoir le matériel qui nous surveille tout ça avant que les programmes (VM) s’en servent. Cela permet d’être pro-actif. Mais je suis d’accord c’est rare, mais cependant ça arrive. Donc ce n’est pas que de l’ECC. C’est toute la capacité du matériel serveur, à s’auto-diagnostiquer. Après que ça soit récupérable via IPMI, IdRAC, vPro etc c’est du détail.
    Faudrait que je lance un memtest sur un serveur avec 1To de RAM pour le fun.

    Pour la migration, comme nous avons du stockage partagé, c’est assez rapide, y compris sur des VM BDD. Mais en effet, plus la VM aura de l’activité (principalement du mouvement sur la RAM), plus la migration sera longue. Et il ne faut pas doubler le nombre d’hyperviseurs. Même loin de là, plus y aura d’hyperviseurs, mois il faudra du spare. Il suffit de garder un peu de mou sur chaque, de quoi redispatcher les VM d’un (ou plus) hyperviseur en maintenance.

    Il y a par contre un gros avantage à la physicalisation, c’est de pouvoir éteindre électriquement les machines qui ne servent vraiment plus. Alors qu’avec la virtu, on restera toujours avec un hyperviseur allumé…

    Ce projet à base de NUC me fait penser au projet moonshot de chez HP (mais il y’en a d’autres chez les concurrents, nokia ou huawei a priori), l’article date, mais la photo des cartouches fait penser aux NUC en plus petit. https://www.silicon.fr/hp-moonshot-un-nouveau-format-de-serveurs-cartouches-arm-ou-intel-85070.html

    Répondre
  • dja
    31 juillet 2018 - 17 h 04 min

    @Ted:
    Oui je comprends, vous faites du hosting ou ca s’y apparente fortement.

    Vous avez du vous amuser avec Spectre et meltdown… vive les patchs, les reboot et les transferts de VMs ;-)

    Vous avez une problèmatique de multiplicité d’instances qui mutualise la charge car vous supposez que toutes les instances ne seront jamais chargées en même temps. C’est une supposition qu’on ne peut pas se permettre dans une infrastructure dédiée.

    Je dirais même que votre problèmatique est encore plus spécifique que la mienne si on s’adresse à la majorité des gens qui voudraient monter une infrastructure dédiée à un applicatif.

    Répondre
  • 31 juillet 2018 - 19 h 07 min

    Merci a vous pour ce sujet hyper intéressant.

    Répondre
  • 31 juillet 2018 - 19 h 40 min

    @dja:
    Avez-vous eu l’occasion d’évaluer l’éventuel gain de passage à des plate-formes à base de Xeon D mini-itx (notamment les D-1500 particulièrement peu énergivores, avec certains modèles allant jusqu’à 12 coeurs / 24 threads) ?

    Répondre
  • dja
    31 juillet 2018 - 21 h 03 min

    @Kris:
    Jamais testé les xeon D.

    En mini-itx, donc chassis metal, nous avons une dizaine de Asrock EPC612D4I parce que nous avions un besoin précis d’embarquer 64Go de ram. Nous avons mis des simples E5-2630, pas cher et bien fréquencé. C’était exceptionnel, nous n’avions pas le choix pour 4 barettes dans un mini-itx. Rien que pour trouver les ventilateurs low profile adaptés au socket, ca a été compliqué.

    Pour du 12/24(HT) cores, le D-2161I, 90 W, max 3.00 GHz, c’est a priori 822 Euros (HT)
    Pour du 6/12(HT) cores, le i7-8700, 65 W, max 4.60 GHz, c’est 273 Euros (HT)

    Personnellement, l’équation serait faite rapidement avec une carte mini-itx grand public et ram grand public.

    Mais nous n’aurions même pas l’utilité d’i7, nous prenons des i5 à 3.2/3.3Ghz et ca fait le travail avec une charge trés acceptable (nous désactivons même le intel boost pour ne pas tirer sur les alimentations inutilement).

    Nous ne faisons pas une course à l’armement en multipliant les machines, mais une croissance linéaire de l’infrastructure avec un équilibrage des nodes.
    Le software, le noyau linux, chaque instance a une capacité de traitement bien définie.
    Vous pouvez avoir un CPU ultra rapide, vous ne pourrez jamais ouvrir/fermer plus de connexion réseau que sur un simple core i3. Idem pour les I/O disques.
    C’est du aux « interruptions » CPU/carte reseau, au protocol TCP qui inclut des timeouts sur les différents états des connexions avec une limite max de sockets par kernel, et de multiples autres choses.

    Si une node de traitement est équilibrée, nous arrivons à un rapport capacité réseau/IO disque/CPU en corrélation avec la capacité du kernel et de nos softwares.
    Une fois qu’on a ca, il suffit de dupliquer linéairement les machines… et on arrive à cette derniere itération avec les NUCs.

    Répondre
  • Ted
    1 août 2018 - 14 h 04 min

    Attention tout de même, sur des serveurs pro, les chipsets des contrôleurs disques et surtout réseaux sont très performants, et accélèrent beaucoup de traitements (ya qu’à voir les accelerations dispo via ethtool -k). La bande passante vers la mémoire est aussi souvent multipliée sur les Xeon (NUC ~ 25GBps, alors qu’un bon xeon on tape vers le 50GBps). Au moins vous avez fait vos bench, et vu que tout ça ne vous apportait rien.

    Je suis de près tout de même ces NUC mais plutôt pour un usage labo ou POC. Pour la virtu principalement. C’est pas un peu cher les 32Go DDR2 en 2xSODIMM ?

    Répondre
  • dja
    1 août 2018 - 15 h 17 min

    @Ted:
    Dans un nuc vous avez une intel eepro1000, à trés peu de chose prêt ce que vous avez sur des cartes mere de serveur.
    Pour du nuc 32 Go, c’est la derniere generation avec vpro, NUC7i5DNHE. C’est de la DDR4 en 2133Mhz.
    debut d’année les 2×16 DDR4-2133 sodimm étaient à 300 euros il me semble. Maintenant c’est plus cher… comme toutes les rams.
    TDP 15W ;)

    Répondre
  • 3 août 2018 - 9 h 33 min

    Bonjour,

    Tout d’abord, merci beaucoup pour cette discussion, et cette approche différente de l’architecture des serveurs.
    N’ayant toujours travaillé qu’avec des machines virtuelles, je découvre complètement un nouveau domaine, qui semble aussi avoir ses avantages et inconvénients.

    Pour me faire une idée, savez-vous si il existe des distributions, tutoriels ou autre, permettant d’aborder et d’expérimenter ce type de serveur ?

    Je ne cherche pas la performance, mais juste à tenter une approche dans ce nouveau monde.

    Merci d’avance

    Répondre
  • dja
    3 août 2018 - 13 h 39 min

    @Draew: Merci à vous.
    La question est un peu large, ca dépend uniquement de ce que vous souhaitez faire avec les machines.
    Linux bien sûr si vous parlez de distribution? ou Freebsd/Netbsd aussi où vous avez l’excellent ZFS en natif et HAST.
    Une quantité astronomique de softs sont adaptés à ces infras physiques, que ce soit pour du stockage réparti/fail-over, du clustering sql/nosql/objet, du serveur web, .. et tout ca en opensource. Il existe des howto un peu partout sur chaque type de systeme. Vous pouvez tester ces infras réparties à partir de serveurs virtuels aussi bien sûr avant de passer sur du physique.
    C’est un peu sans limite et ca dépend totalement de votre objectif.
    Il n’y a pas de distribution linux qui ne puisse pas faire de grid computing. Vous avez le choix, en fonction de l’administration systeme que vous faites, et encore une fois dans ce domaine, il y a plein de solutions en surcouche aussi, comme ‘Puppet’.

    Répondre
  • 7 août 2018 - 13 h 22 min

    article très intéressant
    « Je prends ce dont j’ai besoin et qui performe le plus. » plus le temps passe plus je me rends compte que c’est ce genre de pragmatisme qui est le plus efficace.

    Répondre
  • 7 août 2018 - 14 h 46 min

    Merci dja pour les nouvelle photo, c’est quoi les port série en façade ou peut être du vga au cas ou tu souhaite te connecter en direct sur la machine ?

    Répondre
  • kkn
    7 août 2018 - 20 h 40 min

    Pourquoi ne pas se trouner vers des chassis de type https://www.supermicro.com/products/system/3U/5038/SYS-5038ML-H24TRF.cfm .
    24 systemes en 3U qui supporte les xeon et les core ?
    Je ne connais pas le tarif pour ce chassis mais je pense que l’on doit etre a moins de 300euro par socket (sinon il y a mieux pour moins cher dans la gamme). En plus, on gagne l ‘ipmi et l’alim redondée.

    Répondre
  • dja
    8 août 2018 - 10 h 19 min

    @kkn:
    C’est 8 KEuros pour un chassis supermicro 12 nodes sur 3U. La version 24 nodes est à 16KEuros (une board pour 2 machines).
    Il faut ajouter CPU (xeon) + Ram (petite ddr3) + Disque, donc un chassis 12 nodes chargé dépasse les 15 KEuros.
    Il a 2000W d’alimentation (80+), donc impossible de remplir une baie sans faire sauter les plombs même avec la version 12 nodes.
    Les cartes meres sont propriétaires. Tout est propriétaire (alim, etc..).

    Notre chassis 12nodes/3U NUC a un coût complet de l’ordre de 8000-9000 Euros. Il est alimenté par 600W (90+) et est complétement évolutif. L’IPMI est fourni par le NUC (vPro).

    Répondre
  • dja
    8 août 2018 - 10 h 30 min

    @leclerc: Le connecteur en facade est un adaptateur DisplayPort->vga avec 2 pins VGA jointes.

    Durant nos tests, sur ce NUC (assez vieux désormais), nous avons constaté que l’IPMI/vPro n’activait pas systématiquement le remote console proprement alors que tout était bien booté au niveau bios et OS.
    Petit bug chez intel à priori à l’époque, cette carte nuc venait de sortir.
    Avec cet adaptateur, il n’y avait plus aucun problème donc nous en mettons partout sans nous poser de question.
    C’est certainement corrigé désormais par Intel.

    Répondre
  • 8 août 2018 - 18 h 41 min

    @dja: MErci pour ta reponse. Tracopower, j’en utilise assez souvent dans mon taf (a des puisance bien inférieure); jamais été déçu; c’est bien simple, dès que j’ai besoin d’une alim, je cherche dans leur gamme

    Répondre
  • 14 août 2018 - 14 h 29 min

    Comment tu connais le voltage en sortie de ces alim ?

    du coup tu dois faire le câblage toi même ?

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *