Historisk set har IT-industrien delt sig i to lejre: dem, der er 'for', og dem, der er 'imod'. Emnet for debatten kan være helt vilkårligt. Hvilket operativsystem er bedst: Windows eller Linux? Skal man have en smartphone med Android eller iOS? Skal man gemme alt i skyen eller lagre på kolde RAID-opbevaringsenheder og lægge harddiskene i et pengeskab? Har PHP-udviklere ret til at kalde sig programmører? Disse diskussioner er til tider udelukkende eksistentielle og mangler enhver anden, bortset fra en sportlig interesse, base.
Det er sket, at med fremkomsten af containere og al den elskede teknologi omkring Docker og Kubernetes, er debatter om 'for' og 'imod' brugen af nye muligheder i forskellige områder af backend begyndt. (På forhånd skal det siges, at selvom Kubernetes oftest nævnes som orkestrator, har valget af netop dette værktøj ikke principiel betydning. Man kan i stedet indsætte ethvert andet, man finder mest praktisk og velkendt.)
Og det ville umiddelbart være en simpel debat mellem to sider af samme mønt. Ligeså meningsløs og nådesløs som det evige opgør mellem Windows og Linux, hvor der findes fornuftige mennesker et sted imellem. Men i tilfælde af containerisering er det ikke så enkelt. I sådanne diskussioner er der normalt ikke en 'rigtig' side, men når det kommer til at 'anvende' eller 'ikke anvende' containere til lagring af databaser, bliver det hele vendt på hovedet. For i en vis forstand har både fortalere og modstandere af denne tilgang ret.
Den Lyse Side
Man kan kort beskrive argumentationen for Den Lyse Side med én sætning: “Hej, 2019 står lige udenfor!” Det lyder som populisme, uden tvivl, men hvis man dykker ned i situationen, er der fordele ved det. Dem skal vi nu se nærmere på.
Antag at du har et stort webprojekt. Det kan være bygget på en mikrotjeneste-tilgang fra starten, eller det kan være kommet til det evolutionært på et tidspunkt — det er faktisk ikke så vigtigt. Du har opdelt dit projekt i separate mikrotjenester, konfigureret orkestrering, belastningsbalancering og skalerbarhed. Og nu nyder du med god samvittighed en mojito i hængekøjen under besøget af habra-effekter i stedet for at skulle genstarte nedfaldne servere. Men i alle handlinger er det vigtigt at være konsekvent. Meget ofte containeriseres kun selve applikationen — koden. Og hvad har vi ellers udover koden?
Rigtigt, data. Hjertet i ethvert projekt er dets data: det kan være en typisk DBMS — MySQL, Postgre, MongoDB, såvel som lagringsløsninger, der bruges til søgning (ElasticSearch), key-value lagringsløsninger til caching — for eksempel Redis, og så videre. Nu vil vi ikke tale om de skæve implementeringsmuligheder for backend, hvor databasen fejler på grund af dårligt skrevne forespørgsler, men i stedet tale om, hvordan man sikrer, at denne database er fejltolerant under klientbelastning. For når vi containeriserer vores applikation og tillader den at skalere frit for at håndtere et vilkårligt antal indgående forespørgsler, øger det også belastningen på databasen.
Faktisk bliver adgangen til databasen og serveren, på hvilken den kører, en flaskehals i vores skønne containeriserede backend. Den primære motivation for container-virtualisering er mobilitet og fleksibilitet i strukturen, der giver mulighed for at organisere fordelingen af peakbelastningen på tværs af al den tilgængelige infrastruktur så effektivt som muligt. Det vil sige, hvis vi ikke containeriserer og implementerer alle systemelementerne i klusteret — så laver vi en meget alvorlig fejl.
Det er langt mere logisk at klargøre ikke kun applikationen, men også de tjenester, der står for dataopbevaring, i et cluster. Når vi klargør og implementerer uafhængigt fungerende og belastningsfordelende webservere i k8s, løser vi allerede synkroniseringsproblemet med data — for eksempel kommentarer til indlæg, hvis vi tager et medie eller blogplatform som eksempel. Vi opretter under alle omstændigheder en intern-klynge, selvom det kun er en virtuel, præsentation af databasen som ExternalService. Spørgsmålet er, at databasen endnu ikke er klargjort — de udrulende webservere i klyngen henter oplysninger om ændringer fra vores statiske produktionsdatabase, der kører separat.
Fornemmer du en fælde? Vi bruger k8s eller Swarm til at fordele belastningen og undgå nedbrud af hovedsystemet, webserver, men vi gør ikke det samme for databasen. Men hvis databasen går ned, har hele vores klusterinfrastruktur ikke mening — hvad nytter det os med tomme websteder, der returnerer en fejl ved adgang til databasen?
Derfor skal vi klargøre ikke kun webservere, som det normalt gøres, men også databaseinfrastrukturen. Kun på den måde kan vi sikre en fuldt fungerende struktur, der er uafhængig af hinanden men stadig arbejder sammen. Selv hvis halvdelen af vores backend 'faller' under belastning, vil den resterende overleve, og systemet til synkronisering af databaserne i klyngen sammen med muligheden for uendelig skalering og oprettelse af nye klynger vil hjælpe os med hurtig adgang til nødvendige ressourcer — hvis der blot er plads i datacentret.
Desuden gør den distribuerede klynge-database model det muligt at flytte denne database dertil, hvor den er nødvendig; hvis vi taler om en global service, så er det ret ulogisk at køre webklyngen et sted i San Francisco og samtidig sende pakker frem og tilbage til databasen i Moskva.
Containerisering af databasen muliggør, at alle systemelementer kan placeres på et ensartet abstraktionsniveau. Dette gør det muligt at administrere systemet direkte fra koden af udviklerne, uden aktiv involvering af administratorer. Udviklerne tænkte, at der var behov for en separat database til et nyt projekt — det er nemt! De skrev en yaml-fil, uploadede den til klyngen, og så var det klart.
Og selvfølgelig gør intern driftsbrug det meget lettere. Sig mig, hvor mange gange har du lukket øjnene, når et nyt teammedlem stak hænderne ind i den aktive database? Den, som I i virkeligheden kun har én af, og som kører lige nu? Selvfølgelig er vi alle voksne mennesker her, og vi har et friskt backup et sted, og endnu længere bag hylden med bedstemorens syltede agurker og gamle ski - en anden backup, måske endda på kold opbevaring, fordi dit kontor brændte engang. Men alligevel, hver gang et nyt teammedlem får adgang til den aktive infrastruktur og selvfølgelig den aktive database – det er en spand validol for alle omkring. Hvem kender ham, den nyankomne, måske er han klodsede? Skræmmende, ikke sandt?
Containerisering og i bund og grund den distribuerede fysiske topologi af databasen i dit projekt hjælper med at undgå sådanne validol-momenter. Stoler du ikke på nybegynderen? Okay! Lad os oprette en egen klynge til ham at arbejde i og frakoble fra de andre databaser – synkronisering kun ved manuel push og synkron drejning af to nøgler (en til teamlederen, den anden til administratoren). Og så er alle glade.
Og nu er det tid til at skifte kurs og gå imod databaseklyngning.
Den Mørke Side
Overvej, hvorfor man ikke bør containerisere databasen og fortsætte med at køre den på en central serveren, lad os ikke falde ned på retorik fra ortodokserne og udsagn som "de gamle kørte databaser på hardware, og vi skal også!" I stedet lad os prøve at finde en situation, hvor containerisering faktisk ville give mærkbare fordele.
Enig, projekter, der virkelig har brug for en database i en container, kan tælles på fingrene af én hånd af en ikke alt for dygtig fræser. I de fleste tilfælde er endda brugen af k8s eller Docker Swarm overflødig – det er ret ofte, at man griber til disse værktøjer på grund af den generelle hype omkring teknologierne og påbuddene fra "høje“ ledere om at få alt ind i skyen og i containere. Fordi det er trendy nu, og alle gør det.
I mange tilfælde er brugen af Kubernetes eller blot Docker i et projekt overflødig. Problemet er, at ikke alle teams eller outsourcing-virksomheder, der er ansat til at håndtere kundens infrastruktur, er klar over dette. Det bliver værre, når containere påtvinges, fordi det koster kunden et bestemt beløb.
Generelt er der en opfattelse af, at Docker/kube-mafiaen simpelthen underkaster sig kunderne, der outsourcer disse infrastrukturelle spørgsmål. For at arbejde med klynger er der behov for ingeniører, som kan dette og forstår selve arkitekturen af den implementerede løsning. Vi har allerede beskrevet vores case med udgivelsen af Republic — der trænede vi kundeteamet i at arbejde i Kubernetes, og alle var tilfredse. Og det var en ordentlig indsats. Ofte tager de, der implementerer k8s, kundens infrastruktur som gidsel — for kun de forstår, hvordan det hele fungerer, da der ingen specialister er på kundens side.
Forestil dig nu, at vi ikke kun overlader webserverdelen til outsourcing, men også vedligeholdelsen af databasen. Vi sagde, at databasen er hjertet, og at tab af hjertet er fatal for enhver levende organisme. Med andre ord, fremtidsudsigterne er ikke de bedste. Så i stedet for det hypede Kubernetes ville mange projekter nyde godt af at investere i en rimelig plan på AWS, som ville løse alle problemer med belastningen på deres hjemmeside/projekt. Men AWS er allerede ikke in, og status symboliserer mere end penge — desværre gælder det også i IT-miljøet.
Okay. Måske er klyngeteknologi faktisk nødvendig for projektet, men hvis det er klart med stateless-applikationer, hvordan skal man så organisere en ordentlig netværksforbindelse til en klyngedatabase?
Når vi taler om den sømløse ingeniørløsning, som overgangen til k8s repræsenterer, er vores største hovedpine datarapplikation i en klyngede database. Nogle databasesystemer har fra starten været ret tolerante over for datafordeling mellem deres forskellige instanser. Mange andre er dog ikke så venlige. Og ofte bliver den primære faktor i valget af databasesystem til vores projekt ikke evnen til at replikere med minimale ressourcer og ingeniøromkostninger. Især hvis projektet oprindeligt ikke var planlagt som en mikrotjeneste, men blot har udviklet sig i den retning.
Vi mener, at det ikke er nødvendigt at tale om hastigheden af netværksdrev — de er langsomme. Det vil sige, vi har stadig ikke en reel mulighed for hurtigt at genoprette en instans af databasen et sted, hvor der er mere processorstyrke eller gratis RAM. Vi vil hurtigt støde ind i begrænsningerne af det virtualiserede disk-system. Derfor skal databasen være knyttet til sit eget personlige sæt af maskiner, som befinder sig i umiddelbar nærhed. Alternativt skal vi finde en måde at implementere en hurtig datasyngronisering til de planlagte reserver.
I forlængelse af emnet om virtuelle filsystemer: Docker-volumes er desværre ikke problemfri. Generelt set ville vi i et projekt som langtidssikret datalagring helst arbejde med så enkelt teknisk opbygning som muligt. At tilføje et nyt abstractionslag fra containerens filsystem til værtsmaskinens filsystem er allerede i sig selv en risiko. Men når der også opstår problemer i containeriseringssystemets drift med at overføre data mellem disse lag, så er det virkelig problematisk. Indtil videre synes størstedelen af de problemer, som menneskeheden kender, at være udbedret. Men som du ved, jo mere komplekst mekanismen er, desto lettere går den i stykker.
I lyset af alle disse "eventyr" er det meget mere fordelagtigt og enklere at holde databasen ét sted, og selv hvis du har brug for at containerisere applikationen – lad den køre for sig selv og få simultan forbindelse til databasen gennem en distributionsgateway, som kun vil blive læst og skrevet ét sted. Denne tilgang reducerer risikoen for fejl og desynkroniseringer til et minimum.
Hvor vil vi hen med dette? Det er vigtigt at forstå, at containerisering af databasen kun er relevant, når der er en reel nødvendighed for det. Man kan ikke tage en fuld applikationsdatabase og køre den, som om man havde et dusin mikrotjenester – det fungerer simpelthen ikke. Dette skal være helt klart.
I stedet for output
Hvis du venter på et klart svar om "at virtualisere databasen eller ej", så må vi skuffe dig: der vil ikke være et. Fordi, når man skaber enhver infrastrukturløsning, skal man ikke følge modet og teknologiske fremskridt, men i stedet forholde sig til sund fornuft.
Der findes projekter, hvor principperne og værktøjerne fra Kubernetes passer perfekt, og i sådanne projekter opnås der ofte harmoni, åtminstone i backend-området. Men der er også projekter, som har brug for en normal serverinfrastruktur snarere end containerisering, fordi de principielt ikke kan skaleres til en mikrotjeneste- eller cluster-model, da de vil kollapse.
Kilde: habr.com
