Gestione efficiente e affidabile dei cluster su qualsiasi scala con Tupperware
Oggi su abbiamo introdotto Tupperware, il nostro sistema di gestione dei cluster che orchestra i contenitori su milioni di server che eseguono quasi tutti i nostri servizi. Abbiamo implementato Tupperware per la prima volta nel 2011 e da allora la nostra infrastruttura è cresciuta per intero . Per tutto questo tempo, Tupperware non si è fermato e si è sviluppato con noi. Ti mostreremo come Tupperware fornisce una gestione dei cluster di prima classe, incluso un comodo supporto per servizi stateful, un unico pannello di controllo per tutti i data center e la capacità di distribuire la capacità tra i servizi in tempo reale. Condivideremo anche le lezioni che abbiamo imparato man mano che la nostra infrastruttura si evolve.
Tupperware svolge diversi compiti. Gli sviluppatori di applicazioni lo utilizzano per fornire e gestire le applicazioni. Impacchetta il codice dell'applicazione e le dipendenze in un'immagine e la consegna ai server come contenitori. I contenitori forniscono l'isolamento tra le applicazioni sullo stesso server in modo che gli sviluppatori si occupino della logica dell'applicazione e non debbano preoccuparsi di trovare server o gestire gli aggiornamenti. Tupperware monitora anche le prestazioni del server e, se rileva un guasto, trasferisce i contenitori dal server problematico.
Gli ingegneri addetti alla pianificazione della capacità utilizzano Tupperware per allocare la capacità del server ai team in base al budget e ai vincoli. Lo usano anche per migliorare l'utilizzo del server. Gli operatori dei data center si rivolgono a Tupperware per distribuire correttamente i contenitori tra i data center e arrestare o spostare i contenitori durante la manutenzione. Grazie a ciò, la manutenzione di server, reti e apparecchiature richiede un intervento umano minimo.
Architettura Tupperware
L'architettura PRN di Tupperware è una delle regioni dei nostri data center. La regione è costituita da diversi edifici di data center (PRN1 e PRN2) situati nelle vicinanze. Abbiamo in programma di creare un pannello di controllo che gestirà tutti i server in una regione.
Gli sviluppatori di applicazioni forniscono servizi sotto forma di lavori Tupperware. Un lavoro è costituito da più contenitori e in genere tutti eseguono lo stesso codice dell'applicazione.
Tupperware è responsabile del provisioning dei contenitori e della gestione del loro ciclo di vita. È costituito da diversi componenti:
- Il frontend Tupperware fornisce API per l'interfaccia utente, la CLI e altri strumenti di automazione attraverso i quali puoi interagire con Tupperware. Nascondono l'intera struttura interna ai proprietari dei lavori Tupperware.
- Tupperware Scheduler è un pannello di controllo responsabile della gestione del contenitore e del ciclo di vita del lavoro. Viene distribuito a livello regionale e globale, dove lo scheduler regionale gestisce i server in una regione e lo scheduler globale gestisce i server di diverse regioni. Lo scheduler è diviso in frammenti e ogni frammento gestisce una serie di lavori.
- Lo Scheduler Proxy di Tupperware nasconde lo sharding interno e fornisce un comodo pannello di controllo unico per gli utenti Tupperware.
- L'allocatore Tupperware assegna i contenitori ai server. Lo scheduler gestisce l'arresto, l'avvio, l'aggiornamento e il failover dei contenitori. Attualmente, un allocatore può gestire l’intera regione senza dividerla in frammenti. (Notare la differenza nella terminologia. Ad esempio, lo scheduler in Tupperware corrisponde al pannello di controllo in e l'allocatore Tupperware è chiamato scheduler in Kubernetes.)
- Il broker di risorse archivia l'origine della verità per il server e gli eventi del servizio. Eseguiamo un broker di risorse per ciascun data center e memorizza tutte le informazioni sui server in quel data center. Il broker di risorse e il sistema di gestione della capacità, o sistema di provisioning delle risorse, decidono dinamicamente quale consegna dello scheduler controlla quale server. Il servizio di controllo dello stato monitora i server e archivia i dati sulla loro integrità nel broker di risorse. Se un server ha problemi o necessita di manutenzione, il broker di risorse dice all'allocatore e allo scheduler di arrestare i contenitori o spostarli su altri server.
- L'agente Tupperware è un demone in esecuzione su ciascun server che gestisce il provisioning e la rimozione dei contenitori. Le applicazioni vengono eseguite all'interno di un contenitore, che offre loro maggiore isolamento e riproducibilità. SU Abbiamo già descritto come vengono creati i singoli contenitori Tupperware utilizzando immagini, btrfs, cgroupv2 e systemd.
Caratteristiche distintive di Tupperware
Tupperware è simile in molti modi ad altri sistemi di gestione dei cluster come Kubernetes e , ma ci sono anche delle differenze:
- Supporto integrato per servizi con stato.
- Un unico pannello di controllo per server in diversi data center per automatizzare la consegna dei contenitori in base all'intento, allo smantellamento dei cluster e alla manutenzione.
- Chiara divisione del pannello di controllo per lo zoom.
- L'elaborazione elastica consente di distribuire la potenza tra i servizi in tempo reale.
Abbiamo sviluppato queste fantastiche funzionalità per supportare una varietà di applicazioni stateless e stateful su un enorme parco di server condivisi globali.
Supporto integrato per servizi con stato.
Tupperware gestisce una serie di servizi stateful critici che archiviano dati di prodotto persistenti per Facebook, Instagram, Messenger e WhatsApp. Potrebbero essere grandi archivi di coppie chiave-valore (ad es. ) e monitorare gli archivi di dati (ad esempio, и ). Mantenere i servizi stateful non è facile, perché il sistema deve garantire che la fornitura di container possa resistere a interruzioni su larga scala, comprese interruzioni di rete o interruzioni di corrente. E mentre le tecniche convenzionali, come la distribuzione di contenitori tra domini di errore, funzionano bene per i servizi stateless, i servizi stateful necessitano di supporto aggiuntivo.
Ad esempio, se un guasto del server rende non disponibile una replica del database, è necessario abilitare la manutenzione automatica che aggiornerà i core su 50 server da un pool di 10? Dipende dalla situazione. Se uno di questi 50 server ha un'altra replica dello stesso database, è meglio aspettare per non perdere 2 repliche contemporaneamente. Per prendere decisioni dinamiche sulla manutenzione e sulle prestazioni del sistema, abbiamo bisogno di informazioni sulla replica interna dei dati e sulla logica di posizionamento di ciascun servizio con stato.
L'interfaccia TaskControl consente ai servizi con stato di influenzare le decisioni che influiscono sulla disponibilità dei dati. Utilizzando questa interfaccia, lo scheduler notifica alle applicazioni esterne le operazioni del contenitore (riavvio, aggiornamento, migrazione, manutenzione). Un servizio con stato implementa un controller che comunica a Tupperware quando è sicuro eseguire ciascuna operazione e queste operazioni possono essere scambiate o ritardate temporaneamente. Nell'esempio precedente, il controller del database potrebbe dire a Tupperware di aggiornare 49 dei 50 server, ma per ora lascia solo un server specifico (X). Di conseguenza, se il periodo di aggiornamento del kernel scade e il database non è ancora in grado di ripristinare la replica problematica, Tupperware aggiornerà comunque il server X.
Molti servizi con stato in Tupperware utilizzano TaskControl non direttamente, ma tramite ShardManager, una piattaforma comune per la creazione di servizi con stato su Facebook. Con Tupperware, gli sviluppatori possono specificare il loro intento su come distribuire esattamente i contenitori nei data center. Con ShardManager, gli sviluppatori specificano il loro intento riguardo alla modalità di distribuzione degli shard di dati tra i contenitori. ShardManager è consapevole del posizionamento dei dati e della replica delle sue applicazioni e comunica con Tupperware tramite l'interfaccia TaskControl per pianificare le operazioni del contenitore senza il coinvolgimento diretto dell'applicazione. Questa integrazione semplifica notevolmente la gestione dei servizi con stato, ma TaskControl è in grado di fare di più. Ad esempio, il nostro ampio livello Web è stateless e utilizza TaskControl per regolare dinamicamente la frequenza degli aggiornamenti ai contenitori. Infine al giorno senza compromettere la disponibilità.
Gestione dei server nei data center
Quando Tupperware è stato lanciato per la prima volta nel 2011, ciascun cluster di server era gestito da uno scheduler separato. Allora, un cluster Facebook era un gruppo di server rack collegati a uno switch di rete e il data center ospitava diversi cluster. Lo scheduler poteva gestire solo i server in un cluster, il che significa che il lavoro non poteva essere distribuito su più cluster. La nostra infrastruttura è cresciuta, abbiamo sempre più cancellato i cluster. Poiché Tupperware non poteva trasferire il lavoro dal cluster dismesso ad altri cluster senza modifiche, ciò ha richiesto molto impegno e un attento coordinamento tra gli sviluppatori di applicazioni e gli operatori del data center. Questo processo ha comportato uno spreco di risorse quando i server sono rimasti inattivi per mesi a causa delle procedure di smantellamento.
Abbiamo creato un broker di risorse per risolvere il problema dello smantellamento del cluster e coordinare altri tipi di attività di manutenzione. Il Resource Broker tiene traccia di tutte le informazioni fisiche associate a un server e decide dinamicamente quale scheduler controlla ciascun server. Il collegamento dinamico dei server agli scheduler consente allo scheduler di gestire i server in diversi data center. Poiché un lavoro Tupperware non è più limitato a un singolo cluster, gli utenti Tupperware possono specificare come i contenitori devono essere distribuiti tra i domini di errore. Ad esempio, uno sviluppatore può dichiarare il proprio intento (ad esempio: "eseguire il lavoro su 2 domini di errore nell'area PRN") senza specificare zone di disponibilità specifiche. Tupperware stessa troverà i server adatti per attuare questa intenzione, anche se il cluster o il servizio vengono disattivati.
Scalabile per supportare l’intero sistema globale
Storicamente, la nostra infrastruttura è stata divisa in centinaia di pool di server dedicati per i singoli team. A causa della frammentazione e della mancanza di standard, avevamo costi operativi elevati e i server inattivi erano più difficili da riutilizzare. Alla conferenza dell'anno scorso abbiamo presentato , che dovrebbe unire la nostra infrastruttura in un unico grande parco server. Ma un parco server singolo presenta le sue difficoltà. Deve soddisfare determinati requisiti:
- Scalabilità. La nostra infrastruttura è cresciuta man mano che abbiamo aggiunto data center in ciascuna regione. I server sono diventati più piccoli e più efficienti dal punto di vista energetico, quindi ce ne sono molti di più in ogni regione. Di conseguenza, un singolo scheduler per regione non può gestire il numero di contenitori che possono essere eseguiti su centinaia di migliaia di server in ciascuna regione.
- Affidabilità. Anche se lo scheduler può essere ampliato così tanto, l’ampio ambito dello scheduler implica un rischio maggiore di errori e un’intera regione di contenitori potrebbe diventare ingestibile.
- Tolleranza ai guasti. In caso di grave guasto dell'infrastruttura (ad esempio, i server che eseguono lo scheduler si guastano a causa di un guasto della rete o di un'interruzione dell'alimentazione), le conseguenze negative dovrebbero colpire solo una parte dei server nella regione.
- Facilità d'uso Potrebbe sembrare che sia necessario eseguire diversi scheduler indipendenti per una regione. Ma dal punto di vista della comodità, un unico punto di ingresso nel pool condiviso di una regione rende più semplice la gestione di capacità e posti di lavoro.
Abbiamo diviso lo scheduler in frammenti per risolvere i problemi di mantenimento di un grande pool condiviso. Ogni frammento dello scheduler gestisce il proprio set di lavori nella regione e questo riduce il rischio associato allo scheduler. Man mano che il pool condiviso cresce, possiamo aggiungere più frammenti dello scheduler. Per gli utenti Tupperware, gli shard e i proxy dello scheduler sembrano un unico pannello di controllo. Non devono lavorare con un mucchio di frammenti che orchestrano le attività. Gli shard dello scheduler sono fondamentalmente diversi dagli scheduler del cluster che usavamo prima, quando il pannello di controllo veniva partizionato senza dividere staticamente il pool condiviso di server in base alla topologia di rete.
Migliora l'efficienza di utilizzo con l'Elastic Computing
Quanto più grande è la nostra infrastruttura, tanto più importante è utilizzare i nostri server in modo efficiente per ottimizzare i costi dell'infrastruttura e ridurre il carico. Esistono due modi per aumentare l'efficienza dell'utilizzo del server:
- Elaborazione elastica: riduci i servizi online durante le ore tranquille e utilizza i server liberati per carichi di lavoro offline, come l'apprendimento automatico e i lavori MapReduce.
- Sovraccarico: posizionare i servizi online e i carichi di lavoro batch sugli stessi server in modo che i carichi di lavoro batch vengano eseguiti con priorità bassa.
Il collo di bottiglia nei nostri data center è . Pertanto, preferiamo server piccoli ed efficienti dal punto di vista energetico che insieme forniscono maggiore potenza di elaborazione. Sfortunatamente, su server piccoli con poca CPU e memoria, il sovraccarico è meno efficace. Naturalmente, possiamo posizionare diversi contenitori di piccoli servizi su un piccolo server ad alta efficienza energetica che consuma poche risorse del processore e memoria, ma i servizi di grandi dimensioni avranno prestazioni basse in questa situazione. Pertanto, consigliamo agli sviluppatori dei nostri grandi servizi di ottimizzarli in modo che utilizzino interi server.
Fondamentalmente, miglioriamo l'efficienza di utilizzo utilizzando il calcolo elastico. Molti dei nostri servizi principali, come il feed di notizie, la funzionalità di messaggistica e il livello web front-end, variano a seconda dell'ora del giorno. Riduciamo intenzionalmente i servizi online durante le ore tranquille e utilizziamo server liberati per carichi di lavoro offline, come l'apprendimento automatico e i lavori MapReduce.
Sappiamo per esperienza che è meglio fornire interi server come unità di capacità elastica perché i servizi di grandi dimensioni sono sia i principali donatori che i principali consumatori di capacità elastica e sono ottimizzati per utilizzare interi server. Quando il server viene rilasciato dal servizio online durante le ore tranquille, il Resource Broker affitta il server allo scheduler per eseguire carichi di lavoro offline su di esso. Se il servizio online riscontra un carico di picco, il Resource Broker richiama rapidamente il server preso in prestito e, insieme allo scheduler, lo restituisce al servizio online.
Lezioni apprese e progetti per il futuro
Negli ultimi 8 anni abbiamo sviluppato Tupperware per tenere il passo con la rapida crescita di Facebook. Condividiamo ciò che abbiamo imparato e speriamo che possa aiutare altri a gestire infrastrutture in rapida crescita:
- Configura una connessione flessibile tra la centrale ed i server che gestisce. Questa flessibilità consente al pannello di controllo di gestire server in diversi data center, aiuta ad automatizzare lo smantellamento e la manutenzione dei cluster e consente l'allocazione dinamica della capacità utilizzando l'elaborazione elastica.
- Con un unico pannello di controllo nella regione, diventa più conveniente lavorare con le attività e gestire più facilmente un ampio parco di server condivisi. Si tenga presente che la centrale mantiene un unico punto di ingresso, anche se la sua struttura interna è separata per ragioni di scala o di tolleranza ai guasti.
- Utilizzando un modello plug-in, il pannello di controllo può notificare alle applicazioni esterne le imminenti operazioni del contenitore. Inoltre, i servizi con stato possono utilizzare l'interfaccia del plugin per personalizzare la gestione dei contenitori. Con questo modello di plugin, il pannello di controllo offre semplicità e serve in modo efficiente molti servizi con stato diversi.
- Riteniamo che l’elaborazione elastica, in cui togliamo interi server dai servizi donatori per lavori batch, apprendimento automatico e altri servizi non urgenti, sia il modo ottimale per migliorare l’efficienza di server piccoli ed efficienti dal punto di vista energetico.
Stiamo appena iniziando a implementare . Attualmente circa il 20% dei nostri server si trova in un pool condiviso. Per raggiungere il 100%, è necessario risolvere molti problemi, tra cui il mantenimento di un pool di storage condiviso, l'automazione della manutenzione, la gestione dei requisiti tra tenant, il miglioramento dell'utilizzo dei server e il miglioramento del supporto per i carichi di lavoro di machine learning. Non vediamo l’ora di affrontare queste sfide e condividere i nostri successi.
Fonte: habr.com