Ende letzten Jahres fand eine weitere Live-Übertragung der russischen PostgreSQL-Community statt , bei dem sein Mitbegründer Nikolai Samokhvalov mit dem technischen Direktor von Flant, Dmitry Stolyarov, über dieses DBMS im Kontext von Kubernetes sprach.
Wir veröffentlichen eine Abschrift des Hauptteils dieser Diskussion und unter Vollständiges Video gepostet:
Datenbanken und Kubernetes
NA: Wir werden heute nicht über VACUUM und CHECKPOINTs sprechen. Wir wollen über Kubernetes sprechen. Ich weiß, dass Sie über langjährige Erfahrung verfügen. Ich habe mir Ihre Videos angesehen und einige davon sogar noch einmal angesehen ... Kommen wir gleich zur Sache: Warum überhaupt Postgres oder MySQL in K8s?
DS: Eine eindeutige Antwort auf diese Frage gibt es nicht und kann es auch nicht geben. Aber im Allgemeinen ist dies ein Potenzial für Einfachheit und Bequemlichkeit. Jeder möchte Managed Services.
NA: Wie , nur zuhause?
DS: Ja: wie RDS, einfach überall.
NA: „Anywhere“ ist ein guter Punkt. In großen Unternehmen befindet sich alles an verschiedenen Orten. Warum sollte man dann, wenn es sich um ein großes Unternehmen handelt, nicht auf eine fertige Lösung zurückgreifen? Nutanix hat beispielsweise eigene Entwicklungen, andere Firmen (VMware...) haben das gleiche „RDS, nur zu Hause“.
DS: Aber wir sprechen hier von einer separaten Implementierung, die nur unter bestimmten Bedingungen funktioniert. Und wenn wir über Kubernetes sprechen, dann gibt es eine große Vielfalt an Infrastruktur (die in K8s sein kann). Im Wesentlichen handelt es sich hierbei um einen Standard für APIs zur Cloud ...
NA: Es ist auch kostenlos!
DS: Es ist nicht so wichtig. Freiheit ist für kein sehr großes Marktsegment wichtig. Etwas anderes ist wichtig... Sie erinnern sich wahrscheinlich an den Bericht „"?
NA: Ja
DS: Mir wurde klar, dass es sehr zweideutig aufgenommen wurde. Einige Leute dachten, ich würde sagen: „Leute, lasst uns alle Datenbanken in Kubernetes integrieren!“, während andere meinten, dass das alles schreckliche Fahrräder seien. Aber ich wollte etwas ganz anderes sagen: „Schauen Sie, was passiert, welche Probleme es gibt und wie sie gelöst werden können.“ Sollten wir jetzt Kubernetes-Datenbanken verwenden? Produktion? Naja, nur wenn du Lust hast...bestimmte Dinge zu tun. Aber als Entwickler kann ich sagen, dass ich es empfehle. Für einen Entwickler ist die Dynamik beim Erstellen/Löschen von Umgebungen sehr wichtig.“
NS: Mit Entwickler meinen Sie alle Umgebungen, die nicht produziert werden? Staging, Qualitätssicherung…
DS: Wenn es um Perf-Stände geht, dann wahrscheinlich nicht, denn dort sind die Anforderungen spezifisch. Wenn wir über Sonderfälle sprechen, in denen eine sehr große Datenbank für das Staging benötigt wird, dann wahrscheinlich nicht ... Wenn es sich um eine statische, langlebige Umgebung handelt, welchen Vorteil hat es dann, wenn sich die Datenbank in K8s befindet?
NA: Keiner. Aber wo sehen wir statische Umgebungen? Eine statische Umgebung wird morgen obsolet sein.
DS: Staging kann statisch sein. Wir haben Kunden...
NA: Ja, ich habe auch eins. Es ist ein großes Problem, wenn Sie eine 10-TB-Datenbank und 200-GB-Staging haben ...
DS: Ich habe eine sehr coole Hülle! Beim Staging gibt es eine Produktdatenbank, an der Änderungen vorgenommen werden. Und es gibt einen Button: „Rollout to Production“. Diese Änderungen – Deltas – werden in der Produktion hinzugefügt (anscheinend werden sie einfach über die API synchronisiert). Dies ist eine sehr exotische Option.
NA: Ich habe Startups im Valley gesehen, die in RDS oder sogar in Heroku sitzen – das sind Geschichten von vor 2-3 Jahren – und sie laden den Dump auf ihren Laptop herunter. Denn die Datenbank ist immer noch nur 80 GB groß und auf dem Laptop ist noch Platz. Dann kaufen sie für alle zusätzliche Festplatten, sodass sie über drei Datenbanken verfügen, um verschiedene Entwicklungen durchzuführen. So passiert es auch. Ich habe auch gesehen, dass sie keine Angst davor haben, Produkte in die Staging-Umgebung zu kopieren – das hängt stark vom Unternehmen ab. Aber ich habe auch gesehen, dass sie große Angst haben und oft nicht genug Zeit und Hände haben. Aber bevor wir zu diesem Thema übergehen, würde ich gerne etwas über Kubernetes erfahren. Verstehe ich richtig, dass noch niemand in der Produktion ist?
DS: Wir haben kleine Datenbanken in Produktion. Wir sprechen von Volumina im zweistelligen Gigabyte-Bereich und unkritischen Diensten, für die wir zu faul waren, Replikate zu erstellen (und es besteht keine solche Notwendigkeit). Und vorausgesetzt, es gibt normalen Speicher unter Kubernetes. Diese Datenbank arbeitete in einer virtuellen Maschine – bedingt in VMware, auf dem Speichersystem. Wir haben es hineingelegt und jetzt können wir es von Maschine zu Maschine übertragen.
NA: Datenbanken dieser Größe, bis zu 100 GB, auf guten Festplatten und einem guten Netzwerk kann man in wenigen Minuten ausrollen, oder? Eine Geschwindigkeit von 1 GB pro Sekunde ist kein Exot mehr.
DS: Ja, für den linearen Betrieb ist das kein Problem.
NA: Okay, wir müssen nur über Produkte nachdenken. Und was sollten wir tun, wenn wir Kubernetes für Nicht-Produktumgebungen in Betracht ziehen? Das sehe ich bei Zalando , in Crunchy , es gibt noch einige andere Möglichkeiten. Und da ist - Das ist unser guter Freund Alvaro aus Spanien: Was sie tun, ist im Grunde nicht gerecht , und die gesamte Verteilung (), in die zusätzlich zu Postgres selbst auch ein Backup, der Envoy-Proxy, eingefügt wurde ...
DS: Gesandter für was? Postgres-Verkehr speziell ausgleichen?
NA: Ja. Das heißt, sie sehen es so: Wenn man eine Linux-Distribution und einen Linux-Kernel nimmt, dann ist normales PostgreSQL der Kernel, und sie wollen eine Distribution erstellen, die Cloud-freundlich ist und auf Kubernetes läuft. Sie stellen Komponenten (Backups usw.) zusammen und debuggen sie, damit sie gut funktionieren.
DS: Sehr cool! Im Wesentlichen handelt es sich dabei um eine Software zum Erstellen Ihres eigenen verwalteten Postgres.
NA: Linux-Distributionen haben ewige Probleme: Wie erstellt man Treiber, damit die gesamte Hardware unterstützt wird? Und sie haben die Idee, dass sie in Kubernetes arbeiten werden. Ich weiß, dass wir beim Zalando-Betreiber kürzlich eine Verbindung zu AWS gesehen haben und diese nicht mehr sehr gut ist. Es sollte keine Bindung an eine bestimmte Infrastruktur geben – welchen Sinn hat das dann?
DS: Ich weiß nicht genau, in welche Situation Zalando geraten ist, aber in Kubernetes ist der Speicher mittlerweile so gestaltet, dass es unmöglich ist, mit einer generischen Methode ein Festplatten-Backup zu erstellen. Kürzlich im Standard - in der neuesten Version — Wir haben Snapshots ermöglicht, aber wo wird es implementiert? Ehrlich gesagt, alles ist noch so roh ... Wir probieren CSI zusätzlich zu AWS, GCE, Azure, vSphere aus, aber sobald man anfängt, es zu verwenden, merkt man, dass es noch nicht fertig ist.
NA: Deshalb sind wir manchmal auf Infrastruktur angewiesen. Ich denke, das ist noch ein frühes Stadium – Wachstumsschmerzen. Frage: Welchen Rat würden Sie Neulingen geben, die PgSQL in K8s ausprobieren möchten? Welcher Betreiber vielleicht?
DS: Das Problem ist, dass Postgres für uns 3 % beträgt. Wir haben auch eine sehr große Liste verschiedener Software in Kubernetes, ich werde nicht einmal alles auflisten. Zum Beispiel Elasticsearch. Es gibt viele Betreiber: Einige entwickeln sich aktiv weiter, andere nicht. Wir haben für uns selbst Anforderungen formuliert, was ein Betreiber haben sollte, damit wir diese ernst nehmen können. In einem Operator speziell für Kubernetes – nicht in einem „Operator, der etwas unter den Bedingungen von Amazon tut“ … Tatsächlich verwenden wir ziemlich häufig (= fast alle Kunden) einen einzigen Operator – (wir werden bald einen Artikel über ihn veröffentlichen).
NA: Und auch nicht für MySQL? Ich weiß, dass Percona ... da sie jetzt an MySQL, MongoDB und Postgres arbeiten, eine Art universelle Lösung schaffen müssen: für alle Datenbanken, für alle Cloud-Anbieter.
DS: Wir hatten keine Zeit, uns die Operatoren für MySQL anzusehen. Dies ist derzeit nicht unser Hauptaugenmerk. MySQL funktioniert im Standalone-Modus einwandfrei. Warum einen Operator verwenden, wenn Sie einfach eine Datenbank starten können? Sie können einen Docker-Container mit Postrges oder auf einfache Weise starten.
NA: Dazu gab es auch eine Frage. Gar kein Betreiber?
DS: Ja, bei 100 % von uns läuft PostgreSQL ohne Operator. So weit so. Wir nutzen den Operator aktiv für Prometheus und Redis. Wir planen, einen Operator für Elasticsearch zu finden – er ist derjenige, der am meisten „in Flammen“ steht, weil wir ihn in 100 % der Fälle in Kubernetes installieren wollen. Genauso wie wir sicherstellen wollen, dass MongoDB auch immer in Kubernetes installiert ist. Hier tauchen bestimmte Wünsche auf – es entsteht das Gefühl, dass in diesen Fällen etwas getan werden kann. Und wir haben uns Postgres nicht einmal angesehen. Natürlich wissen wir, dass es verschiedene Möglichkeiten gibt, aber tatsächlich haben wir eine eigenständige Lösung.
DB zum Testen in Kubernetes
NA: Kommen wir zum Thema Testen. Wie man Änderungen an der Datenbank ausrollt – aus DevOps-Perspektive. Es gibt Microservices, viele Datenbanken, irgendwo verändert sich ständig etwas. So stellen Sie normales CI/CD sicher, damit aus DBMS-Perspektive alles in Ordnung ist. Was ist Ihr Ansatz?
DS: Eine Antwort kann es nicht geben. Es gibt mehrere Möglichkeiten. Das erste ist die Größe der Basis, die wir ausrollen möchten. Sie selbst haben erwähnt, dass Unternehmen unterschiedliche Einstellungen dazu haben, eine Kopie der Produktdatenbank auf der Entwicklungs- und Bühnenebene zu haben.
NA: Und unter den Bedingungen der DSGVO denke ich, dass sie immer vorsichtiger werden... Ich kann sagen, dass sie in Europa bereits damit begonnen haben, Bußgelder zu verhängen.
DS: Aber oft kann man Software schreiben, die einen Dump aus der Produktion übernimmt und ihn verschleiert. Es werden Produktdaten erfasst (Snapshot, Dump, Binärkopie...), diese sind jedoch anonymisiert. Stattdessen kann es Generierungsskripte geben: Dabei kann es sich um Fixtures handeln oder einfach nur um ein Skript, das eine große Datenbank generiert. Das Problem ist: Wie lange dauert die Erstellung eines Basisimages? Und wie lange dauert die Bereitstellung in der gewünschten Umgebung?
Wir sind zu einem Schema gekommen: Wenn der Client über einen festen Datensatz (Minimalversion der Datenbank) verfügt, verwenden wir diese standardmäßig. Wenn wir über Überprüfungsumgebungen sprechen, haben wir beim Erstellen einer Verzweigung eine Instanz der Anwendung bereitgestellt – wir führen dort eine kleine Datenbank ein. Aber es ist gut geworden , wenn wir einmal am Tag (nachts) einen Dump aus der Produktion nehmen und darauf basierend einen Docker-Container mit PostgreSQL und MySQL mit diesen geladenen Daten erstellen. Wenn Sie die Datenbank von diesem Bild aus 50 Mal erweitern müssen, ist dies ganz einfach und schnell erledigt.
NA: Durch einfaches Kopieren?
DS: Daten werden direkt im Docker-Image gespeichert. Diese. Wir haben ein fertiges Image, allerdings 100 GB. Dank der Ebenen in Docker können wir dieses Image so oft wie nötig schnell bereitstellen. Die Methode ist dumm, funktioniert aber gut.
NA: Wenn Sie dann testen, ändert es sich direkt in Docker, oder? Copy-on-Write in Docker – wegwerfen und wieder loslegen, alles ist in Ordnung. Klasse! Und nutzen Sie es bereits in vollem Umfang?
DS: Für eine lange Zeit.
NA: Wir machen sehr ähnliche Dinge. Nur verwenden wir nicht das Copy-on-Write von Docker, sondern ein anderes.
DS: Es ist nicht generisch. Und Docker funktioniert überall.
NA: Theoretisch ja. Aber wir haben dort auch Module, Sie können verschiedene Module erstellen und mit verschiedenen Dateisystemen arbeiten. Was für ein Moment hier. Von der Postgres-Seite aus sehen wir das alles anders. Jetzt habe ich von der Docker-Seite aus geschaut und festgestellt, dass bei Ihnen alles funktioniert. Aber wenn die Datenbank riesig ist, zum Beispiel 1 TB, dann dauert das alles sehr lange: Operationen in der Nacht und alles in Docker stopfen ... Und wenn 5 TB in Docker gestopft werden ... Oder ist alles in Ordnung?
DS: Was ist der Unterschied: Das sind Blobs, nur Bits und Bytes.
NA: Der Unterschied besteht darin: Machen Sie es durch Dump und Restore?
DS: Überhaupt nicht notwendig. Die Methoden zur Generierung dieses Bildes können unterschiedlich sein.
NA: Für einige Kunden haben wir es so gestaltet, dass wir nicht regelmäßig ein Basis-Image generieren, sondern es ständig auf dem neuesten Stand halten. Es handelt sich im Wesentlichen um eine Replik, empfängt die Daten jedoch nicht direkt vom Master, sondern über ein Archiv. Ein Binärarchiv, in dem täglich WALs heruntergeladen und Backups erstellt werden ... Diese WALs erreichen dann das Basis-Image mit einer leichten Verzögerung (im wahrsten Sinne des Wortes 1-2 Sekunden). Wir klonen davon auf irgendeine Weise – jetzt haben wir standardmäßig ZFS.
DS: Aber mit ZFS sind Sie auf einen Knoten beschränkt.
NA: Ja. Aber ZFS hat auch etwas Magisches : damit kann man einen Schnappschuss verschicken und sogar (ich habe das noch nicht wirklich getestet, aber...) man kann ein Delta zwischen zwei verschicken PGDATA. Tatsächlich verfügen wir über ein weiteres Tool, das wir für solche Aufgaben noch nicht wirklich in Betracht gezogen haben. PostgreSQL hat , das wie ein „intelligenter“ Rsync funktioniert und viel von dem überspringt, was Sie nicht sehen müssen, weil sich dort nichts geändert hat. Wir können eine schnelle Synchronisierung zwischen den beiden Servern durchführen und auf die gleiche Weise zurückspulen.
Aus dieser eher DBA-Seite versuchen wir also, ein Tool zu entwickeln, mit dem wir das Gleiche tun können, was Sie gesagt haben: Wir haben eine Datenbank, aber wir möchten etwas 50 Mal fast gleichzeitig testen.
DS: 50 Mal bedeutet, dass Sie 50 Spot-Instanzen bestellen müssen.
NA: Nein, wir machen alles auf einer Maschine.
DS: Aber wie soll eine 50-fache Erweiterung erfolgen, wenn diese eine Datenbank beispielsweise Terabyte groß ist? Höchstwahrscheinlich benötigt sie bedingt 256 GB RAM?
NA: Ja, manchmal braucht man viel Speicher – das ist normal. Aber das ist ein Beispiel aus dem Leben. Die Produktionsmaschine verfügt über 96 Kerne und 600 GB. Gleichzeitig werden 32 Kerne (manchmal sogar 16 Kerne) und 100-120 GB Speicher für die Datenbank verwendet.
DS: Und da passen 50 Exemplare rein?
NA: Es gibt also nur eine Kopie, dann funktioniert Copy-on-Write (ZFS)... Ich erzähle es dir genauer.
Wir haben zum Beispiel eine 10 TB große Datenbank. Sie haben eine Festplatte dafür gemacht, ZFS hat auch ihre Größe um 30-40 Prozent komprimiert. Da wir keine Lasttests durchführen, ist die genaue Reaktionszeit für uns nicht wichtig: Lassen Sie sie bis zu 2-mal langsamer sein – das ist in Ordnung.
Wir bieten Programmierern, Qualitätssicherung, DBA usw. die Möglichkeit. Führen Sie Tests in 1-2 Threads durch. Beispielsweise könnten sie eine Art Migration durchführen. Es sind nicht 10 Kerne gleichzeitig erforderlich – es sind 1 Postgres-Backend und 1 Kern erforderlich. Die Migration wird beginnen – vielleicht startet trotzdem, dann wird der zweite Kern genutzt. Wir haben 16–32 Kerne zugewiesen, sodass 10 Personen gleichzeitig arbeiten können, kein Problem.
Denn körperlich PGDATA Ebenso stellt sich heraus, dass wir Postgres tatsächlich täuschen. Der Trick ist folgender: Beispielsweise werden 10 Postgres gleichzeitig gestartet. Was ist normalerweise das Problem? Sie setzen , sagen wir 25 %. Demnach sind es 200 GB. Sie können nicht mehr als drei davon starten, da der Speicher dann erschöpft ist.
Doch irgendwann wurde uns klar, dass das nicht nötig war: Wir haben shared_buffers auf 2 GB gesetzt. PostgreSQL hat , und in Wirklichkeit ist es das einzige, das beeinflusst . Wir haben es auf 0,5 TB eingestellt. Und es spielt keine Rolle, dass sie nicht wirklich existieren: Er macht Pläne, als ob sie existieren würden.
Wenn wir also eine Art Migration testen, können wir alle Pläne sammeln – wir werden sehen, wie es in der Produktion passieren wird. Die Sekunden dort werden unterschiedlich (langsamer) sein, aber die Daten, die wir tatsächlich lesen, und die Pläne selbst (welche JOINs es gibt usw.) sind genau die gleichen wie in der Produktion. Und Sie können viele solcher Prüfungen parallel auf einer Maschine durchführen.
DS: Glauben Sie nicht, dass es hier ein paar Probleme gibt? Die erste ist eine Lösung, die nur unter PostgreSQL funktioniert. Dieser Ansatz ist sehr privat und nicht generisch. Der zweite Grund ist, dass Kubernetes (und alles, was Cloud-Technologien jetzt umfassen) viele Knoten umfasst, und diese Knoten sind kurzlebig. Und in Ihrem Fall handelt es sich um einen zustandsbehafteten, dauerhaften Knoten. Diese Dinge verursachen bei mir Konflikte.
NA: Erstens stimme ich zu, dies ist eine reine Postgres-Geschichte. Ich denke, wenn wir eine Art direkte E/A und einen Pufferpool für fast den gesamten Speicher haben, wird dieser Ansatz nicht funktionieren – die Pläne werden anders sein. Aber im Moment arbeiten wir nur mit Postgres, wir denken nicht an andere.
Über Kubernetes. Sie selbst sagen uns überall, dass wir eine persistente Datenbank haben. Wenn die Instanz ausfällt, besteht die Hauptsache darin, die Festplatte zu retten. Hier haben wir auch die gesamte Plattform in Kubernetes und die Komponente mit Postgres ist separat (obwohl sie eines Tages dort sein wird). Daher ist alles so: Die Instanz ist abgestürzt, aber wir haben ihre PV gespeichert und sie einfach mit einer anderen (neuen) Instanz verbunden, als wäre nichts passiert.
DS: Aus meiner Sicht erstellen wir Pods in Kubernetes. K8s – elastisch: Knoten werden nach Bedarf bestellt. Die Aufgabe besteht darin, einfach einen Pod zu erstellen und zu sagen, dass er X Ressourcen benötigt, und K8s wird es dann selbst herausfinden. Die Speicherunterstützung in Kubernetes ist jedoch immer noch instabil: In (Diese Version wurde veröffentlicht недели vor) sind diese Funktionen nur noch Beta.
Es vergehen sechs Monate bis ein Jahr – es wird mehr oder weniger stabil, oder zumindest wird es als solches deklariert. Dann löst die Möglichkeit von Schnappschüssen und Größenänderungen Ihr Problem vollständig. Weil Sie eine Basis haben. Ja, es ist möglicherweise nicht sehr schnell, aber die Geschwindigkeit hängt davon ab, was sich „unter der Haube“ befindet, da einige Implementierungen auf der Ebene des Festplattensubsystems kopieren und beim Schreiben kopieren können.
NA: Es ist auch notwendig, dass alle Engines (Amazon, Google...) mit der Unterstützung dieser Version beginnen – auch das dauert einige Zeit.
DS: Wir nutzen sie noch nicht. Wir nutzen unsere.
Lokale Entwicklung für Kubernetes
NA: Sind Sie auf einen solchen Wunsch gestoßen, wenn Sie alle Pods auf einer Maschine installieren und einen so kleinen Test durchführen müssen? Um schnell einen Machbarkeitsnachweis zu erhalten, stellen Sie sicher, dass die Anwendung in Kubernetes ausgeführt wird, ohne dass dafür eine Reihe von Maschinen reserviert werden müssen. Da ist Minikube, oder?
DS: Mir scheint, dass es in diesem Fall – bereitgestellt auf einem Knoten – ausschließlich um lokale Entwicklung geht. Oder einige Manifestationen eines solchen Musters. Essen Da , . Wir bewegen uns in Richtung der Verwendung von Kubernetes IN Docker. Jetzt haben wir begonnen, damit für Tests zu arbeiten.
NA: Früher dachte ich, dass dies ein Versuch sei, alle Pods in ein Docker-Image zu packen. Doch es stellte sich heraus, dass es hier um etwas ganz anderes geht. Wie auch immer, es gibt separate Container, separate Pods – nur in Docker.
DS: Ja. Und es gibt eine ziemlich lustige Nachahmung, aber die Bedeutung ist folgende: Wir haben ein Dienstprogramm für die Bereitstellung – . Wir wollen es zu einem bedingten Modus machen werf up: „Besorgen Sie mir lokales Kubernetes.“ Und dann führen Sie dort die Bedingung aus werf follow. Dann kann der Entwickler die IDE bearbeiten und im System wird ein Prozess gestartet, der die Änderungen erkennt, die Bilder neu erstellt und sie erneut auf lokalen K8s bereitstellt. Auf diese Weise wollen wir versuchen, das Problem der lokalen Entwicklung zu lösen.
Snapshots und Datenbankklonen in der K8-Realität
NA: Wenn wir zum Copy-on-Write zurückkehren. Mir ist aufgefallen, dass die Wolken auch Schnappschüsse haben. Sie funktionieren unterschiedlich. Beispiel: In GCP haben Sie eine Multi-Terabyte-Instanz an der Ostküste der Vereinigten Staaten. Sie machen regelmäßig Schnappschüsse. Man holt sich an der Westküste eine Kopie der Festplatte von einem Schnappschuss – in wenigen Minuten ist alles fertig, es funktioniert sehr schnell, nur der Cache muss im Speicher gefüllt werden. Diese Klone (Snapshots) dienen jedoch dazu, ein neues Volume bereitzustellen. Das ist cool, wenn Sie viele Instanzen erstellen müssen.
Aber für Tests scheint mir, dass Snapshots, über die Sie in Docker oder ich in ZFS, Btrfs und sogar LVM sprechen, es Ihnen ermöglichen, keine wirklich neuen Daten auf einer Maschine zu erstellen. In der Cloud zahlen Sie immer noch jedes Mal dafür und warten nicht Sekunden, sondern Minuten (und in diesem Fall , möglicherweise eine Uhr).
Stattdessen können Sie diese Daten in ein oder zwei Sekunden abrufen, den Test ausführen und sie dann verwerfen. Diese Schnappschüsse lösen verschiedene Probleme. Im ersten Fall – um zu skalieren und neue Replikate zu erhalten, und im zweiten – für Tests.
DS: Ich stimme nicht zu. Das ordnungsgemäße Funktionieren des Volume-Klonens ist die Aufgabe der Cloud. Ich habe mir ihre Implementierung nicht angesehen, aber ich weiß, wie wir es auf Hardware machen. Wir haben Ceph, es ermöglicht jedes physische Volumen () sagen klonen und innerhalb von zehn Millisekunden ein zweites Volumen mit den gleichen Eigenschaften erhalten, 'ami usw. Sie müssen verstehen, dass darin eine knifflige Copy-on-Write-Funktion steckt. Warum sollte die Cloud nicht dasselbe tun? Ich bin sicher, dass sie das auf die eine oder andere Weise versuchen.
NA: Aber es wird immer noch Sekunden, Dutzende von Sekunden dauern, um eine Instanz zu erstellen, Docker dorthin zu bringen usw.
DS: Warum ist es notwendig, eine ganze Instanz auszulösen? Wir haben eine Instanz mit 32 Kernen, 16 ... und es passen hinein – zum Beispiel vier. Wenn wir den fünften bestellen, wird die Instanz bereits erhöht und dann gelöscht.
NA: Ja, interessant, Kubernetes stellt sich als eine andere Geschichte heraus. Unsere Datenbank befindet sich nicht in K8s und wir haben eine Instanz. Das Klonen einer Multi-Terabyte-Datenbank dauert jedoch nicht länger als zwei Sekunden.
DS: Das ist cool. Aber mein erster Punkt ist, dass dies keine generische Lösung ist. Ja, es ist cool, aber es ist nur für Postgres und nur auf einem Knoten geeignet.
NA: Es ist nicht nur für Postgres geeignet: Diese Pläne funktionieren, wie ich beschrieben habe, nur darin. Wenn wir uns jedoch nicht um Pläne kümmern und lediglich alle Daten für Funktionstests benötigen, ist dies für jedes DBMS geeignet.
DS: Vor vielen Jahren haben wir etwas Ähnliches mit LVM-Snapshots gemacht. Das ist ein Klassiker. Dieser Ansatz wurde sehr aktiv genutzt. Zustandsbehaftete Knoten sind einfach eine Qual. Weil man sie nicht fallen lassen sollte, sollte man sie immer im Gedächtnis behalten...
NA: Sehen Sie hier die Möglichkeit eines Hybrids? Nehmen wir an, Stateful ist eine Art Pod, der für mehrere Personen (viele Tester) funktioniert. Wir haben ein Volume, aber dank des Dateisystems sind die Klone lokal. Wenn der Pod herunterfällt, aber die Festplatte bleibt, steigt der Pod, zählt Informationen über alle Klone, nimmt alles wieder auf und sagt: „Hier laufen Ihre Klone auf diesen Ports, arbeiten Sie weiter mit ihnen.“
DS: Technisch gesehen bedeutet dies, dass es sich innerhalb von Kubernetes um einen Pod handelt, in dem wir viele Postgres ausführen.
NA: Ja. Er hat eine Grenze: Nehmen wir an, es arbeiten nicht mehr als 10 Personen gleichzeitig mit ihm. Wenn Sie 20 benötigen, starten wir einen zweiten solchen Pod. Wir werden es vollständig klonen, nachdem wir das zweite vollständige Volumen erhalten haben, wird es die gleichen 10 „dünnen“ Klone haben. Sehen Sie diese Chance nicht?
DS: Wir müssen hier Sicherheitsprobleme hinzufügen. Diese Art von Organisation impliziert, dass dieser Pod über hohe Privilegien (Fähigkeiten) verfügt, da er nicht standardmäßige Vorgänge im Dateisystem ausführen kann ... Aber ich wiederhole: Ich glaube, dass sie mittelfristig den Speicher in Kubernetes reparieren werden, und zwar in Die Wolken werden die ganze Geschichte mit Bänden reparieren – alles wird „einfach funktionieren“. Es wird Größenänderung und Klonen geben ... Es gibt ein Volume – wir sagen: „Erstellen Sie darauf basierend ein neues“, und nach anderthalb Sekunden bekommen wir, was wir brauchen.
NA: Ich glaube nicht an eineinhalb Sekunden für viele Terabyte. Auf Ceph machen Sie es selbst, aber Sie reden über die Wolken. Gehen Sie in die Cloud, erstellen Sie einen Klon eines EBS-Volumes mit mehreren Terabyte auf EC2 und sehen Sie, wie hoch die Leistung sein wird. Es wird nicht ein paar Sekunden dauern. Ich bin sehr gespannt, wann sie dieses Niveau erreichen werden. Ich verstehe, was Sie sagen, bin aber anderer Meinung.
DS: Ok, aber ich sagte mittelfristig, nicht kurzfristig. Seit einigen Jahren.
Über den Operator für PostgreSQL von Zalando
Mitten in diesem Treffen schaltete sich auch Alexey Klyukin, ein ehemaliger Entwickler von Zalando, ein und sprach über die Geschichte des PostgreSQL-Betreibers:
Es ist großartig, dass dieses Thema allgemein angesprochen wird: sowohl Postgres als auch Kubernetes. Als wir 2017 bei Zalando damit begonnen haben, war es ein Thema, das jeder machen wollte, aber keiner tat es. Jeder hatte bereits Kubernetes, aber als sie fragten, was sie mit Datenbanken machen sollten, antworteten sogar die Leute , der K8s predigte, sagte etwa Folgendes:
„Gehen Sie zu verwalteten Diensten und nutzen Sie sie, führen Sie die Datenbank nicht in Kubernetes aus. Andernfalls entscheiden sich Ihre K8 beispielsweise für ein Upgrade, schalten alle Knoten ab und Ihre Daten fliegen weit, weit weg.“
Wir haben uns entschieden, einen Betreiber zu gründen, der entgegen diesem Rat eine Postgres-Datenbank in Kubernetes startet. Und wir hatten einen guten Grund – . Dies ist ein automatischer Failover für PostgreSQL, der korrekt durchgeführt wird, d. h. Verwenden von etcd, consul oder ZooKeeper als Speicher für Informationen über den Cluster. Ein solches Repository, das jedem, der zum Beispiel fragt, wer der aktuelle Anführer ist, die gleichen Informationen liefert – trotz der Tatsache, dass wir alles verteilt haben – so dass es nicht zu einer Spaltung des Gehirns kommt. Außerdem hatten wir für ihn.
Im Allgemeinen entstand nach der Migration von einem internen Hardware-Rechenzentrum in die Cloud der Bedarf des Unternehmens an einem automatischen Failover. Die Cloud basierte auf einer proprietären PaaS-Lösung (Platform-as-a-Service). Es ist Open Source, aber es hat viel Arbeit gekostet, es zum Laufen zu bringen. Es wurde genannt .
Anfangs gab es kein Kubernetes. Genauer gesagt, als unsere eigene Lösung bereitgestellt wurde, gab es bereits K8s, aber sie waren so roh, dass sie nicht für die Produktion geeignet waren. Meiner Meinung nach war es 2015 oder 2016. Bis 2017 war Kubernetes mehr oder weniger ausgereift – es bestand die Notwendigkeit, dorthin zu migrieren.
Und wir hatten bereits einen Docker-Container. Es gab ein PaaS, das Docker nutzte. Warum nicht K8s ausprobieren? Warum schreiben Sie nicht Ihren eigenen Operator? Murat Kabilov, der aus Avito zu uns kam, startete dies als Projekt aus eigener Initiative – „zum Spielen“ – und das Projekt „startete“.
Aber im Allgemeinen wollte ich über AWS sprechen. Warum gab es historischen AWS-bezogenen Code ...
Wenn Sie etwas in Kubernetes ausführen, müssen Sie verstehen, dass K8s noch in Arbeit ist. Es entwickelt sich ständig weiter, verbessert sich und bricht von Zeit zu Zeit sogar zusammen. Sie müssen alle Änderungen in Kubernetes genau im Auge behalten, Sie müssen bereit sein, sich darauf einzulassen, wenn etwas passiert, und zu erfahren, wie es im Detail funktioniert – vielleicht mehr, als Ihnen lieb ist. Dies gilt grundsätzlich für jede Plattform, auf der Sie Ihre Datenbanken betreiben...
Als wir die Anweisung erstellten, lief Postgres also auf einem externen Volume (in diesem Fall EBS, da wir auf AWS arbeiteten). Die Datenbank wuchs, irgendwann musste die Größe geändert werden: Die anfängliche Größe von EBS betrug beispielsweise 100 TB, die Datenbank wuchs darauf an, jetzt wollen wir EBS auf 200 TB bringen. Wie? Nehmen wir an, Sie können einen Dump/Restore auf einer neuen Instanz durchführen, aber das wird lange dauern und Ausfallzeiten mit sich bringen.
Deshalb wollte ich eine Größenänderung, die die EBS-Partition vergrößert und dann das Dateisystem anweist, den neuen Speicherplatz zu verwenden. Und wir haben es geschafft, aber zu diesem Zeitpunkt hatte Kubernetes keine API für den Größenänderungsvorgang. Da wir an AWS gearbeitet haben, haben wir Code für dessen API geschrieben.
Niemand hindert Sie daran, dasselbe für andere Plattformen zu tun. Die Aussage enthält keinen Hinweis darauf, dass es nur auf AWS ausgeführt werden kann und auf allen anderen Geräten nicht funktioniert. Im Allgemeinen handelt es sich um ein Open-Source-Projekt: Wer die Einführung der neuen API beschleunigen möchte, ist herzlich willkommen. Essen , Pull-Requests – das Zalando-Team versucht recht schnell darauf zu reagieren und den Betreiber zu fördern. Soweit ich weiß, ist das Projekt bei Google Summer of Code und einigen anderen ähnlichen Initiativen. Zalando arbeitet sehr aktiv daran.
PS-Bonus!
Wenn Sie sich für das Thema PostgreSQL und Kubernetes interessieren, dann beachten Sie bitte auch, dass letzte Woche der nächste Postgres-Dienstag stattfand, bei dem ich mit Nikolai gesprochen habe Alexander Kukuschkin von Zalando. Ein Video davon ist verfügbar .
PPS
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com