{"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 'prepara' 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 magica scatola: chiedi ci\u00f2 di cui hai bisogno e le risorse appaiono dal nulla. Macchine virtuali, database, rete: tutto appartiene solo a te. Esistono anche altri tenant nel cloud, ma nel tuo universo sei l'unico sovrano. Sei sicuro di ricevere sempre le risorse necessarie, senza dover rendere conto a nessuno, e decidi autonomamente come sar\u00e0 la rete. Come funziona questa magia che fa s\u00ec che il cloud assegni risorse in modo elastico e isoli completamente i tenant tra di loro?<\/p>\n

\"Come
\n
\nIl cloud AWS \u00e8 un sistema estremamente complesso che si \u00e8 evoluto dal 2006. Parte di questa evoluzione ha visto Vasily Pantyukhin<\/strong> \u2014 l'architetto Amazon Web Services. Come architetto, vede non solo il risultato finale, ma anche le complessit\u00e0 che AWS affronta. Pi\u00f9 comprendi il funzionamento del sistema, maggiore \u00e8 la fiducia. Perci\u00f2, Vasily condivider\u00e0 i segreti dei servizi cloud AWS. Sotto il titolo, la struttura dei server fisici di AWS, la scalabilit\u00e0 elastica dei database, il database personalizzato di Amazon e i metodi per migliorare le prestazioni delle macchine virtuali, riducendo nel contempo i costi. Conoscere gli approcci architettonici di Amazon aiuter\u00e0 a utilizzare in modo pi\u00f9 efficace i servizi AWS e, forse, fornir\u00e0 nuove idee per costruire soluzioni proprie.
\n<\/a><\/noindex>
\nChi \u00e8 il relatore: Vasily Pantyukhin (Hen<\/a><\/noindex>) ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni su grandi server Sun Microsystem, e per 11 anni ha predicato la centralit\u00e0 dei dati nel mondo in EMC. Si \u00e8 evoluto naturalmente verso i cloud privati e nel 2017 si \u00e8 lanciato nei cloud pubblici. Ora offre consigli tecnici per vivere e prosperare nel cloud AWS.<\/p>\n

Dichiarazione: tutto ci\u00f2 che segue \u00e8 l'opinione personale di Vasily e potrebbe non coincidere con la posizione di Amazon Web Services. La registrazione video<\/a><\/noindex> del discorso, sulla base del quale \u00e8 stato redatto l'articolo, \u00e8 disponibile sul nostro canale YouTube.<\/i><\/p>\n

Perch\u00e9 parlo della struttura di Amazon<\/h2>\n

\nLa mia prima auto era con il 'cambio manuale' \u2014 con cambio meccanico. Era fantastico per la sensazione di poter controllare l'auto e averne il controllo totale. Mi piaceva anche che avessi almeno una comprensione approssimativa del suo funzionamento. Naturalmente, immaginavo la struttura della trasmissione in modo piuttosto primitivo \u2014 pi\u00f9 o meno come un cambio di una bicicletta.<\/p>\n

\"Come
\n
\nTutto \u00e8 stato meraviglioso, tranne un aspetto: stare bloccato nel traffico. Sembra che tu stia seduto e non faccia nulla, ma continui a cambiare marcia, premere la frizione, l'acceleratore, il freno \u2014 e tutto ci\u00f2 ti stanca davvero. Il problema del traffico si \u00e8 parzialmente risolto quando in famiglia \u00e8 arrivata un'auto con cambio automatico. Alla guida ho avuto il tempo di pensare a qualcosa, di ascoltare un audiolibro.<\/p>\n

Inoltre, nella mia vita \u00e8 apparso un mistero, perch\u00e9 ho smesso di capire come funziona la mia auto. Un'auto moderna \u00e8 un dispositivo complesso. Si adatta contemporaneamente a decine di parametri diversi: pressione sull'acceleratore, freno, stile di guida, qualit\u00e0 della strada. Non capisco pi\u00f9 come funziona.<\/p>\n

Quando ho iniziato a lavorare con Amazon Cloud, anche per me era un mistero. Solo che questo mistero \u00e8 a un livello superiore, perch\u00e9 nell'auto c'\u00e8 un solo conducente, mentre in AWS ce ne sono milioni. Tutti gli utenti guidano contemporaneamente, premendo l'acceleratore e il freno. \u00c8 sorprendente che riescano ad andare dove vogliono \u2014 per me \u00e8 un miracolo! Il sistema si adatta automaticamente, si scalda ed \u00e8 elasticamente configurato per ogni utente, al punto che sembra che sia l'unico in questo universo.<\/p>\n

La magia \u00e8 svanita un po' quando poi sono venuto a lavorare come architetto in Amazon. Ho visto quali problemi affrontiamo, come li risolviamo, come sviluppiamo i servizi. Con la crescita della comprensione del funzionamento del sistema, aumenta la fiducia nel servizio. Perci\u00f2 voglio condividere l'immagine di ci\u00f2 che c'\u00e8 sotto il cofano del cloud AWS.<\/p>\n

Di cosa parleremo<\/h2>\n

\nHo scelto un approccio diversificato: 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 si trovano server fisici che ronzano, si scaldano e lampeggiano.<\/p>\n

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

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

Scalabilit\u00e0 della rete<\/strong>. Ultima parte, in cui sveler\u00f2 l'architettura della nostra rete. \u00c8 una cosa meravigliosa \u2014 ogni utente del cloud sente di essere l'unico nel cloud e non vede affatto gli altri tenant.<\/p>\n

Nota. In questo articolo si parler\u00e0 dell'ottimizzazione dei server e della scalabilit\u00e0 dei database. La scalabilit\u00e0 della rete verr\u00e0 trattata nel prossimo articolo. Dove sono le funzioni serverless? Ne \u00e8 stata pubblicata una spiegazione separata \u00abPiccolo ma potente. Unboxing della micro-virtualizzazione Firecracker<\/a><\/noindex>\u00bb. In essa vengono discussi diversi metodi di scalabilit\u00e0, e viene analizzata in dettaglio la soluzione Firecracker, un connubio delle migliori qualit\u00e0 delle macchine virtuali e dei container.<\/i><\/p><\/blockquote>\n

<\/p>\n

Server<\/h2>\n

\nIl cloud \u00e8 effimero. Ma questa effimereit\u00e0 ha pur sempre una rappresentazione fisica: i server. Inizialmente la loro architettura era classica. Chipset x86 standard, schede di rete, Linux, 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 ha un serio svantaggio. Ha costi di overhead piuttosto elevati per l'emulazione dei dispositivi<\/strong>. Con l'emergere di nuove schede di rete pi\u00f9 veloci o di dischi SSD, questi overhead diventano troppo elevati. Come affrontare questo problema? Abbiamo deciso di lavorare su due fronti: ottimizzare sia l'hardware che l'hypervisor<\/strong>. \u00c8 un compito molto serio.<\/p>\n

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

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

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

Incontriamo tutte le difficolt\u00e0, ascoltiamo reclami e suggerimenti. Poi modifichiamo un altro componente. Cos\u00ec, con piccoli incrementi, cambiamo radicalmente tutta l'architettura sulla base del feedback da parte degli utenti e del supporto.<\/p>\n

Le trasformazioni sono iniziate nel 2013 con la parte pi\u00f9 complessa: la rete. In C3<\/strong> gli istanze, \u00e8 stata aggiunta una scheda speciale Network Accelerator accanto alla scheda di rete standard. Essa si collegava letteralmente con un cavo di loopback corto sulla parte anteriore. Brutto da vedere, ma nel cloud non si nota. Tuttavia, l'interazione diretta con l'hardware ha migliorato in modo sostanziale il jitter e la capacit\u00e0 di rete.<\/p>\n

Successivamente, abbiamo deciso di migliorare l'accesso allo storage a blocchi EBS - Elastic Block Storage. Questa \u00e8 una combinazione di rete e storage. La difficolt\u00e0 \u00e8 che se sul mercato esistevano schede Network Accelerator, non c'era la possibilit\u00e0 di acquistare hardware Storage Accelerator. Pertanto, ci siamo rivolti alla startup Annapurna Labs<\/strong>, che ha sviluppato chip ASIC speciali per noi. Questi hanno permesso di collegare volumi EBS remoti come dispositivi NVMe.<\/p>\n

Negli istanze C4<\/strong> abbiamo risolto due problemi. Il primo \u00e8 stato quello di realizzare un futuro promettente, ma nuovo all'epoca, con la tecnologia NVMe. Il secondo \u00e8 stato quello di alleggerire significativamente il processore centrale spostando l'elaborazione delle richieste a EBS su una nuova scheda. \u00c8 andata bene, quindi ora Annapurna Labs \u00e8 parte di Amazon.<\/p>\n

Entro novembre 2017, abbiamo capito che era giunto il momento di cambiare anche l'ipercloud.<\/p>\n

Il nuovo ipervisor \u00e8 stato sviluppato sulla base di moduli migliorati del kernel KVM.<\/p><\/blockquote>\n

Ha permesso di ridurre significativamente le spese generali per l'emulazione dei dispositivi e di lavorare direttamente con i nuovi ASIC. Le istanze C5<\/strong> sono state le prime virtual machine sotto il cofano delle quali opera il nuovo ipervisor. Lo abbiamo chiamato Nitro<\/strong>.<\/p>\n

\"ComeEvoluzione delle istanze su una linea temporale.<\/em><\/p>\n

Tutti i nuovi tipi di macchine virtuali introdotti da novembre 2017 funzionano su questo ipervisor. Le istanze Bare Metal non hanno un ipervisor<\/strong>, ma vengono anch'esse chiamate Nitro, poich\u00e9 utilizzano schede Nitro specializzate.<\/p>\n

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

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

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

\nHanno tre componenti principali: l'ipercloud Nitro (di cui si \u00e8 gi\u00e0 parlato), il chip di sicurezza e le schede Nitro.<\/p>\n

Il chip di sicurezza<\/strong> \u00e8 integrato direttamente nella scheda madre. Controlla molte funzioni importanti, come il controllo di avvio del SO host.<\/p>\n

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

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

Una delle schede \u00e8 destinata a lavorare con la rete<\/strong>VPC<\/strong>. Questa \u00e8 visibile nelle virtual machine come scheda di rete ENA \u2014 Elastic Network Adaptor<\/strong>. Inoltre incapsula il traffico quando viene trasferito attraverso la rete fisica (di questo parleremo nella seconda parte dell'articolo), controlla il firewall delle Security Groups, si occupa del routing e di altre cose di rete.<\/p>\n

Schede separate lavorano con lo storage a blocchi EBS<\/strong> e con i dischi integrati nel server. Per la virtual machine guest, vengono presentati come adattatori NVMe<\/strong>. Inoltre si occupano della crittografia dei dati e del monitoraggio dei dischi.<\/p>\n

Il sistema delle schede Nitro, dell'ipercloud e del chip di sicurezza \u00e8 integrato in una rete SDN o Software Defined Network<\/strong>. Il controllo di questa rete (Control Plane) \u00e8 gestito da controller della mappa<\/strong>.<\/p>\n

Certo, stiamo continuando a sviluppare nuovi ASIC. Ad esempio, alla fine del 2018 abbiamo rilasciato il chip Inferentia, che consente di lavorare in modo pi\u00f9 efficiente su compiti di apprendimento automatico.<\/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