{"id":39304,"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-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Hvordan AWS \"koger\" sine elastiske tjenester. Skalering af netv\u00e6rket","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Amazon Web Services' netv\u00e6rk omfatter 69 zoner over hele verden i 22 regioner: USA, Europa, Asien, Afrika og Australien. Hver zone rummer op til 8 datacentre. Hvert datacenter har tusindvis eller hundrede tusinder af servere. Netv\u00e6rket er konstrueret, s\u00e5 alle usandsynlige scenarier for driftsforstyrrelser tages i betragtning. For eksempel er alle regioner isoleret fra hinanden, og tilg\u00e6ngelighedszonerne er adskilt med afstande p\u00e5 flere kilometer. Selv hvis der sk\u00e6res i et kabel, vil systemet skifte til reservekanaler, og datatab vil v\u00e6re p\u00e5 niveau med en h\u00e5ndfuld datapakker. Om de andre principper, netv\u00e6rket er bygget p\u00e5, og hvordan det fungerer, fort\u00e6ller Vasily Pantiukhin.<\/p>\n

\"Hvordan
\n
\nVasily Pantiukhin<\/b> startede som Unix-administrator i .ru-virksomheder, har i 6 \u00e5r arbejdet med store maskiner fra Sun Microsystem, og i 11 \u00e5r har han pr\u00e6diket datacentercentrerethed i verden i EMC. Han har naturligt udviklet sig til private clouds og har derefter bev\u00e6get sig ind i offentlige. Nu, som arkitekt i Amazon Web Services, hj\u00e6lper han med tekniske r\u00e5d til at leve og udvikle sig i AWS-milj\u00f8et.<\/p>\n

I den foreg\u00e5ende del af trilogien om strukturen i AWS dykkede Vasily ned i infrastrukturen af fysiske servere og databasest\u00f8rrelse. Nitro-kort, et tilpasset hypervisor baseret p\u00e5 KVM, Amazon Aurora-databasen - alt dette kan findes i artiklen \"Hvordan AWS \"koger\" sine elastiske tjenester. Skalering af servere og databaser<\/a><\/noindex>\". L\u00e6s for at dykke ind i konteksten, eller se videooptagelsen<\/a><\/noindex> af pr\u00e6sentationen.<\/p>\n

I denne del vil fokus v\u00e6re p\u00e5 netv\u00e6rksskaleringsl\u00f8sninger - et af de mest komplekse systemer i AWS. Udviklingen fra et fladt netv\u00e6rk til Virtual Private Cloud og dets opbygning, interne tjenester som Blackfoot og HyperPlane, problemet med st\u00f8jende naboer, og til slut - netv\u00e6rkets omfang, backbone og fysiske kabler. Alt dette findes under katten.<\/p>\n

Disclaimer: Alt hvad der st\u00e5r nedenfor er Vasily's personlige holdning og det kan v\u00e6re i uoverensstemmelse med Amazon Web Services' siddende position.<\/i>
\n<\/a><\/noindex><\/p>\n

Netv\u00e6rksskaleringsl\u00f8sninger<\/h2>\n

\nAWS-clouden blev lanceret i 2006. Dens netv\u00e6rk var temmelig primitivt - med en flad struktur. Omr\u00e5det med private IP-adresser var delt blandt alle lejere af skyen. N\u00e5r du lancerede en ny virtuel maskine, modtog du tilf\u00e6ldigt en tilg\u00e6ngelig IP-adresse fra dette omr\u00e5de.<\/p>\n

\"Hvordan
\n
\nDenne tilgang var let at implementere, men begr\u00e6nsede grundl\u00e6ggende brugen af skyen. Is\u00e6r var det ret vanskeligt at udvikle hybride l\u00f8sninger, der kombinerede private netv\u00e6rk p\u00e5 jorden og i AWS. Det mest almindelige problem l\u00e5 i krydsningen af IP-adresseomr\u00e5der.<\/p>\n

\"Hvordan
\n<\/p>\n

Virtuelt Privat Cloud<\/h3>\n

\nSkyen har vist sig at v\u00e6re efterspurgt. Det er tid til at overveje skalerbarhed og muligheden for at anvende den af millioner af lejere. Det flade netv\u00e6rk er blevet den st\u00f8rste hindring. Derfor har vi overvejet, hvordan vi kan isolere brugere fra hinanden p\u00e5 netv\u00e6rksniveau, s\u00e5 de selv kan v\u00e6lge IP-omr\u00e5der.<\/p>\n

\"Hvordan
\n
\nHvad t\u00e6nker du f\u00f8rst p\u00e5, n\u00e5r du overvejer netv\u00e6rksisolering? Selvf\u00f8lgelig VLAN<\/b> og VRF \u2014 Virtuel Routing og Forwarding<\/b>.<\/p>\n

Desv\u00e6rre har dette ikke fungeret. VLAN ID er kun 12 bit, hvilket giver os kun 4096 isolerede segmenter. Selv i de st\u00f8rste switches kan man maksimalt bruge 1-2 tusinde VRF. Kombinationen af VRF og VLAN giver os kun et par millioner subnetv\u00e6rk. Dette er bestemt ikke tilstr\u00e6kkeligt til millioner af lejere, hvor hver enkelt skal have mulighed for at bruge flere subnetv\u00e6rk.<\/p>\n

Derudover har vi simpelthen ikke r\u00e5d til at k\u00f8be det n\u00f8dvendige antal store bokse, for eksempel fra Cisco eller Juniper. Der er to grunde til dette: det er sindssygt dyrt, og vi \u00f8nsker ikke at blive afh\u00e6ngige af deres udviklings- og patchpolitikker.<\/p>\n

Konklusionen er klar \u2013 vi m\u00e5 udvikle vores eget l\u00f8sning.<\/p><\/blockquote>\n

\nI 2009 annoncerede vi VPC<\/b> \u2014 Virtuelt Privat Cloud<\/b>. Navnet har h\u00e6ngt ved, og nu bruger mange cloududbydere det ogs\u00e5.<\/p>\n

VPC \u2013 det er et virtuelt netv\u00e6rk SDN<\/b> (Software Defined Network). Vi besluttede ikke at opfinde specielle protokoller p\u00e5 L2 og L3 niveauer. Netv\u00e6rket fungerer p\u00e5 standard Ethernet og IP. For at transmittere trafik over netv\u00e6rket indkapsles trafik fra virtuelle maskiner i indpakningen af vores eget protokol. Den angiver et ID, der tilh\u00f8rer VPC lejeren.<\/p>\n

\"Hvordan
\n
\nDet lyder enkelt. Men der er flere alvorlige tekniske udfordringer, der skal l\u00f8ses. For eksempel, hvor og hvordan man opbevarer data om kortl\u00e6gningen af virtuelle MAC\/IP-adresser, VPC ID og de tilsvarende fysiske MAC\/IP. I skalaen af AWS er det en k\u00e6mpe tabel, der skal fungere med minimale forsinkelser under foresp\u00f8rgsler. Dette h\u00e5ndteres af kortl\u00e6gningsservicen<\/b>, som er distribueret tyndt over hele netv\u00e6rket.<\/p>\n

I n\u00e6ste generations maskiner udf\u00f8res indkapsling af Nitro-kort p\u00e5 hardware niveau. I \u00e6ldre instanser er indkapsling og dekapsling programmeret.\u00a0<\/p>\n

\"Hvordan
\n
\nLad os se, hvordan det fungerer i store tr\u00e6k. Vi starter med L2-niveauet. Antag, at vi har en virtuel maskine med IP 10.0.0.2 p\u00e5 en fysisk server 192.168.0.3. Den sender data til den virtuelle maskine 10.0.0.3, som er placeret p\u00e5 192.168.1.4. Der dannes en ARP-foresp\u00f8rgsel, som n\u00e5r det netv\u00e6rk Nitro-kortet. For enkelhedens skyld antager vi, at begge virtuelle maskiner lever i det samme 'bl\u00e5' VPC.<\/p>\n

\"Hvordan
\n
\nKortet erstatter kildeadressen med sin egen og videresender ARP-rammen til kortl\u00e6gningstjenesten.<\/p>\n

\"Hvordan
\n
\nKortl\u00e6gningstjenesten returnerer de oplysninger, der er n\u00f8dvendige for at sende over det fysiske L2-netv\u00e6rk.<\/p>\n

\"Hvordan
\n
\nNitro-kortet erstatter MAC-adressen i det fysiske netv\u00e6rk med adressen i VPC i ARP-svaret.<\/p>\n

\"Hvordan
\n
\nVed dataoverf\u00f8rsel indkapsler vi de logiske MAC- og IP-adresser i en VPC-indpakning. Alt dette sendes over det fysiske netv\u00e6rk ved hj\u00e6lp af de relevante IP Nitro-kort fra b\u00e5de kilde og destination.<\/p>\n

\"Hvordan
\n
\nDen fysiske maskine, som pakken er beregnet til, foretager en kontrol. Dette er n\u00f8dvendigt for at forhindre adresseforfalskning. Maskinen sender en speciel foresp\u00f8rgsel til kortl\u00e6gningstjenesten og sp\u00f8rger: \"Fra den fysiske maskine 192.168.0.3 har jeg modtaget en pakke, der er beregnet til 10.0.0.3 i det 'bl\u00e5' VPC. Er den legitim?\"\u00a0<\/p>\n

\"Hvordan
\n
\nKortl\u00e6gningstjenesten tjekker sin ressourceplaceringstabel og tillader eller forbyder pakken at passere. I alle nye instanser er der indbygget ekstra validering i Nitro-kortene. Dette kan ikke omg\u00e5s selv teoretisk. Derfor vil spoofing til ressourcer i et andet VPC ikke lykkes.<\/p>\n

\"Hvordan
\n
\nDerefter sendes dataene til den virtuelle maskine, de er beregnet til.\u00a0<\/p>\n

\"Hvordan
\n
\nKortl\u00e6gningstjenesten fungerer ogs\u00e5 som en logisk router til overf\u00f8rsel af data mellem virtuelle maskiner i forskellige subnetv\u00e6rk. Der er alt enkelt konceptuelt, jeg vil ikke g\u00e5 i detaljer.<\/p>\n

\"Hvordan
\n
\nDet viser sig, at serverne henvender sig til kortl\u00e6gningstjenesten ved overf\u00f8rsel af hver pakke. Hvordan kan vi h\u00e5ndtere de uundg\u00e5elige forsinkelser? Ved at cache<\/b>, selvf\u00f8lgelig.<\/p>\n

Det gode ved det er, at det ikke er n\u00f8dvendigt at cache hele den store tabel. De virtuelle maskiner p\u00e5 den fysiske server kommer fra et relativt lille antal VPC'er. Caching skal kun ske for disse VPC'er. Dataoverf\u00f8rsel til andre VPC'er i standardkonfigurationen er stadig ikke legitim. Hvis der bruges funktioner som VPC-peering, vil oplysninger om de relevante VPC'er ogs\u00e5 blive indl\u00e6st i cachen.\u00a0<\/p>\n

\"Hvordan
\n
\nVi har nu forst\u00e5et dataoverf\u00f8rsel i VPC.<\/p>\n

Blackfoot<\/h3>\n

\nHvordan h\u00e5ndterer man situationer, hvor trafik skal sendes ud, for eksempel til internettet eller via VPN? Her hj\u00e6lper Blackfoot<\/b> \u2014 den interne service AWS. Den er udviklet af vores sydafrikanske team. Derfor er tjenesten opkaldt efter pingvinen, der lever i Sydafrika.<\/p>\n

\"Hvordan
\n
\nBlackfoot dekapslerer trafikken og g\u00f8r hvad der er n\u00f8dvendigt med den. Dataene sendes p\u00e5 internettet som de er.<\/p>\n

\"Hvordan
\n
\nData dekapsles og pakkes igen ind i en IPsec-wrapper ved brug af VPN.<\/p>\n

\"Hvordan
\n
\nVed brug af Direct Connect tagges trafikken og sendes til den relevante VLAN.<\/p>\n

\"Hvordan
\n<\/p>\n

HyperPlane<\/h3>\n

\nDette er en intern tjeneste til trafikstyring. Mange netv\u00e6rkstjenester kr\u00e6ver kontrol af str\u00f8mmen af data<\/b>. For eksempel, ved brug af NAT, skal trafikstyringen sikre, at hver klynge \"IP: destinationsport\" svarer til en unik udg\u00e5ende port. I tilf\u00e6lde af belastningsfordeler NLB<\/b> \u2014 Network Load Balancer<\/b>, skal data str\u00f8mmen altid ledes til den samme m\u00e5lv\u00e6rt. Security Groups er en tilstandbevarende firewall. Den overv\u00e5ger indg\u00e5ende trafik og \u00e5bner implicit porter for den udg\u00e5ende str\u00f8m af pakker.<\/p>\n

\"Hvordan
\n
\nI AWS-milj\u00f8et er kravene til overf\u00f8rselstid ekstremt h\u00f8je. Derfor HyperPlane<\/b> er kritisk for netv\u00e6rkets samlede funktionalitet.<\/p>\n

\"Hvordan
\n
\nHyperplane er bygget p\u00e5 EC2 virtuelle maskiner. Her er der ikke nogen magi, kun snedighed. Snedigheden ligger i, at det er virtuelle maskiner med meget RAM. Transaktionerne udf\u00f8res udelukkende i hukommelsen. Dette muligg\u00f8r latenser p\u00e5 kun ti mikrosekunder. Arbejde med disk ville dr\u00e6be al ydeevne.\u00a0<\/p>\n

Hyperplane er et distribueret system best\u00e5ende af en k\u00e6mpe m\u00e6ngde af s\u00e5danne EC2-maskiner. Hver virtuel maskine har en b\u00e5ndbredde p\u00e5 5 GB\/s. P\u00e5 tv\u00e6rs af hele det regionale netv\u00e6rk betyder dette vanvittige terabits af b\u00e5ndbredde og muligg\u00f8r behandling af millioner af forbindelser pr. sekund<\/b>.<\/p>\n

HyperPlane arbejder kun med str\u00f8mme. VPC-kapsling af pakker er helt gennemsigtig for den. Eventuel s\u00e5rbarhed i denne interne tjeneste vil ikke kunne bryde VPC-isoleringen. Sikring varetages af de lavere niveauer.<\/p>\n

Noisy neighbor<\/h3>\n

\nDer er ogs\u00e5 et problem med det st\u00f8jende nabo<\/b> \u2014 noisy neighbor<\/b>. Lad os antage, at vi har 8 noder. Disse noder behandler str\u00f8mmen fra alle brugere i skyen. Alt ser godt ud, og belastningen skal fordeles j\u00e6vnt over alle noder. Noderne er meget kraftige, og det er sv\u00e6rt at overbelaste dem.<\/p>\n

Men vi bygger vores arkitektur med selv de usandsynlige scenarier i mente.\u00a0<\/p>\n

En lav sandsynlighed betyder ikke umulighed.<\/p><\/blockquote>\n

\nVi kan forestille os en situation, hvor en eller flere brugere genererer en for stor belastning. Alle HyperPlane noder er involveret i behandlingen af denne belastning, og andre brugere kan potentiel opleve en form for nedsat ydeevne. Dette underminerer konceptet om skyer, hvor lejere ikke kan p\u00e5virke hinanden.<\/p>\n

\"Hvordan
\n
\nHvordan l\u00f8ser vi problemet med<\/p>\n

\"Hvordan
\n
\nLad os g\u00f8re det anderledes. Hver bruger f\u00e5r kun tildelt 3 noder.\u00a0<\/p>\n

\"Hvordan
\n
\nTricket er at tildele noder til forskellige brugere tilf\u00e6ldigt. P\u00e5 billedet nedenfor krydser den bl\u00e5 bruger noder med en af de to andre brugere - den gr\u00f8nne og den orange.<\/p>\n

\"Hvordan
\n
\nMed 8 noder og 3 brugere er sandsynligheden for, at den st\u00f8jende nabo krydser med en af brugerne, 54%. Den bl\u00e5 bruger vil med den sandsynlighed p\u00e5virke andre lejere. Dette vil dog kun v\u00e6re en del af deres samlede belastning. I vores eksempel vil denne indflydelse kun v\u00e6re m\u00e6rkbar for en tredjedel af alle brugere. Det er allerede et godt resultat.<\/p>\n

Antallet af brugere, der krydser hinanden<\/p>\n

Sandsynlighed i procent<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

Lad os n\u00e6rme os situationen realistisk - lad os tage 100 noder og 5 brugere p\u00e5 5 noder. I dette tilf\u00e6lde vil ingen af noderne krydse hinanden med en sandsynlighed p\u00e5 77%.\u00a0<\/p>\n

Antallet af brugere, der krydser hinanden<\/p>\n

Sandsynlighed i procent<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

I en virkelig situation, med et stort antal HyperPlane noder og brugere, er den potentielle indflydelse fra den st\u00f8jende nabo p\u00e5 andre brugere minimal. Denne metode kaldes shuffle sharding<\/b> \u2014 . Den minimerer den negative effekt af noder, der fejler.<\/b>Der er bygget mange tjenester p\u00e5 HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Netv\u00e6rkets skala<\/p>\n

Netv\u00e6rkets skala<\/h3>\n

\nLad os tale om omfanget af selve netv\u00e6rket. Fra oktober 2019 tilbyder AWS sine tjenester i 22 regioner<\/b>, og der er planlagt yderligere 9.<\/p>\n