Skyer er som en magisk boks – du spørger, hvad du har brug for, og ressourcerne dukker bare op ud af ingenting. Virtuelle maskiner, databaser, netværk - alt dette tilhører kun dig. Der er andre skylejere, men i dit univers er du den eneste hersker. Du er sikker på, at du altid vil modtage de nødvendige ressourcer, du tager ikke hensyn til nogen, og du bestemmer selvstændigt, hvordan netværket vil være. Hvordan fungerer denne magi, der gør, at skyen elastisk allokerer ressourcer og fuldstændigt isolerer lejere fra hinanden?
AWS-skyen er et mega-superkomplekst system, der har udviklet sig evolutionært siden 2006. En del af denne udvikling fandt sted Vasily Pantyukhin - Amazon Web Services Arkitekt. Som arkitekt får han et indblik i, ikke kun på slutresultatet, men også på de udfordringer, AWS overvinder. Jo større forståelse for hvordan systemet fungerer, jo større tillid. Derfor vil Vasily dele hemmelighederne bag AWS cloud-tjenester. Nedenfor er designet af fysiske AWS-servere, elastisk databaseskalerbarhed, en tilpasset Amazon-database og metoder til at øge ydelsen på virtuelle maskiner og samtidig reducere deres pris. Viden om Amazons arkitektoniske tilgange vil hjælpe dig med at bruge AWS-tjenester mere effektivt og kan give dig nye ideer til at bygge dine egne løsninger.
Om taleren: Vasily Pantyukhin () startede som Unix-administrator hos .ru-virksomheder, arbejdede på stor Sun Microsystem-hardware i 6 år og prædikede en datacentreret verden på EMC i 11 år. Det udviklede sig naturligt til private skyer og flyttede i 2017 til offentlige skyer. Nu giver han teknisk rådgivning for at hjælpe med at leve og udvikle sig i AWS-skyen.
Ansvarsfraskrivelse: alt nedenfor er Vasilys personlige mening og falder muligvis ikke sammen med Amazon Web Services' position. Rapporten, som artiklen er baseret på, er tilgængelig på vores YouTube-kanal.
Hvorfor taler jeg om Amazon-enheden?
Min første bil havde manuel gearkasse. Det var fantastisk på grund af følelsen af, at jeg kunne køre bilen og have fuldstændig kontrol over den. Jeg kunne også godt lide, at jeg i det mindste nogenlunde forstod princippet om dens funktion. Naturligvis forestillede jeg mig, at boksens struktur var ret primitiv - noget som en gearkasse på en cykel.
Alt var fantastisk, bortset fra én ting - fast i trafikpropper. Det ser ud til, at du sidder og laver ingenting, men du skifter hele tiden gear, trykker på koblingen, gassen, bremsen - det gør dig virkelig træt. Problemet med trafikpropper blev delvist løst, da familien fik en automatvogn. Mens jeg kørte, havde jeg tid til at tænke over noget og lytte til en lydbog.
Et andet mysterium dukkede op i mit liv, fordi jeg holdt helt op med at forstå, hvordan min bil fungerer. En moderne bil er en kompleks enhed. Bilen tilpasser sig samtidigt til snesevis af forskellige parametre: gastryk, bremse, kørestil, vejkvalitet. Jeg forstår ikke, hvordan det fungerer længere.
Da jeg begyndte at arbejde på Amazon-skyen, var det også et mysterium for mig. Kun dette mysterium er en størrelsesorden større, fordi der er én chauffør i bilen, og i AWS er der millioner af dem. Alle brugere styrer, trykker på gas og bremser samtidigt. Det er fantastisk, at de går, hvor de vil – det er et mirakel for mig! Systemet tilpasser, skalerer og tilpasser sig automatisk til hver bruger, så det ser ud til, at han er alene i dette univers.
Magien forsvandt lidt, da jeg senere kom til at arbejde som arkitekt hos Amazon. Jeg så, hvilke problemer vi står over for, hvordan vi løser dem, og hvordan vi udvikler tjenester. Med stigende forståelse for, hvordan systemet fungerer, fremkommer der mere tillid til tjenesten. Så jeg vil gerne dele et billede af, hvad der er under hætten på AWS-skyen.
Hvad skal vi tale om
Jeg valgte en diversificeret tilgang - jeg udvalgte 4 interessante tjenester, der er værd at tale om.
Server optimering. Flygtige skyer med en fysisk udførelsesform: fysiske datacentre, hvor der er fysiske servere, der nynner, varmer op og blinker med lys.
Serverløse funktioner (Lambda) er nok den mest skalerbare tjeneste i skyen.
Database skalering. Jeg vil fortælle dig om, hvordan vi bygger vores egne skalerbare databaser.
Netværksskalering. Den sidste del, hvor jeg åbner enheden på vores netværk. Dette er en vidunderlig ting - enhver cloudbruger tror på, at han er alene i skyen og slet ikke ser andre lejere.
Bemærk. Denne artikel vil diskutere serveroptimering og databaseskalering. Vi vil overveje netværksskalering i den næste artikel. Hvor er de serverløse funktioner? Der blev udgivet et separat udskrift om dem "" Den taler om flere forskellige skaleringsmetoder og diskuterer i detaljer Firecracker-løsningen - en symbiose af de bedste kvaliteter ved en virtuel maskine og containere.
Servere
Skyen er flygtig. Men denne flygtigehed har stadig en fysisk legemliggørelse - servere. I starten var deres arkitektur klassisk. Standard x86 chipset, netværkskort, Linux, Xen hypervisor, hvor virtuelle maskiner blev lanceret.
I 2012 klarede denne arkitektur sine opgaver ganske godt. Xen er en fantastisk hypervisor, men den har en stor ulempe. Han har fået nok høj overhead til enhedsemulering. Efterhånden som nye, hurtigere netværkskort eller SSD-drev bliver tilgængelige, bliver denne overhead for høj. Hvordan skal man håndtere dette problem? Vi besluttede at arbejde på to fronter på én gang - optimere både hardware og hypervisor. Opgaven er meget alvorlig.
Optimering af hardware og hypervisor
At gøre alt på én gang og gøre det godt virker ikke. Hvad "godt" var, var også uklart i starten.
Vi besluttede at tage en evolutionær tilgang - vi ændrer et vigtigt element i arkitekturen og kaster det i produktion.
Vi træder på hver rive, lytter til klager og forslag. Så ændrer vi en anden komponent. Så i små trin ændrer vi radikalt hele arkitekturen baseret på feedback fra brugere og support.
Transformationen begyndte i 2013 med det mest komplekse - netværket. I С3 Forekomster blev der tilføjet et specielt Network Accelerator-kort til standardnetværkskortet. Det var bogstaveligt talt forbundet med et kort loopback-kabel på frontpanelet. Det er ikke kønt, men det er ikke synligt i skyen. Men direkte interaktion med hardware forbedrede fundamentalt jitter og netværksgennemstrømning.
Dernæst besluttede vi at forbedre adgangen til at blokere datalagring EBS - Elastic Block Storage. Det er en kombination af netværk og lagring. Vanskeligheden er, at mens Network Accelerator-kort eksisterede på markedet, var der ingen mulighed for blot at købe Storage Accelerator-hardware. Så vi henvendte os til en startup Annapurna Labs, der udviklede specielle ASIC-chips til os. De gjorde det muligt at montere eksterne EBS-enheder som NVMe-enheder.
I tilfælde C4 vi løste to problemer. Den første er, at vi implementerede et fundament for fremtiden med lovende, men ny på det tidspunkt, NVMe-teknologi. For det andet aflastede vi den centrale processor betydeligt ved at overføre behandlingen af anmodninger til EBS til et nyt kort. Det blev godt, så nu er Annapurna Labs en del af Amazon.
I november 2017 indså vi, at det var tid til at ændre selve hypervisoren.
Den nye hypervisor blev udviklet baseret på modificerede KVM-kernemoduler.
Det gjorde det muligt fundamentalt at reducere omkostningerne ved enhedsemulering og arbejde direkte med nye ASIC'er. Forekomster С5 var de første virtuelle maskiner med en ny hypervisor kørende under motorhjelmen. Vi navngav ham Nitro.
Udvikling af forekomster på tidslinjen.
Alle nye typer virtuelle maskiner, der er dukket op siden november 2017, kører på denne hypervisor. Bare Metal-forekomster har ikke en hypervisor, men de kaldes også Nitro, da de bruger specialiserede Nitro-kort.
I løbet af de næste to år oversteg antallet af typer Nitro-forekomster et par dusin: A1, C5, M5, T3 og andre.
Forekomsttyper.
Sådan fungerer moderne Nitro-maskiner
De har tre hovedkomponenter: Nitro-hypervisoren (diskuteret ovenfor), sikkerhedschippen og Nitro-kortene.
Sikkerhedschip integreret direkte i bundkortet. Det styrer mange vigtige funktioner, såsom at kontrollere indlæsningen af værts-OS.
Nitro kort - Der er fire typer af dem. Alle er udviklet af Annapurna Labs og er baseret på almindelige ASIC'er. Noget af deres firmware er også almindeligt.
Fire typer nitro-kort.
Et af kortene er designet til at arbejde med netværkVPC. Dette er, hvad der er synligt i virtuelle maskiner som et netværkskort ENA - Elastisk netværksadapter. Den indkapsler også trafik, når den transmitteres gennem et fysisk netværk (vi taler om dette i anden del af artiklen), styrer Security Groups firewall og er ansvarlig for routing og andre netværksting.
Udvalgte kort fungerer med bloklagring EBS og diske, der er indbygget i serveren. De vises for den virtuelle gæstmaskine som NVMe adaptere. De er også ansvarlige for datakryptering og diskovervågning.
Systemet med Nitro-kort, hypervisor og sikkerhedschip er integreret i et SDN-netværk eller Softwaredefineret netværk. Ansvarlig for at administrere dette netværk (Control Plane) controller kort.
Selvfølgelig fortsætter vi med at udvikle nye ASIC'er. For eksempel udgav de i slutningen af 2018 Inferentia-chippen, som giver dig mulighed for at arbejde mere effektivt med maskinlæringsopgaver.
Inferentia Machine Learning Processor-chip.
Skalerbar database
En traditionel database har en lagdelt struktur. For at forenkle meget, skelnes følgende niveauer.
- SQL — klient- og anmodningsformidlere arbejder på det.
- Bestemmelser transaktioner - alt er klart her, SYRE og alt det der.
- caching, som leveres af bufferpuljer.
- Logning — giver arbejde med redo-logs. I MySQL hedder de Bin Logs, i PosgreSQL - Write Ahead Logs (WAL).
- Opbevaring – direkte optagelse til disk.
Lagdelt databasestruktur.
Der er forskellige måder at skalere databaser på: sharding, Shared Nothing-arkitektur, delte diske.
Men alle disse metoder opretholder den samme monolitiske databasestruktur. Dette begrænser skalering betydeligt. For at løse dette problem udviklede vi vores egen database − Amazon Aurora. Den er kompatibel med MySQL og PostgreSQL.
Amazon Aurora
Den vigtigste arkitektoniske idé er at adskille lager- og logningsniveauer fra hoveddatabasen.
Når vi ser fremad, vil jeg sige, at vi også har gjort caching-niveauet uafhængigt. Arkitekturen holder op med at være en monolit, og vi får yderligere frihedsgrader i at skalere individuelle blokke.
Lognings- og lagerniveauerne er adskilt fra databasen.
En traditionel DBMS skriver data til et lagersystem i form af blokke. Hos Amazon Aurora har vi skabt smart storage, der kan tale sprog redo-logs. Inde i lageret forvandler logfiler til datablokke, overvåger deres integritet og sikkerhedskopierer automatisk.
Denne tilgang giver dig mulighed for at implementere så interessante ting som kloning. Det fungerer grundlæggende hurtigere og mere økonomisk på grund af, at det ikke kræver at oprette en komplet kopi af alle data.
Lagerlaget er implementeret som et distribueret system. Den består af et meget stort antal fysiske servere. Hver gentag-log behandles og gemmes samtidigt seks knob. Dette sikrer databeskyttelse og belastningsbalancering.
Læseskalering kan opnås ved hjælp af passende replikaer. Distribueret lagring eliminerer behovet for synkronisering mellem hoveddatabaseinstansen, hvorigennem vi skriver data, og de resterende replikaer. Opdaterede data er garanteret tilgængelige for alle replikaer.
Det eneste problem er at cache gamle data på læste replikaer. Men dette problem er ved at blive løst overførsel af alle redologs til replikaer over det interne netværk. Hvis loggen er i cachen, er den markeret som forkert og overskrevet. Hvis den ikke er i cachen, bliver den simpelthen kasseret.
Vi ordnede opbevaringen.
Sådan skalerer du DBMS-niveauer
Her er vandret skalering meget vanskeligere. Så lad os gå ned ad den slagne vej klassisk vertikal skalering.
Lad os antage, at vi har en applikation, der kommunikerer med DBMS gennem en masterknude.
Når vi skalerer lodret, tildeler vi en ny node, der vil have flere processorer og hukommelse.
Dernæst skifter vi applikationen fra den gamle masterknude til den nye. Der opstår problemer.
- Dette vil kræve betydelig nedetid for applikationen.
- Den nye masterknude vil have kold cache. Databaseydelsen vil først være maksimal, når cachen er varmet op.
Hvordan kan man forbedre situationen? Konfigurer en proxy mellem applikationen og masternoden.
Hvad vil dette give os? Nu behøver alle applikationer ikke manuelt at blive omdirigeret til den nye node. Skiftet kan foretages under en proxy og er grundlæggende hurtigere.
Det ser ud til, at problemet er løst. Men nej, vi lider stadig under behovet for at varme cachen op. Derudover er der dukket et nyt problem op - nu er proxyen et potentielt fejlpunkt.
Endelig løsning med Amazon Aurora serverløs
Hvordan løste vi disse problemer?
Efterlod en proxy. Dette er ikke en separat instans, men en hel distribueret flåde af proxyer, hvorigennem applikationer opretter forbindelse til databasen. I tilfælde af fejl kan enhver af noderne udskiftes næsten øjeblikkeligt.
Tilføjet en pulje af varme noder i forskellige størrelser. Derfor, hvis det er nødvendigt at allokere en ny node af en større eller mindre størrelse, er den umiddelbart tilgængelig. Ingen grund til at vente på, at den indlæses.
Hele skaleringsprocessen styres af et særligt overvågningssystem. Overvågning overvåger konstant tilstanden af den aktuelle masterknude. Hvis den f.eks. registrerer, at processorbelastningen har nået en kritisk værdi, giver den puljen af varme tilfælde besked om behovet for at allokere en ny node.
Distribuerede fuldmagter, varme instanser og overvågning.
En node med den nødvendige effekt er tilgængelig. Bufferpuljer kopieres til den, og systemet begynder at vente på et sikkert øjeblik for at skifte.
Normalt kommer tidspunktet for at skifte ret hurtigt. Derefter afbrydes kommunikationen mellem proxyen og den gamle masterknude, alle sessioner skiftes til den nye knude.
Arbejdet med databasen genoptages.
Grafen viser, at ophænget faktisk er meget kort. Den blå graf viser belastningen, og de røde trin viser skaleringsmomenterne. Kortvarige dyk i den blå graf er netop den korte forsinkelse.
Amazon Aurora giver dig i øvrigt mulighed for helt at spare penge og slukke for databasen, når den ikke er i brug, for eksempel i weekenden. Efter at have stoppet belastningen, reducerer DB gradvist sin effekt og slukker i nogen tid. Når lasten vender tilbage, vil den stige jævnt igen.
I den næste del af historien om Amazon-enheden taler vi om netværksskalering. Abonner og følg med, så du ikke går glip af artiklen.
On Vasily Pantyukhin vil give en rapport "" Hvilke designmønstre for distribuerede systemer bruges af Amazon-udviklere, hvad er årsagerne til servicefejl, hvad er cellebaseret arkitektur, Constant Work, Shuffle Sharding - det bliver interessant. Mindre end en måned til konferencen - . 24. oktober endelig prisstigning.
Kilde: www.habr.com