{"id":39302,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"Hvordan AWS \"koger\" sine elastiske tjenester. Skalering af servere og databaser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Skya er som en magisk kiste \u2014 du sp\u00f8rger, hvad du har brug for, og ressourcerne dukker op fra ingenting. Virtuelle maskiner, databaser, netv\u00e6rk \u2014 alt dette tilh\u00f8rer kun dig. Der findes andre cloud-tenanter, men i dit univers er du den enev\u00e6ldige hersker. Du er sikker p\u00e5, at du altid vil f\u00e5 de kr\u00e6vede ressourcer, du tager ikke hensyn til andre, og du bestemmer selv, hvordan netv\u00e6rket skal v\u00e6re. Hvordan fungerer denne magi, der f\u00e5r skyen til elastisk at tildele ressourcer og fuldst\u00e6ndigt isolere tenantene fra hinanden?<\/p>\n

\"Hvordan
\n
\nAWS-skyen er et mega-superkomplekst system, der har udviklet sig evolution\u00e6rt siden 2006. En del af denne udvikling s\u00e5 Vasily Pantiukhin<\/strong> \u2014 arkitekt for Amazon Web Services. Som arkitekt ser han ikke kun slutresultatet, men ogs\u00e5 de udfordringer, AWS overvinder. Jo mere forst\u00e5else man har for systemets funktion, jo mere tillid f\u00e5r man. Derfor vil Vasily dele hemmelighederne bag AWS-cloudtjenesterne. Under overskriften kan du l\u00e6se om opbygningen af de fysiske AWS-servere, elastisk skalerbarhed for databaser, den tilpassede Amazon-database og metoder til at \u00f8ge ydeevnen for virtuelle maskiner samtidig med, at deres omkostninger reduceres. Kendskab til Amazons arkitekturtilgange vil hj\u00e6lpe dig med at bruge AWS-tjenesterne mere effektivt og m\u00e5ske give nye id\u00e9er til at udvikle dine egne l\u00f8sninger.
\n<\/a><\/noindex>
\nOm opl\u00e6gsholderen: Vasily Pantyukhin (Hen<\/a><\/noindex>) begyndte som Unix-administrator i .ru-virksomheder, arbejdede 6 \u00e5r med store maskiner fra Sun Microsystems, og i 11 \u00e5r pr\u00e6dikede han datacenteret i EMC. Han er naturligt blevet til private skyer, og i 2017 gik han ind i det offentlige. Nu hj\u00e6lper han med tekniske r\u00e5d til at leve og udvikle sig i AWS-skyen.<\/p>\n

Ansvarsfraskrivelse: alt nedenfor er Vasily's personlige mening, og den kan ikke n\u00f8dvendigvis v\u00e6re i overensstemmelse med Amazon Web Services' position. Videooptagelsen<\/a><\/noindex> af foredraget, p\u00e5 baggrund af hvilket artiklen er skrevet, er tilg\u00e6ngelig p\u00e5 vores YouTube-kanal.<\/i><\/p>\n

Hvorfor fort\u00e6ller jeg om Amazon's opbygning<\/h2>\n

\nMin f\u00f8rste bil havde en \"gearspak\" \u2014 med manuel gearkasse. Det var fantastisk p\u00e5 grund af f\u00f8lelsen af, at jeg kunne styre bilen og have fuld kontrol over den. Jeg kunne ogs\u00e5 lide, at jeg i det mindste omtrent forstod, hvordan den fungerede. Selvf\u00f8lgelig forestillede jeg mig konstruktionen af gearkassen ret primitivt \u2014 omtrent som gearkassen p\u00e5 en cykel.<\/p>\n

\"Hvordan
\n
\nAlt var fantastisk, undtagen \u00e9n ting \u2014 at sidde i trafik. Man sidder der og laver ikke noget, men skifter konstant gear, trykker p\u00e5 koblingen, gas, bremse \u2014 det g\u00f8r en rigtig tr\u00e6t. Problemet med trafik blev delvist l\u00f8st, da vi fik en bil med automatgear. Bag rattet fik jeg tid til at t\u00e6nke p\u00e5 noget, lytte til lydb\u00f8ger.<\/p>\n

Der opstod ogs\u00e5 et mysterium i mit liv, fordi jeg helt sluttede med at forst\u00e5, hvordan min bil fungerer. Moderne biler er komplekse apparater. Bilen tilpasser sig samtidig til dusinvis af forskellige parametre: gasp\u00e5virkning, bremser, k\u00f8restil, vejens kvalitet. Jeg forst\u00e5r ikke l\u00e6ngere, hvordan det virker.<\/p>\n

Da jeg begyndte at arbejde med Amazon Cloud, var det ogs\u00e5 et mysterium for mig. Men dette mysterium er p\u00e5 et h\u00f8jere plan, fordi der i bilen er \u00e9n chauff\u00f8r, mens der i AWS er millioner. Alle brugere styrer samtidig, trykker p\u00e5 gas og bremse. Det er fantastisk, at de k\u00f8rer det sted, de \u00f8nsker \u2014 for mig er det en mirakel! Systemet tilpasser sig automatisk, skaleres og er elastisk tilpasset hver bruger, s\u00e5 de f\u00f8ler, de er den eneste i dette univers.<\/p>\n

Magien blev lidt opl\u00f8st, da jeg senere kom til at arbejde som arkitekt hos Amazon. Jeg s\u00e5 de problemer, vi st\u00e5r overfor, hvordan vi l\u00f8ser dem, og hvordan vi udvikler tjenester. Med en st\u00f8rre forst\u00e5else af systemets arbejde kommer der mere tillid til servicen. Derfor vil jeg dele billedet af, hvad der er under motorhjelmen i AWS skyen.<\/p>\n

Hvad skal vi tale om<\/h2>\n

\nJeg valgte en diversificeret tilgang \u2014 udvalgt 4 interessante tjenester, som det er v\u00e6rd at tale om.<\/p>\n

Serveroptimering<\/strong>. Ephemerale skyder med fysisk manifestation: fysiske datacentre, hvor fysiske servere st\u00e5r, som brummer, bliver varme og blinker med lys.<\/p>\n

Serverless-funktioner <\/strong>(Lambda) \u2014 sandsynligvis den mest skalerbare service i skyen.<\/p>\n

Skalering af databaser<\/strong>. Jeg vil fort\u00e6lle, hvordan vi bygger vores egne skalerbare databaser.<\/p>\n

Netv\u00e6rksskaleringsl\u00f8sninger<\/strong>. Den sidste del, hvor jeg \u00e5bner op for vores netv\u00e6rk. Det er en vidunderlig ting \u2014 hver skybruger mener, at de er alene i skyen og slet ikke ser andre lejere.<\/p>\n

Bem\u00e6rkning. Denne artikel vil fokusere p\u00e5 optimering af servere og skalering af databaser. Skalering af netv\u00e6rk vil blive behandlet i n\u00e6ste artikel. Hvor befinder serverless-funktionerne sig? Der er blevet udgivet en separat uddybning om dem.Lille, men m\u00e6gtig. Unboxing af mikrovirtualiseringen Firecracker<\/a><\/noindex>I denne artikel tales der om flere forskellige m\u00e5der at skalere p\u00e5, og l\u00f8sningen Firecracker bliver n\u00f8jere gennemg\u00e5et \u2014 en symbiose af de bedste kvaliteter fra virtuelle maskiner og containere.<\/i><\/p><\/blockquote>\n

<\/p>\n

Servere<\/h2>\n

\nSkyen er efem\u00e6r. Men denne efem\u00e6rhed har trods alt en fysisk repr\u00e6sentation \u2014 serverne. Oprindeligt var deres arkitektur klassisk. Standard x86 chipset, netv\u00e6rkskort, Linux, hypervisor Xen, hvorp\u00e5 de virtuelle maskiner blev drevet.<\/p>\n

\"Hvordan
\n
\nI 2012 kunne denne arkitektur helt sikkert klare sine opgaver. Xen er en fremragende hypervisor, men den har en alvorlig ulempe. Den har ret h\u00f8je overheadomkostninger til emulering af enheder.<\/strong>N\u00e5r der kom nye, hurtigere netv\u00e6rkskort eller SSD-diske, blev disse overheadomkostninger alt for h\u00f8je. Hvordan kan man l\u00f8se dette problem? Vi besluttede os for at arbejde p\u00e5 to fronter \u2014 b\u00e5de optimere hardwaren og hypervisoren.<\/strong>Opgaven er meget seri\u00f8s.<\/p>\n

Optimering af hardware og hypervisor.<\/h3>\n

\nDet vil ikke v\u00e6re muligt at g\u00f8re alt godt p\u00e5 \u00e9n gang. Hvad der mener 'godt', var oprindeligt ikke klart.<\/p>\n

Vi besluttede os for at anvende en evolution\u00e6r tilgang \u2014 \u00e6ndre et vigtigt element af arkitekturen og implementere det i produktion.<\/p><\/blockquote>\n

Vi tr\u00e6der p\u00e5 alle mulige skjulte problemer og lytter til klager og forslag. Derefter \u00e6ndrer vi en anden komponent. P\u00e5 denne m\u00e5de, i sm\u00e5 inkrementer, \u00e6ndrer vi hele arkitekturen radikalt baseret p\u00e5 feedback fra brugerne og supporten.<\/p>\n

Transformationerne begyndte i 2013 med det mest komplekse \u2014 netv\u00e6rket. I C3<\/strong> instanserne tilf\u00f8jede vi et s\u00e6rligt kort Network Accelerator ud over det standard netv\u00e6rkskort. Det blev tilsluttet med et kort loopback-kabel p\u00e5 den forreste panel. Ikke k\u00f8nt, men det er usynligt i skyen. Men den direkte interaktion med hardwaren forbedrede principielt jitter og netv\u00e6rksb\u00e5ndbredde.<\/p>\n

Dern\u00e6st besluttede vi at forbedre adgangen til EBS \u2014 Elastic Block Storage. Dette er en kombination af netv\u00e6rk og lager. Udfordringen er, at mens der p\u00e5 markedet fandtes Network Accelerator-kort, fandtes der slet ikke mulighed for at k\u00f8be hardware til Storage Accelerator. Derfor henvendte vi os til startupen Annapurna Labs<\/strong>, som har udviklet specielle ASIC-chips til os. De gjorde det muligt at tilslutte fjerntliggende EBS-volumener som NVMe-enheder.<\/p>\n

I instanserne C4<\/strong> l\u00f8ste vi to opgaver. Den f\u00f8rste var at skabe et grundlag for fremtidens lovende, men p\u00e5 det tidspunkt nye NVMe-teknologi. Den anden var at aflaste centralprocessoren betydeligt ved at overf\u00f8re behandlingen af anmodninger til EBS til det nye kort. Det blev en succes, s\u00e5 nu er Annapurna Labs en del af Amazon.<\/p>\n

I november 2017 inds\u00e5 vi, at det var tid til at \u00e6ndre selve hypervisoren.<\/p>\n

Den nye hypervisor blev udviklet p\u00e5 baggrund af modificerede KVM-kernemoduler.<\/p><\/blockquote>\n

Den gjorde det muligt v\u00e6sentligt at reducere overheaden ved enhedsemmulering og arbejde direkte med de nye ASICs. Instanserne C5<\/strong> var de f\u00f8rste virtuelle maskiner, hvor den nye hypervisor k\u00f8rte under overfladen. Vi kaldte den Nitro<\/strong>.<\/p>\n

\"HvordanEvolutionen af instanser p\u00e5 en tidslinje.<\/em><\/p>\n

Alle nye typer virtuelle maskiner, der er opst\u00e5et siden november 2017, k\u00f8rer p\u00e5 denne hypervisor. Bare Metal-instanserne har ikke en hypervisor<\/strong>, men de kaldes ogs\u00e5 Nitro, da de bruger specialiserede Nitro-kort.<\/p>\n

I l\u00f8bet af de n\u00e6ste to \u00e5r oversteg antallet af Nitro-instanstyper flere dusin: A1, C5, M5, T3 og andre.<\/p>\n

\"Hvordan
\nTyper af instanser.<\/em><\/p>\n

Hvordan moderne Nitro-maskiner er opbygget<\/h3>\n

\nDe har tre hovedkomponenter: Nitro-hypervisoren (som n\u00e6vnt f\u00f8r), sikkerhedsbrikken og Nitro-kortene.<\/p>\n

Sikkerhedsbrikken<\/strong> er integreret direkte i bundkortet. Den overv\u00e5ger mange vigtige funktioner, s\u00e5som kontrol af opstart af v\u00e6rtens operativsystem.<\/p>\n

Nitro-kortene<\/strong> \u2014 der findes fire typer. Alle er designet af Annapurna Labs og baseres p\u00e5 f\u00e6lles ASICs. En del af deres firmware er ogs\u00e5 f\u00e6lles.<\/p>\n

\"Hvordan
\nFire typer Nitro-kort.<\/em><\/p>\n

Et af kortene er beregnet til at arbejde med netv\u00e6rket<\/strong>VPC<\/strong>. Det er det, der vises i de virtuelle maskiner som et netv\u00e6rkskort ENA \u2014 Elastic Network Adaptor<\/strong>. Det kapsler ogs\u00e5 trafik, n\u00e5r det overf\u00f8res gennem det fysiske netv\u00e6rk (mere om dette i den anden del af artiklen), overv\u00e5ger Security Groups-firewallen, har ansvar for routing og andre netv\u00e6rksfunktioner.<\/p>\n

Separat kort arbejder med bloklageret EBS<\/strong> og diskene, der er indbygget i serveren. De pr\u00e6senteres for den g\u00e6stende virtuelle maskine som NVMe-adaptere<\/strong>. De har ogs\u00e5 ansvaret for datakryptering og overv\u00e5gning af diskene.<\/p>\n

Systemet af Nitro-kort, hypervisoren og sikkerhedsbrikken er forbundet i et SDN-netv\u00e6rk eller Software Defined Network<\/strong>. Kontrol af dette netv\u00e6rk (Control Plane) ledes af kontrolkort<\/strong>.<\/p>\n

Selvf\u00f8lgelig forts\u00e6tter vi med at udvikle nye ASIC. For eksempel, i slutningen af 2018 udgav vi Inferentia-chippen, som muligg\u00f8r mere effektivt arbejde med maskinl\u00e6ringsopgaver.<\/p>\n

\"Hvordan
\nInferentia Maskinl\u00e6ringsprocessor.<\/em><\/p>\n

Skalerbar database<\/h2>\n

\nEn traditionel database har en lagdelt struktur. Hvis man forenkler det, kan man skelne mellem f\u00f8lgende niveauer.<\/p>\n