Come Linode è passato dall'hardware alle GPU live in sei settimane

Nel 2019, tre diversi dipartimenti hanno fissato l'obiettivo di lanciare nuove istanze Linode GPU per i clienti entro il compleanno di Linode. Tra i team di hardware, marketing e gestione, non eravamo sicuri che fosse possibile, soprattutto per gli altri prodotti su cui stavamo lavorando in quel periodo.

Così abbiamo scelto l'unico team che aveva la possibilità di realizzarlo: un gruppo selezionato di dipendenti desiderosi di lavorare in diversi dipartimenti per formare il Team Mission GPU. Ora, quasi due anni fa e molte istanze di GPU dopo, stiamo facendo un viaggio nella memoria per fornire una visione approfondita di come abbiamo realizzato tutto ciò e trasformato un'idea in un prodotto di successo che stiamo espandendo attivamente.

Breve retroscena sulla storia della virtualizzazione in Linode

Prima di iniziare a parlare di come abbiamo lanciato le istanze GPU , ecco alcuni dettagli tecnici leggeri e la storia di come la virtualizzazione è iniziata in Linode prima di diventare il provider cloud che conoscete oggi.

Linode ha iniziato la sua attività nel 2003 fornendo macchine virtuali con UML (User Mode Linux), un primo paradigma di virtualizzazione simile a Qemu (Quick EMUlator). UML forniva hardware completamente virtualizzato. Quando un cliente accedeva al proprio Linode, i dispositivi che vedeva, come i dischi, la rete, la scheda madre, la RAM e così via, avevano tutti l'aspetto e il comportamento di dispositivi hardware reali, ma i dispositivi erano in realtà supportati da software invece che da hardware reale.

Diversi anni dopo, Linode è passato a XenXen è un hypervisor di tipo 1, ovvero l'hypervisor viene eseguito direttamente sull'hardware, mentre gli ospiti vengono eseguiti sopra il kernel Xen . Il kernel fornisce la paravirtualizzazione ai suoi ospiti, ovvero le interfacce hardware che il Linode vede vengono tradotte in chiamate effettive alla macchina attraverso il kernel e restituite. Il kernel Xen fornisce la paravirtualizzazione ai suoi ospiti, ovvero le interfacce hardware che Linode vede sono tradotte in chiamate alla macchina attraverso il kernel Xen e restituite all'utente. Il motivo per cui esiste questo livello di traduzione è quello di fornire sicurezza e altre caratteristiche di sicurezza in modo che l'istruzione giusta vada al Linode giusto.

Alcuni anni dopo, è stata sviluppata una nuova tecnologia chiamata KVM (Kernel Virtual Machine). KVM consiste in parti del kernel Linux che forniscono interfacce paravirtuali alle istruzioni della CPU. Qemu è una delle tecnologie di virtualizzazione che può trarre vantaggio da KVM. Linode ha deciso di cambiare di nuovo per il beneficio dei nostri clienti. Quando i clienti hanno effettuato l'aggiornamento gratuito a KVM , la maggior parte dei carichi di lavoro ha registrato un aumento immediato delle prestazioni. Questo tipo di paravirtualizzazione è diverso da Xen: le istruzioni della CPU passano dal guest (Qemu) al kernel host e direttamente alla CPU utilizzando le istruzioni a livello di processore, consentendo velocità di esecuzione quasi native. I risultati di queste istruzioni vengono restituiti al Linode che le ha emesse, senza l'overhead richiesto da Xen .

Cosa c'entra tutto questo con le istanze Linode GPU ?

Linode ha condotto una ricerca di mercato e ha cercato di determinare quale sarebbe stato il miglior valore per i clienti interessati a eseguire carichi di lavoro GPU . Abbiamo deciso di fornire le GPU direttamente ai clienti utilizzando una tecnologia chiamata "host passthrough". Indichiamo a Qemu quale dispositivo hardware vogliamo far passare al guest, in questo caso la scheda GPU , e Qemu lavora insieme a Linux per isolare la scheda GPU in modo che nessun altro processo del sistema possa utilizzarla. La macchina Linux ospitante non può usarla, gli altri Linodes sulla macchina non possono usarla. Solo il cliente che l'ha richiesta può usare la scheda GPU e riceve la scheda completa. Il dispositivo hardware vero e proprio viene passato, inalterato e non paravirtualizzato, il che significa che non c'è alcun livello di traduzione.

Settimana 1: L'hardware arriva a Linode

Una volta completata la ricerca, l'intero team ha deciso di portare avanti il progetto. Affinché il piano funzionasse, il sistema richiedeva alcune modifiche all'intero stack di basso livello. L'hardware è stato messo in linea il lunedì e abbiamo avuto cinque giorni per decidere se procedere o meno con un grosso ordine per un datacenter per rispettare la scadenza.

Tutti i partecipanti avevano la stessa idea: se non fossimo stati in grado di farlo funzionare in una normale settimana lavorativa di 40 ore, non saremmo andati avanti. Ciò significa che non c'era alcuna pressione a fare gli straordinari, ma avevamo solo cinque giorni per determinare il futuro di un nuovo prodotto Linode.

Cosa è successo alla fine? È emerso che tutte le nostre ricerche hanno dato i loro frutti. Abbiamo provato a seguire la documentazione esistente e ha funzionato esattamente come previsto. In pochi giorni siamo stati in grado di collegare in modo affidabile le GPU a Linodes in un ambiente di prova. Venerdì eravamo sicuri di poterlo fare. Il test ha avuto successo! Ora era il momento di piazzare un grosso ordine per i clienti e andare avanti.

Settimana 2: Far funzionare il livello di interfaccia hardware con le GPU

Dopo il successo del test iniziale, lunedì siamo tornati in ufficio ricaricati e pronti a integrare il processo di collegamento a GPU con i nostri flussi di lavoro esistenti per la creazione di Linode. Cerchiamo di rendere la nostra interfaccia il più semplice possibile: bastano un paio di clic per distribuire un Linode, e in quelle poche azioni ci sono molte cose di cui dobbiamo tenere conto.

Per rendere possibili le GPU, è stato necessario scrivere e implementare diverse parti a basso livello, come l'isolamento della RAM per GPU e Linode, oltre a fornire a Linode core di CPU dedicati che fossero abbinati alla RAM isolata e a GPU. Abbiamo studiato l'architettura NUMA (Non Uniform Memory Access) della scheda madre e siamo stati in grado di isolare il gruppo NUMA della RAM alla CPU a cui era più strettamente associata e il gruppo NUMA collegato alla corsia PCIe (PCI [Peripheral Computer Interface] express) a cui era collegato GPU . Questo ci ha permesso di avviare un Linode con 1, 2, 3 o 4 GPU collegate e di occupare la parte di RAM e i core della CPU strettamente associati alla scheda GPU in base alla struttura della scheda madre.

Dopo aver completato il livello hardware, abbiamo lavorato sull'interfacciamento con i meccanismi di Linode Job Queuing in modo da poter avviare i Linode attraverso il nostro Cloud Manager e API. A questo punto, abbiamo potuto iniziare a testare l'affidabilità. L'ultima cosa che volevamo era che un ingegnere di turno venisse chiamato nel cuore della notte a causa di un sistema guasto, o che un sistema andasse in tilt nel bel mezzo della giornata lavorativa per un cliente in un fuso orario diverso. Tenendo conto degli orari di sonno dei clienti e degli ingegneri, abbiamo iniziato presto i test e abbiamo continuato a garantire che i clienti avessero un prodotto solido e affidabile.

Settimana 3: Modifiche all'interfaccia dell'amministratore e alla contabilità

Nella terza settimana, avevamo davanti a noi alcune questioni amministrative: come tenere traccia di quali clienti sono assegnati a quali Linode? Come possiamo inviare i clienti a un'istanza Linode con GPU e non a un'istanza Linode senza GPU?

È stato necessario implementare tutte le procedure di monitoraggio e controllo. Abbiamo fatto questo per poter tenere conto di quante carte GPU avevamo, quante erano state prese, quante erano vuote e quante potevamo ancora vendere a nuovi clienti. Abbiamo anche dovuto inserire il monitoraggio di GPU nelle nostre interfacce interne di amministrazione. Potrebbe sembrare un noioso lavoro di contabilità, ma è stata necessaria molta ingegnosità da parte di tutto il team e di membri esterni per interfacciare questo nuovo prodotto con tutti i nostri prodotti esistenti, senza richiedere passaggi manuali.

Fortunatamente, abbiamo riunito tutti e siamo stati in grado di scrivere il codice e di testarlo per assicurarci che funzionasse bene, in modo affidabile e che non richiedesse un intervento manuale per far funzionare un'istanza di Linode GPU . Un altro vantaggio di fare questo lavoro in questa fase è stato che i test sono stati più facili. È stato sufficiente fare clic su un singolo pulsante dell'interfaccia dell'amministratore per attivare un'istanza Linode GPU .

Settimana 4: Rendere pubbliche API Modifiche in modo che i clienti possano avviare i Linode

Dopo aver creato il pulsante dell'interfaccia amministratore per richiamare un'istanza Linode GPU , ci sentivamo abbastanza bene. Ora dovevamo lavorare per esporre questa stessa funzionalità ai clienti. Il sito pubblico API è supportato da Python, il che ha reso il codice estremamente intuitivo. Siamo stati in grado di apportare le modifiche e di testarle molto rapidamente. La parte difficile è stata quella di rendere questa funzionalità disponibile all'interno dell'azienda per i test, ma non disponibile all'esterno fino a quando non avessimo effettuato i test necessari per l'affidabilità.

Settimana 5: Distribuire! Ovvero, come distribuire una funzionalità rivolta al pubblico dietro un flag di funzionalità

Distribuire presto e distribuire spesso.

Stavamo arrivando al dunque, quindi ci siamo posti la domanda: come ci sentiamo a lanciare questo servizio al pubblico e a far sì che i clienti lo utilizzino?

La risposta è stata quella di gestire tutte le incognite fin dall'inizio e di tenerne conto distribuendo presto e spesso. Mentre stavamo ancora testando alcuni dei casi d'uso del team, abbiamo distribuito le istanze Linode GPU al pubblico, ma nascoste dietro un flag di funzionalità. Siamo stati in grado di testare le GPU sugli account dei nostri dipendenti e questo ci ha permesso di assicurarci che le cose si sarebbero comportate esattamente come previsto se un cliente le avesse utilizzate. Ogni volta che abbiamo trovato qualcosa che non ci aspettavamo, abbiamo apportato una correzione e abbiamo reso pubblica la distribuzione.

Lentamente ma inesorabilmente, e distribuendo il codice quasi ogni giorno, abbiamo risolto tutti i problemi del nostro elenco. Abbiamo esaurito le modifiche da apportare e ci siamo sentiti sicuri di poterlo aprire davvero ai clienti.

Settimana 6: Test! Aprire le GPU ai dipendenti Linode

Una delle cose più belle di lavorare in Linode è che possiamo giocare con la tecnologia all'avanguardia prima di chiunque altro. (P.S. Stiamo assumendo!) Ogni dipendente ha la possibilità di mettere alla prova un nuovo prodotto, in modo che ogni pezzo di tecnologia che lanciamo sia stato testato. Ogni dipendente può iscriversi per testare un'istanza di Linode GPU durante l'orario di lavoro, anche dopo il lavoro se lo desidera davvero, per utilizzare l'istanza di Linode GPU come farebbe un cliente. Tutto ciò che dovevano fare era etichettare il loro account di dipendenti e avviare un'istanza GPU.

Ecco alcuni dei modi in cui i linoidi hanno provato le nostre nuove GPU:

• Cloud gaming: il gioco viene eseguito sull'istanza Linode GPU e il video e i controlli vengono inviati tramite Steam Link™.
• Rendering 3D
• Trascodifica video
• Test sulla forza delle password
• Esecuzione di TensorFlow

Dopo questa fase abbiamo raccolto i dati relativi alle prestazioni e abbiamo deciso che eravamo pronti per la produzione e il lancio ai clienti.

Lancio!

Abbiamo lanciato! Abbiamo festeggiato! C'erano gelati e gadget! I clienti hanno iniziato a provare il prodotto che era stato sviluppato solo poche settimane prima. La cosa migliore è che il giorno del lancio tutto ha funzionato. Non abbiamo dovuto apportare modifiche dell'ultimo minuto, non ci sono stati incendi da spegnere, i clienti erano felici e tutto funzionava in modo affidabile.

Il lancio effettivo del codice non è stato difficile. Dal punto di vista del codice e della configurazione del sistema, tutto ciò che è stato necessario per lanciare le GPU in produzione è stata la rimozione di un flag di funzionalità. Ma ci sono anche tonnellate di altre cose che riguardano il lancio di un prodotto in Linode: la documentazione tecnica, le modifiche all'interfaccia utente di Linode Cloud Manager e tutto il materiale di marketing per celebrare il nostro nuovo prodotto.

Post-lancio: Nessuna modifica del codice per sei mesi

Alcune domande sono sempre presenti nella nostra mente: abbiamo fatto abbastanza test? Sei settimane sono state troppo veloci?

Nel nostro caso si trattava della velocità giusta: non ho dovuto toccare il codice dal lancio. E le GPU Linode sono state utilizzate dai clienti ogni singolo giorno. È fantastico quando si può costruire un prodotto e farlo funzionare, e poi continuare a costruire altri grandi prodotti, e quella cosa che si è costruita due anni fa è ancora in funzione, tutta da sola, con un'interazione minima.

A posteriori, ecco alcuni elementi che ci hanno permesso di ottenere questo successo:

1. Fate ricerche in anticipo: questo ci ha aiutato molto ad affrontare tutte le incognite che potevamo avere senza avere l'hardware in mano.
2. Fare un piano - Avevamo un piano molto dettagliato e ogni fase doveva essere eseguita in tempo, altrimenti non saremmo stati in grado di lanciarla.
3. Attenetevi al piano - Concentratevi sul compito da svolgere e tenete a mente le altre attività da portare a termine.
4. Avere un buon team di gestione - Assicurarsi che tutti i livelli di gestione siano consapevoli che se un progetto con scadenze ravvicinate non compie un solo passo, la scadenza del lancio non sarà rispettata. Questa è forse la parte più importante che ci ha permesso di avere successo. Un po' di pressione è una buona cosa, come lo è stata nel nostro caso, mentre troppa pressione porta al burn out e al fallimento. Dopo aver discusso la tempistica con la dirigenza, questa era completamente d'accordo.
5. Sostenetevi a vicenda - L'unica squadra che ha avuto una possibilità non l'avrebbe avuta senza l'intera struttura di supporto del resto dell'organizzazione. Quando tutti i vostri colleghi vogliono che abbiate successo, tutti si faranno avanti e vi aiuteranno se ne avrete bisogno.
6. Test - Test test test test, se potessi scriverlo un'altra volta, direi ancora test. Sia per i test automatizzati che per quelli manuali. Questo è stato di gran lunga il motivo principale per cui nessuno del mio team ha dovuto toccare il codice in oltre 6 mesi.

Per saperne di più sulle istanze Linode GPU , consultate la documentazione diGPU . Abbiamo appena ampliato la disponibilità di GPU nei nostri data center di Newark, Mumbai e Singapore.

Siete interessati a provare le GPU Linode per i vostri carichi di lavoro attuali? È possibile ottenere una prova gratuita di una settimana per vedere come funzionano le nostre GPU. Per saperne di più, cliccate qui.

(E ancora, se volete aiutarci a costruire e testare prodotti come le GPU Linode, stiamo assumendo).