{"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, distribuite in 22 regioni: Stati Uniti, Europa, Asia, Africa e Australia. Ogni zona pu\u00f2 ospitare fino a 8 Data Center (DC). In ciascun DC ci sono migliaia o centinaia di migliaia di server. La rete \u00e8 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\u00e0 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\u00e0 di pacchetti. Vasili Pantuichin parler\u00e0 di quali altri principi fondamentali guidano la rete e come \u00e8 strutturata.<\/p>\n

\"Come
\n
\nVasili Pantuichin<\/b> 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. \u00c8 evoluto naturalmente verso i cloud privati, poi si \u00e8 orientato verso quelli pubblici. Attualmente, come architetto di Amazon Web Services, offre consigli tecnici per aiutare a vivere e prosperare nel cloud AWS.<\/p>\n

Nella parte precedente della trilogia sull'architettura AWS, Vasiliy ha approfondito l'architettura dei server fisici e la scalabilit\u00e0 del database. Schede Nitro, hypervisor personalizzato basato su KVM, database Amazon Aurora: tutti questi temi sono trattati nell'articolo \"Come AWS crea i suoi servizi elastici. Scalabilit\u00e0 dei server e dei database.<\/a><\/noindex>Leggi per approfondire il contesto oppure guarda il video<\/a><\/noindex> della presentazione.<\/p>\n

In questa parte parleremo 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 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.<\/p>\n

Disclaimer: tutto ci\u00f2 che segue \u00e8 l'opinione personale di Vasiliy e potrebbe non coincidere con quella 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 a tutti i tenant del cloud. Quando avviavi una nuova macchina virtuale, ricevevi casualmente un indirizzo IP disponibile da questo intervallo.<\/p>\n

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

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

Virtual Private Cloud<\/h3>\n

\nIl cloud si \u00e8 dimostrato richiesto. \u00c8 giunto il momento di riflettere sulla scalabilit\u00e0 e sulla possibilit\u00e0 di utilizzo da parte di decine di milioni di tenant. Una rete piatta \u00e8 diventata il principale ostacolo. Perci\u00f2 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.<\/p>\n

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

Purtroppo, non ha funzionato. L'ID VLAN \u00e8 di soli 12 bit, il che ci consente di avere solo 4096 segmenti isolati. Anche nei pi\u00f9 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 \u00e8 affatto sufficiente per decine di milioni di tenant, ognuno dei quali deve poter usare pi\u00f9 sottoreti.<\/p>\n

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

La conclusione \u00e8 una: dobbiamo sviluppare la nostra soluzione.<\/p><\/blockquote>\n

\nNel 2009 abbiamo annunciato VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Il nome ha preso piede ed ora lo utilizzano anche molti fornitori di cloud.<\/p>\n

Il VPC \u00e8 una rete virtuale SDN<\/b> (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 \u00e8 racchiuso in un pacchetto del nostro protocollo. In esso \u00e8 indicato l'ID appartenente al tenant del VPC.<\/p>\n

\"Come
\n
\nSembra 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 \u00e8 gestito da servizio di mappatura<\/b>, che \u00e8 distribuito diffusamente in tutta la rete.<\/p>\n

Nei macchinari di nuova generazione, l'incapsulamento avviene tramite le schede Nitro a livello hardware. Negli istanze pi\u00f9 vecchie, l'incapsulamento e la decapsulazione sono gestiti a livello software.\u00a0<\/p>\n

\"Come
\n
\nVediamo 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\u00e0, supponiamo 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 nella risposta ARP sostituisce l'indirizzo MAC nella rete fisica con uno dell'VPC.<\/p>\n

\"Come
\n
\nDurante la trasmissione dei dati, incapsuliamo gli indirizzi MAC e IP logici in un'involucro VPC. Tutto ci\u00f2 viene trasmesso attraverso la rete fisica utilizzando le corrispondenti schede IP Nitro di origine e destinazione.<\/p>\n

\"Come
\n
\nLa macchina fisica destinataria del pacchetto effettua un controllo. Questo serve a prevenire la possibilit\u00e0 di spoofing degli indirizzi. La macchina invia una richiesta speciale al servizio di mappatura e chiede: \u00abDalla macchina fisica 192.168.0.3 ho ricevuto un pacchetto destinato a 10.0.0.3 nel VPC 'blu'. \u00c8 legittimo?\u00bb\u00a0<\/p>\n

\"Come
\n
\nIl 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 \u00e8 integrata nelle schede Nitro. Non pu\u00f2 essere aggirata neanche teoricamente. 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 funge anche da router logico per la trasmissione dei dati tra le macchine virtuali in diverse sottoreti. Concettualmente, tutto \u00e8 semplice, non entrer\u00f2 nei dettagli.<\/p>\n

\"Come
\n
\nA quanto pare, quando si trasmette ogni pacchetto, i server si rivolgono al servizio di mapping. Come affrontare i ritardi inevitabili? Caching<\/b>, naturalmente.<\/p>\n

La bellezza sta nel fatto che non \u00e8 necessario memorizzare nella cache l'intera enorme tabella. Su un server fisico risiedono macchine virtuali provenienti da un numero relativamente ridotto di VPC. \u00c8 necessario memorizzare nella cache informazioni solo su questi VPC. La trasmissione dei dati ad altri VPC, nella configurazione \"predefinita\", non \u00e8 comunque legittima. Se viene utilizzata funzionalit\u00e0 come il VPC peering, le informazioni sui VPC corrispondenti vengono aggiunte al cache.\u00a0<\/p>\n

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

Blackfoot<\/h3>\n

\nCosa 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<\/b> \u2014 un servizio interno di 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 decapsula il traffico e fa con esso ci\u00f2 che \u00e8 necessario. I dati su Internet vengono inviati cos\u00ec come sono.<\/p>\n

\"Come
\n
\nI dati vengono decapsulati e riconsolidati in un pacchetto IPsec quando si utilizza la VPN.<\/p>\n

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

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

HyperPlane<\/h3>\n

\nQuesto \u00e8 un servizio interno di controllo del flusso. Molti servizi di rete richiedono un controllo dello stato del flusso di dati<\/b>. 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<\/b> \u2014 Network Load Balancer<\/b>, 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.<\/p>\n

\"Come
\n
\nIn AWS, i requisiti di latenza della trasmissione 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 \u00e8 che queste sono virtual machine con grande RAM. Le operazioni sono transazionali e avvengono esclusivamente in memoria. Ci\u00f2 consente di raggiungere latenze di solo decine di microsecondi. Lavorare con il disco comprometterebbe le prestazioni.\u00a0<\/p>\n

Hyperplane \u00e8 un sistema distribuito composto da un grande numero di macchine EC2. Ogni virtual machine ha una capacit\u00e0 di throughput di 5 GB\/s. Su scala dell'intera rete regionale, questo fornisce una straordinaria capacit\u00e0 di terabyte e permette di elaborare milioni di connessioni al secondo<\/b>.<\/p>\n

HyperPlane funziona esclusivamente con flussi. La VPC incapsula i pacchetti in modo completamente trasparente per essa. Un'eventuale vulnerabilit\u00e0 in questo servizio interno non permetterebbe comunque di violare l'isolamento della VPC. La sicurezza \u00e8 garantita dai livelli sottostanti.<\/p>\n

Vicino rumoroso<\/h3>\n

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

Ma costruiamo la nostra architettura tenendo conto anche di scenari poco probabili.\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. 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.<\/p>\n

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

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

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

\"Come
\n
\nCon 8 nodi e 3 utenti, la probabilit\u00e0 che un vicino rumoroso si sovrapponga a uno degli utenti \u00e8 del 54%. Proprio con questa probabilit\u00e0 l'utente blu influenzer\u00e0 gli altri tenant. Tuttavia, solo una parte del suo carico avr\u00e0 effetto. Nel nostro esempio, questa influenza sar\u00e0 percepita solo da un terzo di tutti gli utenti. \u00c8 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 su 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, con un enorme numero di nodi e utenti HyperPlane, l'impatto potenziale di un vicino rumoroso sugli altri utenti \u00e8 minimo. Questo metodo si chiama sharding casuale<\/b> \u2014 shuffle sharding<\/b>. Minimizza l'effetto negativo dell'uscita dei nodi dal servizio.<\/p>\n

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

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 previsti altri 9.<\/p>\n