Protéger vos données avec la réplication zonale et régionale

Sélectionnez une version de la documentation :

Cette page décrit l'architecture de référence AlloyDB Omni Premium Availability, qui inclut la protection des données à l'aide de la réplication zonale dans une région (haute disponibilité) et ajoute une protection de reprise après sinistre à l'aide du streaming asynchrone sur de grandes zones géographiques.

Cette architecture de référence est particulièrement adaptée aux cas d'utilisation suivants :

  • Vous avez besoin d'une protection régionale en plus de votre protection zonale pour vos applications critiques.

Cette architecture de référence de disponibilité intègre des réplicas en lecture dans la région pour la haute disponibilité et dans les régions pour la reprise après sinistre. Ce déploiement multirégional protège contre les perturbations importantes, y compris les pannes de courant généralisées et les catastrophes naturelles à grande échelle.

Considérations relatives à l'architecture de référence pour la disponibilité

Lorsque vous évaluez cette architecture de référence de disponibilité, tenez compte des facteurs suivants :

  • Latence et bande passante du réseau dans la région et entre les régions
  • Emplacement géographique des bases de données et des serveurs d'application
  • Stratégie pour décharger les charges de travail en lecture seule sur les répliques
  • Déployer la haute disponibilité dans la région de reprise après sinistre à distance

Un équilibrage de charge en lecture seule peut être nécessaire, en particulier si vous utilisez des serveurs d'application régionaux, afin que les requêtes soient transférées vers la base de données la plus proche pour obtenir la réponse la plus rapide. Pour en savoir plus, consultez Routage des requêtes vers un équilibreur de charge d'application classique multirégional.

Une surveillance supplémentaire peut être nécessaire pour la réplication multirégionale afin de s'assurer que le décalage de réplication ne commence pas à augmenter en raison de la charge de transactions ou de la capacité du réseau.

Pour que votre reprise après sinistre soit réussie, veillez à effectuer des tests approfondis. Il est important de tester la fonctionnalité et le débit de l'application en cas de connexions réseau à latence élevée entre les serveurs d'applications et la base de données.

Architectures HA dans une région et DR interrégionales

La figure 1 montre une configuration de haute disponibilité et de reprise après sinistre suggérée avec trois bases de données de secours répliquées en lecture dans trois zones de disponibilité et deux régions.

AlloyDB Omni avec options de sauvegarde et de haute disponibilité interrégionale

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

Comme l'illustre la figure 1, la réplication par flux synchrone vers des répliques locales (dans la même région) offre une haute disponibilité, tandis que la réplication par flux asynchrone vers une réplique distante géographiquement distincte offre une protection contre les sinistres régionaux. Dans l'ensemble de la configuration, seule l'instance principale peut effectuer des opérations de lecture/écriture, tandis que les autres instances répliquées peuvent répondre aux requêtes de lecture.

Configurez la réplication de l'instance principale vers les instances dupliquées de la même région en mode synchrone, tandis que la réplication vers les instances dupliquées interrégionales doit être configurée en mode asynchrone pour éviter que la latence n'affecte les performances d'écriture de l'instance principale. En cas de défaillance régionale, cette configuration peut entraîner un RPO non nul. Toutefois, cette configuration permet un RTO plus rapide en cas de défaillance. En effet, la base de données principale n'a pas besoin d'attendre la confirmation des bases de données de secours distantes avant de valider les transactions.

Il est possible d'effectuer des sauvegardes interrégionales supplémentaires à partir des bases de données répliquées en lecture seule et d'ajouter ainsi de la redondance aux sauvegardes effectuées à partir de la base de données principale.

Sauvegardes des instances répliquées avec accès en lecture

Lorsque vous utilisez des déploiements Kubernetes, le déploiement secondaire dans la région alternative est automatiquement configuré avec des sauvegardes supplémentaires. Lorsque vous utilisez des déploiements non Kubernetes, vous pouvez choisir de déployer des sauvegardes en fonction des besoins de votre entreprise. Réfléchissez aux éléments suivants :

  • Si votre sauvegarde à distance est susceptible d'être affectée par une défaillance de région, vous devez lancer des sauvegardes supplémentaires dans les régions alternatives.
  • Si vous avez besoin d'une redondance de sauvegarde, vous devez effectuer des sauvegardes régionales d'instances répliquées avec accès en lecture.

Emplacement de l'instance répliquée avec accès en lecture pour prendre en charge la disponibilité multizone

Dans les déploiements non Kubernetes, vous pouvez choisir des instances répliquées avec accès en lecture spécifiques pour qu'elles assument le rôle de l'instance principale en cas de défaillance de celle-ci. L'opérateur AlloyDB Omni Kubernetes gère automatiquement le placement des nœuds dans les zones et les nœuds sur lesquels les pods doivent être déployés. Certaines options de configuration qui affectent le placement, telles que l'affinité et la tolérance des pods, sont disponibles dans la configuration de la base de données utilisée pour le déploiement avec l'opérateur AlloyDB Omni.

Migration d'une architecture HA uniquement vers une architecture HA et DR

Pour les déploiements non Kubernetes, vous devez créer une nouvelle instance de secours dans une nouvelle région et ajouter cette configuration à la configuration du cluster Patroni. Pour les déploiements Kubernetes, vous devez créer un déploiement Kubernetes régional, appelé cluster de base de données secondaire, et activer la réplication inter-centres de données.

Implémentation

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

Avantages

  • Protection contre les défaillances de zones et d'instances
  • Protection contre les défaillances régionales
  • RTO réduit lorsque la base de données subit une défaillance régionale

Limites

  • Vous pouvez réduire le RPO pour la récupération régionale avec la réplication synchrone, mais cette approche entraîne une latence supplémentaire pour les performances des transactions. Pour la reprise après sinistre et la réplication dans une région distante, nous vous recommandons d'utiliser uniquement la réplication asynchrone.
  • La configuration du streaming 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.

Options de protection des données

Étapes suivantes