La portata della rete Amazon Web Services è di 69 zone in tutto il mondo in 22 regioni: Stati Uniti, Europa, Asia, Africa e Australia. Ogni zona contiene fino a 8 data center - Centri elaborazione dati. Ogni data center ha migliaia o centinaia di migliaia di server. La rete è progettata in modo tale da prendere in considerazione tutti gli scenari improbabili di interruzione. Ad esempio, tutte le regioni sono isolate le une dalle altre e le zone di accessibilità sono separate su distanze di diversi chilometri. Anche se si taglia il cavo, il sistema passerà ai canali di backup e la perdita di informazioni ammonterà ad alcuni pacchetti di dati. Vasily Pantyukhin parlerà di quali altri principi è costruita la rete e di come è strutturata.
Vasily Pantyukhin ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni su hardware Sun Microsystem di grandi dimensioni e per 11 anni ha predicato un mondo incentrato sui dati presso EMC. Si è evoluto naturalmente nei cloud privati, per poi passare a quelli pubblici. Ora, in qualità di architetto di Amazon Web Services, fornisce consulenza tecnica per aiutare a vivere e sviluppare nel cloud AWS.
Nella parte precedente della trilogia AWS, Vasily ha approfondito la progettazione di server fisici e la scalabilità del database. Schede Nitro, hypervisor personalizzato basato su KVM, database Amazon Aurora: tutto questo nel materiale "" Leggi per contesto o guarda discorsi.
Questa parte si concentrerà sulla scalabilità della rete, uno dei sistemi più complessi in AWS. L'evoluzione da una rete piatta a un cloud privato virtuale e la sua progettazione, i servizi interni di Blackfoot e HyperPlane, il problema di un vicino rumoroso e, infine, la portata della rete, della dorsale e dei cavi fisici. Tutto questo sotto il taglio.
Dichiarazione di non responsabilità: tutto ciò che segue rappresenta l'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 di indirizzi privati era comune a tutti i tenant del cloud. Quando avvii una nuova macchina virtuale, hai ricevuto accidentalmente un indirizzo IP disponibile da questo intervallo.
Questo approccio era facile da implementare, ma limitava fondamentalmente l’uso del cloud. In particolare, è stato piuttosto difficile sviluppare soluzioni ibride che combinassero reti private a terra e in AWS. Il problema più comune era la sovrapposizione degli intervalli di indirizzi IP.
Cloud privato virtuale
Il cloud si è rivelato molto richiesto. È giunto il momento di pensare alla scalabilità e alla possibilità del suo utilizzo da parte di decine di milioni di inquilini. La rete piatta è diventata un grosso ostacolo. Pertanto, abbiamo pensato a come isolare gli utenti gli uni dagli altri a livello di rete in modo che possano scegliere autonomamente gli intervalli IP.
Qual è la prima cosa che ti viene in mente quando pensi all'isolamento della rete? Certamente VLAN и VRF - Routing e inoltro virtuale.
Sfortunatamente, non ha funzionato. L'ID VLAN è di soli 12 bit, il che ci fornisce solo 4096 segmenti isolati. Anche gli switch più grandi possono utilizzare un massimo di 1-2mila VRF. L'uso combinato di VRF e VLAN ci fornisce solo pochi milioni di sottoreti. Questo sicuramente non è sufficiente per decine di milioni di tenant, ognuno dei quali deve poter utilizzare più sottoreti.
Inoltre, semplicemente non possiamo permetterci di acquistare il numero richiesto di scatole di grandi dimensioni, ad esempio da Cisco o Juniper. Ci sono due ragioni: è pazzesco e non vogliamo essere alla mercé delle loro politiche di sviluppo e patch.
C'è solo una conclusione: crea la tua soluzione.
Nel 2009 abbiamo annunciato VPC - Cloud privato virtuale. Il nome è rimasto e ora lo utilizzano anche molti fornitori di servizi cloud.
VPC è una rete virtuale SDN (Rete definita dal software). Abbiamo deciso di non inventare protocolli speciali ai livelli L2 e L3. La rete funziona su Ethernet e IP standard. Per la trasmissione sulla rete, il traffico della macchina virtuale viene incapsulato nel nostro wrapper di protocollo. Indica l'ID che appartiene al VPC del tenant.
Sembra semplice. Tuttavia, ci sono diverse sfide tecniche serie che devono essere superate. Ad esempio, dove e come archiviare i dati sulla mappatura degli indirizzi MAC/IP virtuali, dell'ID VPC e del MAC/IP fisico corrispondente. Su scala AWS, si tratta di una tabella enorme che dovrebbe funzionare con ritardi di accesso minimi. Responsabile di questo servizio di mappatura, che è distribuito in uno strato sottile in tutta la rete.
Nelle macchine di nuova generazione l'incapsulamento viene eseguito dalle schede Nitro a livello hardware. Nei casi più vecchi, l'incapsulamento e il decapsulamento sono basati su software.
Scopriamo come funziona in termini generali. Cominciamo con il livello L2. Supponiamo di avere una macchina virtuale con IP 10.0.0.2 su un server fisico 192.168.0.3. Invia i dati alla macchina virtuale 10.0.0.3, che risiede su 192.168.1.4. Una richiesta ARP viene generata e inviata alla scheda di rete Nitro. Per semplicità, presupponiamo che entrambe le macchine virtuali vivano nello stesso VPC “blu”.
La mappa sostituisce l'indirizzo di origine 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 il MAC sulla rete fisica con un indirizzo nel VPC.
Durante il trasferimento dei dati, avvolgiamo MAC e IP logici in un wrapper VPC. Trasmettiamo tutto questo sulla rete fisica utilizzando le apposite schede IP Nitro di origine e destinazione.
La macchina fisica a cui è destinato il pacco esegue il controllo. Ciò è necessario per 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 controlla la tabella di allocazione delle risorse e consente o nega il passaggio del pacchetto. In tutti i nuovi casi, una convalida aggiuntiva è incorporata nelle carte Nitro. È impossibile aggirarlo anche teoricamente. Pertanto, lo spoofing sulle risorse in un altro VPC non funzionerà.
Successivamente, i dati vengono inviati alla macchina virtuale a cui sono destinati.
Il servizio di mappatura funziona anche come router logico per il trasferimento di dati tra macchine virtuali in sottoreti diverse. Tutto è concettualmente semplice, non entrerò nei dettagli.
Si scopre che quando trasmettono ciascun pacchetto, i server si rivolgono al servizio di mappatura. Come affrontare gli inevitabili ritardi? Memorizzazione nella cache, ovviamente.
Il bello è che non è necessario memorizzare nella cache l'intero enorme tavolo. Un server fisico ospita macchine virtuali da un numero relativamente piccolo di VPC. Devi solo memorizzare nella cache le informazioni su questi VPC. Il trasferimento dei dati ad altri VPC nella configurazione “predefinita” non è ancora legittimo. Se viene utilizzata funzionalità come il peering VPC, nella cache vengono caricate anche le informazioni sui VPC corrispondenti.
Abbiamo risolto il trasferimento dei dati al VPC.
Blackfoot
Cosa fare nei casi in cui è necessario trasmettere il traffico all'esterno, ad esempio verso Internet o tramite VPN a terra? Ci aiuta qui Blackfoot — Servizio interno AWS. È sviluppato dal nostro team sudafricano. Ecco perché il servizio prende il nome da un pinguino che vive in Sud Africa.
Blackfoot decapsula il traffico e ne fa ciò che è necessario. I dati vengono inviati a Internet così come sono.
I dati vengono decapsulati e riavvolti in IPsec quando si utilizza una VPN.
Quando si utilizza Direct Connect, il traffico viene contrassegnato e inviato alla VLAN appropriata.
IperPiano
Questo è un servizio di controllo del flusso interno. Molti servizi di rete richiedono il monitoraggio stati del flusso di dati. Ad esempio, quando si utilizza NAT, il controllo del flusso deve garantire che ciascuna coppia di porte IP:destinazione disponga di una porta in uscita univoca. Nel caso di un bilanciatore NLB - Bilanciamento del carico di rete, il flusso di dati deve essere sempre indirizzato alla stessa macchina virtuale di destinazione. Gruppi di sicurezza è un firewall con stato. Monitora il traffico in entrata e apre implicitamente le porte per il flusso di pacchetti in uscita.
Nel cloud AWS, i requisiti di latenza di trasmissione sono estremamente elevati. Ecco perché IperPiano fondamentale per le prestazioni dell’intera rete.
Hyperplane è basato su macchine virtuali EC2. Non c'è magia qui, solo astuzia. Il trucco è che si tratta di macchine virtuali con una grande RAM. Le operazioni sono transazionali ed eseguite esclusivamente in memoria. Ciò consente di ottenere ritardi di sole decine di microsecondi. Lavorare con il disco ucciderebbe tutta la produttività.
Hyperplane è un sistema distribuito di un numero enorme di tali macchine EC2. Ogni macchina virtuale ha una larghezza di banda di 5 GB/s. Su tutta la rete regionale, ciò fornisce incredibili terabit di larghezza di banda e consente l'elaborazione milioni di connessioni al secondo.
HyperPlane funziona solo con i flussi. L'incapsulamento dei pacchetti VPC è completamente trasparente per questo. Una potenziale vulnerabilità in questo servizio interno impedirebbe comunque la rottura dell'isolamento VPC. I livelli sottostanti sono responsabili della sicurezza.
Vicino rumoroso
C'è ancora un problema 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 il carico dovrebbe essere distribuito uniformemente su tutti i nodi. I nodi sono molto potenti ed è difficile sovraccaricarli.
Ma costruiamo la nostra architettura sulla base di scenari anche improbabili.
Bassa probabilità non significa impossibile.
Possiamo immaginare una situazione in cui uno o più utenti genererebbero un carico eccessivo. Tutti i nodi HyperPlane sono coinvolti nell'elaborazione di questo carico e altri utenti potrebbero potenzialmente riscontrare qualche tipo di calo delle prestazioni. Ciò rompe il concetto di cloud, in cui gli inquilini non hanno la possibilità di influenzarsi a vicenda.
Come risolvere il problema di un vicino rumoroso? La prima cosa che mi viene in mente è lo sharding. I nostri 8 nodi sono logicamente divisi in 4 frammenti di 2 nodi ciascuno. Ora un vicino rumoroso disturberà solo un quarto di tutti gli utenti, ma li disturberà molto.
Facciamo le cose diversamente. Assegneremo solo 3 nodi a ciascun utente.
Il trucco sta nell'assegnare casualmente i nodi a diversi utenti. Nell'immagine sotto, l'utente blu interseca i nodi con uno degli altri due utenti: verde e arancione.
Con 8 nodi e 3 utenti, la probabilità che un vicino rumoroso si intersechi con uno degli utenti è del 54%. È con questa probabilità che un utente blu influenzerà gli altri inquilini. Allo stesso tempo, solo una parte del suo carico. Nel nostro esempio, questa influenza sarà almeno in qualche modo evidente non a tutti, ma solo a un terzo di tutti gli utenti. Questo è già un buon risultato.
Numero di utenti che si intersecheranno
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 intersecherà con una probabilità del 77%.
Numero di utenti che si intersecheranno
Probabilità in percentuale
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In una situazione reale, con un numero enorme di nodi e utenti HyperPlane, il potenziale impatto di un vicino rumoroso sugli altri utenti è minimo. Questo metodo si chiama mescolare lo sharding - frammentazione casuale. Minimizza l'effetto negativo del guasto del nodo.
Molti servizi sono costruiti sulla base di HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Scala di rete
Ora parliamo della portata della rete stessa. Per ottobre 2019 AWS offre i suoi servizi in 22 regioni, e altri 9 sono previsti.
- Ogni regione contiene diverse zone di disponibilità. Ce ne sono 69 in tutto il mondo.
- Ciascuna AZ è composta da Centri Elaborazione Dati. Non ce ne sono più di 8 in totale.
- Il data center ospita un numero enorme di server, alcuni fino a 300.
Ora calcoliamo la media di tutto questo, moltiplichiamo e otteniamo una cifra impressionante che riflette Scala cloud di Amazon.
Esistono molti collegamenti ottici tra le zone di disponibilità e il data center. In una delle nostre regioni più grandi, sono stati predisposti 388 canali solo per la comunicazione tra l'AZ e i centri di comunicazione con altre regioni (centri di transito). In totale questo fa impazzire 5000 Tbit.
Backbone AWS è costruito specificatamente e ottimizzato per il cloud. Lo costruiamo sui canali 100 GB/sec. Li controlliamo completamente, ad eccezione delle regioni della Cina. Il traffico non è condiviso con i carichi di altre compagnie.
Naturalmente non siamo l’unico cloud provider con una rete backbone privata. Sempre più grandi aziende stanno seguendo questa strada. Ciò è confermato da ricercatori indipendenti, ad esempio da .
Il grafico mostra che la quota di fornitori di contenuti e fornitori di servizi cloud è in crescita. Per questo motivo la quota del traffico Internet dei fornitori di backbone diminuisce costantemente.
Spiegherò perché ciò accade. In precedenza, la maggior parte dei servizi Web era accessibile e consumabile direttamente da Internet. Al giorno d'oggi, sempre più server si trovano nel cloud e sono accessibili tramite CDN - Rete di distribuzione dei contenuti. Per accedere ad una risorsa, l'utente attraversa Internet solo fino al PoP CDN più vicino - Punto di presenza. Molto spesso è da qualche parte nelle vicinanze. Quindi lascia l'Internet pubblica e vola attraverso una dorsale privata attraverso l'Atlantico, ad esempio, e arriva direttamente alla risorsa.
Mi chiedo come cambierà Internet tra 10 anni se questa tendenza continua?
Canali fisici
Gli scienziati non hanno ancora capito come aumentare la velocità della luce nell'Universo, ma hanno fatto grandi progressi nei metodi di trasmissione attraverso la fibra ottica. Attualmente utilizziamo cavi in fibra 6912. Ciò aiuta a ottimizzare in modo significativo il costo della loro installazione.
In alcune regioni dobbiamo utilizzare cavi speciali. Nella regione di Sydney, ad esempio, utilizziamo cavi con uno speciale rivestimento contro le termiti.
Nessuno è immune dai problemi e talvolta i nostri canali vengono danneggiati. La foto a destra mostra i cavi ottici in una delle regioni americane che sono stati strappati dai lavoratori edili. In seguito all’incidente sono andati perduti solo 13 pacchetti di dati, il che è sorprendente. Ancora una volta - solo 13! Il sistema è passato letteralmente all'istante ai canali di backup: la bilancia funziona.
Abbiamo galoppato attraverso alcuni dei servizi e delle tecnologie cloud di Amazon. Spero che tu abbia almeno un'idea della portata dei compiti che i nostri ingegneri devono risolvere. Personalmente, lo trovo molto eccitante.
Questa è la parte finale della trilogia di Vasily Pantyukhin sul dispositivo AWS. IN le parti descrivono l'ottimizzazione del server e il ridimensionamento del database e in — funzioni serverless e Firecracker.
Su a novembre Vasily Pantyukhin condividerà nuovi dettagli del dispositivo Amazon. Lui sulle cause dei guasti e sulla progettazione dei sistemi distribuiti su Amazon. Il 24 ottobre è ancora possibile biglietto a buon prezzo e paghi dopo. Ti aspettiamo a HighLoad++, vieni a chiacchierare!
Fonte: habr.com