In qualchì modu, storicamente, l'industria di l'IT hè divisa in dui campi di cundizzioni per qualsiasi raggiuni: quelli chì sò "per" è quelli chì sò "contra". Inoltre, u sughjettu di disputi pò esse cumplettamente arbitrariu. Quale SO hè megliu: Win o Linux? In un smartphone Android o iOS? Duvete guardà tuttu in i nuvuli o mette in un almacenamentu RAID friddu è mette i viti in una sicura? E persone PHP anu u dirittu di esse chjamatu programatori? Sti disputi sò, à volte, esclusivamente di natura esistenziale è ùn anu micca una basa altru chè l'interessu sportivu.
Hè accadutu chì cù l'avventu di cuntenituri è tutta sta cucina amata cù docker è k8s cundiziunali, i dibattiti "per" è "contra" l'usu di novi capacità in parechji spazii di u backend cuminciaru. (Femu una riservazione in anticipu chì, ancu s'è Kubernetes serà più spessu indicatu cum'è un orchestratore in questa discussione, l'scelta di questu strumentu particulari ùn hè micca d'impurtanza fundamentale. Invece, pudete rimpiazzà qualsiasi altru chì vi pare più còmuda è familiar. .)
È, pare, questu saria una disputa simplice trà dui lati di a stessa munita. Cum'è senza sensu è senza pietà cum'è l'eterna scontru trà Win vs Linux, in quale e persone adatte esistenu in qualchì locu à mezu. Ma in u casu di containerizazione, micca tuttu hè cusì simplice. Di solitu in tali disputi ùn ci hè micca un latu drittu, ma in u casu di cuntenituri "usu" o "micca aduprà" per almacenà e basa di dati, tuttu si gira à l'altru. Perchè in un certu sensu, sia i sustenidori sia l'avversarii di sta dimarchja anu ghjustu.
Latu luminoso
L'argumentu di u Light Side pò esse brevemente descrittu in una frase: "Hello, 2k19 hè fora di a finestra!" Sona cum'è populismu, di sicuru, ma s'è vo sfondate in a situazione in dettu, hà i so vantaghji. Scupritemu avà.
Dicemu chì avete un grande prughjettu web. Puderia esse statu inizialmente custruitu nantu à a basa di un accostu di microserviziu, o à un certu puntu hè ghjuntu à ellu attraversu una strada evolutiva - questu ùn hè micca assai impurtante, in fattu. Avete spargugliatu u nostru prughjettu in microservizi separati, stallate l'orchestrazione, l'equilibriu di carica è a scala. È avà, cù una cuscenza pulita, si beie un mojito in una amaca durante l'effetti habra invece di alzà i servitori caduti. Ma in tutte l'azzioni duvete esse coherente. Assai spessu, solu l'applicazione stessu - u codice - hè cuntainerizatu. Chì altru avemu in più di u codice?
Hè propiu, dati. U core di ogni prughjettu hè i so dati: questu pò esse un DBMS tipicu - MySQL, Postgre, MongoDB, o un almacenamentu utilizatu per a ricerca (ElasticSearch), un almacenamentu chjave-valore per caching - per esempiu, redis, etc. Attualmente ùn simu micca. Parleremu di l'opzioni di implementazione di backend storte quandu a basa di dati si crash per causa di dumande scritte male, è invece parleremu di assicurà a tolleranza di difetti di sta basa di dati assai sottu a carica di u cliente. Dopu tuttu, quandu cuntainizemu a nostra applicazione è permettenu di scala liberamente per processà ogni quantità di richieste entrate, questu naturalmente aumenta a carica nantu à a basa di dati.
In fattu, u canali per accede à a basa di dati è u servitore nantu à quale si corre diventanu l'ochju di l'agulla in u nostru bellu backend containerizatu. À u listessu tempu, u mutivu principale di a virtualizazione di u containeru hè a mobilità è a flessibilità di a struttura, chì ci permette di urganizà a distribuzione di carichi di punta in tutta l'infrastruttura dispunibile per noi in modu efficientemente pussibule. Vale à dì, s'ellu ùn cuntainizemu micca è sparghjemu tutti l'elementi esistenti di u sistema in u cluster, facemu un sbagliu assai seriu.
Hè assai più logicu di clustering micca solu l'applicazione stessu, ma ancu i servizii rispunsevuli di almacenà e dati. Raggruppendu è implementà i servitori web chì travaglianu indipindentamente è distribuiscenu a carica trà elli in k8s, avemu digià risolve u prublema di sincronizazione di dati - i stessi cumenti nantu à i posti, se pigghiamu qualchì media o piattaforma di blog per esempiu. In ogni casu, avemu una rappresentazione intra-cluster, ancu virtuale, di a basa di dati cum'è un Serviziu Esternu. A quistione hè chì a basa di dati stessu ùn hè ancu raggruppata - i servitori web implementati in u cubu piglianu infurmazioni nantu à i cambiamenti da a nostra basa di dati di cummattimentu staticu, chì rota separatamente.
Sentu una cattura? Utilizemu k8s o Swarm per distribuisce a carica è evità di crashing u servitore web principale, ma ùn facemu micca questu per a basa di dati. Ma se a basa di dati crashs, allora tutta a nostra infrastruttura raggruppata ùn hà micca sensu - chì boni sò e pagine web vacanti chì tornanu un errore di accessu à a basa di dati?
Hè per quessa hè necessariu di raggruppà micca solu i servitori web, cum'è di solitu, ma ancu l'infrastruttura di basa di dati. Solu in questu modu pudemu assicurà una struttura chì travaglia cumplettamente in una squadra, ma à u stessu tempu indipindenti di l'altri. Inoltre, ancu s'è a mità di u nostru backend "collassa" sottu a carica, u restu sopravvive, è u sistema di sincronizà e basa di dati cù l'altri in u cluster è a capacità di scala senza fine è implementà novi clusters aiutanu à ghjunghje rapidamente a capacità necessaria. - s'ellu ci era solu racks in u centru di dati.
Inoltre, u mudellu di basa di dati distribuitu in clusters vi permette di piglià sta basa di dati induve hè necessariu; Se parlemu di un serviziu glubale, allora hè abbastanza illogicu per spin up un web cluster in un locu in l'area di San Francisco è à u stessu tempu mandà pacchetti quandu accede à una basa di dati in a regione di Mosca è torna.
Inoltre, a cuntainerizazione di a basa di dati permette di custruisce tutti l'elementi di u sistema à u listessu livellu di astrazione. Chì, à u turnu, permette di gestisce stu sistema assai direttamente da u codice, da i sviluppatori, senza l'implicazione attiva di l'amministratori. I sviluppatori pensanu chì un DBMS separatu era necessariu per u novu sottuprogettu - faciule! hà scrittu un schedariu yaml, l'hà caricatu in u cluster è avete finitu.
È sicuru, u funziunamentu internu hè assai simplificatu. Dìmi, quante volte avete chjusu l'ochji quandu un novu membru di a squadra mette e so mani in a basa di dati di cummattimentu per u travagliu? Qualessu, in fattu, hè l'unicu chì avete è hè spinning right now ? Di sicuru, simu tutti l'adulti quì, è in un locu avemu una copia di salvezza fresca, è ancu più luntanu - daretu à u scaffale cù i cucumari di a nanna è i vechji skis - una altra copia di salvezza, forsi ancu in un magazzinu friddu, perchè u vostru uffiziu era digià in focu una volta. Ma tuttu u listessu, ogni introduzione di un novu membru di a squadra cù accessu à l'infrastruttura di cummattimentu è, sicuru, à a basa di dati di cummattimentu hè un bucket di validol per tutti intornu. Ebbè, quale u cunnosci, un novu, forse hè incruciatu ? Hè spaventosa, sarete d'accordu.
A cuntainerizazione è, in fattu, a topologia fisica distribuita di a basa di dati di u vostru prughjettu aiuta à evità tali mumenti di validazione. Ùn avete micca fiducia in un novu? OK! Damu u so propiu cluster per travaglià è disconnect a basa di dati da l'altri clusters - sincronizazione solu per push manuale è rotazione sincrona di duie chjave (una per u capu di a squadra, l'altra per l'amministratore). È tutti sò felici.
È avà hè u tempu di cambià in l'avversari di u clustering di basa di dati.
Latu scuru
Argumentendu perchè ùn vale a pena di cuntene a basa di dati è di cuntinuà à eseguisce nantu à un servitore cintrali, ùn ci abbatteremu micca à a retorica di l'ortodossie è dichjarazioni cum'è "i missiavu hà gestitu e basa di dati nantu à hardware, è cusì avemu!" Invece, pruvemu à vene cun una situazione in quale a cuntainerizazione pagherebbe veramente dividendi tangibili.
Agree, i prughjetti chì veramente bisognu di una basa in un cuntinuu pò esse cuntatu nantu à i diti di una manu per micca u megliu operatore di fresa. Per a maiò parte, ancu l'usu di k8s o Docker Swarm stessu hè redundant - abbastanza spessu sti arnesi sò ricursu per via di l'hype generale di tecnulugii è l'attitudini di u "onnipotente" in a persona di i generi per spinghje tuttu in u nuvole è cuntenituri. Ebbè, perchè avà hè di moda è tutti facenu.
In almenu a mità di i casi, l'usu di Kubernetis o solu Docker in un prughjettu hè redundante. U prublema hè chì micca tutti i squadre o l'imprese di outsourcing assuciati per mantene l'infrastruttura di u cliente sò cuscenti di questu. Hè peghju quandu i cuntenituri sò imposti, perchè custa una certa quantità di muniti à u cliente.
In generale, ci hè una opinione chì a mafia docker / cube hè stupidu sfracicà i clienti chì esternalizzanu questi prublemi di infrastruttura. Dopu tuttu, per travaglià cù clusters, avemu bisognu di ingegneri chì sò capaci di questu è in generale capiscenu l'architettura di a suluzione implementata. Avemu digià descrittu u nostru casu cù a publicazione di a Republica - quì avemu furmatu a squadra di u cliente per travaglià in a realità di Kubernetis, è tutti sò stati soddisfatti. È era decente. Spessu, i "implementatori" di k8 piglianu in ostaggio l'infrastruttura di u cliente - perchè avà solu capiscenu cumu tuttu funziona quì; ùn ci sò micca specialisti da parte di u cliente.
Avà imaginate chì in questu modu avemu outsource micca solu a parte di u servitore web, ma ancu u mantenimentu di a basa di dati. Avemu dettu chì BD hè u core, è a perdita di u cori hè fatale per ogni urganismu vivente. In corta, e prospettive ùn sò micca u megliu. Allora, invece di l'hype Kubernetis, assai prughjetti ùn deve micca solu di a tarifa normale per AWS, chì risolverà tutti i prublemi cù a carica nantu à u so situ / prughjettu. Ma AWS ùn hè più di moda, è i show-off valenu più di soldi - sfurtunatamenti, ancu in l'ambiente IT.
OK. Forse u prugettu hà veramente bisognu di clustering, ma se tuttu hè chjaru cù l'applicazioni senza statu, allora cumu pudemu urganizà una cunnessione di rete decente per una basa di dati clustered?
Se parlemu di una soluzione di ingegneria senza saldatura, chì hè ciò chì a transizione à k8s hè, allora u nostru principale mal di testa hè a replicazione di dati in una basa di dati clustered. Certi DBMS sò inizialmente abbastanza fideli à a distribuzione di dati trà e so istanze individuali. Parechji altri ùn sò micca cusì accolti. È abbastanza spessu l'argumentu principale in a scelta di un DBMS per u nostru prughjettu ùn hè micca a capacità di riplicà cù costi minimi di risorse è ingegneria. Soprattuttu se u prugettu ùn era micca inizialmente pianificatu cum'è un microserviziu, ma solu evoluzione in questa direzzione.
Pensemu chì ùn ci hè micca bisognu di parlà di a velocità di e unità di rete - sò lenti. Quelli. Ùn avemu micca una vera opportunità, se qualcosa succede, per riavvia una istanza DBMS in un locu induve ci hè più, per esempiu, putenza di processore o RAM libera. Intramu assai rapidamente in a prestazione di u sottosistema di discu virtualizatu. In cunsiquenza, u DBMS deve esse inchiodatu à u so propiu gruppu persunale di macchine situate in prossimità. O hè necessariu di qualchì manera separatamente rinfriscà a sincronizazione di dati abbastanza veloce per e riserve supposte.
Cuntinuà u tema di i sistemi di schedarii virtuali: Docker Volumes, sfurtunatamenti, ùn sò micca senza prublemi. In generale, in una materia cum'è l'almacenamiento di dati affidabile à longu andà, vogliu fà fà cù i schemi più tecnichi simplici. È aghjunghje una nova capa di astrazione da u FS di u cuntinuu à u FS di l'ospite parentale hè un risicu in sè stessu. Ma quandu u funziunamentu di u sistema di supportu di containerizazione scontra ancu difficultà cù a trasmissione di dati trà sti strati, allora hè veramente un disastru. À u mumentu, a maiò parte di i prublemi cunnisciuti da l'umanità prugressiva pare chì sò stati sradicati. Ma capisci, u più cumplessu u mecanismu, più faciule si rompe.
In vista di tutte queste "aventure", hè assai più prufittuosa è più faciule di mantene a basa di dati in un locu, è ancu s'ellu avete bisognu di cuntainerizà l'applicazione, lasciatela correre da sola è attraversu a porta di distribuzione riceve una cumunicazione simultanea cù l'applicazione. basa di dati, chì serà lettu è scrittu solu una volta è In un locu. Stu approcciu riduce a probabilità di errore è di desincronizazione à u minimu.
À chì conducemu ? Inoltre, a cuntainerizazione di basa di dati hè appruvata induve ci hè un veru bisognu. Ùn pudete micca stuff una basa di dati full-app è girallu cum'è s'ellu avete duie decine di microservizi - ùn funziona micca cusì. È questu deve esse chjaramente capitu.
Invece di u realizatu
Sè vo site aspittendu una cunclusione chjara "per virtualizà a basa di dati o micca", allora vi deluderemu: ùn serà micca quì. Perchè quandu crea ogni suluzione infrastrutturali, unu deve esse guidatu micca da a moda è u prugressu, ma, prima di tuttu, da u sensu cumunu.
Ci sò prughjetti per i quali i principii è l'arnesi chì venenu cù Kubernetis si adattanu perfettamente, è in tali prughjetti ci hè a pace almenu in l'area di backend. E ci sò prughjetti chì ùn anu micca bisognu di containerizazione, ma una infrastruttura di servitore normale, perchè fundamentalmente ùn ponu micca rescale à u mudellu di cluster di microserviziu, perchè cascanu.
Source: www.habr.com