Nekako je povijesno IT industrija iz bilo kojeg razloga podijeljena u dva uvjetna tabora: one koji su “za” i one koji su “protiv”. Štoviše, predmet sporova može biti potpuno proizvoljan. Koji OS je bolji: Win ili Linux? Na Android ili iOS pametnom telefonu? Trebate li sve pohraniti u oblake ili staviti u hladno RAID skladište i vijke staviti u sef? Imaju li PHP ljudi pravo nazivati se programerima? Ti sporovi ponekad su isključivo egzistencijalne prirode i nemaju nikakvu drugu osnovu osim sportskog interesa.
Slučajno se dogodilo da su s dolaskom kontejnera i sve te voljene kuhinje s dockerima i uvjetnim k8-ovima počele rasprave "za" i "protiv" korištenja novih mogućnosti u raznim područjima pozadine. (Unaprijed napomenimo da, iako će Kubernetes najčešće biti naznačen kao orkestrator u ovoj raspravi, izbor ovog određenog alata nije od temeljne važnosti. Umjesto toga, možete zamijeniti bilo koji drugi koji vam se čini najprikladnijim i poznatijim .)
I, čini se, to bi bio običan spor između dvije strane iste medalje. Besmisleno i nemilosrdno kao i vječni sukob između Wina i Linuxa, u kojem su adekvatni ljudi negdje u sredini. Ali u slučaju kontejnerizacije nije sve tako jednostavno. Obično u takvim sporovima nema prave strane, ali u slučaju "koristi" ili "ne koristi" spremnike za pohranu baza podataka, sve se okreće naglavačke. Jer u određenom su smislu u pravu i pobornici i protivnici ovog pristupa.
Svijetla strana
Argument Light Sidea može se ukratko opisati u jednoj rečenici: "Zdravo, 2k19 je ispred prozora!" Zvuči kao populizam, naravno, ali ako se detaljno uđe u situaciju, to ima svoje prednosti. Razvrstajmo ih sada.
Recimo da imate veliki web projekt. Mogla je biti inicijalno izgrađena na temelju mikroservisnog pristupa ili je u nekom trenutku do nje došla evolucijskim putem – to zapravo i nije toliko važno. Raspršili ste naš projekt u zasebne mikroservise, postavili orkestraciju, balansiranje opterećenja i skaliranje. I sad mirne savjesti pijuckate mojito u visećoj mreži za vrijeme habra efekata umjesto da dižete pale servere. Ali u svim postupcima morate biti dosljedni. Vrlo često je samo sama aplikacija - kod - kontejnerizirana. Što još imamo osim koda?
Tako je, podaci. Srce svakog projekta su njegovi podaci: to može biti tipični DBMS - MySQL, Postgre, MongoDB ili pohrana koja se koristi za pretraživanje (ElasticSearch), pohrana ključeva i vrijednosti za predmemoriju - na primjer, redis, itd. Trenutno nismo govorit ćemo o pokvarenim opcijama implementacije pozadine kada se baza podataka sruši zbog loše napisanih upita, a umjesto toga ćemo govoriti o osiguravanju tolerancije na greške ove baze podataka pod opterećenjem klijenta. Uostalom, kada našu aplikaciju pretvorimo u spremnik i dopustimo joj da slobodno skalira kako bi obradila bilo koji broj dolaznih zahtjeva, to prirodno povećava opterećenje baze podataka.
Zapravo, kanal za pristup bazi podataka i poslužitelj na kojem se ona izvodi postaju uši igle u našem prekrasnom kontejnerskom backendu. Istovremeno, glavni motiv virtualizacije kontejnera je mobilnost i fleksibilnost strukture, što nam omogućuje da što učinkovitije organiziramo raspodjelu vršnih opterećenja na cjelokupnu infrastrukturu koja nam je na raspolaganju. Odnosno, ako ne kontejneriziramo i ne razvijemo sve postojeće elemente sustava preko klastera, činimo vrlo ozbiljnu pogrešku.
Puno je logičnije grupirati ne samo samu aplikaciju, već i usluge odgovorne za pohranu podataka. Klasteriranjem i postavljanjem web poslužitelja koji rade samostalno i međusobno raspoređuju opterećenje u k8s već rješavamo problem sinkronizacije podataka – isti komentari na objave, ako uzmemo neku medijsku ili blog platformu kao primjer. U svakom slučaju, imamo intra-klasterski, čak i virtualni, prikaz baze podataka kao ExternalService. Pitanje je da sama baza podataka još nije grupirana - web poslužitelji raspoređeni u kocki uzimaju informacije o promjenama iz naše statične borbene baze podataka, koja se zasebno rotira.
Osjećate li kvaku? Koristimo k8s ili Swarm za raspodjelu opterećenja i izbjegavanje rušenja glavnog web poslužitelja, ali to ne radimo za bazu podataka. Ali ako se baza podataka sruši, tada cijela naša klasterirana infrastruktura nema smisla - čemu služe prazne web stranice koje vraćaju pogrešku pristupa bazi podataka?
Zbog toga je potrebno klasterizirati ne samo web poslužitelje, kako se inače 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 jedna o drugoj. Štoviše, čak i ako se polovica našeg backenda “sruši” pod opterećenjem, ostatak će preživjeti, a sustav međusobnog sinkroniziranja baza podataka unutar klastera i mogućnost beskonačnog skaliranja i postavljanja novih klastera pomoći će brzom postizanju potrebnog kapaciteta - kad bi barem postojali regali u podatkovnom centru .
Osim toga, model baze podataka distribuiran u klasterima omogućuje vam da ovu bazu podataka odnesete tamo gdje je potrebna; Ako govorimo o globalnoj usluzi, onda je sasvim nelogično pokrenuti web klaster negdje na području San Francisca i istovremeno slati pakete prilikom pristupa bazi podataka u moskovskoj regiji i natrag.
Također, kontejnerizacija baze podataka omogućuje izgradnju svih elemenata sustava na istoj razini apstrakcije. Što zauzvrat omogućuje upravljanje tim sustavom izravno iz koda, od strane programera, bez aktivnog uključivanja administratora. Programeri su smatrali da je za novi potprojekt potreban poseban DBMS - jednostavno! napisao yaml datoteku, učitao je u klaster i gotovi ste.
I naravno, interni rad je znatno pojednostavljen. Recite mi, koliko puta ste zatvorili oči kada je novi član tima stavio svoje ruke u borbenu bazu podataka za posao? Koji je, zapravo, jedini koji imate i trenutno se vrti? Naravno, svi smo mi ovdje odrasli i negdje imamo svježu rezervu, a još dalje - iza police s bakinim krastavcima i starim skijama - drugu rezervu, možda čak i u hladnjači, jer tvoj je ured već jednom bio u plamenu. Ali svejedno, svako uvođenje novog člana tima s pristupom borbenoj infrastrukturi i, naravno, borbenoj bazi podataka je kanta validola za sve okolo. Pa, tko ga zna, novajlija, možda je prekriženih ruku? Prestrašno je, složit ćete se.
Kontejnerizacija i, zapravo, distribuirana fizička topologija baze podataka vašeg projekta pomaže u izbjegavanju takvih trenutaka provjere valjanosti. Ne vjerujete novajliji? U REDU! Dajmo mu vlastiti klaster da radi s njim i odspojimo bazu podataka od ostalih klastera - sinkronizacija samo ručnim pritiskom i sinkronom rotacijom dva ključa (jedan za voditelja tima, drugi za administratora). I svi sretni.
A sada je vrijeme da se promijenimo u protivnike klasteriranja baze podataka.
Tamna strana
Argumentirajući zašto se ne isplati kontejnerizirati bazu podataka i nastaviti je izvoditi na jednom središnjem poslužitelju, nećemo se spustiti na retoriku ortodoksija i izjava poput “djedovi su vodili baze podataka na hardveru, pa ćemo i mi!” Umjesto toga, pokušajmo smisliti situaciju u kojoj bi kontejnerizacija doista isplatila opipljive dividende.
Slažete se, projekti koji stvarno trebaju podlogu u kontejneru mogu se nabrojati na prste jedne ruke od strane ne najboljeg operatera glodalice. Većinom je čak i sama upotreba k8s-a ili Docker Swarma suvišna - prilično često se tim alatima pribjegava zbog opće pompe tehnologija i stavova "svemogućeg" u osobi spolova da se sve gura u oblaci i kontejneri. Pa zato što je sada moderno i svi to rade.
U barem polovici slučajeva korištenje Kubernetisa ili samo Dockera na projektu je suvišno. Problem je u tome što nisu svi timovi ili outsourcing tvrtke angažirane za održavanje infrastrukture klijenta toga svjesni. Još je gore kada se kontejneri nameću, jer to klijenta košta određenu količinu kovanica.
Općenito, postoji mišljenje da docker/cube mafija glupo slama klijente koji outsource-uju ove infrastrukturne probleme. Uostalom, za rad s klasterima potrebni su inženjeri koji su za to sposobni i općenito razumiju arhitekturu implementiranog rješenja. Već smo jednom opisali naš slučaj s publikacijom Republic - tamo smo obučili klijentov tim za rad u stvarnostima Kubernetisa i svi su bili zadovoljni. I bilo je pristojno. Često k8s "implementatori" uzimaju klijentovu infrastrukturu kao taoca - jer sada samo oni razumiju kako sve tamo funkcionira; nema stručnjaka na strani klijenta.
Sada zamislite da na ovaj način outsourcamo ne samo dio web poslužitelja, već i održavanje baze podataka. Rekli smo da je BD srce, a gubitak srca je poguban za svaki živi organizam. Ukratko, izgledi nisu najbolji. Dakle, umjesto hype Kubernetisa, mnogi projekti se jednostavno ne bi trebali zamarati normalnom tarifom za AWS, koja će riješiti sve probleme s opterećenjem njihove stranice/projekta. Ali AWS više nije moderan, a razmetanje vrijedi više od novca - nažalost, iu IT okruženju.
U REDU. Možda projekt stvarno treba klasteriranje, ali ako je sve jasno s aplikacijama bez stanja, kako onda možemo organizirati pristojnu mrežnu povezanost za klasteriranu bazu podataka?
Ako govorimo o besprijekornom inženjerskom rješenju, što je prijelaz na k8s, onda je naša glavna glavobolja replikacija podataka u klasteriranoj bazi podataka. Neki DBMS-ovi su u početku prilično lojalni distribuciji podataka između svojih pojedinačnih instanci. Mnogi drugi nisu tako gostoljubivi. Često glavni argument pri odabiru DBMS-a za naš projekt nije sposobnost repliciranja uz minimalne troškove resursa i inženjeringa. Pogotovo ako projekt inicijalno nije planiran kao mikroservis, već se jednostavno razvijao u tom smjeru.
Mislimo da nema potrebe govoriti o brzini mrežnih diskova - spori su. Oni. Još uvijek nemamo pravu priliku, ako se nešto dogodi, ponovno pokrenuti DBMS instancu negdje gdje ima više, na primjer, snage procesora ili slobodnog RAM-a. Vrlo brzo ćemo se susresti s performansama podsustava virtualiziranog diska. Sukladno tome, DBMS mora biti prikovan za vlastiti osobni skup strojeva koji se nalaze u neposrednoj blizini. Ili je potrebno nekako zasebno ohladiti dovoljno brzu sinkronizaciju podataka za navodne rezerve.
Nastavljajući temu virtualnih datotečnih sustava: Docker Volumes, nažalost, nisu bez problema. Općenito, u takvoj stvari kao što je dugoročna pouzdana pohrana podataka, želio bih se zadovoljiti tehnički najjednostavnijim shemama. Dodavanje novog sloja apstrakcije iz FS-a spremnika u FS nadređenog hosta rizik je sam po sebi. Ali kada rad sustava za podršku kontejnerizaciji također naiđe na poteškoće s prijenosom podataka između tih slojeva, onda je to stvarno katastrofa. U ovom trenutku, čini se da je većina problema poznatih progresivnom čovječanstvu iskorijenjena. Ali razumijete, što je mehanizam složeniji, to se lakše pokvari.
U svjetlu svih ovih “avantura”, puno je isplativije i jednostavnije držati bazu podataka na jednom mjestu, a čak i ako trebate aplikaciju staviti u kontejner, pustite je da radi sama i preko distribucijskog pristupnika prima simultanu komunikaciju s baza podataka, koja će se čitati i pisati samo jednom i na jednom mjestu. Ovakav pristup smanjuje vjerojatnost grešaka i desinkronizacije na minimum.
Čemu to vodimo? Štoviše, kontejnerizacija baze podataka prikladna je tamo gdje za to postoji stvarna potreba. Ne možete napuniti bazu podataka pune aplikacije i vrtjeti je kao da imate dvadesetak mikroservisa - to ne funkcionira tako. I to se mora jasno razumjeti.
Umjesto rezultata
Ako čekate jasan zaključak "virtualizirati bazu podataka ili ne", razočarat ćemo vas: ovdje ga neće biti. Jer pri stvaranju bilo kakvog infrastrukturnog rješenja ne treba se voditi modom i napretkom, već prije svega zdravim razumom.
Postoje projekti za koje principi i alati koji dolaze s Kubernetisom savršeno odgovaraju, au takvim projektima postoji mir barem u backend području. A postoje projekti koji ne trebaju kontejnerizaciju, već normalnu poslužiteljsku infrastrukturu, jer se fundamentalno ne mogu promijeniti u model klastera mikroservisa, jer će pasti.
Izvor: www.habr.com