Exiger un RTO 0 et un RPO 0 pour toutes les machines virtuelles est l’une des demandes les plus fréquentes dans les cahiers des charges d’infrastructure, et aussi l’une des plus coûteuses à satisfaire. Aucun hyperviseur ne les fournit d’origine, Proxmox VE non plus : ils résultent d’une architecture précise de stockage, de réseau, de cluster et de procédures, et leur coût dépend de la façon dont elle est construite et du nombre de charges qui en ont réellement besoin.
Les points clés de RTO 0 et RPO 0 sur Proxmox en 20 secondes
- Le RPO 0 exige une réplication synchrone ; le RTO 0 exige que le service ne s’arrête pas.
- La haute disponibilité de Proxmox redémarre la VM sur un autre nœud : elle réduit le RTO, mais ne le ramène pas à zéro.
- Le plus efficace est de classer les services et de réserver les valeurs zéro aux services critiques.
Commençons par les définitions. Le RPO (objectif de point de reprise) mesure la quantité de données que l’on peut perdre : un RPO 0 signifie ne perdre aucune transaction validée, ce qui oblige chaque écriture à se trouver en au moins deux endroits avant d’être considérée comme valide. Le RTO (objectif de temps de reprise) mesure combien de temps un service peut rester à l’arrêt : un RTO 0 implique qu’il reste disponible ou se rétablisse sans interruption perceptible par l’utilisateur. Ce sont des objectifs métier qui s’écrivent dans un cahier des charges ou un plan de continuité. Que l’on y parvienne, c’est l’architecture et, surtout, les tests qui le démontrent.
Ce que Proxmox VE offre d’origine, et ce qu’il n’offre pas
La haute disponibilité (HA) de Proxmox VE surveille les nœuds du cluster et, si l’un tombe, démarre ses machines virtuelles sur un autre. Pour éviter que deux nœuds utilisent le même disque en même temps, le nœud qui perd le quorum s’isole lui-même au moyen d’un watchdog qui, selon la documentation du projet, le redémarre au bout de 60 secondes. Ce n’est qu’ensuite que les VM sont récupérées sur un autre nœud, si bien qu’en pratique le service est à l’arrêt de l’ordre d’une à deux minutes, plus le temps de démarrage du système d’exploitation et de l’application. C’est un RTO bas, adapté à de nombreux services, mais pas nul : la VM redémarre, elle ne continue pas. De plus, la HA exige au moins trois nœuds pour maintenir le quorum et que les disques soient sur un stockage partagé.
Pour le RPO, tout dépend du stockage. Avec Ceph intégré à Proxmox, chaque écriture est répliquée de façon synchrone entre plusieurs nœuds du cluster avant d’être validée, si bien que la chute d’un serveur ne fait perdre aucune donnée validée. La réplication de stockage de Proxmox sur ZFS local est autre chose : elle est asynchrone et son intervalle le plus court est d’une minute, de sorte qu’en cas de bascule on peut perdre ce qui a été écrit depuis la dernière copie. C’est une option bon marché et utile, mais elle n’offre pas de RPO 0. Et Proxmox Backup Server couvre un autre besoin, celui de restaurer après des suppressions, une corruption ou un ransomware, avec un RPO et un RTO de l’ordre de plusieurs heures.
Deux voies : l’infrastructure ou la charge
Pour se rapprocher des valeurs zéro entre deux datacenters, il existe deux approches. La première résout le problème dans l’infrastructure : matériel redondant, stockage à réplication synchrone entre sites, clusters étendus et orchestration depuis l’hyperviseur. Elle est centralisée et robuste, mais c’est généralement la plus chère. Sur Proxmox, elle peut s’envisager avec un cluster étendu sur un stockage partagé répliqué de façon synchrone entre les deux datacenters, ou avec le mode stretch de Ceph, qui exige des latences très faibles entre sites et un troisième point d’arbitrage pour le quorum. Des fournisseurs comme Stackscale, du groupe Aire, proposent un stockage en réseau avec réplication synchrone entre deux datacenters à Madrid, conçu pour un RTO 0 et un RPO 0, et des clouds privés avec Proxmox ou VMware sur cette base.
La seconde voie rapproche la protection de la charge : logiciel qui fonctionne à l’intérieur du système d’exploitation ou de la machine virtuelle elle-même, ou réplication native de l’application, comme celle d’une base de données avec des réplicas synchrones. On peut ainsi protéger des services entre hyperviseurs différents, datacenters indépendants, serveurs physiques et virtuels, ou environnements locaux et cloud, et la continuité cesse de dépendre d’un matériel ou d’un hyperviseur précis. Le coût peut beaucoup changer, mais les problèmes ne disparaissent pas.
Dans les deux cas, la distance reste déterminante : la réplication synchrone ajoute la latence aller-retour à chaque écriture, et la bande passante limite ce que l’on peut répliquer. Il faut aussi régler la cohérence des applications, l’ordre de démarrage des services, le réseau et les VLAN sur le site secondaire, le DNS, l’identité et l’authentification, la bascule et, au final, le retour sur le site principal. Un réplica disponible ne garantit pas une application opérationnelle.
Classer avant de concevoir
C’est pourquoi un cahier des charges ne devrait pas exiger un RTO 0 et un RPO 0 pour toutes les machines virtuelles comme s’il s’agissait d’une seule charge. Le plus raisonnable est de classer les services. Les services critiques, comme les paiements, l’identité ou les transactions principales, nécessitent une continuité active ou des valeurs proches de zéro, avec un stockage synchrone entre sites ou la réplication de l’application elle-même. Les services importants peuvent être rétablis en quelques minutes, et pour eux un cluster Proxmox avec HA et Ceph suffit généralement. Les services opérationnels admettent quelques heures, avec une réplication asynchrone ou une restauration rapide. Et les services non critiques peuvent être restaurés depuis une sauvegarde.
La question utile n’est pas de savoir quel produit offre un RTO et un RPO nuls, mais quels processus en ont réellement besoin et quelle est l’architecture la plus efficace pour le démontrer. Toutes les charges n’exigent pas la solution la plus chère, mais toutes ont besoin d’un objectif mesurable, d’un test de reprise périodique avec le temps réel mesuré et d’un responsable. Pour qui migre ses charges vers Proxmox, notre analyse sur la migration de VMware vers Proxmox VE est un bon point de départ, et la conception de la continuité devrait se faire avant de déplacer la première machine, pas après.
Questions fréquentes
Que signifient RTO 0 et RPO 0 ?
Un RPO 0, c’est ne perdre aucune transaction validée. Un RTO 0, c’est que le service reste disponible ou se rétablisse sans interruption perceptible.
La haute disponibilité de Proxmox donne-t-elle un RTO 0 ?
Non. Elle redémarre la machine virtuelle sur un autre nœud après avoir isolé celui qui est tombé, ce qui représente généralement une à deux minutes d’arrêt, plus le démarrage du système.
La réplication ZFS de Proxmox offre-t-elle un RPO 0 ?
Non. Elle est asynchrone et son intervalle minimal est d’une minute, si bien que l’on peut perdre ce qui a été écrit depuis le dernier réplica. Ceph ou le stockage synchrone évitent cette perte.
Toutes les machines virtuelles ont-elles besoin d’un RTO 0 et d’un RPO 0 ?
Non. Le plus efficace est de classer les services en critiques, importants, opérationnels et non critiques, et de réserver les valeurs zéro aux premiers.
Sources :
