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/