Skyer er som en magisk boks – du spør hva du trenger, og ressursene dukker opp fra ingensteds. Virtuelle maskiner, databaser, nettverk - alt dette tilhører bare deg. Det finnes andre skyleietakere, men i universet ditt er du eneherskeren. Du er sikker på at du alltid vil motta de nødvendige ressursene, du tar ikke hensyn til noen, og du bestemmer uavhengig hvordan nettverket vil være. Hvordan fungerer denne magien som gjør at skyen elastisk allokerer ressurser og fullstendig isolerer leietakere fra hverandre?
AWS-skyen er et mega-superkomplekst system som har utviklet seg evolusjonært siden 2006. En del av denne utviklingen fant sted Vasily Pantyukhin - Amazon Web Services Architect. Som arkitekt får han et innblikk ikke bare på sluttresultatet, men også på utfordringene AWS overvinner. Jo større forståelse for hvordan systemet fungerer, jo større tillit. Derfor vil Vasily dele hemmelighetene til AWS skytjenester. Nedenfor er utformingen av fysiske AWS-servere, elastisk databaseskalerbarhet, en tilpasset Amazon-database og metoder for å øke ytelsen til virtuelle maskiner og samtidig redusere prisen. Kunnskap om Amazons arkitektoniske tilnærminger vil hjelpe deg å bruke AWS-tjenester mer effektivt og kan gi deg nye ideer for å bygge dine egne løsninger.
Om foredragsholderen: Vasily Pantyukhin () startet som Unix-administrator hos .ru-selskaper, jobbet med stor Sun Microsystem-maskinvare i 6 år, og forkynte en datasentrisk verden ved EMC i 11 år. Det utviklet seg naturlig til private skyer, og i 2017 flyttet det til offentlige. Nå gir han tekniske råd for å hjelpe til med å leve og utvikle seg i AWS-skyen.
Ansvarsfraskrivelse: alt nedenfor er Vasilys personlige mening og kan ikke sammenfalle med posisjonen til Amazon Web Services. Rapporten som artikkelen er basert på er tilgjengelig på vår YouTube-kanal.
Hvorfor snakker jeg om Amazon-enheten?
Min første bil hadde manuell girkasse. Det var flott på grunn av følelsen av at jeg kunne kjøre bilen og ha full kontroll over den. Jeg likte også at jeg i det minste omtrent forsto prinsippet om driften. Naturligvis så jeg for meg at strukturen til boksen var ganske primitiv - noe som en girkasse på en sykkel.
Alt var flott, bortsett fra én ting - fast i trafikkork. Det virker som om du sitter og ikke gjør noe, men du skifter stadig gir, trykker på clutch, gass, bremser - det gjør deg virkelig sliten. Trafikkproblemet ble delvis løst da familien fikk automatbil. Mens jeg kjørte, fikk jeg tid til å tenke på noe og høre på en lydbok.
Et annet mysterium dukket opp i livet mitt, fordi jeg sluttet helt å forstå hvordan bilen min fungerer. En moderne bil er en kompleks enhet. Bilen tilpasser seg samtidig til dusinvis av forskjellige parametere: gasstrykk, brems, kjørestil, veikvalitet. Jeg forstår ikke hvordan det fungerer lenger.
Da jeg begynte å jobbe med Amazon-skyen, var det også et mysterium for meg. Bare dette mysteriet er en størrelsesorden større, fordi det er én sjåfør i bilen, og i AWS er det millioner av dem. Alle brukere styrer, trykker på gassen og bremser samtidig. Det er utrolig at de går dit de vil – det er et mirakel for meg! Systemet tilpasser seg automatisk, skalerer og tilpasser seg elastisk til hver bruker slik at det ser ut til at han er alene i dette universet.
Magien tok litt av da jeg senere kom på jobb som arkitekt hos Amazon. Jeg så hvilke problemer vi står overfor, hvordan vi løser dem, og hvordan vi utvikler tjenester. Med økende forståelse for hvordan systemet fungerer, vises mer tillit til tjenesten. Så jeg vil dele et bilde av hva som er under panseret til AWS-skyen.
Hva skal vi snakke om
Jeg valgte en diversifisert tilnærming - jeg valgte 4 interessante tjenester som er verdt å snakke om.
Serveroptimalisering. Kortvarige skyer med en fysisk legemliggjøring: fysiske datasentre der det er fysiske servere som nynner, varmes opp og blinker med lys.
Serverløse funksjoner (Lambda) er sannsynligvis den mest skalerbare tjenesten i skyen.
Databaseskalering. Jeg skal fortelle deg om hvordan vi bygger våre egne skalerbare databaser.
Nettverksskalering. Den siste delen der jeg vil åpne enheten til nettverket vårt. Dette er en fantastisk ting - hver skybruker tror at han er alene i skyen og ikke ser andre leietakere i det hele tatt.
Merk. Denne artikkelen vil diskutere serveroptimalisering og databaseskalering. Vi vil vurdere nettverksskalering i neste artikkel. Hvor er de serverløse funksjonene? Det ble publisert en egen utskrift om dem "" Den snakker om flere forskjellige skaleringsmetoder, og diskuterer i detalj Firecracker-løsningen - en symbiose av de beste egenskapene til en virtuell maskin og containere.
Servere
Skyen er flyktig. Men denne flyktigheten har fortsatt en fysisk legemliggjøring - servere. Opprinnelig var arkitekturen deres klassisk. Standard x86 brikkesett, nettverkskort, Linux, Xen hypervisor som virtuelle maskiner ble kjørt på.
I 2012 taklet denne arkitekturen sine oppgaver ganske bra. Xen er en flott hypervisor, men den har en stor ulempe. Han har nok høy overhead for enhetsemulering. Etter hvert som nye, raskere nettverkskort eller SSD-stasjoner blir tilgjengelige, blir denne overheaden for høy. Hvordan håndtere dette problemet? Vi bestemte oss for å jobbe på to fronter samtidig - optimalisere både maskinvare og hypervisor. Oppgaven er svært alvorlig.
Optimalisering av maskinvare og hypervisor
Å gjøre alt på en gang og gjøre det bra vil ikke fungere. Hva som var "bra" var også uklart i utgangspunktet.
Vi bestemte oss for å ta en evolusjonær tilnærming - vi endrer ett viktig element i arkitekturen og setter det i produksjon.
Vi tråkker på hver rake, lytter til klager og forslag. Så endrer vi en annen komponent. Så, i små trinn, endrer vi radikalt hele arkitekturen basert på tilbakemeldinger fra brukere og støtte.
Transformasjonen begynte i 2013 med det mest komplekse - nettverket. I S3 Forekomster ble et spesielt nettverksakseleratorkort lagt til standardnettverkskortet. Den ble bokstavelig talt koblet til med en kort loopback-kabel på frontpanelet. Det er ikke pent, men det er ikke synlig i skyen. Men direkte interaksjon med maskinvare forbedret jitter og nettverksgjennomstrømning fundamentalt.
Deretter bestemte vi oss for å forbedre tilgangen til blokkering av datalagring EBS - Elastic Block Storage. Det er en kombinasjon av nettverk og lagring. Vanskeligheten er at mens Network Accelerator-kort eksisterte på markedet, var det ingen mulighet til å kjøpe Storage Accelerator-maskinvare. Så vi vendte oss til en oppstart Annapurna Labs, som utviklet spesielle ASIC-brikker for oss. De tillot eksterne EBS-volumer å bli montert som NVMe-enheter.
I tilfeller C4 vi løste to problemer. Den første er at vi implementerte et grunnlag for fremtiden med lovende, men ny på den tiden, NVMe-teknologi. For det andre tømte vi den sentrale prosessoren betydelig ved å overføre behandlingen av forespørsler til EBS til et nytt kort. Det ble bra, så nå er Annapurna Labs en del av Amazon.
I november 2017 innså vi at det var på tide å endre selve hypervisoren.
Den nye hypervisoren ble utviklet basert på modifiserte KVM-kjernemoduler.
Det gjorde det mulig å fundamentalt redusere overheaden til enhetsemulering og arbeide direkte med nye ASIC-er. Forekomster S5 var de første virtuelle maskinene med en ny hypervisor under panseret. Vi ga ham navn Nitro.
Utvikling av forekomster på tidslinjen.
Alle nye typer virtuelle maskiner som har dukket opp siden november 2017 kjører på denne hypervisoren. Bare Metal-forekomster har ikke en hypervisor, men de kalles også Nitro, siden de bruker spesialiserte Nitro-kort.
I løpet av de neste to årene oversteg antallet typer Nitro-forekomster et par dusin: A1, C5, M5, T3 og andre.
Forekomsttyper.
Hvordan moderne Nitro-maskiner fungerer
De har tre hovedkomponenter: Nitro-hypervisoren (diskutert ovenfor), sikkerhetsbrikken og Nitro-kortene.
Sikkerhetsbrikke integrert direkte i hovedkortet. Den kontrollerer mange viktige funksjoner, for eksempel å kontrollere lasting av verts-OS.
Nitro kort – Det er fire typer av dem. Alle er utviklet av Annapurna Labs og er basert på vanlige ASIC-er. Noe av fastvaren deres er også vanlig.
Fire typer Nitro-kort.
Ett av kortene er laget for å fungere med NettverkVPC. Dette er det som er synlig i virtuelle maskiner som et nettverkskort ENA - Elastisk nettverksadapter. Den innkapsler også trafikk når den overføres gjennom et fysisk nettverk (vi snakker om dette i andre del av artikkelen), kontrollerer Security Groups brannmur og er ansvarlig for ruting og andre nettverksting.
Utvalgte kort fungerer med blokklagring EBS og disker som er innebygd i serveren. De vises til den virtuelle gjestemaskinen som NVMe-adaptere. De er også ansvarlige for datakryptering og diskovervåking.
Systemet med Nitro-kort, hypervisor og sikkerhetsbrikke er integrert i et SDN-nettverk eller Programvaredefinert nettverk. Ansvarlig for å administrere dette nettverket (Control Plane) kontrollkort.
Selvfølgelig fortsetter vi å utvikle nye ASIC-er. For eksempel, på slutten av 2018 ga de ut Inferentia-brikken, som lar deg jobbe mer effektivt med maskinlæringsoppgaver.
Inferentia Machine Learning prosessorbrikke.
Skalerbar database
En tradisjonell database har en lagdelt struktur. For å forenkle betydelig skilles følgende nivåer ut.
- SQL — klient- og forespørselsformidlere jobber med det.
- Bestemmelser transaksjoner – alt er klart her, ACID og alt det der.
- caching, som leveres av bufferpooler.
- Hogst — gir arbeid med gjenta logger. I MySQL kalles de Bin Logs, i PosgreSQL – Write Ahead Logs (WAL).
- lagring – direkte opptak til disk.
Lagdelt databasestruktur.
Det er forskjellige måter å skalere databaser på: sharding, Shared Nothing-arkitektur, delte disker.
Imidlertid opprettholder alle disse metodene den samme monolitiske databasestrukturen. Dette begrenser skaleringen betydelig. For å løse dette problemet utviklet vi vår egen database − Amazonas Aurora. Den er kompatibel med MySQL og PostgreSQL.
Amazonas Aurora
Den viktigste arkitektoniske ideen er å skille lagrings- og loggingsnivåene fra hoveddatabasen.
Når vi ser fremover, vil jeg si at vi også gjorde bufringsnivået uavhengig. Arkitekturen slutter å være en monolitt, og vi får ytterligere frihetsgrader i å skalere individuelle blokker.
Logg- og lagringsnivåene er atskilt fra databasen.
En tradisjonell DBMS skriver data til et lagringssystem i form av blokker. Hos Amazon Aurora har vi laget smart lagring som kan snakke språk gjøre om logger. Innvendig gjør lagringen logger om til datablokker, overvåker deres integritet og sikkerhetskopierer automatisk.
Denne tilnærmingen lar deg implementere slike interessante ting som kloning. Det fungerer grunnleggende raskere og mer økonomisk på grunn av det faktum at det ikke krever å lage en fullstendig kopi av alle data.
Lagringslaget er implementert som et distribuert system. Den består av et veldig stort antall fysiske servere. Hver gjenta-logg blir behandlet og lagret samtidig seks knop. Dette sikrer databeskyttelse og lastbalansering.
Leseskalering kan oppnås ved å bruke passende kopier. Distribuert lagring eliminerer behovet for synkronisering mellom hoveddatabaseforekomsten, som vi skriver data gjennom, og de gjenværende replikaene. Oppdaterte data er garantert tilgjengelige for alle replikaer.
Det eneste problemet er å bufre gamle data på leste replikaer. Men dette problemet blir løst overføring av alle gjenta logger til replikaer over det interne nettverket. Hvis loggen ligger i cachen, er den merket som feil og overskrevet. Hvis den ikke er i cachen, blir den ganske enkelt forkastet.
Vi ordnet opp i lageret.
Hvordan skalere DBMS-nivåer
Her er horisontal skalering mye vanskeligere. Så la oss gå nedover allfarvei klassisk vertikal skalering.
La oss anta at vi har en applikasjon som kommuniserer med DBMS gjennom en masternode.
Når vi skalerer vertikalt, tildeler vi en ny node som vil ha flere prosessorer og minne.
Deretter bytter vi applikasjonen fra den gamle hovednoden til den nye. Problemer oppstår.
- Dette vil kreve betydelig nedetid for programmet.
- Den nye masternoden vil ha kald cache. Databaseytelsen vil være maksimal først etter at cachen er varmet opp.
Hvordan forbedre situasjonen? Sett opp en proxy mellom applikasjonen og hovednoden.
Hva vil dette gi oss? Nå trenger ikke alle applikasjoner omdirigeres manuelt til den nye noden. Byttingen kan gjøres under en proxy og er grunnleggende raskere.
Det ser ut til at problemet er løst. Men nei, vi lider fortsatt av behovet for å varme opp cachen. I tillegg har et nytt problem dukket opp - nå er proxyen et potensielt feilpunkt.
Endelig løsning med Amazon Aurora serverløs
Hvordan løste vi disse problemene?
Etterlot en proxy. Dette er ikke en egen instans, men en hel distribuert flåte av proxyer som applikasjoner kobler til databasen gjennom. I tilfelle feil kan en hvilken som helst av nodene erstattes nesten umiddelbart.
Lagt til et basseng med varme noder i forskjellige størrelser. Derfor, hvis det er nødvendig å tildele en ny node av større eller mindre størrelse, er den umiddelbart tilgjengelig. Du trenger ikke å vente på at den skal lastes.
Hele skaleringsprosessen styres av et spesielt overvåkingssystem. Overvåking overvåker konstant tilstanden til den gjeldende masternoden. Hvis den for eksempel oppdager at prosessorbelastningen har nådd en kritisk verdi, varsler den poolen av varme tilfeller om behovet for å tildele en ny node.
Distribuerte fullmakter, varme instanser og overvåking.
En node med nødvendig kraft er tilgjengelig. Bufferbassenger kopieres til den, og systemet begynner å vente på et trygt øyeblikk for å bytte.
Vanligvis kommer øyeblikket for å bytte ganske raskt. Da blir kommunikasjonen mellom proxyen og den gamle masternoden suspendert, alle sesjoner byttes til den nye noden.
Arbeidet med databasen gjenopptas.
Grafen viser at fjæringen faktisk er veldig kort. Den blå grafen viser belastningen, og de røde trinnene viser skaleringsmomentene. Kortvarige fall i den blå grafen er nettopp den korte forsinkelsen.
Amazon Aurora lar deg forresten spare penger helt og slå av databasen når den ikke er i bruk, for eksempel i helgene. Etter å ha stoppet belastningen, reduserer DB gradvis strømmen og slår seg av i en stund. Når lasten kommer tilbake, vil den stige jevnt igjen.
I neste del av historien om Amazon-enheten snakker vi om nettverksskalering. Abonnere og følg med så du ikke går glipp av artikkelen.
På Vasily Pantyukhin vil gi en rapport "" Hvilke designmønstre for distribuerte systemer brukes av Amazon-utviklere, hva er årsakene til tjenestefeil, hva er cellebasert arkitektur, Constant Work, Shuffle Sharding - det blir interessant. Mindre enn en måned til konferansen - . 24. oktober endelig prisøkning.
Kilde: www.habr.com