Skala e rrjetit Amazon Web Services përbëhet nga 69 zona në mbarë botën në 22 rajone: SHBA, Evropë, Azi, Afrikë dhe Australi. Në çdo zonë ndodhen deri në 8 Qendra të të Dhënave (QTT). Në çdo QTT ka mijëra ose qindra mijëra servera. Rrjeti është ndërtuar në mënyrë që të gjitha skenarët e pakët të ndërprerjeve të shërbimit të merren parasysh. Për shembull, të gjitha rajonet janë të izoluar nga njëra-tjetra, dhe zonat e disponueshmërisë janë të shpërndara në distanca disa kilometra. Edhe nëse pritet kabulli, sistemi do të kalojë në kanale rezervë, dhe humbja e informacionit do të përbëhet nga njësi paketash të dhënash. Në lidhje me principet e tjera mbi të cilat është ndërtuar rrjeti dhe si është organizuar, do të tregojë Vasiliy Pantyukhin.
Vasiliy Pantyukhin ka filluar si administrator Unix në kompanitë .ru, ka kaluar 6 vjet me pajisje të mëdha nga Sun Microsystems, dhe 11 vjet ka predikuar qendrim të orientuar nga të dhënat në EMC. Në mënyrë natyrale, ka evoluar në cloud privat, më pas u bashkua me atë publik. Tani, si arkitekt i Amazon Web Services, ndihmon me këshillat teknike që të jetojnë dhe zhvillohen në cloud AWS.
NĂ« pjesĂ«n e mĂ«parshme tĂ« trilogjisĂ« pĂ«r strukturĂ«n e AWS, Vasiliy theksoi funksionimin 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Ă« materialin "". Lexoni pĂ«r tĂ« zhytur nĂ« kontekst, ose shikoni tĂ« paraqitjes.
NĂ« kĂ«tĂ« pjesĂ« do tĂ« flasim pĂ«r shkallĂ«zimin e rrjetit â njĂ« nga sistemet mĂ« tĂ« komplikuara nĂ« AWS. Evolucioni nga rrjeti i sheshtĂ« nĂ« Rrjetin Privat Virtual dhe struktura e tij, shĂ«rbimet e brendshme Blackfoot dhe HyperPlane, problemi i fqinjit tĂ« zhurmshĂ«m, dhe nĂ« fund â shkallĂ«t e rrjetit, backbone dhe kabujt fizikĂ«. PĂ«r tĂ« gjitha kĂ«to mĂ« poshtĂ«.
ParalajmĂ«rim: gjithçka mĂ« poshtĂ« â mendim personal i Vasiliy, dhe mund tĂ« mos pĂ«rkojĂ« me pozitat e Amazon Web Services.
Shkallëzimi i rrjetit
Cloud AWS Ă«shtĂ« lançuar nĂ« vitin 2006. Rrjeti i tij ishte mjaft primitiv â me strukturĂ« tĂ« sheshtĂ«. CilĂ«sia e adresave private ishte e zakonshme pĂ«r tĂ« gjithĂ« pĂ«rdoruesit e cloud-it. Kur nisje njĂ« makinĂ« virtuale tĂ« re rastĂ«sisht merrje njĂ« adresĂ« IP tĂ« disponueshme nga ky gamĂ«.
Kjo qasje ishte e lehtë për t'u implementuar, por substantialisht kufizonte përdorimin e cloud-it. Në veçanti, ishte mjaft e vështirë të zhvilloheshin zgjidhje hibride, ku bashkoheshin rrjetet private në tokë dhe në AWS. Problemi më i zakonshëm ishte në përputhjen e gamave të adresave IP.
Reku i Privat Virtual
Reku ka qenë shumë i kërkuar. Ka ardhur koha të mendojmë për shkallëzueshmërinë dhe mundësinë e përdorimit të tij nga miliona të qiramarës. Rrjeti i sheshtë është bërë pengesa kryesore. Prandaj, kemi filluar të mendojmë si t'i izolojmë përdoruesit nga njëri-tjetri në nivelin e rrjetit, në mënyrë që ata të mund të zgjedhin vetë ranges IP.
Ăka tĂ« parĂ«n bie nĂ« mendje kur mendoni pĂ«r izolimin rrjetor? Sigurisht VLAN dhe VRF â RrugĂ«zim dhe PĂ«rçues Virtual.
Fatkeqësisht, kjo nuk funksionoi. VLAN ID është vetëm 12 bit, që na jep vetëm 4096 segmente të izoluar. Edhe në kalimtarët më të mëdhenj, mund të përdoren maksimumi 1-2 mijë VRF. Ndërveprimi i VRF dhe VLAN na jep vetëm disa miliona nënshembuj. Kjo është me të vërtetë e pamjaftueshme për dhjetëra miliona të qiramarës, secili prej të cilëve duhet të ketë mundësinë të përdorë disa nënshembuj.
Po ashtu, ne thjesht nuk mund të përballojmë blerjen e numrit të kërkuar të kutive të mëdha, për shembull, nga Cisco ose Juniper. Ka dy arsye: është joshës çmimi, dhe ne nuk duam të bëhemi të varur nga politika e tyre e zhvillimit dhe patching.
PĂ«rfundimi Ă«shtĂ« njĂ« â tĂ« gatuajmĂ« zgjidhjen tonĂ«.
NĂ« vitin 2009 ne shpallĂ«m VPC â Reku i Privat Virtual. Emri u bĂ« i njohur dhe tani shumĂ« ofrues tĂ« tjerĂ« tĂ« cloud-it e pĂ«rdorin gjithashtu atĂ«.
VPC është një rrjet virtual SDN (Rrjeti e Definuar nga Softueri). Ne vendosëm të mos shpikim protokolle të veçanta në nivelet L2 dhe L3. Rrjeti funksionon mbi Ethernet dhe IP standard. Për të dërguar trafikun, lëvizja e makinerive virtuale incapsulohet në një mbulesë të protokollit tonë. Aty tregohet ID, i cili i përket VPC të qiramarës.
Dëgjohet e thjeshtë. Megjithatë, duhet të zgjidhim disa probleme teknike serioze. Për shembull, ku dhe si të ruajmë të dhënat mbi kartat e virtualizuara MAC/IP, VPC ID dhe MAC/IP të përkatshme fizike. Një tabelë e tillë që do të punojë me vonesa minimale, është një sfidë e madhe në shkallë AWS. Kjo është përgjegjësi e shërbimit të kartës, i cili është shtrirë nën një shtresë të hollë në të gjithë rrjetin.
NĂ« makinat e brezit tĂ« ri, incapsulimi kryhet nga kartat Nitro nĂ« nivelin e harduerit. NĂ« instancat e vjetra, incapsulimi dhe dekapitulimi janĂ« programore.Â
Të shohim se si funksionon në terma të përgjithshëm. Le të fillojmë nga niveli L2. Supozojmë se kemi një virtualkë me IP 10.0.0.2 në serverin fizik 192.168.0.3. Ajo dërgon të dhëna në makinë virtuale 10.0.0.3, e cila jeton në 192.168.1.4. Krijohet një kërkesë ARP, e cila shkon në kartën rrjetike Nitro. Për thjeshtsi, le të supozojmë se të dy virtualkat jetojnë në një VPC "blu".
Karta zëvendëson adresën e burimit me të vetën dhe dërgon kornizën ARP në shërbimin e hartës.
Shërbimi i hartës kthen informacionin e nevojshëm për transmetimin në rrjetin fizik L2.
Nitro-karta në përgjigjen ARP zëvendëson MAC-in në rrjetin fizik me adresën në VPC.
Gjatë dërgimit të të dhënave, ne mbështjellim MAC dhe IP logjik në një mbështjellës VPC. Të gjitha këto i dërgojmë në rrjetin fizik duke përdorur IP-të përkatëse të kartave Nitro të burimit dhe destinacionit.
MakinĂ« fizike, pĂ«r tĂ« cilĂ«n Ă«shtĂ« paketa, kryen njĂ« kontroll. Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« parandaluar mundĂ«sinĂ« e zĂ«vendĂ«simit tĂ« adresave. MakinĂ« dĂ«rgon njĂ« kĂ«rkesĂ« speciale nĂ« shĂ«rbimin e hartĂ«s dhe pyet: "Nga makina fizike 192.168.0.3 kam marrĂ« njĂ« paketĂ«, e cila Ă«shtĂ« e destinuar pĂ«r 10.0.0.3 nĂ« VPC "tĂ« kaltĂ«r". A Ă«shtĂ« legjitime?"Â
Shërbimi i hartës kontrollon me tabelën e tij të vendosjes së burimeve dhe lejon, ose ndalon kalimin e paketës. Në të gjitha instancat e reja, një verifikim shtesë është i koduar në kartat Nitro. Kjo nuk mund të shmangesh as teorikisht. Prandaj, spoofing në burimet e VPC tjetër nuk do të funksionojë.
MĂ« pas, tĂ« dhĂ«nat dĂ«rgohen nĂ« makinĂ«n virtuale pĂ«r tĂ« cilĂ«n ato janĂ« tĂ« destinuara.Â
Shërbimi i hartës funksionon gjithashtu si një ruter logjik për transmetimin e të dhënave mes virtualkave në nënrrjeta të ndryshme. Aty konceptualisht gjithçka është e thjeshtë, nuk do ta shqyrtoj në detaje.
Kështu që, gjatë dërgimit të çdo pakete, serverët i drejtohen shërbimit të hartës. Si të luftojmë me vonesat e pashmangshme? Me cache, sigurisht.
E gjithĂ« bukuria Ă«shtĂ« se nuk Ă«shtĂ« e nevojshme tĂ« ruhet e gjithĂ« tabela e madhe. NĂ« serverin fizik jetojnĂ« virtualka nga njĂ« numĂ«r relativisht i vogĂ«l VPC. Duhet tĂ« ruhet informacioni vetĂ«m pĂ«r kĂ«to VPC. DĂ«rgimi i tĂ« dhĂ«nave nĂ« VPC tĂ« tjera nĂ« konfigurimin "default" megjithatĂ« nuk Ă«shtĂ« legjitim. NĂ«se pĂ«rdoret njĂ« funksionalitet si VPC-peering, atĂ«herĂ« informacioni mbi VPC-tĂ« pĂ«rkatĂ«se ngarkohet shtesĂ« nĂ« cache.Â
Kemi sqaruar dërgimin e të dhënave në VPC.
Blackfoot
Si si tĂ« veprojmĂ« nĂ« raste kur trafik duhet tĂ« dĂ«rgohet jashtĂ«, pĂ«r shembull nĂ« Internet ose pĂ«rmes VPN nĂ« tokĂ«? KĂ«tu na ndihmon Blackfoot â shĂ«rbimi i brendshĂ«m AWS. Ai Ă«shtĂ« zhvilluar nga ekipi ynĂ« nĂ« AfrikĂ«n e Jugut. KĂ«shtu qĂ« shĂ«rbimi ka marrĂ« emrin nga pinguini qĂ« jeton nĂ« AfrikĂ«n e Jugut.
Blackfoot dekapsulon trafikun dhe bën me të atë që nevojitet. Të dhënat në Internet dërgohen siç janë.
Të dhënat dekapsulohen dhe pastaj shtrihen përsëri në paketat IPsec kur përdoret VPN.
Në përdorimin e Direct Connect, trafiku etiketohen dhe dërgohen në VLAN-in përkatës.
HyperPlane
Ky Ă«shtĂ« njĂ« shĂ«rbim i brendshĂ«m pĂ«r kontrollin e trafikut. ShumĂ« shĂ«rbime rrjetesh kĂ«rkojnĂ« kontrollin e statusit tĂ« trafikut tĂ« dhĂ«nash. PĂ«r shembull, nĂ« pĂ«rdorimin e NAT, kontrolli i trafikut duhet tĂ« sigurojĂ« qĂ« çdo çift "IP: porta e destinacionit" tĂ« korrespondon me njĂ« port tĂ« vetĂ«m dalĂ«s. NĂ« rastin e balancuesit NLB â Balancuesi i NgarkesĂ«s nĂ« Rrjet, trafiku i tĂ« dhĂ«nave gjithmonĂ« duhet tĂ« drejtohet nĂ« tĂ« njĂ«jtĂ«n makinĂ« virtuale tĂ« destinacionit. Grupet e SigurisĂ« â janĂ« njĂ« firewall me ruajtjen e statusit. Ai ndjek trafikun e ardhshĂ«m dhe hap portat pĂ«r trafikun dalĂ«s nĂ« mĂ«nyrĂ« tĂ« heshtur.
Në cloud-in AWS, kërkesat për vonesa transmetimi janë jashtëzakonisht të larta. Prandaj HyperPlane është kritik për funksionalitetin e tërë rrjetit.
Hyperplane Ă«shtĂ« ndĂ«rtuar mbi makina virtuale EC2. KĂ«tu nuk ka magji, vetĂ«m mjeshtĂ«ri. MjeshtĂ«ria qĂ«ndron nĂ« faktin se kĂ«to janĂ« makina virtuale me RAM tĂ« madh. Operacionet janĂ« transaksionale dhe kryhen ekskluzivisht nĂ« memorie. Kjo lejon tĂ« arrijmĂ« vonesa vetĂ«m disa mikrosekondash. NdĂ«rveprimi me disqet do tĂ« shkatĂ«rronte tĂ«rĂ« performancĂ«n.Â
Hyperplane Ă«shtĂ« njĂ« sistem i shpĂ«rndarĂ« nga njĂ« numĂ«r tĂ« madh tĂ« tillĂ« EC2-makina. Ădo makinĂ« virtuale ka njĂ« kapacitet prej 5 GB/s. NĂ« shkallĂ«n e tĂ«rĂ« rrjetit rajonal, kjo ofron terabite tĂ« furishme kapaciteti dhe lejon trajtimin e miliona lidhjeve nĂ« sekondĂ«..
HyperPlane punon vetëm me rrjedha. VPC incapsulimi i pakot është plotësisht transparent për të. Një potencial për të bërë dëm në këtë shërbim të brendshëm sërish nuk do t'i lejonte të kalonte izolimin VPC. Siguria mbrohet nga nivelet më poshtë.
Fqinja e zhurmshme
Ka gjithashtu njĂ« problem me fqinjĂ«t e zhurmshĂ«m â fqinj i zhurmshĂ«m. Le tĂ« supozojmĂ« se kemi 8 node. KĂ«to node pĂ«rpunojnĂ« flukset e tĂ« gjithĂ« pĂ«rdoruesve tĂ« cloud-it. Duket se gjithçka Ă«shtĂ« nĂ« rregull dhe ngarkesa duhet tĂ« shpĂ«rndahet nĂ« mĂ«nyrĂ« tĂ« barabartĂ« mbi tĂ« gjitha node-t. Node-t janĂ« shumĂ« tĂ« fuqishme dhe Ă«shtĂ« e vĂ«shtirĂ« t'i mbingarkosh ato.
Por ne e ndĂ«rtuam arkitekturĂ«n tonĂ« duke u bazuar edhe nĂ« skenarĂ« tĂ« pamundur.Â
Një probabilitet i ulët nuk do të thotë se është e pamundur.
Mund ta imagjinojmë një situatë ku një ose disa përdorues do të gjeneronin një ngarkesë shumë të madhe. Të gjithë node-t e HyperPlane përfshihen në përpunimin e kësaj ngarkese dhe përdoruesit e tjerë potencialisht mund të ndiejnë një rënie të performancës. Kjo shkatërron konceptin e cloud-it, në të cilin tenantët nuk kanë mundësi të ndikojnë në njëri-tjetrin.
Si ta zgjidhim problemin e fqinjit të zhurmshëm? E para që na vjen në mendje është shardimi. 8 node-t tona ndahen logjikisht në 4 sharda me nga 2 node në secilin. Tani fqinji i zhurmshëm do të pengojë vetëm një të katërtën e të gjithë përdoruesve, por shumë.
Le tĂ« veprojmĂ« ndryshe. Ădo pĂ«rdorues tĂ« ketĂ« vetĂ«m 3 node.Â
Truku Ă«shtĂ« tĂ« caktosh node tĂ« ndryshme pĂ«rdoruesve tĂ« ndryshĂ«m rastĂ«sisht. NĂ« figurĂ«n mĂ« poshtĂ«, pĂ«rdoruesi me ngjyrĂ« blu prek node-t me njĂ« nga dy pĂ«rdoruesit e tjerĂ« â tĂ« gjelbĂ«rin dhe portokallin.
Me 8 node dhe 3 përdorues, probabiliteti i përputhjes së fqinjit të zhurshëm me një nga përdoruesit është 54%. Me këtë probabilitet, përdoruesi blu do të ndikojë në tenantët e tjerë. Në këtë rast, kjo do të ndodhë vetëm me një pjesë të ngarkesës së tij. Në shembullin tonë, ky ndikim do të jetë i dukshëm vetëm për një të tretën e të gjithë përdoruesve. Kjo është tashmë një rezultat i mirë.
Numri i përdoruesve që do të përputhen
Probabiliteti në përqindje
0
18%
1
54%
2
26%
3
2%
Le tĂ« afrojmĂ« situatĂ«n me reale â tĂ« marrim 100 node dhe 5 pĂ«rdorues nĂ« 5 node. NĂ« kĂ«tĂ« rast, asnjĂ« nga node-t nuk do tĂ« pĂ«rputhet me njĂ« probabilitet prej 77%.Â
Numri i përdoruesve që do të përputhen
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 shumĂ« tĂ« madh node-sh HyperPlane dhe pĂ«rdoruesish, ndikimi potencial i fqinjit tĂ« zhurmshĂ«m ndaj pĂ«rdoruesve tĂ« tjerĂ« Ă«shtĂ« minimal. Ky metod quhet shardim me pĂ«rzierje â shuffle sharding. Ai minimizon efektin negativ nga dalja e node-ve jashtĂ« funksionit.
Shumë shërbime janë ndërtuar mbi bazën e HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Mastër të rrjetit
Tani do flasim për përmasat e vetë rrjetit. Në tetor 2019, AWS ofron shërbimet e veta në 22 rajone, dhe janë të planifikuara edhe 9 të tjera.
- Ădo rajon pĂ«rmban disa zona aksesibiliteti â Availability Zone. NĂ« total, ato janĂ« 69 nĂ« mbarĂ« botĂ«n.
- Ădo AZ pĂ«rbĂ«het nga Qendrat e Trajtimit tĂ« TĂ« DhĂ«nave. NĂ« total, ato nuk janĂ« mĂ« shumĂ« se 8.
- Në Qendrën e Të Dhënave ndodhet një sasi enorme serverash, në disa deri 300,000.
Tani tĂ« gjitha kĂ«to tâi mesojmĂ«, tâi shumojmĂ« dhe tĂ« marrim njĂ« shifĂ«r mbresĂ«lĂ«nĂ«se qĂ« reflekton pĂ«rmasat e cloud-it Amazon..
Ndërmjet zonave të aksesibilitetit dhe Qendrave të Trajtimit të Të Dhënave janë vendosur shumë kanale optike. Në një nga rajonet tona më të mëdha, vetëm për lidhjen mes AZ-ve dhe qendrave të lidhjes me rajone të tjera (Transit Centers) janë vendosur 388 kanale. Në total, kjo jep 5000 Tbit..
Backbone AWS është ndërtuar posaçërisht për cloud-in dhe është optimizuar për të punuar me të. Ne e ndërtuam atë në kanale 100 GBit/s.Ne i kontrollojmë ato plotësisht, përveç rajoneve në Kinë. Trafiku nuk ndahet me ngarkesat e kompanive të tjera.
Sigurisht, nuk jemi provider-i i vetëm cloud me një rrjet private backbone. Një numër në rritje kompanish të mëdha po e ndjekin këtë rrugë. Kjo konfirmohet nga studiues të pavarur, për shembull, nga .
Në grafik, shihet se pjesa e providerëve të përmbajtjes dhe providerëve të cloud-it po rritet. Për shkak të këtij ndryshimi, pjesa e trafikëve të Internetit të providerëve backbone po zvogëlohet vazhdimisht.
Do tĂ« shpjegoj pse po ndodh kjo. MĂ« parĂ«, shumica e shĂ«rbimeve web ishin tĂ« aksesueshme dhe konsumohej drejtpĂ«rdrejt nga Interneti. Tani, gjithnjĂ« e mĂ« shumĂ« servera janĂ« tĂ« vendosur nĂ« cloud dhe janĂ« tĂ« aksesueshĂ«m pĂ«rmes CDN â Content Distribution Network.PĂ«r tĂ« aksesuar burimin, pĂ«rdoruesi hyn nĂ« Internet deri nĂ« PoP-in mĂ« tĂ« afĂ«rt CDN â Point of Presence.Shpesh herĂ«, kjo Ă«shtĂ« diku afĂ«r. MĂ« pas, ai del nga Interneti publik dhe pĂ«rmes njĂ« backbone private shkon pĂ«rtej Atlantikut, pĂ«r shembull, dhe arrin drejtpĂ«rdrejt nĂ« burim.
ĂshtĂ« interesante si do tĂ« ndryshojĂ« Interneti pas 10 vjetĂ«sh nĂ«se kjo tendencĂ« vazhdon?
Kanalet fizike.
Shkencëtarët ende nuk kanë gjetur një mënyrë për të rritur shpejtësinë e dritës në Univers, por kanë avancuar shumë në metodat e transmetimit të saj përmes fibrave optike. Aktualisht, ne përdorim kabllo me 6912 fibra. Kjo ndihmon në optimizimin e kostos së tyre të shtrimit.
NĂ« disa rajone na duhet tĂ« pĂ«rdorim kabllo speciale. PĂ«r shembull, nĂ« regionin e Sidnejit pĂ«rdorim kabllo me mbulesĂ« speciale kundĂ«r termitĂ«ve.Â
Askush qëndron, ndonjëherë kanalet tona dëmtohen. Në fotoja në të djathë janë kabllot optikë në një nga rajonet amerikane, të cilat u prishën nga ndërtuesit. Si rezultat i aksidentit humbën vetëm 13 paketa të dhënash, që është e habitshme. Përsëri - vetëm 13! Sistemi u kalua menjëherë në kanalet rezervë - shkalla funksionon.
Ne shikuam me shpejtĂ«si disa shĂ«rbime dhe teknologji tĂ« reja tĂ« Amazon Cloud. Shpresoj qĂ« tani keni njĂ« ide tĂ« paktĂ«n pĂ«r shkallĂ«n e detyrave qĂ« inxhinierĂ«t tanĂ« duhet tĂ« zgjidhin. Personalish, kjo mĂ« tĂ«rheq shumĂ«.Â
Kjo është pjesa finale e trilogjisë nga Vasiliy Pantyukhin në lidhje me arkitekturën e AWS. Në pjesën e parë përshkruhen optimizimi i serverëve dhe shkallëzimi i bazës së të dhënave, ndërsa në janë funksionet serverless dhe Firecracker.
Në Në nëntor, Vasiliy Pantyukhin do të ndajë detaje të reja për arkitekturën e Amazon. Ai do të flasë për arsyet e dështimeve dhe projektimin e sistemeve të shpërndara në Amazon. Deri më 24 tetor, akoma mund të biletën në një çmim të mirë dhe të paguani më vonë. Po ju presim në HighLoad++, ejani - do të bisedojmë!
Burimi: habr.com
