Die skaal van die Amazon Web Services-netwerk is 69 sones regoor die wêreld in 22 streke: VSA, Europa, Asië, Afrika en Australië. Elke sone bevat tot 8 datasentrums - Dataverwerkingsentrums. Elke datasentrum het duisende of honderdduisende bedieners. Die netwerk is so ontwerp dat alle onwaarskynlike onderbrekingscenario's in ag geneem word. Alle streke is byvoorbeeld van mekaar geïsoleer, en toeganklikheidsones word oor afstande van etlike kilometers geskei. Selfs as jy die kabel sny, sal die stelsel oorskakel na rugsteunkanale, en die verlies aan inligting sal neerkom op 'n paar datapakkies. Vasily Pantyukhin sal praat oor watter ander beginsels die netwerk gebou is en hoe dit gestruktureer is.
Vasily Pantyukhin het as Unix-administrateur in .ru-maatskappye begin, 6 jaar lank aan groot Sun Microsystem-hardeware gewerk en 11 jaar lank 'n datasentriese wêreld by EMC gepreek. Dit het natuurlik in private wolke ontwikkel, en dan na openbare wolke verskuif. Nou, as 'n Amazon Web Services-argitek, gee hy tegniese advies om te help leef en ontwikkel in die AWS-wolk.
In die vorige deel van die AWS-trilogie het Vasily gedelf in die ontwerp van fisiese bedieners en databasisskaal. Nitro-kaarte, pasgemaakte KVM-gebaseerde hipervisor, Amazon Aurora-databasis - oor dit alles in die materiaal "" Lees vir konteks of kyk toesprake.
Hierdie deel sal fokus op netwerkskaal, een van die mees komplekse stelsels in AWS. Die evolusie van 'n plat netwerk na 'n Virtual Private Cloud en sy ontwerp, interne dienste van Blackfoot en HyperPlane, die probleem van 'n raserige buurman, en aan die einde - die skaal van die netwerk, ruggraat en fisiese kabels. Oor dit alles onder die knie.
Vrywaring: alles hieronder is Vasily se persoonlike mening en mag nie saamval met die posisie van Amazon Web Services nie.
Netwerk skaal
Die AWS-wolk is in 2006 bekendgestel. Sy netwerk was nogal primitief – met ’n plat struktuur. Die reeks private adresse was algemeen vir alle wolkhuurders. Wanneer u 'n nuwe virtuele masjien begin, het u per ongeluk 'n beskikbare IP-adres uit hierdie reeks ontvang.
Hierdie benadering was maklik om te implementeer, maar het die gebruik van die wolk fundamenteel beperk. Dit was veral moeilik om hibriede oplossings te ontwikkel wat private netwerke op die grond en in AWS gekombineer het. Die mees algemene probleem was oorvleuelende IP-adresreekse.
Virtuele privaat wolk
Die wolk het geblyk in aanvraag te wees. Die tyd het aangebreek om na te dink oor skaalbaarheid en die moontlikheid van die gebruik daarvan deur tienmiljoene huurders. Die plat netwerk het 'n groot struikelblok geword. Daarom het ons gedink oor hoe om gebruikers op netwerkvlak van mekaar te isoleer sodat hulle onafhanklik IP-reekse kan kies.
Wat is die eerste ding wat by jou opkom as jy aan netwerkisolasie dink? Sekerlik VLAN's и VRF - Virtuele roetering en aanstuur.
Ongelukkig het dit nie gewerk nie. VLAN ID is slegs 12 bisse, wat ons slegs 4096 geïsoleerde segmente gee. Selfs die grootste skakelaars kan 'n maksimum van 1-2 duisend VRF's gebruik. Deur VRF en VLAN saam te gebruik, gee ons net 'n paar miljoen subnette. Dit is beslis nie genoeg vir tienmiljoene huurders nie, wat elkeen verskeie subnette moet kan gebruik.
Ons kan ook eenvoudig nie bekostig om die vereiste aantal groot bokse, byvoorbeeld, by Cisco of Juniper te koop nie. Daar is twee redes: dit is mal duur, en ons wil nie aan die genade van hul ontwikkelings- en regmaakbeleid oorgelewer word nie.
Daar is net een gevolgtrekking – maak jou eie oplossing.
In 2009 het ons aangekondig VPC - Virtuele privaat wolk. Die naam het vasgesteek en nou gebruik baie wolkverskaffers dit ook.
VPC is 'n virtuele netwerk SDN (Sagteware-gedefinieerde netwerk). Ons het besluit om nie spesiale protokolle op die L2- en L3-vlakke uit te vind nie. Die netwerk werk op standaard Ethernet en IP. Vir oordrag oor die netwerk word virtuele masjienverkeer in ons eie protokolomhulsel ingekapsuleer. Dit dui die ID aan wat aan die huurder se VPC behoort.
Klink eenvoudig. Daar is egter verskeie ernstige tegniese uitdagings wat oorkom moet word. Byvoorbeeld, waar en hoe om data te stoor oor die kartering van virtuele MAC/IP-adresse, VPC-ID en ooreenstemmende fisiese MAC/IP. Op AWS-skaal is dit 'n groot tabel wat met minimale toegangsvertragings behoort te werk. Verantwoordelik hiervoor kartering diens, wat in 'n dun laag deur die netwerk versprei word.
In nuwe generasie masjiene word inkapseling deur Nitro-kaarte op hardewarevlak uitgevoer. In ouer gevalle is inkapseling en dekapsulasie sagteware-gebaseer.
Kom ons vind uit hoe dit in algemene terme werk. Kom ons begin met die L2-vlak. Kom ons neem aan dat ons 'n virtuele masjien met IP 10.0.0.2 op 'n fisiese bediener 192.168.0.3 het. Dit stuur data na virtuele masjien 10.0.0.3, wat op 192.168.1.4 leef. 'n ARP-versoek word gegenereer en na die netwerk Nitro-kaart gestuur. Vir eenvoud neem ons aan dat beide virtuele masjiene in dieselfde "blou" VPC leef.
Die kaart vervang die bronadres met sy eie en stuur die ARP-raam aan na die karteringdiens.
Die karteringdiens gee inligting terug wat nodig is vir oordrag oor die L2 fisiese netwerk.
Die Nitro-kaart in die ARP-reaksie vervang die MAC op die fisiese netwerk met 'n adres in die VPC.
Wanneer ons data oordra, draai ons logiese MAC en IP in 'n VPC-omhulsel. Ons stuur dit alles oor die fisiese netwerk deur die toepaslike bron- en bestemmings-IP Nitro-kaarte te gebruik.
Die fisiese masjien waarna die pakket bestem is, voer die kontrole uit. Dit is nodig om die moontlikheid van adres-spoofing te voorkom. Die masjien stuur 'n spesiale versoek aan die karteringdiens en vra: “Vanaf fisiese masjien 192.168.0.3 het ek 'n pakkie ontvang wat bedoel is vir 10.0.0.3 in die blou VPC. Is hy wettig?
Die karteringdiens kontroleer sy hulpbrontoewysingstabel en laat toe of weier die pakkie om deur te gaan. In alle nuwe gevalle is bykomende bekragtiging in Nitro-kaarte ingebed. Dit is onmoontlik om dit selfs teoreties te omseil. Daarom sal spoofing na hulpbronne in 'n ander VPC nie werk nie.
Vervolgens word die data gestuur na die virtuele masjien waarvoor dit bedoel is.
Die karteringdiens werk ook as 'n logiese router vir die oordrag van data tussen virtuele masjiene in verskillende subnette. Alles is konseptueel eenvoudig, ek gaan nie in detail in nie.
Dit blyk dat wanneer elke pakkie oorgedra word, die bedieners na die karteringdiens wend. Hoe om onvermydelike vertragings te hanteer? Kas, natuurlik.
Die skoonheid is dat jy nie die hele groot tafel hoef te cache nie. 'n Fisiese bediener huisves virtuele masjiene vanaf 'n relatief klein aantal VPC's. U hoef slegs inligting oor hierdie VPC's te kas. Die oordrag van data na ander VPC's in die "verstek"-konfigurasie is steeds nie wettig nie. As funksionaliteit soos VPC-peering gebruik word, word inligting oor die ooreenstemmende VPC's addisioneel in die kas gelaai.
Ons het die oordrag van data na die VPC uitgesorteer.
Blackfoot
Wat om te doen in gevalle waar verkeer na buite gestuur moet word, byvoorbeeld na die internet of via VPN na die grond? Help ons hier Blackfoot — AWS interne diens. Dit is ontwikkel deur ons Suid-Afrikaanse span. Daarom is die diens vernoem na 'n pikkewyn wat in Suid-Afrika woon.
Blackfoot dekapsuleer verkeer en doen wat nodig is daarmee. Data word na die internet gestuur soos dit is.
Die data word ontkap en weer in IPsec toegedraai wanneer 'n VPN gebruik word.
Wanneer Direct Connect gebruik word, word verkeer gemerk en na die toepaslike VLAN gestuur.
HyperPlane
Dit is 'n interne vloeibeheerdiens. Baie netwerkdienste vereis monitering datavloeitoestande. Byvoorbeeld, wanneer NAT gebruik word, moet vloeibeheer verseker dat elke IP:bestemmingpoortpaar 'n unieke uitgaande poort het. In die geval van 'n balanseerder NLB - Netwerk Load Balanser, moet die datavloei altyd na dieselfde teiken virtuele masjien gerig word. Security Groups is 'n statige firewall. Dit monitor inkomende verkeer en maak implisiet poorte oop vir uitgaande pakketvloei.
In die AWS-wolk is transmissievertragingsvereistes uiters hoog. Dis hoekom HyperPlane krities vir die prestasie van die hele netwerk.
Hyperplane is gebou op EC2 virtuele masjiene. Hier is geen towerkrag nie, net slinksheid. Die truuk is dat dit virtuele masjiene met groot RAM is. Bewerkings is transaksioneel en word uitsluitlik in die geheue uitgevoer. Dit laat jou toe om vertragings van slegs tientalle mikrosekondes te bereik. Werk met die skyf sal alle produktiwiteit doodmaak.
Hyperplane is 'n verspreide stelsel van 'n groot aantal sulke EC2-masjiene. Elke virtuele masjien het 'n bandwydte van 5 GB/s. Oor die hele streeknetwerk bied dit ongelooflike terabits bandwydte en laat verwerking toe miljoene verbindings per sekonde.
HyperPlane werk net met strome. VPC-pakketinkapseling is heeltemal deursigtig daarvoor. 'n Potensiële kwesbaarheid in hierdie interne diens sal steeds verhoed dat die VPC-isolasie verbreek word. Die vlakke hieronder is verantwoordelik vir sekuriteit.
Raserige buurman
Daar is steeds 'n probleem lawaaierige buurman - lawaaierige buurman. Kom ons neem aan ons het 8 nodusse. Hierdie nodusse verwerk die vloei van alle wolkgebruikers. Alles blyk goed te wees en die las moet eweredig oor alle nodusse versprei word. Nodusse is baie kragtig en dit is moeilik om dit te oorlaai.
Maar ons bou ons argitektuur gebaseer op selfs onwaarskynlike scenario's.
Lae waarskynlikheid beteken nie onmoontlik nie.
Ons kan 'n situasie voorstel waarin een of meer gebruikers te veel las sal genereer. Alle HyperPlane-nodusse is betrokke by die verwerking van hierdie vrag en ander gebruikers kan moontlik 'n soort prestasie-treffer ervaar. Dit breek die konsep van die wolk, waarin huurders geen vermoë het om mekaar te beïnvloed nie.
Hoe om die probleem van 'n lawaaierige buurman op te los? Die eerste ding wat by jou opkom, is skeuring. Ons 8 nodusse is logies verdeel in 4 skerwe van 2 nodusse elk. Nou sal 'n raserige buurman net 'n kwart van alle gebruikers steur, maar dit sal hulle baie steur.
Kom ons doen dinge anders. Ons sal slegs 3 nodusse aan elke gebruiker toeken.
Die truuk is om nodusse ewekansig aan verskillende gebruikers toe te ken. In die prentjie hieronder sny die blou gebruiker nodusse met een van die ander twee gebruikers - groen en oranje.
Met 8 nodusse en 3 gebruikers is die waarskynlikheid dat 'n raserige buurman met een van die gebruikers sal kruis 54%. Dit is met hierdie waarskynlikheid dat 'n blou gebruiker ander huurders sal beïnvloed. Terselfdertyd, net 'n deel van sy vrag. In ons voorbeeld sal hierdie invloed op een of ander manier nie vir almal opmerklik wees nie, maar vir slegs 'n derde van alle gebruikers. Dit is reeds 'n goeie resultaat.
Aantal gebruikers wat sal kruis
Waarskynlikheid in persentasie
0
18%
1
54%
2
26%
3
2%
Kom ons bring die situasie nader aan die werklikheid – kom ons neem 100 nodusse en 5 gebruikers op 5 nodusse. In hierdie geval sal nie een van die nodusse met 'n waarskynlikheid van 77% sny nie.
Aantal gebruikers wat sal kruis
Waarskynlikheid in persentasie
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In 'n werklike situasie, met 'n groot aantal HyperPlane-nodusse en gebruikers, is die potensiële impak van 'n lawaaierige buurman op ander gebruikers minimaal. Hierdie metode word genoem vermenging van versnippering - skuifel versnippering. Dit verminder die negatiewe effek van nodusversaking.
Baie dienste word gebou op die basis van HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netwerk skaal
Kom ons praat nou oor die skaal van die netwerk self. Vir Oktober 2019 bied AWS sy dienste in 22 streke, en nog 9 word beplan.
- Elke streek bevat verskeie beskikbaarheidsones. Daar is 69 van hulle regoor die wêreld.
- Elke AZ bestaan uit dataverwerkingsentrums. Daar is nie meer as 8 van hulle in totaal nie.
- Die datasentrum huisves 'n groot aantal bedieners, sommige met tot 300 000.
Laat ons nou dit alles gemiddeld, vermenigvuldig en kry 'n indrukwekkende syfer wat weerspieël Amazon wolk skaal.
Daar is baie optiese skakels tussen Beskikbaarheidsones en die datasentrum. In een van ons grootste streke is 388 kanale aangelê net vir AZ-kommunikasie tussen mekaar en kommunikasiesentrums met ander streke (Transit Centres). In totaal gee dit mal 5000 Tbit.
Backbone AWS is spesifiek gebou vir en geoptimaliseer vir die wolk. Ons bou dit op die kanale 100 GB / s. Ons beheer hulle heeltemal, met die uitsondering van streke in China. Verkeer word nie met die vragte van ander maatskappye gedeel nie.
Natuurlik is ons nie die enigste wolkverskaffer met 'n privaat ruggraatnetwerk nie. Al hoe meer groot maatskappye volg hierdie pad. Dit word bevestig deur onafhanklike navorsers, byvoorbeeld van .
Die grafiek toon dat die aandeel van inhoudverskaffers en wolkverskaffers groei. As gevolg hiervan neem die aandeel van internetverkeer van ruggraatverskaffers voortdurend af.
Ek sal verduidelik hoekom dit gebeur. Voorheen was die meeste webdienste toeganklik en direk vanaf die internet verbruik. Deesdae is meer en meer bedieners in die wolk geleë en is dit toeganklik via CDN - Inhoudsverspreidingsnetwerk. Om toegang tot 'n hulpbron te verkry, gaan die gebruiker slegs deur die internet na die naaste CDN PoP - Aanwesigheidspunt. Meestal is dit iewers naby. Dan verlaat dit die openbare internet en vlieg deur 'n private ruggraat oor die Atlantiese Oseaan, byvoorbeeld, en kom direk by die hulpbron.
Ek wonder hoe die internet oor 10 jaar gaan verander as hierdie tendens voortduur?
Fisiese kanale
Wetenskaplikes het nog nie uitgepluis hoe om die spoed van lig in die Heelal te verhoog nie, maar hulle het groot vordering gemaak met metodes om dit deur optiese vesel oor te dra. Ons gebruik tans 6912 veselkabels. Dit help om die koste van hul installasie aansienlik te optimaliseer.
In sommige streke moet ons spesiale kabels gebruik. Byvoorbeeld, in die Sydney-streek gebruik ons kabels met 'n spesiale anti-termietbedekking.
Niemand is immuun teen probleme nie en soms word ons kanale beskadig. Die foto regs wys optiese kabels in een van die Amerikaanse streke wat deur konstruksiewerkers geskeur is. As gevolg van die ongeluk is slegs 13 datapakkies verlore, wat verbasend is. Weereens - net 13! Die stelsel het letterlik onmiddellik na rugsteunkanale oorgeskakel – die skaal werk.
Ons het deur sommige van Amazon se wolkdienste en tegnologieë gegalop. Ek hoop dat u ten minste 'n idee het van die omvang van die take wat ons ingenieurs moet oplos. Persoonlik vind ek dit baie opwindend.
Dit is die laaste deel van die trilogie van Vasily Pantyukhin oor die AWS-toestel. IN dele beskryf bedieneroptimalisering en databasisskaal, en in - bedienerlose funksies en Firecracker.
Op in November sal Vasily Pantyukhin nuwe besonderhede van die Amazon-toestel deel. Hy oor die oorsake van mislukkings en die ontwerp van verspreide stelsels by Amazon. 24 Oktober is nog moontlik kaartjie teen 'n goeie prys, en betaal later. Ons wag vir jou by HighLoad++, kom gesels ons!
Bron: will.com