Liewen Datenbanken zu Kubernetes?

Iergendwéi, historesch, ass d'IT Industrie aus irgend engem Grond an zwee bedingte Lageren opgedeelt: déi, déi "fir" sinn an déi, déi "géint" sinn. Ausserdeem, kann d'Thema vun Sträitfäll komplett arbiträr ginn. Wéi eng OS ass besser: Win oder Linux? Op engem Android oder iOS Smartphone? Sollt Dir alles an de Wolleken späicheren oder et op kale RAID-Späichere setzen an d'Schrauwen an eng Safe setzen? Hutt PHP Leit d'Recht Programméierer genannt ze ginn? Dës Sträitfäll sinn, heiansdo, exklusiv existenziell an der Natur an hu keng Basis aner wéi sportlechen Interessi.

Et ass just geschitt, datt mat dem Optrëtt vun Container an all dës beléifte Kichen mat Docker a bedingte K8s, d'Debatten "fir" a "géint" d'Benotzung vun neie Fäegkeeten a verschiddene Beräicher vum Backend ugefaang hunn. (Loosst eis am Viraus reservéieren, datt och wann de Kubernetes an dëser Diskussioun meeschtens als Orchestrator bezeechent gëtt, de Choix vun dësem speziellen Tool net vu fundamentaler Wichtegkeet ass. Amplaz kënnt Dir all aner ersetzen, deen Iech am meeschte bequem a vertraut schéngt. .)

An, et géif schéngen, dëst wier en einfachen Sträit tëscht zwou Säiten vun der selwechter Mënz. Esou sënnlos a barmhäerzlech wéi déi éiweg Konfrontatioun tëscht Win vs Linux, an där adäquate Leit iergendwou an der Mëtt existéieren. Awer am Fall vun der Containeriséierung ass net alles sou einfach. Normalerweis an esou Streidereien gëtt et keng riets Säit, mä am Fall vun "benotzen" oder "net benotzen" Behälter fir Datenbanken ze späicheren, gëtt alles op d'Kopp. Well an engem gewësse Sënn hunn d'Supporter an d'Géigner vun dëser Approche Recht.

Schéin Säit

D'Argument vun der Light Side kann kuerz an engem Saz beschriwwe ginn: "Hallo, 2k19 ass baussent der Fënster!" Et kléngt selbstverständlech no Populismus, mee wann een sech am Detail an d’Situatioun verdaut, huet dat seng Virdeeler. Loosst eis se elo sortéieren.

Loosst eis soen datt Dir e grousse Webprojet hutt. Et kéint am Ufank op der Basis vun enger Mikroservice Approche gebaut ginn, oder iergendwann ass et duerch en evolutive Wee komm - dat ass net ganz wichteg, tatsächlech. Dir hutt eise Projet a getrennte Mikroservicer verspreet, Orchester opgestallt, Belaaschtung a Skaléieren. An elo, mat engem kloere Gewësse, schëpft Dir e Mojito an enger Hängematt während Habra Effekter amplaz vun gefall Serveren ze erhéijen. Awer an all Aktiounen musst Dir konsequent sinn. Ganz dacks ass nëmmen d'Applikatioun selwer - de Code - containeriséiert. Wat soss hu mir ausser Code?

Dat ass richteg, daten. D'Häerz vun all Projet ass seng Donnéeën: dëst kann entweder eng typesch DBMS sinn - MySQL, Postgre, MongoDB, oder Späichere benotzt fir d'Sich (ElasticSearch), Schlësselwäertspäichere fir Caching - zum Beispill Redis, etc. Am Moment si mir net mir wäerten iwwer crooked Backend Ëmsetzung Optiounen schwätzen wann d'Datebank Crash wéinst schlecht schrëftlech Ufroen, an amplaz wäerte mir schwätzen iwwer d'Feeler Toleranz vun dëser ganz Datebank ënner Client Laascht ze garantéieren. No allem, wa mir eis Applikatioun containeriséieren an et erlaben fräi ze skaléieren fir all Zuel vun erakommen Ufroen ze veraarbechten, erhéicht dëst natierlech d'Laascht op der Datebank.

Tatsächlech ass de Kanal fir Zougang zu der Datebank an dem Server op deem se leeft, d'Ae vun der Nadel an eisem schéine containeriséierte Backend. Zur selwechter Zäit ass d'Haaptmotiv vun der Containervirtualiséierung d'Mobilitéit an d'Flexibilitéit vun der Struktur, wat eis erlaabt d'Verdeelung vun de Spëtzelastungen iwwer déi ganz Infrastruktur, déi eis verfügbar ass, esou effizient wéi méiglech ze organiséieren. Dat ass, wa mir all existent Elementer vum System iwwer de Cluster net containeriséieren an ausrollen, maache mir e ganz eeschte Feeler.

Et ass vill méi logesch net nëmmen d'Applikatioun selwer ze clusteren, awer och d'Servicer déi verantwortlech sinn fir d'Daten ze späicheren. Andeems Dir Webserveren clusteren an ofsetzen, déi onofhängeg funktionnéieren an d'Laascht ënner sech an k8s verdeelen, léise mir schonn de Problem vun der Datesynchroniséierung - déiselwecht Kommentaren op Posts, wa mir e puer Medien oder Blogplattform als Beispill huelen. Op alle Fall hu mir en Intra-Cluster, souguer virtuell, Representatioun vun der Datebank als ExternalService. D'Fro ass datt d'Datebank selwer nach net clusteréiert ass - d'Webserver, déi am Wierfel ofgebaut ginn, huelen Informatioun iwwer Ännerungen aus eiser statescher Kampfdatenbank, déi separat rotéiert.

Hues du e Fang? Mir benotze k8s oder Swarm fir d'Laascht ze verdeelen an ze verhënneren, datt den Haaptserver ofstürzt. Webserver, awer mir maachen dat net fir d'Datebank. Mee wann d'Datebank ofstürzt, dann ass eis ganz geclustert Infrastruktur nëtzlos - wat bréngt et, wann eidel Websäiten Datebankzougangsfehler zréckginn?

Dofir ass et néideg net nëmme Webserver ze clusteren, wéi et normalerweis gemaach gëtt, awer och d'Datebankinfrastruktur. Nëmmen esou kënne mir eng Struktur garantéieren, déi voll an engem Team funktionéiert, awer gläichzäiteg onofhängeg vuneneen. Ausserdeem, och wann d'Halschent vun eisem Backend ënner Laascht "zesummebrach" wäert de Rescht iwwerliewen, an de System fir d'Datebanken mateneen am Cluster ze synchroniséieren an d'Fäegkeet fir endlos ze skaléieren an nei Cluster z'installéieren hëlleft séier déi erfuerderlech Kapazitéit z'erreechen - wann et nëmmen Racken am Rechenzentrum wieren.

Zousätzlech erlaabt d'Datebankmodell, déi a Cluster verdeelt gëtt, Iech dës ganz Datebank ze huelen wou se gebraucht gëtt; Wa mir vun engem globalen Service schwätzen, dann ass et ganz onlogesch e Webcluster iergendwou an der San Francisco Regioun ze spinnen a gläichzäiteg Päckchen ze schécken wann Dir op eng Datebank an der Moskau Regioun an zréck kënnt.

Och Containeriséierung vun der Datebank erlaabt Iech all Elementer vum System um selwechten Abstraktiounsniveau ze bauen. Wat, am Tour, mécht et méiglech dëse System direkt aus Code ze verwalten, vun Entwéckler, ouni aktiv Bedeelegung vun Administrateuren. D'Entwéckler hunn geduecht datt eng separat DBMS fir den neien Ënnerprojet gebraucht gëtt - einfach! geschriwwen eng Yaml Datei, eropgelueden an de Stärekoup an Dir sidd fäerdeg.

An natierlech, intern Operatioun ass vill vereinfacht. Sot mir, wéi oft hutt Dir Är Aen zougemaach wann en neien Teammember seng Hänn an d'Kampfdatenbank fir Aarbecht gesat huet? Wat ass tatsächlech deen eenzegen deen Dir hutt a dréint elo? Natierlech si mir hei all Erwuessener, an iergendwou hu mir e frësche Backup, an nach méi wäit ewech - hannert dem Regal mat der Bomi Gurken an al Schier - en anere Backup, vläicht souguer an der Kältelagerung, well Äre Büro schonn eemol a Brand war. Awer nach ëmmer, all Aféierung vun engem neie Teammember mat Zougang zu der Kampfinfrastruktur an natierlech op d'Kampfdatenbank ass en Eemer vu Validol fir jiddereen ronderëm. Gutt, wien kennt hien, en Newbie, vläicht ass hien iwwerrascht? Et ass grujeleg, Dir wäert averstanen.

Containeriséierung an tatsächlech déi verdeelt kierperlech Topologie vun der Datebank vun Ärem Projet hëlleft esou validéierend Momenter ze vermeiden. Vertrau net engem Newbie? OK! Loosst eis him säin eegene Cluster ginn fir mat ze schaffen an d'Datebank vun den anere Cluster ze trennen - Synchroniséierung nëmmen duerch manuell Push a Synchron-Rotatioun vun zwee Schlësselen (eent fir d'Teamführung, déi aner fir den Admin). A jiddereen ass frou.

An elo ass et Zäit fir Géigner vum Datebankclustering z'änneren.

Däischter Säit

Wann ee bedenkt, firwat et sech net lount, d'Datebank an engem Container ze konteneréieren an se weider op enger zentraler Plaz ze bedreiwen ServerLoosst eis net op orthodox Rhetorik a Aussoen ewéi "Eis Grousspappen hunn Datenbanken op Hardware gebaut, a mir och!" zréckgräifen, loosst eis amplaz probéieren, eis eng Situatioun virzestellen, an där Containeriséierung tatsächlech konkret Virdeeler bréngt.

Averstanen, d'Projeten, déi wierklech eng Basis an engem Container brauchen, kënnen op d'Fangere vun enger Hand gezielt ginn vun net dee beschten Milling Machine Bedreiwer. Fir de gréissten Deel ass och d'Benotzung vu k8s oder Docker Swarm selwer iwwerflësseg - zimlech dacks ginn dës Tools benotzt wéinst dem allgemengen Hype vun Technologien an den Attitudë vum "Allmächtege" an der Persoun vun de Geschlechter fir alles an d'Drénken ze drécken. Wolleken a Container. Gutt, well elo ass et moudesch a jiddereen mécht et.

Op d'mannst d'Halschent vun de Fäll ass d'Benotzung vu Kubernetis oder just Docker op engem Projet iwwerflësseg. D'Fro ass datt net all Teams oder Outsourcingfirmen, déi agestallt gi fir d'Infrastruktur vum Client z'erhalen, dëst bewosst sinn. Et ass méi schlëmm wann d'Container imposéiert sinn, well et de Client eng gewësse Quantitéit u Mënzen kascht.

Am Allgemengen gëtt et d'Meenung datt d'Docker / Cube Mafia domm Clienten zerstéiert déi dës Infrastruktur Themen outsourcen. No allem, fir mat Cluster ze schaffen, brauche mir Ingenieuren, déi dozou fäeg sinn an allgemeng d'Architektur vun der ëmgesater Léisung verstoen. Mir hunn eng Kéier schonn eise Fall mat der Republik Publikatioun beschriwwen - do hu mir d'Team vum Client trainéiert fir an de Realitéite vu Kubernetis ze schaffen, a jiddereen war zefridden. An et war anstänneg. Oft huelen k8s "Implementer" d'Infrastruktur vum Client als Geisel - well se elo nëmme verstinn wéi alles do funktionnéiert; et gi keng Spezialisten op der Säit vum Client.

Stellt Iech elo vir, datt mir op dës Manéier net nëmmen de Webserverdeel outsourcen, awer och d'Datebankhaltung. Mir hu gesot datt BD d'Häerz ass, an de Verloscht vum Häerz ass fatal fir all liewegen Organismus. Kuerz gesot, d'Perspektiven sinn net déi bescht. Also, amplaz vum Hype Kubernetis, sollten vill Projeten einfach net mam normalen Tarif fir AWS stéieren, wat all d'Problemer mat der Laascht op hirem Site / Projet léisen. Awer AWS ass net méi moudesch, a Show-offs si méi wäert wéi Suen - leider och am IT Ëmfeld.

OK. Vläicht brauch de Projet wierklech Clustering, awer wann alles kloer ass mat stateless Uwendungen, wéi kënne mir dann anstänneg Netzwierkverbindung fir eng clustered Datebank organiséieren?

Wa mir vun enger nahtloser Ingenieursléisung schwätzen, dat ass wat den Iwwergang op k8s ass, dann ass eisen Haapt Kappwéi Datereplikatioun an enger clusteréierter Datebank. E puer DBMSs sinn am Ufank zimlech trei zu der Verdeelung vun Daten tëscht hiren individuellen Instanzen. Vill anerer sinn net sou begréissend. An zimlech dacks ass d'Haaptargument bei der Auswiel vun engem DBMS fir eise Projet net d'Fäegkeet ze replizéieren mat minimale Ressourcen an Ingenieurskäschte. Besonnesch wann de Projet am Ufank net als Mikrodéngscht geplangt war, mee einfach an dës Richtung evoluéiert ass.

Mir mengen datt et net néideg ass iwwer d'Geschwindegkeet vun de Netzwierkfuerer ze schwätzen - si si lues. Déi. Mir hunn nach keng richteg Geleeënheet, wann eppes geschitt, eng DBMS Instanz iergendwou ze Restart wou et méi ass, Zum Beispill, Prozessor Muecht oder fräi RAM. Mir wäerte ganz séier an d'Leeschtung vum virtualiséierte Disk Subsystem lafen. Deementspriechend muss den DBMS op säin eegene perséinleche Set vu Maschinnen, déi an der Noperschaft läit, nagelt ginn. Oder et ass néideg iergendwéi getrennt genuch séier Datensynchroniséierung fir déi vermeintlech Reserven ofzekillen.

D'Thema vu virtuelle Dateiesystemer weiderféieren: Docker Volumen, leider, sinn net problemfräi. Am Allgemengen, an esou enger Saach wéi laangfristeg zouverlässeg Datelagerung, géif ech gär mat den technesch einfachste Schemaen maachen. An eng nei Abstraktiounsschicht vun der FS vum Container un den FS vum Elterendeel ze addéieren ass e Risiko u sech. Awer wann d'Operatioun vum Containeriséierungs-Ënnerstëtzungssystem och Schwieregkeete mat der Iwwerdroung vun Daten tëscht dëse Schichten begéint, dann ass et wierklech eng Katastroph. Am Moment schéngen déi meescht vun de Probleemer, déi der progressiver Mënschheet bekannt sinn, geläscht ze sinn. Awer Dir verstitt, wat de Mechanismus méi komplex ass, wat et méi einfach brécht.

Am Liicht vun all dësen "Abenteuer" ass et vill méi rentabel a méi einfach d'Datebank op enger Plaz ze halen, an och wann Dir d'Applikatioun muss containeriséieren, loosst se eleng lafen an duerch d'Verdeelungspaart kréien gläichzäiteg Kommunikatioun mat der Datebank, déi nëmmen eemol an Op enger Plaz gelies a geschriwwe gëtt. Dës Approche reduzéiert d'Wahrscheinlechkeet vu Feeler an Desynchroniséierung op e Minimum.

Wat féieren mir zu? Ausserdeem ass d'Datebank Containeriséierung passend wou et e reelle Bedierfnes dofir ass. Dir kënnt net eng voll-App-Datebank ausfëllen an et spin wéi wann Dir zwee Dutzend Mikroservicer hätt - et funktionnéiert net sou. An dat muss kloer verstane ginn.

Amplaz Ausgang

Wann Dir op eng kloer Conclusioun waart "d'Datebank ze virtualiséieren oder net", da wäerte mir Iech enttäuschen: et wäert net hei sinn. Well bei der Schafung vun enger Infrastrukturléisung muss een net vu Moud a Fortschrëtt guidéiert ginn, mä virun allem vum gesonde Mënscheverstand.

Et gi Projete fir déi d'Prinzipien an Tools, déi mat Kubernetis kommen, perfekt passen, an an esou Projeten gëtt et op d'mannst am Backend-Beräich Fridden. An et gi Projeten déi keng Containeriséierung brauchen, mee eng normal Serverinfrastruktur, well se grondsätzlech net op de Mikroservice-Cluster-Modell ëmskaléieren, well se falen.

Source: will.com