Les principaux objectifs d'une configuration multi-centre de données (ou multi-DC) - que l'écosystème de base de données soit SQL (PostgreSQL, MySQL) ou NoSQL (MongoDB, Cassandra) pour n'en nommer que quelques-uns - sont une faible latence pour les utilisateurs finaux, Haute disponibilité et reprise après sinistre. Au cœur d'un tel environnement se trouve la capacité de répliquer les données, de manière à garantir leur durabilité (en passant, les paramètres de configuration de durabilité de Cassandra sont similaires à ceux utilisés par PostgreSQL). Les différentes exigences de réplication seront discutées ci-dessous, cependant, les cas extrêmes seront laissés aux curieux pour des recherches plus approfondies.
La réplication utilisant l'envoi de journaux asynchrone est disponible dans PostgreSQL depuis longtemps, et la réplication synchrone introduite dans la version 9.1 a ouvert un tout nouvel ensemble d'options aux développeurs d'outils de gestion PostgreSQL.
Éléments à considérer
Une façon de comprendre la complexité d'une implémentation PostgreSQL multi-DC est d'apprendre des solutions mises en œuvre pour d'autres systèmes de base de données, tout en gardant à l'esprit que PostgreSQL insiste pour être conforme à ACID.
Une configuration multi-DC comprend, dans la plupart des cas, au moins un centre de données dans le cloud. Bien que les fournisseurs de cloud prennent en charge la gestion de la réplication de la base de données pour le compte de leurs clients, ils ne correspondent généralement pas aux fonctionnalités disponibles dans les outils de gestion spécialisés. Par exemple, avec de nombreuses entreprises adoptant des solutions de cloud hybride et/ou multi-cloud, en plus de leur infrastructure existante sur site, un outil multi-DC devrait être capable de gérer un tel environnement mixte.
De plus, afin de minimiser les temps d'arrêt lors d'un basculement, le système de gestion PostgreSQL doit pouvoir demander (via un appel API) une mise à jour DNS, afin que les demandes de base de données soient acheminées vers le nouveau cluster maître.
Les réseaux couvrant de vastes zones géographiques sont des connexions à latence élevée et toutes les solutions doivent faire des compromis :oubliez la réplication synchrone et utilisez un principal avec de nombreux réplicas en lecture. Voir les études AWS MongoDB et Manynines/Galera Cluster pour une analyse approfondie des effets du réseau sur la réplication. Sur une note connexe, un outil astucieux pour tester la latence entre les emplacements est Wonder Network Ping Statistics.
Bien que la nature à latence élevée du WAN ne puisse pas être modifiée, l'expérience utilisateur peut être considérablement améliorée en s'assurant que les lectures sont servies à partir d'un réplica en lecture proche de l'emplacement de l'utilisateur, mais avec quelques mises en garde. En éloignant les réplicas du primaire, les écritures sont retardées et nous devons donc supprimer la réplication synchrone. La solution doit également être capable de contourner d'autres problèmes tels que la cohérence lecture après écriture et les lectures secondaires obsolètes en raison d'une perte de connexion.
Afin de minimiser le RTO, les données doivent être répliquées sur un stockage durable qui est également capable de fournir un débit de lecture élevé, et selon Citus Data, une option qui répond à ces exigences est AWS S3.
La notion même de plusieurs centres de données implique que le système de gestion de base de données doit être capable de présenter au DBA une vue globale de tous les centres de données et des différents clusters PostgreSQL en leur sein, de gérer plusieurs versions de PostgreSQL et de configurer la réplication entre eux.
Lors de la réplication d'écritures vers des centres de données régionaux, le délai de propagation doit être surveillé. Si le délai dépasse un seuil, une alarme doit être déclenchée indiquant que la réplique contient des données obsolètes. Le même principe s'applique à la réplication multi-maître asynchrone.
Dans une configuration synchrone, une latence élevée ou des perturbations du réseau peuvent entraîner des retards dans le traitement des demandes des clients en attendant la fin de la validation, tandis que dans les configurations asynchrones, il existe des risques de split-brain ou de dégradation des performances pendant une période prolongée. Le split-brain et les retards sur les commits synchrones sont inévitables même avec des solutions de réplication bien établies, comme expliqué dans l'article Grappes de bases de données géo-distribuées avec Galera.
Une autre considération est la prise en charge des fournisseurs - à ce jour, AWS ne prend pas en charge les répliques interrégionales PostgreSQL.
Les systèmes de gestion intelligents doivent surveiller la latence du réseau entre les centres de données et recommander ou ajuster les changements, par ex. la réplication synchrone fonctionne parfaitement entre les zones de disponibilité AWS où les centres de données sont connectés à l'aide de réseaux fibre. De cette façon, une solution peut atteindre zéro perte de données et elle peut également implémenter une réplication maître-maître ainsi qu'un équilibrage de charge. Notez qu'AWS Aurora PostgreSQL ne fournit pas actuellement d'option de réplication maître-maître.
Décidez du niveau de réplication :cluster, base de données, table. Les critères de décision doivent inclure les coûts de bande passante.
Implémentez la réplication en cascade afin de contourner les perturbations du réseau qui peuvent empêcher les répliques de recevoir les mises à jour du maître en raison de la distance géographique.
Solutions
En tenant compte de toutes les exigences, identifiez les produits les mieux adaptés au travail. Une mise en garde cependant :chaque solution comporte ses propres mises en garde qui doivent être traitées en suivant les recommandations de la documentation du produit. Voir par exemple l'exigence de surveillance BDR.
La documentation officielle de PostgreSQL contient une liste d'applications open source non commerciales, et une liste étendue comprenant des solutions commerciales à source fermée peut être trouvée sur la page wiki Replication, Clustering, and Connection Pooling. Quelques-uns de ces outils ont été examinés plus en détail dans l'article Top PG Clustering HA Solutions for PostgreSQL.
Il n'existe pas de solution clé en main, mais certains produits peuvent fournir la plupart des fonctionnalités, en particulier lorsque vous travaillez avec le fournisseur.
Voici une liste non exhaustive :
- Citus Data fournit sa propre version PostgreSQL, enrichie de fonctionnalités d'entreprise impressionnantes et d'une intégration approfondie avec AWS.
- EnterpriseDB propose une large gamme de services qui peuvent être combinés pour répondre à la plupart des besoins. La plupart des informations se trouvent dans la documentation du produit.
- Postgres-BDR est un puissant outil de réplication conçu spécifiquement pour les clusters distribués géographiquement, mais il ne s'intègre à aucun fournisseur de cloud.
- ClusterControl est livré avec un ensemble de fonctionnalités impressionnant pour la gestion de PostgreSQL. Son intégration au cloud est également limitée.
- ElephantSQL fonctionne avec de nombreux fournisseurs de cloud. Cependant, il n'y a pas d'option pour une configuration sur site.
- Crunchy PostgreSQL pour Kubernetes est un produit cloud indépendant basé sur PostgreSQL en amont.
Conclusion
Comme nous l'avons vu, lorsqu'il s'agit de choisir une solution multi-datacenter PostgreSQL, il n'existe pas de solution unique. Souvent, le compromis est un must. Cependant, une bonne compréhension des exigences et des implications peut grandement contribuer à prendre une décision éclairée.
Par rapport aux données statiques (en lecture seule), une solution pour les bases de données doit prendre en compte la réplication des mises à jour (écritures). La littérature décrivant à la fois les solutions de réplication SQL et NoSQL insiste sur l'utilisation d'une seule source de vérité pour les écritures avec de nombreuses répliques afin d'éviter des problèmes tels que le split-brain et la cohérence lecture après écriture.
Enfin, l'interopérabilité est une exigence clé étant donné que les configurations multi-DC peuvent couvrir des centres de données situés sur site et divers fournisseurs de cloud.
