Shkalla e rrjetit të Shërbimeve Ueb Amazon është 69 zona në të gjithë botën në 22 rajone: SHBA, Evropë, Azi, Afrikë dhe Australi. Çdo zonë përmban deri në 8 qendra të dhënash - Qendrat e Përpunimit të të Dhënave. Çdo qendër e të dhënave ka mijëra ose qindra mijëra serverë. Rrjeti është projektuar në atë mënyrë që të merren parasysh të gjithë skenarët e pamundshëm të ndërprerjeve. Për shembull, të gjitha rajonet janë të izoluara nga njëri-tjetri dhe zonat e aksesueshmërisë janë të ndara në distanca prej disa kilometrash. Edhe nëse e prisni kabllon, sistemi do të kalojë në kanale rezervë dhe humbja e informacionit do të arrijë në disa paketa të dhënash. Vasily Pantyukhin do të flasë mbi cilat parime të tjera është ndërtuar rrjeti dhe si është strukturuar.
Vasily Pantyukhin filloi si administrator i Unix-it në kompanitë .ru, punoi në pajisje të mëdha Sun Microsystem për 6 vjet dhe predikoi një botë të përqendruar te të dhënat për 11 vjet në EMC. Natyrisht, ajo evoluoi në retë private, më pas u zhvendos në ato publike. Tani, si një arkitekt i Shërbimeve Ueb në Amazon, ai ofron këshilla teknike për të ndihmuar në jetën dhe zhvillimin në renë AWS.
Në pjesën e mëparshme të trilogjisë AWS, Vasily u zhyt në hartimin e serverëve fizikë dhe shkallëzimin e bazës së të dhënave. Kartat Nitro, hipervizori i personalizuar i bazuar në KVM, baza e të dhënave Amazon Aurora - për të gjitha këto në material "" Lexoni për kontekstin ose shikoni fjalimet.
Kjo pjesë do të fokusohet në shkallëzimin e rrjetit, një nga sistemet më komplekse në AWS. Evolucioni nga një rrjet i sheshtë në një Cloud Private Virtuale dhe dizajni i tij, shërbimet e brendshme të Blackfoot dhe HyperPlane, problemi i një fqinji të zhurmshëm dhe në fund - shkalla e rrjetit, shtylla kurrizore dhe kabllot fizike. Rreth gjithë kësaj nën prerje.
Mohim përgjegjësie: gjithçka më poshtë është mendimi personal i Vasily dhe mund të mos përkojë me pozicionin e Shërbimeve Ueb Amazon.
Shkallëzimi i rrjetit
Reja AWS u lançua në vitin 2006. Rrjeti i tij ishte mjaft primitiv - me një strukturë të sheshtë. Gama e adresave private ishte e zakonshme për të gjithë qiramarrësit e cloud. Kur nisni një makinë të re virtuale, ju aksidentalisht keni marrë një adresë IP të disponueshme nga kjo gamë.
Kjo qasje ishte e lehtë për t'u zbatuar, por thelbësisht e kufizoi përdorimin e cloud. Në veçanti, ishte mjaft e vështirë të zhvilloheshin zgjidhje hibride që kombinonin rrjetet private në terren dhe në AWS. Problemi më i zakonshëm ishte mbivendosja e intervaleve të adresave IP.
Reja Virtuale Private
Reja doli të ishte në kërkesë. Ka ardhur koha të mendojmë për shkallëzueshmërinë dhe mundësinë e përdorimit të saj nga dhjetëra miliona qiramarrës. Rrjeti i sheshtë është kthyer në një pengesë të madhe. Prandaj, ne menduam se si t'i izolojmë përdoruesit nga njëri-tjetri në nivelin e rrjetit, në mënyrë që ata të mund të zgjedhin në mënyrë të pavarur diapazonin e IP-së.
Cila është gjëja e parë që ju vjen në mendje kur mendoni për izolimin e rrjetit? Sigurisht VLAN-et и VRF - Virtual Routing dhe Forwarding.
Fatkeqësisht, nuk funksionoi. VLAN ID është vetëm 12 bit, që na jep vetëm 4096 segmente të izoluara. Edhe çelsat më të mëdhenj mund të përdorin maksimumi 1-2 mijë VRF. Përdorimi i VRF dhe VLAN së bashku na jep vetëm disa milionë nënrrjeta. Kjo definitivisht nuk mjafton për dhjetëra miliona qiramarrës, secila prej të cilëve duhet të jetë në gjendje të përdorë nënrrjeta të shumta.
Ne gjithashtu thjesht nuk mund të përballojmë të blejmë numrin e kërkuar të kutive të mëdha, për shembull, nga Cisco ose Juniper. Ka dy arsye: është çmendurisht e shtrenjtë dhe ne nuk duam të jemi në mëshirën e politikave të tyre të zhvillimit dhe rregullimit.
Ekziston vetëm një përfundim - bëni zgjidhjen tuaj.
Në vitin 2009 kemi shpallur VPC - Reja Virtuale Private. Emri ngeci dhe tani e përdorin edhe shumë ofrues të reve kompjuterike.
VPC është një rrjet virtual Sdn (Rrjeti i definuar nga softueri). Ne vendosëm të mos shpiknim protokolle speciale në nivelet L2 dhe L3. Rrjeti funksionon në Ethernet dhe IP standarde. Për transmetimin përmes rrjetit, trafiku i makinës virtuale është i kapsuluar në mbështjellësin tonë të protokollit. Ai tregon ID-në që i përket VPC-së së qiramarrësit.
Tingëllon e thjeshtë. Megjithatë, ka disa sfida serioze teknike që duhen kapërcyer. Për shembull, ku dhe si të ruhen të dhënat për hartimin e adresave virtuale MAC/IP, ID VPC dhe MAC/IP fizike përkatëse. Në shkallën AWS, kjo është një tabelë e madhe që duhet të funksionojë me vonesa minimale të aksesit. Përgjegjës për këtë shërbimi i hartës, e cila shtrihet në një shtresë të hollë në të gjithë rrjetin.
Në makinat e gjeneratës së re, kapsulimi kryhet nga kartat Nitro në nivel harduer. Në raste të vjetra, kapsulimi dhe dekapsulimi bazohen në softuer.
Le të kuptojmë se si funksionon në terma të përgjithshëm. Le të fillojmë me nivelin L2. Le të supozojmë se kemi një makinë virtuale me IP 10.0.0.2 në një server fizik 192.168.0.3. Ai dërgon të dhëna në makinën virtuale 10.0.0.3, e cila jeton në 192.168.1.4. Një kërkesë ARP gjenerohet dhe dërgohet në kartën Nitro të rrjetit. Për thjeshtësi, supozojmë se të dy makinat virtuale jetojnë në të njëjtin VPC "blu".
Harta zëvendëson adresën e burimit me të sajën dhe e përcjell kornizën ARP te shërbimi i hartës.
Shërbimi i hartës kthen informacionin që është i nevojshëm për transmetim në rrjetin fizik L2.
Karta Nitro në përgjigjen ARP zëvendëson MAC në rrjetin fizik me një adresë në VPC.
Kur transferojmë të dhëna, ne mbështjellim MAC dhe IP logjike në një mbështjellës VPC. Ne i transmetojmë të gjitha këto përmes rrjetit fizik duke përdorur kartat e duhura IP Nitro të burimit dhe destinacionit.
Makina fizike për të cilën është destinuar paketa kryen kontrollin. Kjo është e nevojshme për të parandaluar mundësinë e mashtrimit të adresës. Makina i dërgon një kërkesë të veçantë shërbimit të hartës dhe pyet: "Nga makina fizike 192.168.0.3 mora një paketë që është menduar për 10.0.0.3 në VPC blu. A është ai legjitim?
Shërbimi i hartës kontrollon tabelën e tij të shpërndarjes së burimeve dhe lejon ose mohon kalimin e paketës. Në të gjitha rastet e reja, vlefshmëria shtesë është ngulitur në kartat Nitro. Është e pamundur ta anashkalosh atë edhe teorikisht. Prandaj, mashtrimi i burimeve në një tjetër VPC nuk do të funksionojë.
Më pas, të dhënat dërgohen në makinën virtuale për të cilën janë menduar.
Shërbimi i hartës funksionon gjithashtu si një ruter logjik për transferimin e të dhënave midis makinave virtuale në nënrrjeta të ndryshme. Gjithçka është konceptualisht e thjeshtë, nuk do të hyj në detaje.
Rezulton se kur transmetohet çdo paketë, serverët kthehen në shërbimin e hartës. Si të merreni me vonesat e pashmangshme? Caching, sigurisht.
Bukuria është se nuk keni nevojë të ruani të gjithë tabelën e madhe. Një server fizik pret makina virtuale nga një numër relativisht i vogël VPC. Ju duhet vetëm të ruani informacione në memorie për këto VPC. Transferimi i të dhënave në VPC të tjera në konfigurimin "default" është ende i paligjshëm. Nëse përdoret funksione të tilla si VPC-peering, atëherë informacioni për VPC-të përkatëse ngarkohet gjithashtu në cache.
Ne zgjidhëm transferimin e të dhënave në VPC.
Blackfoot
Çfarë duhet bërë në rastet kur trafiku duhet të transmetohet jashtë, për shembull në internet ose përmes VPN në tokë? Na ndihmon këtu Blackfoot — Shërbimi i brendshëm AWS. Është zhvilluar nga ekipi ynë i Afrikës së Jugut. Kjo është arsyeja pse shërbimi është emëruar pas një pinguini që jeton në Afrikën e Jugut.
Blackfoot dekapsulon trafikun dhe bën atë që nevojitet me të. Të dhënat dërgohen në internet siç janë.
Të dhënat dekapsulohen dhe ri-mbështjellen në IPsec kur përdorni një VPN.
Kur përdorni Direct Connect, trafiku etiketohet dhe dërgohet në VLAN-in e duhur.
Hiperplani
Ky është një shërbim i kontrollit të brendshëm të rrjedhës. Shumë shërbime të rrjetit kërkojnë monitorim gjendjet e rrjedhës së të dhënave. Për shembull, kur përdorni NAT, kontrolli i rrjedhës duhet të sigurojë që çdo çift porti IP: destinacion të ketë një portë unike dalëse. Në rastin e një balancuesi NLB - Balancues i ngarkesës në rrjet, rrjedha e të dhënave duhet të drejtohet gjithmonë në të njëjtën makinë virtuale të synuar. Grupet e Sigurisë është një mur zjarri shtetëror. Ai monitoron trafikun në hyrje dhe hap portat për rrjedhën e paketave dalëse.
Në renë AWS, kërkesat për vonesë të transmetimit janë jashtëzakonisht të larta. Kjo është arsyeja pse Hiperplani kritike për performancën e të gjithë rrjetit.
Hyperplane është ndërtuar në makinat virtuale EC2. Këtu nuk ka magji, ka vetëm dinakëri. Truku është se këto janë makina virtuale me RAM të madhe. Operacionet janë transaksionale dhe kryhen ekskluzivisht në memorie. Kjo ju lejon të arrini vonesa prej vetëm dhjetëra mikrosekonda. Puna me diskun do të vriste të gjithë produktivitetin.
Hyperplane është një sistem i shpërndarë i një numri të madh makinash të tilla EC2. Çdo makinë virtuale ka një gjerësi brezi prej 5 GB/s. Në të gjithë rrjetin rajonal, kjo siguron terabitë të pabesueshme të gjerësisë së brezit dhe lejon përpunimin miliona lidhje në sekondë.
HyperPlane funksionon vetëm me transmetime. Enkapsulimi i paketave VPC është plotësisht transparent për të. Një cenueshmëri e mundshme në këtë shërbim të brendshëm ende do të parandalonte thyerjen e izolimit të VPC. Nivelet e mëposhtme janë përgjegjëse për sigurinë.
Komshi i zhurmshëm
Ka ende një problem fqinj i zhurmshëm - fqinj i zhurmshëm. Le të supozojmë se kemi 8 nyje. Këto nyje përpunojnë flukset e të gjithë përdoruesve të cloud. Gjithçka duket se është në rregull dhe ngarkesa duhet të shpërndahet në mënyrë të barabartë në të gjitha nyjet. Nyjet janë shumë të fuqishme dhe është e vështirë t'i mbingarkosh ato.
Por ne e ndërtojmë arkitekturën tonë bazuar në skenarë madje të pamundur.
Probabiliteti i ulët nuk do të thotë e pamundur.
Mund të imagjinojmë një situatë në të cilën një ose më shumë përdorues do të gjeneronin shumë ngarkesë. Të gjitha nyjet HyperPlane janë të përfshira në përpunimin e kësaj ngarkese dhe përdoruesit e tjerë mund të përjetojnë një lloj goditjeje të performancës. Kjo thyen konceptin e resë, në të cilën qiramarrësit nuk kanë aftësi të ndikojnë në njëri-tjetrin.
Si ta zgjidhni problemin e një fqinji të zhurmshëm? Gjëja e parë që ju vjen në mendje është grisja. 8 nyjet tona ndahen logjikisht në 4 copëza nga 2 nyje secila. Tani një fqinj i zhurmshëm do të shqetësojë vetëm një të katërtën e të gjithë përdoruesve, por do t'i shqetësojë ata shumë.
Le t'i bëjmë gjërat ndryshe. Ne do të ndajmë vetëm 3 nyje për çdo përdorues.
Truku është të caktoni rastësisht nyje për përdorues të ndryshëm. Në foton më poshtë, përdoruesi blu kryqëzon nyjet me një nga dy përdoruesit e tjerë - jeshile dhe portokalli.
Me 8 nyje dhe 3 përdorues, probabiliteti që një fqinj i zhurmshëm të kryqëzohet me një nga përdoruesit është 54%. Është me këtë probabilitet që një përdorues blu të ndikojë në qiramarrësit e tjerë. Në të njëjtën kohë, vetëm një pjesë e ngarkesës së saj. Në shembullin tonë, ky ndikim do të jetë të paktën disi i dukshëm jo për të gjithë, por vetëm për një të tretën e të gjithë përdoruesve. Ky është tashmë një rezultat i mirë.
Numri i përdoruesve që do të kryqëzohen
Probabiliteti në përqindje
0
18%
1
54%
2
26%
3
2%
Le ta afrojmë situatën me realitetin - le të marrim 100 nyje dhe 5 përdorues në 5 nyje. Në këtë rast, asnjë nga nyjet nuk do të kryqëzohet me një probabilitet prej 77%.
Numri i përdoruesve që do të kryqëzohen
Probabiliteti në përqindje
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Në një situatë reale, me një numër të madh të nyjeve dhe përdoruesve të HyperPlane, ndikimi i mundshëm i një fqinji të zhurmshëm tek përdoruesit e tjerë është minimal. Kjo metodë quhet përzierja e copëtimit - copëzimi i përzier. Ai minimizon efektin negativ të dështimit të nyjeve.
Shumë shërbime janë ndërtuar në bazë të HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Shkalla e rrjetit
Tani le të flasim për shkallën e vetë rrjetit. Për tetor 2019 AWS ofron shërbimet e saj në 22 rajone, dhe janë planifikuar edhe 9 të tjera.
- Çdo rajon përmban disa zona të disponueshmërisë. Janë 69 prej tyre në mbarë botën.
- Çdo AZ përbëhet nga Qendrat e Përpunimit të të Dhënave. Nuk janë më shumë se 8 prej tyre në total.
- Qendra e të dhënave strehon një numër të madh serverësh, disa me deri në 300.
Tani le të mesatarizojmë gjithë këtë, të shumëzojmë dhe të marrim një shifër mbresëlënëse që reflekton Shkalla e reve në Amazon.
Ka shumë lidhje optike midis Zonave të Disponueshmërisë dhe qendrës së të dhënave. Në një nga rajonet tona më të mëdha, janë vendosur 388 kanale vetëm për komunikimin AZ ndërmjet njëri-tjetrit dhe qendrave të komunikimit me rajonet e tjera (Qendrat Transit). Në total kjo jep çmenduri 5000 Tbit.
Backbone AWS është ndërtuar posaçërisht për dhe optimizuar për cloud. Ne e ndërtojmë atë në kanale 100 GB / s. Ne i kontrollojmë plotësisht, me përjashtim të rajoneve në Kinë. Trafiku nuk ndahet me ngarkesat e kompanive të tjera.
Sigurisht, ne nuk jemi i vetmi ofrues i reve kompjuterike me një rrjet themelor privat. Gjithnjë e më shumë kompani të mëdha po ndjekin këtë rrugë. Kjo konfirmohet nga studiues të pavarur, për shembull nga .
Grafiku tregon se pjesa e ofruesve të përmbajtjes dhe ofruesve të cloud po rritet. Për shkak të kësaj, pjesa e trafikut në internet të ofruesve të shtyllës kurrizore është vazhdimisht në rënie.
Unë do të shpjegoj pse ndodh kjo. Më parë, shumica e shërbimeve të internetit ishin të aksesueshme dhe konsumoheshin drejtpërdrejt nga interneti. Në ditët e sotme, gjithnjë e më shumë serverë janë të vendosur në cloud dhe janë të aksesueshëm nëpërmjet CDN - Rrjeti i shpërndarjes së përmbajtjes. Për të hyrë në një burim, përdoruesi kalon përmes Internetit vetëm në CDN PoP më të afërt - Pika e Prezencës. Më shpesh është diku afër. Pastaj largohet nga Interneti publik dhe fluturon përmes një shtylle private përtej Atlantikut, për shembull, dhe shkon drejtpërdrejt te burimi.
Pyes veten se si do të ndryshojë interneti në 10 vjet nëse kjo prirje vazhdon?
Kanalet fizike
Shkencëtarët nuk e kanë kuptuar ende se si të rrisin shpejtësinë e dritës në Univers, por ata kanë bërë përparim të madh në metodat e transmetimit të saj përmes fibrës optike. Aktualisht ne përdorim 6912 kabllo fibër. Kjo ndihmon për të optimizuar ndjeshëm koston e instalimit të tyre.
Në disa rajone duhet të përdorim kabllo speciale. Për shembull, në rajonin e Sidneit ne përdorim kabllo me një shtresë të veçantë kundër termiteve.
Askush nuk është i imunizuar nga problemet dhe ndonjëherë kanalet tona dëmtohen. Fotografia në të djathtë tregon kabllot optike në një nga rajonet amerikane që u grisën nga punëtorët e ndërtimit. Si pasojë e aksidentit humbën vetëm 13 pako të dhënash, gjë që është befasuese. Edhe një herë - vetëm 13! Sistemi fjalë për fjalë kaloi menjëherë në kanale rezervë - shkalla po funksionon.
Ne galopuam përmes disa prej shërbimeve dhe teknologjive cloud të Amazon. Shpresoj që të keni të paktën një ide për shkallën e detyrave që inxhinierët tanë duhet të zgjidhin. Personalisht, kjo gjë më duket shumë emocionuese.
Kjo është pjesa e fundit e trilogjisë nga Vasily Pantyukhin në lidhje me pajisjen AWS. NË pjesët përshkruajnë optimizimin e serverit dhe shkallëzimin e bazës së të dhënave, dhe në — funksionet pa server dhe Firecracker.
Mbi në nëntor Vasily Pantyukhin do të ndajë detaje të reja të pajisjes Amazon. Ai në lidhje me shkaqet e dështimeve dhe projektimin e sistemeve të shpërndara në Amazon. 24 tetori është ende i mundur bileta me një çmim të mirë dhe paguani më vonë. Ju presim në HighLoad++, ejani të bisedojmë!
Burimi: www.habr.com