Tehokas ja luotettava klusterien hallinta missä tahansa mittakaavassa Tupperwaren avulla
Tänään esittelimme Tupperwaren, klusterinhallintajärjestelmämme, joka järjestää säilöjä miljoonille palvelimille, jotka käyttävät lähes kaikkia palvelujamme. Otimme Tupperwaren käyttöön ensimmäisen kerran vuonna 2011, ja siitä lähtien infrastruktuurimme on kasvanut kokoon asti . Koko tämän ajan Tupperware ei pysynyt paikallaan ja kehittyi kanssamme. Näytämme sinulle, kuinka Tupperware tarjoaa ensiluokkaista klusterinhallintaa, mukaan lukien kätevän tuen tilapitoisille palveluille, yhden ohjauspaneelin kaikille datakeskuksille ja mahdollisuuden jakaa kapasiteettia palveluiden välillä reaaliajassa. Jaamme myös opiksemme, kun infrastruktuurimme kehittyy.
Tupperware suorittaa erilaisia tehtäviä. Sovelluskehittäjät käyttävät sitä sovellusten toimittamiseen ja hallintaan. Se pakkaa sovelluskoodin ja riippuvuudet kuvaksi ja toimittaa sen palvelimille säilöinä. Säiliöt eristävät samalla palvelimella olevat sovellukset, jotta kehittäjät käsittelevät sovelluslogiikkaa eikä heidän tarvitse huolehtia palvelimien etsimisestä tai päivitysten hallinnasta. Tupperware valvoo myös palvelimen suorituskykyä ja jos se löytää vian, se siirtää kontteja ongelmalliselta palvelimelta.
Kapasiteetin suunnitteluinsinöörit käyttävät Tupperwarea palvelinkapasiteetin jakamiseen ryhmille budjetin ja rajoitusten perusteella. He käyttävät sitä myös palvelimen käyttöasteen parantamiseen. Palvelinkeskusoperaattorit kääntyvät Tupperwaren puoleen jakaakseen säiliöt oikein palvelinkeskusten välillä ja pysäyttääkseen tai siirtääkseen säiliöitä huollon aikana. Tämän ansiosta palvelimien, verkkojen ja laitteiden ylläpito vaatii minimaalista ihmisen väliintuloa.
Tupperware-arkkitehtuuri
Tupperware PRN -arkkitehtuuri on yksi datakeskustemme alueista. Alue koostuu useista lähellä sijaitsevista datakeskusrakennuksista (PRN1 ja PRN2). Aiomme tehdä yhden ohjauspaneelin, joka hallitsee kaikkia palvelimia yhdellä alueella.
Sovelluskehittäjät tarjoavat palveluja Tupperware-työpaikkojen muodossa. Työ koostuu useista säilöistä, ja ne kaikki käyttävät yleensä samaa sovelluskoodia.
Tupperware vastaa konttien toimittamisesta ja niiden elinkaaren hallinnasta. Se koostuu useista komponenteista:
- Tupperwaren käyttöliittymä tarjoaa sovellusliittymiä käyttöliittymälle, CLI:lle ja muille automaatiotyökaluille, joiden avulla voit olla vuorovaikutuksessa Tupperwaren kanssa. Ne piilottavat koko sisäisen rakenteen Tupperwaren työnomistajilta.
- Tupperware Scheduler on ohjauspaneeli, joka vastaa kontin ja työn elinkaaren hallinnasta. Sitä käytetään alueellisella ja maailmanlaajuisella tasolla, jossa alueellinen ajoitus hallitsee palvelimia yhdellä alueella ja globaali ajoitus eri alueiden palvelimia. Ajastin on jaettu sirpaloihin, ja jokainen sirpale hallitsee joukkoa töitä.
- Tupperwaren Scheduler Proxy piilottaa sisäisen sirpaloinnin ja tarjoaa kätevän yhden lasin Tupperwaren käyttäjille.
- Tupperware-allokaattori määrittää säiliöitä palvelimille. Ajastin käsittelee säilöjen pysäyttämisen, käynnistämisen, päivityksen ja vikasietoisuuden. Tällä hetkellä yksi allokaattori voi hallita koko aluetta hajoamatta sirpaleiksi. (Huomaa terminologian ero. Esimerkiksi Tupperwaren ajastin vastaa ohjauspaneelia , ja Tupperware-allokaattoria kutsutaan Kubernetesin ajoittimeksi.)
- Resurssivälittäjä tallentaa palvelimen ja palvelutapahtumien totuuden lähteen. Meillä on yksi resurssien välittäjä jokaisessa palvelinkeskuksessa, ja se tallentaa kaikki tiedot kyseisessä palvelinkeskuksessa olevista palvelimista. Resurssien välittäjä ja kapasiteetinhallintajärjestelmä tai resurssien hallintajärjestelmä päättävät dynaamisesti, mikä ajoitustoimitus ohjaa mitäkin palvelinta. Terveystarkastuspalvelu valvoo palvelimia ja tallentaa tietoja niiden terveydestä resurssivälittäjään. Jos palvelimessa on ongelmia tai se tarvitsee huoltoa, resurssien välittäjä käskee allokaattoria ja ajoittajaa pysäyttämään säilöt tai siirtämään ne muille palvelimille.
- Tupperware Agent on jokaisella palvelimella toimiva demoni, joka hoitaa säilöjen valmistelun ja poistamisen. Sovellukset toimivat säiliön sisällä, mikä antaa niille enemmän eristystä ja toistettavuutta. Päällä Olemme jo kuvanneet kuinka yksittäisiä Tupperware-säilöjä luodaan kuvien, btrfs:n, cgroupv2:n ja systemd:n avulla.
Tupperwaren erityispiirteet
Tupperware on monella tapaa samanlainen kuin muut klusterinhallintajärjestelmät, kuten Kubernetes ja , mutta niissä on myös eroja:
- Sisäänrakennettu tuki tilapalveluille.
- Yksi ohjauspaneeli palvelimille eri palvelinkeskuksissa, joka automatisoi konttien toimituksen tarkoituksen, klustereiden käytöstä poistamisen ja ylläpidon perusteella.
- Ohjauspaneelin selkeä jako zoomausta varten.
- Elastisen laskennan avulla voit jakaa tehoa palveluiden välillä reaaliajassa.
Kehitimme nämä hienot ominaisuudet tukemaan erilaisia tilattomia ja tilallisia sovelluksia valtavassa maailmanlaajuisessa jaetussa palvelinkannassa.
Sisäänrakennettu tuki tilapalveluille.
Tupperware tarjoaa erilaisia kriittisiä tilallisia palveluita, jotka tallentavat pysyviä tuotetietoja Facebookille, Instagramille, Messengerille ja WhatsAppille. Nämä voivat olla suuria avainarvoparien varastoja (esim. ) ja seurantatietovarastot (esim. и ). Tilallisten palveluiden ylläpitäminen ei ole helppoa, koska järjestelmän on varmistettava, että konttien toimitus kestää suuriakin häiriöitä, kuten verkko- tai sähkökatkoksia. Ja vaikka perinteiset tekniikat, kuten säiliöiden jakaminen vikaalueille, toimivat hyvin valtiottomissa palveluissa, tilalliset palvelut tarvitsevat lisätukea.
Jos esimerkiksi palvelinvika tekee yhden tietokannan replikasta poissa käytöstä, pitäisikö sinun ottaa käyttöön automaattinen ylläpito, joka päivittää 50 palvelimen ytimet 10 50 palvelimesta? Riippuu tilanteesta. Jos jollakin näistä 2 palvelimesta on toinen kopio samasta tietokannasta, on parempi odottaa etkä menetä kahta kopiota kerralla. Jotta voimme tehdä dynaamisesti järjestelmän ylläpitoa ja suorituskykyä koskevia päätöksiä, tarvitsemme tietoa sisäisestä tietojen replikaatiosta ja kunkin tilallisen palvelun sijoituslogiikasta.
TaskControl-liittymän avulla tilalliset palvelut voivat vaikuttaa päätöksiin, jotka vaikuttavat tietojen saatavuuteen. Tämän käyttöliittymän avulla ajoittaja ilmoittaa ulkoisille sovelluksille säilön toiminnoista (uudelleenkäynnistys, päivitys, siirto, ylläpito). Tilallinen palvelu toteuttaa ohjaimen, joka kertoo Tupperwarelle, milloin kunkin toiminnon suorittaminen on turvallista, ja nämä toiminnot voidaan vaihtaa tai viivästyttää tilapäisesti. Yllä olevassa esimerkissä tietokantaohjain voisi käskeä Tupperwarea päivittämään 49 palvelimesta 50:stä, mutta jättää tietyn palvelimen (X) rauhaan toistaiseksi. Tämän seurauksena, jos ytimen päivitysaika kuluu ja tietokanta ei edelleenkään pysty palauttamaan ongelmallista replikaa, Tupperware päivittää silti X-palvelimen.
Monet Tupperwaren tilalliset palvelut eivät käytä TaskControlia suoraan, vaan ShardManagerin kautta, joka on yleinen alusta tilallisten palvelujen luomiseen Facebookissa. Tupperwaren avulla kehittäjät voivat määrittää aikomuksensa tarkalleen, kuinka kontit tulisi jakaa palvelinkeskusten välillä. ShardManagerin avulla kehittäjät määrittelevät aikomuksensa sille, kuinka datasirpaleet tulisi jakaa säiliöiden kesken. ShardManager on tietoinen sovellustensa tietojen sijoittelusta ja replikaatiosta ja kommunikoi Tupperwaren kanssa TaskControl-käyttöliittymän kautta aikatauluttaakseen konttitoimintoja ilman suoraa sovelluksen osallistumista. Tämä integraatio yksinkertaistaa huomattavasti tilallisten palveluiden hallintaa, mutta TaskControl pystyy enemmän. Esimerkiksi laaja verkkotasomme on tilaton ja käyttää TaskControlia dynaamisesti säätämään säilöjen päivitysnopeutta. Lopulta päivässä saatavuudesta tinkimättä.
Palvelinten hallinta datakeskuksissa
Kun Tupperware julkaistiin ensimmäisen kerran vuonna 2011, jokaista palvelinklusteria hallinnoi erillinen ajoitus. Tuolloin Facebook-klusteri oli ryhmä palvelintelineitä, jotka oli yhdistetty yhteen verkkokytkimeen, ja palvelinkeskuksessa oli useita klustereita. Ajastin pystyi hallitsemaan vain yhden klusterin palvelimia, mikä tarkoittaa, että työ ei voinut jakaa useiden klustereiden kesken. Infrastruktuurimme kasvoi, kirjasimme yhä enemmän klustereita pois. Koska Tupperware ei voinut siirtää työtä poistetusta klusterista muihin klustereihin ilman muutoksia, se vaati paljon vaivaa ja huolellista koordinointia sovelluskehittäjien ja palvelinkeskusten operaattoreiden välillä. Tämä prosessi johti resurssien hukkaan, kun palvelimet olivat käyttämättömänä kuukausia käytöstäpoistotoimenpiteiden vuoksi.
Loimme resurssivälittäjän ratkaisemaan klusterin käytöstäpoisto-ongelman ja koordinoimaan muun tyyppisiä kunnossapitotehtäviä. Resurssien välittäjä seuraa kaikkia palvelimeen liittyviä fyysisiä tietoja ja päättää dynaamisesti, mikä ajoitus ohjaa kutakin palvelinta. Palvelinten dynaaminen linkittäminen ajoittajiin sallii ajoittajan hallita palvelimia eri tietokeskuksissa. Koska Tupperware-työ ei enää rajoitu yhteen klusteriin, Tupperwaren käyttäjät voivat määrittää, kuinka säilöt tulee jakaa vikaalueille. Esimerkiksi kehittäjä voi ilmoittaa aikomuksensa (kuten: "suorita työni kahdella vikaalueella PRN-alueella") määrittelemättä tiettyjä käytettävyysalueita. Tupperware itse löytää sopivat palvelimet toteuttamaan tätä tarkoitusta, vaikka klusteri tai palvelu poistettaisiin käytöstä.
Skaalautuva tukemaan koko globaalia järjestelmää
Historiallisesti infrastruktuurimme on jaettu satoihin omistettuihin palvelinryhmiin yksittäisille ryhmille. Hajanaisuudesta ja standardien puutteesta johtuen meillä oli korkeat käyttökustannukset, ja käyttämättömiä palvelimia oli taas vaikeampi käyttää. Viime vuoden konferenssissa esittelimme , jonka pitäisi yhdistää infrastruktuurimme suureksi yhdeksi palvelinpuistoksi. Mutta yhdellä palvelinpuistolla on omat vaikeutensa. Sen on täytettävä tietyt vaatimukset:
- Skaalautuvuus. Infrastruktuurimme kasvoi, kun lisäsimme palvelinkeskuksia jokaiselle alueelle. Palvelimista on tullut pienempiä ja energiatehokkaampia, joten niitä on paljon enemmän jokaisella alueella. Tämän seurauksena yksi ajastin aluetta kohti ei pysty käsittelemään säilöjen määrää, joita voidaan käyttää sadoilla tuhansilla palvelimilla kullakin alueella.
- Luotettavuutta. Vaikka ajoitinta voidaan skaalata niin paljon, ajoittimen laaja laajuus tarkoittaa, että virheriskit ovat korkeammat ja kokonaisesta säilöalueesta voi tulla hallitsematon.
- Vikasietoisuus. Valtavan infrastruktuurin vian sattuessa (esimerkiksi ajastinta käyttävät palvelimet epäonnistuvat verkkovian tai sähkökatkon vuoksi), kielteisten seurausten pitäisi vaikuttaa vain osaan alueen palvelimista.
- Helppokäyttöisyys. Saattaa vaikuttaa siltä, että sinun on käytettävä useita itsenäisiä ajoittajia yhdelle alueelle. Mutta mukavuusnäkökulmasta katsottuna yhden pisteen kautta alueen jaettuun pooliin on helpompi hallita kapasiteettia ja työpaikkoja.
Jaoimme ajoittimen sirpaleiksi ratkaistaksemme suuren yhteisen poolin ylläpitoongelmia. Jokainen ajoittimen sirpale hallitsee omaa työjoukkoaan alueella, ja tämä vähentää ajoittimeen liittyvää riskiä. Jaetun poolin kasvaessa voimme lisätä enemmän aikataulun sirpaleita. Tupperwaren käyttäjille sirpaleet ja ajastimen välityspalvelimet näyttävät yhdeltä ohjauspaneelilta. Heidän ei tarvitse työskennellä joukon sirpaleiden kanssa, jotka järjestävät tehtäviä. Ajastimen sirpaleet eroavat olennaisesti aiemmin käyttämistämme klusterin ajoittajista, kun ohjauspaneeli osioitiin jakamatta staattisesti jaettua palvelimia verkon topologian mukaan.
Paranna käyttötehokkuutta elastisella tietojenkäsittelyllä
Mitä laajempi infrastruktuurimme, sitä tärkeämpää on käyttää palvelimiamme tehokkaasti infrastruktuurikustannusten optimoimiseksi ja kuormituksen vähentämiseksi. Palvelimen käytön tehostamiseksi on kaksi tapaa:
- Elastinen tietojenkäsittely – pienennä online-palveluita hiljaisina aikoina ja käytä vapautettuja palvelimia offline-työkuormitukseen, kuten koneoppimiseen ja MapReduce-työhön.
- Ylikuormitus – Sijoita online-palvelut ja erätyökuormat samoihin palvelimiin, jotta erätyökuormat toimivat alhaisella prioriteetilla.
Palvelinkeskustemme pullonkaula on . Siksi suosimme pieniä, energiatehokkaita palvelimia, jotka yhdessä tarjoavat enemmän prosessointitehoa. Valitettavasti pienillä palvelimilla, joissa on vähän prosessoria ja muistia, ylikuormitus on vähemmän tehokasta. Voimme tietysti sijoittaa useita pieniä palveluita yhdelle pienelle energiatehokkaalle palvelimelle, jotka kuluttavat vähän prosessoriresursseja ja muistia, mutta suurilla palveluilla on tässä tilanteessa huono suorituskyky. Siksi suosittelemme suurten palveluidemme kehittäjiä optimoimaan ne niin, että he käyttävät koko palvelimia.
Pohjimmiltaan parannamme käyttötehokkuutta elastisella laskennalla. Monet tärkeimmistä palveluistamme, kuten uutissyöte, viestintäominaisuus ja käyttöliittymän verkkotaso, vaihtelevat vuorokaudenajan mukaan. Vähennämme verkkopalveluita tarkoituksella hiljaisina aikoina ja käytämme vapautettuja palvelimia offline-työkuormitukseen, kuten koneoppimiseen ja MapReduce-työhön.
Tiedämme kokemuksesta, että on parasta tarjota kokonaisia palvelimia joustavan kapasiteetin yksikköinä, koska suuret palvelut ovat sekä suuria joustokapasiteetin lahjoittajia että suuria kuluttajia, ja ne on optimoitu käyttämään kokonaisia palvelimia. Kun palvelin vapautetaan online-palvelusta hiljaisina aikoina, resurssien välittäjä vuokraa palvelimen ajoittajalle suorittaakseen sillä offline-työkuormia. Jos verkkopalvelussa on huippukuormitus, resurssinvälittäjä hakee nopeasti lainatun palvelimen ja palauttaa sen yhdessä ajoittajan kanssa verkkopalveluun.
Opittuja asioita ja tulevaisuuden suunnitelmia
Viimeisten 8 vuoden aikana olemme kehittäneet Tupperwarea pysyäksemme Facebookin nopean kasvun tahdissa. Jaamme oppimamme ja toivomme, että se auttaa muita hallitsemaan nopeasti kasvavia infrastruktuureja:
- Luo joustava yhteys ohjauspaneelin ja sen hallinnoimien palvelimien välille. Tämän joustavuuden ansiosta ohjauspaneeli voi hallita palvelimia eri tietokeskuksissa, auttaa automatisoimaan klustereiden käytöstä poistamisen ja ylläpidon sekä mahdollistaa dynaamisen kapasiteetin allokoinnin joustavan laskentatavan avulla.
- Kun alueella on yksi ohjauspaneeli, tehtävien käsittely on helpompaa ja suuren jaetun palvelinkannan hallinta on helpompaa. Huomaa, että ohjauspaneeli ylläpitää yhtä sisääntulokohtaa, vaikka sen sisäinen rakenne olisi erotettu mittakaavan tai vikasietoisuuden vuoksi.
- Plugin-mallin avulla ohjauspaneeli voi ilmoittaa ulkoisille sovelluksille tulevista konttitoiminnoista. Lisäksi tilalliset palvelut voivat käyttää laajennusrajapintaa mukauttaakseen säilön hallintaa. Tämän laajennusmallin avulla ohjauspaneeli tarjoaa yksinkertaisuutta ja palvelee tehokkaasti monia erilaisia tilallisia palveluita.
- Uskomme, että joustava laskenta, jossa otamme kokonaisia palvelimia pois luovuttajapalveluilta erätöihin, koneoppimiseen ja muihin ei-kiireellisiin palveluihin, on optimaalinen tapa parantaa pienten, energiatehokkaiden palvelimien tehokkuutta.
Olemme vasta aloittamassa toteuttamista . Tällä hetkellä noin 20 % palvelimistamme on jaetussa poolissa. 100 %:n saavuttamiseksi on ratkaistava monia ongelmia, mukaan lukien jaetun tallennusvarannon ylläpito, ylläpidon automatisointi, vuokralaisten välisten vaatimusten hallinta, palvelinten käyttöasteen parantaminen ja koneoppimistyökuormien tuen parantaminen. Emme malta odottaa, että pääsemme ottamaan vastaan nämä haasteet ja jakamaan onnistumisemme.
Lähde: will.com