Bonjour à tous,
Je réalise des tests avec Proxmox en mode labo. J'ai 3 hôtes pve et un san (truenas) qui propose une lun iscsi pour le stockage des VM (structure classique pour la virtualisation).
Mes 1ere lectures montrent des cas où le stockage est sur chaque pve et on tombe sur de la duplication avec forcement un décalage de x minutes entre chaque hôtes et un temps nécessaire pour qu'une VM géré par le pve1 redevienne disponible sur l'un des 2 autres pve lorsque le 1 tombe en marche. Cela engendre une coupure d'activité et une perte de données.
Lorsque je compare avec des solutions comme esx ou hyperv, la question ne se pose même pas. Le cluster a une vue sur les toutes les vm et les hôtes se les passent lorsqu'un ne répond plus avec un délai de quelques secondes (temps de détection d'offline d'un hôte) et surtout sans perte de données.
Si je partage le stockage genre avec un ZFS over iSCSI sur le cluster, est-ce cela va être la même problématique (même si à mon sens il n'y a plus de problème de duplication puisque stockage partagé) qu'avec un stockage sur chaque hôtes ?
La doc n'est pas vraiment clair sur le sujet.
Philippe
# Petite question ....
Posté par totof2000 . Évalué à 3 (+1/-0).
Tu constates ça avec le même matériel ?
[^] # Re: Petite question ....
Posté par Philippe M (site web personnel) . Évalué à 2 (+0/-0).
Non, mes tests proxmox sont fait un pc tout en mode virtualisation.
J'ai en prod un cluster hyperv et un cluster vmware vsphere sur des matériels dédiés et je te confirme que lorsqu'un hôte tombe, hyperv par exemple, l'autre prend le relais avec juste une coupure d'accès de 1 ou 2 secondes le temps que la détection du down se fasse. Cela n'engendre pas de perte de données à cause d'un décalage de copie de vm d'un hôte à un autre. Le fonctionnement est le même avec vmware vsphere et la logique que se soit hyperv ou vmware est la même : une lun accessible par le cluster.
Pour mon test, le matériel n'est pas en cause, puisque j'en suis encore à l'étape lecture de doc et prise d'info sur le net et pour le moment je n'ai pas trouvé de doc qui explique le fonctionnement lorsque les vm sont stocké sur un san et une lun qui est accessible à tout les hôtes du cluster proxmox.
Born to Kill EndUser !
# Hyperconvergence et Ceph
Posté par Julien.D . Évalué à 8 (+6/-0).
Salut,
J'ai un cluster à 3 noeuds à la maison avec du CEPH et le temps de migration d'une VM d'un noeud à un autre est de quelques secondes.
Mais oui, c'est pas du ZFS/NFS 😉
J'ai mis ça en place avec deux disques sur chaque noeud : un pour le système et l'autre dédié à CEPH.
Attention CEPH recommande du 10G donc il faut l'équipement réseau qui va avec si tu veux passer en prod.
L'installation de CEPH avec Proxmox est rendu facile, il faut juste suivre avec beaucoup d'attention la documentation lors d'une mise à jour. Typiquement dernièrement où j'ai dû passer de Proxmox 8 à Proxmox 9 😉
[^] # Re: Hyperconvergence et Ceph
Posté par oau . Évalué à 5 (+3/-0).
ceph c'est bien mangez en :)
# Je ne comprend pas le souci !
Posté par seraf1 (site web personnel) . Évalué à 6 (+5/-0).
Si tu as un SAN, c'est un stockage partagé, donc les images de tes VM sont visible de tous tes PVE et le temps de migrations d'une VM est sensiblement équivalent à VMware ou HyperV.
Pour du HA, il ne faut pas faire de stockage local, car effectivement, la duplication ne se fait que toutes les N secondes.
Mais une des meilleures solutions, à mon avis, est d'utiliser du Ceph (soit en hyperconvergé, soit dans un cluster séparé), car avec un SAN, il reste un SPOF (Single Point Of Failure), le SAN !
[^] # Re: Je ne comprend pas le souci !
Posté par Philippe M (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 01 décembre 2025 à 11:16.
Merci pour tes précisions. En lisant la doc j'ai eu peur qu'il ne soit pas possible de mettre en place un stockage sur SAN visible par le cluster pve et que je sois obligé de passer par du stockage local sur chaque hôte avec les contraintes qui vont avec.
Je suis d'accord que le SPOF devient le SAN et l'idéal est d'en avoir deux différents dans deux salles différentes. Il y a toujours mieux mais par exemple j'ai deux SAN (HP et Netapp) chacun à deux contrôleurs. Chaque contrôleur a son alim, ses cartes réseaux. Les disques créés une grappe de stockage virtuelle visible par chaque contrôleur avec une répartition de charge, du "mirroging", des disques de spare. Si un contrôleur tombe, l'autre prend le relais quasiment instantanément…
Dans ce contexte si j'ai un problème avec le stockage, je pense que c'est ma baie complète qui a pris feu et j'aurais bien d'autres problèmes :)
Born to Kill EndUser !
[^] # Re: Je ne comprend pas le souci !
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
J'ai vu deux fois dans ma carrière des grosses pannes de SAN de vendeurs réputés (EMC et HPE 3PAR). Dans les deux cas malgré avoir des alims, controlleurs redondants et des SAN sur les deux sites les deux SAN étaient indisponibles en même temps.
Une fois c'était un technicien de la marque qui avait appliqué des patches séquenciellement sur les deux SAN et il y avait un bug qui faisait que si tu mettais à jour les deux controlleurs sans attendre je ne sais plus combien de minutes entre les deux ça les faisait tomber…plusieurs heures plus tard. Un truc de fou. Du coup le mec avait pu patcher un controlleur, ça marche, le deuxième, bon ça marche toujours, je fais de même sur le nouveau SAN, tout va bien je confirme et je me déconnectes. 2h après tous tes serveurs perdent leur données et ne peuvent plus booter (vive le boot from san).
La deuxième fois je ne me rappelle plus mais encore un truc super à la con et on s'était retrouvé à attendre des heures que des fsck se fassent sur chaque LUN.
Bref la redondance c'est bien mais des fois ça ne suffit pas si c'est mal branlé, et difficile de savoir quand c'est une boite noire propriétaire.
[^] # Re: Je ne comprend pas le souci !
Posté par Philippe M (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 02 décembre 2025 à 16:06.
Le coup du SAN pas fait pour les précoces c'est vraiment pas de chance et comme tu l'a dis, les patchs ont été appliqué sur un SAN pour validation… Ca marche hop déploiement sur les autres SAN. Dans ce cas que tu en ai 1 ou 200 le problème reste le même et je ne vois pas trop quelle solution pour contourner ce cas et le tech est probablement devenu le président de l'asso des looser.
Je suis un fervent défenseur de l'open source et tout et tout… Mais trouve moi un admin qui a décortiqué la totalité d'une mise à jour. Quand je dis décortiqué, c'est pas juste lire le changelog, mais auditer chaque modification de version d'une appli et surtout le code modifié sur ces appli. En principe on regarde le changelog, on analyse par rapport à l'infra pour anticiper au max l'impact. On lance la mise à jour sur du matos de test… On test, on retest et dans le doute on fait un dernier test… C'est validé… On pousse en prod. T'aura beau faire et refaire, lire et relire, tu aura toujours un cas qui est passé au travers car il fallait que le jour du test : la température soit de 20,4°, que le cours de la cacahuète soit positif au Etats-Unis et que tu dise des mots d'amours à l'oreille de ton SAN pour être certain de finir la journée tranquillement. Donc pour moi l'argument "c'est la faute à la boite noir" n'est pas valable, cela arrivera de la même manière si tu as accès aux sources.
Born to Kill EndUser !
[^] # Re: Je ne comprend pas le souci !
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Perso je n'ai jamais connu de boite qui se permettait d'acheter un SAN identique juste pour de la validation.
Alors que des pizzabox de plus pour un cluster ceph séparé de celui de prod, zéro difficultée à justifier l'achat.
# SAN => migration et reprise rapides
Posté par cg . Évalué à 3 (+1/-0).
Oui, si tes stockages de VMs (et les templates le cas échéant) sont sur le SAN, migrer une VM revient à copier la RAM et l'état des vCPUs vers un autre hyperviseur (quelques secondes), et faire redémarrer une VM sur un autre pve est rapide.
Comme dit par d'autres, tu as un toujours un SPOF avec le SAN, mais après c'est fonction de la continuité que tu veux.
Ceph marche bien en hyperconvergé dans Proxmox si tu as du matériel et un réseau rapides. Ça coûte en général plus cher qu'un SAN aussi, car il y a plus de redondance.
# CEPH c'est bien mais ...
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
Bonjour,
Je bosse actuellement sur un projet qui utilise le cluster SEAPATH, c'est open source et très bien fait.
SEAPATH
C'est basé sur pacemaker / corosync / CEPH et cela fonctionnent très bien vu que l'on a quelques sites en exploitation
Mais et c'est un gros "mais" … il n'y a pas de données persistantes ou très peu
Et pour l'instant je ne suis pas convaincu que dans le cas de bases de données importantes SGBDR de plusieurs dizaines/centaines de Go cela soit une solution viable.
Les grosses BDD ont besoin de travailler en mémoire, plus il y en a mieux c'est pour les temps de reponses en contrepartie la haute dispo doit être gérée par le SGBDR et pas de manière matérielle
de manière native.
Je ne vois pas comment faire pour migrer 32/64/96 Go de RAM d'une machine à l'autre rapidement.
sinon c'est perte de données non commitées.
Je connaissais assez bien la BDD Oracle et leur solution (HORS de PRIX) était techniquement aboutie (STANDBY DB /RAC real appli cluster).
Et j'aimerai avoir votre avis, expérience (pour ma culture perso) si des solutions a base d'outils open source comme POSTGRES ou mysql permettent ce genre de choses : un cluster ACTIF/ACTIF comme RAC ou même ACTIF / PASSIF comme une STBDY DB
[^] # Re: CEPH c'est bien mais ...
Posté par Philippe M (site web personnel) . Évalué à 2 (+0/-0).
Hello, sur mysql j'ai utilisé la réplication en mode maitre/esclave pour synchroniser une base avant une migration. C'est efficace, la donnée est écrite sur le maitre et automatiquement répliqué sur l'esclave. Ca prend un peu prêt 4 minutes à mettre en place.
Mais je n'ai pas testé le cas de crash du maitre comment redirigé vers l'esclave. Je suppose qu'il faut mettre un haproxy devant pour que cela soit transparent pour les utilisateurs/application.
Pour moi il y a deux niveaux :
- faire en sorte qu'un serveur reste disponible;
- faire en sorte qu'une appli reste disponible.
1er niveau : le serveur, tout comme pour un serveur physique, on doit faire le max pour qu'il reste online (merde, un peu de respect pour l'uptime ;) ). L'objectif est de réduire au max le temps de latence pendant le transfert d'un hôte à un autre. Quand je parle de transfert c'est uniquement pour la partie vcpu/vram/réseau, le stockage des VM est commun à tous les hôtes d'un cluster. Forcément la latence aura un impact sur les appli de chaque VM.
2eme niveau : l'appli doit rester disponible. C'est effectivement le plus délicat et encore plus pour les bases de données. J'ai retourné le truc un peu dans tout les sens :
Il y a forcément un moment où une info se perd même si c'est commité toutes les demi-secondes ou même "instantanément". Une coupure en plein milieu d'un commit et réplication entre base… Et hop incohérence. C'est ici que s'arrête mon "expertise" :D
Born to Kill EndUser !
[^] # Re: CEPH c'est bien mais ...
Posté par Christophe B. (site web personnel) . Évalué à 2 (+0/-0).
Salut ! ;)
C'est la qu'il faut utiliser les termes RTO (Recovery Time Objectif) et RPO (Recovery Point Objectif) en gros le temps d'arrêt max que tu veux atteindre (RTO) et le volume de données que tu peu te permettre de perdre (RPO)
Et ce en cas d'incident grave touchant l'entreprise ou le système informatique ( incendie inondation etc … )
Exemple : dans le domaine bancaire RTO = 1h d'arrêt d'exploitation et RPO = rien pas de perte de données
Mais cela coute cher …
Attention cela ne dispense pas de faire des sauvegardes car si une transaction est une bêtise elle sera aussi dupliquée …
Il y a quelques temps … en règle général dans une entreprise "classique" peut se permettre 1/2 journée d'arrêt avec environ 15mn à 1/2h de perte de données.
Mais cela nécessitait un double environnement informatique avec STANDBY DB de chez ORACLE
Un équivalent du coté SQL SERVER de chez M$ existe aussi
Après quelques rechreches : Coté POSTGRESQL apparement cela s'appelle le PITR Point in Time recovery
Si des personnes avisées pouvaient decrire le processus avec des mots simples sur ce forum cela serait sympa …
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.