Učinkovito i pouzdano upravljanje klasterima na bilo kojoj razini uz Tupperware
Danas na predstavili smo Tupperware, naš sustav upravljanja klasterima koji upravlja spremnicima na milijunima poslužitelja koji pokreću gotovo sve naše usluge. Tupperware smo prvi put postavili 2011. i od tada je naša infrastruktura rasla na cjelinu . Sve ovo vrijeme Tupperware nije stajao na mjestu i razvijao se s nama. Pokazat ćemo vam kako Tupperware pruža prvoklasno upravljanje klasterom, uključujući praktičnu podršku za usluge s praćenjem stanja, jednu kontrolnu ploču za sve podatkovne centre i mogućnost raspodjele kapaciteta između usluga u stvarnom vremenu. Također ćemo podijeliti lekcije koje smo naučili kako se naša infrastruktura razvija.
Tupperware obavlja različite zadatke. Programeri aplikacija koriste ga za isporuku i upravljanje aplikacijama. Pakira aplikacijski kod i ovisnosti u sliku i isporučuje je poslužiteljima kao spremnike. Spremnici pružaju izolaciju između aplikacija na istom poslužitelju tako da se programeri bave logikom aplikacije i ne moraju brinuti o pronalaženju poslužitelja ili upravljanju ažuriranjima. Tupperware također prati performanse poslužitelja, a ako pronađe kvar, prenosi spremnike s problematičnog poslužitelja.
Inženjeri za planiranje kapaciteta koriste Tupperware za dodjelu kapaciteta poslužitelja timovima na temelju proračuna i ograničenja. Također ga koriste za poboljšanje iskorištenosti poslužitelja. Operateri podatkovnih centara obraćaju se Tupperwareu za pravilnu distribuciju spremnika po podatkovnim centrima i zaustavljanje ili premještanje spremnika tijekom održavanja. Zahvaljujući tome, održavanje poslužitelja, mreža i opreme zahtijeva minimalnu ljudsku intervenciju.
Tupperware arhitektura
Tupperware PRN arhitektura jedna je od regija naših podatkovnih centara. Regija se sastoji od nekoliko zgrada podatkovnih centara (PRN1 i PRN2) smještenih u blizini. Planiramo napraviti jednu kontrolnu ploču koja će upravljati svim serverima u jednoj regiji.
Programeri aplikacija pružaju usluge u obliku Tupperware poslova. Posao se sastoji od više spremnika i svi obično pokreću isti kod aplikacije.
Tupperware je odgovoran za pripremu spremnika i upravljanje njihovim životnim ciklusom. Sastoji se od nekoliko komponenti:
- Tupperware sučelje pruža API-je za korisničko sučelje, CLI i druge alate za automatizaciju putem kojih možete komunicirati s Tupperwareom. Skrivaju cjelokupnu unutarnju strukturu od vlasnika poslova Tupperwarea.
- Tupperware Scheduler je upravljačka ploča odgovorna za upravljanje spremnikom i životnim ciklusom posla. Primjenjuje se na regionalnoj i globalnoj razini, gdje regionalni planer upravlja poslužiteljima u jednoj regiji, a globalni planer upravlja poslužiteljima iz različitih regija. Planer je podijeljen na shardove, a svaki shard upravlja skupom poslova.
- Tupperwareov Scheduler Proxy skriva interno dijeljenje i pruža prikladno jedno staklo za korisnike Tupperwarea.
- Tupperware alokator dodjeljuje spremnike poslužiteljima. Raspoređivač upravlja zaustavljanjem, pokretanjem, ažuriranjem i prelaskom spremnika. Trenutačno jedan alokator može upravljati cijelom regijom bez dijeljenja na dijelove. (Uočite razliku u terminologiji. Na primjer, planer u Tupperwareu odgovara upravljačkoj ploči u , a Tupperware allocator se u Kubernetesu naziva planer.)
- Posrednik resursa pohranjuje izvor istine za događaje poslužitelja i usluge. Pokrećemo jednog brokera resursa za svaki podatkovni centar i on pohranjuje sve informacije o poslužiteljima u tom podatkovnom centru. Posrednik resursa i sustav upravljanja kapacitetom, ili sustav za pružanje resursa, dinamički odlučuju koji raspoređivač isporuke kontrolira koji poslužitelj. Usluga provjere zdravlja nadzire poslužitelje i pohranjuje podatke o njihovom zdravlju u brokeru resursa. Ako poslužitelj ima problema ili mu je potrebno održavanje, posrednik resursa govori alokatoru i planeru da zaustave spremnike ili ih premjeste na druge poslužitelje.
- Tupperware Agent demon je pokrenut na svakom poslužitelju koji upravlja pripremom i uklanjanjem spremnika. Aplikacije se pokreću unutar spremnika, što im daje veću izolaciju i ponovljivost. Na Već smo opisali kako se pojedinačni Tupperware spremnici kreiraju pomoću slika, btrfs, cgroupv2 i systemd.
Posebnosti Tupperwarea
Tupperware je na mnogo načina sličan drugim sustavima za upravljanje klasterima kao što su Kubernetes i , ali postoje i razlike:
- Ugrađena podrška za usluge s praćenjem stanja.
- Jedna upravljačka ploča za poslužitelje u različitim podatkovnim centrima za automatizaciju isporuke spremnika na temelju namjere, dekomisioniranja klastera i održavanja.
- Jasna podjela kontrolne ploče za zumiranje.
- Elastično računalstvo omogućuje vam raspodjelu snage između usluga u stvarnom vremenu.
Razvili smo ove sjajne značajke kako bismo podržali razne aplikacije bez statusa i statusa u ogromnoj globalnoj floti dijeljenih poslužitelja.
Ugrađena podrška za usluge s praćenjem stanja.
Tupperware upravlja nizom kritičnih servisa koji pohranjuju trajne podatke o proizvodima za Facebook, Instagram, Messenger i WhatsApp. To mogu biti velika spremišta parova ključ-vrijednost (npr. ) i nadgledanje spremišta podataka (na primjer, и ). Održavanje statusnih usluga nije jednostavno, jer sustav mora osigurati da opskrba spremnicima može izdržati velike poremećaje, uključujući prekide mreže ili nestanke struje. I dok konvencionalne tehnike, kao što je distribucija spremnika preko domena greške, dobro funkcioniraju za usluge bez statusa, usluge sa statusom trebaju dodatnu podršku.
Na primjer, ako kvar poslužitelja učini jednu repliku baze podataka nedostupnom, trebate li omogućiti automatsko održavanje koje će ažurirati jezgre na 50 poslužitelja iz grupe od 10 50? Ovisi o situaciji. Ako jedan od ovih 2 poslužitelja ima drugu repliku iste baze podataka, bolje je pričekati i ne izgubiti XNUMX replike odjednom. Kako bismo dinamički donosili odluke o održavanju i izvedbi sustava, potrebne su nam informacije o internoj replikaciji podataka i logici postavljanja svake usluge s praćenjem stanja.
Sučelje TaskControl omogućuje statusnim uslugama da utječu na odluke koje utječu na dostupnost podataka. Pomoću ovog sučelja planer obavještava vanjske aplikacije o operacijama spremnika (ponovno pokretanje, ažuriranje, migracija, održavanje). Usluga s praćenjem stanja implementira kontroler koji govori Tupperwareu kada je sigurno izvršiti svaku operaciju, a te se operacije mogu zamijeniti ili privremeno odgoditi. U gornjem primjeru, kontroler baze podataka mogao je reći Tupperwareu da ažurira 49 od 50 poslužitelja, ali za sada ostavi određeni poslužitelj (X). Kao rezultat toga, ako razdoblje ažuriranja kernela prođe, a baza podataka i dalje ne može vratiti problematičnu repliku, Tupperware će i dalje ažurirati X poslužitelj.
Mnogi statusni servisi u Tupperwareu koriste TaskControl ne izravno, već kroz ShardManager, uobičajenu platformu za kreiranje statusnih servisa na Facebooku. S Tupperwareom, programeri mogu specificirati svoju namjeru kako točno spremnici trebaju biti raspoređeni po podatkovnim centrima. Uz ShardManager, programeri određuju svoju namjeru kako bi se fragmenti podataka trebali distribuirati po spremnicima. ShardManager je svjestan smještaja podataka i replikacije svojih aplikacija i komunicira s Tupperwareom putem sučelja TaskControl za planiranje operacija spremnika bez izravnog uključivanja aplikacije. Ova integracija uvelike pojednostavljuje upravljanje uslugama s praćenjem stanja, ali TaskControl može više. Na primjer, naša opsežna web razina je bez stanja i koristi TaskControl za dinamičko prilagođavanje stope ažuriranja spremnika. Eventualno dnevno bez ugrožavanja dostupnosti.
Upravljanje poslužiteljima u podatkovnim centrima
Kada je Tupperware prvi put lansiran 2011., svakim klasterom poslužitelja upravljao je zasebni planer. Tada je Facebook klaster bio skupina poslužiteljskih regala povezanih s jednim mrežnim preklopnikom, a podatkovni centar je sadržavao nekoliko klastera. Planer je mogao upravljati samo poslužiteljima u jednom klasteru, što znači da se posao nije mogao proširiti na više klastera. Infrastruktura nam je rasla, klastere smo sve više otpisivali. Budući da Tupperware nije mogao bez promjena premjestiti posao iz klastera koji je izašao iz upotrebe u druge klastere, bilo je potrebno mnogo truda i pažljive koordinacije između programera aplikacija i operatera podatkovnog centra. Ovaj je proces rezultirao izgubljenim resursima kada su poslužitelji mjesecima bili u mirovanju zbog postupaka stavljanja izvan pogona.
Stvorili smo brokera resursa za rješavanje problema prestanka rada klastera i koordinaciju drugih vrsta zadataka održavanja. Posrednik resursa prati sve fizičke podatke povezane s poslužiteljem i dinamički odlučuje koji planer kontrolira svaki poslužitelj. Dinamičko povezivanje poslužitelja s planerima omogućuje planeru upravljanje poslužiteljima u različitim podatkovnim centrima. Budući da posao Tupperwarea više nije ograničen na jedan klaster, korisnici Tupperwarea mogu odrediti kako se spremnici trebaju distribuirati po domenama grešaka. Na primjer, razvojni programer može objaviti svoju namjeru (recimo: "izvršiti svoj posao na 2 domene greške u PRN regiji") bez navođenja određenih zona dostupnosti. Tupperware će sam pronaći odgovarajuće poslužitelje za provedbu ove namjere, čak i ako se klaster ili usluga povuku iz upotrebe.
Skalabilan za podršku cijelom globalnom sustavu
Povijesno gledano, naša je infrastruktura bila podijeljena na stotine namjenskih skupova poslužitelja za pojedinačne timove. Zbog fragmentacije i nedostatka standarda imali smo visoke operativne troškove, a neaktivne poslužitelje bilo je teže ponovno koristiti. Na prošlogodišnjoj konferenciji predstavili smo , koji bi trebao ujediniti našu infrastrukturu u veliki pojedinačni poslužiteljski park. Ali park s jednim poslužiteljem ima svoje poteškoće. Mora ispunjavati određene zahtjeve:
- Skalabilnost. Naša je infrastruktura rasla kako smo dodavali podatkovne centre u svakoj regiji. Poslužitelji su postali manji i energetski učinkovitiji, pa ih je u svakoj regiji mnogo više. Kao rezultat toga, jedan planer po regiji ne može podnijeti broj spremnika koji se mogu pokrenuti na stotinama tisuća poslužitelja 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 pogrešaka i čitava regija spremnika mogla bi postati neupravljiva.
- Tolerancija kvarova. U slučaju velikog kvara infrastrukture (na primjer, poslužitelji koji pokreću planer zakažu zbog kvara na mreži ili nestanka struje), negativne bi posljedice trebale utjecati samo na dio poslužitelja u regiji.
- Pogodnost korištenja. Može se činiti da trebate pokrenuti nekoliko neovisnih planera za jednu regiju. Ali iz perspektive pogodnosti, jedna točka ulaska u zajednički bazen regije olakšava upravljanje kapacitetom i poslovima.
Podijelili smo planer na dijelove kako bismo riješili probleme održavanja velikog zajedničkog bazena. Svaki shard planera upravlja vlastitim skupom poslova u regiji, a to smanjuje rizik povezan s planerom. Kako dijeljeni skup raste, možemo dodati još shardova planera. Za korisnike Tupperwarea, shardovi i proxy programeri izgledaju kao jedna kontrolna ploča. Ne moraju raditi s hrpom krhotina koje orkestriraju zadatke. Shardovi planera bitno se razlikuju od planera klastera koje smo koristili prije, kada je upravljačka ploča bila podijeljena bez statičke podjele zajedničkog skupa poslužitelja prema topologiji mreže.
Poboljšajte učinkovitost korištenja uz Elastic Computing
Što je veća naša infrastruktura, to je važnije učinkovito koristiti naše poslužitelje za optimizaciju troškova infrastrukture i smanjenje opterećenja. Postoje dva načina za povećanje učinkovitosti korištenja poslužitelja:
- Elastično računalstvo - smanjite mrežne usluge tijekom mirnih sati i koristite oslobođene poslužitelje za izvanmrežna radna opterećenja, kao što su strojno učenje i poslovi MapReduce.
- Preopterećenje - Postavite mrežne usluge i skupna radna opterećenja na iste poslužitelje tako da se skupna radna opterećenja izvode s niskim prioritetom.
Usko grlo u našim podatkovnim centrima je . Stoga preferiramo male, energetski učinkovite poslužitelje koji zajedno daju veću procesorsku snagu. Nažalost, na malim poslužiteljima s malo procesora i memorije, preopterećenje je manje učinkovito. Naravno, možemo postaviti nekoliko spremnika malih usluga na jedan mali energetski učinkovit poslužitelj koji troše malo procesorskih resursa i memorije, ali veliki servisi će u ovoj situaciji imati niske performanse. Stoga savjetujemo programerima naših velikih usluga da ih optimiziraju tako da koriste cijele poslužitelje.
U osnovi, poboljšavamo učinkovitost korištenja koristeći elastično računalstvo. Mnoge od naših glavnih usluga, kao što su News Feed, značajka Messaging i front-end web sloj, razlikuju se ovisno o dobu dana. Namjerno smanjujemo mrežne usluge tijekom mirnih sati i koristimo oslobođene poslužitelje za izvanmrežna radna opterećenja, kao što su strojno učenje i poslovi MapReduce.
Iz iskustva znamo da je najbolje osigurati čitave poslužitelje kao jedinice elastičnog kapaciteta jer su veliki servisi glavni donatori i glavni potrošači elastičnog kapaciteta te su optimizirani za korištenje cijelih poslužitelja. Kada se poslužitelj oslobodi mrežne usluge tijekom tihih sati, posrednik resursa iznajmljuje poslužitelj planeru da na njemu pokreće izvanmrežna radna opterećenja. Ako mrežna usluga doživi vršno opterećenje, posrednik resursa brzo opoziva posuđeni poslužitelj i, zajedno s planerom, vraća ga mrežnoj usluzi.
Naučene lekcije i planovi za budućnost
Tijekom proteklih 8 godina razvijali smo Tupperware kako bismo držali korak s brzim rastom Facebooka. Dijelimo ono što smo naučili i nadamo se da će pomoći drugima u upravljanju brzo rastućim infrastrukturama:
- Postavite fleksibilnu vezu između upravljačke ploče i poslužitelja kojima upravlja. Ova fleksibilnost omogućuje upravljačkoj ploči upravljanje poslužiteljima u različitim podatkovnim centrima, pomaže automatizirati dekomisioniranje i održavanje klastera te omogućuje dinamičku dodjelu kapaciteta korištenjem elastičnog računalstva.
- S jednom kontrolnom pločom u regiji, postaje praktičniji rad sa zadacima i lakše upravljanje velikom flotom dijeljenih poslužitelja. Imajte na umu da upravljačka ploča održava jednu ulaznu točku, čak i ako je njezina unutarnja struktura odvojena zbog razmjera ili tolerancije na pogreške.
- Koristeći model dodatka, upravljačka ploča može obavijestiti vanjske aplikacije o nadolazećim operacijama spremnika. Štoviše, usluge s praćenjem stanja mogu koristiti sučelje dodatka za prilagodbu upravljanja spremnikom. S ovim modelom dodatka, upravljačka ploča pruža jednostavnost dok učinkovito opslužuje mnoge različite usluge praćenja stanja.
- Vjerujemo da je elastično računalstvo, gdje oduzimamo cijele poslužitelje od donatorskih usluga za skupne poslove, strojno učenje i druge usluge koje nisu hitne, optimalan način za poboljšanje učinkovitosti malih, energetski učinkovitih poslužitelja.
Tek počinjemo s implementacijom . Trenutno je oko 20% naših poslužitelja u zajedničkom bazenu. Da bi se postiglo 100%, potrebno je riješiti mnoga pitanja, uključujući održavanje zajedničkog skladišnog prostora, automatiziranje održavanja, upravljanje zahtjevima među zakupcima, poboljšanje korištenja poslužitelja i poboljšanje podrške za radna opterećenja strojnog učenja. Jedva čekamo prihvatiti ove izazove i podijeliti svoje uspjehe.
Izvor: www.habr.com