Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Hello,
Je test actuellement un cluster Proxmox 6.4
6.4 ? 6.2 plutot ? ou 5.4 ?
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé.
quand tu dit, le noeud est brutalement stoppé, tu veux dire crash,poweroff ? Parce que dans ce cas, les vms sont coupées également. (et la HA les redémarre sur un autre noeud, au bout de 1 à 2min).
il n'y a pas de fault-tolerence dans proxmox. (où la vm mémoire de la vm est repliquée en permanence sur un autre noeud, et permet de basculer sans coupure). Ca existe dans qemu en beta-alpha (projet COLO: [ https://wiki.qemu.org/Features/COLO | https://wiki.qemu.org/Features/COLO ] ), mais pas encore implémenté dans proxmox. (et même dans qemu, je ne sais pas si c'est déjà stable)
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production. Existe il un moyen de palier ce problème ?
Pas moyen de baisser le timeout, principalement pour de stabilité du cluster, pour ne pas killer les noeuds trop vite en cas de flap réseau.
De: "Racamier Stéphane" racamier.steph@gmail.com À: "French SysAdmin Group" frsag@frsag.org Envoyé: Mardi 16 Juin 2020 22:55:11 Objet: [FRsAG] [TECH] Cluster proxmox hyper convergé
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
as-tu bien configuré le quorum du cluster ?
Richard
De : FRsAG frsag-bounces@frsag.org De la part de Racamier Stéphane Envoyé : mardi 16 juin 2020 22:55 À : French SysAdmin Group frsag@frsag.org Objet : [FRsAG] [TECH] Cluster proxmox hyper convergé
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Salut,
Je ne comprends pas trop le problème. Normalement, au moment où tu isoles le nœud en débranchant ses rings, il faut compter environ 2 minutes avant que le cluster lance sa procédure de failover. Le nœud isolé va stopper les VM pour éviter le "split-brain", et le reste du cluster va relancer les VM qui ont été configuré en HA sur les nœuds ayant été configuré pour recevoir les VM.
A priori, le temps de bascule est hard-codé. Selon moi, ce temps est raisonnable, pour éviter de relancer inutilement les VM en cas de coupure réseau passagère.
A noter que sans configuration manuelle, il faut que plus de 50% des nœuds du cluster soit vivant pour que celui-ci lance la procédure de failover.
Je ne sais pas si j'ai répondu a ta question, mais je reste disponible si tu as d'autres questions sur Proxmox.
Cordialement, Benoit MOREAU
On 16/06/2020 22:55, Racamier Stéphane wrote:
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
VmWare permet de faire ce que tu souhaites. C'est ce qu'ils appellent le "Fault Tolerance". Comme l'explique Alexandre, il n'y a pas de miracle : une vm protégée par FT est recopiée sur un autre hôte dans une vm "fantome" : le contenu de la RAM mais aussi l'état du CPU virtuel (la valeur de ses registres et différentes UC). Cela nécessite effectivement pas mal de bande passante mais pas au point de tourner en 40gb. J'ai pu le faire sur du 10g et si ta vm est raisonnable, cela peut aussi marcher sur du 1G. Chez vmware, y'a des contraintes : nbr maxi de vcpu par vm et nombre maxi de VM sur l'ESX. Je crois qu'en 6.1, on pouvait protéger avec FT une vm avec 4vcpu.
Au risque de troller, malgré un passé dans l'hospitalier, je n'ai pas connu de machine qui nécessitait réellement de la FT. Mêmes les besoins les plus critiques ( téléphonie Samu, interfaces applicatives quasi-temps réel, etc) pouvaient supporter un arrêt/redémarrage. Afficher une continuité sans faille, c'est à mon avis se mettre une peau de banane sous le pieds. Si les équipent IT se lancent dans ce sujet, on aura bientôt des DRH qui voudront que l'appli de gestion des congés soit ininterruptible. Attention : je ne veux pas dire que ton besoin est superflu. il y a surement des cas que je n'ai pas imaginé et qui nécessitent une FT. Cependant, je pense qu'il vaut mieux porter nos efforts sur d'autres axes : - apprendre à l'utilisateur à se passer de son service temporairement ( via des procédures en mode dégradé ). C'est à mes yeux le plus important. - réduire au mieux les temps de reprise lors d'une défaillance en accélérant les démarrages : soit on redémarre le paquet sur vm toute prête (cluster applicatif), soit on accélère le boot : SSD, os minimisé, etc... - travailler avec les éditeurs pour que les services co-existent sur plusieurs machines simultanément quand cela est possible, de façon à ce que ce soit le service qui continue via d'autres vm. (en gros, que ce soit l'applicatif qui soit Fault Tolerant "by design").
Olivier,
Le mer. 17 juin 2020 à 19:45, Benoit MOREAU via FRsAG frsag@frsag.org a écrit :
Salut,
Je ne comprends pas trop le problème. Normalement, au moment où tu isoles le nœud en débranchant ses rings, il faut compter environ 2 minutes avant que le cluster lance sa procédure de failover. Le nœud isolé va stopper les VM pour éviter le "split-brain", et le reste du cluster va relancer les VM qui ont été configuré en HA sur les nœuds ayant été configuré pour recevoir les VM.
A priori, le temps de bascule est hard-codé. Selon moi, ce temps est raisonnable, pour éviter de relancer inutilement les VM en cas de coupure réseau passagère.
A noter que sans configuration manuelle, il faut que plus de 50% des nœuds du cluster soit vivant pour que celui-ci lance la procédure de failover.
Je ne sais pas si j'ai répondu a ta question, mais je reste disponible si tu as d'autres questions sur Proxmox.
Cordialement, Benoit MOREAU
On 16/06/2020 22:55, Racamier Stéphane wrote:
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Il me semble que Xen supporte depuis longtemp le live migration d'une VM avec sa mémoire
Le mer. 17 juin 2020 à 20:02, Benoit MOREAU via FRsAG frsag@frsag.org a écrit :
Salut,
Je ne comprends pas trop le problème. Normalement, au moment où tu isoles le nœud en débranchant ses rings, il faut compter environ 2 minutes avant que le cluster lance sa procédure de failover. Le nœud isolé va stopper les VM pour éviter le "split-brain", et le reste du cluster va relancer les VM qui ont été configuré en HA sur les nœuds ayant été configuré pour recevoir les VM.
A priori, le temps de bascule est hard-codé. Selon moi, ce temps est raisonnable, pour éviter de relancer inutilement les VM en cas de coupure réseau passagère.
A noter que sans configuration manuelle, il faut que plus de 50% des nœuds du cluster soit vivant pour que celui-ci lance la procédure de failover.
Je ne sais pas si j'ai répondu a ta question, mais je reste disponible si tu as d'autres questions sur Proxmox.
Cordialement, Benoit MOREAU
On 16/06/2020 22:55, Racamier Stéphane wrote:
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Hello Clément et la liste,
Sous RHEL 5, virsh couplé à un hyperviseur Xen avait déjà le support du live migration: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/htm....
Sous RHEL 7, virsh couplé à un hyperviseur KVM supporte également le live migration: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Bonne soirée, Florent
Le dim. 28 juin 2020 à 20:46, Clément Gineste clement.gineste@gmail.com a écrit :
Il me semble que Xen supporte depuis longtemp le live migration d'une VM avec sa mémoire
Le mer. 17 juin 2020 à 20:02, Benoit MOREAU via FRsAG frsag@frsag.org a écrit :
Salut,
Je ne comprends pas trop le problème. Normalement, au moment où tu isoles le nœud en débranchant ses rings, il faut compter environ 2 minutes avant que le cluster lance sa procédure de failover. Le nœud isolé va stopper les VM pour éviter le "split-brain", et le reste du cluster va relancer les VM qui ont été configuré en HA sur les nœuds ayant été configuré pour recevoir les VM.
A priori, le temps de bascule est hard-codé. Selon moi, ce temps est raisonnable, pour éviter de relancer inutilement les VM en cas de coupure réseau passagère.
A noter que sans configuration manuelle, il faut que plus de 50% des nœuds du cluster soit vivant pour que celui-ci lance la procédure de failover.
Je ne sais pas si j'ai répondu a ta question, mais je reste disponible si tu as d'autres questions sur Proxmox.
Cordialement, Benoit MOREAU
On 16/06/2020 22:55, Racamier Stéphane wrote:
Bonsoir le groupe,
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production.
Existe il un moyen de palier ce problème ?
Cdlt.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 29/06/2020 à 03:44, Clément Gineste a écrit :
Il me semble que Xen supporte depuis longtemp le live migration d'une VM avec sa mémoire
On avait fait ça il y a 10 ans avec Xen, Remus (de mémoire), DRDB... Et ça marchait nickel. À l'époque c'était un peu de la R&D (psa mal de compils de noyaux) mais on y était arrivé.
On s'est ensuite amusé : arrachage de prise de courant, débranchage de SATA, virage de barette ram et même déclipsage de CPU...
Au pire un freeze imperceptible en plein download dans une vm doze...
Par contre : faut du backplane de CM qui roxe, de l'interconnexion de nœud qui roxe ; coupler 2x1 Gbps pour la liaison entre les nœuds est un mini et, d'une manière générale, du setup hard très homogène en perfs car la vraie HA a un vrai coût de ce point de vue.
Bonjour,
A noter qu'avec un backend Ceph, il se peut que l'algo attende qu'un OSD soit réellement HS (pas juste une (micro-)coupure) pour commencer à rebalancer les données sur les noeuds restant. Il se peut donc que ça soit la cause de ce délais, en particulier si vous avez beaucoup de contenu à rebalancer, avec des grosses VMs en terme de stockage.
Rémy.
Le 29/06/2020 à 03:44, Clément Gineste a écrit :
Il me semble que Xen supporte depuis longtemp le live migration d'une VM avec sa mémoire
Le mer. 17 juin 2020 à 20:02, Benoit MOREAU via FRsAG <frsag@frsag.org mailto:frsag@frsag.org> a écrit :
Salut, Je ne comprends pas trop le problème. Normalement, au moment où tu isoles le nœud en débranchant ses rings, il faut compter environ 2 minutes avant que le cluster lance sa procédure de failover. Le nœud isolé va stopper les VM pour éviter le "split-brain", et le reste du cluster va relancer les VM qui ont été configuré en HA sur les nœuds ayant été configuré pour recevoir les VM. A priori, le temps de bascule est hard-codé. Selon moi, ce temps est raisonnable, pour éviter de relancer inutilement les VM en cas de coupure réseau passagère. A noter que sans configuration manuelle, il faut que plus de 50% des nœuds du cluster soit vivant pour que celui-ci lance la procédure de failover. Je ne sais pas si j'ai répondu a ta question, mais je reste disponible si tu as d'autres questions sur Proxmox. Cordialement, Benoit MOREAU On 16/06/2020 22:55, Racamier Stéphane wrote:Bonsoir le groupe, Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1. La plateforme de test utilisé des HP proliant dl380 g7. Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1. Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, l'interruption est bien trop longue pour des services en production. Existe il un moyen de palier ce problème ? Cdlt. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 16/06/2020 à 22:55, Racamier Stéphane a écrit :
Bonsoir le groupe,
Bonjour !
Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 1 carte sur le ring0 et 1 sur le ring1.
La plateforme de test utilisé des HP proliant dl380 g7.
Ma préoccupation principale est de réussir à migrer mes VMs sans interruption de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler cette panne je débranche l'interface ring0 et 1.
Pas certain que tu aies exprimé ton besoin exactement comme tu l'entends mais si je comprends ta phrase, tu souhaites que la VM continue de tourner même si le noeud qui l'héberge subis une avarie sévère (panne électrique ou réseau) ?
Si oui, à ma connaissance, ce n'est pas faisable avec Proxmox. C'est même encore très rare dans l'univers de la virtualisation, notamment parce que ca demande un fonctionnement en hot-spare : il faut qu'à tout moment tu synchronise non seulement le contenu du disque (Ceph pour cela, c'est parfait) mais également le contenu de la RAM et là, il faut un sacré réseau et je peux te dire qu'en gigabit, il faut oublier. Je pense même qu'en dessous de 40Gbps par noeud, c'est mort.
J'ai vu une techno dans ce style chez VMWare qui 'rejoue' l'intégralité des IOs sur chaque VM. Mais ca semble encore très limité (4 coeurs max, 16 Go de RAM max, etc ..).
Je n'ai jamais vraiment joué avec la H.A. dans Proxmox mais je doute que tu arrives à un résultat 'sans interruption'. Au mieux, Proxmox va relancer la VM automatiquement si elle n'est plus palpable après x secondes.
En 2020, le mieux pour ça est de jouer sur une redondance au niveau applicatif (facile si c'est du web, parfois complexe sur d'autres payloads).
Julien
un sacré réseau et je peux te dire qu'en gigabit, il faut oublier. Je pense même qu'en dessous de 40Gbps par noeud, c'est mort.
En fonction de la charge de réplication, ça peut être beaucoup moins.
On a monté une maquette Xen/Remus il y a 10 ans avec du hard pourri (CM Intel à 40€, CPU quad core Q6600, 4Go de ram, 4 disques mécas en RAID10, 1 ETH 1Gbps d'origine pour le réseau, 2 ETH bindées pour 2x1 Gbps avec des cartes à 10€ pièce sur PCI (pas PCIe) et le backplane de la CM pourri.
Le résultat gazait raisonnablement (mais on voyait l'impact. La vraie HA a un coût évident en perfs, les reprises après incidents sont sympas aussi - mais ce n'est pas spécifique vraie HA).
On faisait tourner dessus une VM doze, des VM Ubuntu et Debian. 2 nœuds.
En refaisant ça avec du matos actuel et du 10 Gbps bindé, on doit pouvoir faire du sérieux-sérieux. Mais faut que ça vaille le coup/coût.
En 2020, le mieux pour ça est de jouer sur une redondance au niveau applicatif (facile si c'est du web, parfois complexe sur d'autres payloads).
Effectivement, tout dépend du service...
Cet été, on monte une maquette de notre future infra sur ganeti, vu qu'on aime Xen et le simple. C'est pas très actif mais c'est pas mort non plus et les gens qui l'utilisent ont l'air heureux.
-
Alexandre DERUMIER -
Benoit MOREAU -
Clément Gineste -
Dernat Rémy -
Florent CARRÉ -
Julien Escario -
Olivier Vailleau -
Racamier Stéphane -
Richard Baret -
Stéphane Rivière