{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-Dienstag Nr. 5: \u201ePostgreSQL und Kubernetes. CI\/CD. Automatisierung von Tests\u201c","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-Dienstag
\n
\nAm Ende des vergangenen Jahres fand eine weitere Live-Sendung der russischen PostgreSQL-Community statt #RuPostgres<\/a><\/noindex>, in deren Rahmen sein Mitgr\u00fcnder Nikolai Samokhvalov mit dem technischen Direktor von \u00abFlant\u00bb Dmitriy Stolyarov \u00fcber diese Datenbank in Bezug auf Kubernetes sprach.<\/p>\n

Wir ver\u00f6ffentlichen das Protokoll des Hauptteils dieser Diskussion, und auf dem YouTube-Kanal der Community<\/a><\/noindex> wurde die vollst\u00e4ndige Videoaufzeichnung ver\u00f6ffentlicht:<\/a><\/noindex><\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Datenbanken und Kubernetes<\/h2>\n

\nNS<\/b>: Heute werden wir nicht \u00fcber VACUUM und CHECKPOINTs sprechen. Wir m\u00f6chten \u00fcber Kubernetes reden. Ich wei\u00df, dass du bereits viele Jahre Erfahrung hast. Ich habe deine Videos angeschaut und einige sogar teilweise nochmals angesehen\u2026 Lass uns direkt zur Sache kommen: Warum \u00fcberhaupt Postgres oder MySQL in K8s?<\/i><\/p>\n

DS<\/b>: Auf diese Frage gibt es keine eindeutige Antwort und kann es nicht geben. Aber im Allgemeinen, das ist einfach und bequem\u2026 potenziell. Jeder m\u00f6chte schlie\u00dflich Managed-Services.<\/p>\n

NS<\/b>: Um wie ausgenutzt, und es gibt bereits einen Exploit-Prototypen. Wie genau diese Informationen sind, ist bisher unklar; m\u00f6glicherweise sind im Bericht lediglich die Annahmen der NVD k\u00fcnstlerisch aufbereitet. Nach<\/a><\/noindex>, nur bei sich selbst?<\/i><\/p>\n

DS<\/b>: Ja: um wie RDS, nur \u00fcberall.<\/p>\n

NS<\/b>: \u201e\u00dcberall\u201c \u2014 das ist eine gute Anmerkung. In gro\u00dfen Unternehmen ist alles an verschiedenen Orten angesiedelt. Warum sollte man dann, wenn es sich um ein gro\u00dfes Unternehmen handelt, nicht eine fertige L\u00f6sung verwenden? Zum Beispiel hat Nutanix eigene Entwicklungen, andere Unternehmen (VMware\u2026) haben das gleiche \u201eRDS, nur bei sich\u201c.<\/i><\/p>\n

DS<\/b>: Aber hier sprechen wir \u00fcber eine spezifische Umsetzung, die nur unter bestimmten Bedingungen funktioniert. Wenn es um Kubernetes geht, gibt es hier eine riesige Vielfalt an Infrastruktur (die in K8s sein kann). Es ist im Grunde ein Standard f\u00fcr die API zur Cloud\u2026<\/p>\n

NS<\/b>: Und das sogar kostenlos!<\/i><\/p>\n

DS<\/b>: Das ist nicht so wichtig. Kostenlosheit ist f\u00fcr einen nicht sehr gro\u00dfen Teil des Marktes nicht von gro\u00dfer Bedeutung. Wichtiger ist etwas anderes\u2026 Du erinnerst dich wahrscheinlich an den Vortrag \u201eDatenbanken und Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Ja.<\/i><\/p>\n

DS<\/b>: Ich habe verstanden, dass das sehr unterschiedlich aufgenommen wurde. Einige Leute dachten, dass ich sage: \u201eLeute, lasst uns alle Datenbanken in Kubernetes bringen!\u201c, w\u00e4hrend andere der Meinung waren, dass das alles schreckliche Fahrr\u00e4der sind. Ich wollte eigentlich etwas ganz anderes sagen: \u201eSeht, was passiert, welche Probleme es gibt und wie man sie l\u00f6sen kann. Sollen wir mit Datenbanken in Kubernetes gehen? In die Produktion? Na, nur wenn ihr gerne\u2026 einige Dinge tut. F\u00fcr die Entwicklung \u2014 kann ich sagen, dass ich es empfehle. F\u00fcr die Entwicklung ist die Dynamik beim Erstellen\/L\u00f6schen von Umgebungen sehr wichtig.<\/p>\n

NS: Mit Entwicklung meinst du alle Umgebungen, die nicht Prod sind? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Wenn wir von perf-St\u00e4nden sprechen, dann wahrscheinlich nicht, weil die Anforderungen dort spezifisch sind. Wenn wir von speziellen F\u00e4llen sprechen, in denen auf Staging eine sehr gro\u00dfe DB ben\u00f6tigt wird, dann wahrscheinlich auch nicht... Wenn es sich um eine statische, langlebige Umgebung handelt, wo ist der Vorteil, wenn die Datenbank in K8s liegt?<\/p>\n

NS<\/b>: Keiner. Aber wo sehen wir statische Umgebungen? Statische Umgebungen sind morgen schon veraltet.<\/i><\/p>\n

DS<\/b>: Staging kann statisch sein. Wir haben Kunden\u2026<\/p>\n

NS<\/b>: Ja, ich habe auch welche. Es ist ein gro\u00dfes Problem, wenn du eine Datenbank mit 10 TB hast und das Staging nur 200 GB betr\u00e4gt\u2026<\/i><\/p>\n

DS<\/b>: Ich habe einen sehr coolen Anwendungsfall! Auf dem Staging ist die Produktionsdatenbank, in die \u00c4nderungen vorgenommen werden. Und es gibt einen Knopf: \u201eIn die Produktion bereitstellen\u201c. Diese \u00c4nderungen \u2014 Delten \u2014 werden (scheint, einfach \u00fcber die API synchronisiert) in die Produktion eingespielt. Das ist eine sehr exotische Variante.<\/p>\n

NS<\/b>: Ich habe Startups im Silicon Valley gesehen, die sich noch in RDS oder sogar in Heroku befinden \u2014 das sind Geschichten von vor 2-3 Jahren \u2014 und sie laden sich ein Backup auf ihren Laptop. Weil die Datenbank bisher nur 80 GB gro\u00df ist und auf dem Laptop Platz ist. Danach kaufen sie zus\u00e4tzliche Festplatten, um jeweils 3 Datenbanken zu haben, um verschiedene Entwicklungen durchzuf\u00fchren. So l\u00e4uft es auch manchmal. Ich habe auch gesehen, dass sie keine Angst haben, Prod in Staging zu kopieren \u2014 das h\u00e4ngt sehr stark von der Firma ab. Aber ich habe auch gesehen, dass viele sehr ver\u00e4ngstigt sind und oft die Zeit und die Ressourcen fehlen. Bevor wir jedoch zu diesem Thema \u00fcbergehen, m\u00f6chte ich mehr \u00fcber Kubernetes h\u00f6ren. Verstehe ich richtig, dass es in Produktion derzeit noch bei niemandem ist?<\/i><\/p>\n

DS<\/b>: Wir haben kleine Datenbanken in Produktion. Es geht um Volumina im Bereich von mehreren Gigabyte und um nicht kritische Dienste, f\u00fcr die es zu m\u00fchsam war, Replikate zu erstellen (au\u00dferdem besteht kein Bedarf). Und vorausgesetzt, dass es unter Kubernetes ein gutes Speichersystem gibt. Diese Datenbank lief in einer virtuellen Maschine \u2014 grob gesagt in VMware, \u00fcber SAN. Wir haben sie in PV<\/a><\/noindex> verschoben und k\u00f6nnen sie jetzt von Maschine zu Maschine transferieren.<\/p>\n

NS<\/b>: Datenbanken dieser Gr\u00f6\u00dfe, bis zu 100 GB, k\u00f6nnen auf guten Festplatten und bei gutem Netzwerk innerhalb von Minuten bereitgestellt werden, richtig? Eine Geschwindigkeit von 1 GB pro Sekunde ist schon keine Seltenheit mehr.<\/i><\/p>\n

DS<\/b>: Ja, f\u00fcr eine lineare Operation ist das kein Problem.<\/p>\n

NS<\/b>: Okay, an Prod m\u00fcssen wir nur denken. Und wenn wir Kubernetes f\u00fcr nicht-prod-Umgebungen in Betracht ziehen \u2013 wie machen wir das? Ich sehe, dass Zalando einen Operator<\/a><\/noindex>macht, bei Crunchy entwickeln sie, es gibt noch andere Optionen. Und da ist<\/a><\/noindex>OnGres \u2013 das ist unser guter Freund Alvaro aus Spanien: sie machen im Grunde nicht nur einen<\/a><\/noindex> Operator , sondern ein ganzes Distributionspaket (<\/a><\/noindex>StackGresStackGres<\/a><\/noindex>), in den wir neben dem eigentlichen Postgres auch ein Backup stecken wollten, Proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Wozu ist Envoy gut? Genau f\u00fcr die Lastverteilung des Postgres-Traffics?<\/p>\n

NS<\/b>: Ja. Sie sehen es so: Wenn man eine Linux-Distribution und den Kernel betrachtet, dann ist der normale PostgreSQL der Kernel, und sie wollen eine Distribution erstellen, die cloudfreundlich ist und in Kubernetes l\u00e4uft. Sie kombinieren Komponenten (Backups usw.) und optimieren sie, damit sie gut funktionieren.<\/i><\/p>\n

DS<\/b>: Sehr cool! Im Grunde ist das Software, um ein verwaltetes Postgres anzubieten.<\/p>\n

NS<\/b>: Linux-Distributionen haben st\u00e4ndig Probleme damit, wie man Treiber erstellt, damit die gesamte Hardware unterst\u00fctzt wird. Ihr Ansatz ist, dass sie in Kubernetes arbeiten werden. Ich wei\u00df, dass wir bei Zalando k\u00fcrzlich eine Verbindung zu AWS gesehen haben, was nicht ideal ist. Es sollte nicht von einer bestimmten Infrastruktur abh\u00e4ngen \u2014 was w\u00e4re dann der Sinn?<\/i><\/p>\n

DS<\/b>: Ich wei\u00df nicht, in welchem konkreten Fall Zalando sich zusammengeschlossen hat, aber in Kubernetes ist der Speicher derzeit so gestaltet, dass man keinen generischen Weg nutzen kann, um ein Disk-Backup zu erstellen. Vor kurzem wurde im Standard \u2014 in der neuesten Version, der CSI-Spezifikation,<\/a><\/noindex> die M\u00f6glichkeit von Snapshots integriert, aber wo ist das implementiert? Ehrlich gesagt, alles ist noch so unausgereift\u2026 Wir versuchen CSI \u00fcber AWS, GCE, Azure, vSphere, aber sobald man es zu benutzen beginnt, wird deutlich, dass es noch nicht bereit ist.<\/p>\n

NS<\/b>: Deshalb muss man manchmal auf die Infrastruktur angewiesen sein. Ich denke, wir befinden uns noch in einer fr\u00fchen Phase \u2014 das ist ein Wachstumsproblem. Frage: Was w\u00fcrdest du Neulingen empfehlen, die PgSQL in K8s ausprobieren m\u00f6chten? Welcher Operator vielleicht?<\/i><\/p>\n

DS<\/b>: Das Problem ist, dass Postgres f\u00fcr uns nur 3 % ausmacht. Wir haben eine sehr gro\u00dfe Liste von verschiedenen Softwarel\u00f6sungen in Kubernetes, ich werde gar nicht alles auflisten. Zum Beispiel Elasticsearch. Es gibt viele Operatoren: einige entwickeln sich aktiv, andere nicht. Wir haben f\u00fcr uns Anforderungen festgelegt, was in einem Operator vorhanden sein muss, damit wir ihn ernst nehmen. Bei dem Operator speziell f\u00fcr Kubernetes \u2014 nicht in einem \u201eOperator, um etwas in den Bedingungen von Amazon zu tun\u201c\u2026 Tats\u00e4chlich benutzen wir einen einzigen Operator ziemlich massenhaft (= bei fast allen Kunden), f\u00fcr Redis<\/a><\/noindex> (bald werden wir auch einen Artikel dar\u00fcber ver\u00f6ffentlichen)<\/i>.<\/p>\n

NS<\/b>: Und f\u00fcr MySQL gibt es auch keinen? Ich wei\u00df, dass Percona\u2026 da sie sich jetzt sowohl um MySQL als auch um MongoDB und Postgres k\u00fcmmern, m\u00fcssen sie irgendwie einen universellen Ansatz entwickeln: f\u00fcr alle Datenbanken und alle Cloud-Anbieter.<\/i><\/p>\n

DS<\/b>: Wir haben es nicht geschafft, die Operatoren f\u00fcr MySQL zu betrachten. Das ist im Moment nicht unser Hauptfokus. MySQL funktioniert einwandfrei im Standalone-Modus. Warum einen Operator, wenn man die DB einfach starten kann\u2026 Man kann einen Docker-Container mit PostgreSQL starten, oder man kann es einfach machen.<\/p>\n

NS<\/b>: Dar\u00fcber gab es auch eine Frage. Ganz ohne Operator?<\/i><\/p>\n

DS<\/b>: Ja, in 100 % der F\u00e4lle l\u00e4uft bei uns PostgreSQL ohne Operator. Bis jetzt so. Wir nutzen den Operator aktiv f\u00fcr Prometheus und f\u00fcr Redis. Wir haben geplant, einen Operator f\u00fcr Elasticsearch zu finden - der brennt am meisten, weil wir ihn in 100 % der F\u00e4lle in Kubernetes einsetzen m\u00f6chten. Genauso wie wir auch m\u00f6chten, dass MongoDB immer in Kubernetes installiert wird. Hier gibt es bestimmte W\u00fcnsche - es gibt das Gef\u00fchl, dass man in diesen F\u00e4llen etwas tun kann. Und bei Postgres haben wir uns noch nicht einmal umgesehen. Nat\u00fcrlich wissen wir von verschiedenen M\u00f6glichkeiten, aber faktisch haben wir Standalone.<\/p>\n

DB f\u00fcr Tests in Kubernetes<\/h2>\n

\nNS<\/b>: Lass uns zum Thema Testing \u00fcbergehen. Wie man \u00c4nderungen in der Datenbank ausrollt - aus der Sicht von DevOps. Es gibt Mikrodienste, viele Datenbanken, st\u00e4ndig \u00e4ndert sich irgendwo etwas. Wie stellt man ein ordentliches CI\/CD sicher, damit aus Sicht der DB alles in Ordnung ist. Was ist dein Ansatz?<\/i><\/p>\n

DS<\/b>: Es kann nicht die eine Antwort geben. Es gibt mehrere Parameter. Erstens ist die Gr\u00f6\u00dfe der Datenbank, die wir ausrollen m\u00f6chten. Du hast selbst erw\u00e4hnt, dass Unternehmen unterschiedlich damit umgehen, eine Kopie der Prod-Datenbank in dev und stage zu haben.<\/p>\n

NS<\/b>: Und unter den Bedingungen der GDPR, denke ich, gehen sie immer sorgf\u00e4ltiger damit um... Ich kann sagen, dass in Europa bereits mit Geldstrafen begonnen wurde.<\/i><\/p>\n

DS<\/b>: Aber oft kann man Software schreiben, die ein Dump von der Produktion erstellt und ihn obfuskiert. Es entstehen produktive Daten (Snapshot, Dump, bin\u00e4re Kopie\u2026), die anonymisiert sind. Stattdessen k\u00f6nnen es auch Generierungsskripte sein: das k\u00f6nnen Fixtures oder einfach ein Skript sein, das eine gro\u00dfe Datenbank generiert. Das Problem ist: Wie viel Zeit ben\u00f6tigt man, um das Basis-Image zu erstellen? Und wie viel Zeit braucht es, um es in der ben\u00f6tigten Umgebung bereitzustellen?<\/p>\n

Wir sind zu dem Schema gekommen: Wenn der Kunde ein Fixture-Datensatz hat (minimale Version der Datenbank), verwenden wir diese standardm\u00e4\u00dfig. Wenn es um Review-Umgebungen geht, wenn wir einen Branch erstellt haben und eine Instanz der Anwendung ausgef\u00fchrt wird - bringen wir eine kleine Datenbank dort ein. Aber das hat sich gut ergeben und Variante<\/a><\/noindex>, wenn wir einmal t\u00e4glich (nachts) einen Dump von der Produktion aufnehmen und auf dieser Basis einen Docker-Container mit PostgreSQL und MySQL erstellen, der diese geladenen Daten enth\u00e4lt. Wenn aus diesem Image die Datenbank 50 Mal bereitgestellt werden muss, geschieht dies ziemlich einfach und schnell.<\/p>\n

NS<\/b>: Einfaches Kopieren?<\/i><\/p>\n

DS<\/b>: Die Daten werden direkt im Docker-Image gespeichert. Das hei\u00dft, wir haben ein fertiges Image, sagen wir 100 GB gro\u00df. Dank der Schichten in Docker k\u00f6nnen wir dieses Image schnell die ben\u00f6tigte Anzahl von Malen bereitstellen. Die Methode ist einfach, funktioniert aber ganz gut.<\/p>\n

NS<\/b>: Weiter, wenn du testest, \u00e4ndert es sich direkt innerhalb von Docker, oder? Copy-on-Write innerhalb von Docker \u2014 wir werfen es weg und fangen neu an, alles gut. Klasse! Und du benutzt es schon voll aus?<\/i><\/p>\n

DS<\/b>: Schon lange.<\/p>\n

NS<\/b>: Wir besch\u00e4ftigen uns mit sehr \u00e4hnlichen Dingen. Nur dass wir nicht das Docker'sche Copy-on-Write verwenden, sondern eine andere L\u00f6sung.<\/i><\/p>\n

DS<\/b>: Es ist nicht generisch. Das Docker'sche funktioniert \u00fcberall.<\/p>\n

NS<\/b>: Idealerweise, ja. Aber auch wir haben dort Module, man kann verschiedene Module erstellen und mit unterschiedlichen Dateisystemen arbeiten. Hier ist der Punkt: Wir betrachten das von der PostgreSQL-Seite aus anders. Jetzt habe ich von der Docker-Seite aus geschaut und gesehen, dass bei euch alles funktioniert. Aber wenn die Datenbank riesig ist, zum Beispiel 1 TB, dann dauert das alles schon lange: sowohl die Operationen nachts als auch alles in Docker reinpacken\u2026 Und wenn ich 5 TB in Docker packen m\u00f6chte\u2026 Oder l\u00e4uft alles gut?<\/i><\/p>\n

DS<\/b>: Was macht das f\u00fcr einen Unterschied: das sind doch Blobs, einfach Bits und Bytes.<\/p>\n

NS<\/b>: Der Unterschied ist: machen Sie das \u00fcber Dump und Restore?<\/i><\/p>\n

DS<\/b>: Ganz und gar nicht notwendig. Die Methoden zur Erstellung dieses Images k\u00f6nnen unterschiedlich sein.<\/p>\n

NS<\/b>: F\u00fcr einige Kunden haben wir es so eingerichtet, dass wir anstelle der regelm\u00e4\u00dfigen Generierung eines Basis-Images dieses st\u00e4ndig aktuell halten. Es ist im Grunde eine Kopie, aber die Daten werden nicht direkt vom Master, sondern \u00fcber ein Archiv bezogen. Ein bin\u00e4res Archiv, in das die WALs jeden Tag eingespielt werden, dort werden auch Backups erstellt\u2026 Diese WALs erreichen dann mit einer kleinen Verz\u00f6gerung (buchst\u00e4blich 1-2 Sekunden) das Basis-Image. Von dort aus klonen wir auf jede erdenkliche Weise \u2014 derzeit verwenden wir standardm\u00e4\u00dfig ZFS.<\/i><\/p>\n

DS<\/b>: Aber mit ZFS sind Sie auf einen Knoten beschr\u00e4nkt.<\/p>\n

NS<\/b>: Ja. Aber ZFS hat noch etwas Zauberhaftes send<\/a><\/noindex>: damit kann man einen Snapshot schicken und sogar (ich habe das noch nicht besonders getestet, aber\u2026) man kann die Delta zwischen zwei nachsenden. PGDATA<\/code>. Tats\u00e4chlich haben wir noch ein anderes Werkzeug, das wir f\u00fcr solche Aufgaben noch nicht gro\u00dfartig in Betracht gezogen haben. In PostgreSQL gibt es pg_rewind<\/a><\/noindex>, der als \u201eintelligenter\u201c rsync fungiert und vieles \u00fcberspringt, was man sich nicht ansehen muss, weil sich daran definitiv nichts ver\u00e4ndert hat. Wir k\u00f6nnen eine schnelle Synchronisierung zwischen zwei Servern durchf\u00fchren und genau so zur\u00fcckspulen.<\/i><\/p>\n

Also, wir versuchen, von dieser eher DBA-seitigen Perspektive ein Werkzeug zu schaffen, das dasselbe erm\u00f6glicht, wor\u00fcber du gesprochen hast: Wir haben eine Datenbank, aber wir m\u00f6chten 50 Tests fast gleichzeitig durchf\u00fchren.<\/i><\/p>\n

DS<\/b>: 50 bedeutet, dass Sie 50 Spot-Instanzen bestellen m\u00fcssen.<\/p>\n

NS<\/b>: Nein, wir machen alles auf einer Maschine.<\/i><\/p>\n

DS<\/b>: Aber wie implementiert ihr das 50 Mal, wenn diese eine Datenbank, sagen wir, terabyte-gro\u00df ist? Wahrscheinlich ben\u00f6tigt sie bedingt 256 GB RAM?<\/p>\n

NS<\/b>: Ja, manchmal braucht man viel Speicher \u2013 das ist normal. Aber ein Beispiel aus dem Leben. Auf der Produktionsmaschine sind 96 Kerne und 600 GB. Dabei werden f\u00fcr die Datenbank 32 Kerne (manchmal sogar 16 Kerne heutzutage) und 100-120 GB Speicher verwendet.<\/i><\/p>\n

DS<\/b>: Passt da 50 Kopien hinein?<\/p>\n

NS<\/b>: Also, die Kopie ist eine, danach funktioniert copy-on-write (ZFS)\u2026 Ich werde mehr dar\u00fcber erz\u00e4hlen.<\/i><\/p>\n

Wir haben beispielsweise eine Datenbank mit 10 TB. Die Festplatte daf\u00fcr ist gemacht, ZFS hat ihre Gr\u00f6\u00dfe um 30-40% komprimiert. Da wir keine Lasttests durchf\u00fchren, ist uns die genaue Reaktionszeit nicht wichtig: es kann bis zu 2 Mal langsamer sein \u2013 das ist okay.<\/i><\/p>\n

Wir erm\u00f6glichen es Programmierern, QA, DBAs usw., Tests in 1-2 Streams durchzuf\u00fchren. Zum Beispiel k\u00f6nnen sie eine Migration starten. Diese ben\u00f6tigt nicht sofort 10 Kerne \u2014 sie ben\u00f6tigt 1 Backend von Postgres und 1 Kern. Die Migration wird gestartet \u2014 vielleicht, autovacuum<\/a><\/noindex> wird sie noch eine starten, dann wird der zweite Kern aktiviert. Uns stehen 16-32 Kerne zur Verf\u00fcgung, sodass 10 Personen gleichzeitig arbeiten k\u00f6nnen, es gibt keine Probleme.<\/i><\/p>\n

Da physisch PGDATA<\/code> es wird sich als identisch herausstellen, dass wir Postgres tats\u00e4chlich \u00fcberlisten. Der Trick ist folgender: Wenn beispielsweise 10 Postgres gleichzeitig gestartet werden. Was ist meistens das Problem? Man stellt ein, shared_buffers<\/a><\/noindex>, sagen wir, auf 25%. Das sind entsprechend 200 GB. Mehr als drei solcher Instanzen kann man nicht starten, da der Speicher ausgeht.<\/i><\/p>\n

Aber irgendwann haben wir realisiert, dass das nicht n\u00f6tig ist: Wir setzen shared_buffers auf 2 GB. PostgreSQL hat effective_cache_size<\/a><\/noindex>, und in der Realit\u00e4t beeinflusst nur er die Pl\u00e4ne<\/a><\/noindex>. Den setzen wir auf 0,5 TB. Und es ist nicht einmal wichtig, dass es sie tats\u00e4chlich nicht gibt: Er erstellt Pl\u00e4ne, als ob es sie gibt.<\/i><\/p>\n

Daher, wenn wir eine Migration testen, k\u00f6nnen wir alle Pl\u00e4ne sammeln \u2014 wir werden sehen, wie es in der Produktion abl\u00e4uft. Die Sekunden werden anders sein (langsamer), aber die Daten, die wir tats\u00e4chlich lesen, und die Pl\u00e4ne selbst (welche JOINs usw.) sind genau die gleichen, wie in der Produktion. Und parallel k\u00f6nnen viele solcher \u00dcberpr\u00fcfungen auf einer Maschine durchgef\u00fchrt werden.<\/i><\/p>\n

DS<\/b>: Denkst du nicht, dass es hier mehrere Probleme gibt? Erstens \u2013 das ist eine L\u00f6sung, die nur mit PostgreSQL funktioniert. Ein solcher Ansatz ist sehr speziell, nicht allgemein. Zweitens \u2013 Kubernetes (und alles, wohin die Cloud-Technologien jetzt gehen) bedeutet viele Knoten, und diese Knoten sind fl\u00fcchtig. In deinem Fall ist das jedoch ein stateful, persistenter Knoten. Diese Dinge werfen bei mir Widerspr\u00fcche auf.<\/p>\n

NS<\/b>: Erstens \u2014 ich stimme zu, das ist rein Postgres-bezogen. Ich denke, wenn wir irgendeine direkt IO und einen Pufferpool fast im gesamten Speicher haben, wird dieser Ansatz nicht funktionieren \u2014 die Pl\u00e4ne werden anders sein. Aber wir arbeiten bisher nur mit Postgres und denken nicht an andere.<\/i><\/p>\n

\u00dcber Kubernetes. Du erz\u00e4hlst doch \u00fcberall, dass unsere Datenbank persistent ist. Wenn eine Instanz ausf\u00e4llt, ist das Wichtigste, die Festplatte zu sichern. Auch unsere gesamte Plattform l\u00e4uft in Kubernetes, und die Komponente mit Postgres ist separat (obwohl sie dort eines Tages sein wird). Daher ist es so: Die Instanz ist ausgefallen, aber wir haben ihr PV gesichert und einfach an eine andere (neue) Instanz angeschlossen, als w\u00e4re nichts passiert.<\/i><\/p>\n

DS<\/b>: Aus meiner Sicht erstellen wir Pods in Kubernetes. K8s ist elastisch: Knoten werden je nach Bedarf bereitgestellt. Die Aufgabe besteht darin, einfach einen Pod zu erstellen und ihm zu sagen, dass er X Ressourcen ben\u00f6tigt, und dann k\u00fcmmert sich K8s selbst darum. Aber die Unterst\u00fctzung von Speichern in Kubernetes ist nach wie vor instabil: in 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (dieses Release wurde vor Wochen<\/i> ver\u00f6ffentlicht) sind diese Funktionen nur Beta.<\/p>\n

Nach einem halben Jahr bis zu einem Jahr wird es mehr oder weniger stabil sein, oder zumindest so deklariert. Dann l\u00f6st die M\u00f6glichkeit von Snapshots und Resizing Ihr Problem vollst\u00e4ndig. Denn Sie haben die Basis. Ja, sie mag nicht sehr schnell sein, aber die Geschwindigkeit h\u00e4ngt davon ab, was \"unter der Haube\" ist, da einige Implementierungen das Kopieren und Copy-on-Write auf der Ebene des Speicher-Subsystems beherrschen.<\/p>\n

NS<\/b>: Hier ist es auch wichtig, dass alle Engines (Amazon, Google\u2026) diese Version unterst\u00fctzen - das dauert auch eine gewisse Zeit.<\/i><\/p>\n

DS<\/b>: Momentan verwenden wir sie nicht. Wir verwenden unser eigenes.<\/p>\n

Lokale Entwicklung unter Kubernetes<\/h2>\n

\nNS<\/b>: Hast du schon einmal mit dem Wunsch zu k\u00e4mpfen gehabt, alle Pods auf einer Maschine hochzufahren und einen kleinen Test durchzuf\u00fchren? Um schnell einen Proof of Concept zu erhalten und zu sehen, dass die Anwendung in Kubernetes funktioniert, ohne daf\u00fcr eine Menge Maschinen bereitzustellen. Da gibt es Minikube, oder?<\/i><\/p>\n

DS<\/b>: Ich denke, dieser Fall \u2013 auf einem Knoten zu deployen \u2013 bezieht sich ausschlie\u00dflich auf lokale Entwicklung. Oder auf einige Manifestationen dieses Musters. Es gibt Minikube<\/a><\/noindex>, es gibt k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Wir gehen dahin, dass wir Kubernetes IN Docker verwenden werden. Wir haben jetzt angefangen, damit f\u00fcr Tests zu arbeiten.<\/p>\n

NS<\/b>: Fr\u00fcher dachte ich, dass dies der Versuch sei, alle Pods in ein einziges Docker-Image zu verpacken. Aber es stellte sich heraus, dass es um etwas ganz anderes geht. Es sind trotzdem separate Container, separate Pods \u2013 einfach in Docker.<\/i><\/p>\n

DS<\/b>: Ja. Und dort gibt es eine ziemlich am\u00fcsante Simulation, aber der Sinn ist folgender\u2026 Wir haben ein Tool f\u00fcr das Deployment \u2013 werf<\/a><\/noindex>. Wir wollen darin einen Modus einrichten \u2013 bedingt werf up<\/code>: \u201eErstelle mir ein lokales Kubernetes\u201c. Und anschlie\u00dfend soll dort ein bedingtes werf follow<\/code>. Dann kann der Entwickler in der IDE arbeiten, w\u00e4hrend im System ein Prozess l\u00e4uft, der die \u00c4nderungen sieht, die Images neu baut und sie in das lokale K8s deployt. So wollen wir versuchen, das Problem der lokalen Entwicklung zu l\u00f6sen.<\/p>\n

Snapshots und Klonen von Datenbanken in K8s<\/h2>\n

\nNS<\/b>: Wenn wir zu Copy-on-Write zur\u00fcckkehren. Mir ist aufgefallen, dass Clouds auch Snapshots haben. Sie funktionieren unterschiedlich. Zum Beispiel im GCP: Du hast an der Ostk\u00fcste der USA eine Multi-Terabyte-Instanz. Du machst regelm\u00e4\u00dfig Snapshots. Du hebst eine Kopie des Datentr\u00e4gers aus dem Snapshot an der Westk\u00fcste an \u2013 nach ein paar Minuten ist alles bereit, es funktioniert sehr schnell, nur der Cache muss im Speicher gef\u00fcllt werden. Aber diese Klone (Snapshots) sind da, um einen neuen Volume bereitzustellen. Es ist gro\u00dfartig, wenn du viele Instanzen erstellen musst.<\/i><\/p>\n

Aber f\u00fcr Tests, denke ich, erm\u00f6glichen die Snapshots, von denen du in Docker sprichst oder ich in ZFS, btrfs und sogar LVM\u2026 \u2013 es erm\u00f6glicht, auf einer Maschine keine neuen Daten zu erstellen. In der Cloud wirst du jedes Mal daf\u00fcr zahlen m\u00fcssen und warten m\u00fcssen, nicht Sekunden, sondern Minuten (und im Falle von Lazy Load<\/a><\/noindex>, m\u00f6glicherweise sogar Stunden).<\/i><\/p>\n

Anstattdessen kannst du diese Daten in ein paar Sekunden erhalten, den Test durchf\u00fchren und sie verwerfen. Diese Snapshots l\u00f6sen unterschiedliche Probleme. Im ersten Fall \u2013 um zu skalieren und neue Replikate zu erhalten, und im zweiten \u2013 f\u00fcr Tests.<\/i><\/p>\n

DS<\/b>: Ich stimme nicht zu. Eine ordnungsgem\u00e4\u00dfe Klonung von Volumes ist eine Aufgabe der Cloud. Ich habe ihre Implementierung nicht gesehen, wei\u00df aber, wie wir das auf Hardware machen. Wir haben Ceph, dort kann man jedem physischen Volume (RBD<\/a><\/noindex>) sagen clone<\/i> und innerhalb von wenigen Dutzend Millisekunden das zweite Volume mit denselben Eigenschaften, IOPS<\/a><\/noindex>und \u00e4hnlichem. Man muss verstehen, dass dort drinnen ein cleveres Copy-on-Write steckt. Warum sollte die Cloud das nicht genauso machen? Ich bin sicher, dass sie es so oder so versuchen.<\/p>\n

NS<\/b>: Aber sie ben\u00f6tigen trotzdem Sekunden, sogar Dutzende von Sekunden, um eine Instanz hochzufahren, Docker zu installieren usw.<\/i><\/p>\n

DS<\/b>: Warum muss man unbedingt eine ganze Instanz hochfahren? Wir haben doch eine Instanz mit 32 Kernen, mit 16... und in diese passen ein paar hinein \u2013 beispielsweise vier. Wenn wir die f\u00fcnfte anfordern, wird bereits eine Instanz hochgefahren, und danach wird sie wieder gel\u00f6scht.<\/p>\n

NS<\/b>: Ja, interessant, in Kubernetes sieht das anders aus. Bei uns ist die DB nicht in K8s, und es gibt nur eine Instanz. Aber die Klonung einer Multi-Terabyte-Datenbank dauert nicht l\u00e4nger als zwei Sekunden.<\/i><\/p>\n

DS<\/b>: Das ist cool. Aber mein urspr\u00fcnglicher Punkt ist, dass das keine generische L\u00f6sung ist. Ja, sie ist klasse, aber funktioniert nur mit Postgres und nur auf einem Knoten.<\/p>\n

NS<\/b>: Sie ist nicht nur f\u00fcr Postgres geeignet: Diese Pl\u00e4ne, wie ich beschrieben habe, werden nur dort so funktionieren. Aber wenn man sich nicht um die Pl\u00e4ne k\u00fcmmert und einfach alle Daten f\u00fcr Funktionstests ben\u00f6tigt, dann ist das f\u00fcr jede DBMS geeignet.<\/i><\/p>\n

DS<\/b>: Vor vielen Jahren haben wir etwas \u00c4hnliches mit LVM-Snapshots gemacht. Das ist klassisch. Dieser Ansatz wurde sehr aktiv verwendet. Stateful-Knoten sind jedoch ein Schmerz. Denn man darf sie nicht fallen lassen und muss immer an sie denken...<\/p>\n

NS<\/b>: Siehst du hier nicht eine M\u00f6glichkeit f\u00fcr einen Hybrid? Angenommen, stateful ist ein Pod, der von mehreren Personen (viele Tester) genutzt wird. Wir haben nur ein Volume, aber dank des Dateisystems sind die Klone lokal. Wenn der Pod ausf\u00e4llt, bleibt die Disk erhalten \u2013 der Pod wird wieder hochgefahren, liest die Informationen \u00fcber alle Klone und stellt alles wieder her und sagt: \u201eHier sind eure Klone auf diesen Ports, arbeitet weiter mit ihnen.\u201c<\/i><\/p>\n

DS<\/b>: Technisch bedeutet das, dass es innerhalb von Kubernetes ein Pod ist, in dem wir viele Postgres-Instanzen starten.<\/p>\n

NS<\/b>: Ja. Er hat ein Limit: Angenommen, gleichzeitig arbeiten nicht mehr als 10 Personen damit. Wenn 20 ben\u00f6tigt werden \u2013 starten wir einen zweiten solchen Pod. Es ist vollkommen m\u00f6glich, ihn zu klonen und ein zweites vollst\u00e4ndiges Volume zu erhalten, auf dem dieselben 10 \u201ed\u00fcnnen\u201c Klone sein werden. Siehst du da nicht eine M\u00f6glichkeit?<\/i><\/p>\n

DS<\/b>: Sicherheitsfragen m\u00fcssen hier hinzugef\u00fcgt werden. Diese Art der Organisation setzt voraus, dass dieser Pod hohe Privilegien (Capabilities) hat, da er nicht standardm\u00e4\u00dfige Operationen im Dateisystem ausf\u00fchren kann... Aber ich wiederhole: Ich glaube, dass Kubernetes in absehbarer Zeit den Storage reparieren wird, und in den Clouds wird die gesamte Geschichte mit den Volumes repariert \u2013 es wird einfach funktionieren. Resize, Klonen... Es gibt ein Volume \u2013 wir sagen: 'Erstelle ein neues basierend auf diesem', und nach anderthalb Sekunden haben wir das, was wir brauchen.<\/p>\n

NS<\/b>: Ich glaube nicht an anderthalb Sekunden f\u00fcr mehrere Terabyte. Mit Ceph machst du es selbst, w\u00e4hrend du von Clouds sprichst. Geh in die Cloud, mache auf EC2 ein Klon eines EBS-Volumes mit vielen Terabyte und schau dir die Leistung an. Das wird nicht einige Sekunden dauern. Ich bin wirklich gespannt, wann sie zu solch einem Wert kommen. Ich verstehe, wovon du sprichst, aber ich erlaube mir, nicht zuzustimmen.<\/i><\/p>\n

DS<\/b>: Okay, aber ich habe gesagt, dass ich von einer mittelfristigen Perspektive spreche, nicht von einer kurzfristigen. In ein paar Jahren.<\/p>\n

\u00dcber den PostgreSQL-Operator von Zalando<\/h2>\n

\nMitte dieses Treffens kam auch Alexey K\u043b\u044e\u043a\u0438\u043d, ein ehemaliger Entwickler von Zalando, dazu, der \u00fcber die Geschichte des PostgreSQL-Operators sprach:<\/p>\n

Es ist gro\u00dfartig, dass dieses Thema \u00fcberhaupt angesprochen wird: sowohl Postgres als auch Kubernetes. Als wir 2017 bei Zalando anfingen, daran zu arbeiten, war das ein Thema, mit dem alle sich besch\u00e4ftigen wollten, aber niemand machte es. Jeder hatte bereits Kubernetes, aber als gefragt wurde, wie man mit Datenbanken umgeht, sagten sogar solche Leute wie Kelsey Hightower<\/a><\/noindex>, die K8s propagierten, etwa Folgendes:<\/p>\n

\u201eGeht zu Managed-Services und nutzt sie, startet keine Datenbanken in Kubernetes. Sonst kann euer K8s zum Beispiel beschlie\u00dfen, ein Upgrade durchzuf\u00fchren, alle Knoten herunterfahren und eure Daten sind weit weg.\u201c<\/i><\/p>\n

Wir beschlossen, einen Operator zu erstellen, der entgegen diesem Rat PostgreSQL-Datenbanken in Kubernetes starten w\u00fcrde. Und wir hatten eine gute Grundlage \u2014 Patroni<\/a><\/noindex>. Dies ist ein automatischer Failover f\u00fcr PostgreSQL, der richtig umgesetzt wurde, d.h. der etcd, Consul oder ZooKeeper als Informationsspeicher f\u00fcr das Cluster verwendet. Ein solches Speicher, das allen, die fragen, z.B. wer derzeit der Leader ist, dieselbe Information liefert \u2013 egal, dass wir alles verteilt haben \u2013, um ein Split-Brain zu vermeiden. Au\u00dferdem hatten wir Docker-Image<\/a><\/noindex> nachdenken.<\/p>\n

Generell entstand der Bedarf an Auto-Failover f\u00fcr das Unternehmen nach der Migration vom internen physischen Rechenzentrum in die Cloud. Die Cloud basierte auf einer eigenen PaaS-L\u00f6sung (Platform-as-a-Service). Es war Open Source, aber um es zum Laufen zu bringen, musste man hart arbeiten. Es hie\u00df STUPS<\/a><\/noindex>.<\/p>\n

Urspr\u00fcnglich gab es kein Kubernetes. Genauer gesagt, als die eigene L\u00f6sung implementiert wurde, gab es K8s schon, aber so unausgereift, dass es f\u00fcr die Produktion nicht geeignet war. Das war, meiner Meinung nach, 2015 oder 2016. Bis 2017 wurde Kubernetes mehr oder weniger ausgereift \u2013 es entstand die Notwendigkeit, dorthin zu migrieren.<\/p>\n

Und wir hatten bereits einen Docker-Container. Es gab eine PaaS, die Docker verwendete. Warum also nicht K8s ausprobieren? Warum nicht einen eigenen Operator schreiben? Murat Kabilov, der von Avito zu uns kam, begann dies als Projekt aus eigener Initiative \u2014 \u201eein bisschen zu experimentieren\u201c \u2014 und das Projekt \u201estartete durch\u201c.<\/p>\n

Aber eigentlich wollte ich \u00fcber AWS sprechen. Warum gab es historisch gesehen Code, der mit AWS verbunden war\u2026<\/p>\n

Wenn Sie etwas in Kubernetes starten, m\u00fcssen Sie verstehen, dass K8s ein Work in Progress ist. Es entwickelt sich st\u00e4ndig weiter, verbessert sich und f\u00e4llt manchmal sogar auseinander. Man muss die Ver\u00e4nderungen in Kubernetes genau im Auge behalten und bereit sein, im Falle eines Problems tiefer einzutauchen und zu verstehen, wie es im Detail funktioniert \u2014 m\u00f6glicherweise mehr, als einem lieb ist. Das gilt grunds\u00e4tzlich f\u00fcr jede Plattform, auf der Sie Ihre Datenbanken starten\u2026<\/p>\n

Also, als wir den Operator entwickelten, hatten wir Postgres, das mit einem externen Volume (in diesem Fall EBS, da wir in AWS arbeiteten) arbeitete. Die Datenbank wuchs, und irgendwann war es notwendig, eine Gr\u00f6\u00dfen\u00e4nderung vorzunehmen: Zum Beispiel betrug die urspr\u00fcngliche Gr\u00f6\u00dfe von EBS 100 TB, die Datenbank war gewachsen, nun wollten wir EBS auf 200 TB erh\u00f6hen. Wie? Angenommen, man k\u00f6nnte einen Dump\/Restore auf eine neue Instanz machen, aber das ist zeitaufw\u00e4ndig und mit Ausfallzeiten verbunden.<\/p>\n

Deshalb wollten wir so ein Resize, das die EBS-Partition vergr\u00f6\u00dfert und dann der Dateisystem sagt, dass es den neuen Speicher verwenden soll. Und das haben wir gemacht, aber zu dieser Zeit hatte Kubernetes keinen API f\u00fcr die Resize-Operation. Da wir auf AWS arbeiteten, schrieben wir Code f\u00fcr dessen API.<\/p>\n

Niemand hindert Sie daran, dasselbe f\u00fcr andere Plattformen zu tun. Der Operator hat keine Bindung, die besagt, dass er nur auf AWS gestartet werden kann, und auf allem anderen nicht funktionieren wird. Insgesamt ist das ein Open Source-Projekt: Wenn jemand die Verwendung der neuen API beschleunigen m\u00f6chte \u2014 herzlich willkommen. Es gibt GitHub<\/a><\/noindex>, Pull-Requests \u2013 das Zalando-Team reagiert darauf ziemlich schnell und f\u00f6rdert den Operator. Soweit ich wei\u00df, hat das Projekt teilgenommen<\/a><\/noindex> an Google Summer of Code und anderen \u00e4hnlichen Initiativen. Zalando arbeitet sehr aktiv daran.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nWenn Sie sich f\u00fcr das Thema PostgreSQL und Kubernetes interessieren, beachten Sie bitte auch, dass letzte Woche der n\u00e4chste Postgres-Dienstag stattfand, bei dem Nikolai mit Alexander Kukushkin von Zalando sprach.<\/b>Das Video davon ist verf\u00fcgbar hier<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nLesen Sie auch in unserem Blog:<\/p>\n