Gestionarea eficientă și fiabilă a clusterelor la orice scară cu Tupperware
Astăzi pe am introdus Tupperware, sistemul nostru de management al clusterelor care orchestrează containere pe milioane de servere care rulează aproape toate serviciile noastre. Am implementat pentru prima dată Tupperware în 2011, iar de atunci infrastructura noastră a crescut din la întreg . În tot acest timp, Tupperware nu a stat pe loc și s-a dezvoltat alături de noi. Vă vom arăta cum Tupperware oferă un management de cluster de primă clasă, inclusiv asistență convenabilă pentru serviciile stateful, un singur panou de control pentru toate centrele de date și capacitatea de a distribui capacitatea între servicii în timp real. De asemenea, vom împărtăși lecțiile pe care le-am învățat pe măsură ce infrastructura noastră evoluează.
Tupperware îndeplinește diferite sarcini. Dezvoltatorii de aplicații îl folosesc pentru a furniza și gestiona aplicații. Acesta împachetează codul aplicației și dependențele într-o imagine și îl livrează serverelor ca containere. Containerele asigură izolarea între aplicațiile de pe același server, astfel încât dezvoltatorii să se ocupe de logica aplicației și să nu fie nevoiți să-și facă griji cu privire la găsirea de servere sau la gestionarea actualizărilor. De asemenea, Tupperware monitorizează performanța serverului și, dacă găsește o defecțiune, transferă containere de pe serverul problematic.
Inginerii de planificare a capacității folosesc Tupperware pentru a aloca capacitatea serverului echipelor în funcție de buget și constrângeri. De asemenea, îl folosesc pentru a îmbunătăți utilizarea serverului. Operatorii centrelor de date apelează la Tupperware pentru a distribui corect containerele în centrele de date și pentru a opri sau muta containerele în timpul întreținerii. Datorită acestui fapt, întreținerea serverelor, rețelelor și echipamentelor necesită intervenție umană minimă.
Arhitectura Tupperware
Arhitectura Tupperware PRN este una dintre regiunile centrelor noastre de date. Regiunea este formată din mai multe clădiri de centre de date (PRN1 și PRN2) situate în apropiere. Intenționăm să facem un singur panou de control care va gestiona toate serverele dintr-o singură regiune.
Dezvoltatorii de aplicații oferă servicii sub formă de joburi Tupperware. O lucrare constă din mai multe containere și toate rulează de obicei același cod de aplicație.
Tupperware este responsabil pentru furnizarea containerelor și gestionarea ciclului de viață al acestora. Este format din mai multe componente:
- Interfața Tupperware oferă API-uri pentru interfața cu utilizatorul, CLI și alte instrumente de automatizare prin care puteți interacționa cu Tupperware. Ele ascund întreaga structură internă de proprietarii de locuri de muncă Tupperware.
- Tupperware Scheduler este un panou de control responsabil de gestionarea containerului și a ciclului de viață al lucrării. Este implementat la nivel regional și global, unde planificatorul regional gestionează servere dintr-o regiune, iar planificatorul global gestionează servere din diferite regiuni. Schedul de planificare este împărțit în fragmente, iar fiecare fragment gestionează un set de joburi.
- Scheduler Proxy de la Tupperware ascunde fragmentarea internă și oferă un singur panou convenabil pentru utilizatorii Tupperware.
- Alocatorul Tupperware atribuie containere serverelor. Planificatorul se ocupă de oprirea, pornirea, actualizarea și trecerea la eroare a containerelor. În prezent, un singur alocator poate gestiona întreaga regiune fără a se împărți în fragmente. (Rețineți diferența de terminologie. De exemplu, programatorul din Tupperware corespunde panoului de control din , iar alocatorul Tupperware este numit planificator în Kubernetes.)
- Brokerul de resurse stochează sursa adevărului pentru evenimentele de server și de serviciu. Derulăm un broker de resurse pentru fiecare centru de date și stochează toate informațiile despre serverele din acel centru de date. Brokerul de resurse și sistemul de management al capacității, sau sistemul de furnizare a resurselor, decid în mod dinamic ce livrare planificator controlează ce server. Serviciul de verificare a stării de sănătate monitorizează serverele și stochează date despre starea lor de sănătate în brokerul de resurse. Dacă un server are probleme sau necesită întreținere, brokerul de resurse îi spune alocătorului și planificatorului să oprească containerele sau să le mute pe alte servere.
- Agentul Tupperware este un demon care rulează pe fiecare server care se ocupă de furnizarea și eliminarea containerelor. Aplicațiile rulează în interiorul unui container, ceea ce le oferă mai multă izolare și reproductibilitate. Pe Am descris deja modul în care containerele individuale Tupperware sunt create folosind imagini, btrfs, cgroupv2 și systemd.
Caracteristici distinctive ale Tupperware
Tupperware este similar în multe privințe cu alte sisteme de management al clusterelor, cum ar fi Kubernetes și , dar există și diferențe:
- Suport încorporat pentru servicii cu stat.
- Un singur panou de control pentru servere din diferite centre de date pentru a automatiza livrarea containerelor în funcție de intenție, dezafectarea clusterelor și întreținere.
- Diviziune clară a panoului de control pentru mărire.
- Calcularea elastică vă permite să distribuiți puterea între servicii în timp real.
Am dezvoltat aceste funcții interesante pentru a susține o varietate de aplicații fără stat și cu stat într-o flotă globală uriașă de servere partajate.
Suport încorporat pentru servicii cu stat.
Tupperware operează o varietate de servicii critice care stochează date persistente despre produse pentru Facebook, Instagram, Messenger și WhatsApp. Acestea pot fi depozite mari de perechi cheie-valoare (de ex. ) și monitorizarea depozitelor de date (de exemplu, и ). Menținerea serviciilor cu stat nu este ușoară, deoarece sistemul trebuie să se asigure că aprovizionarea cu containere poate rezista la întreruperi la scară largă, inclusiv întreruperi ale rețelei sau întreruperi de curent. Și, în timp ce tehnicile convenționale, cum ar fi distribuirea containerelor pe domenii de eroare, funcționează bine pentru serviciile fără stat, serviciile cu stat au nevoie de suport suplimentar.
De exemplu, dacă o defecțiune a serverului face ca o replică a bazei de date să fie indisponibilă, ar trebui să activați întreținerea automată care va actualiza nucleele pe 50 de servere dintr-un pool de 10? Depinde de situatie. Dacă unul dintre aceste 50 de servere are o altă replică a aceleiași baze de date, este mai bine să așteptați și să nu pierdeți 2 replici deodată. Pentru a lua în mod dinamic decizii cu privire la întreținerea și performanța sistemului, avem nevoie de informații despre replicarea datelor interne și logica de plasare a fiecărui serviciu cu stare.
Interfața TaskControl permite serviciilor cu state să influențeze deciziile care afectează disponibilitatea datelor. Folosind această interfață, planificatorul notifică aplicațiile externe despre operațiunile containerului (repornire, actualizare, migrare, întreținere). Un serviciu cu stare implementează un controler care îi spune Tupperware când este sigur să efectueze fiecare operație, iar aceste operațiuni pot fi schimbate sau amânate temporar. În exemplul de mai sus, controlerul bazei de date ar putea spune Tupperware să actualizeze 49 din cele 50 de servere, dar să lase un anumit server (X) în pace pentru moment. Ca urmare, dacă perioada de actualizare a nucleului trece și baza de date nu poate restabili replica problematică, Tupperware va actualiza în continuare serverul X.
Multe servicii stateful din Tupperware folosesc TaskControl nu direct, ci prin ShardManager, o platformă comună pentru crearea de servicii stateful pe Facebook. Cu Tupperware, dezvoltatorii își pot specifica intenția cu privire la modul exact în care containerele ar trebui să fie distribuite în centrele de date. Cu ShardManager, dezvoltatorii își specifică intenția cu privire la modul în care fragmentele de date ar trebui să fie distribuite în containere. ShardManager este conștient de plasarea datelor și replicarea aplicațiilor sale și comunică cu Tupperware prin interfața TaskControl pentru a programa operațiunile containerului fără implicarea directă a aplicației. Această integrare simplifică foarte mult gestionarea serviciilor stateful, dar TaskControl este capabil de mai mult. De exemplu, nivelul nostru web extins este apatrid și utilizează TaskControl pentru a ajusta dinamic rata actualizărilor containerelor. În cele din urmă pe zi, fără a compromite disponibilitatea.
Gestionarea serverelor din centrele de date
Când Tupperware a fost lansat pentru prima dată în 2011, fiecare cluster de servere era gestionat de un planificator separat. Pe atunci, un cluster Facebook era un grup de rafturi de servere conectate la un comutator de rețea, iar centrul de date găzduia mai multe clustere. Planificatorul putea gestiona doar servere dintr-un singur cluster, ceea ce înseamnă că sarcina nu s-ar putea răspândi în mai multe clustere. Infrastructura noastră a crescut, am anulat din ce în ce mai mult clusterele. Deoarece Tupperware nu a putut muta munca de la clusterul dezafectat în alte clustere fără modificări, a necesitat mult efort și o coordonare atentă între dezvoltatorii de aplicații și operatorii centrelor de date. Acest proces a dus la risipa de resurse atunci când serverele erau inactive luni de zile din cauza procedurilor de dezafectare.
Am creat un broker de resurse pentru a rezolva problema dezafectării clusterului și pentru a coordona alte tipuri de sarcini de întreținere. Brokerul de resurse ține evidența tuturor informațiilor fizice asociate cu un server și decide în mod dinamic care planificator controlează fiecare server. Conectarea dinamică a serverelor la programatori permite planificatorului să gestioneze serverele din diferite centre de date. Deoarece o lucrare Tupperware nu mai este limitată la un singur cluster, utilizatorii Tupperware pot specifica modul în care containerele ar trebui să fie distribuite pe domeniile de eroare. De exemplu, un dezvoltator își poate declara intenția (să zicem: „execuți lucrarea mea pe 2 domenii de eroare din regiunea PRN”) fără a specifica zone de disponibilitate specifice. Tupperware însuși va găsi servere potrivite pentru a implementa această intenție, chiar dacă clusterul sau serviciul este dezafectat.
Scalabil pentru a susține întregul sistem global
Din punct de vedere istoric, infrastructura noastră a fost împărțită în sute de pool-uri de servere dedicate pentru echipe individuale. Din cauza fragmentării și a lipsei de standarde, am avut costuri operaționale ridicate, iar serverele inactive au fost mai greu de utilizat din nou. La conferința de anul trecut am prezentat , care ar trebui să ne unească infrastructura într-un singur parc mare de servere. Dar un singur parc de servere are propriile sale dificultăți. Trebuie să îndeplinească anumite cerințe:
- Scalabilitate. Infrastructura noastră a crescut pe măsură ce am adăugat centre de date în fiecare regiune. Serverele au devenit mai mici și mai eficiente din punct de vedere energetic, așa că sunt mult mai multe în fiecare regiune. Ca urmare, un singur programator per regiune nu poate gestiona numărul de containere care pot fi rulate pe sute de mii de servere din fiecare regiune.
- Fiabilitate. Chiar dacă planificatorul poate fi mărit atât de mult, domeniul mare de aplicare al planificatorului înseamnă că există un risc mai mare de erori și o întreagă regiune de containere ar putea deveni de negestionat.
- Toleranță la erori. În cazul unei defecțiuni uriașe a infrastructurii (de exemplu, serverele care rulează programatorul eșuează din cauza unei defecțiuni a rețelei sau a unei întreruperi de curent), consecințele negative ar trebui să afecteze doar o parte din serverele din regiune.
- Ușurința de utilizare. Se poate părea că trebuie să rulați mai multe programatoare independente pentru o regiune. Dar dintr-o perspectivă de confort, un singur punct de intrare în pool-ul comun al unei regiuni facilitează gestionarea capacității și a locurilor de muncă.
Am împărțit planificatorul în fragmente pentru a rezolva problemele menținerii unui pool partajat mare. Fiecare fragment de planificator își gestionează propriul set de joburi în regiune, iar acest lucru reduce riscul asociat cu planificatorul. Pe măsură ce pool-ul partajat crește, putem adăuga mai multe fragmente de planificator. Pentru utilizatorii Tupperware, fragmentele și proxy-urile de planificare arată ca un singur panou de control. Nu trebuie să lucreze cu o grămadă de cioburi care orchestrează sarcini. Fragmentele de planificator sunt fundamental diferite de programatoarele de cluster pe care le folosim înainte, când panoul de control a fost partiționat fără a împărți static pool-ul partajat de servere în funcție de topologia rețelei.
Îmbunătățiți eficiența utilizării cu Elastic Computing
Cu cât infrastructura noastră este mai mare, cu atât este mai important să folosim serverele noastre în mod eficient pentru a optimiza costurile de infrastructură și a reduce încărcarea. Există două moduri de a crește eficiența utilizării serverului:
- Elastic computing - reduceți serviciile online în timpul orelor de liniște și utilizați servere eliberate pentru sarcinile de lucru offline, cum ar fi învățarea automată și joburile MapReduce.
- Supraîncărcare - Plasați serviciile online și încărcăturile de lucru în lot pe aceleași servere, astfel încât încărcările de lucru în lot să ruleze cu prioritate scăzută.
Blocajul din centrele noastre de date este . Prin urmare, preferăm serverele mici, eficiente din punct de vedere energetic, care împreună oferă mai multă putere de procesare. Din păcate, pe serverele mici cu CPU și memorie puțină, supraîncărcarea este mai puțin eficientă. Desigur, putem plasa mai multe containere de servicii mici pe un server mic, eficient din punct de vedere energetic, care consumă puține resurse de procesor și memorie, dar serviciile mari vor avea performanțe scăzute în această situație. Prin urmare, sfătuim dezvoltatorii serviciilor noastre mari să le optimizeze astfel încât să folosească întregul server.
Practic, îmbunătățim eficiența utilizării folosind calculul elastic. Multe dintre serviciile noastre majore, cum ar fi fluxul de știri, funcția de mesagerie și nivelul web front-end, variază în funcție de momentul zilei. Reducem în mod intenționat serviciile online în timpul orelor de liniște și folosim servere eliberate pentru sarcinile de lucru offline, cum ar fi învățarea automată și joburile MapReduce.
Știm din experiență că cel mai bine este să furnizați servere întregi ca unități de capacitate elastică, deoarece serviciile mari sunt atât donatori majori, cât și consumatori majori de capacitate elastică și sunt optimizate pentru a utiliza servere întregi. Când serverul este eliberat din serviciul online în timpul orelor de liniște, brokerul de resurse închiriază serverul planificatorului pentru a rula sarcini de lucru offline pe acesta. Dacă serviciul online se confruntă cu o sarcină maximă, brokerul de resurse reamintește rapid serverul împrumutat și, împreună cu planificatorul, îl returnează serviciului online.
Lecții învățate și planuri pentru viitor
În ultimii 8 ani, am dezvoltat Tupperware pentru a ține pasul cu creșterea rapidă a Facebook. Împărtășim ceea ce am învățat și sperăm că îi va ajuta pe alții să gestioneze infrastructurile în creștere rapidă:
- Configurați o conexiune flexibilă între panoul de control și serverele pe care le gestionează. Această flexibilitate permite panoului de control să gestioneze servere în diferite centre de date, ajută la automatizarea dezafectării și întreținerii clusterelor și permite alocarea dinamică a capacității folosind calculul elastic.
- Cu un singur panou de control în regiune, devine mai convenabil să lucrezi cu sarcini și mai ușor să gestionezi o flotă mare de servere partajate. Rețineți că panoul de control menține un singur punct de intrare, chiar dacă structura sa internă este separată din motive de scară sau toleranță la erori.
- Folosind un model de plugin, panoul de control poate notifica aplicațiile externe despre operațiunile viitoare ale containerului. În plus, serviciile stateful pot folosi interfața pluginului pentru a personaliza gestionarea containerelor. Cu acest model de plugin, panoul de control oferă simplitate în timp ce deservește eficient multe servicii diferite.
- Credem că calculul elastic, în care eliminăm servere întregi de la serviciile donatorilor pentru joburi în lot, învățare automată și alte servicii non-urgente, este modalitatea optimă de a îmbunătăți eficiența serverelor mici, eficiente din punct de vedere energetic.
Abia începem să implementăm . În prezent, aproximativ 20% dintre serverele noastre sunt într-un pool partajat. Pentru a atinge 100%, trebuie abordate multe probleme, inclusiv menținerea unui pool de stocare partajat, automatizarea întreținerii, gestionarea cerințelor între chiriași, îmbunătățirea utilizării serverului și îmbunătățirea suportului pentru sarcinile de lucru de învățare automată. Abia așteptăm să facem față acestor provocări și să ne împărtășim succesele.
Sursa: www.habr.com