Efikasno i pouzdano upravljanje klasterima u bilo kojoj skali uz Tupperware
Danas na uveli smo Tupperware, naš sistem za upravljanje klasterima koji orkestrira kontejnere na milionima servera koji pokreću skoro sve naše usluge. Tupperware smo prvi put implementirali 2011. godine i od tada je naša infrastruktura rasla do celine . Sve ovo vrijeme Tupperware nije stajao mirno i razvijao se s nama. Pokazat ćemo vam kako Tupperware pruža prvoklasno upravljanje klasterima, uključujući praktičnu podršku za usluge sa statusom, jedinstvenu kontrolnu ploču za sve centre podataka i mogućnost raspodjele kapaciteta između usluga u realnom vremenu. Također ćemo podijeliti lekcije koje smo naučili kako se naša infrastruktura razvija.
Tupperware obavlja različite zadatke. Programeri aplikacija ga koriste za isporuku i upravljanje aplikacijama. Pakuje kod aplikacije i zavisnosti u sliku i isporučuje je serverima kao kontejnere. Kontejneri pružaju izolaciju između aplikacija na istom serveru tako da se programeri bave logikom aplikacije i ne moraju brinuti o pronalaženju servera ili upravljanju ažuriranjima. Tupperware takođe prati performanse servera i ako pronađe kvar, prenosi kontejnere sa problematičnog servera.
Inženjeri za planiranje kapaciteta koriste Tupperware da dodijele kapacitet servera timovima na osnovu budžeta i ograničenja. Također ga koriste za poboljšanje korištenja servera. Operateri centara podataka se obraćaju Tupperware-u kako bi pravilno distribuirali kontejnere po podatkovnim centrima i zaustavili ili pomjerili kontejnere tokom održavanja. Zahvaljujući tome, održavanje servera, mreža i opreme zahtijeva minimalnu ljudsku intervenciju.
Tupperware arhitektura
Tupperware PRN arhitektura je jedan od regiona naših data centara. Region se sastoji od nekoliko zgrada data centara (PRN1 i PRN2) koje se nalaze u blizini. Planiramo napraviti jedan kontrolni panel koji će upravljati svim serverima u jednom regionu.
Programeri aplikacija pružaju usluge u obliku Tupperware poslova. Posao se sastoji od više kontejnera i svi oni obično pokreću isti kod aplikacije.
Tupperware je odgovoran za obezbjeđivanje kontejnera i upravljanje njihovim životnim ciklusom. Sastoji se od nekoliko komponenti:
- Tupperware frontend pruža API-je za korisničko sučelje, CLI i druge alate za automatizaciju putem kojih možete komunicirati s Tupperwareom. Oni skrivaju cjelokupnu internu strukturu od vlasnika poslova Tupperware-a.
- Tupperware Scheduler je kontrolni panel odgovoran za upravljanje kontejnerom i životnim ciklusom posla. Primjenjuje se na regionalnom i globalnom nivou, gdje regionalni planer upravlja serverima u jednom regionu, a globalni planer upravlja serverima iz različitih regiona. Planer je podijeljen na dijelove, a svaki dio upravlja skupom poslova.
- Tupperwareov Scheduler Proxy sakriva unutrašnje dijeljenje i pruža praktičan jedno staklo za korisnike Tupperwarea.
- Tupperware alokator dodjeljuje kontejnere serverima. Planer upravlja zaustavljanjem, pokretanjem, ažuriranjem i nadilaženjem kontejnera. Trenutno, jedan alokator može upravljati cijelom regijom bez podjele na dijelove. (Obratite pažnju na razliku u terminologiji. Na primjer, planer u Tupperware-u odgovara kontrolnoj tabli u , a Tupperware alokator se u Kubernetesu zove planer.)
- Posrednik resursa pohranjuje izvor istine za serverske i servisne događaje. Pokrećemo jednog posrednika resursa za svaki podatkovni centar i on pohranjuje sve informacije o serverima u tom podatkovnom centru. Posrednik resursa i sistem upravljanja kapacitetom, ili sistem obezbjeđivanja resursa, dinamički odlučuju koji planer isporuke kontroliše koji server. Usluga provjere zdravlja prati servere i pohranjuje podatke o njihovom zdravlju u posredniku resursa. Ako server ima problema ili mu je potrebno održavanje, posrednik resursa govori alokatoru i planeru da zaustave kontejnere ili ih premjeste na druge poslužitelje.
- Tupperware Agent je demon koji radi na svakom serveru koji upravlja obezbjeđivanjem i uklanjanjem kontejnera. Aplikacije se pokreću unutar kontejnera, što im daje veću izolaciju i reproduktivnost. On Već smo opisali kako se kreiraju pojedinačni Tupperware kontejneri koristeći slike, btrfs, cgroupv2 i systemd.
Prepoznatljive karakteristike Tupperware-a
Tupperware je na mnogo načina sličan drugim sistemima za upravljanje klasterima kao što su Kubernetes i , ali postoje i razlike:
- Ugrađena podrška za usluge sa statusom.
- Jedinstvena kontrolna tabla za servere u različitim data centrima za automatizaciju isporuke kontejnera na osnovu namere, dekomisije klastera i održavanja.
- Jasna podjela kontrolne ploče za zumiranje.
- Elastično računarstvo vam omogućava da distribuirate snagu između usluga u realnom vremenu.
Razvili smo ove sjajne funkcije za podršku niza aplikacija bez stanja i stanja u ogromnoj globalnoj floti zajedničkih servera.
Ugrađena podrška za usluge sa statusom.
Tupperware upravlja raznim kritičnim servisima koji pohranjuju trajne podatke o proizvodima za Facebook, Instagram, Messenger i WhatsApp. To mogu biti velika skladišta parova ključ/vrijednost (npr. ) i praćenje spremišta podataka (na primjer, и ). Održavanje usluga sa statusom nije lako, jer sistem mora osigurati da opskrba kontejnera može izdržati velike smetnje, uključujući prekide mreže ili nestanke struje. I dok konvencionalne tehnike, kao što je distribucija kontejnera kroz domene grešaka, dobro funkcionišu za usluge bez državljanstva, uslugama sa statusom potrebna je dodatna podrška.
Na primjer, ako kvar servera učini jednu repliku baze podataka nedostupnom, trebate li omogućiti automatsko održavanje koje će ažurirati jezgre na 50 servera iz grupe od 10? Zavisi od situacije. Ako jedan od ovih 50 servera ima drugu repliku iste baze podataka, bolje je pričekati i ne izgubiti 2 replike odjednom. Da bismo dinamički donosili odluke o održavanju i performansama sistema, potrebne su nam informacije o internoj replikaciji podataka i logici postavljanja svake usluge sa statusom.
Interfejs TaskControl omogućava uslugama sa stanjem da utiču na odluke koje utiču na dostupnost podataka. Koristeći ovo sučelje, planer obavještava vanjske aplikacije o operacijama kontejnera (ponovno pokretanje, ažuriranje, migracija, održavanje). Usluga koja prati stanje implementira kontroler koji govori Tupperware-u kada je bezbedno izvršiti svaku operaciju, a te operacije mogu biti zamenjene ili privremeno odložene. U gornjem primjeru, kontrolor baze podataka može reći Tupperware-u da ažurira 49 od 50 servera, ali da ostavi određeni server (X) na miru za sada. Kao rezultat toga, ako period ažuriranja kernela prođe, a baza podataka i dalje ne može vratiti problematičnu repliku, Tupperware će i dalje ažurirati X server.
Mnogi servisi za praćenje stanja u Tupperware-u koriste TaskControl ne direktno, već preko ShardManager-a, uobičajene platforme za kreiranje servisa sa stanjem na Facebooku. Uz Tupperware, programeri mogu odrediti svoju namjeru za tačno kako bi kontejneri trebali biti distribuirani u podatkovnim centrima. Sa ShardManager-om, programeri određuju svoju namjeru za to kako bi se dijelovi podataka trebali distribuirati po kontejnerima. ShardManager je svjestan postavljanja podataka i replikacije svojih aplikacija i komunicira sa Tupperware-om preko TaskControl interfejsa kako bi zakazao operacije kontejnera bez direktnog uključivanja aplikacije. Ova integracija uvelike pojednostavljuje upravljanje uslugama sa statusom, ali TaskControl je sposoban za više. Na primjer, naš opsežni web sloj je bez stanja i koristi TaskControl za dinamičko prilagođavanje stope ažuriranja kontejnera. Na kraju po danu bez ugrožavanja dostupnosti.
Upravljanje serverima u data centrima
Kada je Tupperware prvi put lansiran 2011. godine, svakim klasterom servera upravljao je poseban planer. Tada je Facebook klaster bio grupa serverskih rekova povezanih na jedan mrežni prekidač, a centar podataka je sadržavao nekoliko klastera. Planer je mogao upravljati serverima samo u jednom klasteru, što znači da se posao ne može širiti na više klastera. Naša infrastruktura je rasla, sve više smo otpisivali klastere. Budući da Tupperware nije mogao premjestiti posao iz klastera koji je povučen iz pogona u druge klastere bez promjena, to je zahtijevalo mnogo truda i pažljive koordinacije između programera aplikacija i operatera centara podataka. Ovaj proces je rezultirao gubitkom resursa kada su serveri bili neaktivni mjesecima zbog postupaka razgradnje.
Stvorili smo posrednika resursa da riješimo problem dekomisije klastera i koordiniramo druge vrste zadataka održavanja. Posrednik resursa prati sve fizičke informacije povezane sa serverom i dinamički odlučuje koji planer kontroliše svaki server. Dinamičko povezivanje servera sa planerima omogućava planeru da upravlja serverima u različitim centrima podataka. Budući da Tupperware posao više nije ograničen na jedan klaster, korisnici Tupperwarea mogu specificirati kako bi kontejneri trebali biti distribuirani u domenima greške. Na primjer, programer može deklarirati svoju namjeru (recimo: "pokreni moj posao na 2 domena greške u PRN regiji") bez navođenja posebnih zona dostupnosti. Sam Tupperware će pronaći odgovarajuće servere za implementaciju ove namjere, čak i ako se klaster ili usluga povuče iz upotrebe.
Skalabilan za podršku čitavom globalnom sistemu
Istorijski gledano, naša infrastruktura je bila podijeljena na stotine namjenskih serverskih grupa za pojedinačne timove. Zbog fragmentacije i nedostatka standarda, imali smo visoke operativne troškove, a servere u stanju mirovanja opet je bilo teže koristiti. Na prošlogodišnjoj konferenciji predstavili smo , koji bi trebao ujediniti našu infrastrukturu u veliki jedinstveni serverski park. Ali jedan park servera ima svoje poteškoće. Mora ispunjavati određene zahtjeve:
- Skalabilnost. Naša infrastruktura je rasla kako smo dodavali data centre u svakoj regiji. Serveri su postali manji i energetski efikasniji, pa ih je mnogo više u svakoj regiji. Kao rezultat toga, jedan planer po regiji ne može podnijeti broj kontejnera koji se mogu pokrenuti na stotinama hiljada servera u svakoj regiji.
- Pouzdanost. Čak i ako se planer može toliko povećati, veliki opseg planera znači da postoji veći rizik od grešaka i čitav region kontejnera može postati neupravljiv.
- Tolerancije grešaka. U slučaju velikog infrastrukturnog kvara (na primjer, serveri koji pokreću planer otkazuju zbog kvara na mreži ili nestanka struje), negativne posljedice bi trebale utjecati samo na dio servera u regiji.
- Pogodnost upotrebe. Može se činiti da trebate pokrenuti nekoliko nezavisnih planera za jednu regiju. Ali iz perspektive pogodnosti, jedna tačka ulaska u zajednički bazen regiona olakšava upravljanje kapacitetima i poslovima.
Podijelili smo planer na dijelove kako bismo riješili probleme održavanja velikog zajedničkog bazena. Svaki segment planera upravlja svojim skupom poslova u regiji, a to smanjuje rizik povezan s planerom. Kako zajednički skup raste, možemo dodati još dijelova planera. Za korisnike Tupperware-a, fragmenti i proxy programeri izgledaju kao jedan kontrolni panel. Ne moraju raditi s gomilom krhotina koje orkestriraju zadatke. Dionice planera se fundamentalno razlikuju od planera klastera koje smo koristili prije, kada je kontrolna tabla bila particionirana bez statičkog dijeljenja dijeljenog skupa servera prema topologiji mreže.
Poboljšajte efikasnost upotrebe pomoću Elastic Computing
Što je naša infrastruktura veća, to je važnije da naše servere efikasno koristimo za optimizaciju troškova infrastrukture i smanjenje opterećenja. Postoje dva načina za povećanje efikasnosti korišćenja servera:
- Elastično računarstvo - smanjite online usluge tokom tihih sati i koristite oslobođene servere za vanmrežna radna opterećenja, kao što su mašinsko učenje i MapReduce poslovi.
- Preopterećenje – Postavite online usluge i grupna radna opterećenja na iste servere tako da se grupna radna opterećenja pokreću s niskim prioritetom.
Usko grlo u našim data centrima je . Stoga preferiramo male, energetski efikasne servere koji zajedno pružaju više procesorske snage. Nažalost, na malim serverima sa malo CPU-a i memorije, preopterećenje je manje efikasno. Naravno, na jedan mali energetski efikasan server možemo postaviti nekoliko kontejnera malih servisa koji troše malo procesorskih resursa i memorije, ali veliki servisi će u ovoj situaciji imati niske performanse. Stoga savjetujemo programere naših velikih servisa da ih optimiziraju tako da koriste cijele servere.
U osnovi, poboljšavamo efikasnost korištenja koristeći elastično računarstvo. Mnoge od naših glavnih usluga, kao što su News Feed, funkcija razmjene poruka i front-end web nivo, razlikuju se u zavisnosti od doba dana. Namjerno smanjujemo mrežne usluge tokom tihih sati i koristimo oslobođene servere za vanmrežna radna opterećenja, kao što su mašinsko učenje i MapReduce poslovi.
Iz iskustva znamo da je najbolje osigurati cijele servere kao jedinice elastičnog kapaciteta jer su velike usluge i glavni donatori i glavni potrošači elastičnog kapaciteta, i optimizirani su za korištenje cijelih servera. Kada se server oslobodi iz online usluge tokom tihih sati, posrednik resursa iznajmljuje server planeru da na njemu pokreće vanmrežna radna opterećenja. Ako mrežna usluga doživi najveće opterećenje, posrednik resursa brzo poziva pozajmljeni server i, zajedno sa planerom, vraća ga online usluzi.
Naučene lekcije i planovi za budućnost
U proteklih 8 godina razvijali smo Tupperware kako bismo pratili brzi rast Facebooka. Dijelimo ono što smo naučili i nadamo se da će pomoći drugima da upravljaju infrastrukturama koje se brzo rastu:
- Postavite fleksibilnu vezu između kontrolne ploče i servera kojima upravlja. Ova fleksibilnost omogućava kontrolnom panelu da upravlja serverima u različitim podatkovnim centrima, pomaže u automatizaciji razgradnje i održavanja klastera i omogućava dinamičku alokaciju kapaciteta pomoću elastičnog računarstva.
- Sa jednom kontrolnom pločom u regionu, postaje praktičnije raditi sa zadacima i lakše upravljati velikom flotom zajedničkih servera. Imajte na umu da kontrolna tabla održava jednu tačku ulaska, čak i ako je njena unutrašnja struktura odvojena zbog razmjera ili tolerancije grešaka.
- Koristeći model dodatka, kontrolna tabla može obavijestiti vanjske aplikacije o predstojećim operacijama kontejnera. Štaviše, usluge sa statusom mogu koristiti sučelje dodataka za prilagođavanje upravljanja kontejnerima. Sa ovim modelom dodataka, kontrolna tabla pruža jednostavnost dok efikasno opslužuje mnoge različite usluge sa podacima o stanju.
- Vjerujemo da je elastično računarstvo, gdje oduzimamo cijele servere donatorskim uslugama za grupne poslove, mašinsko učenje i druge usluge koje nisu hitne, optimalan način za poboljšanje efikasnosti malih, energetski efikasnih servera.
Tek počinjemo sa implementacijom . Trenutno je oko 20% naših servera u zajedničkom bazenu. Da bi se postiglo 100%, potrebno je riješiti mnoga pitanja, uključujući održavanje dijeljenog skladišnog spremišta, automatiziranje održavanja, upravljanje zahtjevima među zakupcima, poboljšanje korištenja servera i poboljšanje podrške za radna opterećenja strojnog učenja. Jedva čekamo da prihvatimo ove izazove i podijelimo svoje uspjehe.
izvor: www.habr.com