På en eller anden måde, historisk set, er it-branchen opdelt i to betingede lejre af en eller anden grund: dem, der er "for", og dem, der er "imod". Desuden kan emnet for tvister være fuldstændig vilkårligt. Hvilket OS er bedre: Win eller Linux? På en Android- eller iOS-smartphone? Skal du opbevare alt i skyerne eller lægge det på koldt RAID-lager og sætte skruerne i et pengeskab? Har PHP-folk ret til at blive kaldt programmører? Disse tvister er til tider udelukkende af eksistentiel karakter og har intet andet grundlag end sportslige interesser.
Det skete bare sådan, at med fremkomsten af containere og alt dette elskede køkken med docker og betingede k8'er, begyndte debatterne "for" og "mod" brugen af nye muligheder i forskellige områder af backend. (Lad os på forhånd tage forbehold for, at selvom Kubernetes oftest vil blive angivet som en orkestrator i denne diskussion, er valget af dette særlige værktøj ikke af grundlæggende betydning. I stedet kan du erstatte et hvilket som helst andet, der virker mest bekvemt og velkendt for dig .)
Og det ser ud til, at dette ville være en simpel tvist mellem to sider af samme mønt. Lige så meningsløs og nådesløs som den evige konfrontation mellem Win vs Linux, hvor der findes passende mennesker et sted i midten. Men i tilfælde af containerisering er alt ikke så simpelt. Normalt i sådanne tvister er der ingen højre side, men i tilfælde af "brug" eller "brug ikke" containere til lagring af databaser, vender alt på hovedet. For i en vis forstand har både tilhængere og modstandere af denne tilgang ret.
Lyse side
Lyssidens argument kan kort beskrives i én sætning: "Hej, 2k19 er uden for vinduet!" Det lyder selvfølgelig som populisme, men hvis man dykker ned i situationen i detaljer, har det sine fordele. Lad os ordne dem nu.
Lad os sige, at du har et stort webprojekt. Det kunne oprindeligt have været bygget på basis af en mikroservicetilgang, eller på et tidspunkt kom det til det gennem en evolutionær vej - det er faktisk ikke særlig vigtigt. Du spredte vores projekt i separate mikrotjenester, opsatte orkestrering, belastningsbalancering og skalering. Og nu nipper du med god samvittighed til en mojito i en hængekøje under habra-effekter i stedet for at rejse faldne servere. Men i alle handlinger skal du være konsekvent. Meget ofte er det kun selve applikationen - koden - der er containeriseret. Hvad har vi ellers udover kode?
Det er rigtigt, data. Hjertet i ethvert projekt er dets data: dette kan enten være en typisk DBMS - MySQL, Postgre, MongoDB eller lager, der bruges til søgning (ElasticSearch), nøgleværdilagring til caching - for eksempel redis osv. I øjeblikket er vi ikke vi vil tale om skæve backend-implementeringsmuligheder, når databasen går ned på grund af dårligt skrevne forespørgsler, og i stedet vil vi tale om at sikre fejltolerancen for netop denne database under klientbelastning. Når alt kommer til alt, når vi containeriserer vores applikation og tillader den frit at skalere til at behandle et vilkårligt antal indkommende anmodninger, øger dette naturligvis belastningen på databasen.
Faktisk bliver kanalen til at få adgang til databasen og serveren, den kører på, nåleøjet i vores smukke containeriserede backend. Samtidig er hovedmotivet for containervirtualisering strukturens mobilitet og fleksibilitet, hvilket giver os mulighed for at organisere fordelingen af spidsbelastninger på tværs af hele den infrastruktur, der er tilgængelig for os, så effektivt som muligt. Det vil sige, at hvis vi ikke containeriserer og udruller alle eksisterende elementer af systemet på tværs af klyngen, begår vi en meget alvorlig fejl.
Det er meget mere logisk at gruppere ikke kun selve applikationen, men også de tjenester, der er ansvarlige for lagring af data. Ved at klynge og implementere webservere, der fungerer uafhængigt og fordeler belastningen indbyrdes i k8s, løser vi allerede problemet med datasynkronisering - de samme kommentarer til indlæg, hvis vi tager nogle medie- eller blogplatforme som eksempel. Under alle omstændigheder har vi en intra-klynge, endda virtuel, repræsentation af databasen som en ekstern tjeneste. Spørgsmålet er, at selve databasen endnu ikke er klynget - de webservere, der er installeret i kuben, tager information om ændringer fra vores statiske kampdatabase, som roterer separat.
Fornemmer du en fangst? Vi bruger k8s eller Swarm til at fordele belastningen og undgå at crashe hovedwebserveren, men det gør vi ikke for databasen. Men hvis databasen går ned, så giver hele vores klyngede infrastruktur ingen mening - hvad hjælper tomme websider, der returnerer en databaseadgangsfejl?
Derfor er det nødvendigt at klynge ikke kun webservere, som man normalt gør, men også databaseinfrastrukturen. Kun på den måde kan vi sikre en struktur, der fungerer fuldt ud i ét team, men samtidig uafhængig af hinanden. Desuden, selvom halvdelen af vores backend "kollapser" under belastning, vil resten overleve, og systemet med at synkronisere databaserne med hinanden i klyngen og evnen til uendeligt at skalere og implementere nye klynger vil hjælpe med hurtigt at nå den nødvendige kapacitet - hvis bare der var stativer i datacentret.
Derudover giver databasemodellen fordelt i klynger dig mulighed for at tage netop denne database derhen, hvor den er nødvendig; Hvis vi taler om en global tjeneste, så er det ret ulogisk at spinne en web-klynge op et sted i San Francisco-området og samtidig sende pakker, når man tilgår en database i Moskva-regionen og tilbage.
Containerisering af databasen giver dig også mulighed for at bygge alle elementer i systemet på samme abstraktionsniveau. Hvilket til gengæld gør det muligt at styre netop dette system direkte fra kode, af udviklere, uden aktiv involvering af administratorer. Udviklerne mente, at der skulle et separat DBMS til det nye delprojekt - nemt! skrev en yaml-fil, uploadede den til klyngen, og du er færdig.
Og selvfølgelig er den interne drift meget forenklet. Fortæl mig, hvor mange gange har du lukket dine øjne, når et nyt teammedlem lagde hænderne ind i kampdatabasen på arbejde? Hvilken er i virkeligheden den eneste du har og snurrer lige nu? Selvfølgelig er vi alle voksne her, og et eller andet sted har vi en frisk backup, og endnu længere væk - bag hylden med bedstemors agurker og gamle ski - endnu en backup, måske endda i kølerum, for dit kontor stod allerede i brand engang. Men alligevel er hver introduktion af et nyt teammedlem med adgang til kampinfrastrukturen og selvfølgelig til kampdatabasen en spand med validol for alle omkring. Nå, hvem kender ham, en nybegynder, måske er han på kryds og tværs? Det er skræmmende, du er enig.
Containerisering og faktisk den distribuerede fysiske topologi i dit projekts database hjælper med at undgå sådanne validerende øjeblikke. Stoler du ikke på en nybegynder? OKAY! Lad os give ham sin egen klynge at arbejde med og afbryde databasen fra de andre klynger - synkronisering kun ved manuel tryk og synkron rotation af to nøgler (den ene til teamlederen, den anden til administratoren). Og alle er glade.
Og nu er det tid til at ændre sig til modstandere af databaseklynger.
Mørk side
Ved at argumentere for, hvorfor det ikke er værd at containerisere databasen og fortsætte med at køre den på én central server, vil vi ikke bøje os til retorikken om ortodoksi og udsagn som "bedstefædre kørte databaser på hardware, og det vil vi også!" Lad os i stedet prøve at komme op med en situation, hvor containerisering faktisk ville give håndgribelige udbytte.
Enig, de projekter, der virkelig har brug for en base i en container, kan tælles på fingrene af én hånd af ikke den bedste fræsemaskineoperatør. For det meste er selv brugen af k8s eller Docker Swarm i sig selv overflødig - ret ofte bliver disse værktøjer tyet til på grund af den generelle hype af teknologier og holdningerne hos den "almægtige" i personen af kønnene for at skubbe alt ind i skyer og containere. Nå, for nu er det på mode, og alle gør det.
I mindst halvdelen af tilfældene er det overflødigt at bruge Kubernetis eller blot Docker på et projekt. Problemet er, at ikke alle teams eller outsourcingvirksomheder, der er ansat til at vedligeholde kundens infrastruktur, er klar over dette. Det er værre, når der pålægges containere, fordi det koster en vis mængde mønter for kunden.
Generelt er der en opfattelse af, at docker/kubemafiaen dumt knuser kunder, der outsourcer disse infrastrukturproblemer. For at kunne arbejde med klynger har vi trods alt brug for ingeniører, der er i stand til dette og generelt forstår arkitekturen i den implementerede løsning. Vi har en gang allerede beskrevet vores sag med Republikkens publikation - der trænede vi klientens team til at arbejde i Kubernetis realiteter, og alle var tilfredse. Og det var anstændigt. Ofte tager k8s "implementere" klientens infrastruktur som gidsel - for nu forstår de kun, hvordan alt fungerer der; der er ingen specialister på klientens side.
Forestil dig nu, at vi på denne måde outsourcer ikke kun webserverdelen, men også databasevedligeholdelsen. Vi sagde, at BD er hjertet, og tabet af hjertet er dødeligt for enhver levende organisme. Kort sagt er udsigterne ikke de bedste. Så i stedet for at hype Kubernetis, burde mange projekter simpelthen ikke genere den normale takst for AWS, som vil løse alle problemer med belastningen på deres websted/projekt. Men AWS er ikke længere på mode, og show-offs er mere værd end penge – desværre også i it-miljøet.
OKAY. Måske har projektet virkelig brug for klyngedannelse, men hvis alt er klart med statsløse applikationer, hvordan kan vi så organisere en anstændig netværksforbindelse til en klynget database?
Hvis vi taler om en sømløs ingeniørløsning, som er hvad overgangen til k8s er, så er vores hovedpine datareplikering i en klynget database. Nogle DBMS'er er i starten ret loyale over for distributionen af data mellem deres individuelle instanser. Mange andre er ikke så imødekommende. Og ret ofte er hovedargumentet ved at vælge et DBMS til vores projekt ikke evnen til at replikere med minimale ressource- og ingeniøromkostninger. Især hvis projektet ikke oprindeligt var planlagt som en mikroservice, men blot udviklede sig i denne retning.
Vi mener, at der ikke er behov for at tale om hastigheden på netværksdrev – de er langsomme. De der. Vi har stadig ikke en reel mulighed for, hvis der sker noget, at genstarte en DBMS-instans et sted, hvor der er mere, for eksempel processorkraft eller ledig RAM. Vi vil meget hurtigt løbe ind i ydeevnen af det virtualiserede diskundersystem. Derfor skal DBMS'et sømmes til sit eget personlige sæt af maskiner placeret i umiddelbar nærhed. Eller det er nødvendigt på en eller anden måde separat at nedkøle tilstrækkelig hurtig datasynkronisering til de formodede reserver.
Fortsætter emnet virtuelle filsystemer: Docker-volumener er desværre ikke problemfrie. Generelt vil jeg i sådan en sag som langsigtet pålidelig datalagring nøjes med de mest teknisk simple ordninger. Og det er en risiko i sig selv at tilføje et nyt abstraktionslag fra containerens FS til FS for forældreværten. Men når driften af containeriseringsstøttesystemet også støder på vanskeligheder med at overføre data mellem disse lag, så er det virkelig en katastrofe. I øjeblikket ser de fleste af de problemer, den progressive menneskehed kender til, ud til at være udryddet. Men du forstår, jo mere kompleks mekanismen er, jo lettere går den i stykker.
I lyset af alle disse "eventyr" er det meget mere rentabelt og nemmere at holde databasen ét sted, og selvom du har brug for at containerisere applikationen, så lad den køre på egen hånd og gennem distributions-gatewayen modtage samtidig kommunikation med database, som kun læses og skrives én gang og på ét sted. Denne tilgang reducerer sandsynligheden for fejl og desynkronisering til et minimum.
Hvad fører vi til? Desuden er databasecontainerisering passende, hvor der er et reelt behov for det. Du kan ikke fylde en fuld-app-database og dreje den, som om du havde to dusin mikrotjenester - sådan fungerer det ikke. Og dette skal forstås klart.
I stedet for output
Hvis du venter på en klar konklusion "at virtualisere databasen eller ej", så vil vi skuffe dig: den vil ikke være her. For når man skaber en hvilken som helst infrastrukturløsning, skal man ikke være styret af mode og fremskridt, men først og fremmest af sund fornuft.
Der er projekter, hvor de principper og værktøjer, der følger med Kubernetis, passer perfekt, og i sådanne projekter er der fred i det mindste i backend-området. Og der er projekter, der ikke har brug for containerisering, men en normal serverinfrastruktur, fordi de grundlæggende ikke kan omskalere til mikroserviceklyngemodellen, fordi de vil falde.
Kilde: www.habr.com