Solutions VMs zero downtime / fault tolerent
Bonjour à tous, allez c'est l'été, je pose une colle :-) Comment gérez-vous une infra zero downtime / fault tolerent ? Pour situer le périmètre, je parle dans un contexte de virtualisation, du fait que l'ensemble de vos VMs continuent à fonctionner sans avoir subi de reboot suite à un crash de l'hyperviseur qui les héberge, donc dans un cas de disaster recovery uniquement. Autrement dit, un RTO RPO de 0 précisément. Dans le monde opensource il ne semble plus y avoir grand chose, les projets ayant été abandonnés. Dans le monde propriétaire, il y a VMware et leur Fault Tolerent (mais il y a des contraintes fortes du style nombre de VMs, de vCPU par hyperviseur, etc). Dans le monde de l'hyperconvergeance il y a des solutions type Dell EMC VxRail, certainement Nutanix et compagnie. Quel est votre retour d'expérience vécue sur le sujet ? Je ne prends même pas en compte l'aspect financier car hyperconvergeance = quelques lingots d'or en général sans autre forme de débat :-) Merci à vous. -- Gregory Poudrel
Le samedi 27 juillet 2019, 10:18:29 CEST Grégory Poudrel a écrit :
Bonjour à tous,
allez c'est l'été, je pose une colle :-)
Comment gérez-vous une infra zero downtime / fault tolerent ? Pour situer le périmètre, je parle dans un contexte de virtualisation, du fait que l'ensemble de vos VMs continuent à fonctionner sans avoir subi de reboot suite à un crash de l'hyperviseur qui les héberge, donc dans un cas de disaster recovery uniquement. Autrement dit, un RTO RPO de 0 précisément. [...]
Bonjour, Désolé, je ne vais pas répondre à la question, mais juste dire que de nos jours (Cloud...) la réponse n'es plus dans l'infrastructure mais dans les applications. Avec une application dont l'architecture logicielle est redondante, on peut dire "Cloud Native", tu peut atteindre du TRO/RPO faible sur des machines standard, quelconque sans garantie de SLA. Et surtout au delà des pannes, on doit quand même redémarrer les applis et les système pour les mises à jour, dans ce cas, pouvoir faire du rolling upgrade sur plusieurs machines, l'une après l'autre sans interruption de service. Bref, s'il n'y a plus beaucoup de solution de fault tolerance (VMware doit toujours avoir ça), c'est peut-être que simplement ça n'a plus d'utilité sur les nouveaux environnements applicatifs (Cloud native apps, Kubernetes...). Bonne journée, PS: Je ne crois pas aux miracle, et RTO=RPO=0, dans un cadre de PRA, à moins d'avoir aucune exigence de perf, je n'y crois pas (théorème CAP).
Il n'y a pas que le HTTP dans la vie Le cloud n'est rien de plus que des VM chez un fournisseur tiers, c'est la définition technique et la réalité +1 pour cap, ceci dit On 07/27/2019 01:01 PM, Gilles Mocellin wrote:
Le samedi 27 juillet 2019, 10:18:29 CEST Grégory Poudrel a écrit :
Bonjour à tous,
allez c'est l'été, je pose une colle :-)
Comment gérez-vous une infra zero downtime / fault tolerent ? Pour situer le périmètre, je parle dans un contexte de virtualisation, du fait que l'ensemble de vos VMs continuent à fonctionner sans avoir subi de reboot suite à un crash de l'hyperviseur qui les héberge, donc dans un cas de disaster recovery uniquement. Autrement dit, un RTO RPO de 0 précisément. [...]
Bonjour,
Désolé, je ne vais pas répondre à la question, mais juste dire que de nos jours (Cloud...) la réponse n'es plus dans l'infrastructure mais dans les applications.
Avec une application dont l'architecture logicielle est redondante, on peut dire "Cloud Native", tu peut atteindre du TRO/RPO faible sur des machines standard, quelconque sans garantie de SLA.
Et surtout au delà des pannes, on doit quand même redémarrer les applis et les système pour les mises à jour, dans ce cas, pouvoir faire du rolling upgrade sur plusieurs machines, l'une après l'autre sans interruption de service.
Bref, s'il n'y a plus beaucoup de solution de fault tolerance (VMware doit toujours avoir ça), c'est peut-être que simplement ça n'a plus d'utilité sur les nouveaux environnements applicatifs (Cloud native apps, Kubernetes...).
Bonne journée,
PS: Je ne crois pas aux miracle, et RTO=RPO=0, dans un cadre de PRA, à moins d'avoir aucune exigence de perf, je n'y crois pas (théorème CAP).
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Il n'y a pas que le HTTP dans la vie
+1
Le cloud n'est rien de plus que des VM chez un fournisseur tiers, c'est la définition technique et la réalité
+1
Comment gérez-vous une infra zero downtime / fault tolerent ? Pour situer le périmètre, je parle dans un contexte de virtualisation, du fait que l'ensemble de vos VMs continuent à fonctionner sans avoir subi de reboot suite à un crash de l'hyperviseur qui les héberge, donc dans un cas de disaster recovery uniquement. Autrement dit, un RTO RPO de 0 précisément. [...]
Des fois des mise à jour nécessite des reboot et comme c'est l'été, c'est la fête aux CVE : mysql et consors, kernels (linux, et autres), etc.... etc.... Donc il faut des fois rebooter la vm ne serait-ce que pour voir si elle résiste au disaster recovery (ex: le putain de service qui ne démarre pas) :)
Désolé, je ne vais pas répondre à la question, mais juste dire que de nos jours (Cloud...) la réponse n'es plus dans l'infrastructure mais dans les applications.
+1000
Avec une application dont l'architecture logicielle est redondante, on peut dire "Cloud Native", tu peut atteindre du TRO/RPO faible sur des machines standard, quelconque sans garantie de SLA.
Considérer tout les vm / hardware peux cramer c'est prévoir une archi logicielle redondante. Le pb c'est bcp de monde pensent que le cloud ça ne se viande jamais et que ca marchera toujours... ce qui est un postulat faux de base. Les downtimes dû à un hardware qui a fait plonk sont généralement plus bas, mais ils existent...
Et surtout au delà des pannes, on doit quand même redémarrer les applis et les système pour les mises à jour, dans ce cas, pouvoir faire du rolling upgrade sur plusieurs machines, l'une après l'autre sans interruption de service.
+1 :)
Bref, s'il n'y a plus beaucoup de solution de fault tolerance (VMware doit toujours avoir ça), c'est peut-être que simplement ça n'a plus d'utilité sur les nouveaux environnements applicatifs (Cloud native apps, Kubernetes...).
+1 aussi. Même le vmware ha est des fois pas sec. Conclusion, autant prévoir l'infra redondante by the code que par l'hyperviseur :)
Je ne crois pas aux miracle, et RTO=RPO=0, dans un cadre de PRA, à moins d'avoir aucune exigence de perf, je n'y crois pas (théorème CAP).
:) /Xavier
Le sam. 27 juil. 2019 à 13:23, <frsag@jack.fr.eu.org> a écrit :
Il n'y a pas que le HTTP dans la vie
+1 aussi là dessus. Certaines applis ne sont pas "cloud native". Et quand il n'y a pas de concurrent à l'éditeur, il continue d'écrire son appli comme s'il vivait dans le monde des bisounours, en imaginant un OS qui n'a jamais besoin de s'arrêter. Cela dit , j'ai eu à gérer des applis qui nécessitaient un RTO=RPO=0, à certains moments. Par exemple, une appli de SAMU, peut être arrêtée à certains moments, mais surtout pas à d'autres (par exemple, lorsqu'il y a un gros carton sur l'autoroute, ou un festival à proximité). Le RTO=RPO=0 est donc bien présent sur CE moment là.. ce qui n'empêche pas d'avoir droits à des fenêtres de Downtime préparées (et annulable par le chef de plateau SAMU jusqu'à la dernière seconde si un appel arrive !) Pour le coup, on blinde comme on peu : de l'oracle en bdd (entre 2005 et 2015, c'était encore pertinent), du sun Solaris en OS (bha oui, c'est putain de costaud ce truc !), le tout hébergé sur de l'ESX en faultTolerance, avec metrocluster, etc...Ça coute cher pour une appli, mais une vie n'a pas de prix. Donc, dire que le monde désormais, c'est des smarts appli, modulables, scalables, etc.. c'est ignorer qu'il existe autre chose que les webservices. De "vieilles" applis existent encore car il y a des choses qui mettent du temps à changer.
Et n'oublions pas que le "webservice", c'est du jetable Connexion tcp courte durée, stateless, qui peut être reexecutée si nécessaire etc Il y a beaucoup de chose qui ne correspondent pas à cette description, ce n'est pas qu'une question de "retard" technologique Dans le monde du cloud publique, on les nommes "services managés" On 07/27/2019 10:05 PM, Olivier Vailleau wrote:
Donc, dire que le monde désormais, c'est des smarts appli, modulables, scalables, etc.. c'est ignorer qu'il existe autre chose que les webservices. De "vieilles" applis existent encore car il y a des choses qui mettent du temps à changer.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Comment gérez-vous une infra zero downtime / fault tolerent ?
Au niveau open source, en vraie HA (pas du heartbeat à bascule), y'a des soluces autour de Xen, on avait testé ça en 2010. Le vrai Xen libre, pas le XenServer proprio (qui a ce qu'il faut de son coté je crois mais qui a d'autres limites aussi, sans compter le coût). Ca nécessite un max de débit entre les machines physiques (nous on avait 2x1 Gbps bindées par serveur). Le résultat n'était pas rapide en soit (mais c'était un lab avec des CM intel à 40 €, des CPU genre dual-core et au max 2 à 4 Go de ram + des RAID10 de 4x2 To WD black pro). Il était poilant de voir un dl de plusieurs Go se freezer un temps imperceptible (genre 2/10ème de seconde) et reprendre alors qu'on venait (au choix) d'arracher la prise secteur d'un des serveurs, enlever à chaud une barette ram, un câble sata ou même - on l'a fait - sortir un CPU sous tension... C'était fondé sur Xen, remus et drdb. Voir aujourd'hui du coté de Ganeti (ma prochaine infra en 2020, les gens en ont l'air content) ou de tout autres soluces (Suze en a aussi autour de Xen mais je ne connais). Ce qu'il faut retenir c'est que la vraie HA, avec ce coté poilant de "machine immortelle" peut être scalé (histoire de sécu, en mode minimal, c'est 2, normal c'est 3, en mode nucléaire c'est 4 dédiés physiques minimum pour assurer la continuité de service d'un seul dédié aec toutes ses VM) mais avec un coût (non négligeable) de perf ou de matos haut de gamme. À réserver à l'application qui l'exige. - Evangélisme Xen Je parle de Xen uniquement car j'ai abandonné tout autre virtu serveurs depuis 10 ans. C'est ultra léger*, Debian natif et impeccablement fiable. En plus ça rebouge bien depuis 5 ans. Donc c'est parfait (pour moi). * Mes sauvegardes secondaires (genre des lots de 500 Mo avec Burp) tournent sur des OVH/KS avec des Atom 2600, 4 Go et 2 To pour un hyperviseur et deux VM... Et ça gaze parfaitement. Sinon sur des gros serveurs OVH de techno 2013 (on va renouveler en 2020), ça bronche pas non plus. Des uptimes de deux ans sur une machine avec 12 VM dont certaines sont chargées sont juste normaux. J'avais testé 8,5 Gbps entre l'hyper et les VM et 4,5 Gbps entre deux VM (je n'ai pas de VM de routage, c'est l'hyperviseur Xen/Linux - bien paramétré au niveau réseau, bridge, fw et sysctl qui fait le job = on gagne bien perf avec en gros seulement 3 fichiers de paramètres à gérer : sysctl, network et firewall). - Limites du cloud et des dédiés (pardon machines on-prem :) Le cloud c'est cher et ça tombe aussi, parfois plus qu'un pool de dédié bien géré. C'est pas la solution miracle. Dire que la réponse n'est pas (aussi) dans l'infra sous entend qu'on a des applics standard ou des trucs qu'on a dockerisés en prenant le temps, un déficit de compétence en infra et qu'on est prêt à mettre plus d'argent que nécessaire dans l'infra : la nécessité faisant loi, on prend du cloud dans ce cas car c'est la solution (no war, ça évite un animal chiant nommé l'adminsys et son salaire). Le dédié, c'est pas cher et très performant mais ça demande de l'expertise, donc de la veille et du temps, donc ça coûte aussi - mais l'indépendance et la maîtrise ont un prix, c'est donc une affaire de stratégie... -- Be Seeing You Number Six
- Précisions Les choses ont également évolué avec Xen de ce coté et COLO permet d'obtenir de bien meilleures perfs que REMUS https://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping -- Be Seeing You Number Six
Bonjour tout le monde,
Des uptimes de deux ans sur une machine avec 12 VM dont certaines sont chargées sont juste normaux. J'avais testé 8,5 Gbps entre l'hyper et les VM et 4,5 Gbps entre deux VM (je n'ai pas de VM de routage, c'est l'hyperviseur Xen/Linux - bien paramétré au niveau réseau, bridge, fw et sysctl qui fait le job = on gagne bien perf avec en gros seulement 3 fichiers de paramètres à gérer : sysctl, network et firewall).
J'ai une petite question justement dans ce cas, utilises-tu OVS (Open vSwitch) pour avoir une partie un peu magique du réseau ou comment l'as-tu fait ? Debian + Xen va devenir ma nouvelle installation pour remplacer l'actuel XCP : problème de perf parce que trop vieux au niveau de certains paquets (sans parler des paquets pour Ceph) Dans le même temps, je pense supprimer les vm de firewall/routing (opnsense) pour gagner en performance et je pensais justement à la combinaison d' Open vSwitch et Open Virtual Network. Y aurait-il des personnes qui auraient mieux pour la HA que cette combinaison ? Cordialement
Bonsoir Florent, Le 27/07/2019 à 19:35, Florent CARRÉ a écrit :
J'ai une petite question justement dans ce cas, utilises-tu OVS (Open vSwitch) pour avoir une partie un peu magique du réseau ou comment l'as-tu fait ?
Tout bêtement sur l'hyperviseur un sysctl.conf aux oignons, une config très particulière au niveau réseau (avec 16 bridges) me permettant de récupérer tout un /28 sans les 3 habituels perdus pour rien, et un script firewall cossu qui gère la géoloc IP. Et enfin pour les réseaux internes entre VM autant de dummy que nécessaire... C'est con, mais c'est cossu (c) Audiard. Tu trouveras une version du setup de 2016 ici qui explique tout... https://stef.genesix.org/pub/serveur_Debian_8_-_Genesix_v2_-_Installation.pd... Je dois transcrire vers networkd/systemd du coté de pointopoint (interfaces) vs [peer] + nftables : c'est prévu en 2020 avec debian X.
Debian + Xen va devenir ma nouvelle installation pour remplacer l'actuel XCP : problème de perf parce que trop vieux au niveau de certains paquets (sans parler des paquets pour Ceph) Dans le même temps, je pense supprimer les vm de firewall/routing (opnsense) pour gagner en performance et je pensais justement à la combinaison d' Open vSwitch et Open Virtual Network.
Ma soluce est KISS mais je ne sais pas si c'est approprié pour tes objectifs. -- Stéphane Rivière Ile d'Oléron - France
Hello Stéphane, Merci beaucoup pour les précisions et le lien En fait, ce que je cherche à faire est un peu bizarre : Un seul gros Open vSwitch qui va mettre les mêmes ranges IP sur les hyperviseurs, remplacer les vm de routage par l'Open Virtual Network et donc faire avec les flow. J'ai envie de virer le maximum de l'iptables/nftables quand ça ne concerne pas l'hyperviseur lui-même. C'est une folie de plus à mon compteur mais qui pourrait aider les migrations à chaud comme tout ce fait sur l'OVS/OVN. Est-ce vraiment fou ? Excellente journée/soirée (dépend du fuseau horaire) On Sat, Jul 27, 2019, 14:24 Stéphane Rivière <stef@genesix.org> wrote:
Bonsoir Florent,
Le 27/07/2019 à 19:35, Florent CARRÉ a écrit :
J'ai une petite question justement dans ce cas, utilises-tu OVS (Open vSwitch) pour avoir une partie un peu magique du réseau ou comment l'as-tu fait ?
Tout bêtement sur l'hyperviseur un sysctl.conf aux oignons, une config très particulière au niveau réseau (avec 16 bridges) me permettant de récupérer tout un /28 sans les 3 habituels perdus pour rien, et un script firewall cossu qui gère la géoloc IP. Et enfin pour les réseaux internes entre VM autant de dummy que nécessaire... C'est con, mais c'est cossu (c) Audiard.
Tu trouveras une version du setup de 2016 ici qui explique tout...
https://stef.genesix.org/pub/serveur_Debian_8_-_Genesix_v2_-_Installation.pd...
Je dois transcrire vers networkd/systemd du coté de pointopoint (interfaces) vs [peer] + nftables : c'est prévu en 2020 avec debian X.
Debian + Xen va devenir ma nouvelle installation pour remplacer l'actuel XCP : problème de perf parce que trop vieux au niveau de certains paquets (sans parler des paquets pour Ceph) Dans le même temps, je pense supprimer les vm de firewall/routing (opnsense) pour gagner en performance et je pensais justement à la combinaison d' Open vSwitch et Open Virtual Network.
Ma soluce est KISS mais je ne sais pas si c'est approprié pour tes objectifs.
-- Stéphane Rivière Ile d'Oléron - France
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 28 juil. 2019 à 18:56, Florent CARRÉ <colundrum@gmail.com> a écrit :
Hello Stéphane,
Merci beaucoup pour les précisions et le lien
En fait, ce que je cherche à faire est un peu bizarre : Un seul gros Open vSwitch qui va mettre les mêmes ranges IP sur les hyperviseurs, remplacer les vm de routage par l'Open Virtual Network et donc faire avec les flow. J'ai envie de virer le maximum de l'iptables/nftables quand ça ne concerne pas l'hyperviseur lui-même. C'est une folie de plus à mon compteur mais qui pourrait aider les migrations à chaud comme tout ce fait sur l'OVS/OVN.
Est-ce vraiment fou ?
Je sais pas, mais j’en profite pour ajouter une question dont je n’ai pas encore pris la peine de cherche la réponse: y a-t-il un moyen d’interconnecter les vSwitch de plusieurs hyperviseurs nativement (par un mécanisme type tunnel auto-magique, donc sans passer par un bridge utilisant les ports physiques de l'hôte) afin que les VM soient sur le « même » LAN ? Merci
Est-ce vraiment fou ?
Je ne sais pas :) Je ne crois pas avoir le niveau pour en juger. De ma lorgnette Xen, que ça soit compatible XenServer (proprio) et Xen (libre) et le topo sur wikipedia donne envie de regarder. Depuis l'abandon de la stack Xen XM pour la stack Xen XL, le réseau est laissé de coté par Xen. C'est un bien, car avant c'était tout un tas de scripts 'automagiques' qui montaient un intranet de VM plug and play simpliste. Depuis la stack XL, c'est à l'admin de construire son réseau. Et c'est (imho) mieux. Même si c'est rebutant pour débuter. Il semble qu'OVS peut combler cet espace... Mais les exemples ci-dessous, quoique très intéressants, me laissent sur ma faim, IP FO unique, natting, vm de routage... c'est pas mon setup exploitant tout un /28 sans perte d'IP et permettant par exemple d'héberger un PABX sur une IP du /28 (puisque j'ai jamais réussi à poser un PABX sur une VM nattée - merci M. SIP et ses flux en RTP). https://blog.debugo.fr/virtualisation-xen-openvswitch-debian-8-jessie https://blog.debugo.fr/tuto-virtualisation-v-2018-xen-openvswitch-debian-9 https://wiki.xenproject.org/wiki/Xen_Networking#Open_vSwitch
Excellente journée/soirée (dépend du fuseau horaire) Bah, sur Oléron, c'est toujours bien, la nuit comme le jour :)
-- Stéphane Rivière Ile d'Oléron - France
Merci de vos retours. C'est toujours intéressant d'avoir des avis. Rassurez-vous, RPO=RTO=0 restera un mythe :-) Bonne journée, -- Gregory Poudrel
Le Sun, Jul 28, 2019 at 11:58:56PM +0200, Stéphane Rivière [stef@genesix.org] a écrit: [...]
De ma lorgnette Xen, que ça soit compatible XenServer (proprio) et Xen (libre) et le topo sur wikipedia donne envie de regarder.
Attention à ne pas confondre la distribution binaire XenServer (devenu "Citrix Hypervisor") fournie par Citrix, avec une version gratuite maintenant assez limitée ( 7.x ) et la distribution "source", reprise par le projet XCP-NG (qui n'ont eu que relativement peu de choses à réécrire). Les 2 utilisant le même hyperviseur Xen que celui que tu appelles "libre", et la stack "XAPI" (xe) :) ( sur une install XenServer, quand les outils "xe" ne s'en sortent plus, tu peux toujours faire des cochoncetés locales avec "xl" :) ) Et pour ceux qui font déjà du libvirt/virsh il y a aussi un "pilote" qui utilise libxl ;-) -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Attention à ne pas confondre la distribution binaire XenServer (devenu "Citrix Hypervisor") fournie par Citrix, avec une version gratuite maintenant assez limitée ( 7.x ) et la distribution "source", reprise
Ces deux là sont la même chose : XenServer, dont une version 'gratuite' effectivement terriblement limitée, après des années de 'libération' des sources...
par le projet XCP-NG (qui n'ont eu que relativement peu de choses à réécrire).
De facto.
Les 2 utilisant le même hyperviseur Xen que celui que tu appelles "libre", et la stack "XAPI" (xe) :)
C'est ça. Ben oui, Xen est libre... Je n'utiliserais jamais XenServer (c'est pas libre ni debianisable), donc jamais xe... J'avais tenté une fois, mais bon... Sous debian : raid soft + lvm + xen + network + netfilter tout en console et on peut se faire quelque chose de très joli et scriptable (question de formation, je suis sûr qu'on doit pouvoir faire la même chose avec XenServer - y compris la partie raid soft + lvm mais ça n'avait pas l'air gagné avec la version gratuite mais je ne maîtrise pas du tout la distrib utilisée par XenServer... )
( sur une install XenServer, quand les outils "xe" ne s'en sortent plus, tu peux toujours faire des cochoncetés locales avec "xl" :) )
Ici ce fut xm, puis désormais xl... et, étant moi-même un cochon, je n'avais jamais compris pourquoi xl me plaisait autant :)
Et pour ceux qui font déjà du libvirt/virsh il y a aussi un "pilote" qui utilise libxl ;-)
Ca doit être super pour ceux qui ont des milieux hétérogènes :) -- Be Seeing You Number Six
participants (9)
-
David Ponzone -
Dominique Rousseau -
Florent CARRÉ -
frsag＠jack.fr.eu.org -
Gilles Mocellin -
Grégory Poudrel -
Olivier Vailleau -
Stéphane Rivière -
Xavier Beaudouin