Ende letzten Jahres fand eine weitere Live-Übertragung der russischen PostgreSQL-Community statt , in deren Rahmen Mitbegründer Nikolai Samokhvalov mit dem technischen Direktor von „Flant“ Dmitry Stolyarov über diese DBMS im Kontext von Kubernetes sprach.
Wir veröffentlichen das Transkript des Hauptteils dieser Diskussion, und auf wurde die vollständige Videoaufzeichnung veröffentlicht:
Datenbanken und Kubernetes
NS: Wir werden heute nicht über VACUUM und CHECKPOINTs sprechen. Wir wollen über Kubernetes reden. Ich weiß, dass du bereits viele Jahre Erfahrung hast. Ich habe deine Videos gesehen und einige sogar in Teilen noch einmal angeschaut… Lass uns gleich zur Sache kommen: Warum Postgres oder MySQL in K8s?
DS: Es gibt keine eindeutige Antwort auf diese Frage und kann sie auch nicht geben. Aber grundsätzlich liegt es an der Einfachheit und Bequemlichkeit… das Potenzial. Jeder möchte schließlich Managed-Services.
NS: Damit wie , nur bei sich selbst?
DS: Ja, damit wie RDS, nur überall.
NS: „Überall“ ist ein guter Hinweis. In großen Unternehmen ist alles an verschiedenen Orten angesiedelt. Warum sollte man in einem großen Unternehmen nicht auf eine fertig ausgearbeitete Lösung zurückgreifen? Zum Beispiel hat Nutanix eigene Entwicklungen, und andere Unternehmen (wie VMware…) bieten dasselbe „RDS, nur bei sich selbst“ an.
DS: Aber das ist nur eine spezifische Implementierung, die nur unter bestimmten Bedingungen funktioniert. Wenn es um Kubernetes geht, gibt es eine enorme Vielfalt an Infrastruktur, die in K8s vorhanden sein kann. Im Grunde genommen ist dies der Standard für die API zu Cloud-Diensten…
NS: Und das sogar kostenlos!
DS: Das ist nicht so entscheidend. Die Kostenfreiheit ist für einen nicht allzu großen Marktsektor wichtig. Es geht um etwas anderes… Du erinnerst dich sicher an den Bericht „»?
NS: Ja.
DS: Ich habe verstanden, dass die Reaktionen sehr gemischt waren. Einige dachten, ich sage: „Leute, lasst uns alle Datenbanken in Kubernetes bringen!“, während andere dachten, das Ganze sei furchtbarer Unsinn. Dabei wollte ich etwas ganz anderes sagen: „Schaut euch an, was passiert, welche Probleme es gibt und wie man sie lösen kann. Jetzt mit Datenbanken in Kubernetes? In der Produktion? Nun, nur wenn ihr… bestimmte Dinge liebt. Aber für die Entwicklung kann ich sagen, dass ich es empfehle. Für die Entwicklung ist die Dynamik der Erstellung/Löschung von Umgebungen sehr wichtig.
NS: Mit Entwicklung meinst du also alle Umgebungen, die nicht in der Produktion sind? Staging, QA…
DS: Wenn wir von Performance-Ständen sprechen, dann wahrscheinlich nicht, denn die Anforderungen sind dort spezifisch. Wenn wir von speziellen Fällen sprechen, in denen im Staging eine sehr große Datenbank benötigt wird, dann auch wahrscheinlich nicht… Wenn es sich um eine statische, langlebige Umgebung handelt, was bringt es dann, wenn die Datenbank in K8s liegt?
NS: Gar nichts. Aber wo sehen wir statische Umgebungen? Eine statische Umgebung ist schon morgen veraltet.
DS: Staging kann statisch sein. Wir haben Kunden…
NS: Ja, ich habe auch welche. Es ist ein großes Problem, wenn du eine Datenbank mit 10 TB hast, aber Staging nur 200 GB…
DS: Ich habe einen sehr interessanten Fall! In der Staging-Umgebung befindet sich die Produktionsdatenbank, in die Änderungen eingepflegt werden. Es gibt einen Button: „In Produktion bringen“. Diese Änderungen – die Deltas – werden (scheinbar einfach über die API synchronisiert) in die Produktion übertragen. Dies ist eine sehr exotische Variante.
NS: Ich habe Startups im Silicon Valley gesehen, die noch auf RDS oder sogar Heroku arbeiten – das sind Geschichten aus 2-3 Jahren zurück – und sie ziehen sich ein Dump auf ihren Laptop. Denn die Datenbank hat bisher nur 80 GB, und auf dem Laptop ist Platz. Dann kaufen sie Festplatten für jeden, um mehrere Datenbanken zu haben, um verschiedene Entwicklungen durchzuführen. So etwas gibt es auch. Ich habe auch gesehen, dass man keine Angst hat, Produktion in Staging zu kopieren – das hängt sehr stark vom Unternehmen ab. Aber ich habe auch gesehen, dass viele Angst haben und oft die Zeit und die Ressourcen fehlen. Aber bevor wir zu diesem Thema kommen, würde ich gerne mehr über Kubernetes hören. Verstehe ich richtig, dass es in der Produktion aktuell noch niemand hat?
DS: Wir haben einige kleinere Datenbanken in der Produktionsumgebung. Dabei handelt es sich um Volumen im Bereich von mehreren Dutzend Gigabyte und nicht-kritische Services, für die es keine Notwendigkeit gab, Replikate zu erstellen. Und vorausgesetzt, dass unter Kubernetes ein ordentliches Speicherangebot vorhanden ist. Diese Datenbank lief in einer virtuellen Maschine — hypothetisch in VMware, über SAN. Wir haben sie in verschoben und können sie jetzt von Maschine zu Maschine transferieren.
NS: Datenbanken dieser Größe, bis zu 100 GB, auf guten Festplatten und bei einer stabilen Netzwerkanbindung können innerhalb weniger Minuten bereitgestellt werden, oder? Eine Geschwindigkeit von 1 GB pro Sekunde ist mittlerweile nichts Außergewöhnliches.
DS: Ja, für lineare Operationen ist das kein Problem.
NS: Okay, wir müssen nur über die Produktionsumgebung nachdenken. Und wie sieht es aus, wenn wir Kubernetes für Nicht-Produktionsumgebungen in Betracht ziehen — wie gehe ich vor? Ich sehe, dass bei Zalando entwickelt wird, bei Crunchy OnGres einen Operator StackGres: Envoy wofür? Für das Load Balancing von PostgreSQL-Traffic?
DS: Wofür ist Envoy? Für die Lastverteilung von PostgreSQL-Traffic?
NS: Ja. Sie sehen es also so: Wenn man ein Linux-Distribution und den Kernel nimmt, dann ist PostgreSQL im Grunde der Kernel, und sie wollen eine Distribution erstellen, die cloudfreundlich ist und in Kubernetes läuft. Sie verbinden Komponenten (Backups usw.) und optimieren sie, damit sie gut funktionieren.
DS: Sehr cool! Im Grunde handelt es sich um eine Software, um ein verwaltetes Postgres zu erstellen.
NS: Linux-Distributionen haben immer Probleme: Wie man Treiber erstellt, damit die gesamte Hardware unterstützt wird. Ihre Idee ist, dass sie in Kubernetes arbeiten werden. Ich weiß, dass wir bei dem Betreiber Zalando kürzlich eine Bindung an AWS gesehen haben, und das ist schon nicht so gut. Es sollte keine Bindung an eine spezifische Infrastruktur geben – wo wäre dann der Sinn?
DS: Ich weiß nicht, in welcher spezifischen Situation Zalando sich festgelegt hat, aber derzeit ist der Storage in Kubernetes so gestaltet, dass man keine generische Methode verwenden kann, um ein Disk-Backup zu erstellen. Kürzlich wurde in den Standards – in der letzten Version – die Möglichkeit von Snapshots eingeführt, aber wo wurde das umgesetzt? Ehrlich gesagt, es ist immer noch so unausgereift… Wir testen CSI auf AWS, GCE, Azure, vSphere, aber wenn man es etwas verwendet, sieht man, dass es noch nicht bereit ist.
NS: Daher müssen wir uns manchmal mit der Infrastruktur beschäftigen. Ich denke, wir befinden uns noch in einer frühen Phase — den Wachstumsproblemen. Frage: Was würdest du Anfängern raten, die PgSQL in K8s ausprobieren möchten? Welchen Operator könntest du empfehlen?
DS: Das Problem ist, dass Postgres für uns nur 3 % ausmacht. Wir haben noch eine lange Liste von verschiedenen Softwarelösungen in Kubernetes, ich möchte gar nicht alles aufzählen. Zum Beispiel Elasticsearch. Es gibt viele Operatoren: Einige entwickeln sich aktiv weiter, andere tun es nicht. Wir haben für uns Anforderungen festgelegt, die ein Operator erfüllen muss, damit wir ihn ernst nehmen. Dabei geht es um Operatoren für Kubernetes — nicht um „Operatoren, die für Amazon oder Ähnliches gedacht sind“... Faktisch verwenden wir sehr häufig (= bei fast allen Kunden) nur einen Operator — (bald veröffentlichen wir auch einen Artikel über ihn).
NS: Gibt es für MySQL keinen? Ich weiß, dass Percona... da sie jetzt sowohl MySQL als auch MongoDB und Postgres unterstützen, müssen sie wahrscheinlich eine universelle Lösung entwickeln: für alle Datenbanken und alle Cloud-Anbieter.
DS: Wir haben die Operatoren für MySQL noch nicht betrachtet. Das ist für uns derzeit nicht der Hauptfokus. MySQL funktioniert gut im Standalone-Modus. Warum einen Operator, wenn man einfach die Datenbank starten kann… Man kann einen Docker-Container mit Postgres starten, oder es ganz einfach halten.
NS: Dazu gab es auch eine Frage. Ganz ohne Operator?
DS: Ja, zu 100% läuft bei uns PostgreSQL ohne Operator. Im Moment ist es so. Wir nutzen aktiv einen Operator für Prometheus und für Redis. Wir haben Pläne, einen Operator für Elasticsearch zu finden – das ist am dringendsten, weil wir ihn in 100% der Fälle in Kubernetes setzen möchten. Genauso wie wir auch wollen, dass MongoDB immer in Kubernetes läuft. Es gibt bestimmte Wünsche – das Gefühl, dass wir in diesen Fällen etwas tun können. Aber bei Postgres haben wir uns noch nicht umgesehen. Natürlich wissen wir von den verschiedenen Optionen, aber in der Praxis nutzen wir Standalone.
Datenbank für Tests in Kubernetes
NS: Lasst uns zum Thema Testen übergehen. Wie man Änderungen in der Datenbank ausrollt – aus der Perspektive von DevOps. Es gibt Mikrodienste, viele Datenbanken, und ständig ändert sich etwas. Wie stellt man sicher, dass CI/CD gut funktioniert, damit alles aus der Sicht der DBMS in Ordnung ist? Was ist dein Ansatz?
DS: Es gibt nicht die eine Antwort. Es gibt mehrere Parameter. Der erste ist die Größe der Datenbank, die wir ausrollen wollen. Du hast selbst erwähnt, dass Unternehmen unterschiedlich mit der Bereitstellung einer Kopie der Prod-Datenbank auf Dev und Staging umgehen.
NS: Im Hinblick auf die GDPR denke ich, dass sie immer vorsichtiger werden... Ich kann sagen, dass in Europa bereits mit Bußgeldern begonnen wurde.
DS: Oft kann man Software schreiben, die ein Dump von der Produktion erstellt und diesen obfuskiert. Es entstehen Prod-Daten (Snapshot, Dump, binäre Kopie...), aber sie sind anonymisiert. Alternativ könnte es auch Skripte zur Generierung geben: das könnten Fixtures oder einfach nur ein Skript sein, das eine große Datenbank generiert. Das Problem ist: Wie viel Zeit benötigt das Erstellen des Basis-Images? Und wie viel Zeit braucht es, um es in der entsprechenden Umgebung bereitzustellen?
Wir haben uns für folgendes Schema entschieden: Wenn der Kunde einen Fixture-Datensatz hat (eine minimale Version der Datenbank), verwenden wir diesen standardmäßig. Wenn es um Review-Umgebungen geht, bei denen wir einen Branch erstellt haben und eine Instanz der Anwendung hochgefahren wird – dann setzen wir eine kleine Datenbank ein. Aber auch die , wenn wir einmal täglich (nachts) ein Backup von der Production-Umgebung machen und basierend darauf einen Docker-Container mit PostgreSQL und MySQL mit diesen geladenen Daten erstellen. Wenn wir diese Datenbank aus diesem Image 50 Mal bereitstellen müssen, erfolgt das ziemlich einfach und schnell.
NS: Einfach durch Kopieren?
DS: Die Daten werden direkt im Docker-Image gespeichert. Das heißt, wir haben ein fertiges Image, sagen wir 100 GB groß. Dank der Schichten in Docker können wir dieses Image schnell die gewünschte Anzahl von Male bereitstellen. Die Methode ist einfach, funktioniert aber gut.
NS: Und wenn du testest, wird es direkt in Docker geändert, oder? Copy-on-Write innerhalb von Docker — wir löschen und fangen neu an, alles gut. Klasse! Nutzt ihr das schon intensiv?
DS: Schon lange.
NS: Wir beschäftigen uns mit sehr ähnlichen Dingen. Nur verwenden wir nicht das Docker Copy-on-Write, sondern eine andere Lösung.
DS: Es ist nicht generisch. Aber die Docker-Lösung funktioniert überall.
NS: Im Prinzip ja. Aber wir haben auch Module, mit denen verschiedene Module erstellt werden können, um mit verschiedenen Dateisystemen zu arbeiten. Hier ist der Punkt. Wir schauen von PostgreSQL anders darauf. Jetzt habe ich aus der Perspektive von Docker geschaut und gesehen, dass alles bei Ihnen funktioniert. Aber wenn die Datenbank riesig ist, zum Beispiel 1 TB, dann dauert alles viel länger: sowohl die Vorgänge nachts als auch das Einfügen in Docker... Und wenn wir 5 TB in Docker einfügen müssen... Ist das problemlos?
DS: Was macht das für einen Unterschied: das sind doch Blobs, einfach Bits und Bytes.
NS: Der Unterschied ist: Machen Sie das über Dump und Restore?
DS: Das ist überhaupt nicht notwendig. Die Methoden zur Erstellung dieses Images können unterschiedlich sein.
NS: Für einige Kunden haben wir das so gelöst, dass wir anstelle der regelmäßigen Erstellung eines Basisimages dieses ständig auf dem neuesten Stand halten. Im Grunde genommen ist es eine Replik, aber die Daten kommen nicht direkt vom Master, sondern über ein Archiv. Ein binäres Archiv, in das die WALs jeden Tag eingespielt werden, dort werden auch Backups gemacht... Diese WALs gelangen dann mit einer kleinen Verzögerung (nur 1-2 Sekunden) zum Basisimage. Von dort aus klonen wir auf jede erdenkliche Weise — standardmäßig verwenden wir ZFS.
DS: Aber mit ZFS sind Sie auf einen Knoten beschränkt.
NS: Ja. Aber ZFS hat auch einen magischen : damit kann man einen Snapshot senden und sogar (das habe ich noch nicht so richtig getestet, aber…) kann man das Delta zwischen zwei PGDATA. Tatsächlich haben wir noch ein weiteres Werkzeug, das wir für solche Aufgaben nicht wirklich in Betracht gezogen haben. In PostgreSQL gibt es , das wie ein „intelligentes“ rsync funktioniert und vieles überspringt, was man nicht beachten muss, weil sich dort sicher nichts geändert hat. Wir können zwischen zwei Servern eine schnelle Synchronisation durchführen und genauso zurückspulen.
Wir versuchen also, von dieser, eher DBA-orientierten Seite ein Tool zu entwickeln, das das ermöglicht, wovon du gesprochen hast: Wir haben eine Datenbank, aber wir wollen etwas 50 Mal testen, fast gleichzeitig.
DS: 50 Mal bedeutet, dass Sie 50 Spot-Instanzen bestellen müssen.
NS: Nein, wir machen das alles auf einer Maschine.
DS: Aber wie möchten Sie 50 Mal bereitstellen, wenn diese eine Datenbank, sagen wir, ein Terabyte groß ist? Höchstwahrscheinlich benötigt sie bedingt 256 GB RAM?
NS: Ja, manchmal benötigt man viel Speicher – das ist normal. Aber so ein Beispiel aus dem Leben: Auf der Produktionsmaschine gibt es 96 Kerne und 600 GB. Dabei werden für die Datenbank 32 Kerne (sogar 16 Kerne manchmal) und 100-120 GB Speicher verwendet.
DS: Und da passen 50 Kopien rein?
NS: So, there is just one copy, then copy-on-write (ZFS) continues to operate… I'll elaborate on this.
For us, for example, the database is 10 TB. We created a disk for it, and ZFS compressed its size by about 30-40%. Since we don’t perform load testing, exact response time is not critical for us: it can be up to twice as slow — that’s fine.
We allow developers, QA, DBAs, etc., to conduct testing in 1-2 threads. For example, they can initiate a migration. It doesn’t require 10 cores right away — it just needs 1 backend of Postgres, 1 core. The migration will start — maybe, will also kick in, then the second core will become active. We have 16-32 cores allocated, so 10 people can work simultaneously without issues.
Since physically PGDATA it's the same, it turns out that we are actually tricking Postgres. The trick is: for example, 10 Postgres instances are started simultaneously. What’s the usual problem? They set , for instance, at 25%. Accordingly, that is 200 GB. You can’t start more than three of those, otherwise, memory will run out.
But at some point, we realized that this is unnecessary: we set shared_buffers to 2 GB. PostgreSQL has , and in reality, only it influences the Wir setzen ihn auf 0,5 TB. Und es spielt keine Rolle, dass es sie eigentlich nicht gibt: Er plant, als ob sie vorhanden wären.
Wenn wir also eine Migration testen, können wir alle Pläne sammeln – wir werden sehen, wie es in der Produktion ablaufen wird. Die Zeiten werden anders sein (langsamer), aber die Daten, die wir tatsächlich lesen, und die Pläne selbst (welche JOINs und so weiter) sind genau die gleichen wie in der Produktion. Gleichzeitig können wir viele solche Überprüfungen auf einer Maschine ausführen.
DS: Denkst du nicht, dass es hier mehrere Probleme gibt? Erstens – das ist eine Lösung, die nur mit PostgreSQL funktioniert. Dieser Ansatz ist sehr spezifisch, nicht generisch. Zweitens – Kubernetes (und alles, wohin die Cloud-Technologien jetzt gehen) setzt auf viele Knoten, und diese Knoten sind flüchtig. In deinem Fall handelt es sich jedoch um einen zustandsbehafteten, persistenten Knoten. Diese Dinge verursachen bei mir Widersprüche.
NS: Erstens – ich stimme zu, das ist rein eine Postgres-Geschichte. Ich denke, wenn wir irgendeine Art von Direct IO und einen Pufferpool haben, der fast den ganzen Speicher abdeckt, wird dieser Ansatz nicht geeignet sein – die Pläne werden anders sein. Aber momentan arbeiten wir nur mit Postgres und denken nicht an andere.
Über Kubernetes. Du erzählst überall, dass wir eine persistente Datenbank haben. Wenn eine Instanz ausfällt, ist das Wichtigste, die Festplatte zu sichern. Unsere gesamte Plattform basiert ebenfalls auf Kubernetes, und die Komponente mit Postgres ist separat (obwohl sie auch irgendwann dort sein wird). Daher ist es so: Die Instanz fällt aus, aber wir haben ihr PV gespeichert und einfach an eine andere (neue) Instanz angeschlossen, als wäre nichts passiert.
DS: Meiner Meinung nach erstellen wir Pods in Kubernetes. K8s ist elastisch: Die Knoten werden nach Bedarf automatisch angefordert. Die Aufgabe besteht einfach darin, einen Pod zu erstellen und anzugeben, dass er X Ressourcen benötigt, und dann kümmert sich K8s selbst darum. Aber die Unterstützung für Speicher in Kubernetes ist nach wie vor instabil: in , in (diese Version kam heraus Wochen her) werden diese Funktionen nur zur Beta.
In sechs Monaten bis einem Jahr wird es mehr oder weniger stabil sein, oder zumindest als solches deklariert werden. Dann löst die Möglichkeit von Snapshots und Resizes dein Problem vollständig. Denn du hast eine Datenbank. Ja, sie könnte nicht die schnellste sein, aber die Geschwindigkeit hängt davon ab, was "unter der Haube" ist, denn einige Implementierungen können Kopieren und Copy-on-Write auf der Ebene des Speichersystems.
NS: Es muss auch sichergestellt werden, dass alle Engines (Amazon, Google…) diese Version unterstützen – das benötigt schließlich auch seine Zeit.
DS: Solange verwenden wir sie nicht. Wir nutzen eigene Lösungen.
Lokale Entwicklung mit Kubernetes
NS: Hast du schon einmal das Bedürfnis verspürt, alle Pods auf einer Maschine hochzufahren, um eine kleine Testphase durchzuführen? Um schnell einen Proof of Concept zu erhalten und zu sehen, dass die Anwendung in Kubernetes funktioniert, ohne dafür eine Menge Maschinen zu nutzen. Gibt es nicht Minikube?
DS: Ich denke, dieser Anwendungsfall – alles auf einem Knoten bereitzustellen – bezieht sich ausschließlich auf lokale Entwicklung oder zeigt solche Muster. Es gibt , und es gibt , . Wir bewegen uns in Richtung Nutzung von Kubernetes IN Docker. Wir haben begonnen, damit für Tests zu arbeiten.
NS: Früher dachte ich, dass es darum geht, alle Pods in ein Docker-Image zu verpacken. Aber es stellt sich heraus, dass es um etwas ganz anderes geht. Es sind trotzdem separate Container, separate Pods – einfach in Docker.
DS: Ja. Und dort gibt es eine ziemlich amüsante Nachbildung, aber die Idee ist… Wir haben ein Tool für das Deployment – . Wir möchten darin einen Modus einrichten – hypothetisch werf up: „Starte mir ein lokales Kubernetes“. Und dann dort eine hypothetische Instanz von werf follow. Dann kann der Entwickler in der IDE bearbeiten, während im System ein Prozess läuft, der Änderungen erkennt und Images neu erstellt und sie ins lokale K8s neu bereitstellt. So wollen wir versuchen, das Problem der lokalen Entwicklung zu lösen.
Snapshots und Datenbankklonierung in K8s Realitäten
NS: Wenn wir zum Copy-on-Write zurückkehren. Mir ist aufgefallen, dass auch Clouds Snapshots haben. Sie funktionieren unterschiedlich. Zum Beispiel in GCP: Du hast an der Ostküste der USA eine Multiterabyte-Instanz. Du machst regelmäßig Snapshots. Du hebst aus einem Snapshot eine Kopie des Datenträgers an der Westküste – nach wenigen Minuten ist alles bereit, das funktioniert sehr schnell, nur der Cache muss im Speicher gefüllt werden. Aber diese Klone (Snapshots) sind dafür da, um einen neuen volumen bereit zu stellen. Das ist großartig, wenn man viele Instanzen erstellen muss.
Für Tests hingegen denke ich, dass die Snapshots, von denen du in Docker sprichst oder ich in ZFS, btrfs und sogar LVM… – sie ermöglichen es, auf einer Maschine keine echten neuen Daten zu erzeugen. In der Cloud musst du dafür jedes Mal bezahlen und wirst nicht nur Sekunden, sondern Minuten warten (und im Falle von , möglicherweise sogar Stunden).
Stattdessen können diese Daten in ein oder zwei Sekunden abgerufen, ein Test durchgeführt und dann verworfen werden. Diese Snapshots erfüllen verschiedene Aufgaben. Im ersten Fall geht es darum, zu skalieren und neue Replikate zu erhalten, im zweiten Fall für Tests.
DS: Da stimme ich nicht zu. Eine ordnungsgemäße Klonierung von Volumina ist eine Aufgabe für die Cloud. Ich habe ihre Implementierung nicht gesehen, weiß aber, wie wir das auf unserer Hardware umsetzen. Wir haben Ceph, wo man jedem physischen Volume () sagen kann, clone und innerhalb von vielen Millisekunden ein zweites Volume mit den gleichen Eigenschaften, usw. erhält. Man muss verstehen, dass dort innen ein cleveres Copy-on-Write-System steckt. Warum sollte die Cloud das nicht auch so machen? Ich bin mir sicher, dass sie versuchen, es in irgendeiner Form umzusetzen.
NS: Aber sie werden trotzdem Sekunden, Dutzende von Sekunden benötigen, um eine Instanz hochzufahren, Docker dorthin zu bringen usw.
DS: Warum muss unbedingt eine gesamte Instanz hochgefahren werden? Wir haben doch eine Instanz mit 32 Kernen, mit 16… und da passen eine bestimmte Anzahl rein – zum Beispiel vier. Wenn wir die fünfte bestellen, wird bereits eine Instanz hochgefahren und danach wieder gelöscht.
NS: Ja, interessant, in Kubernetes ergibt sich eine andere Geschichte. Unsere DB läuft nicht in K8s und ist eine einzige Instanz. Aber für das Klonen einer mehrere Terabyte umfassenden Datenbank benötigt man nicht mehr als zwei Sekunden.
DS: Das ist großartig. Aber mein ursprünglicher Punkt ist, dass es keine generische Lösung ist. Ja, es ist klasse, aber es funktioniert nur mit Postgres und nur auf einem Knoten.
NS: Es ist nicht nur für Postgres geeignet: Diese Pläne, wie ich beschrieben habe, werden nur in diesem funktionieren. Aber wenn wir uns nicht um die Pläne kümmern, sondern einfach alle Daten für funktionale Tests benötigen, dann ist es für jede DBMS geeignet.
DS: Vor vielen Jahren haben wir etwas Ähnliches mit LVM-Snapshots gemacht. Das ist klassisch. Dieser Ansatz wurde sehr häufig verwendet. Stateful-Knoten sind jedoch eine Herausforderung. Weil man sie nicht ignorieren darf, immer präsent sein muss…
NS: Siehst du hier nicht eine Möglichkeit für ein Hybridsystem? Angenommen, der Stateful-Knoten ist ein Pod, der von mehreren Mitarbeitern (viele Tester) genutzt wird. Wir haben nur einen Speicher, aber dank des Dateisystems sind die Klone lokal. Wenn der Pod ausfällt, bleibt die Festplatte — der Pod wird neu gestartet, erkennt alle Klone und gibt an: „Hier sind eure Klone, die auf diesen Ports laufen, arbeitet weiter damit.“
DS: Technisch bedeutet dies, dass es innerhalb von Kubernetes ein Pod ist, in dem wir viele Postgres-Instanzen ausführen.
NS: Ja. Es gibt ein Limit: Angenommen, nicht mehr als 10 Personen arbeiten gleichzeitig daran. Wenn 20 benötigt werden, starten wir einen zweiten solchen Pod. Es ist völlig realistisch, ihn zu klonen und einen zweiten vollständigen Volume zu erhalten, auf dem ebenfalls 10 „dünne“ Klone laufen. Siehst du diese Möglichkeit nicht?
DS: Wir müssen hier Sicherheitsfragen hinzufügen. Diese Organisationsmethode impliziert, dass dieser Pod hohe Privilegien (Capabilities) hat, da er unübliche Operationen am Dateisystem ausführen kann... Aber ich wiederhole: Ich glaube, dass Kubernetes das Storage-Management in naher Zukunft reparieren wird und dass in der Cloud die ganze Geschichte mit den Volumes funktioniert – alles wird „einfach funktionieren“. Es wird Resize und Klonen geben... Es gibt ein Volume – wir sagen: „Erstelle ein neues basierend auf diesem“, und innerhalb von anderthalb Sekunden erhalten wir, was wir brauchen.
NS: Ich glaube nicht an anderthalb Sekunden für mehrere Terabyte. Bei Ceph machst du das selbst, während du von Clouds sprichst. Geh in die Cloud, mach auf EC2 einen Klon eines EBS-Volumes mit vielen Terabytes und schau dir die Leistung an. Das wird keine paar Sekunden dauern. Ich bin sehr gespannt, wann sie dieses Leistungsniveau erreichen. Ich verstehe, worüber du sprichst, aber ich erlaube mir, nicht einverstanden zu sein.
DS: In Ordnung, aber ich habe gesagt, dass ich mittel- bis langfristig spreche, nicht kurzfristig. Innerhalb von ein paar Jahren.
Über den Operator für PostgreSQL von Zalando
Mitte dieses Treffens kam auch Alexey Klyukin, ein ehemaliger Entwickler von Zalando, zu Wort, der die Geschichte des PostgreSQL-Operators erzählte:
Es ist großartig, dass dieses Thema überhaupt angesprochen wurde: Postgres und Kubernetes. Als wir 2017 bei Zalando damit anfingen, war es ein Thema, das alle interessierte, aber niemand kümmerte sich darum. Alle hatten bereits Kubernetes, aber wenn man fragte, wie man es mit Datenbanken macht, sagten sogar solche Leute wie , die für K8s plädierten, etwa folgendes:
„Geht zu Managed-Services und nutzt diese, startet keine DB in Kubernetes. Andernfalls wird euer K8s zum Beispiel ein Upgrade machen, alle Knoten herunterfahren und eure Daten werden weit weg sein.“
Wir haben entschieden, einen Operator zu entwickeln, der entgegen diesem Rat Postgres-Datenbanken in Kubernetes starten wird. Und wir hatten eine gute Grundlage – . Dies ist ein automatischer Failover für PostgreSQL, der richtig implementiert ist, d.h. er nutzt etcd, Consul oder ZooKeeper als Speichersystem für die Clusterinformationen. Ein solches System, das allen Anfragen dieselbe Information über den aktuellen Leader zurückgibt — unabhängig davon, dass wir alles verteilt haben — um Split-Brain-Situationen zu vermeiden. Außerdem hatten wir dafür.
Generell entstand der Bedarf an Auto-Failover für das Unternehmen nach der Migration von einem internen Rechenzentrum in die Cloud. Die Cloud basierte auf einer eigenen PaaS-Lösung (Platform-as-a-Service). Diese ist Open Source, aber um sie zum Laufen zu bringen, musste man viel Arbeit investieren. Sie nannte sich .
Anfangs gab es kein Kubernetes. Genauer gesagt, als die eigene Lösung entwickelt wurde, existierte K8s bereits, aber es war so unausgereift, dass es für die Produktion nicht geeignet war. Das war, glaube ich, im Jahr 2015 oder 2016. Bis 2017 war Kubernetes einigermaßen ausgereift — es entstand die Notwendigkeit, dorthin zu migrieren.
Wir hatten bereits einen Docker-Container. Es gab eine PaaS, die Docker verwendet hat. Warum nicht K8s ausprobieren? Warum nicht einen eigenen Operator schreiben? Murat Kabilov, der zu uns von Avito kam, hat dies als Projekt aus eigener Initiative begonnen – um ein bisschen zu experimentieren – und das Projekt hat Erfolg gehabt.
Ich wollte jedoch eigentlich über AWS sprechen. Warum gab es dort historisch gesehen Code, der mit AWS verknüpft ist...
Wenn Sie etwas in Kubernetes starten, sollten Sie verstehen, dass K8s ein kontinuierlicher Entwicklungsprozess ist. Es entwickelt sich ständig weiter, wird verbessert und geht gelegentlich auch mal kaputt. Man muss die Änderungen in Kubernetes genau im Auge behalten und bereit sein, sich tief damit auseinanderzusetzen und zu verstehen, wie es im Detail funktioniert – vielleicht mehr, als einem lieb ist. Das gilt im Grunde für jede Plattform, auf der Sie Ihre Datenbanken betreiben...
Als wir den Operator entwickelten, hatten wir Postgres, das mit einem externen Volume (in diesem Fall EBS, da wir in AWS arbeiteten) verbunden war. Die Datenbank wuchs, und irgendwann war es notwendig, eine Größenänderung durchzuführen: Zum Beispiel war die ursprüngliche EBS-Größe 100 TB und die Datenbank hat diesen Betrag erreicht, nun möchten wir EBS auf 200 TB erweitern. Wie geht das? Man könnte einen Dump/Restore auf eine neue Instanz machen, aber das wäre zeitaufwendig und würde zu Ausfallzeiten führen.
Deshalb wollten wir eine Größenänderung, die den EBS-Bereich erweitert und dann der Dateisystem sagt, dass es den neuen Platz nutzen soll. Und das haben wir erreicht, aber damals gab es in Kubernetes keinen API für die Größenänderung. Da wir auf AWS arbeiteten, haben wir Code für deren API geschrieben.
Es steht niemandem im Weg, das Gleiche für andere Plattformen zu tun. Der Operator ist nicht an AWS gebunden, er funktioniert auch auf anderen Plattformen. Letztlich ist es ein Open-Source-Projekt: Wenn jemand die Einführung eines neuen APIs beschleunigen möchte – herzlich willkommen. Es gibt , Pull-Requests – das Zalando-Team bemüht sich, darauf recht zügig zu reagieren und den Operator voranzubringen. Soweit ich weiß, hat das Projekt im Google Summer of Code und ähnlichen Initiativen. Zalando arbeitet sehr aktiv daran.
P.S. Bonus!
Wenn Sie sich für das Thema PostgreSQL und Kubernetes interessieren, möchten wir auch darauf hinweisen, dass in der letzten Woche der nächste Postgres-Dienstag stattfand, bei dem Nikolai sich mit Alexander Kukushkin von Zalando unterhielt.. Das Video davon ist verfügbar. .
P.P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
