Els núvols són com una caixa màgica: demaneu què necessiteu i els recursos apareixen del no-res. Màquines virtuals, bases de dades, xarxa: tot això només us pertany. Hi ha altres inquilins de núvols, però en el teu Univers ets l'únic governant. Estàs segur que sempre rebràs els recursos necessaris, no tens en compte ningú i decideixes de manera independent com serà la xarxa. Com funciona aquesta màgia que fa que el núvol assigni recursos de manera elàstica i aïlli completament els inquilins els uns dels altres?
El núvol AWS és un sistema mega-súper complex que ha anat evolucionant evolutivament des del 2006. Part d'aquest desenvolupament va tenir lloc Vasili Pantiukhin - Arquitecte de serveis web d'Amazon. Com a arquitecte, obté una mirada interna no només al resultat final, sinó també als reptes que supera AWS. Com més gran sigui la comprensió de com funciona el sistema, més gran serà la confiança. Per tant, Vasily compartirà els secrets dels serveis al núvol d'AWS. A continuació es mostra el disseny de servidors físics AWS, escalabilitat elàstica de bases de dades, una base de dades d'Amazon personalitzada i mètodes per augmentar el rendiment de les màquines virtuals alhora que es redueixen el seu preu. El coneixement dels enfocaments arquitectònics d'Amazon us ajudarà a utilitzar els serveis d'AWS de manera més eficaç i us pot donar noves idees per crear les vostres pròpies solucions.
Sobre el ponent: Vasily Pantyukhin () va començar com a administrador d'Unix a empreses .ru, va treballar en un gran maquinari Sun Microsystem durant 6 anys i va predicar un món centrat en dades a EMC durant 11 anys. Naturalment, va evolucionar cap a núvols privats i el 2017 va passar als públics. Ara ofereix assessorament tècnic per ajudar a viure i desenvolupar-se al núvol AWS.
Exempció de responsabilitat: tot el que es mostra a continuació és l'opinió personal de Vasily i pot no coincidir amb la posició d'Amazon Web Services. L'informe en què es basa l'article està disponible al nostre canal de YouTube.
Per què parlo del dispositiu Amazon?
El meu primer cotxe tenia una transmissió manual. Va ser fantàstic per la sensació que podia conduir el cotxe i tenir-ne un control total. També em va agradar que almenys entengués aproximadament el principi del seu funcionament. Naturalment, vaig imaginar que l'estructura de la caixa era força primitiva, una cosa com una caixa de canvis en una bicicleta.
Tot va ser genial, excepte una cosa: encallat en embussos de trànsit. Sembla que estàs assegut i no fas res, però estàs constantment canviant de marxa, pressionant l'embragatge, el gas, el fre: realment et cansa. El problema de l'embotellament es va solucionar parcialment quan la família va aconseguir un cotxe automàtic. Mentre conduïa, vaig tenir temps per pensar en alguna cosa i escoltar un audiollibre.
Un altre misteri va aparèixer a la meva vida, perquè vaig deixar completament d'entendre com funciona el meu cotxe. Un cotxe modern és un dispositiu complex. El cotxe s'adapta simultàniament a desenes de paràmetres diferents: pressió de gas, fre, estil de conducció, qualitat de la carretera. Ja no entenc com funciona.
Quan vaig començar a treballar al núvol d'Amazon, també era un misteri per a mi. Només aquest misteri és un ordre de magnitud més gran, perquè hi ha un conductor al cotxe, i a AWS n'hi ha milions. Tots els usuaris dirigeixen, premeu el gas i frenen simultàniament. És increïble que vagin on volen, és un miracle per a mi! El sistema s'adapta automàticament, escala i s'ajusta elàsticament a cada usuari perquè li sembli que està sol en aquest Univers.
La màgia es va esvair una mica quan més tard vaig entrar a treballar com a arquitecte a Amazon. Vaig veure quins problemes ens enfrontem, com els solucionem i com desenvolupem els serveis. Amb una comprensió creixent de com funciona el sistema, apareix més confiança en el servei. Per tant, vull compartir una imatge del que hi ha sota el capó del núvol AWS.
De què parlarem
Vaig triar un enfocament diversificat: vaig seleccionar 4 serveis interessants dels quals val la pena parlar.
Optimització del servidor. Núvols efímers amb una encarnació física: centres de dades físics on hi ha servidors físics que taulen, s'escalfen i parpellegen amb llums.
Funcions sense servidor (Lambda) és probablement el servei més escalable del núvol.
Escalat de bases de dades. Us explicaré com creem les nostres pròpies bases de dades escalables.
Escalat de la xarxa. L'última part en la qual obriré el dispositiu de la nostra xarxa. Això és una cosa meravellosa: tots els usuaris del núvol creuen que estan sols al núvol i no veuen cap altre inquilí.
Nota. Aquest article tractarà l'optimització del servidor i l'escalat de la base de dades. Considerarem l'escala de la xarxa al proper article. On són les funcions sense servidor? Es va publicar una transcripció separada sobre ells "" Parla de diversos mètodes d'escala diferents i analitza en detall la solució Firecracker: una simbiosi de les millors qualitats d'una màquina virtual i contenidors.
Servidors
El núvol és efímer. Però aquesta efímera encara té una encarnació física: els servidors. Inicialment, la seva arquitectura era clàssica. Xips x86 estàndard, targetes de xarxa, Linux, hipervisor Xen en què es van llançar màquines virtuals.
L'any 2012, aquesta arquitectura va afrontar força bé les seves tasques. Xen és un gran hipervisor, però té un gran inconvenient. En té prou sobrecàrrega elevada per a l'emulació del dispositiu. A mesura que estan disponibles targetes de xarxa o unitats SSD noves i més ràpides, aquesta sobrecàrrega es fa massa elevada. Com fer front a aquest problema? Vam decidir treballar en dos fronts alhora: optimitzar tant el maquinari com l'hipervisor. La tasca és molt seriosa.
Optimització de maquinari i hipervisor
Fer-ho tot alhora i fer-ho bé no funcionarà. El que era "bo" tampoc no estava clar inicialment.
Vam decidir adoptar un enfocament evolutiu: canviem un element important de l'arquitectura i el llencem a la producció.
Trepitgem cada rastell, escoltem queixes i suggeriments. Després canviem un altre component. Per tant, en petits increments, canviem radicalment tota l'arquitectura en funció dels comentaris dels usuaris i del suport.
La transformació va començar el 2013 amb el més complex: la xarxa. EN С3 En alguns casos, es va afegir una targeta d'accelerador de xarxa especial a la targeta de xarxa estàndard. Es va connectar literalment amb un cable de bucle curt al panell frontal. No és bonic, però no es veu al núvol. Però la interacció directa amb el maquinari va millorar fonamentalment la fluctuació i el rendiment de la xarxa.
A continuació, vam decidir millorar l'accés per bloquejar l'emmagatzematge de dades EBS - Elastic Block Storage. És una combinació de xarxa i emmagatzematge. La dificultat és que, mentre que les targetes Network Accelerator existien al mercat, no hi havia cap opció per comprar simplement maquinari Storage Accelerator. Així que vam recórrer a una startup Annapurna Labs, que ens va desenvolupar xips ASIC especials. Van permetre muntar volums EBS remots com a dispositius NVMe.
En casos C4 hem resolt dos problemes. El primer és que vam implementar una base per al futur de la tecnologia NVMe prometedora, però nova en aquell moment. En segon lloc, vam descarregar significativament el processador central transferint el processament de sol·licituds a EBS a una targeta nova. Va sortir bé, així que ara Annapurna Labs forma part d'Amazon.
Al novembre de 2017, ens vam adonar que era hora de canviar l'hipervisor.
El nou hipervisor es va desenvolupar basant-se en mòduls modificats del nucli KVM.
Va permetre reduir fonamentalment la sobrecàrrega de l'emulació del dispositiu i treballar directament amb nous ASIC. Instàncies С5 van ser les primeres màquines virtuals amb un nou hipervisor que funcionava sota el capó. Li vam posar nom Nitro.
Evolució de les instàncies a la línia del temps.
Tots els nous tipus de màquines virtuals que han aparegut des del novembre de 2017 s'executen en aquest hipervisor. Les instàncies de Bare Metal no tenen hipervisor, però també s'anomenen Nitro, ja que utilitzen targetes Nitro especialitzades.
Durant els dos anys següents, el nombre de tipus d'instàncies de Nitro va superar un parell de dotzenes: A1, C5, M5, T3 i altres.
Tipus d'instàncies.
Com funcionen les màquines Nitro modernes
Tenen tres components principals: l'hipervisor Nitro (que s'ha comentat més amunt), el xip de seguretat i les targetes Nitro.
Xip de seguretat integrat directament a la placa base. Controla moltes funcions importants, com ara controlar la càrrega del sistema operatiu amfitrió.
Targetes Nitro - N'hi ha de quatre tipus. Tots ells estan desenvolupats per Annapurna Labs i es basen en ASIC comuns. Alguns dels seus firmware també són comuns.
Quatre tipus de targetes Nitro.
Una de les targetes està dissenyada per funcionar xarxaVPC. Això és el que és visible a les màquines virtuals com a targeta de xarxa ENA - Adaptador de xarxa elàstic. També encapsula el trànsit quan el transmet a través d'una xarxa física (d'això en parlarem a la segona part de l'article), controla el tallafocs dels grups de seguretat i s'encarrega de l'encaminament i altres coses de la xarxa.
Les targetes seleccionades funcionen amb emmagatzematge en bloc EBS i els discos integrats al servidor. A la màquina virtual convidada apareixen com Adaptadors NVMe. També són responsables del xifratge de dades i de la vigilància del disc.
El sistema de targetes Nitro, hipervisor i xip de seguretat està integrat en una xarxa SDN o Xarxa definida per programari. Responsable de la gestió d'aquesta xarxa (Pla de control) targeta controladora.
Per descomptat, continuem desenvolupant nous ASIC. Per exemple, a finals del 2018 van llançar el xip Inferentia, que permet treballar de manera més eficient amb les tasques d'aprenentatge automàtic.
Xip del processador d'aprenentatge automàtic Inferentia.
Base de dades escalable
Una base de dades tradicional té una estructura en capes. Per simplificar molt, es distingeixen els nivells següents.
- SQL — El client i els despatxadors de sol·licituds hi treballen.
- Disposicions transaccions - Aquí tot està clar, ACID i tot això.
- memòria cau, que s'ofereix per grups de memòria intermèdia.
- Enregistrament — proporciona treball amb registres de refer. A MySQL s'anomenen Bin Logs, a PosgreSQL - Write Ahead Logs (WAL).
- emmagatzematge - Enregistrament directe al disc.
Estructura de bases de dades en capes.
Hi ha diferents maneres d'escalar les bases de dades: fragmentació, arquitectura Shared Nothing, discs compartits.
Tanmateix, tots aquests mètodes mantenen la mateixa estructura de base de dades monolítica. Això limita significativament l'escala. Per resoldre aquest problema, hem desenvolupat la nostra pròpia base de dades − Amazon Aurora. És compatible amb MySQL i PostgreSQL.
Amazon Aurora
La idea arquitectònica principal és separar els nivells d'emmagatzematge i registre de la base de dades principal.
De cara al futur, diré que també hem fet independent el nivell de memòria cau. L'arquitectura deixa de ser un monòlit i obtenim graus addicionals de llibertat en escalar blocs individuals.
Els nivells de registre i emmagatzematge estan separats de la base de dades.
Un SGBD tradicional escriu dades a un sistema d'emmagatzematge en forma de blocs. A Amazon Aurora, hem creat un emmagatzematge intel·ligent que pot parlar un idioma redo-logs. A l'interior, l'emmagatzematge converteix els registres en blocs de dades, supervisa la seva integritat i fa una còpia de seguretat automàticament.
Aquest enfocament us permet implementar coses tan interessants com clonació. Funciona fonamentalment més ràpid i econòmicament perquè no requereix crear una còpia completa de totes les dades.
La capa d'emmagatzematge s'implementa com un sistema distribuït. Consta d'un nombre molt gran de servidors físics. Cada registre de refer es processa i es desa simultàniament sis nusos. Això garanteix la protecció de dades i l'equilibri de càrrega.
L'escala de lectura es pot aconseguir mitjançant rèpliques adequades. L'emmagatzematge distribuït elimina la necessitat de sincronització entre la instància de la base de dades principal, a través de la qual escrivim les dades, i les rèpliques restants. Es garanteix que les dades actualitzades estan disponibles per a totes les rèpliques.
L'únic problema és la memòria cau de dades antigues a les rèpliques de lectura. Però aquest problema s'està solucionant transferència de tots els registres de refer a rèpliques a la xarxa interna. Si el registre es troba a la memòria cau, es marca com a incorrecte i es sobreescriu. Si no està a la memòria cau, simplement es descarta.
Hem ordenat l'emmagatzematge.
Com escalar els nivells de DBMS
Aquí, l'escala horitzontal és molt més difícil. Així que anem pel camí triturat escala vertical clàssica.
Suposem que tenim una aplicació que es comunica amb el SGBD a través d'un node mestre.
En escalar verticalment, assignem un nou node que tindrà més processadors i memòria.
A continuació, canviem l'aplicació del node mestre antic al nou. Els problemes sorgeixen.
- Això requerirà un temps d'inactivitat important de l'aplicació.
- El nou node mestre tindrà una memòria cau freda. El rendiment de la base de dades serà màxim només després que la memòria cau s'hagi escalfat.
Com millorar la situació? Configureu un servidor intermediari entre l'aplicació i el node mestre.
Què ens donarà això? Ara no cal que totes les aplicacions siguin redirigits manualment al nou node. El canvi es pot fer amb un servidor intermediari i és fonamentalment més ràpid.
Sembla que el problema s'ha resolt. Però no, encara patim la necessitat d'escalfar la memòria cau. A més, ha aparegut un nou problema: ara el proxy és un punt potencial de fallada.
Solució final amb Amazon Aurora sense servidor
Com hem resolt aquests problemes?
Va deixar un proxy. No es tracta d'una instància separada, sinó de tota una flota distribuïda de servidors intermediaris mitjançant els quals les aplicacions es connecten a la base de dades. En cas de fallada, qualsevol dels nodes es pot substituir gairebé a l'instant.
S'ha afegit un conjunt de nodes càlids de diferents mides. Per tant, si cal assignar un nou node de mida més gran o menor, està disponible immediatament. No cal esperar que es carregui.
Tot el procés d'escala està controlat per un sistema de control especial. La supervisió controla constantment l'estat del node mestre actual. Si detecta, per exemple, que la càrrega del processador ha assolit un valor crític, notifica al conjunt d'instàncies càlides la necessitat d'assignar un nou node.
Proxis distribuïts, instàncies càlides i monitorització.
Hi ha disponible un node amb la potència necessària. S'hi copien els grups de memòria intermèdia i el sistema comença a esperar un moment segur per canviar.
Normalment, el moment de canviar arriba amb força rapidesa. Aleshores se suspèn la comunicació entre el proxy i el node mestre antic, totes les sessions es canvien al nou node.
Es reprèn el treball amb la base de dades.
El gràfic mostra que la suspensió és realment molt curta. El gràfic blau mostra la càrrega i els passos vermells mostren els moments d'escala. Les caigudes a curt termini en el gràfic blau són precisament aquest curt retard.
Per cert, Amazon Aurora us permet estalviar completament i apagar la base de dades quan no s'utilitza, per exemple, els caps de setmana. Després d'aturar la càrrega, el DB redueix gradualment la seva potència i s'apaga durant un temps. Quan la càrrega torni, tornarà a pujar sense problemes.
A la següent part de la història sobre el dispositiu Amazon, parlarem de l'escala de la xarxa. Subscriu-te i estigueu atents perquè no us perdeu l'article.
En Vasily Pantyukhin farà un informe "" Quins patrons de disseny per a sistemes distribuïts utilitzen els desenvolupadors d'Amazon, quins són els motius dels errors del servei, què és l'arquitectura basada en cèl·lules, Constant Work, Shuffle Sharding, serà interessant. Menys d'un mes per a la conferència - . Augment final de preu el 24 d'octubre.
Font: www.habr.com