Historisch gesehen hat sich die IT-Branche irgendwie in zwei Lager aufgeteilt: die, die "dafĂŒr" sind, und die, die "dagegen" sind. Dabei kann das Streitthema völlig willkĂŒrlich sein. Welches Betriebssystem ist besser: Win oder Linux? Auf dem Smartphone Android oder iOS? Alles in der Cloud speichern oder auf kalte RAID-Speicher hochladen und die Festplatten im Safe aufbewahren? Haben PHP-Entwickler das Recht, sich Programmierer zu nennen? Diese Streitigkeiten sind manchmal rein existenzieller Natur und basieren auf nichts anderem als sportlichem Interesse.
So kam es, dass mit dem Aufkommen von Containern und all dieser uns vertrauten Docker-KĂŒche und dem hypothetischen k8s auch die Streitigkeiten "dafĂŒr" und "dagegen" ĂŒber die Nutzung neuer Möglichkeiten in verschiedenen Bereich des Backends begannen. (Vorweg sei gesagt, dass im Folgenden Kubernetes als Orchestrator angegeben wird, wobei die Wahl dieses speziellen Werkzeugs fĂŒr das Argument keine wesentliche Bedeutung hat. Man kann stattdessen jedes andere einsetzen, das man als am bequemsten und vertrautesten empfindet.)
Und, so scheint es, wĂ€re das ein einfacher Streit zwischen zwei Seiten einer Medaille. Ebenso sinnlos und gnadenlos wie das ewige Duell Win vs Linux, in dem vernĂŒnftige Menschen irgendwo dazwischen existieren. Doch im Fall der Containerisierung ist nicht alles so einfach. Normalerweise gibt es in solchen Streitereien keine rechte Seite, aber im Fall von "Container zur Speicherung von Datenbanken verwenden" oder "nicht verwenden" wird alles auf den Kopf gestellt. Denn in gewissem Sinne haben sowohl die BefĂŒrworter als auch die Gegner eines solchen Ansatzes recht.
Die Helle Seite
Die Argumentation der Hellen Seite lĂ€sst sich mit einem Satz zusammenfassen: "Hallo, 2k19 steht vor der TĂŒr!" Das klingt zwar nach Populismus, aber wenn man die Situation genauer betrachtet, gibt es auch Vorteile. Die werden wir jetzt analysieren.
Angenommen, Sie haben ein groĂes Webprojekt. Es könnte ursprĂŒnglich auf einem mikroservicebasierten Ansatz aufgebaut worden sein oder sich zu einem bestimmten Zeitpunkt evolutionĂ€r dorthin entwickelt haben â das ist eigentlich nicht so wichtig. Sie haben Ihr Projekt in einzelne Mikrodienste aufgeteilt, die Orchestrierung, Lastverteilung und Skalierung eingerichtet. Und jetzt genieĂen Sie mit reinem Gewissen einen Mojito in einer HĂ€ngematte wĂ€hrend der Habr-Effekte, anstatt die abgestĂŒrzten Server neu zu starten. Aber in allen Handlungen muss man konsequent sein. Sehr oft wird nur die Anwendung selbst containerisiert â der Code. Und was haben wir noch auĂer dem Code?
Richtig, die Daten. Das HerzstĂŒck jedes Projekts sind seine Daten: das kann sowohl eine typische Datenbank wie MySQL, Postgre, MongoDB als auch Speicher fĂŒr Suchanfragen (ElasticSearch), key-value Speicher fĂŒr das Caching â zum Beispiel redis, usw. sein. Heute werden wir nicht ĂŒber fehlerhafte Backend-Implementierungen sprechen, bei denen die Datenbank aufgrund schlecht geschriebener Abfragen zusammenbricht, sondern darĂŒber, wie man die Ausfallsicherheit dieser Datenbank unter Clientlast gewĂ€hrleistet. Denn wenn wir unsere Anwendung containerisieren und ihr erlauben, sich ungehindert zu skalieren, um beliebig viele eingehende Anfragen zu verarbeiten, erhöht sich zwangslĂ€ufig auch die Last auf der Datenbank.
TatsĂ€chlich wird der Zugang zur Datenbank und der Server, auf dem sie lĂ€uft, zu einem Engpass in unserem schönen containerisierten Backend. Dabei ist das Hauptmotiv der Container-Virtualisierung â die Beweglichkeit und FlexibilitĂ€t der Struktur, die es ermöglicht, die Spitzenlastverteilung ĂŒber unsere gesamte verfĂŒgbare Infrastruktur so effizient wie möglich zu organisieren. Das bedeutet, dass wir, wenn wir nicht alle vorhandenen Systemelemente containerisieren und im Cluster ausrollen, einen sehr schwerwiegenden Fehler machen.
Es ist viel logischer, nicht nur die Anwendung selbst zu clustern, sondern auch die Dienste, die fĂŒr die Datenspeicherung verantwortlich sind. Bei der Clusterbildung und dem Deployment von unabhĂ€ngig arbeitenden und untereinander Last verteilen Web-Servern in k8s lösen wir bereits das Problem der Datensynchronisation â insbesondere der Kommentare zu BeitrĂ€gen, wenn wir als Beispiel ein Medium oder eine Blogplattform anfĂŒhren. In jedem Fall haben wir ein internes, wenn auch virtuelles, Datenbankdarstellung als ExternalService. Das Problem ist, dass die eigentliche Datenbank noch nicht geclustert ist â die im Cluster ausgefĂŒhrten Web-Server holen sich Informationen ĂŒber Ănderungen aus unserer statischen Produktionsdatenbank, die separat lĂ€uft.
FĂŒhlen Sie den Hinterhalt? Wir verwenden k8s oder Swarm, um die Last zu verteilen und den Ausfall des Hauptsystems zu vermeiden, Webserver., aber wir tun dies nicht fĂŒr die Datenbank. Aber wenn die Datenbank abstĂŒrzt, macht das in unserer geclusterten Infrastruktur keinen Sinn â was nutzt uns eine leere Webseite, die einen Fehler beim Datenbankzugriff zurĂŒckgibt?
Genau deshalb mĂŒssen nicht nur die Web-Server geclustert werden, wie es normalerweise der Fall ist, sondern auch die Datenbankinfrastruktur. Nur so können wir eine vollstĂ€ndig funktionsfĂ€hige Struktur im gleichen Atemzug aufbauen, die jedoch unabhĂ€ngig voneinander arbeitet. Selbst wenn die HĂ€lfte unseres Backends unter der Last âzusammenbrichtâ â der Rest ĂŒberlebt, und das System zur Datensynchronisation innerhalb des Clusters sowie die Möglichkeit der unbegrenzten Skalierung und des Deployments neuer Cluster helfen uns, schnell die benötigte KapazitĂ€t zu erreichen â sofern die Racks im Rechenzentrum vorhanden sind.
DarĂŒber hinaus ermöglicht das verteilte Datenbankmodell in Clustern, diese Datenbank dorthin zu bringen, wo sie benötigt wird; wenn wir ĂŒber einen globalen Dienst sprechen, ist es ziemlich unlogisch, einen Web-Cluster irgendwo in der NĂ€he von San Francisco zu betreiben und gleichzeitig die Pakete fĂŒr den Zugriff auf die Datenbank nach und aus dem Moskauer Gebiet zu schicken.
AuĂerdem ermöglicht die Containerisierung der Datenbank, alle Elemente des Systems auf derselben Abstraktionsebene zu konstruieren. Dies wiederum macht es möglich, dieses System direkt aus dem Code zu steuern, von den Entwicklern, ohne aktive Einbeziehung von Admins. Die Entwickler dachten, dass eine separate DBMS fĂŒr ein neues Teilprojekt erforderlich ist â kein Problem! Sie schrieben eine yaml-Datei, luden sie in den Cluster hoch, und das war's.
Und natĂŒrlich wird dadurch die interne Nutzung erheblich vereinfacht. Sagen Sie, wie oft haben Sie die Augen zusammengekniffen, als ein neues Teammitglied seine HĂ€nde in die Produktionsdatenbank gesteckt hat? Die, die Sie im Grunde genommen haben, die gerade jetzt lĂ€uft? NatĂŒrlich sind wir hier alle erwachsene Menschen, und irgendwo haben wir ein frisches Backup, und noch weiter â hinter dem Regal mit Omas Gurken und alten Skiern â ein weiteres Backup, vielleicht sogar im kalten Speicher, weil Ihr BĂŒro schon einmal gebrannt hat. Aber trotzdem, jedes EinfĂŒhren eines neuen Teammitglieds, das Zugang zur Produktionsinfrastruktur und natĂŒrlich zur Produktionsdatenbank hat â das ist ein Eimer Valium fĂŒr alle Beteiligten. Wer weiĂ, vielleicht ist der Neue ungeschickt? Erschreckend, stimmen Sie zu.
Die Containerisierung und im Grunde genommen die verteilte physische Topologie der Datenbank Ihres Projekts helfen, solche Valium-Momente zu vermeiden. Vertrauen Sie dem Neuen nicht? Gut! Wir richten ihm einen eigenen Cluster fĂŒr die Arbeit ein und trennen ihn von den anderen Datenbank-Clustern â Synchronisation nur per manuellem Push und synchronem Umlegen von zwei SchlĂŒsseln (einer fĂŒr den Teamleiter, der andere fĂŒr den Administrator). Und alle sind glĂŒcklich.
Jetzt ist es an der Zeit, sich in Gegner der DB-Clusterisierung zu verwandeln.
Die dunkle Seite
Wenn man darĂŒber nachdenkt, warum man die Datenbank nicht containerisieren sollte und sie in einer zentralen Einrichtung weiterlaufen lassen sollte, Server, wollen wir nicht in die Rhetorik der Orthodoxen und solche Aussagen abgleiten wie âDie Alten betrieben die DB auf Hardware, und wir werden es auch!â Stattdessen sollten wir versuchen, eine Situation zu erfinden, in der die Containerisierung tatsĂ€chlich spĂŒrbare Vorteile bringen wĂŒrde.
Stimmen Sie zu, dass Projekte, die wirklich eine Datenbank im Container benötigen, an einer Hand eines nicht so tollen FrĂ€sers abzĂ€hlbar sind. In den meisten FĂ€llen ist selbst die Nutzung von k8s oder Docker Swarm ĂŒbertrieben â sehr oft greifen die Leute auf diese Werkzeuge zurĂŒck, aufgrund des allgemeinen Hypes um Technologien und der Anweisung der 'Höheren', alles in Clouds und Container zu packen. Nun, weil es gerade modern ist und alle es so machen.
In mindestens der HĂ€lfte der FĂ€lle ist die Verwendung von Kubernetes oder einfach Docker im Projekt ĂŒbertrieben. Die Frage ist, dass nicht alle Teams oder Outsourcing-Unternehmen, die angeheuert wurden, um die Infrastruktur des Kunden zu betreuen, sich dessen bewusst sind. Schlimmer ist, wenn Container aufgezwungen werden, weil sie dem Kunden eine bestimmte Anzahl an MĂŒnzen kosten.
Es gibt die Meinung, dass Docker/Kubernetes-Clubs einfach die Kunden unterdrĂŒcken, die diese Infrastrukturfragen outsourcen. Um mit Clustern zu arbeiten, braucht man Ingenieure, die dazu in der Lage sind und die Architektur der implementierten Lösung verstehen. Wir haben bereits unseren Fall mit der Publikation Republic beschrieben - dort haben wir das Team des Kunden geschult, im Umfeld von Kubernetes zu arbeiten, und alle waren zufrieden. Das war fair. Oft halten »Implementierer« von k8s die Infrastruktur des Kunden als Geisel - denn jetzt verstehen nur sie, wie alles funktioniert, und auf der Kundenseite gibt es keine Fachleute.
Stellen Sie sich nun vor, dass wir nicht nur den Webserver-Teil an das Outsourcing abgeben, sondern auch die Wartung der Datenbank. Wir haben gesagt, die Datenbank ist das Herz, und der Verlust des Herzens ist fatal fĂŒr jeden lebenden Organismus. Kurz gesagt, die Aussichten sind nicht die besten. Statt des gehypten Kubernetes wĂ€re es fĂŒr viele Projekte besser, einfach nicht geizig bei einem anstĂ€ndigen Tarif bei AWS zu sein, der alle Lastprobleme ihrer Website/ihres Projekts lösen wĂŒrde. Aber AWS ist schon nicht mehr in, und Prahlerei ist teuer - leider auch in der IT-Welt.
Okay. Vielleicht braucht das Projekt wirklich eine Clusterbildung, aber wenn es bei stateless Anwendungen klar ist, wie dann eine angemessene Netzwerkverbindung fĂŒr eine clusterisierte Datenbank organisiert werden kann?
Wenn wir von einer nahtlosen Ingenieurlösung sprechen, die den Ăbergang zu k8s darstellt, ist unser gröĂtes Problem die Datenreplikation in einer clusterfĂ€higen Datenbank. Einige DBMS gehen anfangs relativ tolerant mit der Verteilung von Daten zwischen ihren einzelnen Instanzen um. Viele andere sind jedoch weniger aufgeschlossen. Und hĂ€ufig wird das Hauptargument bei der Auswahl eines DBMS fĂŒr unser Projekt nicht unbedingt die FĂ€higkeit zur Replikation mit minimalen Ressourcen- und Ingenieurausgaben sein. Besonders wenn das Projekt ursprĂŒnglich nicht als mikroskopisches Dienstsystem geplant war, sondern sich einfach in diese Richtung entwickelt hat.
Wir denken, dass man ĂŒber die Geschwindigkeit von Netzlaufwerken nicht extra sprechen muss â sie sind langsam. Das heiĂt, im Falle eines Falls haben wir keine wirkliche Möglichkeit, eine DBMS-Instanz irgendwo wiederherzustellen, wo es beispielsweise mehr Rechenleistung oder freien Arbeitsspeicher gibt. Sehr schnell stoĂen wir an die Grenzen der Leistung eines virtualisierten Datenspeichersystems. Entsprechend muss das DBMS an seiner eigenen persönlichen Maschinenkonfiguration befestigt werden, die sich in unmittelbarer NĂ€he befindet. Alternativ muss man irgendwie eine ausreichend schnelle Datensynchronisierung zu den vorgesehenen Reserven sicherstellen.
Im Fortlauf der Diskussion ĂŒber virtuelle Dateisysteme: Docker Volumes sind bedauerlicherweise nicht ohne Probleme. Im Allgemeinen möchten wir bei der langfristigen zuverlĂ€ssigen Speicherung von Daten möglichst einfache technische Systeme verwenden. Die EinfĂŒhrung einer neuen Abstraktionsebene vom Container-Dateisystem zum Dateisystem des ĂŒbergeordneten Hosts ist bereits ein Risiko an sich. Doch wenn es im Betrieb des Containerisierungs-Systems auch noch zu Schwierigkeiten mit der DatenĂŒbertragung zwischen diesen Schichten kommt, dann wird es wirklich problematisch. Derzeit scheinen die meisten bekannten Probleme, die der fortschrittlichen Menschheit bekannt sind, weitgehend beseitigt. Aber wie Sie wissen, je komplexer der Mechanismus, desto einfacher bricht er.
Angesichts all dieser "Abenteuer" ist es viel vorteilhafter und einfacher, die Datenbank an einem Ort zu behalten. Selbst wenn Sie eine Containerisierung der Anwendung benötigen, sollte sie fĂŒr sich selbst laufen und ĂŒber einen Verteilungsgateway gleichzeitig auf eine Datenbank zugreifen, die nur einmal und an einem Ort gelesen und geschrieben wird. Dieser Ansatz reduziert die Wahrscheinlichkeit von Fehlern und Desynchronisationen auf ein Minimum.
Worauf wollen wir hinaus? Auf die Tatsache, dass die Containerisierung von Datenbanken dann sinnvoll ist, wenn es einen echten Bedarf dafĂŒr gibt. Man kann eine Datenbank eines Full-Apps nicht einfach nehmen und sie so betreiben, als hĂ€tte man zwei Dutzend Mikrodienste â so funktioniert das nicht. Das muss klar verstanden werden.
Statt einer Ausgabe
Wenn Sie auf eine klare Aussage warten, ob man eine Datenbank virtualisieren sollte oder nicht, mĂŒssen wir Sie enttĂ€uschen: die wird es hier nicht geben. Denn bei der Erstellung jeder Infrastruktur muss man sich nicht von Mode und Fortschritt leiten lassen, sondern in erster Linie von gesundem Menschenverstand.
Es gibt Projekte, in denen die Prinzipien und Werkzeuge von Kubernetes perfekt funktionieren, und in solchen Projekten herrscht zumindest im Backend-Bereich Frieden. Aber es gibt Projekte, die keine Containerisierung benötigen, sondern eine normale Serverinfrastruktur, weil sie grundsÀtzlich nicht in der Lage sind, auf ein mikroskopisches Cluster-Modell umzuskalieren, da sie sonst zusammenbrechen.
Quelle: habr.com
