Učinkovito in zanesljivo upravljanje grozdov v katerem koli obsegu s Tupperware
Danes naprej predstavili smo Tupperware, naš sistem za upravljanje gruče, ki orkestrira vsebnike v milijonih strežnikov, ki izvajajo skoraj vse naše storitve. Tupperware smo prvič uvedli leta 2011 in od takrat je naša infrastruktura rasla do celega . Ves ta čas Tupperware ni miroval in se je razvijal z nami. Pokazali vam bomo, kako Tupperware zagotavlja prvovrstno upravljanje gruče, vključno s priročno podporo za storitve s spremljanjem stanja, enotno nadzorno ploščo za vse podatkovne centre in zmožnostjo porazdelitve zmogljivosti med storitvami v realnem času. Delili bomo tudi izkušnje, ki smo se jih naučili, ko se bo naša infrastruktura razvijala.
Tupperware opravlja različne naloge. Razvijalci aplikacij ga uporabljajo za dostavo in upravljanje aplikacij. Zapakira kodo aplikacije in odvisnosti v sliko ter jo dostavi strežnikom kot vsebnike. Vsebniki zagotavljajo izolacijo med aplikacijami na istem strežniku, tako da se razvijalci ukvarjajo z logiko aplikacij in jim ni treba skrbeti za iskanje strežnikov ali upravljanje posodobitev. Tupperware spremlja tudi delovanje strežnika in če najde napako, prenese vsebnike s problematičnega strežnika.
Inženirji za načrtovanje zmogljivosti uporabljajo Tupperware za dodelitev zmogljivosti strežnika ekipam na podlagi proračuna in omejitev. Uporabljajo ga tudi za izboljšanje izkoriščenosti strežnika. Operaterji podatkovnih centrov se obrnejo na Tupperware, da pravilno razporedijo vsebnike po podatkovnih centrih in ustavijo ali premaknejo vsebnike med vzdrževanjem. Zahvaljujoč temu vzdrževanje strežnikov, omrežij in opreme zahteva minimalno človeško posredovanje.
Tupperware arhitektura
Arhitektura Tupperware PRN je ena od regij naših podatkovnih centrov. Regijo sestavlja več zgradb podatkovnih centrov (PRN1 in PRN2), ki se nahajajo v bližini. Načrtujemo izdelavo ene nadzorne plošče, ki bo upravljala z vsemi strežniki v eni regiji.
Razvijalci aplikacij zagotavljajo storitve v obliki delovnih mest Tupperware. Opravilo je sestavljeno iz več vsebnikov in vsi običajno izvajajo isto kodo aplikacije.
Tupperware je odgovoren za zagotavljanje vsebnikov in upravljanje njihovega življenjskega cikla. Sestavljen je iz več komponent:
- Tupperware frontend ponuja API-je za uporabniški vmesnik, CLI in druga orodja za avtomatizacijo, prek katerih lahko komunicirate s Tupperware. Celotno notranjo strukturo skrivajo pred lastniki delovnih mest Tupperware.
- Tupperware Scheduler je nadzorna plošča, odgovorna za upravljanje vsebnika in življenjskega cikla opravil. Razmeščen je na regionalni in globalni ravni, kjer regionalni razporejevalnik upravlja strežnike v eni regiji, globalni razporejevalnik pa strežnike iz različnih regij. Razporejevalnik je razdeljen na segmente in vsak del upravlja nabor opravil.
- Tupperwarejev Scheduler Proxy skrije notranje drobljenje in uporabnikom Tupperware nudi priročno enojno steklo.
- Dodeljevalnik Tupperware dodeli vsebnike strežnikom. Razporejevalnik obravnava zaustavitev, zagon, posodabljanje in samodejni preklop vsebnikov. Trenutno lahko en razdelilnik upravlja celotno regijo brez razdelitve na drobce. (Upoštevajte razliko v terminologiji. Na primer, razporejevalnik v Tupperware ustreza nadzorni plošči v , dodeljevalec Tupperware pa se v Kubernetesu imenuje razporejevalnik.)
- Posrednik virov shrani vir resnice za dogodke strežnika in storitev. Za vsak podatkovni center izvajamo enega posrednika virov, ki shranjuje vse informacije o strežnikih v tem podatkovnem centru. Posrednik virov in sistem za upravljanje zmogljivosti ali sistem za zagotavljanje virov se dinamično odločita, kateri razporejevalnik nadzira kateri strežnik. Storitev preverjanja stanja spremlja strežnike in shranjuje podatke o njihovem zdravju v posredniku virov. Če ima strežnik težave ali potrebuje vzdrževanje, posrednik virov sporoči dodeljevalcu in razporejevalniku, naj zaustavi vsebnike ali jih premakne na druge strežnike.
- Tupperware Agent je demon, ki se izvaja na vsakem strežniku in skrbi za zagotavljanje in odstranjevanje vsebnikov. Aplikacije se izvajajo znotraj vsebnika, kar jim daje večjo izolacijo in ponovljivost. Vklopljeno Opisali smo že, kako so posamezni vsebniki Tupperware ustvarjeni z uporabo slik, btrfs, cgroupv2 in systemd.
Posebnosti Tupperware
Tupperware je v mnogih pogledih podoben drugim sistemom za upravljanje gruč, kot sta Kubernetes in , vendar obstajajo tudi razlike:
- Vgrajena podpora za storitve s spremljanjem stanja.
- Enotna nadzorna plošča za strežnike v različnih podatkovnih centrih za avtomatizacijo dostave vsebnikov na podlagi namena, razgradnje gruč in vzdrževanja.
- Jasna razdelitev nadzorne plošče za povečavo.
- Elastično računalništvo vam omogoča porazdelitev moči med storitvami v realnem času.
Te odlične funkcije smo razvili za podporo različnih aplikacij brez stanja in stanja v ogromni globalni floti strežnikov v skupni rabi.
Vgrajena podpora za storitve s spremljanjem stanja.
Tupperware upravlja različne kritične storitve s spremljanjem stanja, ki shranjujejo obstojne podatke o izdelkih za Facebook, Instagram, Messenger in WhatsApp. To so lahko velike shrambe parov ključ-vrednost (npr. ) in spremljanje skladišč podatkov (npr. и ). Vzdrževanje storitev s stanjem ni enostavno, saj mora sistem zagotoviti, da lahko dobava vsebnikov prenese obsežne motnje, vključno z izpadi omrežja ali izpadi električne energije. In medtem ko običajne tehnike, kot je distribucija vsebnikov po domenah napak, dobro delujejo pri storitvah brez stanja, storitve s stanjem potrebujejo dodatno podporo.
Na primer, če zaradi okvare strežnika ena replika baze podatkov ni na voljo, ali bi morali omogočiti samodejno vzdrževanje, ki bo posodobilo jedra na 50 strežnikih iz skupine 10? Odvisno od situacije. Če ima eden od teh 50 strežnikov drugo repliko iste baze podatkov, je bolje počakati in ne izgubiti 2 replik hkrati. Za dinamično sprejemanje odločitev o vzdrževanju in delovanju sistema potrebujemo informacije o notranji replikaciji podatkov in logiki umestitve vsake storitve s stanjem.
Vmesnik TaskControl omogoča storitvam s stanjem, da vplivajo na odločitve, ki vplivajo na razpoložljivost podatkov. S pomočjo tega vmesnika razporejevalnik obvesti zunanje aplikacije o operacijah vsebnika (ponovni zagon, posodobitev, selitev, vzdrževanje). Storitev s spremljanjem stanja izvaja krmilnik, ki Tupperwareju pove, kdaj je varno izvesti vsako operacijo, te operacije pa je mogoče zamenjati ali začasno odložiti. V zgornjem primeru bi krmilnik baze podatkov lahko ukazal Tupperwareju, naj posodobi 49 od 50 strežnikov, vendar pusti določen strežnik (X) pri miru. Posledično, če obdobje posodobitve jedra mine in baza podatkov še vedno ne more obnoviti problematične replike, bo Tupperware še vedno posodobil strežnik X.
Številne storitve s spremljanjem stanja v Tupperware ne uporabljajo TaskControl neposredno, temveč prek ShardManagerja, skupne platforme za ustvarjanje storitev s spremljanjem stanja na Facebooku. S Tupperware lahko razvijalci natančno določijo, kako naj bodo vsebniki razporejeni po podatkovnih centrih. S ShardManagerjem razvijalci določijo svojo namero, kako naj bodo podatkovni drobci porazdeljeni po vsebnikih. ShardManager se zaveda umeščanja podatkov in replikacije svojih aplikacij ter komunicira s Tupperware prek vmesnika TaskControl za načrtovanje operacij vsebnika brez neposredne vpletenosti aplikacije. Ta integracija močno poenostavi upravljanje storitev s stanjem, vendar je TaskControl sposoben več. Na primer, naša obsežna spletna raven je brez stanja in uporablja TaskControl za dinamično prilagajanje stopnje posodobitev vsebnikov. Sčasoma na dan brez ogrožanja razpoložljivosti.
Upravljanje strežnikov v podatkovnih centrih
Ko je Tupperware prvič predstavljen leta 2011, je vsako strežniško gručo upravljal ločen razporejevalnik. Takrat je bil grozd Facebook skupina strežniških stojal, povezanih z enim omrežnim stikalom, podatkovni center pa je vseboval več grozdov. Razporejevalnik lahko upravlja samo strežnike v eni gruči, kar pomeni, da se opravilo ne more razširiti na več gruč. Naša infrastruktura je rasla, vse bolj smo odpisovali grozde. Ker Tupperware ni mogel brez sprememb prenesti opravila iz razgrajene gruče v druge gruče, je bilo potrebno veliko truda in skrbnega usklajevanja med razvijalci aplikacij in operaterji podatkovnih centrov. Ta postopek je povzročil izgubljene vire, ko so bili strežniki več mesecev nedejavni zaradi postopkov razgradnje.
Ustvarili smo posrednika virov za reševanje problema razgradnje gruče in usklajevanje drugih vrst vzdrževalnih nalog. Posrednik virov spremlja vse fizične informacije, povezane s strežnikom, in se dinamično odloči, kateri razporejevalnik nadzoruje vsak strežnik. Dinamično povezovanje strežnikov z razporejevalniki omogoča razporejevalniku upravljanje strežnikov v različnih podatkovnih centrih. Ker delo Tupperware ni več omejeno na eno samo gručo, lahko uporabniki Tupperware določijo, kako naj bodo vsebniki porazdeljeni po domenah napak. Na primer, razvijalec lahko izjavi svoj namen (recimo: "zaženi svoje delo na 2 domenah napak v regiji PRN"), ne da bi določil posebna območja razpoložljivosti. Tupperware bo sam našel ustrezne strežnike za izvedbo te namere, tudi če bo gruča ali storitev ukinjena.
Razširljiv za podporo celotnemu globalnemu sistemu
V preteklosti je bila naša infrastruktura razdeljena na stotine namenskih strežniških skupin za posamezne ekipe. Zaradi razdrobljenosti in pomanjkanja standardov smo imeli visoke operativne stroške, nedejavne strežnike pa je bilo težje ponovno uporabiti. Na lanski konferenci smo predstavili , ki naj bi našo infrastrukturo združil v velik enoten strežniški park. Toda park z enim strežnikom ima svoje težave. Izpolnjevati mora določene zahteve:
- Razširljivost. Naša infrastruktura je rasla, ko smo dodajali podatkovne centre v vsaki regiji. Strežniki so postali manjši in energetsko učinkovitejši, zato jih je v vsaki regiji veliko več. Posledično en sam razporejevalnik na regijo ne more obravnavati števila vsebnikov, ki jih je mogoče izvajati na sto tisočih strežnikih v vsaki regiji.
- Zanesljivost. Tudi če je razporejevalnik mogoče toliko povečati, velik obseg razporejevalnika pomeni, da obstaja večje tveganje za napake in celotna regija vsebnikov lahko postane neobvladljiva.
- Toleranca napak. V primeru velike okvare infrastrukture (na primer strežniki, na katerih se izvaja razporejevalnik, odpovejo zaradi okvare omrežja ali izpada električne energije), bi morale negativne posledice vplivati le na del strežnikov v regiji.
- Enostavnost uporabe. Morda se zdi, da morate zagnati več neodvisnih razporejevalcev za eno regijo. Toda z vidika udobja ena sama vstopna točka v skupni bazen regije olajša upravljanje zmogljivosti in delovnih mest.
Razporejevalnik smo razdelili na drobce, da bi rešili težave pri vzdrževanju velikega skupnega bazena. Vsak del razporejevalnika upravlja svoj nabor opravil v regiji, kar zmanjša tveganje, povezano z razporejevalnikom. Ko skupni bazen raste, lahko dodamo več razporejevalnikov. Za uporabnike Tupperware so razdelki in posredniki razporejevalnika videti kot ena nadzorna plošča. Ni jim treba delati s kupom drobcev, ki orkestrirajo naloge. Razporejevalnik razporejevalnikov se bistveno razlikuje od načrtovalcev gruč, ki smo jih uporabljali prej, ko je bila nadzorna plošča particionirana brez statične delitve skupnega nabora strežnikov glede na topologijo omrežja.
Izboljšajte učinkovitost uporabe z elastičnim računalništvom
Večja kot je naša infrastruktura, bolj pomembno je, da naše strežnike uporabljamo učinkovito za optimizacijo stroškov infrastrukture in zmanjšanje obremenitve. Učinkovitost uporabe strežnika lahko povečate na dva načina:
- Elastično računalništvo – zmanjšajte spletne storitve v mirnih urah in uporabite sproščene strežnike za delovne obremenitve brez povezave, kot so strojno učenje in opravila MapReduce.
- Preobremenitev – postavite spletne storitve in paketne delovne obremenitve na iste strežnike, tako da se paketne delovne obremenitve izvajajo z nizko prioriteto.
Ozko grlo v naših podatkovnih centrih je . Zato imamo raje majhne, energetsko učinkovite strežnike, ki skupaj zagotavljajo več procesorske moči. Na žalost je na majhnih strežnikih z malo procesorja in pomnilnika preobremenitev manj učinkovita. Seveda lahko na en majhen energetsko učinkovit strežnik postavimo več vsebnikov majhnih storitev, ki porabijo malo procesorskih virov in pomnilnika, vendar bodo velike storitve v tem primeru imele nizko zmogljivost. Zato razvijalcem naših velikih storitev svetujemo, da jih optimizirajo tako, da bodo uporabljali celotne strežnike.
V bistvu izboljšamo učinkovitost uporabe z elastičnim računalništvom. Številne naše glavne storitve, kot so vir novic, funkcija sporočanja in sprednja spletna raven, se razlikujejo glede na čas dneva. Spletne storitve namenoma zmanjšamo v mirnih urah in uporabljamo sproščene strežnike za delovne obremenitve brez povezave, kot so strojno učenje in opravila MapReduce.
Iz izkušenj vemo, da je najbolje zagotoviti celotne strežnike kot enote elastične zmogljivosti, ker so velike storitve glavni donatorji in glavni porabniki elastične zmogljivosti in so optimizirane za uporabo celotnih strežnikov. Ko se strežnik sprosti iz spletne storitve med mirnimi urami, posrednik virov zakupi strežnik razporejevalniku, da na njem izvaja delovne obremenitve brez povezave. Če spletna storitev doživi največjo obremenitev, posrednik virov hitro odpokliče izposojeni strežnik in ga skupaj s planerjem vrne spletni storitvi.
Pridobljene lekcije in načrti za prihodnost
V zadnjih 8 letih smo razvijali Tupperware, da bi sledili hitri rasti Facebooka. Delimo, kar smo se naučili, in upamo, da bo drugim pomagalo upravljati hitro rastoče infrastrukture:
- Vzpostavite prilagodljivo povezavo med nadzorno ploščo in strežniki, ki jih upravlja. Ta prilagodljivost nadzorni plošči omogoča upravljanje strežnikov v različnih podatkovnih centrih, pomaga avtomatizirati razgradnjo in vzdrževanje gruč ter omogoča dinamično dodeljevanje zmogljivosti z uporabo elastičnega računalništva.
- Z eno samo nadzorno ploščo v regiji postane bolj priročno delo z nalogami in lažje upravljanje velike skupne strežniške flote. Upoštevajte, da nadzorna plošča vzdržuje eno samo vstopno točko, tudi če je njena notranja struktura ločena zaradi velikosti ali tolerance napak.
- Z uporabo modela vtičnika lahko nadzorna plošča obvesti zunanje aplikacije o prihajajočih operacijah vsebnika. Poleg tega lahko storitve s spremljanjem stanja uporabljajo vmesnik vtičnika za prilagoditev upravljanja vsebnika. S tem modelom vtičnika nadzorna plošča zagotavlja preprostost, hkrati pa učinkovito služi številnim različnim storitvam s spremljanjem stanja.
- Verjamemo, da je elastično računalništvo, pri katerem od donatorskih storitev odvzamemo cele strežnike za paketna opravila, strojno učenje in druge nenujne storitve, optimalen način za izboljšanje učinkovitosti majhnih, energetsko učinkovitih strežnikov.
Šele začenjamo izvajati . Trenutno je približno 20 % naših strežnikov v skupnem bazenu. Da bi dosegli 100 %, je treba obravnavati številna vprašanja, vključno z vzdrževanjem skupnega prostora za shranjevanje, avtomatizacijo vzdrževanja, upravljanjem zahtev med najemniki, izboljšanjem uporabe strežnika in izboljšanjem podpore za delovne obremenitve strojnega učenja. Komaj čakamo, da sprejmemo te izzive in delimo svoje uspehe.
Vir: www.habr.com