Plop,
Je suis à la recherche de retours d'expérience sur Open Nebula, plus spécifiquement à savoir comment se passent :
- Passage de vCenter / vSphere à Open Nebula et/ou cohabitation - Conversion de VMs de ESX vers KVM - et rollback - Net : routage et annonce des préfixes des VMs par les HV - Backup, offload ou full remote de VM entre instances et des des clouds publics
Y a t il des barbus du domaine dans la salle ?
Merci !
Ton mail m'a permis de me rendre compte que ce projet existait encore alors que je le pensais mort et enterré depuis 3 ans. Un point pour toi du coup.
Après, est-ce bon signe ?
Le sam. 26 oct. 2019 à 19:22, Jérôme Nicolle jerome@ceriz.fr a écrit :
Plop,
Je suis à la recherche de retours d'expérience sur Open Nebula, plus spécifiquement à savoir comment se passent :
- Passage de vCenter / vSphere à Open Nebula et/ou cohabitation
- Conversion de VMs de ESX vers KVM - et rollback
- Net : routage et annonce des préfixes des VMs par les HV
- Backup, offload ou full remote de VM entre instances et des des clouds
publics
Y a t il des barbus du domaine dans la salle ?
Merci !
-- Jérôme Nicolle +33 6 19 31 27 14 _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut Guillaume,
Le 27/10/2019 à 11:05, Guillaume Barrot a écrit :
Ton mail m'a permis de me rendre compte que ce projet existait encore alors que je le pensais mort et enterré depuis 3 ans. Un point pour toi du coup.
Après, est-ce bon signe ?
https://github.com/OpenNebula/one/graphs/code-frequency
C'est pas le projet le plus actif que je connaisse, mais je le trouve plutôt stable en terme d'activité.
Le truc c'est que je ne trouve pas d'équivalent sur le plan fonctionnel.
OpenStack est trop lourd à mettre en place (à mon goût en tout cas) et n'interopère pas avec beaucoup de chose sans une bonne dose d'huile de co(u)de.
Les box "all-inclusive" à la nutanix laissent peu de contrôle et ont un modèle de licensing qui peut devenir aussi confiscatoire que celui de VMWare.
Proxmox fait trop et pas assez à la fois, et j'aurais pas confiance pour de la prod critique à 1000 cœurs et 6-8To de RAM.
Du coup, garder un bout de VMWare "legacy" (pour le windows ou les trucs voués à mourrir) et rebuild le reste sur une plate-forme plus versatile, ça paraît être un compromis séduisant.
Mais j'ai vraiment pas l'impression que ce soit très utilisé par chez nous…
Après s'il y a des arguments additionnels pour telle ou telle option, ou des alternatives, je suis ouvert à toute préco !
@+
Tu as regardé le pricing VSPP de Vmware (pas de cout de licence, tu payes à l'usage uniquement) ?
Dans le bundle de base, à 7 point, tu as NSX, VSAN, et une partie de la couche vRealize. Clairement pour moi le sujet sur la virtu, maintenant ce sont les outils, non pas l'hyperviseur (c'est du commodity).
Un truc comme VSAN+NSX déjà rapporte enormement en terme de facilité d'usage, cout en equipement réseau, etc (typiquement, des switchs FS avec un simple VLAN à plat suffise vu que tu geres tout en VXLAN sur les hyperviseurs), plus besoin de baie de stockage (même en full flash, VSAN est quasi imbattable en terme de prix, si tu sais bien choisir tes SSD).
Après multiples études, et une tentative complétement foireuse chez JN en Openstack (qui s'est revele 2 à 3 fois plus couteux que la plateforme VMware existante même en la mettant à jour), on a adopté ce modèle, y compris sur les uCPE qu'on fait tourner ESXi. Pour dire.
Le dim. 27 oct. 2019 à 12:28, Jérôme Nicolle jerome@ceriz.fr a écrit :
Salut Guillaume,
Le 27/10/2019 à 11:05, Guillaume Barrot a écrit :
Ton mail m'a permis de me rendre compte que ce projet existait encore alors que je le pensais mort et enterré depuis 3 ans. Un point pour toi du coup.
Après, est-ce bon signe ?
https://github.com/OpenNebula/one/graphs/code-frequency
C'est pas le projet le plus actif que je connaisse, mais je le trouve plutôt stable en terme d'activité.
Le truc c'est que je ne trouve pas d'équivalent sur le plan fonctionnel.
OpenStack est trop lourd à mettre en place (à mon goût en tout cas) et n'interopère pas avec beaucoup de chose sans une bonne dose d'huile de co(u)de.
Les box "all-inclusive" à la nutanix laissent peu de contrôle et ont un modèle de licensing qui peut devenir aussi confiscatoire que celui de VMWare.
Proxmox fait trop et pas assez à la fois, et j'aurais pas confiance pour de la prod critique à 1000 cœurs et 6-8To de RAM.
Du coup, garder un bout de VMWare "legacy" (pour le windows ou les trucs voués à mourrir) et rebuild le reste sur une plate-forme plus versatile, ça paraît être un compromis séduisant.
Mais j'ai vraiment pas l'impression que ce soit très utilisé par chez nous…
Après s'il y a des arguments additionnels pour telle ou telle option, ou des alternatives, je suis ouvert à toute préco !
@+
-- Jérôme Nicolle +33 6 19 31 27 14
Salut Guillaume,
Le 27/10/2019 à 14:47, Guillaume Barrot a écrit :
Tu as regardé le pricing VSPP de Vmware (pas de cout de licence, tu payes à l'usage uniquement) ?
Depuis quand c'est une bonne idée de perdre du temps à moduler les politiques de licensing - et de les intégrer dans l'ERP pour analyser les coûts et marges - plutôt que de CAPXiser tout ce qui peut l'être ? On fait de l'infra ou pas ?
Clairement pour moi le sujet sur la virtu, maintenant ce sont les outils, non pas l'hyperviseur (c'est du commodity).
Justement, KVM, LXD ou ESXi, j'en ai rien à carrer, ce qui compte c'est la robustesse et la maîtrise des coûts. Quand un éditeur proprio modifie son pricing ça casse un business-case produit et ça fait bosser les gens du marketing - doux antonyme, d'où problème. Donc si je veux faire marcher une offre, j'ai besoin de visibilité à moyen terme au moins, et les éditeurs ne me le garantissent pas.
Un truc comme VSAN+NSX déjà rapporte enormement en terme de facilité d'usage, cout en equipement réseau, etc (typiquement, des switchs FS avec un simple VLAN à plat suffise vu que tu geres tout en VXLAN sur les hyperviseurs), plus besoin de baie de stockage (même en full flash, VSAN est quasi imbattable en terme de prix, si tu sais bien choisir tes SSD).
Si je comprends bien, tu préconises de remplacer le backbone par des multiprises, et de perdre le contrôle des flux réseau ? Tu sentiras une certaine réticence de ma part sur ce point, mais faire tourner des vVTEP sur les hyperviseurs quand t'as la feature câblée en dur dans des ASIC de tes ToR, c'est pas trop coûteux en terme de power et CPU ?
Après multiples études, et une tentative complétement foireuse chez JN en Openstack (qui s'est revele 2 à 3 fois plus couteux que la plateforme VMware existante même en la mettant à jour), on a adopté ce modèle, y compris sur les uCPE qu'on fait tourner ESXi. Pour dire.
J'ai aussi vu une majorité d'expériences douloureuses avec OpenStack, c'est pour ça que je n'ai pas envie d'y aller. Et c'est aussi pour ça que Open Nebula me semble être un bon compromis, en tout cas sur le papier.
Par contre, faire dépendre 100% de ma prod d'un seul et unique éditeur de closed-source, sans prévoir d'alternative, c'est hors de question. Créer - ou laisser faire - un risque vital pour la boîte ne fait pas partie de mes attributions.
Je suis d'ailleurs inquiet qu'un tel choix ait pu être fait chez JN, j'ai besoin de plus d'éléments pour en comprendre la rationalité. Tu en as ?
@+
On 27/10/2019 15:09, Jérôme Nicolle wrote:
J'ai aussi vu une majorité d'expériences douloureuses avec OpenStack, c'est pour ça que je n'ai pas envie d'y aller. Et c'est aussi pour ça que Open Nebula me semble être un bon compromis, en tout cas sur le papier.
Par contre, faire dépendre 100% de ma prod d'un seul et unique éditeur de closed-source, sans prévoir d'alternative, c'est hors de question. Créer - ou laisser faire - un risque vital pour la boîte ne fait pas partie de mes attributions.
Sur le principe je suis d'accord avec toi, en pratique il faut reconnaître que Vmware reste le meilleur rapport qualité/prix/emmerdement pour faire l'hébergement soi même. (c'est plus trop ma came actuellement je trouve qu'il y a mieux à faire)
Si tu ne veux pas dépendre d'un éditeur (ce que je comprends et respecte) les seules boites que je connais qui sont sorties à peu près (Gandi, NBS) utilisent des dérivés de Xen. Jette un œil à XCP-ng, c'est ce qui me semble le plus probable. Bon après c'est une partie de la solution, là ou tu vas rigoler c'est quoi comme stockage ?
++
-- Raph
Salut Raphael,
Le 27/10/2019 à 15:18, Raphael Mazelier a écrit :
Sur le principe je suis d'accord avec toi, en pratique il faut reconnaître que Vmware reste le meilleur rapport qualité/prix/emmerdement pour faire l'hébergement soi même. (c'est plus trop ma came actuellement je trouve qu'il y a mieux à faire)
J'ai rien à redire de la qualité technique des offres de VMWare, et si je n'ai pas d'alternative intéressante je compte plutôt rester là dessus en fait.
D'ailleurs, au niveau hyperviseur, je pense que j'en aurais toujours quelques uns.
C'est vraiment sur le coût de leur solution d'orchestration que je m’interroge, ainsi que sur l'hybridation et l'industrialisation…
Si tu ne veux pas dépendre d'un éditeur (ce que je comprends et respecte) les seules boites que je connais qui sont sorties à peu près (Gandi, NBS) utilisent des dérivés de Xen. Jette un œil à XCP-ng, c'est ce qui me semble le plus probable.
C'est un autre débat, tout aussi intéressant pour le coup. Xen a encore un écosystème dynamique ?
Bon après c'est une partie de la solution, là ou tu vas rigoler c'est quoi comme stockage ?
Joker… (c'est du Netapp).
Non, sérieusement, le choix du stockage n'est pas réévalué dans l'immédiat. J'ai jamais réussi à prendre un netapp en défaut, ça _juste_ marche pour pas si cher que ça, et avec peu de variables qui risqueraient d'impacter le coût par VM.
Disons qu'on choisit ses combats ;)
@+
On 28/10/2019 12:37, Jérôme Nicolle wrote:
J'ai rien à redire de la qualité technique des offres de VMWare, et si je n'ai pas d'alternative intéressante je compte plutôt rester là dessus en fait.
D'ailleurs, au niveau hyperviseur, je pense que j'en aurais toujours quelques uns.
C'est vraiment sur le coût de leur solution d'orchestration que je m’interroge, ainsi que sur l'hybridation et l'industrialisation…
Quel niveau d'orchestration ? genre IaaC comme on dit de nos jours ?
Tu as un provider terraform ou ansible donc c'est un début. De toute manière il y a une api donc tout est possible.
(je parle à la fois de Vmware ou de XCP-ng)
Hybridation ? genre mixer du On Premise avec du Cloud ?
C'est un autre débat, tout aussi intéressant pour le coup. Xen a encore un écosystème dynamique ?
A priori oui.
Joker… (c'est du Netapp).
Non, sérieusement, le choix du stockage n'est pas réévalué dans l'immédiat. J'ai jamais réussi à prendre un netapp en défaut, ça _juste_ marche pour pas si cher que ça, et avec peu de variables qui risqueraient d'impacter le coût par VM.
Ça pourrait être pire mais pour le coup c'est cela qui va te coûter un rein au renewal des contrats de maintenances.
++
-- Raphael
Le 28/10/2019 à 13:30, Raphael Mazelier a écrit :
Hybridation ? genre mixer du On Premise avec du Cloud ?
Yep, mais pas seulement. C'est aussi la notion de "Core PoD" vs. "Edge PoD" pour certains services, ou le débordement ponctuel par exemple.
Ça pourrait être pire mais pour le coup c'est cela qui va te coûter un rein au renewal des contrats de maintenances.
Ben, pas tant que ça, et surtout c'est prévisible, jusque là.
@+
Plop,
Le 28/10/2019 à 13:30, Raphael Mazelier a écrit :
C'est un autre débat, tout aussi intéressant pour le coup. Xen a encore un écosystème dynamique ?
A priori oui.
https://www.openwall.com/lists/oss-security/2019/10/25/
Yep, c'est encore actif.
@+
Tout la stack virtu d'AWS est une base Xen, tout le cloud Oracle est en Xen, je pense qu'on peut dire que Xen est parti pour rester un certain temps en effet, et continuera à se developper (tranquillement, certes).
Pour en revenir à Vmware, personne n'utilise la stack d'orchestration Vmware à part Crédit Suisse parce que c'est eux qui l'ont codé au départ. A la limite vCloud à un gros intérêt au niveau du dev d'un portail de self care.
Par contre, si tu as suivi Vmworld cet été, tu peux tout faire en open à base d'Ansible + Terraform, et la stratégie de Vmware est de mixer VM et container dans une approche unifiée, et pour cela Vcenter va intégrer K8S dans les versions à venir. A ma connaissance, il n'y a pas d'autres plateformes qui propose un tel mix (et ne pas parler d'Openstack pour ça, parce que faire tourner cote à cote un K8S et un Nova, c'est pas ce que j'appelle "intégré") en natif.
Ton argument sur le pricing et la capexisation ne tient pas l'expérience pour le coup : 1) les plus gros trou d'anus qu'on s'est pris ces dernières années, c'est sur du hardware bien à l'ancienne genre Cisco / Juniper, ou d'un coup PAF, il a fallu des licences vérouillées pour faire papa/maman (cf le passage des LNS de 7200 à ASR ou MX, ou la licence est maintenant à l'utilisateur, et annuelle ... BIM).
2) toutes les plus grosses licornes ont eu un modèle Opex avant de basculer sur un modele Capex, et tout l'intéret d'une boite comme AWS ou AZURE c'est justement qu'il y a masse de client qui veulent Opexiser, car l'opex, ça varie à la hausse, mais aussi à la baisse, et la tendance ces dernières années et quand même grave baissière (sauf sur les licences Microsoft et Oracle On Premise, mais ça c'est structurel, tout le monde le sait)
3) c'est génial le CAPEX quand tu tires de la fibre optique, mais quand tu dois avoir des infras qui s'adaptent à tes besoins clients, qui peuvent augmenter ou baisser, l'Opex a cette souplesse qui te permet de pas te faire demonter la tréso quand un client résilie.
4) tu oublies dans ta démonstration la plus grosse source d'Opex dans une boite : l'humain. Et quand tu pars sur de la bonne grosse infra en propre, "gratuite car c'est Opensource", tu te bouffes l'OPEX humain en pleine tête, et c'est d'ailleurs pour cette raison qu'il y a autant de projet Openstack qui ont failed.
5) c'est génial de CAPEXiser, quand tu as de la finance qui te suit derrière et qui est capable de mettre au pot quand il faut upgrader. C'est pour ça que tant de startups partent sur de l'OPEX genre AWS and co, c'est parce que ça plait aux fonds d'invest de se dire qu'elles peuvent linéariser les dépenses = tout en frais variables, pas de frais fixes. Est-ce que c'est intelligent ? C'est une autre reflexion.
Bref, c'est pas parce qu'on fait de l'infra qu'il faut fuire les mode OPEX, et c'est pas parce qu'on CAPEXise tout qu'on a tout compris, bien au contraire.
Le lun. 28 oct. 2019 à 17:07, Jérôme Nicolle jerome@ceriz.fr a écrit :
Plop,
Le 28/10/2019 à 13:30, Raphael Mazelier a écrit :
C'est un autre débat, tout aussi intéressant pour le coup. Xen a encore un écosystème dynamique ?
A priori oui.
https://www.openwall.com/lists/oss-security/2019/10/25/
Yep, c'est encore actif.
@+
-- Jérôme Nicolle +33 6 19 31 27 14
Liste de diffusion du FRsAG http://www.frsag.org/
On Mon, Oct 28, 2019 at 10:59 AM Guillaume Barrot < guillaume.barrot@gmail.com> wrote:
Tout la stack virtu d'AWS est une base Xen, tout le cloud Oracle est en Xen, je pense qu'on peut dire que Xen est parti pour rester un certain temps en effet, et continuera à se developper (tranquillement, certes).
Toute la stack de virtualisation d'AWS _était_ une base Xen. Depuis 2017 et la sortie des instances C5, c'est une stack maison appelé Nitro qui a pris le relai ( http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html) avec un modèle hybride mélangeant de la virtualisation hard et soft. La maintenance des instances précédentes continue sous Xen, mais il n'y a plus de nouveaux développements. Arthur
On 28/10/2019 19:26, Arthur Petitpierre wrote:
Toute la stack de virtualisation d'AWS _était_ une base Xen. Depuis 2017 et la sortie des instances C5, c'est une stack maison appelé Nitro qui a pris le relai (http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html) avec un modèle hybride mélangeant de la virtualisation hard et soft. La maintenance des instances précédentes continue sous Xen, mais il n'y a plus de nouveaux développements.
Absolument. Et d'ailleurs même si globalement nous sommes plutôt satisfait de ces instances en terme de performance il y a certain workload que nous ne pouvons pas migrer car il subsiste des bugs (nos kafka à fort trafic notamment).
--
Raphael
Toute la stack de virtualisation d'AWS _était_ une base Xen.
Tout le reste semble rester en Xen, de ce que j'ai cru lire. Maintenant, vu la contrib d'AWS à Xen...
Sinon Xen se développe aussi dans l'embarqué. Et l'embarqué automobile en particulier.
Qube OS est fondé sur Xen également...
On Mon, Nov 4, 2019 at 12:49 PM Stéphane Rivière stef@genesix.org wrote:
Toute la stack de virtualisation d'AWS _était_ une base Xen.
Tout le reste semble rester en Xen, de ce que j'ai cru lire. Maintenant, vu la contrib d'AWS à Xen...
Seules les instances de génération antérieures ou égales à Haswell/Broadwell reste en Xen, ie on ne touche pas à des instances en production. Par contre tout ce qui sorti après C5 (skylake et ultérieur, AMD, ARM) utilise la stack Nitro, à l'exception de quelques instances GPU qui sont sorties en Xen en attendant le développement du support des GPUs dans Nitro, mais cela est réglé depuis la sortie des instances G4. A l'avenir, AWS n'introduira pas de nouvelles instances Xen mais continue de maintenir les existantes jusqu'à ce que les derniers clients aient migré sur des instances Nitro (et cela peut-prendre longtemps, cela ne fait pas très longtemps que les M1 ont été arrêtées même si elles n'étaient plus visibles dans les nouveaux comptes).
Arthur.
Seules les instances de génération antérieures ou égales à Haswell/Broadwell reste en Xen, ie on ne touche pas à des instances en production.
Ben oui...
Par contre tout ce qui sorti après C5 (skylake et ultérieur, AMD, ARM) utilise la stack Nitro, à l'exception de quelques instances GPU qui sont sorties en Xen en attendant le développement du support des GPUs dans Nitro, mais cela est réglé depuis la sortie des instances G4. A l'avenir, AWS n'introduira pas de nouvelles instances Xen mais continue de maintenir les existantes jusqu'à ce que les derniers clients aient migré sur des instances Nitro (et cela peut-prendre longtemps, cela ne fait pas très longtemps que les M1 ont été arrêtées même si elles n'étaient plus visibles dans les nouveaux comptes).
Oui c'est ça, dans dix ans, AWS tournera encore avec un minorité de Xen, à coté d'une majorité de Nitro, c'est à dire du KVM maison, comme ils ont fait du Xen maison.
Il est difficile d'estimer l'apport d'AWS à Xen : visibilité minimale de la part de AWS, peu de retour (connus) vers le libre mais par contre beaucoup de bullshit, genre :
"Most of the Xen vulnerabilities do not apply to AWS because the company has developed its own custom version of Xen. AWS has stripped out all the features of Xen that it doesn’t need, both in order to customize the performance of the open source code to the company’s unique use case, and to limit its exposure to vulnerabilities." (1)
Quand on connaît a minima l'archi de Xen, c'est le genre de prose qui laisse dubitatif. Évidemment, en interne AWS a une des meilleures compétence Xen de la planète mais n'en fait pas publicité.
AWS est connu pour bouffer du libre (elastic search) mais renvoyer l'ascenseur de façon /sélective/ (2). Après, les gens qui font du libre /et tentent d'en vivre/ n'ont pas à s'étonner de certaines dérives, inhérentes au concept (redis ou mongodb).
(1) https://www.networkworld.com/article/2892313/what-happens-inside-amazon-when...
(2) https://aws.amazon.com/fr/opensource/?opensource-all.sort-by=item.additional...
Avec 2000+ contribs sur projets libres et un peu plus de 400 projets sur https://github.com/awslabs, et... "0 results for repositories matching xen"
AWS est un acteur de l'open source mais, sur la page (2), Xen n'est cité que deux fois :
- Xen at Linux Foundation, Founding Advisory Member - Live-Updating Xen - Amit Shah & David Woodhouse
Doit-on croire que Xen est tellement stratégique pour AWS que l'information doit être restreinte, par crainte d'une dissémination d'un 'avantage compétitif' ?
Souhaitons en tout cas que via Nitro, KVM en profite.
On trouve ici, à l'usage de décideurs - c'est du non tech - la vision oss (et non pas free/libre software) d'AWS.
https://d1.awsstatic.com/Open%20Source/enterprise-oss-book.pdf
On Tue, Nov 5, 2019 at 1:02 AM Stéphane Rivière stef@genesix.org wrote:
Avec 2000+ contribs sur projets libres et un peu plus de 400 projets sur https://github.com/awslabs, et... "0 results for repositories matching xen"
AWS est un acteur de l'open source mais, sur la page (2), Xen n'est cité que deux fois :
- Xen at Linux Foundation, Founding Advisory Member
- Live-Updating Xen - Amit Shah & David Woodhouse
Doit-on croire que Xen est tellement stratégique pour AWS que l'information doit être restreinte, par crainte d'une dissémination d'un 'avantage compétitif' ?
Il y a aussi le fait que l'infrastructure AWS est très spécifique, et qu'un grand nombre des modifications apportées n'ont de sens que dans le contexte d'un hyperscaler. Mais sinon, oui, les améliorations apportés dans la stack de virtualisation font partie de ces avantages compétitifs considérés critiques.
Souhaitons en tout cas que via Nitro, KVM en profite.
Je ne parierais pas sur ce point: Nitro utilise une toute petite partie de KVM, uniquement en espace kernel. La majorité de Nitro se passe dans les dongles externes qui font l'émulation de devices hardware (EBS vu comme disques NVMe, interfaces réseau ENA, disques NVMe locaux), c'est là que se font la majorité des développements. Full disclosure: je suis Solutions Architect Specialist EC2 chez AWS ( arthurpt@amazon.com).
Cela dit, il y a aussi des projets AWS complètement open, comme firecracker: https://firecracker-microvm.github.io/ qui est un des moteurs d'exécution de Lambda. Arthur.
Mais sinon, oui, les améliorations apportés dans la stack de virtualisation font partie de ces avantages compétitifs considérés critiques.
Logique.
Je ne parierais pas sur ce point: Nitro utilise une toute petite partie de KVM, uniquement en espace kernel. La majorité de Nitro se passe dans les dongles externes qui font l'émulation de devices hardware (EBS vu comme disques NVMe, interfaces réseau ENA, disques NVMe locaux), c'est là que se font la majorité des développements.
Ok...
Full disclosure: je suis Solutions Architect Specialist EC2 chez AWS (arthurpt@amazon.com mailto:arthurpt@amazon.com).
Je me doutais d'un truc comme ça :) Tu dois avoir un job intéressant...
Un article qui explique des choses, en particulier la logique du passage de Xen vers Nitro. Comme tu le dis, les problématiques d'AWS ne sont pas celles de tout le monde et les réponses sont aussi hors du commun.
https://www.forbes.com/sites/janakirammsv/2019/03/10/how-an-acquisition-made...
Cela dit, il y a aussi des projets AWS complètement open, comme firecracker: https://firecracker-microvm.github.io/%C2%A0qui est un des moteurs d'exécution de Lambda.
J'avais regardé... M'étais dit que c'était une jolie manière (au sens de l'élégance de la solution et de la sécu) de tuer Docker...
On Wed, Nov 6, 2019 at 1:27 AM Stéphane Rivière stef@genesix.org wrote:
Full disclosure: je suis Solutions Architect Specialist EC2 chez AWS (arthurpt@amazon.com mailto:arthurpt@amazon.com).
Je me doutais d'un truc comme ça :) Tu dois avoir un job intéressant...
Un article qui explique des choses, en particulier la logique du passage de Xen vers Nitro. Comme tu le dis, les problématiques d'AWS ne sont pas celles de tout le monde et les réponses sont aussi hors du commun.
Un des posts les plus synthétiques sur la question est celui de Brendan Gregg (monsieur Perf chez netflix, ex-SUN, papa de Dtrace): http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html En bas du poste, il met une série assez complète de lien, en particulier celui-ci : https://www.youtube.com/watch?v=LabltEXk0VQ . Il s'agit de la présentation faite par Anthony Liguori (un des Principal Engineers à l'origine de Nitro) à re:Invent 2017, elle est assez claire et compréhensible.
Cela dit, il y a aussi des projets AWS complètement open, comme
firecracker: https://firecracker-microvm.github.io/ qui est un des moteurs d'exécution de Lambda.
J'avais regardé... M'étais dit que c'était une jolie manière (au sens de l'élégance de la solution et de la sécu) de tuer Docker...
Non, ce n'est pas le but du tout, le but est d'avoir un véhicule de virtualisation suffisamment léger pour se permettre de pouvoir mettre une fonction Lambda par VM (on ne fait pas confiance aux mécanismes d'isolation des containers pour l'isolation entre processus en terme de sécurité). Avec Firecracker, on a des VMs dont le temps de démarrage est de quelques dizaines de ms, et l'overhead mémoire de quelques dizaines de Mo, donc on peut se permettre d'en lancer un très grand nombre par instance. En résumé, ça ne poursuit pas le même but, et concrètement on continue à wrapper des containers à l'intérieur, par ce que le container docker est un véhicule d'exécution/packaging très efficace. Donc c'est plus à voir comme un outil complémentaire que comme un outil concurrent. Et pour AWS, une grande partie de la valeur associée est plus dans le control-plane (ie les moyens pour orchestrer cela à grande échelle, que dans la micro-VM en elle même).
Arthur
Un des posts les plus synthétiques sur la question est celui de Brendan
Super post qui résume magnifiquement l'évolution... Merci !
Non, ce n'est pas le but du tout, le but est d'avoir un véhicule de virtualisation suffisamment léger pour se permettre de pouvoir mettre une fonction Lambda par VM (on ne fait pas confiance aux mécanismes
.../...
Donc c'est plus à voir comme un outil complémentaire que comme un outil concurrent.
Merci également pour l'explication, c'est bien plus clair ainsi :)
C'est un autre débat, tout aussi intéressant pour le coup. Xen a encore un écosystème dynamique ?
J'osais pas intervenir mais nous, Xen, depuis près de 10 ans, ça roule...
Pas le Xen Server (un produit commercial de Citrix)
Le vrai Xen libre... ( Xen-XL ) Avec Debian (par exemple). Couplé à du RAID et LVM. C'est très frugal et ultra stable.
En 2020, on va regarder pour faire mieux,dans la continuité, avec Ganeti par dessus.
Hello,
Le 4 nov. 2019 à 21:45, Stéphane Rivière stef@genesix.org a écrit : En 2020, on va regarder pour faire mieux,dans la continuité, avec Ganeti par dessus.
A ma connaissance, Google ne met plus vraiment de ressources (dev) sur Ganeti, qui est un projet plus ou moins mort (y’a qu’à voir le dernier commit sur git).
Fabien
lundi 4 novembre 2019, 22:32:26 CET Fabien Germain wrote:
A ma connaissance, Google ne met plus vraiment de ressources (dev) sur Ganeti, qui est un projet plus ou moins mort (y’a qu’à voir le dernier commit sur git).
C’est pas faux, il me semble que les devs voulaient plus ou moins laisser les rênes à la communauté. Cependant, le dernier commit date d’août, c’est pas complètement mort non plus. En tout cas, j’espère pas, toute mon infra étant basée dessus. Ceci dit, ça tourne bien, j’ai plus les bugs que j’avais eu (https://fiat-tux.fr/tag/ganeti/).
A ma connaissance, Google ne met plus vraiment de ressources (dev) sur Ganeti, qui est un projet plus ou moins mort (y’a qu’à voir le dernier commit sur git).
Non, ça c'était avant. Ca reprend, sans Google. Il y a pas mal d'infras qui tournent avec Ganeti et Xen.
Mais c'est comme certains langages peu "marketables", mais qui procurent un avantage compétitif. À la limite, à défaut d'avoir pu/su convaincre la communauté, ça devient une sorte de 'secret industriel' au bénéfice des utilisateurs discrets qui n'ont même plus envie d'en parler...
Ca été ça pendant des années avec Xen (qui n'était même pas dans le noyau Debian il n'y a pas si longtemps, fallait tout recompiler)... Xen a été déclaré 'canard mort' cent fois...
Comme (presque tout) est l'effet de la mode en info, les langages typés redeviennent visible, il devient 'hype' de critiquer le 'tout objet' et le fonctionnel revient sur le devant de la scène.
Maintenant, Ganeti, on va tester et, bon ou mauvais, on fera un retex...
Je dois admettre qu'un mec qui me sort un discours aussi bourré de dogmes que le tient, je le fous à la porte direct. Du coup, effectivement, je n'ai pas les mêmes problèmes que toi.
Sinon, contacte Apalia (https://www.apalia.net/) de ma part, c'est leur métier de faire ce genre de choses, ils ont 15+ années d'XP sur le sujet, toutes solutions confondues, ils maintiennent notamment la plateforme CloudStack qu'on avait monté chez Beton Tel pour faire du firewall coeur de réseau en VM en 2011 (du NFV avant que cela ne s'appelle du NFV), bref, ils sauront répondre à ton besoin y compris les innombrables dev intermediaires que tu devras faire pour faire tomber en marche ta plateforme.
Bon courage surtout.
Le dim. 27 oct. 2019 à 15:09, Jérôme Nicolle jerome@ceriz.fr a écrit :
Salut Guillaume,
Le 27/10/2019 à 14:47, Guillaume Barrot a écrit :
Tu as regardé le pricing VSPP de Vmware (pas de cout de licence, tu payes à l'usage uniquement) ?
Depuis quand c'est une bonne idée de perdre du temps à moduler les politiques de licensing - et de les intégrer dans l'ERP pour analyser les coûts et marges - plutôt que de CAPXiser tout ce qui peut l'être ? On fait de l'infra ou pas ?
Clairement pour moi le sujet sur la virtu, maintenant ce sont les outils, non pas l'hyperviseur (c'est du commodity).
Justement, KVM, LXD ou ESXi, j'en ai rien à carrer, ce qui compte c'est la robustesse et la maîtrise des coûts. Quand un éditeur proprio modifie son pricing ça casse un business-case produit et ça fait bosser les gens du marketing - doux antonyme, d'où problème. Donc si je veux faire marcher une offre, j'ai besoin de visibilité à moyen terme au moins, et les éditeurs ne me le garantissent pas.
Un truc comme VSAN+NSX déjà rapporte enormement en terme de facilité d'usage, cout en equipement réseau, etc (typiquement, des switchs FS avec un simple VLAN à plat suffise vu que tu geres tout en VXLAN sur les hyperviseurs), plus besoin de baie de stockage (même en full flash, VSAN est quasi imbattable en terme de prix, si tu sais bien choisir tes SSD).
Si je comprends bien, tu préconises de remplacer le backbone par des multiprises, et de perdre le contrôle des flux réseau ? Tu sentiras une certaine réticence de ma part sur ce point, mais faire tourner des vVTEP sur les hyperviseurs quand t'as la feature câblée en dur dans des ASIC de tes ToR, c'est pas trop coûteux en terme de power et CPU ?
Après multiples études, et une tentative complétement foireuse chez JN en Openstack (qui s'est revele 2 à 3 fois plus couteux que la plateforme VMware existante même en la mettant à jour), on a adopté ce modèle, y compris sur les uCPE qu'on fait tourner ESXi. Pour dire.
J'ai aussi vu une majorité d'expériences douloureuses avec OpenStack, c'est pour ça que je n'ai pas envie d'y aller. Et c'est aussi pour ça que Open Nebula me semble être un bon compromis, en tout cas sur le papier.
Par contre, faire dépendre 100% de ma prod d'un seul et unique éditeur de closed-source, sans prévoir d'alternative, c'est hors de question. Créer - ou laisser faire - un risque vital pour la boîte ne fait pas partie de mes attributions.
Je suis d'ailleurs inquiet qu'un tel choix ait pu être fait chez JN, j'ai besoin de plus d'éléments pour en comprendre la rationalité. Tu en as ?
@+
-- Jérôme Nicolle +33 6 19 31 27 14
Salut Guillaume,
Le 27/10/2019 à 19:46, Guillaume Barrot a écrit :
Je dois admettre qu'un mec qui me sort un discours aussi bourré de dogmes que le tient, je le fous à la porte direct.
Ouais, pareil. Mais quand on a la responsabilité d'un budget et d'une rentabilité comme nous c'est pas anormal de se poser ces questions, tu crois pas ?
Ce qui me dérange, parce que ça crée un risque économique, c'est le fournisseur qui change ses tarifs quand et comme bon lui semble alors que tu es pieds et point liés avec. Ça vaut pour un logiciel central comme pour des cross-connects en datacenter…
Du coup, effectivement, je n'ai pas les mêmes problèmes que toi.
Ou plus exactement tu as arbitré en faveur d'un risque de dépendance fournisseur par rapport à celui d'un presta ou de tes RH qui se poserait si tu devais intégrer quelque chose de moins répandu, non ?
Sinon, contacte Apalia (https://www.apalia.net/) de ma part, c'est leur métier de faire ce genre de choses, ils ont 15+ années d'XP sur le sujet, toutes solutions confondues, ils maintiennent notamment la plateforme CloudStack qu'on avait monté chez Beton Tel pour faire du firewall coeur de réseau en VM en 2011 (du NFV avant que cela ne s'appelle du NFV), bref, ils sauront répondre à ton besoin y compris les innombrables dev intermediaires que tu devras faire pour faire tomber en marche ta plateforme.
Bon courage surtout.
Merci, je regarde ça !
@+
Salut,
Tu as aussi Apache CloudStack qui est un modèle plus intégré par rapport à Open Stack. Il permet de faire de l'IaaS sur du KVM / Xen / Vmware / HyperV
J'ai participé à ce projet (en tant que dev) et je continue à gérer des plates-formes CloudStack depuis 2013 (sur KVM principalement).
Il y a une communauté active et stable avec une société (ShapeBlue) qui propose un très bon support (et dont bcp de membre de l'équipe sont des contributeurs sur le projet)
https://cloudstack.apache.org/
Les sociétés qui utilisent CloudStack: https://cloudstack.apache.org/users.html
A+
On 27/10/2019 12:28, Jérôme Nicolle wrote:
Salut Guillaume,
Le 27/10/2019 à 11:05, Guillaume Barrot a écrit :
Ton mail m'a permis de me rendre compte que ce projet existait encore alors que je le pensais mort et enterré depuis 3 ans. Un point pour toi du coup.
Après, est-ce bon signe ?
https://github.com/OpenNebula/one/graphs/code-frequency
C'est pas le projet le plus actif que je connaisse, mais je le trouve plutôt stable en terme d'activité.
Le truc c'est que je ne trouve pas d'équivalent sur le plan fonctionnel.
OpenStack est trop lourd à mettre en place (à mon goût en tout cas) et n'interopère pas avec beaucoup de chose sans une bonne dose d'huile de co(u)de.
Les box "all-inclusive" à la nutanix laissent peu de contrôle et ont un modèle de licensing qui peut devenir aussi confiscatoire que celui de VMWare.
Proxmox fait trop et pas assez à la fois, et j'aurais pas confiance pour de la prod critique à 1000 cœurs et 6-8To de RAM.
Du coup, garder un bout de VMWare "legacy" (pour le windows ou les trucs voués à mourrir) et rebuild le reste sur une plate-forme plus versatile, ça paraît être un compromis séduisant.
Mais j'ai vraiment pas l'impression que ce soit très utilisé par chez nous…
Après s'il y a des arguments additionnels pour telle ou telle option, ou des alternatives, je suis ouvert à toute préco !
@+
Je suis tombé là dessus, visiblement le bon coin en utilise...
https://medium.com/leboncoin-engineering-blog/infrastructure-as-a-service-le...
Le 26 octobre 2019 19:21:27 GMT+02:00, "Jérôme Nicolle" jerome@ceriz.fr a écrit :
Plop,
Je suis à la recherche de retours d'expérience sur Open Nebula, plus spécifiquement à savoir comment se passent :
- Passage de vCenter / vSphere à Open Nebula et/ou cohabitation
- Conversion de VMs de ESX vers KVM - et rollback
- Net : routage et annonce des préfixes des VMs par les HV
- Backup, offload ou full remote de VM entre instances et des des
clouds publics
Y a t il des barbus du domaine dans la salle ?
Merci !
-- Jérôme Nicolle +33 6 19 31 27 14 _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Arthur Petitpierre -
Fabien Germain -
Guillaume Barrot -
Jean-Yves LENHOF -
Jérôme Nicolle -
Luc Didry -
Milamber -
Raphael Mazelier -
Stéphane Rivière