La scala della rete Amazon Web Services comprende 69 zone in tutto il mondo, distribuite in 22 regioni: Stati Uniti, Europa, Asia, Africa e Australia. Ogni zona può ospitare fino a 8 Data Center (DC). In ciascun DC ci sono migliaia o centinaia di migliaia di server. La rete è progettata tenendo conto di tutti gli scenari improbabili di interruzione. Ad esempio, tutte le regioni sono isolate l'una dall'altra e le zone di disponibilità sono distanti alcuni chilometri. Anche se un cavo viene interrotto, il sistema passa a canali di riserva, riducendo al minimo le perdite di dati a poche unità di pacchetti. Vasili Pantuichin parlerà di quali altri principi fondamentali guidano la rete e come è strutturata.
Vasili Pantuichin ha iniziato come admin Unix in aziende .ru, ha lavorato per 6 anni su grandi sistemi Sun Microsystems e ha trascorso 11 anni a divulgare l'importanza dei data center in EMC. È evoluto naturalmente verso i cloud privati, poi si è orientato verso quelli pubblici. Attualmente, come architetto di Amazon Web Services, offre consigli tecnici per aiutare a vivere e prosperare nel cloud AWS.
Nella parte precedente della trilogia sull'architettura AWS, Vasiliy ha approfondito l'architettura dei server fisici e la scalabilità del database. Schede Nitro, hypervisor personalizzato basato su KVM, database Amazon Aurora: tutti questi temi sono trattati nell'articolo "Leggi per approfondire il contesto oppure guarda della presentazione.
In questa parte parleremo della scalabilità della rete, uno dei sistemi più complessi in AWS. L'evoluzione da una rete piatta a Virtual Private Cloud e la sua architettura, i servizi interni Blackfoot e HyperPlane, il problema dei 'vicini rumorosi', e infine, della grandezza della rete, backbone e cavi fisici. Tutto questo nel seguito.
Disclaimer: tutto ciò che segue è l'opinione personale di Vasiliy e potrebbe non coincidere con quella 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 a tutti i tenant del cloud. Quando avviavi una nuova macchina virtuale, ricevevi casualmente un indirizzo IP disponibile da questo intervallo.
Questo approccio era semplice da implementare, ma limitava sostanzialmente l'uso del cloud. In particolare, era piuttosto complicato sviluppare soluzioni ibride che combinassero reti private on-premise con AWS. Il problema più comune era l'intersezione degli intervalli di indirizzi IP.
Virtual Private Cloud
Il cloud si è dimostrato richiesto. È giunto il momento di riflettere sulla scalabilità e sulla possibilità di utilizzo da parte di decine di milioni di tenant. Una rete piatta è diventata il principale ostacolo. Perciò abbiamo iniziato a pensare a come isolare gli utenti tra loro a livello di rete, in modo che potessero scegliere autonomamente gli intervalli di IP.
Cosa ti viene in mente quando pensi all'isolamento di rete? Certamente VLAN e VRF — Virtual Routing and Forwarding.
Purtroppo, non ha funzionato. L'ID VLAN è di soli 12 bit, il che ci consente di avere solo 4096 segmenti isolati. Anche nei più grandi switch si possono utilizzare al massimo 1-2 mila VRF. La condivisione di VRF e VLAN ci offre solo alcuni milioni di sottoreti. Questo non è affatto sufficiente per decine di milioni di tenant, ognuno dei quali deve poter usare più sottoreti.
Inoltre, semplicemente non possiamo permetterci di acquistare il numero richiesto di grandi scatole, ad esempio da Cisco o Juniper. Ci sono due motivi: è estremamente costoso e non vogliamo dipendere dalla loro politica di sviluppo e patching.
La conclusione è una: dobbiamo sviluppare la nostra soluzione.
Nel 2009 abbiamo annunciato VPC — Virtual Private Cloud. Il nome ha preso piede ed ora lo utilizzano anche molti fornitori di cloud.
Il VPC è una rete virtuale SDN (Software Defined Network). Abbiamo deciso di non inventare protocolli speciali per i livelli L2 e L3. La rete funziona su standard Ethernet e IP. Per il trasferimento dei dati, il traffico delle macchine virtuali è racchiuso in un pacchetto del nostro protocollo. In esso è indicato l'ID appartenente al tenant del VPC.
Sembra semplice. Tuttavia, ci sono diverse sfide tecniche serie da affrontare. Ad esempio, dove e come memorizzare i dati sul mappamento degli indirizzi MAC/IP virtuali, ID VPC e i rispettivi indirizzi MAC/IP fisici. Su scala AWS, si tratta di una tabella enorme, che deve funzionare con latenze minime durante l'accesso. Questo è gestito da servizio di mappatura, che è distribuito diffusamente in tutta la rete.
Nei macchinari di nuova generazione, l'incapsulamento avviene tramite le schede Nitro a livello hardware. Negli istanze più vecchie, l'incapsulamento e la decapsulazione sono gestiti a livello software.
Vediamo come funziona in generale. Iniziamo con il 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à, supponiamo 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 nella risposta ARP sostituisce l'indirizzo MAC nella rete fisica con uno dell'VPC.
Durante la trasmissione dei dati, incapsuliamo gli indirizzi MAC e IP logici in un'involucro VPC. Tutto ciò viene trasmesso attraverso la rete fisica utilizzando le corrispondenti schede IP Nitro di origine e destinazione.
La macchina fisica destinataria del pacchetto effettua un controllo. Questo serve a prevenire la possibilità di spoofing degli indirizzi. La macchina invia una richiesta speciale al servizio di mappatura e chiede: «Dalla macchina fisica 192.168.0.3 ho ricevuto un pacchetto destinato a 10.0.0.3 nel VPC 'blu'. È legittimo?»
Il servizio di mappatura fa riferimento alla sua tabella di allocazione delle risorse e permette o rifiuta il passaggio del pacchetto. In tutte le nuove istanze, una validazione aggiuntiva è integrata nelle schede Nitro. Non può essere aggirata neanche teoricamente. 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 funge anche da router logico per la trasmissione dei dati tra le macchine virtuali in diverse sottoreti. Concettualmente, tutto è semplice, non entrerò nei dettagli.
A quanto pare, quando si trasmette ogni pacchetto, i server si rivolgono al servizio di mapping. Come affrontare i ritardi inevitabili? Caching, naturalmente.
La bellezza sta nel fatto che non è necessario memorizzare nella cache l'intera enorme tabella. Su un server fisico risiedono macchine virtuali provenienti da un numero relativamente ridotto di VPC. È necessario memorizzare nella cache informazioni solo su questi VPC. La trasmissione dei dati ad altri VPC, nella configurazione "predefinita", non è comunque legittima. Se viene utilizzata funzionalità come il VPC peering, le informazioni sui VPC corrispondenti vengono aggiunte al cache.
Abbiamo chiarito la questione della trasmissione dei dati nel VPC.
Blackfoot
Cosa fare nei casi in cui il traffico debba essere inviato all'esterno, ad esempio su Internet o tramite VPN verso la terra? Qui ci viene in aiuto Blackfoot — un servizio interno di AWS. È stato sviluppato dal nostro team sudafricano. Pertanto, il servizio prende il nome da un pinguino che vive in Sudafrica.
Blackfoot decapsula il traffico e fa con esso ciò che è necessario. I dati su Internet vengono inviati così come sono.
I dati vengono decapsulati e riconsolidati in un pacchetto IPsec quando si utilizza la VPN.
Utilizzando Direct Connect, il traffico viene etichettato e inviato nel VLAN corrispondente.
HyperPlane
Questo è un servizio interno di controllo del flusso. Molti servizi di rete richiedono un controllo dello stato del flusso di dati. Ad esempio, utilizzando 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 indirizzato alla stessa macchina virtuale di destinazione. I Security Groups sono un firewall a stato. Monitorano il traffico in entrata e aprono implicitamente porte per il flusso di pacchetti in uscita.
In AWS, i requisiti di latenza della trasmissione 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 è che queste sono virtual machine con grande RAM. Le operazioni sono transazionali e avvengono esclusivamente in memoria. Ciò consente di raggiungere latenze di solo decine di microsecondi. Lavorare con il disco comprometterebbe le prestazioni.
Hyperplane è un sistema distribuito composto da un grande numero di macchine EC2. Ogni virtual machine ha una capacità di throughput di 5 GB/s. Su scala dell'intera rete regionale, questo fornisce una straordinaria capacità di terabyte e permette di elaborare milioni di connessioni al secondo.
HyperPlane funziona esclusivamente con flussi. La VPC incapsula i pacchetti in modo completamente trasparente per essa. Un'eventuale vulnerabilità in questo servizio interno non permetterebbe comunque di violare l'isolamento della VPC. La sicurezza è garantita dai livelli sottostanti.
Vicino rumoroso
C'è anche un problema di un vicino rumoroso — vicino rumoroso. Supponiamo di avere 8 nodi. Questi nodi elaborano i flussi di tutti gli utenti del cloud. Sembra che tutto vada bene e che il carico dovrebbe distribursi equamente tra tutti i nodi. I nodi sono molto potenti e è difficile sovraccaricarli.
Ma costruiamo la nostra architettura tenendo conto anche di scenari poco probabili.
Una bassa probabilità non significa impossibilità.
Possiamo immaginare una situazione in cui uno o più utenti generano un carico eccessivo. Tutte le nodi di HyperPlane sono coinvolte in questo carico e altri utenti potrebbero percepire una diminuzione delle prestazioni. Questo mina il concetto di cloud, in cui i tenant non possono influenzarsi a vicenda.
Come risolvere il problema del vicino rumoroso? La prima cosa che viene in mente è lo sharding. Le nostre 8 nodi si dividono logicamente in 4 shard con 2 nodi ciascuno. Ora un vicino rumoroso disturberà solo un quarto di tutti gli utenti, ma in modo significativo.
Facciamo diversamente. Assegniamo a ogni utente solo 3 nodi.
Il trucco è assegnare nodi a utenti diversi in modo casuale. Nella figura qui sotto, l'utente blu condivide nodi con uno dei due altri utenti: il verde e l'arancione.
Con 8 nodi e 3 utenti, la probabilità che un vicino rumoroso si sovrapponga a uno degli utenti è del 54%. Proprio con questa probabilità l'utente blu influenzerà gli altri tenant. Tuttavia, solo una parte del suo carico avrà effetto. Nel nostro esempio, questa influenza sarà percepita solo da un terzo di tutti gli utenti. È 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 su 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, con un enorme numero di nodi e utenti HyperPlane, l'impatto potenziale di un vicino rumoroso sugli altri utenti è minimo. Questo metodo si chiama sharding casuale — shuffle sharding. Minimizza l'effetto negativo dell'uscita dei nodi dal servizio.
Su HyperPlane sono costruiti molti servizi: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Dimensioni della rete
Ora parliamo delle dimensioni della rete stessa. A ottobre 2019, AWS offre i suoi servizi in 22 regioni, e sono previsti altri 9.
- Ogni regione contiene diverse zone di disponibilità — Availability Zone. In totale ce ne sono 69 nel mondo.
- Ogni AZ consiste in Data Center. In totale non più di 8.
- Nei Data Center ci sono un numero enorme di server, alcuni arrivano fino a 300.000.
Adesso mediamo tutto questo, moltiplichiamo e otteniamo una cifra impressionante che rappresenta la scala del cloud di Amazon.
Tra le zone di disponibilità e i Data Center ci sono molti canali ottici. In una delle nostre più grandi regioni abbiamo solo per la comunicazione tra le AZ e i centri di interconnessione con altre regioni (Transit Centers) 388 canali. In totale questo offre un incredibile 5000 Tbps.
Il backbone di AWS è costruito specificamente per il cloud ed è ottimizzato per funzionare con esso. Lo costruiamo su canali 100 GB/s. Li controlliamo completamente, ad eccezione delle regioni in Cina. Il traffico non si divide con i carichi di altre aziende.
Certo, non siamo l'unico provider cloud con una rete backbone privata. Sempre più grandi aziende stanno seguendo questa strada. Questo è confermato da ricercatori indipendenti, come quelli di .
Il grafico mostra che la quota dei fornitori di contenuti e dei fornitori di cloud sta crescendo. Di conseguenza, la quota del traffico Internet dei fornitori di backbone continua a diminuire.
Spiegherò perché sta accadendo. In passato, la maggior parte dei servizi web era accessibile e consumata direttamente da Internet. Oggi sempre più server si trovano nel cloud e sono accessibili tramite fornitore di CDN). Monitorano il loro — Content Distribution Network. Per accedere alla risorsa, l'utente passa per Internet solo fino al più vicino PoP della CDN — Point of Presence. Nella maggior parte dei casi, è qualcosa di vicino. Poi esce da Internet pubblico e viaggia attraverso un backbone privato, ad esempio, attraverso l'Atlantico, e arriva direttamente alla risorsa.
È interessante pensare a come cambierà Internet tra 10 anni se questa tendenza dovesse proseguire.
Canali fisici
Gli scienziati non hanno ancora scoperto come aumentare la velocità della luce nell'universo, ma hanno fatto notevoli progressi nelle tecniche di trasmissione attraverso la fibra ottica. Attualmente utilizziamo cavi con 6912 fibre. Questo aiuta a ottimizzare notevolmente i costi della loro installazione.
In alcune regioni dobbiamo utilizzare cavi speciali. Ad esempio, nella regione di Sydney usiamo cavi con un rivestimento speciale contro le termiti.
Nessuno è immune da imprevisti e a volte i nostri canali subiscono danni. Nella foto a destra ci sono i cavi in fibra ottica in una delle regioni americane, rotti da alcuni costruttori. A causa dell'incidente, sono andati persi solo 13 pacchetti di dati, il che è sorprendente. Ripeto: solo 13! Il sistema è passato letteralmente istantaneamente ai canali di riserva — il sistema è scalabile.
Abbiamo dato un'occhiata veloce ad alcuni servizi e tecnologie del cloud di Amazon. Spero che vi sia venuta almeno un'idea della portata delle sfide che i nostri ingegneri devono affrontare. Personalmente, questo mi affascina molto.
Questa è l'ultima parte della trilogia di Vasily Pantiukhin sull'architettura di AWS. In questa parte vengono descritti l'ottimizzazione dei server e la scalabilità del database, mentre in si parla di funzioni serverless e di Firecracker.
Su A novembre, Vasily Pantiukhin condividerà nuovi dettagli sull'architettura di Amazon. Egli parlerà delle cause dei fallimenti e della progettazione di sistemi distribuiti in Amazon. Fino al 24 ottobre è ancora possibile un biglietto a un buon prezzo e pagare poi. Vi aspettiamo a HighLoad++, venite a trovarci — sarà un piacere chiacchierare!
Fonte: habr.com
