Historisch gesehen ist die IT-Branche aus irgendeinem Grund in zwei bedingte Lager gespalten: diejenigen, die „dafür“ sind, und diejenigen, die „dagegen“ sind. Darüber hinaus kann der Gegenstand von Streitigkeiten völlig willkürlich sein. Welches Betriebssystem ist besser: Win oder Linux? Auf einem Android- oder iOS-Smartphone? Sollten Sie alles in den Clouds aufbewahren oder es auf einen kalten RAID-Speicher legen und die Schrauben in einem Safe aufbewahren? Haben PHP-Leute das Recht, Programmierer genannt zu werden? Diese Streitigkeiten sind teilweise ausschließlich existenzieller Natur und haben keine andere Grundlage als das sportliche Interesse.
Zufällig begannen mit dem Aufkommen von Containern und all dieser beliebten Küche mit Docker und bedingten K8s die Debatten „für“ und „gegen“ den Einsatz neuer Funktionen in verschiedenen Bereichen des Backends. (Beachten wir im Voraus, dass Kubernetes in dieser Diskussion zwar am häufigsten als Orchestrator genannt wird, die Wahl dieses speziellen Tools jedoch nicht von grundlegender Bedeutung ist. Stattdessen können Sie es durch jedes andere ersetzen, das Ihnen am bequemsten und vertrautesten erscheint.) .)
Und es scheint, dass dies ein einfacher Streit zwischen zwei Seiten derselben Medaille wäre. So sinnlos und gnadenlos wie die ewige Konfrontation zwischen Win vs. Linux, in der irgendwo in der Mitte adäquate Leute existieren. Doch bei der Containerisierung ist nicht alles so einfach. Normalerweise gibt es in solchen Streitigkeiten keine rechte Seite, aber im Fall der „Nutzung“ oder „Nicht-Nutzung“ von Containern zur Speicherung von Datenbanken stellt sich alles auf den Kopf. Denn in gewissem Sinne haben sowohl Befürworter als auch Gegner dieses Ansatzes recht.
Angenehme Seite
Das Argument der Lichtseite kann kurz in einem Satz beschrieben werden: „Hallo, 2k19 ist außerhalb des Fensters!“ Das klingt natürlich nach Populismus, aber wenn man sich die Situation genauer ansieht, hat es seine Vorteile. Lassen Sie uns sie jetzt klären.
Nehmen wir an, Sie haben ein großes Webprojekt. Es könnte ursprünglich auf der Grundlage eines Microservice-Ansatzes aufgebaut worden sein oder irgendwann über einen evolutionären Weg dazu gekommen sein – das ist in der Tat nicht sehr wichtig. Sie haben unser Projekt in separate Microservices aufgeteilt, Orchestrierung, Lastausgleich und Skalierung eingerichtet. Und jetzt schlürft man guten Gewissens während der Habra-Effekte einen Mojito in der Hängematte, anstatt gefallene Kellner aufzurichten. Aber bei allen Handlungen müssen Sie konsequent sein. Sehr oft wird nur die Anwendung selbst – der Code – in Containern gespeichert. Was haben wir außer Code noch?
Genau, Daten. Das Herzstück eines jeden Projekts sind seine Daten: Dies kann entweder ein typisches DBMS sein – MySQL, Postgre, MongoDB, oder Speicher für die Suche (ElasticSearch), Schlüsselwertspeicher für das Caching – zum Beispiel Redis usw. Derzeit ist dies nicht der Fall Wir werden über fehlerhafte Backend-Implementierungsoptionen sprechen, wenn die Datenbank aufgrund schlecht geschriebener Abfragen abstürzt, und stattdessen über die Sicherstellung der Fehlertoleranz genau dieser Datenbank unter Client-Last. Denn wenn wir unsere Anwendung in Container umwandeln und sie frei skalieren lassen, um eine beliebige Anzahl eingehender Anfragen zu verarbeiten, erhöht dies natürlich die Belastung der Datenbank.
Tatsächlich werden der Kanal für den Zugriff auf die Datenbank und der Server, auf dem sie läuft, zum Nadelöhr in unserem schönen Container-Backend. Gleichzeitig ist das Hauptmotiv der Containervirtualisierung die Mobilität und Flexibilität der Struktur, die es uns ermöglicht, die Verteilung von Spitzenlasten auf die gesamte uns zur Verfügung stehende Infrastruktur möglichst effizient zu organisieren. Das heißt, wenn wir nicht alle vorhandenen Elemente des Systems im gesamten Cluster containerisieren und ausrollen, machen wir einen sehr schwerwiegenden Fehler.
Viel logischer ist es, nicht nur die Anwendung selbst, sondern auch die für die Datenspeicherung verantwortlichen Dienste zu gruppieren. Durch die Clusterung und Bereitstellung von Webservern, die unabhängig voneinander arbeiten und die Last in k8s untereinander verteilen, lösen wir bereits das Problem der Datensynchronisierung – die gleichen Kommentare zu Beiträgen, wenn wir als Beispiel eine Medien- oder Blog-Plattform nehmen. In jedem Fall haben wir eine Cluster-interne, sogar virtuelle Darstellung der Datenbank als ExternalService. Die Frage ist, dass die Datenbank selbst noch nicht geclustert ist – die im Cube bereitgestellten Webserver beziehen Informationen über Änderungen aus unserer statischen Kampfdatenbank, die separat rotiert.
Spüren Sie einen Haken? Wir verwenden k8s oder Swarm, um die Last zu verteilen und einen Absturz des Hauptwebservers zu vermeiden, tun dies jedoch nicht für die Datenbank. Aber wenn die Datenbank abstürzt, macht unsere gesamte Cluster-Infrastruktur keinen Sinn – was nützen leere Webseiten, die einen Datenbankzugriffsfehler zurückgeben?
Deshalb ist es notwendig, nicht nur, wie üblich, Webserver zu Clustern, sondern auch die Datenbankinfrastruktur. Nur so können wir eine Struktur gewährleisten, die vollständig im Team funktioniert, aber gleichzeitig unabhängig voneinander ist. Selbst wenn die Hälfte unseres Backends unter Last „zusammenbricht“, bleibt der Rest bestehen, und das System zur Synchronisierung der Datenbanken untereinander innerhalb des Clusters und die Möglichkeit, neue Cluster endlos zu skalieren und bereitzustellen, werden dazu beitragen, die erforderliche Kapazität schnell zu erreichen – Wenn es nur Racks im Rechenzentrum gäbe.
Darüber hinaus ermöglicht Ihnen das in Clustern verteilte Datenbankmodell, genau diese Datenbank dorthin zu bringen, wo sie benötigt wird; Wenn es sich um einen globalen Dienst handelt, ist es völlig unlogisch, irgendwo im Raum San Francisco einen Webcluster aufzubauen und gleichzeitig Pakete beim Zugriff auf eine Datenbank in die Region Moskau und zurück zu senden.
Außerdem ermöglicht Ihnen die Containerisierung der Datenbank, alle Elemente des Systems auf derselben Abstraktionsebene aufzubauen. Dies wiederum ermöglicht es, genau dieses System direkt aus dem Code heraus durch Entwickler zu verwalten, ohne die aktive Beteiligung von Administratoren. Die Entwickler dachten, dass für das neue Teilprojekt ein separates DBMS nötig sei – ganz einfach! Ich habe eine Yaml-Datei geschrieben, sie in den Cluster hochgeladen und fertig.
Und natürlich wird die interne Bedienung erheblich vereinfacht. Erzählen Sie mir, wie oft haben Sie schon die Augen geschlossen, als ein neues Teammitglied zur Arbeit seine Hände in die Kampfdatenbank steckte? Welches ist eigentlich das einzige, das Sie haben und das sich gerade dreht? Natürlich sind wir hier alle Erwachsene, und irgendwo haben wir einen frischen Ersatz, und noch weiter weg – hinter dem Regal mit Omas Gurken und alten Skiern – einen weiteren Ersatz, vielleicht sogar im Kühlhaus, weil Ihr Büro schon einmal gebrannt hat. Aber trotzdem ist jede Einführung eines neuen Teammitglieds mit Zugriff auf die Kampfinfrastruktur und natürlich auf die Kampfdatenbank ein Eimer voller Validol für alle um uns herum. Nun, wer kennt ihn, einen Neuling, vielleicht ist er im Kreuzfeuer? Es ist beängstigend, da werden Sie mir zustimmen.
Die Containerisierung und tatsächlich die verteilte physische Topologie der Datenbank Ihres Projekts tragen dazu bei, solche validierenden Momente zu vermeiden. Einem Neuling nicht trauen? OK! Geben wir ihm seinen eigenen Cluster, mit dem er arbeiten kann, und trennen wir die Datenbank von den anderen Clustern – Synchronisierung nur durch manuellen Push und synchrone Rotation zweier Schlüssel (einer für den Teamleiter, der andere für den Administrator). Und alle sind glücklich.
Und jetzt ist es an der Zeit, zum Gegner des Datenbank-Clusterings zu werden.
Die dunkle Seite
Bei der Argumentation, warum es sich nicht lohnt, die Datenbank zu containerisieren und weiterhin auf einem zentralen Server laufen zu lassen, werden wir uns nicht auf die Rhetorik von Orthodoxien und Aussagen wie „Großväter haben Datenbanken auf Hardware betrieben, und wir auch!“ verlassen. Versuchen wir stattdessen, eine Situation zu schaffen, in der sich die Containerisierung tatsächlich spürbar auszahlt.
Stimmen Sie zu, die Projekte, die wirklich eine Basis in einem Behälter benötigen, können von nicht dem besten Fräsmaschinenbediener an einer Hand abgezählt werden. In den meisten Fällen ist sogar die Verwendung von k8s oder Docker Swarm selbst überflüssig – aufgrund des allgemeinen Hypes um Technologien und der Einstellung des „Allmächtigen“ in der Person der Geschlechter wird häufig auf diese Tools zurückgegriffen, um alles in den Griff zu bekommen Wolken und Container. Nun, weil es mittlerweile in Mode ist und jeder es tut.
In mindestens der Hälfte der Fälle ist die Verwendung von Kubernetis oder nur Docker für ein Projekt überflüssig. Das Problem besteht darin, dass nicht alle Teams oder Outsourcing-Unternehmen, die mit der Wartung der Infrastruktur des Kunden beauftragt sind, sich dessen bewusst sind. Noch schlimmer ist es, wenn Container auferlegt werden, da dies für den Kunden eine bestimmte Menge Münzen kostet.
Im Allgemeinen besteht die Meinung, dass die Docker-/Cube-Mafia dummerweise Kunden vernichtet, die diese Infrastrukturprobleme auslagern. Denn um mit Clustern arbeiten zu können, brauchen wir Ingenieure, die dazu in der Lage sind und die Architektur der implementierten Lösung grundsätzlich verstehen. Wir haben unseren Fall bereits einmal mit der Republic-Publikation beschrieben – dort haben wir das Team des Kunden darin geschult, in den Realitäten von Kubernetis zu arbeiten, und alle waren zufrieden. Und es war anständig. Oftmals nehmen k8s-„Implementierer“ die Infrastruktur des Kunden als Geisel – denn jetzt verstehen nur sie, wie dort alles funktioniert; es gibt keine Spezialisten auf Kundenseite.
Stellen Sie sich nun vor, dass wir auf diese Weise nicht nur den Webserver-Teil, sondern auch die Datenbankwartung auslagern. Wir sagten, BD sei das Herz und der Verlust des Herzens sei für jeden lebenden Organismus tödlich. Kurzum: Die Aussichten sind nicht die besten. Anstatt also Kubernetis zu hypen, sollten sich viele Projekte einfach nicht mit dem normalen Tarif für AWS herumschlagen, der alle Probleme mit der Auslastung ihrer Site/ihres Projekts löst. Aber AWS ist nicht mehr in Mode und Angeber sind mehr wert als Geld – leider auch im IT-Umfeld.
OK. Vielleicht braucht das Projekt wirklich Clustering, aber wenn bei zustandslosen Anwendungen alles klar ist, wie können wir dann eine anständige Netzwerkkonnektivität für eine Cluster-Datenbank organisieren?
Wenn wir über eine nahtlose Engineering-Lösung sprechen, was der Übergang zu k8s bedeutet, dann ist unser größtes Problem die Datenreplikation in einer Cluster-Datenbank. Einige DBMS halten sich zunächst recht loyal an die Verteilung der Daten zwischen ihren einzelnen Instanzen. Viele andere sind nicht so einladend. Und oft ist das Hauptargument bei der Auswahl eines DBMS für unser Projekt nicht die Fähigkeit zur Replikation mit minimalen Ressourcen- und Engineering-Kosten. Vor allem, wenn das Projekt zunächst nicht als Microservice geplant war, sondern sich einfach in diese Richtung weiterentwickelte.
Über die Geschwindigkeit von Netzlaufwerken muss unserer Meinung nach nicht gesprochen werden – sie sind langsam. Diese. Wir haben immer noch keine wirkliche Möglichkeit, eine DBMS-Instanz irgendwo neu zu starten, wenn etwas passiert, wo mehr, zum Beispiel Prozessorleistung oder freier RAM, vorhanden ist. Wir werden uns sehr schnell mit der Leistung des virtualisierten Festplattensubsystems befassen. Dementsprechend muss das DBMS an seinen eigenen persönlichen Maschinensatz in unmittelbarer Nähe angeschlossen sein. Oder es ist notwendig, die ausreichend schnelle Datensynchronisation für die vermeintlichen Reserven irgendwie separat abzukühlen.
Fortsetzung des Themas virtuelle Dateisysteme: Docker-Volumes sind leider nicht problemlos. Generell möchte ich bei einer langfristig zuverlässigen Datenspeicherung mit den technisch einfachsten Schemata auskommen. Und das Hinzufügen einer neuen Abstraktionsschicht vom FS des Containers zum FS des übergeordneten Hosts ist an sich schon ein Risiko. Aber wenn beim Betrieb des Containerisierungsunterstützungssystems auch Schwierigkeiten bei der Datenübertragung zwischen diesen Schichten auftreten, dann ist das wirklich eine Katastrophe. Im Moment scheinen die meisten Probleme, die der fortschrittlichen Menschheit bekannt sind, beseitigt zu sein. Aber Sie verstehen: Je komplexer der Mechanismus, desto leichter geht er kaputt.
Angesichts all dieser „Abenteuer“ ist es viel rentabler und einfacher, die Datenbank an einem Ort aufzubewahren, und selbst wenn Sie die Anwendung in einen Container umwandeln müssen, lassen Sie sie eigenständig laufen und erhalten Sie über das Verteilungsgateway gleichzeitige Kommunikation mit der Anwendung Datenbank, die nur einmal und an einem Ort gelesen und geschrieben wird. Dieser Ansatz reduziert die Wahrscheinlichkeit von Fehlern und Desynchronisation auf ein Minimum.
Wohin führen wir? Darüber hinaus ist die Containerisierung von Datenbanken dort sinnvoll, wo ein echter Bedarf besteht. Sie können nicht eine vollständige App-Datenbank vollstopfen und sie so drehen, als hätten Sie zwei Dutzend Microservices – so funktioniert das nicht. Und das muss klar verstanden werden.
Anstatt der Ausgabe
Wenn Sie auf eine klare Schlussfolgerung warten, ob die Datenbank virtualisiert werden soll oder nicht, werden wir Sie enttäuschen: Sie wird hier nicht verfügbar sein. Denn bei der Schaffung einer Infrastrukturlösung muss man sich nicht von Mode und Fortschritt leiten lassen, sondern vor allem vom gesunden Menschenverstand.
Es gibt Projekte, für die die Prinzipien und Tools, die Kubernetis mit sich bringt, perfekt passen, und in solchen Projekten herrscht zumindest im Backend-Bereich Ruhe. Und es gibt Projekte, die keine Containerisierung, sondern eine normale Server-Infrastruktur benötigen, weil sie grundsätzlich nicht auf das Microservice-Cluster-Modell umskalieren können, weil sie scheitern.
Source: habr.com