L'architecture du cluster mutualisé PostgreSQL
Les données sont répliquées en simultané sur les machines Standby et Lead Standby. Cette dernière autorise des actions en lecture seule des data, par exemple pour réaliser des statistiques, sans ralentir la production. Les quatre machines sont incluses dans la métrologie.
Automatisation à 100 % via Ansible
L’installation, l’administration courante, les mises à jour mineures et majeures) ainsi que l’ajout de nouveaux clients (~3500 lignes de code) sont entièrement automatisés via Ansible. Cette automatisation permet de garantir que la plateforme soit conforme aux préconisations, à jour en termes de patch de sécurité. Elle évite également les potentielles erreurs humaines, inhérentes à toute manipulation manuelle. Petit plus, lorsqu’une modification de sécurité ou de configuration doit être déployée, ce système entièrement automatisé permet de l’appliquer en moins de 15 minutes pour tous les clients hébergés sur cette plateforme !
Haute disponibilité : Patroni pour gérer la bascule automatique
Pour permettre une bascule la plus transparente possible en cas d’un dysfonctionnement quelconque, la solution de Zalando, Patroni a été retenue. Elle gère automatiquement la bascule du serveur primaire en fonction de divers paramètres définis par les experts Sigma. Elle a aussi un autre grand avantage : elle ne rajoute pas de complexité dans l’administration courante. Les administrateurs gardent ainsi leurs (bonnes) habitudes, tout en profitant d’un système qui traite les incidents en complète autonomie. Patroni se basant sur etcd, nous profitons de RAFT, ce célèbre protocole de gestion de consensus en informatique :
- Terminaison : tout processus doit décider une valeur
- Intégrité : tout processus décide une valeur qui a été proposée par un des processus,
- Accord : tous les processus décident la même valeur
Cela garantit une absence complète de Split-Brain, cas tant redouté où deux machines se croient décisionnelles. Elles acceptent donc toutes deux des données, ce qui débouche sur une perte de data inévitable.
Sauvegarde gérée par pgbackrest
L’importance des sauvegardes n'est plus à démontrer ! Chez Sigma, nous avons opté pour pgbackrest, en vue d'un fonctionnement des plus fiables. Cette solution permet de proposer du PITR (Point In Time Recovery) et ainsi restaurer un cluster à une heure choisie (en cas de suppression malheureuse de table, par exemple). Pour garantir un débit de restauration rapide, pas de dump mais sauvegarde directe des fichiers binaires afin de limiter les impacts sur les serveurs (pas de LOCK notamment).
Pooler de connexion : l'efficacité redoutable de PgBouncer
Un pooler de connexion permet d’augmenter significativement la réactivité des applicatifs, en maintenant ouvertes les sessions vers les serveurs de base de données, ce qui rend plus rapide l'ouverture de sessions depuis les clients. Ce travail a été confié à PgBouncer, reconnu comme étant fiable et d'une efficacité redoutable. Il permet même la mutualisation de sessions dans le serveur de base, économisant ainsi des ressources. Dernier point important pour ce pooler : il va permettre de désactiver temporairement l'un des nœuds pour effectuer des maintenances. Cela de manière totalement transparente pour tout applicatif.
Métrologie et supervision : les métriques complets de pgwatch2
Maintenir une plateforme robuste demande un temps considérable. En plus de l’automatisation complète, il est nécessaire d'en suivre la vie et d'en prévoir l’avenir. L'outil de monitoring pgwatch2 fournit des métriques complètes sur la plateforme jusqu'à produire si nécessaire un compte rendu d’activité détaillée. Sur demande de prestation il est également possible de procéder à des analyses très poussées pour remonter des axes d’améliorations d'une base : tuning fin, modification de schémas, ajout/modification d’INDEX, analyse de requêtes… Les scripts check_postgres fournis par Bucardo sont utilisés pour superviser la plateforme.
Des mises à jour transparentes et sans impact
Qui dit plateforme haute-disponibilité dit suivi régulier des évolutions de versions (patchs de sécurité, évolution majeure). Ainsi, via le pooler de connexion, les versions mineures (et donc les patchs de sécurité) sont mises à jour sans aucun impact. Les mises à jour de versions majeures de manière automatique sont réalisées de la manière suivante :
- Mise à disposition d’une plateforme dans la version de destination avec les bases client (à partir du dernier backup)
- Attente de validation client
- Tests de mise à jour (pg_upgrade --check)
- Coupure des accès si le test est concluant, sinon une alerte est levée et un administrateur intervient immédiatement
- Si les tests sont concluants, la mise à jour réelle est effectuée
- Réouverture des accès
Pour minimiser l’impact sur la production, cette partie a également été automatisée par les équipes Sigma. A titre indicatif, une base de 300 Go est coupée en général moins de 2 minutes !
Un peu d'histoire : d'Ingres à PostgreSQL La paternité de cette solution revient au scientifique et informaticien américain Michaël Stonebraker, prix Turing 2014. En 1985, alors qu'il est déjà le créateur de la base de données Ingres, celui-ci décide de reprendre le développement à partir de zéro : Postgres est ainsi le raccourci de Post-Ingres. Avec l'apport des fonctionnalités sql, le nom évolue en 1996 vers PostgreSQL. https://www.postgresql.org/
