Objectif

Cette page présente les principaux concepts et mécanismes permettant d'assurer la haute disponibilité de nos bases de données managées PostgreSQL. Nous décrivons ensuite plusieurs scénarios de panne et leurs conséquences.

Haute disponibilité

Public Cloud Databases pour PostgreSQL est disponible sur trois plans de service, offrant différents niveaux de haute disponibilité. Le plan sélectionné définit les fonctionnalités disponibles. Un résumé est fourni dans le tableau ci-dessous :

À propos des nœuds primaire et réplica

Un nœud est une machine virtuelle disposant de ressources dédiées (CPU, RAM, stockage).

Le nœud primaire, également appelé nœud maître, agit comme le leader de votre cluster. Il peut lire et écrire dans votre base de données. Il n'existe qu'un seul nœud primaire par cluster PostgreSQL.

Les nœuds réplicas sont optionnels et maintiennent des copies à jour des données du nœud primaire. Les nœuds réplicas n'autorisent pas les opérations d'écriture, uniquement les lectures.

Les nœuds primaire et réplica sont interchangeables : lorsque le nœud primaire rencontre un problème, le système déclenche un basculement automatique (failover). Un nœud réplica est promu et devient le nouveau leader du cluster. À partir de ce moment, il assume les fonctions du nœud primaire (par exemple, écritures, source de réplication des données). Le Service URI reste le même, et l'adresse IP interne change pour pointer vers le nouveau nœud primaire.

Disposer d'au moins un nœud réplica dans un cluster PostgreSQL apporte de nombreux avantages :

• Résilience des données : vos données sont répliquées vers une autre ressource physique, contenant des « données actives ».
• Haute disponibilité : en cas de panne du nœud primaire, le temps de restauration est considérablement réduit. Grâce au basculement automatique vers un nœud réplica, votre cluster et vos données sont de nouveau opérationnels en quelques minutes.
• Performance : pour les opérations en lecture seule, vous pouvez vous connecter aux nœuds réplicas, ce qui permet de réduire la charge sur le serveur primaire.

Il est important de disposer d'au moins deux nœuds réplicas, afin que même pendant la récupération après une panne (d'un seul nœud), il existe toujours deux copies des données sur deux nœuds différents. Si une autre panne survient après un basculement, alors qu'un seul nœud maître est en cours d'exécution, on risque à nouveau de perdre certaines des dernières modifications écrites dans la base de données. La reconstruction d'un nouveau nœud de secours et sa synchronisation après un basculement peuvent prendre du temps lorsque la base de données contient un volume important de données, et il est souvent judicieux de protéger les données pendant cette période en disposant d'un autre réplica. Cela est particulièrement important lorsque la taille de la base de données est importante et que la recréation d'un nœud de remplacement pour celui en défaut peut prendre plusieurs heures.

Nous pouvons représenter un cluster de cette manière :

À propos des sauvegardes et restaurations

OVHcloud utilise le démon de sauvegarde populaire et open source PGHoard pour les sauvegardes et restaurations. Il effectue des copies en temps réel des fichiers Write Ahead Logs (WAL) de PostgreSQL, chiffre et compresse les fichiers. Les fichiers de sauvegarde sont stockés dans des conteneurs OVHcloud Object Storage.

Vous trouverez plus d'informations sur leur page officielle : https://github.com/aiven/pghoard.

Scénarios de panne

Nous distinguons deux catégories de pannes :

• Pannes mineures, telles que les plantages de processus de service ou les pertes temporaires d'accès réseau, sont gérées automatiquement par OVHcloud dans tous les plans, sans changement majeur du déploiement du service.
• Pannes sévères, telles que la perte complète d'un nœud en cas de problème matériel ou logiciel critique. L'infrastructure de supervision d'OVHcloud détecte automatiquement un nœud défaillant lorsque celui-ci commence à signaler des problèmes dans son autodiagnostic ou lorsqu'il cesse de communiquer. Dans ce cas, l'infrastructure de supervision planifie automatiquement la création d'un nouveau nœud pour remplacer celui qui est défaillant.

L'impact des différents scénarios de panne dépend du plan de service sélectionné, car le nombre de nœuds y est lié. Consultez la section correspondant à votre offre.

Tableau comparatif

Le tableau ci-dessous résume les scénarios détaillés dans les paragraphes suivants.

Le RPO est le Recovery Point Objective, c'est-à-dire jusqu'à quel point dans le temps avant l'incident vous pouvez récupérer les données. Le RTO est le Recovery Time Objective, c'est-à-dire le temps nécessaire pour revenir à une situation normale.

Scénarios pour les plans de service Essential/Discovery à nœud unique

Les plans Essential/Discovery fournissent un seul nœud : il n'y a pas de réplica.

Panne du nœud

OVHcloud détecte la perte du nœud. Il commence immédiatement à créer un nouveau nœud de remplacement. Une fois le nouveau nœud opérationnel, il restaure son état à partir de la dernière sauvegarde disponible, puis reprend ses opérations.

Comme il n'y a qu'un seul nœud, pendant tout le processus de récupération, vos bases de données sont indisponibles. Vous ne pouvez ni les lire ni écrire dessus. De plus, certaines données d'opérations d'écriture peuvent avoir été perdues, car la restauration se fait à partir de la dernière sauvegarde et des derniers fichiers Write Ahead Logs (WAL) de PostgreSQL sauvegardés. En général, cette fenêtre temporelle est limitée à cinq minutes ou à un fichier WAL.

La durée du processus de récupération dépend du volume de données stockées, de la région et de la bande passante réseau. OVHcloud ne peut garantir un temps de récupération maximal, et vous pouvez vous attendre à quelques heures.

Aucune intervention n'est requise de la part du client.

Panne du datacenter

OVHcloud détecte également la perte d'un datacenter entier. En tant qu'utilisateur, votre cluster reste visible dans l'API et l'espace client.

Les sauvegardes automatiques sont d'abord effectuées sur site (c'est-à-dire dans la même région que le service), puis répliquées hors site, vers un autre datacenter.

En cas de panne du datacenter, la stratégie de récupération consiste à créer un nouveau service dans une autre région, soit en le dupliquant à partir d'une sauvegarde automatique (création d'un fork) répliquée hors site, soit en le restaurant à partir de sauvegardes effectuées manuellement (par exemple, pg_restore d'un pg_dump effectué précédemment). Vous devrez ensuite configurer le service nouvellement créé (par exemple, ajouter des utilisateurs, des restrictions d'IP, etc.) et reconfigurer les applications consommant le service de base de données pour utiliser les nouveaux URI de service et identifiants. Dans les deux cas, le Recovery Time Objective variera en fonction de plusieurs paramètres tels que le volume de données à restaurer, la congestion et la latence réseau, ou les performances des nœuds. Cela peut prendre de quelques heures à quelques jours.

Scénarios pour les plans de service hautement disponibles Business/Production et Enterprise/Advanced

Le plan Business/Production fournit un nœud primaire et un nœud réplica, le plan Enterprise/Advanced démarre avec un nœud primaire et deux nœuds réplicas.

Panne d'un nœud réplica

Lorsque le nœud défaillant est un nœud réplica PostgreSQL, le nœud primaire continue de fonctionner normalement et fournit un niveau de service normal aux applications clientes. Cependant, les applications qui lisent des données directement depuis le nœud réplica défectueux peuvent subir une dégradation du service.

OVHcloud détecte automatiquement la perte d'un nœud réplica et attend 300 secondes avant de créer un nouveau nœud réplica. Ce délai permet à OVHcloud de s'assurer que le nœud est durablement défaillant (et qu'il ne s'agit pas, par exemple, d'une panne réseau). Une fois le nouveau nœud réplica de remplacement prêt et synchronisé avec le nœud primaire, il commence à répliquer le nœud primaire en temps réel, la situation revenant alors à la normale.

Si les deux nœuds réplicas PostgreSQL tombent en panne, le même processus se produit, mais cette fois deux fois de suite.

Bien qu'OVHcloud ne puisse pas s'engager sur une durée fixe pour l'ensemble du processus, vous pouvez vous attendre à une absence d'interruption de service puisque le primaire reste opérationnel, et à quelques heures pour que les nouveaux nœuds de remplacement soient prêts et opérationnels (le temps de restaurer les données).

Aucune intervention n'est requise de la part du client.

Panne du nœud primaire

Lorsque le nœud défaillant est un nœud primaire PostgreSQL, les informations combinées de l'infrastructure de supervision d'OVHcloud et du nœud réplica sont utilisées pour décider d'un basculement automatique.

Après un délai de 60 secondes, le nœud réplica est alors promu au rôle de primaire et commence immédiatement à servir les applications clientes. Un nouveau nœud de remplacement est automatiquement planifié et devient le nouveau nœud réplica.

Panne de tous les nœuds

Si les nœuds primaire et réplicas tombent tous en panne en même temps, la création de nouveaux nœuds pour devenir le nouveau primaire et les nouveaux réplicas est automatiquement planifiée. Le nœud primaire est restauré à partir de la dernière sauvegarde disponible. Cela peut entraîner une perte de données, car toute opération d'écriture postérieure à la sauvegarde du dernier fichier WAL est perdue. En général, cette fenêtre temporelle est limitée à cinq minutes ou à un fichier WAL.

La durée du processus de récupération dépend du volume de données stockées, de la région et de la bande passante réseau. OVHcloud ne peut garantir un temps de récupération maximal, mais vous pouvez vous attendre à quelques heures. Pendant cette période, votre service reste indisponible.

Aucune intervention n'est requise de la part du client.

Panne du datacenter

OVHcloud détecte également la perte d'un datacenter entier. En tant qu'utilisateur, votre cluster reste visible dans l'API et l'espace client.

Les sauvegardes automatiques sont d'abord effectuées sur site (c'est-à-dire dans la même région que le service), puis répliquées hors site, vers un autre datacenter.

En cas de panne du datacenter, la stratégie de récupération consiste à créer un nouveau service dans une autre région, soit en le dupliquant à partir d'une sauvegarde automatique (création d'un fork) répliquée hors site, soit en le restaurant à partir de sauvegardes effectuées manuellement (par exemple, pg_restore d'un pg_dump effectué précédemment). Vous devrez ensuite configurer le service nouvellement créé (par exemple, ajouter des utilisateurs, des restrictions d'IP, etc.) et reconfigurer les applications consommant le service de base de données pour utiliser les nouveaux URI de service et identifiants. Dans les deux cas, le Recovery Time Objective variera en fonction de plusieurs paramètres tels que le volume de données à restaurer, la congestion et la latence réseau, ou les performances des nœuds. Cela peut prendre de quelques heures à quelques jours.

Nous voulons vos retours !

Nous serions ravis de répondre à vos questions et apprécions tout retour que vous pourriez nous faire.

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

Vous êtes sur Discord ? Rejoignez notre chaîne via https://discord.gg/ovhcloud et interagissez directement avec l’équipe qui développe notre service de bases de données !