Klastrite tõhus ja usaldusväärne haldamine mis tahes ulatuses Tupperware abil
Täna edasi tutvustasime Tupperware'i, meie klastrihaldussüsteemi, mis korraldab konteinereid miljonites serverites, mis käitavad peaaegu kõiki meie teenuseid. Võtsime Tupperware esimest korda kasutusele 2011. aastal ja sellest ajast alates on meie infrastruktuur kasvanud tervikuks . Kogu selle aja ei seisnud Tupperware paigal ja arenes koos meiega. Näitame teile, kuidas Tupperware pakub esmaklassilist klastrihaldust, sealhulgas mugavat tuge olekupõhistele teenustele, ühtset juhtpaneeli kõigi andmekeskuste jaoks ja võimalust jaotada võimsust reaalajas teenuste vahel. Samuti jagame oma infrastruktuuri arenedes saadud õppetunde.
Tupperware täidab erinevaid ülesandeid. Rakenduste arendajad kasutavad seda rakenduste tarnimiseks ja haldamiseks. See pakib rakenduse koodi ja sõltuvused pildiks ning edastab selle konteineritena serveritesse. Konteinerid eraldavad samas serveris olevaid rakendusi, nii et arendajad tegelevad rakenduste loogikaga ega pea muretsema serverite leidmise või värskenduste haldamise pärast. Tupperware jälgib ka serveri jõudlust ning vea tuvastamisel kannab probleemsest serverist konteinerid üle.
Võimsuse planeerimise insenerid kasutavad Tupperware'i, et eraldada meeskondadele serverivõimsus eelarve ja piirangute alusel. Nad kasutavad seda ka serveri kasutamise parandamiseks. Andmekeskuste operaatorid pöörduvad Tupperware poole, et konteinerid andmekeskuste vahel õigesti jaotada ning konteinerid hoolduse ajal peatada või teisaldada. Tänu sellele nõuab serverite, võrkude ja seadmete hooldamine minimaalset inimese sekkumist.
Tupperware arhitektuur
Tupperware PRN-arhitektuur on üks meie andmekeskuste piirkondadest. Piirkond koosneb mitmest läheduses asuvast andmekeskuse hoonest (PRN1 ja PRN2). Plaanime teha ühe juhtpaneeli, mis haldaks kõiki ühe piirkonna servereid.
Rakenduste arendajad pakuvad teenuseid Tupperware tööde vormis. Töö koosneb mitmest konteinerist ja need kõik käitavad tavaliselt sama rakenduse koodi.
Tupperware vastutab konteinerite varustamise ja nende elutsükli haldamise eest. See koosneb mitmest komponendist:
- Tupperware kasutajaliides pakub kasutajaliidese, CLI ja muude automatiseerimistööriistade API-sid, mille kaudu saate Tupperware'iga suhelda. Nad peidavad Tupperware'i tööomanike eest kogu sisemise struktuuri.
- Tupperware Scheduler on juhtpaneel, mis vastutab konteineri ja töö elutsükli haldamise eest. Seda juurutatakse piirkondlikul ja globaalsel tasandil, kus piirkondlik planeerija haldab servereid ühes piirkonnas ja globaalne planeerija haldab servereid erinevatest piirkondadest. Planeerija on jagatud kildudeks ja iga kild haldab tööde komplekti.
- Tupperware'i ajakava puhverserver peidab sisemise killustiku ja pakub Tupperware kasutajatele mugavat ühe klaasi.
- Tupperware jaotur määrab serveritele konteinerid. Planeerija tegeleb konteinerite peatamise, käivitamise, värskendamise ja tõrkevahetusega. Praegu saab üks jaotaja hallata tervet piirkonda ilma kildudeks tükeldamata. (Pange tähele terminite erinevust. Näiteks Tupperware'i ajakava vastab juhtpaneelile ja Tupperware'i jaoturit nimetatakse Kubernetesis planeerijaks.)
- Ressursimaakler salvestab tõe allika serveri ja teenuse sündmuste kohta. Me juhime iga andmekeskuse jaoks ühte ressursivahendajat ja see salvestab kogu teabe selles andmekeskuses asuvate serverite kohta. Ressursivahendaja ja võimsuse haldussüsteem või ressursside varustamise süsteem otsustavad dünaamiliselt, milline planeerija edastamine millist serverit juhib. Tervisekontrolli teenus jälgib servereid ja salvestab andmed nende tervise kohta ressursivahendajas. Kui serveril on probleeme või see vajab hooldust, käsib ressursivahendaja jagajal ja planeerijal konteinerid peatada või teisaldada teistesse serveritesse.
- Tupperware Agent on igas serveris töötav deemon, mis tegeleb konteinerite varustamise ja eemaldamisega. Rakendused töötavad konteineris, mis annab neile suurema isoleerituse ja reprodutseeritavuse. Peal Oleme juba kirjeldanud, kuidas üksikuid Tupperware konteinereid luuakse piltide, btrfs, cgroupv2 ja systemd abil.
Tupperware'i eristavad omadused
Tupperware sarnaneb paljuski teiste klastrihaldussüsteemidega, nagu Kubernetes ja , kuid on ka erinevusi:
- Sisseehitatud tugi olekupõhistele teenustele.
- Üks juhtpaneel serverite jaoks erinevates andmekeskustes, et automatiseerida konteinerite tarnimist kavatsuse, klastrite dekomisjoneerimise ja hoolduse alusel.
- Juhtpaneeli selge jaotus suumimiseks.
- Elastne andmetöötlus võimaldab teil reaalajas energiat teenuste vahel jaotada.
Töötasime välja need lahedad funktsioonid, et toetada mitmesuguseid olekuta ja olekuga rakendusi tohutus ülemaailmses jagatud serveripargis.
Sisseehitatud tugi olekupõhistele teenustele.
Tupperware opereerib mitmesuguseid kriitilisi olekupõhiseid teenuseid, mis salvestavad püsivaid tooteandmeid Facebooki, Instagrami, Messengeri ja WhatsAppi jaoks. Need võivad olla suured võtme-väärtuste paaride poed (nt. ) ja seire andmehoidlad (näiteks и ). Seisukohajärgsete teenuste ülalpidamine pole lihtne, sest süsteem peab tagama, et konteinerite tarne talub suuremahulisi häireid, sealhulgas võrgu- või elektrikatkestusi. Ja kuigi tavapärased tehnikad, nagu konteinerite jaotamine veadomeenide vahel, töötavad kodakondsuseta teenuste puhul hästi, vajavad olekupõhised teenused täiendavat tuge.
Näiteks kui serveri rike muudab ühe andmebaasi koopia kättesaamatuks, kas peaksite lubama automaatse hoolduse, mis värskendab 50 serveri tuumasid 10 50 serverist? Oleneb olukorrast. Kui ühel neist 2 serverist on sama andmebaasi teine koopia, on parem oodata ja mitte kaotada XNUMX koopiat korraga. Süsteemi hoolduse ja jõudluse kohta dünaamiliselt otsuste tegemiseks vajame teavet sisemise andmete replikatsiooni ja iga olekupõhise teenuse paigutusloogika kohta.
TaskControli liides võimaldab olekuga teenustel mõjutada andmete kättesaadavust mõjutavaid otsuseid. Seda liidest kasutades teavitab planeerija väliseid rakendusi konteineri toimingute kohta (taaskäivitamine, värskendamine, migreerimine, hooldus). Olekupõhine teenus rakendab kontrollerit, mis teatab Tupperwarele, millal on iga toimingu sooritamine ohutu, ja neid toiminguid saab ajutiselt vahetada või edasi lükata. Ülaltoodud näites võib andmebaasikontroller käskida Tupperwarel värskendada 49 serverit 50-st, kuid jätta konkreetse serveri (X) praegu rahule. Selle tulemusena, kui kerneli värskendusperiood möödub ja andmebaas ei suuda endiselt probleemset koopiat taastada, värskendab Tupperware ikkagi X-serverit.
Paljud Tupperware'i olekupõhised teenused kasutavad TaskControli mitte otse, vaid ShardManageri kaudu, mis on ühine platvorm Facebookis olekuga teenuste loomiseks. Tupperware abil saavad arendajad täpselt määratleda, kuidas konteinereid andmekeskuste vahel jaotada. ShardManageriga määravad arendajad kindlaks, kuidas andmekillud konteinerite vahel jaotada. ShardManager on teadlik oma rakenduste andmete paigutusest ja replikatsioonist ning suhtleb Tupperware'iga TaskControli liidese kaudu, et ajastada konteineri toiminguid ilma rakenduse otsese kaasamiseta. See integratsioon lihtsustab oluliselt olekupõhiste teenuste haldamist, kuid TaskControl on võimeline enamaks. Näiteks meie ulatuslik veebitasand on olekuta ja kasutab TaskControli konteinerite värskenduste määra dünaamiliseks reguleerimiseks. Lõpuks päevas ilma kättesaadavust kahjustamata.
Serverite haldamine andmekeskustes
Kui Tupperware 2011. aastal esmakordselt käivitati, haldas iga serveriklastrit eraldi planeerija. Sel ajal oli Facebooki klaster serveririiulite rühm, mis oli ühendatud ühe võrgulülitiga ja andmekeskuses asus mitu klastrit. Planeerija sai hallata ainult ühes klastris olevaid servereid, mis tähendab, et töö ei saanud levida mitme klastri vahel. Meie infrastruktuur kasvas, me kirjutasime üha enam klastreid maha. Kuna Tupperware ei saanud tööd maha võetud klastrist ilma muudatusteta teistesse klastritesse teisaldada, nõudis see palju pingutust ja hoolikat koordineerimist rakenduste arendajate ja andmekeskuste operaatorite vahel. Selle protsessi tulemuseks oli ressursside raiskamine, kui serverid olid dekomisjoneerimisprotseduuride tõttu mitu kuud jõude.
Lõime klastri dekomisjoneerimise probleemi lahendamiseks ja muud tüüpi hooldustööde koordineerimiseks ressursivahendaja. Ressursivahendaja jälgib kogu serveriga seotud füüsilist teavet ja otsustab dünaamiliselt, milline planeerija iga serverit juhib. Serverite dünaamiline linkimine planeerijatega võimaldab planeerijal hallata servereid erinevates andmekeskustes. Kuna Tupperware töö ei piirdu enam ühe klastriga, saavad Tupperware kasutajad määrata, kuidas konteinereid veadomeenide vahel jaotada. Näiteks võib arendaja deklareerida oma kavatsust (ütleme: "käivita minu tööd kahel veadomeenil PRN-piirkonnas") ilma konkreetseid saadavustsoone täpsustamata. Tupperware ise leiab selle kavatsuse elluviimiseks sobivad serverid, isegi kui klaster või teenus on kasutusest kõrvaldatud.
Skaleeritav, et toetada kogu globaalset süsteemi
Ajalooliselt on meie infrastruktuur jagatud sadadeks spetsiaalseteks serverikogumiteks üksikute meeskondade jaoks. Killustatuse ja standardite puudumise tõttu olid meil suured tegevuskulud ning jõudeolevaid servereid oli jälle raskem kasutada. Eelmise aasta konverentsil esitasime , mis peaks ühendama meie taristu suureks ühtseks serveripargiks. Kuid ühel serveripargil on omad raskused. See peab vastama teatud nõuetele:
- Skaalautuvus. Meie infrastruktuur kasvas, kui lisasime igasse piirkonda andmekeskusi. Serverid on muutunud väiksemaks ja energiasäästlikumaks, seega on neid igas piirkonnas palju rohkem. Selle tulemusel ei saa üks planeerija piirkonna kohta hakkama konteinerite arvuga, mida saab käitada sadades tuhandetes serverites igas piirkonnas.
- Usaldusväärsus Isegi kui planeerijat saab nii palju suurendada, tähendab ajakava suur ulatus suuremat vigade ohtu ja terve konteinerite piirkond võib muutuda juhitamatuks.
- Veataluvus. Suure infrastruktuuri tõrke korral (näiteks plaanijat käitavad serverid ebaõnnestuvad võrgurikke või voolukatkestuse tõttu), peaksid negatiivsed tagajärjed mõjutama ainult osa piirkonna serveritest.
- Kasutusmugavus. Võib tunduda, et peate ühe piirkonna jaoks käivitama mitu sõltumatut planeerijat. Kuid mugavuse vaatenurgast muudab piirkonna ühiskasutusse sisenemise üksainus võimsuse ja töökohtade haldamise lihtsamaks.
Jagasime planeerija kildudeks, et lahendada suure jagatud basseini ülalpidamisega seotud probleemid. Iga planeerija killuke haldab piirkonnas oma tööde komplekti ja see vähendab planeerijaga seotud riski. Jagatud basseini kasvades saame lisada rohkem planeerijakilde. Tupperware kasutajate jaoks näevad killud ja planeerija puhverserverid välja nagu üks juhtpaneel. Nad ei pea töötama hunniku kildudega, mis ülesandeid korraldavad. Ajastikillud erinevad põhimõtteliselt klastri planeerijatest, mida me varem kasutasime, kui juhtpaneel jaotati staatiliselt jagatud serverite kogumit vastavalt võrgu topoloogiale.
Parandage kasutustõhusust elastse andmetöötlusega
Mida suurem on meie infrastruktuur, seda olulisem on oma servereid tõhusalt kasutada, et optimeerida infrastruktuuri kulusid ja vähendada koormust. Serveri kasutamise tõhususe suurendamiseks on kaks võimalust:
- Elastne andmetöötlus – vähendage võrguteenuseid vaiksel ajal ja kasutage vabastatud servereid võrguühenduseta töökoormuse jaoks, nagu masinõpe ja MapReduce'i tööd.
- Ülekoormus – paigutage võrguteenused ja paketttöökoormused samadesse serveritesse, nii et paketttöökoormused töötaksid madala prioriteediga.
Meie andmekeskuste kitsaskoht on . Seetõttu eelistame väikeseid energiatõhusaid servereid, mis koos annavad rohkem töötlemisvõimsust. Kahjuks on väikestes serverites, millel on vähe protsessorit ja mälu, ülekoormus vähem efektiivne. Muidugi saame ühele väikesele energiasäästlikule serverile paigutada mitu konteinerit väikeseid teenuseid, mis kulutavad vähe protsessoriressursse ja mälu, kuid suurte teenuste jõudlus on selles olukorras madal. Seetõttu soovitame oma suurte teenuste arendajatel need optimeerida nii, et nad kasutaksid terveid servereid.
Põhimõtteliselt parandame kasutustõhusust elastse andmetöötluse abil. Paljud meie peamised teenused, nagu uudistevoog, sõnumside funktsioon ja esiotsa veebitasand, sõltuvad kellaajast. Vähendame vaiksetel tundidel võrguteenuseid tahtlikult ja kasutame vabastatud servereid võrguühenduseta töökoormuse jaoks, nagu masinõpe ja MapReduce'i tööd.
Kogemustest teame, et kõige parem on varustada terveid servereid elastse võimsuse ühikutena, sest suured teenused on nii suured annetajad kui ka suuremad elastse võimsuse tarbijad ning on optimeeritud kasutama terveid servereid. Kui server vabastatakse vaiksetel tundidel võrguteenusest, rendib ressursivahendaja serveri planeerijale, et sellel käitada võrguühenduseta töökoormust. Kui võrguteenuses on tippkoormus, kutsub ressursivahendaja kiiresti tagasi laenatud serveri ja tagastab koos planeerijaga selle võrguteenusele.
Õppetunnid ja tulevikuplaanid
Viimase 8 aasta jooksul oleme arendanud Tupperwaret, et pidada sammu Facebooki kiire kasvuga. Jagame õpitut ja loodame, et see aitab teistel kiiresti kasvavaid infrastruktuure hallata:
- Seadistage paindlik ühendus juhtpaneeli ja selle hallatavate serverite vahel. See paindlikkus võimaldab juhtpaneelil hallata servereid erinevates andmekeskustes, aitab automatiseerida klastrite dekomisjoneerimist ja hooldust ning võimaldab dünaamilist võimsuse jaotamist elastse andmetöötluse abil.
- Piirkonnas ühe juhtpaneeliga muutub ülesannetega töötamine mugavamaks ja suure jagatud serveripargi haldamine lihtsamaks. Pange tähele, et juhtpaneelil on üks sisestuspunkt, isegi kui selle sisemine struktuur on mastaabi või tõrketaluvuse tõttu eraldatud.
- Kasutades pistikprogrammi mudelit, saab juhtpaneel teavitada väliseid rakendusi tulevastest konteineritoimingutest. Lisaks saavad olekupõhised teenused konteinerihalduse kohandamiseks kasutada pistikprogrammi liidest. Selle pistikprogrammi mudeliga pakub juhtpaneel lihtsust, teenindades samal ajal tõhusalt paljusid erinevaid olekupõhiseid teenuseid.
- Usume, et elastne andmetöötlus, mille puhul võtame doonorteenustelt ära terved serverid paketttööde, masinõppe ja muude mittekiireloomuliste teenuste jaoks, on optimaalne viis väikeste energiatõhusate serverite tõhususe parandamiseks.
Me alles alustame rakendamist . Praegu on umbes 20% meie serveritest jagatud basseinis. 100% saavutamiseks tuleb lahendada palju probleeme, sealhulgas jagatud salvestusruumi säilitamine, hoolduse automatiseerimine, rentnikeüleste nõuete haldamine, serveri kasutuse parandamine ja masinõppe töökoormuste toe parandamine. Me ei jõua ära oodata, et saaksime need väljakutsed vastu võtta ja oma edusamme jagada.
Allikas: www.habr.com