Skalaen til Amazon Web Services-nettverket er 69 soner rundt om i verden i 22 regioner: USA, Europa, Asia, Afrika og Australia. Hver sone inneholder opptil 8 datasentre - Databehandlingssentre. Hvert datasenter har tusenvis eller hundretusenvis av servere. Nettverket er utformet pÄ en slik mÄte at alle usannsynlige utfallsscenarier er tatt i betraktning. For eksempel er alle regioner isolert fra hverandre, og tilgjengelighetssoner er adskilt over avstander pÄ flere kilometer. Selv om du kutter kabelen, vil systemet bytte til backup-kanaler, og tapet av informasjon vil utgjÞre noen fÄ datapakker. Vasily Pantyukhin vil snakke om hvilke andre prinsipper nettverket er bygget pÄ og hvordan det er strukturert.
Vasily Pantyukhin startet som Unix-administrator i .ru-selskaper, jobbet med stor Sun Microsystem-maskinvare i 6 Är, og forkynte en datasentrisk verden i 11 Är ved EMC. Det utviklet seg naturlig til private skyer, for sÄ Ä flytte til offentlige. NÄ, som Amazon Web Services-arkitekt, gir han tekniske rÄd for Ä hjelpe til med Ä leve og utvikle seg i AWS-skyen.
I den forrige delen av AWS-trilogien fordypet Vasily utformingen av fysiske servere og databaseskalering. Nitro-kort, tilpasset KVM-basert hypervisor, Amazon Aurora-database - om alt dette i materialet "" Les for kontekst eller se taler.
Denne delen vil fokusere pÄ nettverksskalering, et av de mest komplekse systemene i AWS. Utviklingen fra et flatt nettverk til en Virtual Private Cloud og dens design, interne tjenester til Blackfoot og HyperPlane, problemet med en brÄkete nabo, og pÄ slutten - omfanget av nettverket, ryggraden og fysiske kabler. Om alt dette under kuttet.
Ansvarsfraskrivelse: alt nedenfor er Vasilys personlige mening og kan ikke sammenfalle med posisjonen til Amazon Web Services.
Nettverksskalering
AWS-skyen ble lansert i 2006. Nettverket hans var ganske primitivt â med flat struktur. Utvalget av private adresser var felles for alle skyleietakere. NĂ„r du starter en ny virtuell maskin, mottok du ved et uhell en tilgjengelig IP-adresse fra dette omrĂ„det.
Denne tilnÊrmingen var enkel Ä implementere, men begrenset grunnleggende bruken av skyen. Spesielt var det ganske vanskelig Ä utvikle hybridlÞsninger som kombinerte private nettverk pÄ bakken og i AWS. Det vanligste problemet var overlappende IP-adresseomrÄder.
Virtuell privat sky
Skyen viste seg Ä vÊre etterspurt. Tiden er inne for Ä tenke pÄ skalerbarhet og muligheten for bruk av titalls millioner leietakere. Det flate nettet har blitt et stort hinder. Derfor tenkte vi pÄ hvordan vi kunne isolere brukere fra hverandre pÄ nettverksnivÄ slik at de selvstendig kunne velge IP-omrÄder.
Hva er det fÞrste du tenker pÄ nÄr du tenker pÄ nettverksisolering? Sikkert VLAN О VRF - Virtuell ruting og videresending.
Dessverre fungerte det ikke. VLAN ID er bare 12 bits, noe som gir oss bare 4096 isolerte segmenter. Selv de stÞrste bryterne kan bruke maksimalt 1-2 tusen VRF-er. à bruke VRF og VLAN sammen gir oss bare noen fÄ millioner subnett. Dette er definitivt ikke nok for titalls millioner leietakere, som hver mÄ kunne bruke flere subnett.
Vi har rett og slett ikke rÄd til Ä kjÞpe det nÞdvendige antallet store bokser, for eksempel fra Cisco eller Juniper. Det er to grunner: det er vanvittig dyrt, og vi Þnsker ikke Ä vÊre prisgitt deres utviklings- og lappepolitikk.
Det er bare Ă©n konklusjon - lag din egen lĂžsning.
I 2009 annonserte vi VPC - Virtuell privat sky. Navnet festet seg og nÄ bruker mange skyleverandÞrer det ogsÄ.
VPC er et virtuelt nettverk SDN (Programvaredefinert nettverk). Vi bestemte oss for ikke Ä finne opp spesielle protokoller pÄ L2- og L3-nivÄ. Nettverket kjÞrer pÄ standard Ethernet og IP. For overfÞring over nettverket er virtuell maskintrafikk innkapslet i vÄr egen protokollinnpakning. Den indikerer IDen som tilhÞrer leietakers VPC.
HÞres enkelt ut. Det er imidlertid flere alvorlige tekniske utfordringer som mÄ overvinnes. For eksempel hvor og hvordan du lagrer data om kartlegging av virtuelle MAC/IP-adresser, VPC-ID og tilsvarende fysisk MAC/IP. PÄ AWS-skala er dette et stort bord som skal fungere med minimale tilgangsforsinkelser. Ansvarlig for dette karttjeneste, som er spredt i et tynt lag over hele nettverket.
I nye generasjons maskiner utfÞres innkapsling av Nitro-kort pÄ maskinvarenivÄ. I eldre tilfeller er innkapsling og dekapsling programvarebasert.
La oss finne ut hvordan det fungerer i generelle termer. La oss starte med L2-nivÄet. La oss anta at vi har en virtuell maskin med IP 10.0.0.2 pÄ en fysisk server 192.168.0.3. Den sender data til virtuell maskin 10.0.0.3, som lever pÄ 192.168.1.4. En ARP-forespÞrsel genereres og sendes til nettverkets Nitro-kort. For enkelhets skyld antar vi at begge virtuelle maskinene lever i samme "blÄ" VPC.
Kartet erstatter kildeadressen med sin egen og videresender ARP-rammen til karttjenesten.
Karttjenesten returnerer informasjon som er nĂždvendig for overfĂžring over det fysiske L2-nettverket.
Nitro-kortet i ARP-svaret erstatter MAC pÄ det fysiske nettverket med en adresse i VPC.
Ved overfĂžring av data pakker vi logisk MAC og IP inn i en VPC-innpakning. Vi overfĂžrer alt dette over det fysiske nettverket ved Ă„ bruke riktige kilde- og destinasjons-IP Nitro-kort.
Den fysiske maskinen som pakken er bestemt til utfÞrer kontrollen. Dette er nÞdvendig for Ä forhindre muligheten for adresseforfalskning. Maskinen sender en spesiell forespÞrsel til karttjenesten og spÞr: «Fra fysisk maskin 192.168.0.3 mottok jeg en pakke som er beregnet pÄ 10.0.0.3 i den blÄ VPC. Er han legitim?
Karttjenesten sjekker sin ressursallokeringstabell og tillater eller nekter pakken Ä passere gjennom. I alle nye tilfeller er ytterligere validering innebygd i Nitro-kort. Det er umulig Ä omgÄ det selv teoretisk. Derfor vil ikke spoofing til ressurser i en annen VPC fungere.
Deretter sendes dataene til den virtuelle maskinen de er beregnet pÄ.
Karttjenesten fungerer ogsÄ som en logisk ruter for overfÞring av data mellom virtuelle maskiner i ulike undernett. Alt er konseptuelt enkelt, jeg vil ikke gÄ i detalj.
Det viser seg at nÄr hver pakke overfÞres, henvender serverne seg til karttjenesten. Hvordan hÄndtere uunngÄelige forsinkelser? Buffer, selvfÞlgelig.
Det fine er at du ikke trenger Ă„ cache hele det enorme bordet. En fysisk server er vert for virtuelle maskiner fra et relativt lite antall VPC-er. Du trenger bare Ă„ cache informasjon om disse VPC-ene. Det er fortsatt ikke legitimt Ă„ overfĂžre data til andre VPC-er i "standard"-konfigurasjonen. Hvis funksjonalitet som VPC-peering brukes, blir informasjon om de tilsvarende VPC-ene i tillegg lastet inn i cachen.
Vi ordnet overfĂžringen av data til VPC.
Blackfoot
Hva skal man gjĂžre i tilfeller der trafikk mĂ„ overfĂžres utenfor, for eksempel til Internett eller via VPN til bakken? Hjelper oss her Blackfoot â AWS interntjeneste. Den er utviklet av vĂ„rt sĂžrafrikanske team. Derfor er tjenesten oppkalt etter en pingvin som bor i SĂžr-Afrika.
Blackfoot dekapsler trafikken og gjĂžr det som trengs med den. Data sendes til Internett som de er.
Dataene dekapsles og pakkes inn pÄ nytt i IPsec nÄr du bruker en VPN.
NĂ„r du bruker Direct Connect, merkes trafikken og sendes til riktig VLAN.
HyperPlane
Dette er en intern flytkontrolltjeneste. Mange nettverkstjenester krever overvÄking dataflyttilstander. For eksempel, nÄr du bruker NAT, mÄ flytkontroll sikre at hvert IP:destinasjonsportpar har en unik utgÄende port. I tilfelle av en balanserer NLB - Network Load Balancer, bÞr dataflyten alltid rettes til den samme virtuelle mÄlmaskinen. Security Groups er en stateful brannmur. Den overvÄker innkommende trafikk og Äpner implisitt porter for utgÄende pakkeflyt.
I AWS-skyen er kravene til overfĂžringsforsinkelse ekstremt hĂžye. Derfor HyperPlane avgjĂžrende for ytelsen til hele nettverket.
Hyperplane er bygget pĂ„ virtuelle EC2-maskiner. Det er ingen magi her, bare list. Trikset er at dette er virtuelle maskiner med stor RAM. Operasjoner er transaksjonelle og utfĂžres utelukkende i minnet. Dette lar deg oppnĂ„ forsinkelser pĂ„ bare titalls mikrosekunder. Ă
jobbe med disken ville drepe all produktivitet.
Hyperplane er et distribuert system av et stort antall slike EC2-maskiner. Hver virtuell maskin har en bÄndbredde pÄ 5 GB/s. PÄ tvers av hele det regionale nettverket gir dette utrolige terabiter med bÄndbredde og tillater prosessering millioner av tilkoblinger per sekund.
HyperPlane fungerer bare med strÞmmer. VPC-pakkeinnkapsling er helt gjennomsiktig for det. En potensiell sÄrbarhet i denne interne tjenesten vil fortsatt forhindre at VPC-isolasjonen brytes. NivÄene nedenfor er ansvarlige for sikkerheten.
StĂžyende nabo
Det er fortsatt et problem brÄkete nabo - brÄkete nabo. La oss anta at vi har 8 noder. Disse nodene behandler strÞmmene til alle skybrukere. Alt ser ut til Ä vÊre i orden og belastningen skal vÊre jevnt fordelt over alle noder. Noder er veldig kraftige og det er vanskelig Ä overbelaste dem.
Men vi bygger arkitekturen vÄr basert pÄ til og med usannsynlige scenarier.
Lav sannsynlighet betyr ikke umulig.
Vi kan forestille oss en situasjon der en eller flere brukere vil generere for mye belastning. Alle HyperPlane-noder er involvert i Ä behandle denne belastningen, og andre brukere kan potensielt oppleve en slags ytelsestreff. Dette bryter konseptet med skyen, der leietakere ikke har noen mulighet til Ä pÄvirke hverandre.
Hvordan lÞse problemet med en brÄkete nabo? Det fÞrste du tenker pÄ er skjÊring. VÄre 8 noder er logisk delt inn i 4 skÄr med 2 noder hver. NÄ vil en brÄkete nabo bare forstyrre en fjerdedel av alle brukere, men det vil forstyrre dem sterkt.
La oss gjĂžre ting annerledes. Vi vil tildele kun 3 noder til hver bruker.
Trikset er Ä tilfeldig tildele noder til forskjellige brukere. PÄ bildet nedenfor krysser den blÄ brukeren noder med en av de to andre brukerne - grÞnn og oransje.
Med 8 noder og 3 brukere er sannsynligheten for at en stÞyende nabo krysser en av brukerne 54 %. Det er med denne sannsynligheten at en blÄ bruker vil pÄvirke andre leietakere. Samtidig bare en del av lasten. I vÄrt eksempel vil denne pÄvirkningen pÄ en eller annen mÄte vÊre merkbar ikke for alle, men for bare en tredjedel av alle brukere. Dette er allerede et godt resultat.
Antall brukere som vil krysse hverandre
Sannsynlighet i prosent
0
18%
1
54%
2
26%
3
2%
La oss bringe situasjonen nĂŠrmere virkeligheten â la oss ta 100 noder og 5 brukere pĂ„ 5 noder. I dette tilfellet vil ingen av nodene krysse hverandre med en sannsynlighet pĂ„ 77 %.
Antall brukere som vil krysse hverandre
Sannsynlighet i prosent
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
I en reell situasjon, med et stort antall HyperPlane-noder og brukere, er den potensielle innvirkningen av en stÞyende nabo pÄ andre brukere minimal. Denne metoden kalles blande skjÊring - shuffle sharding. Det minimerer den negative effekten av nodesvikt.
Mange tjenester er bygget pÄ basis av HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Nettverksskala
La oss nÄ snakke om omfanget av selve nettverket. For oktober 2019 tilbyr AWS sine tjenester i 22 regioner, og 9 til er planlagt.
- Hver region inneholder flere tilgjengelighetssoner. Det er 69 av dem rundt om i verden.
- Hver AZ bestÄr av databehandlingssentre. Det er ikke mer enn 8 av dem totalt.
- Datasenteret huser et stort antall servere, noen med opptil 300 000.
La oss nÄ gjennomsnittet alt dette, multiplisere og fÄ et imponerende tall som gjenspeiler Amazon skyskala.
Det er mange optiske koblinger mellom Availability Zones og datasenteret. I en av vÄre stÞrste regioner er det lagt 388 kanaler kun for AZ-kommunikasjon mellom hverandre og kommunikasjonssentre med andre regioner (Transit Centers). Totalt gir dette sprÞtt 5000 Tbit.
Backbone AWS er ââbygget spesielt for og optimalisert for skyen. Vi bygger det pĂ„ kanalene 100 GB / s. Vi kontrollerer dem fullstendig, med unntak av regioner i Kina. Trafikken deles ikke med lasten til andre selskaper.
SelvfĂžlgelig er vi ikke den eneste skyleverandĂžren med et privat ryggradsnettverk. Stadig flere store bedrifter fĂžlger denne veien. Dette bekreftes av uavhengige forskere, for eksempel fra .
Grafen viser at andelen innholdsleverandĂžrer og skyleverandĂžrer vokser. PĂ„ grunn av dette synker andelen Internett-trafikk til ryggradsleverandĂžrer stadig.
Jeg skal forklare hvorfor dette skjer. Tidligere var de fleste nettjenester tilgjengelige og konsumert direkte fra Internett. NÄ for tiden er flere og flere servere plassert i skyen og er tilgjengelige via CDN - Innholdsdistribusjonsnettverk. For Ä fÄ tilgang til en ressurs, gÄr brukeren bare gjennom Internett til nÊrmeste CDN PoP - TilstedevÊrelse. Oftest er det et sted i nÊrheten. SÄ forlater den det offentlige Internett og flyr gjennom en privat ryggrad over Atlanterhavet, for eksempel, og kommer direkte til ressursen.
Jeg lurer pÄ hvordan Internett vil endre seg om 10 Är hvis denne trenden fortsetter?
Fysiske kanaler
Forskere har ennÄ ikke funnet ut hvordan de kan Þke lyshastigheten i universet, men de har gjort store fremskritt i metoder for Ä overfÞre det gjennom optisk fiber. Vi bruker for tiden 6912 fiberkabler. Dette bidrar til Ä optimalisere kostnadene for installasjonen deres betydelig.
I noen regioner mÄ vi bruke spesielle kabler. For eksempel bruker vi i Sydney-regionen kabler med et spesielt belegg mot termitter.
Ingen er immun mot problemer og noen ganger blir kanalene vÄre skadet. Bildet til hÞyre viser optiske kabler i en av de amerikanske regionene som ble revet av bygningsarbeidere. Krasjet fÞrte til at bare 13 datapakker gikk tapt, noe som er overraskende. Nok en gang - bare 13! Systemet byttet bokstavelig talt Þyeblikkelig til backup-kanaler - vekten fungerer.
Vi galopperte gjennom noen av Amazons skytjenester og teknologier. Jeg hÄper at du i det minste har en ide om omfanget av oppgavene vÄre ingeniÞrer mÄ lÞse. Personlig synes jeg dette er veldig spennende.
Dette er den siste delen av trilogien fra Vasily Pantyukhin om AWS-enheten. I deler beskriver serveroptimalisering og databaseskalering, og i â serverlĂžse funksjoner og Firecracker.
PÄ i november vil Vasily Pantyukhin dele nye detaljer om Amazon-enheten. Han om Ärsakene til feil og utformingen av distribuerte systemer hos Amazon. 24. oktober er fortsatt mulig billett til en god pris, og betal senere. Vi venter pÄ deg pÄ HighLoad++, kom og la oss prate!
Kilde: www.habr.com
