Délocalisation et stabilisation de l'hébergement infogéré basé sur Proxmox + Ceph avec migration client et temps d'arrêt limités

La situation initiale est un petit hébergement géré sur 3 nœuds Proxmox VE 7.x (pools ZFS locaux), environ 60 VM et 120 conteneurs avec sites clients (NGINX/Apache, PHP-FPM, MariaDB/PostgreSQL), le courrier est retiré séparément. Des réductions d'E/S et des redémarrages imprévisibles de machines virtuelles se produisent régulièrement pendant les pics de charge ; les sauvegardes sont envoyées via vzdump vers NFS et s'avèrent parfois cassées. Il est prévu de passer à Proxmox VE 8.x, de passer au stockage distribué Ceph et de configurer HA afin que la panne d'un nœud n'entraîne pas de temps d'arrêt.

Environnement technique - 4 serveurs physiques (2x NVMe + 4x SATA SSD, 2x10GbE), switch 10GbE séparé, réseau public /27 et interne /24, accès VPN. Certains clients utilisent Cloudflare, d'autres travaillent directement. Au niveau de l'hébergement, il existe des exigences en matière d'isolation des clients et de performances prévisibles.

Ce que vous devez faire est de concevoir et de mettre en œuvre la configuration cible et d'effectuer la migration sans perte de données.
- Préparer un plan de mise à niveau pour PVE 7.x -> 8.x avec vérification de la compatibilité, procédure et restauration
- Déployer Ceph (min 3 MON, MGR, OSD sur NVMe, réseaux publics/cluster séparés), configurer CRUSH et domaines de défaillance en tenant compte de la topologie
- Configurer Proxmox HA pour les machines virtuelles critiques, corriger les mécanismes de clôture, les politiques de redémarrage et de migration
- Migrez les VM/CT existants vers Ceph avec un temps d'arrêt minimal, y compris des migrations à chaud lorsque cela est possible et des fenêtres de temps d'arrêt pour celles restantes.
- Mettez de l'ordre dans vos sauvegardes - Proxmox Backup Server ou une option alternative avec des sauvegardes incrémentielles vérifiables, une conservation et des restaurations de test régulières
- Éliminer les causes des baisses de courant - analyse des E/S, de la latence, configuration des caches, des files d'attente de disques, des paramètres Ceph, des limites VM/CT, identification des goulots d'étranglement du réseau 10GbE
- Configurer la surveillance et les alertes - Prometheus/Grafana ou équivalent, Proxmox/Ceph/SMART/métriques réseau, alertes Telegram/Email
- Préparer la documentation d'exploitation - schéma de réseau, rôles des nœuds, ordre d'ajout d'OSD/nœuds, plan DR et listes de contrôle

Limites : le temps d'arrêt total pour la plupart des clients ne dépasse pas 30 minutes par fenêtre de nuit, pour les projets VIP 3, pas plus de 5 minutes. Vous ne pouvez pas modifier les adresses IP publiques de 20 VM (les clients sont strictement liés). Vous ne pouvez pas arrêter l'ensemble du cluster en même temps. Accès au matériel uniquement à distance via IPMI et VPN.

Le résultat est un cluster Proxmox VE 8.x fonctionnel avec Ceph, HA et des sauvegardes vérifiables, ainsi qu'une documentation claire.

Critères d'acceptation - 1) la panne d'un nœud n'entraîne pas l'arrêt de la VM VIP pendant plus de 2 minutes, confirmée par un test d'arrêt du nœud via IPMI 2) Ceph est dans l'état HEALTH_OK sous charge normale, pas de PG bloqué, des avertissements de plénitude et de latence sont configurés 3) pour 10 VM sélectionnées, un test de récupération à partir d'une sauvegarde a été effectué avec enregistrement du temps RTO et contrôle de l'intégrité des données 4) latence moyenne du sous-système de disque pour la VM testée la charge fio ne dépasse pas 3-5 ms en lecture aléatoire 4k avec le profil cible, les résultats sont joints 5) toute la configuration est enregistrée sous forme de documentation et de paramètres étape par étape (versions, schémas de réseau, commandes)