Leben Datenbanken in Kubernetes?

Historisch gesehen ist die IT-Industrie oft in zwei Lager gespalten: die, die "dafür" sind, und die, die "dagegen" sind. Dabei kann das Thema der Debatten völlig willkürlich sein. Welches Betriebssystem ist besser: Windows oder Linux? Sollte dein Smartphone mit Android oder iOS betrieben werden? Ist es besser, alles in der Cloud zu speichern oder auf kalte RAID-Speicher zu übertragen und die Festplatten im Safe zu lagern? Haben PHP-Entwickler das Recht, sich Programmierer zu nennen? Diese Diskussionen haben manchmal einen rein existenziellen Charakter und basieren auf nichts anderem als sportlichem Interesse.

Mit dem Aufkommen von Containern und all der uns vertrauten Technik mit Docker und dem sogenannten k8s begann auch die Debatte "dafür" und "dagegen" in verschiedenen Bereichen des Backends. (Vorweg möchten wir klarstellen, dass in dieser Diskussion meistens Kubernetes als Orchestrator erwähnt wird. Die Wahl dieses speziellen Tools ist jedoch nicht entscheidend. Stattdessen kann jedes andere Tool verwendet werden, das Ihnen als am bequemsten und vertrautesten erscheint.)

Und scheinbar wäre es nur ein einfacher Streit zwischen zwei Seiten einer Medaille. Genauso sinnlos und unerbittlich wie das ewige Duell von Win gegen Linux, in dem vernünftige Menschen irgendwo dazwischen existieren. Doch im Fall der Containerisierung ist nicht alles so einfach. In solchen Streitigkeiten gibt es normalerweise keine Gewinnerseite, aber wenn es um die Frage "Container zur Speicherung von Datenbanken verwenden oder nicht?" geht, steht alles Kopf. Denn in gewissem Sinne haben sowohl die Befürworter als auch die Gegner dieses Ansatzes recht.

Die Helle Seite

Die Argumentation der Hellen Seite lässt sich mit einem Satz zusammenfassen: „Hallo, 2019 steht vor der Tür!“ Das klingt natürlich populistisch, doch wer die Situation genauer betrachtet, findet einige Vorteile. Diese werden wir jetzt näher untersuchen.

Angenommen, Sie betreiben ein umfangreiches Webprojekt. Es könnte entweder von Anfang an auf einem Mikroservice-Ansatz basieren oder sich in einem evolutionären Prozess dorthin entwickelt haben – das ist im Grunde genommen nicht so entscheidend. Sie haben Ihr Projekt in verschiedene Mikroservices unterteilt, die Orchestrierung, Lastverteilung und Skalierung eingerichtet. Und nun genießen Sie mit reinem Gewissen einen Mojito in der Hängematte während der Habr-Effekte, anstatt abgestürzte Server hochzufahren. Doch in all Ihren Handlungen sollte Kontinuität herrschen. Häufig wird nur die Anwendung selbst – der Code – containerisiert. Was haben wir noch zusätzlich zum Code?

Richtig, die Daten. Das Herz jedes Projekts sind seine Daten: das kann sowohl eine typische Datenbank wie MySQL, PostgreSQL, MongoDB als auch Speicherlösungen für die Suche (ElasticSearch) sein, sowie Key-Value-Speicher für das Caching, wie zum Beispiel Redis, usw. Jetzt wollen wir nicht über fehlerhafte Backend-Implementierungen sprechen, bei denen die Datenbank aufgrund schlecht geschriebener Abfragen ausfällt, sondern darüber, wie wir die Ausfallsicherheit dieser Datenbank unter Kundenlast gewährleisten können. Wenn wir unsere Anwendung containerisieren und ihr erlauben, sich flexibel zu skalieren, um eine beliebige Anzahl an eingehenden Anfragen zu verarbeiten, bedeutet das zwangsläufig auch eine erhöhte Last auf der Datenbank.

Tatsächlich wird der Datenbankzugang und der Server, auf dem sie läuft, zu einem Nadelöhr in unserem erstklassigen containerisierten Backend. Der Hauptgrund für die containerisierte Virtualisierung ist die Flexibilität und Anpassungsfähigkeit der Struktur, die es ermöglicht, die Spitzenlast über unsere gesamte verfügbare Infrastruktur so effizient wie möglich zu verteilen. Wenn wir also nicht alle vorhandenen Systemelemente containerisieren und im Cluster bereitstellen, begehen wir einen sehr schwerwiegenden Fehler.

Es ist viel sinnvoller, nicht nur die Anwendung selbst zu klastern, sondern auch die Dienste, die für die Daten Speicherung zuständig sind. Bei der Clusterbildung und dem Einsatz von unabhängig arbeitenden und Lasten verteilenden Webservern in k8s lösen wir bereits das Problem der Datensynchronisation – zum Beispiel bei den Kommentaren zu Beiträgen, wenn wir an Medien oder Blogplattformen denken. In jedem Fall wird in unserem Cluster eine interne, wenn auch virtuelle, Datenbank als ExternalService eingerichtet. Das Problem ist, dass die Datenbank selbst noch nicht geklastert ist – die in dem Cluster bereitgestellten Webserver holen Informationen über Änderungen aus unserer statischen Produktionsdatenbank, die separat läuft.

Spüren Sie eine Falle? Wir nutzen k8s oder Swarm, um die Last zu verteilen und einen Ausfall der Hauptsysteme zu vermeiden, Webserver, aber wir machen das nicht für die Datenbank. Aber was nützt uns eine klusterierte Infrastruktur, wenn die Datenbank ausfällt? Dann haben wir nur leere Webseiten, die einen Fehler beim Zugriff auf die Datenbank zurückgeben.

Deshalb ist es wichtig, nicht nur die Webserver zu clusterisieren, wie es normalerweise gemacht wird, sondern auch die Datenbankinfrastruktur. Nur so können wir eine vollständig funktionierende Struktur gewährleisten, die in einer Einheit operiert, dabei aber unabhängig ist. Selbst wenn die Hälfte unseres Backends unter Last "ausfällt", bleibt der Rest funktionsfähig. Das System zur Synchronisation der Datenbanken innerhalb des Clusters und die Möglichkeit zur unbegrenzten Skalierung sowie zum schnellen Aufbau neuer Cluster ermöglichen es uns, die erforderliche Leistung schnell zu erreichen – vorausgesetzt, es stehen Racks im Rechenzentrum zur Verfügung.

Darüber hinaus erlaubt das verteilte Datenbankmodell in Clustern, die Datenbank dorthin zu bringen, wo sie gebraucht wird. Wenn wir von einem globalen Service sprechen, ist es wenig sinnvoll, einen Webcluster irgendwo in der Nähe von San Francisco zu betreiben und dabei Anfragen an die Datenbank in der Nähe von Moskau zu leiten.

Die Containerisierung von Datenbanken ermöglicht es, alle Elemente des Systems auf derselben Abstraktionsebene zu organisieren. Dies wiederum erlaubt die Verwaltung des Systems direkt durch die Entwickler aus dem Code, ohne dass aktive Eingriffe durch Administratoren erforderlich sind. Die Entwickler dachten, dass eine separate Datenbank für das neue Teilprojekt notwendig ist – kein Problem! Sie schrieben eine YAML-Datei, luden sie in den Cluster hoch, und schon war es erledigt.

Selbstverständlich vereinfacht sich auch der interne Betrieb erheblich. Sagen Sie, wie oft haben Sie die Augen zusammengekniffen, wenn ein neues Teammitglied auf die Produktionsdatenbank zugriff? Die, die Sie, faktisch, nur einmal haben und die gerade jetzt läuft? Natürlich sind wir hier alle erwachsene Menschen, und irgendwo gibt es ein frisches Backup; wenn Sie noch weiter schauen, hinter dem Regal mit den Großmutters Gurken und den alten Skiern, gibt es vielleicht noch ein weiteres Backup, möglicherweise sogar in einem kalten Speicher, weil Ihr Büro bereits einmal gebrannt hat. Dennoch ist jede Einführung eines neuen Teammitglieds, das Zugang zur Produktionsinfrastruktur und natürlich zur Produktionsdatenbank hat, ein echter Nervenkitzel für alle Beteiligten. Wer weiß schon, ob der Neue geschickt ist? Das ist verständlich, oder?

Die Containerisierung und im Grunde die verteilte physische Topologie der Datenbank Ihres Projekts helfen, derartige kritische Situationen zu vermeiden. Vertrauen Sie dem Neuling nicht? Kein Problem! Lassen Sie uns einen eigenen Cluster für seine Arbeit bereitstellen und ihn von den anderen Datenbank-Clustern trennen – die Synchronisation erfolgt nur durch manuelles Pushen und synchrones Drehen von zwei Schlüsseln (ein Schlüssel für den Teamleiter, der andere für den Administrator). Und alle sind glücklich.

Jetzt ist es an der Zeit, sich gegen die Clusterisierung von Datenbanken zu positionieren.

Die dunkle Seite

Lassen Sie uns erörtern, warum es nicht ratsam ist, die Datenbank zu containerisieren und sie weiterhin auf einem zentralen System zu betreiben. ServerWir werden uns nicht auf die Rhetorik der Orthodoxen herablassen und Aussagen wie „Früher haben die alten Hasen Datenbanken auf Hardware betrieben, und wir werden das auch tun!“ tätigen. Stattdessen lassen Sie uns versuchen, eine Situation zu finden, in der die Containerisierung tatsächlich spürbare Vorteile bringen würde.

Vereinbaren Sie, dass die Anzahl der Projekte, die wirklich eine Datenbank in einem Container benötigen, mit einer Hand abzählbar ist, selbst wenn man kein besonders geschickter Schreiner ist. In den meisten Fällen ist selbst die Nutzung von k8s oder Docker Swarm übertrieben — oft greifen Teams auf diese Werkzeuge zurück, aufgrund des allgemeinen Hypes um die Technologien und den Anweisungen der obersten Führungsetagen, alles in die Cloud und in Container zu bringen. Weil das derzeit in Mode ist und alle so handeln.

In mindestens der Hälfte der Fälle ist die Verwendung von Kubernetes oder einfach Docker in einem Projekt überflüssig. Das Problem ist, dass nicht alle Teams oder Outsourcing-Unternehmen, die damit beauftragt sind, die Infrastruktur des Kunden zu betreuen, sich dessen bewusst sind. Schlimmer noch — wenn Container aufgezwungen werden, weil dies für den Kunden in einem bestimmten Kostenrahmen erscheint.

Es gibt die allgemeine Meinung, dass Docker und die Kubernetes-Community die Kunden im Stich lassen, die ihre infrastrukturellen Fragen outsourcen. Schließlich benötigt man Ingenieure, die mit Clustern arbeiten können und die Architektur der implementierten Lösung verstehen. Wir haben bereits unseren Fall mit der Republic-Redaktion beschrieben – dort haben wir das Team des Kunden in der Kubernetes-Umgebung geschult, und alle waren zufrieden. Das war auch nötig. Oftmals nehmen "Integratoren" von k8s die Infrastruktur des Kunden als Geisel – denn nur sie verstehen, wie alles funktioniert, während es auf der Kundenseite keine Fachkräfte gibt.

Nun stellen Sie sich vor, dass wir nicht nur den Webserver-Bereich an Outsourcing abgeben, sondern auch die Wartung der Datenbanken. Wir haben gesagt, dass die Datenbank das Herz ist und der Verlust des Herzens für jeden lebenden Organismus tödlich ist. Kurz gesagt, die Aussichten sind nicht die besten. Statt des gehypten Kubernetes sollten viele Projekte einfach nicht am richtigen Tarif bei AWS sparen, der alle Probleme mit der Last auf ihrer Website oder ihrem Projekt lösen würde. Aber AWS ist nicht mehr angesagt, und der Schein kostet mehr als das Geld – leider auch in der IT-Branche.

In Ordnung. Möglicherweise ist für das Projekt tatsächlich eine Clusterbildung erforderlich. Während die Verwendung von stateless Anwendungen gut nachvollziehbar ist, stellt sich die Frage, wie man eine zuverlässige Netzwerkverbindung für eine clusterisierte Datenbank sicherstellt.

Wenn wir von einer nahtlosen Ingenieurlösung sprechen, die der Übergang zu k8s darstellt, ist unser Hauptanliegen die Datenreplikation in der clusterisierten Datenbank. Einige Datenbankmanagementsysteme sind anfangs recht kooperativ, wenn es um die Verteilung von Daten zwischen ihren Instanzen geht. Viele andere sind jedoch weniger entgegenkommend. Oft wird bei der Auswahl des Datenbankmanagementsystems für unser Projekt nicht die Fähigkeit zur Replikation mit minimalen Ressourcen- und Ingenieurausgaben zum entscheidenden Kriterium. Insbesondere wenn das Projekt nicht von Anfang an als Mikrodienst geplant war, sondern einfach in diese Richtung evolviert ist.

Wir müssen nicht groß über die Geschwindigkeit von Netzlaufwerken sprechen – sie sind langsam. Das bedeutet, dass wir im Falle eines Falles keinen echten Zugang dazu haben, die Datenbankinstanz an einem Ort mit mehr Rechenleistung oder verfügbarem Arbeitsspeicher erneut hochzufahren. Wir stoßen rasch an die Grenzen der Leistung des virtualisierten Speichersystems. Folglich muss die Datenbank an einen eigenen Satz Maschinen gebunden sein, die sich in unmittelbarer Nähe befinden. Andernfalls müssen wir eine ausreichend schnelle Datensynchronisation für die vorgesehenen Reserven einrichten.

In Fortsetzung des Themas virtuelle Dateisysteme: Docker-Volumes sind leider nicht ohne Probleme. Im Allgemeinen möchte man bei langfristiger, zuverlässiger Datenspeicherung möglichst einfache technische Lösungen verwenden. Die Einführung einer neuen Abstraktionsschicht aus dem Container-Dateisystem auf das Dateisystem des Host-Systems stellt bereits ein Risiko dar. Wenn zudem im Betriebssystem der Containerbereitstellung Schwierigkeiten mit der Datenübertragung zwischen diesen Schichten auftreten, wird die Situation noch komplizierter. Bislang scheinen die meisten bekannten Probleme, die der Menschheit bekannt sind, beseitigt zu sein. Doch wie Sie wissen, je komplexer der Mechanismus, desto einfacher ist es, dass er versagt.

Angesichts all dieser "Abenteuer" ist es viel vorteilhafter und einfacher, die Datenbank an einem Ort zu halten. Selbst wenn Sie eine Containerisierung der Anwendung benötigen, sollte sie eigenständig agieren und über ein Gateway gleichzeitig Verbindung zur Datenbank erhalten, die nur an einem Ort gelesen und geschrieben wird. Ein solcher Ansatz reduziert das Risiko von Fehlern und Synchronisationsproblemen auf ein Minimum.

Wohin wollen wir damit? Zu der Erkenntnis, dass die Containerisierung von Datenbanken nur dort sinnvoll ist, wo es auch tatsächlich notwendig ist. Man kann nicht eine vollständige Datenbank einer Anwendung in einen Container packen und erwarten, dass diese wie zwei Dutzend Mikrodienste funktioniert – so funktioniert das nicht. Das muss man klar im Kopf haben.

Stattdessen Ausgabe

Wenn Sie auf eine klare Antwort zur Frage "Sollte man Datenbanken virtualisieren oder nicht?" hoffen, müssen wir Sie enttäuschen: Die wird hier nicht gegeben. Bei der Erstellung jeder Infrastruktur sind nicht aktuelle Trends und Fortschritt entscheidend, sondern in erster Linie gesunder Menschenverstand.

Es gibt Projekte, in denen die Prinzipien und Werkzeuge, die mit Kubernetes einhergehen, perfekt passen, und in diesen Projekten herrscht zumindest im Backend-Bereich Ruhe. Aber es gibt auch Projekte, die keine Containerisierung brauchen, sondern eine stabile Serverinfrastruktur, weil sie grundsätzlich nicht auf ein mikrodienstliches, kubernetesbasiertes Modell umgeschichtet werden können, ohne dass sie ausfallen.

Quelle: habr.com