A scala di a reta di Amazon Web Services hè 69 zoni in u mondu in 22 regioni: USA, Europa, Asia, Africa è Australia. Ogni zona cuntene finu à 8 data centers - Data Processing Centers. Ogni centru di dati hà millaie o centinaie di millaie di servitori. A rete hè cuncepita in modu chì tutti i scenarii di interrupzione improbabile sò presi in contu. Per esempiu, tutte e regioni sò isolate l'una di l'altru, è e zoni d'accessibilità sò separati nantu à distanze di parechji chilometri. Ancu s'è vo tagliate u cable, u sistema cambierà à i canali di salvezza, è a perdita di l'infurmazioni serà un pocu di pacchetti di dati. Vasily Pantyukhin parlerà di quale altri principii hè custruitu nantu à a reta è cumu hè strutturata.
Vasily Pantyukhin principiatu cum'è amministratore Unix in cumpagnie .ru, hà travagliatu nantu à un grande hardware Sun Microsystem per 6 anni, è pridicatu un mondu centratu in dati per 11 anni in EMC. Naturalmente hà evolutu in nuvuli privati, dopu si trasfirìu à quelli publichi. Avà, cum'è un architettu Amazon Web Services, furnisce cunsiglii tecnichi per aiutà à vive è à sviluppà in u nuvulu AWS.
In a parti precedente di a trilogia AWS, Vasily hà sfondatu in u disignu di i servitori fisichi è a scala di basa di dati. Carte Nitro, ipervisore basatu in KVM persunalizatu, basa di dati Amazon Aurora - circa tuttu questu in u materiale "" Leghjite per u cuntestu o fighjate discorsi.
Questa parte si focalizeghja nantu à a scala di rete, unu di i sistemi più cumplessi in AWS. L'evoluzione da una reta piatta à una Virtual Private Cloud è u so designu, servizii internu di Blackfoot è HyperPlane, u prublema di un vicinu rumore, è à a fine - a scala di a reta, spine è cavi fisichi. Circa tuttu questu sottu u cut.
Disclaimer: tuttu quì sottu hè l'opinione persunale di Vasily è ùn pò micca coincide cù a pusizione di Amazon Web Services.
Scala di rete
A nuvola AWS hè stata lanciata in 2006. A so reta era abbastanza primitiva - cù una struttura plana. A gamma di indirizzi privati era cumuna à tutti l'inquilini di nuvola. Quandu principia una nova macchina virtuale, avete ricevutu accidentalmente un indirizzu IP dispunibule da questa gamma.
Stu approcciu era faciule da implementà, ma fundamentalmente limitatu l'usu di u nuvulu. In particulare, era abbastanza difficiuli di sviluppà suluzioni hibridi chì combinavanu e rete private in terra è in AWS. U prublema più cumuna era a sovrapposizione di intervalli di indirizzu IP.
Cloud Privatu Virtuale
U nuvulu hè statu in dumanda. Hè ghjuntu u tempu di pensà à a scalabilità è a pussibilità di u so usu da decine di milioni di inquilini. A reta piatta hè diventata un ostaculu maiò. Dunque, avemu pensatu à cumu isolà l'utilizatori l'una di l'altru à u livellu di a rete in modu chì puderanu sceglie indipindente intervalli IP.
Chì ghjè a prima cosa chì vene in mente quandu pensate à l'isolamentu di a rete? Di sicuru VLAN и VRF - Routing è Trasferimentu Virtuale.
Sfurtunatamente, ùn hà micca travagliatu. L'ID VLAN hè solu 12 bits, chì ci dà solu 4096 segmenti isolati. Ancu i più grandi switch ponu utilizà un massimu di 1-2 mila VRF. Utilizà VRF è VLAN inseme ci dà solu uni pochi milioni di subnets. Di sicuru, questu ùn hè micca abbastanza per decine di milioni di inquilini, chì ognuna deve esse capace di utilizà parechje subnets.
Ùn pudemu ancu micca permette di cumprà u numeru necessariu di scatuli grossi, per esempiu, da Cisco o Juniper. Ci hè dui mutivi: hè pazzu caru, è ùn vulemu micca esse à a misericòrdia di e so pulitiche di sviluppu è di patching.
Ci hè solu una cunclusione - fate a vostra propria suluzione.
In u 2009 avemu annunziatu VPC - Cloud Privatu Virtuale. U nome s'hè appiccicatu è avà parechji fornituri di nuvola l'utilizanu ancu.
VPC hè una reta virtuale SDN (Rete Definita da u Software). Avemu decisu di ùn inventà protokolli spiciali à i livelli L2 è L3. A reta funziona nantu à Ethernet standard è IP. Per a trasmissione nantu à a reta, u trafficu di a macchina virtuale hè incapsulatu in u nostru propiu wrapper di protokollu. Indica l'ID chì appartene à u VPC di u tenant.
Sona simplice. Tuttavia, ci sò parechje sfide tecniche serii chì deve esse superatu. Per esempiu, induve è cumu per almacenà e dati nantu à a mappatura di l'indirizzi MAC / IP virtuali, l'ID VPC è u MAC / IP fisicu currispundente. À a scala AWS, questu hè un tavulu enormu chì deve travaglià cù ritardi d'accessu minimi. Rispunsevuli di questu serviziu di cartografia, chì si sparghje in una capa fina in tutta a reta.
In e macchine di nova generazione, l'incapsulazione hè realizata da carte Nitro à u livellu di hardware. In i casi più antichi, l'incapsulazione è a decapsulazione sò basati in software.
Scupritemu cumu si travaglia in generale. Cuminciamu cù u livellu L2. Assumimu chì avemu una macchina virtuale cù IP 10.0.0.2 in un servitore fisicu 192.168.0.3. Mandate dati à a macchina virtuale 10.0.0.3, chì vive nantu à 192.168.1.4. Una dumanda ARP hè generata è mandata à a reta di a carta Nitro. Per simplicità, assumemu chì e duie macchine virtuali vivenu in u stessu VPC "blu".
A mappa rimpiazza l'indirizzu fonte cù u so propiu è trasmette u quadru ARP à u serviziu di mapping.
U serviziu di cartografia torna l'infurmazioni necessarii per a trasmissione nantu à a reta fisica L2.
A carta Nitro in a risposta ARP rimpiazza u MAC in a reta fisica cù un indirizzu in u VPC.
Quandu si trasfirìu dati, accumpagnamu MAC logica è IP in un wrapper VPC. Trasmettemu tuttu questu nantu à a reta fisica utilizendu e carte IP Nitro d'origine è di destinazione adattate.
A macchina fisica à quale u pacchettu hè destinatu esegue u cuntrollu. Questu hè necessariu per prevene a pussibilità di spoofing di indirizzu. A macchina manda una dumanda speciale à u serviziu di cartografia è dumanda: "Da a macchina fisica 192.168.0.3 aghju ricevutu un pacchettu chì hè destinatu à 10.0.0.3 in u VPC blu. Hè legittimu ?
U serviziu di cartografia cuntrolla a so tabella di allocazione di risorse è permette o denega u pacchettu per passà. In tutti i casi novi, a validazione supplementaria hè incrustata in carte Nitro. Hè impussibile di aggirallu ancu in teoria. Dunque, spoofing à risorse in un altru VPC ùn funziona micca.
Dopu, i dati sò mandati à a macchina virtuale per quale hè destinatu.
U serviziu di mapping funziona ancu cum'è un router logicu per u trasferimentu di dati trà e macchine virtuali in diverse subnets. Tuttu hè cuncettualmente simplice, ùn andaraghju in dettagliu.
Ci hè chì quandu trasmettenu ogni pacchettu, i servitori turnanu à u serviziu di mapping. Cumu trattà cù ritardi inevitabbili? Caching, ben intesu.
A bellezza hè chì ùn avete micca bisognu di cache tutta a tavola enormi. Un servitore fisicu ospita macchine virtuali da un numeru relativamente chjucu di VPC. Solu bisognu di cache l'infurmazioni nantu à sti VPC. U trasferimentu di dati à altri VPC in a cunfigurazione "default" hè ancu micca legittimu. Se a funziunalità cum'è VPC-peering hè aduprata, allora l'infurmazioni nantu à i VPC currispondenti sò ancu caricate in a cache.
Avemu sorte u trasferimentu di dati à u VPC.
Blackfoot
Cosa da fà in i casi induve u trafficu deve esse trasmessu fora, per esempiu à Internet o via VPN à a terra? Ci aiuta quì Blackfoot - Serviziu internu AWS. Hè sviluppatu da a nostra squadra sudafricana. Hè per quessa chì u serviziu hè chjamatu dopu à un pinguinu chì vive in Sudafrica.
Blackfoot decapsula u trafficu è face ciò chì hè necessariu cun ellu. I dati sò mandati à Internet cum'è.
I dati sò decapsulated è riavucati in IPsec quandu si usa una VPN.
Quandu si usa Direct Connect, u trafficu hè marcatu è mandatu à a VLAN appropritata.
HyperPlane
Questu hè un serviziu di cuntrollu di flussu internu. Parechji servizii di rete necessitanu monitoraghju stati di flussu di dati. Per esempiu, quandu si usa NAT, u cuntrollu di u flussu deve assicurà chì ogni paru IP: portu di destinazione hà un portu in uscita unicu. In u casu di un balancer NLB - Equilibratore di carica di rete, u flussu di dati deve esse sempre diretta à a stessa macchina virtuale di destinazione. Security Groups hè un firewall stateful. Monitora u trafficu in entrata è implicitamente apre i porti per u flussu di pacchetti in uscita.
In u cloud AWS, i requisiti di latenza di trasmissione sò estremamente elevati. Hè perchè HyperPlane criticu à u funziunamentu di tutta a reta.
Hyperplane hè custruitu nantu à e macchine virtuali EC2. Ùn ci hè micca magia quì, solu astuzia. U truccu hè chì queste sò macchine virtuali cù RAM grande. L'operazioni sò transazzione è eseguite solu in memoria. Questu permette di ottene ritardi di solu decine di microsecondi. U travagliu cù u discu uccideria tutta a produtividade.
Hyperplane hè un sistema distribuitu di un gran numaru di tali macchine EC2. Ogni macchina virtuale hà una larghezza di banda di 5 GB/s. In tutta a reta regiunale, questu furnisce incredibili terabits di larghezza di banda è permette a trasfurmazioni milioni di cunnessione per seconda.
HyperPlane funziona solu cù flussi. L'incapsulazione di pacchetti VPC hè cumplettamente trasparente per questu. Una vulnerabilità potenziale in stu serviziu internu impedisce ancu l'isolamentu VPC da esse rottu. I livelli sottu sò rispunsevuli di a sicurità.
Un vicinu rumoroso
Ci hè sempre un prublema vicinu rumoroso - vicinu rumoroso. Assumimu chì avemu 8 nodi. Questi nodi processanu i flussi di tutti l'utilizatori di nuvola. Tuttu pare esse bè è a carica deve esse distribuita uniformemente in tutti i nodi. I nodi sò assai putenti è hè difficiule di sopracarcà.
Ma custruemu a nostra architettura basatu annantu à scenarii ancu improbabili.
Probabilità bassa ùn significa micca impussibile.
Pudemu imaginà una situazione in quale unu o più utilizatori generà troppu carica. Tutti i nodi di HyperPlane sò implicati in u processu di sta carica è altri utilizatori puderanu sperimentà un certu tipu di rendiment. Questu rompe u cuncettu di u nuvulu, in quale l'inquilanti ùn anu micca capacità di influenzà l'altri.
Cumu risolve u prublema di un vicinu rumore? A prima cosa chì vene in mente hè sharding. I nostri 8 nodi sò logicamente divisi in 4 frammenti di 2 nodi ognunu. Avà un vicinu rumore disturbà solu un quartu di tutti l'utilizatori, ma li disturberà assai.
Facemu e cose in modu diversu. Assegnaremu solu 3 nodi à ogni utilizatore.
U truccu hè di assignà aleatoriamente nodi à diversi utilizatori. In a stampa sottu, l'utilizatore blu intersecta i nodi cù unu di l'altri dui utilizatori - verde è aranciu.
Cù 8 nodi è 3 utilizatori, a probabilità di un vicinu rumore intersece cù unu di l'utilizatori hè 54%. Hè cù questa probabilità chì un utilizatore blu influenzerà altri inquilini. À u listessu tempu, solu una parte di a so carica. In u nostru esempiu, sta influenza serà almenu in qualchì manera notevuli micca à tutti, ma solu à un terzu di tutti l'utilizatori. Questu hè digià un bonu risultatu.
Numaru di utilizatori chì si interseceranu
Probabilità in percentuale
0
18%
1
54%
2
26%
3
2%
Avvicinemu a situazione più vicinu à a realità - pigliamu 100 nodi è 5 utilizatori nantu à 5 nodi. In questu casu, nimu di i nodi s'intersece cù una probabilità di 77%.
Numaru di utilizatori chì si interseceranu
Probabilità in percentuale
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In una situazione reale, cù un gran numaru di nodi HyperPlane è utilizatori, l'impattu potenziale di un vicinu rumore à l'altri utilizatori hè minimu. Stu metudu hè chjamatu mischjendu sharding - shuffle sharding. Minimizza l'effettu negativu di fallimentu di node.
Parechji servizii sò custruiti nantu à a basa di HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Scala di rete
Avà parlemu di a scala di a reta stessa. Per ottobre 2019 AWS offre i so servizii in 22 regioni, è 9 altri sò previsti.
- Ogni regione cuntene parechje Zone di Disponibilità. Ci sò 69 di elli in u mondu.
- Ogni AZ hè custituitu da Centri di Trattamentu di Dati. Ùn ci sò micca più di 8 in tuttu.
- U centru di dati ospita un gran numaru di servitori, alcuni cù finu à 300 000.
Avà facemu una media di tuttu questu, multiplicate è uttene una figura impressiunanti chì riflette Scala di nuvola Amazon.
Ci hè parechje ligami ottichi trà e Zone di Disponibilità è u centru di dati. In una di e nostre regioni più grande, i canali 388 sò stati disposti solu per a cumunicazione AZ trà l'altri è i centri di cumunicazione cù altre regioni (Centri di transitu). In tuttu, questu dà pazzi 5000 Tbit.
Backbone AWS hè custruitu specificamente è ottimizzatu per u cloud. Custruemu nantu à i canali 100 GB / s. Li cuntrullemu cumpletamente, cù l'eccezzioni di e regioni in Cina. U trafficu ùn hè micca spartutu cù i carichi di altre cumpagnie.
Di sicuru, ùn simu micca l'unicu fornitore di nuvola cù una rete di backbone privata. Sempre più grande cumpagnie seguitanu sta strada. Questu hè cunfirmatu da circadori indipendenti, per esempiu da .
U graficu mostra chì a parte di i fornituri di cuntenutu è i fornituri di nuvola hè in crescita. Per via di questu, a parte di u trafficu Internet di i fornituri di backbone hè in constantemente diminuite.
Spiegheraghju perchè questu succede. Prima, a maiò parte di i servizii web eranu accessibili è cunsumati direttamente da Internet. Oghje, più è più servitori sò situati in u nuvulu è sò accessibili via CDN - Rete di distribuzione di cuntenutu. Per accede à una risorsa, l'utilizatore passa per Internet solu à u CDN PoP più vicinu - Puntu di Presenza. A maiò spessu si trova in un locu vicinu. Allora abbanduneghja l'Internet publicu è vola per una spina privata à traversu l'Atlanticu, per esempiu, è vene direttamente à a risorsa.
Mi dumandu cumu l'Internet cambierà in 10 anni se sta tendenza cuntinueghja?
Canali fisichi
I scientisti ùn anu micca capitu cumu per aumentà a velocità di a luce in l'Universu, ma anu fattu un grande prugressu in i metudi di trasmette per via di a fibra ottica. Attualmente usemu cavi di fibra 6912. Questu aiuta à ottimisà significativamente u costu di a so stallazione.
In certi rigioni avemu aduprà cables spiciali. Per esempiu, in a regione di Sydney usemu cables cun un revestimentu speciale contru termites.
Nimu hè immune da i prublemi è qualchì volta i nostri canali sò dannati. A foto à a diritta mostra i cavi ottici in una di e regioni americane chì sò stati strappati da i travagliadori di a custruzzione. In u risultatu di l'accidentu, solu 13 pacchetti di dati sò stati persi, chì hè surprisante. Una volta - solu 13! U sistema hà literalmente cambiatu istantaneamente à i canali di salvezza - a scala funziona.
Avemu galoppatu attraversu alcuni di i servizii di nuvola è tecnulugia di Amazon. Spergu chì avete almenu una idea di a scala di i travaglii chì i nostri ingegneri anu da risolve. In modu persunale, mi pare questu assai eccitante.
Questa hè a parte finale di a trilogia di Vasily Pantyukhin nantu à u dispusitivu AWS. IN parte descrizanu l'ottimisazione di u servitore è a scala di basa di dati, è in - funzioni serverless è Firecracker.
nantu in nuvembre Vasily Pantyukhin sparte novi ditagli di u dispusitivu Amazon. Ellu circa i causi di fallimenti è u disignu di sistemi distribuiti in Amazon. U 24 d'ottobre hè sempre pussibule bigliettu à un bonu prezzu, è pagà dopu. Vi aspittemu à HighLoad++, venite à chattemu !
Source: www.habr.com