På en eller annen måte, historisk sett, er IT-bransjen delt inn i to betingede leire uansett grunn: de som er "for" og de som er "mot". Videre kan temaet for tvister være helt vilkårlig. Hvilket operativsystem er bedre: Win eller Linux? På en Android- eller iOS-smarttelefon? Skal du lagre alt i skyene eller legge det på kald RAID-lagring og sette skruene i en safe? Har PHP-folk rett til å bli kalt programmerere? Disse tvistene er til tider utelukkende eksistensielle og har ikke annet grunnlag enn sportslige interesser.
Det skjedde slik at med ankomsten av containere og alt dette elskede kjøkkenet med docker og betingede k8-er, begynte debattene "for" og "mot" bruken av nye muligheter i forskjellige områder av backend. (La oss ta en reservasjon på forhånd at selv om Kubernetes oftest vil bli angitt som en orkestrator i denne diskusjonen, er ikke valget av dette spesielle verktøyet av grunnleggende betydning. I stedet kan du erstatte et hvilket som helst annet som virker mest praktisk og kjent for deg .)
Og det ser ut til at dette ville være en enkel tvist mellom to sider av samme sak. Like meningsløs og nådeløs som den evige konfrontasjonen mellom Win vs Linux, der tilstrekkelige mennesker eksisterer et sted i midten. Men når det gjelder containerisering, er ikke alt så enkelt. Vanligvis i slike tvister er det ingen høyre side, men i tilfelle av "bruk" eller "ikke bruk" beholdere for lagring av databaser, snur alt opp ned. For i en viss forstand har både tilhengere og motstandere av denne tilnærmingen rett.
Lys side
The Light Sides argument kan kort beskrives i en setning: "Hei, 2k19 er utenfor vinduet!" Det høres selvfølgelig ut som populisme, men hvis du går i detalj i situasjonen, har det sine fordeler. La oss ordne dem nå.
La oss si at du har et stort nettprosjekt. Det kunne i utgangspunktet ha blitt bygget på grunnlag av en mikrotjenestetilnærming, eller på et tidspunkt kom det til det gjennom en evolusjonær vei - dette er faktisk ikke veldig viktig. Du spredte prosjektet vårt i separate mikrotjenester, satte opp orkestrering, lastbalansering og skalering. Og nå, med god samvittighet, nipper du til en mojito i en hengekøye under habra-effekter i stedet for å heve falne servere. Men i alle handlinger må du være konsekvent. Svært ofte er det bare selve applikasjonen – koden – som er containerisert. Hva annet har vi enn kode?
Det stemmer, data. Hjertet i ethvert prosjekt er dataene: dette kan enten være en typisk DBMS - MySQL, Postgre, MongoDB, eller lagring som brukes til søk (ElasticSearch), nøkkelverdilagring for caching - for eksempel redis, osv. Foreløpig er vi ikke det. vi vil snakke om skjeve backend-implementeringsalternativer når databasen krasjer på grunn av dårlig skrevne spørringer, og i stedet vil vi snakke om å sikre feiltoleransen til nettopp denne databasen under klientbelastning. Når alt kommer til alt, når vi containeriserer applikasjonen vår og lar den skaleres fritt for å behandle et hvilket som helst antall innkommende forespørsler, øker dette naturligvis belastningen på databasen.
Faktisk blir kanalen for tilgang til databasen og serveren den kjører på nåløyet i vår vakre containeriserte backend. Samtidig er hovedmotivet for containervirtualisering mobiliteten og fleksibiliteten til strukturen, som gjør at vi kan organisere fordelingen av topplaster over hele infrastrukturen som er tilgjengelig for oss så effektivt som mulig. Det vil si at hvis vi ikke containeriserer og ruller ut alle eksisterende elementer av systemet på tvers av klyngen, gjør vi en svært alvorlig feil.
Det er mye mer logisk å gruppere ikke bare selve applikasjonen, men også tjenestene som er ansvarlige for lagring av data. Ved å gruppere og distribuere webservere som fungerer uavhengig og fordeler belastningen seg imellom i k8s, løser vi allerede problemet med datasynkronisering - de samme kommentarene på innlegg, hvis vi tar en eller annen medie- eller bloggplattform som eksempel. I alle fall har vi en intra-klynge, til og med virtuell, representasjon av databasen som en ekstern tjeneste. Spørsmålet er at selve databasen ennå ikke er gruppert – webserverne som er utplassert i kuben tar informasjon om endringer fra vår statiske kampdatabase, som roterer separat.
Fornemmer du en fangst? Vi bruker k8s eller Swarm for å fordele belastningen og unngå å krasje hovedwebserveren, men vi gjør ikke dette for databasen. Men hvis databasen krasjer, gir hele vår klyngede infrastruktur ingen mening - hva hjelper tomme nettsider som returnerer en databasetilgangsfeil?
Det er derfor det er nødvendig å gruppere ikke bare webservere, som vanligvis gjøres, men også databaseinfrastrukturen. Kun på denne måten kan vi sikre en struktur som fungerer fullt ut i ett team, men samtidig uavhengig av hverandre. Dessuten, selv om halvparten av vår backend "kollapser" under belastning, vil resten overleve, og systemet med å synkronisere databasene med hverandre i klyngen og muligheten til uendelig skalering og distribusjon av nye klynger vil hjelpe raskt å nå den nødvendige kapasiteten - hvis det bare var stativer i datasenteret.
I tillegg lar databasemodellen distribuert i klynger deg ta akkurat denne databasen dit den trengs; Hvis vi snakker om en global tjeneste, så er det ganske ulogisk å spinne opp en nettklynge et sted i San Francisco-området og samtidig sende pakker ved tilgang til en database i Moskva-regionen og tilbake.
Dessuten lar containerisering av databasen deg bygge alle elementene i systemet på samme abstraksjonsnivå. Noe som igjen gjør det mulig å administrere akkurat dette systemet direkte fra kode, av utviklere, uten aktiv involvering av administratorer. Utviklerne mente det trengtes et eget DBMS for det nye delprosjektet – enkelt! skrev en yaml-fil, lastet den opp til klyngen og du er ferdig.
Og selvfølgelig er intern drift betydelig forenklet. Fortell meg, hvor mange ganger har du lukket øynene når et nytt lagmedlem la hendene inn i kampdatabasen for jobb? Hvilken er faktisk den eneste du har og spinner akkurat nå? Selvfølgelig er vi alle voksne her, og et sted har vi en frisk backup, og enda lenger unna - bak hyllen med bestemors agurker og gamle ski - en annen backup, kanskje til og med i kjølelager, fordi kontoret ditt var i brann en gang. Men likevel, hver introduksjon av et nytt teammedlem med tilgang til kampinfrastrukturen og, selvfølgelig, til kampdatabasen er en bøtte med validol for alle rundt. Vel, hvem kjenner ham, en nybegynner, kanskje han er på kryss og tvers? Det er skummelt, du er enig.
Containerisering og faktisk den distribuerte fysiske topologien til prosjektets database bidrar til å unngå slike validerende øyeblikk. Stoler du ikke på en nybegynner? OK! La oss gi ham sin egen klynge å jobbe med og koble databasen fra de andre klyngene - synkronisering kun ved manuell trykk og synkron rotasjon av to nøkler (en for teamlederen, den andre for administratoren). Og alle er glade.
Og nå er det på tide å endre seg til motstandere av databaseklynger.
Mørk side
Når vi argumenterer for hvorfor det ikke er verdt å beholde databasen og fortsette å kjøre den på én sentral server, vil vi ikke bøye oss for retorikken om ortodokser og uttalelser som "bestefedre drev databaser på maskinvare, og det vil vi også!" I stedet, la oss prøve å komme opp med en situasjon der containerisering faktisk ville gi håndgripelig utbytte.
Enig, prosjektene som virkelig trenger en base i en container kan telles på fingrene på én hånd av ikke den beste fresemaskinoperatøren. For det meste er til og med bruken av k8s eller Docker Swarm i seg selv overflødig - ganske ofte brukes disse verktøyene på grunn av den generelle hypen av teknologier og holdningene til de "allmektige" i personen til kjønnene for å presse alt inn i skyer og containere. Vel, for nå er det mote og alle gjør det.
I minst halvparten av tilfellene er det overflødig å bruke Kubernetis eller bare Docker på et prosjekt. Problemet er at ikke alle team eller outsourcingselskaper ansatt for å vedlikeholde kundens infrastruktur er klar over dette. Det er verre når containere blir pålagt, fordi det koster en viss mengde mynter for kunden.
Generelt er det en oppfatning om at docker/kubemafiaen dumt knuser klienter som outsourcer disse infrastrukturproblemene. For å jobbe med klynger trenger vi tross alt ingeniører som er i stand til dette og generelt forstår arkitekturen til den implementerte løsningen. Vi beskrev allerede en gang saken vår med Republic-publikasjonen - der trente vi klientens team til å jobbe i Kubernetis-realitetene, og alle var fornøyde. Og det var anstendig. Ofte tar k8s "implementere" klientens infrastruktur som gisler - for nå forstår bare de hvordan alt fungerer der; det er ingen spesialister på klientens side.
Tenk deg nå at vi på denne måten outsourcer ikke bare webserverdelen, men også databasevedlikeholdet. Vi sa at BD er hjertet, og tapet av hjertet er dødelig for enhver levende organisme. Kort sagt, utsiktene er ikke de beste. Så, i stedet for hype Kubernetis, burde mange prosjekter rett og slett ikke bry seg med den normale tariffen for AWS, som vil løse alle problemene med belastningen på nettstedet/prosjektet deres. Men AWS er ikke lenger på moten, og show-offs er verdt mer enn penger – dessverre også i IT-miljøet.
OK. Kanskje prosjektet virkelig trenger klynging, men hvis alt er klart med statsløse applikasjoner, hvordan kan vi da organisere anstendig nettverkstilkobling for en klynget database?
Hvis vi snakker om en sømløs ingeniørløsning, som er hva overgangen til k8s er, så er vår viktigste hodepine datareplikering i en klynget database. Noen DBMS-er er i utgangspunktet ganske lojale mot distribusjon av data mellom deres individuelle forekomster. Mange andre er ikke så imøtekommende. Og ganske ofte er hovedargumentet for å velge et DBMS for prosjektet vårt ikke evnen til å replikere med minimale ressurs- og ingeniørkostnader. Spesielt hvis prosjektet i utgangspunktet ikke var planlagt som en mikrotjeneste, men ganske enkelt utviklet seg i denne retningen.
Vi tror det ikke er nødvendig å snakke om hastigheten på nettverksstasjoner - de er trege. De. Vi har fortsatt ikke en reell mulighet, hvis noe skjer, til å starte en DBMS-forekomst på nytt et sted hvor det er mer, for eksempel prosessorkraft eller ledig RAM. Vi kommer veldig raskt inn i ytelsen til det virtualiserte diskundersystemet. Følgelig må DBMS spikret til sitt eget personlige sett med maskiner plassert i umiddelbar nærhet. Eller det er nødvendig å på en eller annen måte kjøle ned tilstrekkelig rask datasynkronisering for de antatte reservene.
Fortsetter temaet virtuelle filsystemer: Docker-volumer er dessverre ikke problemfrie. Generelt, i en sak som langsiktig pålitelig datalagring, vil jeg gjerne nøye meg med de mest teknisk enkle ordningene. Og å legge til et nytt abstraksjonslag fra beholderens FS til FS til overordnet verten er en risiko i seg selv. Men når driften av støttesystemet for containerisering også støter på problemer med å overføre data mellom disse lagene, så er det virkelig en katastrofe. For øyeblikket ser det ut til at de fleste problemene kjent for den progressive menneskeheten er utryddet. Men du forstår, jo mer kompleks mekanismen er, jo lettere bryter den.
I lys av alle disse "eventyrene" er det mye mer lønnsomt og enklere å holde databasen på ett sted, og selv om du trenger å beholde applikasjonen, la den kjøre på egen hånd og gjennom distribusjonsporten motta samtidig kommunikasjon med database, som bare leses og skrives én gang og på ett sted. Denne tilnærmingen reduserer sannsynligheten for feil og desynkronisering til et minimum.
Hva fører vi til? Dessuten er databasebeholderisering hensiktsmessig der det er et reelt behov for det. Du kan ikke fylle en database med full app og snurre den som om du hadde to dusin mikrotjenester - det fungerer ikke slik. Og dette må forstås tydelig.
I stedet for produksjon
Hvis du venter på en klar konklusjon "å virtualisere databasen eller ikke", så vil vi skuffe deg: den vil ikke være her. For når man lager en hvilken som helst infrastrukturløsning, må man ikke ledes av mote og fremgang, men først og fremst av sunn fornuft.
Det er prosjekter der prinsippene og verktøyene som følger med Kubernetis passer perfekt, og i slike prosjekter er det fred i hvert fall i backend-området. Og det er prosjekter som ikke trenger containerisering, men en normal serverinfrastruktur, fordi de fundamentalt ikke kan skalere til mikrotjenesteklyngemodellen, fordi de vil falle.
Kilde: www.habr.com