Ni 2019, na bado hatuna suluhu ya kawaida ya ujumlishaji wa kumbukumbu katika Kubernetes. Katika makala hii, tungependa, kwa kutumia mifano kutoka kwa mazoezi halisi, kushiriki utafutaji wetu, matatizo yaliyokutana na ufumbuzi wao.
Walakini, kwanza, nitafanya uhifadhi kwamba wateja tofauti wanaelewa mambo tofauti sana kwa kukusanya kumbukumbu:
- mtu anataka kuona kumbukumbu za usalama na ukaguzi;
- mtu - ukataji wa kati wa miundombinu yote;
- na kwa baadhi, ni ya kutosha kukusanya magogo ya maombi tu, ukiondoa, kwa mfano, mizani.
Ifuatayo ni sehemu iliyo hapa chini kuhusu jinsi tulivyotekeleza "orodha za matakwa" mbalimbali na matatizo gani tuliyokumbana nayo.
Nadharia: kuhusu zana za ukataji miti
Usuli juu ya vipengele vya mfumo wa ukataji miti
Ukataji miti umekuja kwa muda mrefu, kama matokeo ya ambayo mbinu za kukusanya na kuchambua kumbukumbu zimeandaliwa, ambazo ndizo tunazotumia leo. Huko nyuma katika miaka ya 1950, Fortran ilianzisha analogi ya mitiririko ya kawaida ya pembejeo/pato, ambayo ilisaidia mpangaji programu kutatua programu yake. Hizi zilikuwa kumbukumbu za kwanza za kompyuta ambazo zilifanya maisha kuwa rahisi kwa watengeneza programu wa nyakati hizo. Leo tunaona ndani yao sehemu ya kwanza ya mfumo wa ukataji miti - chanzo au "mtayarishaji" wa kumbukumbu.
Sayansi ya kompyuta haikusimama: mitandao ya kompyuta ilionekana, makundi ya kwanza ... Mifumo tata yenye kompyuta kadhaa ilianza kufanya kazi. Sasa wasimamizi wa mfumo walilazimika kukusanya magogo kutoka kwa mashine kadhaa, na katika hali maalum wangeweza kuongeza ujumbe wa kernel ya OS ikiwa watahitaji kuchunguza kushindwa kwa mfumo. Ili kuelezea mifumo ya kati ya ukusanyaji wa kumbukumbu, katika miaka ya mapema ya 2000 ilichapishwa , ambayo ilisanifisha remote_syslog. Hivi ndivyo sehemu nyingine muhimu ilionekana: mtoza logi na uhifadhi wao.
Pamoja na ongezeko la kiasi cha magogo na kuanzishwa kwa teknolojia za mtandao, swali liliibuka kuhusu ni kumbukumbu gani zinahitajika kuonyeshwa kwa urahisi kwa watumiaji. Zana rahisi za koni (awk/sed/grep) zimebadilishwa na zile za hali ya juu zaidi watazamaji wa kumbukumbu - sehemu ya tatu.
Kutokana na ongezeko la kiasi cha magogo, kitu kingine kilikuwa wazi: magogo yanahitajika, lakini sio yote. Na magogo tofauti yanahitaji viwango tofauti vya uhifadhi: zingine zinaweza kupotea kwa siku, wakati zingine zinahitaji kuhifadhiwa kwa miaka 5. Kwa hivyo, sehemu ya kuchuja na kuelekeza mtiririko wa data iliongezwa kwenye mfumo wa ukataji miti - wacha tuiite chujio.
Uhifadhi pia umefanya hatua kubwa: kutoka kwa faili za kawaida hadi hifadhidata za uhusiano, na kisha uhifadhi unaozingatia hati (kwa mfano, Elasticsearch). Kwa hiyo hifadhi ilitenganishwa na mtozaji.
Hatimaye, dhana yenyewe ya logi imepanuka hadi aina ya mkondo dhahania wa matukio ambayo tunataka kuhifadhi kwa ajili ya historia. Au tuseme, ikiwa unahitaji kufanya uchunguzi au kuandaa ripoti ya uchambuzi ...
Kwa hivyo, katika kipindi kifupi cha muda, mkusanyiko wa kumbukumbu umekua mfumo mdogo muhimu, ambao unaweza kuitwa moja ya vifungu katika Data Kubwa.
Ikiwa mara moja kwa wakati prints za kawaida zinaweza kutosha kwa "mfumo wa magogo," sasa hali imebadilika sana.
Kubernetes na magogo
Kubernetes ilipokuja kwenye miundombinu, shida iliyopo ya kukusanya magogo haikuipita pia. Kwa namna fulani, ikawa chungu zaidi: kusimamia jukwaa la miundombinu haikuwa rahisi tu, lakini pia ngumu wakati huo huo. Huduma nyingi za zamani zimeanza kuhamia huduma ndogo ndogo. Katika muktadha wa kumbukumbu, hii inaonekana katika kuongezeka kwa idadi ya vyanzo vya kumbukumbu, mzunguko wao maalum wa maisha, na hitaji la kufuatilia uhusiano wa vipengee vyote vya mfumo kupitia kumbukumbu...
Kuangalia mbele, naweza kusema kwamba sasa, kwa bahati mbaya, hakuna chaguo sanifu la ukataji miti kwa Kubernetes ambalo linaweza kulinganisha vyema na wengine wote. Miradi maarufu zaidi katika jamii ni kama ifuatavyo.
- mtu anakunjua rundo EFK (Elasticsearch, Fluentd, Kibana);
- mtu anajaribu iliyotolewa hivi karibuni au matumizi ;
- sisi (na labda sio sisi tu? ..) Nimeridhika sana na maendeleo yangu mwenyewe - ...
Kama sheria, tunatumia vifurushi vifuatavyo katika nguzo za K8s (kwa suluhu zinazojisimamia):
- ;
- .
Walakini, sitakaa juu ya maagizo ya usakinishaji na usanidi wao. Badala yake, nitazingatia mapungufu yao na hitimisho zaidi la kimataifa kuhusu hali na magogo kwa ujumla.
Fanya mazoezi na magogo katika K8s
"Magogo ya kila siku", je mko wangapi?..
Mkusanyiko wa kati wa magogo kutoka kwa miundombinu mikubwa unahitaji rasilimali nyingi, ambazo zitatumika katika kukusanya, kuhifadhi na kusindika magogo. Wakati wa uendeshaji wa miradi mbalimbali, tulikabiliwa na mahitaji mbalimbali na matatizo ya uendeshaji yaliyotokana nayo.
Wacha tujaribu ClickHouse
Wacha tuangalie uhifadhi wa kati kwenye mradi na programu ambayo hutoa kumbukumbu kikamilifu: zaidi ya mistari 5000 kwa sekunde. Wacha tuanze kufanya kazi na kumbukumbu zake, tukiziongeza kwa ClickHouse.
Mara tu muda halisi unapohitajika, seva ya 4-msingi iliyo na ClickHouse itakuwa tayari imejaa kwenye mfumo mdogo wa diski:
Aina hii ya upakiaji ni kutokana na ukweli kwamba tunajaribu kuandika katika ClickHouse haraka iwezekanavyo. Na hifadhidata humenyuka kwa hili na kuongezeka kwa mzigo wa diski, ambayo inaweza kusababisha makosa yafuatayo:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Ukweli ni kwamba katika ClickHouse (zina data ya kumbukumbu) zina shida zao wakati wa shughuli za uandishi. Data iliyoingizwa ndani yao hutoa kizigeu cha muda, ambacho huunganishwa na jedwali kuu. Kama matokeo, rekodi inageuka kuwa ya kuhitaji sana kwenye diski, na pia iko chini ya kizuizi ambacho tulipokea ilani hapo juu: hakuna sehemu ndogo zaidi ya 1 zinaweza kuunganishwa kwa sekunde 300 (kwa kweli, hii ni viingilio 300. kwa sekunde).
Ili kuepuka tabia hii, kwa vipande vikubwa iwezekanavyo na si zaidi ya mara 1 kila sekunde 2. Walakini, kuandika kwa milipuko mikubwa kunapendekeza kwamba tunapaswa kuandika mara kwa mara kwenye ClickHouse. Hii, kwa upande wake, inaweza kusababisha kufurika kwa buffer na upotezaji wa kumbukumbu. Suluhisho ni kuongeza bafa ya Fluentd, lakini basi matumizi ya kumbukumbu pia yataongezeka.
Kumbuka: Kipengele kingine cha shida cha suluhisho letu na ClickHouse kilihusiana na ukweli kwamba ugawaji katika kesi yetu (loghouse) unatekelezwa kupitia meza za nje zilizounganishwa. . Hii inasababisha ukweli kwamba wakati wa sampuli za vipindi vikubwa vya wakati, RAM nyingi inahitajika, kwani metatable iterates kupitia partitions zote - hata zile ambazo ni wazi hazina data muhimu. Walakini, sasa mbinu hii inaweza kutangazwa kuwa haijatumika kwa matoleo ya sasa ya ClickHouse (c ).
Matokeo yake, inakuwa wazi kwamba si kila mradi una rasilimali za kutosha za kukusanya magogo kwa wakati halisi katika ClickHouse (kwa usahihi, usambazaji wao hautakuwa sahihi). Kwa kuongeza, utahitaji kutumia Π°ΠΊΠΊΡΠΌΡΠ»ΡΡΠΎΡ, ambayo tutarudi baadaye. Kesi iliyoelezwa hapo juu ni ya kweli. Na wakati huo hatukuweza kutoa suluhisho la kuaminika na thabiti ambalo lingefaa mteja na kuturuhusu kukusanya kumbukumbu kwa kuchelewa kidogo...
Vipi kuhusu Elasticsearch?
Elasticsearch inajulikana kushughulikia mzigo mzito wa kazi. Wacha tujaribu katika mradi huo huo. Sasa mzigo unaonekana kama hii:
Elasticsearch iliweza kuchimba mkondo wa data, hata hivyo, kuandika idadi kama hiyo kwake hutumia sana CPU. Hii inaamuliwa kwa kupanga kikundi. Kitaalam, hii sio shida, lakini zinageuka kuwa tu kutumia mfumo wa ukusanyaji wa logi tayari tunatumia takriban cores 8 na tuna sehemu ya ziada iliyopakiwa kwenye mfumo ...
Chini ya msingi: chaguo hili linaweza kuhesabiwa haki, lakini tu ikiwa mradi ni mkubwa na usimamizi wake uko tayari kutumia rasilimali muhimu kwenye mfumo wa kati wa ukataji miti.
Kisha swali la asili linatokea:
Ni magogo gani yanahitajika kweli?
Wacha tujaribu kubadilisha mbinu yenyewe: magogo yanapaswa kuwa ya habari wakati huo huo na sio kufunika kila tukio katika mfumo.
Wacha tuseme tuna duka la mtandaoni lililofanikiwa. Ni kumbukumbu gani ni muhimu? Kukusanya taarifa nyingi iwezekanavyo, kwa mfano, kutoka kwa lango la malipo, ni wazo nzuri. Lakini sio kumbukumbu zote kutoka kwa huduma ya kukata picha katika orodha ya bidhaa ni muhimu kwetu: makosa tu na ufuatiliaji wa hali ya juu ni wa kutosha (kwa mfano, asilimia ya makosa 500 ambayo sehemu hii inazalisha).
Kwa hivyo tumefikia hitimisho kwamba ukataji miti katikati sio haki kila wakati. Mara nyingi mteja anataka kukusanya kumbukumbu zote mahali pamoja, ingawa kwa kweli, kutoka kwa logi nzima, ni 5% tu ya ujumbe ambao ni muhimu kwa biashara unahitajika:
- Wakati mwingine inatosha kusanidi, sema, tu saizi ya logi ya chombo na mtoza makosa (kwa mfano, Sentry).
- Arifa ya hitilafu na kumbukumbu kubwa ya ndani yenyewe mara nyingi inaweza kutosha kuchunguza matukio.
- Tulikuwa na miradi iliyohusiana na majaribio ya utendakazi wa kipekee na mifumo ya kukusanya makosa. Msanidi programu hakuhitaji kumbukumbu kama hizo - waliona kila kitu kutoka kwa athari za makosa.
Mchoro kutoka kwa maisha
Hadithi nyingine inaweza kuwa mfano mzuri. Tulipokea ombi kutoka kwa timu ya usalama ya mmoja wa wateja wetu ambaye tayari alikuwa akitumia suluhisho la kibiashara ambalo lilitengenezwa muda mrefu kabla ya Kubernetes kuanzishwa.
Ilihitajika "kufanya urafiki" wa mfumo wa kati wa kukusanya logi na sensor ya kugundua shida ya kampuni - QRadar. Mfumo huu unaweza kupokea kumbukumbu kupitia itifaki ya syslog na kuzipata kutoka kwa FTP. Hata hivyo, haikuwezekana mara moja kuiunganisha na programu-jalizi ya remote_syslog kwa ufasaha (kama ilivyotokea, ). Shida za kusanidi QRadar ziligeuka kuwa upande wa timu ya usalama ya mteja.
Kwa hivyo, sehemu ya kumbukumbu muhimu za biashara ilipakiwa kwa FTP QRadar, na sehemu nyingine ilielekezwa kupitia syslog ya mbali moja kwa moja kutoka kwa nodi. Kwa hili tuliandika hata - labda itasaidia mtu kutatua tatizo sawa ... Shukrani kwa mpango uliosababisha, mteja mwenyewe alipokea na kuchambua magogo muhimu (kwa kutumia zana zake zinazopenda), na tuliweza kupunguza gharama ya mfumo wa ukataji miti, kuokoa tu mwezi uliopita.
Mfano mwingine ni dalili ya kile usichopaswa kufanya. Mmoja wa wateja wetu kwa usindikaji kila mmoja matukio yanayotoka kwa mtumiaji, yametengenezwa kwa mitandao mingi pato lisilo na muundo habari katika logi. Kama unavyoweza kudhani, kumbukumbu kama hizo hazikuwa rahisi sana kusoma na kuhifadhi.
Vigezo vya magogo
Mifano hiyo inaongoza kwa hitimisho kwamba pamoja na kuchagua mfumo wa ukusanyaji wa logi, unahitaji pia tengeneza magogo yenyewe! Je, ni mahitaji gani hapa?
- Kumbukumbu lazima ziwe katika umbizo linaloweza kusomeka kwa mashine (kwa mfano, JSON).
- Kumbukumbu zinapaswa kuwa fupi na zenye uwezo wa kubadilisha kiwango cha ukataji miti ili kutatua shida zinazowezekana. Wakati huo huo, katika mazingira ya uzalishaji unapaswa kuendesha mifumo yenye kiwango cha ukataji miti kama onyo au kosa.
- Kumbukumbu lazima ziwe za kawaida, yaani, katika kitu cha logi, mistari yote lazima iwe na aina sawa ya shamba.
Kumbukumbu zisizo na muundo zinaweza kusababisha matatizo na kupakia magogo kwenye hifadhi na kuacha kabisa katika usindikaji wao. Kama kielelezo, hapa kuna mfano na hitilafu 400, ambayo wengi wamekutana nayo katika magogo fasaha:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Hitilafu inamaanisha kuwa unatuma sehemu ambayo aina yake si dhabiti kwa faharasa yenye ramani iliyotengenezwa tayari. Mfano rahisi zaidi ni uwanja kwenye logi ya nginx na kutofautisha $upstream_status. Inaweza kuwa na nambari au mfuatano. Kwa mfano:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Kumbukumbu zinaonyesha kuwa seva 10.100.0.10 ilijibu kwa hitilafu 404 na ombi lilitumwa kwa hifadhi nyingine ya maudhui. Kama matokeo, thamani kwenye magogo ikawa kama hii:
"upstream_response_time": "0.001, 0.007"
Hali hii ni ya kawaida sana hata inastahili kujitenga .
Vipi kuhusu kutegemewa?
Kuna nyakati ambapo kumbukumbu zote bila ubaguzi ni muhimu. Na kwa hili, mipango ya kawaida ya kukusanya kumbukumbu kwa K8 zilizopendekezwa/kujadiliwa hapo juu zina matatizo.
Kwa mfano, ufasaha hauwezi kukusanya kumbukumbu kutoka kwa vyombo vya muda mfupi. Katika moja ya miradi yetu, kontena ya uhamiaji ya hifadhidata iliishi kwa chini ya sekunde 4 na kisha ikafutwa - kulingana na maelezo yanayolingana:
"helm.sh/hook-delete-policy": hook-succeeded
Kwa sababu hii, logi ya utekelezaji wa uhamiaji haikujumuishwa kwenye hifadhi. Siasa inaweza kusaidia katika kesi hii. before-hook-creation.
Mfano mwingine ni mzunguko wa logi wa Docker. Wacha tuseme kuna programu ambayo inaandika kikamilifu kwa kumbukumbu. Chini ya hali ya kawaida, tunaweza kushughulikia magogo yote, lakini mara tu tatizo linapoonekana - kwa mfano, kama ilivyoelezwa hapo juu na muundo usio sahihi - usindikaji huacha, na Docker huzunguka faili. Matokeo yake ni kwamba kumbukumbu muhimu za biashara zinaweza kupotea.
Ndiyo sababu ni muhimu kutenganisha mito ya logi, ikipachika kutuma zile za thamani zaidi moja kwa moja kwenye programu ili kuhakikisha usalama wao. Kwa kuongeza, haitakuwa superfluous kuunda baadhi "mkusanyiko" wa magogo, ambayo inaweza kustahimili kutopatikana kwa hifadhi fupi huku ikihifadhi ujumbe muhimu.
Hatimaye, hatupaswi kusahau hilo Ni muhimu kufuatilia mfumo mdogo wowote ipasavyo. Vinginevyo, ni rahisi kukimbia katika hali ambayo ufasaha ni katika hali CrashLoopBackOff na haitumi chochote, na hii inaahidi kupoteza habari muhimu.
Matokeo
Katika nakala hii, hatuangalii suluhisho za SaaS kama Datadog. Matatizo mengi yaliyoelezwa hapa tayari yametatuliwa kwa njia moja au nyingine na makampuni ya kibiashara yaliyobobea katika kukusanya magogo, lakini si kila mtu anaweza kutumia SaaS kwa sababu mbalimbali. (Zile kuu ni gharama na kufuata 152-FZ).
Mkusanyiko wa kumbukumbu wa kati mwanzoni inaonekana kama kazi rahisi, lakini sio kabisa. Ni muhimu kukumbuka kuwa:
- Vipengee muhimu pekee vinahitaji kuandikishwa kwa undani, wakati ufuatiliaji na ukusanyaji wa hitilafu unaweza kusanidiwa kwa mifumo mingine.
- Kumbukumbu katika uzalishaji zinapaswa kuwekwa kidogo ili usiongeze mzigo usiohitajika.
- Kumbukumbu lazima zisomeke kwa mashine, ziwe za kawaida, na ziwe na umbizo kali.
- Kumbukumbu muhimu sana zinapaswa kutumwa kwa mkondo tofauti, ambao unapaswa kutengwa na kuu.
- Inastahili kuzingatia mkusanyiko wa logi, ambayo inaweza kukuokoa kutokana na kupasuka kwa mzigo mkubwa na kufanya mzigo kwenye uhifadhi zaidi sare.
Sheria hizi rahisi, zikitumika kila mahali, zingeruhusu mizunguko iliyoelezwa hapo juu kufanya kazi - ingawa inakosa vipengele muhimu (betri). Ikiwa hutazingatia kanuni hizo, kazi itakuongoza kwa urahisi na miundombinu kwenye sehemu nyingine yenye kubeba sana (na wakati huo huo isiyofaa) ya mfumo.
PS
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com