Plateforme HA Proxmox / Ceph

Proxmox donne de très bons résultats quand tout ce qui l’entoure est correctement conçu : stockage, quorum, réseau, sauvegardes, mises à niveau et gestion des pannes.

Cette mission couvre les nouveaux clusters, les migrations depuis vSphere ou des plateformes plus anciennes, ainsi que les revues d’environnements Proxmox/Ceph existants avant qu’ils ne deviennent critiques en production.

Quand cette mission n’est PAS adaptée

• Vous avez besoin d’un service d’hyperviseur entièrement managé et ne souhaitez pas exploiter en interne le stockage, le quorum, les sauvegardes et le cycle de vie matériel.
• Le réseau disponible ne peut pas fournir des chemins prévisibles et à faible latence pour Corosync, le trafic de migration et la réplication Ceph.
• Le parc matériel est trop hétérogène pour fiabiliser la planification de capacité, les domaines de panne ou les baselines de performance.
• Vous ne disposez ni d’une fenêtre de maintenance ni d’un environnement de test pour valider les procédures de failover, de restauration et de remplacement de nœud.

Modes de défaillance courants que nous avons rencontrés

• Corosync partage des réseaux de production congestionnés, ce qui crée de l’instabilité de quorum et un risque de split-brain lors d’incidents ordinaires de switch ou d’hôte.
• Ceph est dimensionné à partir de la capacité disque brute plutôt qu’à partir de la capacité utile, de la bande passante de recovery, de la mémoire OSD et des domaines de panne.
• La HA est activée avant que le fencing, les sauvegardes et les tests de restauration soient prouvés, si bien qu’un redémarrage automatique peut aggraver un incident de stockage ou de réseau.
• Les mises à niveau de cluster sont traitées comme de simples mises à jour de packages, au lieu d’être pilotées comme des changements de plateforme avec migration, rollback et règles de placement des workloads.