Tupperware: Muuaji wa Kubernetes wa Facebook?

Usimamizi bora na wa kuaminika wa vikundi kwa kiwango chochote na Tupperware

Tupperware: Muuaji wa Kubernetes wa Facebook?

Leo kwenye Mifumo @ Mizani mkutano tulianzisha Tupperware, mfumo wetu wa usimamizi wa nguzo ambao hupanga makontena kwenye mamilioni ya seva zinazoendesha karibu huduma zetu zote. Tulisambaza Tupperware kwa mara ya kwanza mwaka wa 2011, na tangu wakati huo miundombinu yetu imeongezeka kutoka 1 kituo cha data kwa nzima Vituo 15 vya data vilivyosambazwa kijiografia. Wakati huu wote, Tupperware haikusimama na kuendeleza nasi. Tutakuonyesha jinsi Tupperware hutoa usimamizi wa nguzo wa daraja la kwanza, ikijumuisha usaidizi unaofaa kwa huduma za hali ya juu, paneli moja dhibiti ya vituo vyote vya data, na uwezo wa kusambaza uwezo kati ya huduma kwa wakati halisi. Pia tutashiriki mafunzo ambayo tumejifunza kadiri miundombinu yetu inavyoendelea.

Tupperware hufanya kazi tofauti. Wasanidi programu huitumia kutoa na kudhibiti programu. Inapakia msimbo wa programu na vitegemezi kwenye picha na kuiwasilisha kwa seva kama vyombo. Vyombo hutoa utengano kati ya programu kwenye seva moja ili wasanidi washughulikie mantiki ya programu na wasiwe na wasiwasi kuhusu kutafuta seva au kudhibiti masasisho. Tupperware pia hufuatilia utendakazi wa seva, na ikipata kutofaulu, huhamisha vyombo kutoka kwa seva yenye matatizo.

Wahandisi wa kupanga uwezo hutumia Tupperware kutenga uwezo wa seva kwa timu kulingana na bajeti na vikwazo. Pia wanaitumia kuboresha utumiaji wa seva. Waendeshaji wa kituo cha data wanageukia Tupperware ili kusambaza vyema kontena kwenye vituo vyote vya data na kusimamisha au kuhamisha kontena wakati wa matengenezo. Shukrani kwa hili, kudumisha seva, mitandao na vifaa huhitaji uingiliaji mdogo wa binadamu.

Usanifu wa Tupperware

Tupperware: Muuaji wa Kubernetes wa Facebook?

Usanifu wa Tupperware PRN ni mojawapo ya maeneo ya vituo vyetu vya data. Kanda hiyo ina majengo kadhaa ya kituo cha data (PRN1 na PRN2) yaliyo karibu. Tunapanga kutengeneza paneli moja ya kudhibiti ambayo itasimamia seva zote katika eneo moja.

Wasanidi programu hutoa huduma kwa njia ya kazi za Tupperware. Kazi ina vyombo vingi, na vyote kwa kawaida huendesha msimbo sawa wa maombi.

Tupperware inawajibika kwa utoaji wa vyombo na kudhibiti mzunguko wao wa maisha. Inajumuisha vipengele kadhaa:

  • Sehemu ya mbele ya Tupperware hutoa API za kiolesura cha mtumiaji, CLI, na zana zingine za otomatiki ambazo kupitia hizo unaweza kuingiliana na Tupperware. Wanaficha muundo mzima wa ndani kutoka kwa wamiliki wa kazi ya Tupperware.
  • Tupperware Scheduler ni paneli dhibiti inayowajibika kudhibiti kontena na mzunguko wa maisha ya kazi. Inasambazwa katika viwango vya kikanda na kimataifa, ambapo kipanga ratiba kikanda hudhibiti seva katika eneo moja na kipanga ratiba cha kimataifa husimamia seva kutoka maeneo tofauti. Mpangaji amegawanywa katika shards, na kila shard inasimamia seti ya kazi.
  • Wakala wa Kiratibu wa Tupperware huficha upakuaji wa ndani na hutoa kidirisha kimoja cha kioo kwa watumiaji wa Tupperware.
  • Kisambazaji cha Tupperware hugawa vyombo kwa seva. Kipanga ratiba hushughulikia kusimamisha, kuanzisha, kusasisha, na kushindwa kwa vyombo. Hivi sasa, mgao mmoja anaweza kusimamia eneo lote bila kugawanyika katika vipande. (Kumbuka tofauti ya istilahi. Kwa mfano, kipanga ratiba katika Tupperware kinalingana na paneli dhibiti katika Mabernet, na kigawaji cha Tupperware kinaitwa kipanga ratiba katika Kubernetes.)
  • Wakala wa rasilimali huhifadhi chanzo cha ukweli kwa seva na matukio ya huduma. Tunaendesha wakala mmoja wa rasilimali kwa kila kituo cha data, na huhifadhi taarifa zote kuhusu seva katika kituo hicho cha data. Wakala wa rasilimali na mfumo wa usimamizi wa uwezo, au mfumo wa utoaji wa rasilimali, huamua kwa uthabiti ni utoaji gani wa kiratibu hudhibiti seva ipi. Huduma ya ukaguzi wa afya hufuatilia seva na kuhifadhi data kuhusu afya zao katika wakala wa rasilimali. Ikiwa seva ina matatizo au inahitaji matengenezo, wakala wa rasilimali humwambia mgawaji na kipanga ratiba kusimamisha vyombo au kuvihamishia kwenye seva nyingine.
  • Wakala wa Tupperware ni daemoni inayoendesha kwenye kila seva ambayo inashughulikia utoaji na uondoaji wa vyombo. Maombi huendeshwa ndani ya chombo, ambayo huwapa kutengwa zaidi na kuzaliana. Washa kongamano la mwaka jana la Systems @Scale Tayari tumeelezea jinsi vyombo mahususi vya Tupperware vinaundwa kwa kutumia picha, btrfs, cgroupv2 na systemd.

Vipengele tofauti vya Tupperware

Tupperware ni sawa kwa njia nyingi na mifumo mingine ya usimamizi wa nguzo kama vile Kubernetes na Mesos, lakini pia kuna tofauti:

  • Usaidizi uliojengewa ndani kwa huduma za hali ya juu.
  • Paneli moja dhibiti ya seva katika vituo tofauti vya data ili kufanya uwasilishaji wa kontena kiotomatiki kulingana na dhamira, uondoaji wa vikundi na matengenezo.
  • Futa mgawanyiko wa paneli dhibiti kwa kukuza.
  • Kompyuta ya elastic hukuruhusu kusambaza nguvu kati ya huduma kwa wakati halisi.

Tumeunda vipengele hivi vyema ili kusaidia aina mbalimbali za programu zisizo na uraia na za hali ya juu katika kundi kubwa la seva za kimataifa zinazoshirikiwa.

Usaidizi uliojengewa ndani kwa huduma za hali ya juu.

Tupperware huendesha huduma nyingi muhimu ambazo huhifadhi data ya bidhaa inayoendelea kwa Facebook, Instagram, Messenger na WhatsApp. Hizi zinaweza kuwa maduka makubwa ya jozi za thamani-msingi (k.m. ZippyDB) na ufuatiliaji wa hazina za data (kwa mfano, Gorilla ya ODS и Scuba) Kudumisha huduma za serikali si rahisi, kwa sababu mfumo lazima uhakikishe kwamba usambazaji wa makontena unaweza kuhimili usumbufu mkubwa, ikiwa ni pamoja na kukatika kwa mtandao au kukatika kwa umeme. Na ingawa mbinu za kawaida, kama vile kusambaza kontena katika vikoa vyenye makosa, hufanya kazi vyema kwa huduma zisizo na uraia, huduma za serikali zinahitaji usaidizi wa ziada.

Kwa mfano, ikiwa hitilafu ya seva itafanya nakala moja ya hifadhidata isipatikane, je, unapaswa kuwasha urekebishaji wa kiotomatiki ambao utasasisha viini kwenye seva 50 kutoka kundi la 10? Inategemea hali. Ikiwa moja ya seva hizi 50 ina nakala nyingine ya hifadhidata hiyo hiyo, ni bora kungojea na usipoteze nakala 2 mara moja. Ili kufanya maamuzi kwa uthabiti kuhusu udumishaji na utendakazi wa mfumo, tunahitaji maelezo kuhusu urudiaji wa data ya ndani na mantiki ya uwekaji wa kila huduma kuu.

Kiolesura cha TaskControl huruhusu huduma bora kuathiri maamuzi yanayoathiri upatikanaji wa data. Kwa kutumia kiolesura hiki, kipanga ratiba huarifu programu za nje kuhusu uendeshaji wa kontena (kuanzisha upya, kusasisha, uhamiaji, matengenezo). Huduma ya hali ya juu hutekeleza kidhibiti kinachoiambia Tupperware wakati ni salama kutekeleza kila operesheni, na shughuli hizi zinaweza kubadilishwa au kucheleweshwa kwa muda. Katika mfano ulio hapo juu, kidhibiti hifadhidata kinaweza kumwambia Tupperware kusasisha seva 49 kati ya 50, lakini acha seva maalum (X) pekee kwa sasa. Kwa hivyo, ikiwa muda wa kusasisha kernel utapita na hifadhidata bado haiwezi kurejesha nakala yenye matatizo, Tupperware bado itasasisha seva ya X.

Tupperware: Muuaji wa Kubernetes wa Facebook?

Huduma nyingi za hali ya juu katika Tupperware hazitumii TaskControl sio moja kwa moja, lakini kupitia ShardManager, jukwaa la kawaida la kuunda huduma bora kwenye Facebook. Kwa kutumia Tupperware, wasanidi wanaweza kubainisha dhamira yao ya jinsi vyombo hasa vinapaswa kusambazwa kwenye vituo vya data. Kwa kutumia ShardManager, wasanidi programu hubainisha dhamira yao ya jinsi vipande vya data vinapaswa kusambazwa kwenye vyombo. ShardManager inafahamu uwekaji na urudiaji wa data ya programu zake na huwasiliana na Tupperware kupitia kiolesura cha TaskControl ili kuratibu utendakazi wa kontena bila kuhusika moja kwa moja kwa programu. Muunganisho huu hurahisisha sana usimamizi wa huduma za hali ya juu, lakini TaskControl ina uwezo wa kufanya zaidi. Kwa mfano, kiwango chetu cha kina cha wavuti hakina uraia na hutumia TaskControl kurekebisha kwa kasi kiwango cha masasisho kwenye vyombo. Hatimaye kiwango cha wavuti kinaweza kukamilisha haraka matoleo mengi ya programu kwa siku bila kuathiri upatikanaji.

Kusimamia seva katika vituo vya data

Tupperware ilipozinduliwa kwa mara ya kwanza mwaka wa 2011, kila nguzo ya seva ilisimamiwa na kipanga ratiba tofauti. Wakati huo, kikundi cha Facebook kilikuwa kikundi cha rafu za seva zilizounganishwa kwenye swichi moja ya mtandao, na kituo cha data kilikuwa na vikundi kadhaa. Kipanga ratiba kinaweza tu kudhibiti seva katika kundi moja, kumaanisha kuwa kazi haikuweza kuenea katika makundi mengi. Miundombinu yetu ilikua, tulizidi kuandika vikundi. Kwa kuwa Tupperware haikuweza kuhamisha kazi kutoka kwa nguzo iliyokataliwa hadi kwa vikundi vingine bila mabadiliko, ilihitaji juhudi nyingi na uratibu wa makini kati ya wasanidi programu na waendeshaji wa kituo cha data. Mchakato huu ulisababisha rasilimali kupotea wakati seva zilipofanya kazi kwa miezi kadhaa kutokana na taratibu za kusitisha utumaji.

Tuliunda wakala wa rasilimali ili kutatua tatizo la kukomesha matumizi ya nguzo na kuratibu aina nyingine za kazi za urekebishaji. Wakala wa rasilimali hufuatilia maelezo yote halisi yanayohusiana na seva na huamua kwa uthabiti ni kiratibu kipi kinachodhibiti kila seva. Kuunganisha seva kwa vipanga ratiba huruhusu kipanga ratiba kudhibiti seva katika vituo tofauti vya data. Kwa kuwa kazi ya Tupperware haina kikomo tena kwa kundi moja, watumiaji wa Tupperware wanaweza kubainisha jinsi vyombo vinapaswa kusambazwa katika vikoa vyenye hitilafu. Kwa mfano, msanidi programu anaweza kutangaza nia yake (hebu tuseme: "endesha kazi yangu kwenye vikoa 2 vya makosa katika eneo la PRN") bila kutaja maeneo maalum ya upatikanaji. Tupperware yenyewe itapata seva zinazofaa kutekeleza nia hii, hata kama nguzo au huduma imeondolewa.

Inaweza kuhimili mfumo mzima wa kimataifa

Kihistoria, miundombinu yetu imegawanywa katika mamia ya seva zilizojitolea kwa timu mahususi. Kwa sababu ya kugawanyika na ukosefu wa viwango, tulikuwa na gharama kubwa za uendeshaji, na seva zisizo na kazi zilikuwa ngumu zaidi kutumia tena. Katika mkutano wa mwaka jana Mifumo @Scale tuliwasilisha miundombinu kama huduma (IaaS), ambayo inapaswa kuunganisha miundombinu yetu kuwa mbuga kubwa ya seva moja. Lakini hifadhi moja ya seva ina shida zake. Lazima ikidhi mahitaji fulani:

  • Scalability. Miundombinu yetu ilikua tulipoongeza vituo vya data katika kila eneo. Seva zimekuwa ndogo na zenye ufanisi zaidi wa nishati, kwa hivyo kuna nyingi zaidi katika kila mkoa. Kwa hivyo, kipanga ratiba kimoja kwa kila eneo hakiwezi kushughulikia idadi ya kontena zinazoweza kuendeshwa kwa mamia ya maelfu ya seva katika kila eneo.
  • Kuegemea Hata kama kipanga ratiba kinaweza kuongezwa kiasi hicho, upeo mkubwa wa kipanga ratiba unamaanisha kuwa kuna hatari kubwa ya makosa na eneo zima la makontena linaweza kuwa lisiloweza kudhibitiwa.
  • Uvumilivu wa makosa. Katika tukio la kushindwa kwa miundombinu kubwa (kwa mfano, seva zinazoendesha kipangaji zinashindwa kutokana na kushindwa kwa mtandao au kukatika kwa umeme), matokeo mabaya yanapaswa kuathiri tu sehemu ya seva katika eneo hilo.
  • Urahisi wa matumizi. Inaweza kuonekana kuwa unahitaji kuendesha vipanga ratiba kadhaa huru kwa eneo moja. Lakini kwa mtazamo wa kufaa, hatua moja ya kuingia katika bwawa la pamoja la eneo hurahisisha kudhibiti uwezo na kazi.

Tuligawanya mpangilio katika shards ili kutatua matatizo ya kudumisha bwawa kubwa la pamoja. Kila shard ya kipanga ratiba inasimamia seti yake ya kazi katika eneo, na hii inapunguza hatari inayohusishwa na kipanga ratiba. Kadiri bwawa la pamoja linavyokua, tunaweza kuongeza vipanga ratiba zaidi. Kwa watumiaji wa Tupperware, shadi na proksi za kiratibu huonekana kama paneli moja dhibiti. Sio lazima kufanya kazi na rundo la shards ambayo hupanga kazi. Vipande vya kuratibu ni tofauti kimsingi na vipanga ratiba vya nguzo tulivyotumia hapo awali, wakati paneli dhibiti iligawanywa bila kugawanya mkusanyiko wa seva zilizoshirikiwa kulingana na topolojia ya mtandao.

Boresha Ufanisi wa Matumizi na Kompyuta ya Elastic

Kadiri miundombinu yetu inavyokuwa kubwa, ndivyo inavyokuwa muhimu zaidi kutumia seva zetu kwa ufanisi ili kuongeza gharama za miundombinu na kupunguza mzigo. Kuna njia mbili za kuongeza ufanisi wa matumizi ya seva:

  • Kompyuta yenye nguvu - punguza huduma za mtandaoni wakati wa saa tulivu na utumie seva zisizolipishwa kwa mzigo wa kazi nje ya mtandao, kama vile kujifunza kwa mashine na kazi za MapReduce.
  • Kupakia kupita kiasi - Weka huduma za mtandaoni na mizigo ya bechi kwenye seva zile zile ili mzigo wa kazi wa kundi uendeshwe kwa kipaumbele cha chini.

Shida katika vituo vyetu vya data ni matumizi ya nguvu. Kwa hivyo, tunapendelea seva ndogo, zisizo na nishati ambazo kwa pamoja hutoa nguvu zaidi ya usindikaji. Kwa bahati mbaya, kwenye seva ndogo zilizo na CPU kidogo na kumbukumbu, upakiaji mwingi haufanyi kazi vizuri. Bila shaka, tunaweza kuweka vyombo kadhaa vya huduma ndogo kwenye seva moja ndogo ya ufanisi wa nishati ambayo hutumia rasilimali ndogo za processor na kumbukumbu, lakini huduma kubwa zitakuwa na utendaji mdogo katika hali hii. Kwa hivyo, tunawashauri watengenezaji wa huduma zetu kubwa kuziboresha ili watumie seva nzima.


Kimsingi, tunaboresha ufanisi wa matumizi kwa kutumia kompyuta ya elastic. Nyingi za huduma zetu kuu, kama vile Mlisho wa Habari, kipengele cha Kutuma Ujumbe, na safu ya wavuti ya mwisho, hutofautiana kulingana na wakati wa siku. Tunapunguza kwa makusudi huduma za mtandaoni wakati wa saa tulivu na kutumia seva zisizolipishwa kwa mzigo wa kazi nje ya mtandao, kama vile kujifunza kwa mashine na kazi za MapReduce.

Tupperware: Muuaji wa Kubernetes wa Facebook?

Tunajua kutokana na uzoefu kwamba ni bora kutoa seva nzima kama vitengo vya uwezo wa kunyumbulika kwa sababu huduma kubwa ni wafadhili wakuu na watumiaji wakuu wa uwezo wa kunyumbulika, na zimeboreshwa ili kutumia seva nzima. Seva inapotolewa kutoka kwa huduma ya mtandaoni wakati wa saa tulivu, wakala wa rasilimali hukodisha seva kwa kipanga ratiba ili kutekeleza mzigo wa kazi nje ya mtandao. Ikiwa huduma ya mtandaoni inakabiliwa na mzigo wa kilele, wakala wa rasilimali hukumbuka haraka seva iliyokopwa na, pamoja na mpangilio, huirudisha kwenye huduma ya mtandaoni.

Mafunzo na mipango ya siku zijazo

Kwa miaka 8 iliyopita, tumekuwa tukitengeneza Tupperware ili kuendana na ukuaji wa haraka wa Facebook. Tunashiriki yale tuliyojifunza na tunatumai yatasaidia wengine kudhibiti miundomsingi inayokua kwa kasi:

  • Sanidi muunganisho unaonyumbulika kati ya paneli dhibiti na seva inazozisimamia. Unyumbufu huu huruhusu paneli dhibiti kudhibiti seva katika vituo tofauti vya data, husaidia kuweka kiotomatiki uondoaji na matengenezo ya vikundi, na kuwezesha ugawaji wa uwezo unaobadilika kwa kutumia kompyuta nyumbufu.
  • Ukiwa na jopo moja dhibiti katika eneo, inakuwa rahisi zaidi kufanya kazi na kazi na rahisi kudhibiti kundi kubwa la seva iliyoshirikiwa. Kumbuka kuwa paneli dhibiti hudumisha sehemu moja ya kuingia, hata ikiwa muundo wake wa ndani umetenganishwa kwa sababu za ukubwa au uvumilivu wa makosa.
  • Kwa kutumia muundo wa programu-jalizi, paneli dhibiti inaweza kuarifu programu za nje za uendeshaji wa kontena zijazo. Zaidi ya hayo, huduma bora zinaweza kutumia kiolesura cha programu-jalizi kubinafsisha usimamizi wa kontena. Kwa modeli hii ya programu-jalizi, paneli dhibiti hutoa unyenyekevu huku ikihudumia kwa ufanisi huduma nyingi tofauti za serikali.
  • Tunaamini kuwa kompyuta nyororo, ambapo tunaondoa seva nzima kutoka kwa huduma za wafadhili kwa kazi za kundi, kujifunza kwa mashine na huduma zingine zisizo za dharura, ndiyo njia bora ya kuboresha utendakazi wa seva ndogo, zinazotumia nishati.

Tunaanza kutekeleza meli moja ya kimataifa ya seva iliyoshirikiwa. Kwa sasa takriban 20% ya seva zetu ziko kwenye kundi la pamoja. Ili kufikia 100%, masuala mengi yanahitaji kushughulikiwa, ikiwa ni pamoja na kudumisha hifadhi ya pamoja, matengenezo ya kiotomatiki, kudhibiti mahitaji ya wapangaji mbalimbali, kuboresha matumizi ya seva na kuboresha usaidizi wa mzigo wa kujifunza mashine. Hatuwezi kusubiri kukabiliana na changamoto hizi na kushiriki mafanikio yetu.

Chanzo: mapenzi.com

Kuongeza maoni