Beaucoup connaissent le SGBD PostgreSQL, qui s'est parfaitement installé sur de petites installations. Cependant, la tendance à passer à l'Open Source devient de plus en plus évidente, même en ce qui concerne les grandes entreprises et les exigences enterprise. Dans cet article, nous allons expliquer comment intégrer Postgres dans un environnement d'entreprise et partager notre expérience de la création d'un système de sauvegarde (SRK) pour cette base de données en prenant comme exemple le système de sauvegarde Commvault.
PostgreSQL a déjà prouvé sa valeur - ce SGBD fonctionne très bien, utilisé par des entreprises numériques en vogue telles qu'Alibaba et TripAdvisor, et l'absence de frais de licence en fait une alternative séduisante à des géants comme MS SQL ou Oracle DB. Mais dès que nous commençons à réfléchir à PostgreSQL dans le paysage de l'Enterprise, nous nous heurtons immédiatement à des exigences strictes : "Comment assurer la résilience de la configuration ? la résilience en cas de catastrophe ? où est la surveillance complète ? et la sauvegarde automatisée ? et l'utilisation de bibliothèques de bandes, à la fois directement et pour le stockage secondaire ?"
D'une part, PostgreSQL n'a pas les outils de sauvegarde intégrés que possèdent des SGBD "adultes" comme RMAN d'Oracle DB ou SAP Database Backup. D'autre part, les fournisseurs de systèmes de sauvegarde pour entreprises (Veeam, Veritas, Commvault), bien qu'ils supportent PostgreSQL, ne fonctionnent en réalité qu'avec certaines configurations (généralement indépendantes) et avec un ensemble de diverses limitations.
Des systèmes de sauvegarde spécifiquement conçus pour PostgreSQL, tels que Barman, Wal-g, pg_probackup, sont extrêmement populaires dans de petites installations du SGBD PostgreSQL ou là où des sauvegardes lourdes d'autres éléments du paysage IT ne sont pas nécessaires. Par exemple, en plus de PostgreSQL, l'infrastructure peut comprendre des systèmes physiques et virtuels, OpenShift, Oracle, MariaDB, Cassandra, etc. Tout cela devrait être sauvegardé avec un outil commun. Installer une solution distincte uniquement pour PostgreSQL est une idée peu judicieuse : les données seront copiées quelque part sur un disque, puis elles devront être transférées sur bande. Ce double travail de sauvegarde augmente le temps de sauvegarde et, ce qui est plus critique, celui de la restauration. serveurs, OpenShift, Oracle, MariaDB, Cassandra, etc. Il est préférable de sauvegarder tout cela avec un outil commun. Mettre en place une solution distincte uniquement pour PostgreSQL est une mauvaise idée : les données seront copiées quelque part sur un disque, puis elles devront être transférées sur une bande. Ce double processus de sauvegarde augmente le temps de sauvegarde et, plus critique encore, le temps de restauration.
Dans une solution enterprise, la sauvegarde de l'installation se fait avec un certain nombre de nœuds d'un cluster dédié. Par exemple, Commvault ne peut travailler qu'avec un cluster à deux nœuds, où le Primary et le Secondary sont fixés à des nœuds spécifiques. Et il n'y a de sens à faire des backups qu'avec le Primary, car la sauvegarde du Secondary présente certaines limitations. En raison des particularités du SGBD, un dump n'est pas créé sur le Secondary, ce qui limite donc les options à la sauvegarde de fichiers.
Pour réduire les risques de temps d'arrêt, lors de la création d'un système tolérant aux pannes, une configuration de cluster « vivante » est formée et le Primary peut migrer progressivement entre différents serveurs. Par exemple, le logiciel Patroni lance automatiquement le Primary sur un nœud choisi au hasard du cluster. Le SRE n'a pas de moyen de suivre cela « par défaut », et si la configuration change, les processus échouent. Cela signifie que la mise en œuvre d'une gestion externe empêche le SRE de fonctionner efficacement, car le serveur de gestion ne comprend tout simplement pas d'où et quelles données doivent être copiées.
Un autre problème est la mise en œuvre du backup dans Postgres. Elle est possible via dump, et cela fonctionne sur de petites bases. Mais dans de grandes bases de données, le dump prend du temps, nécessite beaucoup de ressources et peut entraîner un échec de l'instance de la base de données.
La sauvegarde de fichiers corrige la situation, mais sur de grandes bases, elle est lente, car elle fonctionne en mode mono-thread. De plus, les fournisseurs rencontrent un certain nombre de limitations supplémentaires. Parfois, il n'est pas possible d'utiliser simultanément la sauvegarde de fichiers et celle par dump, parfois la déduplication n'est pas prise en charge. Il y a beaucoup de problèmes, et il est souvent plus simple de choisir une SGBD coûteuse mais éprouvée plutôt que Postgres.
Il n'y a pas de retour en arrière ! Les développeurs de Moscou sont derrière nous !
Cependant, récemment, notre équipe s'est retrouvée face à un défi difficile : dans le projet de création de l'AIS OSAGO 2.0, où nous avons développé l'infrastructure IT, les développeurs pour le nouveau système ont choisi PostgreSQL.
Pour les grands développeurs de logiciels, il est beaucoup plus facile d'utiliser des solutions open-source « tendance ». Dans le personnel de Facebook, il y a suffisamment de spécialistes pour maintenir le fonctionnement de ce SGBD. Mais dans le cas du RSA, toutes les tâches « du deuxième jour » reposaient sur nos épaules. Nous devions assurer la tolérance aux pannes, constituer un cluster et, bien sûr, établir des sauvegardes. La logique des actions était la suivante :
- Enseigner à l'SRK à faire des sauvegardes depuis la nœud principal du cluster. Pour cela, l'SRK doit le localiser — donc, une intégration avec une solution de gestion de cluster PostgreSQL est nécessaire. Dans le cas de RSA, le logiciel Patroni a été utilisé pour cela.
- Déterminer le type de sauvegarde en fonction des volumes de données et des exigences de restauration. Par exemple, lorsqu'une restauration granulaire des pages est nécessaire, utiliser un dump, et si les bases sont importantes et qu'une restauration granulaire n'est pas requise — travailler au niveau des fichiers.
- Ajouter à la solution la possibilité de sauvegarde par blocs, afin de créer des copies de sauvegarde en mode multithreading.
Dans cette optique, nous avons d'abord visé à créer un système efficace et simple sans des composants supplémentaires encombrants. Moins il y a d'artifices, moins la charge sur le personnel est importante et plus le risque de défaillance de l'SRK est réduit. Les approches utilisant Veeam et RMAN ont été immédiatement exclues car un ensemble de deux solutions indique déjà une instabilité du système.
Un peu de magie pour l'entreprise
Ainsi, nous devions garantir une sauvegarde fiable pour 10 clusters de 3 nœuds chacun, avec une infrastructure miroir dans le datacenter de sauvegarde. Les datacenters fonctionnent sur le principe actif-passif pour PostgreSQL. Le volume total des bases de données était de 50 To. Cela peut être facilement géré par n'importe quel SRK niveau entreprise. Mais la nuance est qu'il n'y a pas initialement de prise en charge complète et approfondie des systèmes de sauvegarde dans Postgres. Il a donc fallu chercher une solution qui possède dès le départ un maximum de fonctionnalités en association avec PostgreSQL, et adapter le système.
Nous avons organisé 3 hackathons internes — avons examiné plus de cinquante développements, les avons testés, apporté des modifications en fonction de nos hypothèses, puis vérifié à nouveau. En analysant les options disponibles, nous avons choisi Commvault. Ce produit pouvait déjà fonctionner « prêt à l'emploi » avec la plus simple installation de cluster PostgreSQL, et son architecture ouverte offrait l'espoir (qui s'est avéré justifié) d'une intégration et d'un développement réussis. De plus, Commvault peut effectuer des sauvegardes des journaux de PostgreSQL. Par exemple, Veritas NetBackup ne peut réaliser que des sauvegardes complètes pour PostgreSQL.
En savoir plus sur l'architecture. Les serveurs de gestion Commvault ont été installés dans chacun des deux centres de données en configuration CommServ HA. Le système est redondant, géré via une seule console et répond à tous les critères de HA pour les entreprises.
Dans chaque centre de données, nous avons également lancé deux serveurs de médias physiques, auxquels des systèmes de stockage dédiés spécialement pour les sauvegardes et des bibliothèques de bandes ont été connectés via SAN par Fibre Channel. Les bases de déduplication étendues ont assuré la résilience des serveurs de médias, et la connexion de chaque serveur à chaque CSV a permis un fonctionnement continu en cas de défaillance de n'importe quel composant. L'architecture du système permet de poursuivre la sauvegarde même si l'un des centres de données tombe en panne.
Patroni détermine le nœud primaire pour chaque cluster. Il peut s'agir de n'importe quel nœud libre dans le centre de données – mais uniquement dans le principal. Dans le secours, tous les nœuds sont secondaires.
Pour que Commvault sache quel nœud du cluster est primaire, nous avons intégré le système (merci à l'architecture ouverte de la solution) avec Postgres. Pour cela, un script a été créé pour informer le gestionnaire de l'emplacement actuel du nœud primaire. serveur Commvault.
Globalement, le processus ressemble à ceci :
Patroni choisit le primaire → Keepalived active l'IP du cluster et lance le script → l'agent Commvault sur le nœud du cluster sélectionné reçoit une notification que c'est le primaire → Commvault reconfigure automatiquement la sauvegarde au sein du pseudo-client.
L'avantage de cette approche est que la solution n'affecte ni la cohérence, ni l'exactitude des journaux, ni la restauration de l'instance Postgres. Elle est également facilement extensible, car il n'est plus nécessaire de fixer les nœuds primaire et secondaire pour Commvault. Il suffit que le système sache où se trouve le primaire, et le nombre de nœuds peut donc être augmenté pratiquement à n'importe quelle valeur.
La solution ne prétend pas être parfaite et a ses nuances. Commvault peut sauvegarder uniquement l'instance entière, et non des bases distinctes. Par conséquent, chaque base de données a son propre instance. Les clients réels sont regroupés en pseudo-clients virtuels. Chaque pseudo-client Commvault représente un cluster UNIX. Il inclut les nœuds du cluster sur lesquels l'agent Commvault pour Postgres est installé. En conséquence, tous les nœuds virtuels du pseudo-client sont sauvegardés comme une seule instance.
À l'intérieur de chaque pseudo-client, il y a un nœud actif du cluster. C'est ce nœud que notre solution d'intégration pour Commvault détermine. Le principe de son fonctionnement est assez simple : lorsque l'IP du cluster est activée sur le nœud, le script configure le paramètre « nœud actif » dans le binaire de l'agent Commvault, c'est-à-dire que le script place « 1 » dans la partie mémoire appropriée. L'agent transmet ces données au CommServe, et Commvault effectue la sauvegarde à partir du nœud requis. En outre, le script vérifie la validité de la configuration, aidant à éviter les erreurs lors du démarrage de la sauvegarde.
Pendant ce temps, les grandes bases de données sont sauvegardées par blocs en plusieurs flux, répondant aux exigences RPO et à la fenêtre de sauvegarde. La charge sur le système est peu significative : les copies complètes se produisent pas si souvent, les autres jours seuls les journaux sont collectés, et ce pendant les périodes de faible charge.
D'ailleurs, nous avons appliqué des politiques distinctes pour la sauvegarde des journaux archivés de PostgreSQL - ils sont conservés selon d'autres règles, copiés selon un autre calendrier, et la dé-duplication n'est pas activée, car ces journaux contiennent des données uniques.
Pour assurer la cohérence de toute l'infrastructure informatique, des clients de fichiers Commvault distincts sont installés sur chacune des nœuds du cluster. Ils excluent les fichiers Postgres des sauvegardes et sont uniquement destinés à la sauvegarde du système d'exploitation et des applications. Une politique spécifique ainsi qu'une période de rétention sont également prévues pour ces données.
Actuellement, le SRK n'affecte pas les services de production, mais si la situation change, il sera possible d'activer un système de limitation de charge dans Commvault.
Ça marche ? Ça marche !
Ainsi, nous avons obtenu non seulement une sauvegarde fonctionnelle, mais aussi entièrement automatisée pour l'installation en cluster de PostgreSQL, répondant à tous les défis d'entreprise.
Les paramètres RPO et RTO de 1 heure et 2 heures sont largement couverts, ce qui signifie que le système répondra à ses exigences même avec une augmentation significative des volumes de données stockées. Contre de nombreux doutes, PostgreSQL et l'environnement d'entreprise se sont révélés parfaitement compatibles. Et maintenant, de notre expérience, nous savons que la sauvegarde pour de tels SGBD est possible dans une grande variété de configurations.
Bien sûr, sur ce chemin, nous avons dû user sept paires de bottes en fer, surmonter de nombreuses difficultés, trébucher sur quelques pièges et corriger un certain nombre d'erreurs. Mais maintenant, l'approche est éprouvée et peut être appliquée pour l'intégration d'Open Source à la place des SGBD propriétaires dans des conditions enterprise difficiles.
Avez-vous déjà essayé de travailler avec PostgreSQL dans un environnement entreprise ?
Auteurs :
Oleg Lavrenov, ingénieur en conception de systèmes de stockage de données chez «Infosystèmes Jet»
Dmitry Erykin, ingénieur en conception de complexes informatiques chez «Infosystèmes Jet»
Source : habr.com
