Amazon Web Services sarearen eskala mundu osoko 69 zona da 22 eskualdetan: AEB, Europa, Asia, Afrika eta Australia. Zona bakoitzak gehienez 8 datu-zentro ditu - Datuak Prozesatzeko Zentroak. Datu-zentro bakoitzak milaka edo ehunka mila zerbitzari ditu. Sarea etenaldi-egoera guztiak kontuan hartzeko moduan diseinatuta dago. Esaterako, eskualde guztiak elkarrengandik isolatuta daude, eta irisgarritasun-eremuak hainbat kilometrotako distantzietan bereizten dira. Kablea moztu arren, sistema babeskopia-kanaletara aldatuko da, eta informazio-galera datu-pakete batzuk izango dira. Vasily Pantyukhin-ek sarea zein beste printzipiotan eraikita dagoen eta nola egituratzen den hitz egingo du.
Vasily Pantyukhin Unix administratzaile gisa hasi zen .ru enpresetan, 6 urtez Sun Microsystem hardware handietan lan egin zuen eta 11 urtez datuetan oinarritutako mundua predikatu zuen EMCn. Berez hodei pribatuetara eboluzionatu zen, gero publikoetara pasatu zen. Orain, Amazon Web Services arkitekto gisa, aholkularitza teknikoa ematen du AWS hodeian bizi eta garatzen laguntzeko.
AWS trilogiaren aurreko zatian, Vasilyk zerbitzari fisikoen diseinuan eta datu-baseen eskalatzean sakondu zuen. Nitro txartelak, KVMn oinarritutako hipervisor pertsonalizatua, Amazon Aurora datu-basea - horri guztiari buruz materialan "" Irakurri testuingurua edo ikusi hitzaldiak.
Zati hau sareen eskalatzean zentratuko da, AWSko sistema konplexuenetako bat. Sare lau batetik Hodei Pribatu birtual batera eboluzioa eta bere diseinua, Blackfoot eta HyperPlane-ren barne zerbitzuak, bizilagun zaratatsu baten arazoa, eta amaieran - sarearen, bizkarrezurra eta kable fisikoen eskala. Honi guztiari buruz ebakipean.
Oharra: behean dagoen guztia Vasily-ren iritzi pertsonala da eta baliteke Amazon Web Services-en posizioarekin ez bat etorriko.
Sarearen eskalatzea
AWS hodeia 2006an jarri zen martxan. Bere sarea nahiko primitiboa zen, egitura laua zuena. Helbide pribatuen sorta ohikoa zen hodeiko maizter guztientzat. Makina birtual berri bat abiaraztean, nahi gabe barruti honetako IP helbide erabilgarri bat jaso duzu.
Ikuspegi hau inplementatzeko erraza zen, baina funtsean hodeiaren erabilera mugatu zuen. Bereziki, nahiko zaila izan zen lurrean sare pribatuak eta AWSn konbinatzen zituzten soluzio hibridoak garatzea. Arazo ohikoena IP helbide-barrutiak gainjartzea zen.
Hodei pribatu birtuala
Hodeia eskaria izan zen. Iritsi da eskalagarritasunaz eta hamarka milioi maizterk erabiltzeko aukeraz pentsatzeko unea. Sare laua oztopo nagusi bihurtu da. Hori dela eta, sare mailan erabiltzaileak elkarrengandik nola isolatu pentsatu genuen, IP barrutiak modu independentean aukeratu ahal izateko.
Zein da burura etortzen zaizun lehen gauza sarearen isolamenduari buruz pentsatzen duzunean? Zalantzarik gabe VLANak ΠΈ VRF - Bideratze eta birbidaltze birtuala.
Zoritxarrez, ez zuen funtzionatu. VLAN IDa 12 bit baino ez da, eta horrek 4096 segmentu isolatu baino ez ditu ematen. Etengailu handienek ere 1-2 mila VRF erabil ditzakete gehienez. VRF eta VLAN batera erabiltzeak milioi bat azpisare baino ez dizkigu ematen. Hau ez da nahikoa hamar milioi maizterrentzat, eta horietako bakoitzak hainbat azpisare erabiltzeko gai izan behar du.
Gainera, ezin dugu erosi behar den kutxa handien kopurua, adibidez, Cisco edo Juniper-en. Bi arrazoi daude: zoro garestia da, eta ez dugu haien garapen eta adabaki politiken menpe egon nahi.
Ondorio bakarra dago: egin zure irtenbidea.
2009an iragarri genuen VPC - Hodei pribatu birtuala. Izena itsatsita geratu da eta orain hodeiko hornitzaile askok ere erabiltzen dute.
VPC sare birtual bat da SDN (Software Definitutako Sarea). L2 eta L3 mailetan protokolo berezirik ez asmatzea erabaki genuen. Sarea Ethernet eta IP estandar bidez exekutatzen da. Sarearen bidez transmititzeko, makina birtualaren trafikoa gure protokolo-bilgarri batean kapsulatzen da. Maizterren VPCri dagokion IDa adierazten du.
Sinplea dirudi. Hala ere, gainditu beharreko hainbat erronka tekniko larri daude. Adibidez, non eta nola gorde MAC/IP helbide birtualak, VPC IDa eta dagokion MAC/IP fisikoa mapatzeko datuak. AWS eskalan, sarbide gutxieneko atzerapenekin funtzionatu beharko lukeen taula erraldoia da. Honen arduraduna kartografia zerbitzua, sarean zehar geruza mehe batean hedatuta dagoena.
Belaunaldi berriko makinetan, enkapsulazioa Nitro txartelek egiten dute hardware mailan. Kasu zaharrenetan, kapsulatzea eta deskapsulatzea softwarean oinarritzen dira.
Ikus dezagun nola funtzionatzen duen termino orokorrean. Has gaitezen L2 mailatik. Demagun makina birtual bat dugula IP 10.0.0.2 192.168.0.3 zerbitzari fisiko batean. 10.0.0.3-n bizi den 192.168.1.4 makina birtualera bidaltzen ditu datuak. ARP eskaera bat sortzen da eta sareko Nitro txartelera bidaltzen da. Sinpletasunerako, bi makina birtualak VPC "urdin" berean bizi direla suposatzen dugu.
Mapak iturburu-helbidea berearekin ordezkatzen du eta ARP markoa mapaketa-zerbitzura bidaltzen du.
Kartografia-zerbitzuak L2 sare fisikoan transmititzeko beharrezkoa den informazioa itzultzen du.
ARP erantzuneko Nitro txartelak sare fisikoko MAC ordezkatzen du VPCko helbide batekin.
Datuak transferitzean, MAC eta IP logikoak VPC bilgarri batean biltzen ditugu. Hori guztia sare fisikotik transmititzen dugu iturri eta helmuga egokiak diren IP Nitro txartelak erabiliz.
Paketea helburu duen makina fisikoak egiten du egiaztapena. Hau beharrezkoa da helbideak faltifikatzeko aukera saihesteko. Makinak eskaera berezi bat bidaltzen dio mapa-zerbitzuari eta hauxe galdetzen dio: β192.168.0.3 makina fisikotik 10.0.0.3rako pentsatuta dagoen pakete bat jaso dut VPC urdinean. Zilegi al da?
Kartografia-zerbitzuak baliabideen esleipen-taula egiaztatzen du eta paketeari pasatzen uzten edo ukatzen du. Kasu berri guztietan, baliozkotze gehigarria sartzen da Nitro txarteletan. Teorikoki ere ezinezkoa da saihestea. Hori dela eta, beste VPC bateko baliabideak faltifikatzeak ez du funtzionatuko.
Ondoren, datuak nahi den makina birtualera bidaltzen dira.
Kartografia-zerbitzuak bideratzaile logiko gisa ere funtzionatzen du azpisare desberdinetako makina birtualen artean datuak transferitzeko. Dena kontzeptualki sinplea da, ez naiz xehetasunetan sartuko.
Ematen du pakete bakoitza igortzerakoan zerbitzariek mapa-zerbitzura jotzen dutela. Nola aurre egin ezinbesteko atzerapenei? Cachean gordetzea, Noski.
Edertasuna da ez duzula mahai erraldoi osoa cachean gorde behar. Zerbitzari fisiko batek makina birtualak hartzen ditu VPC kopuru nahiko txiki batetik. VPC hauei buruzko informazioa bakarrik gorde behar duzu. "Lehenetsitako" konfigurazioan datuak beste VPC batzuetara transferitzea oraindik ez da zilegi. VPC-peering bezalako funtzionaltasuna erabiltzen bada, dagozkien VPCei buruzko informazioa cachean kargatuko da gainera.
Datuen transferentzia ordenatu dugu VPCra.
Oin beltza
Zer egin trafikoa kanpoan transmititu behar den kasuetan, adibidez Internetera edo VPN bidez lurrera? Hemen laguntzen gaitu Oin beltza β AWS barne-zerbitzua. Gure Hegoafrikako taldeak garatu du. Horregatik, Hegoafrikan bizi den pinguino baten izena darama zerbitzuari.
Blackfoot-ek trafikoa kentzen du eta horrekin behar dena egiten du. Datuak dauden bezala bidaltzen dira Internetera.
Datuak deskapsulatu eta berriro IPsec-en biltzen dira VPN bat erabiltzean.
Zuzeneko konexioa erabiltzean, trafikoa etiketatu eta dagokion VLANra bidaltzen da.
HiperHegazkina
Hau barne-fluxua kontrolatzeko zerbitzua da. Sareko zerbitzu askok monitorizazioa behar dute datu-fluxuaren egoerak. Adibidez, NAT erabiltzean, fluxuen kontrolak IP:helmuga ataka bikote bakoitzak irteerako ataka bakarra duela ziurtatu behar du. Balantzatzailearen kasuan NLB - Sareko karga-orekatzailea, datu-fluxua beti helburu makina birtual berera zuzendu behar da. Segurtasun Taldeak egoera-suebaki bat da. Sarrerako trafikoa kontrolatzen du eta inplizituki portuak irekitzen ditu irteerako pakete-fluxurako.
AWS hodeian, transmisioaren latentzia-eskakizunak oso altuak dira. Horregatik HiperHegazkina kritikoa sare osoaren errendimendurako.
Hyperplane EC2 makina birtualetan eraikita dago. Hemen ez dago magiarik, maltzurkeria baizik. Trikimailua da RAM handia duten makina birtualak direla. Eragiketak transakzionalak dira eta memorian soilik egiten dira. Horri esker, hamarnaka mikrosegundoko atzerapenak lortzeko aukera ematen du. Diskoarekin lan egiteak produktibitate guztia hilko luke.
Hyperplane horrelako EC2 makina kopuru handi baten sistema banatua da. Makina birtual bakoitzak 5 GB/s-ko banda zabalera du. Eskualdeko sare osoan, banda-zabalera izugarrizko terabitak eskaintzen ditu eta prozesatzeko aukera ematen du segundoko milioika konexio.
HyperPlane-k korronteekin soilik funtzionatzen du. VPC paketeen kapsulatzea guztiz gardena da. Barne-zerbitzu honetan ahultasun potentzial batek VPC isolamendua apurtzea eragotziko luke. Beheko mailak segurtasunaz arduratzen dira.
Bizilagun zaratatsua
Oraindik arazo bat dago bizilagun zaratatsua - bizilagun zaratatsua. Demagun 8 nodo ditugula. Nodo hauek hodeiko erabiltzaile guztien fluxuak prozesatzen dituzte. Dena ondo dagoela dirudi eta karga uniformeki banatu behar da nodo guztietan. Nodoak oso indartsuak dira eta zaila da gainkargatzea.
Baina gure arkitektura agertoki nekezetan oinarrituta eraikitzen dugu.
Probabilitate baxuak ez du esan nahi ezinezkoa.
Erabiltzaile batek edo gehiagok karga gehiegi sortuko lukeen egoera imajina dezakegu. HyperPlane-ko nodo guztiek parte hartzen dute karga hau prozesatzen eta beste erabiltzaile batzuek errendimendu motaren bat izan dezakete. Horrek hodeiaren kontzeptua apurtzen du, maizterrek ez baitute elkarri eragiteko gaitasunik.
Nola konpondu bizilagun zaratatsu baten arazoa? Burura etortzen zaidan lehenengo gauza zatiketa da. Gure 8 nodoak 4 nodoko 2 zatitan banatzen dira logikoki. Orain bizilagun zaratatsu batek erabiltzaile guztien laurdenari bakarrik asaldatuko du, baina asko molestatzen ditu.
Egin ditzagun gauzak beste era batera. Erabiltzaile bakoitzari 3 nodo bakarrik esleituko dizkiogu.
Trikimailua erabiltzaile ezberdinei nodoak ausaz esleitzea da. Beheko irudian, erabiltzaile urdinak nodoak gurutzatzen ditu beste bi erabiltzaileetako batekin - berdea eta laranja.
8 nodo eta 3 erabiltzailerekin, bizilagun zaratatsu bat erabiltzaileetako batekin gurutzatzeko probabilitatea %54koa da. Probabilitate horrekin erabiltzaile urdin batek beste maizterrengan eragina izango du. Aldi berean, bere zamaren zati bat bakarrik. Gure adibidean, eragin hori, nolabait, denek ez dute nabarituko, baizik eta erabiltzaile guztien heren batek bakarrik. Hau dagoeneko emaitza ona da.
Gurutzatuko den erabiltzaile kopurua
Probabilitatea ehunekotan
0
18%
1
54%
2
26%
3
2%
Hurbil dezagun egoera errealitatera - har ditzagun 100 nodo eta 5 erabiltzaile 5 nodotan. Kasu honetan, nodoetako bat ere ez da gurutzatuko %77ko probabilitatearekin.
Gurutzatuko den erabiltzaile kopurua
Probabilitatea ehunekotan
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Egoera erreal batean, HyperPlane nodo eta erabiltzaile kopuru handiarekin, bizilagun zaratatsu batek beste erabiltzaileengan duen eragin potentziala txikia da. Metodo honi deitzen zaio zatiketa nahastuz - nahastu zatiketa. Nodoen hutsegitearen eragin negatiboa gutxitzen du.
Zerbitzu asko HyperPlane-n oinarrituta eraikitzen dira: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Sare-eskala
Orain hitz egin dezagun sarearen beraren tamainaz. 2019ko urrirako AWS-k bere zerbitzuak eskaintzen ditu 22 eskualde, eta beste 9 aurreikusten dira.
- Eskualde bakoitzak hainbat Eskuragarritasun Zona ditu. Munduan zehar 69 daude.
- AZ bakoitza Datuak Prozesatzeko Zentroek osatzen dute. Ez dira guztira 8 baino gehiago.
- Datu zentroak zerbitzari kopuru handia dauka, batzuk 300 arte.
Orain hau guztia batez bestekoa, biderkatu eta islatzen duen zifra ikusgarria lor dezagun Amazon hodei eskala.
Lotura optiko ugari daude erabilgarritasun-guneen eta datu-zentroaren artean. Gure eskualde handienetako batean, 388 kanal jarri dira AZ elkarren arteko komunikaziorako eta beste eskualde batzuekiko komunikazio zentroetarako soilik (Garraio Zentroak). Guztira honek zoramena ematen du 5000 Tbit.
Backbone AWS hodeirako bereziki eraikita dago eta optimizatuta dago. Kanaletan eraikitzen dugu 100 GB / s. Erabat kontrolatzen ditugu, Txinako eskualdeak izan ezik. Trafikoa ez da beste enpresen kargarekin partekatzen.
Jakina, ez gara hodeiko hornitzaile bakarra bizkarrezurreko sare pribatua duena. Gero eta enpresa handi gehiagok jarraitzen dute bide horretatik. Hori baieztatzen dute ikertzaile independenteek, adibidez .
Grafikoak erakusten du eduki-hornitzaileen eta hodeiko hornitzaileen kuota hazten ari dela. Hori dela eta, bizkarrezurreko hornitzaileen Interneteko trafikoaren zatia etengabe murrizten ari da.
Hori zergatik gertatzen den azalduko dut. Aurretik, web-zerbitzu gehienak Internetetik zuzenean eskura daitezke eta kontsumitzen ziren. Gaur egun, gero eta zerbitzari gehiago hodeian kokatzen dira eta bidez eskura daitezke CDN - Edukiak banatzeko sarea. Baliabide batera sartzeko, erabiltzailea Internetetik hurbilen dagoen CDN PoPra bakarrik joaten da - Presentzia puntua. Gehienetan gertuko lekuren batean dago. Gero, Internet publikotik irten eta Atlantikoan zehar bizkarrezurra pribatu batetik hegan egiten du, adibidez, eta zuzenean iristen da baliabidera.
Galdetzen dut nola aldatuko den Internet 10 urte barru joera honek jarraitzen badu?
Kanal fisikoak
Zientzialariek oraindik ez dute asmatu Unibertsoan argiaren abiadura nola handitu, baina aurrerapen handiak egin dituzte zuntz optikoaren bidez transmititzeko metodoetan. Gaur egun 6912 zuntz kable erabiltzen ditugu. Horrek instalazioaren kostua nabarmen optimizatzen laguntzen du.
Eskualde batzuetan kable bereziak erabili behar ditugu. Adibidez, Sydneyko eskualdean termiten aurkako estaldura berezia duten kableak erabiltzen ditugu.
Inor ez da arazoetatik salbu eta batzuetan gure kanalak kaltetzen dira. Eskuineko argazkian, eraikuntzako langileek urratu zituzten Amerikako eskualdeetako batean kable optikoak ageri dira. Istripuaren ondorioz, 13 datu pakete baino ez ziren galdu, eta hori harrigarria da. Beste behin - 13 bakarrik! Sistema literalki berehala aldatu zen babeskopia kanaletara - eskala funtzionatzen ari da.
Amazonen hodeiko zerbitzu eta teknologia batzuetatik lauhazka egin genuen. Espero dut, gutxienez, gure ingeniariek ebatzi behar dituzten zereginen tamainaren ideiaren bat edukitzea. Pertsonalki, oso zirraragarria iruditzen zait.
Hau da Vasily Pantyukhin-en AWS gailuari buruzko trilogiaren azken zatia. IN zatiek zerbitzariaren optimizazioa eta datu-baseen eskalatzea deskribatzen dute, eta barne β Zerbitzaririk gabeko funtzioak eta Petardo.
On azaroan Vasily Pantyukhin-ek Amazon gailuaren xehetasun berriak partekatuko ditu. Berak akatsen arrazoiei eta Amazon-en banatutako sistemen diseinuari buruz. Urriaren 24a posible da oraindik txartela prezio onean, eta gero ordaindu. HighLoad++-en zure zain gaude, zatoz hitz egitera!
Iturria: www.habr.com