Pour ceux qui ont le mythe du xeon , « processeur puissant » en tête … extrait de discussion :
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 
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.
