Gestió eficient i fiable de clústers a qualsevol escala amb Tupperware
Avui dia vam presentar Tupperware, el nostre sistema de gestió de clúster que orquestra contenidors en milions de servidors que executen gairebé tots els nostres serveis. Vam desplegar Tupperware per primera vegada l'any 2011, i des de llavors la nostra infraestructura ha crescut a sencer . Durant tot aquest temps, Tupperware no es va quedar quiet i es va desenvolupar amb nosaltres. Us mostrarem com Tupperware ofereix una gestió de clúster de primera classe, inclòs un suport convenient per a serveis amb estat, un únic panell de control per a tots els centres de dades i la capacitat de distribuir la capacitat entre serveis en temps real. També compartirem les lliçons que hem après a mesura que evolucioni la nostra infraestructura.
Tupperware realitza diferents tasques. Els desenvolupadors d'aplicacions l'utilitzen per lliurar i gestionar aplicacions. Empaqueta el codi de l'aplicació i les dependències en una imatge i la lliura als servidors com a contenidors. Els contenidors proporcionen aïllament entre les aplicacions del mateix servidor perquè els desenvolupadors s'ocupin de la lògica de l'aplicació i no s'hagin de preocupar per trobar servidors o gestionar actualitzacions. Tupperware també supervisa el rendiment del servidor i, si troba un error, transfereix contenidors des del servidor problemàtic.
Els enginyers de planificació de capacitat utilitzen Tupperware per assignar la capacitat del servidor als equips en funció del pressupost i les limitacions. També l'utilitzen per millorar l'ús del servidor. Els operadors de centres de dades recorren a Tupperware per distribuir correctament els contenidors als centres de dades i aturar o moure els contenidors durant el manteniment. Gràcies a això, el manteniment de servidors, xarxes i equips requereix una intervenció humana mínima.
Arquitectura Tupperware
L'arquitectura Tupperware PRN és una de les regions dels nostres centres de dades. La regió consta de diversos edificis de centres de dades (PRN1 i PRN2) situats a prop. Tenim previst fer un tauler de control que gestionarà tots els servidors d'una regió.
Els desenvolupadors d'aplicacions ofereixen serveis en forma de feines de Tupperware. Un treball consta de diversos contenidors i, normalment, tots executen el mateix codi d'aplicació.
Tupperware s'encarrega d'aprovisionar els contenidors i gestionar-ne el cicle de vida. Consta de diversos components:
- La interfície de Tupperware proporciona API per a la interfície d'usuari, la CLI i altres eines d'automatització mitjançant les quals podeu interactuar amb Tupperware. Oculten tota l'estructura interna als propietaris de llocs de treball de Tupperware.
- Tupperware Scheduler és un panell de control encarregat de gestionar el cicle de vida del contenidor i del treball. Es desplega a nivells regional i global, on el planificador regional gestiona els servidors d'una regió i el planificador global gestiona els servidors de diferents regions. El planificador es divideix en fragments i cada fragment gestiona un conjunt de treballs.
- El programador intermediari de Tupperware amaga el fragment intern i proporciona un únic panell de vidre convenient per als usuaris de Tupperware.
- L'assignador de Tupperware assigna contenidors als servidors. El planificador gestiona l'aturada, l'inici, l'actualització i la migració per error dels contenidors. Actualment, un assignador pot gestionar tota la regió sense dividir-se en fragments. (Tingueu en compte la diferència de terminologia. Per exemple, el planificador de Tupperware correspon al tauler de control a , i l'assignador de Tupperware s'anomena planificador a Kubernetes.)
- El corredor de recursos emmagatzema la font de la veritat per als esdeveniments del servidor i del servei. Tenim un agent de recursos per a cada centre de dades i emmagatzema tota la informació sobre els servidors d'aquest centre de dades. L'agent de recursos i el sistema de gestió de capacitat, o sistema de subministrament de recursos, decideixen dinàmicament quin programador de lliurament controla quin servidor. El servei de control de salut supervisa els servidors i emmagatzema dades sobre el seu estat al corredor de recursos. Si un servidor té problemes o necessita manteniment, l'agent de recursos diu a l'assignador i al programador que aturi els contenidors o que els traslladin a altres servidors.
- L'agent de Tupperware és un dimoni que s'executa a cada servidor que gestiona l'aprovisionament i l'eliminació de contenidors. Les aplicacions s'executen dins d'un contenidor, cosa que els proporciona més aïllament i reproductibilitat. Encès Ja hem descrit com es creen contenidors Tupperware individuals mitjançant imatges, btrfs, cgroupv2 i systemd.
Característiques distintives de Tupperware
Tupperware és similar en molts aspectes a altres sistemes de gestió de clúster com ara Kubernetes i , però també hi ha diferències:
- Suport integrat per a serveis amb estat.
- Un únic panell de control per a servidors de diferents centres de dades per automatitzar el lliurament de contenidors en funció de la intenció, la desactivació de clústers i el manteniment.
- Divisió clara del tauler de control per fer zoom.
- La informàtica elàstica us permet distribuir l'energia entre serveis en temps real.
Hem desenvolupat aquestes funcions fantàstiques per donar suport a una varietat d'aplicacions sense estat i amb estat en una enorme flota de servidors compartits global.
Suport integrat per a serveis amb estat.
Tupperware opera una varietat de serveis d'estat crítics que emmagatzemen dades de productes persistents per a Facebook, Instagram, Messenger i WhatsApp. Poden ser grans magatzems de parells clau-valor (p. ex. ) i control de dipòsits de dades (per exemple, и ). Mantenir els serveis amb estat no és fàcil, perquè el sistema ha de garantir que el subministrament de contenidors pugui suportar interrupcions a gran escala, incloses les interrupcions de la xarxa o l'electricitat. I encara que les tècniques convencionals, com ara la distribució de contenidors entre dominis d'error, funcionen bé per als serveis sense estat, els serveis amb estat necessiten suport addicional.
Per exemple, si una fallada del servidor fa que una rèplica de base de dades no estigui disponible, hauríeu d'habilitar el manteniment automàtic que actualitzi els nuclis de 50 servidors d'un grup de 10? Depèn de la situació. Si un d'aquests 50 servidors té una altra rèplica de la mateixa base de dades, és millor esperar i no perdre 2 rèpliques alhora. Per prendre decisions de manera dinàmica sobre el manteniment i el rendiment del sistema, necessitem informació sobre la replicació interna de dades i la lògica de col·locació de cada servei amb estat.
La interfície TaskControl permet que els serveis amb estat influeixin en les decisions que afecten la disponibilitat de dades. Mitjançant aquesta interfície, el planificador notifica a les aplicacions externes les operacions del contenidor (reinici, actualització, migració, manteniment). Un servei amb estat implementa un controlador que indica a Tupperware quan és segur realitzar cada operació, i aquestes operacions es poden canviar o retardar temporalment. A l'exemple anterior, el controlador de la base de dades podria dir-li a Tupperware que actualitzi 49 dels 50 servidors, però de moment deixi un servidor específic (X). Com a resultat, si el període d'actualització del nucli passa i la base de dades encara no pot restaurar la rèplica problemàtica, Tupperware encara actualitzarà el servidor X.
Molts serveis amb estat de Tupperware utilitzen TaskControl no directament, sinó a través de ShardManager, una plataforma comuna per crear serveis amb estat a Facebook. Amb Tupperware, els desenvolupadors poden especificar la seva intenció sobre com s'han de distribuir exactament els contenidors als centres de dades. Amb ShardManager, els desenvolupadors especifiquen la seva intenció sobre com s'han de distribuir els fragments de dades entre els contenidors. ShardManager és conscient de la col·locació de dades i la replicació de les seves aplicacions i es comunica amb Tupperware a través de la interfície TaskControl per programar les operacions dels contenidors sense la implicació directa de l'aplicació. Aquesta integració simplifica molt la gestió dels serveis amb estat, però TaskControl és capaç de fer-ne més. Per exemple, el nostre ampli nivell web és sense estat i utilitza TaskControl per ajustar dinàmicament la velocitat d'actualitzacions dels contenidors. Finalment per dia sense comprometre la disponibilitat.
Gestió de servidors en centres de dades
Quan Tupperware es va llançar per primera vegada el 2011, cada clúster de servidors estava gestionat per un programador independent. Aleshores, un clúster de Facebook era un grup de bastidors de servidor connectats a un commutador de xarxa i el centre de dades allotjava diversos clústers. El planificador només podia gestionar servidors en un clúster, el que significa que la feina no es podia estendre entre diversos clústers. La nostra infraestructura va créixer, cada cop vam cancel·lar més clústers. Com que Tupperware no va poder traslladar la feina del clúster donat de baixa a altres clústers sense canvis, va requerir molt d'esforç i una coordinació acurada entre els desenvolupadors d'aplicacions i els operadors del centre de dades. Aquest procés va provocar un malbaratament de recursos quan els servidors estaven inactius durant mesos a causa dels procediments de desmantellament.
Hem creat un intermediari de recursos per resoldre el problema de desmantellament del clúster i coordinar altres tipus de tasques de manteniment. L'agent de recursos fa un seguiment de tota la informació física associada a un servidor i decideix dinàmicament quin programador controla cada servidor. L'enllaç dinàmic de servidors amb programadors permet que el planificador gestione servidors en diferents centres de dades. Com que un treball de Tupperware ja no es limita a un únic clúster, els usuaris de Tupperware poden especificar com s'han de distribuir els contenidors entre dominis d'error. Per exemple, un desenvolupador pot declarar la seva intenció (per exemple: "executa el meu treball en 2 dominis d'error a la regió PRN") sense especificar zones de disponibilitat específiques. El propi Tupperware trobarà servidors adequats per implementar aquesta intenció, fins i tot si el clúster o el servei està fora de servei.
Escalable per donar suport a tot el sistema global
Històricament, la nostra infraestructura s'ha dividit en centenars de grups de servidors dedicats per a equips individuals. A causa de la fragmentació i la manca d'estàndards, teníem costos operatius elevats i els servidors inactius eren més difícils de tornar a utilitzar. A la conferència de l'any passat vam presentar , que hauria d'unir la nostra infraestructura en un gran parc de servidors únic. Però un únic parc de servidors té les seves pròpies dificultats. Ha de complir uns requisits:
- Escalabilitat. La nostra infraestructura va créixer a mesura que vam afegir centres de dades a cada regió. Els servidors s'han tornat més petits i més eficients energèticament, de manera que n'hi ha molts més a cada regió. Com a resultat, un únic programador per regió no pot gestionar el nombre de contenidors que es poden executar en centenars de milers de servidors de cada regió.
- Fiabilitat Fins i tot si el planificador es pot augmentar tant, l'ampli abast del planificador significa que hi ha un risc més gran d'errors i una regió sencera de contenidors podria arribar a ser inmanejable.
- Falta de tolerància. En cas d'una gran fallada d'infraestructura (per exemple, els servidors que executen el planificador fallen a causa d'una fallada de la xarxa o un tall d'alimentació), les conseqüències negatives haurien d'afectar només una part dels servidors de la regió.
- La comoditat d'ús. Pot semblar que necessiteu executar diversos programadors independents per a una regió. Però des d'una perspectiva de comoditat, un únic punt d'entrada al grup compartit d'una regió facilita la gestió de la capacitat i els llocs de treball.
Vam dividir el planificador en fragments per resoldre els problemes de manteniment d'una gran piscina compartida. Cada fragment del planificador gestiona el seu propi conjunt de treballs a la regió, i això redueix el risc associat al planificador. A mesura que l'agrupació compartida creixi, podem afegir més fragments de planificador. Per als usuaris de Tupperware, els fragments i els servidors intermediaris del programador semblen un tauler de control. No han de treballar amb un munt de fragments que orquestren les tasques. Els fragments del programador són fonamentalment diferents dels planificadors de clúster que hem utilitzat abans, quan el tauler de control es particionava sense dividir estàticament el grup de servidors compartit segons la topologia de la xarxa.
Milloreu l'eficiència d'ús amb la informàtica elàstica
Com més gran sigui la nostra infraestructura, més important és utilitzar els nostres servidors de manera eficient per optimitzar els costos de la infraestructura i reduir la càrrega. Hi ha dues maneres d'augmentar l'eficiència de l'ús del servidor:
- Informàtica elàstica: reduïu els serveis en línia durant les hores tranquil·les i utilitzeu servidors alliberats per a càrregues de treball fora de línia, com ara treballs d'aprenentatge automàtic i MapReduce.
- Sobrecàrrega: col·loqueu serveis en línia i càrregues de treball per lots als mateixos servidors de manera que les càrregues de treball per lots s'executin amb una prioritat baixa.
El coll d'ampolla als nostres centres de dades és . Per tant, preferim servidors petits i eficients energèticament que en conjunt proporcionin més potència de processament. Malauradament, en servidors petits amb poca CPU i memòria, la sobrecàrrega és menys efectiva. Per descomptat, podem col·locar diversos contenidors de serveis petits en un servidor petit d'eficiència energètica que consumeix pocs recursos de processador i memòria, però els serveis grans tindran un rendiment baix en aquesta situació. Per això, aconsellem als desenvolupadors dels nostres grans serveis que els optimitzin perquè utilitzin tots els servidors.
Bàsicament, millorem l'eficiència d'ús mitjançant la informàtica elàstica. Molts dels nostres serveis principals, com ara el canal de notícies, la funció de missatgeria i el nivell web frontal, varien segons l'hora del dia. Reduïm intencionadament els serveis en línia durant les hores tranquil·les i utilitzem servidors alliberats per a càrregues de treball fora de línia, com ara treballs d'aprenentatge automàtic i MapReduce.
Sabem per experiència que el millor és subministrar servidors sencers com a unitats de capacitat elàstica perquè els grans serveis són tant donants importants com consumidors importants de capacitat elàstica, i estan optimitzats per utilitzar servidors sencers. Quan el servidor s'allibera del servei en línia durant les hores tranquil·les, l'agent de recursos lloga el servidor al planificador per executar-hi càrregues de treball fora de línia. Si el servei en línia experimenta una càrrega màxima, l'agent de recursos recupera ràpidament el servidor prestat i, juntament amb el programador, el retorna al servei en línia.
Lliçons apreses i plans de futur
Durant els últims 8 anys, hem estat desenvolupant Tupperware per estar al dia amb el ràpid creixement de Facebook. Compartim el que hem après i esperem que ajudi a altres a gestionar infraestructures de ràpid creixement:
- Configura una connexió flexible entre el tauler de control i els servidors que gestiona. Aquesta flexibilitat permet que el tauler de control gestioni servidors en diferents centres de dades, ajuda a automatitzar el desmantellament i el manteniment dels clústers i permet l'assignació de capacitat dinàmica mitjançant la informàtica elàstica.
- Amb un únic tauler de control a la regió, és més còmode treballar amb tasques i més fàcil gestionar una gran flota de servidors compartits. Tingueu en compte que el panell de control manté un únic punt d'entrada, encara que la seva estructura interna estigui separada per raons d'escala o de tolerància a errors.
- Mitjançant un model de connector, el tauler de control pot notificar a les aplicacions externes les properes operacions de contenidors. A més, els serveis amb estat poden utilitzar la interfície del connector per personalitzar la gestió de contenidors. Amb aquest model de connectors, el tauler de control proporciona simplicitat alhora que serveix de manera eficient molts serveis diferents.
- Creiem que la informàtica elàstica, on traiem servidors sencers dels serveis de donants per a treballs per lots, aprenentatge automàtic i altres serveis no urgents, és la manera òptima de millorar l'eficiència dels servidors petits i eficients energèticament.
Tot just comencem a implementar . Actualment, al voltant del 20% dels nostres servidors es troben en una piscina compartida. Per aconseguir el 100%, s'han de resoldre molts problemes, com ara el manteniment d'un grup d'emmagatzematge compartit, l'automatització del manteniment, la gestió dels requisits entre inquilins, la millora de l'ús del servidor i la millora del suport per a les càrregues de treball d'aprenentatge automàtic. No podem esperar per assumir aquests reptes i compartir els nostres èxits.
Font: www.habr.com