Skip to Content
Haute Disponibilité

Vos instances Odoo
ne s'arrêtent plus.
Failover automatique < 30 secondes. RPO ≈ 0.

Architecture 2 AZ (primaire + standby) avec réplication PostgreSQL WAL streaming, détection automatique des pannes, STONITH intégré et bascule orchestrée par Odizy HA Controller. 100% PostgreSQL natif — aucun lock-in propriétaire.

< 30 s
RTO — Failover automatique
≈ 0
RPO — Mode synchrone
2 AZ
Primaire + Standby synchronisé
1 min
PITR — Précision de restauration
Architecture HA Odizy

Chaque composant conçu
pour ne jamais tomber.

🎯 Odizy HA Controller

Orchestrateur central qui surveille en continu les clusters via Prometheus et pilote toute la logique de bascule. Détection automatique du lag de réplication et de l'état des nœuds, avec alerte dès qu'un standby devient injoignable.

  • Surveillance continue via Prometheus
  • Monitoring du lag de réplication
  • 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. Compatible tous workloads OLTP (Odoo, ERP…).

  • Réplication physique native PostgreSQL
  • RPO ≈ 0 en mode synchrone
  • Quelques secondes en mode asynchrone
🛡️ Anti split-brain
⚔️ STONITH intégré

Fencing du nœud défaillant avant toute promotion, pour éliminer le risque de double-primaire (split-brain). Garantit l'intégrité des données même en cas de partition réseau.

  • Fencing du nœud défaillant avant bascule
  • Zéro risque de double-écriture
  • Intégrité des données garantie
Failover automatique < 30 s

Promotion du standby en primaire en moins de 30 secondes, puis re-synchronisation automatique du nœud restauré via pg_rewind. Aucune intervention humaine requise.

  • Promotion standby → primaire
  • Re-sync automatique via pg_rewind
  • Zéro intervention manuelle
🔀 pgcat — Proxy Rust RW-split

Routage intelligent des connexions vers le primaire actif après une bascule. RW-split activable sur les offres dédiées (sous seuils stricts : RTT < 2 ms, lag < 200 ms).

  • Routage automatique post-bascule
  • RW-split sur offres dédiées
  • Seuils RTT et lag stricts
🌐 Cloudflare Load Balancer

Healthchecks PostgreSQL-aware (is_primary / is_standby) pour rediriger le trafic applicatif automatiquement après une bascule. Transparent pour les utilisateurs Odoo.

  • Healthchecks is_primary / is_standby
  • Redirection automatique post-failover
  • Transparent pour l'application Odoo
Réplication multi-datacenter

Vos données répliquées
en temps réel.

Clusters répliqués 2 AZ — Multi-cloud, multi-datacenter et sur site. RTO optimisé : le standby est prêt à prendre le relais instantanément.
Déploiements synchronisés — Sur plusieurs hôtes et datacenters simultanément. Votre infrastructure Odoo reste cohérente quelle que soit la zone défaillante.
PostgreSQL natif — aucun lock-in — Réplication physique WAL standard, sans extension propriétaire, compatible avec tous les outils PostgreSQL existants.
Backup & PITR pgBackRest

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

PITR — Point In Time Recovery — Sauvegardes continues via pgBackRest sur stockage objet multi-AZ (S3, OVH…). Restauration possible à la minute près — RPO optimisé pour les workloads critiques.
Stockage S3 multi-AZ — Transfert en 1 clic des bases entre clusters. Réutilisez vos backups de production en environnement de test ou de développement.
Rollback post-migration instantané — Une migration Odoo échoue ? Restaurez exactement à l'état précédant la mise à jour, sans perte de données.

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
Odizy HA Controller détecte via Prometheus que le nœud primaire est injoignable. Vérification du lag de réplication et de l'état du standby.
2
STONITH — 5 à 10 s
Fencing du nœud défaillant avant toute promotion. Garantit qu'il ne peut plus écrire en base — élimine définitivement le risque de split-brain.
3
Promotion — 10 à 20 s
Le standby est promu en primaire. pgcat redirige automatiquement les connexions. Cloudflare Load Balancer détecte le nouveau primaire via is_primary et bascule le trafic applicatif.
4
Re-synchronisation — après récupération
Le nœud restauré rejoint le cluster automatiquement via pg_rewind sans rebuild complet. Il reprend son rôle de standby et la réplication reprend.
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

Haute disponibilité Odoo — ce qu'il faut savoir.

Comment fonctionne la haute disponibilité PostgreSQL dans Odizy ?

Odizy déploie une architecture 2 AZ (primaire + standby) avec réplication physique WAL streaming. Odizy HA Controller surveille en continu les clusters via Prometheus. En cas de panne, STONITH fence le nœud défaillant, le standby est promu en moins de 30 secondes, et le trafic applicatif Odoo est redirigé automatiquement via pgcat et Cloudflare LB.

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. La restauration PITR via pgBackRest permet de revenir à n'importe quel point précis à la minute près.

Qu'est-ce que le STONITH et pourquoi est-il critique pour la HA ?

STONITH (Shoot The Other Node In The Head) est un mécanisme de fencing qui isole le nœud défaillant avant toute promotion du standby. Sans STONITH, deux nœuds pourraient simultanément se croire primaires (split-brain), entraînant une corruption de données irréversible. Odizy l'intègre nativement dans sa séquence de failover.

La HA Odizy fonctionne-t-elle en multi-cloud et en hybride ?

Oui. La réplication PostgreSQL WAL streaming est indépendante de l'infrastructure : primaire OVH + standby Scaleway, cloud + on-premise, multi-datacenter. 100% PostgreSQL natif — aucun lock-in propriétaire.

Comment assurer la haute disponibilité d'Odoo avec des instances on-premise ?

Odizy OnPremise intègre les mêmes mécanismes HA que l'offre cloud : réplication WAL, HA Controller, STONITH, pgBackRest. Il gère la haute disponibilité des instances Odoo on-premise, y compris entre plusieurs sites géographiques ou filiales, sans exposition sur Internet.

RTO < 30 s · RPO ≈ 0 · Failover automatique · PITR à la minute

Vos instances Odoo méritent
une infrastructure qui ne tombe pas.

Architecture 2 AZ · PostgreSQL natif · Multi-cloud & hybride · Souverain France

Voir nos offres → Pourquoi Odizy ? →