Nekako, istorijski gledano, IT industrija je iz bilo kog razloga podeljena na dva uslovna tabora: one koji su „za“ i one koji su „protiv“. Štaviše, predmet spora može biti potpuno proizvoljan. Koji je OS bolji: Win ili Linux? Na Android ili iOS pametnom telefonu? Treba li sve pohraniti u oblake ili staviti na hladno RAID skladište i staviti šrafove u sef? Da li PHP ljudi imaju pravo da se zovu programeri? Ovi sporovi su ponekad isključivo egzistencijalne prirode i nemaju nikakvu osnovu osim sportskog interesa.
Desilo se da su s pojavom kontejnera i sve ove omiljene kuhinje sa dockerom i uslovnim k8s, počele debate "za" i "protiv" upotrebe novih mogućnosti u različitim područjima pozadine. (Hajde da unapred rezervišemo da, iako će Kubernetes najčešće biti naznačen kao orkestrator u ovoj diskusiji, izbor ovog alata nije od suštinske važnosti. Umesto toga, možete zameniti bilo koji drugi koji vam se čini najprikladnijim i poznatijim .)
I, čini se, ovo bi bio jednostavan spor između dvije strane istog novčića. Besmislena i nemilosrdna kao što je vječna konfrontacija Win protiv Linuxa, u kojoj negdje na sredini postoje adekvatni ljudi. Ali u slučaju kontejnerizacije nije sve tako jednostavno. Obično u ovakvim sporovima nema prave strane, ali u slučaju “koristiti” ili “ne koristiti” kontejnere za pohranjivanje baza podataka, sve se okreće naopačke. Jer u određenom smislu i pristalice i protivnici ovakvog pristupa su u pravu.
Svijetla strana
Argument Svjetle strane može se ukratko opisati jednom frazom: "Zdravo, 2k19 je ispred prozora!" Zvuči kao populizam, naravno, ali ako se detaljno udubite u situaciju, to ima svoje prednosti. Hajde da ih sada sredimo.
Recimo da imate veliki web projekat. Mogla je u početku biti izgrađena na bazi mikroservisnog pristupa, ili je u nekom trenutku do toga došla evolutivnim putem - to zapravo i nije toliko važno. Raspršili ste naš projekat u zasebne mikroservise, postavili orkestraciju, balansiranje opterećenja i skaliranje. A sada, mirne savjesti, pijuckate mojito u visećoj mreži tokom habra efekata umjesto da dižete pale servere. Ali u svim akcijama morate biti dosljedni. Vrlo često je samo sama aplikacija – kod – kontejnerizirana. Šta još imamo osim koda?
Tako je, podaci. Srce svakog projekta su njegovi podaci: to može biti ili tipičan DBMS - MySQL, Postgre, MongoDB, ili skladište koje se koristi za pretragu (ElasticSearch), skladište ključ/vrijednost za keširanje - na primjer, redis, itd. Trenutno nismo govorit ćemo o pogrešnim opcijama implementacije pozadinske baze kada se baza podataka sruši zbog loše napisanih upita, a umjesto toga ćemo govoriti o osiguranju tolerancije grešaka baš ove baze podataka pod opterećenjem klijenta. Na kraju krajeva, kada kontejneriziramo našu aplikaciju i dopustimo joj da se slobodno skalira za obradu bilo kojeg broja dolaznih zahtjeva, to prirodno povećava opterećenje baze podataka.
Zapravo, kanal za pristup bazi podataka i server na kojem ona radi postaju iglena ušica u našem prekrasnom kontejnerskom backendu. Istovremeno, glavni motiv virtualizacije kontejnera je mobilnost i fleksibilnost strukture, što nam omogućava da što efikasnije organiziramo distribuciju vršnih opterećenja na cjelokupnu infrastrukturu koja nam je dostupna. Odnosno, ako ne kontejneriziramo i ne uvedemo sve postojeće elemente sistema u klaster, pravimo vrlo ozbiljnu grešku.
Mnogo je logičnije grupirati ne samo samu aplikaciju, već i servise odgovorne za pohranjivanje podataka. Klasteriranjem i postavljanjem web servera koji rade samostalno i međusobno raspoređuju opterećenje u k8s-u, već rješavamo problem sinhronizacije podataka - isti komentari na objave, ako za primjer uzmemo neki medij ili blog platformu. U svakom slučaju, imamo intra-klaster, čak i virtuelnu, reprezentaciju baze podataka kao ExternalService. Pitanje je da sama baza podataka još nije grupirana - web serveri raspoređeni u kocki preuzimaju informacije o promjenama iz naše statičke borbene baze podataka, koja se zasebno rotira.
Da li osećate ulov? Koristimo k8s ili Swarm za distribuciju opterećenja i izbjegavanje rušenja glavnog web servera, ali to ne radimo za bazu podataka. Ali ako se baza podataka sruši, onda naša cijela klasterska infrastruktura nema smisla - čemu su dobre prazne web stranice koje vraćaju grešku pristupa bazi podataka?
Zbog toga je potrebno grupirati ne samo web servere, kako se to obično radi, već i infrastrukturu baze podataka. Samo na taj način možemo osigurati strukturu koja u potpunosti funkcionira u jednom timu, ali istovremeno neovisna jedni od drugih. Štaviše, čak i ako se polovina našeg pozadinskog sistema „sruši“ pod opterećenjem, ostatak će preživjeti, a sistem međusobnog usklađivanja baza podataka unutar klastera i mogućnost beskonačnog skaliranja i implementacije novih klastera pomoći će da se brzo postigne potreban kapacitet - samo da postoje stalci u data centru.
Pored toga, model baze podataka distribuiran u klastere omogućava vam da ovu bazu podataka odnesete tamo gdje je potrebna; Ako govorimo o globalnom servisu, onda je prilično nelogično vrtiti web klaster negdje u području San Francisca i istovremeno slati pakete prilikom pristupa bazi podataka u moskovskoj regiji i nazad.
Takođe, kontejnerizacija baze podataka omogućava vam da izgradite sve elemente sistema na istom nivou apstrakcije. Što zauzvrat omogućava upravljanje ovim sistemom direktno iz koda, od strane programera, bez aktivnog uključivanja administratora. Programeri su smatrali da je za novi potprojekat potreban poseban DBMS - lako! napisao yaml fajl, postavio ga u klaster i gotovi ste.
I naravno, interni rad je znatno pojednostavljen. Recite mi koliko ste puta zatvorili oči kada je novi član tima stavio ruke u borbenu bazu podataka za posao? Koja je, zapravo, jedina koju imate i koja se trenutno vrti? Naravno, svi smo mi odrasli ovdje, a negdje imamo svježu rezervu, a još dalje - iza police s bakinim krastavcima i starim skijama - još jednu rezervu, možda čak i u hladnjači, jer vam je kancelarija već jednom gorjela. Ali svejedno, svako predstavljanje novog člana tima s pristupom borbenoj infrastrukturi i, naravno, borbenoj bazi podataka je kanta validola za sve oko sebe. Pa, ko ga zna, novajlija, možda je skroz šaljiv? To je strašno, složićete se.
Kontejnerizacija i, zapravo, distribuirana fizička topologija baze podataka vašeg projekta pomaže da se izbjegnu takvi momenti validacije. Ne vjerujete novajliji? UREDU! Dajmo mu svoj vlastiti klaster za rad i odspojimo bazu podataka sa ostalim klasterima - sinhronizacija samo ručnim pritiskom i sinkronom rotacijom dva ključa (jedan za voditelja tima, drugi za administratora). I svi su sretni.
A sada je vrijeme da se pretvorite u protivnike grupiranja baza podataka.
Tamna strana
Argumentirajući zašto ne vrijedi kontejnerizirati bazu podataka i nastaviti je pokretati na jednom centralnom serveru, nećemo se spustiti na retoriku ortodoksije i izjave poput „djedovi su vodili baze podataka na hardveru, pa ćemo i mi!” Umjesto toga, pokušajmo doći do situacije u kojoj bi kontejnerizacija zapravo isplatila opipljive dividende.
Slažem se, projekti kojima je zaista potrebna baza u kontejneru mogu se nabrojati na prste jedne ruke od strane ne najboljeg operatera glodalice. Uglavnom, čak je i sama upotreba k8s-a ili Docker Swarm-a suvišna - često se ovim alatima pribjegava zbog opće pompe tehnologije i stavova “svemogućeg” u osobi polova da sve gurne u oblaci i kontejneri. Pa, zato što je to sada moderno i svi to rade.
U najmanje polovini slučajeva korištenje Kubernetisa ili samo Dockera na projektu je suvišno. Problem je u tome što nisu svi timovi ili outsourcing kompanije angažirane da održavaju infrastrukturu klijenta toga svjesne. Još je gore kada se nameću kontejneri, jer to klijentu košta određenu količinu novčića.
Općenito, postoji mišljenje da docker/cube mafija glupo slama klijente koji predaju ova pitanja infrastrukturi. Uostalom, za rad sa klasterima potrebni su nam inženjeri koji su za to sposobni i generalno razumiju arhitekturu implementiranog rješenja. Jednom smo već opisali naš slučaj sa Republičkom publikacijom - tamo smo obučili klijentov tim za rad u realnosti Kubernetisa i svi su bili zadovoljni. I bilo je pristojno. Često k8s "implementari" uzimaju klijentovu infrastrukturu kao taoca - jer sada samo oni razumiju kako tamo sve funkcionira; na strani klijenta nema stručnjaka.
Sada zamislite da na ovaj način angažujemo ne samo dio web servera, već i održavanje baze podataka. Rekli smo da je BD srce, a gubitak srca je fatalan za svaki živi organizam. Ukratko, izgledi nisu najbolji. Dakle, umjesto hype Kubernetisa, mnogi projekti se jednostavno ne bi trebali zamarati normalnom tarifom za AWS, što će riješiti sve probleme sa opterećenjem na njihovom sajtu/projektu. Ali AWS više nije moderan, a razmetanje vrijede više od novca - nažalost, iu IT okruženju.
UREDU. Možda je projektu zaista potrebno grupisanje, ali ako je sve jasno sa aplikacijama bez stanja, kako onda možemo organizirati pristojnu mrežnu povezanost za klastersku bazu podataka?
Ako govorimo o besprekornom inženjerskom rješenju, što je prijelaz na k8s, onda je naša glavna glavobolja replikacija podataka u klasteriziranoj bazi podataka. Neki DBMS-ovi su u početku prilično lojalni distribuciji podataka između svojih pojedinačnih instanci. Mnogi drugi nisu tako dobrodošli. I prilično često glavni argument u odabiru DBMS-a za naš projekat nije mogućnost repliciranja uz minimalne troškove resursa i inženjeringa. Pogotovo ako projekt u početku nije bio planiran kao mikroservis, već je jednostavno evoluirao u tom smjeru.
Mislimo da nema potrebe govoriti o brzini mrežnih diskova – oni su spori. One. Još uvijek nemamo pravu priliku, ako se nešto dogodi, da ponovo pokrenemo DBMS instancu negdje gdje ima više, na primjer, snage procesora ili slobodne RAM memorije. Vrlo brzo ćemo naići na performanse virtueliziranog podsistema diska. Shodno tome, DBMS mora biti prikovan za sopstveni lični skup mašina koje se nalaze u neposrednoj blizini. Ili je potrebno nekako odvojeno ohladiti dovoljno brzu sinhronizaciju podataka za tobožnje rezerve.
Nastavljajući temu virtuelnih sistema datoteka: Docker volumeni, nažalost, nisu bez problema. Općenito, u takvom pitanju kao što je dugoročno pouzdano skladištenje podataka, želio bih se zadovoljiti tehnički najjednostavnijim shemama. A dodavanje novog sloja apstrakcije iz FS-a kontejnera u FS roditeljskog hosta je rizik samo po sebi. Ali kada rad sistema za podršku kontejnerizaciji također naiđe na poteškoće s prijenosom podataka između ovih slojeva, onda je to zaista katastrofa. U ovom trenutku, čini se da je većina problema poznatih progresivnom čovječanstvu iskorijenjena. Ali shvatite, što je mehanizam složeniji, lakše se razbija.
U svjetlu svih ovih „avantura“, mnogo je isplativije i lakše držati bazu podataka na jednom mjestu, a čak i ako trebate kontejnerizirati aplikaciju, pustite je da radi samu i da preko distributivnog gateway-a prima istovremenu komunikaciju sa baze podataka, koja će se čitati i pisati samo jednom i na jednom mjestu. Ovaj pristup smanjuje vjerovatnoću grešaka i desinhronizacije na minimum.
čemu vodimo? Štaviše, kontejnerizacija baze podataka je prikladna tamo gdje postoji stvarna potreba za njom. Ne možete puniti bazu podataka pune aplikacije i okretati je kao da imate dva tuceta mikroservisa - to ne funkcionira na taj način. I to se mora jasno shvatiti.
Umesto izlaza
Ako čekate jasan zaključak "virtuelizirati bazu podataka ili ne", onda ćemo vas razočarati: neće biti ovdje. Jer pri kreiranju bilo kakvog infrastrukturnog rješenja ne mora se voditi moda i napredak, već prije svega zdrav razum.
Postoje projekti za koje se principi i alati koji dolaze uz Kubernetis savršeno uklapaju, a u takvim projektima vlada mir barem u backend području. A postoje i projekti kojima nije potrebna kontejnerizacija, već normalna serverska infrastruktura, jer se u osnovi ne mogu reskalirati na model mikroservisnog klastera, jer će pasti.
izvor: www.habr.com