Haute Disponibilité

Vos instances Odoo
ne s’arrêtent plus.

Failover automatique < 30 secondes. RPO ≈ 0.
Architecture primaire + standby avec réplication PostgreSQL WAL streaming, détection automatique des pannes et bascule pilotée par le méta-cluster Muppy.
100% PostgreSQL natif — aucun lock-in propriétaire.

Voir nos offres →
< 30 s
RTO — Failover automatique
≈ 0
RPO — Mode synchrone
2 nœuds
Primaire + Standby synchronisé
1 min
PITR — Précision de restauration

Architecture HA Odizy

Chaque composant conçu pour ne jamais tomber.

🎯

Méta-cluster Muppy

Orchestrateur HA natif de la plateforme. Calcule l’état du cluster (healthy / degraded / critical / broken) via des health-checks programmables et déclenche le failover automatiquement.

  • 4 états : healthy / degraded / critical / broken
  • Calcul d’état via smart-config Python
  • Pilote la logique de bascule complète
🔄

Réplication WAL Streaming

Réplication physique PostgreSQL (WAL streaming) entre primaire et standby, sans dépendance propriétaire ni modification du code client.

  • Réplication physique native PostgreSQL
  • RPO ≈ 0 en mode synchrone
  • Quelques secondes en mode asynchrone

Smart Healthchecks

Sondes Python topology-aware éditables depuis l’interface. Distinguent « standby en panne » de « primaire en panne » sans reconfiguration lors d’un switchover.

  • Topology-aware : rôle résolu dynamiquement
  • Switchover-transparent : zéro reconfiguration
  • Alerte push Pushover sur smartphone
🔀

Failover automatique < 30 s

Promotion du standby en primaire en moins de 30 secondes, puis re-synchronisation automatique du nœud restauré.

  • Promotion standby → primaire
  • Re-sync automatique après récupération
  • Zéro intervention manuelle
🔁

Traefik Load Balancer

Proxy HTTP/HTTPS intégré qui redirige les connexions vers le nœud actif après une bascule. Transparent pour Odoo.

  • Routage automatique post-bascule
  • Certificats TLS gérés nativement
  • Zéro modification de l’application
🌐

DNS failover multi-provider

Bascule DNS automatique après promotion via OVH, Scaleway ou le DNS intégré Muppy (MBD). L’URL reste identique pour vos utilisateurs.

  • OVH, Scaleway, DNS intégré Muppy (MBD)
  • Bascule automatique post-failover
  • URL applicative inchangée
Backup & PITR wal-g

Restaurez à la minute près.
N’importe quand.

  • PITR — Sauvegardes WAL continues via wal-g vers stockage objet multi-AZ (S3 et 8 backends compatibles). Restauration possible à la minute près.
  • Stockage S3 multi-AZ — Transfert en 1 clic des bases entre clusters. Réutilisez vos backups de production en Dev ou Test.
  • Rollback post-migration instantané — Une migration Odoo échoue ? Restaurez exactement à l’état précédant la mise à jour, sans perte de données.
🕐

Point In Time Recovery

Restaurez votre base Odoo à n’importe quel point dans le passé, à la minute près.

RPO optimisé

Ce qui se passe en 30 secondes
quand un nœud tombe.

Séquence de failover automatique Odizy — aucune intervention manuelle.

1

Détection — 0 à 5 s

Le méta-cluster détecte via les smart healthchecks que le nœud primaire est injoignable. Vérification du lag de réplication et de l’état du standby.

2

Isolation — 5 à 10 s

Le nœud défaillant est marqué hors service par le méta-cluster. Le standby entre en phase de promotion sans risque de double-écriture.

3

Promotion — 10 à 20 s

Le standby est promu en primaire. Traefik redirige automatiquement les connexions. Le DNS failover bascule l’URL vers le nouveau nœud actif.

4

Re-synchronisation — après récupération

Le nœud restauré rejoint le cluster automatiquement. La réplication et la synchronisation du filestore reprennent sans intervention.

Multi-cloud & hybride

HA entre sites, datacenters
et clouds différents.

Odizy HA fonctionne en multi-cloud et hybride : un nœud primaire sur OVH France, un standby sur Scaleway, ou un site on-premise en standby pour une production cloud. La réplication PostgreSQL WAL streaming est indépendante de l’infrastructure.

100% PostgreSQL natif — aucun lock-in sur l’infrastructure. Migrez librement entre providers sans reconstruire votre cluster de réplication.

Architectures supportées

  • OVH primaire + Scaleway standby
  • Cloud primaire + On-premise standby
  • Multi-datacenter même provider
  • AWS / Azure / GCP + souverain FR
  • Instances on-premise inter-sites (filiales)

Questions fréquentes

Comment fonctionne la haute disponibilité PostgreSQL dans Odizy ?

Odizy déploie une architecture primaire + standby avec réplication physique WAL streaming. Le méta-cluster Muppy surveille en continu les clusters via des smart healthchecks. En cas de panne, le nœud défaillant est isolé, le standby est promu en moins de 30 secondes, et le trafic est redirigé automatiquement via Traefik et le DNS failover.

Quel est le RTO et le RPO d’Odizy en cas de panne ?

Le RTO (Recovery Time Objective) est inférieur à 30 secondes — délai du failover automatique, sans intervention humaine. Le RPO (Recovery Point Objective) est proche de zéro en mode synchrone, et de quelques secondes en mode asynchrone.

Comment sont acheminées les alertes en cas d’incident ?

Les smart healthchecks envoient une notification push (Pushover) sur smartphone dès qu’un seuil est franchi, sans service tiers de type PagerDuty.

Zéro downtime pour vos utilisateurs

Discutons de votre architecture HA Odoo.

Nous contacter → Voir les services