{"id":39302,"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-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"Come AWS crea i suoi servizi elastici. Scalabilit\u00e0 dei server e dei database.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le nuvole sono simili a una scatola magica: chiedi ci\u00f2 di cui hai bisogno e le risorse compaiono dal nulla. Macchine virtuali, database, rete: tutto ci\u00f2 appartiene solo a te. Ci sono anche altri tenant nel cloud, ma nel tuo universo sei il solo sovrano. Sei sicuro di ricevere sempre le risorse richieste, senza dover renderne conto a nessuno e decidi autonomamente come sar\u00e0 la rete. Come funziona questa magia che consente al cloud di allocare risorse in modo elastico e di isolare completamente i tenant dagli altri?<\/p>\n

\"Come
\n
\nIl cloud AWS \u00e8 un sistema super complesso che si \u00e8 evoluto dal 2006. Parte di questo sviluppo ha visto Vasili Pantuichin<\/strong> \u2014 architetto di Amazon Web Services. In qualit\u00e0 di architetto, ha una visione interna non solo del risultato finale, ma anche delle sfide affrontate da AWS. Maggiore \u00e8 la comprensione del funzionamento del sistema, maggiore \u00e8 la fiducia. Pertanto, Vasiliy condivider\u00e0 i segreti dei servizi cloud di AWS. Scoprite la struttura dei server fisici AWS, la scalabilit\u00e0 elastica del database, il database personalizzato di Amazon e i metodi per migliorare le prestazioni delle macchine virtuali riducendo al contempo i costi. La conoscenza degli approcci architettonici di Amazon aiuter\u00e0 a utilizzare pi\u00f9 efficacemente i servizi AWS e potrebbe dare nuove idee per costruire soluzioni proprie.
\n<\/a><\/noindex>
\nSul relatore: Vasiliy Pantyukhin (Hen<\/a><\/noindex>) ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni con grandi macchine Sun Microsystems e per 11 anni ha predicato la centralit\u00e0 dei dati in EMC. \u00c8 evoluto naturalmente verso i cloud privati e nel 2017 \u00e8 passato ai pubblici. Attualmente offre consigli tecnici per vivere e svilupparsi nel cloud AWS.<\/p>\n

Disclaimer: tutto ci\u00f2 che segue \u00e8 l'opinione personale di Vasiliy e potrebbe non corrispondere alla posizione di Amazon Web Services. La registrazione video<\/a><\/noindex> della presentazione da cui \u00e8 stato creato l'articolo \u00e8 disponibile sul nostro canale YouTube.<\/i><\/p>\n

Perch\u00e9 parlo del dispositivo Amazon<\/h2>\n

\nLa mia prima automobile aveva il cambio manuale. Era fantastico per via della sensazione di poter controllare completamente l'auto. Mi piaceva anche l'idea di capire bene il suo funzionamento. Naturalmente, avevo una concezione piuttosto primitiva della trasmissione, pi\u00f9 o meno come quella di una bicicletta.<\/p>\n

\"Come
\n
\nTutto andava bene, tranne una cosa: stare nel traffico. \u00c8 come se stessi seduto e non facessi nulla, ma continui a cambiare marcia, ad azionare la frizione, a accelerare e frenare \u2014 ti stanchi davvero. Il problema del traffico si \u00e8 parzialmente risolto quando in famiglia \u00e8 arrivata un'auto automatica. Alla guida, ho avuto tempo per riflettere su alcune cose e ascoltare un audiolibro.<\/p>\n

\u00c8 comparsa anche un'enigma nella mia vita, perch\u00e9 ho smesso di capire come funziona la mia auto. Un'auto moderna \u00e8 un dispositivo complesso. Si adatta simultaneamente a decine di parametri diversi: accelerazione, frenata, stile di guida, qualit\u00e0 della strada. Non capisco pi\u00f9 come funzioni.<\/p>\n

Quando ho iniziato a lavorare con Amazon Cloud, anche per me era un mistero. Solo che questo mistero \u00e8 su un altro livello, perch\u00e9 in un veicolo c'\u00e8 un solo guidatore, mentre in AWS ce ne sono milioni. Tutti gli utenti sterzano, accelerano e frenano contemporaneamente. \u00c8 sorprendente che riescano ad andare dove vogliono \u2014 per me \u00e8 un miracolo! Il sistema si adatta automaticamente, si scalda e si adatta in modo elastico per ogni utente, tanto che sembra che sia l'unico in quest'universo.<\/p>\n

La magia \u00e8 svanita un po' quando ho iniziato a lavorare come architetto in Amazon. Ho visto quali problemi affrontiamo, come li risolviamo e come sviluppiamo i servizi. Con una maggiore comprensione del funzionamento del sistema, aumenta la fiducia nel servizio. Perci\u00f2 voglio condividere un quadro di ci\u00f2 che c'\u00e8 dietro le quinte del cloud AWS.<\/p>\n

Di cosa parleremo<\/h2>\n

\nHo scelto un approccio diversificato \u2014 ho selezionato 4 servizi interessanti di cui vale la pena parlare.<\/p>\n

Ottimizzazione dei server<\/strong>. Nuvole effimere con incarnazione fisica: data center fisici, dove ci sono server fisici che ronzano, si riscaldano e lampeggiano.<\/p>\n

Funzioni serverless <\/strong>(Lambda) \u2014 probabilmente il servizio pi\u00f9 scalabile nel cloud.<\/p>\n

Scalabilit\u00e0 del database<\/strong>. Vi parler\u00f2 di come costruiamo i nostri database scalabili.<\/p>\n

Scalabilit\u00e0 della rete<\/strong>. Nella parte finale, sveler\u00f2 la struttura della nostra rete. \u00c8 una meraviglia: ogni utente del cloud si sente come se fosse solo nel cloud e non vede affatto gli altri tenant.<\/p>\n

Nota. In questo articolo si parler\u00e0 di ottimizzazione dei server e scalabilit\u00e0 dei database. La scalabilit\u00e0 della rete verr\u00e0 trattata nel prossimo articolo. E le funzioni serverless? Su di esse \u00e8 stata pubblicata una trascrizione separata \u00abPiccolo ma potente. Unboxing della microvirtualizzazione Firecracker<\/a><\/noindex>\u00bb. In essa sono descritti diversi modi di scalare e viene analizzata in dettaglio la soluzione Firecracker, un'autentica fusione delle migliori caratteristiche delle macchine virtuali e dei container.<\/i><\/p><\/blockquote>\n

<\/p>\n

Server<\/h2>\n

\nIl cloud \u00e8 effimero. Tuttavia, questa effimera qualit\u00e0 ha comunque una rappresentazione fisica: i server. Inizialmente, la loro architettura era classica. Un chipset standard x86, schede di rete, Linux, un hypervisor Xen, su cui venivano eseguite le macchine virtuali.<\/p>\n

\"Come
\n
\nNel 2012, tale architettura gestiva perfettamente i propri compiti. Xen \u00e8 un ottimo hypervisor, ma presenta un grave svantaggio. Ha una abbastanza elevati costi di emulazione dei dispositivi<\/strong>. Con l'arrivo di nuove schede di rete pi\u00f9 veloci o dischi SSD, questi costi diventano troppo elevati. Come affrontare questo problema? Abbiamo deciso di lavorare su due fronti contemporaneamente \u2014 ottimizzare sia l'hardware che l'ipervisor<\/strong>. Il compito \u00e8 molto serio.<\/p>\n

Ottimizzazione dell'hardware e dell'ipervisor<\/h3>\n

\nNon sar\u00e0 possibile fare tutto bene subito. Cosa significhi \"bene\" non era chiaro fin dall'inizio.<\/p>\n

Abbiamo deciso di adottare un approccio evolutivo \u2014 cambiamo un elemento importante dell'architettura e lo lanciamo in produzione.<\/p><\/blockquote>\n

Affrontiamo tutte le sfide, ascoltiamo lamentele e suggerimenti. Poi modifichiamo un altro componente. Cos\u00ec, con piccoli incrementi, cambiamo radicalmente l'intera architettura basandoci sul feedback degli utenti e del supporto.<\/p>\n

Le trasformazioni sono iniziate nel 2013 con la parte pi\u00f9 complessa \u2014 la rete. In C3<\/strong> negli istanze, abbiamo aggiunto alla scheda di rete standard una scheda speciale chiamata Network Accelerator. Veniva collegata letteralmente con un breve cavo loopback nella parte anteriore. Non esteticamente gradevole, ma nel cloud non \u00e8 visibile. Tuttavia, l'interazione diretta con l'hardware ha migliorato drasticamente jitter e larghezza di banda della rete.<\/p>\n

Abbiamo deciso di migliorare l'accesso all'archiviazione a blocchi EBS \u2014 Elastic Block Storage. Questa \u00e8 una combinazione di rete e archiviazione. La difficolt\u00e0 era che, sebbene esistessero schede Network Accelerator sul mercato, non c'era la possibilit\u00e0 di acquistare hardware Storage Accelerator. Quindi, ci siamo rivolti a una startup Annapurna Labs<\/strong>, che ha sviluppato per noi chip ASIC speciali. Questi ci hanno permesso di collegare i volumi EBS remoti come dispositivi NVMe.<\/p>\n

Negli istanze C4<\/strong> abbiamo risolto due problemi. Il primo \u2014 abbiamo realizzato una base per il futuro utilizzando la promettente, ma allora nuova, tecnologia NVMe. Il secondo \u2014 abbiamo notevolmente alleggerito il processore centrale spostando l'elaborazione delle richieste verso EBS su una nuova scheda. \u00c8 andato bene, quindi ora Annapurna Labs \u00e8 parte di Amazon.<\/p>\n

Entro novembre 2017, abbiamo capito che era tempo di cambiare anche l'hypervisor stesso.<\/p>\n

Il nuovo hypervisor \u00e8 stato sviluppato sulla base di moduli core KVM migliorati.<\/p><\/blockquote>\n

Questo ha consentito di ridurre drasticamente l'overhead di emulazione dei dispositivi e di lavorare direttamente con i nuovi ASIC. Le istanze C5<\/strong> sono state le prime virtual machines a avere sotto il cofano il nuovo hypervisor. Lo abbiamo chiamato Nitro<\/strong>.<\/p>\n

\"ComeL'evoluzione delle istanze sulla linea temporale.<\/em><\/p>\n

Tutti i nuovi tipi di macchine virtuali emersi da novembre 2017 operano su questo hypervisor. Le istanze Bare Metal non hanno un hypervisor<\/strong>, ma vengono comunque chiamate Nitro, poich\u00e9 utilizzano schede Nitro specializzate.<\/p>\n

Nei due anni successivi, il numero di tipologie di istanze Nitro ha superato diverse decine: A1, C5, M5, T3 e altre.<\/p>\n

\"Come
\nTipi di istanze.<\/em><\/p>\n

Come sono strutturate le moderne macchine Nitro<\/h3>\n

\nEsse hanno tre componenti principali: l'hypervisor Nitro (di cui si \u00e8 parlato prima), un chip di sicurezza e le schede Nitro.<\/p>\n

Chip di sicurezza<\/strong> \u00e8 integrato direttamente nella scheda madre. Controlla molte funzioni importanti, come il controllo dell'avvio del sistema operativo host.<\/p>\n

Schede Nitro<\/strong> \u2014 esistono quattro tipi. Tutte sono sviluppate da Annapurna Labs e si basano su ASIC comuni. Parte del loro firmware \u00e8 anch'esso comune.<\/p>\n

\"Come
\nQuattro tipi di schede Nitro.<\/em><\/p>\n

Una delle schede \u00e8 progettata per lavorare con la rete<\/strong>VPC<\/strong>. Essa \u00e8 visibile nelle macchine virtuali come scheda di rete ENA \u2014 Elastic Network Adaptor<\/strong>. Inoltre, incapsula il traffico quando viene inviato attraverso la rete fisica (di questo parleremo nella seconda parte dell'articolo), controlla il firewall Security Groups, gestisce il routing e altre questioni di rete.<\/p>\n

Le schede separate funzionano con lo storage a blocchi EBS<\/strong> e i dischi integrati nel server. Per la macchina virtuale, vengono presentati come adattatori NVMe<\/strong>. Sono responsabili anche della crittografia dei dati e del monitoraggio dei dischi.<\/p>\n

Il sistema delle schede Nitro, dell'hypervisor e del chip di sicurezza \u00e8 connesso a una rete SDN o Software Defined Network<\/strong>. La gestione di questa rete (Control Plane) \u00e8 affidata a una scheda controller<\/strong>.<\/p>\n

Naturalmente, continuiamo a sviluppare nuovi ASIC. Ad esempio, alla fine del 2018 abbiamo lanciato il chip Inferentia, che consente di lavorare in modo pi\u00f9 efficiente con i compiti di machine learning.<\/p>\n

\"Come
\nChip Inferentia Machine Learning Processor.<\/em><\/p>\n

Database scalabile<\/h2>\n

\nUn database tradizionale ha una struttura a strati. Se semplifichiamo molto, possiamo individuare i seguenti livelli.<\/p>\n