Historiskt sett har IT-industrin delat sig i tvÄ lÀger: de som Àr 'för' och de som Àr 'emot'. DiskussionsÀmnena kan vara helt godtyckliga. Vilket operativsystem Àr bÀttre: Win eller Linux? Android eller iOS pÄ smartphones? Ska man spara allt i molnet eller anvÀnda kalla RAID-lagringar och förvara hÄrddiskarna i ett valv? Har PHP-utvecklare rÀtt att kalla sig programmerare? Dessa diskussioner har, ibland, en rent existentiell karaktÀr och saknar annan, mer substantiell grund Àn en idrottslig intresse.
Det har blivit sÄ att med framvÀxten av containrar och hela vÄr Àlskade docker- och k8s-miljö har debatten 'för' och 'emot' nya möjligheter i olika delar av backenden inletts. (Vi förbereder oss för att i denna diskussion kommer Kubernetes att nÀmnas som orkestrator, men valet av just detta verktyg har ingen avgörande betydelse. Du kan anvÀnda vilket annat verktyg du tycker kÀnns mest bekvÀmt och vanligt.)
Och, det kan tyckas, skulle detta vara en enkel diskussion mellan tvÄ sidor av samma mynt. Lika meningslös och skoningslös som den stÀndiga kampen mellan Win och Linux, dÀr rationella mÀnniskor befinner sig nÄgonstans i mitten. Men i fallet med containerisering Àr det inte sÄ enkelt. Vanligtvis finns det ingen rÀtt sida i sÄdana diskussioner, men nÀr det gÀller 'att anvÀnda' eller 'inte anvÀnda' containrar för lagring av databaser blir allting upp och ner. För pÄ ett visst sÀtt har bÄde föresprÄkarna och motstÄndarna av denna metod rÀtt.
Den Ljusare Sidan
Att kortfattat beskriva argumentationen för Den Ljusare Sidan kan göras med en fras: 'HallÄ, 2k19 Àr utanför fönstret!' Det lÄter som populism, utan tvekan, men vid en noggrannare granskning finns det sina fördelar. Och dem ska vi nu reda ut.
Anta att du har ett stort webbprojekt. Det kan ha byggts pĂ„ en mikrotjĂ€nstbaserad metod frĂ„n början, eller sĂ„ har det utvecklats till detta steg â vilket Ă€r mindre viktigt i sjĂ€lva verket. Du har fördelat ditt projekt pĂ„ separata mikrotjĂ€nster, konfigurerat orkestrering, lastbalansering och skalning. Och nu njuter du utan bekymmer av en mojito i en hĂ€ngmatta under hĂ€ndelserna pĂ„ Habr, istĂ€llet för att behöva Ă„terstĂ€lla nerlagda servrar. Men i alla Ă„tgĂ€rder Ă€r det viktigt att vara konsekvent. Oftast containeriseras bara sjĂ€lva applikationen â koden. Men vad har vi mer förutom koden?
RĂ€tt, data. HjĂ€rtat i varje projekt Ă€r dess data: det kan vara en typisk databas â MySQL, PostgreSQL, MongoDB, eller lagringslösningar som anvĂ€nds för sökning (ElasticSearch), nyckel-vĂ€rde-lagring för cachning â till exempel Redis, osv. Vi kommer inte att diskutera knasiga implementeringslösningar för backend, dĂ€r databasen kraschar pĂ„ grund av dĂ„ligt skrivna förfrĂ„gningar, utan istĂ€llet prata om att sĂ€kerstĂ€lla att denna databas Ă€r felfri under kundbelastning. NĂ€r vi containeriserar vĂ„r applikation och lĂ„ter den skala fritt för att hantera valfritt antal inkommande förfrĂ„gningar, ökar det naturligt nog Ă€ven belastningen pĂ„ databasen.
Faktiskt blir kanalen till databasen och servern den körs pĂ„ en flaskhals i vĂ„r vackra containeriserade backend. Huvudmotivationen för container-virtualisering Ă€r rörlighet och flexibilitet i strukturen, vilket gör att vi kan organisera fördelningen av spikbelastning över hela vĂ„r tillgĂ€ngliga infrastruktur sĂ„ effektivt som möjligt. Om vi inte containeriserar och distribuerar alla systemelement över klustret â gör vi ett mycket allvarligt misstag.
Det Ă€r mycket mer logiskt att klustrera inte bara sjĂ€lva applikationen, utan Ă€ven tjĂ€nsterna som ansvarar för datalagring. NĂ€r vi klustrar och distribuerar fritt fungerande webbservrar i k8s, löser vi redan problemet med datasykronisering â som till exempel kommentarerna till inlĂ€gg, om vi tar nĂ„got mediaföretag eller bloggplattform som exempel. Vi fĂ„r alltid en intern klusterrepresentation av databasen, Ă€ven om den Ă€r virtuell, som ett ExternalService. FrĂ„gan Ă€r dock att sjĂ€lva databasen inte Ă€r klustrerad Ă€n â de distribuerade webbservrarna hĂ€mtar information om Ă€ndringar frĂ„n vĂ„r statiska produktionsdatabas som körs separat.
KĂ€nner du att det finns en fĂ€lla? Vi anvĂ€nder k8s eller Swarm för att fördela belastningen och undvika att huvudsystemet faller ihop, webbservern, men vi gör inte detta för databaser. Men om databasen kraschar, sĂ„ har hela vĂ„r klustrerade infrastruktur ingen mening â vad hjĂ€lper oss tomma webbsidor som returnerar ett databasĂ„tkomstfel?
Det Ă€r dĂ€rför man inte bara bör klustra webbservrarna, vilket vanligtvis görs, utan Ă€ven databasens infrastruktur. Endast pĂ„ detta sĂ€tt kan vi sĂ€kerstĂ€lla att vi har en fullt fungerande, men oberoende struktur i samma system. Ăven om halva vĂ„r backend skulle "kollapsa" under belastning â skulle den andra hĂ€lften överleva, och systemet för databassynkronisering inom klustret, samt möjligheten till oĂ€ndlig skalning och distribution av nya kluster, skulle hjĂ€lpa oss att snabbt nĂ„ de nödvĂ€ndiga resurserna â förutsatt att det finns rack i datacentret.
Dessutom möjliggör en distribuerad klustermodell för databasen att flytta denna databas dit den behövs; om vi pratar om en global tjÀnst, Àr det ganska ologiskt att köra webbklustret i nÀrheten av San Francisco och samtidigt skicka paket till och frÄn databasen i Moskva-regionen.
Containerisering av databasen gör det ocksĂ„ möjligt att bygga alla systemkomponenter pĂ„ samma abstraktionsnivĂ„. Detta i sin tur gör det möjligt att hantera just detta system direkt frĂ„n koden av utvecklarna, utan aktivt engagemang av administratörer. Utvecklarna tĂ€nkte att de behövde en separat DBMS för det nya delprojektet â inga problem! De skrev en yaml-fil, laddade upp den i klustret och var klara.
SjĂ€lvklart förenklas den interna driften avsevĂ€rt. SĂ€g mig, hur mĂ„nga gĂ„nger har du blundat nĂ€r en ny teammedlem har strĂ€ckt sig in i produktionsdatabasen? Den som ni faktiskt har, och som just nu Ă€r i drift? SjĂ€lvklart Ă€r vi vuxna hĂ€r, och vi har förmodligen en ny backup nĂ„gonstans, och lĂ€ngre in â bakom hyllan med mormor's pickles och gamla skidor â finns det kanske en till backup, kanske till och med pĂ„ kall lagring, eftersom ert kontor brann ner en gĂ„ng. Men trots allt, varje gĂ„ng en ny teammedlem fĂ„r tillgĂ„ng till produktionsinfrastrukturen och, sĂ„klart, till produktionsdatabasen â det Ă€r som en hink med valerian för alla kring er. Vem vet, kanske Ă€r den dĂ€r nykomlingen klumpig? SkrĂ€mmande, eller hur?
Containerisering och, i grund och botten, den distribuerade fysiska topologin av databasen i ert projekt hjĂ€lper till att undvika sĂ„dana valerianmoment. Litar du inte pĂ„ nykomlingen? Okej! Vi skapar en egen kluster för honom att arbeta med och kopplar bort den frĂ„n de andra databasen kluster â synkronisering sker endast via manuell push och synkron vridning av tvĂ„ nycklar (en till teamledaren, den andra till administratören). Och alla Ă€r glada.
Och nu Àr det dags att byta om till motstÄndare till databascluster.
Den Mörka Sidan
Resonerar varför man inte ska containerisera databasen och fortsÀtta köra den pÄ en central servern, ska vi inte sjunka till retoriken hos ortodoxerna och pÄstÄenden som "farfar körde databaser pÄ hÄrdvara, och vi ska göra det ocksÄ!" IstÀllet lÄt oss försöka förestÀlla oss en situation dÀr containerisering verkligen skulle ge betydande vinster.
HĂ„ll med om, projekten som verkligen behöver en databas i en container kan rĂ€knas pĂ„ ena handen av en medelmĂ„ttig frĂ€schare. I de flesta fall Ă€r till och med anvĂ€ndningen av k8s eller Docker Swarm överflödig â ganska ofta vĂ€nder man sig till dessa verktyg pĂ„ grund av den allmĂ€nna hype kring teknologier och instĂ€llningar frĂ„n "högre makter" i form av chefer som pressar att fĂ„ allt i molnet och i containrar. Eftersom det nu Ă€r trendigt och alla gör sĂ„.
I de flesta fallen Àr anvÀndningen av Kubernetes eller helt enkelt Docker i projekt överflödig. FrÄgan Àr att inte alla team eller outsourcingföretag som anstÀlls för att underhÄlla kundens infrastruktur inser detta. Det Àr Ànnu vÀrre nÀr containerlösningar pÄtvingas, eftersom det kostar ett visst antal mynt för kunden.
Generellt rĂ„der det en uppfattning om att Docker/kuber-maffian helt enkelt underkuvar kunder som outsourcar dessa infrastrukturella frĂ„gor. För att arbeta med kluster behövs ingenjörer som kan detta och förstĂ„r den implementerade lösningens arkitektur. Vi har redan beskrivit vĂ„rt fall med utgivningen av Republic â dĂ€r vi utbildade kundens team att arbeta i Kubernetes-realiteter och alla var nöjda. Och det var Ă€rligt talat en bra sak. Oftast tar "implementatörerna" av K8s kundens infrastruktur som gisslan â eftersom det nu bara Ă€r de som förstĂ„r hur allt fungerar, och pĂ„ kundens sida finns det inga specialister.
Och nu, förestĂ€ll dig att vi dĂ€rigenom inte bara överlĂ€mnar webbserverdelen till outsourcing, utan ocksĂ„ underhĂ„llet av databasen. Vi har pratat om att databasen Ă€r hjĂ€rtat, och att förlusten av hjĂ€rtat Ă€r dödlig för varje levande organism. För att sammanfatta, utsikterna ser inte sĂ„ bra ut. SĂ„ istĂ€llet för den hype-kuberetet skulle mĂ„nga projekt helt enkelt kunna avstĂ„ frĂ„n att snĂ„la pĂ„ ett rimligt pris pĂ„ AWS, som skulle lösa alla problem med belastningen pĂ„ deras webbplats/projekt. Men AWS Ă€r inte lĂ€ngre trendigt, och att skryta kostar mer Ă€n pengar â tyvĂ€rr, Ă€ven inom IT-branschen.
Okej. Kanske behövs klustring för projektet, men om det Àr klart med stateless-applikationer, hur organiserar man dÄ en ordentlig nÀtverksanslutning för den klustrade databasen?
NÀr vi talar om en sömlös ingenjörslösning, som övergÄngen till k8s, Àr vÄr största huvudvÀrk replikering av data i en klustrerad databas. Vissa databashanteringssystem Àr frÄn början ganska tillmötesgÄende nÀr det gÀller datadistribution mellan sina egna instanser. MÄnga andra Àr betydligt mindre vÀnliga. Och ganska ofta blir huvudargumentet för valet av databashanteringssystem för vÄrt projekt inte nödvÀndigtvis förmÄgan att replikera med minimala resurs- och ingenjörskostnader. SÀrskilt om projektet frÄn början inte var tÀnkt som mikrotjÀnstbaserat, utan helt enkelt har utvecklats i den riktningen.
Vi behöver nog inte prata om hastigheten hos nĂ€tverksdiskar â de Ă€r lĂ„ngsamma. Det vill sĂ€ga, i hĂ€ndelse av nĂ„got, har vi Ă€ndĂ„ ingen verklig möjlighet att starta en instans av databashanteringssystemet nĂ„gonstans dĂ€r det finns mer processorresurser eller ledigt RAM-minne. Vi kommer snabbt att stöta pĂ„ begrĂ€nsningar i prestandan hos den virtualiserade diskundersystemet. DĂ€rför mĂ„ste databashanteringssystemet kopplas till sin egen personliga uppsĂ€ttning av maskiner som ligger i direkt nĂ€rhet. Alternativt mĂ„ste vi pĂ„ nĂ„got sĂ€tt ordna en tillrĂ€ckligt snabb datasynekronisering för de reserver vi förvĂ€ntar oss.
Fortsatt pÄ temat virtuella filsystem: tyvÀrr Àr Docker Volumes inte utan problem. Generellt sett, nÀr det gÀller lÄngsiktig och pÄlitlig datalagring, skulle vi helst vilja anvÀnda sÄ enkla tekniska scheman som möjligt. Att lÀgga till ett nytt abstraktionslager frÄn behÄllarens filsystem till vÀrdmaskinens filsystem Àr i sig sjÀlvt en risk. Men nÀr det ocksÄ uppstÄr svÄrigheter i containerhanteringssystemet med att överföra data mellan dessa lager, dÄ Àr det verkligen allvarligt. För nÀrvarande verkar de flesta av de kÀnda problemen som har stött pÄ mÀnskligheten vara utrotade. Men ni förstÄr, ju mer komplicerad en mekanism Àr, desto lÀttare Àr den att bryta.
I ljuset av alla dessa "Ă€ventyr" Ă€r det mycket mer fördelaktigt och enklare att hĂ„lla databasen pĂ„ ett stĂ€lle, och Ă€ven om du behöver containerisera applikationen â lĂ„t den snurra pĂ„ egen hand och genom en lastbalanserare fĂ„ samtidig Ă„tkomst till databasen, som endast kommer att lĂ€sas och skrivas en gĂ„ng och pĂ„ ett stĂ€lle. Denna metod minskar sannolikheten för fel och desynkroniseringar till ett minimum.
Vad leder vi fram till? Att containerisering av databaser Ă€r lĂ€mpligt dĂ€r det finns ett verkligt behov. Man kan inte stoppa in en fullstĂ€ndig app-databas och behandla den som om man hade ett dussin mikrotjĂ€nster â det fungerar inte sĂ„. Och detta mĂ„ste man förstĂ„ tydligt.
IstÀllet för utdata
Om du vÀntar pÄ ett tydligt svar pÄ "ska man virtualisera databasen eller inte", sÄ mÄste vi tyvÀrr göra dig besviken: det kommer inte att finnas nÄgot hÀr. Eftersom man vid skapandet av vilken infrastruktur som helst bör styras av inte trend eller framsteg, utan först och frÀmst sunt förnuft.
Det finns projekt dÀr principerna och verktygen som följer med Kubernetes passar perfekt, och i sÄdana projekt rÄder det Ätminstone fred i backend-omrÄdet. Men det finns projekt som inte behöver containerisering, utan en ordentlig serverinfrastruktur, eftersom de i princip inte kan omarbeta för en mikrotjÀnstbaserad kluster-modell, dÄ de kommer att kollapsa.
KĂ€lla: habr.com
