{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Come AWS \"cucina\" i suoi servizi elastici. Scalabilit\u00e0 della rete","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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\u00f2 contenere migliaia o centinaia di migliaia di server. La rete \u00e8 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\u00e0 sono distanziate di diversi chilometri. Anche nel caso in cui un cavo venga interrotto, il sistema passer\u00e0 a canali di riserva, e la perdita di dati sar\u00e0 limitata a pochi pacchetti. Vasily Pantyukhin spiegher\u00e0 su quali altri principi si basa la rete e come \u00e8 strutturata.<\/p>\n

\"Come
\n
\nVasily Pantyukhin<\/b> 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\u00e0 dei dati nel mondo EMC. Naturalmente \u00e8 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.<\/p>\n

Nella parte precedente della trilogia sulla struttura di AWS, Vasily ha approfondito la configurazione dei server fisici e la scalabilit\u00e0 del database. Le schede Nitro, l'iperanno personalizzato basato su KVM, il database Amazon Aurora: tutto ci\u00f2 \u00e8 trattato nell'articolo \"Come AWS 'prepara' i suoi servizi elastici. Scalabilit\u00e0 dei server e dei database<\/a><\/noindex>\". Leggi per immergerti nel contesto, oppure guarda registrazione video<\/a><\/noindex> le sue presentazioni.<\/p>\n

In questa parte si parler\u00e0 della scalabilit\u00e0 della rete, uno dei sistemi pi\u00f9 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 \u00e8 sotto il tag.<\/p>\n

Disclaimer: tutto ci\u00f2 che segue \u00e8 un'opinione personale di Vasily e potrebbe non coincidere con la posizione di Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Scalabilit\u00e0 della rete<\/h2>\n

\nIl cloud AWS \u00e8 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.<\/p>\n

\"Come
\n
\nQuesto 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\u00f9 comune riguardava l'intersezione degli intervalli di indirizzi IP.<\/p>\n

\"Come
\n<\/p>\n

Virtual Private Cloud<\/h3>\n

\nIl cloud si \u00e8 rivelato richiesto. \u00c8 tempo di riflettere sulla scalabilit\u00e0 e sulla possibilit\u00e0 di utilizzo da parte di decine di milioni di tenant. La rete piatta \u00e8 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.<\/p>\n

\"Come
\n
\nCosa ti viene in mente quando pensi all'isolamento della rete? Certamente VLAN<\/b> e VRF \u2013 Virtual Routing and Forwarding<\/b>.<\/p>\n

Sfortunatamente, questo non ha funzionato. L'ID VLAN \u00e8 di soli 12 bit, il che ci d\u00e0 solo 4096 segmenti isolati. Anche nei commutatori pi\u00f9 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 \u00e8 assolutamente sufficiente per decine di milioni di tenant, ciascuno dei quali deve avere la possibilit\u00e0 di utilizzare pi\u00f9 sottoreti.<\/p>\n

Inoltre, semplicemente non possiamo permetterci di acquistare il numero richiesto di grandi unit\u00e0, ad esempio da Cisco o Juniper. Ci sono due motivi: \u00e8 estremamente costoso e non vogliamo dipendere dalla loro politica di sviluppo e di patch.<\/p>\n

L'unica conclusione \u00e8: dobbiamo creare la nostra soluzione.<\/p><\/blockquote>\n

\nNel 2009 abbiamo annunciato VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Il nome \u00e8 adottato e ora molti fornitori di cloud lo usano.<\/p>\n

VPC \u00e8 una rete virtuale SDN<\/b> (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.<\/p>\n

\"Come
\n
\nSembra semplice. Tuttavia, \u00e8 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 \u00e8 gestito dal servizio di mappatura<\/b>, che \u00e8 distribuito uniformemente su tutta la rete.<\/p>\n

Nelle macchine di nuova generazione, l'incapsulamento viene eseguito dalle schede Nitro a livello hardware. Negli istanti pi\u00f9 vecchi, l'incapsulamento e la decapsulazione sono a livello software.\u00a0<\/p>\n

\"Come
\n
\nEsaminiamo 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\u00e0, consideriamo che entrambe le macchine virtuali si trovino nello stesso VPC \"blu\".<\/p>\n

\"Come
\n
\nLa scheda sostituisce l'indirizzo sorgente con il proprio e inoltra il frame ARP al servizio di mappatura.<\/p>\n

\"Come
\n
\nIl servizio di mappatura restituisce le informazioni necessarie per la trasmissione sulla rete fisica L2.<\/p>\n

\"Come
\n
\nLa scheda Nitro nell'ARP di risposta sostituisce il MAC nella rete fisica con l'indirizzo nel VPC.<\/p>\n

\"Come
\n
\nQuando trasferiamo dati, incapsuliamo i MAC logici e gli IP in un involucro VPC. Tutto ci\u00f2 viene trasmesso sulla rete fisica utilizzando le relative schede IP Nitro di origine e destinazione.<\/p>\n

\"Come
\n
\nLa macchina fisica a cui \u00e8 destinato il pacchetto esegue un controllo. Questo \u00e8 necessario per prevenire la possibilit\u00e0 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'. \u00c8 legittimo?\"\u00a0<\/p>\n

\"Come
\n
\nIl 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 \u00e8 integrata nelle schede Nitro. Non \u00e8 possibile bypassarla nemmeno in teoria. Pertanto, lo spoofing delle risorse in un altro VPC non funzioner\u00e0.<\/p>\n

\"Come
\n
\nSuccessivamente, i dati vengono inviati alla macchina virtuale per cui sono destinati.\u00a0<\/p>\n

\"Come
\n
\nIl servizio di mappatura funziona anche come router logico per la trasmissione di dati tra macchine virtuali in diverse sottoreti. Qui tutto \u00e8 concettualmente semplice, non scender\u00f2 nei dettagli.<\/p>\n

\"Come
\n
\nDunque, quando viene trasferito ogni pacchetto, i server si rivolgono al servizio di mappatura. Come affrontare inevitabili ritardi? Con la memorizzazione nella cache.<\/b>, naturalmente.<\/p>\n

La bellezza \u00e8 che non \u00e8 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 \u00e8 comunque legittima. Se viene utilizzata funzionalit\u00e0 come VPC-peering, allora il cache viene ulteriormente popolato con informazioni sui VPC corrispondenti.\u00a0<\/p>\n

\"Come
\n
\nAbbiamo chiarito la trasmissione dei dati in VPC.<\/p>\n

Blackfoot<\/h3>\n

\nCosa 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<\/b> \u2014 un servizio interno AWS. \u00c8 stato sviluppato dal nostro team sudafricano. Pertanto, il servizio prende il nome da un pinguino che vive in Sudafrica.<\/p>\n

\"Come
\n
\nBlackfoot de-incapsula il traffico e lo gestisce secondo necessit\u00e0. I dati in Internet vengono inviati cos\u00ec come sono.<\/p>\n

\"Come
\n
\nI dati vengono de-incapsulati e ri-incapsulati in un involucro IPsec quando si utilizza VPN.<\/p>\n

\"Come
\n
\nQuando si utilizza Direct Connect, il traffico viene etichettato e inviato nel corrispondente VLAN.<\/p>\n

\"Come
\n<\/p>\n

HyperPlane<\/h3>\n

\nQuesto \u00e8 un servizio interno di controllo del flusso. Molti servizi di rete richiedono il controllo dello stato del flusso di dati<\/b>. 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<\/b> \u2014 Network Load Balancer<\/b>, il flusso di dati deve sempre essere diretto alla stessa macchina virtuale di destinazione. Security Groups \u00e8 un firewall stateful. Tiene traccia del traffico in entrata e apre implicitamente porte per il flusso di pacchetti in uscita.<\/p>\n

\"Come
\n
\nNel cloud AWS, i requisiti di latenza sono estremamente elevati. Pertanto HyperPlane<\/b> \u00e8 critico per il funzionamento dell'intera rete.<\/p>\n

\"Come
\n
\nHyperplane \u00e8 costruito su macchine virtuali EC2. Non c'\u00e8 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\u00f2 consente di ottenere latenze nell'ordine di decine di microsecondi. Lavorare con il disco comprometterebbe completamente le prestazioni.\u00a0<\/p>\n

Hyperplane \u00e8 un sistema distribuito composto da un enorme numero di tali macchine EC2. Ogni macchina virtuale ha una capacit\u00e0 di 5 GB\/s. Su scala dell'intera rete regionale, ci\u00f2 fornisce una quantit\u00e0 incredibile di terabits di larghezza di banda e consente di gestire milioni di connessioni al secondo<\/b>.<\/p>\n

HyperPlane funziona solo con flussi. L'incapsulamento dei pacchetti VPC \u00e8 completamente trasparente per esso. Una potenziale vulnerabilit\u00e0 in questo servizio interno non consentirebbe comunque di rompere l'isolamento VPC. La sicurezza \u00e8 garantita dai livelli inferiori.<\/p>\n

Noisy neighbor<\/h3>\n

\nC'\u00e8 anche un problema del vicino rumoroso<\/b> \u2014 noisy neighbor<\/b>. 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 \u00e8 difficile sovraccaricarli.<\/p>\n

Ma costruiamo la nostra architettura tenendo conto anche di scenari improbabili.\u00a0<\/p>\n

Una bassa probabilit\u00e0 non significa impossibilit\u00e0.<\/p><\/blockquote>\n

\nPossiamo immaginare una situazione in cui uno o pi\u00f9 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.<\/p>\n

\"Come
\n
\nCome risolvere il problema del vicino rumoroso? La prima cosa che viene in mente \u00e8 lo sharding. I nostri 8 nodi vengono logicamente suddivisi in 4 shard con 2 nodi ciascuno. Ora il vicino rumoroso disturber\u00e0 solo un quarto di tutti gli utenti, ma in modo significativo.<\/p>\n

\"Come
\n
\nFacciamo diversamente. Assegniamo a ciascun utente solo 3 nodi.\u00a0<\/p>\n

\"Come
\n
\nIl trucco \u00e8 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.<\/p>\n

\"Come
\n
\nCon 8 nodi e 3 utenti, la probabilit\u00e0 che il vicino rumoroso si sovrapponga a uno degli utenti \u00e8 del 54%. Cos\u00ec il'utente blu influenzer\u00e0 gli altri tenant con quella probabilit\u00e0, e solo con una parte del suo carico. Nel nostro esempio, questo impatto sar\u00e0 percepito da un terzo degli utenti, e non da tutti. Questo \u00e8 gi\u00e0 un buon risultato.<\/p>\n

Numero di utenti che si sovrapporranno<\/p>\n

Probabilit\u00e0 in percentuale<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

Avviciniamo la situazione alla realt\u00e0 - prendiamo 100 nodi e 5 utenti che utilizzano 5 nodi. In questo caso, nessuno dei nodi si sovrapporr\u00e0 con una probabilit\u00e0 del 77%.\u00a0<\/p>\n

Numero di utenti che si sovrapporranno<\/p>\n

Probabilit\u00e0 in percentuale<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

Nella situazione reale, data l'enorme quantit\u00e0 di nodi HyperPlane e utenti, l'impatto potenziale del vicino rumoroso sugli altri utenti \u00e8 minimo. Questo metodo \u00e8 chiamato sharding mescolato<\/b> \u2014 shuffle sharding<\/b>. Minimizza l'effetto negativo dell'uscita dei nodi dalla rete.<\/p>\n

Su HyperPlane sono costruiti numerosi servizi: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Le dimensioni della rete<\/h3>\n

\nOra parliamo delle dimensioni della rete stessa. A ottobre 2019, AWS offre i suoi servizi in 22 regioni<\/b>, e sono pianificate altre 9.<\/p>\n