Shkalla e rrjetit Amazon Web Services përfshin 69 zona në të gjithë botën në 22 rajone: SHBA, Europë, Azi, Afrikë dhe Australi. Në secilën zonë ndodhen deri në 8 Qendrat e të Dhënave (QTD). Në çdo QTD ka mijëra ose qindra mijëra serverë. Rrjeti është ndërtuar në një mënyrë që llogarit të gjitha skenarët e pamundshëm të ndërprerjeve. Për shembull, të gjitha rajonet janë të izoluar nga njëra-tjetra, dhe zonat e disponueshmërisë janë të shpërndara në disa kilometra distancë. Edhe nëse pritet një kabllo, sistemi do të kalojë në kanalet rezervë, dhe humbjet e informacionit do të jenë vetëm disa paketa të dhënash. Për parimet e tjera mbi të cilat është ndërtuar rrjeti dhe si funksionon, do të flasë Vasiliy Pantyukhin.
Vasili Pantiukhin fillova si admin Unix në kompanitë .ru, kalova 6 vjet me pajisje të mëdha Sun Microsystem, dhe 11 vjet predikova qendrim të dhënash në botën EMC. Në mënyrë natyrale evoluova në cloud privat, më pas kalova në publik. Tani, si arkitekt i Amazon Web Services, ofroj këshilla teknike për të ndihmuar që të jetojnë dhe zhvillohen në cloud-in AWS.
NĂ« pjesĂ«n e mĂ«parshme tĂ« trilogjisĂ« mbi infrastrukturĂ«n AWS, Vasili u thellua nĂ« ndĂ«rtimin 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 â tĂ« gjitha kĂ«to nĂ« materialin "". Lexoni pĂ«r t'u zhytur nĂ« kontekst, ose shikoni prezantimet.
NĂ« kĂ«tĂ« pjesĂ« do tĂ« flasim pĂ«r shkallĂ«zimin e rrjetit â njĂ« nga sistemet mĂ« komplekse nĂ« AWS. Evolucioni nga njĂ« rrjet 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 â pĂ«rmasat e rrjetit, backbone dhe kabllot fizike. TĂ« gjitha kĂ«to mĂ« poshtĂ«.
PĂ«rjashtim: gjithçka qĂ« ndodhet mĂ« poshtĂ« â Ă«shtĂ« opinioni personal i Vasilit dhe nuk mund tĂ« pĂ«rputhet me pozitat e Amazon Web Services.
Zgjerimi i rrjetit
Rekulli i AWS u lançua nĂ« vitin 2006. Rrjeti i tij ishte mjaft primitiv â me njĂ« strukturĂ« tĂ« sheshtĂ«. Intervali i adresave private ishte i pĂ«rbashkĂ«t pĂ«r tĂ« gjithĂ« tenantĂ«t e rekuptit. Kur aktivizonit njĂ« makinĂ« virtuale tĂ« re, rastĂ«sisht merrnit njĂ« adresĂ« IP tĂ« Disponueshme nga ky interval.
Ky lloj qasjeje ishte e thjeshtë për t'u zbatuar, por kufizonte thelbësisht përdorimin e cloud-it. Ilaçet për të zhvilluar zgjidhje hibride, ku bashkohen rrjetet private në tokë dhe në AWS, ishin të mjaftueshme për t'u bërë sfiduese. Problemi më i zakonshëm ishte përputhja e gamave të adresave IP.
Virtual Private Cloud
Cloud-i doli të ishte shumë i kërkuar. Ka ardhur koha për të menduar mbi shkallëzueshmërinë dhe mundësinë e përdorimit të tij nga dhjetëra miliona tenantë. Rrjeti i sheshtë u bë pengesa kryesore. Prandaj, ne menduam se si të izolojmë përdoruesit nga njëri-tjetri në nivelin e rrjetit, në mënyrë që ata të mund të zgjedhin vetë gamat e IP-ve.
ĂfarĂ« i vjen nĂ« mendje sĂ« pari kur mendoni pĂ«r izolimin e rrjetit? Sigurisht VLAN dhe VRF â Virtual Routing and Forwarding.
Fatkeq, kjo nuk funksionoi. VLAN ID është vetëm 12 bit, që na jep vetëm 4096 segmente të izoluar. Edhe në switch-et më të mëdha, maksimumi i VRF-ve që mund të përdoren është 1-2 mijë. Pjesëtimi i VRF-ëve dhe VLAN-ve na jep vetëm disa milionë nënrrjeta. Kjo sigurisht që nuk është e mjaftueshme për dhjetra miliona qiramarrës, secili prej të cilëve duhet të ketë mundësinë të përdorë disa nënrrjeta.
Gjithashtu, ne thjesht nuk mund ta lejojmë veten të blejmë numrin e kërkuar të kutive të mëdha, p.sh., nga Cisco ose Juniper. Ka dy arsye: është shumë e shtrenjtë dhe ne nuk duam të varfërohemi nga politika e tyre e zhvillimit dhe patch-ing-ut.
PĂ«rfundimi Ă«shtĂ« njĂ« â tĂ« gatuajmĂ« zgjidhjen tonĂ«.
NĂ« vitin 2009, ne e prezantuam VPC â Virtual Private Cloud. Emri u bĂ« i njohur dhe tani shumĂ« ofrues tĂ« shĂ«rbimeve nĂ« cloud e pĂ«rdorin atĂ« gjithashtu.
VPC â Ă«shtĂ« njĂ« rrjet virtual SDN (Rrjeti i Definuar nga Softueri). Ne vendosĂ«m tĂ« mos shpiknim protokolle tĂ« veçanta nĂ« nivelet L2 dhe L3. Rrjeti funksionon nĂ« Ethernet dhe IP standarde. PĂ«r tĂ« transmetuar trafikun nĂ« rrjet, trafiku i makinave virtuale mblidhet nĂ« njĂ« mbĂ«shtjellĂ«s tĂ« protokollit tonĂ« tĂ« vet. Aty specifikohet ID qĂ« i pĂ«rket qiramarrĂ«sit tĂ« VPC.
Duket e thjeshtë. Megjithatë, nevojitet të zgjidhen disa probleme teknike të rëndësishme. Për shembull, ku dhe si të ruhet informacioni mbi mapimin e adresave virtuale MAC/IP, ID e VPC dhe MAC/IP fizike përkatëse. Në përmasa AWS, kjo është një tabelë e madhe që duhet të punojë me vonesa minimale gjatë aksesimit. Këtë e menaxhon shërbimi i mapimit, i cili është i shpërndarë në mënyrë të hollë në të gjithë rrjetin.
NĂ« makinat e brezit tĂ« ri, inkapsulimi kryhet nga kartat Nitro nĂ« nivelin e harduerit. NĂ« instancat e vjetra, inkapsulimi dhe dekapsulimi janĂ« programore.Â
Le të kujtojmë se si funksionon kjo në terma të përgjithshëm. Le të fillojmë me nivelin L2. Le të supozojmë se kemi një virtualizim me IP 10.0.0.2 në serverin fizik 192.168.0.3. Ajo dërgon të dhëna te një makinë virtuale 10.0.0.3, e cila ndodhet në 192.168.1.4. Krijohet një kërkesë ARP, e cila shkon në kartën e rrjetit Nitro. Për thjeshtësi, le të mendojmë se të dy virtualkat jetojnë në të njëjtin VPC 'blu'.
Karta zëvendëson adresën e burimit me të vetën dhe dërgon kornizën ARP te shërbimi i mapimit.
Shërbimi i mapimit kthen informacionin e nevojshëm për transmetim në rrjetin fizik L2.
Kartela Nitro në përgjigjen ARP zëvendëson MAC-in në rrjetin fizik me adresën në VPC.
Kur dërgojmë të dhëna, ne e mbështjellim MAC-in dhe IP-at logjikë në paketat VPC. Të gjitha këto i kalojmë përmes rrjetit fizik me ndihmën e kartelave Nitro përkatëse të burimit dhe destinacionit.
MakinĂ« fizike, e cila Ă«shtĂ« e destinuar pĂ«r paketĂ«n, bĂ«n verifikimin. Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« parandaluar ndĂ«rrimin e adresave. Makina dĂ«rgon njĂ« kĂ«rkesĂ« tĂ« veçantĂ« nĂ« shĂ«rbimin e hartimit dhe pyet: 'Nga makina fizike 192.168.0.3 mora njĂ« paketĂ«, e cila Ă«shtĂ« e destinuar pĂ«r 10.0.0.3 nĂ« VPC-nĂ« 'blu'. A Ă«shtĂ« legjitime?'Â
Shërbimi i hartimit krahason 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ë inkorporuar në kartelat Nitro. Nuk është e mundur të kalohesh as teoriquement. Prandaj, spoofing-u në burime në një VPC tjetër nuk do të funksionojë.
MĂ« pas, tĂ« dhĂ«nat dĂ«rgohen nĂ« makinat virtuale pĂ«r tĂ« cilat janĂ« tĂ« destinuara.Â
Shërbimi i hartimit funksionon gjithashtu si një ruter logjik për kalimin e të dhënave midis makinave virtuale në nënrrjeta të ndryshme. Aty gjithçka është konceptualisht e thjeshtë, nuk do të hyj në detaje.
Praha, që gjatë dërgimit të secilit paketë, serverat i qasen shërbimit të mapimit. Si të përballojmë vonesat e pashmangshme? Me ndihmën e keqershimit, sigurisht.
E gjithĂ« bukuria Ă«shtĂ« se nuk Ă«shtĂ« e nevojshme tĂ« keqershet e gjithĂ« tabela e madhe. NĂ« serverin fizik jetojnĂ« makina virtuale nga njĂ« numĂ«r relativisht i vogĂ«l i VPC-ve. Duhet tĂ« keqershetohet informacioni vetĂ«m rreth kĂ«tyre VPC-ve. Transferimi i tĂ« dhĂ«nave nĂ« VPC tĂ« tjera nĂ« konfigurimin 'default' vazhdon tĂ« mos jetĂ« legjitim. NĂ«se pĂ«rdoret njĂ« funksionalitet si VPC-peering, atĂ«herĂ« nĂ« keqersh Ă«shtĂ« ngarkuar nĂ« mĂ«nyrĂ« shtesĂ« informacioni mbi VPC-tĂ« pĂ«rkatĂ«se.Â
E kemi sqaruar çështjen e transferimit të të dhënave në VPC.
Blackfoot
Si tĂ« veprojmĂ« nĂ« rastet kur trafiku duhet tĂ« transferohet 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. Prandaj, shĂ«rbimi quhet nĂ« nder tĂ« penguinĂ«s qĂ« jeton nĂ« AfrikĂ«n e Jugut.
Blackfoot dekapsulon trafikun dhe bën me të atë që nevojitet. Të dhënat dërgohen në Internet ashtu siç janë.
Të dhënat dekapsulohen dhe përsëri rrethohen në një mbështjellës IPsec kur përdoret VPN.
Kur përdoret Direct Connect, trafiku etiketizohet dhe dërgohet në VLAN-in përkatës.
HyperPlane
Ky Ă«shtĂ« njĂ« shĂ«rbim i brendshĂ«m pĂ«r kontrollin e rrjedhĂ«s. ShumĂ« shĂ«rbime rrjetesh kĂ«rkojnĂ« kontrollin e gjendjes sĂ« rrjedhĂ«s sĂ« tĂ« dhĂ«nave. PĂ«r shembull, kur pĂ«rdoret NAT, kontrolli i rrjedhĂ«s duhet tĂ« sigurojĂ« qĂ« çdo çift "IP: porta e destinacionit" t'i pĂ«rgjigjet njĂ« porte dalĂ«se unike. NĂ« rastin e balancuesit NLB â Network Load Balancer, rrjedha e tĂ« dhĂ«nave gjithmonĂ« duhet tĂ« drejtohet nĂ« tĂ« njĂ«jtĂ«n makinĂ« virtuale. Security Groups janĂ« njĂ« firewall me ruajtje tĂ« gjendjes. Ai monitoron trafikun e ardhshĂ«m dhe hap portet pĂ«r rrjedhĂ«n e paketave dalĂ«se nĂ« mĂ«nyrĂ« tĂ« paqĂ«llimshme.
Në re AWS, kërkesat për vonesa transmetimi janë jashtëzakonisht të larta. Prandaj HyperPlane është kritik për funksionimin e gjithë rrjetit.
Hyperplane Ă«shtĂ« ndĂ«rtuar mbi makina virtuale EC2. KĂ«tu nuk ka magji, vetĂ«m truk. Truku Ă«shtĂ« se kĂ«to janĂ« makina virtuale me RAM tĂ« madh. Operacionet janĂ« transaksionale dhe kryhen ekskluzivisht nĂ« memorie. Kjo lejon arritjen e vonesave prej disa mikrosekondash. Puna me disk do tĂ« shkatĂ«rronte tĂ« gjithĂ« performancĂ«n.Â
Hyperplane Ă«shtĂ« njĂ« sistem i shpĂ«rndarĂ« i pĂ«rbĂ«rĂ« nga njĂ« numĂ«r tĂ« madh makinash EC2. Ădo virtuale ka njĂ« kapacitet kalimi prej 5 GB/s. NĂ« shkallĂ« tĂ« gjithĂ« rrjetit rajonal, kjo rezulton nĂ« terabita tĂ« çmendura kapaciteti kalimi dhe lejon pĂ«rpunimin miliona lidhjesh nĂ« sekondĂ«.
HyperPlane punon vetëm me rrjedha. Inkapsulimi i paketave VPC është krejtësisht i qartë për të. Një cenueshmëri potenciale në këtë shërbim të brendshëm gjithsesi nuk do të lejojë që të thyhet izolimi i VPC. Për sigurinë përgjigjen nivelet më të ulta.
Fqinj i zhurmshëm
Ka edhe njĂ« problem me fqinjĂ«t e zhurmshĂ«m â fqinjĂ«t e zhurmshĂ«m. Supozoni se kemi 8 node. KĂ«to node pĂ«rpunojnĂ« rrjedhat 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Ă« nĂ« tĂ« gjitha node-t. Node-t janĂ« shumĂ« tĂ« fuqishme dhe Ă«shtĂ« e vĂ«shtirĂ« t'i mbingarkosh ato.
Por ne po ndĂ«rtoshim arkitekturĂ«n tonĂ« duke u bazuar edhe nĂ« skenarĂ«t mĂ« tĂ« papritur.Â
Probabiliteti i ulët nuk do të thotë pamundësi.
Mund të kemi parasysh një situatë në të cilën një ose disa përdorues do të krijonin një ngarkesë shumë të madhe. Në përpunimin e kësaj ngarkese janë të involvuar të gjitha nodet HyperPlane dhe përdoruesit e tjerë potencialisht mund të ndiejnë ndonjë ulje 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 zhurmshëm? E para që më vjen në mendje është sharding. Nodat tona 8 ndahen logjikisht në 4 sharda me nga 2 node në secilin. Tani fqinj zhurmshëm do të pengojë vetëm një katër të gjithë përdoruesve, por shumë fort.
Le ta bĂ«jmĂ« ndryshe. Do t'i ndajmĂ« çdo pĂ«rdoruesi vetĂ«m nga 3 nodet.Â
Truku Ă«shtĂ« qĂ« t'i caktojmĂ« nodet pĂ«rdoruesve tĂ« ndryshĂ«m nĂ« mĂ«nyrĂ« rastĂ«sore. NĂ« figurĂ«n mĂ« poshtĂ«, pĂ«rdoruesi blu kalon nĂ«pĂ«r nodet me njĂ«rin nga dy pĂ«rdoruesit e tjerĂ« â tĂ« gjelbĂ«rt dhe portokalli.
Me 8 nodave dhe 3 përdorues, probabiliteti i ndërprerjes së një fqinjë të zhurmshëm me një nga përdoruesit është 54%. Me këtë probabilitet, përdoruesi blu do të ndikojë tek të tjerët. Ndikimi do të jetë 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 gjithë përdoruesve. Ky është një rezultat i mirë.
Numri i përdoruesve që do të ndërpriten
Probabiliteti në përqindje
0
18%
1
54%
2
26%
3
2%
TĂ« afrojmĂ« situatĂ«n me realitetin â tĂ« marrim 100 nod dhe 5 pĂ«rdorues nĂ« 5 nod. NĂ« kĂ«tĂ« rast, asnjĂ« nga nodet nuk do tĂ« ndĂ«rpritet me njĂ« probabilitet prej 77%.Â
Numri i përdoruesve që do të ndërpriten
Probabiliteti në përqindje
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
NĂ« situatĂ«n reale, me njĂ« numĂ«r tĂ« madh HyperPlane nodesh dhe pĂ«rdoruesish, ndikimi potencial i njĂ« fqinjĂ« tĂ« zhurmshĂ«m tek pĂ«rdoruesit e tjerĂ« Ă«shtĂ« minimal. Ky metod quhet shardim me grumbullim â shuffle sharding. Ai minimizon efektin negativ nga dalja jashtĂ« funksionit e nodave.
Më shumë shërbime janë ndërtuar mbi bazën e HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala e rrjetit
Tani, le të flasim për përmasat e vetë rrjetit. Në tetor 2019, AWS ofron shërbimet e tij në 22 rajone, dhe janë planifikuar edhe 9.
- Secili rajon pĂ«rmban disa zona disponueshmĂ«rie â Zona e DisponueshmĂ«risĂ«. NĂ« total, ka 69 tĂ« tillĂ« nĂ« tĂ« gjithĂ« botĂ«n.
- Ădo AZ pĂ«rbĂ«het nga Qendrat e TĂ« DhĂ«nave. NĂ« total, nuk ka mĂ« shumĂ« se 8.
- Në Qendrën e të Dhënave ndodhen një numër i madh serverash, në disa deri në 300,000.
Tani le të gjitha këto t'i mesojmë, ti shumëzojmë dhe të marrim një numër të dukshëm që pasqyron përmasat e cloud-it Amazon.
Midis zonave të disponueshmërisë dhe Qendrave të Të Dhënave janë vendosur shumë kanale optike. Në një nga rajonet tona më të mëdha, vetëm për lidhjen e AZ-ve me njëra-tjetrën dhe me qendrat e komunikimit me rajone të tjera (Qendrat e Transitit) janë vendosur 388 kana. Në total, kjo jep.
5000 Tb Backbone AWS është ndërtuar posaçërisht për cloud dhe është optimizuar për të punuar me të. Ne e ndërtojmë atë në kanalet100 Gb/s.
Sigurisht, ne nuk jemi ofruesi i vetëm i cloud me një rrjet private backbone. Po bëhet gjithnjë e më shumë kompani të mëdha që ndjekin këtë rrugë. Kjo konfirmohet nga hulumtues të pavarur, siç është .
Grafiku tregon se pjesa e ofruesve të përmbajtjes dhe ofruesve të cloud po rritet. Për këtë arsye, pjesa e trafikut Internet të ofruesve backbone po zvogëlohet vazhdimisht.
Do t'ju shpjegoj pse ndodh kjo. Disa kohĂ« mĂ« parĂ«, shumica e shĂ«rbimeve web ishin tĂ« aksesueshme dhe konsumoheshin direkt nga Interneti. Tani, gjithnjĂ« e mĂ« shumĂ« servera janĂ« tĂ« vendosur nĂ« re dhe janĂ« tĂ« aksesueshĂ«m pĂ«rmes CDN â Content Distribution Network. PĂ«r tĂ« aksesuar burimin, pĂ«rdoruesi kalon pĂ«rmes Internetit vetĂ«m deri nĂ« CDN PoP mĂ« tĂ« afĂ«rt â Point of Presence. Shpesh kjo ndodh diku afĂ«r. Pastaj ai largohet nga Interneti publik dhe udhĂ«ton pĂ«rmes njĂ« backbone privat pĂ«rmes Atlantikut, pĂ«r shembull, dhe arrin direkt nĂ« burim.
ĂshtĂ« interesante se 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 transmisionit të saj përmes fiber optik. Tani ne përdorim kabllo me 6912 fibra. Kjo ndihmon në optimizimin e kostos së instalimit të tyre.
NĂ« disa rajone na duhet tĂ« pĂ«rdorim kabllo speciale. PĂ«r shembull, nĂ« rajonin e Sidneit ne pĂ«rdorim kabllo me njĂ« mbĂ«shtjellje speciale kundĂ«r termiteve.Â
Askush nuk është i sigurt nga probleme, dhe ndonjëherë kanalet tona dëmtohen. Në fotografinë përkrah janë kabllot optikë në një nga rajonet Amerikane, që u këputë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ë - scale e lidhur.
Ne bĂ«jmĂ« njĂ« pĂ«rshkrim tĂ« shpejtĂ« tĂ« disa shĂ«rbimeve dhe teknologjive tĂ« cloud-it Amazon. Shpresoj qĂ« ju keni fituar tĂ« paktĂ«n njĂ« pĂ«rshtypje mbi shkallĂ«n e detyrave qĂ« duhet tĂ« zgjidhen nga inxhinierĂ«t tanĂ«. Personalish, kjo Ă«shtĂ« shumĂ« interesante pĂ«r mua.Â
Ky është pjesa përfundimtare e trilogjisë nga Vasily Pantyukhin mbi ndërtimin e AWS. Në kërkesat për optimizimin e serverëve dhe shkallëzimin e databazës, dhe në - funksionet serverless dhe Firecracker.
Në Në nëntor, Vasily Pantyukhin do të ndajë detaje të reja mbi ndërtimin 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, mund të biletin në një çmim të mirë, dhe ta paguani më vonë. Ju presim në HighLoad++, ejani - do të bisedojmë!
Burimi: habr.com
