Cumva, din punct de vedere istoric, industria IT este împărțită în două tabere condiționate din orice motiv: cei care sunt „pentru” și cei care sunt „împotrivă”. Mai mult, subiectul litigiilor poate fi complet arbitrar. Care sistem de operare este mai bun: Win sau Linux? Pe un smartphone Android sau iOS? Ar trebui să depozitați totul în nori sau să-l puneți pe stocare RAID la rece și să puneți șuruburile într-un seif? Oamenii PHP au dreptul să fie numiți programatori? Aceste dispute sunt, uneori, de natură exclusiv existențială și nu au niciun alt temei decât interesul sportiv.
S-a întâmplat că, odată cu apariția containerelor și toată această bucătărie îndrăgită cu docker și k8-uri condiționate, au început dezbaterile „pentru” și „împotriva” utilizării de noi capabilități în diferite zone ale backend-ului. (Să facem o rezervare în avans că, deși Kubernetes va fi cel mai adesea indicat ca orchestrator în această discuție, alegerea acestui instrument special nu are o importanță fundamentală. În schimb, puteți înlocui cu oricare altul care vi se pare cel mai convenabil și mai familiar. .)
Și, se pare, aceasta ar fi o simplă dispută între două fețe ale aceleiași monede. La fel de lipsit de sens și de nemilos ca eterna confruntare dintre Win vs Linux, în care oameni adecvați există undeva la mijloc. Dar în cazul containerizării, nu totul este atât de simplu. De obicei, în astfel de dispute nu există partea dreaptă, dar în cazul containerelor „utilizați” sau „nu folosiți” pentru stocarea bazelor de date, totul se întoarce cu susul în jos. Pentru că într-un anumit sens, atât susținătorii, cât și oponenții acestei abordări au dreptate.
Partea luminoasă
Argumentul lui Light Side poate fi descris pe scurt într-o singură frază: „Bună ziua, 2k19 este în afara ferestrei!” Sună a populism, desigur, dar dacă aprofundezi situația în detaliu, are avantajele sale. Să le rezolvăm acum.
Să presupunem că aveți un proiect web mare. Ar fi putut fi construit inițial pe baza unei abordări de microservicii, sau la un moment dat a ajuns la el printr-o cale evolutivă - acest lucru nu este foarte important, de fapt. Ați împărțit proiectul nostru în microservicii separate, ați configurat orchestrarea, echilibrarea încărcăturii și scalarea. Și acum, cu conștiința curată, sorbi un mojito într-un hamac în timpul efectelor habra în loc să ridici serverele căzute. Dar în toate acțiunile trebuie să fii consecvent. Foarte des, doar aplicația în sine – codul – este containerizată. Ce altceva avem în afară de cod?
Așa e, date. Inima oricărui proiect sunt datele sale: acestea pot fi fie un DBMS tipic - MySQL, Postgre, MongoDB, fie stocare utilizată pentru căutare (ElasticSearch), stocare cheie-valoare pentru stocarea în cache - de exemplu, redis etc. În prezent, nu suntem vom vorbi despre opțiunile de implementare de backend strâmbe atunci când baza de date se blochează din cauza interogărilor scrise prost și, în schimb, vom vorbi despre asigurarea toleranței la erori a acestei baze de date chiar sub încărcarea clientului. La urma urmei, atunci când ne containerizăm aplicația și îi permitem să se scaleze liber pentru a procesa orice număr de solicitări primite, acest lucru crește în mod natural încărcarea bazei de date.
De fapt, canalul pentru accesarea bazei de date și serverul pe care rulează aceasta devin ochiul acului în frumosul nostru backend containerizat. În același timp, principalul motiv al virtualizării containerelor este mobilitatea și flexibilitatea structurii, ceea ce ne permite să organizăm cât mai eficient distribuția sarcinilor de vârf pe întreaga infrastructură disponibilă. Adică, dacă nu containerizăm și nu lansăm toate elementele existente ale sistemului în cluster, facem o greșeală foarte gravă.
Este mult mai logic să grupați nu numai aplicația în sine, ci și serviciile responsabile cu stocarea datelor. Prin gruparea și implementarea serverelor web care funcționează independent și distribuie încărcarea între ele în k8s, rezolvăm deja problema sincronizării datelor - aceleași comentarii la postări, dacă luăm ca exemplu unele platforme media sau blog. În orice caz, avem o reprezentare intra-cluster, chiar virtuală, a bazei de date ca un ExternalService. Întrebarea este că baza de date în sine nu este încă grupată - serverele web instalate în cub preiau informații despre modificări din baza noastră de date statică de luptă, care se rotește separat.
Simți o prindere? Folosim k8s sau Swarm pentru a distribui sarcina și pentru a evita blocarea serverului web principal, dar nu facem acest lucru pentru baza de date. Dar dacă baza de date se blochează, atunci întreaga noastră infrastructură în cluster nu are sens - la ce sunt utile paginile web goale care returnează o eroare de acces la baza de date?
De aceea este necesar să grupați nu numai serverele web, așa cum se face de obicei, ci și infrastructura bazei de date. Numai așa putem asigura o structură care funcționează pe deplin într-o singură echipă, dar în același timp independentă una de cealaltă. Mai mult decât atât, chiar dacă jumătate din backend-ul nostru „se prăbușește” sub sarcină, restul va supraviețui, iar sistemul de sincronizare a bazelor de date între ele în cadrul clusterului și capacitatea de a scala și de a implementa noi clustere vor ajuta la atingerea rapidă a capacității necesare. - dacă ar fi rafturi în centrul de date .
În plus, modelul bazei de date distribuit în clustere vă permite să duceți chiar această bază de date acolo unde este nevoie; Dacă vorbim despre un serviciu global, atunci este destul de ilogic să înveți un cluster web undeva în zona San Francisco și, în același timp, să trimiți pachete atunci când accesezi o bază de date în regiunea Moscovei și înapoi.
De asemenea, containerizarea bazei de date vă permite să construiți toate elementele sistemului la același nivel de abstractizare. Ceea ce, la rândul său, face posibilă gestionarea acestui sistem direct din cod, de către dezvoltatori, fără implicarea activă a administratorilor. Dezvoltatorii au crezut că este nevoie de un SGBD separat pentru noul subproiect - ușor! a scris un fișier yaml, l-am încărcat în cluster și ați terminat.
Și, desigur, funcționarea internă este mult simplificată. Spune-mi, de câte ori ai închis ochii când un nou membru al echipei și-a pus mâinile în baza de date de luptă pentru muncă? Care, de fapt, este singurul pe care îl ai și se învârte chiar acum? Desigur, suntem cu toții adulți aici și undeva avem o rezervă proaspătă, și chiar mai departe - în spatele raftului cu castraveții bunicii și schiurile vechi - o altă rezervă, poate chiar într-un depozit frigorific, pentru că biroul tău era deja în flăcări odată. Dar totuși, fiecare introducere a unui nou membru al echipei cu acces la infrastructura de luptă și, bineînțeles, la baza de date de luptă este o găleată de validol pentru toată lumea din jur. Ei bine, cine îl cunoaște, un începător, poate că are mâinile încrucișate? E înfricoșător, vei fi de acord.
Containerizarea și, de fapt, topologia fizică distribuită a bazei de date a proiectului dumneavoastră ajută la evitarea unor astfel de momente de validare. Nu ai încredere într-un începător? BINE! Să-i dăm propriul său cluster cu care să lucreze și să deconectăm baza de date de la celelalte clustere - sincronizare doar prin apăsare manuală și rotație sincronă a două taste (una pentru liderul echipei, cealaltă pentru administrator). Și toată lumea este fericită.
Și acum este timpul să ne transformăm în oponenți ai grupării bazelor de date.
Partea întunecată
Argumentând de ce nu merită să containerizați baza de date și să o rulăm în continuare pe un server central, nu ne vom apleca la retorica ortodoxiilor și a afirmațiilor de genul „bunicii au condus bazele de date pe hardware, la fel și noi!” În schimb, să încercăm să venim cu o situație în care containerizarea ar plăti efectiv dividende tangibile.
De acord, proiectele care au nevoie într-adevăr de o bază într-un container pot fi numărate pe degetele unei mâini de către cel mai bun operator de frezat. În cea mai mare parte, chiar și utilizarea k8s sau Docker Swarm în sine este redundantă - destul de des se recurge la aceste instrumente din cauza hype-ului general al tehnologiilor și a atitudinilor „atotputernicului” în persoana genurilor de a împinge totul în nori și containere. Ei bine, pentru că acum e la modă și toată lumea o face.
În cel puțin jumătate din cazuri, utilizarea Kubernetis sau doar Docker pe un proiect este redundantă. Problema este că nu toate echipele sau companiile de outsourcing angajate pentru întreținerea infrastructurii clientului sunt conștiente de acest lucru. Este mai rău când sunt impuse containere, deoarece costă o anumită cantitate de monede pentru client.
În general, există o opinie că mafia docker/cube zdrobește prostește clienții care externalizează aceste probleme de infrastructură. La urma urmei, pentru a lucra cu clustere, avem nevoie de ingineri capabili de acest lucru și care înțeleg în general arhitectura soluției implementate. Am descris deja odată cazul nostru cu publicația Republic - acolo am pregătit echipa clientului să lucreze în realitățile Kubernetis și toată lumea a fost mulțumită. Și a fost decent. Adesea, „implementatorii” k8s iau infrastructura clientului ostatic - pentru că acum doar ei înțeleg cum funcționează totul acolo; nu există specialiști de partea clientului.
Acum imaginați-vă că în acest fel externalizăm nu numai partea de server web, ci și întreținerea bazei de date. Am spus că BD este inima, iar pierderea inimii este fatală pentru orice organism viu. Pe scurt, perspectivele nu sunt cele mai bune. Deci, în loc de hype Kubernetis, multe proiecte pur și simplu nu ar trebui să se deranjeze cu tariful normal pentru AWS, care va rezolva toate problemele cu încărcarea de pe site-ul/proiectul lor. Dar AWS nu mai este la modă, iar show-off-urile valorează mai mult decât bani - din păcate, și în mediul IT.
BINE. Poate că proiectul chiar are nevoie de clustering, dar dacă totul este clar cu aplicațiile fără stat, atunci cum putem organiza o conectivitate decentă la rețea pentru o bază de date în cluster?
Dacă vorbim despre o soluție de inginerie fără întreruperi, care este ceea ce este tranziția la k8s, atunci principala noastră durere de cap este replicarea datelor într-o bază de date grupată. Unele SGBD-uri sunt inițial destul de loiale distribuției de date între instanțele lor individuale. Mulți alții nu sunt atât de primitori. Și destul de des, principalul argument în alegerea unui SGBD pentru proiectul nostru nu este capacitatea de a replica cu resurse minime și costuri de inginerie. Mai ales dacă proiectul nu a fost planificat inițial ca un microserviciu, ci pur și simplu a evoluat în această direcție.
Credem că nu este nevoie să vorbim despre viteza unităților de rețea - acestea sunt lente. Acestea. Încă nu avem o oportunitate reală, dacă se întâmplă ceva, de a reporni o instanță DBMS undeva unde există mai multă putere, de exemplu, procesor sau RAM liberă. Ne vom întâlni foarte repede cu performanța subsistemului de disc virtualizat. În consecință, SGBD-ul trebuie să fie fixat în propriul set personal de mașini situate în imediata apropiere. Sau este necesar să se răcească cumva separat sincronizarea datelor suficient de rapidă pentru presupusele rezerve.
Continuând subiectul sistemelor de fișiere virtuale: Docker Volumes, din păcate, nu sunt fără probleme. În general, într-o chestiune precum stocarea de date fiabilă pe termen lung, aș dori să mă mulțumesc cu schemele cele mai simple din punct de vedere tehnic. Și adăugarea unui nou strat de abstractizare din FS al containerului la FS al gazdei părinte este un risc în sine. Dar atunci când funcționarea sistemului de suport pentru containerizare întâmpină și dificultăți în transmiterea datelor între aceste straturi, atunci este într-adevăr un dezastru. În acest moment, majoritatea problemelor cunoscute de umanitatea progresistă par să fi fost eradicate. Dar înțelegi, cu cât mecanismul este mai complex, cu atât se rupe mai ușor.
În lumina tuturor acestor „aventuri”, este mult mai profitabil și mai ușor să păstrați baza de date într-un singur loc și, chiar dacă trebuie să containerizați aplicația, lăsați-o să ruleze singură și prin gateway-ul de distribuție să primiți comunicare simultană cu baza de date, care va fi citită și scrisă o singură dată și Într-un singur loc. Această abordare reduce probabilitatea erorilor și a desincronizării la minimum.
La ce ducem? Mai mult, containerizarea bazei de date este adecvată acolo unde există o nevoie reală de ea. Nu puteți umple o bază de date cu aplicații complete și o puteți roti ca și cum ați avea două duzini de microservicii - nu funcționează așa. Și acest lucru trebuie înțeles clar.
În loc de ieșire
Dacă așteptați o concluzie clară „să virtualizați sau nu baza de date”, atunci vă vom dezamăgi: nu va fi aici. Pentru că atunci când se creează orice soluție de infrastructură, trebuie să ne ghidăm nu după modă și progres, ci, în primul rând, după bunul simț.
Sunt proiecte pentru care principiile și instrumentele care vin cu Kubernetis se potrivesc perfect, iar în astfel de proiecte este liniște cel puțin în zona backend. Și există proiecte care nu au nevoie de containerizare, ci de o infrastructură de server normală, pentru că în mod fundamental nu pot redimensiona la modelul de cluster de microservicii, pentru că vor cădea.
Sursa: www.habr.com