Ang sukat ng network ng Amazon Web Services ay 69 na zone sa buong mundo sa 22 rehiyon: USA, Europe, Asia, Africa at Australia. Ang bawat zone ay naglalaman ng hanggang 8 data center - Mga Data Processing Center. Ang bawat data center ay may libu-libo o daan-daang libong mga server. Ang network ay idinisenyo sa paraang ang lahat ng hindi malamang na mga sitwasyon sa pagkawala ay isinasaalang-alang. Halimbawa, ang lahat ng rehiyon ay nakahiwalay sa isa't isa, at ang mga accessibility zone ay pinaghihiwalay sa mga distansyang ilang kilometro. Kahit na putulin mo ang cable, lilipat ang system sa mga backup na channel, at ang pagkawala ng impormasyon ay aabot sa ilang packet ng data. Si Vasily Pantyukhin ay magsasalita tungkol sa kung ano ang iba pang mga prinsipyo na binuo ng network at kung paano ito nakabalangkas.
Vasily Pantyukhin nagsimula bilang isang administrator ng Unix sa mga kumpanyang .ru, nagtrabaho sa malalaking hardware ng Sun Microsystem sa loob ng 6 na taon, at nangaral ng isang data-centric na mundo sa loob ng 11 taon sa EMC. Ito ay natural na nagbago sa mga pribadong ulap, pagkatapos ay inilipat sa mga pampublikong ulap. Ngayon, bilang arkitekto ng Amazon Web Services, nagbibigay siya ng teknikal na payo upang makatulong na mabuhay at umunlad sa AWS cloud.
Sa nakaraang bahagi ng trilogy ng AWS, sinilip ni Vasily ang disenyo ng mga pisikal na server at pag-scale ng database. Nitro card, custom na KVM-based hypervisor, Amazon Aurora database - tungkol sa lahat ng ito sa materyal "" Basahin para sa konteksto o panoorin mga talumpati.
Ang bahaging ito ay tututuon sa pag-scale ng network, isa sa mga pinakakumplikadong system sa AWS. Ang ebolusyon mula sa isang patag na network hanggang sa isang Virtual Private Cloud at ang disenyo nito, mga panloob na serbisyo ng Blackfoot at HyperPlane, ang problema ng isang maingay na kapitbahay, at sa dulo - ang sukat ng network, gulugod at pisikal na mga cable. Tungkol sa lahat ng ito sa ilalim ng hiwa.
Disclaimer: lahat ng nasa ibaba ay personal na opinyon ni Vasily at maaaring hindi tumugma sa posisyon ng Amazon Web Services.
Pag-scale ng network
Ang AWS cloud ay inilunsad noong 2006. Ang kanyang network ay medyo primitive - na may isang patag na istraktura. Ang hanay ng mga pribadong address ay karaniwan sa lahat ng mga nangungupahan sa cloud. Kapag nagsimula ng bagong virtual machine, hindi sinasadyang nakatanggap ka ng available na IP address mula sa hanay na ito.
Ang diskarte na ito ay madaling ipatupad, ngunit sa panimula ay limitado ang paggamit ng cloud. Sa partikular, medyo mahirap bumuo ng mga hybrid na solusyon na pinagsama ang mga pribadong network sa lupa at sa AWS. Ang pinakakaraniwang problema ay ang magkakapatong na mga saklaw ng IP address.
Virtual Pribadong Cloud
Ang ulap pala ay in demand. Dumating ang oras upang isipin ang tungkol sa scalability at ang posibilidad ng paggamit nito ng sampu-sampung milyong mga nangungupahan. Ang patag na network ay naging isang malaking balakid. Samakatuwid, naisip namin kung paano ihiwalay ang mga user sa isa't isa sa antas ng network para makapag-iisa silang pumili ng mga saklaw ng IP.
Ano ang unang bagay na pumapasok sa isip mo kapag iniisip mo ang tungkol sa paghihiwalay ng network? tiyak Mga VLAN и VRF - Virtual Routing at Forwarding.
Sa kasamaang palad, hindi ito gumana. Ang VLAN ID ay 12 bits lamang, na nagbibigay lamang sa amin ng 4096 na nakahiwalay na mga segment. Kahit na ang pinakamalaking switch ay maaaring gumamit ng maximum na 1-2 thousand VRFs. Ang paggamit ng VRF at VLAN nang magkasama ay nagbibigay lamang sa amin ng ilang milyong subnet. Ito ay tiyak na hindi sapat para sa sampu-sampung milyong mga nangungupahan, bawat isa ay dapat na makagamit ng maraming subnet.
Hindi rin namin kayang bilhin ang kinakailangang bilang ng malalaking kahon, halimbawa, mula sa Cisco o Juniper. Mayroong dalawang dahilan: ito ay napakamahal, at hindi namin nais na maging sa awa ng kanilang mga patakaran sa pag-unlad at pag-patch.
Mayroon lamang isang konklusyon - gumawa ng iyong sariling solusyon.
Noong 2009, inihayag namin VPC - Virtual Pribadong Cloud. Natigil ang pangalan at ngayon ay ginagamit din ito ng maraming cloud provider.
Ang VPC ay isang virtual na network SDN (Software Defined Network). Nagpasya kaming huwag mag-imbento ng mga espesyal na protocol sa mga antas ng L2 at L3. Ang network ay tumatakbo sa karaniwang Ethernet at IP. Para sa paghahatid sa network, ang trapiko ng virtual machine ay naka-encapsulated sa sarili naming protocol wrapper. Isinasaad nito ang ID na pagmamay-ari ng VPC ng nangungupahan.
Parang simple lang. Gayunpaman, may ilang mga seryosong teknikal na hamon na kailangang malampasan. Halimbawa, kung saan at paano mag-imbak ng data sa pagmamapa ng mga virtual na MAC/IP address, VPC ID at kaukulang pisikal na MAC/IP. Sa sukat ng AWS, ito ay isang malaking talahanayan na dapat gumana nang may kaunting pagkaantala sa pag-access. Responsable para dito serbisyo sa pagmamapa, na kumakalat sa isang manipis na layer sa buong network.
Sa mga bagong henerasyong makina, ang encapsulation ay ginagawa ng mga Nitro card sa antas ng hardware. Sa mas lumang mga pagkakataon, ang encapsulation at decapsulation ay software-based.
Alamin natin kung paano ito gumagana sa mga pangkalahatang tuntunin. Magsimula tayo sa antas ng L2. Ipagpalagay natin na mayroon tayong virtual machine na may IP 10.0.0.2 sa isang pisikal na server na 192.168.0.3. Nagpapadala ito ng data sa virtual machine 10.0.0.3, na nabubuhay sa 192.168.1.4. Ang isang kahilingan sa ARP ay nabuo at ipinadala sa network na Nitro card. Para sa pagiging simple, ipinapalagay namin na ang parehong virtual machine ay nakatira sa parehong "asul" na VPC.
Pinapalitan ng mapa ang source address ng sarili nitong address at ipinapasa ang ARP frame sa serbisyo ng pagmamapa.
Ang serbisyo ng pagmamapa ay nagbabalik ng impormasyon na kinakailangan para sa paghahatid sa pisikal na network ng L2.
Pinapalitan ng Nitro card sa tugon ng ARP ang MAC sa pisikal na network ng isang address sa VPC.
Kapag naglilipat ng data, binabalot namin ang lohikal na MAC at IP sa isang VPC wrapper. Ipinapadala namin ang lahat ng ito sa pisikal na network gamit ang naaangkop na pinagmulan at patutunguhan na mga IP Nitro card.
Ang pisikal na makina kung saan nakalaan ang pakete ay nagsasagawa ng tseke. Ito ay kinakailangan upang maiwasan ang posibilidad ng address spoofing. Nagpapadala ang makina ng isang espesyal na kahilingan sa serbisyo ng pagmamapa at nagtanong: “Mula sa pisikal na makina 192.168.0.3 nakatanggap ako ng packet na nilayon para sa 10.0.0.3 sa asul na VPC. Legitimate ba siya?
Sinusuri ng serbisyo sa pagmamapa ang talahanayan ng paglalaan ng mapagkukunan nito at pinapayagan o tinatanggihan ang packet na dumaan. Sa lahat ng mga bagong pagkakataon, ang karagdagang pagpapatunay ay naka-embed sa mga Nitro card. Imposibleng i-bypass ito kahit sa teorya. Samakatuwid, hindi gagana ang panggagaya sa mga mapagkukunan sa isa pang VPC.
Susunod, ang data ay ipinadala sa virtual machine kung saan ito nilayon.
Gumagana rin ang serbisyo sa pagmamapa bilang isang lohikal na router para sa paglilipat ng data sa pagitan ng mga virtual machine sa iba't ibang mga subnet. Ang lahat ay simple sa konsepto, hindi ko na idedetalye.
Ito ay lumiliko na kapag nagpapadala ng bawat packet, ang mga server ay bumaling sa serbisyo ng pagmamapa. Paano haharapin ang mga hindi maiiwasang pagkaantala? Pag-cache, syempre.
Ang kagandahan ay hindi mo kailangang i-cache ang buong malaking mesa. Ang isang pisikal na server ay nagho-host ng mga virtual machine mula sa medyo maliit na bilang ng mga VPC. Kailangan mo lang i-cache ang impormasyon tungkol sa mga VPC na ito. Ang paglilipat ng data sa ibang mga VPC sa "default" na configuration ay hindi pa rin lehitimo. Kung ginagamit ang functionality gaya ng VPC-peering, ang impormasyon tungkol sa mga kaukulang VPC ay ilo-load din sa cache.
Inayos namin ang paglilipat ng data sa VPC.
Blackfoot
Ano ang dapat gawin sa mga kaso kung saan ang trapiko ay kailangang ipadala sa labas, halimbawa sa Internet o sa pamamagitan ng VPN sa lupa? Tumulong sa amin dito Blackfoot — Panloob na serbisyo ng AWS. Ito ay binuo ng aming koponan sa South Africa. Kaya naman pinangalanan ang serbisyo sa isang penguin na nakatira sa South Africa.
Ang Blackfoot ay nagde-decapsulate ng trapiko at ginagawa kung ano ang kinakailangan dito. Ang data ay ipinapadala sa Internet kung ano man.
Ang data ay decapsulated at muling binalot sa IPsec kapag gumagamit ng VPN.
Kapag gumagamit ng Direct Connect, tina-tag ang trapiko at ipinapadala sa naaangkop na VLAN.
HyperPlane
Ito ay isang panloob na serbisyo ng kontrol sa daloy. Maraming serbisyo sa network ang nangangailangan ng pagsubaybay estado ng daloy ng data. Halimbawa, kapag gumagamit ng NAT, dapat tiyakin ng kontrol ng daloy na ang bawat IP:destination port pair ay may natatanging papalabas na port. Sa kaso ng isang balancer NLB - Network Load Balancer, ang daloy ng data ay dapat palaging nakadirekta sa parehong target na virtual machine. Ang Security Groups ay isang stateful firewall. Sinusubaybayan nito ang papasok na trapiko at tahasang nagbubukas ng mga port para sa papalabas na daloy ng packet.
Sa AWS cloud, ang mga kinakailangan sa latency ng paghahatid ay napakataas. kaya lang HyperPlane kritikal sa pagganap ng buong network.
Ang Hyperplane ay binuo sa EC2 virtual machine. Walang magic dito, tuso lang. Ang lansihin ay ang mga ito ay mga virtual machine na may malaking RAM. Ang mga operasyon ay transactional at eksklusibong ginagawa sa memorya. Nagbibigay-daan ito sa iyo na makamit ang mga pagkaantala ng sampu-sampung microseconds lamang. Ang pagtatrabaho sa disk ay papatayin ang lahat ng pagiging produktibo.
Ang Hyperplane ay isang distributed system ng isang malaking bilang ng mga naturang EC2 machine. Ang bawat virtual machine ay may bandwidth na 5 GB/s. Sa buong network ng rehiyon, nagbibigay ito ng hindi kapani-paniwalang mga terabit ng bandwidth at nagbibigay-daan sa pagproseso milyon-milyong mga koneksyon sa bawat segundo.
Gumagana lang ang HyperPlane sa mga stream. Ang VPC packet encapsulation ay ganap na transparent para dito. Ang isang potensyal na kahinaan sa panloob na serbisyong ito ay mapipigilan pa rin ang paghihiwalay ng VPC na masira. Ang mga antas sa ibaba ay responsable para sa seguridad.
Maingay na kapitbahay
May problema pa maingay na kapitbahay - maingay na kapitbahay. Ipagpalagay natin na mayroon tayong 8 node. Pinoproseso ng mga node na ito ang mga daloy ng lahat ng user ng cloud. Mukhang maayos ang lahat at dapat na pantay-pantay ang pag-load sa lahat ng node. Napakalakas ng mga node at mahirap i-overload ang mga ito.
Ngunit binubuo namin ang aming arkitektura batay sa kahit na hindi malamang na mga sitwasyon.
Ang mababang posibilidad ay hindi nangangahulugang imposible.
Maaari naming isipin ang isang sitwasyon kung saan ang isa o higit pang mga user ay makakabuo ng masyadong maraming load. Lahat ng HyperPlane node ay kasangkot sa pagproseso ng load na ito at ang ibang mga user ay maaaring makaranas ng ilang uri ng performance hit. Sinisira nito ang konsepto ng cloud, kung saan walang kakayahan ang mga nangungupahan na impluwensyahan ang isa't isa.
Paano malutas ang problema ng isang maingay na kapitbahay? Ang unang bagay na pumapasok sa isip ay sharding. Ang aming 8 node ay lohikal na nahahati sa 4 na shards ng 2 node bawat isa. Ngayon ang isang maingay na kapitbahay ay makakaistorbo lamang sa isang-kapat ng lahat ng mga gumagamit, ngunit ito ay lubhang makaistorbo sa kanila.
Gawin natin ang mga bagay nang iba. Maglalaan lamang kami ng 3 node sa bawat user.
Ang lansihin ay ang random na magtalaga ng mga node sa iba't ibang user. Sa larawan sa ibaba, ang asul na user ay nag-intersect ng mga node sa isa sa dalawa pang user - berde at orange.
Sa 8 node at 3 user, ang posibilidad ng isang maingay na kapitbahay na interseksyon sa isa sa mga user ay 54%. Ito ay may posibilidad na ang isang asul na gumagamit ay makakaimpluwensya sa ibang mga nangungupahan. Kasabay nito, bahagi lamang ng pagkarga nito. Sa aming halimbawa, ang impluwensyang ito ay hindi bababa sa kahit papaano ay mapapansin hindi sa lahat, ngunit sa ikatlong bahagi lamang ng lahat ng mga gumagamit. Ito ay isang magandang resulta.
Bilang ng mga user na magsa-intersect
Probability sa porsyento
0
18%
1
54%
2
26%
3
2%
Ilapit natin ang sitwasyon sa realidad - kumuha tayo ng 100 node at 5 user sa 5 node. Sa kasong ito, wala sa mga node ang magsalubong na may posibilidad na 77%.
Bilang ng mga user na magsa-intersect
Probability sa porsyento
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Sa totoong sitwasyon, na may malaking bilang ng mga HyperPlane node at user, ang potensyal na epekto ng maingay na kapitbahay sa ibang mga user ay minimal. Ang pamamaraang ito ay tinatawag na paghahalo sharding - shuffle sharding. Pinaliit nito ang negatibong epekto ng pagkabigo ng node.
Maraming serbisyo ang binuo batay sa HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala ng network
Ngayon pag-usapan natin ang sukat ng network mismo. Para sa Oktubre 2019 nag-aalok ang AWS ng mga serbisyo nito sa 22 rehiyon, at 9 pa ang nakaplano.
- Ang bawat rehiyon ay naglalaman ng ilang Availability Zone. Mayroong 69 sa kanila sa buong mundo.
- Ang bawat AZ ay binubuo ng Data Processing Centers. Hindi hihigit sa 8 sila sa kabuuan.
- Naglalaman ang data center ng malaking bilang ng mga server, ang ilan ay may hanggang 300.
Ngayon, i-average natin ang lahat ng ito, paramihin at makakuha ng isang kahanga-hangang pigura na sumasalamin Amazon cloud scale.
Maraming optical link sa pagitan ng Availability Zone at ng data center. Sa isa sa aming pinakamalaking rehiyon, 388 na channel ang inilatag para lang sa komunikasyon ng AZ sa pagitan ng isa't isa at mga sentro ng komunikasyon sa ibang mga rehiyon (Transit Centers). Sa kabuuan, nakakabaliw ito 5000 Tbit.
Ang Backbone AWS ay partikular na binuo para sa at na-optimize para sa cloud. Binubuo namin ito sa mga channel 100 GB / s. Ganap naming kinokontrol ang mga ito, maliban sa mga rehiyon sa China. Ang trapiko ay hindi ibinabahagi sa mga load ng ibang mga kumpanya.
Siyempre, hindi lang kami ang cloud provider na may pribadong backbone network. Parami nang paraming malalaking kumpanya ang sumusunod sa landas na ito. Ito ay kinumpirma ng mga independiyenteng mananaliksik, halimbawa mula sa .
Ipinapakita ng graph na lumalaki ang bahagi ng mga content provider at cloud provider. Dahil dito, patuloy na bumababa ang bahagi ng trapiko sa Internet ng mga backbone provider.
Ipapaliwanag ko kung bakit ito nangyayari. Dati, karamihan sa mga serbisyo sa web ay naa-access at direktang ginagamit mula sa Internet. Sa ngayon, parami nang parami ang mga server na matatagpuan sa cloud at naa-access sa pamamagitan ng CDN - Network ng Pamamahagi ng Nilalaman. Upang ma-access ang isang mapagkukunan, ang gumagamit ay dumaan lamang sa Internet sa pinakamalapit na CDN PoP - Punto ng Presensya. Kadalasan ito ay nasa malapit na lugar. Pagkatapos ay umalis ito sa pampublikong Internet at lumipad sa isang pribadong gulugod sa buong Atlantic, halimbawa, at direktang napupunta sa mapagkukunan.
Nagtataka ako kung paano magbabago ang Internet sa loob ng 10 taon kung magpapatuloy ang trend na ito?
Mga pisikal na channel
Hindi pa naiisip ng mga siyentipiko kung paano papataasin ang bilis ng liwanag sa Uniberso, ngunit nakagawa sila ng malaking pag-unlad sa mga pamamaraan ng pagpapadala nito sa pamamagitan ng optical fiber. Kasalukuyan kaming gumagamit ng 6912 fiber cable. Nakakatulong ito upang makabuluhang ma-optimize ang gastos ng kanilang pag-install.
Sa ilang mga rehiyon kailangan naming gumamit ng mga espesyal na cable. Halimbawa, sa rehiyon ng Sydney ay gumagamit kami ng mga cable na may espesyal na patong laban sa mga anay.
Walang sinuman ang immune mula sa mga problema at kung minsan ang aming mga channel ay nasira. Ang larawan sa kanan ay nagpapakita ng mga optical cable sa isa sa mga rehiyon ng Amerika na pinunit ng mga construction worker. Bilang resulta ng aksidente, 13 data packet lamang ang nawala, na nakakagulat. Muli - 13 lang! Literal na lumipat ang system sa mga backup na channel - gumagana ang sukat.
Sumakay kami sa ilan sa mga serbisyo at teknolohiya ng cloud ng Amazon. Umaasa ako na mayroon kang hindi bababa sa ilang ideya ng laki ng mga gawain na kailangang lutasin ng aming mga inhinyero. Personally, I find this very exciting.
Ito ang huling bahagi ng trilogy mula kay Vasily Pantyukhin tungkol sa AWS device. SA inilalarawan ng mga bahagi ang pag-optimize ng server at pag-scale ng database, at sa — walang server na mga function at Firecracker.
Sa sa Nobyembre, magbabahagi si Vasily Pantyukhin ng mga bagong detalye ng Amazon device. Siya tungkol sa mga sanhi ng pagkabigo at ang disenyo ng mga distributed system sa Amazon. Pwede pa ang October 24 ticket sa magandang presyo, at magbayad mamaya. Hinihintay ka namin sa HighLoad++, halika at mag-chat tayo!
Pinagmulan: www.habr.com