[FRsAG] [TECH] Cluster proxmox hyper convergé

Olivier Vailleau olivier.vailleau at gmail.com
Ven 19 Juin 09:03:13 CEST 2020


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 at 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/
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20200619/093366e3/attachment-0001.htm>


Plus d'informations sur la liste de diffusion FRsAG