Gestione efficiente è affidabile di clusters à ogni scala cù Tupperware
Oghje nantu avemu introduttu Tupperware, u nostru sistema di gestione di cluster chì orchestra cuntenituri in milioni di servitori chì eseguenu quasi tutti i nostri servizii. Avemu implementatu per a prima volta Tupperware in 2011, è da tandu a nostra infrastruttura hè cresciuta à sanu . Tuttu stu tempu, Tupperware ùn hè micca fermu è sviluppatu cun noi. Vi mustraremu cumu Tupperware furnisce una gestione di cluster di prima classe, cumpresu un supportu convenientu per i servizii statali, un unicu pannellu di cuntrollu per tutti i centri di dati, è a capacità di distribuisce a capacità trà i servizii in tempu reale. Avemu da sparte ancu e lezioni chì avemu amparatu mentre a nostra infrastruttura evoluzione.
Tupperware esegue diverse attività. I sviluppatori di applicazioni l'utilizanu per furnisce è gestisce l'applicazioni. Impacchetta u codice di l'applicazione è e dipendenze in una maghjina è a trasmette à i servitori cum'è cuntenituri. I cuntenituri furnisce l'isolamentu trà l'applicazioni nantu à u stessu servitore per chì i sviluppatori si trattanu di a logica di l'applicazione è ùn anu micca da preoccupassi di truvà servitori o di gestisce l'aghjurnamenti. Tupperware monitoreghja ancu u funziunamentu di u servitore, è s'ellu trova un fallimentu, trasferisce cuntenituri da u servitore problematicu.
L'ingegneri di pianificazione di capacità utilizanu Tupperware per attribuisce a capacità di u servitore à e squadre basate nantu à u budget è e restrizioni. Anu ancu aduprà per migliurà l'utilizazione di u servitore. L'operatori di u centru di dati turnanu à Tupperware per distribuisce bè i cuntenituri in i centri di dati è piantà o move i cuntenituri durante u mantenimentu. Grazie à questu, u mantenimentu di i servitori, di e rete è di l'equipaggiu richiede un minimu interventu umanu.
L'architettura Tupperware
L'architettura Tupperware PRN hè una di e regioni di i nostri centri di dati. A regione hè custituita da parechji edifici di centru di dati (PRN1 è PRN2) situati vicinu. Avemu pensatu à fà un pannellu di cuntrollu chì gestisce tutti i servitori in una regione.
I sviluppatori di applicazioni furniscenu servizii in forma di impieghi Tupperware. Un travagliu hè custituitu da parechji cuntenituri, è tutti sò tipicamente eseguite u listessu codice di l'applicazione.
Tupperware hè incaricatu di furnisce i cuntenituri è di gestisce u so ciclu di vita. Hè custituitu di parechji cumpunenti:
- U frontend di Tupperware furnisce API per l'interfaccia d'utilizatore, CLI, è altri strumenti d'automatizazione per mezu di quale pudete interagisce cù Tupperware. Ocultanu tutta a struttura interna da i pruprietarii di u travagliu Tupperware.
- Tupperware Scheduler hè un pannellu di cuntrollu rispunsevule per a gestione di u containeru è u ciclu di vita di u travagliu. Hè implementatu à livellu regiunale è glubale, induve u pianificatore regiunale gestisce i servitori in una regione è u pianificatore globale gestisce i servitori da diverse regioni. U pianificatore hè divisu in shards, è ogni shard gestisce un settore di travagliu.
- U Scheduler Proxy di Tupperware oculta u sharding internu è furnisce un pannellu unicu di vetru convenientu per l'utilizatori di Tupperware.
- L'allocatore Tupperware assigna cuntenituri à i servitori. U pianificatore gestisce l'arrestu, l'iniziu, l'aghjurnamentu è u failover di cuntenituri. Attualmente, un allocatore pò gestisce tutta a regione senza split in shards. (Nota a diferenza in a terminologia. Per esempiu, u scheduler in Tupperware currisponde à u pannellu di cuntrollu in , è l'allocatore Tupperware hè chjamatu pianificatore in Kubernetes.)
- U broker di risorse guarda a fonte di a verità per u servitore è l'avvenimenti di serviziu. Emu un broker di risorse per ogni centru di dati, è guarda tutte l'infurmazioni nantu à i servitori in quellu centru di dati. U broker di risorsa è u sistema di gestione di capacità, o sistema di pruvista di risorse, decide dinamicamente quale pianificatore di consegna cuntrolla quale servitore. U serviziu di cuntrollu di salute monitoreghja i servitori è guarda dati nantu à a so salute in u broker di risorse. Se un servitore hà prublemi o hà bisognu di mantenimentu, u broker di risorsa dice à l'allocatore è à u pianificatore di piantà i cuntenituri o di trasfurmà in altri servitori.
- L'Agente Tupperware hè un daemon chì corre nantu à ogni servitore chì gestisce l'approvvigionamentu è a rimozione di cuntenituri. L'applicazioni funzionanu in un containeru, chì li dà più isolamentu è riproducibilità. On Avemu digià descrittu cumu i cuntenituri Tupperware individuali sò creati cù l'imaghjini, btrfs, cgroupv2 è systemd.
Caratteristiche distintive di Tupperware
Tupperware hè simile in parechje manere à altri sistemi di gestione di cluster cum'è Kubernetes è , ma ci sò ancu differenze:
- Supportu integratu per i servizii stateful.
- Un unicu pannellu di cuntrollu per i servitori in diversi centri di dati per automatizà a consegna di cuntenituri basatu annantu à l'intenzione, a decommissioning di clusters è u mantenimentu.
- Divisione chjaru di u pannellu di cuntrollu per u zoom.
- L'informatica elastica permette di distribuisce u putere trà i servizii in tempu reale.
Avemu sviluppatu queste caratteristiche interessanti per sustene una varietà di applicazioni senza statu è stateful in una enorme flotta di servitori spartuti globale.
Supportu integratu per i servizii stateful.
Tupperware opera una varietà di servizii statali critichi chì almacenanu dati persistenti di u produttu per Facebook, Instagram, Messenger è WhatsApp. Puderanu esse grandi magazzini di coppie chjave-valore (p.e. ) è i repertorii di dati di monitoraghju (per esempiu, и ). A mantenimentu di i servizii statali ùn hè micca faciule, perchè u sistema deve assicurà chì u fornimentu di cuntenituri pò sustene disrupzioni à grande scala, cumprese l'interruzioni di a rete o l'interruzioni di energia. E mentre i tecnichi cunvinziunali, cum'è a distribuzione di cuntenituri in i domini di difetti, funzionanu bè per i servizii senza statu, i servizii stateful necessitanu supportu supplementu.
Per esempiu, se un fallimentu di u servitore rende una replica di basa di dati indisponibile, duvete attivà u mantenimentu automaticu chì aghjurnà i core in 50 servitori da una piscina di 10 50? Dipende da a situazione. Se unu di sti servitori 2 hà una altra replica di a listessa basa di dati, hè megliu aspittà è ùn perde micca XNUMX replicati à una volta. Per piglià dinamicamente decisioni nantu à u mantenimentu è u rendiment di u sistema, avemu bisognu d'infurmazioni nantu à a replicazione di dati interni è a logica di piazzamentu di ogni serviziu stateful.
L'interfaccia TaskControl permette à i servizii statali di influenzà e decisioni chì afectanu a dispunibilità di dati. Utilizendu sta interfaccia, u pianificatore avvisa l'applicazioni esterne nantu à l'operazioni di u containeru (restart, update, migration, maintenance). Un serviziu stateful implementa un controller chì dice à Tupperware quandu hè sicuru per fà ogni operazione, è queste operazioni ponu esse scambiate o ritardate temporaneamente. In l'esempiu supra, u cuntrollu di a basa di dati puderia dì à Tupperware per aghjurnà 49 di i servitori 50, ma lasciate un servitore specificu (X) solu per avà. In u risultatu, se u periodu di l'aghjurnamentu di u kernel passa è a basa di dati ùn hè ancu capace di restaurà a replica problematica, Tupperware hà sempre aghjurnatu u servore X.
Parechji servizii stateful in Tupperware utilizanu TaskControl micca direttamente, ma attraversu ShardManager, una piattaforma cumuni per creà servizii stateful in Facebook. Cù Tupperware, i sviluppatori ponu specificà a so intenzione per esattamente cumu si deve esse distribuiti i cuntenituri in i centri di dati. Cù ShardManager, i sviluppatori specificanu a so intenzione di cumu i frammenti di dati devenu esse distribuiti in cuntenituri. ShardManager hè cunuscenza di u piazzamentu di dati è a replicazione di e so applicazioni è cumunicà cù Tupperware attraversu l'interfaccia TaskControl per programà l'operazioni di u containeru senza implicazione diretta di l'applicazione. Questa integrazione simplifica assai a gestione di i servizii stateful, ma TaskControl hè capaci di più. Per esempiu, u nostru vastu livellu web hè senza statu è usa TaskControl per aghjustà dinamicamente a tarifa di l'aghjurnamenti à i cuntenituri. Eventualmente per ghjornu senza compromette a dispunibilità.
Gestisce i servitori in i centri di dati
Quandu Tupperware hà lanciatu per a prima volta in u 2011, ogni cluster di servitori era gestitu da un pianificatore separatu. Allora, un cluster di Facebook era un gruppu di rack di servitori cunnessi à un switch di rete, è u centru di dati allughjava parechji clusters. U pianificatore puderia solu gestisce i servitori in un cluster, chì significa chì u travagliu ùn puderia micca sparghje in parechje clusters. A nostra infrastruttura hè cresciuta, avemu sempre più annullatu clusters. Siccomu Tupperware ùn pudia micca spustà u travagliu da u cluster decommissioned à l'altri clusters senza cambiamenti, hà bisognu di assai sforzu è cura di coordinazione trà i sviluppatori di l'applicazioni è l'operatori di u centru di dati. Stu prucessu hà risultatu in risorse sprecate quandu i servitori eranu inattivi per mesi per via di e prucedure di decommissioning.
Avemu creatu un broker di risorse per risolve u prublema di decommissioning cluster è coordina altre tippi di attività di mantenimentu. U broker di risorse mantene a traccia di tutte l'infurmazioni fisiche assuciate cù un servitore è decide dinamicamente quale pianificatore cuntrolla ogni servitore. A cunnessione dinamica di i servitori à i pianificatori permette à u pianificatore di gestisce i servitori in diversi centri di dati. Siccomu un travagliu di Tupperware ùn hè più limitatu à un cluster unicu, l'utilizatori di Tupperware ponu specificà cumu si deve esse distribuitu i cuntenituri in i domini di difetti. Per esempiu, un sviluppatore pò dichjarà a so intenzione (dicemu: "eseguite u mo travagliu nantu à 2 duminii di difettu in a regione PRN") senza specificà zoni di dispunibilità specifichi. Tupperware stessu truverà servitori adattati per implementà sta intenzione, ancu s'ellu u cluster o serviziu hè disattivatu.
Scalable per sustene tuttu u sistema glubale
Stòricamente, a nostra infrastruttura hè stata divisa in centinaie di pool di servitori dedicati per squadre individuali. A causa di a frammentazione è a mancanza di standard, avemu avutu i costi operativi elevati, è i servitori inattivi eranu più difficiuli di utilizà di novu. À a cunferenza di l'annu passatu avemu prisentatu , chì deve unisce a nostra infrastruttura in un grande parcu di servitore unicu. Ma un solu parcu di u servitore hà e so difficultà. Deve risponde à certi requisiti:
- Scalabilità. A nostra infrastruttura hè cresciutu cum'è aghjustatu centri di dati in ogni regione. I servitori sò diventati più chjuchi è più efficienti energetichi, cusì ci sò assai più in ogni regione. In u risultatu, un unicu pianificatore per regione ùn pò micca gestisce u numeru di cuntenituri chì ponu esse eseguiti in centinaie di millaie di servitori in ogni regione.
- Affidabilità Ancu s'è u pianificatore pò esse scalatu tantu, u largu scopu di u pianificatore significa chì ci hè un risicu più altu d'errore è una regione sana di cuntenituri puderia diventà ingestibile.
- Tolleranza à i difetti. In l'eventuali di un fallimentu enormi di l'infrastruttura (per esempiu, i servitori chì eseguenu u scheduler fallenu per un fallimentu di a rete o un interrupzione di l'energia), e cunsequenze negative deve affettà solu una parte di i servitori in a regione.
- Facilità d'usu. Pò sembra chì avete bisognu di eseguisce parechji pianificatori indipendenti per una regione. Ma da una perspettiva di comodità, un puntu unicu d'entrata in u pool spartutu di una regione facilita a gestione di a capacità è di l'impieghi.
Avemu divisu u scheduler in shards per risolve i prublemi di mantene una grande piscina sparta. Ogni frammentu di pianificatore gestisce u so propiu settore di travagliu in a regione, è questu reduce u risicu assuciatu cù u pianificatore. Cum'è a piscina sparta cresce, pudemu aghjunghje più frammenti di pianificatore. Per l'utilizatori di Tupperware, i frammenti è i proxies di pianificazione sembranu un pannellu di cuntrollu. Ùn anu micca bisognu di travaglià cù una mansa di frammenti chì orchestranu i travaglii. I scheduler shards sò fundamentalmente diffirenti da i cluster schedulers chì avemu usatu prima, quandu u pannellu di cuntrollu hè stata particionata senza dividisce staticamente a piscina sparta di servitori secondu a topologia di a rete.
Migliurà l'efficienza di l'usu cù l'informatica elastica
A più grande a nostra infrastruttura, u più impurtante hè di utilizà i nostri servitori in modu efficiente per ottimisà i costi di l'infrastruttura è riduce a carica. Ci hè dui modi per aumentà l'efficienza di l'usu di u servitore:
- Informatica elastica - scala i servizii in linea durante l'ore tranquillu è utilizate servitori liberati per i carichi di travagliu offline, cum'è l'apprendimentu automaticu è i travaglii MapReduce.
- Overloading - Pone i servizii in linea è i carichi di travagliu in batch nantu à i stessi servitori in modu chì i carichi di travagliu batch currispondenu à bassa priorità.
U collu di bottiglia in i nostri centri di dati hè . Per quessa, preferimu servitori chjuchi, efficienti in energia chì inseme furnisce più putenza di trasfurmazioni. Sfurtunatamente, nantu à i servitori chjuchi cù pocu CPU è memoria, a sovraccarica hè menu efficace. Di sicuru, pudemu pusà parechji cuntenituri di picculi servizii nantu à un servitore chjuca efficienza energetica chì cunsumu pocu risorse di processore è memoria, ma i servizii grandi averebbe un rendimentu bassu in questa situazione. Dunque, cunsigliemu à i sviluppatori di i nostri grandi servizii per ottimisà elli in modu chì utilizanu tutti i servitori.
In fondu, migliurà l'efficienza di l'usu utilizendu l'informatica elastica. Parechji di i nostri servizii principali, cum'è u News Feed, a funzione di Messaging è u web tier front-end, varienu secondu l'ora di u ghjornu. Scalemu intenzionalmente i servizii in linea durante l'ore di tranquillità è utilizemu servitori liberati per carichi di travagliu offline, cum'è l'apprendimentu automaticu è l'impieghi MapReduce.
Sapemu da l'esperienza chì hè megliu furnisce i servitori interi cum'è unità di capacità elastica, perchè i grandi servizii sò dui grandi donatori è cunsumatori maiò di capacità elastica, è sò ottimizzati per utilizà servitori interi. Quandu u servitore hè liberatu da u serviziu in linea durante l'ora tranquilla, u broker di risorse affittu u servitore à u pianificatore per eseguisce carichi di travagliu offline. Se u serviziu in linea sperimenta un piccu di carica, u broker di risorse ricurdeghja rapidamente u servitore prestitu è, inseme cù u pianificatore, u torna à u serviziu in linea.
Lezioni amparate è piani per u futuru
In l'ultimi 8 anni, avemu sviluppatu Tupperware per seguità a rapida crescita di Facebook. Spartemu ciò chì avemu amparatu è speremu chì aiutarà l'altri à gestisce infrastrutture in rapida crescita:
- Stabilite una cunnessione flessibile trà u pannellu di cuntrollu è i servitori chì gestisce. Questa flessibilità permette à u pannellu di cuntrollu di gestisce i servitori in diversi centri di dati, aiuta à automatizà a decommissioning è u mantenimentu di clusters, è permette l'allocazione dinamica di capacità cù l'informatica elastica.
- Cù un unicu pannellu di cuntrollu in a regione, diventa più còmuda di travaglià cù i travaglii è più faciule di gestisce una grande flotta di servitori spartuti. Nota chì u pannellu di cuntrollu mantene un puntu unicu di entrata, ancu s'è a so struttura interna hè siparata per ragioni di scala o di tolleranza di difetti.
- Utilizendu un mudellu di plugin, u pannellu di cuntrollu pò notificà l'applicazioni esterne di l'operazioni di u containeru chì venenu. Inoltre, i servizii statali ponu utilizà l'interfaccia di plugin per persunalizà a gestione di u containeru. Cù stu mudellu di plugin, u pannellu di cuntrollu furnisce simplicità mentre serve in modu efficiente parechji servizii statali diffirenti.
- Cridemu chì l'informatica elastica, induve cacciemu i servitori interi da i servizii di donatori per i travaglii in batch, l'apprendimentu automaticu è altri servizii non urgenti, hè u modu ottimale per migliurà l'efficienza di i servitori chjuchi, efficienti in energia.
Avemu appena principiatu à implementà . Attualmente circa 20% di i nostri servitori sò in una piscina spartuta. Per ottene u 100%, parechji prublemi anu da esse indirizzati, cumpresu u mantenimentu di una piscina di almacenamentu spartutu, l'automatizazione di a manutenzione, a gestione di i requisiti di l'inquilini cross-inquilini, a migliurà l'utilizazione di u servitore, è u supportu per i carichi di travagliu di l'apprendimentu di macchina. Ùn pudemu aspittà per piglià sti sfide è sparte i nostri successi.
Source: www.habr.com