Viele Menschen kennen das PostgreSQL-DBMS und es hat sich in kleinen Installationen bewährt. Allerdings ist der Trend zu Open Source auch bei großen Unternehmen und Enterprise-Anforderungen immer deutlicher zu erkennen. In diesem Artikel erklären wir Ihnen, wie Sie Postgres in eine Unternehmensumgebung integrieren und teilen unsere Erfahrungen mit der Erstellung eines Backup-Systems (BSS) für diese Datenbank am Beispiel des Commvault-Backup-Systems.
PostgreSQL hat seinen Wert bereits unter Beweis gestellt – das DBMS funktioniert großartig, es wird von angesagten digitalen Unternehmen wie Alibaba und TripAdvisor verwendet und das Fehlen von Lizenzgebühren macht es zu einer verlockenden Alternative zu solchen Monstern wie MS SQL oder Oracle DB. Aber sobald wir anfangen, über PostgreSQL in der Unternehmenslandschaft nachzudenken, stoßen wir sofort auf strenge Anforderungen: „Wie steht es mit der Konfigurationsfehlertoleranz?“ Katastrophenschutz? Wo ist die umfassende Überwachung? Was ist mit automatisierten Backups? Wie wäre es mit der Verwendung von Bandbibliotheken sowohl direkt als auch auf Sekundärspeicher?“
Einerseits verfügt PostgreSQL nicht über integrierte Backup-Tools wie „erwachsene“ DBMS wie RMAN in Oracle DB oder SAP Database Backup. Auf der anderen Seite unterstützen Anbieter von Unternehmens-Backup-Systemen (Veeam, Veritas, Commvault) zwar PostgreSQL, arbeiten jedoch nur mit einer bestimmten (normalerweise eigenständigen) Konfiguration und mit einer Reihe verschiedener Einschränkungen.
Speziell für PostgreSQL entwickelte Backup-Systeme wie Barman, Wal-g, pg_probackup erfreuen sich großer Beliebtheit bei kleinen Installationen des PostgreSQL-DBMS oder dort, wo umfangreiche Backups anderer Elemente der IT-Landschaft nicht erforderlich sind. Beispielsweise kann die Infrastruktur neben PostgreSQL auch physische und virtuelle Server, OpenShift, Oracle, MariaDB, Cassandra usw. umfassen. Es empfiehlt sich, dies alles mit einem gängigen Tool zu sichern. Die Installation einer separaten Lösung ausschließlich für PostgreSQL ist eine schlechte Idee: Die Daten werden irgendwo auf die Festplatte kopiert und müssen dann auf Band entfernt werden. Dieses doppelte Backup erhöht die Backup-Zeit und, was noch wichtiger ist, auch die Wiederherstellungszeit.
Bei einer Unternehmenslösung erfolgt die Sicherung der Installation mit einer bestimmten Anzahl von Knoten in einem dedizierten Cluster. Gleichzeitig kann Commvault beispielsweise nur mit einem Zwei-Knoten-Cluster arbeiten, bei dem Primary und Secondary strikt bestimmten Knoten zugeordnet sind. Und es ist nur sinnvoll, ein Backup von der Primärseite zu erstellen, da die Sicherung von der Sekundärseite ihre Grenzen hat. Aufgrund der Besonderheiten des DBMS wird kein Dump auf dem Secondary erstellt und somit bleibt nur die Möglichkeit einer Dateisicherung.
Um das Risiko von Ausfallzeiten zu verringern, wird beim Erstellen eines fehlertoleranten Systems eine „Live“-Clusterkonfiguration erstellt, und Primary kann schrittweise zwischen verschiedenen Servern migrieren. Beispielsweise startet die Patroni-Software selbst Primary auf einem zufällig ausgewählten Clusterknoten. Das IBS hat keine Möglichkeit, dies sofort zu verfolgen, und wenn sich die Konfiguration ändert, brechen die Prozesse ab. Das heißt, die Einführung einer externen Kontrolle verhindert, dass der ISR effektiv funktioniert, da der Kontrollserver einfach nicht versteht, woher und welche Daten kopiert werden müssen.
Ein weiteres Problem ist die Implementierung von Backups in Postgres. Dies ist durch Dump möglich und funktioniert bei kleinen Datenbanken. Doch bei großen Datenbanken dauert der Dump lange, beansprucht viele Ressourcen und kann zum Ausfall der Datenbankinstanz führen.
Die Dateisicherung behebt die Situation, ist jedoch bei großen Datenbanken langsam, da sie im Single-Thread-Modus arbeitet. Darüber hinaus gelten für Anbieter eine Reihe zusätzlicher Einschränkungen. Entweder können Sie Datei- und Dump-Backups nicht gleichzeitig verwenden, oder die Deduplizierung wird nicht unterstützt. Es gibt viele Probleme und meistens ist es einfacher, ein teures, aber bewährtes DBMS anstelle von Postgres zu wählen.
Es gibt keinen Rückzugsort! Moskauer Entwickler sind im Rückstand!
Doch vor kurzem stand unser Team vor einer schwierigen Herausforderung: Im Projekt zur Erstellung von AIS OSAGO 2.0, bei dem wir die IT-Infrastruktur erstellten, entschieden sich die Entwickler für PostgreSQL als neues System.
Für große Softwareentwickler ist es viel einfacher, „trendige“ Open-Source-Lösungen zu nutzen. Facebook verfügt über genügend Spezialisten, um den Betrieb dieses DBMS zu unterstützen. Und im Fall von RSA lagen alle Aufgaben des „zweiten Tages“ auf unseren Schultern. Wir mussten die Fehlertoleranz sicherstellen, einen Cluster zusammenstellen und natürlich ein Backup einrichten. Die Handlungslogik war wie folgt:
- Bringen Sie dem SRK bei, Sicherungen vom Primärknoten des Clusters zu erstellen. Dazu muss das SRK es finden – was bedeutet, dass eine Integration mit der einen oder anderen PostgreSQL-Cluster-Management-Lösung erforderlich ist. Im Fall von RSA kam hierfür die Patroni-Software zum Einsatz.
- Entscheiden Sie sich für die Art der Sicherung basierend auf dem Datenvolumen und den Wiederherstellungsanforderungen. Wenn Sie beispielsweise Seiten granular wiederherstellen müssen, verwenden Sie einen Dump. Wenn die Datenbanken groß sind und keine granulare Wiederherstellung erforderlich ist, arbeiten Sie auf Dateiebene.
- Fügen Sie der Lösung die Möglichkeit der Blocksicherung hinzu, um eine Sicherungskopie im Multithread-Modus zu erstellen.
Gleichzeitig haben wir uns zunächst zum Ziel gesetzt, ein effektives und einfaches System ohne einen monströsen Kabelbaum an zusätzlichen Komponenten zu schaffen. Je weniger Krücken, desto weniger Arbeitsbelastung für das Personal und desto geringer das Risiko eines Reizdarmsyndroms. Ansätze, die Veeam und RMAN nutzten, haben wir sofort ausgeschlossen, da ein Set aus zwei Lösungen bereits auf die Unzuverlässigkeit des Systems schließen lässt.
Ein bisschen Magie für Unternehmen
Daher mussten wir ein zuverlässiges Backup für 10 Cluster mit jeweils 3 Knoten gewährleisten, wobei die gleiche Infrastruktur im Backup-Rechenzentrum gespiegelt werden sollte. Rechenzentren im Sinne von PostgreSQL arbeiten nach dem Aktiv-Passiv-Prinzip. Die Gesamtgröße der Datenbank betrug 50 TB. Jedes Kontrollsystem auf Unternehmensebene kann dies problemlos bewältigen. Der Vorbehalt besteht jedoch darin, dass Postgres zunächst keine Ahnung von vollständiger und umfassender Kompatibilität mit Backup-Systemen hat. Daher mussten wir nach einer Lösung suchen, die zunächst eine maximale Funktionalität in Verbindung mit PostgreSQL bietet, und das System verfeinern.
Wir haben 3 interne „Hackathons“ abgehalten – wir haben uns mehr als fünfzig Entwicklungen angesehen, sie getestet, Änderungen im Zusammenhang mit unseren Hypothesen vorgenommen und sie erneut getestet. Nachdem wir die verfügbaren Optionen geprüft hatten, entschieden wir uns für Commvault. Dieses Produkt konnte sofort mit der einfachsten PostgreSQL-Cluster-Installation funktionieren und seine offene Architektur weckte berechtigte Hoffnungen auf eine erfolgreiche Entwicklung und Integration. Commvault kann auch PostgreSQL-Protokolle sichern. Beispielsweise kann Veritas NetBackup im Hinblick auf PostgreSQL nur vollständige Sicherungen durchführen.
Mehr über Architektur. In jedem der beiden Rechenzentren wurden Commvault-Verwaltungsserver in einer CommServ HA-Konfiguration installiert. Das System ist gespiegelt, wird über eine Konsole verwaltet und erfüllt aus HA-Sicht alle Unternehmensanforderungen.
Außerdem haben wir in jedem Rechenzentrum zwei physische Medienserver eingeführt, an die wir Festplatten-Arrays und Bandbibliotheken speziell für Backups über SAN über Fibre Channel angeschlossen haben. Erweiterte Deduplizierungsdatenbanken stellten die Fehlertoleranz der Medienserver sicher und die Verbindung jedes Servers mit jedem CSV ermöglichte einen kontinuierlichen Betrieb, wenn eine Komponente ausfiel. Die Systemarchitektur ermöglicht es, die Sicherung auch dann fortzusetzen, wenn eines der Rechenzentren ausfällt.
Patroni definiert einen Primärknoten für jeden Cluster. Es kann jeder freie Knoten im Rechenzentrum sein – aber nur größtenteils. Im Backup sind alle Knoten sekundär.
Damit Commvault erkennt, welcher Clusterknoten primär ist, haben wir das System (dank der offenen Architektur der Lösung) in Postgres integriert. Zu diesem Zweck wurde ein Skript erstellt, das den aktuellen Standort des Primärknotens an den Commvault-Managementserver meldet.
Im Allgemeinen sieht der Prozess so aus:
Patroni wählt Primär → Keepalived holt den IP-Cluster ab und führt das Skript aus → der Commvault-Agent auf dem ausgewählten Clusterknoten erhält eine Benachrichtigung, dass dies der Primärknoten ist → Commvault konfiguriert die Sicherung innerhalb des Pseudo-Clients automatisch neu.
Der Vorteil dieses Ansatzes besteht darin, dass die Lösung keinen Einfluss auf die Konsistenz, Richtigkeit der Protokolle oder die Wiederherstellung der Postgres-Instanz hat. Es ist außerdem leicht skalierbar, da es nicht mehr erforderlich ist, die Commvault-Primär- und -Sekundärknoten zu reparieren. Es reicht aus, dass das System versteht, wo sich Primary befindet, und die Anzahl der Knoten kann auf nahezu jeden Wert erhöht werden.
Die Lösung erhebt keinen Anspruch auf Idealität und hat ihre eigenen Nuancen. Commvault kann nur die gesamte Instanz sichern, nicht einzelne Datenbanken. Daher wurde für jede Datenbank eine eigene Instanz erstellt. Reale Clients werden zu virtuellen Pseudo-Clients zusammengefasst. Jeder Commvault-Pseudo-Client ist ein UNIX-Cluster. Es werden diejenigen Clusterknoten hinzugefügt, auf denen der Commvault-Agent für Postgres installiert ist. Dadurch werden alle virtuellen Knoten des Pseudo-Clients als eine Instanz gesichert.
Innerhalb jedes Pseudo-Clients wird der aktive Knoten des Clusters angegeben. Das definiert unsere Integrationslösung für Commvault. Das Funktionsprinzip ist recht einfach: Wenn eine Cluster-IP auf einem Knoten ausgelöst wird, setzt das Skript den Parameter „aktiver Knoten“ in der Binärdatei des Commvault-Agenten – tatsächlich setzt das Skript „1“ im erforderlichen Teil des Speichers . Der Agent übermittelt diese Daten an CommServe und Commvault erstellt ein Backup vom gewünschten Knoten. Darüber hinaus wird die Korrektheit der Konfiguration auf Skriptebene überprüft und hilft so, Fehler beim Starten eines Backups zu vermeiden.
Gleichzeitig werden große Datenbanken blockweise über mehrere Threads hinweg gesichert und erfüllen so die Anforderungen an RPO und Sicherungsfenster. Die Belastung des Systems ist unbedeutend: Vollständige Kopien finden seltener statt, an anderen Tagen und in Zeiten geringer Auslastung werden nur Protokolle gesammelt.
Übrigens haben wir separate Richtlinien für die Sicherung von PostgreSQL-Archivprotokollen angewendet – sie werden nach unterschiedlichen Regeln gespeichert, nach einem anderen Zeitplan kopiert und die Deduplizierung ist für sie nicht aktiviert, da diese Protokolle eindeutige Daten enthalten.
Um die Konsistenz in der gesamten IT-Infrastruktur sicherzustellen, werden auf jedem der Clusterknoten separate Commvault-Dateiclients installiert. Sie schließen Postgres-Dateien von Backups aus und sind nur für Betriebssystem- und Anwendungs-Backups gedacht. Auch für diesen Teil der Daten gelten eigene Richtlinien und Speicherfristen.
Derzeit hat IBS keinen Einfluss auf Produktivitätsdienste, aber wenn sich die Situation ändert, kann Commvault die Lastbegrenzung aktivieren.
Ist es gut? Gut!
Wir haben also nicht nur ein funktionsfähiges, sondern auch ein vollautomatisiertes Backup für eine PostgreSQL-Cluster-Installation erhalten, das alle Anforderungen für Enterprise-Aufrufe erfüllt.
Die RPO- und RTO-Parameter von 1 Stunde und 2 Stunden sind mit einer Marge abgedeckt, was bedeutet, dass das System diese auch bei einem deutlichen Anstieg der gespeicherten Datenmenge einhält. Entgegen vieler Zweifel erwiesen sich PostgreSQL und die Unternehmensumgebung als durchaus kompatibel. Und jetzt wissen wir aus eigener Erfahrung, dass Backups für solche DBMS in den unterschiedlichsten Konfigurationen möglich sind.
Natürlich mussten wir auf diesem Weg sieben Paar Eisenstiefel abnutzen, eine Reihe von Schwierigkeiten überwinden, auf mehrere Rechen treten und eine Reihe von Fehlern korrigieren. Nun wurde der Ansatz jedoch bereits getestet und kann zur Implementierung von Open Source anstelle eines proprietären DBMS unter rauen Unternehmensbedingungen verwendet werden.
Haben Sie versucht, mit PostgreSQL in einer Unternehmensumgebung zu arbeiten?
Autoren:
Oleg Lavrenov, Konstrukteur von Datenspeichersystemen, Jet Infosystems
Dmitry Erykin, Designingenieur für Computersysteme bei Jet Infosystems
Source: habr.com