Omfanget af Amazon Web Services-netværket er 69 zoner rundt om i verden i 22 regioner: USA, Europa, Asien, Afrika og Australien. Hver zone indeholder op til 8 datacentre - Databehandlingscentre. Hvert datacenter har tusinder eller hundredtusindvis af servere. Netværket er designet på en sådan måde, at alle usandsynlige udfaldsscenarier tages i betragtning. For eksempel er alle regioner isoleret fra hinanden, og tilgængelighedszoner er adskilt over afstande på flere kilometer. Selvom du klipper kablet over, vil systemet skifte til backup-kanaler, og tabet af information vil udgøre nogle få datapakker. Vasily Pantyukhin vil fortælle om, hvilke andre principper netværket er bygget på, og hvordan det er opbygget.
Vasily Pantyukhin startede som Unix-administrator i .ru-virksomheder, arbejdede på stor Sun Microsystem-hardware i 6 år og prædikede en datacentreret verden i 11 år hos EMC. Det udviklede sig naturligt til private skyer og flyttede derefter til offentlige. Nu, som Amazon Web Services-arkitekt, giver han teknisk rådgivning for at hjælpe med at leve og udvikle sig i AWS-skyen.
I den forrige del af AWS-trilogien dykkede Vasily ind i designet af fysiske servere og databaseskalering. Nitro-kort, tilpasset KVM-baseret hypervisor, Amazon Aurora-database - om alt dette i materialet "" Læs for kontekst eller se taler.
Denne del vil fokusere på netværksskalering, et af de mest komplekse systemer i AWS. Udviklingen fra et fladt netværk til en Virtual Private Cloud og dens design, interne tjenester fra Blackfoot og HyperPlane, problemet med en støjende nabo, og i slutningen - omfanget af netværket, backbone og fysiske kabler. Om alt dette under skæringen.
Ansvarsfraskrivelse: alt nedenfor er Vasilys personlige mening og falder muligvis ikke sammen med Amazon Web Services' position.
Netværksskalering
AWS-skyen blev lanceret i 2006. Hans netværk var ret primitivt – med en flad struktur. Udvalget af private adresser var fælles for alle cloud-lejere. Når du starter en ny virtuel maskine, modtog du ved et uheld en tilgængelig IP-adresse fra dette område.
Denne tilgang var nem at implementere, men begrænsede grundlæggende brugen af skyen. Især var det ret svært at udvikle hybridløsninger, der kombinerede private netværk på jorden og i AWS. Det mest almindelige problem var overlappende IP-adresseintervaller.
Virtuel privat sky
Skyen viste sig at være efterspurgt. Tiden er inde til at tænke over skalerbarhed og muligheden for, at den kan bruges af titusinder af lejere. Det flade netværk er blevet en stor hindring. Derfor tænkte vi på, hvordan man kunne isolere brugere fra hinanden på netværksniveau, så de selvstændigt kunne vælge IP-intervaller.
Hvad er det første, du tænker på, når du tænker på netværksisolering? Sikkert VLAN и VRF - Virtuel Routing og Forwarding.
Desværre virkede det ikke. VLAN ID er kun 12 bit, hvilket giver os kun 4096 isolerede segmenter. Selv de største switches kan maksimalt bruge 1-2 tusinde VRF'er. Brug af VRF og VLAN sammen giver os kun et par millioner undernet. Dette er bestemt ikke nok for titusinder af lejere, som hver især skal kunne bruge flere undernet.
Vi har simpelthen heller ikke råd til at købe det nødvendige antal store kasser, for eksempel fra Cisco eller Juniper. Der er to grunde: det er vanvittigt dyrt, og vi ønsker ikke at være prisgivet deres udviklings- og lappepolitikker.
Der er kun én konklusion - lav din egen løsning.
I 2009 annoncerede vi VPC — Virtuel privat sky. Navnet satte sig fast og nu bruger mange cloud-udbydere det også.
VPC er et virtuelt netværk SDN (Softwaredefineret netværk). Vi besluttede ikke at opfinde specielle protokoller på L2- og L3-niveauer. Netværket kører på standard Ethernet og IP. Til transmission over netværket er virtuel maskintrafik indkapslet i vores egen protokolindpakning. Det angiver det ID, der hører til lejerens VPC.
Lyder enkelt. Der er dog flere alvorlige tekniske udfordringer, der skal overvindes. For eksempel hvor og hvordan man lagrer data om kortlægning af virtuelle MAC/IP-adresser, VPC ID og tilsvarende fysisk MAC/IP. På AWS-skala er dette en enorm tabel, der burde fungere med minimale adgangsforsinkelser. Ansvarlig for dette korttjeneste, som er spredt i et tyndt lag i hele netværket.
I den nye generation af maskiner udføres indkapslingen af Nitro-kort på hardwareniveau. I ældre tilfælde er indkapsling og dekapsling softwarebaseret.
Lad os finde ud af, hvordan det fungerer generelt. Lad os starte med L2-niveauet. Lad os antage, at vi har en virtuel maskine med IP 10.0.0.2 på en fysisk server 192.168.0.3. Den sender data til den virtuelle maskine 10.0.0.3, som lever på 192.168.1.4. En ARP-anmodning genereres og sendes til netværkets Nitro-kort. For nemheds skyld antager vi, at begge virtuelle maskiner lever i den samme "blå" VPC.
Kortet erstatter kildeadressen med sin egen og videresender ARP-rammen til korttjenesten.
Korttjenesten returnerer information, der er nødvendig for transmission over det fysiske L2-netværk.
Nitrokortet i ARP-svaret erstatter MAC'en på det fysiske netværk med en adresse i VPC'en.
Ved overførsel af data pakker vi logisk MAC og IP ind i en VPC-indpakning. Vi transmitterer alt dette over det fysiske netværk ved hjælp af de passende kilde- og destinations-IP Nitro-kort.
Den fysiske maskine, som pakken er bestemt til, udfører kontrollen. Dette er nødvendigt for at forhindre muligheden for adressespoofing. Maskinen sender en særlig anmodning til korttjenesten og spørger: “Fra fysisk maskine 192.168.0.3 modtog jeg en pakke, der er beregnet til 10.0.0.3 i den blå VPC. Er han legitim?
Korttjenesten tjekker sin ressourceallokeringstabel og tillader eller nægter pakken at passere igennem. I alle nye tilfælde er yderligere validering indlejret i Nitro-kort. Det er umuligt at omgå det selv teoretisk. Derfor vil spoofing til ressourcer i en anden VPC ikke fungere.
Derefter sendes dataene til den virtuelle maskine, som de er beregnet til.
Korttjenesten fungerer også som en logisk router til overførsel af data mellem virtuelle maskiner i forskellige undernet. Alt er konceptuelt simpelt, jeg vil ikke gå i detaljer.
Det viser sig, at når hver pakke sendes, vender serverne sig til korttjenesten. Hvordan håndterer man uundgåelige forsinkelser? Caching, selvfølgelig.
Skønheden er, at du ikke behøver at cache hele det enorme bord. En fysisk server hoster virtuelle maskiner fra et relativt lille antal VPC'er. Du behøver kun at cache oplysninger om disse VPC'er. Overførsel af data til andre VPC'er i "standard"-konfigurationen er stadig ikke legitim. Hvis funktionalitet såsom VPC-peering anvendes, indlæses information om de tilsvarende VPC'er yderligere i cachen.
Vi ordnede overførslen af data til VPC'en.
Blackfoot
Hvad skal man gøre i tilfælde, hvor trafik skal transmitteres udenfor, for eksempel til internettet eller via VPN til jorden? Hjælper os her Blackfoot — AWS intern service. Det er udviklet af vores sydafrikanske team. Derfor er tjenesten opkaldt efter en pingvin, der bor i Sydafrika.
Blackfoot afkapsler trafikken og gør, hvad der er nødvendigt med det. Data sendes til internettet, som de er.
Data afkapsles og pakkes igen ind i IPsec, når du bruger en VPN.
Når du bruger Direct Connect, mærkes trafik og sendes til det relevante VLAN.
HyperPlane
Dette er en intern flowkontroltjeneste. Mange netværkstjenester kræver overvågning dataflowtilstande. For eksempel, når du bruger NAT, skal flowkontrol sikre, at hvert IP:destinationsportpar har en unik udgående port. I tilfælde af en balancer NLB — Network Load Balancer, bør datastrømmen altid ledes til den samme virtuelle målmaskine. Security Groups er en stateful firewall. Den overvåger indgående trafik og åbner implicit porte for udgående pakkeflow.
I AWS-skyen er kravene til transmissionsforsinkelse ekstremt høje. Derfor HyperPlane afgørende for hele netværkets ydeevne.
Hyperplane er bygget på virtuelle EC2-maskiner. Der er ingen magi her, kun list. Tricket er, at det er virtuelle maskiner med stor RAM. Operationer er transaktionelle og udføres udelukkende i hukommelsen. Dette giver dig mulighed for at opnå forsinkelser på kun snesevis af mikrosekunder. At arbejde med disken ville dræbe al produktivitet.
Hyperplane er et distribueret system af et stort antal af sådanne EC2-maskiner. Hver virtuel maskine har en båndbredde på 5 GB/s. På tværs af hele det regionale netværk giver dette utrolige terabits båndbredde og muliggør behandling millioner af forbindelser i sekundet.
HyperPlane fungerer kun med streams. VPC-pakkeindkapsling er fuldstændig gennemsigtig for det. En potentiel sårbarhed i denne interne tjeneste ville stadig forhindre VPC-isolationen i at blive brudt. Nedenstående niveauer er ansvarlige for sikkerheden.
Støjende nabo
Der er stadig et problem larmende nabo — larmende nabo. Lad os antage, at vi har 8 noder. Disse noder behandler strømmene for alle cloud-brugere. Alt ser ud til at være i orden, og belastningen skal være jævnt fordelt over alle noder. Noder er meget kraftfulde, og det er svært at overbelaste dem.
Men vi bygger vores arkitektur ud fra selv usandsynlige scenarier.
Lav sandsynlighed betyder ikke umuligt.
Vi kan forestille os en situation, hvor en eller flere brugere ville generere for meget belastning. Alle HyperPlane noder er involveret i at behandle denne belastning, og andre brugere kan potentielt opleve en form for præstationshit. Dette bryder konceptet om skyen, hvor lejere ikke har mulighed for at påvirke hinanden.
Hvordan løser man problemet med en støjende nabo? Det første, der kommer til at tænke på, er sønderdeling. Vores 8 noder er logisk opdelt i 4 skår af hver 2 noder. Nu vil en støjende nabo kun forstyrre en fjerdedel af alle brugere, men det vil forstyrre dem meget.
Lad os gøre tingene anderledes. Vi vil kun tildele 3 noder til hver bruger.
Tricket er at tilfældigt tildele noder til forskellige brugere. På billedet nedenfor skærer den blå bruger noder med en af de to andre brugere - grøn og orange.
Med 8 noder og 3 brugere er sandsynligheden for, at en støjende nabo krydser en af brugerne 54 %. Det er med denne sandsynlighed, at en blå bruger vil påvirke andre lejere. På samme tid, kun en del af sin belastning. I vores eksempel vil denne indflydelse i det mindste på en eller anden måde ikke være mærkbar for alle, men kun for en tredjedel af alle brugere. Dette er allerede et godt resultat.
Antal brugere, der vil krydse hinanden
Sandsynlighed i procent
0
18 %
1
54 %
2
26 %
3
2%
Lad os bringe situationen tættere på virkeligheden – lad os tage 100 noder og 5 brugere på 5 noder. I dette tilfælde vil ingen af knudepunkterne skære hinanden med en sandsynlighed på 77%.
Antal brugere, der vil krydse hinanden
Sandsynlighed i procent
0
77 %
1
21 %
2
1,8 %
3
0,06 %
4
0,0006 %
5
0,00000013 %
I en reel situation, med et stort antal HyperPlane-noder og brugere, er den potentielle påvirkning af en støjende nabo på andre brugere minimal. Denne metode kaldes blanding af skæring — blande sønderdeling. Det minimerer den negative effekt af knudefejl.
Mange tjenester er bygget på basis af HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netværks skala
Lad os nu tale om omfanget af selve netværket. Til oktober 2019 tilbyder AWS sine tjenester i 22 regioner, og 9 mere er planlagt.
- Hver region indeholder flere tilgængelighedszoner. Der er 69 af dem rundt om i verden.
- Hver AZ består af databehandlingscentre. Der er ikke mere end 8 af dem i alt.
- Datacentret huser et stort antal servere, nogle med op til 300.
Lad os nu gennemsnittet alt dette, gange og få et imponerende tal, der afspejler Amazon sky skala.
Der er mange optiske links mellem Availability Zones og datacentret. I en af vores største regioner er der lagt 388 kanaler kun til AZ-kommunikation mellem hinanden og kommunikationscentre med andre regioner (Transitcentre). I alt giver dette vanvittigt 5000 Tbit.
Backbone AWS er bygget specifikt til og optimeret til skyen. Vi bygger det på kanalerne 100 GB / s. Vi kontrollerer dem fuldstændigt, med undtagelse af regioner i Kina. Trafikken deles ikke med andre virksomheders byrder.
Vi er naturligvis ikke den eneste cloud-udbyder med et privat backbone-netværk. Flere og flere store virksomheder følger denne vej. Det bekræfter uafhængige forskere, f.eks .
Grafen viser, at andelen af indholdsudbydere og cloududbydere vokser. På grund af dette falder backboneudbydernes andel af internettrafik konstant.
Jeg vil forklare, hvorfor dette sker. Tidligere var de fleste webtjenester tilgængelige og forbrugt direkte fra internettet. I dag er flere og flere servere placeret i skyen og er tilgængelige via CDN — Indholdsdistributionsnetværk. For at få adgang til en ressource går brugeren kun gennem internettet til den nærmeste CDN PoP - Tilstedeværelse. Oftest er det et sted i nærheden. Så forlader den det offentlige internet og flyver gennem en privat rygrad over for eksempel Atlanten og kommer direkte til ressourcen.
Jeg spekulerer på, hvordan internettet vil ændre sig om 10 år, hvis denne tendens fortsætter?
Fysiske kanaler
Forskere har endnu ikke fundet ud af, hvordan man kan øge lysets hastighed i universet, men de har gjort store fremskridt med metoder til at transmittere det gennem optisk fiber. Vi bruger i øjeblikket 6912 fiberkabler. Dette er med til at optimere omkostningerne ved deres installation markant.
I nogle regioner skal vi bruge specielle kabler. For eksempel bruger vi i Sydney-regionen kabler med en speciel belægning mod termitter.
Ingen er immune over for problemer, og nogle gange bliver vores kanaler beskadiget. Billedet til højre viser optiske kabler i en af de amerikanske regioner, der blev revet i stykker af bygningsarbejdere. Som følge af ulykken gik kun 13 datapakker tabt, hvilket er overraskende. Endnu en gang - kun 13! Systemet skiftede bogstaveligt talt øjeblikkeligt til backup-kanaler - vægten virker.
Vi galopperede gennem nogle af Amazons cloud-tjenester og -teknologier. Jeg håber, at du i det mindste har en idé om omfanget af de opgaver, som vores ingeniører skal løse. Personligt synes jeg det er meget spændende.
Dette er den sidste del af trilogien fra Vasily Pantyukhin om AWS-enheden. I dele beskriver serveroptimering og databaseskalering, og i — Serverløse funktioner og Firecracker.
On i november vil Vasily Pantyukhin dele nye detaljer om Amazon-enheden. Han om årsagerne til fejl og designet af distribuerede systemer hos Amazon. 24. oktober er stadig muligt billet til en god pris, og betal senere. Vi venter på dig hos HighLoad++, kom og lad os chatte!
Kilde: www.habr.com