Norii sunt ca o cutie magică - întrebi de ce ai nevoie, iar resursele apar de nicăieri. Mașini virtuale, baze de date, rețea - toate acestea vă aparțin numai dvs. Există și alți chiriași de nori, dar în Universul tău tu ești singurul conducător. Sunteți sigur că veți primi întotdeauna resursele necesare, nu țineți cont de nimeni și determinați independent cum va fi rețeaua. Cum funcționează această magie care face cloud-ul să aloce elastic resurse și să izoleze complet chiriașii unul de celălalt?
Cloud-ul AWS este un sistem mega-super complex care a evoluat evolutiv din 2006. O parte din această dezvoltare a avut loc Vasily Pantyukhin - Amazon Web Services Architect. În calitate de arhitect, el are o privire din interior nu numai asupra rezultatului final, ci și asupra provocărilor pe care AWS le depășește. Cu cât este mai mare înțelegerea modului în care funcționează sistemul, cu atât este mai mare încrederea. Prin urmare, Vasily va împărtăși secretele serviciilor cloud AWS. Mai jos este proiectarea serverelor fizice AWS, scalabilitatea elastică a bazei de date, o bază de date Amazon personalizată și metode pentru creșterea performanței mașinilor virtuale, reducând simultan prețul acestora. Cunoașterea abordărilor arhitecturale Amazon vă va ajuta să utilizați mai eficient serviciile AWS și vă poate oferi noi idei pentru a vă construi propriile soluții.
Despre vorbitor: Vasily Pantyukhin () a început ca administrator Unix la companii .ru, a lucrat la hardware-ul Sun Microsystem mare timp de 6 ani și a predicat o lume centrată pe date la EMC timp de 11 ani. A evoluat în mod natural în cloud-uri private, iar în 2017 a trecut la cele publice. Acum oferă consiliere tehnică pentru a vă ajuta să trăiți și să se dezvolte în cloudul AWS.
Disclaimer: totul de mai jos este opinia personală a lui Vasily și este posibil să nu coincidă cu poziția Amazon Web Services. Raportul pe care se bazează articolul este disponibil pe canalul nostru de YouTube.
De ce vorbesc despre dispozitivul Amazon?
Prima mea mașină avea transmisie manuală. A fost grozav din cauza sentimentului că aș putea conduce mașina și să am control complet asupra ei. Mi-a plăcut și că am înțeles cel puțin aproximativ principiul funcționării acestuia. Desigur, mi-am imaginat structura cutiei ca fiind destul de primitivă - ceva ca o cutie de viteze pe o bicicletă.
Totul a fost grozav, cu excepția unui singur lucru - blocat în ambuteiaje. Se pare că stai și nu faci nimic, dar schimbi constant vitezele, apeși ambreiajul, benzina, frâna - chiar te obosești. Problema ambuteiajului a fost parțial rezolvată când familia a primit o mașină automată. În timp ce conduceam, am avut timp să mă gândesc la ceva și să ascult o carte audio.
În viața mea a apărut un alt mister, pentru că am încetat complet să mai înțeleg cum funcționează mașina mea. O mașină modernă este un dispozitiv complex. Mașina se adaptează simultan la zeci de parametri diferiți: apăsarea gazului, frâna, stilul de condus, calitatea drumului. Nu mai înțeleg cum funcționează.
Când am început să lucrez pe cloud-ul Amazon, era și un mister pentru mine. Numai că acest mister este cu un ordin de mărime mai mare, pentru că în mașină există un singur șofer, iar în AWS sunt milioane. Toți utilizatorii conduc simultan, apasă pe accelerație și frână. Este uimitor că merg unde vor ei - este un miracol pentru mine! Sistemul se adaptează, scalează și se adaptează elastic în mod automat fiecărui utilizator, astfel încât acestuia să i se pară că este singur în acest Univers.
Magia a dispărut puțin când am venit mai târziu să lucrez ca arhitect la Amazon. Am văzut cu ce probleme ne confruntăm, cum le rezolvăm și cum dezvoltăm serviciile. Odată cu înțelegerea crescândă a modului în care funcționează sistemul, apare mai multă încredere în serviciu. Așa că vreau să împărtășesc o imagine a ceea ce se află sub capota cloudului AWS.
Despre ce ar trebui sa vorbim
Am ales o abordare diversificată - am selectat 4 servicii interesante despre care merită să vorbim.
Optimizarea serverului. Nori efemeri cu o întruchipare fizică: centre de date fizice în care există servere fizice care zumzăie, se încălzesc și clipesc cu lumini.
Funcții fără server (Lambda) este probabil cel mai scalabil serviciu din cloud.
Scalare baze de date. Vă voi spune despre cum ne construim propriile noastre baze de date scalabile.
Scalarea rețelei. Ultima parte în care voi deschide dispozitivul rețelei noastre. Acesta este un lucru minunat - fiecare utilizator de cloud crede că este singur în cloud și nu vede deloc alți chiriași.
Notă. Acest articol va discuta despre optimizarea serverului și scalarea bazei de date. Vom lua în considerare scalarea rețelei în articolul următor. Unde sunt funcțiile serverless? A fost publicată o transcriere separată despre ei „" Vorbește despre mai multe metode de scalare diferite și discută în detaliu soluția Firecracker - o simbioză a celor mai bune calități ale unei mașini virtuale și ale containerelor.
Servere
Norul este efemer. Dar această efemeritate are încă o întruchipare fizică - serverele. Inițial, arhitectura lor a fost clasică. Chipset x86 standard, plăci de rețea, Linux, hypervisor Xen pe care au fost lansate mașinile virtuale.
În 2012, această arhitectură și-a făcut față destul de bine sarcinilor sale. Xen este un hipervizor grozav, dar are un dezavantaj major. Are destule overhead mare pentru emularea dispozitivului. Pe măsură ce devin disponibile plăci de rețea sau unități SSD noi, mai rapide, această suprasarcină devine prea mare. Cum să faci față acestei probleme? Am decis să lucrăm pe două fronturi simultan - optimizați atât hardware-ul, cât și hypervisorul. Sarcina este foarte serioasă.
Optimizarea hardware și hypervisor
A face totul deodată și a le face bine nu va funcționa. Ce a fost „bun” nu era, de asemenea, clar inițial.
Am decis să adoptăm o abordare evolutivă - schimbăm un element important al arhitecturii și îl aruncăm în producție.
Călcăm pe fiecare greblă, ascultăm plângeri și sugestii. Apoi schimbam o alta componenta. Deci, în trepte mici, schimbăm radical întreaga arhitectură pe baza feedback-ului de la utilizatori și asistență.
Transformarea a început în 2013 cu cel mai complex lucru - rețeaua. ÎN S3 cazuri, o cartelă specială Network Accelerator a fost adăugată la placa de rețea standard. A fost conectat literalmente cu un cablu scurt loopback pe panoul frontal. Nu este frumos, dar nu se vede în nor. Dar interacțiunea directă cu hardware-ul a îmbunătățit în mod fundamental fluctuația și debitul rețelei.
Apoi am decis să îmbunătățim accesul la stocarea de date bloc EBS - Elastic Block Storage. Este o combinație de rețea și stocare. Dificultatea este că, în timp ce cardurile Network Accelerator existau pe piață, nu exista nicio opțiune de a cumpăra pur și simplu hardware Storage Accelerator. Așa că am apelat la un startup Laboratoarele Annapurna, care a dezvoltat cipuri ASIC speciale pentru noi. Au permis ca volumele EBS la distanță să fie montate ca dispozitive NVMe.
În cazuri C4 am rezolvat doua probleme. Primul este că am implementat o bază pentru viitorul tehnologiei NVMe promițătoare, dar nouă la acel moment. În al doilea rând, am descărcat semnificativ procesorul central, transferând procesarea cererilor către EBS pe un card nou. A ieșit bine, așa că acum Annapurna Labs face parte din Amazon.
Până în noiembrie 2017, ne-am dat seama că era timpul să schimbăm hypervisorul în sine.
Noul hypervisor a fost dezvoltat pe baza modulelor kernel-ului KVM modificate.
A făcut posibilă reducerea fundamentală a emulării dispozitivului și lucrul direct cu noile ASIC-uri. Instanțe S5 au fost primele mașini virtuale cu un nou hypervisor care rulează sub capotă. L-am numit Nitro.
Evoluția instanțelor pe linia temporală.
Toate tipurile noi de mașini virtuale care au apărut din noiembrie 2017 rulează pe acest hypervisor. Instanțele Bare Metal nu au un hypervisor, dar se mai numesc și Nitro, deoarece folosesc carduri Nitro specializate.
În următorii doi ani, numărul de tipuri de instanțe Nitro a depășit câteva zeci: A1, C5, M5, T3 și altele.
Tipuri de instanțe.
Cum funcționează mașinile moderne Nitro
Au trei componente principale: hipervizorul Nitro (discutat mai sus), cipul de securitate și cardurile Nitro.
Cip de securitate integrat direct in placa de baza. Controlează multe funcții importante, cum ar fi controlul încărcării sistemului de operare gazdă.
Carduri Nitro - Există patru tipuri de ele. Toate sunt dezvoltate de Annapurna Labs și se bazează pe ASIC-uri comune. Unele dintre firmware-urile lor sunt, de asemenea, comune.
Patru tipuri de carduri Nitro.
Una dintre carduri este concepută pentru a funcționa rețeaVPC. Acesta este ceea ce este vizibil în mașinile virtuale ca o placă de rețea ENA - Adaptor de rețea elastic. De asemenea, încapsulează traficul atunci când îl transmite printr-o rețea fizică (vom vorbi despre asta în a doua parte a articolului), controlează paravanul de protecție Security Groups și este responsabil pentru rutare și alte lucruri de rețea.
Cardurile selectate funcționează cu stocare în bloc EBS și discuri care sunt încorporate în server. Ele apar mașinii virtuale invitate ca adaptoare NVMe. Ei sunt, de asemenea, responsabili pentru criptarea datelor și monitorizarea discului.
Sistemul de carduri Nitro, hypervisor și cip de securitate este integrat într-o rețea SDN sau Rețea definită de software. Responsabil cu gestionarea acestei rețele (plan de control) card de controler.
Desigur, continuăm să dezvoltăm noi ASIC-uri. De exemplu, la sfârșitul lui 2018 au lansat cipul Inferentia, care vă permite să lucrați mai eficient cu sarcinile de învățare automată.
Cipul Inferentia Machine Learning Processor.
Baza de date scalabila
O bază de date tradițională are o structură stratificată. Pentru a simplifica foarte mult, se disting următoarele niveluri.
- SQL — clientul și dispecerii de solicitări lucrează la asta.
- Prevederi tranzacții - totul este clar aici, ACID și toate astea.
- stocarea în cache, care este oferit de pool-uri tampon.
- Logare — oferă lucrări cu jurnalele de refacere. În MySQL se numesc Bin Logs, în PosgreSQL - Write Ahead Logs (WAL).
- Depozitare – înregistrare directă pe disc.
Structură stratificată a bazei de date.
Există diferite moduri de a scala bazele de date: sharding, arhitectură Shared Nothing, discuri partajate.
Cu toate acestea, toate aceste metode mențin aceeași structură de bază de date monolitică. Acest lucru limitează semnificativ scalarea. Pentru a rezolva această problemă, am dezvoltat propria noastră bază de date − Amazon Aurora. Este compatibil cu MySQL și PostgreSQL.
Amazon Aurora
Ideea arhitecturală principală este de a separa nivelurile de stocare și de înregistrare din baza de date principală.
Privind în viitor, voi spune că am făcut și nivelul de cache independent. Arhitectura încetează să mai fie un monolit și obținem grade suplimentare de libertate în scalarea blocurilor individuale.
Nivelurile de înregistrare și stocare sunt separate de baza de date.
Un SGBD tradițional scrie date într-un sistem de stocare sub formă de blocuri. La Amazon Aurora, am creat stocare inteligentă care poate vorbi limba redo-log-uri. În interior, spațiul de stocare transformă jurnalele în blocuri de date, le monitorizează integritatea și face backup automat.
Această abordare vă permite să implementați lucruri atât de interesante ca clonarea. Funcționează în mod fundamental mai rapid și mai economic datorită faptului că nu necesită crearea unei copii complete a tuturor datelor.
Stratul de stocare este implementat ca un sistem distribuit. Este format dintr-un număr foarte mare de servere fizice. Fiecare jurnal de refacere este procesat și salvat simultan șase noduri. Acest lucru asigură protecția datelor și echilibrarea încărcăturii.
Scalare de citire poate fi realizată folosind replici adecvate. Stocarea distribuită elimină necesitatea sincronizării între instanța principală a bazei de date, prin care scriem date, și replicile rămase. Datele actualizate sunt garantate a fi disponibile pentru toate replicile.
Singura problemă este stocarea în cache a datelor vechi pe replicile citite. Dar această problemă se rezolvă transferul tuturor jurnalelor de refacere la replici prin rețeaua internă. Dacă jurnalul se află în cache, este marcat ca incorect și suprascris. Dacă nu este în cache, este pur și simplu aruncat.
Am aranjat depozitul.
Cum să scalați nivelurile DBMS
Aici, scalarea orizontală este mult mai dificilă. Deci haideți să mergem pe cărarea bătută scalare verticală clasică.
Să presupunem că avem o aplicație care comunică cu SGBD printr-un nod master.
La scalarea pe verticală, alocam un nou nod care va avea mai multe procesoare și memorie.
În continuare, comutăm aplicația de la vechiul nod master la cel nou. Apar probleme.
- Acest lucru va necesita un timp de nefuncționare semnificativ al aplicației.
- Noul nod master va avea cache rece. Performanța bazei de date va fi maximă numai după ce memoria cache s-a încălzit.
Cum să îmbunătățești situația? Configurați un proxy între aplicație și nodul principal.
Ce ne va oferi asta? Acum toate aplicațiile nu trebuie să fie redirecționate manual către noul nod. Comutarea se poate face sub un proxy și este fundamental mai rapidă.
Se pare că problema a fost rezolvată. Dar nu, încă suferim de nevoia de a încălzi cache-ul. În plus, a apărut o nouă problemă - acum proxy-ul este un potențial punct de eșec.
Soluție finală cu Amazon Aurora serverless
Cum am rezolvat aceste probleme?
A lăsat un proxy. Aceasta nu este o instanță separată, ci o întreagă flotă distribuită de proxy prin care aplicațiile se conectează la baza de date. În caz de defecțiune, oricare dintre noduri poate fi înlocuit aproape instantaneu.
S-a adăugat un grup de noduri calde de diferite dimensiuni. Prin urmare, dacă este necesar să se aloce un nou nod de dimensiune mai mare sau mai mică, acesta este disponibil imediat. Nu este nevoie să așteptați să se încarce.
Întregul proces de scalare este controlat de un sistem special de monitorizare. Monitorizarea monitorizează constant starea nodului master curent. Dacă detectează, de exemplu, că încărcarea procesorului a atins o valoare critică, anunță grupul de instanțe calde despre necesitatea alocarii unui nou nod.
Proxy distribuite, instanțe calde și monitorizare.
Este disponibil un nod cu puterea necesară. Pool-urile de buffer sunt copiate în acesta, iar sistemul începe să aștepte un moment sigur pentru a comuta.
De obicei, momentul trecerii vine destul de repede. Apoi comunicarea dintre proxy și vechiul nod master este suspendată, toate sesiunile sunt comutate la noul nod.
Lucrul cu baza de date reia.
Graficul arată că suspensia este într-adevăr foarte scurtă. Graficul albastru arată sarcina, iar pașii roșii arată momentele de scalare. Scăderile pe termen scurt în graficul albastru sunt tocmai acea întârziere scurtă.
Apropo, Amazon Aurora vă permite să economisiți complet bani și să opriți baza de date atunci când nu este utilizată, de exemplu, în weekend. După oprirea încărcăturii, DB-ul își reduce treptat puterea și se oprește pentru o perioadă de timp. Când sarcina revine, se va ridica din nou lin.
În următoarea parte a poveștii despre dispozitivul Amazon, vom vorbi despre scalarea rețelei. Abonati-va și rămâneți pe fază ca să nu ratați articolul.
Pe Vasily Pantyukhin va da un raport „" Ce modele de proiectare pentru sistemele distribuite sunt folosite de dezvoltatorii Amazon, care sunt motivele defecțiunilor serviciului, ce este arhitectura bazată pe celule, Constant Work, Shuffle Sharding - va fi interesant. Mai puțin de o lună până la conferință - . Creșterea finală a prețului pe 24 octombrie.
Sursa: www.habr.com