Reprise du message précédent :

 
Pas plein emploi non plus, on est le plus grand employeur de la région Paca  . C'est has been mais ça avance quand même avec l’inertie d'un super tanker  

Il n'empêche que quand ton workload est stable, que t'as une sécurité assurée par l'OS et en aval, que ton réseau bouge pas toutes les 2 minutes, ben la virtu/jail/cont/whatever remplacera jamais le niveau d'économie réalisé quand t'as du metal bien dimensionné.  
On dirait vraiment que vous bossez tous dans des boites qui font que des bullshit job/économie virtuelle/communication/banque-assurance avec des niveaux de turn over utilisateurs et de variations de charges ahurissants. Ou des plans sur 1 an max (j'ai même pas envie de voir la gueule de l'économie des entreprises qui vous embauchent.)
 
Hormis de la hype, vous avez des cas d'usages concrets ? Autant pour Plam je peux comprendre, son coeur de métier c'est justement l'IT, autant les autres, je vois/comprend pas.

ce mépris  

Ah les libristes, toujours des avis bien tranchés, sûrs de leurs convictions    

Hormis dire "ce mépris", petite question :
Tu propose/vend quoi comme solution à une entreprise qui fait du calandrage/rotomoulage/thermoformage plastique, une usine de sous traitance en assemblage de pièces pour l'automobile, un GAEC qui monte une station de méthanisation, un plublicitaire solo qui utilise des contractuels pour fournir ses objets, un groupe qui bosse dans l'IT mais qui veut pas se faire chier à gérer le data ?
 
Cas d'usages réels. Pro tips, y'a besoin de virtualiser/jailer/solution cloud dans 2 cas uniquement. Pro tips 2, c'est pas les cas qui sont économiquement les plus viables.

Je bosse pour un groupe qui a entre 10 - 20 sites de e-commerce + du physique, ben l'élasticité du cloud ça sert, black-friday / confinement tout ça  

+1, a plein d'endroits, le bare métal est la solution. Encore plus quand t'a des grosses contraintes de perf/stockage mais pas forcément de flexibilité/migration/whatever.
J'dois avoir 50% de mon parc en bare-metal. Et j'invite n'importe qui a m'expliquer que ce serais moins cher et mieux en virtu/conteneur/whatever sachant qu'on parle de 100aines de To de stockage, pas de scalabilité/flexibilité nécessaire...

Economie "virtuelle"/e-commerce. Le cloud est valable. Pour le physique, a moins que les types fassent du dumping et remontent des magasins tout les 3 ans (se qui est au mieux douteux, au pire éthiquement et légalement à l'ouest), aucunes raisons que les caisses et le backoffice soient pas en metal. La compta et la gestion employés en cloud. (et encore c'est à condition que ton employeur ait pas peur de retrouver ses données dans la nature et à condition d'exercer dans une zone bien desservie en termes de telco).

 
Tu réfléchis pas à l'échelle de la planète, et juridique. Faire un datacenter en Russie, au Brésil, En France... tu as pas forcement besoin et l'envi de faire du datacenter dans tous les pays, par contre pour des caisses magasins, tu veux de la haute-dispo dans le même pays. Plus le web... on a pris une charge énorme avec le confinement, va commander des serveurs à ce moment là  

 
quand la forme n'y est pas, ça donne pas envie de répondre sur le fond ...
 
Tes use cases sont bien trop vagues pour y répondre par une réponse précise, c'est justement quand on se penche sur ce genre d'appels d'offre régulièrement qu'on sait qu'il faut des heures/jours d'étude avant de dégager les meilleures solutions. Le métier ou la taille du client ne déterminent pas la maturité de son infra, l'adéquation du metal / virtu / conteneurisation / cloudification ou non. Déjà parce que ces clients ont souvent de l'infra éclatée un peu partout, dans des maturités différentes, avec des prestas différents, et cherchent rarement le "big bang" en venant te voir.
 
Les réponses évoluent sans cesse en plus. Il y a 10 ans on envisageait même pas de faire du call center sérieux en mode SaaS par exemple, et le ticket d'entrée était très élevé, ce qui n'est plus le cas aujourd'hui.
 
Bref j'ai l'impression que tu cherches un dogmatisme sur ce topik alors qu'il n'y en a pas vraiment. Chacun a eu son lot d'expérience sur des infras variées et sait bien qu'aucun type d'infra n'est une réponse magique à tous les use cases.

 
sur du bare metal uniquement, pour moi non ce serait de la perte monstrueuse en place.
J'ai une 30aine de serveurs virtu actuellement à cause des nombreuses applis, sauf que ces 30 serveurs n'arrivent même pas à utiliser plus de 10% de mes CPUs en temps normal (6x xeon 10c/20t - existant à mon arrivée), mais remplissent tout à fait la RAM (400Go total), derrière j'ai en gros 20To de stockage et ça me suffit.
 
Je suis sur une bibliothèque universitaire, on propose une très grosse collection en numérique.
Du coup, oui, notre charge est très instable, venant tout bêtement du traffic extérieur sur le site web auto hebergé.
On est éduc nationale, côté ministère en ce moment c'est le choix de la possession des données : on doit posséder le plus possible nos données sans passer par des produits commerciaux.
 
Donc bon, si toi TES applis passent bien sur du bare metal sans perte de place ni gros overkill au niveau de la puissance, grand bien te fasse, mais c'est pas le cas pour tout le monde.
Moi j'ai soit du très gros (serveur de fichier 12To pour bibli numérique), soit du très petit (genre serveur pour 1 forum et 2 wordpress)
Dans le tas, j'ai que 4 instances de serveur qui nécéssitent vraiment Windows - à savoir AD / DNS / DHCP / console de gestion Kaspersky. TOUT le reste peut basculer sous linux voir même BSD, et est par nature variable en charge... des bases de données qui toutes servent le web, des applis webs préconstruites type wordpress ou applis métier internes, une tripotée d'applis web publiques, un nextcloud, un Jitsi, un RocketMail, ...)
 
J'ai aussi des applis (quelques sites avec leur DB, deux trois wordpress) qui sont édités par des intervenants externes (on héberge en fait des sites de sociétés savantes sur notre infra et sous notre nom de domaine). Pour ceux là, il faut un accès extérieur, et je veux les séparer du reste / entre elles.
Et bon, balancer 1 CPU / 1Go de RAM c'est déjà trop pour ça. même 256Mo c'est trop. et pourtant, 256Mo c'est à peine assez pour faire tourner rien qu'une distro debian basique.

 
 
1. Juste si. Une VM est par définition flexible. C'est l'intérêt majeur de la virtu. Si c'est pas le cas, ta une plateforme de merde ou pas configuré correctement tes machines. Aujourd'hui, tu peux migrer une VM d'un DC à l'autre, avec le storage en live, ça marche très bien. C'est pas de la pseudo flexibilité, c'est de la flexibilité et ça marche. Donc n'invente pas des problèmes là où 99% des gens utilisent justement de la virtu pour ça sans problèmes Et pour le coup, j'en croise des milliers par ans des utilisateurs de la virtu.
 
2. IRL, les 3% de pertes de perfs de la virtu, ça coûte RIEN par rapport à cette flexibilité. Pose toi la question sinon : le monde entier est-il vraiment con à encore utiliser de la virtualisation, même les très gros du cloud ? (AWS par exemple, qui est sur Xen). Ou alors c'est plus flexible que tu ne l'imagines ?
 

 
Ça ne divise pas, c'est complémentaire. C'est pas un remplacement, en tout cas pas dans la vraie vie (ou alors faut me dire où ). J'ai vu de mes yeux cet enthousiasme quand Docker est arrivé (« la virtu c'est mort »). J'en ai même parlé avec les fondateurs de Docker, et devine quoi, ils en sont vite revenu de leur propre aveux
 
Auissi je pige pas la partie en gras. La variabilité de la charge n'est pas un argument ni pour l'un, ni pour l'autre. Ensuite, ton NextCloud, Jitsi, RocketMail et BBB, tu les fais tourner sur la même machine physique ensemble dans des containers ? (perso ça me choque sauf si c'est que pour toi en interne, mais si c'est des clients différents, LOL, aucune chance de faire ça en terme de sécu).
 
Et même si c'est que pour toi, il te faut une infra de cluster de container pour ces besoins, et ça c'est au moins aussi voir plus complexe à mettre en œuvre que son équivalent en VM « pures » (donc pareil, je vois pas en quoi c'est mutuellement exclusif). Et franchement une VM par service, ça a du sens quand tu veux isoler (dans ce cas VM >> container), mais qu'en c'est pour le même client, tu sais pas faire tourner des services dans `systemd` Dans ce cas, la containerisation rajoute une couche inutile je trouve    
 
Bloquer les ressources, je suis pas sûr de piger, il existe aussi plein de moyen de faire respirer tes VMs à l'heure actuelle. Quand c'est nécessaire, ce qui est pas souvent le cas IRL.  
Je trouve pas les containers con si t'es bien organisé et que ton compute est complètement séparé de tes données « persistantes », le container à du sens oui
 
J'ai aussi vu déficit de savoir faire/connaissance système aussi, on sait plus créer des usersou des units, systemd qui gère très bien tout ça (même les limites par services ). Le container sent souvent l'excuse à deux balles car on sait pas (ou veux pas, c'est entendable) comprendre comment marche le système. Au final c'est souvent calé dans des VMs, car c'est tout moisi et on veut pas contaminer autour, mais je vais pas faire un procès à la techno pour de mauvais usages (c'est une expérience perso avec un dev quand on faisait de l'intégration chez nous).
 

 
Quand tu vois déjà les besoins d'isolation, faut un truc vraiment solide, le container c'est quasi du service.
 

 
1. Tu peux avoir ton serveur TFTP sur une VM Alpine, 50Mo d'utilisé sur le stockage Parfaite isolation, utilisation de SDN de manière simple (isolation réseau, VxLAN, tunnel, gestion fine de toutes les ressources, backup de ta machine si jamais c'est de la prod importante, voir HA au niveau VM, migration à chaud si besoin ailleurs donc sans perte de service visible). C'est justement pour les softs où ta pas la main dessus (perso j'écris pas mon TFTP en Cloud native), ça te laisse une fléxibilité inégalable, pour un coût très modique, car ça « juste marche ».
 
2. « Passer à côté » : je renvoie au fait que les très gros « on prem » (qui on pas décidé de tourner sur les serveurs des autres) continuent à utiliser de la virtu et même à tout baser dessus. C'est pas par inertie, mais que ça apporte une flexibilité à un niveau inégalé en rapport qualité/prix/sécurité. C'est assez factuel. Pas cher, efficace, flexible, et bien isolé. Pour les mêmes raisons que le x86 a gagné par exemple face à certaines archi très prometteuses
 
Après si tu veux de la sécurité au top et des ressources ultra-légère, le mieux c'est de l'unikernel (le « meilleur des 2 mondes »). C'est génial sur le papier, et Docker à l'époque (2 ou 3 ans jsais plus) à racheté une boîte qui faisait ça.
 
Et… ça n'a pas marché. Les raisons : faut tout ré-écrire tes services pour que ça marche Remember : si tu veux être adopté, faut être complémentaire, et si tu remplaces, il faut être aussi simple, ou VRAIMENT avoir de quoi différencier.

 
de mon côté, je dois avoir 99% de mon infra virtualisée sur 2 hosts.
 
J'aimerais beaucoup savoir comment 150 à 200 serveurs physiques pourraient être plus économiques que les deux hosts en question et leurs licences (sans parler des perfs).
 
A côté de ça, j'ai par exemple 500 To sur des serveurs physiques pour de la vidéo-surveillance, je me pose pas franchement de questions à leur sujet.

Qui recrute ? Je veux faire un projet (ingé info réseau) pour faire mon mémoire
J'ai 55 jours de CP, m'en fout du salaire mais je veux pas 25 jours de CP et 0 RTT
Et surtout : qualité de vie au travail.

 
C'est tout à fait pertinent le cloud pour les charges élastiques. C'est même sa raison d'être en fait Ça devrait être LE cas d'usage, sauf que la majorité c'est l'envie de plus gérer du hardware (CAPEX/OPEX), quitte à mettre ses données n'importe où
 

 
Ça peut être une solution oui. Pour mon infra clairement pas, j'ai trop besoin de pouvoir déplacer ma charge un peu partout au grès de l'évolution de mon SI, sans avoir à reconfigurer mes services. Le besoin de flexibilité : virtu. Besoin de perfs et infra/applicatif statique c'est bien aussi. Données jetables et en mode devops pour appli cloud native : cloud et/ou containers.
 
En fait c'est ça le truc Il n'y a pas d'outil magique qui va tout remplacer Ça dépend des BESOINS
 

 
Il y a des uses cases spécifiques partout. Après par exemple, la virtu arrive dans l'embarqué (ou l'edge, cad on reste en x86) pour des questions de sécurité, redondance, et praticité/automatisation. Ça peut paraître bizarre à certain mais je peux vous dire que pour nous c'est le branche la plus prometteuse

Je sais pas si je l'ai dit ici mais ici le +1 va supprimer les donnée en local et tout sera via seafile sur un truc je ne sais où
En gros le type vire tout petit à petit sans avoir jamais rien maintenu

 
T'as rien compris de ce dont je parle.
Je parle de la flexibilité de la machine virtu en elle même.
Si mon appli monte à 8Go de RAM en full charge, mais passe 90% de son temps à moins de 2 Go, je perds donc 6Go de RAM la grande majorité du temps. La VM n'est pas flexible.
La majorité des VMs qui tournent sur mon infra sont infoutues de rapporter leur utilisation RAM à l'hyperviseur même avec les VMtools installés. Du coup... le ballooning ne fait pas son effet.
 
Je m'en fous que les hébergeurs soient tous en VM. Eux s'en branlent, tu payes quoi qu'il arrive, que tu utilises les 8Go de RAM que t'as dans ton instance ou pas.
Moi j'ai mon infra en propre, et un budget limité - secteur public. Du coup, les VMs qui me bouffent 8Go en permanence alors que c'est pas utile, c'est un poil énervant.
 
Pendant ce temps, la flexibilité dont tu parles toi, qui est la capacité de bouger des instances d'un hôte à l'autre... est aussi présente avec les containers.

 
C'est bien ce que je dis, ta un problème sur ta plateforme. Rapporter la RAM utilisée c'est un truc de base T'es sur ProxMox ou quoi ?

Euh, sinon tu fait un service scalable sur plusieurs VMs.
Je sais, t'a résolu ton problème avec des conteneurs. C'est pas pour ça que t'aurais pas pu le faire autrement.
Tu peux même faire de la scalabilité avec du bare métal, et du provisionnement auto. Mais c'est un poil moins réactif. Quoi qu'avec du stockage sur san, ça doit le faire.

 
Oui oui il y a toujours moyen de bricoler un truc. Il n'empêcher qu'aussi légère soit ta surcouche OS, tu auras toujours à l'administrer. Si on reste sur le TFTP, tout ce dont ça a besoin pour fonctionner, c'est un réseau, un fichier de conf et un répertoire pour servir les fichiers. Tout le reste est superflu. Et c'est pareil pour la quasi-intégralité des services réseaux (modulo 2-3 bricoles ).
 

 
Je ne nie pas l'intérêt de la virtualisation ou du on prem, au contraire. Mais la conteneurisation me paraît être le prolongement logique. Avant la virtualisation, on n'avait pas une machine par service. On optimisait comme on pouvait selon les ressources qu'on avait mais au final, on en arrivait toujours à empiler les services et à pousser les murs. Avec la virtualisation, on a pu s'affranchir des contraintes physiques. Avec la conteneurisation, on peut s'affranchir des contraintes logiques (aka. l'OS).
 

 
Je suis d'accord et c'est pour ça que je te dis que gérer un conteneur doit être aussi simple, sinon plus, que gérer une VM et être accessible à n'importe quel tech. Ca viendra. On sélectionnera dans XCP-ng un .deb ou un .rpm, une ip, un espace de stockage. Et voilà

 
ESX 6.5
exemple en direct :

celle là montre moins que ce qu'elle utilise
J'ai des exemples avec l'inverse aussi

T'es conscient que les 1.7Go affichés, c'est pleins de trucs différents (cache, mémoire allouée aux applis, au kernel), et que les 0.48 correspondent probablement à la même liste... Sans le cache, vu que ça peut être libéré si nécessaire ? (Et peut être même sur demande des additions client).

Le 1378M de RES pour mysql n'est pas d'accord.

 
Je crois pas avoir ce problème sur XCP-ng, si ta un soucis lié à ta plateforme de virtu chez toi tu crois que c'est généralisé pour tous le monde

 
Comment ça marche, d'un point de vue réseau ?

Ça l'utilise à priori

https://blogs.vmware.com/vsphere/20 [...] emory.html
la mémoire active, ce sont les pages qui "bougent", pas ce qui est utilisé (=alloué) dans la VM
c'est d'ailleurs pour ça que souvent l'overprovisonning RAM marche pas trop mal vu que même si il y a beaucoup de mémoire allouée, a l'arrivé beaucoup moins est accédée, ce qui permet a l'hôte de swapper ce qui ne l'est pas sans grosse baisse significative des perfs

 
C'est bien là le soucis. Tes 500To sont sur un clust, et si tu considère le clust comme une seule et même machine ... Ben non. Rien qu'une MD1000 standalone, c'est une machine en elle même et devrait être comptée comme tel par tout sys qui se respecte. Ben ouai, la perc sous arm avec un x86 tronqué sous minix dedans, elle est pas là pour faire joli. S'il n'y a pas de baie DAS capable d'adresser plus de 254To, y'a une raison.
 

 
Tout a fait, c'est même l'ancêtre de la virtu moderne. (ça et les mécaniques d'isolation mise en place dans les firmware et les micro systèmes de gestion/translation d'adresses physiques à la volée)
 

 
Ça s'appelle réinventer le thin client.
 
Quand vous aurez compris que tout se que vous faites c'est du minitel sur mainframe multi instances x86.    
PS : UEFI c'est déjà de la virtu. (enfin pour être plus précise, du container auto unloadé pour le chainboot)
PS2 : IPMI, management OOB, c'est aussi de la virtualisation. Et ça va avoir les mêmes failles de sécurité, les mêmes problèmes que l'ancêtre.
PS3 : les concepts de la convergence stockage proviennent de la virtu SAN OOB. Et ça souffre des mêmes contraintes et limitations.

THIS.
J'ai milité des années pour la souveraineté des données (cliniques, et or noir de la boîte). J'avais commencé à monter un projet d'infra hybride avec débordement de charge sur le cloud et environnement de dev/test sur le cloud mais la prod restait on-prem.

Le CEO n'a jamais eu quelconque intérêt pour la souveraineté de la donnée.
Le CFO (et CEO) tout ce qu'ils voulaient c'était payer moins cher et avoir plus d'opportunités.
Là ils vont migrer tout sur azure (c'est plus moi qui gère, long story), ca va faire plaisir au patron, c'est hype, et ça coûtera plus cher même si on a biaisé les chiffres sur le ppt..

J'ai lâché l'affaire personnellement..
Le gars qui gère le projet m'a dit, on va mettre k8s et tout. Je lui ai demandé pourquoi, il m'a dit que les dev voulaient bosser dessus (grossièrement).
Je pensais qu'il allait me dire que c'était pour répliquer la plate-forme n'importe où y compris chez les cloud provider, mais non. C'est juste de la hype en fait (j'ai rien contre la techno, elle est chouette et certainement utile dans notre situation, mais pas été choisie pour la bonne raison ça rend fou).
On a des plateformes qui vont tourner pendant 5 à 8ans voir plus.  

Bref faut que j'arrête ça me donne des boutons.

Je vais me prendre une rafale mais j'assume    
 
k8s c'est la vie !  
- ça tourne dans le cloud et on-prem de façon iso
- ça gère le RBAC, l'isolation, le scaling
- ça gère les containers, les VMs (linux et windows)
- on peut développer ses propres fonctionnalités via des opérateurs  
- c'est HA
 
Par contre oui, la courbe d'apprentissage est longue !  
 
Dans mon ancien poste ( labo de recherche fonction publique ) on était on-prem avec du k8s, et là énorme cogip on fait du k8s, d'ici la fin de l'année ça sera > 50% de la boite.  
 
Et comme tu le dis, oui tous le monde veut / voudra en faire, donc autant se former  

 
Il fallait comprendre "c'est bien en physique, c'est cheap, ça n'a aucune raison d'être virtualisé".
 
Maintenant j'aimerais bien savoir comment "la virtu/jail/cont/whatever remplacera jamais le niveau d'économie réalisé quand t'as du metal bien dimensionné".

La question est vaste « Ça dépend ». Si ça reste ton réseau, ça se passe comme une migration en local. Mais je sais pas si ta question concerne la migration en local et le process de migration en lui-même, ou le fait de déplacer de DC ?

hahaha Ça s'appelle un manque de vision business Après ça peut passer si jamais les clients en ont rien à foutre. Par contre le jour où ya un client qui gueule ou une fuite de donnée J'aimerai te dire que ya un karma mais malheureusement non, donc ils peuvent aussi s'en sortir très bien avec des idées à la con et perdurer là dedans.

Faut laisser tomber et trouver une boîte où tu as une vision proche de la direction…

Non Après je sais pas dans quelle équipe tu te trouves, si c'est toi qui ramasse la merde ou pas en cas de problème... Si t'es du bon côté de la barrière (que tu profites de tout ça, par exemple en tant que dev métier), tant mieux

Par contre j'imagine que c'est pour de l'appli « faite pour »

 
Je suis dans l'équipe que l'on accuse quand il y a une merde    
 
Je suis curieux, quelle application ne peut pas rentrer dans k8s pour toi ? (je précise c'est pas que du containers)

Mes applis fournies en .ova, qui ont besoin de plusieurs centaines de To en local, et où j'ai le support éditeur que si c'est du vmware ?
Mes outils fournis UNIQUEMENT en appliances physiques ?

 
La question est très vague, tout est possible (modulo les lois de la physique) en y passant un temps infini
 
C'est surtout l'investissement initial (un peu comme OpenStack à l'époque en fait) qui n'a du sens que si « tu passes à l'échelle ». L'orchestration automatisé (peu importe la techno)  c'est des équipes de devs et maintenance en permanence. Donc faut pouvoir se le payer (et on retombe sur l'effet d'échelle nécessaire).
 
En fait je dirai que ma vision de l'IT a pas mal évolué avec le contact du terrain, et pas vraiment sur le principe des technos, mais sur le rapport qualité/prix/sécu. Une techno n'est pas mauvaise, il y a juste des usages inadaptés.
 
Dans votre cas, ça peut être parfaitement adapté, comme aurait pu l'être un OpenStack ou un VMware ou whatever qui est capable d'orchestrer des « trucs ».
 
Donc je résume : pour une infra petite/moyenne et/ou sans besoin de scalabiliité, l'orchestration « avancée » n'est pas nécessaire (ni souhaitable, introduire de la complexité sans maîtriser la techno, c'est le risque de problèmes graves sans pouvoir réagir).
 
Le sweet spot dépend de beaucoup de facteurs hein, ya pas de règle absolue. Chez nous, par expérience, Xen Orchestra commence à être limite chez des gros acteurs (centaines de machines physiques). Après certains utilisent notre API directement (Kayak avec 1200 machines physiques et 10 fois plus de VMs). Il y a même du k8s a des endroits, je crois qu'ils ont même leur lib en Ruby pour connecter tout ça
 
Bref, ça m'étonne pas que k8s soit bien adapté dans ta grosse COGIP
 

Attends, on arrive sur les appliances physiques en partenariat avec certains acteurs (on fluidifie et sécurise leur déploiement)

 
Yep, les appliances physiques par définition c'est hors charte :>
Genre mon boitier VPN Pulse Secure, yep, bah non, je l'intègre pas.

Change de taf

C'est le plan, si t'a un poste fait tourner

Non, là je pète une durite donc je vais changer aussi
A deux on ouvre plam corp toulouse

Ouai enfin, a 1.75 vu qu'il te faut 50 jours de cp par an