Protéger vos données à l'aide de la réplication zonale

Sélectionnez une version de la documentation :

Cette page décrit l'architecture de référence AlloyDB Omni à disponibilité améliorée, qui offre une haute disponibilité grâce au déploiement de plusieurs instances répliquées de base de données dans la même région. Cela permet de disposer d'une protection contre les défaillances au niveau des nœuds ou des zones.

Cas d'utilisation

Cette architecture de référence de disponibilité convient pour les cas d'utilisation suivants :

  • Applications critiques nécessitant un RTO et un RPO plus faibles.
  • Vous souhaitez déployer dans une autre zone ou sur un autre nœud une instance répliquée qui garantit une haute disponibilité pour vos bases de données et vous protège contre les défaillances d'instance, de serveur et de zone.
  • Vous souhaitez vous protéger contre les erreurs des utilisateurs et la corruption des données (à l'aide de sauvegardes).

Fonctionnement de l'architecture de référence

La disponibilité améliorée renforce la disponibilité standard en ajoutant des instances répliquées en lecture dans la région pour activer la haute disponibilité (HA). Cela réduit l'objectif de temps de récupération (RTO). Cette approche réduit également l'objectif de reprise après sinistre (RPO) en permettant la diffusion en flux continu des modifications transactionnelles vers l'instance répliquée.

La haute disponibilité dans AlloyDB Omni utilise au moins deux instances de base de données. Une instance sert de base de données principale. Elle accepte les opérations de lecture et d'écriture. Les instances restantes font office d'instances répliquées avec accès en lecture et fonctionnent en mode lecture seule.

Voici quelques concepts importants concernant la haute disponibilité :

  • Le basculement est une procédure opérée lors d'une panne imprévue. Lorsque l'instance principale subit une défaillance ou devient indisponible, l'instance répliquée de secours est activée pour prendre le relais en mode principal (lecture/écriture). Ce processus est appelé promotion. Dans les scénarios de ce type, lorsque le serveur ou la base de données principaux sont de nouveau en ligne, la base de données doit généralement être reconstruite et prendre le rôle de base de données de secours. Des mécanismes sont en place pour automatiser les basculements dans l'optique d'offrir une disponibilité élevée.
  • Une commutation, également appelée inversion de rôle, est une procédure utilisée pour inverser les modes entre la base de données principale et l'une des bases de données de secours. Ici, la base de données principale devient la base de données de secours, et inversement. Les commutations se font généralement de manière contrôlée et fluide. Elles peuvent être initiées pour de nombreuses raisons, par exemple pour permettre l'arrêt et la mise à jour de l'ancienne base de données principale. Des commutations fluides doivent permettre un futur retour en arrière sans qu'il soit nécessaire de réinstancier la nouvelle base de données de secours ni d'autres aspects de la configuration de la réplication.

Options de haute disponibilité

Dans les déploiements non Kubernetes, utilisez Patroni et HAProxy. Pour en savoir plus, consultez Architecture à haute disponibilité pour AlloyDB Omni pour PostgreSQL.

Remarque : Patroni et HAProxy sont des outils tiers non commerciaux et compatibles avec AlloyDB Omni.

Nous vous recommandons d'avoir au moins deux bases de données de secours afin que la perte d'une base de données n'ait pas d'incidence sur la haute disponibilité du cluster. Dans ce mode, vous disposez d'au moins une paire à haute disponibilité en cas de basculement ou lors de toute maintenance planifiée d'un nœud.

Pour planifier la taille et la forme de votre déploiement AlloyDB Omni, consultez Planifier votre installation AlloyDB Omni sur une VM.

Équilibreurs de charge

La présence d'un équilibreur de charge est un autre mécanisme important pour faciliter les procédures de commutation et de basculement.

Pour les déploiements non Kubernetes, le logiciel HAProxy fournit l'équilibrage de charge. HAProxy assure un équilibrage de charge en répartissant le trafic réseau sur plusieurs serveurs. HAProxy gère également l'état de fonctionnement des serveurs backends auxquels il se connecte en effectuant des vérifications d'état. Si un serveur échoue à une vérification d'état, HAProxy cesse de lui envoyer du trafic jusqu'à ce qu'il passe avec succès les nouvelles vérifications d'état.

Haute disponibilité

Les bases de données répliquées avec accès en lecture déployées dans une région offrent une haute disponibilité en cas de défaillance de la base de données principale. Si une défaillance de la base de données principale se produit, la base de données de secours est promue pour la remplacer. L'application continue ainsi de fonctionner, sans ou presque sans interruption.

Il est généralement recommandé d'effectuer des vérifications régulières (annuelles ou semestrielles) en procédant à des commutations pour s'assurer que toutes les applications qui s'appuient sur ces bases de données peuvent toujours se connecter et répondre dans un délai approprié.

La protection au niveau de la zone peut être obtenue avec l'un ou l'autre type de déploiement en plaçant l'une des instances répliquées de secours avec accès en lecture dans une zone de disponibilité différente de celle de la base de données principale.

Un autre avantage des instances répliquées avec accès en lecture est la possibilité de décharger les opérations en lecture seule sur les bases de données de secours, qui peuvent servir de bases de données de reporting utilisant des données à jour. Cette approche réduit la charge et les frais généraux sur l'instance principale avec accès en lecture/écriture.

Sauvegardes et configuration de la haute disponibilité

Les instances répliquées avec accès en lecture peuvent être configurées dans plusieurs zones offrant une haute disponibilité. Bien qu'elles offrent des RTO et RPO faibles, elles ne protègent pas contre certaines défaillances, comme la corruption logique des données (par exemple, la suppression accidentelle de tables ou la mise à jour incorrecte de données). Par conséquent, des sauvegardes régulières doivent être effectuées en plus de la configuration de la haute disponibilité. Pour en savoir plus, consultez la documentation sur l'architecture de disponibilité standard.

La figure 1 montre une configuration de haute disponibilité recommandée avec deux bases de données de secours disposant d'instances répliquées avec accès en lecture dans deux zones de disponibilité différentes.

AlloyDB Omni avec options de sauvegarde et de haute disponibilité

Figure 1 : AlloyDB Omni avec options de sauvegarde et de haute disponibilité.

Pour vous protéger contre la perte de données en cas de défaillance de l'instance principale, vous devez configurer la réplication en mode synchrone. Bien que cette méthode offre une protection solide des données, elle peut avoir un impact sur les performances de la base de données principale, car tous les commits doivent être écrits à la fois dans la base de données principale et dans toutes les bases de données de secours synchronisées. Une connexion réseau à faible latence entre ces instances de base de données est essentielle pour cette configuration.

Déploiements à haute disponibilité non Kubernetes

Le déploiement autonome non Kubernetes passe par une configuration manuelle qui nécessite des outils tiers. Il est plus complexe à configurer et à gérer que le déploiement Kubernetes.

Lorsque vous utilisez un déploiement non Kubernetes, certains paramètres affectent la façon dont un basculement est détecté, et la rapidité avec laquelle il se produit une fois que le nœud principal devient indisponible. Voici un bref récapitulatif de ces paramètres :

  • Ttl : délai maximal pour acquérir un verrou pour la base de données principale avant de lancer un basculement. La valeur par défaut est de 30 secondes.
  • Loop_wait : délai d'attente avant la prochaine vérification. La valeur par défaut est de 10 secondes.
  • Retry_timeout : délai avant rétrogradation de l'instance principale en raison d'une défaillance réseau. La valeur par défaut est de 10 secondes.

Pour en savoir plus, consultez Architecture à haute disponibilité pour AlloyDB Omni pour PostgreSQL.

Implémentation

Lorsque vous choisissez une architecture de référence de disponibilité, gardez à l'esprit les avantages, les limites et les alternatives suivants.

Avantages

  • Protège contre les défaillances d'instance.
  • Protège contre les défaillances du serveur.
  • Protège contre les défaillances de zones.
  • Le RTO est considérablement réduit par rapport à la disponibilité standard.

Limites

  • Aucune protection supplémentaire en cas de catastrophe régionale.
  • Impact potentiel sur les performances de l'instance principale en raison de la réplication synchrone.
  • La configuration du flux WAL PostgreSQL en mode synchrone permet d'éviter toute perte de données (RPO=0) en cas de fonctionnement normal ou de basculement typique. Toutefois, cette approche ne protège pas contre la perte de données dans des situations spécifiques de double défaillance, par exemple lorsque toutes les instances de secours sont perdues ou deviennent inaccessibles depuis l'instance principale, et que l'instance principale redémarre immédiatement après.

Alternatives

Étapes suivantes