La scala della rete Amazon Web Services comprende 69 zone in tutto il mondo, suddivise in 22 regioni: Stati Uniti, Europa, Asia, Africa e Australia. Ogni zona contiene fino a 8 data center. Ogni data center può contenere migliaia o centinaia di migliaia di server. La rete è progettata considerando tutti gli scenari improbabili di interruzione del servizio. Ad esempio, tutte le regioni sono isolate l'una dall'altra e le zone di disponibilità sono distanziate di diversi chilometri. Anche nel caso in cui un cavo venga interrotto, il sistema passerà a canali di riserva, e la perdita di dati sarà limitata a pochi pacchetti. Vasily Pantyukhin spiegherà su quali altri principi si basa la rete e come è strutturata.
Vasily Pantyukhin ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni con hardware complesso di Sun Microsystem e per 11 anni ha promosso la centralità dei dati nel mondo EMC. Naturalmente è evoluto verso cloud privati, per poi passare ai pubblici. Ora, come architetto di Amazon Web Services, offre consulenze tecniche per vivere e svilupparsi nel cloud AWS.
Nella parte precedente della trilogia sulla struttura di AWS, Vasily ha approfondito la configurazione dei server fisici e la scalabilità del database. Le schede Nitro, l'iperanno personalizzato basato su KVM, il database Amazon Aurora: tutto ciò è trattato nell'articolo "". Leggi per immergerti nel contesto, oppure guarda le sue presentazioni.
In questa parte si parlerà della scalabilità della rete, uno dei sistemi più complessi in AWS. L'evoluzione da una rete piatta a Virtual Private Cloud e la sua struttura, i servizi interni Blackfoot e HyperPlane, il problema del vicino rumoroso e, infine, le dimensioni della rete, backbone e cavi fisici. Tutto questo è sotto il tag.
Disclaimer: tutto ciò che segue è un'opinione personale di Vasily e potrebbe non coincidere con la posizione di Amazon Web Services.
Scalabilità della rete
Il cloud AWS è stato lanciato nel 2006. La sua rete era piuttosto primitiva, con una struttura piatta. L'intervallo degli indirizzi privati era comune per tutti i tenant del cloud. Quando veniva avviata una nuova macchina virtuale, si otteneva casualmente un indirizzo IP disponibile da questo intervallo.
Questo approccio era semplice da implementare, ma limitava sostanzialmente l'utilizzo del cloud. In particolare, era abbastanza difficile sviluppare soluzioni ibride che combinassero reti private on-premise e in AWS. Il problema più comune riguardava l'intersezione degli intervalli di indirizzi IP.
Virtual Private Cloud
Il cloud si è rivelato richiesto. È tempo di riflettere sulla scalabilità e sulla possibilità di utilizzo da parte di decine di milioni di tenant. La rete piatta è diventata il principale ostacolo. Pertanto, abbiamo pensato a come isolare gli utenti l'uno dall'altro a livello di rete in modo che possano scegliere autonomamente le gamme di IP.
Cosa ti viene in mente quando pensi all'isolamento della rete? Certamente VLAN e VRF – Virtual Routing and Forwarding.
Sfortunatamente, questo non ha funzionato. L'ID VLAN è di soli 12 bit, il che ci dà solo 4096 segmenti isolati. Anche nei commutatori più grandi, si possono utilizzare al massimo 1-2 mila VRF. La condivisione di VRF e VLAN ci fornisce solo alcuni milioni di sottoreti. Questo non è assolutamente sufficiente per decine di milioni di tenant, ciascuno dei quali deve avere la possibilità di utilizzare più sottoreti.
Inoltre, semplicemente non possiamo permetterci di acquistare il numero richiesto di grandi unità, ad esempio da Cisco o Juniper. Ci sono due motivi: è estremamente costoso e non vogliamo dipendere dalla loro politica di sviluppo e di patch.
L'unica conclusione è: dobbiamo creare la nostra soluzione.
Nel 2009 abbiamo annunciato VPC — Virtual Private Cloud. Il nome è adottato e ora molti fornitori di cloud lo usano.
VPC è una rete virtuale SDN (Software Defined Network). Abbiamo deciso di non inventare protocolli speciali ai livelli L2 e L3. La rete funziona su Ethernet e IP standard. Per trasmettere sulla rete, il traffico delle macchine virtuali viene incapsulato in un involucro del nostro protocollo. Qui viene specificato un ID appartenente al tenant VPC.
Sembra semplice. Tuttavia, è necessario risolvere alcuni problemi tecnici seri. Ad esempio, dove e come memorizzare i dati sulla mappatura degli indirizzi MAC/IP virtuali, VPC ID e i corrispondenti MAC/IP fisici. Su larga scala AWS, si tratta di una tabella enorme, che deve funzionare con latenze minime. Questo è gestito dal servizio di mappatura, che è distribuito uniformemente su tutta la rete.
Nelle macchine di nuova generazione, l'incapsulamento viene eseguito dalle schede Nitro a livello hardware. Negli istanti più vecchi, l'incapsulamento e la decapsulazione sono a livello software.
Esaminiamo come funziona in linea generale. Iniziamo dal livello L2. Supponiamo di avere una macchina virtuale con IP 10.0.0.2 su un server fisico 192.168.0.3. Essa invia dati a una macchina virtuale 10.0.0.3, che si trova su 192.168.1.4. Viene generata una richiesta ARP che arriva alla scheda di rete Nitro. Per semplicità, consideriamo che entrambe le macchine virtuali si trovino nello stesso VPC "blu".
La scheda sostituisce l'indirizzo sorgente con il proprio e inoltra il frame ARP al servizio di mappatura.
Il servizio di mappatura restituisce le informazioni necessarie per la trasmissione sulla rete fisica L2.
La scheda Nitro nell'ARP di risposta sostituisce il MAC nella rete fisica con l'indirizzo nel VPC.
Quando trasferiamo dati, incapsuliamo i MAC logici e gli IP in un involucro VPC. Tutto ciò viene trasmesso sulla rete fisica utilizzando le relative schede IP Nitro di origine e destinazione.
La macchina fisica a cui è destinato il pacchetto esegue un controllo. Questo è necessario per prevenire la possibilità di falsificazione degli indirizzi. La macchina invia una richiesta speciale al servizio di mappatura chiedendo: "Ho ricevuto un pacchetto da 192.168.0.3 destinato a 10.0.0.3 nel VPC 'blu'. È legittimo?"
Il servizio di mappatura confronta con la sua tabella di posizionamento delle risorse e consente o impedisce il passaggio del pacchetto. In tutte le nuove istanze, una validazione aggiuntiva è integrata nelle schede Nitro. Non è possibile bypassarla nemmeno in teoria. Pertanto, lo spoofing delle risorse in un altro VPC non funzionerà.
Successivamente, i dati vengono inviati alla macchina virtuale per cui sono destinati.
Il servizio di mappatura funziona anche come router logico per la trasmissione di dati tra macchine virtuali in diverse sottoreti. Qui tutto è concettualmente semplice, non scenderò nei dettagli.
Dunque, quando viene trasferito ogni pacchetto, i server si rivolgono al servizio di mappatura. Come affrontare inevitabili ritardi? Con la memorizzazione nella cache., naturalmente.
La bellezza è che non è necessario memorizzare l'intera enorme tabella. Nei server fisici risiedono macchine virtuali da un numero relativamente limitato di VPC. Le informazioni devono essere memorizzate nella cache solo per questi VPC. La trasmissione di dati in altri VPC, in configurazione "predefinita", non è comunque legittima. Se viene utilizzata funzionalità come VPC-peering, allora il cache viene ulteriormente popolato con informazioni sui VPC corrispondenti.
Abbiamo chiarito la trasmissione dei dati in VPC.
Blackfoot
Cosa fare nei casi in cui il traffico deve essere inviato all'esterno, ad esempio in Internet o tramite VPN verso terra? Qui ci aiuta Blackfoot — un servizio interno AWS. È stato sviluppato dal nostro team sudafricano. Pertanto, il servizio prende il nome da un pinguino che vive in Sudafrica.
Blackfoot de-incapsula il traffico e lo gestisce secondo necessità. I dati in Internet vengono inviati così come sono.
I dati vengono de-incapsulati e ri-incapsulati in un involucro IPsec quando si utilizza VPN.
Quando si utilizza Direct Connect, il traffico viene etichettato e inviato nel corrispondente VLAN.
HyperPlane
Questo è un servizio interno di controllo del flusso. Molti servizi di rete richiedono il controllo dello stato del flusso di dati. Ad esempio, quando si utilizza NAT, il controllo del flusso deve garantire che a ogni coppia "IP: porta di destinazione" corrisponda una porta di uscita unica. Nel caso di un bilanciatore di carico NLB — Network Load Balancer, il flusso di dati deve sempre essere diretto alla stessa macchina virtuale di destinazione. Security Groups è un firewall stateful. Tiene traccia del traffico in entrata e apre implicitamente porte per il flusso di pacchetti in uscita.
Nel cloud AWS, i requisiti di latenza sono estremamente elevati. Pertanto HyperPlane è critico per il funzionamento dell'intera rete.
Hyperplane è costruito su macchine virtuali EC2. Non c'è alcuna magia, solo astuzia. L'astuzia sta nel fatto che queste sono macchine virtuali con molta RAM. Le operazioni sono transazionali e si svolgono esclusivamente in memoria. Ciò consente di ottenere latenze nell'ordine di decine di microsecondi. Lavorare con il disco comprometterebbe completamente le prestazioni.
Hyperplane è un sistema distribuito composto da un enorme numero di tali macchine EC2. Ogni macchina virtuale ha una capacità di 5 GB/s. Su scala dell'intera rete regionale, ciò fornisce una quantità incredibile di terabits di larghezza di banda e consente di gestire milioni di connessioni al secondo.
HyperPlane funziona solo con flussi. L'incapsulamento dei pacchetti VPC è completamente trasparente per esso. Una potenziale vulnerabilità in questo servizio interno non consentirebbe comunque di rompere l'isolamento VPC. La sicurezza è garantita dai livelli inferiori.
Noisy neighbor
C'è anche un problema del vicino rumoroso — noisy neighbor. Supponiamo di avere 8 nodi. Questi nodi gestiscono il traffico di tutti gli utenti del cloud. Sembra che tutto funzioni bene e il carico dovrebbe essere distribuito uniformemente tra tutti i nodi. I nodi sono molto potenti ed è difficile sovraccaricarli.
Ma costruiamo la nostra architettura tenendo conto anche di scenari improbabili.
Una bassa probabilità non significa impossibilità.
Possiamo immaginare una situazione in cui uno o più utenti generano un carico eccessivo. Tutti i nodi HyperPlane sono coinvolti nella gestione di questo carico e altri utenti potrebbero percepire una certa diminuzione delle prestazioni. Questo distrugge il concetto di cloud, dove i tenant non possono influenzarsi a vicenda.
Come risolvere il problema del vicino rumoroso? La prima cosa che viene in mente è lo sharding. I nostri 8 nodi vengono logicamente suddivisi in 4 shard con 2 nodi ciascuno. Ora il vicino rumoroso disturberà solo un quarto di tutti gli utenti, ma in modo significativo.
Facciamo diversamente. Assegniamo a ciascun utente solo 3 nodi.
Il trucco è assegnare i nodi a diversi utenti in modo casuale. Nella figura sottostante, l'utente blu condivide alcuni nodi con uno dei due altri utenti: quello verde e quello arancione.
Con 8 nodi e 3 utenti, la probabilità che il vicino rumoroso si sovrapponga a uno degli utenti è del 54%. Così il'utente blu influenzerà gli altri tenant con quella probabilità, e solo con una parte del suo carico. Nel nostro esempio, questo impatto sarà percepito da un terzo degli utenti, e non da tutti. Questo è già un buon risultato.
Numero di utenti che si sovrapporranno
Probabilità in percentuale
0
18%
1
54%
2
26%
3
2%
Avviciniamo la situazione alla realtà - prendiamo 100 nodi e 5 utenti che utilizzano 5 nodi. In questo caso, nessuno dei nodi si sovrapporrà con una probabilità del 77%.
Numero di utenti che si sovrapporranno
Probabilità in percentuale
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Nella situazione reale, data l'enorme quantità di nodi HyperPlane e utenti, l'impatto potenziale del vicino rumoroso sugli altri utenti è minimo. Questo metodo è chiamato sharding mescolato — shuffle sharding. Minimizza l'effetto negativo dell'uscita dei nodi dalla rete.
Su HyperPlane sono costruiti numerosi servizi: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Le dimensioni della rete
Ora parliamo delle dimensioni della rete stessa. A ottobre 2019, AWS offre i suoi servizi in 22 regioni, e sono pianificate altre 9.
- Ogni regione contiene diverse zone di disponibilità — Availability Zone. In totale ce ne sono 69 nel mondo.
- Ogni AZ è composta da Data Center. In totale, non sono più di 8.
- Nei Data Center sono presenti un enorme numero di server, alcuni hanno fino a 300.000.
Ora facciamo una media, moltiplichiamo e otteniamo una cifra impressionante che riflette la scala del cloud di Amazon.
Tra le zone di disponibilità e i Data Center ci sono molti canali ottici. In una delle nostre regioni più grandi, ci sono 388 canali dedicati solo per collegare le AZ tra loro e i centri di transito con altre regioni. In totale, ciò porta a 5000 Tbps.
Il Backbone AWS è costruito appositamente per il cloud ed è ottimizzato per funzionare con esso. Lo costruiamo su canali 100 Gbps.Ne abbiamo il completo controllo, eccetto che nelle regioni della Cina. Il traffico non è condiviso con i carichi di altre aziende.
Certo, non siamo l'unico fornitore di cloud con una rete backbone privata. Sempre più grandi aziende stanno seguendo questa strada. Questo è confermato da ricercatori indipendenti, ad esempio da .
Nel grafico si vede che la quota dei fornitori di contenuti e dei fornitori di cloud sta crescendo. Di conseguenza, la quota del traffico Internet dei fornitori backbone sta costantemente diminuendo.
Spiegherò perché questo accade. In passato, la maggior parte dei servizi web erano disponibili e consumati direttamente da Internet. Ora sempre più server si trovano nel cloud e sono accessibili tramite CDN — Content Distribution Network.Per accedere alla risorsa, l'utente passa tramite Internet solo fino al più vicino PoP CDN — Point of Presence.Nella maggior parte dei casi è nelle vicinanze. Poi esce da Internet pubblico e viaggia attraverso il backbone privato, ad esempio attraverso l'Atlantico, e arriva direttamente alla risorsa.
È interessante pensare a come cambierà Internet tra 10 anni se questa tendenza continuerà.
Canali fisici
Gli scienziati non hanno ancora trovato un modo per aumentare la velocità della luce nell'universo, ma hanno fatto grandi progressi nei metodi per trasmetterla attraverso la fibra ottica. Attualmente utilizziamo cavi con 6912 fibre. Questo aiuta a ottimizzare significativamente i costi della loro posa.
In alcune regioni dobbiamo utilizzare cavi speciali. Ad esempio, nella regione di Sydney, utilizziamo cavi con un rivestimento speciale contro le termiti.
Nessuno è al sicuro dai guai e a volte i nostri canali possono subire danni. Nella foto a destra ci sono cavi in fibra ottica in una delle regioni americane, danneggiati da costruttori. A causa dell'incidente sono andati persi solo 13 pacchetti di dati, il che è sorprendente. Ripeto: solo 13! Il sistema si è letteralmente commutato istantaneamente sui canali di riserva — il ridimensionamento funziona.
Abbiamo fatto un rapido giro tra alcuni servizi e tecnologie del cloud di Amazon. Spero che ora abbiate almeno un'idea dell'ampiezza delle sfide che i nostri ingegneri devono affrontare. Personalmente, lo trovo molto coinvolgente.
Questa è l'ultima parte della trilogia di Vasiliy Pantyukhin sull'architettura di AWS. Nel primo volume sono descritti l'ottimizzazione dei server e la scalabilità del database, mentre nel secondo volume si parla di funzioni serverless e Firecracker.
A A novembre, Vasiliy Pantyukhin condividerà nuovi dettagli sull'architettura di Amazon. Egli tratterà delle cause di guasti e della progettazione di sistemi distribuiti in Amazon. Fino al 24 ottobre è ancora possibile acquistare un biglietto a un buon prezzo e pagare in seguito. Vi aspettiamo a HighLoad++, venite a trovarci — chiacchiereremo!
Fonte: habr.com
