De nombreuses personnes connaissent le SGBD PostgreSQL et il a fait ses preuves dans les petites installations. Cependant, la tendance vers l'Open Source est devenue de plus en plus claire, même lorsqu'il s'agit des grandes entreprises et des exigences des entreprises. Dans cet article, nous vous expliquerons comment intégrer Postgres dans un environnement d'entreprise et partagerons notre expérience de création d'un système de sauvegarde (BSS) pour cette base de données en utilisant comme exemple le système de sauvegarde Commvault.
PostgreSQL a déjà fait ses preuves : le SGBD fonctionne très bien, il est utilisé par des entreprises numériques à la mode comme Alibaba et TripAdvisor, et l'absence de frais de licence en fait une alternative tentante à des monstres tels que MS SQL ou Oracle DB. Mais dès que nous commençons à penser à PostgreSQL dans le paysage de l'entreprise, nous nous heurtons immédiatement à des exigences strictes : « Qu'en est-il de la tolérance aux pannes de configuration ? résistance aux catastrophes ? où est le suivi complet ? Qu’en est-il des sauvegardes automatisées ? Qu’en est-il de l’utilisation de bibliothèques de bandes directement et sur un stockage secondaire ? »
D'une part, PostgreSQL ne dispose pas d'outils de sauvegarde intégrés, comme les SGBD « adultes » tels que RMAN dans Oracle DB ou SAP Database Backup. D'autre part, les fournisseurs de systèmes de sauvegarde d'entreprise (Veeam, Veritas, Commvault), bien qu'ils prennent en charge PostgreSQL, ne fonctionnent en fait qu'avec une certaine configuration (généralement autonome) et avec un ensemble de diverses restrictions.
Les systèmes de sauvegarde spécialement conçus pour PostgreSQL, tels que Barman, Wal-g, pg_probackup, sont extrêmement populaires dans les petites installations du SGBD PostgreSQL ou lorsque de lourdes sauvegardes d'autres éléments du paysage informatique ne sont pas nécessaires. Par exemple, en plus de PostgreSQL, l'infrastructure peut inclure des serveurs physiques et virtuels, OpenShift, Oracle, MariaDB, Cassandra, etc. Il est conseillé de sauvegarder tout cela avec un outil commun. Installer une solution distincte exclusivement pour PostgreSQL est une mauvaise idée : les données seront copiées quelque part sur le disque, puis elles devront être supprimées sur bande. Cette double sauvegarde augmente le temps de sauvegarde, mais aussi, plus important encore, le temps de récupération.
Dans une solution d'entreprise, la sauvegarde de l'installation s'effectue avec un certain nombre de nœuds dans un cluster dédié. Dans le même temps, par exemple, Commvault ne peut fonctionner qu'avec un cluster à deux nœuds, dans lequel les nœuds primaire et secondaire sont strictement attribués à certains nœuds. Et cela n'a de sens que d'effectuer une sauvegarde à partir du principal, car la sauvegarde à partir du secondaire a ses limites. En raison des particularités du SGBD, un dump n'est pas créé sur le Secondaire, et donc seule la possibilité d'une sauvegarde de fichier demeure.
Pour réduire le risque de temps d'arrêt, lors de la création d'un système tolérant aux pannes, une configuration de cluster « en direct » est créée et Primary peut migrer progressivement entre différents serveurs. Par exemple, le logiciel Patroni lance lui-même Primary sur un nœud de cluster sélectionné au hasard. L'IBS n'a aucun moyen de suivre cela dès le départ, et si la configuration change, les processus s'interrompent. Autrement dit, l'introduction d'un contrôle externe empêche l'ISR de fonctionner efficacement, car le serveur de contrôle ne comprend tout simplement pas où et à partir de quelles données doivent être copiées.
Un autre problème est la mise en œuvre de la sauvegarde dans Postgres. C'est possible via dump, et cela fonctionne sur de petites bases de données. Mais dans les grandes bases de données, le dump prend beaucoup de temps, nécessite beaucoup de ressources et peut entraîner la panne de l'instance de base de données.
La sauvegarde de fichiers corrige la situation, mais sur les bases de données volumineuses, elle est lente car elle fonctionne en mode monothread. De plus, les fournisseurs sont soumis à un certain nombre de restrictions supplémentaires. Soit vous ne pouvez pas utiliser simultanément les sauvegardes de fichiers et de vidages, soit la déduplication n'est pas prise en charge. Les problèmes sont nombreux et le plus souvent, il est plus facile de choisir un SGBD coûteux mais éprouvé au lieu de Postgres.
Il n'y a nulle part où se retirer ! Les développeurs moscovites sont derrière !
Cependant, récemment, notre équipe a été confrontée à un défi difficile : dans le projet de création d'AIS OSAGO 2.0, où nous avons créé l'infrastructure informatique, les développeurs ont choisi PostgreSQL pour le nouveau système.
Il est beaucoup plus facile pour les grands développeurs de logiciels d’utiliser des solutions open source « à la mode ». Facebook dispose de suffisamment de spécialistes pour prendre en charge le fonctionnement de ce SGBD. Et dans le cas du RSA, toutes les tâches du « deuxième jour » nous sont tombées sur les épaules. Nous devions assurer la tolérance aux pannes, assembler un cluster et, bien sûr, mettre en place une sauvegarde. La logique d’action était la suivante :
- Apprenez au SRK à effectuer des sauvegardes à partir du nœud principal du cluster. Pour ce faire, le SRK doit le trouver, ce qui signifie qu'une intégration avec l'une ou l'autre solution de gestion de cluster PostgreSQL est nécessaire. Dans le cas de RSA, le logiciel Patroni a été utilisé à cet effet.
- Décidez du type de sauvegarde en fonction du volume de données et des exigences de récupération. Par exemple, lorsque vous devez restaurer des pages de manière granulaire, utilisez un dump, et si les bases de données sont volumineuses et qu'une restauration granulaire n'est pas requise, travaillez au niveau du fichier.
- Attachez la possibilité de sauvegarde en bloc à la solution pour créer une copie de sauvegarde en mode multi-thread.
Dans le même temps, nous avions initialement pour objectif de créer un système efficace et simple, sans un ensemble monstrueux de composants supplémentaires. Moins il y a de béquilles, moins la charge de travail du personnel est faible et plus le risque d'échec du SCI est faible. Nous avons immédiatement exclu les approches utilisant Veeam et RMAN, car un ensemble de deux solutions laisse déjà entrevoir le manque de fiabilité du système.
Un peu de magie pour l'entreprise
Nous devions donc garantir une sauvegarde fiable pour 10 clusters de 3 nœuds chacun, avec la même infrastructure reflétée dans le centre de données de sauvegarde. Les centres de données en termes de PostgreSQL fonctionnent sur le principe actif-passif. La taille totale de la base de données était de 50 To. Tout système de contrôle au niveau de l’entreprise peut facilement y faire face. Mais la mise en garde est qu'au départ, Postgres n'a aucune idée d'une compatibilité totale et approfondie avec les systèmes de sauvegarde. Par conséquent, nous avons dû rechercher une solution offrant initialement une fonctionnalité maximale en conjonction avec PostgreSQL et affiner le système.
Nous avons organisé 3 « hackathons » internes - nous avons examiné plus de cinquante développements, les avons testés, apporté des modifications en lien avec nos hypothèses et les avons testés à nouveau. Après avoir examiné les options disponibles, nous avons choisi Commvault. Prêt à l'emploi, ce produit pourrait fonctionner avec l'installation de cluster PostgreSQL la plus simple, et son architecture ouverte a suscité des espoirs (qui étaient justifiés) d'un développement et d'une intégration réussis. Commvault peut également sauvegarder les journaux PostgreSQL. Par exemple, Veritas NetBackup en termes de PostgreSQL ne peut effectuer que des sauvegardes complètes.
En savoir plus sur l'architecture. Des serveurs de gestion Commvault ont été installés dans chacun des deux centres de données dans une configuration CommServ HA. Le système est en miroir, géré via une seule console et, du point de vue haute disponibilité, répond à toutes les exigences de l'entreprise.
Nous avons également lancé deux serveurs de médias physiques dans chaque centre de données, auxquels nous avons connecté des baies de disques et des bibliothèques de bandes dédiées spécifiquement aux sauvegardes via SAN via Fibre Channel. Les bases de données de déduplication étendues garantissaient la tolérance aux pannes des serveurs de médias et la connexion de chaque serveur à chaque CSV permettait un fonctionnement continu en cas de panne d'un composant. L'architecture du système permet de poursuivre la sauvegarde même en cas de panne de l'un des centres de données.
Patroni définit un nœud principal pour chaque cluster. Il peut s'agir de n'importe quel nœud libre du centre de données, mais seulement pour la plupart. Dans la sauvegarde, tous les nœuds sont secondaires.
Afin que Commvault comprenne quel nœud de cluster est principal, nous avons intégré le système (grâce à l'architecture ouverte de la solution) avec Postgres. À cette fin, un script a été créé pour signaler l'emplacement actuel du nœud principal au serveur de gestion Commvault.
En général, le processus ressemble à ceci :
Patroni sélectionne Principal → Keepalived récupère le cluster IP et exécute le script → l'agent Commvault sur le nœud de cluster sélectionné reçoit une notification indiquant qu'il s'agit du principal → Commvault reconfigure automatiquement la sauvegarde dans le pseudo-client.
L'avantage de cette approche est que la solution n'affecte pas la cohérence, l'exactitude des journaux ou la récupération de l'instance Postgres. Il est également facilement évolutif, car il n'est plus nécessaire de réparer les nœuds Commvault primaire et secondaire. Il suffit que le système comprenne où se trouve le primaire et que le nombre de nœuds puisse être augmenté jusqu'à presque n'importe quelle valeur.
La solution ne prétend pas être idéale et comporte ses propres nuances. Commvault ne peut sauvegarder que l'intégralité de l'instance, et non des bases de données individuelles. Par conséquent, une instance distincte a été créée pour chaque base de données. Les clients réels sont regroupés en pseudo-clients virtuels. Chaque pseudo-client Commvault est un cluster UNIX. Les nœuds de cluster sur lesquels l'agent Commvault pour Postgres est installé y sont ajoutés. Par conséquent, tous les nœuds virtuels du pseudo-client sont sauvegardés comme une seule instance.
Au sein de chaque pseudo-client, le nœud actif du cluster est indiqué. C'est ce que définit notre solution d'intégration pour Commvault. Le principe de son fonctionnement est assez simple : si une IP de cluster est levée sur un nœud, le script définit le paramètre « nœud actif » dans le binaire de l'agent Commvault - en fait, le script définit « 1 » dans la partie requise de la mémoire. . L'agent transmet ces données à CommServe et Commvault effectue une sauvegarde à partir du nœud souhaité. De plus, l'exactitude de la configuration est vérifiée au niveau du script, ce qui permet d'éviter les erreurs lors du démarrage d'une sauvegarde.
Dans le même temps, les bases de données volumineuses sont sauvegardées par blocs sur plusieurs threads, répondant ainsi aux exigences en matière de RPO et de fenêtre de sauvegarde. La charge sur le système est insignifiante : les copies complètes ne se produisent pas si souvent, les autres jours, seuls les journaux sont collectés et pendant les périodes de faible charge.
À propos, nous avons appliqué des politiques distinctes pour sauvegarder les journaux d'archives PostgreSQL - ils sont stockés selon des règles différentes, copiés selon un calendrier différent, et la déduplication n'est pas activée pour eux, car ces journaux contiennent des données uniques.
Pour garantir la cohérence dans l'ensemble de l'infrastructure informatique, des clients de fichiers Commvault distincts sont installés sur chacun des nœuds du cluster. Ils excluent les fichiers Postgres des sauvegardes et sont destinés uniquement aux sauvegardes du système d'exploitation et des applications. Cette partie des données a également sa propre politique et sa propre période de stockage.
Actuellement, IBS n'affecte pas les services de productivité, mais si la situation change, Commvault peut activer la limitation de charge.
Est-ce bien? Bien!
Ainsi, nous avons reçu non seulement une sauvegarde fonctionnelle, mais également entièrement automatisée pour l'installation d'un cluster PostgreSQL, et elle répond à toutes les exigences pour les appels d'entreprise.
Les paramètres RPO et RTO de 1 heure et 2 heures sont couverts par une marge, ce qui signifie que le système les respectera même en cas d'augmentation significative du volume de données stockées. Contrairement à de nombreux doutes, PostgreSQL et l'environnement d'entreprise se sont avérés tout à fait compatibles. Et maintenant, nous savons par notre propre expérience que la sauvegarde de tels SGBD est possible dans une grande variété de configurations.
Bien sûr, tout au long de ce chemin, nous avons dû user sept paires de bottes de fer, surmonter un certain nombre de difficultés, marcher sur plusieurs râteaux et corriger un certain nombre d'erreurs. Mais maintenant, l'approche a déjà été testée et peut être utilisée pour mettre en œuvre l'Open Source au lieu d'un SGBD propriétaire dans des conditions d'entreprise difficiles.
Avez-vous essayé de travailler avec PostgreSQL dans un environnement d'entreprise ?
Auteurs:
Oleg Lavrenov, ingénieur concepteur de systèmes de stockage de données, Jet Infosystems
Dmitry Erykin, ingénieur de conception de systèmes informatiques chez Jet Infosystems
Source: habr.com